1

これに似たスキーマがある場合: 

TABLE 1  
id  
column  
other_column  
etc

TABLE 2  
id  
table1_id  
some_other_table_id

次のような 3 番目のテーブルを追加することをお勧めします。 

TABLE 3  
id  
table2_id  
row_from_another_table_id

EDIT：
物事をより明確にするために、次のようなスキーマを考えてみましょう：

EVENTS  
id  
name  
other_stuff 

RANGES  
id  
time_from  
time_to  
max_people  
etc

EVENTS_PLACES  
id  
event_id  
place_id

私がやりたいことは、イベントの時間範囲を定義することです。しかし、特定の場所 ( ) での特定のイベントによって、EVENTS_PLACESこの範囲が「上書き」される可能性があります。また、イベントは複数の範囲を持つことができます。

これで質問がもう少し明確になることを願っています。

4

3 に答える 3

2

多対多の関係はBoyce-Codd Normal Formに違反しているため、適切なリレーショナル データベース スキーマに違反しているというのが私の印象です。

したがって、データをリンク テーブルに関連付けることは、実際には BCNF を実現するために必要であり、したがって有効です。データ更新の異常を回避するのが良い場合。

あなたが提示した特定のスキーマの例に進みます。これらの論理テーブル (またはエンティティ) が必要だと思いますが、

-----------------------
EventClass
-----------------------
Id
Name
... Other attributes common to every instance
-
-----------------------
TimeSlot
-----------------------
Id
Start
End
-
-----------------------
Place
-----------------------
Id
Name
Address
MaxAttendance
... etc
-
----------------------
EventInstance
-----------------------
Id
EventClassId
TimeSlotId
PlaceId
PresenterName
...Other attributes specific to the instance

EventInstanceはとの間の関係EventClassです。に固有の属性はすべて、そのエンティティに格納する必要があります。関連するイベントのグループに共通する属性は、その属性に格納する必要があります。TimeSlotPlaceEventInstanceEventClass

それはすべてデータベースの正規化の問題であり、一般的に言えば、データが正規化されているほど良いです。ただし、パフォーマンスが懸念される場合は妥協する場合があります。必要なデータが出力形式で格納されている場合、選択クエリがよりシンプルで高速になりますが、更新は地獄になる可能性があります。

適切な Indecies、Materialized Views、およびMaterialized Views の indecies を使用すると、両方の世界を最大限に活用できることを示唆することで、妥協のケースに対抗します。パフォーマンスの速度で完全に正規化されたデータの保守性。ただし、適切なスキーマを作成するには、ある程度のスキルと考慮が必要です。

于 2012-11-23T10:15:02.567 に答える
1

したがって、プロパティを持つ 2 つのテーブル間にリレーションがあり、そのリレーションのサブクラスにさらにいくつかのプロパティがあります。これはまれですが、可能です。

一夫多妻制の異性の出会い系サイトで、1 人以上の女性エンティティが 1 人以上の男性と関係を持っているとします。これらの 2 つのテーブルは、ジャンクション テーブルである Relationship と組み合わせることができます。現在、彼らの何人かは結婚しており、あなたはそれを特別なタイプの関係と考えています。Marriage は Relationship のサブクラスであり、Marriage テーブルには Relationship テーブルの id への参照があります。

もちろん、このような状況を別の方法で解決する方が簡単な場合もあります。たとえば、男性と女性の間に 2 つのジャンクション テーブルを作成するだけです。しかし、ジャンクション テーブルのリレーションシップを拡張したい状況が確かにあります。

于 2012-11-14T10:45:06.427 に答える
0

別のオプションは、「もの」間の接続の性質を説明する列を TABLE2 に追加することです。たとえば、PERSON テーブルと RELATIONSHIPS テーブルでは、最初のテーブルで「オブジェクト」をモデル化し、次に「リンク」を数秒でモデル化します。

+---------+---------+-------+--------+
| link_id | from_id | to_id |  type  |
+---------+---------+-------+--------+
|       1 |       2 |     3 | Mother |
|       2 |       8 |     3 | Sister |
+---------+---------+-------+--------+

適切なインデックスを使用すると、これは、特定の人のすべての関係を検索したり、姉妹を持つすべての人を検索したりできることを意味します。これは単純な例ですが、from_id と to_id が異なるタイプになると興味深いものになります。オブジェクトの、つまり人だけではありません。

私は過去に、さまざまなソースからデータを集約し、柔軟性を持たなければならない非常に一般的なスキーマを操作するときに、このアプローチを使用していました。明らかに、柔軟性と速度、クエリの複雑さなどの間にはトレードオフがあります。あなたの場合に役立つかどうかを判断する必要があります。

于 2012-11-14T12:52:32.590 に答える