Identifying Relationship vs. Non-identifying Relationship

本文探讨了数据库中标识与非标识关系的概念,通过具体案例解释了一对一、一对多及多对多关系的区别,并强调了正确设置主键与外键的重要性。

Identifying vs non-identifying has nothing to do with identity. Simply ask yourself can the child record exist without the parent? It has to do with whether the primary key of the child (can include more than one coumn) includes the foreign key of the parent. In the non-identifying relationship the child's primary key(PK) MUST NOT include the foreign key(FK).

Ask yourself this question

  • Can the foriegn key from the parent be included in the primary key of the child?

or asked in the opposite way

  • Can the child record exist without the parent record?

These are the same question, just put differently. If the FK must not be included in the PK meaning the child can exist without the parent, then it is non-identifying. Otherwise it is identifying. As noted in the comments more clearly: If a child can exist without the parent, then it is non-identifying.

One-to-one identifying relationship

Social security numbers fit nicely in to this category. SSNs cannot exist with out a person. The person_id would be the PK for the person table, including columns such as a name and address. (let's keep it simple). The social_security_number table would include the ssn column and the person_id column as a foreign key. Since this FK could be the PK for the social_security_number table it is an identifying relationship.

One-to-one non-identifying relationship

At a large office complex you might have an office table that includes the room numbers by floor and building number with a PK, and a separate employee table. The employee table (child) has a FK which is the office_id column from the office table PK. While each employee has only one office and (for this example) every office only has one employee this is a non-identifying relationship since offices can exist without employees, and employees can change offices or work in the field.

One-to-many relatoinships

One-to-many relationships can be categorized easily by asking the same question. 

Many-to-many relationships

Many-to-many relationships are always identifying relationships. This may seem counter intuitive, but bear with me. Take two tables libary and books, each library has many books, and a copy of each book exists in many libraries.

Here's what makes it and identifying relationship: In order to implement this you need a linking table with two columns which are the primary keys of each table. Call them the library_id column and the ISBN column. This new linking table has no separate primary key, but wait! The foreign keys become a multi-column primary key for the linking table since duplicate records in the linking table would be meaningless. The links cannot exist with out the parents; therefore, this is an identifying relationship. I know, yuck right?

Most of the time the type of relationship does not matter.

All that said, usually you don't have to worry about which you have. Just assign the proper primary and foreign keys to each table and the relationship will discover itself.

<think>嗯,用户想了解如何使用MySQL Workbench生成E-R图并定义实体之间的关系。首先,我需要回忆一下MySQL Workbench的基本操作步骤。记得在Workbench里,E-R图是通过创建EER模型来实现的,所以可能需要先新建一个模型或者从已有数据库导入结构。 接下来,用户可能需要具体的步骤指导,比如如何添加实体、定义属性、设置主键和外键。应该分步骤说明,从打开软件开始,创建新模型,添加表,定义字段,再到建立关系。另外,实体之间的关系,比如一对一、一对多,可能需要不同的操作方式,比如使用外键工具拖动连接。 还要考虑用户可能遇到的问题,比如如何调整视图布局,或者如何导出E-R图。另外,用户可能对关系类型不太清楚,需要简单解释一下不同关系的区别和应用场景。比如一对多关系通常用外键实现,而多对多则需要中间表,这部分可能需要示例说明。 然后,根据用户提供的引用内容,里面提到了配置文件的位置和外键约束的相关问题。虽然用户的问题是关于E-R图的,但可能需要提到在应用层处理外键的情况,尤其是阿里开发规范中提到的不使用数据库外键,这时候在设计E-R图时可能需要注释说明,但实际在Workbench中还是会用到外键来建立关系,只是在实际代码中不依赖数据库的外键约束。 还需要检查是否有遗漏的步骤,比如保存模型、导出图像格式,或者如何逆向工程从现有数据库生成E-R图,这可能对用户有帮助。同时,用户可能需要知道如何验证关系是否正确,比如查看外键设置是否正确,或者通过生成的SQL脚本来确认。 最后,生成相关问题时要围绕E-R图创建、关系类型、外键约束与应用层实现的区别,以及Workbench的其他功能,比如正向和逆向工程等。确保问题覆盖用户可能进一步感兴趣的方面,帮助他们深入学习。</think>### 使用MySQL Workbench生成E-R图及定义关系的分步教程 #### 一、创建E-R图基础操作 1. **新建EER模型** - 打开MySQL Workbench → 点击"File" → 选择"New Model" - 在左侧"Physical Schemas"区域右键选择"Add Diagram"创建画布[^1] 2. **添加实体(表)** ```mermaid graph TD A[点击工具栏Table图标] --> B[在画布单击放置表] B --> C[双击表头修改表名] C --> D[填写列名/数据类型/约束] ``` - 主键设置:勾选PK(Primary Key)列 - 字段属性:通过NN(Not Null)、UQ(Unique)等设置约束[^2] #### 二、定义实体关系(Relationships) 1. **一对多(1:N)关系** - 使用工具栏"Non-Identifying Relationship"工具 - 从父表拖拽到子表 → 自动生成外键字段 - 示例:`部门表(department)`与`员工表(employee)` ```sql ALTER TABLE employee ADD FOREIGN KEY (dept_id) REFERENCES department(id); ``` 2. **多对多(M:N)关系** - 需创建中间表:如`学生选课表(student_course)` - 同时建立两个一对多关系 - 示例配置: ```markdown | student | course | student_course | |---------------|---------------|----------------------| | id (PK) | id (PK) | student_id (FK) | | name | name | course_id (FK) | ``` 3. **一对一(1:1)关系** - 使用"Identifying Relationship"工具 - 共享主键:子表主键同时作为外键 - 典型应用场景:用户表与用户详情表分离 #### 三、高级配置技巧 1. **逆向工程生成ER图** - 点击"Database" → "Reverse Engineer..." - 连接现有数据库自动生成模型[^1] 2. **关系可视化调整** - 右键关系线 → "Edit Relationship"设置级联规则 - 拖动锚点调整连接线布局 3. **注释与文档生成** - 在表属性中添加注释(Comment字段) - 通过"File" → "Export"生成PNG/SVG格式图表 #### 四、注意事项 1. **外键约束与实际应用** - Workbench默认生成物理外键,但根据阿里开发规范建议,生产环境应在应用层实现约束逻辑[^3] - 可通过`Foreign Key Options`禁用自动约束 2. **模型版本控制** - 保存为.mwb文件(包含完整模型结构) - 使用"File" → "Export" → "Forward Engineer SQL CREATE Script"生成DDL语句
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值