我是数据建模新手，已开始学习教程以了解更多信息。
我正在尝试为假设场景创建一个模型，并且正在努力验证我创建的内容是否会被视为正确的数据模型。
基本上所有我试图做的就是以规范化的形式正确存储数据。在我的场景中，有 3 种类型的人，每种类型都有一些属性，并且每种都有一组联系方式。
下面的数据模型看起来可行吗？
【问题讨论】：
标签： sql-server entity-relationship data-modeling erd
个人与被告人、地方法官或工作人员之间的关系是类/子类模式的案例。在关系表中对这种模式进行建模有两种常用方法。
一种方式称为“类表继承”。您可以通过访问此标签了解更多信息：class-table-inheritance 或通过在网络上搜索 Martin Fowler 对同一主题的处理。您的设计与此设计相似。
另一种方法称为“单表继承”，您也可以用同样的方法进行研究。 single-table-inheritance。它更简单，并且在某些情况下可以正常工作。你处理更少的连接，但你处理更多的 NULLS。
许多使用类表继承的人也应用了一种称为“共享主键”的技术。 shared-primary-key。使用这种技术，被告、裁判官和 Staff_Member 将各自使用 person_id 的副本作为主键。此主键还用作外键。共享主键强制执行本例中存在的 IS-A 关系的一对一性质。
如果您想在数据建模方面走得更远，您可能希望将 ER 建模作为与关系模型不同的数据模型来学习。您在这里所做的基本上是使用 ER 图表来绘制关系模型。这并没有错，但它掩盖了一个全新的研究领域，通常称为概念数据建模。
如果您在概念级别生成 ER 模型，则不要尝试根据表来实现它。 ER 中有一个名为“泛化/专业化”的图表约定，它允许您描述一个类/子类的情况，同时对如何实现它保持沉默。
除了关系数据建模之外，概念数据模型还有一个有用的领域。概念数据模型之所以有用，恰恰是因为它们呈现了信息需求，而没有说明如何满足这些需求。
一旦您精通创建概念数据模型，将其中之一转换为关系模型并不难。
这可能超出了您的预期，但由于您正在学习建模，我想我会为您调查一些领域。
【讨论】：