DATABASE AND DATABASE MANAGEMENT SYSTEM & KEY ISSUES IN THE CONTEXT OF

ORGANIZATIONAL STRUCTURE

INTRODUCTION
A collection of related data is usually called database. In order to assist in the
maintenance and utilization of databases on large scale, we then use DBMS for these
purposes. DBMS stands for Database Management System. A Database scientist named
as Charles, in the late 1960s introduced the DBMS. In 1960 IBM bought IMS - Information
Management System for the purpose of large scale databases. Edgar Codd in 1970 at
IBM introduced new database named as RDBM i.e. Relational Database Management
System. After the advent of these databases, SQL came into being in 1980. In early 1990
we then saw the new and advanced databases coming to fulfill the needs of the
technological industry, which includes DB2 and Oracle.
DATA
An entity or raw facts or figures are known as data. There is a need to record day to day
operational activities in the organization for the effective decision making, for this
purpose we have to store the data of those activities somewhere in the system, and that
record is known as Data.
TASK OF DATA MANAGEMENT

Data Capture: A data have to be associated with some task relevant to the activity.
Data Classification: Data have to be classified according to the nature when
recorded.
Data Storage: Data should have to be stored properly.
Data Arranging: It is important to arrange data in proper order/format.
Data Retrieval: There is a frequent need of data for the certain processes, for this
purpose it is important to create some indexes which are easy for the retrieval of
data.
Data Maintenance: Up to Date data is a back bone for the decision making process
in the organization, for this purpose data should be up to date and maintained
properly.
Data Editing: Editing means to re-arrange the data for the beneficial use of it.

DBMS
A Database Management System is a collection of program/software that enables user to
create and maintain data effectively and efficiently. DBMS is a general purpose software
program that facilitates the process of defining, creating, and manipulating database for
specific applications or programs.
CHARACTERISTICS OF DBMS

For the purpose of organizational requirements system should be designed for

smart maintenance.

Information system should be designed in such an interactive way to fetch data for
the specific. purpose without writing a new piece of code.
Data should be co-related to other data to meet rapid changing environment.
Integration between different data scattered in different programs should be easy.
Concurrent access should be available.
Automatic recovery feature has to be provided to overcome the problem in the
case of system failures.

DBMS UTILITIES
Data Loading Utility: It allows data to load from one format to standard format without
writing any code.
Backup Utility: It allows data to back up periodically to secure data in the case of crashes
and system failure.
Recovery Utility: It is one of the important utility, which allows reconstructing the correct
state of database from backup.
Monitoring Tools: It allows to optimized database access and monitor performance so
that internal schema can be changed.
File Organization: It allows data to reconstruct from one type to another.
FILE SYSTEM VS DBMS

File system is a collection of data. To manage the file, user has to write the
procedures, whereas in DBMS user is not required to write the procedure.
File system show the details of the data presentation and data storage, whereas
DBMS provides abstract view.
File system did not provide efficient storing and retrieving of data. DBMS is efficient
in providing operations of storage and retrieving the data, it has wide varieties of
techniques to do the tasks.
Concurrent access creates problem in file, where DBMS provide effective
concurrent access to the user at the same time.
There is no crash recovery mechanism in file system, where DBMS has a great tool
to recover data from catastrophes.
Under file system it is difficult to protect a file. Whereas DBMS has a good
mechanism for protection.

ADVANTAGES OF DBMS
Data Independency: There should no exposition to a program details, DBMS only provide
abstract view of data and hide all details which are not specific for the user.
Efficient Data Access: There are a variety of sophisticated techniques available in DBMS
to store and retrieve data efficiently.

Data Integrity & Security: DBMS enforces data integrity for the purpose of unauthorized
access to data.
Data Administration: Data redundancy can be minimized to centralize the data, which
reduces the retrieval time.
Concurrent Access: DBMS can provide multiple users at a time to perform certain task on
a single table or multiple tables, without losing any information.
Crash Recovery: DBMS protects user from system failure to save important data and
time.

