４ 演習問題

(1) 名詞を抜き出しなさい

エンティティを見つけるためには、何らかの情報がないといけません。何の情報もなしにエンティティを見つけることはできません。

エンティティを見つけるためには、業務説明書などを参照します。業務説明書には、業務目的、業務の概要、システム画面イメージなどが記述されています。

また、通常、システムを開発する場合、システム開発の依頼者やシステムの利用者にヒアリングを行い、その結果を議事録としてまとめます。その場合には、エンティティを見つけるために議事録を参照します。

このように、業務説明書、議事録などを参考にして、業務で重要な概念が何かを検討します。しかし、業務説明書などを読んで重要な概念をすぐに思い浮かべるのは困難かもしれません。そこで、業務に関する説明や画面イメージから名詞を抜き出し、整理するという方法を行います。

ところで、以下のように業務説明や画面イメージなどから名詞を抜き出す際には、何らかの観点を持っておくと重要な概念を抜き出しやすいでしょう。例えば、次のようなものを名詞だと考えたらよいでしょう。

• 人物や役割に関する名詞　（例）申込者、受講者、社員、講師
• 場所や所属に関する名詞　（例）A社、セミナールーム
• 物に関する名詞　　　　　　　（例）コース、情報
• 出来事に関する名詞　　　　（例）開催、受講

次の業務説明から名詞を抜き出しなさい。名詞と思われる言葉をクリックして選択しなさい（ただし、同じ言葉は最初に現れる部分しかクリックに対応していません）。

(2) 業務で重要な管理対象である名詞を選択しなさい

抜き出した名詞が業務で重要な管理対象かどうかを判定します。業務で重要な管理対象であると思われる名詞を、クリックして選択しなさい。

(3) 異音同義語、同音異義語を見つけなさい

名詞のみの情報があっても、異音同義語（e-mail や電子メールあるいはメールのように表現は異なるが同じものを表している言葉）と同音異義語（価格のように同じ表現が使われていますが、実際には販売時の価格や仕入時の価格というように、異なるものを表している言葉）を充分に検討できるとは限りません。そこで、名詞の意味を日本語などの自然言語で記述します。名詞の意味を記述することにより、異音同義語や同音異義語の発見がしやすくなります。

意味を定義する対象は、エンティティを見つける途中に登場する名詞だけではありません。エンティティに限らず、属性やリレーションシップなどのモデル要素のついては、その意味を記述するようにします。

もし「e-mail」、「電子メール」、「メール」という言葉があったのならば、例えば、「メール」という言葉に統一します。

もし「価格」という言葉があったのならば、何の「価格」なのかがはっきりしないので、例えば、「販売時の価格」、「仕入時の価格」というように明確化します。

異音同義語 異なる名詞であるけれども、意味が同じ名詞

同音異義語 同じ名詞であるけれども、意味が異なる名詞

異音同義語や同音異義語が含まれていないかどうかを判定します。異音同義語であると思われる単語を名詞の欄にドラッグし、そして「統一した名詞」を記述しなさい。同様に同音異義語であると思われる単語を名詞の欄にドラッグし、「明確化した名詞」を記述しなさい。

(4) エンティティの名称を選び出しなさい

エンティティ候補の名称を選び出すには名詞を以下の観点から2つのグループに分けます。

例えば、「商品」は、「商品名」や「仕入会社」、「仕入価格」などを持つ複雑な名詞です。それに対して、「商品名」は「商品」の名前にすぎません。よって、「商品」は、エンティティの名称の可能性が高いですし、「商品名」は「商品」エンティティの属性名の可能性が高いといえます。

エンティティとなり得る名称を、クリックして選択しなさい。

(1) 「講習会」、「開催」、「講師」エンティティ間にリレーションシップを定義しなさい

とりあえず「講習会」から考えてみましょう。

当然ながら「講習会」が「開催」されます。1度の「開催」で行われるのは1つの「講習会」だけです。そして、「講習会」が「開催」されるには、開催日やセミナールームなどとともに「講師」を決める必要があります。「講師」は、「講習会」によって、あらかじめ決まっているわけではなく、「開催」を決める時に決定されます。

