1 / 70

Relational Database Systems

Relational Database Systems. Higher Information Systems. 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.

leone
Download Presentation

Relational Database Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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. Entity-Occurrence Modelling • Lines indicate howthe instances ofeach entity arelinked • 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 berented by manyMembers • Each Member canrent many DVDs • So there is a many-to-many relationship between Member and DVD

  6. Entity-Occurrence Modelling • This method isonly as good asthe available data • Make up “dummy”data if necessary tofill 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 (RegNo Make Model HirerID HirerName DateOfHire) RENTAL (RentalNo 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)?

  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

  12. Update Anomalies • 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 modificationanomaly

  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

  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

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

  18. Un-normalised Form (UNF) • Identify repeating data items

  19. First Normal Form (1NF) • Remove repeating data items to form a new entity • Take the key with you!

  20. First Normal Form (1NF) • Remove repeating data items to form a new entity • Take a copy of the key with you!

  21. First Normal Form (1NF) • Identify a key for the new entity • It will be a compound key

  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.

  23. First Normal Form (1NF) • A data model is in 1NF if it has no multi-valued attributes

  24. First Normal Form (1NF)

  25. First Normal Form (1NF) • 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

  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.

  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

  32. Second Normal Form (2NF) • Item Code becomes the key of the new entity • And becomes a foreign key in ORDER-ITEM

  33. Second Normal Form (2NF) • A data model is in 2NF if it is in 1NF and there are no partial dependencies

  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

  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

  38. Third Normal Form (3NF) • In the ORDER entity, Customer Name, Address, Post Code and Telephone Number are all dependent on Customer Number

  39. Third Normal Form (3NF) • Remove these attributes to a new entity

  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

  41. Third Normal Form (3NF) • A data model is in 3NF if it is in 2NF and there are no non-key dependencies

  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

  46. Entity-Relationship Diagram • The foreign key is always at the “many” end of the relationship

  47. Source documents

  48. Source documents • List all the attributes which must be stored in the database

  49. Source documents • List all the attributes which must be stored in the database • Identify a key

  50. Source documents • There are two attributes called Title

More Related