Learning Objectives Database Systems: • The Three-Level ANSI-SPARC Architecture • Database Languages Thomas Connolly, Carolyn Begg, Database System, A Practical Approach to Design Implementation and Management, 4th Edition, Addison Wesley • Data Models and Conceptual Modeling • Function & Components of DBMS

1-1 Chapter 2 Part One: Database Environment | 1 Chapter 2 Part One: Database Environment | 2

The Three-Level ANSI-SPARC Architecture The Three-Level ANSI-SPARC Architecture

• An early standard terminology and general architecture for • In 1975, The American National Standards Institute (ANSI) database systems produced in 1971 by Data Base Task Group Standards Planning and Requirements Committee (SPARC), (DBTG) and Conference on Data Systems and Languages ANSI/SPARC produced a similar terminology and and (CODASYL, 1971). recognized the need for a three-level approach with a system • The DBTG recognized the need for a two-level approach with a catalog: system view called the schema and user views called • External Level subschemas. • Conceptual Level • Internal Level

Chapter 2 Part One: Database Environment | 3 Chapter 2 Part One: Database Environment | 4 The Three-Level ANSI-SPARC Architecture The Three-Level ANSI-SPARC Architecture

Objectives • The users’ view of the External database. Level – All user should be able to access the same data. • Describes that part of database that is relevant to – A user’s view is immune to changes made in other views. each user. Conceptual – Users should not need to know physical database storage details. • Community view of the Level database. – The Database Administrator (DBA) should be able to change the • Describes what data is stored in database and database storage structures without affecting the users’ views. relationships among the Internal data. Level – The internal structure of the database should be unaffected by • Physical representation of changes to the physical aspects of storage. the database on the Physical computer. – The DBA should be able to change the conceptual structure of the • Describes how the data is Data Organzation database without affecting all users. stored in the database. Chapter 2 Part One: Database Environment | 5 Chapter 2 Part One: Database Environment | 6

External Schema External/Conceptual Mapping The Three-Level ANSI-SPARC Architecture NIM Name Semester

Course Code Course Name Credits Fees EXTERNAL LEVEL EXTERNAL

Conceptual Schema

NIM Name Semester CourseCode Course Name Credits Credits x fee

LEVEL CONCEPTUAL

Conceptual/ Internal Schema Internal Mapping Students KRS Courses

-NIM -NIM -CourseCode

LEVEL -Name -Semester -CourseName

-Address -CourseCode -CourseCredit INTERNAL INTERNAL Chapter 2 Part One: Database Environment | 7 Chapter 2 Part One: Database Environment | 8 Data Independence Data Independence

• A major objective for the three-level architecture is to provide data independence, which means that upper levels are unaffected by changes to lower levels. • There are two kinds of data independence: – logical independence: immunity of the external schemas to changes in the conceptual schema; – physical independence: immunity of the conceptual schema to changes in the internal schema.

Chapter 2 Part One: Database Environment | 9 Chapter 2 Part One: Database Environment | 10

Data Independence Database Languages

Logical Data Independence • A data sublanguage consists of two parts: a Data Definition changes to the conceptual schema, such as the addition or removal of new Language (DDL) and a Data Manipulation Language (DML). entities, attributes, or relationships, should be possible without having to • The DDL is used to specify the database schema. change existing external schemas or having to rewrite application rograms. • The DML is used to both read and update the database. Physical Data Independence • Database languages are called data sublanguages because they changes to the internal schema, such as using different file organizations or do not include constructs for all computing needs. storage structures, using different storage devices, modifying indexes, or • Many DBMSs have a facility for embedding the sublanguage in hashing algorithms, should be possible without having to change the a high-level programming language such as COBOL, Fortran, onceptual or external schemas. Pascal, Ada, ‘C’, C++, Java, or Visual Basic.

Chapter 2 Part One: Database Environment | 11 Chapter 2 Part One: Database Environment | 12 Database Language – Data Definition Language (DDL) Database Language – Data Definition Language (DDL)

