2nd course

Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle

MODULE TITLE: Designing a Database

NOMINAL DURATION: 120 hrs
LO1: Determine database requirements
1.1 Introduction to the module
Designing a database is a very important phase in the database life cycle, which precedes all other phases except the
requirements collection and the analysis. if the database design is created merely intuitively (without needing to ask)
and without any plan, the resulting database will most likely not meet the user requirements concerning
performance.
Another consequence of a bad database design is superfluous data redundancy, which in itself has two
disadvantages: the existence of data anomalies and the use of an unnecessary amount of disk space.
1.2 Determining database functionality
In determining database functionality, a user need analysis is conducted / performed to determine database
functionality.
A database program must be able to add, delete and edit records in the tables which make up the database and also to
search for specific records in the tables by using different search criteria. In most cases, user authentication is
required.
1.3 Identifying technical requirements
Identifying technical requirements enable the business or process to meet expectations.
Identify technical requirements involves:
 Assessing the business problem(including input/output requirements, interface requirements, process
requirements)
 Developing a business solution.
 Investigating output/result.
 Documenting results/output.
Assess the business problem:
To assess a problem or an opportunity faced by a business, it is necessary to look at the technical requirements of the
business. These fall into three general categories: - Input/output requirements
- Interface requirements
- Process requirements
o Input/output requirements
The stages involved in identifying technical requirements for input/output:
- Identify the interaction process(whether for business to business or business to costumer)
- Identify the input/output data required for the process
- Identify relevant protocols for the data exchange
o Interface requirements: - Many computer-based systems require data from other systems or provide data to
another system.
The stages involved in identifying the interface requirements include:
- Identify the sources of required data
- Identify the data items and data structures required for the exchange
- Identify relevant protocols for the data exchange

o Process requirements
Identifying technical requirements for how the system will function and what the system will do, are identifying
the processes, qualities and environment requirements of the system.
Once the technical requirements have been identified, it is possible to develop a solution.
Finally, the recommendations will need to be measured against the technical requirements and documented.
1.4 Developing conceptual model of the database
Database Administrator Level III by instructor kayisle k date 13/09/2016E.c
 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
Conceptual database design is the process of constructing a model of the information used in an enterprise,
independent of any physical considerations.
- It is a High level description of the data and the constraint.
- It is the source of information for the logical design phase.
- It mostly uses an Entity Relationship Model to describe the structure at this level.
In developing conceptual model of the database, the designer should answer the following question:
– What are the entities and relationships in the enterprise?
– What information about these entities and relationships should we store in the database?
– What are the integrity constraints or business rules that hold?
• Conceptual database Model Concepts includes:
Entities and Attributes
Entity Types, Value Sets, and Key Attributes
Relationships and Relationship Types
Weak Entity Types
Roles and Attributes in Relationship Types
ER Model Notations, Naming Conventions, Design Issues.
LO2: Develop logical data model
2.1 Identifying attributes
An attribute is a fact or non-decomposable piece of information about an entity. When you represent an entity as a
table, its attributes are added to the model as columns.
After you determine the entities, you can identify the characteristics of each entity.
To select attributes, you have to check:
- It’s significant.
- It’s Usefulness to the database users.
- It is non-decomposable. Composite values must be separated into individual attributes.
2.2 Determining data types
Data Type is a constraint that specifies the possible value for each field in the table.
Common examples of data type:
i) In MS-Access – Auto-number, text, number, date\Time, currency, Yes/No, and so on.
ii) In MS-SQL server - integers, Booleans, characters, floating-point numbers, datetime, and so on.
2.3 Undertaking normalization of attributes
Normalization is a process that involves dividing large tables (complex data structures) into smaller (simple and
stable data structures) that do not accept redundant values and defining relationships between them.
Database normalization is the process of organizing the fields and tables of a relational database to minimize
redundancy and to avoid update anomalies (insert, modify, and delete anomalies).
If an attribute of a table is multi-valued, it must be normalized.
 Functional dependency
A functional dependency (FD) is a constraint between two sets of attributes in a table from a table in the database.
* A functional dependency occurs when one attribute in a table uniquely determines another attribute. This can
be written as: A  B ("B is functionally dependent upon A").
If a particular value of one attribute (A) in a table uniquely determines the value of another attribute (B) in the same
table, then there is a functional dependency between attributes A and B.

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
Examples: In a table employee’s characteristic including employee ID and name, it can be said that name is
functionally dependent upon ID because an employee's name can be uniquely determined from their ID. However,
the reverse statement is not true because more than one employee can have the same name but different ID.
 Full functional dependency
