The document discusses key concepts of database design, focusing on logical and conceptual design principles, including entity integrity, referential integrity, and functional dependencies. It explains the importance of normalization to eliminate anomalies (insert, update, delete) and provides examples to illustrate how to move from un-normalized forms to first, second, and third normal forms. It also outlines the steps for mapping entity-relationship models to tables and emphasizes the necessity of user involvement in the design process.

1. Er. Nawaraj Bhandari
Database Design &
Development
Topic 2 & 3:
Enhancing Design
Logical Design & Conceptual
Design

2. Some Key Concepts
• Entity integrity
• Referential integrity(Relational Integrity)
• General constraints
• Nulls

3. Question
• Why cannot any part of a primary key be null?
?

4. Answer
• Because a null value, being unknown, might be the same as the value in the
primary key of another tuple.

5. Properties of a Relation
• Relation Named
• Atomic values in cells
• Attribute Named
• Attribute value drawn from a domain
• No duplicate tuples (rows)
• No significance to order of tuples
• No significance to order of attributes

6. Class Record (Is This a Relation? )
Class Code Instrument Taught Teachers No of Instruments
Rented
2 Saxophone Marcus Smith 10
6 Trumpet Ajay Singh
Sonny Muller
20
7 Guitar Farhad Khan 10
9 Guitar Farhad Khan
Tommy Jones
23
1 Drums Tommy Jones 5

7. Activity - Is This a Relation?
• It has a name which is unique within the relational schema - Yes
• Each cell of a relation contains exactly one value - No
• Each attribute has a name – YES
• Each tuple is unique - YES
• The order of attributes is insignificant – YES
• The order of tuples is insignificant - YES

8. Class Record – A Relation
Class Code Instrument Taught Teachers No of Instruments
Rented
2 Saxophone Marcus Smith 10
6 Trumpet Ajay Singh 20
6 Trumpet Sonny Muller 20
7 Guitar Farhad Khan 10
9 Guitar Farhad Khan 23
9 Guitar Tommy Jones 23
1 Drums Tommy Jones 5

9. Activity - Is This a Relation?
Student Name Modules Course
Guy Smith Med1 Medieval History 1
Med2 Medieval History 2
TCE Twentieth Century
History
Sarah Anusiem
12 New Street, Lagos
OS Operating Systems
NET Networks
Computing

10. Activity - Is This a Relation?
• It has a name which is unique within the relational schema - No
• Each cell of a relation contains exactly one value - No
• Each attribute has a name – YES
• Each tuple is unique - YES
• The order of attributes is insignificant – YES
• The order of tuples is insignificant - YES

11. Now a Relation
Student Name Address Modules Course
Guy Smith Med1 Medieval History 1 History
Guy Smith Med2 Medieval History 2 History
Guy Smith TCE Twentieth Century History
Sarah Anusiem 12 New Street,
Lagos
OS Operating Systems Computing
Sarah Anusiem 12 New Street,
Lagos
NET Networks Computing

12. Functional Dependency
Student ID First Name Surname
9901 John Dacus
9902 Satpal Singh
9922 Jagpal Singh
9911 John Smith
Students
• For any Student ID, there is one first name and one surname, So, First Name
and Surname are functionally dependent on Student ID. We can also say
Student ID functionally determines First Name and Surname.
• Student ID -> First Name, but not the reverse
• Student ID -> Surname

13. Partial Dependency
• When an non-key attribute is determined by a part, but not the whole,
of a composite primary key. This kind of functional dependency is
known as partial dependency.
• There are two non-key fields : marks and subject_name.
• If you know just student_id, can you determine marks?
• If you know just subject_id, can you determine marks?
• So, marks is partially dependent on student_id and subject_id.
student_id subject_id marks subject_name
1 1 80 Database
2 1 70 Database
1 2 90 Java

14. Transitive Dependency

15. 3NF

16. Anomalies
1. Insert Anomalies
2. Update Anomalies
3. Delete Anomalies

