Semester 1 Session 3. Database design

Transcription

1 IRU SEMESTER 2 January 2010 Semester 1 Session 3 Database design Objectives To be able to begin the design of a relational database by Writing a mission statement for the project Specifying the mission objectives Writing a requirements specification document Drawing an entity-relationship model All the above may be required in the Assignment part one To continue work on the IRU assignment, part one. C:\Allwork\geoff\web stuff\askgeoff\iru\iru session 3 header - database design part one.doc Created by Geoff Leese

2 IRU database design part one Geoff Leese September 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 2 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 3

3 The Requirements Specification Document (RSD) 4 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. 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 5 ERD implied by that view Module 1 is assessed by Assessment 1 is taught in M assesses M belongs to Session M is attended by M is taken by M takes Student M attends 6

4 Entities 7 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 An entity must satisfy the following 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 8 Entity relationship modelling 9 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.

5 Concepts and notation 10 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 Attribute 11 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. 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 12

6 Degree of relationship (1) Denotes the number of occurrences of each entity type in the relationship SSADM notation this is shown using crows feet. 13 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. 14 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. 15

7 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. 16 Optionality 17 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. Part of an ERD Supplier May be sent Purchase order Is sent to So what does it mean? 18

8 It means.. Each supplier may be the supplier for one or more purchase Orders and each Purchase Order must be placed with one supplier. 19 One to try. Student Course 20 Use of ERDs 21 SSADM uses it in the feasibility phase as well as in the investigation of the current system 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.

9 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. 22 Resolving many to many relationships: The main reasons for this are: The M:N relationship hides many masterdetail 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! 23 How to resolve M:N 24 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

10 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. 25 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. 26 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 27 system

11 ERDs in software 28 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 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). 29 Further Reading 30 Rolland Chapter 2 Date C.J ((2004); An introduction to Database Systems (8 th 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

12 IRU SEMESTER 2 January 2010 Semester 1 Session 3 Database design part one Tutorial work A. Continue work on SQL exercises (Ex 3 attached) B. Continue work on IRU assignment part one. Be ready to demonstrate your solutions during next week s tutorial session. C:\Allwork\geoff\web stuff\askgeoff\iru\iru session 3 tutorial - database design part 1.doc

13 IRU SEMESTER 2 January 2010 SQL Exercise 3: 1: Select the name, job and date of hire of the employees in department 20. Display results as formatted below: ENAME JOB HIREDATE SMITH CLERK 12/17/80 JONES MANAGER 04/02/81 SCOTT ANALYST 04/19/87 ADAMS CLERK 05/23/87 FORD ANALYST 12/03/81 2: Select the name, job and date of hire of the employees in department 20. Display results as formatted below: ENAME JOB HIREDATE SMITH CLERK WEDNESDAY DECEMBER 17, 1980 JONES MANAGER THURSDAY APRIL 02, 1981 SCOTT ANALYST SUNDAY APRIL 19, 1987 ADAMS CLERK SATURDAY MAY 23, 1987 FORD ANALYST THURSDAY DECEMBER 03, : Select the name, job and date of hire of the employees in department 20. Display results as formatted below: ENAME JOB HIREDATE SMITH CLERK WEDNESDAY 17th DECEMBER, 1980 JONES MANAGER THURSDAY 02nd APRIL, 1981 SCOTT ANALYST SUNDAY 19th APRIL, 1987 ADAMS CLERK SATURDAY 23rd MAY, 1987 FORD ANALYST THURSDAY 03rd DECEMBER, : Select the name, job and date of hire of the employees in department 20. Display results as formatted below: ENAME JOB HIREDATE SMITH CLERK DECEMBER :12AM JONES MANAGER APRIL :04AM SCOTT ANALYST APRIL :04AM ADAMS CLERK MAY :05AM FORD ANALYST DECEMBER :12AM C:\Allwork\geoff\web stuff\askgeoff\iru\iru session 3 tutorial - database design part 1.doc

14 IRU SEMESTER 2 January : Are there any employees who have worked for more than 20 years for the company? EMPNO ENAME DEPTNO SMITH ALLEN WARD JONES BLAKE CLARK TURNER 30 6: Show the first day of the month in which each employee was hired. ENAME HIREDATE ADD_MONTH SMITH 17-DEC DEC-80 ALLEN 20-FEB FEB-81 WARD 22-FEB FEB-81 JONES 02-APR APR-81 MARTIN 28-SEP SEP-81 BLAKE 01-MAY MAY-81 CLARK 09-JUN JUN-81 SCOTT 19-APR APR-87 KING 17-NOV NOV-81 TURNER 08-SEP SEP-81 ADAMS 23-MAY MAY-87 JAMES 03-DEC DEC-81 FORD 03-DEC DEC-81 MILLER 23-JAN JAN-82 7: Show details of employee hire-dates and the date of their first payday. Paydays occur on the last Friday of each month. ENAME HIREDATE FIRSTPAYDAY SMITH 17-DEC-80 FRIDAY 26 DECEMBER 1980 ALLEN 20-FEB-81 FRIDAY 27 FEBRUARY 1981 WARD 22-FEB-81 FRIDAY 27 FEBRUARY 1981 JONES 02-APR-81 FRIDAY 24 APRIL 1981 MARTIN 28-SEP-81 FRIDAY 25 SEPTEMBER 1981 BLAKE 01-MAY-81 FRIDAY 29 MAY 1981 CLARK 09-JUN-81 FRIDAY 26 JUNE 1981 SCOTT 19-APR-87 FRIDAY 24 APRIL 1987 KING 17-NOV-81 FRIDAY 27 NOVEMBER 1981 TURNER 08-SEP-81 FRIDAY 25 SEPTEMBER 1981 ADAMS 23-MAY-87 FRIDAY 29 MAY 1987 JAMES 03-DEC-81 FRIDAY 25 DECEMBER 1981 FORD 03-DEC-81 FRIDAY 25 DECEMBER 1981 MILLER 23-JAN-82 FRIDAY 29 JANUARY 1982 Note that the actual data displayed will depend upon the date the query is run. Look at the data in emp to k h h C:\Allwork\geoff\web stuff\askgeoff\iru\iru session 3 tutorial - database design part 1.doc