DATABASE DESIGN

What is Database Design?

• Database Design is a collection of processes that facilitate the designing,
development, implementation and maintenance of enterprise data
management systems.
• Is the process of producing a detailed data model of a database. This logical
data model contains all the needed logical and physical design choices and
physical storage parameters needed to generate a design in a data
definition language, which can then be used to create a database.
• Properly designed database is easy to maintain, improves data consistency
and are cost effective in terms of disk storage space.
• The database designer decides how the data elements correlate and what
data must be stored.
The Three-Level ANSI-SPARC
Architecture
Introduction
• in 1971, DBTG(DataBase Task Group) realized the requirement for a
two-level approach having views and schema and afterward, in 1975,
ANSI-SPARC realized the need for a three-level approach with the
three levels of abstraction comprising of an external, a conceptual,
and an internal level.
• The three-level architecture aims to separate each user’s view of the
database from the way the database is physically represented.
External level:
• It is how the user views the database. The data in the database that is
relevant to that user is described at this level.
• The external level consists of several different external views of the
database.
• In the external view only those entities, attributes, and relationships that are
relevant to a specific user that are included.
• The different views may have different ways of representing the same
data. For example, one user may view name in the form (firstname,
lastname), while another may view the same name as (lastname,
firstname).
Conceptual level:
• The middle-level or the second-level in the three-level architecture is
the conceptual level.
• It represents the semantic, security, and integrity information about
the data.
• It is the community view (not specific to a particular user) of the
database and describes what data is stored in the database. it also
represents the entities, their attributes, and their relationships.
• This level contains the logical structure of the entire database, it
represents the complete view of the database that the organization
demands independent of any storage consideration.
Internal level
• At the internal level, the database is represented physically on the
computer. It emphasizes the physical implementation of the database
to do storage space utilization and to achieve the optimal runtime
performance, and data encryption techniques.
• It interfaces with the operating system to place the data on storage
files and build the storage space, retrieve the data, etc.
Database Development Life Cycle
The Three phases of database design
Cont.
• In designing and presenting a database design methodology, you have
to divide the design process into three main stages or steps.
• These stages are also known as the Database development life
cycle. The three phases are:
• Conceptual Design
• Logical Design
• Physical Design
• The stages are discussed in details later in the lesson.
Conceptual Design
• In this design methodology, the process of constructing a model of
the data is used in an enterprise, independent of all physical
considerations.
• In other words, make sure that all data needed are in the model and
that all data in the model are needed.
• i.e
• All data elements required by the database transactions must be defined in
the model, and all data elements defined in the model must be used by at
least one database transaction.
Cont.
• The conceptual design has four steps, which are as follows.
1. Data analysis and requirements
2. Entity relationship modeling and normalization
3. Data model verification
4. Distributed database design
1. Data Analysis and Requirements:
The first step in conceptual design is to discover the characteristics of
the data elements. Appropriate data element characteristics are those
that can be transformed into appropriate information.
Therefore, the designer’s efforts are focused on:
• Information needs. What kind of information is needed—that is,
what output (reports and queries) must be generated by the system,
what information does the current system generate, and to what
extent is that information adequate?
• Information users. Who will use the information? How is the
information to be used? What are the various end-user data views?
Cont.
• Information sources. Where is the information to be found? How is the
information to be extracted once it is found?
• Information constitution. What data elements are needed to produce the
information?
• What are the data attributes?
• What relationships exist among the data?
• What is the data volume?
• How frequently are the data used?
• What data transformations are to be used to generate the required information?
• The designer obtains the answers to those questions from a variety of
sources in order to compile the necessary information. Note these
sources:
Cont.
• Developing and gathering end-user data views. The database designer
and the end user(s) interact to jointly develop a precise description of end-
user data views. In turn, the end-user data views will be used to help
identify the database’s main data elements.
• Directly observing the current system existing and desired output. The
end user usually has an existing system in place, whether it’s manual or
computer-based. The designer reviews the existing system to identify the
data and their characteristics.
• Interfacing with the systems design group. The database design process is
part of the Systems Development Life Cycle (SDLC). In some cases, the
systems analyst in charge of designing the new system will also develop the
conceptual database model.
2. Entity Relationship Modeling and Normalization:

• Involves creating an Entity Relationship (E.R) diagram

