逻辑数据模型和概念数据模型有什么区别？
逻辑数据模型和概念数据模型有什么区别？
在概念数据模型中，您只关心高层devise – 应该存在哪些表以及它们之间的关系。 在这个阶段，您可以识别模型中的实体以及它们之间的关系。
当您明确定义每个表中的列时，逻辑模型在概念build模之后。 在编写逻辑模型的时候，你也可以考虑你正在devise的实际数据库系统，但是只有当它影响到devise时（例如，如果没有触发器，你可能要删除一些冗余列等）
还有物理模型，详细阐述了逻辑模型，并为每一列指定了types/长度等。
这是一个很好的描述三个层次的图片。
在这个表格中你可以看到每个模型之间的区别： 
有关更多信息和一些数据模型示例，请参阅http://www.1keydata.com/datawarehousing/data-modeling-levels.html 。
不幸的是，这些术语过载了几个可能的定义。 根据ANSI-SPARC“三模式”模型，概念模式或概念模型由数据库中的对象集合（表格，视图等）组成，而外部模式则是用户看到的对象。
在数据pipe理专业，尤其是数据build模师/build筑师之间，术语“概念模型”常常用来表示语义模型，而术语“逻辑模型”则用来表示初步的或虚拟的数据库devise 。 这可能是您在工作场所最有可能遇到的用法。
然而，在学术用法和描述DBMS体系结构时，逻辑级别是指与物理级别（文件，索引，存储）不同的数据库对象（表，视图，表，键，约束等）。 为了进一步混淆事物，在工作场所，术语“物理模型”常常用来表示在实际数据库中实施或计划实施的devise。 这可能包括“物理”和“逻辑”级别的结构（例如表和索引）。
当你遇到任何这些条款时，你真的需要澄清什么是被描述的，除非上下文显而易见。
有关这些差异的讨论，请参阅Simsion和Witt的Data Modeling Essentials。
逻辑数据库模型
逻辑数据库build模是编译业务需求和代表需求的模型。 它主要与业务需求的收集而不是数据库devise有关。 需要收集的信息是关于组织单位，业务实体和业务stream程。
信息编译完成后，就会生成报告和图表，包括：
ERD-Entity关系图显示了不同类别数据之间的关系，并显示了开发数据库所需的不同类别的数据。 业务stream程图 – 它显示了公司内个人的活动。 它显示了数据如何根据可以devise哪个应用程序接口在组织内移动。 用户反馈文档。
逻辑数据库模型基本确定是否收集了业务的所有需求。 由开发人员，pipe理人员以及最终用户审查是否需要在物理build模开始之前收集更多的信息。
物理数据库模型物理数据库build模基于逻辑数据库build模期间收集的要求来处理devise实际数据库。 所有收集到的信息都被转换成关系模型和业务模型。 在物理build模过程中，对象被定义在一个称为模式级别的级别上。 模式被认为是在数据库中相互关联的一组对象。 表和列是根据逻辑build模期间提供的信息制作的。 定义主键，唯一键和外键是为了提供约束。 索引和快照被定义。 数据可以被总结，并且一旦创build了表格，就为用户提供了一个替代的视angular。
物理数据库build模取决于组织中已经使用的软件。 它是软件特定的。 物理build模包括：
服务器模型图 – 它包括数据库中存在的表和列以及不同的关系。 数据库devise文档。 用户的反馈文档。
概要：
1，逻辑数据库build模主要是收集业务需求信息，不涉及数据库devise; 而数据库的实际devise主要需要物理数据库build模。 2.逻辑数据库build模不包括索引和约束; 应用程序的逻辑数据库模型可用于各种数据库软件和实现; 而物理数据库build模是软件和硬件特定的并且具有索引和约束。 3.逻辑数据库build模包括; ERD，业务stream程图和用户反馈文档; 而物理数据库build模包括; 服务器模型图，数据库devise文档和用户反馈文档。
阅读更多：逻辑和物理数据库模型之间的区别| |之间的区别 逻辑与物理数据库模型http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg
我需要产生一个逻辑模型和一个概念模型。 这里所有的解释都非常模糊。 上面贴出的链接只是显示了一个概念模型是一个没有字段的逻辑模型。 好吧，我没有提到数据库的名称。 这似乎是完全多余的。
我真的不知道“语义”是什么意思。 有人可以解释我会做什么不同的使用“英语”，并可能张贴链接到更好的例子，而不是一张图片，显示一个图片，有一个字段，一个没有。 stream行语总是很好，但是它太模糊，实际上没有用处。
除了采用我的逻辑模型（这基本上是我的物理模型颠倒了数据库，单击工具中的一个button，图像看起来有点不同，然后取下数据types）之外，我还能做其他任何事情吗？
从我几乎可以看到（也没有stream行语）
物理模型：实际上是表格。 小图片有数据types，并命名为pk / fk约束逻辑模型：点击我的工具（使用ORACLE SQL开发人员数据build模器，我没有erwin许可证和2010年visio不再扭转工程师的数据库）小button，然后屏幕上的图像稍微改变。 数据types消失了，约束的名字消失了，然后表格的颜色变成了紫色（所以现在我称之为实体）。
好。 那么我的概念模型会是什么样子呢：与我的逻辑模型相同的东西减去字段。 我认为还有比这更多的东西。 背诵数据的“语义”表示听起来真的很好看，但对于以前没有做过这些的人来说是没有意义的。
这里的大多数答案严格地与不同抽象层次的数据模型的符号和语法有关。 关键的区别并没有被任何人提及。 概念模型表面的概念。 概念以不同的方式与其他概念相联系，即一个实体在逻辑抽象层与另一个实体相关联。 概念更接近types。 通常在概念级别，你显示事物的types（这并不意味着你必须在你的命名约定中使用术语“types”）以及这些types之间的关系。 因此，多对多关系的存在不是规则，而是types元素之间关系的结果。 在逻辑模型中实体代表了现实世界中这个事物的一个实例。 在概念模型中，不期望描述实体的实例及其关系，而是描述该特定实体的“types”或“类”。 例子： – 车辆在车辆中使用车轮和车轮。 在概念层面上，这是一个多对多的关系 – 一个特定的车辆（例如一辆汽车），一个特定的注册号码有5个车轮，每个特定的车轮，每个车轮都与一个特定的车辆相关。 在逻辑层面上，这是一个一对多的关系。
概念涵盖“types/类”。 逻辑涵盖“实例”。
我会添加关于数据库的另一个评论。 我同意上面提到的同事之一，概念和逻辑模型对数据库一无所知。 概念模型和逻辑模型使用ER或UML等符号从数据angular度描述现实世界。 数据库供应商巧妙地devise了他们的产品，遵循用于逻辑模拟世界的相同理念，并创build了关系数据库，使每个人的生活变得更加简单。 您可以使用概念和逻辑模型在所有级别描述组织的数据格局，而不使用关系数据库。
那么我猜这是我的2美分…
概念模式 – 涵盖实体和关系。 应该先创build。 与其他一些答案相反; 表格在这里没有定义。 例如，“多对多”表不包含在概念数据模型中，而是定义为实体之间的“多对多”关系。
逻辑架构 – 涵盖表，属性，密钥，强制angular色约束和引用完整性，而不考虑物理实现。 像索引这样的东西没有定义，属性types应该保持逻辑，例如文本而不是varchar2。 应该基于概念模式来创build。
逻辑数据模型
逻辑数据模型尽可能详细地描述数据，而不考虑数据库中物理实现的方式。 逻辑数据模型的function包括：·包含它们之间的所有实体和关系。 ·指定每个实体的所有属性。 ·指定每个实体的主键。 ·指定了外键（标识不同实体之间的关系的键）。 正常化发生在这个级别。 概念数据模型
概念数据模型确定不同实体之间的最高级别关系。 概念数据模型的特点包括：·包括重要的实体及其间的关系。 ·没有指定属性。 没有指定主键。
