Presentation is loading. Please wait.

Presentation is loading. Please wait.

Relational Database Systems Higher Information Systems.

Similar presentations


Presentation on theme: "Relational Database Systems Higher Information Systems."— Presentation transcript:

1 Relational Database Systems Higher Information Systems

2 The Relational Model data is grouped into entities which are related, in order to minimise data duplication and achieve data integrity many-to-many relationships between entities are removed and replaced with one-to-many relationships

3 Entity-Occurrence Modelling

4 Lines indicate how the instances of each entity are linked E.g. Member 1034 has rented DVDs 002 and 015 DVD 003 has been rented by members 1012 1056

5 Entity-Occurrence Modelling Each DVD can be rented by many Members Each Member can rent many DVDs So there is a many-to-many relationship between Member and DVD

6 Entity-Occurrence Modelling This method is only as good as the available data Make up “dummy” data if necessary to fill in the gaps

7 More about keys An atomic key consists of one attribute MEMBER(Member Number, Name, Telephone Number) A compound key consists of two or more attributes MEMBER(Member Number, Name, Telephone Number) A surrogate key is a made up attribute designed to uniquely identify a record Member Number is a surrogate key

8 Surrogate Key RENTAL (RegNo Make Model HirerID HirerName DateOfHire) RENTAL (RentalNo RegNo Make Model HirerID HirerName DateOfHire) RENTAL (RegNo Make Model HirerID HirerName DateOfHire)

9 Choosing a key An atomic key is better than a compound key A numeric attribute is better than a text attribute KISS = Keep It Short and Simple A key must have a value—it cannot be blank (or “null”) A key should not change over time Andrew Smith class 1B reg teacher C Walker PupilCode = AS1BCW

10 The flat file revisited… What is a suitable key? DVD Code? Member Number? (DVD Code, Member Number)? DVD CodeTitleCostDate OutDate Due Member NumberName Telephone Number 002Finding Nemo£2.5003/09/0404/09/041034John Silver142536 003American Pie£2.5027/08/0428/08/041056Fred Flintstone817263 003American Pie£2.5001/09/0402/09/041012Isobel Ringer293847 008The Pianist£2.5004/09/0406/09/041097Annette Kirton384756

11 Update Anomalies There is no way of storing the details of a member who hasn’t rented any DVDs A value must be provided for both DVD Code and Member Number for the key This is called an insertion anomaly DVD CodeTitleCostDate OutDate Due Member NumberName Telephone Number 002Finding Nemo£2.5003/09/0404/09/041034John Silver142536 003American Pie£2.5027/08/0428/08/041056Fred Flintstone817263 003American Pie£2.5001/09/0402/09/041012Isobel Ringer293847 008The Pianist£2.5004/09/0406/09/041097Annette Kirton384756

12 Update Anomalies DVD CodeTitleCostDate OutDate Due Member NumberName Telephone Number 002Finding Nemo£2.5003/09/0404/09/041034John Silver142536 003American Pie£2.5027/08/0428/08/041056Fred Flintstone817263 003American Pie£2.5001/09/0402/09/041012Isobel Ringer293847 008The Pianist£2.5004/09/0406/09/041097Annette Kirton384756 If a member’s details have to be amended, this must be done in each record with those details This can lead to data inconsistency if there is an error or omission in making the change This is called a modification anomaly

13 Update Anomalies If a DVD is removed from the database, then it may also remove the only record of a member’s details This is called a deletion anomaly DVD CodeTitleCostDate OutDate Due Member NumberName Telephone Number 002Finding Nemo£2.5003/09/0404/09/041034John Silver142536 003American Pie£2.5027/08/0428/08/041056Fred Flintstone817263 003American Pie£2.5001/09/0402/09/041012Isobel Ringer293847 008The Pianist£2.5004/09/0406/09/041097Annette Kirton384756

14 Update Anomalies Insertion anomalies Modification anomalies Deletion anomalies These are characteristics of poorly designed databases The solution is to use a relational database We use normalisation to help work out what tables are required and which data items should be stored in each table

15 Normalisation

16 Un-normalised Form (UNF) Identify an entity List all the attributes Identify a key ORDER(Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number Item Code Description Unit Cost Quantity)

17 Un-normalised Form (UNF) Identify repeating data items

18 Un-normalised Form (UNF) Identify repeating data items ORDER(Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number Item Code Description Unit Cost Quantity)

19 First Normal Form (1NF) Remove repeating data items to form a new entity Take the key with you! ORDER(Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number Item Code Description Unit Cost Quantity)