A full functional dependency occurs when you already meet the requirements for a functional dependency and the
set of attributes on the left side of the functional dependency statement cannot be reduced any farther.
Example: {SSN, age} name is a functional dependency, but it is not a full functional dependency because you
can remove age from the left side of the statement without impacting the dependency relationship.
 Transitive dependency.
Transitivity dependency is a functional dependency between non-primary-key.
I.e.: It occurs when there is an indirect relationship that causes a functional dependency.
Example: AC is a transitive dependency when “A  B” and “B  C” are true.
A relation can be normalized to a specific form to prevent possible occurrence of update anomalies.
Four most commonly used normal forms are: - First (1NF)
- Second (2NF)
- Third (3NF) normal forms, and
- Boyce–Codd normal form (BCNF).
 1st Normal Form (1NF):
A table is in 1NF if: - There are no duplicated rows in the table.
- Each cell is single-valued.
- Entries in a column (attribute, field) are of the same kind.
 2nd Normal Form (2NF):
A table is in 2NF if: - it is in 1NF
- All non-key attributes are dependent on the entire key (has no partial dependencies).
 3rd Normal Form (3NF):
A table is in 3NF if: - It is in 2NF
- If it has no transitive dependencies.
- There are no functional dependencies between two or more non-primary-key attributes.
Example: a table named VEHICLE, and its characteristics are Registration_No, Owner, Model, Manufacturer, and
Engine_Size, where the Registration_No is the primary key:

Registration_No Owner Model Manufacturer Engine_Size

10234 TDA Land Cruiser I Toyota 2.5
10545 REST Land Cruiser II Toyota 2.9
45454 TDA Jeep Nissan 2.5
46765 REST Land Cruiser I Toyota 2.5
54098 Mekelle University Jeep Nissan 2.5
a) Is this table satisfy the 1NF?
b) Is this table satisfy the 2NF?
c) Is this table satisfy the 3NF?

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
A) This table satisfies 1NF because: - no duplicated rows in the table
- Each cell is single-valued.
- Entries in a column are of the same kind.
B) This table satisfies 2NF because:
It is in 1NF
All non-key attributes are dependent on the key attribute. The Registration_No uniquely determines
the value of the all non-key.
C) This table does not satisfy 3NF because there is a transitive dependency (there exist functional dependencies
between non-primary-key attributes even though it satisfies 2NF).
The Model name uniquely determines the values of the Manufacturer and the Engine_Size.
Model Manufacturer, Engine_Size (different Manufacturers do not use the same model names).
Because of this transitivity dependency, the VEHICLE does not satisfy 3NF.
To convert the table to 3NF:
 Remove transitivity dependency by creating a new table with the attributes in the dependency.
 The determinant attribute(s) being the primary key of the new table and foreign key for the old table.
I.e.: table1: REGISTRATION (Registration_No, Owner, Model)
Table2: VEHICLE (Model, Manufacturer, Engine_Size)
Now, both the VEHICLE and REGISTRATION tables are in 3NF because:
- They are in 2NF (every non-primay-key attribute is functionally dependent on the whole primary key)
- No dependencies between non-primary-key attribute (No transitivity dependency in each table).
 Boyce–Codd normal form (BCNF).
A table is in BCNF if:
- It is in 3NF and every determinant is a candidate key.
- There are no non-trivial functional dependencies of attributes on anything other than a superset of a candidate key.
BCNF is also sometimes referred to as 3.5 Normal Form (it is really an extension of 3rd Normal Form).
 Anomalies can occur in relations in 3NF if there is a composite key in which part of that key has a
determinant which is not itself a candidate key.
 This can be expressed as R(A,B,C), C--->A where:
. The relation R contains attributes A, B and C.
. A and B form a candidate key.
. C is the determinant for A (A is functionally dependent on C).
. C is not part of any key.
 Anomalies can also occur where a relation contains several candidate keys where:
. The keys contain more than one attribute (they are composite keys).
. An attribute is common to more than one key.

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
2.4. Developing Entity Relationship to clarify cardinality of relationships.
An entity-relationship model (a graphical representation of entities and their relationships to each other) describes
the organization of data within databases or information systems.
In developing Entity Relationship model, the building blocks are:
 Entities
- Entity types fall into five classes: roles, events, locations, tangible things or concepts.
 Relationships
- A data relationship is a natural association that exists between one or more entities.
E.g. Employees process payments.
 Cardinality
Defines the number of occurrences of one entity for a single occurrence of the related entity.
E.g. an employee may process many payments, but a payment can be processed by only
one employee.
 Attribute
Name the information details (fields) which are essential to the system under development.

 Cardinality Notations
