逻辑数据模型和概念数据模型有什么区别?

62

逻辑数据模型和概念数据模型有何区别?


我认为引用1keydata并不合理,因为很多答案都这样做了。概念模型(如实体-关系模型)确实包括属性和主键,而1keydata上的表格是完全错误的。 - Xavier Z.
10个回答

74

在概念数据模型中,您只需要关注高层设计 - 应该存在哪些表以及它们之间的连接。在此阶段,您识别模型中的实体和它们之间的关系。

逻辑模型是在概念建模之后进行的,这时您明确定义了每个表中的列。编写逻辑模型时,如果它影响到设计(例如,如果没有触发器,您可能想删除某些冗余列),您也可以考虑要设计的实际数据库系统。

还有物理模型,它详细说明了逻辑模型并为每个列分配了其类型/长度等信息。

这里有一张很好的表格和图片,描述了这三个级别。

|----------------------|------------|---------|----------|
| Feature              | Conceptual | Logical | Physical | 
|----------------------|------------|---------|----------|
| Entity Names         | X          | X       |          |
| Entity Relationships | X          | X       |          |
| Attributes           |            | X       |          |
| Primary Keys         |            | X       | X        |
| Foreign Keys         |            | X       | X        |
| Table Names          |            |         | X        |
| Column Names         |            |         | X        |
| Column Data Types    |            |         | X        |
|----------------------|------------|---------|----------|

来自https://www.1keydata.com/datawarehousing/data-modeling-levels.html的数据建模层次


9
只有当你确定要在关系型数据库上构建系统时,这个答案才是正确的。概念数据建模也非常有用,如果你使用的是非关系型数据库(例如图形数据库等NoSQL),或者根本没有使用数据库!(例如你自己编写代码,或者在模拟领域或业务时确定正确的类和对象,或者不使用任何代码) - Johannes Ernst
@veljkoz:我曾经学过,概念层次与逻辑层次是相同的。这里有参考资料,请帮我解决疑惑。http://jcsites.juniata.edu/faculty/rhodes/dbms/dbarch.htm - Sudhir
1
@Sudhir 他们都在讨论相同层次的设计,但细节不同,所以是的,你可能可以用相同的名称来称呼它们(尽管我个人更倾向于选择“逻辑”而不是“概念”作为一个总称)。这是理论,所以你可能会发现其他变化。 - veljkoz
1
这个答案应该澄清一个概念数据模型定义了哪些实体存在以及它们之间的关系,而不是哪些表格。例如,“多对多”表可能存在于逻辑或物理数据模型中,但在概念数据模型中只显示为一种关系,而不是表格。 - Chris
这个图表确实不准确。像ER这样的概念模型可以包括属性和主键。 - Xavier Z.
显示剩余2条评论

29

2
@EmilianoSangoi,在概念模型中添加属性也是正确的吗? - danilo
实际上,“主键”应该包含在概念层级中,因为这篇论文已经提出了E-R模型并讨论了它。 - Xavier Z.
实际上,“主键”应该包含在概念层级中,因为该论文已经提出了E-R模型并讨论了它。 - undefined

17

这些术语不幸地被赋予了几个可能的定义。例如,根据 ANSI-SPARC 的“三模式”模型,概念模式或概念模型由数据库中的对象集(表、视图等)组成,与外部模式相对应,外部模式是用户所看到的对象。

在数据管理专业,尤其是数据建模/架构师之间,概念模型一词经常用于表示语义模型,而逻辑模型一词则用于表示初步或虚拟数据库设计。这可能是您在工作场所最有可能遇到的用法。

然而,在学术用途和描述 DBMS 架构时,逻辑层意味着数据库对象(表、视图、表、键、约束等),与物理层(文件、索引、存储)区分开来。更进一步混淆问题的是,在工作场所,物理模型一词通常用于表示在实际数据库中实现或计划实现的设计。这可能包括“物理”和“逻辑”层结构(例如表和索引)。

当您遇到任何这些术语时,除非上下文很明显,否则确实需要寻求澄清。

要讨论这些差异,请查看 Simsion 和 Witt 的《数据建模精要》。


嗨 @nvogel,非常感谢你的回答,我对你提到的“学术用途”很感兴趣。你介意给我一些建议关于这个用途的关键词或参考资料吗? - Xavier Z.

4

逻辑数据库模型

逻辑数据库建模是为了编译业务需求并将这些需求表示为一个模型。它主要与收集业务需求相关,而不是数据库设计。需要收集的信息涉及组织单元、业务实体和业务流程。

