Data base Management System
Module-1
INTRODUCTION TO DATABASES
OVERVIEW OF DATABASE LANGUAGES AND ARCHITECTURES
CONCEPTUAL DATA MODELING USING ENTITIES AND RELATIONSHIPS
By:
Girish BG
Assistant Professor
Department of CSE,SJCIT
By: Girish BG, Department of CSE, SJCIT
1
Basic Definitions
•
Data: Known facts that can be recorded and have an implicit meaning.
•
Database: A collection of related data with an implicit meaning.
•
Mini-world or Universe of discourse (UoD): Some part of the real world about
which data is stored in a database. For example, student grades and transcripts
at a university.
•
Database Management System (DBMS): A collection of programs that enables
users to create and maintain database. DBMS is a general purpose software
system that facilitates the processes of defining, constructing, manipulating and
sharing databases among various users and applications.
•
Database System: The DBMS software together with the database. Sometimes,
the applications are also included.

Metadata : Database definition or Descriptive information is also stored by the
DBMS in the form of database catalog or dictionary.
2
Implicit Properties of database
•
Database represents some aspects of the real
world (miniworld), Changes to the miniworld are
reflected in database.
•
Database is logically coherent collection of data,
random assortment of data cannot be referred as
database.
• A DB is designed, built and populated with data for
specific purpose, it has an intended group of users
and some preconceived applications In which these
users are interested.
3
Typical DBMS Functionality
 Define a database : In terms of data types, structures
and constraints.
 Construct or Load the Database on a secondary
storage medium.
 Manipulating the database : Querying, generating
reports, insertions, deletions and modifications to its
content to reflect changes in the miniworld
 Sharing and Concurrent Processing by a set of