20 First Normal Form (1NF) Remove repeating data items to form a new entity Take a copy of the key with you! ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number)

21 First Normal Form (1NF) Identify a key for the new entity It will be a compound key ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number)

22 First Normal Form (1NF) Identify a key for the new entity It will be a compound key Label the foreign key Order Number is both part of the compound primary key and also a foreign key. ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number*)

23 First Normal Form (1NF) A data model is in 1NF if it has no multi-valued attributes ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number*)

24 First Normal Form (1NF)

25 But what if there were lots of orders for large deluxe red widgets…? There are still update anomalies

26 Update Anomalies Item Code, Description and Unit Cost values are duplicated in each entry. If the price of item 5499 were to change, this would have to be updated three times, which is both inefficient and could result in data inconsistency. This is a modification anomaly. it is not possible to enter details for an item which has not yet been ordered (because an order number is required as part of the compound key). This is an insertion anomaly. if an order is deleted (perhaps because it is cancelled), this could remove the only record containing an item’s details. This is a deletion anomaly.

27 Dependencies An attribute A is dependent on another attribute B if there is only one possible value for A given any value for B. For example, in the mail order system, consider the relationship between Order Number and Order Date. Order Date is dependent on Order Number, because for any given Order Number, there is only one possible date (i.e. the date the order was placed). However, the reverse is not true. Order Number is not dependent on Order Date, because for any given Order Date, there may be more than Order Number (because many orders may have been placed on that date).

28 Dependencies City is dependant on Airport The City can be determined if the Airport is known. There is only one possible City for a given Airport. Airport is not dependant on City. Knowing the City does not determine the Airport. A given City could have more than one Airport.

29 Second Normal Form (2NF) Examine any entity with a compound key (in this case ORDER_ITEM) See if any attributes are dependent on just one part of the compound key These are called partial dependencies ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number*)

30 Second Normal Form (2NF) Order Number is part of the key Item Code is part of the key Description is dependent on the Item Code Unit Cost is dependent on the Item Code Quantity is dependent on both Order Number and Item Code. ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number*)

31 Second Normal Form (2NF) Description and Unit Cost are partial dependencies They are dependent on Item Code Remove all these attributes to a new entity Leave a copy of the attribute they are dependent on as the FK ORDER ORDER_ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code Description Unit Cost Quantity Order Number*)

32 Second Normal Form (2NF) Item Code becomes the key of the new entity And becomes a foreign key in ORDER-ITEM ORDER ORDER_ITEM ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

33 Second Normal Form (2NF) A data model is in 2NF if it is in 1NF and there are no partial dependencies ORDER ORDER_ITEM ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

34 Second Normal Form (2NF) We can add an item to the Item table without it having to be on an order We can delete an order in the Order table without deleting details of the items on the order We can update item details once in the Item table without affecting the orders for that item in the Order-Item table

35 Second Normal Form (2NF) But there are still update anomalies with the Order entity ORDER(Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number)

36 Anomalies Clearly, the customer details are duplicated in each entry. If a customer’s address or telephone number were to change, this would have to be updated three times, which is both inefficient and presents the possibility of data inconsistency. This is a modification anomaly. It is not possible to enter details for a customer unless they have placed an order (because Order Number is required as a key). This is an insertion anomaly. If an order is deleted, this could remove the only record containing a customer’s details. This is a deletion anomaly.

37 Third Normal Form (3NF) Examine all the entities produced so far See if there are any non-key attributes which are dependent on any other non-key attributes These are called non- key dependencies ORDER ORDER_ITEM ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

38 Third Normal Form (3NF) In the ORDER entity, Customer Name, Address, Post Code and Telephone Number are all dependent on Customer Number ORDER ORDER_ITEM ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

