1. Database Design Chapter-2- Database System Concepts and Architecture
Reference:
Prof. Mona Mursi Lecture notes
Dr.Lilac Safadi Lecture notes

2. Architecture Evolution
DBMS was a tightly
integrated system
Mainframes replaced by hundreds
of distributed computers connected by a network
DBMS now is modular in design
with client- server architecture

3. Client–Server Architecture
Server Module
Handles data storage.
Access, search .. ect
Client 1
LAN
Server
(DBMS)
Database
Client 2
Client Module
Run on user computer
Application programs & user interface that access DB
Handles user interaction and supports GUI

4. Data Model
Data Abstraction : hiding details of data storage that are not needed by most DB users.
Data Model: a collection of concepts used to describe the structure of the DB and a set of operations for specifying retrieval and updates of the DB.
DB Structure :
Data types
Relationships
Constraints

5. Categories of Data Models
High Level
(Conceptual Data Model)
Provides concepts close to the way
Many users see data
Provides concepts may be understood
by end users but are not far from the
way the data is organized.
(Entities, Attributes, Relationships)
Relational Data Model widely used
Representational
(implementation Data Model)
Low Level
(Physical Data Model)
Details of how data is stored in
the computer. (Computer specialist)
(Records format, ordering, access paths : makes the search for a record more efficient)

6. Representational (implementation Data Model)
Entity: Represent a real-world objects or concepts. (ex: employee)
Attribute: Represent some property of interest that describes an entity. (ex: salary, name)
Relationship: among two or more entities. (ex: a works-on relationship between an employee and a project)

7. Database Schema

8. What is DB Schema? A description of the database (meta-data)
Covers only some aspects
E.g. name of record type, data items, some constraints
Not changed frequently
Specify when a new database defined
Meta-data = DBMS Catalog
Schema constructs: Objects in schema
Schema diagram : Convention to display the structure of each record but not the actual instance

9. Schema Diagram Name Student_Number Class Major
Schema Construct
STUDENT
Name Student_Number Class Major
COURSE
C_Name C_Number CreditHours Department
Note:
Schema diagram displays only some aspects of a schema.
Ex: does not show the data types nor the relationship between files.
Some conditions can not be represented .
EX: student’s majoring in computer science must take CS1310 before
the end of their sophomore year.

10. Instances and Schema Name Account Number Balance Layla 102 850 Maha
529
1933
Schema
The overall design
Of the DB
Instances
The data stored
In the database at any given time

11. Example: University Database
DB Schema
Schema Constructs
A DB Instance
Mar 4,2008

12. Three Levels of Database Abstraction
Subschema
Part of the schema
Controls what info can be seen
AS MANY AS NEEDED
View 1
View 2
View 3
View N
……..
Conceptual Level
Conceptual Schema
Ex: name, account, balance
ONLY ONE SCHEMA
Physical Schema
(files of records or structs) ONLY ONE SCHEMA
Physical Level

13. Database State
Database state : the data in the database at particular moment in time. (current set of occurrences or instances).
Every insert, delete, update will change the database state.
Important difference between database state and database schema.
Define a new DB => specify Database schema to the DBMS, At this point the database state is “empty state”. Database is populated or loaded with data => database state changes. At any time there is a current database state.

14. Database State
Valid state: every state of the database satisfies the structure and constraints specified in the schema.
The DBMS stores the structure and constraints (meta- data) in the DBMS catalog.
Schema Evolution : adding another data item to the schema. Ex: adding dateofbirth to the student schema.

15. Database Instances Data in the database at a particular time Instance
= snapshot
= database state
~= current set of occurrences
DB_state(i)
 insert/delete/update
 DB_state(i+1)

16. Schema, Instances & DB States
Define DB schema  DB_state(0) = empty state
DB_state(0)  populate  initial state
DB_state(i) is a valid state for all I
Satisfies the structure and the constraints defined in the schema
DB Schema = intention of the database
DB state = extension of the Schema

17. Three - Schema Architecture

18. DBMS Architecture and Data Independence
Characteristics of database approach:
Insulation of program and data (program-data and program-operation independence)
Support of multiple user views
Use of catalog
To achieve the previous characteristics => three schema architecture was proposed.
The goal was to separate the user applications and the physical database.

19. Visualization of Three-Schema Architecture

20. Three-Schema Architecture
Internal level: describes how data is stored. The way perceived by the DBMS & OS.
Conceptual level: describes what data stored in DB, and the relationships among the data. The way perceived by the DBA & programmers.
External level: describes the part of the DB that user is interested in. The way perceived by the end users.

21. Three-Schema Architecture
External
Level
View 1
View 2
Emp_No FName LName Dept_No
Staff_No LName Salary
EMPLOYEE
Emp_No CHAR(6)
FName CHAR(15)
LName CHAR(15)
Dept_No CHAR(3)
Salary NUMBER(5)
Conceptual
Level
PREFIX TYPE=BYTE(6),OFFSET=0
EMP# TYPE=BYTE(6),OFFSET=6, INDEX=EMPX
LNM TYPE=BYTE(15),OFFSET=12
FNM TYPE=BYTE(15),OFFSET=27
DPT# TYPE=BYTE(4),OFFSET=42
PAY TYPE=FULLWORD,OFFSET=46
Internal
Level

22. Mapping
Mapping is the process of transforming requests and results between the Internal, Conceptual & External levels.
Two types of mapping:
- External / Conceptual mapping
-Conceptual / Internal mapping

