Relational Data Model

Chapter Two
 Important terms
• Relation: a table with rows and columns
• Attribute: a named column of a relation
• Domain: a set of allowable values for one or more attributes
• Tuple: a row of a relation
• Degree: the degree of a relation is the number of attributes it
contains
Unary relation, Binary relation, Ternary relation, N-ary
relation
• Cardinality: of a relation is the number of tuples the relation
has
• Relational Database: a collection of normalized relations with
distinct relation names.
 Important terms…
• Relation Schema: a named relation defined by a set of
attribute-domain name pair
Let A1, A2...........An be attributes with domain D1, D2 ………,Dn.
Then the sets {A1:D1, A2:D2… An:Dn} is a Relation Schema.
e.g. Student (studentId char(10), studentName char(50), DOB
date) is a relation schema for the student entity
• Relational Database schema: a set of relation schema each
with distinct names.
Suppose R1, R2,……, Rn is the set of relation schema in a
relational database then the relational database schema (R)
can be stated as
R={ R1 , R2 ,……., Rn}
 Properties of Relational Databases
• Each relation has a distinct name
• Each tuple in a relation must be unique.
• All tables are LOGICAL ENTITIES
• Each cell of a relation contains exactly one atomic (single)
value.
• Each column (field or attribute) has a distinct name.
• The values of an attribute are all from the same domain.
• A table is either a BASE TABLES (Named Relations) or
VIEWS (Unnamed Relations)
• Only Base Tables are physically stored
• Order of rows and columns is immaterial
• Entries with repeating groups are said to be un-normalized
 Building Blocks of the Relational Data Model

• Entities: real world physical or logical object

• Attributes: properties used to describe each
Entity or real world object.
• Relationship: the association between Entities
• Constraints: rules that should be obeyed
while manipulating the data.
 Building Blocks of the Relational Data Model

1. The ENTITIES
– Entities are persons, places, things etc. which the
organization has to deal with.
– Described by a singular noun name
E.g. : student NOT students.
– Alternative terminology is relation or table
– A relation is a collection of tuples, each of which
contains values for a fixed number of attributes
• Strong entity : an entity that do not require the
existence of other entities to exist.
• Weak entity : an entity that can not exist without
the entity with which it has a relationship
Building Blocks of the Relational Data Model

2. The ATTRIBUTES –
– the items of information which characterize and
describe these entities.
– are pieces of information ABOUT entities.
– Attributes will give rise to recorded items of
data in the database
– Attribute name should be self explanatory
 Types of Attributes
Simple (atomic) Vs Composite attributes
• Simple : contains a single value (not divided into sub
parts)
E.g. Age, gender
• Composite: Divided into sub parts (composed of other
attributes)
E.g. Name, address

Single-valued Vs multi-valued attributes

• Single-valued : have only single value(the value may
change but has only one value at one time)
E.g. Name, Sex, Id. No. color_of_eyes
• Multi-Valued: have more than one value
E.g. Address, dependent-name
Person may have several college degrees
 Types of Attributes…
Stored vs. Derived Attribute
• Stored : not possible to derive or compute
E.g. Name, Address
• Derived: The value may be derived (computed) from the values of
other attributes.
E.g. Age (current year – year of birth)
Length of employment (current date- start date)
Profit (earning-cost)
G.P.A (grade point/credit hours)
Null Values
• NULL applies to attributes which are not applicable or which do not
have values.
• You may enter the value NA (meaning not applicable)
• Value of a key attribute can not be null.

• Default value - assumed value if no explicit value

 Building Blocks of the Relational Data Model

3. The RELATIONSHIPS
– Is a kind of association that exist between two or
more entities due to some event
– One external event or process may affect several
related entities in a r/ship
– Related entities require setting of LINKS from one
part of the database to another.
– A relationship should be named by a word or
phrase which explains its function
 Degree of a Relationship
• Refers to the number of entities participating in a
relationship
• Basic kinds of relationship:
– UNARY/RECURSIVE RELATIONSHIP: Tuples/records of a
Single entity are related withy each other.
– BINARY RELATIONSHIPS: Tuples/records of two entities
are associated in a relationship
– TERNARY RELATIONSHIP: Tuples/records of three
different entities are associated
– And a generalized one:
• N-ARY RELATIONSHIP: Tuples from arbitrary number of entity
sets are participating in a relationship.
 Cardinality of a Relationship
• Refers to the number of instances participating
or associated with a single instance from an
entity in a relationship.
• The major cardinalities of a relationship are:
– ONE-TO-ONE: one tuple is associated with only one
other tuple.
• E.g. Building – 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-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 – Department: as many employees belong to a single
department.
– MANY-TO-MANY: one tuple is associated with many other
tuples and from the other side, with a different role name
one tuple will be associated with many tuples
• E.g. Student – Courseas a student can take many courses and a
single course can be attended by many students.

• However, the degree and cardinality of a relation are

different from degree and cardinality of a relationship.
Building Blocks of the Relational Data Model…

4. Key constraints
• Tuples need to be unique in the database
Common keys
• Super Key: an attribute or set of attributes that uniquely
identifies a tuple within a relation.
• Candidate Key: a super key such that no proper subset of
that collection is a Super Key within the relation.
• Primary Key: the candidate key that is selected to identify
tuples uniquely within the relation.
• 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 a
view or an unnamed relation
 Integrity
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
 Relational Views
• Relations are perceived as a Table from the users’ perspective.
1. Base Relation
– A Named Relation corresponding to an entity in the conceptual
schema, whose tuples are physically stored in the database.
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.
– a view is virtually derived relation that does not necessarily
exist in the database
• Purpose of a view
– Hides unnecessary information from users
– Provide powerful flexibility and security : since unnecessary
information will be hidden from the user there will be some
sort of data security.
– Provide customized view of the database for users
– A view of one base relation can be updated.
 Schemas and Instances & Database State

• When a database is designed using a Relational data

model, all the data is represented in a form of a table.
• In such definitions and representation, there are two
basic components of the database. The definition of
the Relation or the Table and the actual data stored in
each table.
• The data definition is what we call the Schema or the
skeleton of the database and
• the Relations with some information at some point in
time is the Instance or the flesh of the database.
 Schemas and Instances & Database State…
Schemas
• Schema describes how data is to be structured, defined at
setup/Design time (also called "metadata")
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
– Visual representation of the database schema
Schema Construct
– refers to each object in the schema (e.g. STUDENT)
• E.g.: STUNEDT (FName,LName,Id,Year,Dept, Sex)
 Schemas and Instances & Database State…
• 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
• Since Instance is actual data of database at some point in
time, changes rapidly
• To define a new database, we specify its database schema to
the DBMS (database is empty)
• database is initialized when we first load it with data
 Database design
conceptual design (chap 3)
Logical design (chap 4)
Physical design (chap 5)