39 Third Normal Form (3NF) Remove these attributes to a new entity ORDER ORDER_ITEM ITEM (Order Number Order Date Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

40 Third Normal Form (3NF) Remove these attributes to a new entity Customer Number is the key of the new entity Leave Customer Number behind as a foreign key ORDER CUSTOMER ORDER_ITEM ITEM (Order Number Order Date *Customer Number) (Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

41 Third Normal Form (3NF) A data model is in 3NF if it is in 2NF and there are no non-key dependencies ORDER CUSTOMER ORDER_ITEM ITEM (Order Number Order Date *Customer Number) (Customer Number Customer Name Address Post Code Telephone Number) (Item Code* Quantity Order Number*) (Item Code Description Unit Cost)

42 Third Normal Form (3NF) We can add a customer to the Customer table without the customer having to place an order We can delete an order in the Order table without deleting details of the customer who placed the order We can update a customer’s details once in the Customer table without affecting the orders placed by that customer in the Order table

43 Memory Aid In 3NF, each attribute is dependent on the key the whole key and nothing but the key

44 Normalisation A data model is in 1NF if it has no multi-valued attributes 2NF if it is in 1NF and there are no partial dependencies 3NF if it is in 2NF and there are no non-key dependencies

45 Entity-Relationship Diagram ORDER CUSTOMER ORDER_ITEM ITEM (Order Number Order Date *Customer Number) (Customer Number Customer Name Address Post Code Telephone Number) (*Order Number *Item Code Quantity) (Item Code Description Unit Cost)

46 Entity-Relationship Diagram ORDER CUSTOMER ORDER_ITEM ITEM (Order Number Order Date *Customer Number) (Customer Number Customer Name Address Post Code Telephone Number) (*Order Number *Item Code Quantity) (Item Code Description Unit Cost) The foreign key is always at the “many” end of the relationship

47 Source documents

48 List all the attributes which must be stored in the database DVD_RENTAL(Member Number Title Forename Surname Telephone No DVD Code Title Cost Date Hired Date Due Member Number Name)

49 Source documents List all the attributes which must be stored in the database Identify a key DVD_RENTAL(Member Number Title Forename Surname Telephone No DVD Code Title Cost Date Hired Date Due Member Number Name)

50 Source documents There are two attributes called Title DVD_RENTAL(Member Number Title Forename Surname Telephone No DVD Code Title Cost Date Hired Date Due Member Number Name)

51 Source documents There are two attributes called Title Member Number is stored twice DVD_RENTAL(Member Number Title Forename Surname Telephone No DVD Code Title Cost Date Hired Date Due Member Number Name)

52 Source documents There are two attributes called Title Member Number is the same as Member Number Name is already stored as Forename and Surname DVD_RENTAL(Member Number Title Forename Surname Telephone No DVD Code Title Cost Date Hired Date Due Member Number Name)

53 Source documents There are two attributes called Title Member Number is the same as Member Number Name is already stored as Forename and Surname Number or No? DVD_RENTAL(Member Number Title Forename Surname Telephone No DVD Code Title Cost Date Hired Date Due Member Number Name)

54 Source documents Tidy up UNF Carry on as before to 3NF DVD_RENTAL(Member Number Title Forename Surname Telephone Number DVD Code DVD Title Cost Date Hired Date Due)

55 Database Design For each attribute you must decide its name its data type its properties

56 Database Design For each attribute you must decide its name Choose sensible and meaningful field names Be consistent! e.g. Number/Num/No/#

57 Database Design For each attribute you must decide its name its data type text (alphanumeric, string) numeric (integer, real, currency) date or time Boolean (yes or no) link object (e.g. picture, sound, file)

58 Data Types Text Alphabetic “Smith” “John Smith” Alphanumeric “IV99 9ZZ” “01234 567890” “10 Downing Street” Free text: “The cat sat on the mat, etc…”

59 Data Types Numeric Integer: 3, 1246, 0, -5 Real/floating point: 3.14, 1246.0, 0, -5.2 Currency: 3.14, 1246.00, 0.00, -5.20 Note that the currency symbol is not stored

60 Data Types Date “Short” date: 20/09/2010 dd/mm/yyyy “Medium” date: 20 Sep 10 dd mmm yyyy “Long” date: 20 September 2010 dd mmmm yyyy Custom Monday, 20 September 2010 dddd dd mmm yyyy Watch out for US dates: mm/dd/yyyy

61 Database Design Names are usually stored as 3 or 4 fields Title (Mr/Mrs/Miss/Ms) Forename Initials/Other Names Surname

62 Database Design Addresses are usually stored as 3 or 4 fields Address1 (Street Address) Address2 (Town) Address3 (District) Post Code Sometimes the house number is stored separately from the Street Name

63 Database Design Telephone Numbers are always text Other “numbers” are also stored as text ISBNs Vehicle Registration “numbers” Serial numbers Use integers for whole numbers

64 Database Design For each attribute you must decide its name its data type its properties Primary key/foreign key PK/FK Validation (presence, range, restricted choice) Default value Format Store this information in a Data Dictionary

65 3NF Member MemberNumber Title Forename Surname Address1 Address2 Address3 PostCode TelephoneNumber Film FilmCode Title Loan MemberNumber* DVDCode* DateHired DateDue DVD DVDCode FilmCode* Cost

66 Data Dictionary

67

68

69

70


Download ppt "Relational Database Systems Higher Information Systems."

Similar presentations


Ads by Google