SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.

htm

Requirements Specification
A high-level requirements specification is required. The purpose of the requirements analysis is to identify requirements for the proposed system. The emphasis is on the discovery of user requirements. Each

Page

- page

numbering

will

be

maintained within the catalogue.

Source/Origin - is the originator of the requirement; the person with the responsibility for negotiation about the requirement.

requirement (or problem) must be defined and documented in the requirements catalogue. Each requirement is recorded in the

Requirement

Number -

unique

requirement number is assigned to each requirement. is an The requirement number

requirements catalogue on a requirements catalogue entry form. A copy of the form is in the appendix section of the standards manual. The form should be completed as follows:

number

incremental

starting with one.

Priority - a priority is assigned to the requirement. The priority given is

Project/System -

the

proposed

agreed between the originator and the analyst. There are three priority levels: high (H), medium (M) and low (L). High priority is assigned when the requirement priority is is mandatory. Medium the

system name or an abbreviation of it.

Analyst - your name as the analyst on this project.

Date - the date the entry was made in the catalogue, whether it is a new entry or an amended entry, ie another version of an existing entry.

assigned

when

requirement is desirable. Low priority is assigned when the requirement is

Version -

version

number

is

optional.

assigned to a requirement. The initial version of a requirement is number one. However, the requirement may need to be updated in the course of the development of the project, so then the requirements catalogue entry will be replaced with the updated version of the requirement and the updated version number will reflect this change.

Functional Requirements and NonFunctional Requirements - see next page.

Related Documents - reference to any related documents, eg user

documentation, data flow diagrams.

Proposed

Solution -

any

possible

solution or general comments.

Actual Solution - records how the requirement implemented is or resolved, abandoned. eg This

