DBMS 1

Junar A. Landicho
Faculty, Information Technology Department
Database Architecture and
Transaction Management
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.

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 organizations
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 enterprises
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.






A transaction (xact) is the DBMSs abstract view of a user
program (or activity):

- A sequence of reads and writes of database objects.

- Unit of work that must commit or abort as an atomic unit.

A users program may carry out many operations on the data
retrieved from the database, but the DBMS is only concerned
about what data is read/written from/to the
database.

Transaction Manager controls the execution of transactions.
A tomicity: All actions in the Xact happen, or none
happen.

C onsistency: If each Xact is consistent, and the DB
starts consistent, it ends up consistent.

I solation: Execution of one Xact is isolated from that
of other Xacts.

D urability: If a Xact commits, its effects persist.
A very important property guaranteed by the DBMS
for all transactions is that they are atomic. That is, a
user can think of a Xact as always executing all its
actions in one step, or not executing any actions at all.

A transaction ends in one of two ways:
- commit after completing all actions
- abort after executing some actions
- system crash while the Xact is in progress; treat as
abort.
DBMS ensures the above by logging all actions:
- Undo the actions of aborted/failed transactions
- Redo actions of committed transactions not yet
propagated to disk when system crashes.
Giving the best what we have in making what
you are and what you can be