1. Relational Database Systems Higher Information Systems

2. What’s new? New are… –Clear focus on SSADM methodology –Knowledge of the Relational Database Model –Clearly defined data types –Reduction in practical work with RDBMS –No bias towards one database implementation tool i.e. Microsoft Access –one data dictionary

3. Unit Specification General Outcomes and Performance Criteria Only two outcomes One theory, one practical Detailed content statements Clear evidence requirements Reduced assessment burden Clear limitations on complexity of problems to be experienced by pupils Written to reflect a more analytical approach to database systems

4. Unit Specification Detailed Content Layout with Intermediate 2 content to show progression and assist bi-level teaching Content Statements: Database fundamentals Intermediate 2Higher Description of the benefits of an electronic database system in comparison with manual data storage, including –searching and sorting –data retrieval –data storage and updating –data analysis and reporting Description of need for and methods of achieving good database design, including consideration of the following: –data duplication –data insertion –data deletion –data modification –problems associated with meaningful identifiers

5. Evidence Requirements Outcome 1 - Objective Test. Multiple choice – can be marked quickly. Observation checklist for practical work. Only need to have hard copy of three of the observation items.

6. Approach to delivering the unit

7. Teach pupils about databases first and the relational model in particular then.. teach pupils how to analyse data, to design data and databases, the elements of implementation (queries, reports, user interface design), and then complete some limited implementation

8. Approach to delivering the unit The unit is designed to develop student skills from small concepts to big ideas and tasks. Start small…data (datum), row, column, knowledge about databases… …and end BIG. Developing a solution through analysis, design, implementation

9. Database Fundamentals

10. Start small

11. Drawbacks of Traditional Paper Based Databases

12. Revision from last time Entity Integrity Referential Integrity Primary Key Foreign Key Compound Primary Key Surrogate Key

13. Candidate Key New Car Make Model Colour Registration No. Manufacturer No. Chassis No. Drivers Licence Ref No.

14. Database Fundamentals The Relational Data Model The relational data model is the most common data model currently in use today and consists of three components: –A data structure –A set of data operators –A set of data integrity rules The Relational Data Model deals with RELATIONS (represented as tables)

15. Database Fundamentals Seven Rules 1.Every relation/table in a database must have a unique name. 2.Every column in a relation/table must have a unique name within that relation. 3.All entries in a column must be of the same kind. 4.The ordering of columns in a relation/table is not significant. 5.Each row in a relation/table must be unique. Duplicate rows are not allowed in a relation. 6.The order of the rows is not important in the relation. 7.Each cell in the table (the intersection of a column and a row) must contain only one value. Multiple entries are not allowed in a cell.

16. Database Fundamentals – Columns and Column Characteristics Each column in a relation must have a unique name. Two or more tables within the same database may have columns with the same name Naming scheme to refer to similarly named columns i.e. student.dept_code and department.dept_code Column data from same domain i.e this is incorrect surname Burton Low 0821 928192 Ogston Wilson Smith

17. student_idtitlefirstnamesurname 9701111MrCharlieBurton 9802600MissSusanLow 9802685MrAlexanderMiddleton 9807777MrDavidWilson 9891000MrJohnSmith Database Fundamentals – Rows and Row Characteristics Each row in a relation must be unique. Each cell in a relation must contain only one piece of data. relations that hold multi-valued cells contain repeating data items and where there are one or more of these items they are referred to, collectively, as a repeating group. Row Column Cell

18. Entities, Instances and Attributes Instance Entity Instance Attribute

19. Database Fundamentals – Rows and Row Characteristics Each piece of data in a relational database is a data item. Addresses in database systems are typically stored as multiple data items (such as house number, street, town and postcode) rather than one data item (address). Data items must be atomic Increases the ease with which we can search and maintain the data