• 1度の「開催」で行われるのは1つの「講習会」だけ
• 「講習会」が「開催」されるには、開催日やセミナールームなどとともに「講師」を決める必要がある
• 「講師」は、「講習会」によって、あらかじめ決まっているわけではなく、「開催」を決める時に決定される

下の説明にあるカーディナリティとオプショナリティの図をドラッグして、講習会、開催、講師 エンティティ間のリレーションシップを完成してください。

カーディナリティとオプショナリティ
リレーションシップのそれぞれの側にある「種類の数」

	（0以上）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは存在しないこともあるし、複数存在することもある。
	（1以上）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは必ず１個以上存在する。
	（0または1）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは存在しないか１個だけ存在する。
	（1）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは必ず１個存在する。

講習会

開催

講師

「講習会」と「開催」の間のリレーションシップを先に考えます。

1度の「開催」で行われるのは1つの「コース」だけですが、「講習会」は何度も「開催」されますし、逆に1度も「開催」されないこともあるかもしれません。

よって、「開催」側が、0以上の 1対多のリレーションシップになります。

次に、「開催」と「講師」の間のリレーションシップです。先ほどと同様に、1度の「開催」で「講師」を務めるのは一人だけですが、「講師」は何度も「開催」される「開催」の「講師」になりますし、逆に1度も「講師」しないこともあるかもしれません。

よって、やはり「開催」側が、0以上の 1対多のリレーションシップになります。

(2) 「申込者」、「申込」、「受講者」エンティティ間にリレーションシップを定義しなさい

「申込」について考えてみましょう。

「申込者」は複数の「開催」に申し込めますが、「申込」は１件のみ作成されます。その後、申し込む「開催」を追加したとしても、「申込」は１件のみです。

申し込んだ「開催」ごとに別々の「受講者」が存在します。そして、「受講者」は「開催」ごと固有の「コード」が与えられ、それ以降この「コード」で管理されます。同じ「受講者」でも、「開催」が異なれば、違う「コード」が与えられるわけです。

• 「申込」の「申込者」は一人だけ
• 「申込」には、複数の「開催」が含まれる。同じ「申込者」の「申込」は１件のみ
• 「申込」には、複数の「開催」が含まれるので、「受講者」も複数いることが考えられる。「受講者」は「コード」で管理される

下の説明にあるカーディナリティとオプショナリティの図をドラッグして、申込者、申込、受講者 エンティティ間のリレーションシップを完成してください。

カーディナリティとオプショナリティ
リレーションシップのそれぞれの側にある「種類の数」

	（0以上）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは存在しないこともあるし、複数存在することもある。
	（1以上）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは必ず１個以上存在する。
	（0または1）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは存在しないか１個だけ存在する。
	（1）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは必ず１個存在する。

申込者

申込

受講者

「申込」と「申込者」の間のリレーションシップを先に考えます。

複数の「講習会」を申し込んでも「申込」は１件だけです。また、１件の「申込」に対して複数の「申込者」がいるわけではなく一人だけです。

よって、1対1のリレーションシップになります。

次に、「申込」と「受講者」の間のリレーションシップです。１件の「申込」で、繰り返し項目として複数の「開催」を含んでいます。そして、「開催」には必ず一人以上の「受講者」がいます。

よって、「受講者」側が１以上の 1対多のリレーションシップになります。

(3) 「開催」と「申込」エンティティ間のリレーションシップを定義しなさい

「開催」と「申込」について考えてみましょう。

同じ「開催」に対して、別々の「申込者」が「申込」することができます。

また、１回の「申込」で、異なる「講習会」の「開催」に対して、「申込」をすることができます。

下の説明にあるカーディナリティとオプショナリティの図をドラッグして、「開催」と「申込」エンティティ間のリレーションシップを完成してください。

申込者

申込

受講者

講習会

開催

講師

