The document provides an overview of database design and development, detailing various types of database systems, concepts, and components including transaction processing systems, management information systems, and data warehouses. It outlines the phases of database design, including conceptual and logical design, and discusses key elements such as metadata, attributes, relationships, and database normalization. Additionally, it highlights the importance of understanding user requirements and the entire lifecycle of database development.

1. Er. Nawaraj Bhandari
Database Design &
Developmentf
Topic 1:
Introduction to the Module

2. Module Database : Exam Pattern
 Written Exam : 50%
 Global Assignment : 50%

3. Overview of the Module
1 Introduction to the Module
Key concepts in databases and database development
2 Enhancing Design 1
3 Enhancing Design 2
4 Data Retrieval 1
5 Data Retrieval 2
6 Physical Design 1
7 Physical Design 2
8 Physical Design 3
9 Physical Design 4
10 Distributed Databases
11 Data Warehouses
12 Summary

4. Metadata
 Metadata is data about data.
 It is the way in which the database keeps information about its own
structure.
 Metadata is stored in the data dictionary.

5. Metadata
Name Type Length Description
Student Name Character 50 Student’s
name
Student ID Number 8 Unique identification
number for a student
Date of Birth Date 8 Student’s date of birth
in the format
’01.01.80’

6. Metadata(Data Dictionary)
Datatypes
1. VARCHAR
2. TEXT
3. INTEGER
4. DECIMAL
5. DATE
Column Name Type Length Null Key Constraint

7. Database System in Detail
DATA
Customer
Processing
Application
Rental
Processing
Application
Other
Application Database
DBMS
User
User
User
METADATA
Database
Management
System
Application Requests
Data
Data
Data
Application Requests
Application Requests
DBMS serves as intermediary
between user and the database by translating
user requests into the complex code required
to fulfill those requests.
Application programs might be written in a programming
Language, such as Visual Basic or C++, or it might
be created through a DBMS utility e.g. Access’s forms wizard.

8. Common Types of Database Systems
 Transaction processing systems
 Management Information Systems
 Data Warehouses
 Distributed Databases

9. Transaction processing systems
 A transaction process system (TPS) is an information processing
system for business transactions involving the collection,
modification and retrieval of all transaction data.
 Characteristics of a TPS include performance, reliability and
consistency.
 TPS is also known as real-time processing.

10. Management Information Systems
 A management information system (MIS) is a computerized database
of financial information organized and programmed in such a way
that it produces regular reports on operations for every level of
management in a company.
 It is usually also possible to obtain special reports from the system
easily.

11. Data Warehouses
 A data warehouse is a technique of organizing
data, so that there should be corporate credibility
and integrity.
 Data warehouse contains integrated and
processed data to perform data mining at the time
of planning and decision making, and data
discovered by data mining results in finding
patterns that are useful for future predictions
 Data warehouse supports basic statistical
analysis. The information retrieved from data
mining is helpful in tasks like Market segmentation,
customer profiling, credit risk analysis, fraud
detection etc.

12. Distributed Databases
 A distributed database is a database in which
portions of the database are stored in multiple
physical locations and processing is distributed
among multiple database nodes.
 The DDBMS synchronizes all the data periodically
and ensures that updates and deletes performed
on the data at one location will be automatically
reflected in the data stored elsewhere.

13. Common Uses of Database Systems
 Purchasing from supermarkets
 Using a credit card
 Booking a holiday
 Using a library
 Taking out insurance
 Using the Internet
 What others can you think of?

14. Entity
 An entity can be defined as anything, which can be uniquely identified
and about which data is stored in a database.
 A place, person, picture, concept (e.g. course, position, job) are the
example of an entity.
 Some other examples can be student, workers, car, departments, etc.

15. Attributes
 An attribute is a property of an entity type.
 The data that we want to keep about each entity within an entity type is
contained in attributes.
 Examples of Attributes :
1. Roll number, name and grade are the attributes of Student.
2. Brand, cost and weight are the attributes of Cellphone.
3. Book name, price, author, publisher, etc. are attributes of Book.

16. Types of Attributes
1. Single-valued attribute
2. Multi-valued attribute
3. Null Attribute
4. Simple Attribute
5. Composite Attribute
6. Key Attribute
7. Derived Attribute
8. Attribute Domain

17. Types of Attributes
1. Single-valued attribute :
Attribute that holds a single value for an occurrence of an entity type.
E.g. age, first_name, last_name, full_name, Gender etc.
2. Multi-valued attribute :
Attribute where there might be more than one value for a given
occurrence of an entity type, e.g. for the 'Telephone Number', where a
person or company might have many of these.
3. Null attribute :
Attribute that has NULL.

18. Types of Attributes
4. Simple Attribute
It is composed of a single component. e.g. age, first_name,
last_name, Gender etc. But full_name is not simple attribute.
Because it is composed of first_name and last_name.
5. Composite Attribute
It is composed of more than one component. For example,
'address' might have city, state, country, zip code, etc.

