FUNDAMENTAL

S OF DATABASE
SYSTEMS 1
Tutorial session
For
exit exam preparation
OBJECTIVES OF THE COURSE
 Understand what database is, database system and DBMS
 Differentiate database system from file system
 Identify the pros and cons of manual approach, file based
approach and database approach
 Understand the basic principles of database design systems
using different database models
 Appreciate the use of database system in the real world.

2
 OBJECTIVES … CONT’D …
 Design different types of databases
 Understand database normalization & functional dependency
 Understand the principles of relational database management systems
and their languages
 Understand file organizations and storage management, and index
structure for files
 Demonstrate queries in the relational algebra.
 Demonstrate queries in the tuple relational calculus.
 Create a relational database schema in SQL that incorporates key, entity
integrity, and referential integrity constraints.
3
 Introduction
 Data are raw facts.
 The facts about an object or concept.
 The object could be any real world entity :- a person, a thing, a place, a
concept …
 Data may not have a meaning unless it is processed.
 When data is processed it will yield information.
 A database is a set of data that has a regular structure.
 It is a collection of records about some entity such as a person, organization,
city, product.
 Data in a database is organized in such a way a computer can easily manage
the data.
 Data in a database can be used to generate information.
4
 Introduction
 Data in a database is broadly classified into two types
 End user Data: raw facts of interest to the end user(the
actual data)
 Metadata or data about data: information about the data in
the database.
 For Example:
 Age of student
 The data may be 25
 Meta-data may contain information like (Age is numeric data, it
should be integer valued, it cannot be Negative value, it cannot be
>200
5
CHARACTERISTICS OF
DATABASE
 A database is a collection of related data and data in a Database is
shared.
 Related
 Data in a database is related in some way
 A collection of random data is not really a database in the true sense
of the word.
 Shared
 A database defined once and used simultaneously by many users.
 No separate file for each user.

6
 WHY USE A
DATABASE?
 To organize information
 To be able to get reports from data
 To protect data :- to apply security features
 To be able to share data
 Keep consistency of data
 Enable online data access

7
 APPLICATION OF DATABASE
 Example Applications of database in our day to day activities
 Ethio-Telecom Database
 Check Balance
 Recharge balance
 Balance Transfer
 Bank Database
 ATM machine access you Account Balance in the Bank Database.
 Transfer Money

8
 HOMEWORK 1
Write short and precise description about the application of
database in the following areas
 In Ethiopian Statistics Agency
 In Registrar
 In Hospitals
 In Banks
 in supermarket
 In finance
 In library
 In Hotels
 Local administration offices (like kebele, woreda, city).
9
 DATABASE SYSTEM
A Database System consists of
 Data:
 User Data: Data used by the organization and
 Metadata: a description of this data
 Software:
 DBMS, operating system, network software (if necessary) and also the
application programs
 Hardware :
 All the necessary input, output , storage and backup devices.
 Can range from a PC to a network of computers
 Users
 Different Roles taken by people while designing and using a Database systems
10
 DATABASE USERS
End users
 Use the database system to achieve some goal
Application developers
 Write software to allow end users to interface with the database system
 Uses a DBMS
Database Administrator (DBA)
 Designs & manages the database system
 Top-level database expert for an organization
Database systems programmer
 Writes the database software itself

11
 DATABASE MANAGEMENT
SYSTEM (DBMS)
 A DBMS is a set of programs that enables users to create a database and
access the data in the database.
 It is designed to store, manage, and facilitate access to databases.
 Most database applications are created using an existing DBMS.
 But you could also write your own DBMS application (e.g. using C++, C#,
VB, Java …)
 The main objectives of database management system are
 data availability,
 data integrity,
 data security, and
 data independence
12
HISTORY OF DATABASE
Database systems passes through the
different levels of development along with
the development in technology and
services.
 Manual approach
 File based system
 Database approach

13
 MANUAL APPROACH
 There were data storage activities before we start to use computers; which is
manual.
 Information are handled by using cards and papers.
In manual approach
 Files are labeled and stored in one or more filing cabinet
 Storage and retrieval is performed using human labor.
 It works well while the number of files to be stored is small.

 Limitations
 Prone to error
 Difficult to retrieve, update
 Difficult to produce a report
 Any advantage of manual approach?
14
 TRADITIONAL FILE BASED SYSTEM
 Is an earlier attempt to computerize the manual filing system.
 File is a collection of records which contains logically related data.
 There is one application program for each data access activity.
 Data Program Dependency
 definitions of the data are embedded in the application program

 Their implementation means are called File processing Systems

 Limitations
 Limited data sharing

(definitions of the data are

 Data dependency on the application
embedded in the application program)
 Duplication of data
15
File terminology
 Data
 Raw Facts
 Field
 Group of characters with specific meaning
 Record
 Logically connected fields that describe a person, place, or thing
 File
 Collection of related records

16
A UNIVERSITIES FILE BASED
SYSTEM

17
 DATABASE APPROACH
 All the limitations of the file based approach can be attributed
to two factors:
1) Data Dependence: The definition of the data is
embedded in the application programs
2) There is no control over the access and manipulation
of data beyond that imposed by the application
programs.
 The database is a large repository of data, which is defined
