1. Richard Merritt1 Data Modelling Entities, Attributes and Relationships

2. Richard Merritt2 Data Modelling u Technique for describing information structures u Information models represent: u things - entities u properties of things - attributes u associations between things - relationships

3. Richard Merritt3 Entities u Abstractions of real world things e.g. CUSTOMER does not relate to specific customers...any distinguishable person, place, thing, event or concept about which information is kept. (Bruce 1992) Specific customer A

4. Richard Merritt4 Attributes u The elements of data belonging to an entity are known as its attributes Customer A/C No. Name Address Tel No. Credit limit

5. Richard Merritt5 Relationships u Imagine two entities: Lecturer and Student u Lecturers teach students u Teaching is the “relationship” between the two abstract entities

6. Richard Merritt6 Logical Data Model An Entity Type has a set of attributes e.g. Customer has attributes of Account Number Name Address Telephone Number Credit Limit

7. Richard Merritt7 Logical Data Model An Entity Type may have a number of occurrences. Each Entity Occurrence has a unique set of values for the attributes. CB Customer Entity Type A/C No. Name Address Tel No. Credit limit A Customer Entity Occurrences

8. Richard Merritt8 Logical Data Model Customer Entity AttributeValue Account NumberBL032 Name Bloggs & Son Address117 Acacia Rd Birmingham 7 Telephone Number0121 345678 Credit Limit£2500

9. Richard Merritt9 A Table or Relation Reg. No.SurnameForename 45632 45315 44355 45422 JonesDavid JamesSarah Jones Mary HillSimon Each row of the table is unique.

10. Richard Merritt10 Entities, Tables & Relations u An Entity Type is represented as a Table ( Relation ) u Each Row ( Tuple ) of the Table is an Occurrence of the Entity u Each Column ( Domain ) of the Table contains the Values of one Attribute of the Entity

11. Richard Merritt11 Physical Data Organisation u An Entity Type is usually implemented as a File in the Physical Storage Medium u Each Entity Occurrence is a Record in the File u The Value of an Attribute of the Entity Occurrence is stored in a Field within the Record

12. Richard Merritt12 Physical Organisation physical medium file recor d field

13. Richard Merritt13 one record order no. customer item qty. item qty. item qty. item qty. order no. customer repeating fields Repeating Attributes / Fields Are repeating attributes (fields) really attributes of this entity? Order File / Entity

14. Richard Merritt14 Attributes / Fields of an Order only one item but … One Entity Occurrence / Record OrderCustomerItemQuantity Number 1234 AceXY345 8 Another Occurrence / Record OrderCustomerItem 1Quantity 1Item 2Quantity2........... Number 2156 WilliamsCCD3 2TR805 5...........

15. Richard Merritt15 Entities or Attributes? When is data an Attribute of an Entity and when is it a separate Entity? Can one Entity ever be considered to be simply Attributes of another?

16. Richard Merritt16 Diagrammatic Representation custome r Symbols for entities hard box soft box studen t

17. Richard Merritt17 Diagrammatic Representation orde r Relationship between entities item crow’s foot one order can be for many items master detail

18. Richard Merritt18 Degrees of Relationship orde r deliver y one to one orde r deliver y one to man y orde r deliver y man y to man y

19. Richard Merritt19 Optional Relationships An Order must be for a Customer Customer Sales Order but a Customer may not have any orders optional at the customer end

20. Richard Merritt20 Consultant System u A Client has an Account u Consultants have a Grade and a number of Skills u Consultants are active on various Projects u Each Project is for one Account

21. Richard Merritt21 Possible Entities for Consultant System

22. Richard Merritt22 Initial Attempt at Relationships

23. Richard Merritt23 Resolving One to One Relationships ClientAccount The account is an attribute of the client and NOT a separate entity. Simply merge the entities which have a one to one relationship. A Client can only have one Account.

24. Richard Merritt24 One to one relationships resolved

25. Richard Merritt25 Resolving Many to Many Relationships What is the nature of the relationship between an Actor and a Scene? Difficult to implement so how can they be replaced?

