Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Consistency
This material was covered during lectures on February 5, 1997.
Both the entity-relationship diagram and the data flow diagrams provide a way the represent the ``stored data'' that the system must remember to function. The entity-relationship diagram doesn't really show anything else (but it does show logical ``relationships'' between different pieces of stored data clearly, and can be helpful later on, when you want to design the data stores for the system). The data flow diagram(s) shows ``stored data'' using data stores.
If the entity-relationship diagram and data flow diagrams are developed completely independently, then there's a danger that the two models of ``stored data'' that they provide will be contradictory.
In order to prevent this, Edward Yourdon has proposed a simple ``consistency rule'' for entity-relationship diagrams and data flow diagrams, which can be found in his book ``Modern Structured Analysis.''
Every data store in the data flow diagram (or set of data flow diagrams) for a system must correspond to exactly one entity (but not ``virtual'' supertype), relationship, associative object, or weak entity in the entity-relationship diagram, and each entity (but not ``virtual'' supertype), relationship, associative object, and weak entity in the entity-relationship diagram should correspond to exactly one data store in the data flow diagram(s).
If you follow this rule then developing data dictionary definitions for data stores is trivial, provided that you've already developed a data dictionary for the ERD.
The entity-relationship diagram models stored data that can be represented as a set of data tables; the number of instances of each entity, relationship, etc., in the entity-relationship diagram is supposed to be ``unbounded'' - or, at least, it should be possible for the number of instances to be quite large.
However, it may be necessary for asynchronous processes in a system to share access to one (or a very small, fixed number of) piece(s) of information. It wouldn't be appropriate to model this in the entity-relationship diagram, and you'd probably use a ``register'' rather than a ``data base'' to maintain this information as part of an implemented system. It certainly should be shown on a data flow diagram - as a ``data store'' that won't correspond to anything shown on the system's entity-relationship diagram.
Please do include data stores on DFDs that don't correspond to anything on entity-relationship diagrams, when it's necessary to do so in order to model this kind of information.
We will see, later on, that it isn't always necessary to use a separate data table for each entity and relationship, etc., in a system's data base. In particular, if each instance of an entity participates in exactly one instance of the relationship, so that the relationship type is ``1:1,'' ``1:1c,'' ``1:M,'' or ``1:Mc,'' then you could use a single data table to represent both this entity and this relationship.
It's tempting to represent this entity and this relationship by a single data store on the system's data flow diagrams, as well. You might end up with a slightly less ``cluttered'' set of diagrams, if you were to do this.
On the other hand, it would also (slightly) complicate the process of developing the definition of the data store (particularly, the process of defining the data store's ``type''). Expressing the type as a sequence of aggregations of the entity's type and the relationship's type wouldn't be quite right, because this would suggest that the attributes in the entity's primary key should be included twice in each instance of what's being stored. Alternatively, you could list the attributes (making up the instance of what's being stored) explicitly in the definition. However, this mean that some information would need to be shown in more than one place in the data dictionary (such as the attributes making up the entity), increasing the risk that errors might be introduced when changes are made.
Rather than introduce these slight complications (and, since we haven't yet seen how to represent two components of the ERD with a single ``data table,'' anyway), I will suggest that you not try to represent multiple components of the ERD with a single data store in this course; the ERDs and data flow diagrams that you'll be reading and developing will be simple enough, so that this should not cause problems or too much extra work.
As has already been mentioned, each process in the system's data flow diagrams should be ``refined'' or ``specified'' in exactly one way - either using a lower level data flow diagram, or using a process specification, but not both. The only process specifications that should be included that are the ones that are needed for processes on the data flow diagrams; that is, don't include a ``process specification'' that doesn't correspond to some ``process.''
Every attribute of every component of the ERD, every component of the ERD (entity, relationship, etc.), every data store on the data flow diagram(s), and every data flow on the data flow diagram(s), should have exactly one definition in the system's data dictionary.
The data dictionary can also include ``auxiliary definitions'' that don't correspond to any of the above, but that are used in order to define the ``type'' in one of the above definitions. The data dictionary shouldn't include any other definitions, except for these.
In particular, please note that the data dictionary shouldn't include definitions for any ``local variables'' that you might refer to in a process specification, but that don't appear as data flows anywhere on the data flow diagrams.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Consistency of the Specification