9/28/2017

Last Lecture -Recap

• Types of DBMS
DATABASE INTEGRITY
CONSTRAINTS 1. Hierarchical
2. Network
3. Relational - RDBMS
Ivan Bamweyana
4. Object-oriented -
OODBMS
LSG 2102
5. Object-relational -
ORDBMS

Last Lecture -Recap Last Lecture -Recap

Integrity Constraints (IC) Integrity Constraints (IC)

• A set of rules to enforce that the data are and remain
consistent over time
• Rules that constrain or govern how database data is
inserted or manipulated
• ICs are specified when schema is defined (there is no data
yet)
• They are included when the table is created and they take
on different nature;
• Static Integrity Constraint = rule that the database instance
must obey at all times.
• Conditions that involve facts of only one state of the
database. E.g. HoD should be from within the department
• Dynamic constraints are conditions that involve facts of
two or more states of the DB. They take into account the
sequences of states that describe the dynamic behaviour
of the DB.
• E.g. All new employees are assigned to some department
within 30 days
• ICs are checked when database state is modified
• A valid relation / database instance satisfies all specified
ICs

1
 9/28/2017

Integrity Constraints Integrity Constraints

• Implicit ICs – are integrated in the data model
(often implied ) • There are three main types of constraints in the relational
 For the RM these are model:
Key integrity (also called entity integrity constraints) • Key constraints
Tuple integrity
• Entity integrity constraints
Referential integrity (Foreign Key constraint)
• Referential integrity constraints
• Explicit (User defined) Constraints – must be
explicitly stated by the DB designer and further • Domain constraint
action must be taken to ensure their enforcement, • Unique constraint
either through:
 Roll-back – push back – e.g. re-enter values
 Triggers NB-Every value in a tuple must be from the domain of its
 Explicit transaction checks (like queries) attribute (or it could be null, if allowed for that attribute
• Deduced constraints – are a logical
consequence of combinations of the above and
therefore need not be checked

Keys Constraints Type of Keys

• Unique Keys
 Candidate
• A key is a combination of one or more columns that is used
 Primary
to identify rows in a relation
 Alternate
• Each row in a table must be uniquely identifiable  Surrogate
• The role of the key to be able to determine particulars of A if • Foreign Key
B is known. E.g. If you know the value of attribute A • Composite Key
(Student number), you can determine the value of attribute
• Secondary Key
B (Student name)
http://rdbms.opengrass.net/2_Database%20Design/2.1_Ter
msOfReference/2.1.2_Keys.html

Unique Keys: Candidate Unique Keys: Primary/ Alternate

• A candidate key is an attribute or minimal set of attributes
that serves to uniquely identify each (single) row /tuple of
the relation.
• There may be several candidate keys for a relation
• E.g. Stu_No, Stu_email… both are candidates, so pick one,
otherwise not minimal set
• Book_name, Author, Publication_date…. No subset of
these would work to uniquely identify each row
• One candidate key is usually chosen as the primary key;
others become alternate keys
• Primary key is a column or attribute that is used to
uniquely identify a row/tuple. Each value of this column is
unique
• The primary key may be a composite key
• There is only one primary key per relation/table

2
 9/28/2017

Unique Key: Surrogate Foreign Key

• A column in a table whose values must be listed in a
• A surrogate key or artificial primary key is an artificial
column added to a relation to serve as a primary key (when primary key of another table;
it is difficult to find a natural attribute to identify a record) • Provides a link to information in another relation
• Can be • Important for referential integrity
 Make one’s own
 generated by DBMS – often generated based on system clock – fairly
meaningless to users Composite Key
 Oracle (ORDBMS) – “Create sequence, CustomerID increment by 1 start
with 1000;” • A key that contains two or more attributes
…
(columns)
• All the key types may be composite keys
• Example: (BookName, Author,
PublicationDate)

Secondary Key Entity Integrity

• No attribute of primary key will contain a null value. If a
• A key that is used for data retrieval purposes
relation have a null value in the primary key attribute,
then uniqueness property of the primary key cannot be
• E.g. Data retrieval for a relation STUDENT can be
maintained. Consider the example below-
facilitated when the STU_LNAME and STU_PHONE are
used, in this case, STU_NUM is PK and STU_LNAME+
STU_PHONE is secondary key
• A secondary key may not necessarily yield a unique
result

Referential Integrity
• Applies to Foreign Keys
• If all foreign key constraints are enforced, referential integrity is
achieved, i.e. there are no ‘dangling references’ in the database
• if a foreign key in Table 1 refers to the Primary Key of Table 2,
then every value of the Foreign Key in Table 1 must be null or
be available in Table 2. For example,
Referential Integrity
• FK’s prevent accidental deletion
 Once defined, your DBMS does not allow the deletion of rows that
have related rows in other tables.
 E.g. can’t delete a customer (Customer ID) with associated orders;
 Must delete orders first (attend to them) and then the customer.

3
 9/28/2017

Enforcing Referential integrity Enforcing Referential integrity

• You should not be allowed to assign a grade
to a student not already in the student table!
• Consider Student and Enrolled; sid in Enrolled is a foreign
key that references the student in Student
• What should be done if an enrolled tuple with non existent
sid is inserted? (Reject it! – Roll back)
• What should be done if a Student tuple is deleted?
 Also delete all Enrolled tuples that refer to it, or
 Disallow deletion of that tuple if it is refered to, or

 Set sid in Enrolled tuples that refer it to null.

• Similar if primary key in Student tuple is updated.
• Vice versa, what if an Enrolled tuple is deleted, or a Student
tuple inserted?

Domain Constraints Domain Constraints

• The domain of an attribute is a defined set of its allowable • Domain Constraints specifies that what set of values an
values. Includes: attribute can take. Value of each attribute X must be an
 Logical description (meaning)
atomic value from the domain of X.
 Physical description (domain definition)
The data type associated with domains include integer,
• Example: STATION_MASTER_ID attribute:
character, string, date, time, currency etc. An attribute
 Logical: What is it for? Does it have to meet rules?
value must be available in the corresponding domain.
 Physical: What sort of data: Integer, text string, …?
Consider the example below –
Attribute Meaning Domain Definition
Station_master_id Uniquely identifies the Character, length 7
station master
• Such a list of names or range of numerical numbers is
called the permissible values of a domain
• Since this permissible values limit what can be stored in a
table, they are called the domain constraints of the
database

Unique Constraints
Unique Constraints
• Ensure all data in a column or set of columns is unique; • A relation is defined as a set of tuples. All tuples or all
• Example of (Stu-No and Reg-No) rows in a relation must be unique or distinct. Suppose if in
• Similar to PK.s but: a relation, tuple uniqueness constraint is applied, then all
 Can contain null the rows of that table must be unique i.e. it does not
 A table can have several UC’s, but only one PK; contain the duplicate values. For example,
 Can be modified or updated
 Cannot be used to define FK’s.