26. Richard Merritt26 Resolving Many to Many Relationships Actor and Scene are both masters to the new linking entity of Appearance. Create a linking entity which is a detail to both the original entities.

27. Richard Merritt27 Resolving Many to Many Relationships What would make suitable entities and what attributes might they have? PatientDrug ? ConsultantSkill ?

28. Richard Merritt28 Many to many relationships resolved Avoid crossed relationships Resuscitate dead crows!

29. Richard Merritt29 Developing a Logical Data Structure u identify possible entities u draw initial entity relationship diagram u resolve 1:1 and many:many relationships & check for further entities and relationships u remove redundant relationships u show optionality

30. Richard Merritt30 Cross-checking the LDS The LDS is derived using a “Top Down” approach. It can be cross-checked by using a “Bottom Up” approach, building up the entities from their attributes. This technique is called Normalisation which is the subject of the next lecture.

31. Richard Merritt31 Relational Data Analysis Normalisation With thanks to Codd & Date.

32. Richard Merritt32 Attributes / Fields of an Order only one item but … One Entity Occurrence / Record OrderCustomerItemQuantity Number 1234 AceXY345 8 Another Occurrence / Record OrderCustomerItem 1Quantity 1Item 2Quantity2........... Number 2156 WilliamsCCD3 2TR805 5...........

33. Richard Merritt33 Normalisation objectives u to reduce data redundancy u to hold each data item (attribute) with as few occurrences as possible u to identify and remove any dependencies between data items stored together (in the same table)

34. Richard Merritt34 A Relation A two-dimensional table row (tuple) Reg. No.SurnameForename 45632 45315 44355 45422 JonesDavid JamesSarah Jones Mary HillSimon column (attribute) unique primary key

35. Richard Merritt35 A Compound Key Consultant No.Project No.Time (days) 001 003 C232 C979 A176 C232 3.0 10.5 5.0 20.0

36. Richard Merritt36 Attributes Listed Consultant No. Project No. Time (days) Reg. No. Surname Forename key attribute underlined compound key

37. Richard Merritt37 Un-Normalised Data Consultant Details No.NameAddressGrade Salary Scale 004Mary Wheeler236 Fore Street D S2 Ivybridge Devon Skills CodeDescriptionQualification SK01AccountingIMA SK10CAD / CAM3 yrs. AutoCAD SK15SSADMV4 Certificate

38. Richard Merritt38 Assumptions u Consultant No., Skill Code and Grade are unique. u A consultant can have many skills each identified by a Skill Code. u For each skill only the consultant’s highest Qualification is recorded. u Other consultants may have the same skills (and Skill Code ) but not necessarily the same Qualification. u Each Skill Code has one Description. u Each Grade belongs to one Salary Scale.

39. Richard Merritt39 Un-Normalised Form (UNF) Consultant No. Name Address Grade Salary Scale Skill Code Description Qualification key should uniquely identify a row in the table

40. Richard Merritt40 UNF UNF u list all data attributes u allocate primary key u identify repeating group(s) (optional) UNF Consultant No. Name Address Grade Salary Scale (Skill Code Description Qualification)

41. Richard Merritt41 First Normal Form (1 NF) Rule remove repeating data Consultant No. Name Address Grade Salary Scale Skill Code Description Qualification

42. Richard Merritt42 First Normal Form (1 NF) Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Description Qualification The compound key of the new table which contains the repeating group consists of the original key plus the attribute(s) which uniquely identify a single set of repeating values given a single value of the original key.

43. Richard Merritt43 1NF 1NF u separate repeating group u copy non-repeating group unchanged u add initial primary key to repeating group & identify compound key UNF Consultant No. Name Address Grade Salary Scale (Skill Code Description Qualification) 1NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Description Qualification

44. Richard Merritt44 Second Normal Form (2 NF) Rule remove part-key dependencies Consultant No. Skill Code Description Qualification

45. Richard Merritt45 Second Normal Form (2 NF) Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description

46. Richard Merritt46 2NF 2NF u separate part-key dependencies u all other groups are copied across unchanged u do not omit key only groups 1NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Description Qualification 2NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description

