Chapter 1: Introduction

Instructor : Dr. HO Mony

Qualification : PhD in Computer Science, Cambodia.
: PhD Student in Information Technology, Malaysia.
Telegram : +85512603314
Outline
Introduction

1.1 Database-System Applications

1.2 Purpose of Database Systems

1.3 View of Data

1.4 Database Languages

1.5 Database Design

2
Introduction
• A database-management system (DBMS) is a collection of
interrelated data and a set of programs to access those data.

• The collection of data, usually referred to as the database, contains

information relevant to an enterprise.

• The primary goal of a DBMS is to provide a way to store and retrieve

database information that is both convenient and efficient.

• Database systems are designed to manage large bodies of

information.
3
Introduction
• Management of data involves both defining structures for storage of
information and providing mechanisms for the manipulation of
information.

• If data are to be shared among several users, the system must avoid
possible anomalous results.

4
1.1 Database-System Applications
• Database systems are used to manage collections of data that:

• are highly valuable,

• are relatively large, and

• are accessed by multiple users and applications, often at the same

time.

5
1.1 Database-System Applications
• Here are some representative applications:

• Enterprise Information
• Sales: For customer, product, and purchase information.

• Manufacturing: For management of the supply chain and for

tracking production of items in factories, inventories of items in
warehouses and stores, and orders for items.

• Banking and Finance

• Banking: For customer information, accounts, loans, and

banking transactions. 6
1.1 Database-System Applications
• Universities: For student information, course registrations, and
grades (in addition to standard enterprise information such as
human resources and accounting).
• Airlines: For reservations and schedule information.

7
1.1 Database-System Applications
• Web-based services

• Online retailers: For keeping records of sales data and orders as

for any retailer, but also for tracking a user’s product views,
search terms, etc., for the purpose of identifying the best items
to recommend to that user.
• Navigation systems: For maintaining the locations of varies places
of interest along with the exact routes of roads, train systems,
buses, etc.
8
1.2 Purpose of Database Systems
• To understand the purpose of database systems, consider part of a
university organization that, among other data, keeps information
about all instructors, students, departments, and course offerings.

• One way to keep the information on a computer is to store it in

operating-system files.

9
1.2 Purpose of Database Systems
• To allow users to manipulate the information, the system has a
number of application programs that manipulate the files, including
programs to:
• Add new students, instructors, and courses.
• Register students for courses and generate class rosters.
• Assign grades to students, compute grade point averages (GPA),
and generate transcripts.

10
1.2 Purpose of Database Systems
• New application programs are added to the system as the need arises.

• For example, suppose that a university decides to create a new major.

• As a result, the university creates a new department and creates new

permanent files (or adds information to existing files) to record
information about all the instructors in the department, students in
that major, course offerings, degree requirements, and so on.

• This typical file-processing system is supported by a conventional

operating system.
11
1.2 Purpose of Database Systems
• The system stores permanent records in various files, and it needs
different application programs to extract records from, and add
records to, the appropriate files.

• Keeping organizational information in a file-processing system has a

number of major disadvantages: data redundancy and inconsistency,
difficulty in accessing data, data isolation, integrity problems, atomicity
problems, concurrent-access anomalies, security problems.

12
1.2 Purpose of Database Systems
• Data redundancy and inconsistency: The same information may be
duplicated in several places (files). The various copies of the same
data may no longer agree.

• Difficulty in accessing data: do not allow needed data to be

retrieved in a convenient and efficient manner.

• Data isolation: Because data are scattered in various files, and files
may be in different formats, writing new application programs to
retrieve the appropriate data is difficult.
13
1.2 Purpose of Database Systems
• Integrity problems: The data values stored in the database must
satisfy certain types of consistency constraints.

• Atomicity problems: if a failure occurs, resulting in an inconsistent

database state.

• Concurrent-access anomalies: For the sake of overall performance of

the system and faster response, many systems allow multiple users to
update the data simultaneously.

• Security problems: Not every user of the database system should be

able to access all the data. 14
1.3 View of Data
• A major purpose of a database system is to provide users with an
abstract view of the data.