users and programs – yet, keeping all data valid and
consistent.
4
Conti….
Other functions of DBMS
– Protection or Security measures to prevent
unauthorized access
– Maintaining of the database for a longer period of
time by allowing the system to evolve as
requirements change over time.
5
A Simplified Database System
Environment
6
Example of a Database
(with a Conceptual Data Model)
• Some mini-world relationships:
– SECTIONs are of specific COURSEs
– STUDENTs take SECTIONs
– COURSEs have prerequisite COURSEs
– INSTRUCTORs teach SECTIONs
– COURSEs are offered by DEPARTMENTs
– STUDENTs major in DEPARTMENTs
Note: The above could be expressed in the ENTITY-RELATIONSHIP data model.
7
Example of a Database System
8
9
Main Characteristics of the Database Approach
• Self-describing nature of a database system
• Insulation between programs and data
• Data Abstraction
• Support of multiple views of the data
• Sharing of data and multiuser transaction processing
10
11
13
14
15
16
Database Users
Users may be divided into those who actually
use and control the content (called “Actors on
the Scene”) and those who enable the database
to be developed and the DBMS software to be
designed and implemented (called “Workers
Behind the Scene”).
17
Database Users
Actors on the scene
1. Database administrators: responsible for authorizing access
to the database, for co-coordinating and monitoring its use,
acquiring software, and hardware resources, controlling its
use and monitoring efficiency of operations.
2. Database Designers: responsible to define the content, the
structure, the constraints, and functions or transactions
against the database. They must communicate with the endusers and understand their needs.
3. End-users: they use the data for queries, reports and some
of them actually update the database content.
18
Categories of End-users
• Casual : access database occasionally when needed.
• Naive or Parametric : they make up a large section of the end-user
population. They use previously well-defined functions in the form of “canned
transactions” against the database. Examples are bank-tellers or reservation
clerks who do this activity for an entire shift of operations.
• Sophisticated : these include business analysts, scientists, engineers, others
thoroughly familiar with the system capabilities. Many use tools in the form of
software packages that work closely with the stored database.
• Stand-alone : mostly maintain personal databases using ready-to-use
packaged applications. An example is a tax program user that creates his or
her own internal database.
19
4.System Analysts and Application Programmers(Software Engineers):
System Analyst determine the requirements of end users, especially Naïve and
parametric end users and develop specifications for canned transactions that meet
these requirements.
Application Programmers implement these specifications as programs, then they
test, debug, document and maintain these canned transactions.
20
• Workers behind the scene
– DBMS System Designers and Implementers
– Tool Developers
– Operators and Maintenance Personnel
21
Advantages of Using the Database Approach
1.
Controlling redundancy in data storage and in development and
maintenance efforts.
2.
Restricting unauthorized access to data.
3.
Providing persistent storage for program Objects.
4.
Providing Storage Structures for efficient Query Processing
5.
Providing backup and recovery services.
6.
Providing multiple interfaces to different classes of users.
7.
Representing complex relationships among data.
8.
Enforcing integrity constraints on the database.
9.
Permitting Inferencing and Actions using rules.
22
23
24
25
26
27
28
29
30
31
32
33
Additional Implications of Using the Database Approach
•
Potential for enforcing standards:
– This is very crucial for the success of database applications in large organizations
Standards refer to data item names, display formats, screens, report structures,
meta-data (description of data) etc.
•
Reduced application development time:
– Incremental time to add each new application is reduced.
•
Flexibility to change data structures:
– Database structure may evolve as new requirements are defined.
•
Availability of up-to-date information:
– Very important for on-line transaction systems such as airline, hotel, car
reservations.
Economies of scale:
– By consolidating data and applications across departments wasteful overlap of
resources and personnel can be avoided.
•
34
Brief History of Database Applications
• Early Database Applications: The Hierarchical and Network Models
were introduced in mid 1960’s and dominated during the seventies. A
bulk of the worldwide database processing still occurs using these
models.
• Relational Model based Systems: The model that was originally
introduced in 1970 was heavily researched and experimented with in
IBM and the universities. Relational DBMS Products emerged in the
1980’s.
• Object-oriented applications: OODBMSs were introduced in late 1980’s
and early 1990’s to cater to the need of complex data processing in CAD
and other applications. Their use has not taken off much.
• Data on the Web and E-commerce Applications: Web contains data in
HTML (Hypertext markup language) with links among pages. This has
given rise to a new set of applications and E-commerce is using new
standards like XML (extended Markup Language).
35
When not to use a DBMS
•
Main inhibitors (costs) of using a DBMS:
– High initial investment and possible need for additional hardware.
– Overhead for providing generality, security, concurrency control, recovery, and
integrity functions.
•
When a DBMS may be unnecessary:
– If the database and applications are simple, well defined, and not expected to
change.
– If there are stringent real-time requirements that may not be met because of
DBMS overhead.
– If access to data by multiple users is not required.
•
When no DBMS may suffice:
– If the database system is not able to handle the complexity of data because of
modeling limitations
– If the database users need special operations not supported by the DBMS.
36
Data Models
• Data Model: A set of concepts to describe the structure of a database, and
certain constraints that the database should obey.
Or
A data model is a collection of concepts that can be used to describes structure
of a database- Provide necessary means to archive the abstraction
• structure of a database- we mean the data types , relationships and constraint
that apply to the data.
• Most data models also include a set of basic operations for specifying retrievals
and updates on the database.
37
38
39
40
Figure
Schema diagram for the database in
41
Three-Schema Architecture
• (1) use of a catalog to store the database description (schema)
so as to make it self-describing
• (2) insulation of programs and data (program-data and
program-operation independence)
•
(3) support of multiple user views.
• three-schema architecture, that was proposed to help
achieve and visualize these characteristics.
42
Three-Schema Architecture
43
Three-Schema Architecture
 Defines DBMS schemas at three levels:
Internal Schema
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.
Conceptual schema
which describes the structure of the whole database for a community of users.
The conceptual schema hides the details of physical storage structures and
concentrates on describing entities, data types, relationships, user operations, and
constraints.
External schema
The external or view level includes a number of external schemas or user views.
Each external schema describes the part of the database that a particular user
group is interested in and hides the rest of the database from that user group.
44
Data Independence
 The capacity to change the schema at one level of a database
system without having to change the system at the next higher
level.
 Two types of data independences:
◦ Logical Data Independence: The capacity to change the
conceptual schema without having to change the external
schemas and their application programs.
◦ Physical Data Independence: The capacity to change the
internal schema without having to change the conceptual
schema.
45
DBMS Languages
• Once the design of a database is completed and a DBMS is
chosen to implement the database, the first step is to specify
conceptual and internal schemas for the database and any
mappings between the two. In many DBMSs where no strict
separation of levels is maintained .
46
Database Languages
“User Required a medium to interact with database”
•
DDL - Data Definition Language
•
DML - Data Manipulation Language
•
DCL - Data Control Language
•
TCL – Transaction Control Language
47
48
49
50
DBMS Languages
• Data Manipulation Language (DML):
Once the database schemas are compiled and the
database is populated with data, users must have
some means to manipulate the database.
• Typical manipulations include retrieval, insertion,
deletion, and modification of the data.
51
There are two main types of DMLs.
1.
2.
high-level or nonprocedural DML
low level or procedural DML
A high-level or nonprocedural DML can be used on its own to specify complex
database operations concisely.
High-level DMLs, such as SQL, can specify and retrieve many records in a single
DML statement; therefore, they are called set-at-a-time or set-oriented DMLs.
A low level or procedural DML must be embedded in a generalpurpose programming language.
This type of DML typically retrieves individual records or objects from the database and
processes each separately.
Low-level DMLs are also called record-at-a-time DMLs because of this property.
52
DBMS Interfaces
1.
2.
3.
4.
5.
6.
7.
Menu-based, popular for browsing on the web
Forms-based, designed for naïve users
Graphics-based (Point and Click, Drag and Drop etc.)
Natural language: requests in written English
Speech as Input and Output
Web Browser as an interface
Parametric interfaces (e.g., bank tellers) using function
keys.
8. Interfaces for the DBA:
• Creating accounts, granting authorizations
• Setting system parameters
• Changing schemas or access path
53
54
55
56
57
58
59
60
61
62
63
The Database System Environment
DBMS Component Modules
The figure is divided into two parts. The top part
of the figure refers to the various users of the
database environment and their interfaces. The
lower part shows the internal modules of the
DBMS responsible for storage of data and
processing of transactions.
The database and the DBMS catalog are
usually stored on disk. Access to the disk is
controlled primarily by the operating system
(OS), which schedules disk read/write. Many
DBMSs have their own buffer management
module to schedule disk read/write, because
management of buffer storage has a considerable
effect on performance. Reducing disk read/write
improves performance considerably.
 A higher-level stored data manager module of
the DBMS controls access to DBMS information
that is stored on disk, whether it is part of the
database or the catalog.
64
 The DBA staff, casual users who work with
interactive interfaces to formulate queries,
application programmers who create programs
using some host programming languages, and
parametric users who do data entry work by
supplying parameters to predefined transactions.
 The DBA staff works on defining the database
and tuning it by making changes to its definition
using the DDL and other privileged commands.
 The DDL compiler processes schema
definitions, specified in the DDL, and stores
descriptions of the schemas (meta-data) in the
DBMS catalog.
The catalog includes information such as the
names and sizes of files, names and data types of
data items, storage details of each file, mapping
information among schemas, and constraints.
65
Casual users and persons with occasional need for information
from the database interact using the interactive query interface.
These queries are parsed and validated for correctness of the
query syntax, the names of files and data elements, and so on by a
query compiler that compiles them into an internal form.
 This internal query is subjected to query optimization. Among
other things, the query optimizer is concerned with the
rearrangement and possible reordering of operations, elimination of
redundancies, and use of efficient search algorithms during
execution.
It consults the system catalog for statistical and other physical
information about the stored data and generates executable code
that performs the necessary operations for the query and makes
calls on the runtime processor.
Application programmers write programs in host languages
such as Java, C, or C++ that are submitted to a precompiler.
The precompiler extracts DML commands from an application
program written in a host programming language. These
commands are sent to the DML compiler for compilation into
object code for database access. The rest of the program is sent to
the host language compiler.
The runtime database processor executes the privileged
commands, the executable query plans, and the canned transactions
with runtime parameters.
 It works with the system catalog and may update it with
statistics.
66
It also works with the stored data manager, which in turn
uses basic operating system services for carrying out low-level
input/output (read/write) operations between the disk and main
memory.
The runtime database processor handles other aspects of data
transfer, such as management of buffers in the main memory.
Some DBMSs have their own buffer management module
whereas others depend on the OS for buffer management. We
have shown concurrency control and backup and recovery
systems separately as a module
67
68
69
70
71
CONCEPTUAL DATA MODELING USING ENTITIES AND RELATIONSHIPS
72
Using High – Level Conceptual Data Models for Database
Design
The first step shown is requirements
collection and analysis. During this step, the
database designers interview prospective
database users to understand and document
their data requirements. The result of this
step is a concisely written set of users’
requirements. These requirements should be
specified in as detailed and complete a form as
possible.
 In parallel with specifying the data