47. Richard Merritt47 Third Normal Form (3 NF) Rule remove inter-data ( and inter-key ) dependencies Consultant No. Name Address Grade Salary Scale

48. Richard Merritt48 Inter-Data Dependency Salary ScaleGrade S1 S2 S3 ABCDEFGABCDEFG

49. Richard Merritt49 Third Normal Form (3 NF) Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description * * denotes a Foreign Key

50. Richard Merritt50 3NF 3NF u separate inter-data ( non-key ) dependencies u identify foreign keys 2NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description 3NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description *

51. Richard Merritt51 Normalisation of Consultant Data 1NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Description Qualification 2NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description 3NF Consultant No. Name Address Grade Salary Scale Consultant No. Skill Code Qualification Skill Code Description * UNF Consultant No. Name Address Grade Salary Scale (Skill Code Description Qualification)

52. Richard Merritt52 Normalisation Stages u UNF - list attributes & allocate primary key u 1NF - remove repeating groups u 2NF - remove part key dependencies u 3NF - remove inter-data dependencies

53. Richard Merritt53 Third Normal Form Tests u Given a value for the key of a 3NF relation, is there only one possible occurrence of the associated data (row)? u Is each attribute (column) of the relation dependent on the key, the whole key and nothing but the key?

54. Richard Merritt54 Consultant No. Name Address Grade Salary Scale * CONSULTANT GRADE Consultant No. Skill Code Qualification Skill Code Description CONSULTANT SKILL SKILL Relation (Table) Names

55. Richard Merritt55 Summary of the Normalisation UNF1NF2NF3NF CONSULTANT Consultant No. Name Address Grade Salary Scale CONSULTANT SKILL Consultant No. Skill Code Description Qualification CONSULTANT Consultant No. Name Address Grade Salary Scale Skill Code Description Qualification CONSULTANT Consultant No. Name Address Grade Salary Scale CONSULTANT SKILL Consultant No. Skill Code Qualification SKILL Skill Code Description CONSULTANT Consultant No. Name Address Grade GRADE Grade Salary Scale CONSULTANT SKILL Consultant No. Skill Code Qualification SKILL Skill Code Description *

56. Richard Merritt56 3NF Entity-Relationship Diagram u 3NF Relations are Entities u Entities / Relations are linked by their common attributes è Relational Model

57. Richard Merritt57 Relationships from 3NF u Entities are linked by their keys Keys and Foreign Keys are the common attributes. u An Entity / Relation with a Compound Key is a Detail Its Masters are Relations that have as their Key a part of the Compound Key u An Entity / Relation with a Foreign Key is a Detail Its Master is the Relation which has the Foreign Key as its whole Key

58. Richard Merritt58 3NF Relations are Entities

59. Richard Merritt59 Compound Keys are Details master Skill Code master Consultant No. detail with compound key Consultant No. Skill Code

60. Richard Merritt60 Foreign Keys are Details master Grade detail with foreign key * Grade

61. Richard Merritt61 Cross-checking the LDS The LDS is derived using a “Top Down” approach. Normalisation is used to cross-check the LDS by using a “Bottom Up” approach, building up the entities and relationships from their attributes.

62. Richard Merritt62 Compare to LDS

63. Richard Merritt63 Why are the diagrams not the same? What do they have in common? What are the differences? Why? What do we need to resolve the differences? Normalise other documents / data sources. LDS versus 3NF Entity Relationship Diagram

64. Richard Merritt64 What is the key? Activity No 1212112121 Project No C232 C979 A176 Time (days) 0.1 1.5 0.3 2.0 1.0 Activity Type write letter draw DFD interview plan project visit site Activity No. is only unique within one project. Consultant No 003 001 004 002

65. Richard Merritt65 A Composite Key Project No. Activity No. Consultant No. Activity Type Time (days) composite key a key of more than one attribute where part of the key does not have a unique meaning

66. Richard Merritt66 Data Modelling u Derive an LDS - “top down” u Normalise all relevant data (documents etc.) apply 3NF tests u Merge relations with the same key check for synonyms and homonyms apply 3NF tests again u Give each Relation (Entity) a name names should be consistent with LDS u Draw a 3NF Entity Relationship Diagram u Compare LDS & 3NF ERD and resolve differences