once and used simultaneously by many departments and users.
 What emerged in the database approach were the Database
and the DBMS.
18
 DATABASE APPROACH
DBMS:
 It is a piece of software that allows a user to define, create and
access data in a database.
 DBMS decouples application programs from data
 Acts as an intermediate between the centralized database and
application programs accessing it.
 Every access to the data in database is through DBMS
 There is no direct access of data by the application programs.
 Every Database Software has DBMS at its core.

19
 DATABASE APPROACH
Database approach has improved many of the problems of file
based approach.
These improvements are
 Data can be shared:- there is a centralized database which can be
shared by different users.
 Data integrity:- database always contains consistent data.
 Increase data independency:-
 The DBMS actually decouples application programs from data.
 This provides the ability to change Database definition without
changing the application program which access it.
 This is called Data independence)
20
A UNIVERSITY’S DATABASE
SYSTEM

21
 DATA MODEL
Data Model:
 Is an integrated collection of tools and concepts describing a
data, relationships and constraints on the data.
 Used to represent data and make the data understandable

 It provides the concepts and notations that a database designer

uses to create and manage data to communicate their database
requirements.
22
 DATA MODEL
Data model comprises three components:
 A structural part; consisting of a set of rules according to which
database constructed.
 Set of operations to be performed on the data (to update or retrieve data)
 Set of rules to maintain integrity of data. i.e. constraints

Two categories of Data Models

1. Conceptual Data Models
2. Implementation Data Models

23
 CONT’D …
Conceptual Models:
It is the complete visualization of the database
requirement of an organization.
Before implementing the database in database
software, we produce the conceptual model on paper.
concerned with what is represented, rather than how
it is represented.
It is Implementation independent

24
 CONT’D …
Implementation Models
 Defines how data are represented in the database
 On computer - On the database software.

Three types of implementation database Models

I. Hierarchical database model
Parent-child Relationship (a tree-like structure)
Data access is only from top to bottom
The data is stored in a flat file.
II. Network database Model
 a record can have many parent record and many child.
 Data is accessed in both direction from top to bottom and from bottom to up
 The data is still stored in a flat file.
25
 CONT’D …
III. Relational Data Model
 The Most widely used database model
 In a relational database, data is stored in tables (also
called relations).
 Tables are a series of row/column intersections
 Columns : fields
 Rows : records
 Tables related by sharing common columns or
characteristic(s) (Foreign Key)

26
RELATIONAL DATA MODEL

27
CONT’D …
Relational model uses database languages like SQL
 They specify what data is to be retrieved.
 The question of how is left for the DBMS.

28
RELATIONAL
DATABASE
MODEL 29
 DATA MODEL
Data model is a collection of tools or concepts for
describing data, data relationship and constraints.
Within the history of database systems we have
 The first generation data models (file based)
 Hierarchical Model
 Network Model
 The second generation data models (Relational Database)
 Relational Model
 The third generation data models
 Object Oriented Data Models
30
 RELATIONAL DATA MODEL
 Relational Data Model is the dominant database software in use
today.
 It is based on the relational model proposed by a paper written by E.F.
Codd. in 1970.
 Originates from the branch of mathematics called set theory and relation
 The major objectives of Relational Data Model specified on the paper
are
 Data independence (application program is independent of internal
schema).
 To deal with semantic, inconsistency and redundancy problems.
 To enable set oriented manipulation languages. E.g. SQL

31
 CONT’D …
 The relational data model represents data as a two
dimensional table called a relation.
 Database in relational data model is a collection of tables
(Relations).
 Each relation represents a single real world entity and has a
name and named attributes(columns).
 Each tuple(row) contains one value per attribute.
 The great strength of relational model is its simple structure.
 It Can define more flexible and complex relationship

32
RELATION/TABLE

33
BANK DATABASE

34
 EXAMPLE: BANK DATABASE
