Page 66 - DLIS408_INFORMATION_TECHNOLOGY-APPLICATIONSL SCIENCES

Unit 5: Types of Database

level for an application well supports most of the needed external views. The conceptual view also Notes
determines the internal level (which primarily deals with data layout in storage) to a great extent.
External views requirement may add supporting storage structures, like indexes, for enhanced
performance. Typically the internal layer is optimized for top performance, in an average way
that takes into account performance requirements (possibly conflicting) of different external views
according to their relative importance. While the conceptual and external levels design can usually
be done independently of any DBMS (DBMS-independent design software packages exist, possibly
with interfaces to some specific popular DBMSs), the internal level design highly relies on the
capabilities and internal data structure of the specific DBMS utilized.
A common way to carry out conceptual level design is to use the Entity-relationship model (ERM)
(both the basic one, and with possible enhancement that it has gone over), since it provides a
straightforward, intuitive perception of an application’s elements. An alternative approach, which
preceded the ERM, is using the Relational model and dependencies (mathematical relationships)
among data to normalize the database, i.e., to define the (“optimal”) relations (data tupple types)
in the database. Though a large body of research exists for this method it is more complex, less
intuitive, and not more effective than the ERM method. Thus normalization is less utilized in
practice than the ERM method.
Another aspect of database design is its security. It involves both defining access control to database
objects (e.g., Entities, Views) as well as defining security levels and methods for the data itself (See
Database security above).

Entities and Relationships

The most common database design methods are based on the Entity relationship model (ERM, or
ER model). It consists of “Entities” and the “Relationships” among them. Accordingly a database
consists of entity and relationship types, each with defined attributes (field types) that model
concrete entities and relationships. Modeling a database in this way typically yields an effective
one with desired properties (as in some normal forms; see normalization below). Such model can
be translated to any other data model (e.g., Relational model) required by any specific DBMS for
building an effective database.

Database Normalization
In the design of a relational database, the process of organizing database relations to minimize
redundancy is called normalization. The goal is to produce well-structured relations so that additions,
deletions, and modifications of a field can be made in just one relation (table) without worrying
about appearance and update of the same field in other relations. The process is algorithmic and
based on dependencies (mathematical relations) that exist among relations’ field types. The process
results in bringing the database relations into a certain “normal form”. Several normal forms exist
with different properties.

Database Building, Maintaining, and Tuning

After designing a database for an application arrives the stage of building the database. Typically
an appropriate general-purpose DBMS can be selected to be utilized for this purpose. A DBMS
provides the needed user interfaces to be utilized by database administrators (e.g., Data definition
language interface) to define the needed application’s data structures within the DBMS’s respective
data model. Other user interfaces are used to select needed DBMS parameters (like storage allocation
parameters, etc.).
After completing the database and making it operational arrives the database maintenance stage:
Various database parameters may need to be changed and tuning for better performance,
LOVELY PROFESSIONAL UNIVERSITY 61