在此表中,您可以看到每个模型之间的差异:
看到 http://www.1keydata.com/datawarehousing/data-modeling-levels.html 有关更多信息和一些数据模型示例。
这里的大多数答案与不同抽象级别的数据模型的符号和语法严格相关。任何人都没有提到关键的区别。概念模型表面概念。概念以不同的方式与其他概念相关,实体在逻辑抽象级别与另一个实体相关。概念更接近于类型。通常在概念级别显示事物类型(这并不意味着您必须在命名约定中使用术语“类型”)以及这些类型之间的关系。因此,多对多关系的存在不是规则,而是类型元素之间关系的结果。在逻辑模型中,实体代表现实世界中该事物的一个实例。在概念模型中,不期望描述实体的实例及其关系,而是描述该特定实体的“类型”或“类”。 例子: - 车辆使用车轮和车轮。在概念层面,这是一个多对多的关系 - 特定车辆(例如汽车),具有一个特定的登记号码具有5个车轮和每个特定车轮,每个车轮具有序列号仅与该特定车辆相关。在逻辑级别,这是一对多的关系。
概念涵盖“类型/类”。逻辑涵盖“实例”。
我想补充一点关于数据库的评论。我同意上面评论过的一位同事,概念和逻辑模型对数据库一无所知。概念和逻辑模型使用ER或UML等符号从数据角度描述现实世界。聪明地,数据库供应商设计他们的产品遵循用于逻辑模拟世界的相同理念,他们创建了关系数据库,使每个人的生活更轻松。您可以使用概念和逻辑模型在所有级别描述组织的数据格局,而不使用关系数据库。
嗯,我想这是我的2美分......
遗憾的是,这些术语超载了几种可能的定义。例如,根据ANSI-SPARC“三模式”模型,概念模式或概念模型由数据库中的对象集(表,视图等)组成,而外部模式是用户看到的对象。
在数据管理专业,特别是数据建模师/建筑师之间,术语概念模型经常被用来表示a 语义 模型,而术语逻辑模型用于表示初步或虚拟数据库 设计 。这可能是您最有可能在工作场所遇到的用法。
然而,在学术用途和描述DBMS体系结构时,逻辑级别表示数据库对象(表,视图,表,键,约束等),与物理级别(文件,索引,存储)不同。为了进一步混淆事物,在工作场所中,物理模型这一术语通常用于表示在实际数据库中实施或计划实施的设计。这可能包括“物理”和“逻辑”级别构造(例如表和索引)。
当您遇到任何这些术语时,您确实需要寻求对所描述内容的澄清,除非上下文显而易见。
有关这些差异的讨论,请查看Simsion和Witt的Data Modeling Essentials。
的 概念图式 强> - 涵盖实体和关系。应该先创建。与其他一些答案相反;这里没有定义表格。例如,“多对多”表不包含在概念数据模型中,而是被定义为实体之间的“多对多”关系。
的 逻辑架构 强> - 涵盖表,属性,密钥,强制角色约束和参照完整性,而不考虑物理实现。像索引这样的东西没有定义,属性类型应该保持逻辑,例如文本而不是varchar2。应该基于概念架构创建。
我需要生成逻辑模型和概念模型。这里的所有解释都非常模糊。上面发布的链接只显示了概念模型是没有字段的逻辑模型的区别。好的,我没有提到数据库的名称。这看起来完全是多余的。
我真的不知道'语义'是什么意思。有人可以使用“英语”来解释我会做些什么,并且可能会发布一个链接到更好的例子,而不是一张图片显示一张图片有字段,一张图片没有字段。流行语一切都很好,但它的含糊不清对实际实施起来没有用。
除了采用我的逻辑模型(基本上是我的物理模型,在数据库中反向设计,点击所述工具中的按钮,图像看起来有点不同,然后取消数据类型),我该怎么办?
从我几乎可以看到(并没有流行语)
物理模型:实际上是表格。小图片中包含数据类型,并命名为pk / fk约束 逻辑模型:单击我的工具上的小按钮(使用Oracles SQL Developer Data Modeller,我没有erwin许可证,而且2010 visio不再将工程师从数据库中撤出),然后屏幕上的图像会略有变化。数据类型消失了,约束的名称消失了,然后表格表示的颜色变为紫色(所以现在我将它们称为实体)。
好。那么我的概念模型会是什么样子呢:与我的逻辑模型完全相同的东西减去字段。我认为它还有更多。背诵其数据的“语义”表示听起来真的很好看,但对于之前没有制作过这些数据的人来说没有意义。
逻辑数据模型
逻辑数据模型尽可能详细地描述数据,而不考虑它们将如何在数据库中物理实现。逻辑数据模型的特征包括: 包括它们之间的所有实体和关系。 指定每个实体的所有属性。 the指定了每个实体的主键。 specified指定外键(标识不同实体之间关系的键)。 正常化发生在此级别。 概念数据模型
概念数据模型识别不同实体之间的最高级别关系。概念数据模型的特征包括: 包括重要实体及其间的关系。 未指定任何属性。 未指定主键。
这是一个老问题,也许这太晚了,但我没有看到回答这个问题所必需的一个非常重要的方面。 也就是说,TARGET的数据模型受众。概念数据模型是通过业务分析生成的模型,通过对业务有关其数据的访谈。它并不是“高级别”,因为它是企业对其数据的理解,是“候选”实体之间关系中捕获的业务规则。此时,您正在捕捉对业务(员工,客户,合同,帐户等)及其之间关系的重要事项。 最终的概念数据模型可能有些抽象 - 例如,将签订合同的个人和组织视为“党”,承包商和永久雇员的子类型,作为员工的子类型,甚至是“人员”的员工和客户子类型 - - 但这是一份文档,数据建模者通过与业务中小企业的讨论开发出来并向企业提交验证。
逻辑数据模型不仅仅是“更详细” - 有用且重要的是,概念数据模型可能包含属性 - 它是ARCHITECTURE文档,提供给软件分析师/工程师解释和指定的模型数据要求。它将解析与关联表的多对多关系,并将使用示例和约束定义所有属性,以便可以针对体系结构编写代码。
物理模型是专门为特定环境生成的逻辑模型,例如SQL Server或Teradata或Oracle等等。它将具有密钥,索引,分区或实现所需的任何内容,具体取决于大小,访问频率,安全性约束等。
因此,如果要求您开发概念数据模型,则会要求您从头开始设计解决方案(或部分解决方案),从业务中获取您的信息。还有更多,但我希望能回答这个问题。
在概念数据模型中,您只关心高级设计 - 应该存在哪些表以及它们之间的连接。在此阶段,您可以识别模型中的实体以及它们之间的关系。
当您明确定义每个表中的列时,逻辑模型位于概念建模之后。在编写逻辑模型时,您可能还会考虑您正在设计的实际数据库系统,但前提是它会影响设计(即,如果没有触发器,您可能需要删除某些冗余列等)
还有物理模型详细说明了逻辑模型,并为每个列分配了它的类型/长度等。
这里 是描述三个级别中每个级别的好图片。
逻辑数据库模型
编译业务需求并将需求表示为模型需要逻辑数据库建模。它主要与收集业务需求而不是数据库设计有关。需要收集的信息涉及组织单位,业务实体和业务流程。
编译完信息后,会生成报告和图表,包括:
ERD CEntity关系图显示了不同类别数据之间的关系,并显示了开发数据库所需的不同类别的数据。 业务流程图 显示公司内部个人的活动。它根据可以设计的应用程序界面显示数据在组织内的移动方式。 用户的反馈文档。
逻辑数据库模型基本上确定是否已收集业务的所有要求。开发人员,管理人员以及最终用户将对其进行审核,以确定在物理建模开始之前是否需要收集更多信息。
物理数据库模型 物理数据库建模涉及根据逻辑数据库建模期间收集的需求设计实际数据库。收集的所有信息都转换为关系模型和业务模型。在物理建模期间,对象在称为模式级别的级别定义。模式被认为是一组在数据库中彼此相关的对象。 表和列根据逻辑建模期间提供的信息进行。定义主键,唯一键和外键以提供约束。索引和快照已定义。可以汇总数据,并在创建表后为用户提供备用透视图。
物理数据库建模取决于组织中已使用的软件。它是特定于软件的。物理建模包括:
服务器模型图 CIt包括数据库中存在的表和列以及不同的关系。 数据库设计文档。 用户的反馈文档。
摘要:
1.逻辑数据库建模主要用于收集有关业务需求的信息,不涉及设计数据库;而物理数据库建模主要是实际设计数据库所必需的。 2.逻辑数据库建模不包括索引和约束;应用程序的逻辑数据库模型可用于各种数据库软件和实现;而物理数据库建模是特定于软件和硬件的,并具有索引和约束。 3.逻辑数据库建模包括; ERD,业务流程图和用户反馈文档;而物理数据库建模包括;服务器模型图,数据库设计文档和用户反馈文档。
阅读更多:逻辑和物理数据库模型之间的差异| |之间的区别逻辑与物理数据库模型 http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg
首先,一个 的 数据 强> model是一个抽象工具和一个 的 数据库 强> model(或scheme / diagramm)是一个建模结果。
概念数据模型独立于DBMS,涵盖功能/域设计领域。最着名的概念数据模型是“实体 - 关系”。通常,您可以重用概念方案来生成不仅是关系的不同逻辑方案。
逻辑数据模型旨在由某些DBMS实现,并且主要对应于概念级别 ANSI / SPARC架构 (1975年提出);这一点给出了术语的一些碰撞。 扎克曼框架 十年后,他试图解决这种碰撞,引入概念,逻辑和物理模型。
有许多逻辑数据模型,最常见的是关系模型。
因此,概念数据模型的主要区别在于关注域和DBMS独立性,而逻辑数据模型是您计划使用的最具抽象性的DBMS级别。请注意,当代DBMS同时支持多个逻辑模型。
你也可以看看 我的书 并 这篇文章 更多细节。