Database Management System Lecture Notes

===============================================================

CHAPTER TWO
Database System Architecture A Classification
of DBMS

Schemas, Instances, and Database State

In any data model, it is important to distinguish between the description of the database and the
database itself. The description of a database is called the database schema, which is specified
during database design and is not expected to change frequently.

The actual data in a database may change quite frequently. For example, the database shown in
changes every time we add a new student or enter a new grade. The data in the database at a
particular moment in time is called a database state or snapshot. It is also called the current set
of occurrences or instances in the database.

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:
 Record-based
 Physical
 Object-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

1 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================
 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)
 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
 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 that 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 no 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 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================

Employe
e Activity

Time card

DVANTAGES of Network Data Model:

 Network Model is able to model complex relationships and represents semantics
of add/delete on the relationships.
 Can handle most situations for modeling using record types and relationship
types.
 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
 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.
 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

3 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================
Alternative terminologies
Relation Table File
Tuple Row Record
Attribute Column Field

 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
 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

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]
 Is the collection of tables
- Each entity in one table
- 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

4 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================

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. The ENTITIES (persons, places, things etc.) which the organization has to deal
with. Relations can also describe relationships. 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:
A relation is a collection of tuple, each of which contains values for a fixed number of
attributes
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. The 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
• 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: an attribute that holds a single value for a single entity.

5 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================
- 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: an attribute that holds multiple values for a single entity.
- have more than one value
E.g. Address, dependent-name, telephone number
Person may have several college degrees
(3) Stored vs. Derived Attribute
• Stored: not possible to derive or compute
E.g. Name, Address
• Derived: an attribute that represents a value that is derived from the value of
a related attributes or set of attributes.
- The value may be derived (computed) from the values of other attributes.
E.g. - Age (current year – year of birth) can be derived from date 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
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:
 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)
3. 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)
4. 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

6 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================
 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:
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-NARY RELATIONSHIP: Tuples from arbitrary number of entity sets are
participating in a relationship.

7 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================

Cardinality of a Relationship
• Another important concept about relationship is the number of instances/tuples that can
be associated with a single instance from 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:
ONE-TO-ONE: one tuple is associated with only one other tuple.
A B
a b

a b

a b

a
b

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.
A B
a b

a b

a b

b
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
A B
a
b
a
b
a
b

a b
8 Compiled by Seada A. 2010
Database Management System Lecture Notes
===============================================================
E.g. Student – Course-as a student can take many courses and a single course can be
attended by many students.

5. 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.
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 tyapes 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.

9 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================
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 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.
Schemas and 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.
 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)

10 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================

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

2. Object Based Data Models

Object based data models use concepts such as entities, attributes, and relationships. An
entity is a distinct object (a person, place, concept, and event) in the organization that is
to be represented in the database. An attribute is a property that describes some aspect of
the object that we wish to record, and a relationship is an association between entities.

Some of the more common types of object based data model are:

• Entity-Relationship

• Object Oriented

• Semantic

• Functional

The Entity-Relationship model has emerged as one of the main techniques for modeling
database design and forms the basis for the database design methodology. The object
oriented data model extends the definition of an entity to include, not only the attributes
that describe the state of the object but also the actions that are associated with the object,
that is, its behavior. The object is said to encapsulate both state and behavior. Entities in
semantic systems represent the equivalent of a record in a relational system or an object
in an OO system but they do not include behavior (methods). They are abstractions ‘used
to represent real world (e.g. customer) or conceptual (e.g. bank account) objects. The
functional data model is now almost twenty years old. The original idea was to’ view the
database as a collection of extensionally defined functions and to use a functional
language for querying the database.

3. Physical Data Models

Physical data models describe how data is stored in the computer, representing
information such as record structures, record ordering, and access paths. There are not as
many physical data models as logical data models, the most common one being the
Unifying Model.

11 Compiled by Seada A. 2010

Database Management System Lecture Notes
===============================================================

THREE-SCHEMA ARCHITECTURE AND

DATA INDEPENDENCE
Three of the four important characteristics of the database approach, listed in Section
1J, are (1) insulation of program:; and data (program-data and program-operation
independence),
(2) support of multiple user views, and (3) use of a catalog to store the database
description (schema). In this section we specify an architecture for database systems,
called the three-schema architccture.i' that was proposed to help achieve and visualize
these characteristics. We then further discuss the concept of data independence.
2.2.1 The Three-Schema Architecture
The goal of the three-schema architecture, illustrated in Figure 2.2, is to separate the user
applications and the physical database. In this architecture, schemas can be defined at the
following three levels:
1. The internal level has an internal schema, which describes the physical storage
structure of the database. The internal schema uses a physical data model and describes
the complete details of data storage and access paths for the database.

12 Compiled by Seada A. 2010