弱/强关系：强关系只是意味着依赖实体不能脱离关系而存在。以班级、课程和房间为例。想象以下对话：
"I think I'll teach a class this September."
"Good. What course will you teach?"
"I haven't decided yet."
好吧，在这位讲师决定一门课程之前，真的不能上课。由于必须在创建课程之前指定课程，因此这种关系很牢固。此外，在考虑上哪门课时，“珠子渲染”中的课程和“Cybercrafting”中的课程是完全不同的两件事，即使他们可能同时在同一个房间（只是在不同的日子）见面。每个班级的身份都与课程密不可分。所以这种关系也是识别的。
"I think I'll reach Discretionary Logic this September."
"Good. What room will it be in?"
"I haven't decided yet."
即使没有分配房间，该类仍然可以存在。是的，需要在学期开始前分配一个房间，但目前我们仍然可以创建班级，将“TBD”放入目录并允许学生注册。班级可以在没有房间的情况下存在（一段时间，无论如何），所以关系很弱。此外，“自由裁量逻辑”中的两个课程在功能上是等效的，即使它们是在不同的房间教授的。与房间的关系与班级的类型无关。关系是不确定的。
所以如果学生在17号房间报了珠子渲染，却被告知房间已经变成了12号房间，他们就不会想，“这是一个完全不同的班级！” 不，班级是一样的，只是位置不同。但是，如果他们被告知该课程现在是“二手嘉年华人员配备”，那么他们是对的。现在这是一个完全不同的类。这是识别关系和非识别关系之间的区别。
一元/递归关系：重要的是要认识到所有关系都至少包含两个实体。通过这种方式，数据库关系类似于人际关系—— Tango 需要两个。“一元”只是意味着关系的双方都由同一个逻辑实体填充。
很容易看出，在两个 Class 实体或两个 Room 实体之间，不能满足 Class 实体和 Room 实体之间的“相遇”关系。但是，“由管理”关系需要双方都有一个 Employee 实体。很明显，员工不需要这种关系才能存在。也许该员工是新员工，尚未分配经理。也许员工是这个特定组织中的领头羊，没有其他员工值得满足这个要求。
或者说，如果当初由Carol管理的Pete，现在由Sarah管理，Pete的本性并没有改变。去问问他吧。
所以这种一元关系是弱/不可识别的。它也是递归的，Pete 可能由 Carol 管理，而 Carol 由 Sam 管理，而 Sam 是......好吧，你明白了。
一元关系也往往是递归的，尽管这更多是设计的效果而不是关系的要求。例如，“已婚”的关系将是一元的，但不是递归的。如果以可以递归的方式实施，则必须小心防止它 - 或者劳动力中可能会有一些尴尬的时刻。
请注意，我没有在任何地方提到“主键”或“外键”。这些是实现细节，而不是关系类型的特征。人们可以完全理解关系的概念，而无需使用甚至考虑这些术语。
说了这么多，应该指出，识别和非识别，如果不是完全主观的术语，对上下文很敏感。例如，一所大学在同一学期安排多个相同课程的课程是完全合理的。因此，房间 3 可能有一个“代数 2”课程，房间 7 中可能有一个不同的“代数 2”课程，房间 12 中还有另一个课程。这大大加强了班级和房间之间的关系。现在，“我正在学习代数 2”这一陈述不足以确定您注册了三个课程中的哪一个。
除此之外，第四节“代数 2”课也可以与其他人在同一个房间举行，只是在不同的时间或日期。
因此，使用弱关系的初始设计在某些情况下可能工作得很好（一个学期内只开设一门课程的小学校），但必须在不同的情况下建立强关系（提供或提供或可能在同一学期提供同一课程的多个班级）。所以这不是实体类型所固有的。仅通过查看 ER 图无法提前确定。
