1. Database Systems
Instructor Name:
Lecture-12

2. Contents Resolve Unary Relationship Resolve Ternary Relationship
Resolve One-to-Many Unary Relationship
Resolve Many-to-Many Unary Relationship
Resolve Ternary Relationship
Relational Model
Integrity Constraints
Well Structured Relations and Anomalies 2

3. Resolve Many-to-Many Unary Relationship
Two Entities are created
One for the Entity Type itself and other for Many-to-Many Relationship
The primary key of the associative relation consists of two attributes, both taking their values from the primary key of the other relation
Any non-key attribute of the relationship is included in the associative relation
{Represent in ERD} 3

4. Resolve Many-to-Many Unary Relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT relations 4

5. Resolve Ternary Relationship
It is best to convert a ternary relationship to an associative entity in order to represent participation constraints more accurately. Firstly, we create a new associative relation. The default primary key of this relation consists of the three primary key attributes for the participating entities (sometimes additional attributes are required to form a unique primary key)
These attributes then act in the role of foreign keys that reference the individual primary keys of the participating entity types . Any attributes of the associative entity type become attributes of the new relation 5

6. Resolve Ternary Relationship
The following Fig. Represents a PATIENT receiving a TREATMENT from a PHYSICIAN
The associative entity type PATIENT_Treatment has the attributes Date, Time and Results and values of these are recorded for each instance of patient treatment
The primary key attributes Patient_ID, Physician_ID and Treatment_Code become foreign keys in PATIENT_TREATMENT – these are components of its primary key but do not uniquely identify a given treatment, since a patient may receive the same treatment from the same physician on more than one occasion 6

7. Ternary Relationship with Associative Entity7

8. Resolve Ternary Relationship with Associative Entity8

9. The Relational Model Was introduced in 1970 by Dr. E. F. Codd (of IBM)
Commercial relational databases began to appear in the 1980s
Today relational databases have become the dominant technology for database management 9

10. The Relational Model
Data is represented in the form of tables, and the model has 3 components
Data structure – data are organised in the form of tables with rows and columns
Data manipulation – powerful operations (using the SQL language) are used to manipulate data stored in the relations
Data integrity – facilities are included to specify business rules that maintain the integrity of data when they are manipulated 10

11. Relational Definitions
A relation is a named, two-dimensional table of data
Every relation has a unique name, and consists of a set of named columns and an arbitrary number of unnamed rows
An attribute is a named column of a relation, and every attribute value is atomic.
Every row is unique, and corresponds to a record that contains data attributes for a single entity.
The order of the columns is irrelevant.
The order of the rows is irrelevant. 11

12. Integrity Constraints
These help maintain the accuracy and integrity of the data in the database
Domain Constraints - a domain is the set of allowable values for an attribute.
Domain definition usually consists of 4 components: domain name, meaning, data type, size (or length), allowable values/allowable range (if applicable)
Entity Integrity ensures that every relation has a primary key, and that all the data values for that primary key are valid. No primary key attribute may be null. 12

13. Entity Integrity
In some cases a particular attribute cannot be assigned a data value, e.g. when there is no applicable data value or the value is not known when other values are assigned
In these situations we can assign a null value to an attribute (null signifies absence of a value)
But still primary key values cannot be null – the entity integrity rule states that “no primary key attribute (or component of a primary key attribute) may be null 13

14. Referential Integrity
A Referential Integrity constraint is a rule that maintains consistency among the rows of two relations – it states that any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side. (Or the foreign key can be null) 14

15. Referential Integrity
How do you know if a foreign key is allowed to be null?
In this example, as each ORDER must have a CUSTOMER the foreign key of Customer_ID cannot be null on the ORDER relation
Whether a foreign key can be null must be specified as a property of the foreign key attribute when the database is designed 15

16. Referential Integrity
what happens to order data if we choose to delete a customer who has submitted orders? We may want to see sales even though we do not care about the customer anymore. Three choices are possible:
Restrict – don’t allow delete of “parent” side if related rows exist in “dependent” side, i.e. prohibit deletion of the customer until all associated orders are first deleted
Cascade – automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted, i.e. delete the associated orders, in which case we lose not only the customer but also the sales history
Set-to-Null – set the foreign key in the dependent side to null if deleting from the parent side - an exception that says although an order must have a customer_ID value when the order is created, Customer_ID can become null later if the associated customer is deleted [not allowed for weak entities] 16