Cardinality specifies how many instances of an entity relate to one instance of another entity.
Ordinarily is also closely linked to cardinality. While cardinality specifies the occurrences of a relationship,
ordinarily describes the relationship as either mandatory or optional. In other words, cardinality specifies the
maximum number of participation and ordinarily specifies the absolute minimum number of participation. When the
minimum number is zero, the relationship is usually called optional and when the minimum number is one or more,
the relationship is usually called mandatory.
There are many notation styles that express cardinality and they are all supported by Smart Draw and Visio
drawing software.
i. Information Engineering

ii. Chen

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle

iii. Bachman

iv. Martin

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
2.5. Normalizing data and entity relationships diagrams
Multi-valued dependency equivalency in ERD occurs when attributes within an entity instance have more than one
value. This is a situation when some attributes within an entity instance have maximum cardinality of N (more than
1 )when an attribute has multiple values in an entity instance, it can be setup either as a composite key identifier of
the entity type, or split into a weak entity type.
Each instance of an entity type has exactly one value for its attributes.
2.6. Forwarding documentation to client
Database documentation enables a Database designer or developer to deliver the designed system to the client.
The documentation describe the design of a database which is a collection of related data stored in one or more
computerized files in a manner that can be accessed by users or computer programs via a database management
system. The design documentation must include:
General nature of the database
Business context of database
Intended use.
Maintenance objectives/Operations
Design decisions on backup and restoration includes data and process distribution strategies, permissible actions
during backup and restoration, and special considerations for new or non-standard technologies.

LO3. Design data structures

3.1 Confirming primary and foreign keys for tables
A primary key is a column which uniquely identifies the records in a table. Most programmers recommend all
tables having a primary key (only one) to enhance the speed of queries and overall database performance.
A foreign key is a column in a table that refers a value from another table to create relationship between the tables.
A candidate key is any attribute of a table that can accept unique value in the table and it could be set as a primary
key for a table.
3.2. Reviewing client business rules
A business rule is a rule of a business, company, or corporation that defines or constrains some aspect of business.
It describes the operations, definitions and constraints that apply to an organization or business.
3.3. Identifying referential integrity constraints
Integrity constraint is a constraint which used to ensure accuracy and consistency of data in a relational database by
prevents the user from entering the duplicate rows into tables.
Types of integrity constraints:
• Entity integrity
The entity integrity constraint states that no primary key value can be null, and there is no any duplicate entries in
the primary key column.
• Referential Integrity
Referential integrity is a feature provided by relational DBMS that prevents users from entering inconsistent data.

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
The referential integrity constraint is specified between two tables and is used to maintain the consistency among
tuples in the two tables.
Referential integrity means the foreign key in any referencing table must always refer to a valid row
in the referenced table.
• Domain Integrity
The domain integrity states that every element from a table should respect the type and restrictions of its
corresponding attribute. A type can have a variable length which needs to be respected. Restrictions could be the
range of values that the element can have, the default value if none is provided, and if the element can be NULL.
• User Defined Integrity
Business rules may dictate/state that when a specific action occurs further actions should be triggered. For example,
deletion of a record automatically writes that record to an audit table.
3.4. Establishing DBMS constraints
Constraints within a database are rules which control values allowed in columns and also enforce the integrity
between columns and tables.
 Constraints are used to limit the type of data that can go into a table.
 Constraints can be specified when a table is created (with the CREATE TABLE statement) or after the table
is created (with the ALTER TABLE statement).

3.5. Developing validation rules for data

One of the main goals when building applications is to make sure that the data you enter into the database meets all
your business rules.
Data validation is a critical part of your application to ensure that your data meets the requirements developed by
your business analysts.
Designing indexes
An index is a set of one or more keys which is used to speed up access to data in a table. An index is a separate
physical data structure that enables queries to access one or more data rows fast.
Proper index design is the most important issue in tuning (alteration) SQL Server performance.
A number of ways are available to improve SQL Server performance, but the greatest speed improvement results
from having indexes that the optimizer can use to avoid table scans and reduce the I/O costs of resolving queries.
Why Use Indexes? Two primary reasons exist for creating indexes in SQL Server:
To maintain uniqueness of the indexed column(s)
To provide fast access to the data in tables.
3.6. Developing data dictionary
A data dictionary is a collection of descriptions of the data or items in a data model for the benefit of programmers
and others who need to refer to them. I.e.: It is a file that defines the basic organization of a database.
A data dictionary contains:
 The definitions of all schema objects in the database (tables, views, indexes, clusters, procedures, functions,
triggers, and so on).
 Name of the tables, names of attributes of each table, Data type of each field, Length of each field.
 How much space has been allocated for, and is currently used by the schema objects.
 Default values for columns
 Logical structure of database
 Integrity constraint information
 Privileges and roles each user has been granted
 Auditing information, such as who has accessed or updated various schema objects