FUNCTIONS OF DBMS
Data Definition: For the purpose of defining the structure of data, DBMS provides
function for this. It includes modifying and defining the structure, the type and size of the
fields and the various constraints.
Data Manipulation: Whenever we define the structure of the data, we then need to
insert, modify or delete the data. These important functions are part of the DBMS.
Data Security & Integrity: There are certain modules in DBMS which handles data
security and integrity with efficient manners.
Data Recovery & Concurrency: There is always a chance of failure due to some reasons,
for this reason DBMS provide function which recover data on the time of crash or some
failure. DBMS also handles concurrent access at a time.
Performance: To optimize the queries in the database is one the important function of
DBMS.
ROLE OF DATABASE ADMINISTRATOR
DBMS has typically 3 main users:
1. End User It is the one who uses the database and actually input data in the
system for the purpose of business activities. The end user does not need to know
anything about the organization of the database in the physical level.
2. Programmer/Developer This person has the knowledge about the data and its
structure and can manipulate the data using certain program or piece of code.
3. Database Administrator DBS This person is considered as the super user of
the system. DBA can perform many functions in the organization as follows:
Defining the Schema: DBA defines the structure of the database in the
application. DBA has to determine what data needs to be presented in the
system and how this data should be organized.
Liaising with Users: DBA should have to interact with the end user
continuously to cope with rapidly changing requirements.
Defining security & Integrity Check: DBA defines security checks and put
integrity checks accordingly.
Defining Backup/Recovery Procedures: DBA defines backup and recovery
procedures to maintain the database for the organization. Defining backup
specifies what data needs to be backed up and when it needs to be backed
up.
Monitoring Performance: DBA should have to monitor the performance of the
queries frequently and take such measures which optimized all the queries in
the application.

SIMPLIFIED DATABASE SYSTEM ENVIRONMENT (Figure 2c.)

EXAMPLE OF DATABASE (WITH A CONCEPTUAL DATA MODEL)

Mini world for the example: Part of a UNIVERSITY environment.

Some mini-world entities: STUDENTs, COURSEs, SECTIONs (of COURSEs),
DEPARTMENTs, INSTRUCTORs.
Some mini-world relationships: SECTIONs are of specific COURSEs, STUDENTS take
SECTIONs, COURSEs have pre-requisite COURSEs, INSTRUCTORs teach SECTIONs,
COURSEs are offered by DEPARTMENTs, and STUDENTs major in DEPARTMENTs.
(Database Management Systems)

EXAMPLE OF SIMPLE DATABASE

EXAMPLE OF A STUDENT FILE

ARCHITECTURE OF A DBMS

A commonly used view of data approach is the three level architecture suggested by
ANSI/SPAC (American National Standards Institute/Standards Planning and Requirements
Committee). ANSI/SPAC produced an interim report in 1972 followed by a final report in
1977. The report proposed an architectural framework for databases. Under this
approach, a database is considered containing data about an enterprise. The three levels
of architecture have three different views of data:

External individual user view

Conceptual community user view
Internal physical or storage view

In conceptual view, database architecture allows a clear view or separation of the

information meaning from the external data representation and from the physical data
structure layout. This database which is likely able to separate three different views of
data is flexible and adaptable. This flexibility lies under data independence.
THE EXTERNAL VIEW
It is the view for the end user. This is generally the restricted views for the user, but at
the same time this database can provide different views for different class of users. End
user or even the programmer eventually interested in the subsets of the database. For
example: A department head may only be interested in the finances of the department
or he may also be interested in the students enrolled in the respective department. In
the same manner librarian would like to seek the information regarding the books in the
library and not in the payroll of the staffs.
CONCEPTUAL VIEW
The conceptual view is the information model of the enterprise and contains the view of
the whole enterprise without any concern for the physical implementation. This view is
normally more stable than external and internal view. In the database we may change
the internal view to improve performance while we cant change in the conceptual view

of the database. It is overall a community view of the database and it includes all the
information of data that is going to be represented in the database. This view can also be
defined by the conceptual schema which includes definitions of each o the various types
of data.
INTERNAL VIEW
It is the view about the actual physical storage of data. It tells us how and what data is
stored in the database. Efficiency consideration is the most important at this level, and
the data structures are chosen to provide an efficient database.
The separation of the conceptual view from the internal view enables us to provide a
logical description of the database without the need to specify physical structures. This is
often called physical data independence. Separating the external views from the
conceptual view enables us to change the conceptual view without affecting the external
views. This separation is sometimes called logical data independence.
DATA INDEPENDENCE
It is the capacity to change the schema at one level without changing the schema at
another level. Two types are:
1- Logical Data Independence: it is the capacity to change the schema without
changing the external schema.
2- Physical Data Independence: it is the capacity to change the internal schema
without changing the conceptual schema.
Types of Databases and Database Applications
Traditional Applications:
Numeric and Textual Databases
More Recent Applications:
Multimedia Databases
Geographic Information Systems (GIS)
Data Warehouses
Real-time and Active Databases
Many other applications

