Entities are the things about which we seek information.
Attributes are the data we collect about the entities.
Relationships provide the structure needed to draw information from multiple entities. Generally, ERDs look like this:
adapted from another professor.
Developing an ERD
Developing an ERD requires an understanding of the system and its components. Before discussing the procedure, lets look at a narrative created byProfessor Harman.
Consider a hospital:
Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two. Heathcare assistants also attend to the patients, a number of these are associated with each ward. Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time. The system must record details concerning patient treatment and staff payment. Some staff are paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade). The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put).
How do we start an ERD?
1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above). 2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity); identified in the narrative (see highlighted items above). 3. Add attributes to the relations; these are determined by the queries,and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers. What questions can we ask?
a. Which doctors work in which wards?
b. How much will be spent in a ward in a given week?
c. How much will a patient cost to treat?
d. How much does a doctor cost per week?
e. Which assistants can a patient expect to see?
f. Which drugs are being used?
4. Add cardinality to the relations
Many-to-Many must be resolved to two one-to-manys with an additional entity Usually automatically happens
What is a data flow diagram (DFD)?
Data Flow Diagrams (DFD) helps us in identifying existing business processes. It is a technique we benefit from particularly before we go through business process re-engineering. At its simplest, a data flow diagram looks at how data flows through a system. It concerns things like where the data will come from and go to as well as where it will be stored. But you wont find information about the processing timing (e.g. whether the processes happen in sequence or in parallel). We usually begin with drawing a context diagram, a simple representation of the whole system. To elaborate further from that, we drill down to a level 1 diagram with additional information about the major functions of the system. This could continue to evolve to become a level 2 diagram when further analysis is required. Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very common. Please bear in mind that the level of detail asked for depends on your process change plan.
Now wed like to briefly introduce to you a few diagram notations which youll see in the tutorial below.
An external entity can represent a human, system or subsystem. It is where certain data comes from or goes to. It is external to the system we study, in terms of the business process. For this reason, people use to draw external entities on the edge of a diagram.
A process is a business activity or function where the manipulation and transformation of data takes place. A process can be decomposed to finer level of details, for representing how data is being processed within the process.
A data store represents the storage of persistent data required and/or produced by the process. Here are some examples of data stores: membership forms, database table, etc.
A data flow represents the flow of information, with its direction represented by an arrow head that shows at the end(s) of flow connector.
What will we do in this tutorial?
In this tutorial we will show you how to draw a context diagram, along with a level 1 diagram. Note: The software we are using here is Business Process Visual ARCHITECT Analyst edition. You are welcome to download a free 30-dayevaluation copy of Business Process Visual ARCHITECT to walk through the example below. No registration, email address or obligation is required.
Steps to Draw a Context Diagram
1.To create a new DFD, select Business > Data Flow Diagram from the toolbar at the top. 1.To rename the new diagram, right click on the background and select Rename¦. In the diagrams name box (at the top left corner), enter Context and press ENTER. 2.Well now draw the first process. From the Diagram Toolbar, drag Process onto the diagram. Name the new process System.
Next, lets create an external entity. Place your mouse pointer over System.
Drag the resource icon Bidirectional Data Flow > External Entity to the left and release your mouse to create one.
Name the new external entity Customer.
Now well model the database accessed by the system. Again, place your mouse pointer over System but this time drag a different resource icon called Bidirectional Data Flow > Data Store to the right. Then release your mouse to create a new data store.
Name the new data store Inventory.
Create two more data stores, Customer and Transaction, as shown below. We have just completed the Context diagram.
Steps to Draw a Level 1 DFD
1.Instead of creating another diagram from scratch, we will decompose the System process to form a new DFD. Right click on System and select Decompose from the popup menu.