Database Administrator Level III by instructor kayisle k date 13/09/2016E.c
 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
 Constraints that apply to each field, if any
 Brief description of the expected data for each field (Constraints on data i.e. range of values permitted).
 Access Authorization - the Description of database users, their responsibilities and their access rights.
 Relationships between database transactions and data items.

Example of data dictionary

Table Name Column Name Data type Field size Null Validation Description
EMPLOYEE Fname Char 15 No First name of employee
Lname Char 15 No Last name of employee
Emp_Id Varchar 5 No Employee identity
Gender Char 6 No Male or female
Dept_No char 10 Yes
PROJECT Pname Char 17 No
Pcode Char 10 No
Ptype Char 25 Yes
DEPARTMENT Dname Char 20 No
Dnumber Varchar 10 No
Mgr_Id Varchar 5 Yes

Data dictionaries do not contain any actual data from the database, only bookkeeping information for managing it.
Advantages of a Data Dictionary
When a new user is introduced to the system or a new administrator takes over the system, identifying table
structures and types becomes simpler.
3.7. Documenting database design
Database design documentation is detailed information about a database’s design specifications, its internal
workings, and its functionality.
Database design documentation should include:
• Conceptual data model
Conceptual database design is the process of constructing a model of the information used in an enterprise.
- It is a High level description of the data and the constraint.
- It includes:
Entities and Attributes
Entity Types, Key Attributes, and Value Sets
Relationships and Relationship Types
Weak Entity Types
Roles and Attributes in Relationship Types
ER Model Notations, Naming Conventions, Design Issues.
• Logical data model is a fully attributed entity relationship diagram (ERD), which shows each entity, its
relationship to other entitles, normalized structures, and specifies the applicable business rules.
• Physical data model is the final representation of the relational database design structures(physical
implementation, access method and storage requirements).

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle

LO4. Design queries, screens and reports

4.1 Designing user interface for database
A user interface is an interface by which people (users) interact with a machine.
User interfaces exist for: - Input, allowing the users to manipulate a system
- Output, allowing the system to indicate the effects of the users' manipulation.
 In Designing user interface for a database, there are two basic things:
i. Form – a form is an interface that contains some predefined data and may include some areas where
Additional data are to be filled in.
ii. Report – a report is a passive business document that used only for reading and viewing.
- It can contain data from many unrelated records or transactions.
 Guidelines for designing forms (Structuring Data Entry) and reports:
 Defaults -Always provide default values when appropriate.
 Captioning - Always place a caption adjacent to fields.
 Format - To ease user training and data recording, use standard formats for forms and reports similar to
paper- based standard forms and reports format.
 Help -Provide context-sensitive help when appropriate, for example, provide a hot key, such as the F1
key, that opens the help system on an entry.
 Use meaningful titles - clear and specific titles describing content and use of form or report.
 Design an easy navigation system - Clearly show how to move forward and backward
4.2 Designing queries based on requirements
Queries are a way of searching for and compiling data from one or more tables. When you build a query, you are
defining specific search conditions to find exactly the data you want.
Queries allow you to pull information from one or more tables based on a set of search conditions you define.
When planning (designing) a query that uses two or more tables, you should follow these steps:
i. Identify every type of information you want to include in your query results.
ii. Determine the criteria that meet to retrieve the information you need.
SQL Server Management Studio has a GUI (Graphical User Interface) called ‘Query Designer’ that easily allows
users to create queries without prior knowledge of SQL.
The Query Designer allows the users to select the Data Sources of the query (which can be tables, views or
functions) and select the fields they want returned by clicking the checkbox next to the name of the desired field.
4.3. Designing output reports based on requirements
A report is a formatted and organized presentation of database information which can be an easy-to-read and print.
Database reports are the formatted result of database queries and contain useful data for decision-making and
analysis. It must always be accurate, concise, clear, and well structured.
You can design the report by using Report Designer (graphical query and design tools) which is hosted within the
Microsoft Visual Studio environment.

Report Designer provides a Report Data pane to organize data used in your report, and tabbed views for Design and
Preview so that you can design a report interactively.

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle
Report Designer also provides query designers to help specify data to retrieve from data sources and the Expression
dialog to specify report data to use in the report layout.

Report Designer is hosted in the Business Intelligence Development Studio, which is fully integrated with the
Microsoft Visual Studio 2008 development environment. If you do not have Visual Studio 2008 installed, SQL
Server Setup installs the shell so that you can run Report Designer.