カーディナリティとオプショナリティ
リレーションシップのそれぞれの側にある「種類の数」

	（0以上）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは存在しないこともあるし、複数存在することもある。
	（1以上）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは必ず１個以上存在する。
	（0または1）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは存在しないか１個だけ存在する。
	（1）	相手のエンティティのデータに対して、この終端に接続されるエンティティのデータは必ず１個存在する。

申込者

申込

受講者

講習会

開催

講師

同じ「開催」に対して、複数の「申込」があり、また、１回の「申込」で複数の「開催」を申し込むことができるわけです。

ただし、「申込」が１件もない「開催」もあり得ます。

よって、「申込」側が０以上の 多対多のリレーションシップになります。

リレーションシップの説明をしたときに、多対多のリレーションシップは、エンティティを見逃している証拠であるとしました。管理対象を見逃したまま概念設計を終えるわけにはいかないので、必ず多対多を分解して、エンティティを見つけるようにしなければなりません。

これについては、後ほど、正規化によって対応します。

(1) エンティティに主キーを定義しなさい

主キーは、エンティティの属性の中でも特殊な属性です。主キーとは、エンティティのデータを１つだけ識別するための属性です。ただし、一つの属性からなるとは限りません。複数の属性で成り立つ主キーもあり、複合キーと呼ばれています。

主キーは、基本的に業務説明、画面イメージ、帳票イメージなどから発見した名詞から選びます。ただし、「申込番号」や「講師番号」などのように業務説明からでは発見できないものもあります。

また、「申込」には、「開催」が繰り返し項目として含まれています。したがって、複数の「開催番号」を含むと考えます。これも、業務説明からでは発見できないかもしれません。

それでは、「開催」と「受講者」に主キーが記述されていませんので、他のエンティティにならって指定してください。

ただし、主キーに指定できる名称は先に発見した属性か、この図の中にすでに記述してあるエンティティの主キーや属性のみです。

「開催」と「受講者」エンティティの主キーに、他のエンティティの主キーや属性名をドラッグするか直接入力して完成してください。

申込者 申込者番号

申込 申込番号 開催番号(FK)

受講者

講習会 講習会番号

開催

講師 講師番号

申込者 申込者番号

申込 申込番号 開催番号(FK)

受講者 開催番号(FK) コード

講習会 講習会番号

開催 開催番号

講師 講師番号

「開催」エンティティから見てみましょう。

「開催」には、何を、いつ、誰が、どこでといった情報が必要です。したがって、「講習会番号」「開催日」を主キーとすることも考えられますが、「申込」の外部キーとして「開催番号」がありますので、これを主キーとします。

次に、「受講者」エンティティを見てみましょう。

「受講者」には、「申込」ごとに固有のコードが与えられます。したがって、「申込」が異なれば同じコードの別の「受講者」データが存在することになります。よって、この「コード」だけでは、一意にデータを識別できませんので、これだけでは主キーになり得ません。

つまり、「受講者」データを一意に識別するためには、「コード」だけでなく、「開催」の識別のために「開催番号」も必要となります。

このように、同じことを表現するのに、「開催」、「講習会」、「セミナー」、「スケジュール」など異なる表現をすることがよくあります。日常生活では、判断できることが、ER図にしようとするとこのように悩むことになるわけです。データモデリングでは、携わる人たち全員ができるだけ誤解なく解釈できるように命名するようにする必要があります。

なお、「受講者」エンティティは、他のエンティティの主キーと関連付く識別子を持っている従属エンティティですので、角の丸い四角形にしています。

(2) エンティティに外部キーを定義しなさい

外部キーとは、リレーションシップの相手のエンティティが持つ属性です。リレーションシップの相手のエンティティの主キーを、エンティティがその属性として取り込みます。よって、外部キーによって、相手のエンティティのデータが一意に識別されます。

例えば、「申込」エンティティには、誰が「申込者」なのかが分かるように、「申込者」エンティティの主キーである「申込者番号」を外部キーとして持つ必要があります。これで、「申込者」を一人に絞り込めるわけです。

