实体框架中的存储和逻辑模型
有人可以帮我解决一些问题吗？据我的理解，物理模型描述了数据在特定存储介质的上下文中如何表示。逻辑模型是实体和关系的表示，独立于任何特定的数据管理技术。这两者如何与实体框架配合使用？我假设 EF 针对逻辑模型工作。在这种情况下，物理模型适合在哪里？
Could someone clear something up for me? As far as my understanding goes, the physical model describes how the data is represented in the context of a specific storage medium. The logical model is a representation in terms of entities and relationships, independent of any particular data management technology. How do these two work with Entity Framework? I assume the EF works against a logical model. In which case, where does the physical model fit in?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在EDM（实体数据模型）中，第一个由存储架构定义语言（SSDL）表示
第二个是概念模式定义语言(CSDL)。但是，这个游戏中还有第三个参与者：映射规范语言（MSL）。
在实体框架元数据中，映射层位于概念层和存储层之间，提供从实体属性返回到数据存储中的表和列的映射。
Ef 作为一个 ORM，适用于所有这三个。开发人员根据概念模型进行编码，EF 使用 MSL 将其映射回存储模型。
In the EDM (Entity Data Model) the first one is represented by Store Schema Definition Language (SSDL)
and the secound one by Conceptual Schema Definition Language (CSDL). But, there is also a third player in this game: Mapping Specification Language (MSL).
In the Entity Framework metadata, the mapping layer sits between the conceptual and store layers and provides the map from the entity properties back to the tables and columns in the data store.
Ef, as an ORM, works with all three. Developer codes against the Conceptual model and EF maps it back to the storage model using the MSL.
当谈论关系数据库时，逻辑模型是用关系（又名表）、值、键和完整性约束（如外键关系）表示的数据库。 物理模型是这些数据实际上如何作为数据结构存储在文件或内存中。不同的关系数据库系统可以表示相同的逻辑模型，但物理模型将是特定于系统的并针对不同的目的进行优化。逻辑-物理映射不一定是 1:1，在某些情况下，单个逻辑表可以在物理上拆分为多个文件甚至多个计算机，或者逻辑连接可以存储（缓存）为单个物理表。这在逻辑层面上应该是透明的，但会影响性能。
SQL 在逻辑级别上工作，因为无论物理表示如何，您都以相同的方式查询表。某些 SQL 方言可能支持基于物理模型特征的优化提示。
因此，在实体框架中，所谓的存储模型实际上是逻辑数据库模型，因为EF存储模型独立于任何特定的数据库实现。 AFAIK 中根本没有表示物理数据库模型。
然后，EF 在此基础上构建另一层，EF 将其称为“概念模型”。概念模型通常更具体于应用程序。同一数据库上的不同应用程序可能具有基于共享逻辑模型的不同概念模型。 （顺便说一句，EF中的存储模型不必代表DB的整个逻辑模型，它可以是一个子集。但是包含的子集必须与DB的逻辑模型1：1映射）
When talking about relational databases, the logical model is the database represented in terms of relations (aka. tables), values, keys and integrity constraints like foreign key relationships. The physical model is how this data is actually stored as data structures on files or in memory. Different relational database systems can represent the same logical model, but the physical model will be system-specific and optimized for different purposes. The logical-physical mapping does not have to be 1:1, in some cases a single logical table could be physically split over several files or even several machines, or a logical join could be stored (cached) as a single physical table. This should be transparent on the logical level, but affects performance.
SQL works on the logical level, since you query tables the same way regardless of the physical representation. Some SQL dialects may supports optimization hints based on characteristics on the physical model.
Hence, in Entity Framework, what is called the storage model is actually the logical database model, since the EF storage model is independent of any specific database implementation. The physical database model is not represented in EF at all, AFAIK.
EF then builds yet another layer on top on this, which EF calls the conceptual model. The conceptual model is typically more application specific. Different applications on the same database might have different conceptual models based on the shared logical model. (BTW. The storage model in EF does not have to represent the whole logical model of the DB, it can be a subset. But the subset included must map 1:1 to the logical model of the DB)