• That is, the system hides certain details of how the data are stored
and maintained.

• Underlying the structure of a database is the data model: a collection

of conceptual tools for describing data.

15
1.3.1 Data Models
• The data models can be classified into four different categories:

• Relational Model
• Entity-Relationship Model

• Semi-structured Data Model

• Object-Based Data Model

16
1.3.1 Data Models
• Relational Model

• The relational model uses a collection of tables to represent both

data and the relationships among those data.

• Each table has multiple columns, and each column has a unique
name.
• Tables are also known as relations.

• Chapter 2 and Chapter 7 cover the relational model in detail.

17
1.3.1 Data Models
• Entity-Relationship Model

• The entity-relationship (E-R) data model uses a collection of basic

objects, called entities, and relationships among these objects.

• An entity is a “thing” or “object” in the real world that is

distinguishable from other objects.

• The entity-relationship model is widely used in database design.

• Chapter 6 explores it in detail.

18
1.3.1 Data Models
• Semi-structured Data Model

• The semi-structured data model permits the specification of data

where individual data items of the same type may have different sets
of attributes.

• JSON and Extensible Markup Language (XML) are widely used semi-
structured data representations.

• Semi-structured data models are explored in detail in Chapter 8.

19
1.3.1 Data Models
• Object-Based Data Model

