问题
This is my first project outside of school so I'm rusty and lacking practice.
I want to create a database but I'm not sure if I'm doing ok so far. I need a little help with the reports table.
The situation:
- The food bank has multiple agencies who hand out food
- Each agency has to submit a report with how many families/people served from a long list of zip codes.
- I thought of putting a fk on Report to Zips table. But will that make selecting multiple zips impossible?
Maybe I'm way off base. Does someone have a suggestion for me?
回答1:
A better name for this table might be FoodService or something. I imagine the kind of reports you really want to end up are not just a single row in this table, so naming it Report is a bit confusing.
In any case, each Report is the unique combination of {Agency ID, ZIP code, Date} and of course Agency ID is a foreign key. The other columns in this table would be number of families and people served, as you've indicated. This means you'll have rows for each agency-ZIP-date combination like this:
Agency | ZIP | Date | FamiliesServed | PeopleServed
Agency A | 12345 | Jan-12 | 100 | 245
Agency A | 12340 | Jan-12 | 20 | 31
Agency B | 12345 | Jan-12 | 80 | 178
Agency B | 12340 | Jan-12 | 0 | 0
Are these totals also broken down by "program"? If so, program needs to be part of the primary key for this table. Otherwise, program doesn't belong here.
Finally, unless you're going to start storing data about the ZIP codes themselves, you don't need a table for ZIP codes.
回答2:
Usually having orphan tables like "Food" is a sign something's missing. If there's that much data involved, you'd think it would link in to the order model in some capacity, or at the very least you'd have some kind of indication as to which agency stocks which kind of food.
What's curiously absent is how data like "families-served" is computed from this schema. There doesn't seem to be a source for this information, not even a "family served" record, or a spot for daily or weekly summaries to be put in and totalled.
A "Zips" table is only relevant if there is additional data that might be linked in by zip code. If you have a lat/long database or demographic data this would make sense. Having an actual foreign key is somewhat heavy handed, though. What if you don't know the zip? What if, for whatever reason, the zip is outside of the USA? How will you handle five and nine digit zip codes?
Since zips are not created by the user, the zips table is mostly auxiliary information that may or may not be referenced. This is a good candidate for an isolated "reference" table.
Remember that the structure of a diagram like this is largely influenced by the front-end of the application. If users are adding orders for food items, that translates into relationships between all three things. If agencies are producing reports based on daily activity logs, then once again you need relationships between those three entities.
The front end is usually based on use-cases, so be sure you're accommodating all of those that are relevant.
来源：https://stackoverflow.com/questions/14016569/need-help-designing-erd-for-food-bank