DATA MODEL
Model is an abstraction, which hides superfluous details from the user. Whereas data
modeling is use to represent entities of interest and their relationship in the database.
Data model is a collection of concept that can be used to describe the structure of a
database which provides the necessary means to achieve the abstraction. It consists of:
Data types
Relationships
Constraints
TYPES
1.
2.
3.
4.
5.

High Level- Conceptual data model.

Low Level Physical data model.
Relational or Representational
Object-oriented Data Models
Object-Relational Models

The most common models are:

Relational Database Model
The Relational Model uses a collection of tables both data and the relationship among
those data. Each table has multiple columns and each column has a unique name.
Relational database comprising of two tables
Customer Table

ADVANTAGES
o it represent data in simplified form
o manipulation of record is simplified with key attributes to retrieve data
o different type of relationship with other tables is easy
NETWORK MODEL
In this type of model, data is represented by links which can be considered as pointers.

ADVTANGES
o representations of relationships between entities is implemented using pointers
which allows the arbitrary relationship
o it is easy as compared to hierarchical
o data manipulation is also easy

HIERCHICAL MODEL
A hierarchical data model is a data model which the data is organized into a tree like
structure. The structure allows repeating information using parent/child relationships:
each parent can have many children but each child only has one parent. All attributes of
a specific record are listed under an entity type.

ADVANTAGES
o
o
o
o

representation is in ordered tree format

one-to-many relationship
proper ordering of tree is easier, ultimately easy retrieval of records
it allow the use of virtual records

DBMS Languages

Data Definition Language DDL

Data Manipulation Language DML
High Level or Non Procedural Language (SQL)
Low Level or Procedural Language

Data Definition Language (DDL)

Used by the DBA and database designers to specify the conceptual schema of a
database.
In many DBMSs, the DDL is also used to define internal and external schemas
(views)
In some DBMSs, separate storage definition language (SDL) and view definition
language (VDL) are used to define internal and external schemas.
SDL is typically realized via DBMS commands provided to the DBA and database
designers

Data Manipulation Language (DML)

Used to specify database retrievals and updates DML commands (data sublanguage) can
be embedded in a general-purpose programming language (host language), such as
COBOL, C, C++, or Java.
A library of functions can also be provided to access the DBMS from a
programming language
Alternatively, stand-alone DML commands can be applied directly (called a query
language).

DBMS Interfaces
Stand-alone query language interfaces
Example: Entering SQL queries at the DBMS interactive SQL interface (e.g.
SQL*Plus in ORACLE)
Programmer interfaces for embedding DML in programming languages
User-friendly interfaces
Menu-based, forms-based, graphics-based, etc.
DBMS Programming Language Interfaces
Programmer interfaces for embedding DML in a programming languages:
Embedded Approach: e.g embedded SQL (for C,C++, etc.), SQLJ (for Java)
Procedure Call Approach: e.g. JDBC for Java, ODBC for other programming
languages
Database Programming Language Approach: e.g. ORACLE has PL/SQL, a
programming language based on SQL; language incorporates SQL and its data
types as integral components.

DBMS COMPONENT MODULES

CENTRALIZED DBMS

Combines everything into single system including- DBMS software, hardware,

application programs, and user interface processing software.
User can still connect through a remote terminal however, all processing is done
at centralized site.

Basic 2-tier Client-Server Architectures

Specialized Servers with Specialized functions

Print server
File server
DBMS server
Web server
Email server
Clients can access the specialized servers as needed

