Richard Merritt1 Data Modelling Entities, Attributes and Relationships

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

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

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

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

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

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

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

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

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

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

Richard Merritt12 Physical Organisation physical medium file recor d field

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

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 2Quantity Number 2156 WilliamsCCD3 2TR

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?

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

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

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

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

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

Richard Merritt21 Possible Entities for Consultant System

Richard Merritt22 Initial Attempt at Relationships

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.

Richard Merritt24 One to one relationships resolved

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?

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.

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

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

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

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.

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

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 2Quantity Number 2156 WilliamsCCD3 2TR

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)

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

Richard Merritt35 A Compound Key Consultant No.Project No.Time (days) C232 C979 A176 C

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

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

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.

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

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)

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

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.

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

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

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

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

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

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

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

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 *

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)

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

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?

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

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 *

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

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

Richard Merritt58 3NF Relations are Entities

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

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

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.

Richard Merritt62 Compare to LDS

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

Richard Merritt64 What is the key? Activity No Project No C232 C979 A176 Time (days) Activity Type write letter draw DFD interview plan project visit site Activity No. is only unique within one project. Consultant No

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

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

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 Part No

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

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)

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 Part No Value Item Order Total Date Required assembly 3.20 Quantity /2/99 26/3/99

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 ( ) *

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 * ( )

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 * * ( )

Richard Merritt74 3NF Relations are Entities

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 ( )

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

Richard Merritt77 LDS from Tutorial Example

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