• Object-oriented programming (especially in Java, C++, or C#) has

become the dominant software-development methodology.

• This led initially to the development of a distinct object-oriented

data model, but today the concept of objects is well integrated
into relational databases.

• Object-based data models are summarized in Chapter 8.

20
1.3.2 Relational Data Models
• In the relational model, data are represented in the form of tables.

• Each table has multiple columns, and each column has a unique name.

• Each row of the table represents one piece of information.

• Figure 1.1 presents a sample relational database comprising two

tables: one shows details of university instructors and the other
shows details of the various university departments.

21
1.3.2 Relational Data Models

22
1.3.3 Database Abstraction

View Level Logical Level Physical Level

23
1.3.3 Database Abstraction
• Since many database-system users are not computer trained,
developers hide the complexity from users through several levels of
data abstraction, to simplify users’ interactions with the system:
• Physical level:
• The lowest level of abstraction describes how the data are
actually stored.

24
1.3.3 Database Abstraction
• Logical level:

• The next-higher level of abstraction describes what data are

stored in the database, and what relationships exist among
those data.
• The logical level thus describes the entire database in terms of a
small number of relatively simple structures.
• Database administrators, who must decide what information to
keep in the database, use the logical level of abstraction.
25
1.3.3 Database Abstraction
• View level:

• The highest level of abstraction describes only part of the entire

database.

• Many users of the database system do not need all this

information; instead, they need to access only a part of the
database.

26
1.3.4 Instances and Schemas
• The collection of information stored in the database at a particular
moment is called an instance of the database.

• The overall design of the database is called the database schema.

27
1.4 Database Languages
• A database system provides a data-definition language (DDL) to
specify the database schema and a data-manipulation language
(DML) to express database queries and updates.

• Almost all relational database systems employ the SQL language,

which we cover in great detail in Chapter 3, Chapter 4, and Chapter 5.

28
1.4.1 Data-Definition Language
• Thus, database systems implement only those integrity constraints
that can be tested with minimal overhead:

• Domain Constraints: A domain of possible values must be associated

with every attribute (for example, integer types, character types,
date/time types).

• Referential Integrity: There are cases where we wish to ensure that a

value that appears in one relation for a given set of attributes also
appears in a certain set of attributes in another relation (referential
integrity). 29
1.4.1 Data-Definition Language
• Referential Integrity (cont.): For example, the department listed for
each course must be one that actually exists in the university. More
precisely, the dept name value in a course record must appear in the
dept name attribute of some record of the department relation.

30
1.4.1 Data-Definition Language
• Authorization: We may want to differentiate among the users as far
as the type of access they are permitted on various data values in the
database.
• Read authorization: which allows reading, but not modification, of
data
• Insert authorization: which allows insertion of new data, but not
modification of existing data;
• Update authorization: which allows modification, but not deletion,
of data
• Delete authorization: which allows deletion of data.

31
1.4.2 The SQL Data-Definition Language
• SQL provides a rich DDL that allows one to define tables with data
types and integrity constraints.

• For instance, the following SQL DDL statement defines the

department table:

create table department

(dept_name char (20),

building char (15),

budget numeric (12,2));

32
1.4.2 The SQL Data-Definition Language
• Execution of the preceding DDL statement creates the department
table with three columns: dept_name, building, and budget, each of
which has a specific data type associated with it.

33
1.4.3 Data-Manipulation Language
• A data-manipulation language (DML) is a language that enables
users to access or manipulate data as organized by the appropriate
data model.

• The types of access are:

• Retrieval of information stored in the database.
• Insertion of new information into the database.

• Deletion of information from the database.

• Modification of information stored in the database.

34
1.4.4 The SQL Data-Manipulation Language
• Here is an example of an SQL query that finds the names of all
instructors in the History department:

select instructor.name

from instructor

where instructor.dept_name = 'History';

35
1.4.4 The SQL Data-Manipulation Language
• Queries may involve information from more than one table.

• For instance, the following query finds the instructor ID and

department name of all instructors associated with a department with
a budget of more than $95,000.
select instructor.ID, department.dept_name
from instructor, department
where instructor.dept_name= department.dept_name
and department.budget > 95000;

36
1.4.5 Database Access from Application
Programs
• Application programs are programs that are used to interact with
the database in this fashion.

• Examples in a university system are programs that allow students to

register for courses, generate class rosters, calculate student GPA,
generate payroll checks, and perform other tasks.

37
1.4.5 Database Access from Application
Programs
• To access the database, DML statements need to be sent from the
host to the database where they will be executed.

• This is most commonly done by using an application-program

interface (set of procedures) that can be used to send DML and DDL
statements to the database and retrieve the results.

38
1.5 Database Design
Initial (a
specification of Conceptual-design
user requirements) phase
phase

Logical-design Physical-design
phase phase

39
1.5 Database Design
• The (1) initial phase of database design, then, is to characterize fully
the data needs of the prospective database users.

• The outcome of this phase is a specification of user requirements.

40
1.5 Database Design
• Initial Phase (User Requirements)

41
1.5 Database Design
• Next, the designer chooses a data model, and by applying the
concepts of the chosen data model, translates these requirements
into a conceptual schema of the database. The schema developed at
this (2) conceptual-design phase provides a detailed overview of the
enterprise.

• The focus at this point is on describing the data and their

relationships.

42
1.5 Database Design
• conceptual-design phase (E-R Diagram)

43
1.5 Database Design
• The process of moving from an abstract data model to the
implementation of the database proceeds in two final design phases.

• In the (3) logical-design phase, the designer maps the high-level

conceptual schema onto the implementation data model of the
database system that will be used.

44
1.5 Database Design
• logical-design phase (Relation Model)

45
1.5 Database Design
• The designer uses the resulting system-specific database schema in
the subsequent (4) physical-design phase, in which the physical
features of the database are specified.

46
1.5 Database Design
• physical-design phase
CREATE TABLE vaccine (
vaccine_id INT NOT NULL,
khmer_first_name INT NOT NULL,
latin_first_name INT NOT NULL,
latin_last_name INT NOT NULL,
id_card INT NOT NULL,
phone_number INT NOT NULL,
created_at INT NOT NULL,
updated_at INT NOT NULL,
PRIMARY KEY (vaccine_id)
); 47
1.5 Database Design
• physical-design phase
CREATE TABLE vaccine_informations(
vaccine_id INT NOT NULL,
phase INT NOT NULL,
vaccine_name INT NOT NULL,
location INT NOT NULL,
vaccine_date INT NOT NULL,
created_at INT NOT NULL,
updated_at INT NOT NULL,
FOREIGN KEY (vaccine_id) REFERENCES
vaccine(vaccine_id)
); 48
Reference
• Abraham Siberschatz, Henry F. Korth,
S. Sudarshan (2019). Database System
Concepts (7th Edition). McGraw-Hill
Education. ISBN 9780078022159

49