What is the difference between logical data model and conceptual data model?
逻辑数据模型和概念数据模型有什么区别?
9 个解决方案
#1
45
In the conceptual data model you worry only about the high level design - what tables should exist and the connections between them. In this phase you recognize entities in your model and the relationships between them.
在概念数据模型中，您只关心高级设计——应该存在哪些表以及它们之间的连接。在这个阶段，您可以识别模型中的实体以及它们之间的关系。
The logical model comes after the conceptual modeling when you explicitly define what the columns in each table are. While writing the logical model, you might also take into consideration the actual database system you're designing for, but only if it affects the design (i.e., if there are no triggers you might want to remove some redundancy column etc.)
逻辑模型出现在概念建模之后，当您显式地定义每个表中的列时。在编写逻辑模型时，您可能还会考虑您正在设计的实际数据库系统，但前提是它会影响设计(例如。，如果没有触发器，您可能想要删除一些冗余列等)
There is also physical model which elaborates on the logical model and assigns each column with it's type/length etc.
还有一个物理模型，它详细描述逻辑模型，并为每个列分配类型/长度等。
Here is a good picture that describes each of the three levels.
这是一幅描述三个层次的好图片。
#2
15
In this table you can see the difference between each model: 
在这个表格中你可以看到每个模型的不同:
See http://www.1keydata.com/datawarehousing/data-modeling-levels.html for more information and some data model examples.
有关更多信息和一些数据模型示例，请参见http://www.1keydata.com/datawarehousing/data-modeling-levels.html。
#3
8
These terms are unfortunately overloaded with several possible definitions. According to the ANSI-SPARC "three schema" model for instance, the Conceptual Schema or Conceptual Model consists of the set of objects in a database (tables, views, etc) in contrast to the External Schema which are the objects that users see.
不幸的是，这些术语超载了几个可能的定义。例如，根据ANSI-SPARC“三个模式”模型，概念模式或概念模型由数据库中的一组对象(表、视图等)组成，而外部模式是用户看到的对象。
In the data management professions and especially among data modellers / architects, the term Conceptual Model is frequently used to mean a semantic model whereas the term Logical Model is used to mean a preliminary or virtual database design. This is probably the usage you are most likely to come across in the workplace.
在数据管理行业，特别是在数据建模者/架构师中，概念模型这个术语经常被用来表示语义模型，而逻辑模型这个术语则被用来表示初步的或虚拟的数据库设计。这可能是你在工作中最可能遇到的用法。
In academic usage and when describing DBMS architectures however, the Logical level means the database objects (tables, views, tables, keys, constraints, etc), as distinct from the Physical level (files, indexes, storage). To confuse things further, in the workplace the term Physical model is often used to mean the design as implemented or planned for implementation in an actual database. That may include both "physical" and "logical" level constructs (both tables and indexes for example).
然而，在学术上的使用和描述DBMS架构时，逻辑层意味着与物理层(文件、索引、存储)不同的数据库对象(表、视图、表、键、约束等)。更让人困惑的是，在工作环境中，术语“物理模型”通常用于表示在实际数据库中实现或计划实现的设计。这可能包括“物理”和“逻辑”级别构造(例如表和索引)。
When you come across any of these terms you really need to seek clarification on what is being described unless the context makes it obvious.
当你遇到这些术语的时候，你确实需要对所描述的内容进行澄清，除非上下文很明显。
For a discussion of these differences, check out Data Modelling Essentials by Simsion and Witt for example.
要讨论这些差异，请查看Simsion和Witt的数据建模要点。
#4
2
Logical Database Model
逻辑数据库模型
Logical database modeling is required for compiling business requirements and representing the requirements as a model. It is mainly associated with the gathering of business needs rather than the database design. The information that needs to be gathered is about organizational units, business entities, and business processes.
需要逻辑数据库建模来编译业务需求并将需求表示为模型。它主要与业务需求的收集相关，而不是数据库设计。需要收集的信息是关于组织单元、业务实体和业务流程的。
Once the information is compiled, reports and diagrams are made, including these:
一旦资料被汇编，就会编制报告和图表，包括:
ERD–Entity relationship diagram shows the relationship between different categories of data and shows the different categories of data required for the development of a database. Business process diagram–It shows the activities of individuals within the company. It shows how the data moves within the organization based on which application interface can be designed. Feedback documentation by users.
ERD-Entity关系图显示了不同类别的数据之间的关系，并显示了数据库开发所需的不同类别的数据。业务流程图表——显示公司内部个人的活动。它显示了数据如何在组织中移动，基于哪个应用程序接口可以被设计。用户反馈文档。
Logical database models basically determine if all the requirements of the business have been gathered. It is reviewed by developers, management, and finally the end users to see if more information needs to be gathered before physical modeling starts.
逻辑数据库模型主要确定是否收集了业务的所有需求。它由开发人员、管理人员和最终用户审阅，以查看在物理建模开始之前是否需要收集更多的信息。
Physical Database Model Physical database modeling deals with designing the actual database based on the requirements gathered during logical database modeling. All the information gathered is converted into relational models and business models. During physical modeling, objects are defined at a level called a schema level. A schema is considered a group of objects which are related to each other in a database. Tables and columns are made according to the information provided during logical modeling. Primary keys, unique keys, and foreign keys are defined in order to provide constraints. Indexes and snapshots are defined. Data can be summarized, and users are provided with an alternative perspective once the tables have been created.
物理数据库模型物理数据库建模处理基于在逻辑数据库建模过程中收集的需求而设计的实际数据库。所有收集到的信息都被转换为关系模型和业务模型。在物理建模期间，对象是在一个称为模式级别的级别上定义的。模式被认为是一组在数据库中相互关联的对象。表和列是根据逻辑建模期间提供的信息生成的。为了提供约束，定义了主键、惟一键和外键。定义了索引和快照。可以对数据进行汇总，并在创建表之后为用户提供另一种透视图。
Physical database modeling depends upon the software already being used in the organization. It is software specific. Physical modeling includes:
物理数据库建模依赖于组织中已经使用的软件。它是特定的软件。物理模型包括:
Server model diagram–It includes tables and columns and different relationships that exist within a database. Database design documentation. Feedback documentation of users.
服务器模型图——包括表和列以及数据库中存在的不同关系。数据库设计文档。反馈用户的文档。
Summary:
简介:
1.Logical database modeling is mainly for gathering information about business needs and does not involve designing a database; whereas physical database modeling is mainly required for actual designing of the database. 2.Logical database modeling does not include indexes and constraints; the logical database model for an application can be used across various database software and implementations; whereas physical database modeling is software and hardware specific and has indexes and constraints. 3.Logical database modeling includes; ERD, business process diagrams, and user feedback documentation; whereas physical database modeling includes; server model diagram, database design documentation, and user feedback documentation.
1。逻辑数据库建模主要用于收集有关业务需求的信息，不涉及数据库的设计;而物理数据库建模是数据库实际设计的主要要求。2。逻辑数据库建模不包括索引和约束;应用程序的逻辑数据库模型可以跨各种数据库软件和实现使用;而物理数据库建模是特定于软件和硬件的，并具有索引和约束。3所示。逻辑数据库建模包括;ERD、业务流程图和用户反馈文档;而物理数据库建模包括;服务器模型图、数据库设计文档和用户反馈文档。
Read more: Difference Between Logical and Physical Database Model | Difference Between | Logical vs Physical Database Model http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg
逻辑数据库模型和物理数据库模型之间的区别逻辑数据库模型和物理数据库模型之间的区别
#5
1
I need to produce both a logical model and a conceptual model. All the explanations here are really vague. The link posted above just shows the difference being that a conceptual model is a logical model without fields. Ok fine, I don't mention the name of the database. It appears to be totally redundant.
我需要同时生成逻辑模型和概念模型。这里所有的解释都很模糊。上面的链接只是显示了概念模型是没有字段的逻辑模型的区别。好的，我没有提到数据库的名字。它看起来是完全多余的。
I really don't know what 'semantic' means. can someone explain what I would do differently using 'english' and possibly post a link to better examples than a picture that shows one picture that has fields and one that does not. The buzzwords are all well and good, but its so vague its not useful to practically implement.
我真的不知道“语义”是什么意思。有人能解释一下我用“英语”做的不同之处吗?或许还可以发布一个链接，链接到更好的示例，而不是显示一张有字段的图片和一张没有字段的图片。这些流行语都很好，但它的含糊其辞，对实际执行来说没有多大用处。
do I do anything other than take my logical model (which is basically my physical model reversed engineered out of the DB, click a button in said tools and the images look a little different and then take off the data types).
除了使用我的逻辑模型(这基本上是我的物理模型反向设计了DB外，点击一个工具中的一个按钮，图像看起来有点不一样，然后去掉数据类型)，我还会做什么吗?
From what i can practically see (and without buzzwords)
从我能看到的东西(没有流行词)
physical model: actually tables. The little pictures have data types in them and named pk/fk constraints Logical Model: click the little button my tool (using Oracles SQL Developer Data Modeller, I dont have an erwin license and 2010 visio no longer reverse engineers out of the DB), and then the images on the screen change slightly. The data types are gone and the names of the constraints are gone, then the colors of the table representations changes to purple (so now I call them entities).
物理模型:实际上表。小图片有数据类型和命名pk /颗约束逻辑模型:点击小按钮工具(使用神谕SQL开发人员数据分析员,我不该有一个欧文许可证和2010 visio不再逆向工程师的DB),然后是图像在屏幕上略有变化。数据类型消失，约束名称消失，然后表表示的颜色变为紫色(因此现在我将它们称为实体)。
ok. so what would my Conceptual model look like other then: exact same thing as my logical model minus the fields. I would think there is more to it than this. Reciting that its a 'semantic' representation of data sounds real nice and fancy, but doesn't make sense to someone who has not made one of these before.
好的。那么，我的概念模型会是什么样子呢?和我的逻辑模型减去字段是完全一样的。我认为还有比这更重要的。背诵它是数据的“语义”表示听起来确实不错，但对于以前没有做过这些的人来说，这是没有意义的。
#6
1
Conceptual Schema - covers entities and relationships. Should be created first. Contrary to some of the other answers; tables are not defined here. For example a 'many to many' table is not included in a conceptual data model but is defined as a 'many to many' relationship between entities.
概念模式——涵盖实体和关系。应该首先创建。与其他一些答案相反;这里没有定义表。例如，“many to many”表不包含在概念数据模型中，而是定义为实体之间的“many to many”关系。
Logical Schema - Covers tables, attributes, keys, mandatory role constraints, and referential integrity with no regards to the physical implementation. Things like indexes are not defined, attribute types should be kept logical, e.g. text instead of varchar2. Should be created based on the conceptual schema.
逻辑模式——包含表、属性、键、强制角色约束和引用完整性，与物理实现无关。像索引之类的东西没有定义，属性类型应该保持逻辑，例如文本而不是varchar2。应该基于概念模式创建。
#7
0
Most answers here are strictly related to notations and syntax of the data models at different levels of abstraction. The key difference has not been mentioned by anyone. Conceptual models surface concepts. Concepts relate to other concepts in a different way that an Entity relates to another Entity at the Logical level of abstraction. Concepts are closer to Types. Usually at Conceptual level you display Types of things (this does not mean you must use the term "type" in your naming convention) and relationships between such types. Therefore, the existence of many-to-many relationships is not the rule but rather the consequence of the relationships between type-wise elements. In Logical Models Entities represent one instance of that thing in the real world. In Conceptual models it is not expected the description of an instance of an Entity and their relationships but rather the description of the "type" or "class" of that particular Entity. Examples: - Vehicles have Wheels and Wheels are used in Vehicles. At Conceptual level this is a many-to-many relationship - A particular Vehicle (a car by instance), with one specific registration number have 5 wheels and each particular wheel, each one with a serial number is related to only that particular car. At Logical level this is a one-to-many relationship.
这里的大多数答案都与不同抽象级别的数据模型的符号和语法严格相关。关键的区别没有被任何人提及。概念模型表面的概念。概念以一种不同的方式与其他概念相关联，这种方式与实体在逻辑抽象层次上与另一个实体相关联。概念更接近类型。通常在概念级别，您会显示事物的类型(这并不意味着您必须在命名约定中使用术语“type”)以及这些类型之间的关系。因此，多对多关系的存在不是规则，而是类型元素之间关系的结果。在逻辑模型中，实体表示现实世界中该事物的一个实例。在概念模型中，它不期望描述一个实体的实例及其关系，而是期望描述该实体的“类型”或“类”。例子:车辆有*和*。在概念层面上，这是一种多对多的关系——一辆特定的车(比如一辆车)，一个特定的注册号有5个*和每个特定的*，每个带有序列号的都只与那辆特定的车有关。在逻辑层面上，这是一对多的关系。
Conceptual covers "types/classes". Logical covers "instances".
概念涵盖了“类型/类”。逻辑覆盖“实例”。
I would add another comment about databases. I agree with one of the colleagues who commented above that Conceptual and Logical models have absolutely nothing about databases. Conceptual and Logical models describe the real world from a data perspective using notations such as ER or UML. Database vendors, smartly, designed their products to follow the same philosophy used to logically model the World and them created Relational Databases, making everyone's lifes easier. You can describe your organisation's data landscape at all the levels using Conceptual and Logical model and never use a relational database.
我将添加另一个关于数据库的评论。我同意其中一个同事的观点，即概念和逻辑模型完全没有关于数据库的东西。概念和逻辑模型使用符号(如ER或UML)从数据的角度描述真实世界。数据库供应商聪明地设计了他们的产品，以遵循逻辑地为世界建模的哲学，他们创建了关系数据库，使每个人的生活都更容易。您可以使用概念和逻辑模型来描述您的组织的所有级别的数据，并且永远不要使用关系数据库。
Well I guess this is my 2 cents...
我猜这是我的2分……
#8
0
This is an old question and maybe this comes way too late, but I don't see one very important aspect necessary to answering the question. That is, the TARGET audience for the data model. The Conceptual Data Model is the model generated from business analysis, from interviews with the BUSINESS about their data. It is not so much "high level" as it is the business's understanding of their data, business rules captured in the relationships between "candidate" entities. At this point, you are capturing the things of importance to the business (Employee, Customer, Contract, Account, etc.) and the relationships between them. The final Conceptual Data Model may be somewhat abstract -- for instance, treating Individuals and Organizations entering into a contract as subtypes of a "Party", Contractors and Permanent Employees as subtypes of an Employee, even Employees and Customers subtypes of "Person" -- but it is a document that a data modeler develops from discussions with the business SMEs and presents to the business for validation.
这是一个老问题，可能来得太晚了，但我认为没有一个非常重要的方面需要回答这个问题。即数据模型的目标受众。概念数据模型是由业务分析生成的模型，从对业务的访问和对数据的访问。与其说它是“高层”，不如说它是企业对其数据的理解，即在“候选”实体之间的关系中捕获的业务规则。此时，您正在捕获对业务(雇员、客户、合同、帐户等)和它们之间的关系重要的东西。最终的概念数据模型可能有点抽象,例如,把个人和组织进入一个合同作为“党”的亚型,承包商和永久的员工作为一个员工的亚型,甚至员工和客户类型的“人”——但这是一个文档,从讨论与业务数据建模师发展中小企业业务进行验证和礼物。
The Logical Data Model is not just "more detail" -- where useful and important, a Conceptual Data Model may well have attributes included -- it is the ARCHITECTURE document, the model that is presented to the software analysts/engineers to explain and specify the data requirements. It will resolve many-to-many relationships to association tables and will define all attributes, with examples and constraints, so that code can be written against the architecture.
逻辑数据模型不仅仅是“更详细的”——在有用和重要的地方，概念数据模型很可能包含了属性——它是体系结构文档，它被呈现给软件分析师/工程师来解释和指定数据需求。它将解析到关联表的多对多关系，并定义所有属性，包括示例和约束，以便可以针对架构编写代码。
The Physical model is that Logical Model generated specifically for a particular environment, such as SQL Server or Teradata or Oracle or whatever. It will have keys, indexes, partitions, or whatever is needed to implement, based on sizing, access frequency, security constraints, etc.
物理模型是为特定环境生成的逻辑模型，如SQL Server、Teradata或Oracle等。它将具有键、索引、分区，或者根据大小、访问频率、安全约束等需要实现的任何东西。
So, if you are being asked to develop a Conceptual Data Model, you are being asked to design the solution (or part of it) from scratch, getting your information from the business. There's more to it, but I hope that answers the question.
因此，如果您被要求开发一个概念性的数据模型，您将被要求从头设计解决方案(或部分解决方案)，从业务中获取您的信息。还有更多，但我希望这能回答问题。
#9
-1
logical data model
逻辑数据模型
A logical data model describes the data in as much detail as possible, without regard to how they will be physical implemented in the database. Features of a logical data model include: · Includes all entities and relationships among them. · All attributes for each entity are specified. · The primary key for each entity is specified. · Foreign keys (keys identifying the relationship between different entities) are specified. · Normalization occurs at this level. conceptual data model
逻辑数据模型尽可能详细地描述数据，而不考虑如何在数据库中实现这些数据。逻辑数据模型的特性包括:·包含所有实体和它们之间的关系。·指定每个实体的所有属性。·指定每个实体的主键。·指定外键(标识不同实体之间关系的键)。·标准化在这个级别发生。概念数据模型
A conceptual data model identifies the highest-level relationships between the different entities. Features of conceptual data model include: · Includes the important entities and the relationships among them. · No attribute is specified. · No primary key is specified.
概念数据模型标识不同实体之间的*关系。概念数据模型的特点包括:·包含重要实体及其之间的关系。·没有指定属性。·未指定主键。
#1
45
In the conceptual data model you worry only about the high level design - what tables should exist and the connections between them. In this phase you recognize entities in your model and the relationships between them.
在概念数据模型中，您只关心高级设计——应该存在哪些表以及它们之间的连接。在这个阶段，您可以识别模型中的实体以及它们之间的关系。
The logical model comes after the conceptual modeling when you explicitly define what the columns in each table are. While writing the logical model, you might also take into consideration the actual database system you're designing for, but only if it affects the design (i.e., if there are no triggers you might want to remove some redundancy column etc.)
逻辑模型出现在概念建模之后，当您显式地定义每个表中的列时。在编写逻辑模型时，您可能还会考虑您正在设计的实际数据库系统，但前提是它会影响设计(例如。，如果没有触发器，您可能想要删除一些冗余列等)
There is also physical model which elaborates on the logical model and assigns each column with it's type/length etc.
还有一个物理模型，它详细描述逻辑模型，并为每个列分配类型/长度等。
Here is a good picture that describes each of the three levels.
这是一幅描述三个层次的好图片。
#2
15
In this table you can see the difference between each model:
在这个表格中你可以看到每个模型的不同:
See http://www.1keydata.com/datawarehousing/data-modeling-levels.html for more information and some data model examples.
有关更多信息和一些数据模型示例，请参见http://www.1keydata.com/datawarehousing/data-modeling-levels.html。
#3
8
These terms are unfortunately overloaded with several possible definitions. According to the ANSI-SPARC "three schema" model for instance, the Conceptual Schema or Conceptual Model consists of the set of objects in a database (tables, views, etc) in contrast to the External Schema which are the objects that users see.
不幸的是，这些术语超载了几个可能的定义。例如，根据ANSI-SPARC“三个模式”模型，概念模式或概念模型由数据库中的一组对象(表、视图等)组成，而外部模式是用户看到的对象。
In the data management professions and especially among data modellers / architects, the term Conceptual Model is frequently used to mean a semantic model whereas the term Logical Model is used to mean a preliminary or virtual database design. This is probably the usage you are most likely to come across in the workplace.
在数据管理行业，特别是在数据建模者/架构师中，概念模型这个术语经常被用来表示语义模型，而逻辑模型这个术语则被用来表示初步的或虚拟的数据库设计。这可能是你在工作中最可能遇到的用法。
In academic usage and when describing DBMS architectures however, the Logical level means the database objects (tables, views, tables, keys, constraints, etc), as distinct from the Physical level (files, indexes, storage). To confuse things further, in the workplace the term Physical model is often used to mean the design as implemented or planned for implementation in an actual database. That may include both "physical" and "logical" level constructs (both tables and indexes for example).
然而，在学术上的使用和描述DBMS架构时，逻辑层意味着与物理层(文件、索引、存储)不同的数据库对象(表、视图、表、键、约束等)。更让人困惑的是，在工作环境中，术语“物理模型”通常用于表示在实际数据库中实现或计划实现的设计。这可能包括“物理”和“逻辑”级别构造(例如表和索引)。
When you come across any of these terms you really need to seek clarification on what is being described unless the context makes it obvious.
当你遇到这些术语的时候，你确实需要对所描述的内容进行澄清，除非上下文很明显。
For a discussion of these differences, check out Data Modelling Essentials by Simsion and Witt for example.
要讨论这些差异，请查看Simsion和Witt的数据建模要点。
#4
2
Logical Database Model
逻辑数据库模型
Logical database modeling is required for compiling business requirements and representing the requirements as a model. It is mainly associated with the gathering of business needs rather than the database design. The information that needs to be gathered is about organizational units, business entities, and business processes.
需要逻辑数据库建模来编译业务需求并将需求表示为模型。它主要与业务需求的收集相关，而不是数据库设计。需要收集的信息是关于组织单元、业务实体和业务流程的。
Once the information is compiled, reports and diagrams are made, including these:
一旦资料被汇编，就会编制报告和图表，包括:
ERD–Entity relationship diagram shows the relationship between different categories of data and shows the different categories of data required for the development of a database. Business process diagram–It shows the activities of individuals within the company. It shows how the data moves within the organization based on which application interface can be designed. Feedback documentation by users.
ERD-Entity关系图显示了不同类别的数据之间的关系，并显示了数据库开发所需的不同类别的数据。业务流程图表——显示公司内部个人的活动。它显示了数据如何在组织中移动，基于哪个应用程序接口可以被设计。用户反馈文档。
Logical database models basically determine if all the requirements of the business have been gathered. It is reviewed by developers, management, and finally the end users to see if more information needs to be gathered before physical modeling starts.
逻辑数据库模型主要确定是否收集了业务的所有需求。它由开发人员、管理人员和最终用户审阅，以查看在物理建模开始之前是否需要收集更多的信息。
Physical Database Model Physical database modeling deals with designing the actual database based on the requirements gathered during logical database modeling. All the information gathered is converted into relational models and business models. During physical modeling, objects are defined at a level called a schema level. A schema is considered a group of objects which are related to each other in a database. Tables and columns are made according to the information provided during logical modeling. Primary keys, unique keys, and foreign keys are defined in order to provide constraints. Indexes and snapshots are defined. Data can be summarized, and users are provided with an alternative perspective once the tables have been created.
物理数据库模型物理数据库建模处理基于在逻辑数据库建模过程中收集的需求而设计的实际数据库。所有收集到的信息都被转换为关系模型和业务模型。在物理建模期间，对象是在一个称为模式级别的级别上定义的。模式被认为是一组在数据库中相互关联的对象。表和列是根据逻辑建模期间提供的信息生成的。为了提供约束，定义了主键、惟一键和外键。定义了索引和快照。可以对数据进行汇总，并在创建表之后为用户提供另一种透视图。
Physical database modeling depends upon the software already being used in the organization. It is software specific. Physical modeling includes:
物理数据库建模依赖于组织中已经使用的软件。它是特定的软件。物理模型包括:
Server model diagram–It includes tables and columns and different relationships that exist within a database. Database design documentation. Feedback documentation of users.
服务器模型图——包括表和列以及数据库中存在的不同关系。数据库设计文档。反馈用户的文档。
Summary:
简介:
1.Logical database modeling is mainly for gathering information about business needs and does not involve designing a database; whereas physical database modeling is mainly required for actual designing of the database. 2.Logical database modeling does not include indexes and constraints; the logical database model for an application can be used across various database software and implementations; whereas physical database modeling is software and hardware specific and has indexes and constraints. 3.Logical database modeling includes; ERD, business process diagrams, and user feedback documentation; whereas physical database modeling includes; server model diagram, database design documentation, and user feedback documentation.
1。逻辑数据库建模主要用于收集有关业务需求的信息，不涉及数据库的设计;而物理数据库建模是数据库实际设计的主要要求。2。逻辑数据库建模不包括索引和约束;应用程序的逻辑数据库模型可以跨各种数据库软件和实现使用;而物理数据库建模是特定于软件和硬件的，并具有索引和约束。3所示。逻辑数据库建模包括;ERD、业务流程图和用户反馈文档;而物理数据库建模包括;服务器模型图、数据库设计文档和用户反馈文档。
Read more: Difference Between Logical and Physical Database Model | Difference Between | Logical vs Physical Database Model http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg
逻辑数据库模型和物理数据库模型之间的区别逻辑数据库模型和物理数据库模型之间的区别
#5
1
I need to produce both a logical model and a conceptual model. All the explanations here are really vague. The link posted above just shows the difference being that a conceptual model is a logical model without fields. Ok fine, I don't mention the name of the database. It appears to be totally redundant.
我需要同时生成逻辑模型和概念模型。这里所有的解释都很模糊。上面的链接只是显示了概念模型是没有字段的逻辑模型的区别。好的，我没有提到数据库的名字。它看起来是完全多余的。
I really don't know what 'semantic' means. can someone explain what I would do differently using 'english' and possibly post a link to better examples than a picture that shows one picture that has fields and one that does not. The buzzwords are all well and good, but its so vague its not useful to practically implement.
我真的不知道“语义”是什么意思。有人能解释一下我用“英语”做的不同之处吗?或许还可以发布一个链接，链接到更好的示例，而不是显示一张有字段的图片和一张没有字段的图片。这些流行语都很好，但它的含糊其辞，对实际执行来说没有多大用处。
do I do anything other than take my logical model (which is basically my physical model reversed engineered out of the DB, click a button in said tools and the images look a little different and then take off the data types).
除了使用我的逻辑模型(这基本上是我的物理模型反向设计了DB外，点击一个工具中的一个按钮，图像看起来有点不一样，然后去掉数据类型)，我还会做什么吗?
From what i can practically see (and without buzzwords)
从我能看到的东西(没有流行词)
physical model: actually tables. The little pictures have data types in them and named pk/fk constraints Logical Model: click the little button my tool (using Oracles SQL Developer Data Modeller, I dont have an erwin license and 2010 visio no longer reverse engineers out of the DB), and then the images on the screen change slightly. The data types are gone and the names of the constraints are gone, then the colors of the table representations changes to purple (so now I call them entities).
物理模型:实际上表。小图片有数据类型和命名pk /颗约束逻辑模型:点击小按钮工具(使用神谕SQL开发人员数据分析员,我不该有一个欧文许可证和2010 visio不再逆向工程师的DB),然后是图像在屏幕上略有变化。数据类型消失，约束名称消失，然后表表示的颜色变为紫色(因此现在我将它们称为实体)。
ok. so what would my Conceptual model look like other then: exact same thing as my logical model minus the fields. I would think there is more to it than this. Reciting that its a 'semantic' representation of data sounds real nice and fancy, but doesn't make sense to someone who has not made one of these before.
好的。那么，我的概念模型会是什么样子呢?和我的逻辑模型减去字段是完全一样的。我认为还有比这更重要的。背诵它是数据的“语义”表示听起来确实不错，但对于以前没有做过这些的人来说，这是没有意义的。
#6
1
Conceptual Schema - covers entities and relationships. Should be created first. Contrary to some of the other answers; tables are not defined here. For example a 'many to many' table is not included in a conceptual data model but is defined as a 'many to many' relationship between entities.
概念模式——涵盖实体和关系。应该首先创建。与其他一些答案相反;这里没有定义表。例如，“many to many”表不包含在概念数据模型中，而是定义为实体之间的“many to many”关系。
Logical Schema - Covers tables, attributes, keys, mandatory role constraints, and referential integrity with no regards to the physical implementation. Things like indexes are not defined, attribute types should be kept logical, e.g. text instead of varchar2. Should be created based on the conceptual schema.
逻辑模式——包含表、属性、键、强制角色约束和引用完整性，与物理实现无关。像索引之类的东西没有定义，属性类型应该保持逻辑，例如文本而不是varchar2。应该基于概念模式创建。
#7
0
Most answers here are strictly related to notations and syntax of the data models at different levels of abstraction. The key difference has not been mentioned by anyone. Conceptual models surface concepts. Concepts relate to other concepts in a different way that an Entity relates to another Entity at the Logical level of abstraction. Concepts are closer to Types. Usually at Conceptual level you display Types of things (this does not mean you must use the term "type" in your naming convention) and relationships between such types. Therefore, the existence of many-to-many relationships is not the rule but rather the consequence of the relationships between type-wise elements. In Logical Models Entities represent one instance of that thing in the real world. In Conceptual models it is not expected the description of an instance of an Entity and their relationships but rather the description of the "type" or "class" of that particular Entity. Examples: - Vehicles have Wheels and Wheels are used in Vehicles. At Conceptual level this is a many-to-many relationship - A particular Vehicle (a car by instance), with one specific registration number have 5 wheels and each particular wheel, each one with a serial number is related to only that particular car. At Logical level this is a one-to-many relationship.
这里的大多数答案都与不同抽象级别的数据模型的符号和语法严格相关。关键的区别没有被任何人提及。概念模型表面的概念。概念以一种不同的方式与其他概念相关联，这种方式与实体在逻辑抽象层次上与另一个实体相关联。概念更接近类型。通常在概念级别，您会显示事物的类型(这并不意味着您必须在命名约定中使用术语“type”)以及这些类型之间的关系。因此，多对多关系的存在不是规则，而是类型元素之间关系的结果。在逻辑模型中，实体表示现实世界中该事物的一个实例。在概念模型中，它不期望描述一个实体的实例及其关系，而是期望描述该实体的“类型”或“类”。例子:车辆有*和*。在概念层面上，这是一种多对多的关系——一辆特定的车(比如一辆车)，一个特定的注册号有5个*和每个特定的*，每个带有序列号的都只与那辆特定的车有关。在逻辑层面上，这是一对多的关系。
Conceptual covers "types/classes". Logical covers "instances".
概念涵盖了“类型/类”。逻辑覆盖“实例”。
I would add another comment about databases. I agree with one of the colleagues who commented above that Conceptual and Logical models have absolutely nothing about databases. Conceptual and Logical models describe the real world from a data perspective using notations such as ER or UML. Database vendors, smartly, designed their products to follow the same philosophy used to logically model the World and them created Relational Databases, making everyone's lifes easier. You can describe your organisation's data landscape at all the levels using Conceptual and Logical model and never use a relational database.
我将添加另一个关于数据库的评论。我同意其中一个同事的观点，即概念和逻辑模型完全没有关于数据库的东西。概念和逻辑模型使用符号(如ER或UML)从数据的角度描述真实世界。数据库供应商聪明地设计了他们的产品，以遵循逻辑地为世界建模的哲学，他们创建了关系数据库，使每个人的生活都更容易。您可以使用概念和逻辑模型来描述您的组织的所有级别的数据，并且永远不要使用关系数据库。
Well I guess this is my 2 cents...
我猜这是我的2分……
#8
0
This is an old question and maybe this comes way too late, but I don't see one very important aspect necessary to answering the question. That is, the TARGET audience for the data model. The Conceptual Data Model is the model generated from business analysis, from interviews with the BUSINESS about their data. It is not so much "high level" as it is the business's understanding of their data, business rules captured in the relationships between "candidate" entities. At this point, you are capturing the things of importance to the business (Employee, Customer, Contract, Account, etc.) and the relationships between them. The final Conceptual Data Model may be somewhat abstract -- for instance, treating Individuals and Organizations entering into a contract as subtypes of a "Party", Contractors and Permanent Employees as subtypes of an Employee, even Employees and Customers subtypes of "Person" -- but it is a document that a data modeler develops from discussions with the business SMEs and presents to the business for validation.
这是一个老问题，可能来得太晚了，但我认为没有一个非常重要的方面需要回答这个问题。即数据模型的目标受众。概念数据模型是由业务分析生成的模型，从对业务的访问和对数据的访问。与其说它是“高层”，不如说它是企业对其数据的理解，即在“候选”实体之间的关系中捕获的业务规则。此时，您正在捕获对业务(雇员、客户、合同、帐户等)和它们之间的关系重要的东西。最终的概念数据模型可能有点抽象,例如,把个人和组织进入一个合同作为“党”的亚型,承包商和永久的员工作为一个员工的亚型,甚至员工和客户类型的“人”——但这是一个文档,从讨论与业务数据建模师发展中小企业业务进行验证和礼物。
The Logical Data Model is not just "more detail" -- where useful and important, a Conceptual Data Model may well have attributes included -- it is the ARCHITECTURE document, the model that is presented to the software analysts/engineers to explain and specify the data requirements. It will resolve many-to-many relationships to association tables and will define all attributes, with examples and constraints, so that code can be written against the architecture.
逻辑数据模型不仅仅是“更详细的”——在有用和重要的地方，概念数据模型很可能包含了属性——它是体系结构文档，它被呈现给软件分析师/工程师来解释和指定数据需求。它将解析到关联表的多对多关系，并定义所有属性，包括示例和约束，以便可以针对架构编写代码。
The Physical model is that Logical Model generated specifically for a particular environment, such as SQL Server or Teradata or Oracle or whatever. It will have keys, indexes, partitions, or whatever is needed to implement, based on sizing, access frequency, security constraints, etc.
物理模型是为特定环境生成的逻辑模型，如SQL Server、Teradata或Oracle等。它将具有键、索引、分区，或者根据大小、访问频率、安全约束等需要实现的任何东西。
So, if you are being asked to develop a Conceptual Data Model, you are being asked to design the solution (or part of it) from scratch, getting your information from the business. There's more to it, but I hope that answers the question.
因此，如果您被要求开发一个概念性的数据模型，您将被要求从头设计解决方案(或部分解决方案)，从业务中获取您的信息。还有更多，但我希望这能回答问题。
#9
-1
logical data model
逻辑数据模型
A logical data model describes the data in as much detail as possible, without regard to how they will be physical implemented in the database. Features of a logical data model include: · Includes all entities and relationships among them. · All attributes for each entity are specified. · The primary key for each entity is specified. · Foreign keys (keys identifying the relationship between different entities) are specified. · Normalization occurs at this level. conceptual data model
逻辑数据模型尽可能详细地描述数据，而不考虑如何在数据库中实现这些数据。逻辑数据模型的特性包括:·包含所有实体和它们之间的关系。·指定每个实体的所有属性。·指定每个实体的主键。·指定外键(标识不同实体之间关系的键)。·标准化在这个级别发生。概念数据模型
A conceptual data model identifies the highest-level relationships between the different entities. Features of conceptual data model include: · Includes the important entities and the relationships among them. · No attribute is specified. · No primary key is specified.
概念数据模型标识不同实体之间的*关系。概念数据模型的特点包括:·包含重要实体及其之间的关系。·没有指定属性。·未指定主键。