Design & Build A Microsoft Office Access Database

Designing and Building
Access Database Systems
Edition 7, October 2009
Mark Gregory
___________________________________________________________________________
Page 1 of 150
Designing and Building Access
Database Systems
Mark Gregory
École Supérieure de Commerce de Rennes
ESC Rennes School of Business, France
Previously,
Edition 0 School of Computing and March 2000

Engineering, University of
Huddersfield
Edition 7 ESC Rennes School of Business, October 2009

France
Work on this document started when Mark Gregory was working

at the University of Huddersfield, UK in 1999/2000. Some of the
material included was originally written by my then colleague Dr.
Steve Wade, who is still at Huddersfield. Other portions draw on
work by Dr. Ken Lunn, who has moved on to the IT Directorate of
the UK National Health Service.
The Sixth Edition was a very substantial revision of the previous
year’s edition, as is this Seventh Edition.
Page 2 of 150
DESIGNING AND BUILDING ACCESS DATABASE SYSTEMS..............................2
MARK GREGORY.......................................................................................................2
ÉCOLE SUPÉRIEURE DE COMMERCE DE RENNES..............................................2
ESC RENNES SCHOOL OF BUSINESS, FRANCE...................................................2
PREVIOUSLY, .............................................................................................................2
Edition 0..................................................................................................................................................................2
School of Computing and Engineering, University of Huddersfield................................................................2
March 2000.............................................................................................................................................................2
Edition 7..................................................................................................................................................................2
ESC Rennes School of Business, France..............................................................................................................2
October 2009...........................................................................................................................................................2
1. INTRODUCTION: WHO IS THIS DOCUMENT FOR?...........................................13

1.1. Preface .............................................................................................................................................................13
1.2. Skills required................................................................................................................................................13
1.3. The aims of the remainder of this document .............................................................................................13
1.4. The structure of this document and how to use it......................................................................................14
1.5. About Learning Access..................................................................................................................................15

1.5.1. Starter: the naïve user: Level 1................................................................................................................15
1.5.2. The thinking user: Level 2.......................................................................................................................15
1.5.3. The competent (“power”) user: Level 3..................................................................................................15
1.5.4. Advanced: the programmer or systems integrator: Level 4....................................................................15
1.5.5. What is the relevance of MS Access skills?............................................................................................15
1.6. Testing yourself..............................................................................................................................................15

1.6.1. What you should already know................................................................................................................16
1.6.2. What you should already be able to do or need now to learn.................................................................16
1.6.3. A checklist of more advanced skills........................................................................................................17
1.6.4. Further help on learning to learn..............................................................................................................17
1.7. Conventions Used in this document.............................................................................................................17
1.8. Limitations......................................................................................................................................................17
1.9. Acknowledgements........................................................................................................................................18
SECTION 1 - THE PRINCIPLES OF DATABASE....................................................19
Page 3 of 150
2. A BRIEF INTRODUCTION TO DATABASES........................................................19
2.1. Databases (bases de données) and how they are designed.........................................................................19
2.2. Models used by systems analysts..................................................................................................................19
2.3. Simple model of data processing..................................................................................................................19
2.4. Why study Databases?...................................................................................................................................20

2.4.1. They are used in every significant BIS....................................................................................................20
2.4.2. They are at the heart of............................................................................................................................20
2.5. Background....................................................................................................................................................20
2.6. How to store data...........................................................................................................................................20
2.7. What is a database?.......................................................................................................................................21
2.8. Why keep data in different tables?..............................................................................................................21
2.9. Learning a minimum about database..........................................................................................................23
2.10. Basic concepts...............................................................................................................................................23
2.11. Entity (type, class)........................................................................................................................................24
2.12. An example: Students by Programme.......................................................................................................25
2.13. Attribute........................................................................................................................................................25
2.14. Primary and Foreign Keys.........................................................................................................................25
2.15. Why have foreign keys? .............................................................................................................................26
2.16. Entity occurrences – student......................................................................................................................26
2.17. Entity occurrences – programme...............................................................................................................26
2.18. Queries..........................................................................................................................................................26
2.19. Students and Modules.................................................................................................................................27
2.20. Three Vital Rules.........................................................................................................................................27
2.21. Resolving Many-to-Many Relationships...................................................................................................27
2.22. Towards a more complete entity relationship attribute model..............................................................30
2.23. Example Query – definition........................................................................................................................31
2.24. Example Query – results.............................................................................................................................31
2.25. What is a query?

(French ‘une requête’).........................................................................................................................................32
2.26. Data Dictionary............................................................................................................................................32
2.27. Entity-Relationship Diagrams (ERD)........................................................................................................32
2.28. Another example database: NorthWind / Les Comptoirs.......................................................................32

Page 4 of 150
2.29. Relationship: meaning and characteristics...............................................................................................33
2.30. Why it’s important to relate entities..........................................................................................................34
2.31. Degree of relationship (simplified).............................................................................................................34
2.32. Simple database design................................................................................................................................34
3. A SIMPLE METHODOLOGY FOR DESIGNING MICROSOFT ACCESS

DATABASES..............................................................................................................35
3.1. Introduction – background to the methodology.........................................................................................35
3.1.1. Database, or something else?...................................................................................................................35
3.1.2. What is a methodology?...........................................................................................................................35
3.1.3. Assumptions..............................................................................................................................................36
3.1.4. Introduction to modelling business information systems: why we have chosen certain techniques.....36
3.1.5. What we’re trying to achieve together.....................................................................................................37
3.1.6. Business Process Modelling: Documenting a Business Process.............................................................37
3.1.7. Why have we chosen the techniques we have?.......................................................................................37
3.1.8. Business Process Modelling.....................................................................................................................38
3.1.9. SSADM.....................................................................................................................................................38
3.1.10. MERISE..................................................................................................................................................39
3.2. Feasibility study.............................................................................................................................................39
3.3. Set out Project Terms of Reference.............................................................................................................40
3.4. Analyse the needs of users.............................................................................................................................40

3.4.1. Identify business processes using a high-level Use Case diagram..........................................................40
3.4.2. Identify detailed requirements for a process to be computerised: carry out Process Modelling...........40
3.5. Decide the purpose and basic contents of the database – Data Modelling..............................................41
3.5.1. Basic Constructs of ER Modelling...........................................................................................................41
3.5.2. Deciding entity types................................................................................................................................41
3.5.3. Entities......................................................................................................................................................41
3.5.4. Relationships.............................................................................................................................................42
3.5.5. Fields: What are the attributes of each entity?........................................................................................43
3.5.6. Data type: Domain....................................................................................................................................44
3.5.7. Identify Domains......................................................................................................................................44
3.5.8. Classifying Relationships.........................................................................................................................45
3.5.9. Keys: primary and secondary (“foreign”)................................................................................................46
3.5.10. Normalisation.........................................................................................................................................48
3.5.11. ER Notation............................................................................................................................................49
3.5.12. Online tutorial.........................................................................................................................................50
3.5.13. DFDs and ERDs – why both? How are they linked?............................................................................51
3.5.14. Why BOTH Data and Process models?.................................................................................................51
3.6. Cross-check: entity life history.....................................................................................................................51

3.6.1. Cross-check DFD and ERA......................................................................................................................51
3.6.2. Time dimension........................................................................................................................................51
3.7. Model User <-> System Interactions ..........................................................................................................52
3.8. Define required outputs: reports, forms, queries.......................................................................................52
3.9. How will Input / Update be carried out (Forms etc.)? .............................................................................52
3.10. Work through your design on paper, whiteboard, etc............................................................................52
3.11. Implementing processes in Access.............................................................................................................52

Page 5 of 150
3.11.1. System data processing.........................................................................................................................53
3.12. Define (“design” in Access terms) the database: Build a prototype......................................................53
3.13. Refine / iterate / implement........................................................................................................................53
3.14. Test the database..........................................................................................................................................53
3.15. Obtain User Feedback.................................................................................................................................53
3.16. Refine the system by Iteration....................................................................................................................54
4. PUTTING DATABASE DESIGN THEORY INTO PRACTICE...............................54

4.1. Design aids......................................................................................................................................................54
4.2. An Exercise.....................................................................................................................................................54
4.3. Achieving real competence in Database Design.........................................................................................55

4.3.1. Documented scenarios..............................................................................................................................55
4.3.2. Suggested but undocumented scenarios...................................................................................................56
4.3.3. Further study.............................................................................................................................................56
5. MORE ABOUT DATABASES................................................................................56

5.1. What is a database?.......................................................................................................................................56
5.2. The history of databases................................................................................................................................57
5.3. Implementing data models in MS Access....................................................................................................57
5.4. What is a database management system?...................................................................................................58
5.5. First challenge: database design..................................................................................................................58
5.6. Second challenge: database implementation..............................................................................................59
5.7. An inductive approach..................................................................................................................................59
5.8. What Is a Database?......................................................................................................................................59
5.9. What Is a DBMS?..........................................................................................................................................60
SECTION 2 – USING MICROSOFT ACCESS TO BUILD GOOD DATABASES....61
6. INTRODUCTION TO MICROSOFT ACCESS........................................................61

6.1. What is a database management system?...................................................................................................61
6.1.1. Software which manages a database........................................................................................................61
6.1.2. Implements entities as tables, maintaining and enforcing relationships.................................................61
6.1.3. Deals with all the component disc files...................................................................................................61
6.1.4. Provides functions such as.......................................................................................................................61
6.1.5. An approachable programming language................................................................................................61
6.2. Important facilities of more advanced DBMS............................................................................................61
6.3. Further facilities of more advanced DBMS................................................................................................62

Page 6 of 150
6.3.1. Other RDBMS..........................................................................................................................................63
6.4. Why we want business students to learn Access.........................................................................................63

6.4.1. The relative ease-of-use of MS Access....................................................................................................64
6.4.2. MS Access is easily obtained...................................................................................................................64
6.4.3. MS Access supports usable programming languages..............................................................................64
7. MS ACCESS IMPLEMENTATION OF DATA MODELS........................................64

7.1. Tables, one per entity type............................................................................................................................64
7.2. Fields, one per attribute................................................................................................................................64
7.3. Records, one per entity occurrence.............................................................................................................64
7.4. Attribute types in MS Access........................................................................................................................65
7.5. Permitted data types in MS Access..............................................................................................................65

7.5.1. Use of Number or Currency fields...........................................................................................................67
7.5.2. Storing telephone numbers.......................................................................................................................67
7.5.3. Controlling data entry formats with masks..............................................................................................67
7.6. Keys ................................................................................................................................................................67

7.6.1. Candidate keys..........................................................................................................................................67
7.6.2. Primary key...............................................................................................................................................67
7.6.3. Multi-part primary keys............................................................................................................................68
7.6.4. Entity integrity rule..................................................................................................................................68
7.6.5. Foreign keys..............................................................................................................................................68
7.7. Relationships..................................................................................................................................................68
7.7.1. Relationships and linking: Enforcing referential integrity where appropriate.......................................70
7.8. System outputs...............................................................................................................................................70

7.8.1. Queries......................................................................................................................................................70
7.8.2. Reports......................................................................................................................................................70
7.8.3. Forms........................................................................................................................................................70
7.9. System inputs..................................................................................................................................................71

7.9.1. Forms, sub-forms and their use with 1: M and M: N relationships.........................................................71
7.9.2. Field-specific validation checks...............................................................................................................71
7.9.3. Using relational integrity to carry out inter-table validation checks......................................................71
7.9.4. Table-level checks on forms....................................................................................................................72
7.10. Implementing processes..............................................................................................................................72

7.10.1. Data processing in Access......................................................................................................................72
7.10.2. Functional elements in Access...............................................................................................................72
7.11. System data transformations......................................................................................................................73

7.11.1. Append and Update queries...................................................................................................................73
7.11.2. Macros....................................................................................................................................................73
7.11.3. Visual Basic for Applications (VBA) modules inside Access..............................................................73
7.11.4. Visual Basic programs outside Access..................................................................................................73
8. WAYS IN WHICH TO LEARN MORE MS ACCESS..............................................74

8.1. Sample databases and applications included with Microsoft Access.......................................................74
8.1.1. NorthWind Traders sample database (English edition) /
Les Comptoirs (édition française)......................................................................................................................74
8.1.2. Database Wizards (Assistants).................................................................................................................74
Page 7 of 150
SECTION 3 – THE ANYTOWN DISTANCE LEARNING BUSINESS SCHOOL
EXAMPLE...................................................................................................................75
9. EXAMPLE SCENARIO: ANYTOWN DISTANCE LEARNING BUSINESS

SCHOOL.....................................................................................................................75
10. BACKGROUND: STUDYING...............................................................................75
11. A CLOSER LOOK INTO "MANAGING STUDENTS".........................................75
12. THE PROCESS OF DECIDING WHAT HAPPENS TO STUDENTS...................76
13. COURSE REVIEW................................................................................................76
14. SIMPLIFYING ASSUMPTIONS............................................................................77
15. EXTERNAL ENTITIES..........................................................................................77
16. PROCESSES........................................................................................................77
16.1. Process Applicants.......................................................................................................................................77
16.2. Admit students to Course – Course Enrolment........................................................................................77
16.3. Register students on core and optional modules......................................................................................77
16.4. Teach and assess a module..........................................................................................................................77
16.5. Prepare for and hold exam board (jury)...................................................................................................77

Collect together the results for all students for all modules they have been studying....................................77
Review module results in exam board..............................................................................................................77
Decide student status in exam board.................................................................................................................77
16.6. Review Course..............................................................................................................................................77
17. DOCUMENTS.......................................................................................................78
17.1. Course Description......................................................................................................................................78
17.1.1. List of Modules.......................................................................................................................................78
17.2. Management Reports..................................................................................................................................78
18. ENTITY AND ATTRIBUTE LISTS........................................................................78
19. EXAMPLE STUDENT RECORD REPORT..........................................................79
20. ANYTOWN HIGH-LEVEL USE CASE DIAGRAM...............................................80
21. ANYTOWN: CONTEXT DIAGRAM......................................................................81
Page 8 of 150
22. LEVEL 1 DFD.......................................................................................................82
23. EXAMPLE LEVEL 2 DFD.....................................................................................83
24. DATA DICTIONARY.............................................................................................84

24.1. Data dictionary for Anytown Business School..........................................................................................84
25. ANYTOWN ER DIAGRAM....................................................................................96
26. ANYTOWN SYSTEM IMPLEMENTATION .........................................................97
27. TERMINOLOGY ASSOCIATED WITH DATA MODELLING AND DATABASE

DESIGN.......................................................................................................................97
28. REFERENCES......................................................................................................98
28.1. Basics of structured analysis.......................................................................................................................98
28.2. Database theory............................................................................................................................................98
28.3. DataFlow Diagrams (DFDs).......................................................................................................................98
28.4. Entity relationship modelling.....................................................................................................................98
28.5. Use Case .......................................................................................................................................................98
28.6. Basics of Object Oriented Analysis and Design (OOAD)........................................................................99
29. APPENDIX 1 BUSINESS PROCESS ANALYSIS USING USE CASE

ANALYSIS................................................................................................................100
29.1. What is a Use Case Diagram?..................................................................................................................100
29.2. What to do if a use case diagram won’t fit on a single page?...............................................................103
29.3. Finding Use Cases......................................................................................................................................103
29.4. Naming Use Cases......................................................................................................................................104
29.5. Describing Use Cases.................................................................................................................................105
29.6. Using Use Cases to identify System Inputs and Outputs.......................................................................105
29.7. Other resources for learning about Use Cases.......................................................................................105
30. APPENDIX 2 DATA FLOW DIAGRAMS..........................................................106

30.1. What are Data Flow Diagrams (DFDs)?.................................................................................................106
30.2. Why use Data Flow Diagrams?................................................................................................................106
30.3. What is a DFD? Main elements................................................................................................................107
Page 9 of 150
30.4. The components of a DFD.........................................................................................................................107
30.5. What appears on a DFD?..........................................................................................................................108

30.5.1. Listing the elements of a DFD.............................................................................................................109
30.6. The Data Flow Diagram Symbols – SSADM Notation..........................................................................109
30.7. Making a Data Flow Diagram: a Top-Down Approach........................................................................109
30.8. The elements of a DFD..............................................................................................................................110
30.9. Creating DFDs............................................................................................................................................110
30.10. First List the Elements of the Data Flow Diagram..............................................................................112
30.11. Drawing the Context Diagram...............................................................................................................112
30.12. Expanding a context diagram to give a level 1 DFD............................................................................112
30.13. Questions to ask yourself........................................................................................................................113
30.14. Rules for DFDs.........................................................................................................................................113
30.15. Some points on logical DFDs..................................................................................................................113
30.16. Supporting documentation.....................................................................................................................113
30.17. Summary: “levelled” DFDs....................................................................................................................114
31. APPENDIX 3 WHEN TO USE A SPREADSHEET, AND WHEN TO USE A

DATABASE...............................................................................................................115
31.1. Introduction................................................................................................................................................115
31.2. Spreadsheets versus databases.................................................................................................................115

31.2.1. What spreadsheets are good at.............................................................................................................115
31.2.2. What databases are better at.................................................................................................................115
31.2.3. Using spreadsheets and database together...........................................................................................116
31.2.4. Summary...............................................................................................................................................116
31.3. What to do if your spreadsheet skills are weak......................................................................................117
31.4. What to do if your database skills are weak...........................................................................................117
31.5. Conclusion..................................................................................................................................................118
31.6. Acknowledgements – bibliography for Appendix 31.............................................................................118
1. APPENDIX 4: REASONS WHY A DATABASE IS TO BE PREFERRED TO A

SPREADSHEET - SPREADSHEET DOES NOT EQUAL DATABASE..................119
1.1. More Than a List.........................................................................................................................................119
1.2. Create the Database.....................................................................................................................................120
1.3. Create a Data Entry Form..........................................................................................................................122
Page 10 of 150
2. APPENDIX 5: ACCESS HINTS - DESIGNING FOR USE...................................124
2.1. Getting more help........................................................................................................................................124
2.2. Unlocking the power of many-to-many relationships..............................................................................124
2.3. Some difficulties associated with forms and subforms and how to overcome them............................128
2.4. Subform not updated...................................................................................................................................128
2.5. Detail subform does not show the subset of records based on the value of the current master form
record...................................................................................................................................................................130
3. APPENDIX 6: NORMALISATION........................................................................133
3.1. Introduction to Normalisation....................................................................................................................133
3.2. Introduction..................................................................................................................................................133
3.3. Preliminary remarks...................................................................................................................................134
3.4. Terminology.................................................................................................................................................134
3.4.1. Records...................................................................................................................................................134
3.4.2. Field names.............................................................................................................................................134
3.4.3. Keys........................................................................................................................................................134
3.5. The various stages of normalisation..........................................................................................................137

3.5.1. Convert data into unnormalised form (UNF, 0NF)...............................................................................137
3.5.2. Convert UNF into First Normal Form (1NF).........................................................................................137
3.5.3. Convert 1NF into Second normal form (2NF)......................................................................................137
3.5.4. Convert 2NF into Third normal form (3NF).........................................................................................137
3.6. Further normalisation.................................................................................................................................138
3.7. A full example of normalisation.................................................................................................................138

3.7.1. Step 1 - Convert data into UNF..............................................................................................................138
3.7.2. Step 2 - Convert data into 1NF..............................................................................................................139
3.8. Normalisation: A Summary........................................................................................................................141
3.9. Normalisation complements top-down entity-relationship modelling...................................................141
3.10. What is achieved by normalisation?........................................................................................................142
3.11. How is normalisation used in practice?..................................................................................................142
3.12. Still confused?............................................................................................................................................142
3.13. Some questions with which to check your understanding.....................................................................142
4. APPENDIX 7 INSTALLING AND USING MICROSOFT VISIO...........................146

4.1. Introduction..................................................................................................................................................146
4.2. Visualize complex information to better understand it...........................................................................146
4.3. Learning Visio..............................................................................................................................................147

Page 11 of 150
4.4. Creating DFDs using Visio..........................................................................................................................147
4.5. Installing SSADM support..........................................................................................................................147
5. APPENDIX 8 STRUCTURED WALKTHROUGHS, A WAY TO IMPROVE THE

QUALITY OF ANALYSIS.........................................................................................149
5.1. How to seek for perfection! Improving the quality of our work............................................................149
5.2. References for Appendix 8..........................................................................................................................150
Page 12 of 150
1. Introduction: Who is this document for?
1.1. Preface
The booklet aims to help you learn how to design and build applications using Microsoft
Access. This document is written to be read and understood as you are working on your own
design and build experiments.
This Access database design and implementation document is a higher-level self-instruction
booklet; it is assumed that you are already a fairly competent Access user.
If you need to learn how to use Microsoft Access, please see section 1.6 for further advice.
1.2. Skills required

Modern relational database management systems such as Microsoft Access have been
designed to enable users to get as far as is reasonably possible without needing software
design and construction (“programming”) skills. Four basic levels of skill can be recognised
in database use. These are:
♦ LEVEL 1 – Database User
Straightforward data input, amendment and querying, such as
might be undertaken by a clerical or professional worker who is
expected to capture and use data as a small part of their every
day work;
♦ LEVEL 2 – Database Builder
Basic database implementation skills, including design of
simple databases and implementation of the design as a series
of tables, queries and reports; such skills might be anticipated
in a professional worker in an office environment who has
some responsibility for the basic information systems (IS)
needed in that office, but whose primary job responsibility is
not IS-oriented;
♦ LEVEL 3 – Database Administrator
Real database design and implementation competence. You
would expect this in an information systems professional. But
this same higher level of competence may also be found in
certain business-oriented individuals who take a real pride in
using computers to their full potential. Such individuals are
sometimes referred to as power users. The work of such an
individual includes serving the needs of other clerical and
professional office workers by undertaking detailed analysis,
design and implementation work and creating systems usable
by other office workers and business professionals.
♦ LEVEL 4 – Database Professional
Expert user with programming skills.
1.3. The aims of the remainder of this document

The main aim of asking you to work through the remainder of this document is to link the
following topics:
♦ To help you to learn the principles of modelling
information systems in an experiential, problem-oriented way
and not just a theoretical one. (Corresponds to Level 1 above)
♦ If you are aspiring to general competence in business studies:
Page 13 of 150
to give you reasonable skills in the analysis and
construction of effective, albeit small-scale, computerised
business information systems. (Corresponds to Level 2
above)
♦ If you want really to exploit the power of databases and
systems and / or you aspire to the challenge of managing
information systems professionals: To help you reach the
point where you can analyse a user's requirements,
design them a solution, and refine the solution by means
of building a working prototype in MS Access.
(Corresponds to Level 3 above)
♦ If you are a budding IS professional, or wish to become a
systems analyst or consultant: This document is a starting
point only – you will need specific additional training and
experience. (Corresponds to Level 4 above)
Note that material which only applies to Level 3 or above is shown in grey-
background Arial Narrow, like this paragraph.
1.4. The structure of this document and how to use it

This document consists of:
♦ Section 1 – The Principles of Database
∗ Data modelling using ERM
∗ Databases
♦ Section 2 – Using Microsoft Access to build good databases
∗ System implementation using Microsoft Access
♦ Section 3 – The Anytown Distance Learning Business School
example
∗ A fully worked example of the analysis and design of a
system for a virtual enterprise
∗ However, please note that this example does not enter
into the business-oriented aspects of the assignment
you are doing
♦ Appendix 1 Use Case analysis
∗ User interaction modelling using Use Case scenarios
♦ Appendix 2 Data Flow Diagrams
∗ Process modelling using DFD data modelling
♦ Appendix 3 When to use a spreadsheet, and when to use a
database
♦ Appendix 4 Reasons why a database is to be preferred to a
spreadsheet
♦ Appendix 5: Access Hints – Designing for Use
♦ Appendix 6: Normalisation
♦ Appendix 7 Installing and using Microsoft Visio
♦ Appendix 8 Structured Walkthroughs, a way to improve the
Page 14 of 150
quality of your analysis
All readers should start with Section 1. Then read the rest of the document , but ignoring
this kind of text. Later, reread the document including text like this.
1.5. About Learning Access

You should work your way through the following stages:
1.5.1. Starter: the naïve user: Level 1

You should already be at (or perhaps beyond) this stage. If you aren’t – learn how to
use Access now! This Designing and Building Access Database Systems guide
cannot help you to learn these basic skills, which you are assumed already to have –
but may have to acquire, revise and practise them, at the same time as you are
reading this booklet. You’ll find a checklist just below, in section 1.6.
1.5.2. The thinking user: Level 2

The business specialist who nevertheless thinks carefully about how s/he can best
use a computer to help them to get their work done, or who spots a new application
area or ICT-related business opportunity.
Working through this document, and using the facilities of each Office programme
just a little bit more each time, should get you to about this stage.
1.5.3. The competent (“power”) user: Level 3

This is the person who becomes known as the person to whom to talk when no-one
else in the department or office seems to know what to do! This is the person who
has mastered spreadsheets and uses them frequently, and who knows when to use a
database.
1.5.4. Advanced: the programmer or systems integrator: Level

4
Further competence in Access will require you to begin to use the
power of the VBA programming language and to understand SQL.
This subject is beyond the scope of this module, and is NOT
expected in ESC business students.
1.5.5. What is the relevance of MS Access skills?

The main reason for advising business students to learn Access is that it is possible
using Access to build reasonably powerful Information Systems (IS) with a tool
which is reasonably straightforward (if not always easy!). In effect, you are building
a Prototype system using an End User Computing tool. At the same time, you are
consolidating what you have been taught in first and second year modules. All this is
essential if you are to achieve the learning outcomes of the module that you are
studying.
Facility in Access is itself a marketable skill. You should find it much easier to
obtain certain internships or placements as a result of the fact that you know industry
standard software like Access. In addition, Access is a reasonably complete
implementation of the theoretical relational database model originally defined by
Edgar Codd and popularised by many authors (notably, Chris Date—see Date 2003).
Relational databases are a very powerful way to structure data and to be able to get
the information you need as a future manager.
1.6. Testing yourself
Page 15 of 150
In this section, we summarise what we consider to be the basic knowledge and ability you
need to have in Microsoft Access.
The most important first step is to take a first step! Get hold of a copy of Access and start to
use it. As you do so, tick off the various things on the list below. You can start reading this
Designing and Building Access Database Systems guide in parallel, but please understand
that you cannot understand what is in this book without actually testing your practical ability
and knowledge.
1.6.1. What you should already know

We have already revised or introduced the following concepts:
♦ What are Tables?
♦ Designing a Table
♦ Keys: primary and secondary (“foreign”)
♦ Relationships and linking
1.6.2. What you should already be able to do or need now to learn

You should aim at the following practical competences, which you may have
acquired in the first year at ESC Rennes, or which you may now need to learn:
Competence Tick when
you can
do this
Fundamental skills
∗ Starting Access
∗ Creating a database
∗ Creating a Table
∗ Adding Data
∗ Creating a Query
∗ Adding a second table
∗ Linking tables with a relationship –
establishing foreign keys
Forms – basic concepts
∗ Creating a form based on a table using the
form-building assistant / wizard
∗ Changing the design of the form
∗ Adding records using a form
Reports – basic concepts
∗ Creating a report
∗ Creating a report based on a query
Relationships
∗ Creating a relationship between tables
∗ Creating a query which uses linked tables
∗ Forms, sub-forms and their use with one-to-
Page 16 of 150
many (1:M) relationships
∗ Many-to-many relationships and multi-part
primary keys
Forms – more advanced use
∗ Using list and combo boxes
∗ Combo boxes (zones de liste déroulantes)
and subforms (sous-formulaires)
∗ Creating a subform (sous-formulaire)
∗ Inserting a subform into a main form
∗ Subforms of subforms
∗ Adding record navigation buttons
1.6.3.A checklist of more advanced skills

If you are aiming at Level 3 or Level 4 competence, you will need to
achieve:
Competence Tick
when
you can
do this
∗ Competence in update and append
queries
∗ Advanced data validation techniques
∗ Basic competence in Visual Basic
programming
∗ Basic competence in SQL (structured
query language)
∗ Dealing with problematic many-to-
many relationships
1.6.4. Further help on learning to learn

See appendix 1 for a very basic introduction to Microsoft Access, and appendix 31.4
for some suggested websites.
1.7. Conventions Used in this document

Points which are significant only to more advanced users are
indicated like this paragraph.
 VITAL POINTS are indicated like this!

