DBMS U1-Chap02 PDF

Copyright © 2004 Pearson Education, Inc.
Chapter 2
Database System
Concepts and
Architecture
By
SHRUTHI K

Data Models
 Data Model: A set of concepts to describe the structure of
a database, and certain constraints that the database should
obey.
 By structure of db we can understand the data types
relationships and constraints that hold for the data.
 Data Model Operations: Operations for specifying
database retrievals and updates by referring to the concepts
of the data model. Operations on the data model may
include basic operations and user-defined operations.
 Eg: CALCULATE_CGPA which can apply to the student
db.
 Basic operations like insert, delete, modify, or
retrieve,(lower,upper) builtin.
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Slide 2-3
Categories of data models
 Conceptual (high-level, semantic) data models:
Provide concepts that are close to the way many
users perceive data. (Also called entity-based or
object-based data models it gives what type of
data is stored.)
 Physical (low-level, internal) data models:
Provide concepts that describe details of how data
is stored in the computer.
 Implementation (representational) data models:
Provide concepts that fall between the above two,
balancing user views with some computer storage
details. Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Slide 2-4
Conceptual data model
 It uses the concepts such as entities, attributes and
relationships.
 Entity represents a real world object or concept.
 Eg: employee, student etc.
 Attribute represents some property of interest that
further describes the entity.
 Eg: employee name, salary.
 A relationship among two or more entities
represents an association among two or more
entities.
 Eg: works on relationship between an employee
and project.
Slide 2-5
Physical model
 How data is organized or stored in the
memory/files in the computer by
representing the information such as record
paths, record formats, record orderings.
 Access path is helps to search for particular
database.(efficiently).
Representational model
 It is used in old traditional DBMS.
 It uses relational datamodel, network model,
hierarchical data model.
Slide 2-6
Schemas versus Instances
• Database Schema: The description of a database.
Includes descriptions of the database structure and
the constraints that should hold on the database.
• It is described at the time of database design.
• Schema Diagram: A diagrammatic display of
(some aspects of) a database schema.
• Schema Construct: A component of the schema
or an object within the schema, e.g., STUDENT,
COURSE.
• Database Instance: The actual data stored in a
database at a particular moment in time. Also
called database state (or occurrence).
Slide 2-11
Database Schema Vs.
Database State
• Database State: Refers to the content of a database
at a moment in time.
• Initial Database State: Refers to the database when
it is loaded
• Valid State: A state that satisfies the structure and
constraints of the database.
• Distinction
• The database schema changes very infrequently. The
database state changes every time the database is updated.
• Schema is also called intension, whereas state is called
extension.
Slide 2-12
Slide 2-13
Slide 2-14
Three-Schema Architecture
• Specifying the architecture for database
systems called three schema architecture.
• Proposed to support DBMS characteristics
of:
• Program-data independence.
• Support of multiple views of the data.
• Self describing nature of database

Slide 2-15
Slide 2-16
• Defines DBMS schemas at three levels:
• Internal schema at the internal level to describe
physical storage structures and access paths. Typically
uses a physical data model.
• Conceptual schema at the conceptual level to describe
the structure and constraints for the whole database for
a community of users. Uses a conceptual or an
implementation data model.
• External schemas at the external level to describe the
various user views. Usually uses the same data model
as the conceptual level.

Slide 2-17
Mappings among schema levels are needed
to transform requests and data. Programs
refer to an external schema, and are mapped
by the DBMS to the internal schema for
execution.

Slide 2-18
Slide 2-19
Slide 2-20
Data Independence
• Logical Data Independence: The capacity to change the
conceptual schema without having to change the external
schemas and their application programs.
• Changing of conceptual schema can be done in two ways
• Expand the database(By addying the data item)
• Reduce the database(By removing the data item)
• Physical Data Independence: The capacity to change the

internal schema without having to change the conceptual
schema.

Slide 2-21
Data Independence
When a schema at a lower level is changed,
only the mappings between this schema
and higher-level schemas need to be
changed in a DBMS that fully supports data
independence.
The higher-level schemas themselves are
unchanged. Hence, the application
programs need not be changed since they
refer to the external schemas.
Slide 2-22
DBMS Languages
• Data Definition Language (DDL): Used by the
DBA and database designers to specify the
conceptual schema of a database. In many
DBMSs, the DDL is also used to define internal
and external schemas (views). In some DBMSs,
separate storage definition language (SDL) and
view definition language (VDL) are used to
define internal and external schemas.

Slide 2-23
DBMS Languages
• Data Manipulation Language (DML):
Used to specify database retrievals and
updates.
• DML commands (data sublanguage) can be
embedded in a general-purpose programming
language (host language), such as COBOL, C
or an Assembly Language.
• Alternatively, stand-alone DML commands can
be applied directly (query language).

Slide 2-24
DBMS Languages
• High Level or Non-procedural
Languages: e.g., SQL, are set-oriented and
specify what data to retrieve than how to
retrieve. Also called declarative languages.
• Low Level or Procedural Languages:
record-at-a-time; they specify how to
retrieve data and include constructs such as
looping.
Slide 2-25
DBMS Interfaces
• Stand-alone query language interfaces.
• User-friendly interfaces:
• 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
• Eg: Google search
• Speech Ip/Op interface
• Interface for parametric users: users often uses the same
set of operations that they invoke perform repeatedly.
Bank tellers uses the same functional keys to invoke
routine repetitive transactions so that minimal usage of
key strokes.
Slide 2-26
Other DBMS Interfaces
• Speech as Input (?) and Output
• Web Browser as an interface
• Parametric interfaces (e.g., bank tellers) using
function keys.
• Interfaces for the DBA:
• Creating accounts, granting authorizations
• Changing schemas or access path

