Chapter two: Data Model

2.1 Classification of data models

A specific DBMS has its own specific Data Definition Language, but this
type of language is too low level to describe the data requirements of an
organization in a way that is readily understandable by a variety of
users.
We need a higher-level language. Such a higher-level is called data-
model.
Data Model: a set of concepts to describe the structure of a database
and certain constraints that the database should obey.
A data model is a description of the way that data is stored in a
database. Data model helps to understand the relationship between
entities and to create the most effective structure to hold data.
Data Model is a collection of tools or concepts for describing
Data
Data relationships
Data semantics
Data constraints
The main purpose of Data Model is to represent the data
in an understandable way.
Categories of data models include:
Object-based
Record-based
Physical-based
Record-based Data Models
Consist of a number of fixed format records. Each record type defines a
fixed number of fields; each field is typically of a fixed length.
Hierarchical Data Model
Network Data Model
Relational Data Model
1. Hierarchical Model
• The simplest data model
• Record type is referred to as node or segment
• The top node is the root node
• Nodes are arranged in a hierarchical structure as sort of
upside- down tree
• A parent node can have more than one child node
• A child node can only have one parent node
• The relationship between parent and child is one-to-many
• Relation is established by creating physical link between
stored records (each is stored with a predefined access path
to other records)

1
 • To add new record type or relationship, the database must
be redefined and then stored in a new form.

Department

Employee
Job

Time Card
Activity

ADVANTAGES of Hierarchical Data Model:

Hierarchical Model is simple to construct and operate on
Corresponds to a number of natural hierarchically organized
domains
- e.g., assemblies in manufacturing, personnel
organization in companies
8 Language is simple; uses constructs like GET, GET UNIQUE,
GET NEXT, GET NEXT WITHIN PARENT etc.

DISADVANTAGES of Hierarchical Data Model:

Navigational and procedural nature of processing
Database is visualized as a linear arrangement of records
Little scope for "query optimization"

2. Network Model
• Allows record types to have more than one parent
unlike hierarchical model
• A network data models sees records as set members
• Each set has an owner and one or more members
• Allow many to many relationship between entities
• Like hierarchical model, network model is a collection of physically
linked records.
• Allow member records to have more than one owner

Department Job

2
 Employee
Activity

Time Card

ADVANTAGES of Network Data Model:

8 Network Model is able to model complex relationships and
represents semantics of add/delete on the relationships.
8 Can handle most situations for modeling using record
types and relationship types.
8 Language is navigational; uses constructs like FIND, FIND
member, FIND owner, FIND NEXT within set, GET etc.
Programmers can do optimal navigation through the
database.

DISADVANTAGES of Network Data Model:

Navigational and procedural nature of processing
8 Database contains a complex array of pointers that thread
through a set of records.
Little scope for automated "query optimization”

3. Relational Data Model

• Developed by Dr. Edgar Frank Codd in 1970 (famous
paper, 'A Relational Model for Large Shared Data Banks')
• Terminologies originates from the branch of mathematics
called set theory and relation
• Can define more flexible and complex relationship
• Viewed as a collection of tables called “Relations”
equivalent to collection of record types
• 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
• Records are related by the data stored jointly in the fields of
records in two tables or files. The related tables contain
information that creates the relation
• The tables seem to be independent but are related some how.

3
• 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

Alternative terminologies
Relation Table File
Tuple Row Record
Attribut
e Column Field

• The rows represent records (collections of information

about separate items)
• The columns represent fields (particular attributes of a record)
• Conduct searches by using data in specified columns of one table
to find additional data in another table
• In conducting searches, a relational database matches
information from a field in one table with information in a
corresponding field of another table to produce a third table that
combines requested data from both tables

2.2 Relational Data Model

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.
• A column or combination of columns that matches the primary
key of another table is called a FOREIGN KEY. Used to cross-
reference tables.
• 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)
• Only Base Tables are physically stores
• VIEWS are derived from BASE TABLES with SQL
instructions like: [SELECT .. FROM .. WHERE .. ORDER BY]