同様に、多対１のリレーションシップになっている、「受講者」エンティティから「申込」エンティティや、「開催」エンティティから「講師」エンティティを一意に識別される必要があります。

外部キーを示すために、「申込」エンティティの「申込者番号」には、横に FK（Foreign Key） という記号をつけます。

「開催」と「受講者」エンティティに、他のエンティティの主キーをドラッグするか直接入力して完成してください。

申込者 申込者番号

申込 申込番号 開催番号(FK) 申込者番号(FK)

受講者 開催番号(FK) コード

講習会 講習会番号

開催 開催番号

講師 講師番号

申込者 申込者番号

申込 申込番号 開催番号(FK) 申込者番号(FK)

受講者 開催番号(FK) コード 申込番号(FK)

講習会 講習会番号

開催 開催番号 講習会番号(FK) 講師番号 (FK)

講師 講師番号

外部キーが必要なエンティティは、「受講者」と「開催」です。

「開催」エンティティから見てみましょう。

どの「講習会」の開催なのか、誰が「講師」なのかが分かりませんので、外部キーとして「講習会」エンティティの主キーである「講習会番号」が必要です。さらに「講師」エンティティの主キーである「講師番号」を持ちます。これで、「講師」も一意に決まります。

「申込」エンティティとは、多対多なので、外部キーは持てません。１回の「開催」に対して、複数の申し込みがあるので一意に絞り込むことはできないからです。

次に、「受講者」エンティティを見てみましょう。

どの「申込」によって、作成された「受講者」データなのかが分かるように、「申込番号」を外部キーとして持ちます。

また、この例ではリレーショナルシップが設定されていませんが、もし「受講者」から誰が「講師」なのかを参照する度合いが高いのならば、「講師番号」を外部キーとして持つことも考えられます。

(3) エンティティに属性を定義しなさい

属性に指定する名称は、先に発見した属性だけでなく、思いついたものも書き込んでください。

「講師」エンティティには、業務説明からは見つからなかった「講師名」を定義しています。

属性名をドラッグするか直接入力して完成してください。

申込者 申込者番号

申込 申込番号 開催番号(FK) 申込者番号(FK)

受講者 開催番号(FK) コード 申込番号(FK)

講習会 講習会番号

開催 開催番号 講習会番号 (FK) 講師番号 (FK)

講師 講師番号 講師名

申込者 申込者番号 申込者名 住所 電話番号

申込 申込番号 開催番号(FK) 申込者番号(FK) 受講料合計

受講者 開催番号(FK) コード 申込番号(FK) 受講者名

講習会 講習会番号 講習会名 定員

開催 開催番号 講習会番号(FK) 講師番号(FK) 開催日 受講料 セミナールーム 座席数

講師 講師番号 講師名

「講師」エンティティの「講師名」が、ここで初めて使用した名称です。

また、「受講料」を「開催」エンティティに入れています。同じ「講習会」ならばいつでも「受講料」が同じあるならば、「講習会」エンティティに入れることもあり得ます。しかし、ここでは、「開催」エンティティに入れておいて、後で正規化によって修正します。

(1) 第１正規化を行いなさい

第一正規形とは、「繰り返し項目」を持たない状態です。すべての状態を１つのエンティティで管理すると、いくつかの項目が繰り返し記述されてしまうことがあります。この問題を解決するために繰り返し記載される項目を別のエンティティとして構成する必要があります。

第一正規化とは、繰り返し部分の属性を他のエンティティに分離することです。

「申込」エンティティと「開催」エンティティには、多対多のリレーションシップがあります。多対多のリレーションシップは、何らかのエンティティを見逃していることを示しています。

もう一度、業務説明を見直してみましょう。「１回の受講申込で、複数の講習会を申し込める」となっています。つまり、この「申込」エンティティには複数の「開催」という繰り返しがあるということが分かります。よって、この多対多のリレーションシップに対して第１正規化が必要となります。

よって、「申込」エンティティと「開催」エンティティの間の多対多のリレーションシップを解消します。

