2.database Architecture
2.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”