23. DBMS & Three- Schema Architecture
Not all DBMS support three-schema architecture because: the mapping between the levels require the catalog to be expanded to include information on how to map requests and data among the levels.
=> this requires a software to accomplish the mapping.
=>may cause overhead during compilation or execution of a query or a program & time consuming.

24. Data Independence

25. Data Independence
Data independence: is the ability to modify a schema definition in one level without affecting a schema definition in the next higher level.
Two levels of data independence:
Logical data independence
Physical data independence

26. Data Independence External Schema External Schema External Schema
External/Conceptual
Mapping
Logical data Independence
Conceptual
Schema
Conceptual/Internal
Mapping
Physical data Independence
Internal
Schema

27. 1- Logical data independence
The ability to change the conceptual schema without affecting the external schemas. (application programs)
Ex: adding/ removing a record or a data item
The external schema that refer to the remaining data should not be affected.

28. 2- Physical data independence
The ability to change the internal schema without affecting the conceptual or external schemas.
This change might be for reorganizing the physical files. EX: creating new access structures to improve the performance of retrieval or update.( i.e. change in the physical files does not affect the queries)

29. Database Languages

30. Purpose of a Database Language
DDL (Data Definition Languages)
Conceptual schema
Internal schemas (when schema separation is not clear)
External schema (in most DBMSs)
SDL (Store Definition Languages)
Internal schema
VDL (View Definition Languages)
External view
DML (Data Manipulation Languages)
To manipulate the populated data
Modern DB  All in one  (E.g. SQL)
Separate SDL

31. Data Definition Language (DDL)
DDL is a descriptive language for defining the database schema
DDL compiler generates meta-data stored in a the data dictionary

32. Data Manipulation Language (DML)
DML is a language for retrieving and updating (insert, delete, & modify) the data in the DB
Two classes of languages
– Procedural: user specifies what data is required and how to get those data
– Nonprocedural: user specifies what data is required without specifying how to get those data (e.g. SQL)

33. Database Languages DBMS
DBMS have a facility for embedding DDL & DML (sub-languages) in a High-Level Language (COBOL,PASCAL, C), which in this case is considered a host language.
C,C++,Lisp,..
Application
Program
DBMS
Call to DB
Local Vars
(memory)

34. Where the DML is Used? When DML is embedded in program
Programming Language  host language
DML  data sub language
For interactive queries
DML  query language
General users
User friendly interfaces

35. DBMS Interfaces Menu- based Form- based Graphic user interface
Natural Language interface
Interface for parametric users
Interfaces for DBA

36. Type of interface
What is viewed?
Types of users
When it’s used?
Menu- based
Menus
No need to know a query language
Unstructured, exploratory manner
Form- based
Forms
Naïve users
Data entry , retrieve a record
Graphic user interface
Menus & forms , schemas
Manipulated by queries
Natural Language interface
Written language ex: English
Interface for parametric users
People who have to do limited range of operations repeatedly
Limit the number of key strokes (short cuts, hotkeys)
Interfaces for DBA
Privileged commands
DBA Staff
Creating accounts, setting the system

37. The Database System Environment

38. Software Components of a DBMS
DBMS Component Modules
Database System Utilities
Tools
Application Environments

39. DBMS Component Modules (1/2)

40. DBMS Component Modules (2/2)
Disk access control
OS:DB & catalog are stored on disk .Access to disk is controlled by OS which schedules disk input/output.
Stored Data Manager: controls access to DBMS information stored in the disk.
Compilers
DDL Compiler : process schema definition specified in the DDL, and stores the description of the schema (meta-data) in the DBMS catalog.
Query Compiler: handles high- level queries that are entered interactively.
DML Compiler
Precompiler /Host language compiler: extracts DML commands from an application program written in a host programming language. These commands are sent to the DML complier for compilation into object code for database access.
Handling DB access at runtime
Runtime database processor

41. Database System Utilities
Loading: load/transfer existing data files (e.g. text files or sequential files) into the database.
Backup: backup copy of the database by dumping the entire databases onto tape.
File reorganization: to improve performance
Performance Monitoring: monitors database usage and provides statistics to the DBA.

42. Tools
CASE( Computer Aided Software Engineering Tools): used in the design phase of database system. Used by DB designers/DBA/users
Examples:
Oracle’s Designer/Developer
Powersoft’s S- Designer tool.
Information Engineering Facility (IEF) to implement the ER.
Data repository systems (Information repository)
Used in large organizations, accessed directly by users or DBA
Stores :
Catalog information (schema, constraints).
Design decisions, Usage standards , application program descriptions and user information

43. Application Development Environments
E.g. PowerBuilder/JBuilder
Supports
Development of database applications
Database design
GUI development
Querying and updating
Application program development

44. DBMS Classifications

45. DBMS Classification Based on Data Model
Relational data model
Hierarchical data model
Network data model
Example of
network data model

46. DBMS Classification Based on Number of Sites (view of control)
Centralized systems
Distributed DBMSs (DDBMS)
Homogeneous DDBMS
Heterogeneous DBMS (Federated DBMS/multi-database systems)

47. Chapter -2- Summary Data Model Database schema
Database state, instances
Three Schema Architecture
Mapping
Data Independence
Database Languages & Interfaces
The Database System Environment
DBMS Classifications