そして、「申込明細」エンティティを新たに作成して、 「申込」エンティティと「開催」エンティティに対して、リレーションシップを追加してください。

また、 「申込明細」エンティティの主キーや外部キーも記述してください。ただし、 その他の属性は、開催された講習会ごとの受講する人数を「受講者数」、開催された講習会ごとの受講料の合計を「受講料小計」として追加しています。

さらに、開催される一つひとつの講習会に対して、受講者がいるわけですから、「受講者」エンティティは、「申込」エンティティではなく「申込明細」エンティティとリレーションシップが定義されることになります。リレーションシップの関係が変わるわけですから、外部キーの定義も変わりますので忘れないで指定してください。

カーディナリティとオプショナリティ

		（0以上）
		（1以上）
		（0または1）
		（1）

申込 申込番号 申込者番号(FK) 受講料合計

申込明細 申込番号(FK) 開催番号(FK) 受講者数 受講料小計

受講者 開催番号(FK) コード 申込番号(FK) 受講者名

開催 開催番号 講習会番号(FK) 講師番号 (FK) 開催日 受講料 セミナールーム 座席数

繰り返し項目とは、エンティティに２回以上現れる属性です。正規化する前の「申込」エンティティでいえば、複数申し込んだ「開催」です。したがって、「申込」エンティティには、「開催番号」という繰り返し項目があるといえます。

繰り返し項目を持つエンティティは非正規形と呼ばれています。第１正規化は、非正規形から繰り返し項目を除く作業です。つまり、「申込」エンティティから繰り返し部分を「申込明細」エンティティとして分離します。

「申込明細」エンティティの主キーを考えます。

分離した「申込明細」エンティティは元の「申込」エンティティと関連づいていなければいけません。よって、主キーとして「申込番号」が必要です。しかし、これだけでは、繰り返し部分を個別に識別できませんので、さらに「開催番号」を追加します。「開催番号」は繰り返し部分ごと固有の値を持つので、個別に識別することができます。

したがって、「申込明細」エンティティの主キーは「申込番号」と「開催番号」になります。

また、「申込」エンティティと「申込明細」エンティティとのリレーションシップは、「申込」エンティティが１に対して「申込明細」エンティティが１以上の１対多となります。

そして、「開催」エンティティと「申込明細」エンティティとのリレーションシップは、「開催」エンティティが１に対して「申込明細」エンティティが０以上の１対多となります。

最後に、「受講者」エンティティの外部キーです。

開催される一つひとつの講習会に対して、受講者がいるわけですから、「受講者」エンティティは、「申込」エンティティではなく「申込明細」エンティティとリレーションシップが定義されることになります。どの「申込」かが分からないといけないわけですから、「申込明細」エンティティの主キーである「申込番号」を外部キーとして持つことになります。

また、「受講者」エンティティと「申込明細」エンティティとのリレーションシップは、「申込明細」エンティティが１に対して「受講者」エンティティが１以上の１対多となります。

(2) 第２正規化を行いなさい

第二正規形とは、「すべての属性が、主キー(主キーが複数の属性から構成されている場合はその全ての項目) に完全に従属している（一意に識別できる）状態」です。

第二正規化とは、主キーの一部に従属する属性を他のエンティティに分離することです。

「開催」エンティティの「受講料」は、同じ「講習会」でも「開催日」や「講師」によっても金額が変わるのならば必要です。しかし、講習会が決まれば自動的に金額が決まるのだとすれば、「開催」エンティティに存在する必要のない属性と考えられます。

変更の必要のあるエンティティを定義しなおしなさい。

講習会  講習会番号  講習会名  定員  受講料

開催 開催番号  講習会番号(FK)  講師番号(FK)  開催日  ルーム番号  座席数

「開催」エンティティの「受講料」は、講習会が決まれば自動的に金額が決まります。 「開催」エンティティのどのデータを見ても、「講習会番号」と「受講料」は同じ組み合わせだということです。 「講習会番号」が一緒なのに「受講料」が異なるということはありえないということです。