Contains Three Relations
 Customer, Acount and Depositor relations
Customer Relation
 The rows each represent a bank Customer
 columns each represent a property which describe the
Customer (attributes).

35 35
RDM TERMINOLOGY
Relation:
 Relation is a table with rows and columns.
 In relational model database is perceived by the user as
tables.
 But physically the database is stored with different
storage structures.
 A relation represents a single real world entity and has
it’s own unique name.
 E.g. Student, course, Bank_account etc.

36 36
 RDM TERMINOLOGIES
Attribute-
Attribute are a column of a table equivalent to
fields
Are characteristics of the object that is to be
represented by the relation.
It tells about the values in the column below.

37
 MORE ABOUT ATTRIBUTE
 Attribute Types:-attributes can be divided into two
 Main attributes:- are attributes of an entity which have a
constant value.
 They have almost no probability of change.
 Example F_Name, L_name, Birth_Date, Sex, … etc of a student
have constant values which cannot change through time.
 Derived Attributes:- are types of attributes which are derived
from an main attributes of the entity.
 Example: Age of a student can be derived from birthDate and
current day attributes.

38
RDM TERMINOLOGY
 Tuples:-
 A tuple is a row of a relation.
 has one component for each attribute of the relation.
 The change in the order of tuples doesn’t change the
meaning of the relation.
 Degree
 The degree of a relation is the number of attributes it
contains.
 Uniary, Binary, n-ary

 Cardinality
 The cardinality of a relation is the number of tuples it
contains. 39
 RDM TERMINOLOGY
 Domain
 is set of permitted (allowable) value for an attribute.
 E.g. Numeric, string, date, currency, Autonumber
 Every attribute in a relation is defined on a domain.
 E.g. the domain for attribute first_name is string.
 More than one attributes can have the same domain.
 The domain concept is important, because it allows the user to
define in a central place the meaning and source of values that
attributes can hold.

40
 MORE ABOUT DOMAIN …
 Domain Atomicity
 The domains of all attributes must be atomic – the values must be
indivisible i.e. a simple, single value, that cannot be further divided.
 The set of all possible names of people – is atomic.
 The set of full names (first name and father’s name) – is not atomic.
 Null value
 Null means the actual value is unknown or does not exist.
 It is a special value that can be a member of any possible domain.
 E.g. a student may not have email-address. So that we put NULL

41
 PROPERTIES OF RELATION
 A relation has the following properties:
1. the relation has a name that is distinct from all other relation
names in the relational schema;
2. each cell of the relation contains exactly one atomic (single)
value;
3. each attribute has a distinct name;
4. the values of an attribute are all from the same domain;
5. each tuple is distinct; there are no duplicate tuples;
6. the order of attributes has no significance;
7. the order of tuples has no significance, theoretically

42
 SCHEMA
Schema is a description of database - defined at set-up time,
rarely changes (part of the "metadata")
Database Schema
 The description of database
 In a relational database the schema defines the tables, the fields
in each table, and the relationships between fields and tables.
 Includes descriptions of the database structure and the constraints
that should hold on the database.
The database schema changes very rarely

43
 EXAMPLE:- UNIVERSITY DATABASE
Database schema of a university database with four
relations
Student-schema (student_id, student_firstname, student_fathersname,
Program_code)
Program-schema (Program_code, Program_name,
Program_description)
Course-schema(course_code, course_name, course_description,
credit_hours)
Student-Course-Schema (student_id,course_code, Grade)
44
Schema Diagram: A diagrammatic display of
(some aspects of) a database schema.
 Example:- Schema Diagram of University Database

45
 INSTANCES
 Relation Instance
 The content of the relation at some moment.
 Is the set of tuples and data which exist in a table at a specific
moment
 Database Instance
 A database instance is a snap-shot (picture) of the data in the
database at any given instant in time.
 it is the instance of the data in all the tables in the database.
The database instance changes every time the database
is updated (inserting new data, changing an existing
data or deleting an existing data in any of the relations).
46
EXAMPLE:
RELATIONAL
INSTANCES

47
 REVISION QUESTIONS (RELATIONAL MODEL)

1. In relational database data is represented by using _____________.

2. ________________ of an attribute is the set of permitted value for
an attribute.
3. If we don’t know the actual value of an attribute we use ________
value.
4. What does it mean the domains of all attributes must be atomic?
5. In relational database one relation can be used to represent more
than one entity. (True/False)

48
KEYS
 In a relation no two tuples can have exactly the same values for all the
attributes. (why?)
 We need some way to distinguish the tuples from one another.
 A key is an attribute or set of attributes in a relation that uniquely