CLIENTS
Appropriate interfaces provided through a client software module which access and
utilize the server with various resources.
Clients server maybe machines which are diskless or other PCs or workstations
with disks with only client software installed.
Network maybe connected to the server.
(LAN: local area network, wireless network, etc.)
DBMS SERVER
Function is to provide database query and services of transaction to the clients.
Relational DBMS servers are often called SQL servers, query servers, or transaction
servers
Applications running on clients utilize an Application Program Interface (API) to
access server databases via standard interface such as:
o ODBC: Open Database Connectivity standard
o JDBC: for Java programming access
For ODBC or JDBC, there must be an installation of appropriate client and server
module on both clients and server side.
TWO TIER CLIENT-SERVER ARCHITECTURE
A client program may connect to several DBMSs, sometimes called the data
sources.
In general, data sources can be files or other non-DBMS software that manages
data. Other variations of clients are possible: e.g., in some object DBMSs, more
functionality is transferred to clients including data dictionary functions,
optimization and recovery across multiple servers, etc. (Unit DB1)
THREE TIER CLIENT-SERVER ARCHITECTURE
Very common for applications which are web based.
Intermediate Layer called Application Server or Web Server:
It stores those data which are related to business logic and web connectivity of the
software which later used to access corresponding data from database server.
Acts like a conduit for sending partially processed data between the database
server and the client.
Three-tier Architecture Can Enhance Security:
Database server only accessible via middle tier
Clients cannot directly access database server

Classification of DBMSs

It is based on data model which is used.

Traditional: Relational, Network, Hierarchical.
Emerging/Trending: Object-oriented, Object-relational.
Single-user (typically used with personal computers) vs. multi-user (most DBMSs).
Centralized (uses a single computer with one database) vs. distributed (uses
multiple computers multiple databases).
They do not support a totally distributed environment, but rather a set of database
servers supporting a set of clients. (Unit DB1)

UNDERSTANDING OF DATABASE DESIGN TECHNIQUES

Good database design is critical for high performance at higher/organizational level. To
work effectively, data need to be optimizing at regular interval of time. Many factors
which contribute towards optimization of database, which includes normalization as well.
Normalization makes our database easy to maintain and remove duplication. For
example: you have to maintain a database of student and classes in which they are
enrolled. If 35 of these students are in the same class of Maths, this class name would
appear 35 times in the table. Now the instructor decides to change the class name to
Advance Math, you must change 35 records. (Unit DB1)
One can gain numerous advantages from maintaining and well planned database design,
and this will ultimately the result of the work you do upfront. If you do the work upfront
at the initial stage, it is obvious that the less you have to do later.
TYPES OF RELATIONSHIPS

One-to-one Relationships
One-to-many Relationships
Many-to-many Relationships

For example, suppose that you have a table called employees that contains each
persons Social Security number, name, and the department in which he or she works.
Suppose that you also have a separate table called departments, containing the list of all
available departments, made up of a Department ID and a name. In the employees
table, the Department ID field matches an ID found in the departments table. (Unit
DB2)

One-to-One Relationships
In a one-to-one relationship, a key appears only once in a related table. The employees
and departments tables do not have a one-to-one relationship because many employees
undoubtedly belong to the same department. A one-to-one relationship exists, for
example, if each employee is assigned one computer within a company. (Unit DB2)

One-to-Many Relationships
In a one-to-many relationship, keys from one table appear multiple times in a related
table. (Unit DB2)

Many-to-Many Relationships
The many-to-many relationship often causes problems in practical examples of
normalized databases, so much so that it is common to simply break many-to-many
relationships into a series of one-to-many relationships. In a many-to-many relationship,
the key value of one table can appear many times in a related table. So far, it sounds like
a one-to-many relationship, but heres the curveball: The opposite is also true, meaning
that the primary key from that second table can also appear many times in the first
table. (Unit DB2)

NORMALIZATION
To make life easier, normalization is a set of rules for database administrators. It is the
way to organize your database in such an efficient way then for future growth you can
use the table where appropriately required.
The sets of rules used in normalization are called normal forms. If your database design
follows the first set of rules, its considered in the first normal form. If the first three sets
of rules of normalization are followed, your database is said to be in the third normal
form. (Unit DB2)
FIRST NORMAL FORM
The rules are as follows:

Eliminate repeating information

Create separate table for related data

SECOND NORMAL FORM

The rule is as follow:
No non key attributes depend on a portion of the primary key.
If your fields are not entirely related to a primary key, you have to refine it. (Unit DB2)