19. Types of Attributes
6. Key Attribute
Primary Key is a key attribute.
Not Null and Unique attribute of an entity
At most one attribute in each entity
7. Derived Attribute
The value of the derived attribute can be derived from the values
of other attributes
Age of a person can be derived from the date of birth and current
date i.e. age = current date – date of birth.

20. Types of Attributes
8. Attribute Domain
A domain is the set of allowable values for an attribute or number
of attributes.
A domain therefore limits the values that an attribute can have.
For example, the domain of 'gender' would include the values
'Male' ,'Female’, ’Other’.
Similarly, the domain of fruit would include the values 'Apple',
'Orange' etc.

21. Relationship
 A relationship is an association of entities showing how the entities
are related with each other.
The examples of relationship are:
 Teaching is the relationship between Lecturer and Student.
 Buying is the relationship between Vendor and Customer.
 Treatment is the relationship between Doctor and Patient.

22. Types of Relationship or Multiplicity
 Number or range of possible occurrences of an entity type in relation
to another entity type (CARDINALITY)
1. One-to-One (1 : 1)
2. One-to-Many (1 : N)
3. Many-to-One (N : 1)
4. Many-to-Many (M : N)

23. Types of Relationship or Multiplicity
1. One-to -One (1 : 1)
Each department can have only one
department head.
Each worker works in one department.
A: Department
B:Department_Head
2. One-to-Many (1 : N)
One course can have many students registered.
A lecturer may be teaching to many students.
A:Course
B:Student

24. Types of Relationship or Multiplicity
3. Many-to-One (N : 1)
Many cities come under one country.
Many books can be written by one writer.
Many authors can write one book.
4. Many-to-Many (M : N)
An Author can write several Books, and a Book
can be written by several Authors
A teacher teaches many class and a
class studies from many teachers.

25. Activity: Draw an ER model
 Draw an ER model for the following scenario:
 A student record system contains data about the
students at a college, the modules they are taking and
the course they are enrolled on. Each course can have
many modules; a student will take many modules. A
student will be enrolled on one course only.

26. ER Solution
STUDENT COURSE
MODULESTUDENT
MODULE
0..*
11
0..*
0..* 1

27. ER Diagram Notation (UML)
 A Book is written by one or more authors. An author writes one or
more Books. A Category may have zero or many books.
 Nouns: Book, Author, Category
 [Note : Many to Many Relationship cannot be shown in relational
model]
1..N
AuthorBook AuthorBook
11..N1
Category
1
0..N

28. A Gardening Company
 The company hires out workers as they need to.
 Workers in the town stay in lodgings. A lodging may have many
workers in it. We are only concerned with the workers’ current
lodging. Workers possess certain skills such as ‘Tree Surgery’ and
‘Garden Design’. They may have more than one skill.
 [Note : Try to identify nouns that could possibly be entities.]

29. A Gardening Company - Nouns
 The company hires out workers as they need to.
 Workers in the town stay in lodgings. A lodging may have many
workers in it. We are only concerned with the workers’ current
lodging. Workers possess certain skills such as ‘Tree Surgery’ and
‘Garden Design’. They may have more than one skill.
 [Note : We are only concerned with one town. So, town is not entity
here. But 'Town' is an attribute of the Lodging.]

30. Possible Solution(UML)
0..*
SkillWorker SkillWorker
10..*1
Lodging
0..*
1

31. Activity: Draw an ER model(Assessment 1)
 A university consists of a number of departments. Each department
offers several courses.
 A number of modules make up each course. Students enroll in a
particular course and take modules towards the completion of that
course.
 Each module is taught by a lecturer from the appropriate department,
and each lecturer tutors a group of students.

32. Key Concepts of Relational Model
 Relations and tables
 Attribute
 Domain
 Tuples and rows
 Primary Key
 Foreign Key

33. Terminology-Relation Model
1. Relation
A relation is a table with columns and rows.
2. Attribute
The columns in a relation are known as attributes.
3. Domain
A domain or attribute domain is the set of allowable values for one
or more attributes.
4. Tuple
A tuple is a row of a relation. They are also called the records.

34. Terminology-Relation Model
5. Degree
The degree of a relation is the number of attributes it has. Example,
the department table has 3 attributes. So, is has degree three.
6. Cardinality
The cardinality of a relation is the number of tuples it contains.
7. Relational Database
A collection of normalized relations with distinct or unique relation
names. It consists of relations that are appropriately structured
having no repeating groups. This is known as Normalization.
So normalized database called relation database.

35. Terminology-Relation Model
Student ID First Name Last Name Course Code
S334 Dave Watson COMP
S765 Jagpal Jutley COMP
S783 Cynthia Kodogo HIST
S111 Walace Antigone LIT
4Tuples
4 Degree
Cardinality
4 Attributes