1.8. Limitations
This document is aimed at people who are comparatively new to systems analysis and design,
and who are not aiming to be experts in that field. It therefore aims to be useful and usable
without necessarily being totally complete. Where a conflict exists between being totally
comprehensive (but unnecessarily difficult), and being comprehensible and straightforward,
the second approach is adopted. The aim is to exclude material which is extraneous in the
Page 17 of 150
sense that most business people, and indeed many analysts, do not need to consider it.
Therefore complex issues such as ternary relationships are ignored. Instead, the main issues
are concentrated on and the reader is encouraged to understand them and to apply them.
Once the reader is comfortable with the approach adopted in this document and has
achieved some real competence in database design and implementation, he/she can read
more advanced texts and tackle the more difficult issues. Until then, the slightly simplified
(but never facile) approach adopted in this document is a sensible compromise.
Microsoft Access is very unusual as a database management
package in that it is intended both to be very useful to people who
are new to database, and also to offer the full power of a
programmable system to more advanced users. Microsoft Access
aims to make the gap between intermediate and advanced use as
small as it can be, because it provides both macros and Visual Basic
for Applications (VBA). Macros can be used to automate repetitive
sequences of commands or instructions, such as those needed to
open a form without having first explicitly to open the database
window. VBA is a full programming language, and it can be used for
relatively complex tasks such as advanced field validation, and also
for dealing with anticipated errors and automatically recovering
from them. VBA is a programming language which is based on
Microsoft's Visual Basic system. In Office 97 and beyond, the same
VBA language is used in all the major Microsoft applications, Word,
Excel and Access.
Although this document does not assume familiarity with Visual
Basic, certain more advanced uses of Access do require awareness
of such Visual Basic concepts as functions (sub programs which
return a result) and many more advanced features of Access –
things like validation rules - use Visual Basic syntax.
Business students should NOT normally attempt to master the VBA
programming language.
However, at certain points in this document, VBA is used to illustrate
more advanced techniques.
1.9. Acknowledgements
I should like to thank:
♦ Former Huddersfield colleagues Dr. Steve Wade and Dr. Ken
Lunn
♦ ESC Rennes colleagues, notably Dr. Renaud Macgilchrist
♦ Previous ESC Rennes students
The following students gave me permission to reuse parts of their excellent
work on the Anytown Business School group case. I have incorporated this
case as a worked example in this document, and made significant use of
these students’ work:
Marine CORRE; Marie GALATAUD; Emmanuelle HAMEURY;
Naïla MALTI
Page 18 of 150
SECTION 1 - THE PRINCIPLES OF DATABASE
2. A brief introduction to databases
2.1. Databases (bases de données) and how they are designed

In this chapter, we give consideration to databases: what they are, to some extent how they
are used, and to a limited extent how they are designed.
The subject matter here involves a specialised vocabulary, and a degree of complexity. Many
of the ideas surrounding database are on first encounter quite strange, but they quickly
become intuitive if you combine a study of the theory of database with an attempt to make
them work in practice. So: stick with that approach, learn a little then try it out!
2.2. Models used by systems analysts

These are examples only!
♦ Interaction models
∗ UCDs (Use Case Diagrams)
♦ Process models
∗ DFDs (Data Flow Diagrams)
♦ Data models
∗ ERA (Entity Relationship Attribute diagram)
2.3. Simple model of data processing
Data
Sourc Data Processing Recipien
e System t
Information
Store Retrieve
Data Data
Database
This diagram, which shows the structure of a data processing system (a synonym for business
information system), highlights the central importance of the database as the place where
data is stored and from which it is retrieved.
Page 19 of 150
2.4. Why study Databases?
2.4.1. They are used in every significant BIS

♦ Store details of orders, customers etc.
♦ Support product catalogue in B2C applications
2.4.2. They are at the heart of

♦ “Database marketing”
♦ CRM – customer relationship management
♦ ERP – enterprise resource planning
2.5. Background
Some understanding of what a database is, how it is used, and (to a greater or lesser extent)
how databases are designed is essential to understanding electronic business.
Businesses are systems; they use Information Systems, which are based on Information and
Communications Technology.
Example: any e-commerce company provides a Web window onto its internal catalogue:
which is a web page connected to a database.
Every stakeholder needs information from the business. They generally obtain this as
information presented on forms (screens), reports and dynamic web-pages (webpages which
show the current contents of a database and permit stockholders to update that database).
2.6. How to store data

♦ Data is stored in tables: 2-dimensional structures
♦ In MS Office terms:
∗ Word tables (also PowerPoint)
∗ Excel worksheets
∗ Access tables
♦ The 2-dimensional table which follows was created in Word
Relative strengths and weaknesses of Word, Excel and Access for storing data
Method Advantages Disadvantages
Word Simple, well understood by people with weak computing skills No formulae (or only very
Processing: e.g. rudimentary ones)
Word
Excellent formatting options Tables are not related in any
way Can only be updated by one
person at a time. The data in a
table has no “structure” known to
the computer.
Spreadsheet: e.g. Some degree of structure – cells organised into rows and Persistent data is not safe.
Excel columns, with links possible between the cells
Very powerful data manipulation using formulae Size limits – 65535 rows (until
Office 2007).
Separate tables can be held in different worksheets No design methodology or
coherence – it is possible and
easy to mix data up in a way
which makes it impossible to
Page 20 of 150
find, update and relate.
Items of data can be related together using lookup formulae such Poor support for queries –
as VLOOKUP (RECHERCHEV) and HLOOKUP searching is slow, and the lookup
(RECHERCHEH) formulae are far from being
intuitive.
Can only be updated by one
person at a time
Database: e.g. Each kind of data is stored by the database management system More difficult to use and to learn
Access (DBMS) in its own separate table. The tables are related together (at first)
in accordance with the Relational data model – this gives
coherence to the collection of tables, which is the whole database
Very powerful data structuring and querying. In fact a query is Requires thoughtful use and
just a results table which combines together selected data from advance planning
more than one stored table. The database program enables the
user to say what data they need and they construct a query which
precisely specifies what data is to be retrieved into the results
table
Safer persistent data (though less safe than bigger, more powerful Access databases are not directly
DBMS programs like Microsoft SQL Server, ORACLE etc) web-accessible
Is multi-user: that is, more than one person at a time can change
(update) the database
Since every record in a table has the same basic structure, it is But the programming language
much easier and / or more cost-effective to process complete sets within Access, VBA, is too
of records under program control difficult and / or inappropriate
for most business users to learn.
Figure 1 Comparative strengths and weaknesses of data storage in two dimensional tables:
Microsoft Office tools
2.7. What is a database?

♦ A linked collection of tables (tables)
♦ Each table containing data about a single kind of thing
♦ Data in the separate tables can be combined ("joined") to
answer user needs for information
2.8. Why keep data in different tables?

♦ Company A uses a single table named orders to record orders
they receive, while Company B uses a relational database with
two tables: orders and customers.
♦ When a customer places an order with Company A, a new
record (or row) in the table orders is created.
♦ Because Company A has only one table of data, all the
information pertaining to that order must be put into a single
record: the customer’s general information, such as name and
address, is stored in the same record as the order information,
such as product description, quantity, and price. If customers
place more than one order, their general information will need
to be re-entered and thus duplicated for each order they place.
Page 21 of 150
Order Customer name Customer Product Product Unit Price Quantit Amount
number address code description of per unit y
sale
O001 GREGORY Mark 1 La Rue P001 Apples kg 0,80 € 2,5 2,00 €
O002 GREGORY Mark 1 La Rue P876 Oranges kg 0,90 € 1 0,90 €
O003 MACGILCHRIST 1 La Croix P001 Apples kg 0,80 € 3 2,40 €
Renaud Mistype
O004 GREGORY Mark 1 La Rue P001 Apples kg d €
0,80 2 1,60 €
O005 MACGILCHRIST 1 La Croix P876 Oranges kg address
1,05 € 1,5 1,58 €
Renaud
O006 GREGORY Mark 11 La Rue P001 Apples kg 0,90 € 2 1,80 €
O007 GOT Guillaume 1 L’Avenue P001 Apples kg 0,90 € 3 2,70 €
O008 GREGORY Mark 99 Le Chemin P876 Oranges kg 0,90 € 1,5 1,35 €
Changed
address
♦ Whenever there is duplicate data, as in the case above, many

inconsistencies may arise when users try to query the
database. Additionally, a customer’s change of address might
require the database manager to find all records in orders that
the customer placed, and change the address data for each
one.
♦ Company B is much better off with its relational database.
Each of its customers has one and only one record of general
information stored in the table customers. Each customer’s
record is identified by a unique customer code which will serve
as the relational key. When a customer orders from Company
B, the record in orders need contain only a reference to the
customer’s code, because all of the customer’s general
information is already stored in customers.
♦ Indeed, Company B might go further and introduce a product
table. It then has:
∗ CUSTOMER table
Customer Customer name Customer
number address
C001 GREGORY Mark 1 La Rue
C002 MACGILCHRIST 1 La Croix
Renaud
C003 GOT Guillaume 1 L'Avenue
∗
Page 22 of 150
∗ PRODUCT table Price
p
unit i er
Product Product Unit of sale Standard s on
bot h t
code description price per a
One i bles!
unit s
stand
a
P001 Apples kg 0,80 € other rd, the
P876 Oranges kg 0,90 € order
specif -
ic.
∗ ORDER table
Order Customer Product Actual Quantity Amount
number number code price per
unit
O001 C001 P001 0,80 € 2,5 2,00 €
O002 C001 P876 0,90 € 1 0,90 €
O003 C002 P001 0,80 € 3 2,40 €
O004 C001 P001 0,80 € 2 1,60 €
O005 C002 P876 1,05 € 1,5 1,58 €
O006 C001 P001 0,90 € 2 1,80 €
O007 C003 P001 0,90 € 3 2,70 €
O008 C001 P876 0,90 € 1,5 1,35 €
♦ This still isn’t perfect, since Orders and their Details continue to
be mixed together in one table. 1
2.9. Learning a minimum about database

Every business student needs to know about and understand:
♦ Database principles
∗ Tables
∗ Queries
∗ A query is a results table
♦ Introduction to database design
♦ How to use a sample database
♦ How databases are used - ERP, CRM etc.
2.10. Basic concepts

♦ Entity: class of thing about which data is stored
Examples: student; programme – these are tables of data.
♦ Occurrence: a single instance of an entity
Example: ETU2004987 Smith, John – this is one record in the table of
data.
♦ Attribute: a single fact that describes, qualifies or is otherwise
a property of an entity
Example: Programme name, value for John Smith: MA International
Business
♦ Key: attribute(s) which uniquely identify a single occurrence of
an entity
Example: student number uniquely identifies a Student
1
The solution here includes the introduction of a link or intersection entity, called Order
Detail. See section 2.20 for a general description of what must be done.
Page 23 of 150
♦ Relationship: a logical connection or dependency between
two entities
Example: any one programme has many students; any one student is on
precisely one programme: we say that a one to many relationship exists
between programme and student
2.11. Entity (type, class)

An entity represents a class of objects, usually in the real world. Synonyms for entity include
class and type.
♦ Entities are of importance to the area of business being
investigated
♦ They are objects about which data is stored
♦ Represented as boxes on an Entity Relationship Model (ERM)
♦ Examples:
∗ Student
∗ Programme
An entity has a number of different data attributes or properties, that is, facts about the thing.
For example a student will have a student number, a last name, a first name, and a
programme code. A programme will have a programme code, name and programme leader.
Page 24 of 150
2.12. An example: Students by Programme
Entity relationship
Sample data
diagram
Programme code Programme name LMD Leader

Programme level
PGE Programme Grande M RIVET
PK Programme code École Philippe
EMBA Executive MBA M MINDAY
Don
Programme name
LMD level
Leader
Student no Surname Forenames Programme

code
20099234 Leuchars Annabelle EMBA
Student 20099235 Dromsky Pierre-Charles PGE
20099897 Mozart Anne-Marie PGE

PK Student no
In the diagram, the two rectangular boxes represent entity types. Here, they are programme
and student.Surname
They are represented as different entity types because they represent different
things in the real world. At least in theory, a programme could exist without any students.
Forenames
Almost by definition, a student is on a programme of some kind, but it is clear that
programme and student are notcode
FK1 Programme the same things. It is equally clear that they are related. The
diagram represents this relationship by using a line with a crow's foot at one end of it. The
end of the crow's foot represents the many end of a one to many relationship, often
represented simply as 1: M
It is necessary to have an additional attribute on the student which links the student to its
owning programme. On the sample data provided with the diagram, we have shown
Annabelle Leuchars as being a student on the Executive MBA, by including the Programme
code in the Student table. Programme code is a foreign key, which links the Student back to
her Programme.
2.13. Attribute
An attribute is a Property of an entity, a single fact about the entity. An entity type will
normally have several different attributes, one (or occasionally more) of which uniquely
identifies every instance of the entity type. The identifying attribute or group of attributes is
called for the primary key for the entity type.
The Attributes of Programme are Programme Code (primary key), Programme Name, and
Programme leader
The Attributes of Student are Number (primary key), First name, Last name, Programme
Code (foreign key)
Programme code has to be present as a foreign key in the student entity in order to represent
the relationship which exists between programme and student.
2.14. Primary and Foreign Keys

Page 25 of 150
♦ Primary key is an attribute or combination of attributes which
uniquely identifies an entity occurrence
♦ To make a link between the Many (child) end of a relationship
and its One (parent) end, the Primary key of the One end is
repeated in the Many end
♦ In the Many entity, it is known as the Foreign Key
♦ What are Foreign Keys? A foreign key is an attribute that
completes a relationship by identifying the parent entity.
Foreign keys provide a method for maintaining integrity
(coherence, consistency) in the data. Every relationship in the
data model must be supported by a foreign key.
♦ Identifying Foreign Keys: Every dependent and subtype entity
in the data model must have a foreign key for each relationship
in which it participates. Foreign keys are formed in dependent
and subtype entities by migrating the entire primary key from
the parent entity.
2.15. Why have foreign keys?

♦ One particular programme has many students on it. That group
of students (we call the group an entity type or table or set –
the words are synonyms) is defined by having the same
programme code
♦ The programme code of programme is of course the Primary
key
♦ It is also, in the student table, the Foreign key which links each
student to the programme of which s/he is a part
♦ Remember that the foreign key repeats at the many end, the
primary key of the one end of the one to many relationship.
This is essential if the database management software is to be
able to link back together the students on a given programme,
or to look up the details of the programme for a given student.
2.16. Entity occurrences – student

Having decided the general attributes of an entity type, it is then possible to store records
relating to occurrences of the entity, typically in the real world. So, in the example above,
details of three students are given, two on one programme, one on another.
2.17. Entity occurrences – programme

In the example above, details of two programmes are given.
2.18. Queries
The purpose of a database is to enable users to get the specific information they need. This
can be done using queries. Queries are both useful in themselves, and also are used as the
basis for reports and for forms.
♦ To answer a question like: who is programme leader for a
given student? We can get all the necessary information by a
query on both tables - programme and student
♦ Note that the name of the programme leader should be an
Page 26 of 150
attribute of programme, and definitely NOT of student!
To answer a question like: who is programme leader for a given student? we can get all the
necessary information by a query on both tables - programme and student. This is the work of
the relational database management system software (RDBMS). A user of the database
formulates a query, and the RDBMS goes away to look up details of occurrences in both
entity types, joining the answers together as a result presented to the user.
2.19. Students and Modules
Module Student
In this diagram, the two rectangular boxes represent entity types. Here, they are Module and
Student. The relationship is Many-to-Many. The diagram represents this relationship by using
a line with a crow's foot at both ends of it. The end of the crow's foot represents the many end
of the many to many relationship, often represented simply as M:M or M:N
This model reflects the empirical observations that:
1. Any one student studies many modules
2. Any one module has many students
Many-to-Many relationships are very common. They are also problematical – this is because
actual database management systems like Access (and almost all others) cannot support
Many-to-Many relationships directly.
However, by following simple rules, it is possible to eliminate many-to-many relationships.
2.20. Three Vital Rules

1. An attribute can only hold a single fact
∗ If the name of an attribute is a list (e.g. something in
the plural, like Student Qualifications) this is a sign that
another entity is needed
2. The Primary key of the One end of a One to Many relationship also
appears as a foreign key in the Many end
3. A Many to Many relationship can be resolved into two One to Many
relationships, both going to a Link (or Intersection) entity type
These are Rules – there is no need to question them, just to apply them!
2.21. Resolving Many-to-Many Relationships
Page 27 of 150
Resolv
♦
♦
Relatio
The many-to-many relationship is removed by:
♦ Introducing a link or intersection entity
Drawing 1-to-many links FROM each original entity TO the new
one
∗ Note that the primary key of EACH parent entity
becomes part of the COMPOUND primary key of the
link entity
Here, the primary key of Module is Module Code, and that of
Student is Student No. Both become the compound primary
key of the Registration entity
Module
PK Module code
Module name Module code Student no Module result

Module leader IS402E 20099234 A
Module Registration
IS402E 20099235 B
IS402E 20099897 C
PK,FK1 Module code
OB401E 20099234 Fx
Module
PK,FK2 Student no
Module result
Student
PK Student no
Page 28 of 150
Surname
Forenames
♦ Note that there is only one primary key, made up of two
attributes
∗ Neither Module code nor Student no are unique in the
Module registration table – but the combination is
unique
Unless a student is allowed to do a module a second time, in
which case it is necessary to add a further attribute, usually a date,
to the compound primary key in order to make it unique again:
Module code Student no Date Module result
IS402E 20099234 2009 A
IS402E 20099235 2009 B
IS402E 20099897 2009 C
OB401E 20099234 2009 Fx
OB401E 20099234 2010 E
Page 29 of 150
2.22. Towards a more complete entity relationship attribute model
As analysis proceeds, the model is gradually refined and improved. Still incomplete, it might
look like this:
Programme Qualification
PK Programme code PK Qualification
Programme name
LMD level
Programme leader surname
Programme leader forenames
Student
PK Student no Award
PK,FK1 Qualification
Student surname PK,FK2 Student no
Student forenames
FK1 Programme code Award result
Student gender
Student birthdate
Module Registra
PK,FK1 Module code

PK,FK1 Module year
PK,FK2 Student no
Module grade
Module mark
Module Operation
PK,FK1
Note that this model has introduced a number Module code
of changes:
♦ PK
There is greater precision in Module yearnames
the attribute semester
chosen
♦ We wish to record a student’sModule
qualifications,
leader so we have
introduced Qualification
♦ Because a many-to many relationship exists between student
and qualification, an intermediate (link) entity has been
Page 30 of 150
Module
PK Module code
introduced; we observe that in the real world a specific award
is give to each student who qualifies in something, so we’ve
called the link entity Award
♦ We observe that many modules are offered and “run” (that is,
they occur and are taught) for several years in succession (and
sometimes in more than one semester in a year), and further
that in some cases students take a module one year, fail it,
and do it again in a subsequent year; therefore we introduce a
Module Operation, the run of a module in a given year and
semester
♦ The model remains incomplete but it’s now good enough to be
worth prototyping (building and testing) in Access – so that we
can check that it meets our needs for storing data and (above
all) retrieving information in a very flexible way
2.23. Example Query – definition

Suppose we want to show a list of the students and the programme they are on, in ascending
order of student last name. The slide is a screen shot indicating how this query is constructed
in the Microsoft Access RDBMS.
I created it using the query design wizard (assistant) in Access. In the simple query wizard, I
specified fields from the student table and from the programme table which I wished to
appear in the result. Here, I wanted a list of students with details of the programme they are
following. The screen shot shows the resulting query: it indicates that there are two tables
which are joined together in the preparation of the result, and it also indicates which fields
take part in the result.
2.24. Example Query – results

This slide shows the results of running (executing) the query. The results of the query have
the form of a table, in which the columns are the attributes from the participating tables and
the rows are the result records.
Page 31 of 150
How has Access created this result? Probably something like this: it reads each record in the
student table. One of the attributes of student is the programme code. Programme code is the
foreign key in the student table; it is also the primary key in the programme table. Access
looks up the details from the programme corresponding to the programme code for each
student record. In effect, it joins together the two tables on the basis of the linking foreign
key.
2.25. What is a query?

(French ‘une requête’)
♦ A query is a response to a question formulated by a user of the
database
♦ A query takes the form of a table, in this case, a results table
∗ Technically, data tables are sets or relations
∗ So are the results of a query
♦ The power of a relational database is that it treats all stored
data and derived information as what mathematicians call sets
(sometimes called relations)
∗ Therefore database software is “simply” a computerised
implementation of mathematical set manipulation
2.26. Data Dictionary

A store of data about data, a dictionary is a database used by analysts, programmers etc. or by
you as you design a database. I find it useful to use a spreadsheet for this purpose, and you
will find an example dictionary implemented as a spreadsheet for the Anytown case later in
this document.
2.27. Entity-Relationship Diagrams (ERD)

Entity-Relationship Diagrams show:
♦ Entity types = the kind of things data is collected about in the
database
∗ Entities = the specific things data is collected about
♦ Relationship = the way specific entities of one type are related
to specific entities of the other type
♦ Attributes = the specific data items of interest stored for each
entity type
♦ ERDs help determine what kinds of data will be included in a
database, and how the database will be structured
♦ They are an excellent communication medium between users
and developers
2.28. Another example database: NorthWind / Les Comptoirs

Page 32 of 150
♦ Provided with Microsoft Access – usually to be found under
help menu, Sample databases. It includes table like:
∗ Product
∗ Order
∗ Customer
∗ Supplier
∗ Purchase order
The screen-shot shows a slightly-improved version of NorthWind.
2.29. Relationship: meaning and characteristics

♦ A link between entities which is significant for this type of
system
♦ Degree of relationship
♦ Optionality: does this relationship have to hold?
♦ Name: link phrase
E.g. Customer places orders.
∗ Two names?
A relationship can be named in either of two directions, depending
on which entity you start from. Thus:
(i) Customer places orders
(ii) Orders are placed by customers
Page 33 of 150
2.30. Why it’s important to relate entities
Construction of the query in the previous example was eased because a proper design process
had been undertaken in order to determine what entity types would be represented in the
database, and how they would be related. This design process resulted in the simple entity
relationship model presented in section 2.22. A line was used to link the two entity boxes
together; this line had a crow's foot at the many end of the one to many relationship which
analysis indicated exists between programme and student.
So one of the most important results of analysis is to establish what entity types are, and how
they are related. Relationships are links between entities which are significant for this type of
information and which are normally true in reality. A relationship can have a name: actually,
it can have two, one read from one end of the link, the other from the other end. In the earlier
example of Student and Programme, we can recognise two relationships - "student is on
programme" and "programme enrols student". The relationship is said to have a degree of
1:M, which can be read one to many. In this case, the relationship is said to be mandatory:
that is to say, a student is not a student if they are not on a programme, and a programme is
not a programme if it has no students. (The second assertion may not always be the case, and
it is possible to represent a relationship as being optional from one or both ends.)
2.31. Degree of relationship (simplified)

The degree of a relationship is an indication at the end being considered of whether more
than one occurrence can be associated with one entity occurrence at the other
♦ There are three basic possibilities:
∗ One to one: 1:1
∗ One to many: 1:M
∗ Many to many: M:N
For more information concerning the degree of a relationship, please see 3.5.4
2.32. Simple database design

Design means deciding:
♦ What are the main entities?
♦ What are the attributes of each entity?
∗ What is the data type of each attribute?
∗ Validation rules
♦ Keys: primary and “foreign”
Before building, for example, a Microsoft Access database, it is essential to carry out at least
some database design. These are the main points that have got to be addressed in even the
most informal design exercise.
The aim is to identify all the main entities and to give them the appropriate attributes.
Having done that, consideration has to be given to the kind of data which each attribute will
actually hold. Broadly speaking, the type of data is either numeric, text or something more
special-purpose like a date. If text, consideration has to be given to the maximum number of
characters that can be stored. Data which appears to be numeric may not in fact be so:
telephone numbers, for example, must be stored as text, as indeed should code numbers like
student numbers.
Note the usefulness of a simple data dictionary here. If you decide that a customer number is
to be five letters (as it is in NorthWind), then it needs to be five letters everywhere it is used.
You record that decision in the data dictionary.
Page 34 of 150
It is absolutely critical to identify the primary key for each entity type, and to ensure that
there is a foreign key at the many end of any one to many relationship which is discovered
as you think about how the entity types are related.
3. A Simple Methodology for Designing Microsoft Access

Databases
A methodology is a coherent set of methods, linked by a common underlying philosophy. The
methodology I suggest for designing and building access databases is described in this section, and
elaborated on in the remainder of this document. Some of the specific methods are derived from the
British SSADM, Structured Systems Analysis and Design Methodology; and one UML2 technique,
that of Use Case analysis, is employed. However, the Simple Methodology presented here is greatly
simplified to make it more appropriate to business use.
3.1. Introduction – background to the methodology
3.1.1.Database, or something else?

As the writer of the biblical book Ecclesiastes wrote nearly three millennia ago,
"There is nothing new under the sun"! Whatever, it is certainly the case that most
standard information handling problems encountered in business are common to
more than one business. It is therefore very likely that you will be able to find a
system which has been written for someone else but which is (more or less) directly
applicable to an information systems requirement you are analysing. If you can find
a packaged solution which is (more or less) applicable to your company or to a
client whom you are advising, then you can save yourself a lot of effort and the
client a lot of money.
But what if there is no such package, or if it really doesn't suit the needs of the client
/ user?
A Database may be, and often is, appropriate in many contexts - but still consider
alternatives, such as spreadsheets, for more straightforward or small-scale work, or
where system users are already highly familiar with spreadsheets.
Spreadsheets are great in some contexts, and there is immense power in advanced
spreadsheet packages like Microsoft Excel and Lotus 1-2-3. 3 And as we will begin
to see as we become more knowledgeable about information systems modelling and
more experienced in our use of relational databases, there are deficiencies also in the
relational database approach. For this reason, newer techniques such as object
oriented systems analysis and design are beginning to be used by IS/IT professionals.
But for now, what you must do is work hard to get familiar with systems analysis
using the structured approach, and database design using the relational approach.
3.1.2. What is a methodology?

A methodology is a set of methods for tackling a particular class of problem; the
methods should be linked by a coherent philosophy and be consistent with one
another. Formal (mathematical) and semi-formal (strictly defined) methodologies
have been defined for the analysis, design and construction of information systems.
However, they are often too rigid, too prescriptive or quite simply too long-winded
to be useful for people who are still learning the basics of the craft and who are
tackling relatively small problems. The approach adopted in the rest of this
document is methodical, but does NOT follow any one specific methodology;
instead, it follows a simplified methodology of my own. 4 So, if you think a full-
2
UML is the Unified Modelling Language, a set of notations largely used by information systems
professionals and particularly associated with a style of programming called Object Oriented or OO. The only
UML notation we employ in this module is the Use Case diagram, UCD.
3
However, it is a serious error to use a spreadsheet when a database is necessary. Please see appendices 31
and 1 for a discussion of reasons why a database is often superior to a spreadsheet.
Page 35 of 150
blown database is appropriate, you need to consider the steps outlined in the main
parts of this section, many of them associated with a particular method. 5
3.1.3.Assumptions
The approach described in this document is applicable only to relatively small
applications: such as proof-of-concept prototype systems or perhaps end user
computing systems. So:
∗ The requirement is relatively small scale
E.g. the specific needs of the department in which you work; or
(part or all) of a small business
∗ A prototype (and perhaps target system) can be
implemented using Microsoft Access or a similar end-
user orientated database
Even if it’s too large for Access, people often create an initial (or
“prototype”) system in Microsoft Access. This is then used to
establish the complete requirements for an eventual full, or
“target” system. Or the target system may be sufficiently small to
be realisable using Microsoft Access.
∗ You are acting as the Analyst or System Designer
This document exists to help people design an effective database
application. In business, it is normal to distinguish between those
who use a system, the so-called users, and those who analyse,
design and implement a system – the developers.
This document treats you throughout as though you were acting in
the developer role.
What if you are the user as well as the developer?
Then you are in the situation sometimes described as end user
development, where a business person or student develops a
system for their own use and perhaps also for the use of other
members of their team or department.
Wherever possible, get someone else – e.g. a member of your
team – to act in the role of a true system user. Their perspective
may be different but also complementary.
3.1.4. Introduction to modelling business information systems:

why we have chosen certain techniques
♦ Business situations and how to model them
Business information systems Our preferred modelling
have several overlapping technique for each of these
aspects: “views”:
The situations and decisions that Usage models – Use Case
influence the system Diagrams
The processes through which Process models – Data Flow
4
Some of the techniques I use are borrowed from the UK standard SSADM (Structured Systems Analysis and
Design Methodology); the French equivalent is MERISE (see, for example,
http://www.commentcamarche.net/merise/concintro.php3). Nevertheless, these methodologies in their full
form are far too complex to be used by business people unaided.
5
Please note that what follows does not directly correspond to the structure of the assignment that you have to
undertake, but that there are close parallels.
Page 36 of 150
information flows through system Diagrams
Taking account of the life cycles of
information
The manner in which data and Data models - ERA Diagrams
information is organised (Entity Relationship Attribute
diagram)
3.1.5. What we’re trying to achieve together

♦ Three viewpoints - Trois cas de figure
∗ You need a system and you want someone else to
build it for you
Then you need to know how to specify what you need

∗ You need a system and you have to build it yourself
Then you need to know how to analyse and build what you
need
∗ You’re an entrepreneur and you want to build a
business
So: along with your business, marketing, organisational, etc.

strategies: you need a systems strategy and process and data
models
∗ In every case – YOU have work to do!
3.1.6. Business Process Modelling: Documenting a Business Process

♦ Is itself a business process that involves naming business
processes and subdividing them into their basic elements
∗ Helps clarify the problem the information system
attempts to solve – requirements analysis
∗ Can later be used as program specifications
♦ Business Process Modelling is a hot topic associated with
quality management
♦ Business Process Reengineering (BPR) = the complete
redesign of a business process using ICT
3.1.7. Why have we chosen the techniques we have?

♦ Entity relationship attribute model
The ER model maps directly to tables and fields in commonly-used
database management systems. It is much less complex than classes, the
parallel in the more-recent but (very technical) object oriented (OO)
approach.
♦ Use case model
This technique is intended specifically for use with business users, and it is
reasonably visual. It is therefore a very good basis for a dialogue between
you as system users and IS professionals.
Page 37 of 150
♦ Dataflow diagrams
This technique is intended specifically for use with business users, and it is
reasonably visual. It also breaks large problems down into smaller, more-
manageable ones. It is therefore a very good basis for a dialogue between
you as system users and IS professionals.
3.1.8. Business Process Modelling

It has long been recognised that there is a need for a
fundamental and high-level analysis of the business's
processes. In fact, in early strategic information systems
planning exercises, it was not uncommon to seek to do a data
flow diagram and an entity relationship model for a complete
organisation. However, these tools may be too low-level when
all that is required is to identify potential systems
requirements.
More recently, specific business process modelling techniques
have been developed. The approach which is gaining favour
currently is that of the Business Process Management
Initiative. See http://www.bpmi.org/ (checked 24/11/2008)
This approach, though of great interest, is outside the scope
of this document. Instead, the assumption is that a single
business process is being “computerised”, that is, supported
by a new computer-based information system.
3.1.9. SSADM
SSADM itself is less widely used than once it was but remains
important, not least because it is relatively easy for business
people to understand when compared with more modern
techniques.
For a good worked example of all SSADM techniques, please
see http://www.systemsanalysis.org.uk/ accessed 24/11/2008.
Wikipedia (accessed 26/02/2008) has a useful summary of SSADM (Structured
Systems Analysis and Design Methodology):
http://en.wikipedia.org/wiki/Structured%20Systems%20Analysis
%20and%20Design%20Method
The following material was found at http://www.edrawsoft.com/SSADM.php
accessed 03/01/2009.
♦ Introduction - Structured Systems Analysis and Design
Methodology (SSADM)
SSADM (Structured Systems Analysis and Design Method) is
another method dealing with information systems design. It was
developed in the UK by CCT (Central Computer and
Telecommunications Agency) in the early 1980's. It is the UK
government's standard method for carrying out the systems
analysis and design stages of an information technology project.
SSADM has been traditionally used for the development of medium
or large systems. However, one variant of SSADM is 'Micro SSADM'
which is for small systems. SSADM starts from defining the
information system strategy and then develops a feasibility study
module. These are followed by requirements analysis, requirements
Page 38 of 150
specification, logical system specification and a final physical
system design.
♦ Structured Systems Analysis and Design Methodology
(SSADM) Stages
SSADM consists of 5 main stages (which are broken-down in several
sub-stages). The 5 main stages are:
♦ Feasibility Study
The Feasibility Study involves a high level analysis of a
business area to determine whether it’s feasible to develop
a particular system. Data Flow Modelling and (high-level)
Logical Data Modelling can be used as technique during this
stage.
♦ Requirements Analysis
In the Requirements Analysis stage requirements are
identified and the current business environment is
modelled, business system options are produced and
presented. One of these options will be chosen then refined.
Data Flow Modelling and Logical Data Modelling can be used
as technique during this stage.
♦ Requirements Specification
In the Requirements Specification the functional and non-
functional requirements are specified as a result of the
previous stage. Data Flow Modelling, Logical Data Modelling
and Entity Event Modelling can be used as technique during
this stage.
♦ Logical System Specification
In the Logical System Specification the development and
implementation environment are specified, and the logical
design of update and enquiry processing and system
dialogues are carried out.
♦ Physical Design
During the Physical Design the logical system specification
and technical specification are used to create a physical
design and a set program specifications.
♦ Applicability of SSADM
Unlike rapid application development, which conducts steps in
parallel, SSADM builds each step on the work that was prescribed in
the previous step with no deviation from the model. Because of the
rigid structure of the methodology, SSADM is praised for its control
over projects and its ability to develop better quality systems. Most
current developers find it too onerous in its application, however.
3.1.10. MERISE
This is a French equivalent to SSADM.
See, for example,
http://www.commentcamarche.net/merise/concintro.php3 accessed
24/11/2008.
3.2. Feasibility study

Page 39 of 150
Research the basic situation and write up a natural-language description of the scenario. Go
on to describe the purpose of the database, who will use it; why; and for storing what kind of
data
♦ Include a list of the basic, obvious system requirements (things
the system must do) as enunciated by its users or their
representatives
♦ Set out the basic constraints – budget, timescale, existing
systems, etc.
♦ Can the user afford the hardware, software, development effort
and training required to implement the system?
♦ Do the benefits (financial and other) exceed the costs?
♦ Is there sufficient time to build a system in this way, or will the
user have to make do with a bought-in package?
The result of a feasibility study is usually a Go / No-Go decision, with the go sometimes
given to a proposal whose scope is more limited than the original idea.
3.3. Set out Project Terms of Reference

The terms of reference for a project are an agreement between the client for a project and the
people responsible for carrying out the project. The terms of reference describe the context
and scope of the project, identify the client, implementers and project management approach,
and set out the overall timetable for the project.
3.4. Analyse the needs of users

The next step is a thorough analysis of user requirements.
You might use Use Case diagrams (see also Appendix 29) and Data Flow Diagrams (see also
Appendix 30) for this purpose:
3.4.1. Identify business processes using a high-level Use Case

diagram
This should be done for a whole area of business, not just the part which you intend
to computerise. The purpose of this step is to ensure that you have a good idea of
what is, and is not, in the scope of a particular process to be computerised. This can
be done using a high-level Use Case diagram; the technique is described in
Appendix 29.
3.4.2. Identify detailed requirements for a process to be computerised:

carry out Process Modelling
This is done using Data Flow Diagrams, which can be used in an iterative, refining
fashion both to understand the needs of users better, and to improve on the existing
situation with models of a better, computerised, solution.
The elements of a Data Flow Diagram (DFD) are:
♦ External entities
These are people and/or systems outside the scope of the system being
modelled. They may also indicate required entities in the subsequent data
model.
♦ Processes
These are business activities within the scope of the system being
modelled, which process things and data in order to carry out an activity of
value to the business.
Page 40 of 150
♦ Data stores
Which also indicate required entities in the subsequent Data Model.
♦ Flows
DFDs are intended to identify flows of data.
For a tutorial on DFDs, see http://www.cems.uwe.ac.uk/~tdrewry/dfds.htm checked
24/11/2008.
Appendix 30 describes the technique.
3.5. Decide the purpose and basic contents of the database –

Data Modelling
The approach adopted here is to develop an Entity Relationship (Attribute) [ER; ERA] model
(after the method first proposed by Peter Chen, 1976).
What data has to be stored? And how is it related?
3.5.1. Basic Constructs of ER Modelling

The ER model views the real world as a construct of entities and association
between entities.
3.5.2. Deciding entity types

♦ An entity type is a class of real-world thing of which there is
(usually) more than one occurrence
♦ Its name is a noun or noun-phrase
♦ As an initial indication: in a natural language description of the
scenario, underline the names of things which occur more than
once in the real world
♦ Look for “persistence” - longevity, ongoing significance
♦ Do not include reports - this is output information, we are
looking for the structure of the underlying data
Invoices may be stored as an entity type. However, in my view, an Invoice
is a report which is created at a specific moment in order to seek payment
from a customer. It can therefore be argued that there is no need to store its
details in the database.
♦ Do not include "calculated" items as attributes
For example, it is usually wrong to store calculated per-ordered-item costs
in a specific attribute such as amount, when these can quickly be calculated
as (quantity * unit price) at the time of use of a query or report.
♦ “Rationalise” (merge, remove) irrelevant entities
♦ It isn’t always clear when something is an attribute of
something else, or an entity type in its own right; however, an
attribute should never be a list – if it is, this indicates another
entity
3.5.3. Entities6
Entities are the principal data object about which information is to be collected.
Entities are usually recognizable concepts, either concrete or abstract, such as
6
This material was in part found at http://www.edrawsoft.com/datamodel.php checked 18/10/2009.
Page 41 of 150
person, places, things, or events which have relevance to the database. Some specific
examples of entities are Employees and Projects. An entity is analogous to a table in
the relational model.
Entities can be classified as independent or dependent (in some
methodologies, the terms used are strong and weak,
respectively). An independent entity is one that does not rely on
another for identification. A dependent entity is one that relies on
another for identification.
An entity occurrence (also called an instance) is an individual occurrence of an
entity. An occurrence is analogous to a row in the relational model.
♦ Special Entity Types
∗ Associative entities (also known as link or intersection
entities) are entities used to associate two or more
entities in order to reconcile a many-to-many
relationship.
∗ Subtypes entities are used in generalisation hierarchies
to represent a subset of instances of their parent entity,
called the supertype, but which have attributes or
relationships that apply only to the subset.
An example is B2B Customer, a specialisation of Customer. The
Customer entity has the main attributes. A B2B entity then has
additional attributes specific to B2B, for example, credit
arrangements or contact details. Customer and B2B customer have
a one to one relationship.
Associative entities and generalisation hierarchies are discussed in more
detail below.
♦ What are the main entities / tables?
We now go on to decide which tables are necessary and how they link
together. There should be a table for each class of real-world thing, or
'entity'.
3.5.4. Relationships
A Relationship represents an association between two or more entities. Example of
such a relationship might be:
1. Employees are assigned to projects
2. Projects have subtasks
3. Departments manage one or more projects
Relationships are classified in terms of degree, connectivity, cardinality, and
existence. These concepts are discussed below.
How are the entity types inter-related? There are three basic possibilities,
sometimes referred to as the cardinality of the relationship. Cardinality
specifies how many instances of an entity relate to one instance of another
entity.
Ordinality is also closely linked to cardinality. While cardinality specifies
the number of occurrences of a relationship, ordinality describes the
relationship as either mandatory or optional. In other words, cardinality
specifies the maximum number of related records and ordinality specifies
the absolute minimum number of related records. When the minimum
number is zero, the relationship is usually called optional and when the
Page 42 of 150
minimum number is one or more, the relationship is usually called
mandatory.
∗ 1:1 (one to one)
In a one-to-one relationship, each record in Table A can have only
one matching record in Table B, and each record in Table B can
have only one matching record in Table A. This type of
relationship is not common, because most information related in
this way would be in one table. For example, it may not be
necessary to have a separate credit reference entity; instead, its
attributes could appear on the customer entity.
You might use a one-to-one relationship to divide a table with
many fields, to isolate part of a table for security reasons, or to
store information that applies only to a subset of the main table.
For example, you might want to create a table to track employees
participating in a fundraising soccer game. The additional
attributes for employees who are also football players would be
stored in a football player table, linked one-to-one to employee.
This is done because the vast majority of employees will not be
football players. Similarly, you might have a general customer
table, and then link it to a B2B table (for B2B-specific elements)
and a B2C one. See also generalisation hierarchies below.
∗ 1:M (one to many)
A one-to-many relationship is the most common type of
relationship. In a one-to-many relationship, a record in Table A
can have many matching records in Table B, but a record in Table
B has only one matching record in Table A.
∗ M:N (many to many) and their resolution into two 1:M,
1:N relationships to a new link entity
In a many-to-many relationship, a record in Table A can have
many matching records in Table B, and a record in Table B can
have many matching records in Table A. This type of relationship
can only be stored in a database by defining a third table (called a
junction table, or a link or intersection entity) whose primary key
consists of or includes two fields - the foreign keys from both
Tables A and B. A many-to-many relationship is really two one-
to-many relationships with a third table. For example, an Orders
table and a Products table have a many-to-many relationship that's
defined by creating two one-to-many relationships to an Order
Details table.
It is occasionally necessary to add another attribute to the key to
ensure uniqueness – often this is a date/time field.
3.5.5. Fields: What are the attributes of each entity?

Attributes describe the entity of which they are associated. A particular instance of
an attribute is a value. For example, "DOLMAN Arthur" is one value of the attribute
Name. The domain of an attribute is the collection of all possible values an attribute
can have. The domain of Name is a character string.
Attributes can be classified as identifiers or descriptors. Identifiers, more commonly
called keys, uniquely identify an instance of an entity. A descriptor describes a non-
unique characteristic of an entity instance.
What attributes / fields are required? In other words: what characteristics or
attributes does each table have? For example, an animal type entity has a primary
key of type, and other attributes, such as the number of legs this kind of animal has,
and its normal diet.
Page 43 of 150
Each of the characteristics represents a different field in the table and to differentiate
them they need a unique name. A database management system such as Access
requires to be told the name of each field (attribute) and type of data (text, numeric,
date etc.) which that field represents. If it is a text field the largest character size,
e.g. the biggest name to be stored will need to be included.
 AVOID “repeating fields”- fields whose name is in

the plural, or which imply a plural, which almost
certainly requires a list of values - this is almost
invariably a sign that an extra table is needed.
As an example in a students database, do not make qualifications into fields of
Student – a student already has many qualifications and will gain more. The very
fact that the word qualifications is in the plural is an indication that the relationship
between student and qualification is in fact many-to-many. So a good database
design is:
Programme Qualification
PK Programme code PK Qualification
Programme name
LMD level
Programme leader surname
Programme leader forenames
Student
PK Student no Award
PK,FK1 Qualification
Student surname PK,FK2 Student no
Student
Note that, in accordance with forenames
the rule that the primary key of the one end of a
many-to-may
FK1relationship
Programmebecomes ancodeattribute of the many end – where it is known
as a foreign key – the entity type Award has attributes Qualification and Student no. Award result
Student
Very frequently, the combination gender
of the foreign keys is the best primary key for the
new entity type. However,
Student it isbirthdate
sometimes necessary to add a date or time attribute
to make the key unique – this is arguably necessary here because it is possible to
envisage a student achieving a qualification on more than one date. However, for
simplicity, we have ignored this rare possibility here.
3.5.6. Data type: Domain

For each field: it is necessary to consider the type of data it will contain. Numeric?
Integer or real? etc. If text: how many characters? The combination of type, size and
all its potential values is sometimes called the domain of an attribute.
3.5.7.Identify Domains
This concept, which goes beyond the Chen model, is both well-
based theoretically and very useful in practice. A Domain is the list
of all possible values of an attribute. Thus you might know that the
set of all possible values of a Sex attribute is Male and Female (for
Page 44 of 150
mammals); you might also choose to add the value Hermaphrodite
(to cover worms). It is also very common to permit a Null value,
meaning that for a particular individual we do not know what their
sex is. However, with these four permitted values, we have defined
ALL possible values of that attribute. From this we can state that a
Sex attribute should be a 1-character Text field, and that a
Validation rule should permit only the values M, F, H and (perhaps)
space, representing <null>. We have identified the domain of the
Sex attribute.
It is important to think about the Domain of an attribute for two
reasons:
♦ The Domain determines the data type, size and permitted
values
All attributes having the same Domain should have the
same data type, size and permitted values.
Therefore a Surname should be defined in the same way
throughout a database implementation.
Neither MS Access nor the vast majority of actual database
management systems provide direct support for the Domain
concept - instead, it is the responsibility of the implementer
to ensure that all attributes which share the same domain
are defined with the same type (e.g. numeric integer, text
….), size (e.g. long, double, 5-character text ….), and that
appropriate validation rules are defined and enforced.
In the case of the animal type entity, the number of legs
attribute is an integer number in the range 2 to 1000. The
data type is integer; the domain is the total set of possible
values, in this case, 2, 4, 6, 8… 1000 (millipede!).
♦ Validation rules: What rules apply to each field having this
domain?
Simple example: Sex may be male or female. All other values should be
disallowed by a validation rule, which permits only M (male/masculine) or
F (female/feminine) (and, perhaps, unknown) as values for a Sex attribute.
Consider the validation rules for each data attribute. For example, in the
animal entity, the attribute number of legs must be a value in the domain of
all possible values. Values such as three and 5 are never valid. Consider
setting a rule which does not permit these values. This has the benefit that
it decreases the likelihood of storing bad data.
3.5.8. Classifying Relationships

Relationships are classified by their degree, connectivity, cardinality, direction, type,
and existence. Not all modelling methodologies use all these classifications.
♦ Degree of a Relationship
The degree of a relationship is the number of entities associated with the
relationship. This is usually two, since only two entities are involved in
any given relationship - such relationships are called binary relationships.
This association between two entities is the most common type in the real
world.
The n-ary relationship is the general form for degree n.
Special cases are the binary and ternary, where the degree
is 2 and 3, respectively.
∗ Binary relationships
Page 45 of 150
This association between two entities is the most
common type in the real world.
(a) A recursive binary relationship occurs

when an entity is related to itself. An
example might be "some employees are
married to other employees".
∗ Ternary relationships
A ternary relationship involves three entities and is
used when a binary relationship is inadequate. Many
modelling approaches recognize only binary
relationships. Ternary or n-ary relationships are
decomposed into two or more binary relationships.
They are sufficiently rare to be ignored in the
remainder of this document.
♦ Direction
The direction of a relationship indicates the originating entity of a binary
relationship. The entity from which a relationship originates is the parent
entity; the entity where the relationship terminates is the child entity.
The direction of a relationship is determined by its connectivity. In a one-
to-one relationship the direction is from the independent entity to a
dependent entity. If both entities are independent, the direction is arbitrary.
With one-to-many relationships, the entity occurring once is the parent.
The direction of many-to-many relationships is arbitrary.
♦ Type of relationship
An identifying relationship is one in which one of the child
entities is also a dependent entity. A non-identifying
relationship is one in which both entities are independent.
♦ Existence
Existence denotes whether the existence of an entity
instance is dependent upon the existence of another,
related, entity instance. The existence of an entity in a
relationship is defined as either mandatory or optional. If an
instance of an entity must always occur for an entity to be
included in a relationship, then it is mandatory. An example
of mandatory existence is the statement "every project must
be managed by a single department". If the instance of the
entity is not required, it is optional. An example of optional
existence is the statement, "employees may be assigned to
work on projects".
♦ Generalisation Hierarchies
A generalisation hierarchy is a form of abstraction that
specifies that two or more entities that share common
attributes can be generalized into a higher level entity type
called a supertype or generic entity. The lower-level of
entities become the subtype, or categories, to the super
type. Subtypes are dependent entities.
3.5.9. Keys: primary and secondary (“foreign”)

What are the primary and foreign keys in the attributes of the entities you have
identified?
Page 46 of 150
There is one and only one primary key per entity type. One (sometimes more)
field(s) will uniquely identify each entity in a database; therefore, we have to set it
to be the primary key.
The primary field of an animal patient might be its name or the owner name.
However, both of these are bad choices. Why? What better alternative can you
suggest?
Patient also needs to contain a foreign key - the name of the animal type. Why?
 NEVER FORGET: if a table is at the many end of

one (or more) one-to-many relationship(s), then
the attribute or attributes which uniquely identify
records in the One table must also appear as
attribute(s) in the Many table. These one or more
attributes, known together as a Foreign key, are
essential because they link records in the Many
table to a record in the One table.
Therefore, it is necessary to have a foreign key in
Episode corresponding to the patient-code attribute in
Patient, and also a foreign key corresponding to the
treatment-name attribute in Treatment. The
combination of patient-code and treatment-name is
not, however, sufficient in this case to act as the
primary key – it is also necessary to include the date
in order to create a unique key. As a rule of thumb if
there are two or more columns within a given table
which together are the logical way to identify that
row (and the way you would always join to the
table), then use those as a compound key, otherwise
assign a separate auto increment column as a primary
key.
∗ Candidate keys
There may be more than one possible candidate for use as the
primary key of a table. For example, in an employee table, you
could use either the company generated employee number, or the
Social Security number. In this situation, we say that there are two
candidate primary keys.
∗ Choosing a primary key
One primary key must be selected for the table. A primary key can
sometimes be a compound key, that is it may consist of two or
more elements, which in combination uniquely identify the entity
occurrence.
There may be several candidates, but each entity has one and only
one primary key.
∗ Entity integrity rule
The entity integrity says that no field participating in the primary
key of an entity may be null. Null means empty, or spaces, or
zero, etc.
∗ Multi-part primary keys
Where a link or intersection entity is used to resolve a many to
many relationship into two one to many relationships, it is
common for each foreign key in the child entity to form a part of a
compound primary key. Sometimes it may be necessary to add an
additional part to ensure that the primary key is unique for each
instance; most commonly, it is necessary to add a Date.
∗ Foreign keys
Page 47 of 150
In order to create a one to many relationship between two entity
types, the primary key of the parent entity (or, much more rarely,
another candidate key) is replicated in the child entity as the so-
called foreign key.
Foreign keys implement one to many (1:M) relationships in the
following way. If two entity types are related 1:M, then the
primary key attribute(s) (or, rarely, the alternate key attribute(s))
of the one entity MUST appear as attribute(s) of the many entity.
This is because this is the only way in which the database software
can “join” the many records to the one. Consider a situation in
which students are on a programme. The entity types are
Programme and Student, related 1:M. If the primary key of
Programme is Programme_Code, then Student must also have a
Programme_Code attribute.
♦ Ensuring referential integrity
The terms referential integrity, linking, Primary and Foreign keys and
relationship can be described in this way: Two tables can be linked by a
relationship. This link can be one-to-one (e.g. husband to wife), or one-to-
many (e.g. one brand of car gives rise to many models of car - but each
model has one and only one brand). Coordination is accomplished with
relationships between tables. A relationship works by matching data in key
fields - usually a field with the same name in both tables. In most cases,
these matching fields are the primary key from one table, which provides a
unique identifier for each record, and a foreign key in the other table. For
example, employees can be associated with orders they're responsible for
by creating a relationship between the Employee table and the Order table
using the EmployeeID fields. You can ask Microsoft Access to enforce
referential integrity: if a table such as patient is related to another table
animal type, and referential integrity is enforced, then Access will only
allow a new patient to be introduced if the animal type already exists in the
animal type table.
When you create the properties of a new relationship, you can specify the
behaviour to be followed:
∗ Insert
∗ Update
If a primary key is changed in an owning table, should the system
automatically change the related foreign keys? The answer will
usually be yes, and the option should be set.
To be certain, it is necessary to model the ordinality
of a relationship, as mentioned in section 3.5.4 and
again in section 3.5.11.
∗ Delete
If a parent record is deleted, should the system automatically
delete all the associated child records? Setting this option should
only be done after careful thought!
3.5.10. Normalisation
We should now go back and check each attribute list is:
∗ Complete
∗ Has the right attributes on the right entities
We may choose to use the formal relational data analysis technique
called normalisation. This technique is described in appendix 3. It is
a useful cross-check, and is not essential.
Page 48 of 150
3.5.11.ER Notation
There is no standard for representing data objects in ER diagrams. Each modelling
methodology uses its own notation.
The original notation used by Chen is widely used in academic texts
and journals but rarely seen in either CASE (Computer Aided
Software Engineering) tools or publications by non-academics.
Today, there are a number of notations used, among the more
common being Bachman, crow's foot, IDEFIX and SSADM.
Source: http://en.wikipedia.org/wiki/File:ERD_Representation.svg accessed

18/10/2009.
All notational styles represent entities as rectangular boxes and relationships as lines
connecting boxes. Each style uses a special set of symbols to represent the
cardinality of a connection.
♦ Showing relationships diagrammatically using the crow’s foot
notation
Page 49 of 150
The symbols used in this document for the basic ER constructs are taken
from the American Information Engineering tradition and are also called
the crow’s foot notation (in French, patte d’oie).
∗ Entities are represented by labelled rectangles. The
label is the name of the entity. Entity names should be
singular nouns.
∗ Relationships are represented by a solid line connecting
two entities. The name of the relationship is written
above the line. Relationship names should be verbs.
∗ Attributes, when included, are listed inside the entity
rectangle. Attributes which are identifiers are
underlined. Attribute names should be singular nouns.
∗ Cardinality of many is represented by a line ending in a
crow's foot. If the crow's foot is omitted, the cardinality is
one.
∗ Existence is represented by placing a circle or a
perpendicular bar on the line. Mandatory existence is
shown by the bar (which looks like a 1) next to the entity
of which an instance is required. Optional existence is
shown by placing a circle next to the entity that is
optional.
There are many different ways of drawing entity-relationship diagrams. In
most of this document, we show one-to-many relationships using the
crow’s foot notation without particular concern for the ordinality.
Where it is desirable or necessary to consider ordinality
(whether or not a relationship is mandatory) we can use an
extended set of symbols:
We have not been this precise in the remainder of this

document.
3.5.12.Online tutorial
For an additional online tutorial about entity relationship modelling, see
http://www.cems.uwe.ac.uk/~tdrewry/lds.htm checked 24/11/2008. Note that this
tutorial sticks rigidly to the SSADM modelling conventions and names and makes
reference to Logical Data Structures, LDS. As it makes clear, “Logical data
Page 50 of 150
structures are data models, and are sometimes called entity-relationship (ER) models
or even entity-attribute-relationship models.” In other words, LDS is a synonym for
Entity Relationship Model.
3.5.13.DFDs and ERDs – why both? How are they linked?

♦ DFDs are process models; BUT
∗ Data stores usually have to be stored in database, as
one or more entity types
∗ External entities may have to be stored in database, as
one or more entity types
♦ ERM is a data model
∗ Used to analyse data requirements, and to design
database tables, attributes and relationships
3.5.14.Why BOTH Data and Process models?

 To analyse requirements for data, you should create an Entity Relationship
model (also known as a Data Model, an ER model and an ERA model). An
ERA model is a complementary technique to process modelling, done for
example using Data Flow Diagrams – both are necessary before the overall
requirements of a system are understood.
Process modelling using DFDs can be used in an iterative, refining fashion both to
understand the needs of users better, and to improve on the existing situation with
models of a better, computerised, solution
There is no direct link between DFD process models and ERA data models.
However, data stores and data flows give clues as to what data needs to be modelled:
♦ External entities and data stores indicate required entities
Although note that in some cases a data store is actually an updateable
view of (that is, an updateable query on) one or more entities.
♦ Data flows to and from external entities indicate system inputs
and outputs
3.6. Cross-check: entity life history

This is another useful cross-check.
3.6.1.Cross-check DFD and ERA

The data stores and external entities on the DFD must have
counterpart entity types on the ERA diagram – although the
correspondence is not necessarily one to one (it can be an
updatable view of one or more entity types), there should be
somewhere to store all the data indicated in the DFD.
3.6.2.Time dimension
Ensure that, for all major entity types, there are processes which
CReate, Update, and Delete (CRUD!) them. It may be necessary to
create specific processes to carry out operations which create,
update or delete entity types. But note that some systems do not
ever delete data, instead, they may archive the data.
Formal Entity Life History models exist as part of SSADM but are rarely
constructed nowadays. It is usually sufficient simply to ensure that the
Page 51 of 150
above points 3.6.1 and 3.6.2 are respected. See also
http://www.cems.uwe.ac.uk/~tdrewry/modeling.htm#Modeling
%20Techniques
3.7. Model User <-> System Interactions

Work out what interactions will take place between system users and the information system
you are creating. This can be done by using a low-level Use Case diagram or by other
techniques not taught in the School.
♦ System inputs and outputs
Identification of these can be aided by Use Case diagrams, since these
indicate who needs to use a system and for what. The Use Case diagram
will indicate the basic interactions between the system and its users - some
of these will be data input / update actions, others will involve information
output. They can also be used to derive a list of system inputs and outputs –
e.g. forms, reports and/or webpages. The technique is described in
Appendix 29.
3.8. Define required outputs: reports, forms, queries

What is the database actually for? What Information is to be Output? (Query etc.). Think out
what OUTPUTS are required from the system. This is the information that system users
require FROM the system in order to be able to do their jobs more effectively, to make better
decisions etc.
From this, you can create a list of the information-yielding Forms and Reports required, and
the Queries necessary to support those forms and reports.
3.9. How will Input / Update be carried out (Forms etc.)?

Think out what the necessary system INPUTS are, and when system users will be in a
position to store that input data. How will Input / update be carried out (Forms etc.)?
Although formal dialogue design methods exist, they are usually taught as part of specific
HCI (Human Computer Interface) or webpage design courses. The approach recommended in
this module is simply to identify the necessary forms, perhaps sketching them out on paper or
in an MS Office product. The Use Case diagram produced as part of the modelling of User <-
> System interactions tells you where forms, etc, are needed: each interaction between a
human user (actor) and a Use Case implies a need for Inputs and Outputs.
3.10. Work through your design on paper, whiteboard, etc.

As far as you can, ensure that the system you are proposing will do the job you have outlined
for it. Doing this properly is time consuming and is hard work, but it usually pays off in terms
of avoided wasted implementation effort at the computer. It is also extremely useful in
helping to identify the steps in a test plan, that is, the tests that you will have to carry out on
the implemented system and the expected results of those tests.
An excellent technique for improving the quality of your work is to work with team
colleagues. This can either be explicit collaboration (e.g. working in pairs); or it can take the
form of structured walkthroughs. Structured walkthroughs are discussed in appendix 5.
3.11. Implementing processes in Access

The implementation of complex processes will involve at least macros and perhaps module
programming in (for example) the Visual Basic for Applications programming language.
However, for many simple database applications, this is not necessary. Instead, all that is
required is to guide the user as to which form, query or report they should next be using. This
can be done by creating an initial form, called a switchboard, and by the use of menus and
submenus. This approach leaves the choice of what step to take next to the user, a style of use
which we sometimes call event-driven.
Page 52 of 150
3.11.1. System data processing
In order actually to carry out the data processing, Microsoft Access supports update,
append and delete operations which operate on complete sets of records defined by
corresponding queries. Therefore, the contents of the database can be changed under
the control of queries.
Beyond that, it is necessary to use a programming language. The
specification of data processing is carried out by means of
descriptions of the algorithms involved, using techniques such as
pseudocode. The language supported within Access is Visual Basic
for Applications. The use of pseudocode and of programming
languages is beyond the scope of this document.
3.12. Define (“design” in Access terms) the database: Build a

prototype
This is the stage at which you "tell" Access what your design decisions are, as you design the
tables, attributes, forms, queries, reports etc. There's a fair bit of work here, but if you have
done your "homework" in terms of carefully carrying out the steps already described, and
have already taken the trouble to become reasonably competent in your use of Microsoft
Access as a package, you should be able to concentrate on a good Access implementation of
a design in which you can already place some confidence.
3.13. Refine / iterate / implement

At each stage, but particularly at the design stage and early implementation stage, you will be
learning more about what your system should be doing and you may also be finding problems
with the way it currently works. Where necessary, revise the earlier work and then go on to
ensure that later work is in line with the changed requirement. If you do this conscientiously,
there should not be too many surprises at the system testing stage.
3.14. Test the database

As you implement the system, test as many aspects as you can as you go along. If, for
example, you have created a table and a form by which to input and/or update data in that
table, ensure that the form works and that the data you can input is sensible and appropriately
validated. As you add new forms and subforms, you should find that you can both test them,
and also go back to forms and queries you implemented earlier and further check that they
behave as they ought to do.
When you find problems, do not rush to solve them too quickly. It is wise to carry out as
many tests as you can, building up a “bug list”, or register of problems / deficiencies. Tackle
these in small batches, rather than one at a time, because you will often find that apparently
different problems are linked and have the same underlying causes.
3.15. Obtain User Feedback

Eventually, you will have a working system which does not have too many obvious
implementation faults. However, it is more than likely that it will not be what the would-be
system users expected. It is often the case that users react badly when first shown a system.
This is likely to be for one of the following reasons:
♦ You, the designer / implementer, have made mistakes in
implementing a user's requirements
You may well have omitted a user requirement, or got it wrong. Such
deficiencies are bugs, and you have to put them right.
♦ You, the designer / implementer, have failed to understand
some aspect of the user's requirements of a system
Page 53 of 150
The fault in this case may lie with you or the user or both, but you have to
reach some agreement on what needs to be done to put the system right,
and it will normally be at your expense.
♦ The user has not themselves sufficiently thought through what
they require of a system
Even though the "fault" here is more obviously with the user, you still have
to reach some agreement on what needs to be done to put the system right.
♦ The user, inspired by seeing the implemented system, decides
that they would like the system to do more
Great! A business opportunity! You enter the required additional
functionality on a document which you may grandly term the Enhancement
Register, work out the implications in terms of additional design and
implementation effort, and tell the user what the enhancements will cost -
in terms of later delivery and / or an increased bill. You should never allow
yourself to get dragged into a cycle of continuously responding to such
changes as you go along, without explicit renegotiation of the terms of
reference agreed at the outset of the project.
3.16. Refine the system by Iteration

The ideal in any area of activity is "Right, on time, first time, and every time" - that is,
wherever possible, we should aim to avoid repeated work and wasteful repetition. However,
even the most experienced information systems designers do not achieve this when designing
and implementing information systems. It is almost invariably necessary to go back to earlier
stages in the simple methodology, repeating the work. Note that if you change work carried
out at an early stage in the process, you will normally have to repeat not only that step but
also all subsequent steps. Professional systems analysts and designers build in a significant
amount of time and budget into their original plan in order to cover this reality.
4. Putting database design theory into practice
4.1. Design aids

Use some or all of the following as appropriate to the context in which you are working.
♦ Diagramming tools
E.g. Microsoft Visio Professional, SmartDraw, or EDraw. For more on
using Visio, please see Appendix 4.
♦ Using a spreadsheet as a simple data dictionary
Professional developers often make use of a database about the design
decisions they make. This database about databases is sometimes called a
Data Dictionary, sometimes a Repository. For the small-scale scenarios
dealt with in this module, it is possible and sensible to use a relatively-
straightforward spreadsheet as a simple Data Dictionary. Such spreadsheets
can be a useful aid when recording attributes and rearranging them
subsequently. See section 24.1 for an example of how this can be useful.
♦ CASE tools
CASE tools -- CASE here stands for computer aided software
engineering (and has nothing to do with use case
diagrams!) -- are tools which are used by professionals to
manage the development of large and complex systems.
The use of these tools is beyond the scope of this document.
4.2. An Exercise
Page 54 of 150
Assume that you are the people who originally designed the University of
Anytown database used as an example later in this booklet. Now that you
know about the various stages required to analyse user needs and design
a database solution, carry out those steps for yourself for a business
school. Go through the various stages and carefully document what you
do at each stage. Or, if you are responsible for database design in an
assignment I have set, do the same thing for that database.
This is a significant piece of work - it will probably take you at least a few
hours of effort, and may well take you a week of on-and-off effort.
When you have finished the University of Anytown database design,
compare the results of your work with those of the original analyst /
designers. You should find that you have reached similar or better
conclusions.
4.3. Achieving real competence in Database Design

If you can successfully tackle this exercise and test, you have achieved a
reasonable mastery of database design and should go on to a really
difficult task. So you need to test out your skills! You can do some work on
one of the suggested scenarios that follow.
Alternatively and/or additionally, move on directly to your own scenario,
such as the one you are working on as part of an assignment set by your
teachers.
4.3.1. Documented scenarios

I have produced a companion document, called Database design
and implementation cases, which is available on request. This
describes the following scenarios.
♦ Instruction Training Company
This requirement is separately documented as "Instruction
Training Company".
♦ Dating agency
This requirement is separately documented as "Seekers
Dating Agency".
♦ Filing system
This requirement is separately documented as "Filing
System".
♦ Video Collection
This requirement is separately documented as "Video
Collection".
♦ A catalogue of your record, CD or tape collection
- To include entities such as Album, Artist, Track, and
attributes such as media (e.g. CD, tape, vinyl) and play-time
(length of track in minutes and seconds).
This requirement is separately documented as "Media
System"
♦ A contact / correspondence management system
This requirement is separately documented as "Contact
Manager".
Page 55 of 150
♦ A Student CD Library system
This requirement is separately documented as "Student CD
Library".
4.3.2.Suggested but undocumented scenarios

Decide on a scenario of value to you in your work or in your leisure
time in which a database might be of value. In each case, you
should prepare a scenario document, similar to the ones listed
above, which sets out the main features of the problem area you
intend to tackle. Here are some ideas - you can of course come up
with your own idea, but you are advised to discuss it with a tutor
just in case it is inappropriately complex:
♦ Details of the modules (“courses”) you have studied, the
lectures and classes which formed part of that module, and a
diary of significant events.
♦ Details of your personal research - to include entities such as
references, authors, citations.
Be aware that this is a fairly difficult example to tackle - for
example, how will your database design cope with an article
by many authors (NOT just two or three, maybe five?).
4.3.3.Further study
Before going much further with database design, and assuming you
are full of enthusiasm for database, you are advised to study the
topic in a textbook, learning more about concepts such as
normalisation, which is a very useful technique for ensuring that
each table has exactly the right attributes. Normalisation is
introduced in appendix 3. For a basic treatment, see [Hughes
2000]; for an advanced treatment, see [Date 2003]
5. More about Databases
5.1. What is a database?

A database is a collection of inter-related data, stored together without unnecessary
redundancy, which can serve multiple uses and applications
It is the implementation on a computer of the data model.
Databases were originally a reaction to uncoordinated “conventional files”.
A database is a collection of inter-related data, stored together without unnecessary
redundancy, which can serve multiple uses and applications. It is the physical
implementation of the data model (entity-relationship model) created by the data analyst.
Entities are implemented as tables.
Entity occurrences are records.
Attributes are implemented as fields.
Key relationships may be enforced - in Access, for example, it is possible to "enforce
referential integrity". This ensures that in a one to many situation, the many-end record
cannot exist unless a one-end record already exists. This is good, in that it prevents
unwittingly creating records that are not linked to anything else.
The emphasis throughout is on effective data retrieval in order to answer arbitrarily complex
questions.
Page 56 of 150
5.2. The history of databases
♦ Hierarchic and network databases were invented in the 1960s.
♦ 1970: Dr. E.F. Codd introduces the concept of the relational
database
In 1970, the expatriate British researcher Edgar Codd was
working for IBM in the United States. He suggested that a
better basis for database implementation was relational set
theory, a mathematical approach.
♦ Concepts are relatively simple and have a strong theoretical
basis, that of mathematical set theory
In a relational database, care is taken to keep all the data
for a set of like entities in what is mathematically a relation
or a set, but what we would probably refer to as a table of
records: e.g. student. Each different kind of entity is kept
separately: so we might also have a programme entity (or
relation or table - these are equivalent terms). Student
records are linked to a programme record by means of a
shared linking attribute, in this case, the programme code.
♦ Relational model does have limitations but is currently the
dominant paradigm (way of thinking)
♦ Object databases are just beginning to become commercially
significant and might dominate eventually
The relational database paradigm has been dominant since
about 1980, and has yet to be displaced by the more recent
object database approach.
∗ Oracle – hybrid object-relational approach
5.3. Implementing data models in MS Access

♦ Entities are implemented as tables
∗ Entity occurrences are records or rows in the tables
♦ Attributes are implemented as fields
♦ Key relationships should almost always be enforced
∗ Set cascade update yes; think hard about cascade
delete
Page 57 of 150
The diagram shows a situation in which a foreign key, programme
code, in a Student table is being linked to the corresponding
programme code in the Programme table. It is necessary for a
Programme to exist before a Student can be registered. It is
probably appropriate automatically to cascade any change to the
programme code in Programme to each Student record having that
code. By contrast, the deletion of a Programme might not require
the deletion of linked Students (who perhaps studied on the
programme before it was deleted).
♦ The emphasis has to be on effective data retrieval in order to
answer arbitrarily complex questions
5.4. What is a database management system?

♦ Software which manages a database
♦ Implements entities as tables, maintaining and enforcing
relationships
♦ Deals with all the component disc files
♦ Provides functions such as
∗ Table creation and structural updating
∗ Insert, update and delete operations, on individual
records and on complete sets of records
∗ Queries, reports and forms
5.5. First challenge: database design

A professional systems analyst will carry out parallel data analysis and also process
modelling. The results of data analysis will be compared with Data Flow Diagrams (process
view): data stores and flows give clues as to what data needs to be modelled.
Page 58 of 150
♦ Decide the purpose of the database
♦ Analyse the needs of its users in data terms
∗ Compare with Data Flow Diagrams (process view): data
stores and external entities give clues as to what data
needs to be modelled
∗ Informal cross-referencing between process and data
models
Informal cross-referencing between process and data models may
point up potential problems in one or both sets of analysis.
♦ Design the database on paper
Design the database on paper, define the computer implementation, and
only then think about implementation!
It is very important to give consideration to how input / update be carried
out (forms etc.); in connection with electronic business it is worth noting
that nearly every interaction with the system will take place through a web
interface.
5.6. Second challenge: database implementation

♦ Define the computer implementation
∗ Tables
∗ Attribute types: e.g. student number is 11 chars text,
split three letters and eight digits
♦ How will input / update be carried out?
∗ Forms
∗ Web interface
5.7. An inductive approach

♦ Learning from examples:
∗ Student: Anytown case
See section 9.
∗ NorthWind2003 (complex but useful in an e-business
context; based on standard Microsoft NorthWind
example)
NorthWind2003 is a complex but useful example in an e-business
context; based as it is on the standard Microsoft NorthWind
example
5.8. What Is a Database?

♦ A structured collection of ELECTRONICALLY STORED data
∗ Controlled & accessed through computers
∗ The structure is given by predefined relationships
between predefined types of data items
♦ May include many types of data
Page 59 of 150
5.9. What Is a DBMS?
♦ Database management system (DBMS) = an integrated set of
programs, used to define, update, and control the database
♦ Examples
∗ Small MS Access,
OpenOffice.org Base
∗ Medium MS SQL Server, MySQL, PostgreSQL
∗ Large ORACLE, IBM DB/2
Page 60 of 150
SECTION 2 – USING MICROSOFT ACCESS TO BUILD GOOD
DATABASES
6. Introduction to Microsoft Access

The Microsoft Office Access relational database management system is software to manage
databases.
6.1. What is a database management system?

Microsoft Access is an example of a Relational DataBase Management System (RDBMS). It
is positioned in the marketplace as an office productivity aid. As such, it has limited
resilience and recovery facilities, can be used by more than one person at the same time, but
is NOT suitable for "mission-critical" high reliability or high performance applications -
beyond a handful of concurrent users, Access runs out of steam!
Access - and other small scale databases, such as Filemaker Pro - offer the standard features
expected of such programs:
6.1.1. Software which manages a database
6.1.2. Implements entities as tables, maintaining and enforcing

relationships
6.1.3. Deals with all the component disc files

In Access, there is only one file per database. Bigger databases have much more
complex file structures stored on disc.
6.1.4. Provides functions such as

♦ Table creation and structural updating
♦ Form-based insert, update and delete operations, on individual
records and on complete sets of records
♦ Query and report facilities
Access provides powerful query and report facilities. When you define a
query, what Access does on your behalf, behind the scenes, is to create and
then run a query expressed in a powerful industry-standard programming
language called SQL (Structured Query Language). You can in fact see the
generated SQL if you use View / SQL View.
6.1.5.An approachable programming language

Access offers Visual Basic for Applications (VBA) and SQL.
6.2. Important facilities of more advanced DBMS

More advanced DBMS offer additional features, and are usually structured to operate in a so-
called "client server" situation. In a client-server application, client programs running on PCs
or other low-power computers present data to individual users. The data itself is managed and
stored on a database server computer to which all the client machines are connected.
The clients may either be directly connected to the distant database server, or they may run a
local database (usually Access) which connects to the distant database server (e.g. MS SQL
Server, Oracle ….) using the Open DataBase Connectivity feature ODBC, or they may
Page 61 of 150
present the data in the database by means of web pages. The architecture then looks
something like:
Client Server Architecture Client workstation

1. This
workstation
simply displays
web pages, which
asks for using the
HTTP protocol.
Workstation
HTTP carrying
HTML
Client workstation
2. In addition to
displaying web Local server
pages, this PC
runs a copy of
Microsoft Access
which can
alsoquery the
remote database
(SQL Server or
ORACLE or Server
whatever) which
runs on the main HTTP carrying
database server Workstation HTML; plus
computer ODBC (open
database
connectivity
feature) for
database queries
Web Server –
responds to
Internet HTTP and
delivers HTML;
the web pages
can include
database forms,
with data stored
on the database
server computer.
Servers
Database server
computer. It is
this central
6.3. Further facilities of more advanced DBMS computer that
runs the Central computers
♦ Support many users and multiple
company’s main applications
transaction
∗ MS Access does this, sort of ...
processing andan individual
database
database may support a handful ofsoftware.
users
♦ Depend upon a data dictionary (sometimes
called a repository)
Page 62 of 150
♦ Integrate with the CASE (Computer Aided
Software Engineering) tool which created and
maintains the data dictionary
♦ Implement resilience and recovery mechanisms
These things include roll-forward and / or roll-back mechanisms so
that complete transactions (only) are carried out. Such mechanisms
are essential to prevent situations where, for example, money
leaves one company’s bank account, but never reaches another
company’s.
♦ Enforce security
Only privileged users should be able to see things like payroll data.
6.3.1. Other RDBMS

Examples of so-called "industrial strength" databases include
♦ The “Big Three”
These are the commercial databases at the heart of most large
enterprises:
(a) Microsoft SQL Server
(b) Oracle Corporation ORACLE
(c) IBM DB2

♦ Computer Associates INGRES
The first commercial-strength database management
system, INGRES is now an Open Source product.
♦ MySQL
MySQL is a relational database management system
which has more than 11 million installations.
MySQL is popular for web applications and acts as
the database component of the LAMP, BAMP, MAMP,
and WAMP platforms (Linux/BSD/Mac/Windows-
Apache-MySQL-PHP/Perl/Python), and for open-
source bug tracking tools like Bugzilla. Its popularity
for use with web applications is closely tied to the
popularity of the PHP programming language and the
Ruby on Rails programming framework, which are
often combined with MySQL.
♦ PostgreSQL
These systems are capable of supporting very large numbers of
users and transaction rates measured in tens or hundreds every
second. They are typically used to store so-called "corporate"
databases, and are "overkill" in the context of the personal and
team productivity applications to which Access is well-suited.
6.4. Why we want business students to learn Access

We expect our students to become competent Access users and (to a limited extent)
designers. We start off with Access for a number of reasons:
Page 63 of 150
6.4.1. The relative ease-of-use of MS Access
Industrial strength databases, such as ORACLE, are harder to learn and less well
integrated into the PC environment, whereas MS Access is easily accessible (sic!)
6.4.2. MS Access is easily obtained

It forms a part of the Microsoft Office Professional and Premium office suites
(although it is included neither in the Small Business Edition nor the Student
edition). MS Access is available in French on ESC Rennes student workstations for
students who do not have a copy on their own personal machine. Alternatively a free
copy can be obtained by means of the MSDN Academic Alliance membership of the
School.
6.4.3.MS Access supports usable programming languages

MS Access supports and integrates with the two most widely-used
programming languages associated with personal productivity aids
and with databases. These two languages are Basic and SQL. In
fact, MS Access provides Basic and SQL in a number of ways:
♦ Visual Basic for Applications (VBA)
The dialect of Basic supported by MS Access is VBA - the
same language also used internally by several other
Microsoft Office products, including Excel and the Visio
business drawing package.
♦ Visual Basic (VB) itself
Access can act as the so-called "Jet Engine", providing
database facilities to programs written in Visual Basic.
♦ SQL: Structured Query Language
SQL, Structured Query Language, is a database query
language that was adopted as an industry standard in 1986.
In their SQL standard, the American National Standards
Institute ANSI declared that the official pronunciation for
SQL is "es queue el". However, many database professionals
have taken to the "slang" pronunciation sequel that reflects
the language's original name, Sequel, before trademark
conflicts caused IBM to insist on the ‘official’ pronunciation.
Access supports a reasonably-comprehensive subset of the
ANSI SQL 92 standard. This provides the basis for a high
degree of integration with other databases - so that, for
example, an Access database can act as a client to an
industrial-strength database running on a server computer.
7. MS Access implementation of data models

Access provides a direct implementation of many of the features of a data model (entity relationship
model). Having completed an ERM, it can be implemented in Access as:
7.1. Tables, one per entity type
7.2. Fields, one per attribute
7.3. Records, one per entity occurrence
Page 64 of 150
7.4. Attribute types in MS Access
What data type should you use for a field in a table?
Decide what kind of data type to use for a field based on these considerations:
• What kind of values do you want to allow in the field? For
example, you can't store text in a field with a Number data type.
• How much storage space do you want to use for values in the
field?
• What types of operations do you want to perform on the values in
the field? For example, Microsoft Access can sum values in Number or
Currency fields, but not values in Text or OLE Object fields.
• Do you want to sort or index a field? Memo, Hyperlink, and OLE
Object fields can't be sorted or indexed.
• Do you want to use a field to group records in queries or reports?
Memo, Hyperlink, and OLE Object fields can't be used to group records.
• How do you want to sort values in a field? In a Text field,
numbers sort as strings of characters (1, 10, 100, 2, 20, 200, and so on), not
as numeric values. Use a Number or Currency field to sort numbers as
numeric values. Also, many date formats will not sort properly if entered in
a Text field. Use a Date/Time field to ensure proper sorting.
7.5. Permitted data types in MS Access

The following table summarises all the field data types available in
Microsoft Access, their uses, and their storage sizes.
Data Type Use Size

Text (Français: Text or combinations of text and numbers, Up to 255
Texte) such as addresses. Also numbers that do characters (if you
not require calculations, such as phone need more text
numbers, part numbers, or postal codes. in a field, you
have to use a
Memo field).
Memo (Mémo) Lengthy text and numbers, such as notes Up to 64,000
or descriptions. characters.
Number Numeric data to be used for mathematical 1, 2, 4, 8 bytes.
(Numérique) calculations, except calculations involving
money (use Currency type). Set the
FieldSize property to define the specific
Number type.
Byte Stores numbers from 0 to 255 (no 1 byte
(Octet: fractions).
Numérique 1
octet)
Integer Stores numbers from –32,768 to 32,767 (no 2 bytes
(Entier: fractions).
Numérique 2
octets)
Long Integer (Default) Stores numbers from – 4 bytes
(Entier Long: 2,147,483,648 to 2,147,483,647 (no
Numérique 4 fractions).
octets)
Page 65 of 150
Single Stores numbers from –3.402823E38 to – 4 bytes
(Réel simple) 1.401298E–45 for negative values and
from
1.401298E–45 to 3.402823E38 for positive
values
Double Stores numbers from – 8 bytes
(Réel double) 1.79769313486231E308 to
–4.94065645841247E–324 for negative
values and from 1.79769313486231E308
to 4.94065645841247E–324 for positive
values.
15 decimal places.
Date/Time Dates and times. 8 bytes
(Date/Heure)
Currency Currency values. Use the Currency data 8 bytes
(Monétaire) type to prevent rounding off during
calculations. Accurate to 15 digits to the
left of the decimal point and 4 digits to the
right.
AutoNumber Unique sequential (incrementing by 1) or 4 bytes
(Numérotation random numbers automatically inserted
automatique) when a record is added.
NB: if you use an automatically numbered
field as part of the primary key of a table,
and you also have to use it as the foreign
key in a linked table, the data type
required in the many end is long integer,
which is how in fact an AutoNumber field is
stored.
Yes/No Fields that will contain only one of two 1 bit
(Oui/Non) values, such as Yes/No, True/False, On/Off.
OLE Object Objects (such as Microsoft Word Up to one
(Liaison OLE) documents, Microsoft Excel spreadsheets, gigabyte (subject
pictures, sounds, or other binary data), to disc space!)
created in other programs using the OLE
protocol, that can be linked to or
embedded in a Microsoft Access table. You
must use a bound object frame in a form or
report to display the OLE object.
Hyperlink Field that will store hyperlinks. A hyperlink Up to 64,000
(Hyperlien) can be a UNC (Universal Naming characters
Convention) path to a file, or a URL.
Assistant for Creates a field which permits you to The same size as
choosing from a choose, from a scrolling list, a value which the primary key
list comes either from another table or from a of the
(Assistant Liste specified list of permitted values. If you corresponding
de choix) choose this option, a wizard appears to table. In the
help you to define the field. (common) case
where this is an
AutoNumber
field, it will be 4
Page 66 of 150
bytes in length.
7.5.1. Use of Number or Currency fields

Microsoft Access provides two field data types to store data containing numeric
values: Number or Currency.
Use a Number field to store numeric data to be used for mathematical calculations,
except calculations that involve money or that require a high degree of accuracy.
The kind and size of numeric values that can be stored in a Number field is
controlled by setting the FieldSize property. For example, the Byte field size will
only store whole numbers (no decimal values) from 0 to 255 and occupies 1 byte of
disk space.
Use a Currency field to prevent rounding off during calculations. A Currency field is
accurate to 15 digits to the left of the decimal point and 4 digits to the right. A
Currency field occupies 8 bytes of disk space.
7.5.2. Storing telephone numbers

Quite a lot of data which we informally refer to as numbers are in practice nothing
of the kind! For example, telephone numbers include nonnumeric characters such as
plus, spaces, and leading zeros: +44 (0)789 12345. For this reason, such fields must
be stored as text. See the next section for details of how to ensure that the data stored
in the fields is correctly formatted.
7.5.3. Controlling data entry formats with masks

When you have several people entering data in your database, you can define how
users must enter data in specific fields to help maintain consistency and to make
your database easier to manage. For example, you can set an input mask for a form
so that users can only enter telephone numbers in the Swedish format or addresses in
the French format. You can set a specific format for the input mask, and select
another format so that the same data is displayed differently.
For full details of masks and how to use them, please refer to Microsoft Access
documentation available online: http://office.microsoft.com/en-
us/access/HA100964521033.aspx#2
7.6. Keys
7.6.1. Candidate keys

If there is only one candidate key, it has to be the primary key, and the comments
below for primary key apply.
If a key is a candidate key but not a primary key, it is wise to set additional
properties: indexed - null forbidden; and duplicates not allowed.
7.6.2. Primary key

There is only one primary key per table (although the single primary key may have
multiple attributes within it -- please refer to the next section).
If the key has only one part, select it, and use Edit / Primary key to set the attribute
as primary key.
♦ Primary keys in MS Access
A commonly-used technique in Access is to use an AutoNumber field as a
primary key attribute. An AutoNumber field is in fact a Long Integer value.
For this reason, the data type of a corresponding foreign key field should be
set to Long Integer.
Page 67 of 150
7.6.3. Multi-part primary keys
The primary key may be multipart. To create a multipart primary key in Access,
select the first field, then, holding the control key, select the second and subsequent
parts. Once all parts of the primary are selected, use Edit / Primary key to set the
attribute as primary key.
7.6.4. Entity integrity rule

This rule states that no field participating in the primary key of an entity may be
null. This rule may be enforced in Microsoft Access as follows: set the Null
Forbidden property for each attribute which participates in the primary key.
7.6.5. Foreign keys

In Microsoft Access, a foreign key is created by creating attributes which correspond
to the primary key of the one end of a one to many relationship in the many end.
These attributes must have the same data type and size as the attributes in the
primary table. If the primary key is an auto number field, the attribute in the many
table should be declared as a long integer. Then a one to many relationship should
be established, as is described in the next section.
7.7. Relationships
Defining relationships in Access involves you in adding the tables you want to relate to the
Relationships window, and then dragging the primary key field from one table and dropping
it on the foreign key field in the other table.
The kind of relationship that Microsoft Access creates depends on how the related fields are
defined:
♦ One-to-many relationship
A one-to-many relationship is created if only one of the related fields is a
primary key or has a unique index. This is usually the case.
♦ One-to-one relationship
A one-to-one relationship is created if both of the related fields are
primary keys and / or have unique indexes.
Sometimes Access recognises this automatically, as here, when a B2B
customer table is being created to hold fields specific to B2B customers:
Page 68 of 150
The result is:
Sometimes Access will not automatically recognise a one to one

relationship and you may need to force a one-to-one relationship; you do
this by setting the index property of the foreign key attribute to duplicates
not allowed.
So, if we have this B2B table which we want to link back to Customer:
Then we have to set a property on the Indexed field CustomerID:
Page 69 of 150
♦ Many-to-many relationship
A many-to-many relationship is really two one-to-many relationships with
a third table whose primary key consists of7 two fields - the foreign keys
from the two other tables. This has already been discussed in section 2.21
7.7.1. Relationships and linking: Enforcing referential integrity where

appropriate
Should you enforce referential integrity? As you define a 1: M relationship, you are
invited to check the box which enforces referential integrity. You should normally
do this - it means that you cannot create a child record for a non-existent parent
record, and this is a powerful and useful validation / data integrity constraint in
nearly every case. Do NOT do this if your ER model shows the relationship to be
optional.
To summarise why you might want to use referential integrity: if a table such as
animal patient is related to another table animal type, and referential integrity is
enforced, then a database management system will only allow an actual patient
record to be inserted if the type of the animal already appears in the animal type
table. This is a highly-desirable constraint, since it ensures that questions to which a
precise answer is needed actually get one. Without it, someone might erroneously
update the database to say of Fido that he is a dawg, and a query which lists all dogs
would omit Fido.
If you do set the option to enforce referential integrity, it is common also to set the
option for Cascade update; it is potentially dangerous to set the option for Cascade
delete, and you should only do this if you are certain of what you are doing.
7.8. System outputs
7.8.1. Queries
A query is a temporary results table resulting from joining together fields taken from
one or more database tables. A query can also include calculated fields.
7.8.2. Reports
Reports are comprehensive summaries of a situation, and normally involve data
from several tables. As such, it is based rather on a single query than on a single
table. A report is frequently intended to be printed, rather than viewed on-screen.
7.8.3. Forms
7
Or, includes them, along with another attribute which ensures uniqueness, usually a date.
Page 70 of 150
Forms are used to get data into a system, and may also be used to get information
out -- see the next section.
7.9. System inputs
7.9.1. Forms, sub-forms and their use with 1: M and M: N relationships

A form can be used to input data into a table. Where two tables are linked by a one
to many relationship, it is common to use the form and an associated sub-form.
A subform is a form within a form. The primary form is called the main form, and
the form within the form is called the subform. A form/subform combination is often
referred to as a hierarchical form, a master/detail form, or a parent/child form.
Subforms are especially effective when you want to show data from tables or queries
with a one-to-many relationship. For example, you could create a form with a
subform to show data from a Customer table and a Cars table. One Customer can
own many Cars. Conversely, one Car can be owned by only one Customer at a time.
The data in the Customer table is the "one" side of the relationship. The data in the
Cars table is the "many" side of the relationship. From a Customer-based form, a
subform of type datasheet or continuous form can show the details of all the various
cars owned by that customer. Alternatively, the form/subform relationship can be
used in the opposite sense, since with a Service record displayed, a user might want
to show the details of the (one) car which is being serviced.
Subforms can be nested, that is, a 1:M:N situation such as Customer : Order : Order
Detail can be implemented as a form containing a subform which itself contains a
subform.
Unfortunately, there is no straightforward way to show the three tables which
participate in a many to many relationship (for example, Order, Product and the link
table OrderDetail). Often, it is adequate just to use two (different) form to sub form
combinations. Where it is necessary to show the contents of all three tables at the
same time, a technique which is frequently applicable is to have a form and subform
relationship, with the link between the subform table and its other owner being
implemented as a combo box. An example of the use of this technique is provided in
appendix 2.2.
7.9.2. Field-specific validation checks

In Microsoft Access, these may take the form of simplified Visual Basic rules, such
as that a field must be either M or F. Where the list of permitted values will never
change, such as in the case of gender, it is sensible to include the rule as a property
of the attribute being defined. When the valid values form part of a variable list, it is
probably better to set that list up as a separate table and to enforce referential
integrity – see the next section.
7.9.3. Using relational integrity to carry out inter-table validation checks

Where two tables are linked in a one to many relationship, it is usually good practice
to enforce referential integrity. See section 7.7.1. This makes it impossible to
introduce a child record for a non-existent parent; this is often of considerable value
in improving the design of a database.
A variant of this technique involves the specific identification of so-called lookup
tables. A lookup table contains the valid values of an attribute. By making the
lookup table a parent entity to the table whose values are to be verified, it becomes
impossible to enter “bad” data, that is, data not authorised by the lookup table. In
this example, the grade attribute of a student’s result in a module has been made into
a lookup based on the valid values stored in the parent Grade table. It is therefore
impossible to record an invalid grade.
Page 71 of 150
7.9.4. Table-level checks on forms
On a form, it is possible to cross check fields. For example, you
might not allow the title Mr for a person whose gender is female.
However, to do so requires the use of VBA.
7.10. Implementing processes
7.10.1.Data processing in Access

People expect systems to do things for them! This normally involves some amount
of data processing or transformation
7.10.2.Functional elements in Access

♦ Implicit data processing
E.g. a query involves joining two or more tables and generating a single
unnormalised table which is the required result - Access is doing a lot of
processing to achieve this, albeit it is not particularly visible to the system
user.
♦ Calculations: using expressions in Microsoft Access
A query may involve arithmetic elements, such as creating totals and sub-
totals. When defining the query, instead of specifying a field, specify a
calculated field. The syntax is exemplified in:
Amount : [Quantity] * [Unit price]
The operators (such as * for multiply) and functions (such as ) permitted in
expressions are documented at http://office.microsoft.com/en-
us/access/HP051866381033.aspx which also describes the Expression
Builder, which considerably eases the task of building valid expressions.
Expressions are also used in forms and reports.
♦ SQL
The set-processing language in Access is SQL: Structured
Query Language, which is an ANSI (American National
Standards Institute) standard language. As the name
suggests, SQL is a means of asking queries (questions) of a
database and getting back answers. Part of the power of the
relational data model is that, provided that the database
consists of normalised entities, it is possible to ask almost
any arbitrarily-complex question and get an answer.
Page 72 of 150
However, SQL is more than a conventional query language.
It also provides set manipulation facilities, that is, it is
possible to create whole new sets of data and to store them
in tables, and / or it is possible to update complete sets of
records in a single operation. Access implements this
functionality as ‘append’ and ‘update’ queries – see below,
section 7.11.1.
♦ Occasional need for record-at-a-time navigation and
processing
Access usually manipulates records a set at a time.
Sometimes, it is necessary to carry out record-at-a-time
navigation and processing under program control. This is
achieved in Access by means of:
∗ Recordsets: the Access mechanism for making tables
and queries available a record at a time
∗ Visual Basic: the language in which you can manipulate
individual records
ESC students should not normally try to learn how to do this.
7.11. System data transformations

Access provides the following explicit ways in which to take stored data and either to change
the way in which it is stored, or to transform it under program control:
7.11.1.Append and Update queries

These are the user-accessible means by which Access provides set manipulation
facilities, that is, it is possible to create whole new sets of data and to store them in
tables, and / or it is possible to update complete sets of records in a single operation.
They are not described further in this document.
7.11.2. Macros
Macros are stored sequences of user commands.
7.11.3.Visual Basic for Applications (VBA) modules inside

Access
Program code can be linked to objects within a database, such as
forms, etc. This program code is written in VBA.
7.11.4.Visual Basic programs outside Access

A program written in Visual Basic can manipulate data stored in a
Microsoft Access database. The facility to do this is called Access
Data Objects, ADO.
This document does not cover these topics in any systematic
manner. ESC students should not normally attempt to learn
programming.
Page 73 of 150
8. Ways in which to learn more MS Access
8.1. Sample databases and applications included with Microsoft

Access
The material in this section is based on, and quotes from, the MS Access help files.
Microsoft Access provides a sample database that you can use while you're learning
Microsoft Access.
8.1.1. NorthWind Traders sample database (English edition) /

Les Comptoirs (édition française)
Use this sample database when you're first learning Microsoft Access. The
NorthWind database contains the sales data for a fictitious company called
NorthWind Traders, which imports and exports speciality foods from around the
world. By viewing the tables, queries, forms, reports, macros, and modules included
in the NorthWind database, you can develop ideas for your own Microsoft Access
database. You can also use the NorthWind data to experiment with Microsoft Access
before you enter your own data. For example, you may want to practice designing
queries using the Orders table since it contains enough records to produce
meaningful results.
A French version of the same application can be built using the French-language
edition of Access. It is entitled Les Comptoirs. It is not quite as complete as the
American English version.
We have created an improved version of NorthWind which overcomes some of the
weaknesses in its original design and implementation by Microsoft.
8.1.2. Database Wizards (Assistants)

Microsoft Access also includes a database wizard (assistant) that you can use to
create common databases, such as a Contact Management database8. You can use
the databases created by the database wizard as-is or as a learning tool to help you
design your own databases.
8
However, please note that this Contact Management system will NOT meet the requirement set out in section 4.3.1!
Page 74 of 150
SECTION 3 – THE ANYTOWN DISTANCE LEARNING BUSINESS
SCHOOL EXAMPLE
9. Example scenario: Anytown Distance Learning Business
School
The Anytown Distance Learning Business School offers general business courses at undergraduate
and postgraduate levels. The undergraduate course is a Bachelor of Arts (BA) course called Business
Studies. The postgraduate course is a Master of Business Administration (MBA). Each course is
administered by a Course Coordinator.
Students apply for a course, BA or MBA.9 They send in an application form containing their personal
details, and their desired course. On behalf of the School, the appropriate Course Coordinator checks
whether the course is available and that the student has already obtained the necessary academic
qualifications. If the course is available (not yet full) and the student is qualified, he or she is enrolled
in the course, and the School confirms the enrolment by sending a confirmation letter to the student.
If the course is unavailable or the student is not sufficiently qualified, the student is sent a rejection
letter.
10. Background: Studying

The academic year is divided into two teaching semesters, the first of which runs from October to
January, the second from February to May. At the start of a semester students must register for the
modules they will be taking in that semester. These are the core modules for that semester of the
course, and the electives chosen by the student. All modules last only one semester. There is a third
semester, over the summer, running from June to September. No ordinary modules are taught in the
third semester. However, MBA students do their dissertation in the third semester.
Once the student is enrolled on a course, they have to study modules, each of which has an associated
credit. The credit for an undergraduate module is 10; that for a postgraduate module is 15. To be
awarded a BA, a student on the BA course has to achieve 360 credits, and this is normally achieved
by the student studying six 10-credit modules per semester for each of two semesters per year for each
of 3 years: 6 X 10 X 2 X 3 = 360. On the MBA, students study four 15-credit modules per semester
for each of two semesters in a single year: 4 X 15 X 2 = 120. They then undertake a single
dissertation (project) in the third semester; the dissertation is for 60 credits. A student is awarded an
MBA when he or she has achieved 180 credits. The table summarises the structure of each course:
Course Modules Credits per Taught Number of Sub-total Project Total
per module Semesters years credits
semester per year
BA 6 10 2 3 360 0 360
MBA 4 15 2 1 120 60 180
The student chooses the modules they will study at the start of each semester. A module is taught by a
module leader. Each module is assessed by coursework and by an exam, in varying proportions – one
module might be 60% exam, another 50%. A student passes a module if the mark for the module as a
whole exceeds 40%. If they pass, they are awarded the module credits; if they fail, they are awarded
zero credits. If a student fails a module, he or she has to take an alternative module in a later semester,
so that they can obtain sufficient credits.
Study is by means of Distance Learning. Coursework is submitted by email. The students do not need
to come to Anytown, except when they have exams to do at the end of the first and second semesters.
11. A Closer Look into "Managing Students"

This section focuses on the part of the system that supports the administration of information about
students on courses and modules.
9
Note that course in this case study is neither programme nor module – but, as we will see, it is closer to
programme than module.
Page 75 of 150
• Students study modules drawn from two lists of modules held for the School, one of
undergraduate modules, the other of postgraduate ones.
• Modules have titles and a unique identifying code. Each module has a pre-defined value
expressed as a number of credits.
• Modules are of two kinds - some modules are core, some are electives, that is they are
optional.
• Core modules must be taken by all students on the course. The course regulations will
specify how many optional modules a student can take and what these options might be.
• Students who pass a module are awarded the number of credits specified as that module’s
value. If they fail, they get zero credits.
• Students construct a programme of study by doing core modules, to which are added the
optional (elective) modules they select from those available.
• Every course defines a maximum period of enrolment within which time the course must be
completed. This is normally five years for an undergraduate course and three years for a
postgraduate course. If a student does not complete within this time, the decision of the next
exam board will be that they have failed the course.
• Students may suspend studies or withdraw from the course. The date on which this happens
must be recorded.
• Each component (coursework or exam) of a module has a certain percentage weighting and a
student’s overall mark for a module is calculated by combining the marks for each component.
• An exam board (jury) meets after each semester to consider the marks obtained by students
and to determine whether they have passed or failed the modules they were registered for, and
what their status on the course now is. This process is described in more detail in section 12.
12. The process of deciding what happens to students

At the end of every semester, the module leaders and course coordinator meet together in an exam
board (jury). The exam board is chaired by the Dean of the School, who represents the School’s
management.
The exam board firstly looks at the results for each module, checking to see that they are reasonable
and sensible – that is, that the marks awarded are neither too high nor too low. If there is a problem,
all the marks awarded are scaled up or down by a percentage decided by the board.
The exam board is then presented with a list of all the students on the course. For each student, there
is a report, called a Student Results Summary, which shows what modules the student has undertaken
and the results they have achieved. An example of this report is given below in section 19. The jury
then decides for each student whether they have:
1. Passed all the necessary credits, including all the core modules for the course and at
least the necessary number of options from the course’s collection of optional modules; in
this case, the decision is that they have succeeded in the course and they are awarded a BA or
MBA.
2. Not yet passed all the necessary credits, but are making satisfactory progress: the
decision is that they may proceed, taking further credits as necessary.
3. Are not making satisfactory progress, that is, they are failing to complete too many
modules or have exceeded the maximum time they may stay on the course: the decision is
that they have failed in the course as a whole.
After the exam board, a revised version of the Student Record is printed and sent to the students.
13. Course Review

Once a year, a Course Review meeting is held at which each course is reviewed to see whether the list
of modules is still appropriate, or whether some modules have become obsolete, or whether new
modules need to be devised. The same meeting has the power to change the relative weightings of the
coursework and exam components, and to decide which modules are core on a course and which are
electives. Module leaders can propose changes to module specifications. The Dean can propose
changes to the programme itself.
Page 76 of 150
14. Simplifying Assumptions
This database does not contain full details of qualifications. 10 So data about the following things is
simply stored as large text fields (Access Memo type), because it does not need to be queried:
Course Qualifications Required
Applicant / Student Previous Qualifications
Each module has only one teacher, and that teacher is the module leader. One teacher may however
be the module leader for a number of modules.
15. External entities

These are:
♦ Applicant
♦ Student
♦ Course Coordinator
♦ Module Leader
♦ Management – the Dean
16. Processes
This list is not necessarily complete.
16.1. Process Applicants

Decide whether to accept or reject students, on the basis of their qualifications and the
availability of spare places on the course.
16.2. Admit students to Course – Course Enrolment

Details of the applicant are transferred to the Student table.
16.3. Register students on core and optional modules

This is done at the start of each semester. Students fill in a form stating which optional
modules they wish to do and confirming the core modules that they have to do.
16.4. Teach and assess a module

Each module lasts one semester.
16.5. Prepare for and hold exam board (jury)

• Collect together the results for all students for all modules they have
been studying
• Review module results in exam board
• Decide student status in exam board
16.6. Review Course

This is described in section 13.
10
For a more thoughtful approach to how to manage qualifications, please see section 2.22
Page 77 of 150
17. Documents
The Course Coordinators currently produce and maintain the following documents:
17.1. Course Description

Produced for each course, this describes the course, says what qualifications students have to
have, and lists the core and elective modules. It is updated for and as a result of the Course
Review meeting (section 13). The Course Description is a report, it is not an entity.
17.1.1.List of Modules
For each module, the following data has to be kept:
♦ Module Code
♦ Module Title
♦ Course Code – The Course on which the module is used – a
module is used either on the BA or the MBA
♦ The Lecturer who is the Module Leader
♦ Elective or Core?
♦ Examination weighting %
17.2. Management Reports

The following statistics and analyses would be of value to management:
♦ Analysis of the results for each module – average mark,
standard deviation, percentage of students who do not pass
the module.
18. Entity and Attribute Lists
Some initial analysis work has been undertaken; however, please note that it is not complete, and you
are expected to add to it.
Some of the entities are Applicant, Course, Lecturer (module leader), and Student.
Some of the attributes for some of these entities are:
Applicant
Applicant No
Date of Application
Applicant Name
Applicant Address
Applicant Country
Actual Qualifications (stored as a Memo field)
Course
Course Code
Course Name
Course Description
Qualifications Required (stored as a Memo field)
Lecturer
Lecturer No
Lecturer Name
Home Address
Student
Student No
Course Code (Foreign key)
Page 78 of 150
Student Name
Student Address
Date of Birth
Previous Qualifications (stored as a Memo field)
Status (Applicant / Enrolled / Passed / Failed / Withdrawn / Suspended / Progressing)
19. Example Student Record Report

This is an extract of the information presented to the exam board for one student; it is later
printed and sent to the student.
Page 79 of 150
20. Anytown high-level Use Case diagram
Please note that the label <<include>> can also be written « include ». Note also that Microsoft
Visio employs <<uses>> or « uses » instead of << include >> - they mean the same thing.
Use Case diagram

for Anytown Input applicant
details
Applicant
Confirm applicant
as student
Record student
module choices
Print module
results for jury
Course coordinator
Print student
results for jury
Student
Update student
status Jury
Print student
results letters
Record new staff
member
Submit coursework
Change course
structure
«uses»
Module leader
Input module Update module

results
«uses»
Dean
Allocate teacher
Request management
reports
Page 80 of 150
21. Anytown: Context diagram
Proposed changes to module specification

Applicant Module leader
Application Revised module specification
Acceptance or rejection
Module results
Proogramme co -
ordinator
Decision
Application University of Anytown Student
Course description
System
Management reports
Dean / Management
Module choices
Potential changes to programme
Coursework and exams for assessment

Student
Student results letters
Page 81 of 150
22. Level 1 DFD
Applicant Module marking Module leader
Application
Revised module specification
Student status
Acceptance or rejection
4
Prepare for and hold
D4 Module results exam board Proposed changes to
Decision module specification
Course Process applications 7

co-ordinator Application Produce management
reports
5
6
Teach and assess Module &
module D5 Review Courses and
Course specs modules
Management reports
Applicant
D1
details Module
D3 Potential changes to Course
registrations
Semester results letters
2 3
Admit students to Register students on Dean / Management
Coursework and exams course D2 Students core and elective
for assessment modules
Course descriptions
Module results letters
Course
co-ordinator
Student Module choices
Page 82 of 150
23. Example Level 2 DFD
4 Prepare for and hold exam board
D4 Module results
4.1
Collect module results

and produce student D6 Student profiles
Changed profile
module results
Initial module
Revised module results
4.2
results
Review module results
4. 4
Print results letters

4.3
Decide student status
Student result letters
D2 Students
Students
Page 83 of 150
24. Data dictionary
We now need to move towards a good ERA model by means of top-down entity attribute modelling.
The approach I have adopted here is to work on the basis of the list of "obvious" entities which I identified in section 18, put them into a spreadsheet, and gradually add the
appropriate attributes. The spreadsheet is an extended example of what is sometimes called a Data Dictionary.
24.1. Data dictionary for Anytown Business School
Data Dictionary for Anytown Business School
Description
External entities
Applicant
Student
Course Coordinator
Module Leader
Dean
Process (P) Sub-

or Sub process
Processes process (S)? Process No Process name No Sub-processes DFD number
Process
applications P 1 Process applications 1
Admit students Admit students to

to course P 2 course 2
Page 84 of 150
Register
students on
core and Register students on
elective core and elective
modules P 3 modules 3
Prepare for and
hold exam Prepare for and hold
board P 4 exam board 4
Collect module
results and Collect module
produce student results and produce
profile S 4 1 student profile 4.1
The scaling factor (if any)
is applied to the recorded
student results before the
Review module Review module Student Results
results S 4 2 results 4.2 Summary is reprinted
Decide student Decide student

status S 4 3 status 4.3
Print results
letters S 4 4 Print results letters 4.4
Teach and Teach and assess

assess module P 5 module 5
Review
programmes Review programmes
and modules P 6 and modules 6
Page 85 of 150
Produce
management Produce management
reports P 7 reports 7
Data Stores Store name
1 Applicants
2 Students
3 Module registrations
4 Module results
5 Module specifications
6 Student profiles
7 Course specifications
Process
Data Flows External entity Process No Direction Name of flow name
Process
Applicant 1 Inward Application applications
Process
Applicant 1 Outward Acceptance or rejection applications
Process
Course Coordinator 1 Outward Application applications
Process
Course Coordinator 1 Inward Decision applications
Page 86 of 150
Review
programmes
Course Coordinator 6 Inward Course description and modules
Register
students on
core and
elective
Student 3 Inward Module choices modules
Review
Coursework and exams for module
Student 4.2 Inward assessment results
Teach and
assess
Student 5 Outward Module results letters module
Print results
Student 4.4 Outward Student results letters letters
Review
Proposed changes to module programmes
Module Leader 6 Inward specification and modules
Review
Module specification as programmes
Module Leader 6 Outward revised and agreed and modules
Review
programmes
Module Leader 6 Inward Module results and modules
Analysis of the results of
Produce each module; course
management description; list of
Dean 7 Outward Management reports reports modules
Review
Proposed changes to programmes
Dean 6 Inward programme and modules
Page 87 of 150
Entities Attribute Primary? Foreign? Domain Validation
Y or C Type Size Format Input mask Rules Description
An applicant becomes a
Applicant / student when they are
Student enrolled
Student
number Y Text 11 > LLL00000000
Student
forenames Text 30
Student last
name Text 20 >
Date of birth Date/time Date 00/00/0000

Student
address line
1 Text 20
Student
address line
2 Text 20
Student city Text 50 >

Student
postcode Text 8
Student
country Text 32
Course code Y Text 3

Application
date Date/time 20 Date 00/00/0000
Enrolment
Page 88 of 150
Finishing
Applicant /
Enrolled /
Passed /
Failed /
Withdrawn /
Suspended /
Status Text 12 Progressing
Term
address line
1 Text 20
Term
address line
2 Text 20
Term city Text 50 > Defaults to Anytown
Term
postcode Text 8
Contact
details Text 60
Previous
qualifications Memo
Employee
Employee
number Y Text 7 > LLL0000 e.g. EMP1234
Employee
forenames Text 30
Employee
last name Text 20
Page 89 of 150
Course
coordinator /
Employee module
role Text 20 leader / Dean
Social
security
number Text 16
Employee
address line
1 Text 20
Employee
address line
2 Text 20
Employee
city Text 50
Employee
postcode Text 8
Employee
country Text 32
Employee
contact E.g. telephone numbers,
details Memo etc.
Programme Level Y Text 1 > L P/U
Credits per 10 if undergrad; 15 if
module Integer postgrad
Project
credits Integer 60 if postgrad
Credits 360 if undergrad; 180 if
required Integer postgrad
Course
Course MBA /
code Y Text 3 BA
Page 90 of 150
BA Business Studies or
Course Master of Business
name Text 40 Administration
Course Long Employee who manages
coordinator Y Integer the course
Level Y Text 1
Required
qualifications Memo
Max number
of students Integer
Normal
number of
years Integer
Max number
of years Integer
Module
value Integer
Modules per
semester Integer
Taught
semesters
per year Integer
Description Memo
Module
Module
code Y Text 4
Module title Text 1
Page 91 of 150
Course code Y Text 1
Hypertext
Specification link
A Module Operation is the
operation, or running, of a
Module operation module in a given year
Module
code C Y Text 4
Year C Text 4
Core /
elective / C/E/
obsolete? Text 1 O L
Examination
weighting Integer %
Teacher Text 7 > LLL0000
Scaling
factor Scaling factor, in %,
applied Single % decided by jury
Registration Result
Module
code C Y Text 4 L000
Student
number C Y Text 11 > LLL00000000
Date course
work
received Date/time
Course work
mark Integer %
Exam mark Integer %

Page 92 of 150
Overall mark Integer %
Module
result Text 4 Pass / fail
Relationship
s Parent Relationship Child Degree Description
A Course is part of either
a Postgraduate or an
Undergraduate
Programme Includes Course 1:M Programme
An application is made by
an Applicant for a Course.
If they are acceptable,
they may Enrol on the
Applicant / Course. They are then a
Course Enrols Student 1:M Student on that Course
A Course is delivered as
Course Consists Of Module 1:M a series of Modules
An Employee whose role
is Course Co-ordinator,
Employee Coordinates Course 1:M coordinates the Course
An Employee whose role
is Lecturer, Leads the
Employee Leads Module 1:M Module
Registration Result
resolves the many-to-
many relationship
Registration between Module and
Module Results In Result 1:M Student
Registration Result
resolves the many-to-
Is many relationship
Applicant / Registered Registration between Module and
Student On Result 1:M Student
Page 93 of 150
Module
Module Runs as operation 1:M
Use Cases Actors Relationships Other Use Cases Description

Input applicant details Course coordinator Used by actor
Confirm applicant as student Course coordinator Used by actor
Register student on modules Student Used by actor
Input module results Module leader Used by actor
Print module results for jury Course coordinator Used by actor
Print student results for jury Course coordinator Used by actor
Print student results letters Course coordinator Used by actor
Change course structure Dean Used by actor
Change course structure Includes Update module
Module, and Module
Update module Module leader Used by actor Operation
Update module Dean Includes Allocate teacher
Update student status Jury Used by actor
Record new staff member Dean Used by actor
Submit coursework Student Used by actor
Request management reports Dean Used by actor
Allocate teacher Dean Used by actor
System
Outputs
Reports Description
Average mark, standard
deviation, percentage of
students who have not
Analysis of the results of each module passed
See section 10 of
Student Results Summary scenario
Page 94 of 150
Sub-
Forms Forms Description
Queries Description
System
Inputs
Sub-
Forms Forms Description
Applicant details
Student details
Programme and module
Record student module choices details
Module and Module Operation
Update course structure details
Update module
Update student Registration results
Update member of staff
Coursework receipt
Validation Checks Description

(NB: this is intended for inter-entity validation checks, and there are none in this
particular scenario)
Page 95 of 150
25. Anytown ER diagram
Entity Relationship model for Anytown
Programme
Includes
Course Coordinates Employee
Consists of
Module
Leads
Runs as
Enrols Module Operation
Results in
Registration / Result
Is Registered on
Applicant / Student
Page 96 of 150
26. Anytown system implementation
In order to use the analysis and design work we have already undertaken, you would begin to
translate the ERA model (data model) into equivalent Access objects. Therefore, entities
become tables, attributes become fields, and relationships are defined as relationships!
Similarly, the Use Case diagram has already been used to identify inputs and outputs indicated
in the dictionary above. Implementation in Access involves converting these into equivalent
forms and subforms. You might like to try this for yourself (because we have not uploaded an
Anytown database). Over to you to try…
27. Terminology associated with data modelling and

database design
Unfortunately, both for historical reasons, and for others, a variety of
complex vocabulary has built up in the area of database design, and
specifically of normalisation. The literature of normalisation generally
follows the vocabulary established by Edgar Codd. This is based on a
specialised branch of mathematics, and is frankly obscure. I have therefore
deliberately changed the vocabulary in the rest of this document to follow
the Entity Relationship Attribute approach we have been using so far. It is
possible that you will encounter other vocabularies, and therefore I have set
out the equivalences in the table below. The only ones you need to know
are the column headed ERA, and that headed Access. OOAD stands for
object oriented analysis and design, a more recent approach which we do
not teach in the School.
Meaning File Spreadsheet ERA Access Codd OOAD

Class of File (worksheet) Entity Table Relation Class
object,
thing
Instance of Record Row Entity Record Tuple Instance
object, occurrence
thing
Property, Field Column Attribute Field Attribute Attribute
fact about
Relationshi (none) [achieved Relationship Relationshi Relations Associati
p painfully by p hip on
lookup
functions]
Set of all (none) (none) (none) (none) Domain Domain /
possible type
values
Operation (none) Formula (none) Module (none) Operation
/ method
Degree (none) (none) Degree Degree Cardinalit Multiplicit
(1:M etc.) y y
Page 97 of 150
28. References
28.1. Basics of structured analysis

There are a myriad number of books on basic "structured" systems analysis and design
techniques. One which I would recommend for its combination of cheapness and
accessibility is:
Hughes, Martin
Mastering systems analysis and design
Basingstoke: Macmillan, 2000
ISBN 0-333-74803-4 Out of print.
The following book is excellent for setting the techniques used in this document in a
business-oriented context:
Curtis, Graham & David Cobham
Business Information Systems: Analysis, Design & Practice 6ed
Financial Times / Prentice Hall, 2008
28.2. Database theory

The classic reference for students who really want to understand
database theory is the book by Chris Date - Date was a collaborator
with Dr. Edgar Codd, who invented the relational data model, until
the death of the latter in 2003:
Date, Chris
An introduction to database systems (8th edition)
Reading, MS: Addison-Wesley, 2003
This book is frankly difficult at first encounter, but it remains the

classic reference on relational database.
28.3. DataFlow Diagrams (DFDs)

For a tutorial on DFDs, see http://www.cems.uwe.ac.uk/~tdrewry/dfds.htm
28.4. Entity relationship modelling

Entity relationship modelling was originally proposed by Peter Chen in the seminal
article
Chen, Peter
The entity-relationship model—toward a unified view of data
ACM Transactions on Database Systems (TODS) archive, Volume 1 , Issue
1 (March 1976) - Special issue: papers from the international conference on
very large data bases: September 22-24, 1975, Framingham, MA.
ISSN:0362-5915.
I use a simplified version of his notation in this document.
For an additional online tutorial about entity relationship modelling, see
http://www.cems.uwe.ac.uk/~tdrewry/lds.htm
28.5. Use Case

Wikipedia (accessed 26/02/2008) has a useful summary of Use Case diagrams
http://en.wikipedia.org/wiki/Use_case_diagram
See also http://www.systemsanalysis.org.uk/ accessed 15/06/2008.
Page 98 of 150
28.6. Basics of Object Oriented Analysis and Design
(OOAD)
The structured approach is not the only one used in industry – the
more recent object oriented analysis and design approach is
described in books such as this one. OO is conceptually more difficult
than the older structured approach. But if you need a textbook on
this more recent approach, I recommend the following - although it is
NOT suitable for the basic "structured" systems analysis and design
techniques used in this document:
Bennett, Simon & McRobb, Steve & Farmer, Ray
Object-oriented systems analysis and design using
UML 3/e
Maidenhead: McGraw-Hill, 2006
£44.99
A good textbook for initial study of object-oriented analysis and
design. Rather long-winded in places.
Page 99 of 150
29. Appendix 1 Business Process Analysis using Use Case
Analysis
With thanks to Dr. Ken Lunn, former colleague at the University of Huddersfield, whose
material has formed the main basis for this section.
A Use Case is a definition of a meaningful interaction with a computer system. If you have
used the internet to buy things, an example of a Use Case would be choosing something from
an online catalogue, and another might be paying for the goods.
Use Case modelling is part of requirements definition and systems analysis. At the high level, a
set of Use Case diagrams define the presentation of the system, and these are excellent tools
for discussion with stakeholders of a system, such as users and sponsors. At a more detailed
level, Use Cases are used to fully specify the external functionality of a system.
Use Cases are part of the information required by developers to design and implement a
system.
Use Case diagrams say "what" a system does. The detailed analysis of Use Cases begins to say
something of "how" the system behaves in an environment. However, it does not say "how" a
system is structured internally to provide that behaviour. In computer system development you
will frequently see this separation emphasised. Before you decide how a system works, you
need to determine what it does first - a simple and obvious rule, but one so often forgotten to
many people's ultimate regret. That’s why Use Case diagrams (UCDs) and Use Case models
(UCDs with supporting text documents) can be so useful.
29.1. What is a Use Case Diagram?

A Use Case Diagram models a complete business process.
It consists of three key elements:
 ACTORS: People or things that use a system. An Actor might be a
clerk in a business, a manager, or even a customer accessing a
system via the Internet. Other computer systems are also called
Actors. A banking system that you send information to might well
be an Actor in your system.
 USE CASES: A Use Case is a meaningful piece of functionality
provided by a computer system. It can be quite complicated.
Examples would be printing invoices, accepting payment, ordering
goods.
Use case: A use case in a use case diagram is a visual
representation of distinct, identifiable (nameable) business
functionality in a system.
To choose a business process as a likely candidate for
modelling as a use case, you need to ensure that the
business process is discrete in nature. Discrete means
separately and clearly-identifiable.
As the first step in identifying use cases, you should list the
discrete business functions in your problem statement.
Each of these business functions can be classified as a
potential use case.
 RELATIONSHIPS: These are links between Actors and Use
Cases. Actors use Use Cases, and also Use Cases can use other
Use Cases.
We draw a Use Case as an ellipse with the name of the Use Case underneath:
Page 100 of 150
Sometimes the name is put inside:
A Use Case
A Use Case
The Use Case name is a concise, active description of the behaviour carried out by the
Use Case, such as "print invoice". Do not write mini-essays to describe the behaviour
of the Use Case - we shall use a more elaborate means for describing the behaviour in
full.
An Actor is drawn as a stick person:
An Actor
This is rather an unusual choice of notation when it is an external computer system,

but you will get used to it. An Actor is really a role, not a person. One person may use
the system under many different roles. When finding actors, you are looking for the
roles that people adopt, not the people or even the job titles.
Relationships are drawn as lines, usually with an arrow:
A Use
An Actor Case
This means that an Actor uses the Use Case. In any relationship there will be two way
communications. The direction of the arrow indicates who initiates the interaction.
Often in an interactive system, it is the Actor that initiates the dialogue, but it can be
the Use Case. Sometimes the arrow is left out.
A Use Case can use another Use Case. If you have a piece of well-defined
functionality, it makes sense to re-use this wherever possible. Also, sometimes a Use
Case gets too big to manage sensibly and it makes sense to break this down into
smaller Use Cases.
There are two ways Use Cases can relate. The first is where a Use Case "includes"
another Use Case. In this case the second Use Case is always invoked as part of the
execution of the first. This is drawn with an arrow pointing to the Use Case that is
included, with the label <<include>> tagged to the line:
Page 101 of 150

<<include>
>
Add item to sales

Change Invoice
ledger
Please note that the label <<include>> can also be written « include ». Note also that
Microsoft Visio employs <<uses>> or « uses » instead of << include >>.
Sometimes a Use Case is only called occasionally from another Use Case. From the
scenario analysis of the business, this will often be to support an alternative path or an
exception. We draw this with an arrow pointing the other way (yes it is confusing at
first) where the arrow points to the calling Use Case. So below, Chase Payment
sometimes calls Issue Warning Letter.
<<extend>
>
Chase Issue Warning

Payment Letter
So now we have the building blocks for a sophisticated description of a system's
external behaviour. Let us look now at an application that manages payments for
customers. A credit controller might be able to print invoices, chase payments, process
payments, correct invoices, and correct deliveries and register bad debts using a
computer system. Part of chasing payment may involve either issuing warning letters,
where the computer system prints one off, or telephoning the customer, where the
computer system provides a means of the controller logging the results of the
conversation.
Page 102 of 150

Print Invoice
<<extend>>
Customer
Issue Warning Letter
Chase Payment <<extend>>
Telephone Reminder
Process Payment
<<include>>
Correct Invoice
Credit Control
Clerk Receive Payment
<<extend>>
<<extend>>
Correct Delivery
Receive Cheque Receive Bank Credit

Register Bad Debt
With a Use Case Diagram like the one above, you are getting a clear picture of who
uses a system, and what they can do with it. You also have forced some decisions, and
provided some external structure to the system.
29.2. What to do if a use case diagram won’t fit on a single

page?
Answer: split the diagram over several pages, with each page corresponding to a
single area of business activity.
29.3. Finding Use Cases

The first stage of analysis is to map out the business using:
 A High Level Business Activity Model, that breaks a business
down into a simple, three level hierarchy of activities.
 Scenario Analysis of Business Activities, using primary and
alternative path analysis.
 Construction of Business Processes or Business Workflows
from the Scenario Analysis, and described using Activity
Diagrams.
The use of these techniques is not taught on this module, nor is it described in
this document. That is because the scope of activity for the kind of systems
described in the rest of the document is assumed to be relatively small scale,
Page 103 of 150

in relatively clear-cut situations. So you should already know what the
business process is, and you are simply trying to improve it. Once you have a
business process fully defined, you go around all the activities asking the
simple question "is there a potential use of a computer system here?"
Sometimes you may need no system support in an activity in a business
process, sometimes the need for one use case, sometimes many use cases are
needed for a particular business activity.
We are now beginning to see the rudiments of a methodology emerging. It starts in the
business arena, describing the business in some detail. Then it starts to think about
where computer systems are used. The first thing to worry about is what the system
does, and how it fits in to the business, not how it does it in detailed technical terms.
29.4. Naming Use Cases

This section summarises the document “What Makes a Good Use-Case Name?” by
Dr. Use Case (aka Leslee Probasco, Rational Software Canada) to be found at
http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/mar01/WhatM
akesaGoodUseCaseNameMar01.pdf accessed 15/12/2008.
“Auction” is a poor choice of use case name. Is it a noun or is it a verb? Both.
Having clear and meaningful use-case names is very important; it's worth spending the
time on up front to get them right.
Why Should We Care About Use-Case Names, Anyway?
Why should we care so much about what name we give a use case? When
defining the requirements that a part of the business needs, the project team
and customers must agree on scope definition and cost and schedule
estimates. Ultimately they must make the decision to either proceed with the
project or to cancel it (one of the objectives of the inception phase during
which UCDs are initially created).
Often the only information available about the identified actors and use
cases are their names. Along with specified features and other system
requirements, this must be sufficient for all stakeholders to have a clear
enough understanding of the functionality of the system in order to make this
critical "thumbs-up" or "thumbs-down" decision.
Naming use cases should enable anyone (at least anyone familiar with the
problem domain) to be able to look at a use-case diagram -- noting the actor
and use case names, and their associations - and have a pretty good idea of
the value or goal to be achieved by each use case. To accomplish this, it is
very important to choose the names of all actors and use cases with this
objective in mind.
The "Golden Rule of Use-Case Names" suggested by Probasco comes from
the Rational Unified Process RUP. This states that "each use case should
have a name that indicates what value (or goal) is achieved by the actor's
interaction with the system" (if all goes as expected! :>).
Here are some good questions to help you adhere to this rule:
• Why would the actor initiate this interaction with the
system?
• What goal does the actor have in mind when undertaking
these actions?
• What value is achieved and for which actor?
The preference is to have a use-case name that begins with a verb – just as in
a To-Do list. For an ATM system, a to-do list might include actions such as
"Withdraw Cash," "Transfer Funds," "Service the ATM," "Deposit Funds,".
Names like "Cash Withdrawal," "Funds Transfer," "ATM Service," and the
like do not follow this rule.
Page 104 of 150
So: All use-case names should indicate what value or goal is achieved by
the actor(s)' interaction with the system and must be stated in the active
form, beginning with a verb.
29.5. Describing Use Cases

The high level Use Case Diagrams above are fine for a “mile-high”, or “birds-eye”,
view of the computer system’s behaviour. For many stakeholders, such as sponsors
and managers, this will be enough. However, the analyst who thinks the job is done
has a rude awakening. Once you have defined the use cases at the high level, a lot of
work may still be necessary to open these up and define them in detail.
At the very least, the Use Case may need to be described in some detail in a text
document which explains the use case diagram. Sometimes people distinguish
between the diagram alone, the UCD, and the use case model, which is the UCD and
other supporting documentation.
Now we know what the system presents to the various users (or actors), we need to
define in fine detail the "how" of that interaction. Use cases can be further defined as
detailed sequences of behaviour. This is beyond the scope of this simple introduction.
29.6. Using Use Cases to identify System Inputs and Outputs

At every point on a Use Case diagram where an arrow connects a (human) actor to a
Use Case, one or more Forms, Reports or Web Pages are needed to input data to the
process or to output information. You can therefore make a list of these of these
interactions, and state what means (Form, Report or Web Page) is appropriate to that
interaction.
29.7. Other resources for learning about Use Cases

There’s plenty of material about use case modelling on the Web, but much of it is
unnecessarily complicated because it is described as part of the full UML language
which business students should not learn.
One reference is http://www.parlezuml.com/tutorials/usecases/usecases_intro.pdf
accessed 24/11/2008 and written by Jason Gorman.
Page 105 of 150

30. Appendix 2 Data Flow Diagrams
This appendix summarises the steps required in creating a dataflow diagram. Examples of
context, level 1 and a single level two diagram are given earlier in the document, in the
University of Anytown business school case.
Creating a DFD is a process also called Data Flow Modelling: the process of identifying,
modelling and documenting how data moves around an information system. Data Flow
Modelling examines processes (activities that transform data from one form to another), data
stores (the holding areas for data), external entities (what sends data into a system or receives
data from a system), and data flows (routes by which data can flow).
30.1. What are Data Flow Diagrams (DFDs)?

♦ DFDs are diagrams that show how data flows within a
system
♦ They are initially created as two simple HIGH LEVEL
diagrams: the Context Diagram and the Level One Data
Flow Diagram (DFD)
♦ Parts of the high level diagram may then be ‘exploded’
(alternatively, expanded or zoomed) to show more detail
♦ DFDs represent the flow of data between different
processes within a system, together with the original
flows of data into the system and the output flows of
information from the system to its users, clients or other
consumers
∗ The idea is that the diagrams be simple and
intuitive, not focusing on details
∗ They should describe what the users of systems
do,
do rather than what computers do
♦ Limitations:
∗ Focus only on flows of information (not physical
flows of goods)
∗ The diagrams therefore ignore flows of materials
∗ Nor do they show how a process works: its
decision points (if this, then this, otherwise this) or
repetitions – such diagrams, sometimes called
flowcharts, are NOT a part of the approach
documented in this booklet
30.2. Why use Data Flow Diagrams?

♦ They are a technique used in structured analysis, that is,
a tool used by the systems analyst for analysing
requirements
♦ They are also a communications aid
∗ Between user and analyst
∗ Within an analysis team
Page 106 of 150
♦ The diagrams can be used to solve disagreements about
how work is being done or how it should be done in the
future
30.3. What is a DFD? Main elements

♦ Context diagram
♦ Sources and Recipients of information (“external
entities”)
♦ Main system inputs and outputs
♦ Main data stores
30.4. The components of a DFD

A complete DFD is a hierarchical set of diagrams:
♦ One Context diagram
∗ Shows the system boundary by indicating the
name of the main process in the system, and the
External Entities which lie outside the system
∗ Summarizes the main data flows into and out of
the system
∗ The Context diagram defines the system
boundary: what is a part of the system under
study (and what is outside it); this also sometimes
called the scope of the system
∗ Defines data flows to, and information flows from,
a system
∗ Identifies the data flows and stores within the
system
∗ Identifies the functions (processes) performed by
the system
♦ Levelled set of DFDs
∗ One Level 1 DFD, which identifies the business
processes and breaks them down into
subprocesses
∗ Several (2 to 10, typically 7) Level 2 DFDs
♦ Main system functions (processes), the key functions,
appear as Level 1 DFDs
♦ Where necessary, explode level 1 DFDs into component
level 2 DFDs
∗ This means that there are parent and child
processes
∗ Consider parent as a window onto its children
∗ Possible to look at a process at any level of detail,
so may need Level 2 diagrams, or even Level 3
Page 107 of 150

♦ All key documents should be identified as data flows
Structure of a Data Flow Diagram ,

showing that it is a hierarchical set of
diagrams
Context
University of Anytown Student System There is one and only one Context diagram in a DFD
L1 DFD There is one and only one Level 1 diagramin a DFD

University of Anytown Student Applicant
System
L2 DFD process 4
L2 DFD process 1 The L 1 DFD identifies between two and seven /eight
Prepare for and hold exam
Process applications main processes ; each such main process may be
board
expanded into a Level 2 DFD (here , only two are shown
L3 DFD process 1
L3 DFD process 2 L3 DFD process 3 The L 2 DFD identifies between two and
NB: this is NOT a DFD; this diagram shows the STRUCTURE
Collect module results and
produce student profile
Review moduleof a DFD!
results Decide student status main processes ; each such main pro
expanded into a Level 3 DFD (he
30.5. What appears on a DFD?

There are only FIVE kinds of thing on a DFD:
♦ Processes
A Process takes data in and processes it to create output
data or information; the inputs are modified or
transformed in the process of generating the outputs.
Processes can often be identified in the real world with
actions undertaken by individuals or whole departments.
For example, a sales representative is part of a process
Take Order. That process may itself be a part of (a sub-
process of) the larger process, Fulfil Order.
♦ External entities
An External Entity is a source of data to the system as a
whole, or a client or consumer of information (processed
data) produced by the system. They are outside of the
system being modelled. External Entities are terminators
which indicate where data comes from and where output
information goes to. In designing a system, we have no
idea about what these terminators do or how they do it.
♦ Data stores
A Data Store is a place where data is stored: typically, a
folder in a filing cabinet (a paper file) or a file in a
computer. Data Stores represent a place in the process
where data comes to rest. A DFD does not say anything
about the relative timing of the processes, so an example
data store might be a place to accumulate data over a
year for the annual accounting process
♦ Data flows
∗ Data flows in from an external entity, another
Page 108 of 150
process, or a data store
∗ Data flows out to an external entity (in this case it
is information), or to another process or a data
store
Data flows may sometimes be obvious in the real-world as
documents, such as order forms (a data flow into a Fulfil Orders
process) or invoices (a data flow out from a Bill Customers process).
♦ Elementary process descriptions
A process which is relatively simple and straightforward is NOT
broken down into sub-processes; instead, it is described in a
paragraph or so of text called an Elementary Process Description
30.5.1.Listing the elements of a DFD

Analysts normally identify and list the main elements of a DFD on paper or in
a spreadsheet before they go on to make the actual diagram. This list of
elements is sometimes formally maintained as a Data Dictionary.
30.6. The Data Flow Diagram Symbols – SSADM Notation
1 A Process box
The Number and Description is the
Process same as in the Elements List (data
Description dictionary)
A Data Store
D1 Name of Data Store The Number and Description is the
same as in the Elements List
Source or Source/Destinatio
Destination n
Arrows show DATA FLOWS
30.7. Making a Data Flow Diagram: a Top-Down Approach

♦ The systems analyst makes a context level DFD, which
shows the interaction (data flows) between the system
(represented by one process) and the system
environment (represented by external entities).
♦ The system is decomposed in a lower level (Level 1) into
a set of processes, data stores, and the data flows
between these processes and data stores.
♦ Each process on the Level 1 diagram may then
decomposed into an even lower level diagram (Level 2)
Page 109 of 150
containing its subprocesses.
♦ This approach then continues on the subsequent
subprocesses, until a necessary and sufficient level of
detail is reached which is called the primitive process.
♦ A primitive process is briefly described in natural
language (English, French etc.) This description is
sometimes called an Elementary Process Description.
30.8. The elements of a DFD

Every page in a DFD should contain fewer than 10 components. If a process has more
than 10, exceptionally 20, components, then one or more components (typically a
process) should be combined into one and another, lower-level, DFD be generated that
describes that component in more detail. Each component should be numbered, as
should each subcomponent, and so on. So for example, a top level DFD would have
components 1 2 3 4 5; the sub-component DFD of component 3 would have
components 3.1, 3.2, 3.3, and 3.4; and the sub-sub-component DFD of component 3.2
would have components 3.2.1, 3.2.2, and 3.2.3
♦ Context diagram (one only)
♦ Level 1 DFD (one only, identifying up to seven / eight
main processes)
♦ Level 2 DFDs (two to seven / eight in number)
♦ All key documents should be identified as data flows
♦ Key processes or functions appear in Level 1 DFD
♦ Where necessary, explode level 1 DFD into component
level 2 DFDs
∗ Parent and child processes
∗ Consider parent as a window onto its children
30.9. Creating DFDs

♦ Pencil and paper: often good enough, especially for a
first draft
♦ Can use MS Draw in Word, PowerPoint
∗ Very painful!
♦ Drawing packages
∗ MS Visio Professional
(a) Comprehensive but expensive
(b) In Visio, the DFD is called a data flow model

diagram in the "software" category, or
diagramme de modèle de flux de données in the
“logiciels” category
(c) SSADM support is no longer provided in the

standard Visio product
Page 110 of 150

MS Visio is now available to ESC students via the
Microsoft Developers’ Network Academic Alliance
MSDNAA Electronic Licence Management System ELMS.
You should by now have received an email from
Microsoft’s agent e-Academy telling you how you can
profit from this scheme.
In order to create a drawing of a particular kind, you use
both a template file and a stencil file. These together tell
Visio what kind of symbols can be used. The equivalent
terms in French are un modèle and un gabarit.
For more information on Microsoft Visio and its use, please
see appendix 4.
∗ SmartDraw (www.smartdraw.com)
(a) Slightly less expensive
(b) There’s also a free time-limited trial edition

This product has built in support for SSADM, and is
significantly cheaper than Microsoft Visio. However, it is
much less widely used, and there is much less third party
support for this product. So although it is an excellent
product and quite appropriate for the work you will do on
this module, it is unlikely that you will be using it in your
professional life.
∗ EDraw (http://www.edrawsoft.com/)
This new product also has good support for SSADM, and is
significantly cheaper than Microsoft Visio. However, it is
much less widely used, and there is much less third party
support for this product. So although it is an excellent
product and quite appropriate for the work you will do on
this module, it is unlikely that you will be using it in your
professional life.
∗ Dia
So far, the open source software available does not seem to
me to be as good as it needs to be seriously to compete with
Visio. Sadly, there is as yet no open source software that I
can identify which is of sufficient quality to recommend in
the area of drawing and computer aided software
engineering. You might consider Dia, which is an open
source diagramming package which can be used to create
some analysis diagrams.
♦ CASE tools: Computer Aided Software Engineering
Professional systems analysts often work in a project
environment in which they and other developers
(programmers, etc.) use comprehensive packages
called CASE tools to document an entire system
development and implementation approach. The
market leading CASE tool is IBM’s Rational Rose
product. It is far too complex to be used by business
professionals alone and unaided, although business
specialists are a very important part of the overall
project team (they, systems analysts, designers,
programmers, etc.) which carries out large information
systems projects.
Page 111 of 150
30.10.First List the Elements of the Data Flow Diagram
♦ The Sources or Destinations of Data
∗ Where the data comes from or goes to
(sometimes called External Entities)
♦ The Processes
∗ The processes that use or change the data
♦ Documents: flows of data
The documents used in or created by a process - for example, paper
reports output by a system; paper forms used to “capture” (record)
data for input into a system – are often a very good starting point for
initial systems analysis. Sometimes, in complex systems, flows of
data between processes are also distinct documents.
♦ The Data Stores
∗ Repositories of data (can be card indexes,
folders, computer files, documents)
30.11.Drawing the Context Diagram

This level shows the overall context of the system and its operating environment and
shows the whole system as just one process. It does not show data stores.
A context diagram is a top level (sometimes also known as Level 0) data flow
diagram. It only contains one process box that generalizes the function of the entire
system in relationship to external entities.
♦ Draw a box to represent the system under study and give
it a name
♦ Add the External Entities outside the system box
♦ For each data flow, put directional arrows from and to the
external entities to and from the system box
♦ Label the data flows; typically these are documents, they
may also be other kinds of message
30.12.Expanding a context diagram to give a level 1 DFD

♦ Draw a big box to contain the expanded diagram
♦ Name it across the top
♦ Add the data flows entering or leaving the box
♦ Work back from a flow leaving the box to identify the sub-
process (child process) which creates that output flow
and add it to the diagram
♦ Identify the data flows which are inputs to that process
♦ Those data flows may be the direct outputs of other child
processes; or more often, such another child process
outputs to a data store which is then intermediate
between the two child processes
♦ Number the child processes; if there are more than seven
or eight, it will be necessary to group together some
Page 112 of 150

processes at this level, and create a Level Two diagram
for that process
30.13.Questions to ask yourself

♦ For each process in the top level DFD:
∗ Does it need to read from or write to a data store?
∗ Does it send data to or read it from another
process?
∗ Does the process have access to all the data it
needs?
∗ Does it need to be specified in more detail, using
a Level 2 diagram, or is it simple enough to
describe in (possibly, structured) English as an
Elementary Process Description?
30.14.Rules for DFDs

♦ Process name has form imperative-verb followed by
object (noun phrase), e.g. Enrol students
∗ Not “Enrolment” – which is a noun
♦ All processes and data stores must somewhere have
data going in to them and away from them
♦ All data flows must start from or end with a process -
otherwise, what makes them happen?
30.15.Some points on logical DFDs

♦ Arrows show DATA flows - not the sequence of
processes, nor physical flows
♦ Sources and Destinations NEVER connect directly to a
Data Store – always Processes
♦ A Process must have at least one Data Input and one
Data Output
♦ Arrows not to or from data stores should be labelled with
the data that is flowing
30.16.Supporting documentation
♦ Elementary Process Descriptions
∗ Description in natural language of a process
which is not further exploded in lower-level
diagrams
∗ Shouldn’t need to be long – if it is, may indicate
need for another level of diagram
♦ The list of elements - External entity list, etc – which is
typically stored in a Data Dictionary
Page 113 of 150

30.17.Summary: “levelled” DFDs
The output of the whole process of analysing processes (!) is sometimes referred to as
a Levelled Data Flow Diagram. A Levelled DFD consists of:
♦ One Context diagram
♦ One Level one DFD
♦ Multiple level two DFDs (two to seven/eight in number)
♦ (Rarely) level three DFDs (two to seven/eight in number
for each level two process which needs explosion)
♦ Elementary Process Descriptions where necessary
Page 114 of 150

31. Appendix 3 When to use a spreadsheet, and when to use a
database
31.1. Introduction
We normally store data on computers when we have many occurrences of a specific
kind of record, and we want to process specific records, or complete set of records.
For example, we may want to maintain a list of companies. For purposes of
comparison, we will normally choose to store the same items of data about each
occurrence. For example, we will store the name of each company, its principal sector
of activity, and the address of its global headquarters. A widely accepted way of
storing data, indeed, we may even refer to it as the “natural” way to store such data, is
by means of two-dimensional tables.
Many widely used office productivity programs provide good facilities for storing two-
dimensional tables. We can use a word processing program, such as Microsoft Word; a
spreadsheet, such as Microsoft Excel; or a database, such as Microsoft Access. However, each
program has specific strengths and weaknesses when it stores data in this way. Refer back to
section 2.6 for more on this.
31.2. Spreadsheets versus databases
31.2.1.What spreadsheets are good at

∗ Spreadsheets combine conceptual simplicity, very
powerful data manipulation and analysis facilities,
and good information presentation facilities
∗ Spreadsheets are easier to design and to use
than are databases
∗ It is comparatively easy to involve the use of a
spreadsheet as the context of its use changes
∗ Functions make it easy to use previously
programmed data analytical techniques
∗ It is possible to program new functions, or to have
them written for you so that you can use a specific
data analytical technique
∗ Recent versions of Excel have excellent
presentation facilities and they also connect very
well to Word or PowerPoint
31.2.2.What databases are better at

∗ Spreadsheets are by their very nature highly
insecure – anyone who can access a spreadsheet
can see all the data in that spreadsheet; industrial
strength databases make it impossible for users
who are not privileged to see data to do so
∗ Spreadsheets can rapidly become very complex,
and it is very difficult to understand what the
overall structure of the spreadsheet is; as a result,
they can become a nightmare to maintain
∗ It is difficult for more than a very small number of
Page 115 of 150
people to use a single spreadsheet at one time,
and almost impossible to stop them from
interacting with each other, often in a conflicting
way
∗ Spreadsheets can handle at the most a few
thousand records; databases can handle millions
∗ Databases can support tens, or even thousands,
of simultaneous users
31.2.3.Using spreadsheets and database together

Microsoft Office is an integrated suite of programmes. As a result, there are
many different ways in which Microsoft Excel and Microsoft Access can be
made to work together. In the most difficult cases, it will be necessary to
programme this interchange using the Microsoft Office Automation feature.
However, this is often not necessary. As stated in
http://www.dummies.com/WileyCDA/DummiesArticle/id-2128.html,
(checked 20/11/2008) “You can do plenty of importing and exporting data
between Microsoft Office applications without writing any code at all. For
example, you can perform the following actions:
• Import and export data by using options on the Access File menu.
• E-mail Access objects, such as reports, by choosing Send To --> Mail
Recipient.
• Use the OfficeLinks feature to send objects to other programs.
• Use basic Windows cut-and-paste techniques and OLE (Object Linking and
Embedding) to copy and link data between programs.
• Merge data from Access tables to Microsoft Word letters, labels, envelopes, or
other reports, using the Word Mail Merge feature. (Search the Word Help
system for merge.)
If you're just looking to get data from Access to another program (or vice
versa), writing code is probably not the easiest approach. Any of the previous
approaches are easier than writing custom VBA code to do the job.”
If you wish to incorporate data stored in Microsoft Access and manipulate it
in a Microsoft Excel spreadsheet, for example because you wish to create a
monthly report with charts and graphics, you can create a query which
extracts the data from several tables and then sends the results to Microsoft
Excel in the form of an external data range.
In the opposite direction, it is possible to create a list of data in Excel and
make it available in Microsoft Access as though it were an external table. Or
you can use a Microsoft Access form to enter data into Excel. For further
information, see the online help facility in each of the two products.
31.2.4.Summary
When you are manipulating data for yourself alone, or as part of a small
team, or in a very small business, spreadsheets are likely to be more intuitive,
initially more productive and easier to get started with. However, as the
volumes of data, or the number of users, increase, databases become much
the preferable option. It is often a sensible and viable option to prototype the
requirements for a small business information system using a spreadsheet,
and then, when the requirements are quite clear, to transfer the data storage
element to a database.
See also http://www.epinions.com/content_972857476 (checked 20/11/2008)
Page 116 of 150

31.3. What to do if your spreadsheet skills are weak
Almost all business professionals need to be more or less able to use a spreadsheet. If
you are not confident that you can use formulae in spreadsheets to carry out
moderately complex data analysis, I suggest that you follow tutorials that you can find
using Google. Here are a few suggestions – though they are unlikely to be the best
ones:
Spreadsheet – Link to Excel tutorials
Microsoft’s
(http://office.microsoft.com/en-gb/training/CR100654561033.aspx)
own tutorials
Spreadsheet – http://www.yevol.com/excel2003/index.htm
Excel 2003 -
English
Spreadsheet – http://translate.google.com/translate?u=http%3A%2F%2Fwww.yevol.com
Excel 2003 - %2Fexcel%2Findex.htm&sl=en&tl=fr&hl=en&ie=UTF-8
français
Spreadsheet – http://www.yevol.com/excel/index.htm
Excel 2007 -
English
Spreadsheet – http://translate.google.com/translate?u=http%3A%2F%2Fwww.yevol.com
Excel 2007 - %2Fexcel%2Findex.htm&sl=en&tl=fr&hl=en&ie=UTF-8
français
31.4. What to do if your database skills are weak

Work through some or all of an online tutorial guide – there are some excellent
Access tutorials available on the World Wide Web. See what you can find for
yourself using Google; here are some suggestions:
Database – Link to Access tutorials
Microsoft’s
(http://office.microsoft.com/en-gb/training/CR100654561033.aspx)
own tutorials
Database – http://www.yevol.com/en/access2003/index.htm
Access 2003 -
English
Database – http://www.yevol.com/access2003/index.htm
Access 2003 -
français
Database – http://www.yevol.com/en/access/index.htm
Access 2007 -
English
Database – http://translate.google.com/translate?u=http%3A%2F%2Fwww.yevol.com
Access 2007 - %2Faccess%2Findex.htm&sl=en&tl=fr&hl=en&ie=UTF-8
français
Alternatively and / or additionally, if you were here in your first year, revise the work
that you carried out on Access in the second semester of the first year.
Page 117 of 150

31.5. Conclusion
There is usually more than one way to skin a cat, as we say in English! There are
certainly many ways of storing data. Each program has specific strengths and
weaknesses. You are advised to consider very carefully who it is that requires what
information, who collects the data, what kind of transformation is required between
the input data and the output information, and then to choose the right program – or
programs. For it is no coincidence that Microsoft, and other vendors, sell office
productivity suites. A suite is a collection of programs, each program having specific
strengths and weaknesses. Microsoft Office is just such a suite. As such, it provides
many ways to store data using one program, and to link to that data in another. A very
common scenario is that the data is stored in a database, while required output
information is presented using the data analytical features of a spreadsheet. A good
workman knows his or her tools, and chooses the appropriate tool for the job!
31.6. Acknowledgements – bibliography for Appendix 31

http://www.sjsoft.com/
Thanks to St James Software http://www.sjsoft.com/ for the

original material on which I based this appendix.
http://www.epinions.com/content_972857476
(checked 20/11/2008) Thanks to Epinions; see

http://www.epinions.com/about/ for information about this
organisation.
Page 118 of 150

1. Appendix 4: Reasons why a database is to be preferred to
a spreadsheet - Spreadsheet Does Not Equal Database
This section was taken from http://www.pcmag.com/article2/0,2817,1435148,00.asp (checked
24/11/2008), an article which originally appeared in the United States edition of PC Magazine,
dated February 3, 2004. This material is Copyright (c) 2004 Ziff Davis Media Inc. All Rights
Reserved.
“
♦ February 3, 2004
♦ By Helen Bradley
Since the days of Lotus 1-2-3, people have used spreadsheet programs for everything
from word processing to data management. Doing the former is silly. Doing the latter,
however, is viable, especially in the latest version of Microsoft Excel. But though you
may be more comfortable with Excel, a real relational database program like
Microsoft Access is a better choice for managing data—for a number of reasons.
♦ Databases are safer. Excel, for example, does everything
in memory, so that any unsaved data may be lost if your
system crashes. Databases write data to the hard drive
immediately.
♦ Databases can handle more data. Sure, Excel can
technically handle more than 65,000 rows of data, but
doing so will likely bog down even the fastest PC.
♦ Databases can easily link tables of related data together,
such as customers and orders or musical groups and
albums (as well as the songs on each album). This is
where the words relational and database come together.
Storing related data together in a single table or
spreadsheet can be unwieldy and invite errors.
We'll look at a situation for which Access is a better tool than Excel and show you how
an Access solution works. If you've never used Access before, that's okay; we'll walk
you through how to create everything from scratch. We used Access 2002 for the
instructions, but you'll find the process is similar in all versions of Access. We chose
Access because so many users have it already, but you can do the same things in other
relational databases such as FileMaker or Microsoft SQL Server. For more on picking
the right database, see "Databases for All Reasons" in our issue of January 2003 at
http://www.pcmag.com/article2/0,1759,760886,00.asp (checked 24/11/2008).
1.1. More Than a List

Consider a veterinarian's office: To record pet and owner details, you could use a list
in an Excel worksheet, but you'd encounter difficulties. If you create one record for
each owner, how would you handle an owner with multiple pets? You could add a
field for each pet, which would work for most clients. But a client who runs a
breeding kennel with 25 cats and innumerable kittens would force your data record to
grow to an excessive length.
On the other hand, if you organize your data so you have one record per pet, you
would have to enter the owner details for each pet in the household. This is
unnecessarily repetitive. And if an owner changes his address, you would have to find
and update all his pets' records individually.
The better solution is to have two lists—one with the owner details and one with the
pet details—and then link the two by including a field in both lists with a common
Page 119 of 150

piece of information. For example, give each owner a unique code number, which you
can then use in his pets' records. That way, you can find a pet, check the owner code,
and then find the owner's details in the owner file. Likewise, you can look up an
owner, find his code, and then extract all the pet records with that owner number.
Although you have two lists, each owner and each pet has only one entry in the
system. It's neat and efficient, and it solves another problem our veterinarian may
encounter: When client breeders sell kittens to new owners, the new owners may
become clients, too. To change a pet from one owner to another, simply change the
owner code in the pet's record and if necessary add a new owner record.
1.2. Create the Database

To create the database requires two tables, one for owners and one for pets, with a
field common to both—the owner code. We will set up the relationship between the
two tables and add a form to make it easier to enter data.
Each table needs a structure that includes a list of field names and types, as well as the
sizes of the fields. Each table must also have a primary key—a field that contains a
piece of information unique to that record. In the owner's table, the primary key is the
owner code; in the pet table, we'll use a similar field called the pet code. We will use
an AutoNumber field type for each. Access will then assign a unique sequential value
to that field for each record.
To build your database, launch Access, choose Blank Database from the task pane,
and name your file PetHosp.mdb. Click on Create then double-click on the Create
table in Design view option. The Table1:Table dialog will appear. Type Owner Nr as
the first field name, then tab over to the next column and enter AutoNumber as the
Data Type. (Access automatically completes the entry once you've typed the first
letter.) Now enter the rest of the data as shown on the next page. Here are the fields
and types:
Field Name Data Type
Owner Nr AutoNumber
Surname Text
First Name Text
Title Text
Address 1 Text
Address 2 Text
Town Text
Postcode Text
Date Created Date/Time
If you want, you can add a description for each field to explain its contents as well as
a caption. The caption is a name that is used in place of the field name in reports and
forms. If you use shortened or cryptic field names, captions are a good idea.
To set a primary key, right-click on the area to the left of the Owner Nr field and
choose Primary Key. A key icon will appear, indicating that the field is the primary
key. Save the file with the name Owner, and click on the table's Close button.
Repeat this process to create a second table for pets with these fields:
Field Name Data Type

patient no AutoNumber
patient name Text
owner code Number
Page 120 of 150
animal type Text
condition Text
treatment date Date/Time
leave date Date/Time
date of birth Date/Time
Set patient no as the primary key, name the table patients, and close it.
Once you have created the tables, you can define the relationship between them.
When you do this, Access helps you maintain your data integrity. For example, you
can set up the relationship so that removing an owner automatically removes any of
his pets from the patients table.
Choose Tools | Relationships. When the Show Table dialog appears, click on the
Owner table and then select Add. Do the same with the patients table and then click
on Close. Small dialogs will appear, showing the structure of the two tables. Drag the
ClientNo field from the Client table and drop it on the ClientNo field in the Pets table.
When you let go of the mouse button, the Edit Relationships dialog appears with these
two fields listed. Select the Enforce Referential Integrity check box and the Cascade
Delete Related Records check box. This ensures that if an owner is removed, all his
pets are removed, too. Click on Create to set up the relationship, which is one-to-many
—one owner can have many pets (Figure 1). Click on the window's Close button and
answer Yes when prompted to save the changes.
Figure 1
Owner and Patients have a one-to-many relationship.
Now you can enter data into the tables. Click on Tables in the Objects bar and double-
click on Clients to open it in datasheet view. Type the following data into the table
(the number in the Owner Nr field will be entered automatically):
Page 121 of 150

Owner First Address 1 Address 2 Town Post- Date
Surname Title
Nr Name code Created
1 Brown Joe 12/12/98 1 Blah St Downtown Athens 12345 01/04/04
2 Smith Anne 2/2/2000 2 Blah Avenue Uptown Athens 12345 12/04/04
3 Green Rick 5/5/2000 3 Blah Blvd Trackside Atlanta 56789 15/04/04
Close the table and then repeat the process to add the following data to the Pet table
(the patient no will be added automatically):
patient owner animal patient condition treatment leave date date of birth
no code type name date
1 2 Cat Peaches fever 30/04/2004 01/05/2004 01/04/2003
2 1 Dog Sam 01/04/2003
3 3 Horse Dobbin 03/03/1999
4 3 Cat Ginger 01/04/2003
1.3. Create a Data Entry Form

Although you could continue to add data using the two tables separately, it's easier to
use a form that displays all the related data. Access can do this for you. Close both
tables and click on the Forms icon in the Objects bar and double-click on Create form
by using wizard.
From the Tables / Queries drop-down list choose Table:Owner and click on the double
angle brackets (>>) to move all the Available Fields to the Selected Fields pane. Then
choose Table:Patients and move only the animal type and patient name fields from the
Available Fields to the Selected Fields pane. Then click on Next.
Access will ask you, How do you want to view your data? Choose by owner and click
on the Form with subform(s) option and then choose Next. When prompted, select
Datasheet as the layout type for the subform and choose Next. Pick a style for your
form (any will do) and click on Next. Type a form name, such as Owner and patient
details, click on Open to view or enter information in the form and click on Finish to
end.
A form appears on the screen with the client data on top and the details of the pets
belonging to the client in a table below (Figure 2). You'll see two sets of record
navigation tools. The one at the bottom of the table is for the patients subform and the
other is for the owner records. Click on the Next Record button for the Owner data
and you will see that pets are displayed for that owner.
Figure 2
Now you can add a new owner and his pet, as well as add a new patient to one of the
existing clients. To see what is happening behind the scenes, close the form and open
the patients table. You'll see that the data has been entered into the fields patient no
and owner code, even though neither field was included on the form. The patient no
Page 122 of 150
number is automatically entered, because the field type is AutoNumber and the owner
code field is automatically set to the owner’s number, since the records are related
through the form's design.
Remove a client from the Clients table by opening the table, selecting the client, and
clicking on Delete. You'll be warned that a record in another data file will be affected
(the client's pets will be removed when the client is). This is the result of selecting the
Cascade Delete Related Records check box when setting up the relationship. The same
does not work in reverse and it is possible to have a client with no pets in the Clients
table.
”
Page 123 of 150

2. Appendix 5: Access Hints - Designing for Use
The whole point of using Microsoft Access is to permit the safe, effective
and efficient storage of data in tables so that information can be retrieved
from them. We have seen that this involves analysing what data is to be
stored in what tables. Designing a set of database tables which correctly
reflects the structure of the data is, as we have seen, very important.
However, almost as important is
♦ To ensure that users of the database can get out
the information they are looking for - this is done,
in technical terms, using reports and forms and
queries;
♦ To enable users easily to put correct data into the
underlying tables – this is done using forms and
subforms.
In this section, we will suggest that the best way in which to get data into a
database is to use forms and subforms which are based on the relational
structure of the data. Very approximately, we will use forms and subforms
which correspond to master and detail tables.
2.1. Getting more help

The web is crucial to learning more about Microsoft Access and in
particular for getting help with problems which you find too difficult
to solve alone. There are many forums in which people help each
other. There are many people who are very anxious to help by
writing about how they have solved problems which probably
seemed complicated to them when they first encountered them!
A key to getting help is to formulate your Google query very
carefully, adding just the right keywords. For example, when writing
this appendix, I used the Google search:
I found material helpful to my writing in the first three sites which

Google displayed! They are:
♦ http://www.microsoft.com/communities/newsgrou
ps/en-us/default.aspx?
dg=microsoft.public.access.queries&tid=462cbebf
-5bef-437b-88f6-
fbf70e774da0&cat=&lang=&cr=&sloc=&p=1
♦ http://articles.techrepublic.com.com/5100-
10878_11-5285168.html
♦ http://www.access-
programmers.co.uk/forums/showthread.php?
t=170227
2.2. Unlocking the power of many-to-many

relationships
Page 124 of 150
The examples here are based on the following database structure:
In this database, the many-to-many between Student and Module

Operation has been resolved by introducing link entity Module
Registration. But how do we make it easy for the database user to
input data into the database and to get it out again?
The answer requires the use of forms and subforms that are based
on one of the two “owning” tables and the link (junction, intersection)
table. Using the nomenclature introduced on the diagram, we can
refer to an A side of the many to many between Student and Module
operation and a B side. Which we take as A and which as B is a
matter of choice.
You base the parent form on the A side of a relationship – here, on
Module Operation.
You base the subform on the junction table.
You then use a combo box based on the table on the other side of
the junction table, the B side – here, on Student. The combo box goes
on the subform.
In summary, to do data entry for a many to many relationship, use
the two main tables and their junction table to create a form,
subform and combo setup.
More generally, when accommodating a many-to-many relationship
via an associate table, you'll need to base forms on a query which
combines the fields from the various tables involved. Make sure that
this query includes all the non-key fields you may want to modify or
may need from both the many and the one table, and, if necessary,
from other tables as well. It is also essential that the foreign key that
represents the one side from the associate table be included.
Page 125 of 150

Consider the following example. Assume that you are the module
leader responsible for the operation of a module in a given year and
that you want to manage students for whom you are responsible.
The steps you should follow are these:
♦ You will create a form with subform based
on a query, which in this case I have called
Module Operation Registration. (I’ve included all
the main fields from Module, Module Operation,
Module Registration and Students because I use
the same query in several forms.) Using the
nomenclature introduced above, Module Operation
is on the A side (as is its parent entity, Module).
♦ Create a form – subform - subform based on

the query (here for Module, Module Operation
and Module Registration as combined in the query
Module Operation Registration). Ensure that, as a
minimum, the fields displayed include all the
elements of all the primary keys of the tables.
♦ Turn the foreign key corresponding to the
primary key of the B side of the many-to-
many into a combo box. Here, turn the Student
no field in the subform into a combo box. That
combo's rowsource needs to independently query
the Students table so as to return the possible
values of Student no. When you choose a value it
is inserted as the bound field. Your combo box
therefore needs to include the student number,
but also a concatenation of first and last names of
the Students, so you have some meaningful data
from which to select. This will enable you to
choose an existing student from the list (or even
enter a new one, although this is probably
undesirable). To accomplish this task, open
the completed form in Design view and
change the foreign key field's bound control
to a combo box. (Right–click the control, choose
Change To, and then select Combo Box.) Set the
combo box control's Row Source property to an
Page 126 of 150
appropriate SQL statement11:
SELECT DISTINCT [Module Operation
Registration].[Student no], [Module
Operation Registration].[Student surname],
[Module Operation Registration].[Student
forenames] FROM [Module Operation
Registration] ORDER BY [Student surname],
[Student forenames];
♦ In addition, set the Column Count property to 3 (so
that the three fields in the SELECT statement will
be displayed). Return to Form view and display the
control's drop-down list.
11
You don’t need to create this SQL statement yourself. Instead, separately create a query that
combines the fields that you need in the usual way, using Design mode (mode création). Test that it
works, then display it in SQL mode. Copy the SQL SELECT statement that Access has generated and
use it to replace the SELECT statement in the Row Source mentioned above.
Page 127 of 150
2.3. Some difficulties associated with forms and
subforms and how to overcome them
The examples here are based on the following database structure:
2.4. Subform not updated

A common problem is that when you scroll through records in
the main form, the subform is not updated. The records on the
main form and the subform are not synchronized. This is
because the subform is not always automatically linked to the
main form.
When you create a subform or subreport by dragging a form
or report from the Database window onto another form or
report or by using the Form Wizard, Microsoft Access does
automatically set the LinkChildFields and LinkMasterFields
properties, but only under one of the following conditions:
∗ Both the main form or report and the child
object are based on tables, and a
relationship between those tables has been
defined with the Relationships command.
Microsoft Access uses the fields that relate
the two tables as the linking fields.
∗ The main form or report is based on a table
with a primary key, and the subform or
subreport is based on a table or query that
contains a field with the same name and the
same or a compatible data type as the
primary key. Microsoft Access uses the
primary key from the main object's
underlying table and the identically named
field from the child object's underlying table
or query as the linking fields.
Page 128 of 150
Recalculation occurs automatically for controls that reference
other fields on the same form or fields in subforms.
Recalculation does not occur automatically for subform
controls that only reference fields on the main (master) form
or in other subforms.
This is because subforms notify the main form of any
changes, but the master form does not notify the subforms of
changes. Nor do subforms on the same main form notify one
another of any changes.
Otherwise, it is necessary to set these properties explicitly. A
common situation is where it is necessary to incorporate an
existing form as a subform to a newly-established one.
Because setting the properties changes the definition of the
existing form, it is wise to take a new copy of the existing form
and to work with that, rather than the original.
SOLUTION: Setting LinkChildFields, LinkMasterFields
Properties explicitly
You should use the LinkMasterFields and LinkChildFields
subform control properties to link the main form and subform
automatically. You can manually update the subform by
pressing the F9 (recalculate) key.
You can use the LinkChildFields and LinkMasterFields
properties together to specify how Microsoft Access links
records in a form or report to records in a subform, subreport,
or embedded object, such as a chart. If these properties are
set, Microsoft Access automatically updates the related record
in the subform when you change to a new record in a main
form.
You can set the LinkChildFields and LinkMasterFields
properties for the subform, subreport, or embedded object as
follows:
∗ The LinkChildFields property. Enter the
name of one or more linking fields in the
subform, subreport, or embedded object.
∗ The LinkMasterFields property. Enter the
name of one or more linking fields or
controls in the main form or report.
You can use the Subform/Subreport Field Linker to set these
properties by clicking the Build button to the right of the
property box in the property sheet.
You can use the name of a control (including the name of a
calculated control) to set the LinkMasterFields property, but
you can't use the name of a control to set the LinkChildFields
property. If you want to use a calculated value as the link for a
subform, subreport, or embedded object, define a calculated
field in the child object's underlying query and set the
LinkChildFields property to the field.
When you specify more than one field or control name for
these property settings, you must enter the same number of
fields or controls for each property setting and separate the
names with a semicolon (;).
Page 129 of 150

Note The linking fields don't have to be included in the main
object or in the child object. As long as they are contained in
the objects' underlying tables or queries, you can use the
fields to link the objects. When you use a wizard, Microsoft
Access automatically includes the linking fields.
2.5. Detail subform does not show the subset of

records based on the value of the current
master form record
Unless you take specific action, a detail subform does not
show the subset of records based on the value of the current
master form record when that master form record changes.
SOLUTION
Solving this problem requires both SQL and some simple VBA,
which deals with certain events.
Event programming is a very powerful tool that you can use
within your VBA code to monitor user actions, take
appropriate action when a user does something, or monitor
the state of the application as it changes.
An Event is an action initiated either by user action or by
other VBA code. An Event Procedure is a Sub procedure that
you write, according to the specification of the event, which is
called automatically by Access when an event of that
particular type occurs.
A form frmComboTest is defined:
This is a test form which shows how the ProductID combo box
displays values based on the CategoryID selected.
The content, the RowSource for the ProductID, is obtained
using the SQL statement:
SELECT distinct Products.ProductID,
Products.ProductName FROM Products WHERE
(((Products.CategoryID)=[forms]![frmComboTest]!
Page 130 of 150

[CategoryID])) UNION select distinct null, null FROM
Products ORDER BY Products.ProductName;
The ProductID combo box is requeried on both the OnCurrent
event for the Form as well as the Change event for the
CategoryID combo box. The code required for the OnCurrent
event procedure is:
Private Sub Form_Current()
ProductID.Requery
End Sub
The code required for the Change event on the parent
(master) is:
Private Sub CategoryID_Change()
ProductID.Value = Null
ProductID.Requery
End Sub
Pay close attention to the RowSource for the ProductID combo
box. The RowSource is an SQL statement. It is based on a
UNION query with the appropriate Product table records as
well as a row that contains null values. When the CategoryID
combo box is changed, the ProductID combo box receives the
null value. This is how the contents of the ProductID combo
box are cleared.
Unfortunately, the SQL used as the RowSource has to be
written by you, the user – this particular kind of SQL statement
cannot automatically be generated on the basis of a user-
defined query.
Note The syntax for referring to objects, such as forms and
controls, is not completely straightforward.
Use either of the following syntax statements to reference a
control on a main form:
Forms!formname!controlname
Me!controlname
(In more recent versions, you can substitute dot (.) for
exclamation mark (!) between objects.)
One of the most common mistakes made in Access form
development is improper syntax when referencing controls on
a subform. As far as Access is concerned, a subform is just
another control on the main form.
To refer to a subform or a control on a subform, you must
remember that Access treats the subform as a control.
Essentially, you have a form with a control with a control. To
express that arrangement in terms Access can decipher, you
need the Form property as follows
Forms!mainform!subform.Form.controlonsubform
Me!subform.Form.controlonsubform
In other words, subform is simply a control on the main form.
Page 131 of 150

In the example given above, frmComboTest is a form. If it is
included as a form on another form (for example, mainform),
that is, if it is a subform of mainform, then the SQL SELECT
statement needs to be amended:
SELECT distinct Products.ProductID,
Products.ProductName FROM Products WHERE
(((Products.CategoryID)=[forms]![mainform]!
[frmComboTest]![CategoryID])) UNION select distinct
null, null FROM Products ORDER BY
Products.ProductName;
If the full syntax is not respected, Access returns an error
when the field on the form is used.
Page 132 of 150

3. Appendix 6: Normalisation
3.1. Introduction to Normalisation

With thanks to my former colleague at Huddersfield, Steve Wade, on
whose material much of this section is based! I have also referred to
the book by Graham Curtis (Curtis & Cobham 2008).
Normalisation is a bottom-up technique for relational data analysis
based on analysing inter-relationships between data items. From our
point of view, this is just an alternative way to establish the entity
types, their attributes, and their relationships. We will use it primarily
as a way of crosschecking that we have found all the relevant
entities, attributes and relationships. Curtis (2008) says:
“Normalisation results in a fine tuning of the entity model. It may
lead to more entities and relationships being defined if the entity
model does not contain entities in the simplest form. The analyst is
moving away from considering a high-level logical model of the
organisation to the detailed analysis of data and its impact on that
model. Doing this ensures that data is organised in such a way that
(1) updating a piece of data generally requires its update in only one
place, and (2) deletion of a specified piece of data does not lead to
the unintended loss of other data.”
The end product of the technique is a set of entities designed
to minimise redundancy of data and to avoid consistency
problems.
3.2. Introduction
♦ The relational database has a mathematical basis in Set
Theory
♦ It is possible to exploit the mathematical basis for
relational database design to improve the quality of the
actual design. Normalisation is a formal technique for
ensuring that the right attributes appear on the right
entities
♦ Also called relational data analysis, the technique of
normalisation is based on a property of data called
dependency or functional dependency.
♦ Normalisation aims to yield a set of entities designed to
∗ Minimise data redundancy
∗ Avoid consistency problems
♦ Normalisation is a “Bottom up” technique
Instead of starting with a top-down analysis of user
requirements, this technique starts with the existing
situation: the technique examines business documents
as they are currently used in existing business
processes. From this, it induces the necessary
database entities. For example, the starting point
might be an existing purchase order form. As we saw
Page 133 of 150
above in section 2, normalisation enables us to deduce
the need for several entity types, including purchase
order, supplier, product and order detail line.
♦ It is applied to attributes discovered on paper and
computer forms, viewed as a table (cf. Spreadsheet view)
3.3. Preliminary remarks

An Entity name takes the form of a Singular noun (or occasionally
noun phrase), e.g. Student, Module, Module registration.
♦ Attributes should be singular and represent a single fact
about an entity.
♦ They MUST NOT be lists (= more than one fact); an
Awards attribute for a student is WRONG
♦ Each attribute should depend upon the whole key (an
issue only if the key is compound)
♦ If an attribute depends on part only of the key, this is
WRONG
♦ Each attribute should depend only on the key
♦ If an attribute depends on any other non-key attribute,
this is WRONG
♦ What do I mean by wrong?
If you design a database which does not respect the
rules which follow, it is likely that you will store
duplicate, and therefore potentially inconsistent, data;
or that other inconsistencies will develop, especially
when you delete entity occurrences.
3.4. Terminology
3.4.1.Records
Data tends to be held in groups of items - each individual item
of data is a field, and the group of fields constitutes a record.
3.4.2.Field names
Or attributes.
3.4.3.Keys
♦ Introduction
Before we can store details of (facts about) things in a
database, we need unique labels, that is, identifiers or
names, for the entities about which attributes are to be
stored. These identifiers, or keys, need to be chosen
with precision and consistency.
Candidate keys are possible labels / names /
identifiers.
Page 134 of 150

Where there is more than one candidate key, we need
to choose one as the primary key.
Usually we choose numeric / short keys.
Often, we deliberately create a unique key (perhaps
intended to be computer-generated), such as a
student enrolment number
∗ Candidate keys
There may be more than one possible key in a
given situation. For example, we might identify
an Employee by her payroll number, or by her
National Insurance (NI) number in the UK, or
Social Security (US) number.
∗ Choose numeric / short keys
This may imply encoding, e.g. BAIB for BA
(Honours) International Business.
∗ Often need to create a unique key (perhaps
computer-generated)
Microsoft Access offers the AutoNumber facility
to assist in generating unique keys.
♦ Key types
Keys may be:
∗ Simple: single attribute
∗ Secondary - identifies a group of linked
occurrences
This document does not discuss secondary
keys.
∗ Compound
(a) This means the key is made up of

more than one attribute
(b) Each attribute is often a single key in

another relation
∗ Candidate key
An attribute or combination of attributes is a
candidate key if it uniquely identifies a record.
We have to choose to make one the Primary
key, and leave others as Alternate keys (i.e.
candidate keys which have not been chosen as
the Primary key).
∗ Foreign keys
Foreign keys implement one to many (1:M)
relationships in the following way. If two entity
types are related 1:M, then the primary key
attribute(s) (or, rarely, the alternate key
attribute(s)) of the one entity MUST appear as
attribute(s) of the many entity. This is because
Page 135 of 150
this is the only way in which the database
software can “join” the many records to the
one. Consider a situation in which students are
on a programme. The entity types are
Programme and Student, related 1:M. If the
primary key of Programme is Programme_Code,
then Student must also have a
Programme_Code attribute.
∗ Questions and Answers
Question: How many primary keys must an

entity have?
Answer: one
Question: How many foreign keys does an

entity have?
Answer: potentially several – one per 1:M

relationship in which the entity is at the
many end
♦ Functional Dependency
This is a fundamental concept, initially a bit difficult to
grasp.
Consider an entity E that has two attributes A and B.
The attribute B of the entity is functionally dependent
on the attribute A if and only if for each value of A no
more than one value of B is associated. In other words,
the value of attribute A uniquely determines the value
of B and if there were several entity occurrences that
had the same value of A then all these entity
occurrences will have an identical value of attribute B.
A and B need not be single attributes. They could be
any subsets of the attributes of an entity E (possibly
single attributes). We may then write
E.A -> E.B
This can be read as A determines B (though this is not
strictly correct), or that B depends on A (which is true).
♦ Dependency made simple(r!)
An attribute B is functionally dependent on A if for any
particular example of B, it is the value for that one
particular A and there can be no other value.
Example: healthy sound animals have a number of
legs which is true for all animals of that type.
Knowing an animal is a dog, we know it ought to have
four legs.
Number of legs is functionally dependent upon animal
type.
Page 136 of 150

3.5. The various stages of normalisation
3.5.1.Convert data into unnormalised form (UNF, 0NF)

List out all the data attributes you can identify. I find it useful
to record them on a spreadsheet or in a word processor
running in outline mode - using either of these tools, it is easy
to reorder data as you realise that particular attributes are
part of another entity from the one you first thought.
3.5.2.Convert UNF into First Normal Form (1NF)

♦ 1NF: The rule
♦ There must be only one value per cell (row / column
intersection) in the entity viewed as a table. That is, an
attribute must be a single value, and not a list.
♦ Identify Groups: data field(s) (one or many) that can have
multiple values for the single main key
♦ You should remove repeating groups ('remove' means
set up as a separate entity)
♦ Key to the new entity will be a compound key comprising
the original key plus additional information needed to
uniquely identify individual occurrences
3.5.3. Convert 1NF into Second normal form (2NF)

♦ Rule for 2NF: A 1NF entity is also in 2NF if every non-key
attribute depends on the whole of the key
♦ Avoids duplication, which is inefficient and leads to
update problems
♦ For each entity, determine whether the key is compound
♦ For entities which have a compound key, ask: "Are there
any non-key attributes which depend only on part of the
key?"
♦ If there are: remove them (i.e. set up a new entity)
3.5.4. Convert 2NF into Third normal form (3NF)

♦ For each entity, ask: "Are there any non-key attributes
dependent only on any other non-key attributes?"
♦ If there are: remove them (i.e. set up a new entity)
♦ Rule for 3NF:
A 2NF entity is also in 3NF if no non-key attribute
depends on any other non- key attribute
♦ Avoids duplication, which is inefficient and leads to
update problems
♦ Gives us somewhere to store data when there is no (in
this case) order
Page 137 of 150

3.6. Further normalisation
Fourth normal, Boyce-Codd normal and further normal forms have
been identified in the database literature but circumstances in which
they are needed are so rare as to be of little practical significance.
3.7. A full example of normalisation

We shall consider how each of these steps might be carried out on the
following document:
Purchase Order placed by Entrepôt Direct, Lille Date 01/05/2004
Purchase order 1234567 Supplier number 1

number
Supplier name Aardvark Supplier address 23bis rue du Flâneur

35000 RENNES
Supplier product Product Name Quantity Packet size Purchase price Sub-total
code required
A1 Digital Radio 10 1 160,00 1600,00
A2 Whiteboard 16 1 120,00 1920,00
Pre-tax total 3520,00
VAT rate 19,6%
VAT 689,92
Total remitted 4209,92
3.7.1. Step 1 - Convert data into UNF
This involves representing the data in the Purchase Order in the following
format:
Purchase order number

Supplier number
Supplier Name
Supplier Address
Supplier product code
Product Name
Quantity required
Packet size
Purchase price
This UNF representation indicates that:

 "Purchase order number" is the key data item.
 "Supplier number, Name and Address" occur once per order.
 The remaining items are repeated a number of times as a group.
They are indented above – this emphasises the repetition.
Page 138 of 150

3.7.2. Step 2 - Convert data into 1NF
Remove repeating groups, i.e. groups of data fields (or a single data field)
that may have multiple values for a single value of the key.
Set such groups up as a separate entity.
The key to this new entity will be a compound key comprising the original
key plus additional information to identify individual occurrences.
Applying this to the above example gives us the following:
First Normal Form
Purchase order number Purchase order number

Supplier number Supplier product code
Supplier Name Product Name
Supplier Address Quantity required
Packet size
Purchase price
We now have two entities, purchase order and purchase order detail.
The rule for 1NF is therefore:
There must be only one value per cell (row/column intersection) in the
entity. Put in another way, an entity is in first normal form (1NF) if there
are no repeating groups of attributes.
For each entity we must ask:

 Does the entity have a compound key?
 If it does, then we must ask: Are there any non-key attributes
which depend on only a part of the key?
Rule for 2NF
A 1NF entity is also in 2NF if every non-key attribute depends on the

whole of the key.
Any attributes that are dependent on only a part of the key should be
removed and stored in their own entity along with the part-key on which
they depend.
Applying this rule to our example leads us to produce the following
representation:
Second Normal Form
Purchase order number Purchase order number

Supplier number Part No
Supplier Name Quantity Required
Page 139 of 150
Supplier Address Purchase price
Part Number
Product Name
Packet size
What was wrong with 1NF, and what have we gained by moving to 2NF?
The answer is that the 1NF representation contains unnecessary repetition
of "Part Description" and "Packet size" information for every part ordered.
The same part may be ordered many hundreds of times so that storing the
data in 1NF could represent a waste of disk space. More importantly, this
amount of redundancy in the way data is stored could lead to significant
update problems.
Another problem with our 1NF representation is that there is nowhere in the
database to store information about Parts which are not currently on order.
So to summarise, by normalising, we have discovered a third entity type,
which is going to be called something like Product, or Stock item.
To avoid the possibility of the database becoming inconsistent (with some
copies of the same data being updated whilst other copies are overlooked)
we would ideally like to store each piece of data only once. This is really
what normalisation is all about.

For each 2NF entity must ask:
 Are any of the non-key attributes dependent on any other
non-key attributes?
So that we can enforce the following rule:
Rule for 3NF
A 2NF entity is also in 3NF if no non-key attribute depends on any other

non-key attribute.
Applying this rule to our example would give the following representation:
Third Normal Form
PURCHASE ORDER PURCHASE ORDER LINE SUPPLIER

Purchase order number Purchase order number Supplier number
Supplier number Supplier product code Supplier Name
Quantity required Supplier Address
Purchase price
PRODUCT
Supplier product code
Product Name
Packet size
Note: The items in CAPITALS above are suggested names for the entities now
identified
Again we should ask the question: "What's wrong with 2NF"?
Page 140 of 150

Our 2NF representation included unnecessary repetition of "Supplier Name"
and "Supplier Address" for every purchase order associated with the same
supplier.
This corresponds to the first problem that we discussed with regard to 1NF.
The second problem corresponds to the fact that in the 2NF representation
there is nowhere to store information about suppliers from whom nothing is
currently on order.
So normalisation here has identified the existence of a supplier entity.
There is another possible reason for interdependency of attributes. This is
that one attribute is calculated from others. It is very wise not to make such
calculated attributes part of the database structure. Instead, it is better
simply to remove them, and to create them as calculated fields on queries,
reports or forms as they are needed. In this example, it would be unwise to
have a subtotal attribute calculated as quantity required times purchase
price. Instead, as the subtotal is needed – e.g. on a report or form – it should
normally be recalculated by a formula. The exception to this advice is where
it genuinely is necessary to store the value calculated at one point in time,
typically for accounting reasons.
3.8. Normalisation: A Summary

♦ First normal form: No repeating attributes or groups of
attributes
♦ Second normal form: Remove dependencies on part
(only) of the key
♦ Third normal form: Remove inter-dependencies
♦ Most important aspects of normalisation
Generally, the 3NF representation is the ideal we should strive for.
There are higher normal forms for dealing with anomalous situations.
They are explained in the database literature, but rarely have any
practical significance.
The steps involved in normalisation may be summarised as follows:
1. Separate repeating groups
2. Separate partial-key dependencies
3. Separate non-key dependencies
♦ ESSENTIAL rule: No repeating attributes (no plurals)
(1NF)
If you break this essential rule, you will end up with a
completely unusable database design.
♦ GOLDEN rule: “An entity is fully normalised if every non-
key attribute depends upon the key, the whole key and
nothing but the key.”
Even if you do not carry out all the stages of
normalisation, this can be a very useful final check to
apply to the results of any database design work.
3.9. Normalisation complements top-down entity-relationship

modelling
Page 141 of 150
Once you have completed normalisation, you should compare the
results with those achieved by the top-down modelling carried out in
accordance with Chen's ER model and resolve any inconsistencies.
3.10. What is achieved by normalisation?

Normalisation of entity types leads to a data model that forms the
basis of a good database design because it:
• Decomposes entity types into their simple “atomic
constituents”, that is, their basic parts
• Ensures that data is not unnecessarily repeated
• Allows data on entities to be independent of the existence of
other entities
It is also important to realise that the data that was associated with
the original unnormalised entity is still recoverable. The entities are
connected at the entity level by their key attributes. Having
normalised each of the entity types in the model, it is possible to
recombine the entity types in order to answer specific questions. This
is done in Microsoft Access by means of queries which join together
more than one table.
• So a further advantage of normalisation is that tables which
are in third normal form can be recombined so as to answer
almost any conceivable question.
3.11. How is normalisation used in practice?

Very few database designers use normalisation as the only way in
which they build data models. Instead, normalisation is used in one
of the two following ways:
The data model is built in two ways, using top-down entity modelling
(section 24), and by bottom-up normalisation. The results are then
compared and any inconsistencies resolved by specific design
decisions.
The data model created by top-down means is checked to ensure
that all the entities are in third normal format. This can either e done
by using the three rules outlined above for each stage of
normalisation, or simply by applying the so-called “golden rule” of
normalisation.
3.12. Still confused?

See if Microsoft’s explanation at
http://support.microsoft.com/default.aspx?scid=kb;EN-
US;283878
(checked 24/11/2008) is any help. There’s also an associated
webcast.
3.13. Some questions with which to check your understanding

The answers to these questions are NOT in this document. However,
if you do them, you may approach the author of this document to
discuss them!
Page 142 of 150

1. Identify the duplicated data in the following table:
Emp. Emp. Job Job Title Start Date Finish

No. Name Code Date
123 Smith A1 Trainee Analyst 3/2/2000 5/2/2001

349 Cairns P3 Senior 3/2/2001 3/9/2001
Programmer
541 McPhee P3 Senior 5/2/2001 7/4/2003
Programmer
123 Smith A2 Analyst 6/2/2001 7/5/2003
541 McPhee P4 Chief Programmer 8/4/2003
123 Smith A3 Senior Analyst 8/5/2003 10/10/2003
632 Keith A2 Analyst 9/4/2004
123 Smith M1 Project Manager 11/10/2003
2. Given the following table are the following statements true or false?
a. A customer can have more than one salesperson

b. A salesperson can have more than one customer
c. A discount code is associated with only one discount percentage.
d. The total sales to date is determined solely by customer no.
S.Perso S.Person Cust. Cust. Cust. Cust. Total

n Name No. Name Disc. Disc % Sales
No. Code to
Date
002 Kellerman 257 Jones A 10 2272

286 Brown B 15 189
295 Foster B 15 23652
014 Adams 317 Green C 20 24272
352 Tate A 10 5734
027 Jennings 463 Young O 0 5734
494 Peacock C 20 4153
295 Foster B 15 2253
i) Choose a key field for the above table.

ii) Remove the repeating groups from the above table to produce 1NF
tables.
iii) Perform 2NF analysis on the tables identified in (ii)
iv) Perform 3NF analysis on the tables identified in (iii)
v) Represent the tables in (iv) as an ERM.
3. Consider a retail company that stores sales information. The information is

