ANSI-SPARC 3-Level

Architecture

• ANSI-SPARC

• American National Standards Institute - Standards Planning And Requirements Committee

• ANSI-SPARC

• First proposed in 1975, but never became a formal standard.

• Most modern commercial DBMS are based on this system.

• The objective of the three-level architecture is to separate the users’ view(s) of the database from the way that it is physically represented. This is desirable since:– It allows independent customised user views: Each user should be

able to access the same data, but have a different customised view of the data. These should be independent: changes to one view should not affect others.

– It hides the physical storage details from users: Users should not have to deal with physical database storage details. They should be allowed to work with the data itself, without concern for how it is physically stored.

– The database administrator should be able to change the database storage structures without affecting the users’ views: From time to time rationalisations or other changes to the structure of an organisation’s data will be required.

– The internal structure of the database should be unaffected by changes to the physical aspects of the storage: For example, a changeover to a new disk.

– The database administrator should be able to change the conceptual or global structure of the database without affecting the users: This should be possible while still maintaining the desired individual users’ views.

• External Level– Users view of the database

• Conceptual Level– What data is stored and its relationships

• Internal Level– Physical presentation of the data

ANSI/SPARC 3-Level Architecture

• Each level consists of one or more views of underlying data

• these views are described by SCHEMAs (Metadata)

• A DB consists of the actual data, plus an internal schema, a conceptual schema and several external schema

• Schemas are stored in the system catalogue

Schemas

External Level

Conceptual Level

Internal Level

ANSI/SPARC 3-Level Architecture

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

DataDefinition

DataManipulation

DataAdministration

Associated Languages

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

DataDefinition

DataManipulation

DataAdministration

Associated Languages

• Each level consists of one or more views of underlying data

• these views are described by SCHEMAs (Metadata)

• A DB consists of the actual data, plus an internal schema, a conceptual schema and several external schema

• Schemas are stored in the system catalogue

Schemas

The threelevels in

detail

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

DataDefinition

DataManipulation

DataAdministration

Associated Languages

• Provides the users with different ways of viewing the data

• Each user or group of users has their own way of viewing the data

• This level is not at all concerned with how the data is physically stored

• They are very LOGICAL VIEWS

External Level

• All users access the DB via an external via an external view, defined at the external level

• External views are not disjoint; they can overlap

• External schemas are defined using a DATA DEFINITION LANGUAGE or a VIEW DEFINITION LANGUAGE

External Level

• There are different interfaces at the external level for the various user classes– application programmers– on-line terminal users– database administrators

External Level

• Application Programmers Interface

• Application programmers are responsible for developing routine applications

• their programs typically involve accessing different parts of the DB

• They need to be familiar with the DB structure as defined in the system catalogue

• They view the data through programming language data structures

External Level

• Application Programmers Interface

• The DATA MANIPULATION LANGUAGE through which programmers read from, write to and update the DB is embedded in the application program

• Query languages which support the needs of the end-users are not sufficiently powerful for “heavy duty” computing

• Application programmers need the processing power and expressiveness of 3rd or 4th generation languages

• An important part of the job of the application programmer is to develop customised interfaces to support naïve end-users

• often done by means of CANNED TRANSACTIONS

External Level

• End-User Interface

• End-users require customised interfaces tailored to their requirements and working environment

• Casual users require user-friendly interfaces with on-line help, etc.

• Regular end-users (e.g. travel agents, banktellers) requires interfaces which are quick to use

• DATA MANIPULATION LANGUAGE used by end-users is generally SET-ORIENTED, i.e. it can operate on several records at once

• For example, to retrieve the names of all the patients who are allergic to penicillin using SQL

• SQL is the most widely-used set-oriented query language

External Level

PrescriptionID

DoctorID

PatientID

DrugID

Date

Frequency

User Interface

• Database Administrator

• DBA needs special access privileges e.g. to update the system catalogue

• DBA is concerned with conceptual and internal levels unlike end-users and application programmers

External Level

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

DataDefinition

DataManipulation

DataAdministration

Associated Languages

• Lies at the heart of the DBMS architecture

• Provides a mapping between the external and internal levels of the DB

• Represents the community (global) view of the DB

• Also a LOGICAL VIEW

Conceptual Level

Prescription

Drug

Patient

Doctor

• Closest to the organisations view of the data resource

• unconstrained by data structures supported by the application programming languages (external level) or by particular file organisation techniques (internal level)

• avoids duplication of information about customers if they have several accounts

Conceptual Level

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

DataDefinition

DataManipulation

DataAdministration

Associated Languages

• Ideally should be one step removed from the physical storage, i.e., should not deal with things in terms of block or physical device characteristics

• Is concerned with indexes and other mechanisms for providing rapid access to the data

• Most DBMSs make use of the OSs file management facilities

Internal Level

Doctor

Name

Patient

Name

Drug

Name Date

Frequency

(per day)

Dr. Lewis

Zimmerman

Tom

Paris Tri-Ox

42231.2

2

Dr. Julian

Bashir

Odo Hyronalin 45432.1

3

Dr. Lewis

Zimmerman

Harry

Kim

Tri-Ox 42235.2

7

Dr. Beverly

Crusher

Lt. Data Hyronalin 45912.3

1

Dr. Julian

Bashir

Odo Synaptizine 48796.6

2

Dr. Lewis

Zimmerman

Tom

Paris

Priaxate 42765.5

90

Dr. Lewis

Zimmerman

Tom

Paris

Tri-Ox 42604.4

5

Dr. Lewis

Zimmerman

Katherine

Janeway

Hyronalin 45673.4

4

Dr.

Phlox

T’Pol Tri-Ox 37389.5

3

Dr. Lewis

Zimmerman

Dr. Beverly

Crusher

Dr. Julian

Bashir

Dr.

Phlox

External Level

Conceptual Level

Internal Level

ExternalSchema 1

ExternalSchema n

ConceptualSchema

InternalSchema

ANSI/SPARC 3-Level Architecture

DataDefinition

DataManipulation

DataAdministration

Associated Languages