This document provides an overview of database systems and concepts. It discusses how a database management system (DBMS) stores and manages data, defines various DBMS functions like security management and query languages, and describes different approaches to database development like the systems development life cycle and prototyping. It also explains the three schema architecture including the external, conceptual, and internal schemas and different levels of data abstraction.

1. Chapter 1
Database Systems

2. •Logically related data stored in a single logical
data repository
• Physically distributed among multiple storage facilities
• DBMS eliminates most of file system’s problems
•Current generation DBMS software:
• Stores data structures, relationships between structures, and
access paths
• Defines, stores, and manages all access paths and
components
2
DATABASE SYSTEMS

3. 3
CONTRASTING DATABASE AND FILE SYSTEMS

4. 4
THE DATABASE SYSTEM ENVIRONMENT

5. 5
DBMS FUNCTIONS
Data dictionary management
• Data dictionary: Stores definitions of the data elements and their relationships
Data storage management
• Performance tuning: Ensures efficient performance of the database in terms of
storage and access speed
Data transformation and presentation
• Transforms entered data to conform to required data structures
Security management
• Enforces user security and data privacy

6. 6
DBMS FUNCTIONS
Multiuser access control
• Sophisticated algorithms ensure that multiple users can access the
database concurrently without compromising its integrity
Backup and recovery management
• Enables recovery of the database after a failure
Data integrity management
• Minimizes redundancy and maximizes consistency

7. 7
DBMS FUNCTIONS
Database access languages and application programming
interfaces
• Query language: Lets the user specify what must be done without having to
specify how
• Structured Query Language (SQL): De facto query language and data
access standard supported by the majority of DBMS vendors
Database communication interfaces
• Accept end-user requests via multiple, different network
environments

8. •SDLC
• System Development Life Cycle
• Detailed, well-planned development process
• Time-consuming, but comprehensive
• Long development cycle
•Prototyping
• Rapid application development (RAD)
• Cursory attempt at conceptual data modeling
• Define database during development of initial prototype
• Repeat implementation and maintenance activities with new
prototype versions
TWO APPROACHES TO DATABASE AND IS DEVELOPMENT

9. SYSTEMS DEVELOPMENT LIFE CYCLE
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design

10. SYSTEMS DEVELOPMENT LIFE CYCLE (CONT.)
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Planning Purpose–preliminary understanding
Deliverable–request for study
Database activity–
enterprise modeling and
early conceptual data
modeling

11. SYSTEMS DEVELOPMENT LIFE CYCLE (CONT.)
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Analysis
Purpose–thorough requirements analysis and
structuring
Deliverable–functional system specifications
Database activity–thorough
and integrated conceptual
data modeling

12. SYSTEMS DEVELOPMENT LIFE CYCLE (CONT.)
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Logical Design
Purpose–information requirements elicitation
and structure
Deliverable–detailed design specifications
Database activity–
logical database design
(transactions, forms,
displays, views, data
integrity and security)

13. SYSTEMS DEVELOPMENT LIFE CYCLE (CONT.)
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Physical Design
Purpose–develop technology and
organizational specifications
Deliverable–program/data
structures, technology purchases,
organization redesigns
Database activity–
physical database design (define
database to DBMS, physical
data organization, database
processing programs)

14. SYSTEMS DEVELOPMENT LIFE CYCLE (CONT.)
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Implementation
Purpose–programming, testing,
training, installation, documenting
Deliverable–operational programs,
documentation, training materials
Database activity–
database implementation,
including coded programs,
documentation,
installation and conversion

15. SYSTEMS DEVELOPMENT LIFE CYCLE (CONT.)
Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Maintenance
Purpose–monitor, repair, enhance
Deliverable–periodic audits
Database activity–
database maintenance,
performance analysis
and tuning, error
corrections

16. PROTOTYPING DATABASE METHODOLOGY

17. PROTOTYPING DATABASE METHODOLOGY

18. PROTOTYPING DATABASE METHODOLOGY

19. PROTOTYPING DATABASE METHODOLOGY

20. PROTOTYPING DATABASE METHODOLOGY

21. THE THREE SCHEMA ARCHITECTURE

22. •End users’ view of the data environment
•ER diagrams represent external views
•External schema: specific representation of an
external view
• Entities
• Relationships
• Processes
• Constraints
THE EXTERNAL MODEL

23. •External Schema/external view
• User Views
• Subsets of Conceptual Schema
• Can be determined from business-function/data entity
matrices
• DBA determines schema for different users.
• Describe the specific part, that the specific user group
is interested in and hides rest of the database, for the
user group.
• Has different external views for different users.
DATABASE SCHEMA

24. •Conceptual Schema
• Describe the structure of the whole database for a
community of users.
• Hide the details of physical storage structures and
concentrates on describing entities, data types,
relationships, user operations, and constraints
• E-R models
DATABASE SCHEMA

25. •Internal Schema
• Describes the physical storage of structure of the
database.
• Uses a physical data model to describe the complete
details of data storage and access paths for the
database.
• Physical structures
• Logical structures
DATABASE SCHEMA

27. DATA ABSTRACTION LEVELS

28. •Easy to identify specific data required to support
each business unit’s operations
•Facilitates designer’s job by providing feedback
about the model’s adequacy
•Ensures security constraints in database design
•Simplifies application program development
THE EXTERNAL MODEL (CONT’D.)

29. •Represents global view of the entire database
•All external views integrated into single global
view: conceptual schema
•ER model most widely used
•ERD graphically represents the conceptual schema
THE CONCEPTUAL MODEL

30. CONCEPTUAL MODEL SCHOOL

31. •Provides a relatively easily understood macro level
view of data environment
•Independent of both software and hardware
• Does not depend on the DBMS software used to
implement the model
• Does not depend on the hardware used in the
implementation of the model
• Changes in hardware or software do not affect
database design at the conceptual level
THE CONCEPTUAL MODEL (CONT’D.)

32. •Representation of the database as “seen” by the
DBMS
• Maps the conceptual model to the DBMS
•Internal schema depicts a specific representation of an
internal model
•Depends on specific database software
• Change in DBMS software requires internal model be
changed
•Logical independence: change internal model without
affecting conceptual model
THE INTERNAL MODEL

33. INTERNAL MODEL FOR SCHOOL

34. •Operates at lowest level of abstraction
• Describes the way data are saved on storage media
such as disks or tapes
•Requires the definition of physical storage and
data access methods
•Relational model aimed at logical level
• Does not require physical-level details
•Physical independence: changes in physical model
do not affect internal model
THE PHYSICAL MODEL

35. DATABASE CAREER OPPORTUNITIES
35

36. •Coronel, Morris, Database Systems Design,
Implementation and Management. 11th Edition
•Hoffer, J., Ramesh, V., Topi, H. (2013). Modern
Database Management 11th Edition, Prentice Hall.
REFERENCE

37. “
”
IF YOU CANNOT DO GREAT
THINGS, DO SMALL THINGS IN
A GREAT WAY.
Napoleon Hill

38. THANKS!
Any questions?
You can find me at
delfirome@yahoo.com
0929 804 2327
38