“Database Architecture”

DBMS 1
Junar A. Landicho
Faculty, Information Technology Department
RG Cabahug, DTE
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, as discussed earlier.
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.
1. 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.
2. 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.
 The internal model separates the
physical requirements of the hardware
and the operating system from the data
model.
3. 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.
Figure 1 depicts a schema in a relational
database.
 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.
1. Physical data independence
2. Logical 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.
The ability to modify the
conceptual scheme without causing
application programs to be
rewritten.
Usually done when logical
structure of database is altered.
Logical data independence is
harder to achieve as the
application programs are usually
heavily dependent on the logical
structure of the data. An analogy is
made to abstract data types in
programming languages.
1. 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.
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:
1. Organization: information on organizational
positions as the corporate, division,
department and group level.
2. Function: information on organizational
functions, processes, and activities (we
define these terms in the next section).
3. Critical success factors (CSFs): information
on those areas where things must go right
for the company to succeed.
4. Data: information on data requirements
throughout the organization (subcategories
are entries, records, and elements).
5. System: information on the organization’s
automated information systems (present and
proposed).
6. Project: information about candidate projects that
will be considered by the organization.
2. System Definition
Scope
Parameters
Application areas
User groups
Discovery prototyping
3. Information Needs/Requirements Analysis
Goal: to communicate information in ways that are
relevant to the recipient group
A process of :
Discovery
Refinement
Modeling
Specifications
3. Information Needs/Requirements Analysis
Requirements Discovery Methods
Collecting facts from existing documentation
Research and site visits
Questionnaires
Interviews
Discovery prototyping
4. 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.
5. Database Design
The process of creating a design for a
database that will support the enterprise’s
operations and objectives.
6. 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.
7. Stages of Implementation
Hardware/Software Acquisition if needed
Programming
Testing (program, subsystem, system tests)
7. 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
8. 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.
“Giving the best what we have in making what
you are and what you can be”