20. DVD CodeTitleCost Member NumberName Telephone Number 002Finding Nemo£2.501034John Silver142536 003American Pie£2.501056Fred Flintstone817263 003American Pie£2.501012Isobel Ringer293847 011Notting Hill£2.501012Isobel Ringer293847 011Notting Hill£2.501056Fred Flintstone817263 014Prime Suspect£2.001097Annette Kirton384756 015Shrek£1.501034Joan Silver142536 016Toy Story 3£2.50 1189Tom McKenzie566988

21. Database Fundamentals – Primary Key Each row in a relation must be unique. each relation must have a primary key A primary key is one or more columns of the relation whose values are used to uniquely identify each row Avoid meaningful Primary Keys student_idtitlefirstnamesurname date_of_birth year_of_studydept_code 9701111MrCharlieBurton05/01/19754 th COMP 9802600MissSusanLow12/09/19862 nd OENG 9806666MrSandyOgston14/12/19822 nd ENG 9701111MrCharlieBurton05/01/19754 th COMP student_idtitlefirstnamesurname date_of_birth year_of_studydept_code 9701111MrCharlieBurton05/01/19754 th COMP 9802600MissSusanLow12/09/19862 nd OENG 9806666MrSandyOgston14/12/19822 nd ENG 9701173MrCharlieBurton05/01/19754 th COMP

22. Concept of candidate keys – how do I choose a key? The two tables are part of a database used by a university. The university allocates a unique identifier to each department (dept_code) and each department has a different name. The university has many buildings on its campus and it is possible for departments to share accommodation. The university has an internal telephone system. All lecturers, departments and administration staff have their own extension number. student_idtitlefirstnamesurname date_of_birth year_of_studydept_code 9701111MrCharlieBurton05/01/19754thCOMP 9802600MissSusanLow12/09/19862ndOENG 9802685MrAlexanderMiddleton28/05/19802ndMIS 9806666MrSandyOgston14/12/19822ndENG 9807777MrDavidWilson21/10/19842ndENG 9891000MrJohnSmith19/02/19861stCOMP Database Fundamentals – Primary Key

23. location can be ruled out because departments can share accommodation (even though the sample data given does not show this!). The ext_no could be used as a primary key but the ext_no is also used by lecturers and administration staff The dept_name and the dept_code are both unique to each row Large keys are clumsy therefore dept_code is a better primary key than the dept_name and would be the best choice as primary key Database Fundamentals – Primary Key dept_codedept_namelocationext_no COMPSchool of Computer and Mathematical SciencesBuilding A1234 ENGSchool of Electronic and Electrical EngineeringWest Annex2136 MISSchool of Management and InformationBuilding C4101 OENGSchool of Mechanical and Offshore EngineeringBuilding B2134

24. Database Fundamentals – Primary Key also…dept_name is a meaningful primary key and therefore is unsuitable. Meaningful primary keys tend to change over time and this can introduce significant problems in a database system. Avoid using meaningful primary keys if you possibly can. Use arbitrary codes of numbers or letters instead.

25. Database Fundamentals – Compound Primary Keys because a property can be viewed more than once, property_id and client_name are repeated; because one potential buyer can view one or more properties on several different occasions, potential_buyer_no and potential_buyer_name can appear more than once; and because any house can be visited more than once on the same day, the date_of_viewing is repeated. Note that the same person cannot view the same house twice on the same day. combination of property_id, potential_buyer_no and date_of_viewing is unique. property_idclient_namepotential_buyer_nopotential_buyer_namedate_of_viewing P101Smith1282Jones17.04.2004 P101Smith1982Perkins19.04.2004 P101Smith2983Patel29.05.2004 P101Smith1282Jones29.05.2004 P106Parker1282Jones29.05.2004 P106Parker7225Mitchell23.04.2004

