Apologies in advance if this is a silly question. I recently faced this question while revising for databases, so I wish to check if my understanding is correct.
I understand that participation constraint is referring to the number of instances of an entity that can participate in a relationship. (E.g. Total and Partial).
Referential integrity is also a constraint that is related to relationships in a table, stating that a foreign key must reference an existing primary key of another entity.
Based on what I have read, I feel that referential integrity constraint is more about ensuring data integrity with regards to foreign keys, while participation constraint is more about just describing the relationships between two entities.
However, I keep having the feeling that Total Participation and Referential Integrity have a huge similarity. For example, let's say we have two tables
Customer(CustID, CustName)
Order(OrderID, CustID, OrderDate).
As CustID in the Order table must match a valid CustID in the Customer table, there is a referential integrity constraint here. Am I right to say that Order is also totally participating with Customer in a relationship?
Related
I want to create a many-to-one relationship between my customer and booking tables, however when I enforce referential integrity, only one-to-one shows.
I have several other tables that have worked correctly, so this seems to be a bug; can anyone offer any suggestions?
Summary:
Customer ID is the unique primary key in the Customer table
Customer ID is a foreign key in the booking table
Access is enforcing a one-one relationship between the two
How can I create this many-to-one relationship?
Thank you to everyone who responded, it turned out I had accidentally set the field indexing property to NO Duplicates.
When we create relational database tables, we have to use foreign key columns. It is obvious, otherwise we can not create relationships.
However, I noticed that it is enough to have a foreign key column, you do not need to say that there is a foreign key relationship in table A with table B.
As long as you can write the queries you can retrieve the data.
Do we use this concept for make thing easy? I know, when I look at a database table schema which has marked what columns are foreign key columns, it is easy to understand and start to work with it.
Is there any other reasons?
The point is Referential integrity. If you don't enforce it, sooner or later a bug in the code or some other accident happens and your database is left in an inconsistent state. These inconsistencies are very hard or impossible to fix afterwards.
When we create relational database tables, we have to use foreign key
columns. It is obvious, otherwise we can not create relationships.
Incorrect. You do not need to create foreign keys (though it's a good idea), and they do not represent relationships. They enforce the integrity of the relationship. A foreign key makes sure that a value in one column exists in another column.
However, I noticed that it is enough to have a foreign key column, you
do not need to say that there is a foreign key relationship in table A
with table B. As long as you can write the queries you can retrieve the data.
Yes, the relationship is based on the data itself, not by the inclusion of a foreign key. Also, foreign keys do not need to be between two tables, a table can have a foreign key to itself.
Do we use this concept for make thing easy?
No, we use foreign keys to enforce integrity. That they happen to make ERD diagrams easier to understand is simply a bonus.
I found the same definition for referential and relational integrity. Are they the same? I have researched the two terms separately but cannot find any good definitions.
Yes, they are the same thing. The term "Referential Integrity" is used much more though.
Referential Integrity relates to Foreign Keys in a Relational DB. For a table to exhibit Referential Integrity, the Foreign Key must either be null or reference an existing PK value in the related table.
I found a case in ER where for the life of me I can't figure out how to achieve referential integrity. The classical Employee, Manager, Department relationship can illustrate this problem.
With the following constraints:
Employee can work in only one Department.
Department can have many Employees.
Employee can have one Manager working in the same Department.
Manager can have many Employees working in the same Department.
Employee that doesn't have a Manager is a Manager.
This diagram illustrates the concept.
Before normalisation I end up with the following table.
After normalisation I end up with these tables.
However, there is still nothing stopping me from accidentally assigning a manager working in one department to an employee working in a different department in the EmployeeManager table.
One possible solution that I found was to put Department into the EmployeeManager table and define a reference integrity constraint so that {Manager, Department} refers {Employee, Department} in the EmployeeDepartment table.
However, for this to work doesn't {Manager, Department} have to be a candidate key? Is there a different design that can solve this?
Update
Ok to answer my first question, doesn't {Manager, Department} have to be a candidate key? It turns out that the {Manager, Department} in the EmployeeManager table doesn't have to be a candidate key or a unique key. It simply has to be a foreign key referencing the {Employee, Department} in the EmployeeDepartment table. The uniqueness of {Employee, Department} key isn't well defined and may differ between different engines. MySQL for example advises that the foreign keys reference only unique keys.
Additionally, MySQL requires that the referenced columns be indexed for performance reasons. However, the system does not enforce a requirement that the referenced columns be UNIQUE or be declared NOT NULL. The handling of foreign key references to nonunique keys or keys that contain NULL values is not well defined for operations such as UPDATE or DELETE CASCADE. You are advised to use foreign keys that reference only UNIQUE (including PRIMARY) and NOT NULL keys.
In my case it will work because Employee can only work in one Department however if the constraint chances to allow Employees work in many Departments it won't work because {Employee, Department} will no longer be unique.
It should work in all cases including if the constraint chances to allow Employees work in many Departments.
Is there a different design that can solve this? I also thought about replacing EmployeeDepartment with ManagerDepartment table with {Manager} as a primary key and going back to a previous EmployeeManager table with (Employee, Manager) columns. So now to find out which Department an Employee works you need to join EmployeeManager with ManagerDepartment table.
Do you see any bad practises or anomalies with this design?
Assuming all these columns are declared NOT NULL . . .
One possible solution that I found was to put Department into the
EmployeeManager table and define a reference integrity constraint so
that {Manager, Department} refers {Employee, Department} in the
EmployeeDepartment table.
Yes, add a column for "department" to the "EmployeeManager" table. But you need two foreign key constraints that overlap. (But see below . . .)
(manager, department) references EmployeeDepartment (Employee, Department)
(employee, department) references EmployeeDepartment (Employee, Department)
Since EmployeeDepartment.Employee is unique, the pair of columns EmployeeDepartment.Employee and EmployeeDepartment.Department is also unique. So you can declare "Employee" as a primary key, and also declare a unique constraint on the pair of columns (Employee, Department). Should the requirements change and allow employees to work in multiple departments, you can drop the single-column primary key. I would probably drop both the primary key and unique constraints, and create a new primary key constraint that included both columns, but all that's strictly necessary is to drop the primary key constraint.
In systems like yours, it's usually a good idea to have a table of managers, with the obvious foreign key references. Right now, if you delete the employee Will, you lose the fact that Steve is a manager.
I have got two questions when designing a database for a sales system.
Is it possible to have a isolated table, which means a table does not have relationship with all other tables?
How to solve the following issue:
Table: SalesOrderDetail, Table: InventoryTrans
Every record in SalesOrderDetail will insert into InventoryTrans, but not all records in InventoryTrans are from SalesOrderDetail. Because other tables may also insert records into the InventoryTrans.
Therefore, I want to add a reference column SalesOrderDetailID to InventoryTrans table, but does not specify FK constraint. Because if the record is not from SalesOrderDetail table, then the SalesOrderDetailID should be null.
Is this the right design?
Yes, you can have a table that has no foreign key references to other tables. A table that stores various configuration settings is probably the most common, but there are others.
The column InventoryTrans.SalesOrderDetailID can be a nullable foreign key reference. But you haven't provided enough detail to tell whether that's a good design decision. Making an educated guess, I'd say probably not. (Other kinds of transactions would probably benefit from a foreign key reference.)