Chapter two

Relational Data Model

Cont…
 A relational model is a model that is
perceived by the user as table.
 Relation: Two dimensional table
◦ Stores information or data in the form of
tables (rows and columns)
◦ A row of the table is called tuple(equivalent to
record)
◦ A column of a table is called attribute(
equivalent to fields)
 Data value is the value of the Attribute
 Cont…
 The tables seem to be independent but are
related some how.
 No physical consideration of the storage is
required by the user
 Many tables are merged together to come
up with a new virtual view of the
relationship
Cont…
 The rows represent records (collections
of information about separate items)
 The columns represent fields (particular
attributes of a record)
 Conducts searches by using data in
specified columns of one table to find
additional data in another table
 Properties of Relational Databases
 Each row of a table is uniquely identified by
a PRIMARY KEY composed of one or
more columns
 Each tuple in a relation must be unique
 Group of columns, that uniquely identifies a
row in a table is called a CANDIDATE KEY
 ENTITY INTEGRITY RULE of the
model states that no component of the
primary key may contain a NULL value
 Cont…
 A column or combination of columns that
matches the primary key of another table is
called a FOREIGN KEY.
 The REFERENTIAL INTEGRITY RULE
of the model states that, for every foreign key
value in a table there must be a corresponding
primary key value in another table in the
database or it should be NULL.
 All tables are LOGICAL ENTITIES
 A table is either a BASE TABLES (Named
Relations) or VIEWS (Unnamed Relations)
Cont…
 Only Base Tables are physically stores
 VIEWS are derived from BASE TABLES with
SQL instructions like: [SELECT .. FROM ..
WHERE .. ORDER BY]
 Order of rows and columns is immaterial
 Entries with repeating groups are said to be
un-normalized
 Entries are single-valued
 Each column (field or attribute) has a distinct
name
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.
The ENTITIES
 The ENTITIES (persons, places, things etc.)
which the organization has to deal with.
 The name given to an entity should always
be a singular noun descriptive of each item
to be stored in it. E.g.: student NOT
students.
 Every relation has a schema, which
describes the columns, or fields
 The relation itself corresponds to our
familiar notion of a table
ATTRIBUTES
 The items of information which
characterize and describe these entities.
 Attributes are pieces of information
ABOUT entities.
 The analysis must of course identify those
which are actually relevant to the
proposed application
Cont…
 Attribute name (be explanatory words or
phrases)
 The domain from which attribute values
are taken (A DOMAIN is a set of values
from which attribute values may be
taken.)
◦ Each attribute has values taken from a
domain.
◦ For example, the domain of Name is string
and that for salary is real
 Cont…
 Whether the attribute is part of the entity
identifier (attributes which just describe an
entity and those which help to identify it
uniquely)
 Whether it is permanent or time-varying
(which attributes may change their values
over time)
 Whether it is required or optional for the
entity (whose values will sometimes be
unknown or irrelevant)
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
Cont…
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
 Cont…
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)
Cont…
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
RELATIONSHIPS
The RELATIONSHIPS between entities
which exist and must be taken into account
when processing information.
 One external event or process may affect
several related entities.
 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
Cont…
 Role names are different from the names
of entities forming the relationship: one
entity may take on many roles, the same
role may be played by different entities
 An important point about a relationship is
how many entities participate in it.
◦ The number of entities participating in a
relationship is called the DEGREE of the
relationship.
Cont…
 UNARY/RECURSIVE
RELATIONSHIP: Single entity
 BINARY RELATIONSHIPS: Two
entities associated
 TERNARY RELATIONSHIP: Three
entities associated
 N-NARY RELATIONSHIP: arbitrary
number of entity sets
Cont…
 The number of instances participating or
associated with a single instance from
another entity in a relationship is called the
CARDINALITY of the relationship.
1. ONE-TO-ONE, e.g. Building - Location,
2. ƒ
ONE-TO-MANY, e.g. hospital - patient,
3. ƒ
MANY-TO-ONE, e.g. Employee -
Department
4. ƒ
MANY-TO-MANY, e.g. Author - Book.
Cont…
 Relational Constraints/Integrity
