Download Introduction Introduction: Database management system

Introduction
Databases vs. files
Basic concepts
Brief history of databases
Architectures & languages
Introduction: Database management system
User / Programmer
Database
System
Application program
Software to process queries
Software to access stored data
FU-Berlin, DBS I 2006, Hinze / Scholz
Stored
Data
Stored DB
definition
DBMS
Software
Database
(Meta-data)
1.2
1
Introduction: DBS versus File system
Why database systems?
Application
program
Application program
DBMS Software
Database
FU-Berlin, DBS I 2006, Hinze / Scholz
•
•
•
•
•
Files
Self-describing nature (schema as meta-data)
Program-data independence
Concurrent access (multiuser, data-sharing)
Multiple views (security)
Fault tolerant (recovery)
But sometimes DBS are an overkill
1.3
Introduction: DBS concepts & architecture
Important terms!
Data model:
ƒ Collection of concepts used to describe structure of a
database (data types, relation, constraints)
ƒ Basic operations for specifying retrieval and update
Conceptual models
ƒ Describes high-level concepts in DB design
ƒ Models subset of real world
student
attend
ƒ E.g., entity relationship model
FU-Berlin, DBS I 2006, Hinze / Scholz
name
Matr-nr
lecture
title
Physical (data)models
ƒ Logical description of implementation schema
ƒ Five models: network model, hierarchical model, relational
model, object-oriented, object-relational
1.4
2
Introduction: DBS concepts & architecture
Important terms!
Database schema
ƒ Description of DB structure
ƒ Stored as meta-data
ƒ Intensional schema
FName
Author
Name
Email
Müller
Katz
Maus
mueller@...
katz@...
piep@...
Database state
FU-Berlin, DBS I 2006, Hinze / Scholz
ƒ = database instance
ƒ Data in DB at particular moment
ƒ Extensional schema
Tina
Anna
Carla
1.5
Introduction: Early databases in the 60’s
Hierarchical model (e.g., IMS):
Data relationships in trees
classific1
catalogue
classific2
book1
author1
book2
author2
author1
book1
author3
book3
place1
place2
place1
place2
place2
Network model (e.g., Codasyl):
Data relationships in graphs
FU-Berlin, DBS I 2006, Hinze / Scholz
classific1
classific2
author1
book1
author2
book2
author3
book3
place1
place2
1.6
3
Introduction: relational databases
1970: Relational model (e.g., system R, Ingres, …)
Data in tables [E.F. Codd: The Relational Data Model]
classific1
classific2
author1
place1
place2
book1
book2
book3
author2
author3
Author
FName
FU-Berlin, DBS I 2006, Hinze / Scholz
Tina
Anna
Carla
Name
Müller
Katz
Maus
Email
mueller@...
katz@...
piep@...
1980: RDBMS everywhere, distributed DBS
1.7
Introduction: databases in the 90’s
1988: Active databases (e.g., HiPAC)
1990: Object- oriented DBMS (e.g., O2)
1992: Object- Relational DBMSs
1995: Wide scale distribution
1997: Semi-structured data, ... , XML / DB
199x: New application areas:
Data warehousing, Web and Internet
FU-Berlin, DBS I 2006, Hinze / Scholz
Integration with application software, e.g. SAP R3
uses Oracle (mostly) behind the curtains
New challenges: how to deal with text, pictures,
video-streams?
1.8
4
Introduction: dominating DBMS
Oracle
Informix (IBM)
Sybase
DB2 (IBM)
SQL-Server (Microsoft)
personal, low cost desktop DBS: Access (Microsoft)
FU-Berlin, DBS I 2006, Hinze / Scholz
MySQL open source (http://www.mysql.com/)
Postgres (http://www.postgresql.org/)
1.9
Introduction: 3-Schema-Architecture
Goal: separate physical aspects, logical data
structuring, and application views on the data
External level (views)
user-dependent view on data
user
user
applications
Conceptional level
FU-Berlin, DBS I 2006, Hinze / Scholz
= logical layer
logical database schema
Logical data structure
Internal level
Physical data structure
physical storage of data
1.10
5
Introduction: External Views
Example: hospital information system
ƒ managing data about patients, doctors, medication etc.
ƒ doctors must be able to read the diagnostics
ƒ administration must not read the results, but which kind
of diagnostics has been performed
⇒ Two user groups with different views
Advantages of external views
FU-Berlin, DBS I 2006, Hinze / Scholz
ƒ Access protection (data privacy)
ƒ Data presentation customized for user groups
ƒ Independence of users of conceptional schema
ƒ Time-consuming mapping
ƒ Not supported by all DBMS
1.11
Introduction: Data independence
Data independence
Important term!
ƒ DB level not influenced by changes at other DB level
ƒ Interfaces introduce levels of abstraction
Logical Data independence
ƒ external schema (level) independent of conceptual schema
(small changes in database schema invisible for users)
ƒ e.g., application independent from data not used by
application
FU-Berlin, DBS I 2006, Hinze / Scholz
Physical Data Independence
ƒ Conceptual schema independent of internal schema
ƒ e.g. hash, B-Tree or sequential access to records should
be transparent to the program (ignoring performance
impacts)
1.12
6
Introduction: User Groups
Various end users
ƒ Naïve end user: access via application program
ƒ Sophisticated end user: changing interactive DB-queries
Application Programmer
Implementation of complex DB-tasks embedded in
application programs
Database designer
Responsible for problem analysis, (physical) schema design,
user communication, view design (before DB implementation)
FU-Berlin, DBS I 2006, Hinze / Scholz
Database administrator
responsible for authoring access to DB, coordinating and
monitoring DB use, security, performance, backup
1.13
Introduction: Languages
Different languages levels of DBS:
Data Definition Language (DDL)
ƒ Definition of DB schema
Data Manipulation Language (DML)
Part of the
Data model
ƒ Query database
ƒ Update data (insert, change, delete)
FU-Berlin, DBS I 2006, Hinze / Scholz
Data Administration Language
ƒ Define access path
ƒ Adjust tuning and other parameters
1.14
7
Introduction: Languages & Interfaces
Interactive interfaces for DML
Interfaces provided by DBMS for data access, e.g,
ƒ Menu-based interfaces for browsing
ƒ Forms-based interfaces
ƒ Graphical user interface
ƒ Interface for DBA
Embedded DML
FU-Berlin, DBS I 2006, Hinze / Scholz
Application Programming Interface (API) of DBS for
executing commands and transferring the result data
ƒ Technically more demanding: result data my be very large
set of data, type systems may differ heavily
ƒ Most popular: Embedded SQL / C and SQLJ (Java)
1.15
Introduction: Mainframe Architecture
Traditional mainframe architecture
Transaction monitor
Applications
DBS
Terminals
Operating system
FU-Berlin, DBS I 2006, Hinze / Scholz
ƒ Transaction monitor queues requests, schedules
application programs (usually simple application logic)
ƒ Very efficient
ƒ Still in use today, e.g. flight reservation systems
1.16
8
Introduction: 2-tier Architecture
Two-tier architecture
Client workstation
(presentation,
requests, GUI)
Database server
Proprietary protocol
FU-Berlin, DBS I 2006, Hinze / Scholz
ƒ Used with fourth Generation Languages (4GL)
i.e. application specific non-procedural languages, easy
development of form-based application, e.g., SQL
ƒ Transaction support through database system
ƒ Used in medium size applications
ƒ Decreasing importance because of web-based presentation
and standard protocols (http)
1.17
Introduction: 3-tier Architecture
Three-tier Architecture
ƒ Separation of presentation, application logic and DB access
JDBC /
ESQL/
ODBC
http
Presentation
e.g web server
Browser
Applications
Database server
ƒ Middle tier needn’t be a web server:
Application server
FU-Berlin, DBS I 2006, Hinze / Scholz
implements presentation,
session control and business
logic (applications)
Applet
http
Database server
Data access transparent
for application programs
1.18
9
Introduction: DB Lifecycle
FU-Berlin, DBS I 2006, Hinze / Scholz
Requirements analysis
DB designer
Application programmer
Conceptual Design
DB designer
Application programmer
Logical Schema Design
Application programmer
DB administrator
Physical Schema Design
DB administrator
Administration
DB administrator
1.19
10