currently stored in a single file. The company has several stores (shops) and
the file has a record for every product line on sale at each store. The file also
contains details of future price changes and the effective date for which these
have been scheduled. The file therefore has the following structure:
Store Item Descriptio Annual Price Effective

n Sales to Date
Date
Page 143 of 150

10 AB13 Towel 1100.00 1.15 30/06/03
10 CF99 Handkerchi 350.00 0.38 30/06/03
ef
10 CF99 Handkerchi * 0.47 31/10/03
ef
10 HK76 Jeans 1700.00 26.99 30/06/03
20 AB13 Towel 840.00 * *
The entries marked * have values that have already been entered, i.e. *
represents 'ditto'.
(I) What problems might result from storing this data in a single table?
(II) Take the data in the file through to third normal form.
(III) Does the new file structure address all the problems identified
in (I)?
(IV) If the sales manager wanted to add the following data to the
files:
- Supplier Name for each item
- Name of store manager for each store
- Maximum quantity of each item to be stored in each
store
Where would the data be stored in your 3NF model? Would
any new tables be required?
4. The following table shows the breakdown of student marks on different courses
by assignment number. In this example we have a repeating group inside a
repeating group. For each course there is repeating student data and for each
student there is repeating assignment data.
Cours Course Student Student Ass. Ass. Ass.