THIRD NORMAL FORM

The rule is as follow:
No attributes depend on other non-key attributes.

If you need to look at your tables and see whether you have more fields that can be
broken down further and that arent dependent on a key. (Unit DB2)

DESIGN PROCESS
Important and crucial part of any application is to give it forethought before
implementing it. Same is the case with database application in which design process
must include a thorough evaluation of your database. What data should hold and where
it relates, most importantly it is scalable or not.
One should follow these steps:

Define objectives
Design the structure (tables, fields)
Discern relationships
Define business rules
Create application

E-R MODEL
In ER model we used to represent real world situation using concepts which are used by
people. In this model we define a real world object representation at logical level. ER
model has no facilities to describe machine-related aspects. In this model we capture the
logical structure of database by indicating the grouping of data into entities. The ER
model also supports a top-down approach by which details can be given in successive
stages. (Unit DB3)
Entity: An entity is something which is described in the database by storing its data; it
may be a concrete entity or a conceptual entity.
Entity set: An entity set is a collection of similar entities.
Attribute: An attribute describes a property associated with entities. Attribute will have
a name and a value for each entity.
Domain: A domain defines a set of permitted values for an attribute.

SYMBOLS IN E-R MODEL (Unit DB3)

OVERVIEW OF DATABASE DESIGN PROCESS (Unit DB3)

EXAMPLE COMPANY DATABASE

We need to create a database schema design based on the following (simplified)
requirements of the COMPANY Database:
The company is organized into DEPARTMENTs. Each department has a name, number and
an employee who manages the department. We keep track of the start date of the
department manager. A department may have several locations. Each department
controls a number of PROJECTs. Each project has a unique name, unique number and is
located at a single location. We store each EMPLOYEEs social security number, address,
salary, sex, and birth date. Each employee works for one department but may work on
several projects.
We keep track of the number of hours per week that an employee currently works on
each project. We also keep track of the direct supervisor of each employee. Each
employee may have a number of DEPENDENTs. For each dependent, we keep track of
their name, sex, birth date, and relationship to the employee. (Unit DB3)
ER MODEL CONCEPTS
Entities and Attributes: Entities are specific objects or things in the mini-world that
are represented in the database. For example
the EMPLOYEE John Smith,
the Research DEPARTMENT,
the ProductX PROJECT.
Attributes are properties used to describe an entity. For example an EMPLOYEE entity
may have the attributes Name, SSN, Address, Sex, BirthDate .
A specific entity will have a value for each of its attributes. For example a specific
employee entity may have
Name='John Smith', SSN='123456789',
Address ='731, Fondren, Houston, TX',
Sex='M', BirthDate='09-JAN-55
Each attribute has a value set (or data type) associated with it e.g. integer, string,
subrange, enumerated type. (Unit DB3)
TYPES OF ATTRIBUTES
There are two types of Attributes
Simple
Each entity has a single atomic value for the attribute. For example SSN or Sex.
Composite
The attribute may be composed of several components. For example: Address (Apt#,

House#, Street, City, State, ZipCode, Country), or Name(FirstName, MiddleName,

LastName).
Composition may form a hierarchy where some components are themselves composite.
Multi-valued
An entity may have multiple values for that attribute. For example, Color of a CAR or
Previous Degrees of a STUDENT. Denoted as {Color} or {Previous Degrees}.
In general, composite and multi-valued attributes may be nested arbitrarily to any
number of levels, although this is rare. For example, Previous Degrees of a STUDENT is a
composite multi-valued attribute denoted by
{Previous Degrees (College, Year, Degree, Field)}
Multiple Previous Degrees values can exist. Each has four subcomponent attributes:
College, Year, Degree, Field. (Unit DB3)
ENTITY TYPE OF A COMPANY DATABASE

RELATIONSHIPS AND RELATIONSHIP TYPES

A relationship relates two or more distinct entities with a specific meaning.
For example, EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE
Franklin Wong manages the Research DEPARTMENT. (Unit DB3)
Relationships of the same type are grouped or typed into a relationship type. For
example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs
participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs
participate. (Unit DB3)
The degree of a relationship type is the number of participating entity type. Both
MANAGES and WORKS_ON are binary relationships. (Unit DB3)
E R DIAGRAM