• Before creating the ER model, the designer must communicate and
enforce appropriate standards to be used in the documentation of
the design.
• The process of defining business rules and developing the conceptual
model using ER diagrams can be described using the following steps.
Cont.
1. Identify, analyze, and refine the business rules.
2. Identify the main entities, using the results of Step 1.
3. Define the relationships among the entities, using the results of Steps 1 and
2.
4. Define the attributes, primary keys, and foreign keys for each of the entities.
5. Normalize the entities. (Remember that entities are implemented as tables
in an RDBMS.)
6. Complete the initial ER diagram.
7. Validate the ER model against the end users’ information and processing
requirements.
8. Modify the ER model, using the results of Step 7.
3. Data Model Verification:
• The data model verification step is one of the last steps in the
conceptual design stage, and it is also one of the most critical ones.
• In this step, the ER model must be verified against the proposed
system processes in order to ascertain that the intended processes
can be supported by the database model.
• Verification requires that the model be run through a series of tests
against:
• End-user data views.
• All required transactions: SELECT, INSERT, UPDATE, and DELETE operations.
• Access rights and security.
• Business-imposed data requirements and constraints.
4. Distributed Database Design:
• Although not a requirement for most databases, sometimes a
database may need to be distributed among multiple geographically
disperse locations.
• Processes that access the database may also vary from one location
to another.
• For example, a retail process and a warehouse storage process are
likely to be found in different physical locations.
• If the database data and processes are to be distributed across the
system, portions of a database, known as database fragments, may
reside in several physical locations.
Cont.
• A database fragment is a subset of a database that is stored at a given
location.
• The database fragment may be composed of a subset of rows or
columns from one or multiple tables.
• The goal at this stage is to design a database that is independent of
database software and physical details.
• The output of this process is a conceptual data model that describes
the main data entities, attributes, relationships, and constraints of a
given problem domain. This design is descriptive and narrative in
form.
Logical Database Design
• Logical database design is the process of deciding how to arrange the
attributes of the entities in a given business environment into
database structures, such as the tables of a relational database.
• The goal of logical database design is to create well-structured
tables that properly reflect the company's business environment.
• The tables will be able to store data about the company's entities in a
non-redundant manner and foreign keys will be placed in the tables
so that all the relationships among the entities will be supported.
Cont.
• The objective of logical database design methodology is to interpret
the conceptual data model into a logical data model and then
authorize this model to check whether it is structurally correct and
able to support the required transactions or not.
• In this step of the database development life cycle, the main purpose
is to translate the conceptual data model created in conceptual
methodology (of the previous chapter) into a logical data model of
the data requirements of the enterprise.
Cont.
• This objective can be achieved by following the activities given below:
✓Obtain the relations for the logical data model
✓Authorize those relations using normalization
✓Validate those relations against user transactions
✓Check integrity control and its limitation
✓Evaluate the logical data model with user
✓Combine logical data models into the global model (This step is an optional
one)
✓Check for future growth and development
Physical Database Design
• Logical database designs are concerned with the "what," and in
contrast, physical database design is concerned with the "how."
• It requires diverse skills that are often found in different people.
• In particular, the physical database designer must know how the
computer system hosts the DBMS and how it operates and must be
fully conscious of the working of the target DBMS.
Basic Design Principles
• Avoid redundant information: I.e., keep duplication of data to a
minimum. The process to find such a design is called normalization.
• The normalization process can be formalized to a set of strict rules,
and the level of normalization can be expressed in terms of different
normal forms,
• e.g., First Normal Form (1NF), Second Normal Form (2NF), Third Normal Form
(3NF), Boyce-Codd Normal Form (BCNF), Fourth Normal Form (4NF), and Fifth
Normal Form (5NF).
• However, in most cases it is enough to follow the simple rule "avoid
redundant information" with your common sense.
Basic Design Principles
• Make the database structure flexible to meet the future needs:
Flexibility here means scalability and such design that new tables or
table columns need not to be created after the database has been set
up.
• The aim is to be able to handle all situations just by manipulating
data, making new data definitions (creation of new tables or fields)
unnecessary.
Cont.
• Define data types and constraints: The three basic data type
categories are string, numeric, and date/time*. Choose numeric for
fields including values that are measures.
• Some modern DBMS have Variable Character (VARCHAR) is a general
purposes datatype that accepts any category of data.
• For example, phone numbers and zip codes are not a measures, and
the appropriate data type is thus string. Date and time data is not
string data, even though it is most often represented as strings to the
user.
• After the data type category has been chosen, next task is to find the
appropriate (maximum) length for the data items.
Cont.
• The main considerations with respect to defining constraints
• is the field value always required, i.e., are NULL values denied (NOT NULL
constraint in SQL)**
• should the field values be unique (PRIMARY KEY constraint, UNIQUE
constraint)***
• what set of values is allowed (CHECK constraint, FOREIGN KEY constraint)
• is there some more complex constraints or business rules to be set up
(ASSERTION constraint, triggers)
Basic Design Principles Cont.
• Optimize physical performance: Speed is a very important factor in
database applications. Indexes help the database management
system (DBMS) to search data from the database tables. Indexes are
data structures maintained automatically by the DBMS after they
have been created.
• Primary indexes, indexes for the primary key fields, are automatically
created. Normally, other indexes have to be created manually. It is not
always easy to analyze what indexes are worth creating.
Basic Design Principles
• Consider User experience (UX design)- During designing its important
to consider how easily the users will be able to interact with the
database.
• A well designed database will make it easy for users to query the
database while a poorly designed database may make it very difficult
for non-technical users to query the database.
• Its recommended that after designing of the database a user-review
test is conducted to assess the ease of use.
The END

Q &A