36. Alternative Terminology
Formal Term Alternative 1 Alternative 2
Relation Table File
Tuple Row Record
Attribute Column Field

37. Relational Keys
1. Super Key (All Possible Combination of Keys)
 An attribute, or set of attributes, that uniquely identifies a tuple within a relation.
 For example, for the entity Student = {SID, Name, Address, Age, Mobile No}, the
possible super keys are <SID>, < Mobile No, Name>, <SID, Name>.
2. Candidate Key (All highly likely keys)
 It is such an attribute of a table that can uniquely identify a row in a table.
 Generally they contain unique values and can never contain NULL values. There
can be more than one candidate key in a table
 e.g. within a STUDENT table Roll and Mobile No. can both serve to uniquely
identify a student.

38. Relational Keys
3. Primary Key (Chosen one Key)
 It is one of the candidate keys that are chosen to be the identifying key for the
entire table.
 E.g. although there are two candidate keys in the STUDENT table, the college
would obviously use Roll as the primary key of the table.
4. Alternate Key:
 This is the candidate key which is not chosen as the primary key of the table.
They are named so because although not the primary key, they can still
identify a row.

39. Relational Keys
5. Composite Key:
 Sometimes one key is not enough to uniquely identify a row. E.g. in a single
class Roll is enough to find a student, but in the entire school, merely
searching by the Roll is not enough, because there could be 10 classes in the
school and each one of them may contain a certain roll no 5.
 To uniquely identify the student we have to say something like “class VII, roll
no 5”. So, a combination of two or more attributes is combined to create a
unique combination of values, such as Class + Roll.

40. Relational Keys
6. Foreign Key:
 Sometimes we may have to work with an attribute that does not have a
primary key of its own.
 To identify its rows, we have to use the primary attribute of a related table.
Such a copy of another related table’s primary key is called foreign key.

41. Database Design and Development
 Development involves the whole life cycle of the project to elicit the
user requirements and produce the database, applications and the
supporting hardware and software.
 Design focuses on producing the actual database once the
requirements have been gathered

42. Requirements Gathering
 Part of Systems Analysis
 Understanding what it is that the users want…
 A whole topic in itself!

43. Database Design
 “The process of creating a design that will support the enterprise’s
mission statement and mission objectives for the required database
system.”
Connolly and Begg

44. Phases of Database Design
 Conceptual database design
 Logical database design
 Physical database design

45. © NCC Education LimitedV1.0
Introduction to the Module Topic 1 - 1.45
Database Design and our Topics
1 Introduction to the Module
Key concepts in databases and database development
2 Enhancing Design 1 CONCEPTUAL AND LOGICAL
3 Enhancing Design 2 CONCEPUTAL AND LOGICAL
4 Data Retrieval 1
5 Data Retrieval 2
6 Physical Design 1 PHYSICAL
7 Physical Design 2 PHYSICAL
8 Physical Design 3 PHYSICAL
9 Physical Design 4 PHYSICAL
10 Distributed Databases
11 Data Warehouses
12 Summary

46. Conceptual Database Design
 “The process of constructing a model of the data used in an enterprise,
independent of all physical considerations.”
Connolly and Begg

47. Conceptual Database Design
 Investigation of data needed to support system
 Does not take account of physical implementation or data model
What data is held?
In what format is the data?
How is this the data
used?

48. Activity - Why do Conceptual Design?
 What is the purpose of doing design that doesn’t take account of the eventual
implementation, ignores the data model, ignores the software that will be used?

49. Logical Database Design
 “The process of constructing a model of the data used in an enterprise
based on a specific data model, but independent of a particular DBMS
and other physical considerations.”
Connolly and Begg

50. Logical Design
 Data is investigated and design is undertaken without regard to the
DBMS product that will be used, but that data model (usually the
relational model) is known.
Normalisation Entity relationship diagram
Design transactions

51. Difference between Conceptual and Logical
Design
 Conceptual design is independent of data model and target DBMS
 Logical model takes account of data model (but not DBMS)
 Thus in logical design we know we are dealing with, for example, a
relational model

52. Logical Model Uses…
 Normalisation
 Ensures that relations derived from the data model do not display data
redundancy, which can cause update anomalies.

53. Physical Database Design
 “The process of producing a description of the implementation of the database
on secondary storage; it describes the base relations, file organisations, and
indexes used to achieve efficient access to the data, and any associated
integrity constraints and security measures.”
Connolly and Begg

54. Physical Design
 From entities to tables
 Designing the base relations
Indexing Denormalisation
Query tuning
View creation

55. Additional Aspects of Development
 DBMS selection
 Application design
 Transaction design
 User interface issues
 Implementation
 Data conversion
 Testing

56. ANY QUESTIONS?