Database Systems (CC-2141)

Lecture # 3-4-5

Instructor
Amna Zulfiqar
 Lecture # 3-4 Agenda:
• Introduction to Database Environment
o Components of Database Environment
o Types of Database Users/Roles
• History of Database Systems
• When Not to Use a DBMS?
• DBMS Functions
• Database Design and Modelling
• Types of Database Management Systems
• Examples & Mappings of Database Models

2
Introduction to Database Environment

3
 Components of Database Environment

1. Hardware
2. Software
3. Data
4. Procedures
5. People/User Groups

4
Components of Database Environment (cont.)

1. Hardware

• The DBMS and the applications require hardware to run. The hardware can range
from a single personal computer to a single mainframe or a network of computers.

• The particular hardware depends on the organization’s requirements and the DBMS
used.

• Some DBMSs run only on particular hardware or operating systems, while others
run on a wide variety of hardware and operating systems.

• A DBMS requires a minimum amount of main memory and disk space to run, but
this minimum configuration may not necessarily give acceptable performance.

5
Components of Database Environment (cont.)

2. Software

• The software component comprises the DBMS software itself and the application
programs, together with the operating system, including network software if the
DBMS is being used over a network.

• Typically, application programs are written in a third-generation programming

language (3GL), such as C, C++, C#, Java, Visual Basic, COBOL, Fortran, Ada, or
Pascal, or a fourth-generation language (4GL), such as SQL, embedded in a third
generation language.

• The target DBMS may have its own fourth-generation tools that allow rapid
development of applications through the provision of nonprocedural query
languages, reports generators, forms generators, graphics generators, and
application generators.

• The use of fourth-generation tools can improve productivity significantly and

produce programs that are easier to maintain.
6
Components of Database Environment (cont.)
3. Data

• Perhaps the most important component of the DBMS environment—certainly from

the end-users’ point of view—is the data.

