Section 07 (a)DFD to ERD Link1 HSQ - DATABASES & SQL By MANSHA NAWAZ 07 (a) - DFD to ERD Link And Franchise Colleges

Section 07 (a)DFD to ERD Link2 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 Link3 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) DFD - ERD links in practice

Section 07 (a)DFD to ERD Link4 College Applications (DFD fragment)

Section 07 (a)DFD to ERD Link5 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 Link6 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 Link7 If we now consider some of the flows, Reference could be added to the entity model

Section 07 (a)DFD to ERD Link8 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 Link9 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 Link10 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