Database Systems

Instructor Name:
Lecture-12
 Contents

 Resolve Unary 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
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
Resolve Many-to-Many Unary Relationship

(a) Bill-of-materials
relationships (M:N)

(b) ITEM and

COMPONENT
relations
4
 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
 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
Ternary Relationship with Associative Entity

7
Resolve Ternary Relationship with Associative
Entity

8
 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
 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
 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
 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
 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
 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
 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
 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
 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
 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
 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
 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
 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
 Database Systems - Lab

 What are Constraints?

 Constraints are used to control, reference, verify (check) and
restrict (allowable)
 Types of Constraints
 Column Level (inline)
 Table Level (out-of-line)

22
 Constraint

 Column Level Constraints

 Not Null
 Unique
 Check
 Default
 Table Level Constraints
 Primary Key (In parent table)
 Foreign Key (In child table)

23
 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
 Creating Constraint

 On delete Cascade
 On Delete Set Null
 Enable/ Disable Constraints

25
 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
 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
 Erroneous Relationship

 Receives or summarize the data, transfer, translate or calculate data

29