• A language that allows the DBA or user to describe and name • The system catalog integrates the metadata,that is data that the entities, attributes, and relationships required for the describes objects in the database and makes it easier for those application, together with any associated integrity and security objects to be accessed or manipulated. constraints. • The metadata contains definitions of records, data items, and • The DDL is used to define a schema or to modify an existing other objects that are of interest to users or are required by the one. It cannot be used to manipulate data. DBMS. • The result of the compilation of the DDL statements is a set of • In practice, there is one comprehensive DDL that allows tables stored in special files collectively called the system specification of at least the external and conceptual schemas. catalog.

Chapter 2 Part One: Database Environment | 13 Chapter 2 Part One: Database Environment | 14

Database Language – Data Definition Language (DDL) Database Language – Data Man. Languange (DML)

• Used to set up, change and remove data structures from tables by • A language that provides a set of operations to support the basic using these instructions: data manipulation operations on the data held in the database. – create • Data manipulation operations usually include the following: – alter – insertion of new data into the database; – drop – modification of data stored in the database; – rename – retrieval of data contained in the database; – truncate – deletion of data from the database. • Data manipulation applies to the external, conceptual, and internal levels.

Chapter 2 Part One: Database Environment | 15 Chapter 2 Part One: Database Environment | 16 Database Language – Data Man. Languange (DML) Database Language – Data Man. Languange (DML)

• The part of a DML that involves data retrieval is called a query • Allow to enters new rows, changes existing rows, and removes language. unwanted rows from tables in the database, respectively using • The term ‘query’ is therefore reserved to denote a retrieval these instructions: statement expressed in a query language. – insert • There are two types of DML: procedural and non-procedural – update – – Procedural DMLs: allows the user to tell the system what data is delete needed and exactly how to retrieve the data. – merge – Non-procedural DMLs: allows the user to state what data is needed – select  data retrieval/query language rather than how it is to be retrieved.

Chapter 2 Part One: Database Environment | 17 Chapter 2 Part One: Database Environment | 18

Database Language – Data Man. Languange (DML) Database Language – 4th Generation Languange (4GL)

• The DBMS translates a DML statement into one or more • 4GL is non-procedural language that allow user to defines what procedures that manipulate the required sets of records. is to be done, not how. • Non-procedural languages are also called declarative • The user does not define the steps that a program needs to languages. perform a task, but instead defines parameters for the tools that • Relational DBMSs usually include some form of non-procedural use them to generate an application program. language for data manipulation, typically SQL (Structured • 4GL encompass: Query Language) or QBE (Query-By-Example). – presentation languages, such as query languages and report generators; • Non-procedural DMLs are normally easier to learn and use than – speciality languages, such as spreadsheets and database languages; procedural DMLs.

Chapter 2 Part One: Database Environment | 19 Chapter 2 Part One: Database Environment | 20 Database Language – 4th Generation Languange (4GL) Data Model

– application generators that define, insert, update, and retrieve data from • Schema is written using a data definition language and is written the database to build applications; in the data definition language of a particular DBMS. – very high-level languages that are used to generate application code. • The type of this language is too low level to describe the data • 4GL is non-procedural language that allow user to defines what requirements of an organization in a way that is readily is to be done, not how. understandable by a variety of users. • The require for a higher-level description of the schema: that is, a data model.

Chapter 2 Part One: Database Environment | 21 Chapter 2 Part One: Database Environment | 22

Data Model Data Model

• Data model: An integrated collection of concepts for describing • Purpose: to represent data in an understandable way. and manipulating data, relationships between data, and • Categories of data models include: constraints on the data in an organization. – Object-based; • A data model can be thought of as comprising three components: – Record-based; and 1. a structural part, consisting of a set of rules according to which – Physical. databases can be constructed; • 1st & 2nd categorie: used to describe data at the conceptual and 2. a manipulative part, defining the types of operation that are allowed external levels on the data; rd 3. possibly a set of integrity constraints, which ensures that the data is • 3 categorie: used to describe data at the internal level. accurate. Chapter 2 Part One: Database Environment | 23 Chapter 2 Part One: Database Environment | 24 Physical Data Model Conceptual Modeling

