3

これは私の学校外での最初のプロジェクトなので、さびついて練習が不足しています。

データベースを作成したいのですが、今のところうまくいっているかどうかわかりません。レポート テーブルについて少し助けが必要です。

状況：

  • フードバンクには、食品を配布する複数の機関があります
  • 各機関は、郵便番号の長いリストからサービスを提供した家族/人々の数を含むレポートを提出する必要があります.
  • Report to Zip テーブルに fk を配置することを考えました。しかし、それでは複数の zip を選択できなくなりますか?

多分私はベースから外れています。誰か私に提案がありますか？

ここに画像の説明を入力

4

2 に答える 2

1

通常、「食べ物」のような孤立したテーブルがあることは、何かが欠けている兆候です。関係するデータが非常に多い場合は、ある程度の容量で注文モデルにリンクしていると思います。少なくとも、どの代理店がどの種類の食品を在庫しているかについて、何らかの指標があります。

不思議なことに欠けているのは、「家族向け」のようなデータがこのスキーマからどのように計算されるかです。この情報の出典はなく、「家族で提供された」記録や、毎日または毎週の要約を入れて合計する場所さえないようです。

「Zips」テーブルは、郵便番号によってリンクされる可能性のある追加のデータがある場合にのみ関連します。緯度/経度のデータベースまたは人口統計データがある場合、これは理にかなっています。ただし、実際の外部キーを持つことはやや手間がかかります。zipがわからない場合はどうなりますか？何らかの理由でzipが米国外にある場合はどうなりますか？5桁と9桁の郵便番号をどのように処理しますか？

zipはユーザーが作成するものではないため、zipテーブルはほとんどの場合、参照される場合とされない場合がある補助的な情報です。これは、分離された「参照」テーブルの候補として適しています。

このような図の構造は、アプリケーションのフロントエンドに大きく影響されることに注意してください。ユーザーが食品の注文を追加している場合、それは3つすべての関係に変換されます。代理店が毎日の活動ログに基づいてレポートを作成している場合は、もう一度、これら3つのエンティティ間の関係が必要です。

フロントエンドは通常、ユースケースに基づいているため、関連するすべてのユースケースに対応していることを確認してください。

于 2012-12-24T03:20:04.027 に答える
1

このテーブルのより適切な名前は、FoodServiceなどです。最終的に作成したい種類のレポートは、このテーブルの1行だけではないので、レポートという名前を付けるのは少し混乱します。

いずれの場合も、各レポートは{エージェンシーID、郵便番号、日付}の一意の組み合わせであり、もちろんエージェンシーIDは外部キーです。この表の他の列は、あなたが示したように、家族と奉仕された人々の数です。これは、次のように、代理店とZIPと日付の組み合わせごとに行があることを意味します。

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

これらの合計も「プログラム」ごとに分類されていますか？その場合、プログラムはこのテーブルの主キーの一部である必要があります。それ以外の場合、プログラムはここに属していません。

最後に、郵便番号自体に関するデータの保存を開始する場合を除いて、郵便番号のテーブルは必要ありません。

于 2012-12-24T03:21:25.003 に答える