3

モデリングが必要なデータの問題について頭を悩ませています。テーブルと関係の概要を説明するために最善を尽くします

users (basic user information name/etc)
users.id

hospitals (basic information about hospital name/etc)
hospitals.id

pages
pages.id
user_id (page can be affiliated with a user)
hospital_id (page can be affiliated with a hospital)

ここから新しいデータが始まり、問題が発生しています

groups (name of a group of pages)
groups.id

groups_pages (linking table)
group_id
page_id

ここで注意が必要な部分があります..グループはユーザーまたは病院のいずれかが「所有」できますが、それらのページは必然的にそのユーザー/病院に関連付けられていません..さらに、「できる別のタイプのエンティティ（会社）があります」グループを所有する

グループを表示するときは、グループのタイプ（ユーザー/病院/会社）を知り、正しい関連データ（名前、住所など）を取得できるようにする必要があります。

それぞれの所有者が異なる可能性があることを知って、グループをそれぞれの所有者にリンクする方法について空白を描いています。

4

4 に答える 4

0

何らかの形の弁別器を使用する必要があります。「owner_type」を使用して列を追加するのと同様に、enum、vchar、または単にintのいずれかを使用して、列が表す所有者のタイプを表すことができます。

于 2012-07-13T13:23:11.750 に答える
0

これは、妥当な正規形と参照整合性を維持しながら、データベースで継承をモデル化する方法に関する優れたチュートリアルです。

要約バージョン：別のテーブルを作成しowners、最小限の属性セット（ユーザーと病院に共通するもの、おそらく氏名、住所、そしてもちろんid）を保持させます。ユーザーと病院にはそれぞれidの列があり、同時に主キーと参照する外部キーになりますusers.id。病院にはない属性をユーザーに提供し、その逆も同様です。owners現在、各病院は、からとからの2つの簡単に結合された行で表されていhospitalsます。

これにより、から参照できusers.idますgroups.owner_id。

（ユーザーと病院用に1つのテーブルのみを作成し、特定の行に適用されないすべての列にNULLを配置するが、すぐに扱いにくくなる、より単純な代替手段もあります。）

于 2012-07-13T13:45:45.937 に答える
0 
HospitalGroups(HospitalID, GroupID)
UserGroups(UserID, GroupID)
CompanyGroups(CompanyID, GroupID)

Groups(GroupID,....)

GroupPages(GroupID, PageID)

Pages(PageID, ...)

古典的な方法になります。

@Robertが言及したディスクリミネーターのアイデアも機能しますが、参照整合性が失われるため、テーブルを増やす代わりにコードを増やす必要があります。

于 2012-07-13T13:56:44.860 に答える
0
  • Party個人または組織の総称です。
  • テーブル内のすべての一般的なフィールド（電話番号、住所..）を保持しPartyます。
  • PersonHospitalサブタイプの特定のフィールドのみが必要です。
  • 会社の列のセットが異なる場合は、Hospital単に別のサブタイプとして追加します。
  • Hospitalと会社の列が同じである場合は、の名前Hospitalをより一般的なものに変更しますOrganization
  • PartyType弁別器です{P,H}

ここに画像の説明を入力してください

于 2012-07-13T16:26:46.493 に答える