开发数据库模型的不确定性
uncertainty in developing a database model
我正在尝试为候选人、他们的注册考试和参加考试时的考试结果开发一个数据库模型。
这是我到目前为止所做的。但是我不确定我是否在正确的轨道上，尤其是从考试 table 到考试结果 table。
为特定候选人
的 examinationresult population 正确编写插入 sql 代码有多容易
考试类型分为科学、艺术和社会科学。他们每个都有 4 个组件
进度说明
鉴于问题根据我的回复和 TRD 发生了实质性变化（在澄清要求时，不是范围），这将需要一些时间 back-and-forth。让我们确定步骤：您的步骤编号是奇数，从 1 开始；作为回应，我的是偶数。 以前响应步骤的部分 已经过时，它们可能不再有意义。
我会建议赏金，除了你的点数很少。
回答初始问题的第 2 步 & Step 1 Diagram
This is what I've done so far.
你做的不错，但是现在分配PK还为时过早。此外，为每个文件分配一个 ID 作为起点会削弱建模过程，结果将不是数据库。你得先对数据（不是数据库）建模，然后在entities clear 和stable 的时候赋值Keys。因此，删除所有 ID 和 PK，并将数据建模为数据。忘记你想用数据做什么（即忘记应用程序）。
how easy will it be to right write an insert sql code for examinationresult population for a particular candidate
现在你不能。 Candidate 和 Examination[Result]. 之间没有关系 这不是问题，因为现阶段建模不完整，完成后代码会很简单。
隐含了实体 Course，但它丢失了。
however im unsure if am on the right track especially from the examination table to the examination result table
您在处理其他一些文件时走在了正确的轨道上，但是 Examination 集群需要改进。这将花费一些 back-and-forth。一旦你回答了评论中的问题，我们就可以继续了。
主要问题是：Examination 如何识别。
An ID field does not identify anything, nor does it provide uniqueness in the data, which is required if you want data integrity. IDs result in a Record Filing System with no integrity, however, it appears you want a database with data integrity. Is that correct ?
回到用户那里讨论课程和组件是如何识别的，他们使用什么代码等等。这些是他们用来的自然键识别他们的数据，当他们需要查询或输入考试结果时，他们将输入系统。
- 例如。考虑独立存在的
Examination 是不合理的（正如您对其建模的那样）。人们不会去大厅参加任何旧考试。考试只存在于一门课程的上下文中，他们参加考试一门课程。
- 然后课程（而不是考试）包含要检查的组件。而且每门课程都有不同数量的组件。
- 例如。一个
Course 被识别为 作为 ENG101 对于 English Literature year 1
- 然后是其中的组件。例如。
2b Short essay on poetry.
他们可能还需要确定课程的年份和学期，在这种情况下，您每学期需要CourseOffering。
考虑这个，作为一个讨论点。 Courier是示例数据，蓝色是Key，绿色是non-key:
响应步骤 4
对问题和描述的回应
This is what I've done so far.
我之前的回复仍然适用：
You have done some good work, but it is too early for assigning PKs. Besides, assigning an ID on every file as a starting point will cripple the modelling process, the result will not be a database. You have to model the data (not the database) first, then assign Keys when the entities are clear and stable. So drop all your IDs and PKs and model the data, as data. Forget about what you want to do with the data (ie. forget the app).
你还没有解决我在你的 Step 1 Diagram, in your Step 3 Diagram 中确定的那个问题。从证据来看，您可能对 ID 为 "Primary Keys"（没有）感到满意，尽管您已经确定了障碍。这意味着你对数据的理解是残缺的，你的图表的进展会很慢。
我之前的回复仍然适用：
An ID field does not identify anything, nor does it provide uniqueness in the data, which is required if you want data integrity. IDs result in a Record Filing System with no integrity, however, it appears you want a database with data integrity. Is that correct ?
您必须回答这些问题，否则您的设计将无法进行。这些是必须纠正的严重错误。一个包含严重错误的基础无法建立或进步。
您能否确认一下，您确实想要一个关系数据库，它具有关系数据库所具有的完整性和性能，并且易于编码，而不是记录归档系统，具有没有完整性或速度，将难以编码。正确 ?
如果[1]是正确的。由于 ID 字段 "Primary Keys" 不提供关系数据库所需的 行 唯一性，您打算如何提供所需的行唯一性？或者，您是否乐于拥有一个充满重复 行（每个都有唯一记录 ID）的 RFS？
how easy will it be to right write an insert sql code for examinationresult population for a particular candidate
我之前的回复仍然适用：
Right now you can't. You have no relationship between Candidate and Examination[Result]. That is not a problem because the modelling is incomplete at this stage, when it is complete the code will be simple.
好的，在您的 Step 3 Diagram 中，您已经在 Candidate 文件和 ExaminationResult 文件之间画了一条线（与在数据库中插入关系相反）。
在记录归档系统中，当然，您可以在任意两个文件之间画一条 线，插入相关的 ID 字段，嘿，转瞬之间，您有"linked"或"connected"或"mapped"这两个文件。
但是数据库设计（相对于文件设计）并不是那样进行的，你不能只是在任意两个之间画一条线 objects，插入相关的 ID 字段，然后嘿 presto , 创建 数据库关系 。不，你画的虚线没有依据，没有完整性。例如。在您的 Step 3 Diagram 中，任何考生都可以与任何考试[结果]相关联。
在记录归档系统中是 "normal" 或 "ordinary"，但在数据库中，它是被识别和理解为 错误，从而阻止。因为我们期望数据库的完整性，并且因为它可以很容易地被阻止。
however im unsure if am on the right track especially from the examination table to the examination result table
我之前的回复仍然适用：
You are on the right track with some of the other files, but the Examination cluster needs work. This will take a bit of back-and-forth. Once you answer the questions in the comments, we can proceed.
The main issue is this: how is Examination identified.
ID 字段不标识 行（它标识一条记录，它在数据库中没有任何相关性）。
相同的两个问题 (a) 缺少有效的 identifier，以及 (b) 缺少 row 唯一性，存在于您的考生、组件和考试结果文件。
响应图表作为图表（相对于内容）
你比 Step 1 Diagram 改进了它，并且响应我的响应步骤 2，太棒了。但是关系（其中大部分）仍然不正确。而Candidate::Examination的基础还没有解决
在我看来，您不清楚符号（缺口；圆圈；鱼尾纹）以及它们在 parent 和 child 结尾处的确切含义） .所以你需要先学习它，然后再画图，而不是反过来。
很高兴您使用了有意义的符号，并且显示了许多细节（很多人不这样做，他们绘制的 nice-looking 图表缺少充分理解模型。这意味着每个凹口；圆圈；鱼尾纹，都有特定的含义，必须正确绘制，才能将含义传达给 reader.
实体不是孤立存在的，必须先有一个parent，才能让child成为[=的child 487=]。没有"equal"这样的东西。依赖总是一个方向。
你的一侧是 1-and-only-1，另一侧是 1-and-only-1 的关系不正确，它们表示规范化错误.从属记录中的字段可以规范化为从属记录。
例如。 AdmissionLetter 不是一个单独的文件，某种形式的 AdmissionLetter identifier（不是 ID 字段）应该位于 Candidate.
例如。 Title::Candidate是绘图错误，Title端应该是1，Candidate端应该是0-to-many。
在数据模型中，粗体（按照惯例）表示迁移的外键。迁移的Primary Key不是粗体
对图表内容的回应
从您的回复来看，Subject 一词胜过 Component 一词；类别胜过各种 loosely-identified 元素成为一个清晰的实体。
考虑独立存在的考试是不合理的（正如您所建模的那样）。
人们不会去大厅参加任何旧考试，任何旧科目。考试只存在于一门学科的背景下，他们参加考试一门学科。
我接受一次考试，四门科目
我接受这四个主题由一个类别定义。
我接受候选人已注册类别。
因此考试只存在于一个主题的上下文中，而这个主题只存在于一个类别的上下文中，而考生参加的考试是一个类别，其中包含四个（数字无所谓）主题。
解决了这个问题，还有两个问题：
您是否需要将考试记录为一个事件，独立于参加该事件的考生。例如。检查（位置，日期时间）？
考试是考一个还是多个类别的考生？
作为一个记录中的四个重复字段实现的四个主题的概念打破了第二范式，它要求将重复字段规范化为 child 文件中的单独记录。
因此，对于您的 Component 和 ExaminationResult 文件，该问题需要解决。
请注意，在两个单独的文件中重复出现该问题的事实是第二个警报，表明这是一个错误。
我已经为您澄清了 Category/Subject 问题，并解决了规范化错误。
我已经为类别和主题提供了简单的 标识符。
如果您不执行此操作，您将无法在候选人和他们正在检查的主题之间保持完整性。同样，当你进入编码阶段时，你会遇到各种问题。
我不知道你想用 exComp 做什么，所以我没有回复。也许你可以说几句。
到目前为止，仍然没有合理的方法将考生与考试或考试结果相关联。也就是说，它没有基础，没有任何东西被定义为关系的基础，因此关系没有完整性。
根据我目前能够确定的情况，必须进行某种考试注册。否则您不会知道考生正在参加考试。
当考生注册时，他们注册了考试，并且该考试由类别定义（因此受到限制）。否则任何考生都可以参加任何考试，我相信这是你想避免的。
此外，他们参加的[四个]考试科目应该受到他们注册的类别的限制。
- 您确实想确保您不记录注册理科的考生的经济学考试成绩，对吗？
我确定考试的基础是注册。这就是事件、事实和记录，确定考生将参加考试。
identifier无形中跳出来，就是CategoryCode加CandidateID。瞧！我们有行唯一性。壮观！我们有诚信。
现在ExaminationResult的完整性可以实现了：它被约束到CandidateRegistration::Category 和到Category::Subject.
待解决：您是否需要确定考生注册考试的事实（RegistrationDate、AdmissionLetter 等）与考生参加考试的事实（例如 ExaminationDate） ？一种唱名。
现在，我已经将其建模为没有区别的单一事实，并且 table 被称为检查，因为您似乎专注于此。
谓词
如今，人们似乎在不了解关系数据库的基础知识或数据建模练习的情况下，埋头于绘制图表。可以预见的是，这会导致 ill-defined 图表（省略了许多相关细节）[谢天谢地，你的图表有一些定义]，并且它会产生一个不完整的记录归档系统，没有关系的力量，就没有速度，取而代之的是具有完整性、力量和速度的关系数据库。
一个经常被忽略的概念是谓词。一个有能力的reader可以读懂一个好的数据模型，并确定谓词，因为它们是在模型中以符号的形式绘制的，但是新手不理解符号，或者各个项目的相关性，因此会错过谓词。总而言之，谓词是对数据施加的所有约束：
行标识：
- 它存在的依据，以及它是如何识别的：独立的（方角）；或从属（圆角）
行唯一性：主键和备用键（注意，IDs 不是键）
行之间的关系：
正在识别（实线）；或 Non-identifying（虚线）
意义、相关性、目的：all-important动词短语
另外，新手在没有图的时候，或者图不好的时候，或者自己设计文件系统，自己画图的时候，是不能确定Predicate的。因此，他们没有在他们的图表中识别相关的谓词。
Predicates在建模过程中非常重要，因为Predicates和模型表达Predicates一样，Predicates确认模型的准确性，它是一个反馈回路。它是建模练习的重要组成部分。因为我正在为您执行建模任务，所以我在执行该任务时正在计算谓词，它们对我来说是显而易见的。但它们对您来说可能并不明显。
当数据模型发布并准备好与用户讨论时，这些谓词将被合并到其中。它们属于 业务规则 的标题，它们构成了其中的一部分，因为这是用户感知它们的方式。因此，在演练和讨论期间，谓词（以及其他规定的业务规则）要么被用户确认，要么被拒绝。它们需要明确说明，因为与受过技术教育的开发人员不同，不能期望用户从良好数据模型中的符号中读取所有相关谓词。
在这种情况下，我是建模者，你是"user"。因此，我决定明确地为您提供谓词。这样您就可以确认或否认它们，从而我们可以推进建模练习。一旦习惯了从良好的数据模型中读取谓词，就不需要为您显式声明它们。同样，谓词非常重要，因为它们验证（或不验证）模型的准确性。所以请仔细阅读它们，并对您不完全同意或不理解的任何谓词进行评论。
当然，没有必要显式声明所有谓词，太多了，我们只声明更相关的，涉及：
(a)行(tables)，它们存在的基础
(b) 他们的身份证明
(c) 所有依赖项
(d)关系，双方（一方是Verb Phrase）。
步骤 4 TRD
以上我都实现了，很详细。请将此 TRD 视为下一次迭代和评论的讨论平台。 Courier表示示例数据，蓝色表示Key值，绿色表示non-key values:
回复第 6 步聊天第 5 步
所有讨论的问题都已解决，并在模型中实施。抱歉，我现在没有时间 post 详细信息，这只是识别更新的型号。
Entity-Relation 和第 1 页的完整谓词
已解决所有问题。
谓词
既然是stable，我现在给你关系谓词(child-to-parent)的第二面。现在你已经理解了它们，我已经删除了新手需要的重复的、烦人的"Each"。
Entity-Relation-第2页关键
现在 TRD 是 stable，我们准备好进行密钥确定
(仅次于Normalisation，Key Determination是建模练习的关键部分。这两个任务通常执行side-by-side，它们是密不可分的，我已经确定了keys。在这种情况下，给定通信媒体的局限性，我将其作为顺序步骤呈现）。
在这里，我使用了 IDEF1X 符号的扩展，它允许我集中与任务相关的组件，我希望它是 self-explanatory。仅给出键列。外键不是粗体（因为它们在 DM 中）。所有这些，都是为了让眼睛看起来更舒服。
大多数 table 有一把钥匙（主要）。如果有两个键（主键和备用键），AK 在线下方。
这是我根据要求为您推荐的密钥。
我正在尝试为候选人、他们的注册考试和参加考试时的考试结果开发一个数据库模型。 这是我到目前为止所做的。但是我不确定我是否在正确的轨道上，尤其是从考试 table 到考试结果 table。 为特定候选人
的 examinationresult population 正确编写插入 sql 代码有多容易考试类型分为科学、艺术和社会科学。他们每个都有 4 个组件
进度说明
鉴于问题根据我的回复和 TRD 发生了实质性变化（在澄清要求时，不是范围），这将需要一些时间 back-and-forth。让我们确定步骤：您的步骤编号是奇数，从 1 开始；作为回应，我的是偶数。 以前响应步骤的部分 已经过时，它们可能不再有意义。
我会建议赏金，除了你的点数很少。
回答初始问题的第 2 步 & Step 1 Diagram
This is what I've done so far.
你做的不错，但是现在分配PK还为时过早。此外，为每个文件分配一个 ID 作为起点会削弱建模过程，结果将不是数据库。你得先对数据（不是数据库）建模，然后在entities clear 和stable 的时候赋值Keys。因此，删除所有 ID 和 PK，并将数据建模为数据。忘记你想用数据做什么（即忘记应用程序）。
how easy will it be to right write an insert sql code for examinationresult population for a particular candidate
现在你不能。 Candidate 和 Examination[Result]. 之间没有关系 这不是问题，因为现阶段建模不完整，完成后代码会很简单。
隐含了实体 Course，但它丢失了。
however im unsure if am on the right track especially from the examination table to the examination result table
您在处理其他一些文件时走在了正确的轨道上，但是 Examination 集群需要改进。这将花费一些 back-and-forth。一旦你回答了评论中的问题，我们就可以继续了。
主要问题是：Examination 如何识别。
An ID field does not identify anything, nor does it provide uniqueness in the data, which is required if you want data integrity. IDs result in a Record Filing System with no integrity, however, it appears you want a database with data integrity. Is that correct ?
回到用户那里讨论课程和组件是如何识别的，他们使用什么代码等等。这些是他们用来的自然键识别他们的数据，当他们需要查询或输入考试结果时，他们将输入系统。
- 例如。考虑独立存在的
Examination是不合理的（正如您对其建模的那样）。人们不会去大厅参加任何旧考试。考试只存在于一门课程的上下文中，他们参加考试一门课程。 - 然后课程（而不是考试）包含要检查的组件。而且每门课程都有不同数量的组件。
- 例如。一个
Course被识别为 作为ENG101对于English Literature year 1 - 然后是其中的组件。例如。
2b Short essay on poetry.
他们可能还需要确定课程的年份和学期，在这种情况下，您每学期需要CourseOffering。
考虑这个，作为一个讨论点。 Courier是示例数据，蓝色是Key，绿色是non-key:
响应步骤 4
对问题和描述的回应
This is what I've done so far.
我之前的回复仍然适用：
You have done some good work, but it is too early for assigning PKs. Besides, assigning an ID on every file as a starting point will cripple the modelling process, the result will not be a database. You have to model the data (not the database) first, then assign Keys when the entities are clear and stable. So drop all your IDs and PKs and model the data, as data. Forget about what you want to do with the data (ie. forget the app).
你还没有解决我在你的 Step 1 Diagram, in your Step 3 Diagram 中确定的那个问题。从证据来看，您可能对 ID 为 "Primary Keys"（没有）感到满意，尽管您已经确定了障碍。这意味着你对数据的理解是残缺的，你的图表的进展会很慢。
我之前的回复仍然适用：
An ID field does not identify anything, nor does it provide uniqueness in the data, which is required if you want data integrity. IDs result in a Record Filing System with no integrity, however, it appears you want a database with data integrity. Is that correct ?
您必须回答这些问题，否则您的设计将无法进行。这些是必须纠正的严重错误。一个包含严重错误的基础无法建立或进步。
您能否确认一下，您确实想要一个关系数据库，它具有关系数据库所具有的完整性和性能，并且易于编码，而不是记录归档系统，具有没有完整性或速度，将难以编码。正确 ?
如果[1]是正确的。由于 ID 字段 "Primary Keys" 不提供关系数据库所需的 行 唯一性，您打算如何提供所需的行唯一性？或者，您是否乐于拥有一个充满重复 行（每个都有唯一记录 ID）的 RFS？
how easy will it be to right write an insert sql code for examinationresult population for a particular candidate
我之前的回复仍然适用：
Right now you can't. You have no relationship between Candidate and Examination[Result]. That is not a problem because the modelling is incomplete at this stage, when it is complete the code will be simple.
好的，在您的 Step 3 Diagram 中，您已经在 Candidate 文件和 ExaminationResult 文件之间画了一条线（与在数据库中插入关系相反）。
在记录归档系统中，当然，您可以在任意两个文件之间画一条 线，插入相关的 ID 字段，嘿，转瞬之间，您有"linked"或"connected"或"mapped"这两个文件。
但是数据库设计（相对于文件设计）并不是那样进行的，你不能只是在任意两个之间画一条线 objects，插入相关的 ID 字段，然后嘿 presto , 创建 数据库关系 。不，你画的虚线没有依据，没有完整性。例如。在您的 Step 3 Diagram 中，任何考生都可以与任何考试[结果]相关联。
在记录归档系统中是 "normal" 或 "ordinary"，但在数据库中，它是被识别和理解为 错误，从而阻止。因为我们期望数据库的完整性，并且因为它可以很容易地被阻止。
however im unsure if am on the right track especially from the examination table to the examination result table
我之前的回复仍然适用：
You are on the right track with some of the other files, but the Examination cluster needs work. This will take a bit of back-and-forth. Once you answer the questions in the comments, we can proceed.
The main issue is this: how is Examination identified.
ID 字段不标识 行（它标识一条记录，它在数据库中没有任何相关性）。
相同的两个问题 (a) 缺少有效的 identifier，以及 (b) 缺少 row 唯一性，存在于您的考生、组件和考试结果文件。
响应图表作为图表（相对于内容）
你比 Step 1 Diagram 改进了它，并且响应我的响应步骤 2，太棒了。但是关系（其中大部分）仍然不正确。而Candidate::Examination的基础还没有解决
在我看来，您不清楚符号（缺口；圆圈；鱼尾纹）以及它们在 parent 和 child 结尾处的确切含义） .所以你需要先学习它，然后再画图，而不是反过来。
很高兴您使用了有意义的符号，并且显示了许多细节（很多人不这样做，他们绘制的 nice-looking 图表缺少充分理解模型。这意味着每个凹口；圆圈；鱼尾纹，都有特定的含义，必须正确绘制，才能将含义传达给 reader.
实体不是孤立存在的，必须先有一个parent，才能让child成为[=的child 487=]。没有"equal"这样的东西。依赖总是一个方向。
你的一侧是 1-and-only-1，另一侧是 1-and-only-1 的关系不正确，它们表示规范化错误.从属记录中的字段可以规范化为从属记录。
例如。 AdmissionLetter 不是一个单独的文件，某种形式的 AdmissionLetter identifier（不是 ID 字段）应该位于 Candidate.
例如。 Title::Candidate是绘图错误，Title端应该是1，Candidate端应该是0-to-many。
在数据模型中，粗体（按照惯例）表示迁移的外键。迁移的Primary Key不是粗体
对图表内容的回应
从您的回复来看，Subject 一词胜过 Component 一词；类别胜过各种 loosely-identified 元素成为一个清晰的实体。
考虑独立存在的考试是不合理的（正如您所建模的那样）。
人们不会去大厅参加任何旧考试，任何旧科目。考试只存在于一门学科的背景下，他们参加考试一门学科。
我接受一次考试，四门科目
我接受这四个主题由一个类别定义。
我接受候选人已注册类别。
因此考试只存在于一个主题的上下文中，而这个主题只存在于一个类别的上下文中，而考生参加的考试是一个类别，其中包含四个（数字无所谓）主题。
解决了这个问题，还有两个问题：
您是否需要将考试记录为一个事件，独立于参加该事件的考生。例如。检查（位置，日期时间）？
考试是考一个还是多个类别的考生？
作为一个记录中的四个重复字段实现的四个主题的概念打破了第二范式，它要求将重复字段规范化为 child 文件中的单独记录。
因此，对于您的 Component 和 ExaminationResult 文件，该问题需要解决。
请注意，在两个单独的文件中重复出现该问题的事实是第二个警报，表明这是一个错误。
我已经为您澄清了 Category/Subject 问题，并解决了规范化错误。
我已经为类别和主题提供了简单的 标识符。
如果您不执行此操作，您将无法在候选人和他们正在检查的主题之间保持完整性。同样，当你进入编码阶段时，你会遇到各种问题。
我不知道你想用 exComp 做什么，所以我没有回复。也许你可以说几句。
到目前为止，仍然没有合理的方法将考生与考试或考试结果相关联。也就是说，它没有基础，没有任何东西被定义为关系的基础，因此关系没有完整性。
根据我目前能够确定的情况，必须进行某种考试注册。否则您不会知道考生正在参加考试。
当考生注册时，他们注册了考试，并且该考试由类别定义（因此受到限制）。否则任何考生都可以参加任何考试，我相信这是你想避免的。
此外，他们参加的[四个]考试科目应该受到他们注册的类别的限制。
- 您确实想确保您不记录注册理科的考生的经济学考试成绩，对吗？
我确定考试的基础是注册。这就是事件、事实和记录，确定考生将参加考试。
identifier无形中跳出来，就是CategoryCode加CandidateID。瞧！我们有行唯一性。壮观！我们有诚信。
现在ExaminationResult的完整性可以实现了：它被约束到CandidateRegistration::Category 和到Category::Subject.
待解决：您是否需要确定考生注册考试的事实（RegistrationDate、AdmissionLetter 等）与考生参加考试的事实（例如 ExaminationDate） ？一种唱名。
现在，我已经将其建模为没有区别的单一事实，并且 table 被称为检查，因为您似乎专注于此。
谓词
如今，人们似乎在不了解关系数据库的基础知识或数据建模练习的情况下，埋头于绘制图表。可以预见的是，这会导致 ill-defined 图表（省略了许多相关细节）[谢天谢地，你的图表有一些定义]，并且它会产生一个不完整的记录归档系统，没有关系的力量，就没有速度，取而代之的是具有完整性、力量和速度的关系数据库。
一个经常被忽略的概念是谓词。一个有能力的reader可以读懂一个好的数据模型，并确定谓词，因为它们是在模型中以符号的形式绘制的，但是新手不理解符号，或者各个项目的相关性，因此会错过谓词。总而言之，谓词是对数据施加的所有约束：
行标识：
- 它存在的依据，以及它是如何识别的：独立的（方角）；或从属（圆角）
行唯一性：主键和备用键（注意，
IDs不是键）行之间的关系：
正在识别（实线）；或 Non-identifying（虚线）
意义、相关性、目的：all-important动词短语
另外，新手在没有图的时候，或者图不好的时候，或者自己设计文件系统，自己画图的时候，是不能确定Predicate的。因此，他们没有在他们的图表中识别相关的谓词。
Predicates在建模过程中非常重要，因为Predicates和模型表达Predicates一样，Predicates确认模型的准确性，它是一个反馈回路。它是建模练习的重要组成部分。因为我正在为您执行建模任务，所以我在执行该任务时正在计算谓词，它们对我来说是显而易见的。但它们对您来说可能并不明显。
当数据模型发布并准备好与用户讨论时，这些谓词将被合并到其中。它们属于 业务规则 的标题，它们构成了其中的一部分，因为这是用户感知它们的方式。因此，在演练和讨论期间，谓词（以及其他规定的业务规则）要么被用户确认，要么被拒绝。它们需要明确说明，因为与受过技术教育的开发人员不同，不能期望用户从良好数据模型中的符号中读取所有相关谓词。
在这种情况下，我是建模者，你是"user"。因此，我决定明确地为您提供谓词。这样您就可以确认或否认它们，从而我们可以推进建模练习。一旦习惯了从良好的数据模型中读取谓词，就不需要为您显式声明它们。同样，谓词非常重要，因为它们验证（或不验证）模型的准确性。所以请仔细阅读它们，并对您不完全同意或不理解的任何谓词进行评论。
当然，没有必要显式声明所有谓词，太多了，我们只声明更相关的，涉及：
(a)行(tables)，它们存在的基础
(b) 他们的身份证明
(c) 所有依赖项
(d)关系，双方（一方是Verb Phrase）。
步骤 4 TRD
以上我都实现了，很详细。请将此 TRD 视为下一次迭代和评论的讨论平台。 Courier表示示例数据，蓝色表示Key值，绿色表示non-key values:
回复第 6 步聊天第 5 步
所有讨论的问题都已解决，并在模型中实施。抱歉，我现在没有时间 post 详细信息，这只是识别更新的型号。
Entity-Relation 和第 1 页的完整谓词
已解决所有问题。
谓词
既然是stable，我现在给你关系谓词(child-to-parent)的第二面。现在你已经理解了它们，我已经删除了新手需要的重复的、烦人的"Each"。Entity-Relation-第2页关键
现在 TRD 是 stable，我们准备好进行密钥确定
(仅次于Normalisation，Key Determination是建模练习的关键部分。这两个任务通常执行side-by-side，它们是密不可分的，我已经确定了keys。在这种情况下，给定通信媒体的局限性，我将其作为顺序步骤呈现）。
在这里，我使用了 IDEF1X 符号的扩展，它允许我集中与任务相关的组件，我希望它是 self-explanatory。仅给出键列。外键不是粗体（因为它们在 DM 中）。所有这些，都是为了让眼睛看起来更舒服。
大多数 table 有一把钥匙（主要）。如果有两个键（主键和备用键），
AK在线下方。这是我根据要求为您推荐的密钥。