0% found this document useful (0 votes)
19 views33 pages

Relational Model Keys

HshnsnsnsnsnsnsnsnsnnsnsbsbsbsbsbsbsbsbsnsbbshsshhshssjjssjjssjsnsjsnsnsshshsjsjsjsjsjsJVadbdbdndjdjdjdjdjdjdjsnzndjdjdhdhdhdhdbdbdbdbxhdueueejjdjdjjdjdjdjdjsbdbbsbsbsbdbsbdbdndndndjjddjjdjdjdjdjdjjdjdjdjdjdjd

Uploaded by

Mahesh Babu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views33 pages

Relational Model Keys

HshnsnsnsnsnsnsnsnsnnsnsbsbsbsbsbsbsbsbsnsbbshsshhshssjjssjjssjsnsjsnsnsshshsjsjsjsjsjsJVadbdbdndjdjdjdjdjdjdjsnzndjdjdhdhdhdhdbdbdbdbxhdueueejjdjdjjdjdjdjdjsbdbbsbsbsbdbsbdbdndndndjjddjjdjdjdjdjdjjdjdjdjdjdjd

Uploaded by

Mahesh Babu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 33

Relational

Model
Introduction
 Proposed by Edgar. F. Codd (1923-2003) in the
early seventies. [ Turing Award – 1981 ]
 Most of the modern DBMS are relational.
 Simple and elegant model with a mathematical
basis.
 Led to the development of a theory of data
dependencies and database design.
 Relational algebra operations –
crucial role in query optimization and execution.
 Laid the foundation for the development of
 Tuple relational calculus and then
 Database standard SQL
Relation
Scheme
 C o nsists o f re latio n name , and a se t o f
attributes or f ie ld names or column names. Each
attribute has an associated domain.
 Example:
student ( studentName : string,
rollNumber : string,
phoneNumber : integer,
Relation yearOfAdmission : integer,
name branchOfStudy : string )

Attribute domain
names s
 Domain – set of atomic (or indivisible ) values –
data type
Relation
Instance
 A f inite set of tuples constitute a relation instance.
 A tuple of relation with scheme R = (A1, A2, … ,
Am) is an ordered sequence of values
(v1,v2, ... ,vm) such that vi ∈ domain (Ai),
1≤ i ≤ m

student
studentName rollNumber
yearOf phoneNumber branch Of
Admission Study
Ravi Teja CS05B015 2005 9840110489 CS
Rajesh CS04B125 2004 9840110490 EC

No duplicate tuples ( or rows ) in a relation instance.


We shall later see that in SQL, duplicate rows would be allowed in
tables.
Another Relation
Example

enrollment (studentName, rollNo, courseNo,


sectionNo)

enrollment
studentName rollNumber courseNo sectionNo

Rajesh CS04B125 CS320 2


Rajesh CS04B125 CS370 1
2
Suresh CS04B130 CS320

Keys for a Relation
(1/2)
• Key: A set of attributes K, whose values uniquely identify
a tuple in any instance. And none of the proper subsets
of K has this property
Example: {rollNumber} is a key for student relation.
{rollNumber, name} – values can uniquely identify a
tuple
• but the set is not minimal
• not a Key
• A key can not be determined from any particular
instance data
 it is an intrinsic property of a scheme
 it can only be determined from the meaning of
attributes
Keys
• Let K  R
• K is a superkey of R if values for K are sufficient
to identify a unique tuple of each possible
relation r(R)
– by “possible r ” we mean a relation r that could exist
in the enterprise we are modeling.
– Example: {customer_name, customer_street} and
{customer_name}
are both superkeys of Customer, if no two customers
can possibly have the same name
• In real life, an attribute such as customer_id would be used
instead of customer_name to uniquely identify customers,
but we omit it to keep our examples small, and instead
assume customer names are unique.
Keys (Cont.)
• K is a candidate key if K is minimal
Example: {customer_name} is a candidate key
for Customer, since it is a superkey and no
subset of it is a superkey.
• Primary key: a candidate key chosen as the
principal means of identifying tuples within a
relation
– Should choose an attribute whose value never, or
very rarely, changes.
– E.g. email address is unique, but may change
Foreign Keys
• A relation schema may have an attribute that
corresponds to the primary key of another relation. The
attribute is called a foreign key.
– E.g. customer_name and account_number attributes of
depositor are foreign keys to customer and account
respectively.
– Only values occurring in the primary key attribute of the
referenced relation may occur in the foreign key attribute of the
referencing relation.
• Schema diagram
Keys for a Relation
(2/2)
 A relation can have more than one key.
 Each of the keys is called a candidate key
