DATABASE DESIGN

AND DEVELOPMENT
SESSION 1
• Data - Raw fact or unorganized form. (Such as
alphabets, numbers or symbols)
• Information- Knowledge, Intelligence, a particular
piece of data with a special meaning of a function.
DATABASE

• Is a collection of related data.

• A shared collection of logically related data and a
description of this data, designed to meet the
information needs of an organization.
TYPES OF DATABASE

• There are two types of database

• Manual Database
• Electronic Database
Manual Database
• A manual database is a hard-file storage system that consists of paper
records, folder and filling cabinets or storage boxes.
Electronic Database
• An electronic database is, any collection of data or information, that is
specially organized for rapid search, update, delete and retrieve by
computer.
 COMPARISON

Manual Database Electronic database

• limited storage space available • can store very large amount of data
• difficult to access • allow easy input and editing of data
• very difficult to share • sharing is very easy
• extra cost of storing multiple copies • allow centralized use of information
• amongst many users over a network

• worse when new items are frequently • improved backup and recovery services
• being inserted or deleted
• less data security • data security is very high
• data inconsistency • data consistency
PROS AND CONS OF USING ELECTRONIC
DATABASE
PROS CONS
• Data independence • Complexity
• Efficient data access • Size
• Data integrity and security • Cost of DBMS system
• Data administration • Additional hardware costs
• Concurrent access and crash recovery • Cost of conventions
• reduced application development time • Higher impact of failure
USES OF DATABASE

• Store large number of records

• Read and modify data
• Atomicity
• Secured data collection
COMPONENTS OF DATABASE SYSTEM

1. Hardware
2. Software
• DMBS
• Application software

3. People
• Users
• Practitioners

4. Data
DATABASE MANAGEMENT SYSTEM (DBMS)

• A Database Management System (DBMS) is a software

designed by using technology to store, retrieve, define and
manage data in a database.
DATABASE DESIGN PROCESS

• Database design process is:

1. Requirement’s collection and analysis
2. Conceptual design
3. Logical design/ data model mapping
4. Physical design
REQUIREMENT

• Requirements convey the expectations of users from the

software.
• The requirements can be known or unknown, obvious
or hidden, expected or unexpected from client’s point of
view
TYPES OF REQUIREMENTS
USER REQUIREMENTS

• Simply, user requirements can be referred as user needs. It describes

what the user does with the system.
• In a database system, identifying user requirements are the main task.
• Discuss some examples
• User requirements can be defined using natural language, charts,
tables and diagrams.
SYSTEM REQUIREMENTS

• The system requirements define what software programs or hardware devices should
require to operate the program
• Software requirement- e.g. Functional Requirements
1. Searching requested details
2. Printing requested invoices
3. Comply administrative functions

• Non-functional requirements- e.g.

1. Security
2. Storage
3. Logging
HARDWARE REQUIREMENT

• To run a database system very efficiently there are should be

very good hardware devices.
1. Enough hard disk space
2. SSD used to fasten the performance
3. A RAM which can handle database process
4. A processor which can handle a database.
• There are four types of requirements which are categorized logically as,
• Must have: Software cannot be said to be operational without them
• Should have: Enhancing the functionality of the software
• Could have: Software can still function properly with these
requirements
• Wish list: These requirements do not map to the objectives of the
software
DATABASE KEYS

• Identifying key field for tables is the main task of creating a database.
• A key is an attribute or set of attributes which helps to identify a row
(tuple) in a relation
• (table). Keys allow to find the relationship between two tables. Several
types of keys can be defined in DBMS as per those;
TYPES OF KEYS

• Super key
• A super key is a loop of single or multiple keys which identifies row in a table. A
super key may have additional attributes which are not needed for identification.
• Candidate key
• Candidate key is a set of attributes that uniquely identify tuples in a table. It is a
super key with no repeated attributes. The primary key should be selected from the
candidate keys. Every table must have at least a single candidate key.
• Primary key
• Primary key is the attribute or set of attributes which uniquely identify every tuple in
the table. The values of the primary key cannot be repeated. The table cannot have
more than one primary key.
• Alternate key
• A table can have multiple choices for a primary key but only one can be set as the
primary key. All the keys which are not set as primary key are known as alternate
keys.
• Composite key
• Composite key is a combination of two or more attributes which
uniquely identify rows in a table.
• Foreign key
• Foreign key is an attribute that create a relationship between two
tables. It acts as across reference between two tables and a foreign key
always references the primary key of another table.
NORMALIZATION

