逻辑数据模型和概念数据模型有何区别?
逻辑数据模型和概念数据模型有何区别?
在概念数据模型中,您只需要关注高层设计 - 应该存在哪些表以及它们之间的连接。在此阶段,您识别模型中的实体和它们之间的关系。
逻辑模型是在概念建模之后进行的,这时您明确定义了每个表中的列。编写逻辑模型时,如果它影响到设计(例如,如果没有触发器,您可能想删除某些冗余列),您也可以考虑要设计的实际数据库系统。
还有物理模型,它详细说明了逻辑模型并为每个列分配了其类型/长度等信息。
这里有一张很好的表格和图片,描述了这三个级别。
|----------------------|------------|---------|----------|
| 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 |
|----------------------|------------|---------|----------|
在这个表格中,您可以看到每个模型之间的差异:
有关更多信息和一些数据模型示例,请参见http://www.1keydata.com/datawarehousing/data-modeling-levels.html。
这些术语不幸地被赋予了几个可能的定义。例如,根据 ANSI-SPARC 的“三模式”模型,概念模式或概念模型由数据库中的对象集(表、视图等)组成,与外部模式相对应,外部模式是用户所看到的对象。
在数据管理专业,尤其是数据建模/架构师之间,概念模型一词经常用于表示语义模型,而逻辑模型一词则用于表示初步或虚拟数据库设计。这可能是您在工作场所最有可能遇到的用法。
然而,在学术用途和描述 DBMS 架构时,逻辑层意味着数据库对象(表、视图、表、键、约束等),与物理层(文件、索引、存储)区分开来。更进一步混淆问题的是,在工作场所,物理模型一词通常用于表示在实际数据库中实现或计划实现的设计。这可能包括“物理”和“逻辑”层结构(例如表和索引)。
当您遇到任何这些术语时,除非上下文很明显,否则确实需要寻求澄清。
要讨论这些差异,请查看 Simsion 和 Witt 的《数据建模精要》。
逻辑数据库模型
逻辑数据库建模是为了编译业务需求并将这些需求表示为一个模型。它主要与收集业务需求相关,而不是数据库设计。需要收集的信息涉及组织单元、业务实体和业务流程。
一旦收集到信息,就会制作报告和图表,包括以下内容:
ERD - 实体关系图显示数据不同类别之间的关系,并显示开发数据库所需的不同数据类别。 业务流程图 - 它显示公司内个人的活动。它显示基于哪些应用程序界面数据在组织内部移动。 用户反馈文档。
逻辑数据库模型基本上确定了是否已经收集到了业务的所有需求。它由开发人员、管理层和最终用户评审,以查看在开始物理建模之前是否需要收集更多信息。
物理数据库模型
物理数据库建模涉及根据逻辑数据库建模期间收集的需求设计实际数据库。收集的所有信息都会转换成关系模型和业务模型。在物理建模过程中,对象在架构级别定义。架构被认为是数据库中彼此相关的对象组。
根据逻辑建模提供的信息制作表和列。定义主键、唯一键和外键以提供约束。定义索引和快照。在创建表后,可以对数据进行汇总,并为用户提供另一种视角。
物理数据库建模取决于组织中已经使用的软件。它是特定于软件的。物理建模包括:
服务器模型图 - 它包括数据库内的表和列以及不同的关系。 数据库设计文档。 用户反馈文档。
摘要:
1.逻辑数据库建模主要是为了收集业务需求的信息,而不涉及数据库设计;而物理数据库建模主要是实际的数据库设计。 2.逻辑数据库建模不包括索引和约束;应用程序的逻辑数据库模型可以在各种数据库软件和实现之间使用;而物理数据库建模是特定于软件和硬件的,并具有索引和约束。 3.逻辑数据库建模包括ERD、业务流程图和用户反馈文档;而物理数据库建模包括服务器模型图、数据库设计文档和用户反馈文档。
阅读更多:逻辑数据库模型和物理数据库模型的区别 | Difference Between | 逻辑数据库模型与物理数据库模型的区别http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg
概念模式 - 包括实体和关系。应该首先创建。与其他答案相反,表在此处未定义。例如,“多对多”表不包括在概念数据模型中,但被定义为实体之间的“多对多”关系。
逻辑模式 - 包括表、属性、键、强制角色约束和引用完整性,不考虑物理实现。诸如索引之类的内容未定义,属性类型应保持逻辑,例如使用text而不是varchar2。应基于概念模式创建。
物理模型:实际上是表格。小图片中包含数据类型和命名的主外键约束。
逻辑模型:在我的工具(使用Oracle SQL Developer Data Modeler,我没有Erwin许可证,而2010年的Visio不再从数据库中反向工程)中点击小按钮,然后屏幕上的图像会略微改变。数据类型消失了,约束的名称也消失了,然后表格表示的颜色变为紫色(现在我称它们为实体)。
好的。那么我的概念模型看起来会是什么呢?除了字段外,它与我的逻辑模型完全相同。我认为这不仅仅是这样。重复说它是数据的“语义”表示听起来很漂亮、很高大上,但对于没有做过这种事情的人来说并不合理。
这里的大多数答案都严格涉及不同抽象级别的数据模型的符号和语法。关键差异没有被任何人提到。概念模型表面上是概念。概念与实体在逻辑抽象层面上相互关联的方式不同。概念更接近于类型。通常在概念层面上,您会显示事物的类型(这并不意味着您必须在命名约定中使用“类型”一词)以及这些类型之间的关系。因此,多对多关系的存在并不是规则,而是类型元素之间关系的结果。在逻辑模型中,实体代表现实世界中该事物的一个实例。在概念模型中,不需要描述实体实例及其关系,而是需要描述该特定实体的“类型”或“类”。 例如: -车辆有轮子,轮子用于车辆。在概念层面上,这是一种多对多的关系 -特定车辆(例如汽车),具有一个特定的注册号码,有5个轮子,每个特定的轮子,每个轮子都有一个序列号,与仅与该特定汽车相关联。在逻辑层面上,这是一种一对多的关系。
概念涵盖“类型/类”。逻辑涵盖“实例”。
我想再添加一条关于数据库的评论。我同意前面有位同事所说的,概念模型和逻辑模型与数据库完全无关。概念模型和逻辑模型使用诸如ER或UML之类的符号,从数据角度描述现实世界。数据库供应商巧妙地设计了他们的产品,遵循了用于逻辑建模世界的相同哲学,并创建了关系数据库,使每个人的生活更加轻松。您可以使用概念模型和逻辑模型在所有层面上描述组织的数据景观,而不必使用关系数据库。好吧,我想这就是我的两分钱意见...