Chapter Three

Relational Database Modeling

1
Building Blocks(1)
 Entities: Real world physical or logical object.
 Attributes: Properties used to describe each Entity
or real world object.
 Relationship: The association between the real
world objects (i.e. Entities.)
 Constraints: Rules that should be obeyed or
followed while manipulating the data.
2
 Building Blocks(2)
 The name given to an entity should always be a singular noun
descriptive of each item to be stored in it.
 Attributes - The items of information which characterize and
describe these entities
 Attributes are pieces of information about entities

 Attribute name: Should be explanatory words or phrases.

 In any business processing one object may be associated with

another object due to some event. Such kind of association is
what we call a relationship between entity objects. 3
 Types of Attributes
 Simple (atomic) Vs Composite attributes
 Simple : Contains a single value (not divided into sub
parts):example a student's phone number is an atomic value of 10
digits, age, gender.
 Composite: Divided into sub parts (composed of other attributes).
Eg. Address, Hobbies , name
 Single-valued Vs multi-valued attributes
 Single-valued : Have only single value (the value may change but
has only one value at one time): eg. A manufactured part can have
only one serial number, Name, Sex, Id. No., color of_eyes.
 Multi-Valued: Type of attribute that can have more than one value
at a time. Eg. multiple degrees, Address, dependent-name

4
 Cont…
Stored vs. Derived Attributes
Stored : not possible to derive or compute. E.g. Name, Address
Derived: The value may be derived (computed) from the values of
other attributes. Ex. Age (current year- year of birth), GPA (grade
point-credit hours)
Null Values: NULL applies to attributes which are not applicable
or which do not have values.
Value of a key attribute can not be null.

5
Degree of a Relationship
 Degree of a relationship is the number of entities
participating in relationship.

The number of participating entities



Unary/recursive relationship- records of a single



entity are related with each other.

6
 Degree of a Relationship
 Binary relationships- records of two entities are associated in a relationship.

 Ternary relationship - tuples of three entities are associated in relationship.

 n-nary relationship - tuples from arbitrary number of entity sets are

participating in a relationship
7
 Cardinality of a Relationship
(1)
Cardinality of a relationship refers to the number of tuples participating in
relationship.
 One-to-One: one tuple is associated with only one other tuple. Building -to-
Location  as a single building will be located in a single location and as a
single location will only accommodate a single Building.
 One-to-Many- one tuple can be associated with many other tuples, but not
the reverse. E.g. Department-to-Student  as one department can have
multiple students
• Many-to-One- many tuples are associated with one tuple but not the reverse.
E.g. Employee–to-Department: as many employees belong to a single
department.
• Many-to-Many- many tuple is associated with many other tuples.
• E.g. Student–to-Course as a student can take many courses and a single course can be
attended by many students. 8
Cardinality of a Relationship
(2)

9
 Relational Integrity
 Domain integrity: No value of the attribute should be beyond
the allowable limits.
 Entity integrity: In a base relation, no attribute of a Primary
Key can assume a value of NULL.
 Referential integrity: If a Foreign Key exists in a relation,
either the Foreign Key value must match a Candidate Key value
in its home relation or the Foreign Key value must be NULL.
 Enterprise integrity: Additional rules specified by the users or
database administrators of a database are incorporated. 10
 Types of Keys- Super key
 A set of one or more attributes that in group (collectively) can

identify an entity uniquely from the entity set.

 an attribute or set of attributes that uniquely identifies a tuple

within a relation.
 Eg. Employee(EmpID, EmployeeName, SSN, DeptID, DOB)

 {EmpID + EmployeeName}, {EmpID, DOB}, {SSN}, {EmpID}

 Super key stands for superset of a key.

 A Super Key is a set of one or more attributes that are taken

 Collectively and can identify all other attributes uniquely

11
Types of Keys- Candidate Key
(1)
 The candidate key is the sufficient and the necessary set of
attributes to distinguish an entity set.
 Are individual columns in a table that qualifies for
uniqueness of each row/tuple.
Employee(EmpID, EmpName, SSN, DeptID, DOB}= EmpID, SSN

 For a Primary Key and thus are Candidate keys.

 Are super keys for which no proper subset is a super key

 In other words candidate keys are minimal super keys

12
Types of Keys- Candidate Key
(2)
 Candidate key - an attribute or set of attributes that

uniquely identifies individual occurrences of an

entity type or tuple within a relation.
 A candidate key has two properties:

 Uniqueness
 Irreducibility

13
Types of Keys – Alternative
key
 Candidate column other than the Primary column,
like if EmployeeID is set for a PK then SSN would be
the Alternate key.
Employee(EmpID, EmpName, SSN, DeptID, DOB}=
SSN

14
Types of Keys - Composite key
Composite key: A candidate key that consists of two or
more attributes.
If a table do have a single column that qualifies for a
Candidate key, then you have to select 2 or more columns to
make a row unique.
 Like if there is no EmployeeID or SSN columns, then you can

make EmployeeName + DOB as Composite Primary Key.

But still there can be a narrow chance of duplicate rows
15
Employee(EmpID, EmpName, SSN, DeptID, DOB}
 Cont…

Score table: to save scores of the student for various

subjects.

In the above picture we have a score table which stores the

marks scored by a student in a particular subject. In this table
student_id and subject_id together will form the primary key,
hence a composite key.

16
Types of Keys - Primary key
(1)
 Primary key: the candidate key that is selected to identify
tuples uniquely within the relation. Can not null value.
 It is a candidate key that is chosen by the database designer
to identify entities with in an entity set.

Is the column you choose to maintain uniqueness in a table



at row level

17
Types of Keys - Primary key
(2)
 No two rows can have the same primary key value
 Every row must have a primary key value
 The primary key field cannot be null
 Value in a primary key column can never be
modified or updated, if any foreign key refers to that
primary key.

18
Types of Keys – Foreign Key
 Foreign key: an attribute, or set of attributes, within one
relation that matches the candidate key of some relation.
 A foreign key is a link between different relations to create
relationship or view.

19
Types of Keys – Unique Key
 Unique key is same as primary with the difference
being the existence of null.
 Unique key field allows one value as NULL value.

20
Relational Views (1)
 Relations are perceived as a table from the users’ perspective.
 There are two kinds of relation in relational database.
 Base (Named) and
 View (Unnamed) Relations.
 The basic difference is on how the relation is created, used and
updated:
 Base Relation: A named relation corresponding to an entity in
the conceptual schema, whose tuples are physically stored in
the database. 21
Relational Views (2)
 View (Unnamed Relation): A View is the dynamic result of

one or more relational operations operating on the base

relations to produce another virtual relation that does not
actually exist as presented.
 So a view is virtually derived relation that does not

necessarily exist in the database but can be produced upon

request by a particular user at the time of request.

22
Schema
 Database Schema (Intension): specifies name of relation and
the collection of the attributes (specifically the Name of
attributes).
Refer to a description of database (or intention)
Specified during database design
Should not be changed unless during maintenance

 Schema Diagrams: convention to display some aspect of a

schema visually.
 Schema Construct: refers to each object in the schema (e.g.
23
Instances
 Instance: is the collection of data in the database at a
particular point of time (snap-shot).

Also called State or Snap Shot or Extension of the
database.
 Refers to the actual data in the database at a specific
point in time
 State of database is changed any time we add, delete or

update an item.
 Valid state: the state that satisfies the structure and

constraints specified in the schema and is enforced by

DBMS.
24
Thanks !!!

25