17. Activity: Delete Anomalies
Student ID Student Name Activity Fee
9901 Binay Basketball 200
9902 Shyam Football 300
9922 Sitaram Cricket 500
9811 Prashant Football 300
• What information do we lose if Binay quits Basketball?
• We would lose the price of ‘Basketball’.
• This is the deletion anomaly that occur when relations are not fully
normalized.
• When you delete some information and lose valuable related information
at the same time.

18. Insert Anomalies
• If we want to record a new activity, but no one has yet taken it. Can
we insert this information?
• We cannot do so; we need a student ID because the student ID is part
of the primary key and therefore cannot be null.
• This is an insert anomaly.

19. Update Anomalies
• If we wanted to change the cost of football to ‘500’, we would have to
do it for every tuple where someone was playing football .
• Any change made to your data will require you to scan all records to
make the change. This is called the update anomaly.

20. Customer Order Sheet for an Art Supplier
Customer Number: 37
Customer Name: Jagpal Singh
Customer Type Code: RC
Customer Type Description: Retail Customer
Item Number Item Name Supplier ID Price Supplier Name Quantity
099 Basic Paint Set S1 £3 Smith and Co 1
0100 Sable Brush Set S2 £3.50 Acro 1
0101 Extended Colour
Set
S1 £3.75 Smith and Co 3
098 Metallic Paint Set S1 £3.99 Smith and Co 1
078 Mixed Brush Set S2 £3.99 Acro 2
Customer Order Sheet for Art Supply
Shop

21. UNF Lev
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Item Number
Item Name
Supplier ID
Price
Supplier Name
Quantity
1
1
1
1
2
2
2
2
2
• Un-normalised Form. Identify repeating groups
First Step

22. UNF Lev 1NF
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Item Number
Item Name
Supplier ID
Price
Supplier Name
Quantity
1
1
1
1
2
2
2
2
2
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Customer Number*
Item Number
Item Name
Supplier ID
Price
Supplier Name
Quantity
First Normal Form (1NF)
(Separate Repeating and Non-repeating group)

23. 1NF 2NF
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Customer Number*
Item Number
Item Name
Supplier ID
Price
Supplier Name
Quantity
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Customer Number*
Item Number*
Quantity
Item Number
Item Name
Supplier ID
Price
Supplier ID
Supplier Name
Second Normal Form (2NF)
(Remove Partial Dependency)

24. 2NF 3NF
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Customer Number*
Item Number*
Quantity
Item Number
Item Name
Supplier ID
Price
Supplier ID
Supplier Name
Customer Number
Customer Name
Customer Type
Code
Customer Type
Name
Customer Number*
Item Number*
Quantity
Item Number
Item Name
Supplier ID*
Price
Supplier ID
Supplier Name
Third Normal Form (3NF)
(Remove Non-Key Dependency)

25. 2NF 3NF
Customer Number
Customer Name
Customer Type Code
Customer Type Name
Customer Number*
Item Number*
Quantity
Item Number
Item Name
Supplier ID
Price
Supplier ID
Supplier Name
Customer Number
Customer Name
Customer Type
Code
Customer Type
Name
Customer Number*
Item Number*
Quantity
Item Number
Item Name
Supplier ID*
Price
Supplier ID
Supplier Name
Customer
CustomerItem
Item
Supplier
Third Normal Form (3NF) to Deriving Entities

26. Customer CustomerItem Item
Supplier
1 1
1
0...*
0...* 0...*
The Entity Relationship Diagram

27. Normalisation and Semantics - 1
• Normalisation depends on understanding the meaning of the
data.
• For example the price of an item depends on just the item. If the
same item could be supplied by different suppliers at different
prices then the normalisation would look different. How?

28. Normalisation and Semantics - 2
• Answer: there would be a separate group of attributes with the primary key
of Supplier Number and Item Number. Price would be functionally dependent
on both of these attributes and would therefore be an attribute of this entity.

29. Extended Example
• To be used throughout the course
• Lots of different documents might be examined e.g.
• Customer records
• Sales sheets
• Receipts and invoices

