IRU – database design part one

1. IRU – database design part one Geoff Leese September 2009

2. The mission statement • “High level” purpose of the project • “The purpose of the student records database system is to collect, store, manage and control access to the data that supports the delivery of our HE courses”

3. The mission objectives • Each one identifies a particular task that the database must support • Examples • To enter, update and delete data about students • To perform searches on staff data • To report on assessment data

4. The Requirements Specification Document (RSD) • Often a very formal document – avoids argument later! • Templates exist for their production • Clear, complete, unambiguous set of requirements • Often expressed as “user views” • Based on interviews, observation etc.

5. RSD example (VERY partial) • The module leader must be able to • Maintain (enter, update delete) details about her module(s) • Maintain (enter, update, delete) details about the sessions where her module is delivered • Maintain (enter, update, delete) details about the assessments required in his module • Report on which students are taking his module and their assessment progress

6. ERD implied by that view 1 is assessed by Module Assessment 1 is taught in M assesses M is taken by M belongs to Session M takes M is attended by Student M attends

7. Entities • An object or concept about which a system needs to hold information is known as an entity type or entity. • a person, place, a thing, an object, an event • which can be distinctly identified and is of interest. • e.g.: A specific student: Fred Smith • Can be concrete like a company • Can be abstract like an idea, concept

8. An entity must satisfy thefollowing criteria: • There must be more than one occurrence of the entity • Each occurrence must be uniquely identifiable • There must be data that the organisation wants to hold about the entity • It should be of direct interest to the system

9. Entity relationship modelling • A method of analysing the logical structure of an organisations information. • graphical representation of: • what the information is about • how it relates to other information and business concepts • how business rules are applied to its use in the system.

10. Concepts and notation • Many different notations used for drawing ER-diagrams • SSADM methodology: • Logical Data Structures (LDS). • This approach uses four main concepts and symbols: • Entities, • Relationships • Degrees • Optionality

11. Attribute • The attributes describe the entity • e.g. Sales Invoice entity may have the following attributes: • Sales invoice number • Customer Number • Sales invoice date • The detail of the attributes belonging to entities can be recorded as part of the diagram or in a separate textual description.

12. Relationships • Entities do not remain isolated they are related to other entities. • Represents a logical and not physical explanation of a system. • The relationships between entities represent business associations or rules and not physical links. • Any entities which are related are joined by a line on the diagram. The line is labelled with the name of the relationship in both directions and the relationship is two way

13. Degree of relationship (1) • Denotes the number of occurrences of each entity type in the relationship • SSADM notation this is shown using ‘crows feet’.

14. Degree of relationship (2) • One to one (1:1) This shows that each occurrence of Entity A is related to only one of entity B and each occurrence of B is related to only one occurrence of A. • Example - each student has one set of personal data, and each set of personal data is related to only one student.

15. Degree of relationship (3) • One to Many (1:M) This shows that each occurrence of entity A may be related to many occurrences of entity B. • Example: each sales invoice may be sent to only one customer but each customer may receive one or more sales invoices. This reflects one of the business rules of the organisation.

16. Degree of relationship (4) • Many to one (M:1) This shows that many occurrences of Entity A may be related to a single occurrence of Entity B. (It’s 1:M the other way around!) • Many to Many (M:N) • Relationships which are 1:1 or M:N are usually converted to 1:M on closer inspection.

17. Optionality • Each relationship can be further annotated to show if it must exist for all occurrences of the participating entity types. • If there can be occurrences of one entity that are not related to at least one occurrence of the other entity, then the relationship is optional. • shown by the use of a dashed line at the optional end(s) in the SSADM approach.

18. Part of an ERD Supplier May be sent Purchase order Is sent to So what does it mean?

19. It means……….. • Each supplier may be the supplier for one or more purchase Orders and each Purchase Order must be placed with one supplier.

20. One to try………. Student Course

21. Use of ERDs • SSADM uses it in the feasibility phase as well as in the investigation of the currentsystem and in the logical design of the proposed system. • RAD approaches concentrate on the proposed system and so use ERDs to model the proposed system alone.

22. Tips on drawing ERDs • Diagrams are easier to follow if you avoid crossing lines where ever possible. • For 1:M relationships you should aim to keep the entity at the ‘1’ end above and/or to the left of the entity at the ‘M’ end. (Not always possible). • At all times the diagram should agree with the users understanding of the system.

23. Resolving many to many relationships: • The main reasons for this are: • The M:N relationship hides many master-detail relationships • M:N relationships make navigation around the model very difficult or even impossible. • M:N relationships invariably hide information about the participating relationships or the entities themselves. • Many DBMS’s (MS-Access included!) can’t implement M:N relationships!

24. How to resolve M:N • Take the primary key from the entity at each end of the M:N relationship. • Merge them to form an “interposing” or “joining” entity between the original two. • Determine a primary key for the new entity • Re-examine dependencies

25. Resolving one to one relationships • achieved either by merging the two entities involved • or by replacing the 1:1 relationship by a I :M relationship which reads one or more, the reason for this is: • 1:1 relationships often obscure an underlying single entity • There may be a “missing link” entity.

26. Resolving M:N relationships • A sales invoice consists of one or more sales invoice lines, and an invoice line is associated with one invoice. • A sales invoice line comprises one item of stock, and an item of stock may appear on one or more sales invoice lines. • The M:N relationship was hiding the entity invoice line.

27. Removing redundant relationships • a “route map” navigates between any pair of entities, possibly by a number of different routes. • One of the aims of drawing a clear diagram should be to include only the minimum number of relationships needed to apply all the business rules relating to the data. • Any unnecessary relationships are redundant and will involve a maintenance overhead if implemented in the final system

28. ERDs in software • Access uses the relationship view to show ERDs for the database • On the Tools menu, select Relationships to see an ERD of your database (only works with multiple tables) • Access Help has topics on relationships

29. ERM Summary • Aims to facilitate communication between the database designer and the end user during the requirements analysis. • To facilitate such communication, the designer needs adequate communication tools. • Entity-Relationship diagrams are such tools that enable the system analyst to display the overall view of the enterprise data structure (the enterprise conceptual schema).

30. Further Reading • Rolland Chapter 2 • Date C.J ((2004); An introduction to Database Systems (8th edn); Chapter 14 • Ritchie C (1998); Relational Database Principles; chapters 3 and 4 • Avison D.E. and Fitzgerald G. (1995); Information Systems Development... ; Section 4.5