e Title Code Name No. Subject Mark
Code
SA Systems A1234 Wade 1 Dataflow Diagrams 75

Analysis
2 Entity Relationship 67
Models
3 Normalisation 25
A1235 Walker 1 Dataflow Diagrams 60
2 Entity Relationship 54
Models
3 Normalisation 32
DB Databas A1230 Smith 1 SQL 65

e
Design
Page 144 of 150

2 Prototype 54
Implementation
A1234 Wade 1 SQL 55
2 Prototype 64
Implementation
i) Take the data in this report through to 3NF. What are the benefits of
storing this data in third normal form?
5. The Natural Yoghurt Company sells many products. Each product is composed
of several raw ingredients that are supplied by various vendors. A particular
ingredient is always supplied by the same vendor; however a vendor may
supply more than one ingredient. The product line (product offering) is divided
up so that only one department is responsible for a particular product.
However, each department is responsible for more than one product. Each
manager manages exactly one department. The following data items must be
stored in the Natural Yoghurt Company’s database:
Product Number EmployeeID of manager Product name

Manager’s name Ingredient Number Department Identification
No.
Ingredient name Department name Qty of ingredient
required for product
Dept office address Dept. phone number Vendor ID
Vendor name Vendor address
Derive an entity relationship model and a set of 3NF tables from the above
description.
Page 145 of 150