4
 • Is the collection of tables
o Each entity in one table
o Attributes are fields (columns) in table
• 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
• All values in a column represent the same attribute and
have the same data format

Building Blocks of the Relational Data Model

The building blocks of the relational data model are:
¾ 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.

1. ENTITIES (Person, places, thing 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.
 Existence Dependency: the dependence of an entity on the
existence of one or more entities.
 Weak entity : an entity that can not exist without the entity
with which it has a relationship – it is indicated by a double
rectangle

2. 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. Attributes will give rise to
recorded items of data in the database
At this level we need to know such things as:
• 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

5
 • 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
(1) 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
(2)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
(3)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) (4) 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
Entity versus Attributes
When designing the conceptual specification of the database, one
should pay attention to the distinction between an Entity and an
Attribute.
Consider designing a database of employees for an organization:

6
Should address be an attribute of Employees or an entity (connected to
Employees by a relationship)?
 If we have several addresses per employee, address must be an
entity (attributes cannot be set-valued/multi valued)
 If the structure (City, Woreda, Kebele, etc) is important, e.g. want
to retrieve employees in a given city, address must be
modeled as an entity (attribute values are atomic)

3. The RELATIONSHIPS between entities which exist and must be

taken into account when processing information. 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.
• 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
• 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
• For each RELATIONSHIP, one can talk about the number of
entities and the number of Tuples participating in the association.
These two concepts are called DEGREE and CARDINALITY
of a relationship respectively.

Degree of a Relationship
• 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.
• Among the Degrees of relationship, the following are the basic:
O UNARY/RECURSIVE RELATIONSHIP: Tuples/records of
a Single entity are related withy each other.
O BINARY RELATIONSHIPS: Tuples/records of two
entities are associated in a relationship
O TERNARY RELATIONSHIP: Tuples/records of three
different entities are associated
o And a generalized one:
N-NARY RELATIONSHIP: Tuples from
arbitrary numbers of entity sets are participating in
a relationship.
Cardinality of a Relationship
• Another important concept about relationship is the number of
instances/tuples that can be associated with a single instance from

7
 one entity in a single relationship. The number of
instances participating or associated with a single instance from an
entity in a relationship is called the CARDINALITY of the
relationship. The major cardinalities of a relationship are:
o 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.
o 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.
o 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.
o 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.
4. 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 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
• Key constraints
If tuples are need to be unique in the database, and then we
need to make each tuple distinct. To do this we need to have
relational keys that uniquely identify each relation.
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.

8
 A candidate key has two properties:
1. Uniqueness
2. Irreducibility
If a super key is having only one attribute, it is
automatically a Candidate key.
If a candidate key consists of more than one
attribute it is called Composite Key.
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 Views
Relations are perceived as a Table from the users’ perspective. Actually,
there are two kinds of relation in relational database. The two
categories or types of Relations are Named and Unnamed Relations.
The basic difference is on how the relation is created, used and
updated:
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. 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. The virtual table or relation can be
created from single or different relations by extracting some
attributes and records with or without conditions.
Purpose of a view
¾ Hides unnecessary information from users: since only part of the
base relation (Some collection of attributes, not necessarily all) are to
be included in the virtual table.
¾ 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: each users are
going to be interfaced with their own preferred data set and

9
 format by making use of the Views.
¾ A view of one base relation can be updated.
¾ Update on views derived from various relations is not
allowed since it may violate the integrity of the database.
¾ Update on view with aggregation and summary is not
allowed. Since aggregation and summary results are
computed from a base relation and does not exist actually.

2.3 Schemas, Instances and 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
two components are 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
Schema describes how data is to be structured, defined at
setup/Design time (also called "metadata")
Since it is used during the database development phase,
there is rare tendency of changing the schema unless there
is a need for system maintenance which demands change to
the definition of a relation.
z 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. STUDENT)
E.g.: STUNEDT (FName,LName,Id,Year,Dept,Sex)
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.

10
 ¾ 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 .

11