实体框架中的存储和逻辑模型

Question

有人可以为我清理一些事吗？就我的理解而言，物理模型描述了如何在特定存储介质的上下文中表示数据。逻辑模型是实体和关系的表示，独立于任何特定的数据管理技术。这两个如何与Entity Framework一起使用？我假设EF对逻辑模型起作用。在哪种情况下，物理模型适合哪里？

Answer 1

在 EDM（实体数据模型）中，第一个由商店架构定义语言（SSDL）表示 通过概念架构定义语言（CSDL）来识别它。但是，在这个游戏中还有第三个玩家：映射规范语言（MSL）。
在Entity Framework元数据中，映射层位于概念层和存储层之间，并将实体属性中的映射提供回数据存储中的表和列。
如果是ORM，则与所有三个一起使用。针对Conceptual模型的开发人员代码和EF使用MSL将其映射回存储模型。

Answer 2

在谈论关系数据库时，逻辑模型是根据关系（也称为表），值，键和完整性约束（如外键关系）表示的数据库。 物理模型是这些数据实际存储为文件或内存中的数据结构的方式。不同的关系数据库系统可以表示相同的逻辑模型，但物理模型将是系统特定的并且针对不同目的进行优化。逻辑 - 物理映射不必是1：1，在某些情况下，单个逻辑表可以物理地分割在几个文件甚至几个机器上，或者逻辑连接可以作为单个物理表存储（缓存）。这应该在逻辑层面上是透明的，但会影响性能。

SQL在逻辑层上工作，因为无论物理表示如何，您都以相同的方式查询表。一些SQL方言可能支持基于物理模型特征的优化提示。

因此，在实体框架中，所谓的存储模型实际上是逻辑数据库模型，因为EF存储模型独立于任何特定的数据库实现。物理数据库模型根本没有在EF中表示，AFAIK。

EF然后在此基础上构建另一层，EF称之为概念模型。概念模型通常更具针对性。同一数据库上的不同应用程序可能具有基于共享逻辑模型的不同概念模型。 （顺便说一下.EF中的存储模型不必代表DB的整个逻辑模型，它可以是一个子集。但是包含的子集必须将1：1映射到DB的逻辑模型）