Chapter 2
Chapter 2
Chapter 2
DATABASE SYSTEM
ARCHITECTURE
Objective
• to briefly describe the evolution of database
systems and to understand some of the main
data models used and now in use.
• To understand the database system
Architecture
• Estimated time 4 hours
Outline
• Basic Database Terminologies
• Overview of data models
• Schemas and Instances
• DBMS Architecture
• Data Independence
Basic Database Terminologies
• Enterprise - an organization : A library, a bank, a university, etc.
• Entity - person, place, thing, or event
– An "object" in the real world that we are interested in like
Student, Customer, Book, …
• Attribute (Field) - a characteristics of an Entity, that has a specific
meaning. Eg. Name, age, telephone, grade, sex, etc.
• Record - a logically connected set of one or more Attributes that
describe an Entity
• File - a collection of related records. For example, a file might
contain data about customers; or students of a certain department in a
university
• Database - collection of Files
Data Model
• A set of primitives for defining the structure of a
database.
• Database Model is a collection of tools or concepts
for describing:
– Data
– Data relationships
– Data semantics
– Data constraint
• The main purpose of database model is to represent
the data in an understandable way.
Data Model
123,Tesfay, Kebede, 04 407600, Yeka kefle ketema Addis Ababa, 1234, 1000,
9876, 1000
• A file contains data about one entity e.g. Customer is an entity. Each record in the
file represents an instance of that entity.
• Each row is a record; the file represents a record type.
Cont’d
Disadvantages
• Programmers had to write specific programs to carry out each tasks - so a lot of
work was involved.
– e.g. to retrieve all customer records or to find the customer record for a given customer
number.
• It could also lead to data being duplicated in different files
– e.g. think of a bank’s database. A customer’s name and phone number could appear in a
file containing all savings accounts. If the same customer also has a current account, their
name and phone number would also appear in the file containing all current accounts. Or
if a customer has 2 savings accounts – need 2 rows in the file –name and phone number
are repeated.
• If the customer changes their phone number – it has to be changed in both files.
• This system worked, but didn’t allow data to be related – e.g. to have the
customer name and phone number in one place, and relate a savings account to
it and a current account to it.
Record-based Data Models
– Conceptual simplicity
– Data access flexibility – no need for a preorder traversal
– Promotes database integrity – must first define the owner
and then the member record
– Data independence
– Network Model is able to model complex relationships and r
epresents semantics of add or delete on the relationships.
– Can handle most situations for modeling using record types
and relationship types.
– Conformance to standards
• System complexity
• Lack of structural independence
• Navigational and procedural nature of processing.
• 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
• Database contains a complex array of pointers
that thread through a set of records.
• Little scope for automated "query optimization”
Relational 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 relational algebra.
• 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.