一旦收集到信息,就会制作报告和图表,包括以下内容:

ERD - 实体关系图显示数据不同类别之间的关系,并显示开发数据库所需的不同数据类别。 业务流程图 - 它显示公司内个人的活动。它显示基于哪些应用程序界面数据在组织内部移动。 用户反馈文档。

逻辑数据库模型基本上确定了是否已经收集到了业务的所有需求。它由开发人员、管理层和最终用户评审,以查看在开始物理建模之前是否需要收集更多信息。

物理数据库模型

物理数据库建模涉及根据逻辑数据库建模期间收集的需求设计实际数据库。收集的所有信息都会转换成关系模型和业务模型。在物理建模过程中,对象在架构级别定义。架构被认为是数据库中彼此相关的对象组。

根据逻辑建模提供的信息制作表和列。定义主键、唯一键和外键以提供约束。定义索引和快照。在创建表后,可以对数据进行汇总,并为用户提供另一种视角。

物理数据库建模取决于组织中已经使用的软件。它是特定于软件的。物理建模包括:

服务器模型图 - 它包括数据库内的表和列以及不同的关系。 数据库设计文档。 用户反馈文档。

摘要:

1.逻辑数据库建模主要是为了收集业务需求的信息,而不涉及数据库设计;而物理数据库建模主要是实际的数据库设计。 2.逻辑数据库建模不包括索引和约束;应用程序的逻辑数据库模型可以在各种数据库软件和实现之间使用;而物理数据库建模是特定于软件和硬件的,并具有索引和约束。 3.逻辑数据库建模包括ERD、业务流程图和用户反馈文档;而物理数据库建模包括服务器模型图、数据库设计文档和用户反馈文档。

阅读更多:逻辑数据库模型和物理数据库模型的区别 | Difference Between | 逻辑数据库模型与物理数据库模型的区别http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg


2

概念模式 - 包括实体和关系。应该首先创建。与其他答案相反,表在此处未定义。例如,“多对多”表不包括在概念数据模型中,但被定义为实体之间的“多对多”关系。

逻辑模式 - 包括表、属性、键、强制角色约束和引用完整性,不考虑物理实现。诸如索引之类的内容未定义,属性类型应保持逻辑,例如使用text而不是varchar2。应基于概念模式创建。


1
我需要制作逻辑模型和概念模型。这里的所有解释都非常模糊。上面发布的链接只显示概念模型是没有字段的逻辑模型的区别。好吧,我不提及数据库的名称。它似乎完全是多余的。
我真的不知道“语义”是什么意思。有人能解释一下,如果使用“英语”,我会做些什么不同,并可能发布比显示具有字段和没有字段的图片更好的示例的链接。流行语都很好,但是它们如此模糊,以至于在实际实施中没有用处。
除了拿出我的逻辑模型(基本上是从数据库反向工程出来的物理模型),在所述工具中单击按钮,图像看起来略有不同,然后去掉数据类型,我还需要做些什么?
从我实际看到的情况来看(而没有流行语)。

物理模型:实际上是表格。小图片中包含数据类型和命名的主外键约束。

逻辑模型:在我的工具(使用Oracle SQL Developer Data Modeler,我没有Erwin许可证,而2010年的Visio不再从数据库中反向工程)中点击小按钮,然后屏幕上的图像会略微改变。数据类型消失了,约束的名称也消失了,然后表格表示的颜色变为紫色(现在我称它们为实体)。

好的。那么我的概念模型看起来会是什么呢?除了字段外,它与我的逻辑模型完全相同。我认为这不仅仅是这样。重复说它是数据的“语义”表示听起来很漂亮、很高大上,但对于没有做过这种事情的人来说并不合理。


我同意解释比较模糊。三层存在的主要原因是为了a)清晰度和b)它们有助于演变数据库设计。数据库模型往往会变得相当大。当您开始创建数据库设计时,起初您更多地只想确定主要实体并从那里开始。在这个级别上,实体名称和实体之间的关系是您最关心的问题。随后(在其他类型的模型中),您根据需要添加详细信息(约束、关系、索引等)。 - Robotronx