DATA INTEGRITY
There are certain rules on which data is accepted and becomes valid. Data integrity is
one such enforcement rule that ensures the data is valid and correct. Keys play an
important role in maintaining data integrity. The various types of keys that have been
identified are:

Candidate key
Primary key
Alternate key
Composite key
Foreign Key

Candidate key
An attribute or set of attributes that uniquely identifies a row is called a Candidate key.
This attribute has values that are unique
Vehicle (Unit DB3)

Primary Key
The Candidate key that you choose to identify each row uniquely is called the Primary
key.
Alternate Key
A Candidate key that is not chosen as a Primary key is an Alternate key.
Composite Key
In certain tables, a single attribute cannot be used to identify rows uniquely and a
combination of two or more attributes is used as a Primary key. Such keys are called
Composite keys.
Foreign Key
When a primary key of one table appears as an attribute in another table, it is called the
Foreign key in the second table A foreign key is used to relate two tables.
Weak entity:
A weak entity does not have a distinguishing attribute of its own and mostly are
dependent entities, which are part of some another entity. A weak entity will always be
related to one or more strong entities. They can be also understood as multi-valued
attributes.

CONSTRUCTNG AN E-R MODEL

Before constructing any E-R model, we have to carefully look upon requirements
specifications.
1. Identify entities - list all potential entity types. These are the object of interest in
the system. It is better to put too many entities in at this stage and they discard
them later if necessary.
2. Remove duplicate entities - Ensure that they really separate entity types or just
two names for the same thing.
Also do not include the system as an entity type
E.g. if modeling a library, the entity types might be books, borrowers, etc.
The library is the system, thus should not be an entity type.
3. List the attributes of each entity (all properties to describe the entity which are
relevant to the application).
Ensure that the entity types are really needed.
Are any of them just attributes of another entity type?
If so keep them as attributes and cross them off the entity list.
Do not have attributes of one entity as attributes of another entity
4. Mark the primary keys.
Which attributes uniquely identify instances of that entity type?
This may not be possible for some weak entities.
5. Define the relationships

Examine each entity type to see its relationship to the others.

6. Describe the cardinality of the relationships

Examine the constraints between participating entities.

7. Remove redundant relationships

Examine the ER model for redundant relationships.

TYPES OF DATA INTEGRITY
Data Integrity falls into the following categories
Entity integrity
Entity integrity ensures that each row can be uniquely identified by an attribute called
the Primary key. The Primary key cannot have a NULL value.
Domain integrity
Domain integrity refers to the range of valid entries for a given column. It ensures that
there are only valid entries in the column.
Referential integrity
Referential integrity ensures that for every value of a foreign key, there is a matching
value of the Primary key.

BE ABLE TO DESIGN AND CREATE DATABASE

DESIGN METHODOLOGY
The approach taken in building or designing things is known as design methodology and
it serves as a guideline on how things are to be done. Normally we broke down design
methodology into phases or stages, later for each stage a detailed steps are outlined,
and appropriate tools and techniques are specifies into details.
This methodology can support and facilitate designers in many phases like planning,
modeling and managing a database development project in a structured and systematic
way. One of the key aspects in this methodology is to ensure the business requirements
that the produced model is accurately representing the user requirements.
CONCEPTUAL METHODOLOGY
STEP 1: Build Conceptual Data Model

Entity types
Relationship types
Attributes and its domain
Primary and alternate keys
Integrity constraints

Depending on the size of the database application to be build, we may produce one local
conceptual data model for each user view. We assume that we only need to build one
conceptual data model. The following are the steps that we need to perform to build the
conceptual data model. (Unit DB4)
STEP 1.1: Identify Entity Types
Identify main objects, which are required for the model, is the first step to be performed.
This can be obtained from user requirements specification.
We have identified seven entity types for our model: Customer, Employee, Product,
Order, Invoice, Delivery, and Supplier.
Step 1.2: Identify Relationship Types
Next, we need to determine the important relationships that exist between the entity
types that have been identified. Relationships are identified by examining the
transactions that are needed by the users in the requirements specification. The
relationships are typically described using a verb. Use of ER diagram helps to visualize
the relationship and the model more effectively. We need also to include the cardinality
and the participation constraints of relationship types in the diagram. The descriptions of
this information need to be documented for the refinement and validation purposes.