17. Well Structured Relations
A well-structured relation contains minimal redundancy and allows users to insert, modify and delete the rows in a table without errors and inconsistencies
Redundancies in a table (such as more than one entry for each EMPLOYEE) may result in errors and inconsistencies (anomalies) when the table is updated
3 Types of anomaly are possible, insertion, deletion and modification anomalies 17

18. Insertion Anomaly Insertion anomaly – looking at EMPLOYEE:
A1 Fred Bloggs Info Sys Delphi
A1 Fred Bloggs Info Sys VB
Suppose that we want to add a new employee – the primary key for this relation is the combination of Emp_ID and Course_Title. Therefore, to insert a new row, the user must supply both these values (since primary keys cannot be null or nonexistent)
This is an anomaly, since the user should be able to enter employee data without supplying course data 18

19. Insertion Anomaly Insertion anomaly – looking at EMPLOYEE:
A1 Fred Bloggs Info Sys Delphi
A1 Fred Bloggs Info Sys VB
Suppose that we want to add a new employee – the primary key for this relation is the combination of Emp_ID and Course_Title. Therefore, to insert a new row, the user must supply both these values (since primary keys cannot be null or nonexistent)
This is an anomaly, since the user should be able to enter employee data without supplying course data 19

20. Deletion and Modification Anomaly
Suppose that the data for a particular employee are deleted from the table
This results in losing the information that this employee completed a particular course
This results in losing the information that this course was offered – deletion anomaly
If employee A1 changes the department they work in, this must be recorded in both the rows of the table otherwise the data will be inconsistent – modification anomaly 20

21. Resolve Anomalies
These anomalies indicate that EMPLOYEE is not a well-structured relation
We should use normalisation theory (discussed later) to divide EMPLOYEE2 into 2 relations, one called EMPLOYEE1 and one called EMP_COURSE that keeps track of the course details 21

22. Database Systems - Lab What are Constraints? Types of Constraints
Constraints are used to control, reference, verify (check) and restrict (allowable)
Types of Constraints
Column Level (inline)
Table Level (out-of-line) 22

23. Constraint Column Level Constraints Not Null Unique Check Default
Table Level Constraints
Primary Key (In parent table)
Foreign Key (In child table) 23

24. Creating Constraint Add Constraint at Table Level Creation
Change and Drop Constraint using ALTER TABLE command
Add Table Level Constraint
Modify Table and Column Level Constraints
Rename Table and Column Level Constraints
Drop Table and Column Level Constraints
Primary Key (In parent table)
Foreign Key (In child table) 24

25. Creating Constraint On delete Cascade On Delete Set Null
Enable/ Disable Constraints 25

26. Table with Constraints
CREATE TABLE Show ( show_id NUMBER NOT NULL, category_id NUMBER NOT NULL, act_id NUMBER NOT NULL, venue_id NUMBER NOT NULL, showdate DATE NULL, CONSTRAINT XPKShow PRIMARY KEY (show_id), CONSTRAINT FKShow_Cat FOREIGN KEY (category_id) REFERENCES Category, CONSTRAINT FKShow_Venue FOREIGN KEY (venue_id) REFERENCES Venue, CONSTRAINT FKShow_Act FOREIGN KEY (act_id) REFERENCES Act ); 26

27. Table with Constraints
CREATE TABLE Dept_tab ( Deptno NUMBER(3) CONSTRAINT Dept_pkey PRIMARY KEY, Dname VARCHAR2(15), Loc VARCHAR2(15), CONSTRAINT Dname_ukey UNIQUE (Dname, Loc), CONSTRAINT Loc_check1 CHECK (loc IN ('NEW YORK', 'BOSTON', 'CHICAGO'))); CREATE TABLE Emp_tab ( Empno NUMBER(5) CONSTRAINT Emp_pkey PRIMARY KEY, Ename VARCHAR2(15) NOT NULL, Job VARCHAR2(10), Mgr NUMBER(5) CONSTRAINT Mgr_fkey REFERENCES Emp_tab, Hiredate DATE, Sal NUMBER(7,2), Comm NUMBER(5,2), Deptno NUMBER(3) NOT NULL CONSTRAINT dept_fkey REFERENCES Dept_tab ON DELETE CASCADE); 27

28. ???????????????? 28

29. Erroneous Relationship
Receives or summarize the data, transfer, translate or calculate data 29