30. Marlowe Interiors - 2
Marlowe Interiors
1 Newington Green Road
London
N1 TYY
020 7888 1234
Job: Kitchen Makeover
Customer: Ivan Jones, 2 Digby Mansions. Highbury Park
Area: London North
Date: 02/03/00
Parts
1 sink, tin @ 130.00 including VAT.
1 u-pipe @ 20.00 ditto
3 x assorted plumbing fittings @ 33.00 total including VAT
1 thermostat @ 100.00 including VAT
Labour
Plumber 3 hours £150
Labourer 3 hours £60
Electrician 1 hour £50 (to fit thermostat)
TOTAL PARTS £283.00 TOTAL
LABOUR £260.00
TOTAL £543.00

31. Job Customer Area Date Part Labour
Kitchen
Makeover
Ivan Jones, 2
Digby
Mansions.
Highbury Park
North London 02/03/00 1 sink, tin @
130.00
Plumber 3
hours £150
Kitchen
Makeover
Ivan Jones, 2
Digby
Mansions.
Highbury Park
North London 02/03/00 1 u-pipe @
20.00
Labourer 3
hours £60
Kitchen
Makeover
Ivan Jones, 2
Digby
Mansions.
Highbury Park
North London 02/03/00 3 x assorted
plumbing
fittings
Kitchen
Makeover
Ivan Jones, 2
Digby
Mansions.
Highbury Park
North London 02/03/00 1 thermostat
@ 100.00
Electrician 1
hour £50 (to
fit
thermostat)

32. Logical Design
• Step One: Create and check ER model
• Step Two: Map ER Model to tables

33. Iterative
• Discussed as a series of steps but...
• Iterative
• Step-wise refinement
• Revisiting steps
• User involvement

34. Logical Design Step One - 1
• Step One: Create and check ER mode
• 1.1 Identify entities
• 1.2 Identify relationships
• 1.3 Identify and associate attributes with entities
• 1.4 Determine attribute domains
• 1.5 Determine candidate, primary and alternative key attributes

35. Logical Design Step One - 2
• Step One: Create and check ER mode
• 1.6 Specialise/Generalise entities (optional step, not covered here)
• 1.7 Check model for redundancy
• 1.8 Check model supports user transactions
• 1.9 Review model with user

36. Identifying Entities
• Examine user requirements
• Look for nouns
• Look for objects that exist in their own right e.g. Customers,
staff,
• Be aware of synonyms and homonyms

37. Art Suppliers Example Revisited - 1
• From an interview with the manager:
• “We get our goods from various suppliers. Generally we have
one supplier for each item. Customers order from us. They
usually order in bulk and we fill in an order form. We usually
group orders in the same are into a delivery. We have three
delivery vans.”

38. Art Suppliers Example Revisited - 2
• From an interview with the manager:
• “We get our goods from various suppliers. Generally we have
one supplier for each item. Customers order from us. They
usually order in bulk and we fill in an order form. We usually
group orders in the same are into a delivery. We have three
delivery vans.”

39. Art Suppliers – Some Possible Entities
• Manager
• Goods
• Suppliers
• Item
• Customers
• Order
• Order form
• Delivery
• Vans

40. Examining Entities more Closely
• Manager – one of a number of types of Staff
• Suppliers – yes probably an entity
• Item aka Goods
• Customers - yes
• Order – yes so we don’t need a separate entity for order form
• Delivery - yes
• Vans – yes in order to allocate to a delivery

41. Step 1.2 Identify Relationships
• Look for verbs e.g. Items are supplied by Suppliers
• Draw up a table with relationships between entities.

42. Cross Reference Entities for Relationships
Entity Relationship Entity
Items Have Suppliers
Orders Contain Items

43. Add Multiplicity
Entity Multiplicit
y
Relationship Multiplicit
y
Entity
Items 1 Have 0...* Suppliers
Orders 1...* Contain 0...* Items