4. Appendix 7 Installing and using Microsoft Visio
4.1. Introduction
MS Visio is now available to ESC students via the Microsoft Developers’ Network
Academic Alliance MSDNAA Electronic Licence Management System ELMS. You
should by now have received an email from e-academy telling you how you can profit
from this scheme.
In order to create a drawing of a particular kind, you use both a template file and a
stencil file. These together tell Visio what kind of symbols can be used. The
equivalent terms in French are un modèle and un gabarit.
Microsoft Office Visio 2007 makes it easy for business and ICT professionals to
visualise, explore, and communicate complex information. Rather than complicated
text and tables that are hard to understand, you can use Visio diagrams that
communicate information at a glance. Instead of static pictures, you can create data-
connected Visio diagrams that display data, are easy to refresh, and dramatically
increase your productivity. You can use the wide variety of diagrams in Office Visio
2007 to understand, act on, and share information about organizational systems,
resources, and processes throughout an enterprise.
Office Visio 2007 is available in two stand-alone editions: Office Visio Professional
and Office Visio Standard. Office Visio Standard 2007 has the same basic
functionality as Visio Professional 2007 and includes a subset of its features and
templates. Office Visio Professional 2007 offers advanced functionality, such as data
connectivity and visualization features, that Office Visio Standard 2007 does not.
4.2. Visualize complex information to better understand it