26. Database Fundamentals – Surrogate Keys A surrogate key is an arbitrary single column primary key which is created specifically for a relation. A surrogate key is created when the compound key for a relation is too complex to allow the key to be used efficiently or there is no unique collection of columns available in the relation. viewing_idproperty_idclient_namepotential_buyer_nopotential_buyer_namedate_of_viewing 164P101Smith1282Jones17.04.2004 165P101Smith1982Perkins19.04.2004 166P101Smith2983Patel29.05.2004 167P101Smith1282Jones29.05.2004 168P106Parker1282Jones29.05.2004 169P106Parker7225Mitchell23.04.2004

27. Database Fundamentals – Foreign Keys Foreign keys are vital in relational databases. Relationships between relations in database are created by linking a foreign key in one relation with its related primary key in a different relation.

28. Database Fundamentals – Data Operators There are four ways in which data is manipulated in a relational database system. –Data is entered in to a relation –Data is deleted from a relation –Data is amended in a relation –Data is retrieved from a relation These relational database operators allow data to be inserted, amended, deleted and retrieved from a relational database.

29. Database Fundamentals – Data Integrity Entity integrity Entity integrity relates to primary keys. This rule states that every relation must have a primary key and the column or columns selected for the primary key should be unique and not null. Referential integrity Referential integrity is concerned with foreign keys. The referential integrity rule states that foreign keys should have two states. Either, the foreign key should be linked to the primary key of a related relation or, in very special circumstances, should have a null value.

30. Data Modelling – Building Blocks and Tools

31. Data Modelling – Building Blocks What is an entity? An entity is something about which we want to record information. An entity may be concrete (a person or a book, for example) or abstract (like a holiday or a concept). For instance: –Joanne Harris with National Insurance Number NC 54 72 12 D –The Rental of Spiderman with a rental date of 23/12/05 and DVD Number of 6591

32. Data Modelling – Building Blocks Entity Set An entity set is a collection of entities of the same type this is often represented as a table in a database system or as a relation in the relational data model. Attributes An entity is represented by a set of attributes. Each attribute stores some data about the entity.

33. Data Modelling – Building Blocks Domain Constraints The domain of an attribute is the set of permitted values (e.g. the name must only contain letters). Each domain has a set of domain constraints. These constraints apply to the type and value of the data that the attribute can hold. The domain constraints define the data that can be legally held by an attribute.

34. Data Modelling – Building Blocks Data Types Text, Integer, - no decimals eg no of pupils Real, - all other numbers Object, - picture Boolean, - yes/no Date, Time.

35. Data Modelling – Building Blocks More on Domain Constraints Size of attributes Constrained by permitted values Constrained by range Constrained by format Storage requirements

36. Data Modelling – Building Blocks Cardinality A relationship can be thought of as a connection between the two entities. There are three types of relationship, better know as the cardinality of the relationship. One-to-one One-to-many Many-to-many

37. One-to-one pupil_numpupil_nameregister_classlocker_numlocker_type 43781Jennifer Brown4A232CVanguard 57842Aveek Anderson3E234CGuardian 23423Scott Lowson2F728DAthletic 23426Wendy Alexander2F483BVanguard Data Modelling – Building Blocks

38. One-to-many A local medical centre has several doctors that work for it. Each doctor has a list of patients and patients can only see the doctor on whose list they appear. doctor_nodoctor_name patient_nopatient_name 81Dr Paul Johnson781902Mrs Angela Lilly 891201Miss Megan Smith 090120Mr Henry Ford 142Dr Wendy Reid110202Mr Ivor Barr 210092Miss Iona Jones 093791Mr Ian Hosack 223Dr Vanessa Love093794Mr Colin Holm 103792Mr Gordon Buck 210198Mr Rob Elliott 226Prof James Joyce210199Miss Louise Flower 210200Mr Nick Spencer

39. Data Modelling – Building Blocks Many-to-many A group of colleges have set up a netball league. The league is made up of teams and the teams have many players. One player can play for more than one team. Each team must have at least one player and each player must have at least one team. team_idteam_nameplayer_idplayer_name KY91St. Andrews0021Carol Keller AB81Ellon0145Jo Andrews ED12Edinburgh0212Kylie Scott GL12Glasgow0895Constance West IV12Inverness0992Christina Hamilton DF12Dunfermline2616Star West ST12Stirling4281Adele Booker BW19North Berwick5298Iona McCrae AB12Cults7291Louise Ludd PP12Perth8102Kim White DD61Dundee9182Madia Smith

