Synopsis: In the DFD assignment for WalkMyDog, you used data stores to facilitate the operations of your modules (programs). While the DFD captures the dynamic behavior of your application, data stores are needed to maintain the static things of your application. You should go through my lecture notes on Common Sense Database one more time to refresh your understanding.

Follow the Steps

(1) Identify entities. For example, DogOwner, Dog, DogWalker are potential GOOD and CONCRETE entities. Other entities may be Dispute, Review, Request, etc. These are just a few of the obvious ones for you to start. You should study the DFD and see if you could identify any other entities.

If they are GOOD entities, you can use your imagination to create the attributes of them. If you cannot think of any meaningful attributes, it may not be an entity. However, you dont need to exhaust all the attributes, just the salient ones that are unique to the entity. Think this way: entity is a table, attribute is the column of the table. Also, remember, every table needs a PRIMARY KEY.

(2) Identify relationship. What are the relationships (also known as cardinalities, or multiplicities, or memberships) between the entities you have identified in (1)? They are either 1-to-1, 1-to-many and many-to-many (YOU HAVE TO READ MY COMMON SENSE DATABASE LECTURE.) For example, a DogOwner has a 1-to-many relationship with Dog. It means a dog owner may own 1 or more dogs. AND, A (ONE) DOG BELONGS TO ONE DOG OWNER. IT MEANS YOU DO NOT SUPPORT A SITUATION THAT A DOG IS CO-OWNED BY MORE THAN ONE DOG OWNERS. This is the so-called business rule of the application.

Once the relationships are ironed out, make sure you enforce the referential integrity, a.k.a foreign key, in the tables, when appropriate.

WHAT TO DO:

(1) Design your ERD with Visio using the crows foot notation. Copy and paste your design to a Word document.

(2) Describe the business rules you use to define the cardinalities.

(3) Create a (Data Dictionary) to your ERD.

Level 0 Diagram Manage Waker Requests Manage Walker Scheduke Wak Request Info Walk Reque st Table Request Response Table Schedub Wa kerAvallablity Request RaspenseS Manage Reviews Dog Owner Da) Oog Walker DW) Ouner Review 5 Walker cction Into Dog owner Walker Owner Reviews Reviews er Revie out pos Vak walker Poi Dsputes &Dog Owner Manage Walker Selection ected Polile Manage Dog Owner Dog Owner/Dog Profile Dog Walker Profi le Table Manage Deg Waker Informatcn DO Dispute Handle Disputes DO Disputes Table DW Disputes Ta ble Dispute Admin Process Description: Good attempt. Process I.D. (1): MANAGE DOG OWNER A. B. Dog Owner (DO) inputs profile data Process stores data into Dog Owner/ Dog Profile Table A. B. C. Dog Owner (DO) files dispute claim Process takes the claim & transfers it to the HANDLE DISPUTES (7) process (via interrupt) Disputes are handled by the app administrator off-line & dispute resolutions are inputted & sent back to the MANAGE DOG OWNER (1) process & ultimately back to the dog owner Level 0 Diagram Manage Waker Requests Manage Walker Scheduke Wak Request Info Walk Reque st Table Request Response Table Schedub Wa kerAvallablity Request RaspenseS Manage Reviews Dog Owner Da) Oog Walker DW) Ouner Review 5 Walker cction Into Dog owner Walker Owner Reviews Reviews er Revie out pos Vak walker Poi Dsputes &Dog Owner Manage Walker Selection ected Polile Manage Dog Owner Dog Owner/Dog Profile Dog Walker Profi le Table Manage Deg Waker Informatcn DO Dispute Handle Disputes DO Disputes Table DW Disputes Ta ble Dispute Admin Process Description: Good attempt. Process I.D. (1): MANAGE DOG OWNER A. B. Dog Owner (DO) inputs profile data Process stores data into Dog Owner/ Dog Profile Table A. B. C. Dog Owner (DO) files dispute claim Process takes the claim & transfers it to the HANDLE DISPUTES (7) process (via interrupt) Disputes are handled by the app administrator off-line & dispute resolutions are inputted & sent back to the MANAGE DOG OWNER (1) process & ultimately back to the dog owner