identifies each tuples in the relation.
 The values of those key attributes of a single instance of tuple must
uniquely identify that instance.
 Types of keys
i. Super key
ii. Candidate key
iii. Primary key 49
 I. SUPER KEY
 Super key can be an attribute or a set of attributes.
 It is a key made of maximum combination of attributes.
 Super key may contain additional attributes that are not necessary for
unique identification.
 For example: Given a relation “Student” as
Student(stud_id, F_name, L_name)
 Examples of superkeys for relation student can be
 {stud_id, F_name}
 {stud_id,L_name}
 {stud_id,F_name, L_name} or
 {stud_id}
 Q. How about {F_name, L_name}, can it be used as a superkey? 50
 II. CANDIDATE KEYS
 A candidate key is a superkey for which no subset is itself a
superkey. (i.e. stud_id)
 It is a combination of attributes which can be a key by
themselves individually.
 If a super key is having only one attribute, it is automatically a
Candidate key
E.g. Department(Dept_Id, Dept_Name, specialization)

Dept_Id and Dept_Name can be the candidate keys

51
GRADE_SCALE RELATION
Q: IDENTIFY THE CANDIDATE KEYS

Grade ID Letter_grade Min Max

1 A+ 90 100
2 A 85 89
3 A- 80 85
. . . .
. . . .
. . . .

52
 III. PRIMARY KEYS
 A primary key is a candidate key chosen to be the main way to
uniquely identify tuples in the relation.
 For each records(tuples) in the relation the Primary key value
should be unique.
 For example: Dept_Id
 Dept_Id must be unique for every department.
 For example: stud_id of student

 Some times a candidate key may contain more than 1 attribute.

 And more than one attributes can be chosen as a primary key
 This is called composite-primary-key

53
 PRIMARY KEY
There are two types of primary key
 Simple Primary key
 Is a primary key made up of a single field only.
 E.g. Student_Id in student relation.
 Composite primary key
 Is a primary key composed of more than one attribute.
 E.g. Grade Relation

Grade
Stud_Id Course_Code Grade
001 GIS231 A 54
 RELATIONSHIPS
 Example: university-database

55
 RELATIONSHIPS
 Relationship is the connection between different relations(tables) in a
database.
 A row in one table can be related to a row(s) in another table(s).

 These connections are called relationships.

 For the university database schema diagram given above, relationship

is represented as a line connecting each relations together
 Types of Relationships
 1:1(One to one)
 1:M(One to Money)
 M:M(Many to many) 56
 HOW TO CREATE A RELATIONSHIP?
Let’s say we have two relations R1 and R2
Relationship is created between R1 and R2 by sharing
primary key(PK) attribute of one of the two relations let’s
say R1 into R2.
 In this case sharing attribute means adding a column in R2 as a
foreign key.
 The column to be added in R2 must be PK column of R1.
 For a single relationship, attributes are shared only in one
direction (from R1 to R2 or from R2 to R1, Not in both direction)
 The attribute to be shared must be a primary key.
57
 HOW TO CHOOSE THE SHARING RELATION???
 How to choose which one will share it’s PK attribute?
 Answer: It depends on the relationship type (1:1, 1:M, M:M)
 If the relationship is 1:1, PK attribute can be shared either from
R1 to R2 or from R2 to R1. You choose one, but not both.
 If the relationship is 1:M , PK is shared only from 1 side to the
M side. (i.e. Let’s say R1 is the 1 side and R2 is the M side), we
add the PK of R1 into R2 as a foreign key.
 M:M relationship is illegal in Relational database Model.
 Specifically in 1:M relationship, PK is shared from 1 side
into M side.
58
EXAMPLE
 Student

stud_id first_name last_name sex CGPA dept_id

107 Getachew Yiheyis M 2.82 D003
113 Mesfin Negesse M 3.51 D003
106 Leyla Endris F 3.21 D001
109 Edlawit Amare F 2.37 D004
 Department

dept_id dept_name Level head