Office Visio 2007 provides a wide range of templates — business process flowcharts,
network diagrams, workflow diagrams, database models, and software diagrams —
you can use to visualize and streamline business processes, track projects and
resources, chart organizations, map networks, diagram building sites, and optimize
systems.
You can more easily visualize processes, systems, and complex information using new
or improved features in Office Visio 2007:
♦ Get started quickly with templates.
Office Visio 2007 includes specific tools to support the diverse
diagramming needs of IT and business professionals. Create a
broader range of diagrams with new templates, such as the ITIL
(Information Technology Infrastructure Library) template and the
Value Stream Mapping template in Office Visio Professional 2007.
Use the predefined Microsoft SmartShapes symbols and powerful
search capabilities to locate the right shape, whether it is saved on a
computer or on the Web.
♦ Quickly access templates you use often.
In the Getting Started window, find the template you need by
browsing simplified template categories and using large template
previews. Locate the templates you used recently by using the new
Recent Templates view in the Getting Started window.
♦ Get inspired by sample diagrams.
Find new sample diagrams more easily by opening the Getting
Started window and using the Samples category in Office Visio
Professional 2007. View sample diagrams that are integrated with
data to get ideas for creating your own diagrams, to realize how data
Page 146 of 150
provides more context for many diagram types, and to determine
which template you want to use.
♦ Connect shapes without drawing connectors.
The AutoConnect functionality in Office Visio 2007 connects
shapes, distributes them evenly, and aligns them for you — with
only one click. When you move the connected shapes, they stay
connected and the connectors automatically reroute between the
shapes
4.3. Learning Visio