Example: book (isbnNo, authorName, title, publisher,
year) (Assumption : books have only one author )
Keys: {isbnNo}, {authorName, title}
 A relation has at least one key
- the set of all attributes, in case no proper subset is a key.
 Superkey: A set of attributes that contains any key as a
subset.
 A key can also be defined as a minimal superkey
 Primary Key: One of the candidate keys chosen for
indexing purposes ( More details later…)
Relational Database Scheme and Instance
Relational database scheme: D consist of a f inite no. of
relation schemes and a set I of integrity constraints.
Integrity constraints: Necessary conditions to be satisf ied
by the data values in the relational instances so that
the set
of data values constitute a meaningful database
• domain constraints
• key constraints
• referential integrity constraints
Database instance: Collection of relational instances
satisfying the integrity constraints.
Domain and Key
Constraints
• Domain Constraints: Attributes have associated domains
Domain – set of atomic data values of a specif ic type.
Constraint – stipulates that the actual values of an
attribute in any tuple must belong to the declared domain.

• Key Constraint: Relation scheme – associated keys


Constraint – if K is supposed to be a key for scheme R,
any relation instance r on R should not have two
tuples that have identical values for attributes in K.
Also, none of the key attributes can have null value.
Foreign
Keys
• Tuples in one relation, say r1(R1), often need to refer to
tuples in another relation, say r2(R2)
• to capture relationships between entities
• Primary Key of R2 : K = {B1, B2, …, Bj}
• A set of attributes F = {A1, A2, …, Aj} of R1 such that
dom(Ai) = dom(Bi), 1≤ i ≤ j and
whose values are used to refer to tuples in r2 is
called a foreign key in R1 referring to R2.

• R1, R2 can be the same scheme also.


• There can be more than one foreign key in a relation
scheme
Foreign Key –
Examples(1/2)
Foreign key attribute deptNo of course relation
refers to Primary key attribute deptID of
department relation

Course Department
courseId name credits deptNo deptId name hod phone

CS635 ALGORITHMS 3 1 1 COMPUTER CS01 22576235


SCIENCE
CS636 A.I 4 1
2 ELECTRICAL ES01 22576234
ES456 D.S.P 3 2 ENGG

ME650 AERO 3 3 3 MECHANICAL ME01 22576233


DYNAMIC ENGG
Foreign Key –
Examples(2/2)
It is possible for a foreign key in a relation
to refer to the primary key of the relation itself

An Example:

univEmployee ( empNo, name, sex, salary, dept, reportsTo)

reportsTo is a foreign key referring to empNo of the same


relation

Every employee in the university reports to some


other employee for administrative purposes
- except the vice-chancellor, of course!
Referential Integrity Constraint
(RIC)
• Let F be a foreign key in scheme R1 referring to scheme
R2 and let K be the primary key of R2.
• RIC: any relational instance r1on R1, r2 on R2 must be s.t
for any tuple t in r1, either its F-attribute values are
null or they are identical to the K-attribute values
of some tuple in r2.
• RIC ensures that references to tuples in r2 are for
currently existing tuples.
• That is, there are no dangling references.
Referential Integrity Constraint (RIC) -
Example
COURSE DEPARTMENT

courseId name credits deptNo deptId name hod phone

CS635 ALGORITHMS 3 1 1 COMPUTER CS01 22576235


SCIENCE
CS636 A.I 4 1
2 ELECTRICAL ES01 22576234
ES456 D.S.P 3 2 ENGG.

ME650 AERO 3 3 3 MECHANICAL ME01 22576233


DYNAMIC ENGG.

CE751 MASS 3 4
TRANSFER

The new course refers to a non-existent department


and thus violates the RIC
18
Integrity Rules
• Many RDBMs enforce integrity rules
automatically
• Safer to ensure that application design
conforms to entity and referential integrity rules