D001 Statistics Degree Mifta R.
D002 Mathematics Diplome Sultan
D003 Public Administration Masters Dejene
D004 Public Administration Degree Dejene
59
 Forexample: E.g. Department – Student relationship
 Based on previous slide (Slide#59)
 The relationship is 1:M. How?
 1 department can have M students (e.g. Two students are in psychology
department)
 1 students can be assigned to only 1 department (e.g. every student have
only 1 department.)
 It is read as Student is the M side and Deparment is the 1 side.
 So that we move attribute from Department to Student relation (from 1 side
to the M side).
 Their relational schema
 Department (dept_id, dept_name, head)
 Student(stud_id, first_name, last_name, sex, CGPA, dept_id)

 Here dept_id in student relation is used for relationship purpose.

60
 RELATIONSHIPS PURPOSE …
 Relationships are used to avoid duplication of
data in different tables.
 E.g. If there is a new student, it will be added to
‘Student’ relation with the relevant student
information and his/her ‘dept_id’.
 The other details about the department can be found
from department relation using the ‘dept_id’.
 For_example: There are two masters students in
public administration
 Q: Add a student named “Endashaw Kifle” into
students table as a Mathematics diploma student.
Give him Id_number by yourself 61
 FOREIGN KEY
 Foreign key: is an attribute in one relation which
is linked with a primary key in another table.
 For example: dept_id is a foreign key in student
relation. But it is a primary key in department relation.

 Foreign key is used to link tables together and

create relationship.

62
CONSTRAINTS
 Constraints are rules that restrict the possible
values that can go into a relation.
 NULL constraint
 Entity Integrity constraint
 Referential Integrity constraint
 General constraints : Domain Constraint

63
NULL
 Null Represents a value for an attribute that is
currently unknown or is not applicable for this tuple.
 Nulls are a way to deal with incomplete or exceptional
data.
 Null is not Zero (0).
 Null is not the same as a zero numeric value : a null
represents the absence of a value.
 It can be a member of any domain (string, numeric, …)

64
 ENTITY INTEGRITY CONSTRAINTS

Entity integrity rule states that

 Each relation must have a primary key.
 A primary key value cannot be NULL
 Nulls can cause implementation problems.

Entity Integrity is enforced using

Primary Key.

65
 REFERENTIAL INTEGRITY CONSTRAINTS

 We have said that, a Foreign Key is an attribute in

one relation which is a primary key in the related
table.
 Referential integrity states that:
 If a foreign key exists in a relation, either the foreign
key value must match a primary key value of some
tuple in its home(referenced) relation or the foreign
key value must be wholly NULL.
 I.e. foreign key value must come from primary key value of the related table.

 Referential Integrity is enforced using Foreign Keys.

66
GENERAL CONSTRAINTS
Domain constraint:
 every attribute has a domain.
 A restriction on the type of value to be entered in these
attributes is called domain constraint.
 Other Constraints
 There can be additional rules specified by the
users or database administrators of a database
that define or constrain some aspect of the
enterprise.
 For example: The total mark for a course must not
be greater than 100 and cannot be less than 0.
67
REVISION EXAMPLE
 Student

stud_id first_name last_name sex CGPA dept_id

107 Getachew Yiheyis M 2.82 D003
113 Mesfin Negesse M 3.51 D003
106 Leyla Endris F 3.21 D001
109 Edlawit Amare F 2.37 D004
 Department

dept_id dept_name Level head

D001 Statistics BSc Mifta R.
D002 Mathematics Diplome Sultan
D003 Public Administration Masters Dejene
D004 Public Administration BSc Dejene
68
 REVISION QUESTION
Based on the given relationship between Student and Department given above
answer the following questions

1. The name of the two relations are ___________ and _______

2. The relation ‘student’ has _______ number of attributes and ______ number of
tuples.
3. List all the attributes of the relation student and Department and identify the
possible domain of each attributes.
4. What are the possible primary key attribute for the relations student and
Department?
5. What is the foreign key attribute in student and department relation?
6. Is there any foreign key attribute in Department relation?
7. What is the degree & cardinality of the relation student and Department?
8. Write the relational schema of the student and Department relations.
69
 EXAMPLE:- UNIVERSITY DATABASE
Create the university database based on the database-
schema given below

70
E.G. UNIVERSITY DATABASE
 Discuss the following revision topics using the university
database example.
 Relation, attribute, domain
 Candidate key
 Primary key (simple/composite)
 How relationship is created in relational mode.
 Foreign key
 Entity Integrity Constraints
 Referential Integrity Constraint
 Relational schema
 Database Schema
71
SAMPLE DATA: DEPARTMENT

72
 DISCUSSION …

 Add a column named “Telephone Number” and discuss the probability the value for it not
Atomic.

73
SAMPLE DATA: STUDENT

74
SAMPLE DATA: COURSE

75
SAMPLE DATA: STUDENTCOURSE (GRADE)

76
 REVIEW QUESTIONS
What is the primary key for the relation Grade?

1) _________ is an attribute used to uniquely identify each tuples of a relation.

2) What does NULL value indicates?

77