在学习了 George Tillmann 的一本书“使用驱动的数据库设计：从逻辑数据建模到物理模式定义”之后。
我想为我自己的社交平台创建一个逻辑模型，该模型类似于具有自己风格的博客平台。然而，在绘制逻辑模型时，很难决定什么是它自己的实体和关系。本书中的大多数示例都显示了与现实世界实体的“映射”，即已经存在的所有实体，即部门到工人，而不是我的网站，它有更多的人为分离。
例如，我必须决定“用户”、“公共个人资料”、“用户定义的类别”、“评论”、“喜欢”、“帖子”之间的关系。问题是，我可以找到它们之间的关系。即评论是由用户发表的，评论可以放在公共档案中，评论在帖子中，评论有喜欢，等等其他实体。如您所见，区别并不像现实世界的映射那样突出。这个映射正常吗？除非，我应该更具体..like profile-comment 链接到配置文件和用户，post-comment 链接到帖子和用户，postlikes 链接到帖子和用户，commentlikes 喜欢评论和用户。这里仍然有一个星形模式。如果我添加一个“通知记录器”实体，更糟糕的是，这里几乎所有地方都与它相关联！
我现在觉得，在没有逻辑模型的情况下创建一个实际的物理模型会更容易，但我不想错误地认为可以跳过——因为我缺乏构建模型的能力。
George Tillmann 对要遵循的框架的建议：
我个人从未正式创建过逻辑模型/逻辑模式，而不仅仅是从最终用户那里收集的一些预先计划和信息和需求。因此，这大致解释了您从 George Tillmann 提供的图中逻辑建模的前两个步骤，而不是实际构建逻辑模型。
我喜欢开始动手，并在数据库中构建物理实体及其关系。根据需要对它们进行更改很容易，尤其是在它们被发布到生产环境之前，尤其是在它们中有任何实际数据之前。拥有物理模式可以很容易地可视化，然后在短期内根据需要进行修改。
当人们难以定义模型时，我的一般建议是从本质上倒退并考虑最终用户需要的用例，然后考虑应用程序中需要支持它的具体类。您的数据模型在设计上通常与具体类本身相距不远，尤其是在最常见的用例中，例如您的博客平台。
此外，当您的大多数模型本身相互关联时，本质上并没有错。一方面，这是一件好事，因为它表明您在关系模型中具有很强的引用完整性，使其适合关系数据库。
并不是每个实体都与您的用例直接相关，例如，您不能
like（public-profile通常）在博客中。相反，这两个实体具有扩展关系，其中 apublic-profile与 auserwholikesa相关post。