• Normalization is a database design technique that reduces data redundancy

and eliminates undesirable characteristics like Insertion, Update and
Deletion Anomalies. Normalization rules divides larger tables into smaller
tables and links them using relationships.
• The purpose of Normalization in SQL is to eliminate redundant (repetitive)
data and ensure data is stored logically.
• It is a multi-step process that puts data into tabular form, removes
duplicate data, and set up the relationship between tables.
• There is less repetition of data,
• A large set of data is structured into a bunch of smaller tables,
• And the tables have a proper relationship between them.
Normalization is required for,
• Eliminating redundant(useless) data, therefore handling data integrity,
because if data is repeated it increases the chances of inconsistent data.
• Normalization helps in keeping data consistent by storing the data in
one table and referencing it everywhere else.
• Storage optimization although that is not an issue these days because
Database storage is cheap.
CONT..

• Breaking down large tables into smaller tables with

relationships, so it makes the database structure more scalable
and adaptable.
• Ensuring data dependencies make sense i.e. data is logically
stored.
PROBLEMS WITHOUT NORMALIZATION IN DBMS

• Eat up extra memory space

• Difficult to handle and update the data in the database, without
losing data.
• Insertion, Updation, and Deletion Anomalies are very frequent
if the database is not normalized.
DATABASE ANOMALIES

• To understand these anomalies let us take an example of a Student table.

data for four Computer Sci. students.

• As we can see, data for the fields branch, hod(Head of
Department), and office_tel are repeated for the students who
are in the same branch in the college, this is Data Redundancy.
DATA REDUDANCY WILL LEAD TO PROBLEMS
SUCH AS
1. Insertion Anomaly in DBMS
• Suppose for a new admission, until and unless a student opts for a branch,
data of the student cannot be inserted, or else we will have to set the
branch information as NULL.
• Also, if we have to insert data for 100 students of the same branch, then
the branch information will be repeated for all those 100 students.
• These scenarios are nothing but Insertion anomalies.
ADDING A NEW STUDENT MEANS REPEATING SAME INFORMATION IN THE DB
REASON TO WHY THESE IS HAPPENING
2. Deletion Anomaly in DBMS
• In our Student table, two different pieces of information are kept together, the Student
information and the Branch information.
• So if only a single student is enrolled in a branch, and that student leaves the college, or
for some reason, the entry for the student is deleted, we will lose the branch information
too.
• So never in DBMS, we should keep two different entities together, which in the above
example is Student and branch,
• If you start deleting student information the branch information is also deleted
3. Updation Anomaly in DBMS
• What if Mr. X leaves the college? or Mr. X is no longer the HOD of the
computer science department? In that case, all the student records will
have to be updated, and if by mistake we miss any record, it will lead to
data inconsistency.
• This is an Updation anomaly because you need to update all the records in
your table just because one piece of information got changed.
NORMALISATION WILL BREAK THE STUDENT TABLE INTO TWO SEPARATE TABLES
• If you have to repeat the same data in every row of data, it's
better to keep the data separately and reference that data in
each row.
• So in the above table, we can keep the branch information
separately, and just use the branch_id in the student table,
where branch_id can be used to get the branch information.
BRANCH TABLE WILL HAVE ONLY ONE RAW OF DATA WITH CAN BE REFERENCED
STUDENT TABLE WILL HAVE A RELATIONSHIP WITH THE BRANCH TABLE USING THE BRANCH ID i.e. CS
Normalization doesn’t eliminate redundancy but reduces it
Only branch info that’s keeps separately is now repeated here
Changes made on the Branch table will also update on the Student table
• The solution for all the three anomalies described above is to
keep the student information and the branch information in
two different tables. And use the branch_id in the student table
to reference the branch.
PRIMARY KEY AND NON-KEY ATTRIBUTES
• In the table above, the student_id column is a primary
key because using the student_id value we can uniquely
identify each row of data, hence the remaining columns then
become the non-key attributes.