40. Data Modelling – Tools Case Study Reed and Co. are a transport and removal company which specialise in removals for large corporate clients. The manager of Reed and Co. has a system for allocating removal vans to clients. The current system uses two books. The first book contains the names and details of the clients together with dates and details of the removals. Each client has a section of this book dedicated to them. When a removal is requested, the removal is entered and allocated a shipment number. Each shipment is covered by an insurance policy. For insurance reasons each client can only have one removal in any one shipment. However, different clients can be allocated the same shipment number so that they are covered by the same insurance policy. The Insurance Ref is the insurance policy number for the shipment.

41. From this you can see that each Shipment Nbr is only unique for each Client. The second book contains details of the removal vans that Reed and Co. own. Each removal van has a unique registration number. To allocate a van to a removal the manager writes the van number against the removal in the Client book. Each van has only one removal allocated at a particular time and each removal only has one van allocated to it. Data Modelling – Tools Client Nbr:0921Client Telephone:0327 989127 Client Name:Great Arwoods Plc.Client Fax:0327 981111 Client Address:18 New Parlie St Edinburgh EH87 9QQ Contact Person:Vicky Kenn Shipment Nbr Insurance Ref FromToDateTimeVan Reg 0012NT92383 Abercrombie St, Aberdeen, AB15 7YU 18 Drummond Pl, Aberdeen AB11 8TR 23/02/200409:30KY51 AFZ 0010RT87215 West Beach, Finchley NW9 8YU 12 Dorset St, Leeds L87 8HU 24/02/200408:30P385 ASA 0014QW1211The Lodge, Heathsville West Moore WM8 3HJ 15 Smith Heights Bothwill G56 7ER 24/02/200411:30D842 YSA

42. Van RegClient Nbr P385 ASA2711 KY51 AFZ YT71 7YE 0921 D842 YSA Data Modelling – Tools Creating an E/R Occurrence diagram This assists identification of relationship.

43. Data Modelling – Tools Entity Set - the name must never be a plural, it must always be a singular e.g. person rather than people. The relationship between the two entity sets. Relationships illustrate how two entities sets share information. Attribute Key Attribute Multivalued Attribute

44. Data Modelling – Tools A weak entity set is one that is created to remove a many- to-many relationship. Derived Attribute - A derived attribute is one that is calculated from other attributes. To connect a weak entity set with others, you should use a weak relationship notation.

45. Data Modelling – Tools Entity/Relationship Diagram One-to-one One-to-Many Many-to-many NOT

46. Adding Attributes

47. Data Modelling – Tools Case Study 2 Attempt Q1 and Q2 at the end of Case Study 2

48. Data Modelling – Tools Notation and Rules Keep to all lower case letters in entity and attribute names Don’t use spaces, use underscore (_) instead Using meaningful names Keep it short (if you can)

49. Data Modelling – Tools Data Dictionary –Entity Set –Name –Type –Size –Validation presence (are null values allowed or not) range (above / below certain values) permitted values (only one of a selection of permitted values is allowed) format (the data entered must conform to a specific pattern and/or number of characters) –Index/Key

50. Data Modelling – Tools Concept of an index Idea of index being useful for locating data

51. Data Modelling – Tools Index entry in data dictionary Data Dictionary can be created before normalisation to assist understanding of the data, then again, after normalisation, to assist implementation. There is only a requirement to create a dictionary once. Attribute propertyIndex Entry Attribute is primary keyYes, primary key Attribute is part of a compound primary keyYes, compound key Attribute is a foreign keyYes, foreign key Attribute is to be indexedYes Attribute is not to be indexedNo