在设计RDBMS schema时，我想知道具体对象是否有形式原则：例如，如果是Persons表，那么每条记录都是非常具体和唯一的。事实上，每条记录都代表一个独特的人。
但是像Courses（在学校里）这样的桌子呢？它可以有描述、单元数、仅在秋季（秋季）或春季提供等，这些是课程的“一般属性”。
然后是 actual CourseSessions，它有关于time_fromand的信息time_to（例如上午 10 点到 11 点），无论是周一、周三还是周二/周四，以及教授它的讲师，还使用 a 指向course_idCourses 表。
所以上面两张表都是需要的。
是否有“具体”与“抽象”的表格设计原则？
更新：我在这里的“抽象”意思是一门课程是一个抽象的概念……它可以有多个实例……例如上午 10 点到 11 点的物理 10 课程，以及下午 12 点到 1 点的课程。
例如，如果是 Persons 表，那么每条记录都是非常具体和唯一的。事实上，每条记录都代表一个独特的人。
那是希望，但不是现实的情况。
根据移民或法定死亡身份，可能有两个（或多个）代表同一个人的记录。唯一识别人是很困难的——首先，中间名和姓氏可以匹配，但实际上反映了不同的人。SSN/SIN 不可靠，因为它们可以改变（移民，合法死亡）。名字并不能保证性别，而且性别是可以改变的。
“具体”与“抽象”的分类是任意的，有待解释。开始和结束日期真的使课程会话“具体”吗？因为我可以在 [Calendaring software of choice] 中预订很多东西——这并不意味着真的上课了，或者最终成绩是合法的值......
表设计基于业务规则，以及支持这些规则所需的逻辑实体（可以成为物理模型中的表）。规范化有助于使这些实体更加明显。
基于数学的关系数据模型证明了一种设计数据模型的方法，在该数据模型上某些操作正确无风险。
不幸的是，这种数据模型不是解决数据库性能问题的合适解决方案。如何组织特定业务领域的表不仅需要考虑对象的抽象模型或数据库规范化，还需要考虑系统的性能规划。是的，抽象的泄漏。
例如，树形结构的设计策略有两种：邻接模型和物化路径模型（The art of SQL）。哪个更好取决于哪些操作需要优化。
我推荐一篇很好的经典文章：泄漏抽象定律
抽象是有代价的（而且通常比预期的要高）
作者：Keith Cooper
SQL 的艺术，在我看来，当然是数据库设计的灵魂。