在设计RDBMS模式时，我想知道具体对象是否有形式化原则：例如，如果它是Persons表，那么每个记录都是非常具体且唯一的。每条记录实际上代表一个独特的人。
但是像Courses这样的表呢（在学校）。它可以具有说明，单位数（仅在秋季（秋季）或春季等期间提供），这是课程的“常规属性”。
然后是实际的CourseSessions，其中包含有关time_from和time_to的信息（例如上午10点至上午11点），无论是星期一，星期三还是星期二/星期四，并且由讲师进行讲授，并指出在课程表中使用course_id。
因此，以上两个表都是必需的。
是否有针对“具体”与“抽象”的表格设计原则？
更新：我的意思是“抽象”，这是一门课程是一个抽象的主意...它可以有多个实例...例如，上午10点至11点的Physics 10课程，以及下午12点至1pm的另一门课程。
最佳答案
例如，如果是Persons表，则每个记录都是非常具体且唯一的。每条记录实际上代表一个独特的人。
那是希望，但不是现实。
根据移民身份或合法死亡身份，可能有两个（或更多记录）代表同一个人。很难唯一地识别人-首先，中间名和姓氏可以匹配，但实际上反映了不同的人。 SSN / SIN不可靠，因为它们会发生变化（移民，合法死亡）。名称不能保证性别，可以更改性别。
是否有针对“具体”与“抽象”的表格设计原则
根据解释，“具体”与“抽象”的分类是任意的。开始日期和结束日期是否真的使课程课程“具体化”？因为我可以在[选择日历的软件]中预订很多东西-并不意味着上课确实已经发生，或者说最终成绩是合法的值...
表设计基于业务规则，以及支持这些规则所需的逻辑实体（可以在物理模型中成为表）。规范化有助于使这些实体更加明显。
关于mysql - 在RDBMS中，是否存在针对具体对象的正式设计原则，例如Course vs CourseSession？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3648288/