It’s worth investing a little (but not much?) effort into mastering Visio.
The standard Microsoft tutorials can be found at http://office.microsoft.com/en-
us/visio/CH102262071033.aspx
4.4. Creating DFDs using Visio

In Visio, the DFD is called a data flow model diagram in the "software" category, or
diagramme de modèle de flux de données in the “logiciels” category. Here you will
find various DFD conventions – one widely used in America is Gane Sarson.
4.5. Installing SSADM support

In this document, I have followed the SSADM convention (particularly fir DFDs). The
standard Visio product no longer contains support for SSADM shapes. I can make
available a template on request.
To use them with an English-language or French-language version of Visio, please
follow the following instructions. I am indebted to the Danish specialist Pavel Hruby,
whose web site is to be found at http://www.phruby.com/index.html (checked
24/11/2008) for the basic information on which I based this approach.
Typically, Visio 2002 keeps stencils and templates in the folder
C:\Program Files\Microsoft Office\Visio10\1033\Solutions\Software
in the English-language version of the product, and in the folder
C:\Program Files\Microsoft Office\Visio10\1033\Solutions\Logiciel
in the French language version of the product.
I believe that Visio 2003 uses the folder
C:\Program Files\Microsoft Office\Visio11\1036\
in both the English-language and French language versions of the product.
I believe that Visio 2007 uses the folder
C:\Program Files\Microsoft Office\Office12\1036\
in both the English-language and French language versions of the product.
It is not very wise to put your additional files in these Microsoft folders. I advise you
instead to keep them in a different folder, and to tell Visio where to find them. So:
♦ In English-language Visio:
∗ Download the files to any folder, except for the
folder in which Visio 2003 stores its own stencils
and templates.
∗ Start Visio, click "Tools" and "Options". In the
"Advanced" tab, click "File Paths..." and type in
Page 147 of 150

the fields "Stencils:" and "Templates:" the paths to
the directory with the SSADM stencil and
template. Restart Visio. The template "SSADM"
will appear under the "(Other)" tab, not under the
Software tab as it was in certain earlier versions of
Visio.
♦ In French-language Visio:
∗ Download the files to any folder, except for the
folder in which Visio 2003 stores its own stencils
and templates.
∗ Start Visio, click "Outils" and "Options". In the
"Options avancés" tab, click "Chemins d’accès..."
and type in the fields "Modèles:" and "Gabarits:"
the paths to the directory with the SSADM stencil
and template. Restart Visio. The template
"SSADM" will appear under the "(Autres)" tab.
Page 148 of 150

5. Appendix 8 Structured Walkthroughs, a way to improve the
quality of analysis
5.1. How to seek for perfection! Improving the quality of our

work
This section borrows heavily from Bell, Douglas (2005), himself quoting Weinberg,
Gerald M. (1998).
Some aspects of systems analysis require considerable precision. In effect, we are
looking for the correct answer to a precise problem. This is a way of thinking which is
alien to most of us most of the time. Human beings are used to imprecision! But in
analysis and in programming, we seek zero-defect, bug-free implementations.12
However, in this real world, this is impossible to achieve and very difficult to
approach. Once we have created something, such as an entity relationship diagram, it
is wise to assume that it will contain faults. However, we can become very blind to
our own mistakes. For this reason, it is a common experience that someone else can
spot errors better than the author himself. This observation led to the invention of the
so-called "structured walk-through". Credit for its invention belongs to Gerry
Weinberg, in his book "The psychology of computer programming". Weinberg
suggested that programmers see their programs as an extension of themselves. He
suggested that we get very involved with our own creations and tend to regard them as
manifestations of our own thoughts. Since we are unable to find fault with ourselves,
we become unable to see mistakes in what we have created; the recognition of such
failings is unacceptable to us. This failing is sometimes referred to as cognitive
dissonance.
The solution, as Douglas Bell says in his book "Software engineering for students: a
programming approach", is to seek help with fault finding. In doing this we will
relinquish our private relationship with our work. When applied to computer
programming, the approach is sometimes called ego-less programming. But it has
much wider application, specifically to anything we create which needs to be more-or-
less correct. Seeking for help can be a completely informal technique, carried out by
colleagues in a friendly manner. It must not be a formalised or rigid procedure of the
organisation. Such formalisation destroys its ethos and therefore its effectiveness.
Instead, if you get a friend or colleague to inspect your work, it is extraordinary to
witness how quickly someone else can see a fault that has been defeating you for
hours. Studies also show that different people tend to uncover different types of fault.
This further reinforces the need for team techniques.
An extension to this approach is the so-called “structured walkthrough”. A structured
walk-through is simply a term for on organised meeting at which an artefact is
examined by a group of colleagues. The aim of the meeting is to try to find faults
which might otherwise go undetected for some time. The word structured in this
context simply means well organised. The term walk-through means that the producer
of the artefact has to explain to the meeting
♦ Step by step the working of the artefact
and
♦ All the assumptions behind that artefact.
The very act of explaining the artefact, and of course of letting other people look at
that artefact, will enable errors or problems to be detected much more quickly. It is
important that the meeting concern itself only with the identification of problems or
12
Please note : the zero-defect ideal is emphatically not expected in the work that you do for
assessment. Instead, we are aiming for “good enough”! This appendix is included only because of the
extremely useful technique it illustrates.
Page 149 of 150
serious errors of style. The designer of the artefact should correct the problems
subsequently
Keys to success in the use of structured walk-through include:
 Correctly assembling the right group of colleagues.
 Distributing the artefact to participants before the meeting.
 Total concentration on the artefact itself, rather than the person -- individual
criticism should be avoided.
 The meeting should be scheduled in advance and of fixed duration.
The benefits of structured walk-throughs can be summarised as:
 The quality of the artefact is improved because more faults are found, and
because errors of style -- which can lead subsequently to errors of
interpretation by others -- are eliminated.
 Misunderstandings of the original requirements are more likely to be
detected.
 The earlier a problem is found with an artefact, the cheaper it will be to fix it.
But there are obvious problems in using this technique in an organisational culture that
is not collaborative and supportive.
5.2. References for Appendix 8

Bell, Douglas (2005) "Software Engineering for Students (4 ed)" Pearson Mar
2005, Paperback, 448 pages ISBN13: 9780321261274 ISBN10: 0321261275
Weinberg, Gerald M. (1998) “The Psychology of Computer Programming: Silver

Anniversary Edition” (Paperback) Gerald M. Weinberg (Author) Dorset House;
Anl Sub edition (September 1998) ISBN-10: 0932633420 ISBN-13: 978-
0932633422
Page 150 of 150

Design & Build A Microsoft Office Access Database

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Design & Build A Microsoft Office Access Database

Transféré par

Droits d'auteur :

Formats disponibles

Designing and Building

Access Database Systems

Edition 7, October 2009

ESC Rennes School of Business, France

Edition 0 School of Computing and March 2000

Edition 7 ESC Rennes School of Business, October 2009

Work on this document started when Mark Gregory was working

ÉCOLE SUPÉRIEURE DE COMMERCE DE RENNES..............................................2

ESC RENNES SCHOOL OF BUSINESS, FRANCE...................................................2

School of Computing and Engineering, University of Huddersfield................................................................2

ESC Rennes School of Business, France..............................................................................................................2

1. INTRODUCTION: WHO IS THIS DOCUMENT FOR?...........................................13

1.2. Skills required................................................................................................................................................13

1.3. The aims of the remainder of this document .............................................................................................13

1.4. The structure of this document and how to use it......................................................................................14

1.5. About Learning Access..................................................................................................................................15

1.6. Testing yourself..............................................................................................................................................15

1.7. Conventions Used in this document.............................................................................................................17

SECTION 1 - THE PRINCIPLES OF DATABASE....................................................19

2.2. Models used by systems analysts..................................................................................................................19

2.3. Simple model of data processing..................................................................................................................19

2.4. Why study Databases?...................................................................................................................................20

2.6. How to store data...........................................................................................................................................20

2.7. What is a database?.......................................................................................................................................21

2.8. Why keep data in different tables?..............................................................................................................21

2.9. Learning a minimum about database..........................................................................................................23

2.10. Basic concepts...............................................................................................................................................23

2.11. Entity (type, class)........................................................................................................................................24

2.12. An example: Students by Programme.......................................................................................................25

2.14. Primary and Foreign Keys.........................................................................................................................25

2.15. Why have foreign keys? .............................................................................................................................26

2.16. Entity occurrences – student......................................................................................................................26

2.17. Entity occurrences – programme...............................................................................................................26

2.19. Students and Modules.................................................................................................................................27

2.20. Three Vital Rules.........................................................................................................................................27

2.21. Resolving Many-to-Many Relationships...................................................................................................27

2.22. Towards a more complete entity relationship attribute model..............................................................30

2.23. Example Query – definition........................................................................................................................31

2.24. Example Query – results.............................................................................................................................31

2.25. What is a query?

2.26. Data Dictionary............................................................................................................................................32

2.27. Entity-Relationship Diagrams (ERD)........................................................................................................32

2.28. Another example database: NorthWind / Les Comptoirs.......................................................................32

2.30. Why it’s important to relate entities..........................................................................................................34

2.31. Degree of relationship (simplified).............................................................................................................34

2.32. Simple database design................................................................................................................................34

3. A SIMPLE METHODOLOGY FOR DESIGNING MICROSOFT ACCESS

3.2. Feasibility study.............................................................................................................................................39

3.3. Set out Project Terms of Reference.............................................................................................................40

3.4. Analyse the needs of users.............................................................................................................................40

3.6. Cross-check: entity life history.....................................................................................................................51

3.7. Model User <-> System Interactions ..........................................................................................................52

3.8. Define required outputs: reports, forms, queries.......................................................................................52

3.10. Work through your design on paper, whiteboard, etc............................................................................52

3.11. Implementing processes in Access.............................................................................................................52

3.12. Define (“design” in Access terms) the database: Build a prototype......................................................53

3.13. Refine / iterate / implement........................................................................................................................53

3.14. Test the database..........................................................................................................................................53

3.15. Obtain User Feedback.................................................................................................................................53

3.16. Refine the system by Iteration....................................................................................................................54

4. PUTTING DATABASE DESIGN THEORY INTO PRACTICE...............................54

4.3. Achieving real competence in Database Design.........................................................................................55

5. MORE ABOUT DATABASES................................................................................56