• In Figure (slide # 4) , we observe that the data acts as a bridge between the
machine components and the human components.

• The database contains both the operational data and the metadata, the “data about
data.”

• The structure of the database is called the schema.

4. Procedures

• Procedures refer to the instructions and rules that govern the design and use of the
database.

7
Components of Database Environment (cont.)
4. Procedures (cont.)

• The users of the system and the staff who manage the database require
documented procedures on how to use or run the system.

• These may consist of instructions on how to:

o Log on to the DBMS.
o Use a particular DBMS facility or application program.
o Start and stop the DBMS.
o Make backup copies of the database.
o Handle hardware or software failures. This may include procedures on how to
identify the failed component, how to fix the failed component (for
example, telephone the appropriate hardware engineer), and,
following the repair of the fault, how to recover the database.
o Change the structure of a table, reorganize the database across multiple disks,
improve performance, or archive data to secondary storage.

5. People
• The final component is the people involved with the system. 8
 Types of Database Users/Roles
• Database users are the persons who interact with the database and take the
benefits of database.

• Users are differentiated by the way they expect to interact with the system.

• Following are the types of database users in DBMS.

1. Data and Database Administrators

The database and the DBMS are corporate resources that must be managed like any
other resource. Data and database administration are the roles generally associated
with the management and control of a DBMS and its data.

• The Data Administrator (DA) is responsible for the management of the data
resource, including database planning; development and maintenance of
standards, policies and procedures; and conceptual/logical database design.

• The DA consults with and advises senior managers, ensuring that the
of database development will ultimately support corporate objectives.
direction 9
 Types of Database Users/Roles (cont.)
• The Database Administrator (DBA) is responsible for the physical realization of
the database, including physical database design and implementation,
security and integrity control, maintenance of the operational system, and
ensuring satisfactory performance of the applications for users.

• The role of the DBA is more technically oriented than the role of the DA,
requiring detailed knowledge of the target DBMS and the system environment.

• In some organizations there is no distinction between these two roles; in

others, the importance of the corporate resources is reflected in the allocation
of teams of staff dedicated to each of these roles.

2. Database Designers

• Database Designers are the users who design the structure of database which
includes tables, indexes, views, constraints, triggers, stored procedures.
He/she controls what data must be stored and how the data items to be
related.
10
 Types of Database Users/Roles (cont.)
3. Application Programmers/Developers

• Once the database has been implemented, the application programs that
provide the required functionality for the end-users must be implemented.

• This is the responsibility of the application developers.

• Typically, the application developers work from a specification produced by

systems analysts.

• Each program contains statements that request the DBMS to perform some
operation on the database, which includes retrieving data, inserting,
updating, and deleting data.

11
 Types of Database Users/Roles (cont.)
4. End Users
The end-users are the “clients” of the database, which has been designed and
implemented and is being maintained to serve their information needs. End-users can
be classified according to the way they use the system:

• Naïve users
o They are typically unaware of the DBMS. They access the database through
specially written application programs that attempt to make the
operations as simple as possible.

o They invoke database operations by entering simple commands or choosing

options from a menu. This means that they do not need to know
anything about the database or the DBMS.

o For example, the checkout assistant at the local supermarket uses a bar code
reader to find out the price of the item. However, there is an
application program present that reads the bar code, looks up the price
of the item in the database, reduces the database field containing
stock,
the and displays
number of suchthe price
items in on the till. 12
 Types of Database Users/Roles (cont.)
4. End Users (cont.)

• Sophisticated users
o At the other end of the spectrum, the sophisticated end-user is familiar with
the structure of the database and the facilities offered by the DBMS.

o Sophisticated end-users may use a high-level query language such as SQL to

perform the required operations.

o Some sophisticated end-users may even write application programs for their
own use.

13
 History of Database Systems
1. 1950s and early 1960s:
• Data processing using magnetic tapes for storage
• Tapes provided only sequential access
• Punched cards for input

2. Late 1960s and 1970s:

• Hard disks allowed direct access to data

• Hierarchical and network data models in widespread use

o IBM’s DL/I (Data Language One)
o CODAYSL’s DBTG (Data Base Task Group) model
o → the basis of current DBMSs

• Ted Codd defines the relational data model

o IBM Research develops System R prototype
o UC Berkeley develops Ingres prototype

• Entity-Relationship Model for database design

14
 History of Database Systems (cont.)
3. 1980s:
• Research relational prototypes evolve into commercial systems
o DB2 from IBM is the first DBMS product based on the relational model
o Oracle and Microsoft SQL Server are the most prominent commercial
DBMS products based on the relational model

• SQL becomes industrial standard

• Parallel and distributed database systems

• Object-oriented database systems (OODBMS)

o Goal: store object-oriented programming objects in a database without
having to transform them into relational format
o In the end, OODBMS were not commercially successful due to high cost of
relational to object-oriented transformation and a sound underlying
theory, but they still exist

• Object-relational database systems allow both relational and object views of

data in the same database 15
 History of Database Systems (cont.)
4. Late 1990s:
• Large decision support and data-mining applications
• Large multi-terabyte data warehouses
• Emergence of Web commerce

5. Early 2000s:
• XML and XQuery standards
• Automated database administration

6. Later 2000s:
• Web databases (semi-structured data, XML, complex data types)
• Cloud computing
• Giant data storage systems (Google BigTable, Yahoo PNuts, Amazon Web
Services,…)
• Advanced databases (mainly non-relational (e.g., graph-based, text based) but
also advanced relational)

16
History of Database Systems (cont.)

17
 When Not to Use a DBMS?
In spite of the advantage of using a DBMS, there is some situation in which a DBMS
may involve unnecessary overhead costs that would not be incurred in traditional file
processing. The overhead cost of using a DBMS is due to the following:

1. High initial investment in hardware, software, and training.

2. The basic property that DBMS provide is defining and processing of data.
3. Overhead for providing security, concurrency control, recovery and integrity
functions.

Additional problems may arise if the database designers and DBA don’t properly
design the database or if the database systems application is not implemented
properly.
Hence it may be more desirable to use regular files under the following
circumstances.

4. We can use a regular file system when we know that a simple database is not
going to change.
5. Severe, real-time requirements for some programs that may not be met
3. No multiple user access to data.
because 18
 When Not to Use a DBMS? (cont.)
Certain industries and application have elected not to use general purpose DBMSs.

For example:
1. Many computer-aided design tools (CAD) used by students of the mechanical and
civil department have proprietary file and data management software that is
geared for the internal manipulation of drawing and 3D objects.

2. Communication and switching systems which are basically designed by companies

like AT&T were early manifestations of database software that was used because
they are made to run very fast with hierarchically organized data and to access and
routing of calls quickly.

3. Similarly, GIS implementation often implements their own data organization

schemes for efficiently implementing function related to processing maps, physical
contours, lines, polygons, and so on and General purpose DBMS are inadequate for
their purpose.

19
 An Example: Online Bookseller

What data do we need?

• Data about books, customers, pending orders, order histories, trends, preferences,
etc.

What capabilities on the data do we need?

• Insert/remove books, find books by author/title/etc., analyse past order history,
recommend books, … – Data must be accessed efficiently, by many users –
Data must be safe from failures and malicious users

20
 Reading Assignment

Completion of Chapter # 1: Read Chapter # 1

Book: Database Systems: A Practical Approach to Design, Implementation, and

Management,
6th Edition by Thomas Connolly and Carolyn Begg

21
 Functions of a DBMS
• We look at the types of function and service that we would expect a DBMS to
provide.

1. Data storage, retrieval, and update

• A DBMS must furnish users with the ability to store, retrieve, and update data
in the database. This is the fundamental function of a DBMS.

• The DBMS should hide the internal physical implementation details (such as
file organization and storage structures) from the user.

2. A user-accessible catalogue
• A DBMS must furnish a catalogue in which descriptions of data items are
stored and which is accessible to users.

• Typically, the system catalogue stores:

o Names, types, and sizes of data items
o Names of relationships
o Integrity constraints on the data
o Names of authorized users who have access to the data
22
 Functions of a DBMS (cont.)
o The data items that each user can access and the types of access allowed;
for example, insert, update, delete, or read access
o External, conceptual, and internal schemas and the mappings between
the schemas
o Usage statistics, such as the frequencies of transactions and counts on
the number of accesses made to objects in the database

3. Transaction support
• A DBMS must furnish a mechanism that will ensure either that all the
updates corresponding to a given transaction are made or that none
of them is made.

• A transaction is a series of actions, carried out by a single user or application

program, which accesses or changes the contents of the database.

• If the transaction fails during execution, perhaps because of a computer

crash, the database will be in an inconsistent state: some changes will have
been made and others will not. Consequently, the changes that have been
made will have to be undone to return the database to a consistent state
again. 23
 Functions of a DBMS (cont.)
4. Concurrency control services
• A DBMS must furnish a mechanism to ensure that the database is updated
correctly when multiple users are updating the database concurrently.

• One major objective in using a DBMS is to enable many users to access

shared data concurrently.

• Concurrent access is relatively easy if all users are only reading data, as
there is no way that they can interfere with one another.

• However, when two or more users are accessing the database

simultaneously and at least one of them is updating data, there may be
interference that can result in inconsistencies.

24
 Functions of a DBMS (cont.)

5. Recovery services
• A DBMS must furnish a mechanism for recovering the database in the event
that the database is damaged in any way.

• When discussing transaction support, we mentioned that if the transaction

fails, then the database has to be returned to a consistent state.

• This failure may be the result of a system crash, media failure, a hardware
or software error causing the DBMS to stop, or it may be the result of the
user detecting an error during the transaction and aborting the transaction
before it completes.

• In all these cases, the DBMS must provide a mechanism to restore the
database to a consistent state.

25
 Functions of a DBMS (cont.)
6. Authorization services
• A DBMS must furnish a mechanism to ensure that only authorized users can
access the database.

• It is not difficult to envision instances where we would want to prevent some

of the data stored in the database from being seen by all users.

• For example, we may want only branch managers to see salary-related

information for staff and to prevent all other users from seeing this data.

7. Support for Data Communication

• A DBMS must be capable of integrating with communication software.

• Most users access the database from workstations. Sometimes these

workstations are connected directly to the computer hosting the DBMS.

• In other cases, the workstations are at remote locations and communicate

with the computer hosting the DBMS over a network. In either case, the
DBMS receives requests as communications messages and responds in a
similar way. 26
 Functions of a DBMS (cont.)
7. Support for Data Communication (cont.)
• All such transmissions are handled by a data communication manager
(DCM).

• Although the DCM is not part of the DBMS, it is necessary for the DBMS to
be capable of being integrated with a variety of DCMs if the system is to be
commercially viable.

• Even DBMSs for personal computers should be capable of being run on a

local area network so that one centralized database can be established for
users to share, rather than having a series of disparate databases, one for
each user.

• This does not imply that the database has to be distributed across the
network, but rather that users should be able to access a
centralized database from remote locations.

27
 Functions of a DBMS (cont.)
8. Integrity Services
• A DBMS must furnish a means to ensure that both the data in the database
and changes to the data follow certain rules.

• “Database integrity” refers to the correctness and consistency of stored

data. Integrity is concerned with the quality of data itself.

• Integrity is usually expressed in terms of constraints, which are consistency

rules that the database is not permitted to violate.

• For example, we may want to specify a constraint that no member of staff

can manage more than 100 properties at any one time.
Here, we would want the DBMS to check when we assign a property to a
member of staff whether this limit would be exceeded and to prevent the
assignment from occurring if the limit has been reached.

28
 Database Design and Modelling
• Data modelling is the first step in the process of database design. This step is
sometimes considered to be a high-level and abstract design phase, also referred
to as conceptual design. The aim of this phase is to describe:

• The data contained in the database (e.g., entities: students, lecturers,

courses,
subjects)

• The relationships between data items (e.g., students are supervised by

lecturers; lecturers teach courses)

• The constraints on data (e.g., student number has exactly eight digits; a
subject has four or six units of credit only)

• In the second step, the data items, the relationships and the constraints are all
expressed using the concepts provided by the high-level data model.

• Since these concepts do not include the implementation details, the result of the
data modelling process is a (semi) formal representation of the database
29
 Database Design and Modelling (cont.)
• This result is quite easy to understand so it is used as reference to make sure that
all the user’s requirements are met.

• The third step is database design. During this step, we might have two sub-steps:

o One called database logical design, which defines a database in a data model
of a specific DBMS.

o Another called database physical design, which defines the internal database
storage structure, file organization or indexing techniques.

• These two sub-steps are database implementation and operations/user

interfaces
building steps.

• In the database design phases, data are represented using a certain data model.

• The data model is a collection of concepts or notations for describing data, data
relationships, data semantics and data constraints. Most data models also include
30
 Types of Database Management Systems
• Database management systems can be classified based on several criteria, such as
the data model, user numbers and database distribution, all described below.

1. Classification Based on Data Model

The types of DBMS based on data model are as follows:
i. Relational database.
ii. Object oriented database.
iii. Hierarchical database.
iv. Network database.

i. Relational database
• A relational database management system (RDBMS) is a system where data is
organized in two-dimensional tables using rows and columns.

• The most popular data model in use today is the relational data model. It is
based on SQL.

• Every table in a database has a key field which uniquely identifies each
record. 31
Types of Database Management Systems (cont.)
i. Relational database (cont.)
• Relational database management system software is available for personal
computers, workstation and large mainframe systems.

• Well-known DBMSs like Oracle, MS SQL Server, DB2 and MySQL support
this
model.

• In the below table, Std_ID, Name and city are called as attributes and their
values. Std_ID is a primary key attribute which uniquely identifies each record
in the student table.
Std_ID Name City

201 Bob Hyderabad

204 Ali Karachi

205 Ahmed Islamabad

32
 Types of Database Management Systems (cont.)
ii. Object oriented database

• It is a system where information or data is represented in the form of objects

which is used in object-oriented programming.

• It is a combination of relational database concepts and object-oriented

principles.

• Relational database concepts are concurrency control, transactions,

etc.

• OOPs principles are data encapsulation, inheritance, and

polymorphism.

• It requires less code and is easy to maintain.

• Some examples of object-oriented DBMSs are O2, Object Store and

Jasmine.
34
 Types of Database Management Systems (cont.)
ii. Object oriented database (cont.)

• The object oriented database is represented in diagram format below:

35
 Types of Database Management Systems (cont.)
Hierarchical database
 Types of Database Management Systems (cont.)
iv. Network database
Examples & Mappings of Database Models

44
 Examples & Mappings of Database Models (cont.)

Guess the model?

• Lets say we have few students and few courses and a course can be assigned to a
single student only, however a student take any number of courses so this
relationship becomes one to many.

45
 Examples & Mappings of Database Models (cont.)

Guess the model?

46
 Examples & Mappings of Database Models (cont.)

ER and Hierarchical Models

47
 Examples & Mappings of Database Models (cont.)

Guess the Model?

48
 Examples & Mappings of Database Models (cont.)

Hierarchical Model and Relational Model

49
 Examples & Mappings of Database Models (cont.)

Network Data Model

• The following diagram represents a network data model that shows that the Stores
entity has relationship with multiple child entities and the Transactions entity has
relationships with multiple parent entities. In other words, a network database
model allows one parent to have multiple child record sets and each record set can
be linked to multiple nodes (parents) and children.

50
 Examples & Mappings of Database Models (cont.)

Relational and hierarchical

51
 Examples & Mappings of Database Models (cont.)

OO

52
 Examples & Mappings of Database Models (cont.)

OO

53