问题
Let's say I have a 2 tables like below :
Department:
DeptId Name
Employee:
EmpId Name DeptId
Here I have a 0-to-many relationship between Department and Employee table.
Now when I read the relationship from Department to Employee, it says 1 department can have 0 or more employees.
Does this mean while creating Employee table, I will set DepartmentId (foreign key) as null due to zero or many relationship?
And how do we represent 1 or many relationship like for eg If relationship in ERD says 1 department can have 0 or more employees then DepartmentId (foreign key) will be non nullable in Employee table?
Basically I am just trying to understand how do we give constraint on foreign key based on ERD cardinality (1 to many relation,1 to zero or more relationship).
Can anyone please help me clear this confusion? I will really really appreciate that :)
回答1:
I will set DepartmentId(Foreign key) as null due to zero or many relationship?
No, the Foreign key should be not null. Imagine you have no employee in table Employee with DeptId = 1. So it represents the Department has zero relationships.
Otherwise, the Employee table contains multiple items with DeptId = 2, So it represents the 1-n relationships between Department and Employee table.
回答2:
ERD tools are great, but the most powerful design tool is still natural language, predicates, and constraints. So, when in doubt, use a plain text editor instead of an ERD tool. Also do not allow NULLs in the design phase.
All attributes (columns) NOT NULL
[p x] = predicate x
(c x.y) = constraint x.y
PK = Primary Key
AK = Alternate Key (Unique)
FK = Foreign Key
Starting with the department, this part does not change.
[p 1] Department identified by number DEPT_ID, named DEPT_NAME exists.
(c 1.1) Department is identified by department number.
(c 1.2) For each department name, exactly one department has that name; for each department, that department has exactly one name.
department {DEPT_ID, DEPT_NAME} -- p 1
PK {DEPT_ID} -- c 1.1
AK {DEPT_NAME} -- c 1.2
Case 1: Emp * ---- 1 Dept
[p 2] Employee identified by number EMP_ID, named EMP_NAME, works for department DEPT_ID.
(c 2.1) Employee is identified by employee number.
(c 2.2) Each employee has exactly one name; for each employee name, more than one employee can have that name.
(c 2.3) Each employee works for exactly one department; for each department more than one employee may work for that department.
(c 2.4) If an employee works for a department, then that department must exist.
employee {EMP_ID, EMP_NAME, DEPT_ID} -- p 2
PK {EMP_ID} -- c 2.1, c 2.2, c 2.3
FK {DEPT_ID} REFERENCES department {DEPT_ID} -- c 2.4
Case 2: Emp * ---- 0..1 Dept
[p 2] Employee identified by number EMP_ID, named EMP_NAME, exists.
(c 2.1) Employee is identified by employee number.
(c 2.2) Each employee has exactly one name; for each employee name, more than one employee can have that name.
[p 3] Employee identified by number EMP_ID works for department identified by number DEPT_ID.
(c 3.1) Each employee works for at most one department; for each department more than one employee may work in that department.
(c 3.2) If an employee works for a department, then that employee must exist.
(c 3.3) If an employee works for a department, then that department must exist.
employee {EMP_ID, EMP_NAME} -- p 2
PK {EMP_ID} -- c 2.1, c 2.2
emp_dept {EMP_ID, DEPT_ID} -- p 3
PK {EMP_ID} -- c 3.1
FK1 {EMP_ID} REFERENCES employee {EMP_ID} -- c 3.2
FK2 {DEPT_ID} REFERENCES department {DEPT_ID} -- c 3.3
Case 3: Emp * ---- * Dept
[p 2] Employee identified by number EMP_ID, named EMP_NAME, exists.
(c 2.1) Employee is identified by employee number.
(c 2.2) Each employee has exactly one name; for each employee name, more than one employee can have that name.
[p 3] Employee identified by number EMP_ID works for department identified by number DEPT_ID.
(c 3.1) Each employee may work for more than one department; for each department more than one employee may work in that department.
(c 3.2) If an employee works for a department, then that employee must exist.
(c 3.3) If an employee works for a department, then that department must exist.
employee {EMP_ID, EMP_NAME} -- p 2
PK {EMP_ID} -- c 2.1, c 2.2
emp_dept {EMP_ID, DEPT_ID} -- p 3
PK {EMP_ID, DEPT_ID} -- c 3.1
FK1 {EMP_ID} REFERENCES employee {EMP_ID} -- c 3.2
FK2 {DEPT_ID} REFERENCES department {DEPT_ID} -- c 3.3
Case 4: Emp * ---- 1..* Dept
This one is tricky, combine cases 1 and 3 by introducing the concept of a home (primary, default) department.
[p 2] Employee identified by number EMP_ID, named EMP_NAME, works for home department HOME_DEPT_ID.
(c 2.1) Employee is identified by employee number.
(c 2.2) Each employee has exactly one name; for each employee name, more than one employee can have that name.
(c 2.3) Each employee works for exactly one home department; for each home department more than one employee may work for that home department.
(c 2.4) If an employee works for a home department, then that department must exist.
[p 3] In addition to the home department, employee identified by number EMP_ID also works for another department identified by number DEPT_ID.
(c 3.1) In addition to the home department, each employee may work for more than one other department; for each department more than one employee may work for that department.
(c 3.2) If an employee works for a department, then that employee must exist.
(c 3.3) If an employee works for a department, then that department must exist.
employee {EMP_ID, EMP_NAME, HOME_DEPT_ID} -- p 2
PK {EMP_ID} -- c 2.1, c 2.2, c 2.3
FK {HOME_DEPT_ID} REFERENCES department {DEPT_ID} -- c 2.4
emp_dept {EMP_ID, DEPT_ID} -- p 3
PK {EMP_ID, DEPT_ID} -- c 3.1
FK1 {EMP_ID} REFERENCES employee {EMP_ID} -- c 3.2
FK2 {DEPT_ID} REFERENCES department {DEPT_ID} -- c 3.3
On the application level check that, for a given employee, HOME_DEPT_ID is not repeated as EMP_ID in the emp_dept.
回答3:
It wouldn't be null because every employee has a department. A department can have zero employees though, meaning its ID is in none of the employee rows.
来源：https://stackoverflow.com/questions/60245854/how-do-we-give-constraint-on-foreign-key-column-based-on-erd-cardinality