Slide 2-27
Database System Utilities
• To perform certain functions such as:
• Loading data stored in files into a database. Includes
data conversion tools.
• Backing up the database periodically on tape.
• Backup can be used and restored the database in case of
catastropic failure.
• Reorganizing database files into different file
organisation structure to improve the performance.
• Report generation utilities.
• Performance monitoring utility monitors database usage
and provides statistics to the DBA.
• Performance monitoring utilities.
• Other functions, such as sorting, user monitoring, data
compression, etc.Copyright © 2004 Pearson Education, Inc. Slide 2-28
Database System Environment
 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 internals 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.
 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.
 Top part of Figure 2.3 It shows interfaces for 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.

Slide 2-29
 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.
 Casual users and persons with occasional need for information from
the database interact using interactive query interface.
– Menu-based or form-based interaction that may be used to
generate the interactive query automatically.
 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.
 Query optimizer is used for rearrangement and possible reordering of
operations, elimination of redundancies, and use of correct algorithms
and indexes during execution.
 Application programmers write programs in host languages such as
Java, C, or C++ that are submitted to a precompiler.

Slide 2-30
 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 object codes for the DML commands and
the rest of the program are linked, forming a canned
transaction whose executable code includes calls to the
runtime database processor.
 Canned transactions are executed repeatedly by parametric
users, who simply supply the parameters to the
transactions.
 Each execution is considered to be a separate transaction.
 An example is a bank withdrawal transaction where the
account number and the amount may be supplied as
parameters. Copyright © 2004 Pearson Education, Inc.
Slide 2-31
 The runtime database processor executes (1) the
privileged commands, (2) the executable query plans, and
(3) the canned transactions with runtime parameters.
 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.
 Concurrency control and backup and recovery systems
they are integrated into the working of the runtime
database processor for purposes of transaction
management.
 Client program that accesses the DBMS running on a
separate computer from the computer on which the
database resides.
 The former is called the client computer running a DBMS
client software and
Elmasri and the
Navathe, latterofisDatabase
Fundamentals called the
Systems, database
Fourth Edition server.
Slide 2-32
Slide 2-33
Centralized and Client-Server
Architectures
• Centralized DBMS: combines everything
into single system including- DBMS
software, hardware, application programs
and user interface processing software.

Slide 2-35
Basic Client-Server
Architectures
• Specialized Servers with Specialized
functions
• Clients
• DBMS Server

Slide 2-36
Specialized Servers with
Specialized functions:
• File Servers
• Printer Servers
• Web Servers
• E-mail Servers

Slide 2-37
Clients:
• Provide appropriate interfaces and a client-version
of the system to access and utilize the server
resources.
• Clients maybe diskless machines or PCs or
Workstations with disks with only the client
software installed.
• Connected to the servers via some form of a
network.
(LAN: local area network, wireless network,
etc.)
Slide 2-38
DBMS Server
• Provides database query and transaction
services to the clients
• Sometimes called query and transaction
servers

Slide 2-39
Two Tier Client-Server
Architecture
• User Interface Programs and Application
Programs run on the client side
• Interface called ODBC (Open Database
Connectivity – see Ch 9) provides an
Application program interface (API) allow
client side programs to call the DBMS.
Most DBMS vendors provide ODBC
drivers.
Slide 2-40
Two Tier Client-Server
Architecture
• A client program may connect to several DBMSs.
• Other variations of clients are possible: e.g., in
some DBMSs, more functionality is transferred to
clients including data dictionary functions,
optimization and recovery across multiple servers,
etc. In such situations the server may be called the
Data Server.

Slide 2-41
Three Tier Client-Server
Architecture
• Common for Web applications
• Intermediate Layer called Application Server or
Web Server:
• stores the web connectivity software and the rules and
business logic (constraints) part of the application used to
access the right amount of data from the database server
• acts like a conduit for sending partially processed data
between the database server and the client.
• Additional Features- Security:
• encrypt the data at the server before transmission
• decrypt data at the client
Slide 2-42
Classification of DBMSs
• Based on the data model used:
• Traditional: Relational, Network, Hierarchical.
• Emerging: Object-oriented, Object-relational.
• Other classifications:
• Single-user (typically used with micro-
computers) vs. multi-user (most DBMSs).
• Centralized (uses a single computer with one
database) vs. distributed (uses multiple
computers, multiple databases)
Slide 2-43
Classification of DBMSs
Distributed Database Systems have now
come to be known as client server based
database systems because they do not
support a totally distributed environment,
but rather a set of database servers
supporting a set of clients.

Slide 2-44
Variations of Distributed
Environments:
• Homogeneous DDBMS
• Heterogeneous DDBMS
• Federated or Multidatabase Systems

Slide 2-45

DBMS U1-Chap02 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DBMS U1-Chap02 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Copyright © 2004 Pearson Education, Inc.

Copyright © 2004 Pearson Education, Inc.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

• Physical Data Independence: The capacity to change the

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Vous aimerez peut-être aussi