1. ITEC224 Database Programming
Lecture 2: Database Design Methodology

2. Learning Objectives Purpose of Database Design
Phases of Database Design

3. Database Development
In the past many software development projects were unsuccessful due to:
requirements were not properly collected/specified
Lack of development methodology
The stages in the DB development cycle has been identified:
Clearly specified
Not sequential, but involve some repetition.
Contain feedback loops (even back to the requirements stage)

4. Db Development Life Cycle
Database planning
System definition
Requirement collection and analysis
Database design
DBMS selection
Application design
Prototyping
Implementation
Data conversion and loading
Testing
Operational maintenance

5. Database Application Lifecycle
DATABASE PLANNING
SYSTEMS DEFINITION
REQUIREMENTS ANALYSIS
Database Design
CONCEPTUAL DESIGN
DBMS SELECTION
LOGICAL DESIGN
APPLICATION
DESIGN
DISTRIBUTED DB DESIGN
Optional
PHYSICAL DESIGN
PROTOTYPING
These are the stages in the development cycle. It is important to note that these are not sequential, but involve some repetition. Sometimes this going back to previous stages is called feedback loops. For example a problem of design might mean going back to the requirements stage and collecting more data.
PLANNING - Identifying how the stages can be completed in the most effective & efficient way.
SYSTEM DEFINITION - Specifying the scope & boundaries of the system.
REQUIREMENTS ANALYSIS - Collection of requirements of users
DB DESIGN - The design of the DB itself
DBMS Selection (Optional). Which software
APPLICATION DESIGN - Designing the functionality of the DB
PROPTOTYPING(Optional) - building a working model
IMPLEMENTATION - Creating the DB (tables etc) and the application programs.
DATA CONVERSION & LOADING - (Only if replacing an old system).
TESTING -
MAINTENANCE - Monitoring, adding new requirements.
IMPLEMENTATION
DATA LOADING
TESTING
MAINTENANCE

6. Database Application Lifecycle
Management activities that allow the stages of the database application to be realized as efficiently as possible
Database Planning :
The scope and boundaries of the application including its major application areas and user groups
System Definition :
Encompasses tasks that determine the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting, vague and incomplete requirements of the various stakeholders
Requirements Analysis:
Planning: has two stages (a) Planning factors (2) Planning Objectives.
(1) Planning factors involve (a)work to be done (b) the resources to do it © cost
However…
Must be done within the overall planning strategy of the organisation
Therefore, several factors to be taken into account:
Identify goals of the organisation, e.g.
10% growth per year
No redundancies
Identify critical success factors, e.g.
High quality products
On-time deliveries
Identify problem areas, e.g.
Inaccurate stock control
More competition
(2)Identify Planning Objectives
Organisational Units
Consist of various departments
Locations
List of operational locations
Business Functions
Identify related business processes
Entity Types
System definition : Here you want to know at a very high level, what the boundaries of the system are: You might need to think about who the users are, what the current application areas are etc
Something for which data is collected
Identify boundaries
Want to know at a very high level what the boundaries of the system are, e.g.
Current application areas
Current users
Identify interfaces within organisation
Requirement Analysis : Database design should reflect the information within the organisation
Critical information
Documentation used
Main application areas and user groups
Details of transactions needed
Amount gathered depends on size of organisation and scope of application
Use information to
(1) draw up a prioritised user requirement specification
(2) Document the requirements clearly
Requirements analysis is critical to the success of a development project. A DB system with inadequate functionality will fail => reqs are important
Requirements must be documented, actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Database Design is based on the information about the organisation.
There are many ways of gathering such information
interviewing
observing
examining documents
using questionnaires
using experience from the design of other systems etc
The information gathered should include the main application areas and user groups; the documentation used. Details of the transactions needed. A prioritised user requirement specification should be drawn up. This is a preliminary stage to logical database design. The amount of data gathered depends on the size of the organisation, the scope of the application to be developed etc. It is VERY important to document the requirements and there are all kinds of techniques that can be used for this - Data Flow Diagrams, Document/use matrices etc. You will be studying some of these techniques in the Systems Analysis & design module.
Identifying the required functionality for a database system is crucial, as systems with inadequate functionality will fail.

7. Database Application Lifecycle
Design of the user interface and the application programs that use and process the database.
Application Design :
Building a working model of a database application
Prototyping :
Physical realization of the database and application design
Implementation :

8. Database Application Lifecycle
Transferring any existing data into the new database and converting any existing processes to run on the new database.
Data Conversion and Loading :
Process of executing the application programs with the intent of finding errors.
Testing :
Process of monitoring and maintaining the system following installation.
Operational Maintenance :
Data conversion and Loading: used only if there is an existing system. Normally DBMSs provide a facility to load the data. Eg. Oracle sql loader or other tools such as data pump fmay be used
Testing:

9. Planning Planning Factors Planning Objectives Two stages
The work to be done
The resources to do it
The cost
Planning Objectives
Organisational Units
Consist of various departments
Locations
List of operational locations
Business Functions
Identify related business processes
Entity Types
Something for which data is collected
Must be done within the overall planning strategy of the organisation
Therefore, several factors to be taken into account:
Identify goals of the organisation, e.g.
10% growth per year
No redundancies
Identify critical success factors, e.g.
High quality products
On-time deliveries
Identify problem areas, e.g.
Inaccurate stock control
More competition

10. System Definition Identify boundaries
Want to know at a very high level what the boundaries of the system are, e.g.
Current users
Current application areas
Identify interfaces within organization
Here you want to know at a very high level, what the boundaries of the system are: You might need to think about who the users are, what the current application areas are etc

11. Requirements Analysis
Database design should reflect the information within the organisation
Many ways of gathering information
interviewing
observing
examining documents
using questionnaires
using experience from the design of other systems …
Database Design is based on the information about the organisation.
There are many ways of gathering such information
interviewing
observing
examining documents
using questionnaires
using experience from the design of other systems etc
The information gathered should include the main application areas and user groups; the documentation used. Details of the transactions needed. A prioritised user requirement specification should be drawn up. This is a preliminary stage to logical database design. The amount of data gathered depends on the size of the organisation, the scope of the application to be developed etc. It is VERY important to document the requirements and there are all kinds of techniques that can be used for this - Data Flow Diagrams, Document/use matrices etc. You will be studying some of these techniques in the Systems Analysis & design module.
Identifying the required functionality for a database system is crucial, as systems with inadequate functionality will fail.

12. Requirements Analysis
Critical information
Main application areas and user groups
Documentation used
Details of transactions needed
A prioritized user requirement specification
Amount gathered depends on size of organization and scope of application
Documentation is VERY important
DFD, matrices etc.
The information gathered should include the main application areas and user groups; the documentation used. Details of the transactions needed. A prioritised user requirement specification should be drawn up. This is a preliminary stage to logical database design. The amount of data gathered depends on the size of the organisation, the scope of the application to be developed etc. It is VERY important to document the requirements and there are all kinds of techniques that can be used for this - Data Flow Diagrams, Document/use matrices etc. You will be studying some of these techniques in the Systems Analysis & design module.
Identifying the required functionality for a database system is crucial, as systems with inadequate functionality will fail.
Identifying the required functionality for a database system is crucial:
systems with inadequate functionality will fail

13. Database Design MAIN AIMS To represent data & relationships required
by users and applications
To provide a data model which supports transactions
To specify a design that meets performance requirements

14. Database Design Approaches
BOTTOM UP
begins at the level of attributes and then adds entities as new relationships are seen.
Normalization is an example of this.
TOP-DOWN
starts with the development of the data model that contains a few high level entities and then it refines them in ever increasing detail.
Data modeling comes under this.
There are other approaches, e.g. the back of the fag packet approach (not very successful), and a mixed approach.

15. Phases of database Design
Remember the main phases:
Conceptual Database Design
Logical Database design
Distributed Database Design (optional)
Physical Database Design
The next few slides will examine each of these phases.

16. Conceptual Database Design
Create a conceptual data model
Use data modeling to understand
each users perspective of data
the data
Use of data across applications
Independent of any implementation details
DBMS or physical aspects are immaterial
Based on user requirements specification
assists in understanding data
facilitates communication
Building a data model requires you to ask a lot of questions about entities, relationships etc. We undertake data modelling to try to understand each user’s perspective of the data, to understand the data itself (independently of its physical representation, and to understand the use of data across applications)
We also use data modelling to convey the designers understanding of the data. Data modelling is based on the Entity-Relationship model.
Data Modelling is a top down approach to design - because it starts at the ‘top’ of the organisation and then works down to a more & more detailed view. Very good at identifying the data used in an organisation. It is not normally enough on its own though - because you have no real way of knowing whether all of the entities have been identified.

17. Logical database design
The data model created in the previous phase is refined
At this point you know
which type of DBMS you will implementing in - e.g. relational, object-oriented …
but not the actual DBMS
Test the correctness of the data model through
Normalization
Validation against user transactions
Normalization is a bottom up approach to design. It is driven by a set of rules which determine how the data is structured. It is time consuming to perform. Sometimes it is difficult to know how many levels of normalization should be used. It is also dependent on the analyst understanding the rules. The best approach is usually a combination of both of these. The entity model can be compared to the normalized data model to identify any differences etc.