Rules
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 be null
Cont…
 Referential Integrity: If a foreign key
exists in a relation, either the foreign key
value must match a candidate key in its
home relation or the foreign key value
must be null foreign key to primary key
match-ups
 Enterprise Integrity: Additional rules
specified by the users or database
administrators of a database are
incorporated
Key constraints
 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.
 A candidate key has two properties:
◦ Uniqueness
◦ Irreducibility
 If a candidate key consists of more than one
attribute it is called composite key.
Cont…
 Primary Key: the candidate key that is
selected to identify tuples uniquely within
the relation.
 The entire set of attributes in a relation can
be considered as a primary case in a worst
case.
 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 the view or the unnamed
relation
Relational languages and views
 The languages in relational database
management systems are the DDL and the
DML that are used to define or create the
database and perform manipulation on the
database.
 We have the two kinds of relation in
relational database.
 The difference is on how the relation is
created, used and updated
Cont…
Base Relation
 A Named Relation corresponding to an entity in
the conceptual schema, whose tuples are
physically stored in the database.
View
 Is the dynamic result of one or more relational
operations operating on the base relations to
produce another virtual relation.
 So a view 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.
 Purpose of a view
 Hides unnecessary information from users
 Provide powerful flexibility and security
 Provide customized view of the database for
users
 A view of one base relation can be updated.
 Update on views derived from various
relations is not allowed
 Update on view with aggregation and
summary is not allowed.
Schemas and Instances and
Database State
Schemas
 Schema describes how data is to be structured,
defined at set-up time, rarely changes
 Database Schema (intension): specifies name of
relation, plus name and type of each column.
◦ 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. STUDENT)
◦ E.g.: STUNEDT (FName,LName,Id,Year,Dept,Sex)
Three-Schema Architecture
Internal schema (or internal level)
 Internal schema describes the physical
storage, structure of the database (data
storage, access paths)
Conceptual schema (or conceptual level)
◦ describes the structure of the entire database
◦ hides the details of physical storage structures
◦ concentrates on the describing entities, data
types, relationships, operations, and constraints
Cont…
External schema (or view-level)
 includes a number of external schema or
user view
 each view describes subset of database
needed by a particular user
 High Level data model or an
implementation data model can be used
here
Instances
 Database state (snapshot or extension): is
the collection of data in the database at a
particular point of time (snap-shot).
◦ Refers to the actual data in the database at a
specific time
◦ State of database is changed any time we add
or delete a record
◦ Valid state: the state that satisfies the structure
and constraints specified in the schema and is
enforced by DBMS
Cont…
 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
Database design consists of several tasks:
 Requirements Analysis,
 Conceptual Design, and Schema
Refinement,
 Logical Design,
 Physical Design and
 Tuning (Modification)
The Three levels of Database Design
Conceptual Database Design
 Conceptual design is the process of
constructing a model of the information used
in an enterprise, independent of any physical
considerations.
◦ It is the source of information for the logical design
phase.
◦ Community User’s view
 After the completion of Conceptual Design
one has to go for refinement of the schema,
which is verification of Entities, Attributes, and
Relationships
Logical Database Design
 Logical design is the process of
constructing a model of the information
used in an enterprise based on a specific
data model (e.g. relational, hierarchical or
network or object), but independent of a
particular DBMS and other physical
considerations.
◦ Normalization process
◦ Discover new entities
◦ Revise attributes
Physical Database Design
 Physical design is the process of producing a
description of the implementation of the
database on secondary storage.
◦ defines specific storage or access methods used by
database
◦ Describes the storage structures and access
methods.
◦ Tailored to a specific DBMS system --
Characteristics are function of DBMS and
operating systems
◦ Includes estimate of storage space