Database System

Architecture
(Part 2)
DATABASE SCHEMA
✗ A schema is quite simply a group of
related objects in a database.
✗ Within a schema, objects that are
related have relationships to one
another.

2
DATABASE SCHEMA
✗ There is one owner of a schema, who
has access to manipulate the structure of
any object in the schema.
✗ A schema does not represent a person,
although the schema is associated with a
user account that resides in the database.

3
DATABASE SCHEMA
✗ Three models associated with a schema:
✗ The conceptual model, also called the
logical model, is the basic database
model, which deals with organizational
structures that are used to define
database structures such as tables and
constraints.

4
DATABASE SCHEMA
✗ Example

5
DATABASE SCHEMA
✗ Example

6
DATABASE SCHEMA

✗ The internal model, also called the

physical model, deals with the physical
storage of the database, as well as
access to the data, such as through
data storage in tables and the use of
indexes to expedite data access.

7
DATABASE SCHEMA

✗ The internal model, also called the

physical model, deals with the physical
storage of the database, as well as
access to the data, such as through
data storage in tables and the use of
indexes to expedite data access.

8
DATABASE SCHEMA
✗ Example

9
DATABASE SCHEMA
✗ Example

10
DATABASE SCHEMA

✗ The external model, or application

interface, deals with methods through
which users may access the schema,
such as through the use of a data input
form. The external model allows
relationships to be created between
the user application and the data
model.
11
DATABASE SCHEMA
✗ Example

12
DATABASE ARCHITECTURE

13
DATABASE ARCHITECTURE

14
DATABASE ARCHITECTURE

15
DATA INDEPENDENCE
✗ The ability to modify a scheme definition in
one level without affecting a scheme
definition in a higher level is called data
independence .
✗ There are two kinds.
✗ Physical data independence
✗ Logical data independence

16
DATA INDEPENDENCE
✗ Physical Data Independence
✗ The ability to modify the physical
scheme without causing application
programs to be rewritten.
✗ Modifications at this level are
usually to improve performance.

17
DATA INDEPENDENCE
✗ Logical Data Independence
✗ The ability to modify the conceptual
scheme without causing application
programs to be rewritten.
✗ Usually done when logical structure
of database is altered.

18
DB DEVELOPMENT LIFE CYCLE
✗ Database planning
✗ The first step in the planning process is to decide
what data to collect and how to organize it. The
planning data will be stored in the CASE tool
repository, and the project team must define the
objects (or entries), and the relationships among
those objects. The CASE tools provide a database
management system (DBMS) for defining, storing
and retrieving the data in the planning database.

19
DB DEVELOPMENT LIFE CYCLE
✗ There are six entries. Each entity in turn is
broken down into several levels, as
appropriate. The entities shown in this
figure are the following:
✗ Organization: information on
organizational positions as the
corporate, division, department and
group level.
20
DB DEVELOPMENT LIFE CYCLE
✗ Function: information on organizational
functions, processes, and activities (we define
these terms in the next section).
✗ Critical success factors (CSFs): information on
those areas where things must go right for the
company to succeed.
✗ Data: information on data requirements
throughout the organization (subcategories
are entries, records, and elements).
21
DB DEVELOPMENT LIFE CYCLE
✗ System: information on the organization’s
automated information systems (present and
proposed).
✗ Project: information about candidate projects
that will be considered by the organization.

22
DB DEVELOPMENT LIFE CYCLE
✗ System Definition
✗ Scope
✗ Parameters
✗ Application areas
✗ User groups
✗ Discovery prototyping

23
DB DEVELOPMENT LIFE CYCLE
✗ Information Needs/Requirements Analysis
✗ Requirements Discovery Methods
■ Collecting facts from existing documentation
■ Research and site visits
■ Questionnaires
■ Interviews
■ Discovery prototyping

24
DB DEVELOPMENT LIFE CYCLE
✗ Goals of Requirements Analysis
✗ To determine the data requirements of the database in terms
of primitive objects.
✗ To classify and describe the information about these objects.
✗ To identify and classify the relationships among the objects.
✗ To determine the types of transactions that will be executed on the
database and the interactions between the data and the
transactions.
✗ To identify rules governing the integrity of the data.

25
DB DEVELOPMENT LIFE CYCLE
✗ Database Design
✗ The process of creating a design for a
database that will support the
enterprise’s operations and objectives.

26
DB DEVELOPMENT LIFE CYCLE
✗ Database Design Framework
✗ Determine the information requirements.
✗ Analyze the real-world objects that you want to model in
the database.
✗ Determine primary key attributes.
✗ Develop a set of rules that govern how each table is
accessed, populated and updated.
✗ Identify relationship between the entities.
✗ Plan database security.
27
DB DEVELOPMENT LIFE CYCLE
✗ Stages of Implementation
✗ Hardware/Software Acquisition if
needed
✗ Programming
✗ Testing (program, subsystem, system
tests)

28
DB DEVELOPMENT LIFE CYCLE
✗ Stages of Implementation
✗ Training ( lead users, train the trainer)
✗ Conversion (in order of increasing complexity and
risk)
■ Parallel (old and new systems)
■ Pilot ( small scale, small scope)
■ Phased ( most critical functions first)
■ Direct Cutover( with manual parallel operations
29
DB DEVELOPMENT LIFE CYCLE
✗ Database Maintenance
✗ Objectives: Fix “bugs” (incorrect program specs or code) in
software, add enhanced functions, cycle back through
SDLC phases as needed for small- scale projects
✗ End Result: Fully Functional “Robust” System
✗ Methods: As needed for phases above; audit the system
✗ How to Avoid Risk: Watch changing business
requirements, set priorities.

30