And Franchise Colleges
HSQ - DATABASES & SQL
07 (a) - DFD to ERD Link
By MANSHA NAWAZ
Section 07 (a)
DFD to ERD Link
1
DFD - ERD Links
•
Systems modelled using
either : Entity Relationship (E-R) Modelling.
– Provide us with a Top Down approach to producing TABLES
or
: Normalisation.
– Provide us with a Bottom Up approach to producing TABLES
•
It is worth considering the tie-up between ERDs and DFDs
• DFD : Entities, Dataflow, Processes & Datastores
• ER & NF : Provides the optimum tables for each datastore
• Produce an ERD fragment for each datastore
• Combine these fragments for a complete ERD
Section 07 (a)
DFD to ERD Link
2
DFD - ERD links in practice
•
Read this sub-section in your own time.
•
It is intended as a guide to show the development from Analysis (DFD) to Design
(ERD)
•
Firstly, the link between ERDs and DFDs. This is worth considering both as a
consistency and completeness check, and to help in developing one type of
diagram when the other already exists. Yourdon's rule for the link between the
two types of diagram is that there should be a one to one correspondence
between the entities on the ERD and the Data Stores on the DFD. This might just
work for the Chen notation adopted by Yourdon if you don't count associative
object types as entities. But it is certainly too simplistic for ERDs drawn with the
crow's feet notation.
•
Consider the DFD for college applications in the DFD fragment (from SAD
module)
Section 07 (a)
DFD to ERD Link
3
College Applications
(DFD fragment)
Section 07 (a)
DFD to ERD Link
4
•
We can start by extracting the stores as entities, but we need to do more than just
think about the relationships between these entities if we're to construct a good
ERD. Let's think about the External Entities. Well, Graduate could be a valid
addition to our entity model. Presumably, graduates could apply for more than
one postgraduate course, so we could model this on our ERD..
Section 07 (a)
DFD to ERD Link
5
•
Here each graduate sends many applications and each application is sent by one
graduate. Similarly, Referee might be added to our model.
Section 07 (a)
DFD to ERD Link
6
•
If we now consider some of the flows, Reference could be added to the entity
model
Section 07 (a)
DFD to ERD Link
7
•
Each Referee may supply a reference for more than one graduate, the relationship is
'each referee supplies many references and each reference is supplied by one referee'.
Similarly, Home Applications and Other Applications would be useful additions to our
entity model. These could come in as sub-types of Application. We won't worry about
the cardinality here, but each home application is checked against exam results and
each other application requires a reference.
Section 07 (a)
DFD to ERD Link
8
•
Finally, the processes on the DFD won't give us any help with the entities, but they
might correspond to some of the relationships. For example, we can see that the
processes on the DFD for checking entry requirements, exam results and references
could be reflected in the relationships on the ERD
Section 07 (a)
DFD to ERD Link
9
•
The link between DFDs and ERDs is not clear cut. However the following guide will assist
you.
•
•
All datastores on a DFD should be taken across to the ERD as entities
Also consider the External Entities and Data Flows as candidate entities.
•
The processes might give us some help with the relationships.
•
When we've got an ERD that we're happy with, what should we record in the Data
Dictionary?
•
Entities and Relationships could be recorded in a similar way to Data Stores and Data Flows.
•
That is, for entities, the Data Dictionary should automatically capture connected
relationships, and allow the attributes to be recorded. For relationships, the Data Dictionary
should automatically capture connected entities. In the Chen notation, which has the
concept of relationships having data via associative object types, there should also be the
facility to record attributes. In the crow's feet notation, this probably isn't necessary.
The only addition to the Data Dictionary needed for entities and relationships is a way of
identifying a key, that is, a unique identifier for the entity or relationship made up of one or
more attributes. Yourdon suggests that key attributes could be prefixed with an @.
•
Section 07 (a)
DFD to ERD Link
10