ダイヤモンドスキーマ：どのように正規化されていますか？

Question

のは、我々は次のエンティティを持っているとしましょう：この単純な世界では

• 制作スタジオ
• ジャーナリスト
• カメラオペレーター
• ニュース映像

、制作スタジオは、多くのジャーナリストや多くを持っていますカメラオペレータ。各ジャーナリストは正確に1つのスタジオに属します。オペレーターと同じこと。 1人のジャーナリストと1人のオペレータがニュース映像を制作します。どちらも同じスタジオから来ています。

はここでリレーショナルデータベースにこのモデルを置くために私の単純なアプローチです：

CREATE TABLE production_studios(
    id     SERIAL PRIMARY KEY, 
    title    TEXT NOT NULL 
); 

CREATE TABLE journalists(
    id     SERIAL PRIMARY KEY, 
    name     TEXT NOT NULL, 
    prodution_studio_id INTEGER NOT NULL REFERENCES production_studios 
); 

CREATE TABLE camera_operators(
    id     SERIAL PRIMARY KEY, 
    name     TEXT NOT NULL, 
    production_studio_id INTEGER NOT NULL REFERENCES production_studios 
); 

CREATE TABLE news_footages(
    id     SERIAL PRIMARY KEY, 
    description   TEXT NOT NULL, 
    journalist_id  INTEGER NOT NULL REFERENCES journalists, 
    camera_operator_id INTEGER NOT NULL REFERENCES camera_operators 
); 

このスキーマフォームうまく形のダイヤモンドERDといくつかの質問。

ニュースの映像は、異なる制作スタジオから来たカメラオペレーターと一緒にジャーナリストをリンクすることができます。対応する制約を記述することでこれが解決できることを理解していますが、実験のために、標準フォームデータベース設計でエクササイズを行っているようです。

1. 最初の質問は、用語についてです：このスキーマが非正規化であると述べるのは正しいですか？はいの場合は、どの通常のフォームが壊れますか？または、レコード間の冗長性、マルチパス関係など、この異常の名前がありますか？

2. このスキーマを記述して、異常を説明する方法を変更する方法はありますか？

もちろん、この特定の問題に取り組んでいる論文を参考にしていただければ幸いです。

Answer 1

あなたのジャーナリストとcamera_operatorsをに依存するエンティティにすることは、彼らが働くスタジオに依存していることになります。つまり、制作スタジオの外部キーが主キーの一部になります。

• journalist_id：
• camera_operator_id
• footage_id

と2つの外部キーをjournalist_id

• production_studio_id：あなたnews_footageテーブルは、次に、4つの成分から成る主キーを有します、production_studio_id、poジャーナリストのテーブルにinting、および
• camera_operator、production_studio_id、簡単

カメラオペレータテーブルを指します。

またはそうではありません。これで、カメラオペレーターやジャーナリストのがスタジオに依存しているという考えをE-Rモデルに定義しました。これは実際の仕事をとてもよく反映しているわけではありません。このモデルでは、人々は自分の雇用主を変えることはできません。

しません。

の人物と遊んでいる人（ジャーナリストまたはカメラオペレーター）と混同していて、あなたのニュース映像の制作を実際に担当する一時的なエンティティが不足しています。[[スタジオ専用]制作チーム。

マイERモデルはこのようなものになります。

create table studio 
(
    id int not null primary key , 
    title varchar(200) not null , 
) 

create table person 
(
    id int not null primary key , 
    title varchar(200) not null , 
) 

create table team 
(
    studio_id   int not null , 
    journalist_id  int not null , 
    camera_operator_id int not null , 

    primary key (studio_id , journalist_id , camera_operator) , 

    foreign key (studio_id   ) references studio (id) , 
    foreign key (journalist_id  ) references person (id) , 
    foreign key (camera_operator_id) references person (id) , 

) 

create table footage 
(
    studio_id   int not null , 
    journalist_id  int not null , 
    camera_operator_id int not null , 
    id     int not null , 
    description  varchar(200) not null , 

    primary key (studio_id , journalist_id , camera_operator_id , id) , 

    foreign key  (studio_id , journalist_id , camera_operator_id) 
    references team (studio_id , journalist_id , camera_operator_id) , 

) 

を今、あなたは、人々が異なる役割で働くことが可能な世界を持っている：同じ人には、いくつかの状況でカメラオペレーターとジャーナリストであるかもしれません他にもあります。人々は雇用主を変えることができます。ジャーナリストとカメラオペレーターで構成されるスタジオ固有のチームが構成されています。状況によっては、同じ人物がチームで両方の役割を果たすこともあります。そして最後に、スタジオ固有のチームが1つだけのニュース映像を制作します。

これは実際の世界をはるかに良く反映しており、はるかに柔軟です。

編集サンプルクエリを追加するには：特定のスタジオのために働くジャーナリストを見つけるには

を：

select p.* 
from studio s 
join team t on t.studio_id = s.id 
join person p on p.id  = t.journalist_id 
where s.title = 'my desired studio name' 

これはあなたにしている（または持っている）人々の集合を与えるだろうが、スタジオに関連付けられてジャーナリストの役割で現実世界では、ある期間、雇用者のために働くということに注意する必要があります。適切にモデル化するには、開始日と終了日が必要で、現在の相対的な概念でクエリを修飾する必要があります。