Database Management System

KCS-501

UNIT-2
 RDBMS
• Most popular database system.

• Simple and sound theoretical basis.

• Developed by E F Codd in the early 1970's.

•The model is based on tables, rows and columns and the

manipulation of data stored within.

• Relational database is a collection of these tables.

• First commercial system: MULTICS in 1978.

• Has overtaken Hierarchical and Network models.

• Main feature: Single database can be spread across

several tables.

•Examples include: Oracle, IBM's DB2, Sybase, MySQL & Microsoft

 Relational Database Model
Terminology
• Relation is a table or flat file with columns and rows which has certain properties
• A tuple is a row of a relation and represents an instance of a relation
• An attribute is a named column of a relation
• A domain is the set of allowable values for one or more attributes
• The degree of a relation is the number of attributes it contains
• The cardinality of relation is the number of tuples it contains

Film Attributes

Film Number Title Director Country Year Genre

0.05 Reservoir Dogs Tarantino USA 1992 Crime

0.06 Pulp Fiction Tarantino USA 1994 Crime

0.08 Trainspotting Boyle UK 1996

1.09 Internal Affairs Wai-Keung China 2002 Crime

1.11 Snakes on a Plane Ellis USA 2006 Disaster

Relational Model
• A particular way of structuring data (relations)
• Simple
• Mathematically based
• Expressions (queries) can be analyzed by DBMS
• Transformed to equivalent expressions automatically (query
optimization)
• Optimizers have limits (=> programmer
needs to know how queries are evaluated
and optimized)

4
Relation Instance
• Relation is a set of tuples
• Tuple ordering immaterial
• No duplicates
• Cardinality of relation = number of tuples
• All tuples in a relation have the same structure;
constructed from the same set of attributes
• Attributes named (=> ordering immaterial)
• Value of an attribute drawn from the attribute’s domain
• Degree of a relation = number of attributes

5
Relation Instance (Example)

Id Name Address Status

1111111 John 123 main freshman

2345678 Mary 456 cedar sophmore

4433322 Art 77 so. 3rd senior

7654321 Pat 88 no. 4th sophmore

Student
6
Differences between DBMS
and RDBMS

DBMS

• Data is stored in a single large table

• Single record modification affects the whole database

RDBMS (Codd 1980)

• Database is 'broken down' into smaller pieces

• The changes will not affect the entire database
Differences continued…..

Example – Landlord to the same tenant of four different properties

• DBMS – In this case you would have to enter the tenants information for
each property (remember the tenant is the same, so time is wasted), as
well as the information about the property itself.

Property no. Tenant Tenants Tenants Contact

t D/O/B

1North Street Ben Dover 01/01/1970 07000123456

1North Street Ben Dover 01/01/1970 07000123456

• The incorporation of „KEY‟ fields can help to save time and reduce the
chance of errors from occurring upon the inputting of information into the
database
Differences continued…..

• Enter RDBMS……

• There needs to be the introduction of 'KEY' fields which allows more immediate
access to what you are looking for. For example „tenant number' would be a key field
and this would lead to all the information about that tenant being in one place.

• Other 'KEY' fields could be introduced for other 'OBJECTS' (data files) of the
tenancies which leads to 'relationships' being formed. For example two of the objects
would be; tenant and property. The 'KEY' fields can be displayed by underlining them;

OBJECT FIELDS

TENANT - (Tenant Number, Tenant Name, Tenant Contact Details… etc)

PROPERTY - (Property Number, Property Name, Property Address)

• The idea of relationships comes from being able to input two or more „KEY‟ fields into
the system and being able to find out exactly what you want.

• So by creating 'KEY' fields you can find certain information by searching through that
'KEY' field. This means that the input of duplicate data is not required constantly and
you can find what you are looking for easier through objects and fields.
 12 Rules….
• Rule 0: The system must qualify as relational, as a database, and as a
management system
• Rule 1: The information rule:
• Rule 2: The guaranteed access rule:
• Rule 3: Systematic treatment of null values:
• Rule 4: Active online catalogue based on the relational model:
• Rule 5: The comprehensive data sublanguage rule: (fix language SQL)
• Rule 6: The view updating rule: (account, sales, manager)
• Rule 7: High-level insert, update, and delete:
• Rule 8: Physical data independence: (structure, location, access)
• Rule 9: Logical data independence: (col/table add/break)
• Rule 10: Integrity independence:
• Rule 11: Distribution independence: (user unaware about distribution)
• Rule 12: The non-subversion rule: (no sublanguage)
Integrity Constraints
• Part of schema
• Restriction on state (or sequence of states) of
data base
• Enforced by DBMS
• Intra-relational - involve only one relation
• Part of relation schema
• e.g., all Ids are unique
• Inter-relational - involve several relations
• Part of relation schema or database schema

11
Types of Integrity Constraint
 Entity Integrity Constraint
Entity integrity is concerned with ensuring that each
row of a table has a unique and non-null primary key
value; this is the same as saying that each row in a
table represents a single instance of the entity type
modeled by the table.
Example:

13
Referential Integrity Constraint

Referential integrity is a relational database concept,

which states that table relationships must always be
consistent. In other words, any foreign key field must
agree with the primary key that is referenced by the
foreign key. Thus, any primary key field changes must
be applied to all foreign keys, or not at all. The same
restriction also applies to foreign keys in that any
updates (but not necessarily deletions) must be
propagated to the primary parent key.
EXAMPLE : Referential Integrity Constraint
Key Constraint
• Values in a column (or columns) of a relation are
unique: at most one row in a relation instance
can contain a particular value(s)
• Key - set of attributes satisfying key constraint
• e.g., Id in Student,
• e.g., (StudId, CrsCode, Semester)

16
Key Constraint (con’t)
• Minimality - no subset of a key is a key
• (StudId, CrsCode) is not a key of Transcript
• Superkey - set of attributes containing key
• (Id, Name) is a superkey of Student
• Every relation has a key
• Relation can have several keys:
• primary key (Id in Student) – (cannot be null)
• candidate key ((Name, Address) in Student)

17
Domain Constraint
• Domain constraint ensures that the value associated
with an attribute is justifying its domain.
• Whenever we declare any relation to the database
while declaring its attribute we specify a particular
domain for each attribute.
• There are three constraints which we can study
under domain constraint.
• not null constraint
• default constraint
• check clause constraint
18
 Specifying Domain Constraint
• The domain of an attribute specifies all the possible values that
attribute can hold.
• Declaring the domain of an attribute it acts as a constraint on that
attribute which specifies the possible values that it can take.
• create table Student
(Student_id varchar (5) , name varchar (20) not null,
depart_name varchar (20),
primary key (Student_id),
foreign key(depart_name) references Department);