dr. amr mahmoud tolba

8/14/2019 Dr. Amr Mahmoud Tolba

1/36

Copyright 2004 Pearson Education, Inc.

Instructor

Dr. Amr Mahmoud TolbaOffice No : 106 Floor 7Website: http://faculty.ksu.edu.sa/atolba


2/36


Chapter 2

Database SystemConcepts andArchitecture


3/36

Slide 2-3Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition


Data Models

Data Model : A set of concepts to describe thestructure of a database ( the data types, relationships and constraintsthe data types, relationships and constraintsthat should hold for the datathat should hold for the data ), and certain constraints that thedatabase should obey.Data Model Operations : Operations forspecifying database retrievals and updates byreferring to the concepts of the data model.Operations on the data model may include basicoperations and user-defined operations . (An example of An example of useruser --define operation isdefine operation is COMPUTECOMPUTE --GPAGPA which can be applied to thewhich can be applied to the StudentStudent objectobject )


4/36



Categories of Data Models

Conceptual (high-level , semantic ) data models:Provide concepts that are close to the way manyusers perceive data. (Also called entity-based orobject-based data models.)Physical (low-level , internal ) data models:Provide concepts that describe details of how datais stored in the computer.Implementation (representational ) data models:Provide concepts that fall between the above two,balancing user views with some computer storage

details.


5/36



Data Models

Physicalmodel

Logicalmodel

Conceptual

model

Hardware dependentSoftware dependent

Hardware independentSoftware dependent

Hardware independent

Software independent

(low-level , internal )data models

(Representational )data models

(high-level , semantic )

data models


6/36



Data ModelsObject-based conceptual model

Entity-Relationship

Object-Oriented Semantic Functional

- Binary

Record-based logical models

Relational model Network model Hierarchical model


7/36



Data Models

Staff_No LName Salary Brn_No Brn_No Street Tel_No

St1 Name1 7000 1St2 Name2 4000 1St3 Name3 6500 2St4 Name4 3000 3

1 Olayaa 46300002 Malaz 47800003 Rawda 2310000

St1 Name1 7000 Olayaa 4630000

St2 Name2 4000

St3 Name3 6500

St4 Name4 3000

Malaz 4780000

Rawda 2310000

RelationalModel

Network

Model


8/36



Data Models

St3 Name3 6500

HierarchicalModel

St1 Name1 7000 St2 Name2 4000

St4 Name4 3000

Olayaa 4630000Malaz 4780000 Rawda 2310000


9/36



Schemas versus Instances Database Schema : The description of a database.

Includes descriptions of the database structure andthe constraints that should hold on the database.

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 . Alsocalled database state (or occurrence ).


10/36



Database Schema Vs.Database State Database State: Refers to the content of a databaseat 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 . Thedatabase state changes every time the database is updated.

Schema is also called intension , whereas state is called

extension .


11/36



Three-Schema Architecture

Proposed to support DBMS characteristicsof: Program-data independence . Support of multiple views of the data.


12/36




Database

ExternalLevel

InternalLevel InternalDescription

ConceptualDescription

View 2 View nView 1

User 1 User 2 User n

Conceptual

Level


13/36




Emp_No FName LName Dept_No Staff_No LName Salary

View 1 View 2

InternalLevel

ConceptualLevel

EMPLOYEEEmp_No CHAR(6)FName CHAR(15)LName CHAR(15)

Dept_No CHAR(3)Salary NUMBER(5)

PREFIX TYPE=BYTE(6),OFFSET=0

EMP# TYPE=BYTE(6),OFFSET=6, INDEX=EMPXLNM TYPE=BYTE(15),OFFSET=12FNM TYPE=BYTE(15),OFFSET=27DPT# TYPE=BYTE(4),OFFSET=42PAY TYPE=FULLWORD,OFFSET=46

ExternalLevel


14/36


15/36




Mappings among schema levels are neededto transform requests and data. Programsrefer to an external schema, and are mappedby the DBMS to the internal schema forexecution.


16/36



Data Independence

Logical Data Independence : The capacityto change the conceptual schema withouthaving to change the external schemas andtheir application programs.

Physical Data Independence : The capacity

to change the internal schema withouthaving to change the conceptual schema.