For our product ordering, we have identified the following relationships:

Between
Between
Between
Between
Between
Between

Customer and Order: Customer makes Order

Product and Order: Order has Product
Supplier and Product : Supplier supplies Product
Order and Invoice : Order has Invoice
Employee and Order : Employee takes Order
Order and Delivery : Order sends for Delivery

Step 1.3: Identify and Associate Attributes with Entity or Relationship Types
After identifying the entity and relationship types, the next step is to identify their
attributes. It is important to determine the type of these attributes. Attributes can be
categorized as simple or composite, single or multi-valued, and derived attributes. Again,
we need to document the details of each identified attribute.
For our model, the list of attributes for the defined entities is as follows:
Customer CustNo, Name, CustAddress,TelNo, Balance
Employee EmpNo, Name, TelNo, Position, Gender, DOB, Salary
Order OrderNo, OrderDate, OrderAddress
Invoice InvoiceNo, Date, DatePaid, OrderNo;
Product ProductNo,Name,UnitPrice, QtyOnHand, ReorderLevel, SuppNo
Delivery DeliveryNo, DeliveryDate, OrderNo, ProductNo;
Supplier SuppNo, Name, SuppAddress, TelNo, ContactPerson

Step 1.4: Determine Attribute Domains

Next, we need to determine domains for each attributes and document the details of
each domain. If we have more than one user view, the domain of an attribute for each
user view might be different.
Step 1.5: Determine candidate, primary, and alternate key attributes
A relation must have a key that can uniquely identify each of the tuples. In order to
identify the primary key, we need first to determine the candidate key for each of the
entity types.
The primary key for each of the entity types are underlined as listed below.

Customer CustNo, Name, CustAddress,TelNo, Balance

Employee EmpNo, Name, TelNo, Position, Gender, DOB, Salary
Order OrderNo, OrderDate, OrderAddress, CustNo
Invoice InvoiceNo, Date, DatePaid, OrderNo;
Product ProductNo,Name,UnitPrice, QtyOnHand, ReorderLevel, SuppNo
Delivery DeliveryNo, DeliveryDate, OrderNo, ProductNo;

Supplier SuppNo, Name, SuppAddress, TelNo, ContactPerson

Step 1.6: Check Model for Redundancy

Check for the presence of any redundancy in the model as an important step to perform.
The common checking for the redundancy is to re-evaluate the 1:1 relationship. If the
entities in the relationship are similar, then we need to merge them together as one
entity, and may need to redefine the primary key. This type of problem typically exists
when we have more than one user view.
Step 1.7: Validate Conceptual Model against User Transactions
We have to ensure that the conceptual model supports the transactions required by the
user view.
Step 1.8: Review Conceptual Data Model with User
User involvement during the review of the model is important to ensure that the model is
a true representation of the users view of the enterprise. (Unit DB4)

LOGICAL DESIGN
Main focus of logical design phase is to map out and validate the step 1 i.e. conceptual
data model on the logical structure. The detail descriptions of the steps are presented
below:
Step 2: Build and Validate Logical Data Model
The main objective of this step is to translate the conceptual data model into logical data
model. The activities involved in this process include defining the relations, the
relationship, and integrity constraints. ER model is the source representing the
conceptual data model and normalization as an important technique used for the
validation in the logical design phase. The following are the activities involved in this
phase.
Step 2.1: Derive Relations for Logical Data Model
Firstly, we create a set of relations for the logical data model based on ER model
produced in the prior design phase to represent the entities, relationships, and key
attributes.
Each entity is classified as strong or weak entity type. The relationship is examined for
its relationship type (1:1, 1:M, M:N) and its cardinality (minimum and maximum
occurrence) and participation (optional or mandatory).

Step 2.2: Validate Relations using Normalization

In order to make sure that the relations have minimal and yet adequate number of
attributes and data redundancy, we need to validate that all relations is at least in third
normal form (3NF). Please refer to Topic 6 for the details of the normalization process.
Step 2.3: Validate Relations against user Transactions
For this step, it is important to ensure that derived relations support the required
transactions as mention in the user requirement specifications.
Step 2.4: Check Integrity Constraints
This step is crucial in order to protect the database from becoming unfinished, imprecise
or incompatible. In this step we identify what integrity constraints are needed. This
includes identifying:

Required data : identify the attributes that cannot have null

Attribute domain constraints : define a set of allowable values for each attribute
Multiplicity : define the constraint for relationship
Entity integrity : constraint for primary key
Referential integrity : constraint for foreign key
General constraints to implement business rules

Step 2.5: Review Logical Data Model with User

In this step, we need to let the user review the logical data model to ensure that the
model is the true representation of the data requirements of their enterprise. This is to
ensure that the user is satisfied and we can continue to the next step. (Unit DB4)

PHYSICAL DESIGN
In the physical design phase, there involve processes which produce description for the
implementation of databases using a defined DBMS on secondary storage. The
description includes those factors: information, storage structure, methods of access and
security mechanism. The key focus of this stage is performance in terms of efficiency
and simplicity. In physical design we take care of those steps to ensure that all key
functions perform well and simple to implement. If there arise a complexity in the
implementation phase, we may change the logical data, for the improvement in
performance and efficiency.
The output from the logical design phase consisting of all the documents that provide
description of the process of the logical data model such as ER diagram, relational
schema, data dictionary are important sources for the physical design process. Unlike
the logical phase which is independent of the DBMS and implementation consideration,
the physical phase is tailored to a specific DBMS and is dependent on implementation
details. (Unit DB4)
Step 3: Translate logical database design for target DBMS
This step concerns with mapping the logical data model to the target DBMS. Our focus is
to produce a relational database schema that can be implemented in the target DBMS.
All process performed for every step of design need to be documented for easy
maintenance.
Step 3.1: Design Base Tables
We begin with designing the base relations that have been identified in the logical data
model in the target DBMS. For each of these relations, we need to define the attributes,
and entity constraint for primary and referential constraints for foreign keys. For each of
the attributes, among the information that we need to define in the target DBMS include
the domain, data types and default value.
Step 3.2: Design Representation of Derived Data
It is also important in this stage to decide how to represent the derived attributes which
normally should not be in the base relation.
Step 3.3: Design Remaining Business Rules
Besides the entity and referential integrity constraint, the design of business rules as the
general constraint for the target DBMS is also important to ensure the accuracy of the
information systems functionality.
Step 4: Design File Organizations and Indexes
Since one of the key focus of the physical design phase is on the performance efficiency,
determining the optimal file organization and indexes is a crucial task. Among the steps
that need to be taken are as follows:
Step 4.1: Analyze Transactions

Understanding that each functionality of the transactions that will run on the database is
vital.

Step 4.2: Choose file Organization

There are many types of file structure. Thus we need to analyze and determine the best
file organization and access method.
Step 4.3: Choose Indexes
We need to decide whether we should use indexes to improve the performance.
Step 4.4: Estimate Disk Space Requirements
The size of storage space for the database affects the performance. Thus, the right
estimation of the space is important.
Step 5: Design User Views
This step is important for a multi-user environment. The objective of this step is to design
the user views that were identified during the requirement and analysis of the system
development lifecycle.
Step 6: Design Security Mechanisms
Security is one of the important aspects in the database design. The objective of this
step is to realise the security measures as required by the user. The designer must
investigate the security features provided by the selected DBMS. (Unit DB4)

REFERENCES
Figure 2c." (n.d.): n. pag. A Simplified Database System Environment. Web.
<http://courses.cse.tamu.edu/yurttas/csce310/CN/EN/01.pdf>
Database Management Systems." RDF Database Systems (2015): 9-40. Conceptual Data
Model. Web. <http://www.nirulanice.com/uploads/materials/UNIT%20I.pdf>
Unit DB1: Database Management System. Web.
< http://www.nirulanice.com/uploads/materials/UNIT%20I.pdf>
Unit DB2: Understanding the Database Design Process. Web
< http://public.wsu.edu/~arola/356/spring09/meloni_15.pdf>
Unit DB3: The Relational Data Model and Relational Database. Web.
< http://www.nirulanice.com/uploads/materials/UNIT%20II%20A.pdf>
Unit DB4: Design Methodology. Web.
< http://www.tankonyvtar.hu/hu/tartalom/tamop412A/20110021_53_database_system/CMDB5103_Database_System_07.pdf>