18. Database selection
A crucial stage in the database Application lifecycle is choosing the DB.
The aim is to choose a system that
allows expansion
enables speedy retrieval
gives easy application development etc.
All data should have been collected and documented before DB selection
Many organizations in practice choose a DBMS purely on the basis of cost.
A crucial stage in the database Application lifecycle is choosing the DB. The aim is to choose a system that allows expansion, that enables speedy retrieval, gives easy application development etc.
Ideally before engaging in DB selection all data should have been collected and documented. Many organisations in practice choose a DBMS purely on the basis of cost.
A simple way to choose a DB is to have a checklist of things to look for.
Terms of Reference
Prior to any software evaluation, the scope of the study should be stated. This should include a potential list of the products to be assessed,the criteria to be used, timescales etc.
Identify products
The info in the terms of reference is used to draw up the list. Decisions about harware, compatibility with existing systems, cost etc should be used to draw up the list. User support, upgrades etc can be taken into account.
Produce Shortlist
Shortlist 2 or 3 products usually by an analysis of the features of each. Get students to write down some of the features that they think could be included. The best way is to weight features so that they can be compared.
Evaluate Products
Allow vendors to give presentations, involve users.
Recommend one
This is the final stage. Produce a report of findings. Give details of the criteria, and how each product measured up.

19. Database selection Define terms of reference Identify products
the scope of the study should be stated
potential list of the products to be assessed
the criteria to be used, timescales …
Identify products
hardware,
compatibility with existing systems,
cost ..
User support
upgrades …
Produce shortlist of products
Shortlist 2-3 products
Evaluate products
Ask Vendors
Involve Users
Recommend selection and produce report
Give details of criteria used
Compare/Contrast alternatives
A simple way to choose a DB is to have a checklist of things to look for.
Terms of Reference
Prior to any software evaluation, the scope of the study should be stated. This should include a potential list of the products to be assessed,the criteria to be used, timescales etc.
Identify products
The info in the terms of reference is used to draw up the list. Decisions about harware, compatibility with existing systems, cost etc should be used to draw up the list. User support, upgrades etc can be taken into account.
Produce Shortlist
Shortlist 2 or 3 products usually by an analysis of the features of each. Get students to write down some of the features that they think could be included. The best way is to weight features so that they can be compared.
Evaluate Products
Allow vendors to give presentations, involve users.
Recommend one
This is the final stage. Produce a report of findings. Give details of the criteria, and how each product measured up.

20. Physical Database Design
HOW to physically implement the logical data model
derive tables & constraints
identify storage structures and access methods
design security features
The aim of physical design is to describe how we intend to physically implement the logical data model. At this point the target DBMS is known. Physical design is about HOW. Logical design is about WHAT.
We will look in detail later at the steps to go through to physically implement a design.
Derive Tables etc
Storage structures e.g.
B-Tree - , hashing etc., choosing indexes etc. Demoralization for performance purposes etc.
Security - who uses what, authorization rules etc.

21. Application Design Design transactions Design human interface
Design of software programs which will process the data
Design transactions
data to be used by transactions
functions of the transactions
output of transactions
programs
Design human interface
Various guidelines
Application design is the design of software programs which will process the data. There are several techniques for specifying the high level transactions that need to occur. The design of transactions is based on the information given in the requirements specification.
Design Interface (ITEC333)
- meaningful titles,
- good instructions
- consistent use of colour etc

22. Prototyping used to check Building a working model
developer’s understanding of what is required
interpretation of requirements
Building a working model
Inexpensive & quick to build
At various points we can build a prototype. It is primarily used to check developer’s understanding of what is required. There are different kinds of prototyping, e.g. simulation

23. Implementation Database created using DDL
Implement application programs using selected language
Implement security & integrity controls
On completion of the design stage we are ready to implement.

24. Data Loading/Conversion
Transfer any existing data
Insert any new data
Usually there is a facility within the DBMS to load data into a database
This stage is only used when there is an existing system. Usually there is a facility within the DBMS to load data into a database. (e.g. In Oracle this facility is called SQL Loader)

25. Testing
The process of executing the application programs with the intention of finding errors.
Use realistic data
Involve users
There are various strategies that can be used:
White Box
Black box testing
This is achieved through strategies for testing. This means using realistic data. Users should be involved in testing. There are various strategies that can be used- White Box & Black box testing (software engineering course)