ということならば、 「受講料」は「開催」エンティティではなく、 「講習会」エンティティに従属するということになります。こうすれば、料金改定などで、「受講料」が変更になったような場合でも、すべての「開催」エンティティのデータを書き換えなくても、 「講習会」エンティティの料金改定のあったコースの「受講料」を書き換えるだけで済みます。

データの重複を最小限とし、状況の変化やシステムの拡張に柔軟に対応できるように設計しましょう。

(3) 第３正規化を行いなさい

第三正規形とは、「すべての属性が主キー以外の属性にも完全に従属している（一意に識別できる）状態」です。

第三正規化とは、主キー以外の属性に従属する属性を他のエンティティに分離することです。

「開催」エンティティの「座席数」は、セミナールームが決まれば自動的に決まるので、「開催」エンティティに存在する必要のない属性です。よって、 「開催」エンティティから取り除きます。

しかし、単に「開催」エンティティから削除してしまっては、セミナールームの座席数が分からなくなってしまいますので、新たに「セミナールーム」エンティティを追加して、そこに持たせるようにします。ここでは、ついでに「ルーム名」という属性も持たせています。

また、「開催」エンティティと「セミナールーム」エンティティとのリレーションシップは、「セミナールーム」エンティティが１に対して、「開催」エンティティが０以上の１対多となります。（コースを開催するにはセミナールームが１つだけ必要ですが、どのコースの開催でも使用されていないセミナールームがあるかもしれない）

開催 講習会番号(FK) 講習会番号(FK) 講師番号(FK) 開催日 ルーム番号(FK)

セミナールーム ルーム番号 ルーム名 座席数

「開催」エンティティの「座席数」は、セミナールームが決まれば自動的に決まるので、「開催」エンティティに存在する必要のない属性です。よって、 「開催」エンティティから取り除きます。

しかし、単に「開催」エンティティから削除してしまっては、セミナールームの座席数が分からなくなってしまいますので、新たに「セミナールーム」エンティティを追加して、そこに持たせるようにします。ここでは、ついでに「ルーム名」という属性も持たせています。

また、「開催」エンティティと「セミナールーム」エンティティとのリレーションシップは、「セミナールーム」エンティティが１に対して、「開催」エンティティが０以上の１対多となります。（コースを開催するにはセミナールームが１つだけ必要ですが、どのコースの開催でも使用されていないセミナールームがあるかもしれない）

(1) 導出属性を削除しなさい

第三正規化が終わったER図は図のようになりました。

かなりすっきりしたのですが、まだ無駄があります。導出属性が存在しているからです。導出属性とは、他の属性から導き出せる値を持つ属性です。

導出属性を探して、取り除いてください。

申込者 申込者番号 申込者名 住所 電話番号

申込 申込番号 申込者番号(FK) 受講料合計

申込明細 申込番号(FK) 開催番号(FK) 受講者数 受講料小計

受講者 開催番号(FK) コード 申込番号(FK) 受講者名

講習会 講習会番号 講習会名 定員 受講料

開催 開催番号 講習会番号(FK) 講師番号 (FK) 開催日 ルーム番号 (FK)

講師 講師番号 講師名

申込者 申込者番号 申込者名 住所 電話番号

申込 申込番号 申込者番号(FK) 受講料合計

申込明細 申込番号(FK) 開催番号(FK) 受講者数 受講料小計

受講者 開催番号(FK) コード 申込番号(FK) 受講者名

講習会 講習会番号 講習会名 定員 受講料

開催 開催番号 講習会番号(FK) 講師番号 (FK) 開催日 ルーム番号 (FK)

講師 講師番号 講師名

セミナー　ルーム ルーム番号 ルーム名 座席数

「受講料小計」は、「講習会」の「受講料」×「受講者数」で求めることができます。また、「受講料合計」は、同様に「講習会」ごとに求めた受講料の合計です。ともに、他の属性を参照して計算で求めることができます。