44. Step 1.3 Identify Attributes
• Ask the question ‘what information are we to hold about that
particular entity?’
• Are they simple or composite attributes.
• Activity: What attributes do we need for a ‘Customer’?

45. Step 1.4 Determine Attribute Domains
• What are the possible values of an attribute?
Attribute Description Data type Domain
CustomerID Unique ID for
customer
Char First character will be
letter ‘C’ followed by a
sequential number
CustomerSurname Customer’s surname Char
CustomerType Specifies if customer
is private or a
company
Char Will be letter ‘P’ for
Private or ‘C’ for
company
CustomerSex Customer’s sex Char Will be ‘M’ or ‘F’

46. Step 1.5 Determine Candidate, Primary and
Alternate Keys
• Candidate key is an attribute or group of attributes capable of
uniquely identifying a row.
CustomerID OrderItemNo Date Time
1 1 13/01/11 9.55
1 2 13/01/11 9.56
3 1 13/01/11 10.01
Possible candidate keys?

47. • Candidate key is an attribute or group of attributes capable of
uniquely identifying a row.
CustomerID OrderItemNo Date Time
1 1 13/01/11 9.55
1 2 13/01/11 9.56
3 1 13/01/11 10.01
Possible candidate keys?
1. CustomerID, OrderItemNo, Date, Time
2. CustomerID, OrderItemNo, Date
3. CustoemrID, OrderItemNo, Time

48. Chose the Primary Key by Choosing
• The candidate key with the minimal set of attributes
• The candidate key that is less likely to have its values changed
• The candidate key that is less likely to lose uniqueness over time
• The candidate key with fewest characters or numbers
• The candidate key that is easiest to use for users

49. • Candidate key is an attribute or group of attributes capable of
uniquely identifying a row.
CustomerID OrderItemNo Date Time
1 1 13/01/11 9.55
1 2 13/01/11 9.56
3 1 13/01/11 10.01
Possible candidate keys?
1. CustomerID, OrderItemNo, Date, Time
2. CustomerID, OrderItemNo, Date
3. CustomerID, OrderItemNo, Time
Candidate 2 is best
choice

50. Step 1.7 Check Model for Redundancy
• Re-examine one-to-one relationships
• Remove redundant relationships
• Consider time dimension when assessing redundancy

51. Remove Redundant Relationships
Video
Rental Customer
is part of
takes out
rents
Take out this
relationship

52. Step 1.8 Check Model Supports User
Transactions
• Describe and document transactions
• Example
1. Create, update and delete a customers details
2. Create and update an order
3. Retrieve details for customers and the orders they make

53. Documenting Transactions
Transaction/Table Customer Order
1 C U D
2 C U
3 R R

54. Step 1.9 Review Model with User

55. Step 2.1 Create Tables
• Move from entities to tables.
• Most entities will have a one-to-one mapping of entity to table.
• Document in a data dictionary

56. Entities to Tables - 1
• Decompose any ‘many to many’ relationships
Order Item
An order is for many items and
an item might be on many
orders
Order ItemOrderItem

57. Entities to Tables - 2
• Some domains will become separate tables
• If a ‘type’ attributes has many values and these are dynamic then a look-up
table to support the domain should be added.
• Product_Type, Student_Type

58. Step 2.2 Check Table Structure using
Normalisation
• Use the normalisation techniques discussed in the previous
lecture to check the tables
• Do the tables you have from the top-down method match those
from the bottom-up (normalisation) method?

59. Step 2.3 Check Tables Support user
Transactions
• As the CRUD matrix checked that the ER supported the transactions a similar
check should now be made for the tables.

60. Step 2.4 Check Business Rules
• This begins the process of check integrity rules and other constraints.
• Check required data
• Column domain constraints
• Entity integrity
• Multiplicity
• Referential intgrity

61. Step 2.5 Review Logical Design with Users
•This is vital!

62. References
• Connolly, T. and Begg, C. (2004). Database Systems: A Practical Approach to
Design, Implementation, and Management, 4th Edition. Addison Wesley –
Chapters 9 and 10