Status - the status of the requirement will be either ongoing or complete. When the status is ongoing the status box will be empty, and when the status is complete the status box will contain a tick (().

section will be completed at a later stage when the requirement has

reached the completed status.

Functional and Non-Functional Requirements

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

Functional

Requirements -

deal with what data needs protected; what data should be restricted to a particular restriction user role; and eg level of

description of the facility or feature required. Functional requirements deal with what the system should do or provide for users. They include

required,

physical,

password, view only. Non-functional requirements may cover the system as a whole or relate to specific functional requirements.

description of the required functions, outlines of associated reports or online queries, and details of data to be held in the system.

Requirement Summary Form

Requirements a The requirements catalogue also contains a summary of the ongoing on and the completed requirement

Non-Functional

description and, where possible, target values of associated non-functional Non-functional

requirements

detailed

requirements.

summary form, a copy of which is in the appendix. The requirement summary form is completed as follows:

requirements detail constraints, targets or control mechanisms for the new system. They describe how, how well or to what standard a function should be provided. For example, levels of required times; service security such as and response access

Analyst Name - your name as the analyst on this project.

System Name - the proposed system name or an abbreviation of it.

Version -

version

number

is

requirements;

technical

constraints;

assigned to a requirement. The initial version of a requirement is number one. However, the requirement may need to be updated in the course of the development of the project, then the requirements catalogue entry will be replaced with the updated version of the requirement and the updated

required interfacing with users' and other systems; and project constraints such as implementation on the

organisation's

hardware/software

platform. Service level requirements are measures of the quality of service required, and are crucial to capacity planning and physical design. Identify realistic, measurable target values for each service service hours, level. These include

version number will reflect this change.

Page -

page

numbering

will

be

maintained within the catalogue.

service

availability, and

Requirement

Number -

unique

responsiveness,

throughput

requirement number is assigned to each requirement. is an The requirement number

reliability. Security includes defining priority and frequency of backup of data, recovery, planning fallback and and access

number

incremental

starting with one.

contingency

Requirement Description - a brief textual description of the requirement.

restrictions. Access restrictions should

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

Priority - a priority is assigned to the requirement. The priority given is

agreed between the originator and the analyst. There are three priority levels: high (H), medium (M) and low (L). High priority is assigned when the requirement priority is is mandatory. Medium the

assigned

when

requirement is desirable. Low priority is assigned when the requirement is optional.

Originator - is the originator of the requirement; the person with the

responsibility for negotiation about the requirement.

Status - the status of the requirement will be either ongoing or complete. When the status is ongoing, the status box will be empty. When the status is complete the status box will contain a tick (().

The requirements summary is a summary of all the requirements in the catalogue and each summary must reflect accurately the details of the requirement as specified in its requirement catalogue entry, ie requirement numbers,

Data Flow Modelling

The above system, presented in text, is quite simple to follow, but for large systems, text can become almost incomprehensible.

version numbers, priorities and status must match.

Example of a Requirements Specification Document

Fortunately SSADM comprises tools that allow us to show the system graphically. This makes it much easier to show the three views mentioned earlier. We have already seen that the methodology works by documenting the current system and then creating the required system. But it also considers the system representation to be physical and logical.

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

Difference between and Logical

Physical

which is much easier to follow than the text description. Data flow modelling is carried out in stages, or levels as they are known. We start with a top level that we call the Level 0 Data Flow Diagram (sometimes called the Context Data Flow Diagram). We then expand this into the Level 1 Data Flow Diagram and then further expand this into a set of Level 2 Data Flow Diagrams.

'Physical' means that we document the system as it appears in the 'real world', while 'logical' means what the system actually does. Our system development project, therefore, has four stages in its development: 1. Current Physical 2. Current Logical 3. Required Logical 4. Required Physical

DFD Symbols Current

the system's Data Flow Diagrams (DFDs) only use six symbols:

Difference between and Required

During the early stages,

requirements are identified and the current business environment is modelled in terms of the processes carried out and the data

structures involved. In stage 1, DFDs are used to produce detailed logical models of the current system. In stage 2, DFDs and LDSs are produced to support the final chosen option. The transition from stage 1 to stage 2 is a key part of SSADM. This is where we move from a logical model of the current system to a logical model of the required system, ie this is where the DFDs and LDSs have to be refined to cater for new/changed requirements. So, our task is to carry out the following:

y y

Document the current physical system Convert this to the current logical system.

After we have converted it to its logical version, we can then derive our three views mentioned earlier. To start the procedure off, we need to learn our first technique - a diagramming method called data flow modelling. This technique gives us a diagram of the system's operation,

DFD Example

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

Suppose you are given the details of a small mail order catalogue system that allows people to shop from home. When a customer receives the catalogue and wants to buy something, they can telephone, fax or email their order to the company. The company gets the order and sends the goods and an invoice. When the customer receives the goods with a delivery note, they send payment and receive a receipt for their payment. The first thing we must do is model the main outputs and sources of data in the scenario above. Then we draw the system box and name the system. Next we identify the information that is flowing to the system We

Payment comes in - ie a payment data flow is received, and a receipt data flow goes out to the customer.

Catalogue goes out to the customer this is also a physical data flow. now have a top-level view of the

information flow in and out of the system.

Activity 4
Now let's try drawing a level 0 diagram. Examine the following outline and then draw the diagram you think will model the situation. When a patient arrives at Mosspark Surgery with a repeat prescription request, the

receptionist checks the prescription file and writes out a prescription. This has to be authorised by the doctor before being passed to the resident chemist for dispensing. The chemist then gives the prescription to the patient. If the patient is entitled to free prescriptions, the chemist verifies this and fills in the appropriate details on a form, which is filed in the free prescriptions file. Otherwise the chemist takes the appropriate amount of money from the patient and gives them a receipt.

and from the system. Here is the Level 0 (also known as the context diagram) DFD for the Mail Order system:

Answer to Activity 4
Your answer should be similar to that below:

You will see that the Customer (a source of information) has sent in an order.

The system has sent out an invoice data flow, a delivery note data flow and goods ('goods' is not information; it is shown as a double-headed arrow because it is a physical or resource data flow).

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

Level 1 DFD
The next stage is to create the Level 1 Data Flow Diagram. This highlights the main

However, we are not quite finished with this diagram yet. There are certain rules we must learn in order to ensure that we create a valid DFD. Here they are below - it is recommended that you learn these well! Rule 1 - Does each function have input and output? Rule 2 - Does each function have all the information it needs in order to produce its output? Rule 3 - If not, then what information does it need and where will it get that information from?

functions carried out by the system. As a rule, we try to describe the system using between two and seven functions - two being a simple system and seven being a complicated system. This enables us to keep the model manageable on screen or paper. Activity 5 Try to describe what the mail-order system does in a number (two to seven) of short sentences these sentences become the

system's functions. Let's describe the system in two sentences. Compare your answer with others in the group. Are all the answers the same? If not, why do you think this is so?

Applying the Rules

Applying these simple rules ensures a valid Data Flow Model. So let us apply these rules to our Level 1 DFD. Rule 1: Answer YES. Rule 2: Function 1: YES - it does have all the

Answer to Activity 5
Some functions could be described in sentences like: Gets orders from customers and receives payment when they are delivered. We can show this as a Level 1 DFD:

information it needs. It only needs order details to produce its output - invoice. Function 2: NO - it does not have all the information it needs to produce its output (receipt). So we must apply Rule 3 to Function 2. Rule 3: Function 2 has payment details but it also needs order details so that it can match up payment with order. So where will it get information from? We can see that Function 1 receives order details from the customer, so it must receive order details from Function 1. How do we show this in our DFD? Well, we can assume that when orders enter the system they are stored in the system for further use. We can assume that Function 1 stores order details. This is shown on the below:

Note that the data flows from the Level 0 DFD are attached to the correct Level 1 function.

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

requested to come in for interview. After interviews have taken place, a decision on the most suitable candidate is taken and they are offered the post. The interviewees who have been unsuccessful are sent a refusal letter.

We have used the data store symbol to show the stored orders. Note that Function The final stage in data flow modelling is to take each Level 1 Function and break it down into its constituent parts. These parts are the fundamental Processes which make up the function. We apply exactly the same rules as we did when converting from Level 0 to Level 1. Try this yourself and compare your answers with others in your group, if possible.

1 creates the order data store and Function 2 reads the data store. Note also how

important it is to apply all the rules - if we only applied the main rule (ie all functions to input and output), the diagram would have been incomplete.

Activity 6
Let's try another example. Given the scenario and level 0 diagram below, create the level 1 diagram as appropriate: When FlashIT are interviewing and selecting new employees for their company, they ask applicants to send their application forms and their CVs to then personnel. checks The these personnel forms for

Answer to Activity 6
Your answer should be along the lines of that shown below:

department

completeness and, if found to be complete, they are stored these in the applications are returned file. to

Otherwise

forms

applicants for resubmission. The applications are then Any scrutinised candidates for not

possible

interviewees.

considered suitable for the post are sent a refusal letter. Suitable candidates are

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

Did everyone in your group come up with the same answer? Of course not! That is what happens when we use a modelling tool like this. Were some answers better than others? What made them better? Which answer should be the one we adopt?

Now apply the 'three rules': 1. Q Does every process have inputs and outputs? A No. Process 1.2 has no inputs. We will deal with this shortly. 2. Q Does each process have all the information it needs to produce its

Level 2 DFDs
We now create the Level 2 Data Flow Diagrams. A possible solution is as shown below. We describe each function using two to seven sentences. These sentences then

output? A No. Process 1.1 does, Process 1.2 does not. 3. Q What information does Process 1.2 need and where will it get this from? A It needs order details and it will get these from Process 1.1.

become the function's processes. Since this is a simple system, we will use two processes for each function:

Updated Diagram Here is the updated diagram:

1. Receive order 2. Issue invoice and goods. Function 2 - 1. Receive payment 2. Issue receipt and Process Payments catalogue Function 1 Process Order
Let us show this diagrammatically. First

'expand' the function boxes so that we can fit the process boxes into them. Then position the data flows from Level 1 into the correct process in Level 2.

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

A It needs order. Q Where will it get this from? A 2.1. Here is the updated diagram:

We now do the same for Function 2:

Notice that we have also dealt with the problem of 2.1 having no output. This situation is quite common.

Activity 7
Given the following scenario and level 1 diagram, create the physical level 2 diagram. Mavisbank High School has a library that lends books to staff and students. Pupils are allowed to borrow six books and teachers are allowed

Applying the Three Rules

1. Process 2.1 has no output. Process 2.2 has no input. It is usually easier to resolve a situation like this by first examining the process that has no inputs rather than the one with no outputs. The Reason? Well, it is easier to answer the question "What does the process need in order to produce its output?" rather than "What does the process do with its input?" 2. So we will deal with Process 2.2 first. We can, in fact, go directly to Rule 3. 3. Q What does Process 2.2 need in order to produce its output?

to borrow ten. When someone borrows a book the library book file is updated, as is the borrower file. Everyone issued with a book has it for a period of one month, after which time they are sent a reminder. If, after six months, they haven't returned the book, they are sent a bill for the cost of recovery of the book.

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

interact easily with it, but these features make it difficult to implement on the computer system. To carry out logicalisation we apply a set of rules or procedures to our current physical system. These rules are applied to the current physical level 2 Data Flow Diagrams. The rules are shown below.

Deal with the Names of the Objects in the Model

Firstly, we check that the names of the sources, data flows and data stores are clear

Answer to Activity 7
Your answer should be along the lines of that shown below. Only level 2 for the Issue books process has been done.

and represent what the object's purpose is. We also check that, where an object is used in more than one part of the model, the same name is used for it in each case. For example, it is quite common in a physical system to have several versions of the same object. Consider the situation where we have an invoice being sent to the customer and a copy of the invoice being stored in the

customer's file. We need to ensure that the same name is used for both; otherwise we will be storing two copies of the same item in our database!

Deal with Stores

Duplicated

Data

This is quite a common occurrence. It can occur for two reasons. Firstly, when the same data store is accessed

Logicalisation
The system as currently documented is termed 'physical', since it is how the system appears in the real world. However, if we are to document what the system is actually doing we have to convert it into what we call its 'logical' form. This is necessary because the physical system consists of features to enable the user to

in more than one function and has a different name in each function. For example, one function calls the data store customer and another function calls the same data store client. If we left this situation, we would be duplicating our database. Secondly, when there is a copy of the data store being maintained by a function. This is quite a dangerous situation, since not only do

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

we have two copies of the same data store, but these copies would almost certainly be out of synchronisation. How do we know if the data stores are the same object? We simply examine the

Imagine also that the order forms arrive at, say, ten-minute intervals. The worker may decide to complete orders every 30 minutes and do a batch at a time for efficiency's sake. In this case their in-tray is a temporary data store. Physically, the order forms 'wait' until they are processed, but 'logically' the forms are

attributes of each - if the have the same set of attributes, then they are most likely the same object. To remedy the situation, we simply make sure that the same name appears in all functions accessing the data store. In the example above, we would ensure that all functions use either the name customer or client.

accepted and processed. The way we deal with temporary data stores is quite simple - we delete them. Obviously this means that we may have a situation where processes may therefore have missing inputs and outputs, so data flow diagram validation must be carried out. It may also mean that if the sole function of a process is to read or create a temporary data store, then it will be deleted also.

Deal with Duplicated Processes

This is similar to the above. We may find that the same process is being carried out by more than one function. This is quite all right and is not necessarily a problem. For example, the customer files may be updated by different functions in our system. This does become a problem when the

Conclusion
Carrying out logicalisation is an important step in SSADM. It ensures we have a tight, welldefined and efficient data flow model, which will become the basis for the rest of the procedure. However we must ensure, when we are adding or deleting items to or from our data flow model, that we continually validate it to make sure we are not introducing errors. We now have to convert our current physical level 2 Data Flow Diagrams to their logical forms. Please refer to the logicalisation rules provided as we go through this stage. In this case there is not very much to do to the diagrams. We generally find this to be the

processes that do the same operation are given different names. For example, we may have a process called Maintain Customer

Details and another called Update Customer File. If these processes are the same, then we have a duplicated process. We can tell if they are the same by examining the algorithms in each case. The situation can be remedied by ensuring that only one process name is chosen for that process, wherever it appears in the model.

Deal with Stores

Temporary

Data

norm, especially where there already is an upto-date, working computer system in place. Let us start with Function 1. You will see that we have a physical or resource data flow (goods) to deal with. Refer to the rule that deals with physical flows. The rule states that if

This is also a common occurrence. Imagine we have a warehouse worker whose job it is to accept order forms in their in-tray and to collect and send the items out to the customer.

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

the physical flow is represented by a logical flow then it will be deleted. The information about the goods being sent to the customer is shown in the delivery note, so this means that the goods data flow is redundant and can be deleted. In Function 2 there is another physical data flow. This time it is not represented by a logical flow, so how do we decide whether or not to keep it? The answer in this case is quite simple - if we remove it, then the customer will not receive their catalogue. So, since physical data flows cannot exist in our logical system, we will make this data flow logical. Finally we will 'tidy up' the names of the objects in our model so that we can implement them in our database later. There is nothing else to do to our diagrams at this stage and they are now shown on the following page:

Activity 8
Now let's try logicalisation for ourselves. Examine the following diagram. It's a level 2 diagram. Apply the logicalisation rules to it and then redraw.

Logical DFDs

Answer to Activity 8

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

The General Manager regularly communicates with staff in the sales and marketing and

Entity (ER)
system

Relationship

Diagrams

accounts departments by using email. Orders received by sales and marketing are forwarded to the production and accounts departments for completion and invoicing. The accounts department forwards regular written reports to the General Manager. It also raises invoices and sends these to the customers. Data modelling is a technique aimed at making the most of the way that information is stored and used in an organisation. It begins with the identification of the main data groups, for example the invoice, and continues by defining the detailed content of each of these groups. This results in structured definitions for all of the information that is stored and used within

Now that we have the DFDs, we have the view in of the the main functions and

processes

new

system.

Another

important stage in the development is creating Entity Relationship diagrams, which will help us understand the data model view of the system. Data modelling is a technique that is widely used in the world of business and information technology to show how information is, or should be, stored and used within a system. The success of any organisation relies on the efficient flow and processing of information.

Let's look at an example in which information flows around the various departments in the organisation. This information can take many forms; for example it could be written, oral or electronic.

a system. The technique provides a solid foundation for systems design and a universal standard for system documentation. Data modelling is an essential precursor to analysis and design, maintenance and documentation, and

improving the performance of an existing system.

Data Modelling Symbols

Data modelling uses a standard set of symbols to represent each of these defined data

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm
groups, and then proceeds by establishing the relationships between them. The first of these symbols is the soft-box entity symbol, eg:

1. One-to-One Relationships 2. One-to-Many Relationships 3. Many-to-Many Relationships.

One-to-One Relationships
This type of relationship takes place when a single occurrence of an entity is related to just one occurrence of a second entity. An entity is something about which data will be stored in the system under consideration. In this example the data group invoice can be identified as a system entity. For example, a roof covers one building;

a building is covered by one roof. A One-to-One relationship is shown on the diagram by a line connecting the two entities.

The other main component on a data model is the relationship line. A relationship is an association between two entities to which all of the occurrences of those entities must

One-to-Many Relationships
This type of relationship takes place when a single occurrence of an entity is related to many occurrences of a second entity. For example, an employee works in

conform.

one department; many employees. A line that joins the two entities to which it refers represents the relationship. This line represents two reciprocal relationships: that of the first entity with respect to the second, and that of the second entity with respect to the first.

a department has

A One-to-Many relationship is shown on the diagram by a line connecting the two entities with a 'crow's foot' symbol denoting the 'many' end of the relationship.

Relationships Between Entities

Frequently, a meaningful relationship exists between two different types of entity. For example:

Many-to-Many Relationships
This type of relationship takes place when multiple occurrences of an entity are related to multiple occurrences of a second entity. For example, many employees can be involved in many projects at a given time. of

y y y y
There

Employees work in a department Lawyers advise clients Equipment is allocated to projects A truck is a type of vehicle are potentially three types

A Many-to-Many relationship is shown on the diagram by a line connecting the two entities with 'crow's foot' symbols at both ends.

relationship which can exist different entities:

between two

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

entities often are) a flight is an event and an airport is a location. However, entities are nearly always the things about which data will

The Problem with Many Relationships

Many-to-Many relationships in

Many-toan entity

be stored in the system under investigation. Note that entities are always named in the singular; for example: customer, account, and loan, and not customers, accounts and loans.

relationship diagram tend to conceal areas of poor understanding, and in fact some

databases will not allow you to create such relationships. Almost always, a Many-to-Many relationship conceals a hidden entity. For this reason, identifying and adding the hidden entity to the model eliminates Many-to-Many relationships. This usually ends up with an extra entity being added, which then has a One-to-Many relationship with the existing entity. Data modelling is all about identifying entities and their relationships, and then drawing a diagram that accurately depicts the system. This applies equally to the design of a new system or the analysis of an existing one. The end result of data modelling should be a clear picture of how information is stored and related within a proposed, or existing, system. Some examples of information systems and their entities are listed below:

This course uses symbols that are standard in the IT industry. We use the soft-box symbol shown to represent an entity. If an Internet site uses a different symbol set this is not a problem, as data modelling techniques are the same regardless of the symbols being used.

Similar

entity

occurrences

are

grouped

together and collectively termed an entity type. It is entity types that are identified and drawn on the data a model. specific An 'entity

occurrence'

identifies

resource,

event, location, notion or (more typically) physical object. In this course, the term 'entity' refers to entity type. The term 'entity

occurrence' will be specifically used where relevant.

Each entity has a data group associated with it. The elements of the data group are referred to

Banking

system: customer,

account,

loan

as the 'attributes' of the entity. The distinction between what is an attribute of an entity and

Airline airport

system: aircraft,

passenger,

flight,

what is an entity in its own right is often unclear. This is illustrated shortly.

Identifying and Naming Entities

Entity names are normally single words, and the name chosen should be one familiar to the users. The entity name can include a qualifier in order to clarify its meaning. However, if different names are currently used to describe

A box containing the name of that entity represents an entity. A precise definition of 'entity' is not really possible, as entities vary in nature. For example, in the airline system, whilst an aircraft is a physical object (as

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

given entity

in

different

areas

of

the

Read the following case study. Study this information carefully and see if you can

organisation, a new one should be chosen that is original, unique and meaningful to all of the users. For example, the terms 'signed contract', 'sale' and 'agreement' might be recreated as the entity 'completed'.

identify the entities - remember that entities are things about which data will be stored. Make your own list of those things that you think are likely to be entities, before looking at the answers and seeing if you were correct. Then see if you can identify some attributes of

Conversely, an organisation may be using a 'catch-all' term to describe what the analyst identifies as being a number of separate entities. For example, the term 'invoice' may be being used to describe three invoice types, each of which is, in fact, processed in a different manner.

each entity. Cardonald Cameras is an independent retailer of cameras, video cameras and accessories. The owner is both the shopkeeper and

manager, and he purchases a variety of products from a number of different suppliers. He can check on different suppliers' wholesale and recommended retail prices with reference

In this case, prefixing the entity names with qualifiers is likely to be the best solution. The process of identifying entities is one of the most important steps in developing a data model.

to their price lists, as shown.

It is common practice for an experienced analyst to adopt an intuitive approach to entity identification, in order to produce a shortlist of potential entities. The viability of each of these potential entities can then be considered using a set of entity identification guidelines. This should result in some of the potential entities being confirmed as entities, whilst others will be rejected. During a normal day several customers will enter the shop and a number of them will buy one or more of the products on sale. At some stage the owner may decide that one or more product lines need to be re-ordered, following a visual stock-take. He will then consult the latest suppliers' price lists to see who is offering the best deals on given product lines.

Activity 9
In this exercise you will be asked to identify a set of potential entities in a simple business scenario. This should help you to understand and appreciate the entity identification process better.

Following this, he will ring one or more of the suppliers to order some of their products. At

SOURCE: http://www.sqa.org.uk/e-learning/SDM03CD/index.htm

the same time he will also keep a record of the orders that have been placed with each

entity we can see that this entity contains the key of the entity at the other end of the symbol.

supplier on a separate sheet of paper. These records are used to verify incoming orders and invoicing details.

Activity 10
Examine this next scenario and attempt to draw the entity model that matches it.

Answer to Activity 9
Answers such as customer, order, sales, owner, manager, product etc are acceptable. Here is the Entity Model for our system:

Mosspark

Surgery

has

doctors,

nurses,

midwives and patients. The patient has to telephone for appointments with the doctors or nurses and these appointments are allocated by the receptionist. An appointment can only be made with one doctor, midwife or nurse at a time. A patient may also only be registered with one doctor.

Answer to Activity 10

The Relationship shows the position of the keys within the entity. It is usually called a One-toMany relationship; hence the single element at the left and the multiple elements at the right end of the symbol. For example, take the section of the diagram showing the relationship between customer and order. From this we can state that 'one Customer makes many Orders', or, in fact, 'many orders are made by a customer'. This diagram also tells us that the order entity contains the prime key of the customer entity (verify this from the entity descriptions above). When we see a crow's foot attached to an