19
Example Relational
Scheme
student (rollNo, name, degree, year, sex, deptNo, advisor)
Here, degree is the program ( B Tech, M Tech, M S, Ph
D etc) for which the student has joined. Year is the
year of admission and advisor is the EmpId of a
faculty member identified as the student’s advisor.

department (deptId, name, hod, phone)


Here, phone is that of the department’s of fice.

professor (empId, name, sex, startYear, deptNo, phone)


Here, startYear is the year when the faculty member
has joined the department deptNo.
Example Relational
Scheme
course (courseId, cname, credits, deptNo)
Here, deptNo indicates the department that offers the
course.

enrollment (rollNo, courseId, sem, year, grade)


Here, sem can be either “odd” or “even” indicating the
two semesters of an academic year. The value of
grade will be null for the current semester and non
-null for past semesters.

teaching (empId, courseId, sem, year, classRoom)

preRequisite (preReqCourse, courseID)


Here, if (c1, c2) is a tuple, it indicates that c1 should be
successfully completed before enrolling for c2.
Example Relational
Scheme
student (rollNo, name, degree, year, sex, deptNo,
advisor)

department (deptId, name, hod, phone)

professor (empId, name, sex, startYear, deptNo,

phone) course (courseId, cname, credits, deptNo)


enrollment (rollNo, courseId, sem, year,
grade)
teaching (empId, courseId, sem, year,
classRoom)
preRequisite (preReqCourse,
courseID)
Example Relational Scheme with RIC’s
shown
student (rollNo, name, degree, year, sex, deptNo,
advisor)

department (deptId, name, hod, phone)

professor (empId, name, sex, startYear, deptNo,

phone) course (courseId, cname, credits, deptNo)

enrollment (rollNo, courseId, sem, year, grade)

teaching (empId, courseId, sem, year, classRoom)

preRequisite (preReqCourse, courseID)


Keys
• SuperKey
– a set of attributes whose values together uniquely
identify a tuple in a relation
• Candidate Key
– a superkey for which no proper subset is a superkey…a
key that is minimal .
– Can be more than one for a relation
• Primary Key
– a candidate key chosen to be the main key for the
relation.
– One for each relation
• Keys can be composite
Foreign Key
• a set of attributes in a relation that exactly
matches a (primary) key in another relation
– the names of the attributes don’t have to be the same
but must be of the same domain
– a foreign key in a relation A matching a primary key in a
relation B represents a
• many:one relationship between A and B

Student(studno,name,tutor,year)

Staff(lecturer,roomno,appraiser)
Referential Integrity
• Student(studno,name,tutor,year)
• Staff(lecturer,roomno,appraiser)

• CASCADE
– delete all matching foreign key tuples
eg. STUDENT
• RESTRICT
– can’t delete primary key tuple STAFF whilst a foreign key
tuple STUDENT matches
• NULLIFY
– foreign key STUDENT.tutor set to null if the foreign key
ids allowed to take on null
Entity Integrity and Nulls
No part of a key can be null
• Attribute values THREE categories of null values
1. Not applicable
– Atomic 2. Not known
3. Absent (not recorded)
– Known domain
– Sometimes can be null
STUDENT
The Data Dictionary and System
• Data dictionary
Catalog
– Provides detailed accounting of all tables found within the
user/designer-created database
– Contains (at least) all the attribute names and characteristics for
each table in the system
– Contains metadata: data about data
– Active & passive
• System catalog
– Contains metadata
– Detailed system data dictionary that describes all objects within the
database
• Data about table names, table’s creator, creation date, number of
columns in each table, data type of each column, index filenames,
index creators, authorized users and access privileges

28
30
The Data Dictionary and System
Catalog
• Homonym
– Indicates the use of the same name to label
different attributes
• Use C_NAME in a CUSTOMER table for customer
name and in a CONSULTANT table for consultant
name
• Synonym
– Opposite of a homonym
• Indicates the use of different names to describe
the same attribute e.g., CAR and AUTO
31
Codd’s Relational Database Rules
• In 1985, Codd published a list of 12 rules
to define a relational database system
– Products marketed as “relational” that did not
meet minimum relational standards
• Even dominant database vendors do not
fully support all 12 rules

32
33

You might also like