Gathering Requirements continued…
The Data Our App Needs to Manage
In the last post, we took our business description of our golf tournament and identified the activities our app needs to support in order to run the event. Now, we take a look at the data our app needs to manage.
It’s tempting to jump right into FileMaker and start building tables and views, but it is worth the time to plan out our data elements ahead of construction.
This post assumes the reader knows the basics about Entity-Relationship (ER) Modeling. There are links below to some good tutorials on the subject. We’ll be using the Crow Foot Notation to model our data.
Reviewing our business description and activities list, we can identify eight separate data entities that need to be managed by our app.
E1. Person – The most fundamental entity in our model is a Person. Attributes of this entity will include items such as Name, Address, Phone.
E2. Player – A Person can also be a Player in the event. Player attributes will include items such as Handicap.
E3. Volunteer Tasks – A Person can also be a Volunteer for the event. A Volunteer Task will have attributes such as Volunteer Activity.
E4. Sponsorship – A Person purchase Sponsorships for the event. Attributes of the Sponsorship entity will include items such as Sponsorship Type and Fee.
E5. Team – A Team will be composed of one to four Players. Team attributes will include Registration Fee and Flight.
E6. Donation – A Person can make Donations of cash or prizes.
E7. Receipt – As Donations, Sponsorship, and Registration revenues are collected, a record must be made of the Receipt,
E8. Deposit – As Receipts are received, they are collected together and sent to the bank as a Deposit.
We have identified Activities that manage each of these Entities. All the other Activities will be supported by different Views looking at these Entities.
Some of the Relationships we have in our model are called out in the descriptions of the Entities. We’ll define all of them here for reference purposes.
R1. A Person can purchase one or more Sponsorships (one-to-many).
R2. A Person may make one or more Donations (one-to-many).
R3. A Person can be a Player (one-to-one).
R4. A Team can have up to four Players (one-to-many).
R5. A Person can volunteer for one or more Volunteer Tasks (one-to-many).
R6. Once revenues are received from a Sponsorship, Donation or Team registration, a Receipt is formed (soft relationship).
R7. A Deposit is made of one or more Receipts (one-to-many).
The Logical Data Model
Given the Entities and Relationships, we can model our data in the diagram below (click on the image to get a full-size version):
Caveats to this diagram:
- Database purists will note this is not 3rd Normal Form (3NF). I argue that for purposes of this app, bringing the model into 3rd Normal Form will overly complicate the model.
- Although this is a logical model, we added Date Created and Date Modified attributes to each Entity. This is a best practices technique.
Next time, we’ll identify the Views needed to support the Activities in our app.
First Post – Links to all Simple FileMaker posts can be found on this page.
ER Model Basic Concepts tutorial.
Crow Foot Notation tutorial.
These are some of the better books to introduce you to logical data modeling. See here for full disclosure on Amazon links.