0

次の設計パターンが受け入れられるかどうかを判断するのに苦労しています。リレーショナル モデルには、次の要件 (およびその他の要件) があります。

AppA1) アプリケーション ( 、AppB、など) を表すことができなければならずAppC、それぞれが独自の属性セットを持っています。

Internet2) すべてのアプリケーションは、(電子メール、Twitter、Facebook)、 (SMS、MMS など) などのさまざまなチャネルを介して通信できるPhoneため、プログラムとチャネルの間に多対多の関係があります。

3) 多くのプログラムで共有できる事前定義された識別子 (アドレス、電話番号、ログイン アカウント) のセットがあるため、プログラムと識別子の間には多対多の関係があります。

4) 同じ ID で複数のタイプのメッセージを送信でき、プログラムも (多対多) 送信できますが、アプリケーションごとに通信タイプの ID の使用を制限できるようにする必要があります。

基本的に、私が行ったことは、Program、Channel、IdentおよびCommunicationTypeこれらのそれぞれに関する情報を格納する 4 つのテーブルを作成することでした。設計を複雑にする(Program, Channel)、(Program, Identifier)、などのジャンクション テーブルを作成する代わりに、プライマリで構成される単一のテーブルを作成しました。これら 4 つのテーブルのキーに一意の制約を適用し(Program, Channel, Ident, CommunicationType)ます。これで、このテーブルの各レコードが特定の通信にリンクされます。

もちろん、これは私の問題を非常に簡単な方法で解決しますが、正規化の原則に反する場合、これがまったく受け入れられるかどうかを自問しています. どなたかご意見いただけないでしょうか？

4

3 に答える 3

2

基本的に、私が行ったことは、Program、Channel、Ident、および CommunicationType の 4 つのテーブルを作成して、これらのそれぞれに関する情報を格納することでした。

それは良い考えです。

(Program, Channel)、(Program, Identifier) などのジャンクション テーブルを作成すると設計が複雑になるだけでなく、これら 4 つのテーブルの主キーで構成される単一のテーブルを作成し、(Program, Channel) に一意の制約を適用しました。チャネル、Ident、CommunicationType)。

このようなテーブルを設計する場合、1 つのことに注意する必要があります。キー {Program, Channel, Ident, CommunicationType} を持つ構造では、Program と Channel、Channel と Ident、Program と CommunicationType などのあらゆる組み合わせが可能です。時にはそれは悪い考えです。

同じ識別子で複数のタイプのメッセージを送信でき、プログラムも送信できます (これも多対多) が、アプリケーションごとに通信タイプの識別子の使用を制限できるようにする必要があります。

そして、それがそれを悪い考えにしている理由です。Ident、Program、および CommunicationsType のすべての組み合わせが有効であるとは限らないと言っているようです。

有効な組み合わせを独自のテーブルに格納します。外部キー参照を使用して、データの整合性を維持します。

キー {Program, Ident, CommunicationsType} を持つテーブルを作成します。キー {Program, Channel, Ident, CommunicationType} を持つテーブルには、外部キー参照を設定できます。

知っているすべての制約を実装するのに必要な数のテーブルを作成します。テーブルが多いほど、データの整合性チェックが簡単になります。(私が言及したものよりも多くのテーブルが必要になる場合があります。2 つの列が必要であると想定しないでください。さらに必要になる可能性があります。)

{Program, Channel} をキーとするテーブルが必要かどうかは、まったく明確ではありません。しかし、もしそうなら、これらの線に沿ってテーブルを構築する必要があります。(エアコード)

create table pc (
    program_name varchar(10) not null references programs (program_name),
    channel_name varchar(10) not null references channels (channel_name),
    primary key (program_name, channel_name)
);

create table pict (
    program_name varchar(10) not null,
    channel_name varchar(10) not null,
    comm_type varchar(10) not null references communication_type (comm_type),
    primary key (program_name, channel_name, comm_type),
    foreign key (program_name, channel_name) 
        references pc (program_name, channel_name) 
);

create table your-table-name (
    program_name varchar(10) not null,
    channel_name varchar(10) not null,
    comm_type varchar(10) not null,
    ident varchar(10) not null,
    primary key (program_name, channel_name, comm_type, ident),
    foreign key (program_name, channel_name, comm_type) 
        references pict (program_name, channel_name, comm_type),
    foreign key (ident) references ident (ident)
);

必要に応じて他の列を追加します。場合によっては、重複する外部キーが必要になることがあります。ここでは必要ないと思いますが、間違っている可能性があります。

「正規化の原則に反する場合」の意味がわかりません。4 列の主キーを持つテーブルは、その理由だけで通常の形式に違反することはありませんが、他の理由による場合もあります。既知のすべての制約を実装できないことは、通常、最適化されていない設計ですが、通常の形式に違反しているからではありません。

于 2011-07-03T00:31:13.667 に答える
1

私はこれをしません。

テーブルの各ペア (または n タプル) の間に 1 つのジャンクション テーブルを作成します。これにより、最終的にクエリがより簡単になり、必要に応じて適切な方法で行を制約することもできます。

また、あるソフトウェアから別のソフトウェアへ、方向性、ペイロード、使用言語、アクセスされているクエリポイントなど、これらのジャンクションには追加の属性が必要であることに気付くでしょう。

于 2011-07-03T00:10:50.353 に答える
1

詳細を求める回答を提供して申し訳ありません。この時点での私の評判はコメントを許可しません...

説明に基づいて選択したデザインに問題はありません。

しかし、あなたの質問に真に答えるには、なぜこのデザインを選んだのかを理解することが役に立ちます。

結局のところ、すべてのキーと複合一意インデックスを持つ単一のテーブルがなくても機能します。このようにすべての組み合わせをロックダウンするのはかなり制限的です。

通信を見つけた場合でも、通信を構成する情報にアクセスするために、1 つ以上の他のテーブルと結合する必要があります。

それぞれの固有の通信パスをこのように保存する必要があるのはなぜですか?

于 2011-07-02T23:59:10.067 に答える