データモデリングの問題で悩む

Question

私はデータモデルに苦労しています（私はデータベースにMySQLを使用しています）。私は何を思いついたのか不安です。もし誰かがより良いアプローチを提案したり、私がそれを感謝するいくつかの参考事項を指摘することができます。

データには多くの種類の組織が存在します。私は3つのレベルの分類（クラス、カテゴリ、タイプ）をしようとしています。私は「イタリア料理」を持っている場合、それは次のような分類

フードサービスがありますと言う>レストラン>イタリア

しかし、組織が複数のグループに属していてもよいです。レストランでは中国語とイタリア語も提供しています。

ORG_CLASS（のRowId、ClassCode、：だから、2つの分類に

フードサービス>レストラン>イタリア
フードサービス>レストラン>中国

分類参照テーブルは以下のようになるに適合しますクラス名）

1, FOOD, Food Services 

ORG_CATEGORY（のRowId、ClassCode、CategoryCode 、カテゴリ名）

1, FOOD, REST, Restaurants 

ORG_TYPE（のRowId、ClassCode、CategoryCode、のTypeCode、型名）

100, FOOD, REST, ITAL, Italian 
101, FOOD, REST, CHIN, Chinese 
102, FOOD, REST, SPAN, Spanish 
103, FOOD, REST, MEXI, Mexican 
104, FOOD, REST, FREN, French 
105, FOOD, REST, MIDL, Middle Eastern 

実際のデータテーブルは、次のようになる：

私ができるようになります組織には最大3つの分類があります。 ORG_TYPEの行を指す3つのGroupIdがあります。だから私は持っている私のORGANIZATION_TABLE

ORGANIZATION_TABLE（OrgGroupId1、OrgGroupId2、OrgGroupId3、OrgNameの、OrgAddres）

100,103,NULL,MyRestaurant1, MyAddr1 
100,102,NULL,MyRestaurant2, MyAddr2 
100,104,105, MyRestaurant3, MyAddr3 

データは、ダイアログは、ユーザーがclssa、カテゴリ、タイプを選択してみましょうことができ追加し、対応する中、 GroupIdには、ORG_TYPE表のROWIDが移入されます。

検索中に3つの分類がすべて選択された場合は、より具体的になります。例えば、

フードサービス>レストラン場合>イタリアの句は次のようになりの基準を、ある'where OrgGroupId1 = 100'

唯一の2レベルが

フードサービス>レストラン

私がしなければならないを選択している場合 'where OrgGroupId1 in (100,101,102,103,104,105, .....)' - そのリストに100個ある可能性があります

私はクラスレベルの検索を禁止します。それは私がクラスとカテゴリの選択を強制するでしょう

Idsは整数です。私はパフォーマンスの問題やその他の問題を見たいと思っています。

全体的には、これは機能しますか？または私はこれを投げ捨ててゼロから始めなければなりません。

Answer 1

「3つまでの」分類の3つの列を持つのが嫌いです。私の意見では、組織とタイプの間の多対多のマッピング、つまりOrganisationId、OrgGroupIdという列のテーブルORGANISATION_GROUPSを許可する相互参照テーブルを作成する方が良いでしょう。

異なるレベルの分類を照会できないという問題を解決するために、この相互参照表に実際の分類を保持するように設定できます。つまりORGANISATION_GROUPSにはOrganisationId、ClassCode、CategoryCode、TypeCodeというcolumnnsがあります。

これにより、さまざまな分類レベルでのクエリが非常に簡単になります。

このスキームで参照整合性を保つには、ORG_ *テーブルにサロゲート整数キーを使用せず、プライマリキーを実際のユニークキー、つまりClassCode、CategoryCode、ORG_TYPEのTypeCodeに設定することをお勧めします。

Answer 2

私があなたのデザインで見る問題は、少し固いということです。

まず、クラス、カテゴリ、タイプ、およびその他の分類タイプのテーブルがあります。このテーブルは自動参照されます。

分類（ID、説明、PARENT_ID）@ジョンのピックアップが示唆されているようにあなたは、持っているでしょう

ITAL, Italian, REST 
CHIN, Chinese, REST 
MEXI, Mexican, REST 
REST, Restaurant, FOOD 

次に、中間クロス：すべてのレジスタは、次のように、その直接の親を参照するフィールドを持っているでしょうあなたのレストラン（または必要なもの）テーブルと複合主キーのみを含む分類テーブル（そのコンポーネントは両方のテーブルの主キー）の間の-referenceテーブル。

FOODSERVICE_CLASSIFICATION（Rest_Id、CLASS_ID）

100, ITAL 
100, CHIN 
101, MEXI 
102, CHIN 

分類テーブルのみ葉レジスタクロス参照テーブル内で参照できるように、それを制限することが賢明であろう。

すべてのレストランを検索した例は、RESTのすべての子カテゴリを探して相互参照表で検索するのと同じくらい簡単です。これは、Oracleの単一の選択肢で記述することができます（他のRDBMSについてはわかりません）。

することができますこの方法：

• は、3つのカテゴリーに限定されることなく、あなたのレストランのために複数のカテゴリがあります。
• 相互参照表を使用してクイック検索を行います。

このスキーマは、カテゴリ化がルートとして機能する基本カテゴリを持つツリーのようなものであると想定しても問題ありません。代わりに、より緩やかな分類が必要な場合は、おそらくタグアプローチが必要になります。

Btw、私も@ジョンピックアップに同意します。この場合、実際のプライマリキーを使用する方が良いです。

HTH