67. Richard Merritt67 Another Normalisation A sample purchase order document. Assumptions Identify data items and work out rules and assumptions. It is critical to document the rules or assumptions of the data prior to normalisation. Assumptions may change over the life of the system. Supplier No., Purchase Order No. and Part No. are unique. Cost Each depends only on Part No. Supplier No. 54 Name Wizcorp Ltd. Purchase Order No. 46 Order Date 15/2/99 Description Cost each Quantity stainless bolt 10mm x 4cm stainless nut 10mm 3m x 8cm stainless round 0.50 0.20 82.50 100 5 Part No. 34576 34579 34121

68. Richard Merritt68 Normalisation of Purchase Order 1NF Purchase Order No. Date Supplier No. Name Purchase Order No. Part No. Description Cost each Quantity 2NF Purchase Order No. Date Supplier No. Name Purchase Order No. Part No. Quantity Part No. Description Cost each UNF Purchase Order No. Date Supplier No. Name (Part No. Description Cost each Quantity) 3NF * Purchase Order No. Date Supplier No. Name Purchase Order No. Part No. Quantity Part No. Description Cost each

69. Richard Merritt69 Purchase Order Document 3NF * Purchase Order No. Date Supplier No. Name Purchase Order No. Part No. Quantity Part No. Description Cost each Purchase Order Supplier Purchase Order Item Part u apply 3NF tests u name entities (relations)

70. Richard Merritt70 Assumptions Customer No, Order No and Part No are unique but Item is only unique within one order. Price each depends on Part No.. The same Part No can be used for more then one Item on the same order (but the Date Required will vary). Sales Order Customer No 54 Name J. Thomas Order No 76 Date 5/2/99 Description widget assembly rod Price each 1.50 3.20 1.20 Part No 41235 23467 89965 Value 6.00 12.80 7.20 Item 1 2 3 Order Total 58.00 Date Required 4 23467 assembly 3.20 Quantity 4 4 6 10 32.00 19/2/99 26/3/99

71. Richard Merritt71 Normalisation of Sales Order UNF Sales Order No. Date Customer No. Name Order Total (Item Part No. Description Price each Quantity Value Date Required) 1NF Sales Order No. Date Customer No. Name Order Total Sales Order No. Item Part No. Description Price each Quantity Value Date Required ( ) 2NF Sales Order No. Date Customer No. Name Order Total Sales Order No. Item Part No. Description Price each Quantity Value Date Required )( 3NF * Sales Order No. Date Customer No. Order Total Customer No. Name Sales Order No. Item Part No. Quantity Value Date Required Part No. Description Price each ( ) *

72. Richard Merritt72 Sales Order Document 3NF Customer No. Name Part No. Description Price each Customer Part Sales Order Sales Order Item * Sales Order No. Date Customer No. Order Total Sales Order No. Item Part No. Quantity Value Date Required * ( )

73. Richard Merritt73 Merged 3NFs PURCHASE ORDER Purchase Order No. Purchase Order Date Supplier No. SUPPLIER Supplier No. Supplier Name PURCHASE ORDER ITEM Purchase Order No. Part No. Quantity PART Part No. Description Cost each Price each * SALES ORDER Sales Order No. Sales Order Date Customer No. Order Total CUSTOMER Customer No. Customer Name SALES ORDER ITEM Sales Order No. Item Part No. Quantity Value Date Required * * ( )

74. Richard Merritt74 3NF Relations are Entities

75. Richard Merritt75 Compound Keys are Details master Purchase Order No. master Part No. detail with compound key Purchase Order No. Part No. composite key Sales Order No. Item not compound ( )

76. Richard Merritt76 Foreign Keys are Details Sales Order No. is foreign key

77. Richard Merritt77 LDS from Tutorial Example

78. Richard Merritt78 LDS versus 3NF Entity Relationship Diagram What are the differences? What do we need to resolve these? Normalise a despatch document.