また、「受講者数」も導出属性と考えられます。同じ「開催番号」と「申込番号」を持つ「受講者」のレコードの件数を求めれば分かるからです。しかし、「受講者数」を求めるために、対象となる「受講者」のレコードの件数を数えるのは負荷が多いので、ここでは導出属性とはしませんでした。

導出属性をエンティティに持たせると、データ更新時に余計な値まで更新しないといけなくなります。例えば、「受講者」が増えた場合に「受講者数」、「受講料小計」、「受講料合計」も更新しなければならなくなるからです。当然、余計に値を変更しなければいけないので、変更に余分に時間がかかります。また、変更をし忘れてしまうということもあるかもしれません。

しかし、導出属性をすべて取り除くのが良いかどうかは分かりません。例えば、「受講料合計」を参照することが多い場合、その都度、「申込明細」 から「講習会」の「受講料」を調べ、さらに「受講者」の人数を求め、講習会ごとの受講料を計算し、それを合計していては、かえって効率の悪いことになるかもしれないからです。導出属性を取り除くかどうかは、充分に検討する必要があります。

したがって、導出属性を、一度取り除いた後にまた追加することも十分にあり得ます。

(2) 重複属性を追加しなさい

重複属性は、以下のような特徴があります。

• 元となるエンティティの値が変更されたら、重複属性も同じように更新しなければ、整合性が取れなくなる
• 重複属性を持てば検索のレスポンスは速くなるが、更新時にはすべての重複属性を更新しなければならないので更新のレスポンスは遅くなる

しかし、すべての重複属性が必ずしも更新されなければいけないわけではありません。

たとえば、商品に金額があり、また売り上げ明細に金額がある場合は、金額が重複属性となります。しかし、売り上げ明細の金額をなくしてしまうと、商品の金額が改定された時に、過去の売上金額が分からなくなってしまいます。

このように、元のエンティティが更新されても、一緒に更新する必要のない、あるいは一緒に更新してはいけない、あるいは更新するのに負荷が大きい属性であれば、重複属性を持つことも検討すべきです。

属性名をドラッグするか直接入力することによって、導入すべき重複属性を追加しなさい。

申込者 申込者番号  申込者名  住所  電話番号

申込 申込番号 申込者番号(FK)  受講料合計

申込明細 申込番号(FK) 開催番号(FK)  受講者数  受講料小計

受講者 開催番号(FK) コード 申込番号(FK)  受講者名

講習会 講習会番号  講習会名  定員  受講料

開催 開催番号 講習会番号(FK) 講師番号(FK) 開催日 ルーム番号 (FK)

講師 講師番号  講師名

申込者 申込者番号 申込者名 住所 電話番号

申込 申込番号 申込者番号(FK) 受講料合計

申込明細 申込番号(FK) 開催番号(FK) 受講者数 受講料小計

受講者 開催番号(FK) コード 申込番号(FK) 受講者名

講習会 講習会番号 講習会名 定員 受講料

開催 開催番号 講習会番号(FK) 講師番号(FK) 開催日 ルーム番号(FK) 受講料

講師 講師番号 講師名

セミナー　ルーム ルーム番号 ルーム名 座席数

「講習会」ごとに「受講料」が決まっていますので、「開催」に「受講料」属性を持たなくても、受講料を知ることができます。しかし、「講習会」の「受講料」が改定されたときは、それまでに「開催」された「講習会」の受講料を計算したときにも改定された「受講料」で毎回計算しなおすことになりますので、実際に受講したときの金額とは異なることになります。

よって、もし「受講料」が変わっても「講習会番号」が変わらないのならば、「開催」にも「受講料」属性を持つ必要があります。

しかし、「受講料」変わったら、「講習会番号」も変わるということならば、「受講料」を重複属性として持つ必要はありません。

重複属性の必要性については、次のように判断します。

• 元のエンティティが更新されても、更新しなくてもよい場合は重複属性を検討する
• 元のエンティティの更新に伴い、更新しなければならない場合は重複属性を持たない