17/36



Data Independence

When a schema at a lower level is changed,only the mappings between this schemaand higher-level schemas need to bechanged in a DBMS that fully supports dataindependence. The higher-level schemasthemselves are unchanged . Hence, theapplication programs need not be changedsince they refer to the external schemas.


18/36



Data Independence

InternalSchema

ConceptualSchema

ExternalSchema ExternalSchemaExternalSchema

External/ConceptualMapping

Conceptual/InternalMapping

Logical data Independence

Physical data Independence


19/36



DBMS Languages

Data Definition Language (DDL ): Used by theDBA and database designers to specify theconceptual schema of a database. In many

DBMSs, the DDL is also used to define internaland external schemas (views). In some DBMSs,separate Storage Definition Language (SDL ) andView Definition Language (VDL ) are used todefine internal and external schemas.


20/36



DBMS Languages

Data Manipulation Language (DML ):Used to specify database retrievals andupdates.

DML commands ( data sublanguage ) can beembedded in a general-purpose programminglanguage ( host language ), such as COBOL, Cor an Assembly Language.

Alternatively, stand-alone DML commands canbe applied directly ( query language ).


21/36



DBMS Languages

High Level or Non-proceduralLanguages: e.g., SQL, are set-oriented andspecify what data to retrieve than how toretrieve. Also called declarative languages.

Low Level or Procedural Languages:

record-at-a-time; they specify how toretrieve data and include constructs such aslooping.


22/36



DBMS Interfaces Stand-alone query language interfaces. Programmer interfaces for embedding DML in

programming languages: Pre-compiler Approach

Procedure (Subroutine) Call Approach User-friendly interfaces:

Menu-based, popular for browsing on the web

Forms-based, designed for nave users Graphics-based (Point and Click, Drag and Drop etc.) Natural language: requests in written English Combinations of the above


23/36



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

Setting system parameters Changing schemas or access path


24/36


25/36



Other Tools

Data dictionary / repository : Used to store schema descriptions and other information suchas design decisions, application program descriptions, userinformation, usage standards, etc.

Active data dictionary is accessed by DBMS software andusers/DBA.

Passive data dictionary is accessed by users/DBA only.

Application Development Environments and CASE(computer-aided software engineering) tools:

Examples Power builder (Sybase), Builder (Borland)


26/36



Centralized and Client-ServerArchitectures

Centralized DBMS: combines everythinginto single system including- DBMSsoftware, hardware, application programs

and user interface processing software.


27/36



Basic Client-ServerArchitectures

Specialized Servers with Specializedfunctions Clients DBMS Server


28/36



Specialized Servers withSpecialized functions:

File Servers Printer Servers Web Servers E-mail Servers


29/36



Clients:

Provide appropriate interfaces and a client-versionof the system to access and utilize the serverresources.

Clients maybe diskless machines or PCs orWorkstations with disks with only the clientsoftware installed.

Connected to the servers via some form of anetwork.

(LAN: local area network, wireless network,etc.)


30/36



DBMS Server

Provides database query and transactionservices to the clients Sometimes called query and transaction

servers


31/36



Two Tier Client-ServerArchitecture

User Interface Programs and ApplicationPrograms run on the client side Interface called ODBC (Open Database

Connectivity see Ch 9 ) provides anApplication program interface (API) allowclient side programs to call the DBMS.Most DBMS vendors provide ODBCdrivers.


32/36



Two Tier Client-ServerArchitecture

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 .


33/36



Three Tier Client-ServerArchitecture

Common forWeb applications

Intermediate Layer called Application Server orWeb Server: stores the web connectivity software and the rules and

business logic (constraints) part of the application used toaccess the right amount of data from the database server

acts like a conduit for sending partially processed databetween the database server and the client.

Additional Features- Security: encrypt the data at the server before transmission decrypt data at the client


34/36



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 onedatabase) vs. distributed (uses multiplecomputers, multiple databases)


35/36



Classification of DBMSs

Distributed Database Systems (DDS) havenow 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 serverssupporting a set of clients.


36/36



Variations of DistributedEnvironments:

Homogeneous DDBMS Heterogeneous DDBMS Federated or Multidatabase Systems

dr. amr mahmoud tolba

Documents