Database Environment Chapter 2

Data Independence Sometimes the way data are physically organized depends on the requirements of the application. Result:  it is impossible to change the storage structure without affecting the application  this is typically a problem introduced by the file handling software, and not by the problem to solve Data independence is needed because :  different applications need different views on the same data  the database administrator must have the freedom to change the storage structure, file organization and access strategy

Definition of Data Independence Data independence is the independence of data and applications.  data structures can be modified without affecting applications  applications can be modified without affecting other applications A possibility to achieve this:  Three level database architecture

Three level database architecture  Conceptual level: Reflects the community user view  External level: Reflects the user view  Internal level: Close to the physical storage It is a framework describing general concepts not all database systems follow this architecture

ANSI-SPARC and CODASYL Three-level Architecture

ANSI-SPARC three-level Architecture Reasons for this architecture  user should have access to the same data, but have a customized view of the data  users should not have to deal directly with physical database storage details  the DBA should be able to change the database storage structure without affecting the users’ view  DBA should be able to change the conceptual or global structure of the database without affecting all users

External Level The user’s view of the database. This level describes that part of the database that is relevant to a particular user or group of users  number of different external views  familiar to or efficient for the user  part of the database can be hidden for certain users  different presentations of the same data (e.g. dates)  can include derived or calculated data, not stored in the database

Conceptual Level The community view of the database. This level describes what data is stored in the database and the relationships among the data.  Logical structure of the entire database as seen by the DBA, independent of any storage considerations  all entities, attributes and relationships  constraints on the data  semantic information about the data  security and integrity information  Supports all external views

Internal Level The physical representation of the database on the computer. This level describes how the data is stored in the database.  to achieve optimal run-time performance and storage space utilization  data structures and storage devices  file organization, indexes, …  general aspects  storage space allocation for data and indexes  record description for storage  record placement  data compression and data encryption techniques

Differences between Three Levels of ANSI-SPARC Architecture

Data Independence  Logical Data Independence.  Refers to immunity of external schemas to changes in conceptual schema.  Conceptual schema changes e.g. addition/removal of entities.  Should not require changes to external schema or rewrites of application programs.

Data Independence  Physical Data Independence  Refers to immunity of conceptual schema to changes in the internal schema.  Internal schema changes e.g. using different file organizations, storage structures/devices.  Should not require change to conceptual or external schemas.

Data Independence and the ANSI-SPARC Three-level Architecture

Database Languages  Data Definition Language (DDL)  Allows DBA or user to describe and name entitles, attributes and relationships required for the application.

Database Languages  Data Manipulation Language (DML)  Provides basic data manipulation operations on data held in the database.  Procedural DML - allows user to tell system exactly how to manipulate data.  Non-Procedural DML - allows user to state what data is needed rather than how it is to be retrieved.

Database Languages  Fourth Generation Language (4GL)  Query Languages  Forms Generators  Report Generators  Graphics Generators  Application Generators

Host Language Program DML-statements Procedural Language e.g. Pascal including DML-statements Pre-compiler Compiled DML module Program Call-statements 3GL Compiler Object-code Call

Data Model  Collection of concepts for describing data, relationships between data and constraints on the data in an organization.  Data Model comprises:  A structural part.  A manipulative part.  Possibly a set of integrity rules.

Conceptual modeling  The process of developing a conceptual data model that is  a complete and accurate representation of an organization's data requirements.  independent of implementation details.

Functions of a DBMS  Data Storage, Retrieval and Update.  Must furnish users with the ability to store, retrieve, and update data in the database.  A User-Accessible Catalog.  Must furnish a catalog in which descriptions of data items are stored and which is accessible to users.

Functions of a DBMS  Transaction Support  Must furnish a mechanism to ensure that either all the updates corresponding to a given transaction are made or that none of them are made.  Concurrency Control Services  Must furnish a mechanism to ensure that database is updated correctly when multiple users are updating the database concurrently.

Functions of a DBMS  Recovery Services  Must furnish a mechanism for recovering the database in the event that the database is damaged in any way.  Authorization Services  Must furnish a mechanism to ensure that only authorized users can access the database.

Functions of a DBMS  Support for Data Communication  Must be capable of integrating with communication software.  Integrity Services  Must furnish a means to ensure that both the data in the database and changes to the data follow certain rules.

Functions of a DBMS  Services to Promote Data Independence  Must include facilities to support the independence of programs from the actual structure of the database.  Utility Services  Should provide a set of utility services.

Components of a DBMS

 Query processor  Database manager (DM)  File manager  DML preprocessor  DDL compiler  Catalog manager

Components of Database Manager (DM)

 Authorization control  Command processor  Integrity checker  Query optimizer  Transaction manager  Scheduler  Recovery manager  Buffer manager

The Catalog  Catalog, meta-data, data dictionary, repository  names, types and sizes of data items  names of relationships  integrity constraints on the data  authorizations  usage statistics  schema mappings  Benefits  centrally stored meta-data  simpler communication  identification of redundancy and inconsistency  changes to the database can be recorded and followed-up  security can be enforced  integrity can be ensured  audit information can be provided