• Physical data models describe how data is stored in the • From an examination of the three-level architecture, we see that computer, representing information such as record the conceptual schema is the ‘heart’ of the database. structures, record orderings, and access paths. • It supports all the external views and is, in turn, supported by the • There are not as many physical data models as logical data internal schema. models, the most common ones being the unifying model and the • The internal schema is merely the physical implementation of frame memory. the conceptual schema. • The conceptual schema should be a complete and accurate representation of the data requirements of the enterprise.

Chapter 2 Part One: Database Environment | 31 Chapter 2 Part One: Database Environment | 32

Conceptual Modeling as Conceptual Data Model DBMS Functions

• Conceptual modeling, or conceptual database design, is the • Codd (1982) lists eight services that should be provided by any process of constructing a model of the information use in an full-scale DBMS + two more that might reasonably be expected enterprise that is independent of implementation details. to be available. (conceptual data model). 1. Data storage, retrieval, and update a DBMS must furnish users with the ability to store, retrieve, and update data in the database.

2. A user-accessible catalog a DBMS must furnish a catalog in which descriptions of data items are stored and which is accessible to users.

Chapter 2 Part One: Database Environment | 33 Chapter 2 Part One: Database Environment | 34 DBMS Functions DBMS Functions

3. Transaction support 6. Authorization services a DBMS must furnish a mechanism which will ensure either that all the updates a DBMS must furnish a mechanism to ensure that only authorized users can corresponding to a given transaction are made or that none of them is made. access the database. 4. Concurrency control services 7. Support for data communication a DBMS must furnish a mechanism to ensure that the database is updated a DBMS must be capable of integrating with communication software. correctly when multiple users are updating the database concurrently. 8. Integrity services 5. Recovery services a DBMS must furnish a means to ensure that both the data in the database and a DBMS must furnish a mechanism for recovering the database in the event that changes to the data follow certain rules. the database is damaged in any way.

Chapter 2 Part One: Database Environment | 35 Chapter 2 Part One: Database Environment | 36

DBMS Functions DBMS Components

+ 2 more Components of DBMS: • 9. Services to promote data independence Query processor, transforms queries into a series of low- a DBMS must include facilities to support the independence of programs from the level instructions directed to actual structure of the database. the database manager 10. Utility services • Database manager (DM), a DBMS should provide a set of utility services. accepts queries and examines the external and conceptual schemas to determine what conceptual records are required to satisfy the request.

Chapter 2 Part One: Database Environment | 37 Chapter 2 Part One: Database Environment | 38 DBMS Components DBMS Components • File manager, manipulates the • DDL compiler, converts DDL underlying storage files and statements into a set of tables manages the allocation of containing metadata. storage space on disk. • Catalog manager, manages • DML preprocessor, converts access to and maintains the DML statements embedded in system catalog. an application program into standard function calls in the host language.

Chapter 2 Part One: Database Environment | 39 Chapter 2 Part One: Database Environment | 40

Database Manager Database Manager Components of DM: • Integrity checker, checks that the • Authorization control, checks that the requested operation satisfies all user has the necessary authorization to necessary integrity constraints. carry out the required operation. • Query optimizer, determines an • Command processor, giving user the optimal strategy for the query execution. authority to carry out the operation once • Transaction manager, performs the the user has the necessary authorization required processing of operations it and then control is passed to the receives from transactions. command processor. • Scheduler, ensuring that concurrent operations on the database proceed without conflicting with one another. Chapter 2 Part One: Database Environment | 41 Chapter 2 Part One: Database Environment | 42 Database Manager • Recovery manager, ensures that the database remains in a consistent state in Database Systems: the presence of failures. Thomas Connolly, Carolyn Begg, Database System, A Practical Approach to Design Implementation and Management, 4th Edition, Addison Wesley • Buffer manager, responsible for the transfer of data between main memory and secondary storage, such as disk and tape. The buffer manager is sometimes known as the cache manager.

1-44 Chapter 2 Part One: Database Environment | 43 Chapter 2 Part One: Database Environment | 44