requirements, it is useful to specify the known
functional requirements of the application.
These consist of the user defined operations
(or transactions) that will be applied to the
database, including both retrievals and updates.
73
Once the requirements have been collected and
analyzed, the next step is to create a conceptual
schema for the database, using a high-level
conceptual data model.
conceptual design-The conceptual schema is a
concise description of the data requirements of the
users and includes detailed descriptions of the entity
types, relationships, and constraints; these are
expressed using the concepts provided by the highlevel data model.
Because these concepts do not include
implementation details, they are usually easier to
understand and can be used to communicate with
non technical users.
The high-level conceptual schema can also be
used as a reference to ensure that all users’ data
requirements are met and that the requirements do
not conflict.
74
During or after the conceptual schema design,
the basic data model operations can be used to
specify the high-level user queries and operations
identified during functional analysis.
This also serves to confirm that the conceptual
schema meets all the identified functional
requirements. Modifications to the conceptual
schema can be introduced if some functional
requirements cannot be specified using the initial
schema.
The next step in database design is the actual
implementation of the database, using a commercial
DBMS.
75
Most current commercial DBMSs use an
implementation data model—such as the
relational (SQL) model—so the conceptual
schema is transformed from the high-level
data model into the implementation data
model. This step is called logical design or
data model mapping; its result is a database
schema in the implementation data model of
the DBMS.
The last step is the physical design phase,
during which the internal storage structures, file
organizations, indexes, access paths, and
physical design parameters for the database
files are specified.
In parallel with these activities, application
programs are designed and implemented as
database transactions corresponding to the
high-level transaction specifications.
76
Entity Types, Entity Sets, Attributes and Keys
77
Types of Attributes
 Composite versus simple(Atomic) Attributes
 Single Valued versus Multivalued Attributes
 Stored versus Derived Attributes
 Complex Attributes
 Null Values
78
79
80
81
82
83
84
 Eg: No two companies will have the same
name, so name attribute is the key attribute in
COMPANY.
 In ER diagrammatic notation, each key
attribute has its name underlined inside the
oval.
85
86
87
88
89
90
Example 1…
EMPLOYEE
WORKS_FOR
DEPARTMENT
e1
r1
d1
e2
r2
e3
e4
e5
r3
r4
e6
r5
e7
r6
d2
d3
r7
91
Example 2…
EMPLOYEE WORKS_ON
PROJECT
r9
e1
r1
e2
r2
e3
e4
e5
e6
e7
r3
r4
p1
p2
p3
r5
r6
r7
r8
92
93
94
95
1:1 Relationship
EMPLOYEE
MANAGES
e1
r1
e2
r2
e3
e4
e5
e6
e7
r3
.
DEPARTMENT
d1
d2
d3
.
.
96
1:N Relationship
EMPLOYEE
WORKS_FOR
DEPARTMENT
e1
r1
d1
e2
r2
e3
e4
e5
r3
r4
e6
r5
e7
r6
d2
d3
r7
97
M:N Relationship
EMPLOYEE
WORKS_ON
PROJECT
r9
e1
r1
e2
r2
e3
r3
e4
r4
e5
p1
p2
p3
r5
e6
r6
e7
r8
r7
98
Notations Used in ER Diagrams
Symbol
Meaning
ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
E1
E1
E2
R
1
R
R
TOTAL PARTICIPATION OF E2 IN R
N
E2
CARDINALITY RATIO 1:N FOR E1:E2 IN R
(min,max)
E
STRUCTURAL
CONSTRAINT
PARTICIPATION OF E IN R
(min,
max)
99
ON
100
101
102
103
104
E – R Diagram for COMPANY
105
106
107
108
109
110
ER Diagram For Library Database
111
ER Diagram For Order Database
112
ER Diagram For Movie Database
113
College Database:
114
ER DIAGRAM-EXAMPLES:
Consider the ER diagram shown in Figure 3.22 for part of a BANK
database. Each bank can have multiple branches, and each branch can
have multiple
accounts and loans.
a. List the strong (nonweak) entity types in the ER diagram.
b. Is there a weak entity type? If so, give its name, partial key, and
identifying
relationship.
c. What constraints do the partial key and the identifying relationship
of the weak entity type specify in this diagram?
d. List the names of all relationship types, and specify the (min, max)
constraint on each participation of an entity type in a relationship type.
Justify your choices.
115
116
Questions
1. What are the advantages of DBMS. Explain.
2. Explain the three-schema architecture with a neat
diagram.
3. With a neat diagram, explain the various components of
DBMS.
4. Explain the different ways of interacting with the
databases.
5. Explain the different types of attributes with examples for
each.
6. Write an E-R diagram for hospital database by considering
at least 5 entities.
7. Differentiate between specialization and generalization.
117