1
这是一个旧问题,也许来得太晚了,但我没有看到回答这个问题所必需的一个非常重要的方面,那就是数据模型的目标受众。概念数据模型是从业务分析中生成的模型,通过与业务人员的访谈来了解他们的数据。它不仅仅是“高层次”的,更是业务对其数据的理解,捕捉候选实体之间关系中的业务规则。在此时,您正在捕捉业务重要的事物(如员工、客户、合同、账户等)以及它们之间的关系。
最终的概念数据模型可能有些抽象——例如,将进入合同的个人和组织视为“Party”的子类型,将承包商和永久雇员视为员工的子类型,甚至将员工和客户视为“Person”的子类型——但它是一份数据建模师从与业务SMEs的讨论中制定并提交给业务进行验证的文件。
逻辑数据模型不仅仅是“更详细”——在必要和重要的情况下,概念数据模型可能会包括属性——它是架构文档,是向软件分析/工程师展示数据需求的模型。它将多对多关系解析为关联表,并定义所有属性,包括示例和约束条件,以便可以针对架构编写代码。
物理模型是为特定环境生成的逻辑模型,例如SQL Server、Teradata或Oracle等。它将具有键、索引、分区或其他根据大小、访问频率、安全约束等实现所需的内容。因此,如果要求您开发概念数据模型,则要求您从业务中获取信息,从头开始设计解决方案(或其中一部分)。还有更多内容,但希望这回答了问题。

关于“语义”一词:它只是指人们谈论事物的方式。当您构建报告时,可能不会使用与内部相同的语言。例如,您在内部可能有一个“handset.device”,但在报告中是“model”。对于工程师来说,“高级装配”是营销专家的“产品”。语义只是特定上下文中使用的语言。可以通过视图在数据仓库模型之上构建语义模型,以向业务翻译数据意义,让他们理解。 - alann9

1
首先,数据模型是一种抽象工具,而数据库模型(或方案/图表)是建模结果。
概念数据模型是与DBMS无关的,涵盖功能/域设计领域。最著名的概念数据模型是“实体关系”。通常,您可以重用概念方案来生成不仅关系的不同逻辑方案。
逻辑数据模型旨在由某些DBMS实现,并大多对应于 ANSI / SPARC架构(1975年提出)的概念级别;这一点导致术语上的一些冲突。 Zachman Framework尝试在十年后引入概念、逻辑和物理模型来解决这种冲突。
有许多逻辑数据模型,其中最著名的是关系模型。
因此,概念数据模型的主要区别在于聚焦于域和DBMS独立性,而逻辑数据模型则是您计划使用的具体DBMS的最抽象级别。请注意,当代DBMS同时支持几个逻辑模型。
你还可以查看我的书这篇文章以获取更多详细信息。

0

这里的大多数答案都严格涉及不同抽象级别的数据模型的符号和语法。关键差异没有被任何人提到。概念模型表面上是概念。概念与实体在逻辑抽象层面上相互关联的方式不同。概念更接近于类型。通常在概念层面上,您会显示事物的类型(这并不意味着您必须在命名约定中使用“类型”一词)以及这些类型之间的关系。因此,多对多关系的存在并不是规则,而是类型元素之间关系的结果。在逻辑模型中,实体代表现实世界中该事物的一个实例。在概念模型中,不需要描述实体实例及其关系,而是需要描述该特定实体的“类型”或“类”。 例如: -车辆有轮子,轮子用于车辆。在概念层面上,这是一种多对多的关系 -特定车辆(例如汽车),具有一个特定的注册号码,有5个轮子,每个特定的轮子,每个轮子都有一个序列号,与仅与该特定汽车相关联。在逻辑层面上,这是一种一对多的关系。

概念涵盖“类型/类”。逻辑涵盖“实例”。

我想再添加一条关于数据库的评论。我同意前面有位同事所说的,概念模型和逻辑模型与数据库完全无关。概念模型和逻辑模型使用诸如ER或UML之类的符号,从数据角度描述现实世界。数据库供应商巧妙地设计了他们的产品,遵循了用于逻辑建模世界的相同哲学,并创建了关系数据库,使每个人的生活更加轻松。您可以使用概念模型和逻辑模型在所有层面上描述组织的数据景观,而不必使用关系数据库。

好吧,我想这就是我的两分钱意见...


-1
逻辑数据模型
逻辑数据模型尽可能详细地描述数据,而不考虑它们在数据库中的物理实现方式。逻辑数据模型的特征包括: · 包括所有实体及其之间的关系。 · 指定每个实体的所有属性。 · 指定每个实体的主键。 · 指定外键(用于标识不同实体之间关系的键)。 · 在此级别进行规范化。
概念数据模型
概念数据模型识别不同实体之间的最高级别关系。概念数据模型的特征包括: · 包括重要实体及其之间的关系。 · 不指定任何属性。 · 不指定任何主键。

2
你从哪里复制粘贴了这个答案? - james.garriss

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接