26. Maintenance Monitoring Performance Maintaining and Upgrading
Various tools are available
Maintaining and Upgrading
Once the DB is fully operational, close monitoring should take place to ensure that performance is acceptable. Usually there are various monitoring tools that are available to do this.

27. Database Development Phases
Conceptual Data
Modeling
Logical Database
Design
Distributed Database
Physical Database
ERD
Tables
Distribution Schema
Internal Schema, Populated DB
Data requirements
OPTIONAL
Input:
- Data requirements come in many formats
- Description of data needs
- Documentation of existing system
- Proposed forms and reports
Phases:
- Logical information content: Conceptual data modeling and logical database design
- Performance: distributed and physical db design

28. Database Design
Conceptual database design - the process of constructing a model of the information used in an organization, independent of all physical considerations
Step 1 Build local conceptual data model for each user view

29. Database Design
Logical database design for the relational model - the process of constructing a model of the info used in an organization based on a specific data model, but independent of a particular DBMS and other physical considerations
Step 2 Build and validate local data model for each user view
Step 3 Build and validate global logical data model

30. Database Design
Physical database design for relational databases - the process of producing a description of the implementation of the database on secondary storage.
Step 4 Translate global data model for target DBMS
Step 5 Design physical representation
Step 6 Design security mechanisms
Step 7 Monitor and tune the operational system

31. Phases of Database Design
Process of constructing a model of the information used in an enterprise independent of all physical considerations
Conceptual Database Design
Process of constructing a model of information used in an enterprise based on a specific data model but independent of a particular DBMS or any other physical considerations
Logical Database Design
(Optional)Process of deciding about the placement of data across the sites of a computer network. Involves designing the network itself, as well as distribution of DBMS software, DB applications and data
Distributed Database Design
Description of the implementation of the database on secondary storage. It describes the storage structures and access methods for efficient access.
Physical Database Design

32. Overview of Database Design
Build local conceptual data model for each user view
Conceptual
Logical
Build and Validate local logical data model for each user view
Build and validate global logical Model
Translate global logical model for target DBMS
Physical
Design Physical representation
Design Security Mechanisms
Monitor and Tune operational system

33. Centralized Approach to Managing Multiple User Views
We do not use this approach
Pearson Education © 2009

34. View Integration Approach to Managing Multiple User Views

35. Conceptual Database Design
Build local logical data model for each user view
1.1 Identify entity types
1.2 Identify relationship types
1.3 Identify and associate attributes with entity or relationship types
1.4 Determine Attribute Domains
1.5 Determine candidate and primary key attributes
1.6 Specialize/generalize entity types
1.7 Draw Entity-Relationship Diagram
1.8 Review local conceptual data model with user

36. Conceptual Database Design
1. Build local logical data model for each user view
1.1
Identify entity types
1.2
Identify relationship types
1.3
Identify and associate attributes with entity or relationship types
1.4
Determine Attribute Domains
1.5
Determine candidate and primary key attributes
1.6
Specialize/generalize entity types
1.7
Draw Entity-Relationship Diagram
1.8
Review local conceptual data model with user

37. Logical Database Design
Build and validate local logical data model
2.1 Map local Conceptual data model to local local data model
2.2 Derive relations from local logical data model
2.3 Validate model using normalization
2.4 Validate model against user transactions
2.5 Draw Entity relationship Diagram
2.6 Define integrity constraints
2.7 Review Local logical data model with user

38. Logical Database Design
2. Build and validate local logical data model
2.1
Map local Conceptual data model to local logical data model
2.2
Derive relations from local logical data model
2.3
Validate model using normalization
2.4
Validate model against user transactions
2.5
Draw Entity relationship Diagram
2.6
Define integrity constraints
2.7
Review Local logical data model with user

39. Logical Database Design
Build and Validate Global Logical data model
3.1 Merge local logical data models into global model
3.2 Validate global logical data model
3.3 Check for future growth
3.4 Draw final Entity Relationship diagram
3.5 Review global logical data model with users

40. Logical Database Design
3. Build and Validate Global Logical data model
3.1
Merge local logical data models into global model
3.2
Validate global logical data model
3.3
Check for future growth
3.4
Draw final Entity Relationship diagram
3.5
Review global logical data model with users

41. Physical Database Design
Translate Global Logical Data Model for target DBMS
4.1 Design base relations for target DBMS
4.2 Design enterprise constraints for target DBMS
Design Physical Representations
5.1 Analyze transactions
5.2 Choose file organizations

42. Physical Database design
5.3 Choose secondary indexes
5.4 Consider introduction of controlled redundancy
Design Security Mechanisms
6.1 Design user views
6.2 Design access rules
Monitor and tune operational system

43. END OF LECTURE