4.4. Comparing physical design with conceptual model/user needs.

Physical design is the process of producing a description of the implementation of the database on secondary
storage. It defines specific storage or access methods used by a database.
I.e: - It describes the storage structures and access methods used to achieve efficient access to the data.
Conceptual design is the process of constructing a model of the information used in an enterprise, independent of
any physical considerations. It mostly uses an Entity Relationship Model to describe the structure.
The important activities in conceptual design are to identify:
Entities Relationships
Attributes Constraints
LO5. Design access and security systems
5.1 Reviewing business security plan
Business security plan make sure that security is part of your business planning process.
When setting up a security plan, your business should consider all the relevant areas of its operations.
5.2. Designing password and access system
A Windows user account or a login allows a user to log in to the system. A user who subsequently wants to access a
particular database of the system may needs a database user account to work with the database.
Therefore, users must have a database user account for each database they want to use. The database user account
can be mapped from the existing Windows user accounts, Windows groups (of which the user is a member), logins,
or roles.
Setting Up Database User Accounts and login:
Most Windows users need SQL Server login account to connect to SQL Server. This shows how to design a SQL
Server login account.
* User name is the name that is used to identify the user inside the database.
* Login specifies the login for which the user is being created.
* A password is a secret word or string of characters that is used for user authentication to prove identity, or
for access approval to gain access to a resource.

5.3. Identifying multiple-user requirements

A requirement is a statement that specifies what an intended product should do, or how it should perform.
Types of requirements:
Functional requirements specify what the system should do.
Non-Functional requirements specify what constraints there are on the system or its development.
Identifying user needs:
 Identifying user needs means understand as much as possible about the users, as well as their work and the
context of their work. System under development should support users in achieving their goals.

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle

LO6: Confirm database design

6.1. Identifying database back-up and recovery requirements
Database backup is the process of dumping data (from a database, a transaction log, or a file) into backup devices
that system creates and maintains.
- I.e.: A backup is a copy of data from your database that can be used to reconstruct that data.
Backups can be divided into physical backups and logical backups.
 Physical backups are backups of the physical files used in storing and recovering your database, such as data
files, control files, and archived redo logs.
 A logical backup (export) of a database exports the database objects independent of the physical location of
those objects. Ie: a logical backup exports the data stored in a table regardless of the location of the table.
Recovery is the process of using the backup media to replace uncommitted, inconsistent, or lost data.
The reasons for data loss can be divided into the following groups:
- Program errors
- Administrator (human) errors
- Computer failures (system crash)
- Disk failures
- Catastrophes (fire, flood, earthquake) or theft
Therefore, Backup and recovery refers to the various strategies and procedures involved in protecting your
database against data loss and reconstructing the database after any kind of data loss.
The SQL Server backup and restore component provides an essential safeguard for protecting critical data stored in
your SQL Server databases. To minimize the risk of catastrophic data loss, you need to back up your databases to
preserve modifications to your data on a regular basis. A well-planned backup and restore strategy helps protect
databases against data loss caused by a variety of failures.

Database Engine provides four different backup methods:

- Full database backup
- Differential backup
- Transaction log backup
- File (or file group) backup
Full Database Backup
A full database backup captures the state of the database at the time the backup is started. During the full database
backup, the system copies the data as well as the schema of all tables of the database and the corresponding file
structures. If the full database backup is executed dynamically, the database system records any activity that takes
place during the backup.
Differential Backup
A differential backup creates a copy of only the parts of the database that have changed since the last full database
backup.
The advantage of a differential backup is speed. It minimizes the time required to back up a database, because the
amount of data to be backed up is considerably smaller than in the case of a full database backup.
Transaction Log Backup
A transaction log backup considers only the changes recorded in the log. This form of backup is therefore not based
on physical parts (pages) of the database, but rather on logical operations (that is, changes executed using the DML

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c

 2nd course
Occupied
Course title : design database occupation : WDDBA level 3 accdemic year 2016
by
instructor
New diplomatic colege
kayisle

statements INSERT, UPDATE, and DELETE). Because the amount of data is smaller, this process can be performed
significantly quicker than a full database backup and quicker than a differential backup.
File or File group Backup
File (or file group) backup allows you to back up specific database files (or file groups) instead of the entire
database. In this case, Database Engine backs up only files you specify.
Individual files (or file groups) can be restored from a database backup, allowing recovery from a failure that affects
only a small subset of the database files. You can use either a database backup or a file group backup to restore
individual files or file groups.

Database Administrator Level III by instructor kayisle k date 13/09/2016E.c