CONTENTS コンテンツ

SQLを学ぼう!(7)

学習編-SQL

2024.06.23

 生成AIで架空のポケモンを作るためのデータベースを作る過程で必要になったSQLについて学んでいます。今回は正規化。数段階あるので一度に少しずつ進んでいこう。

入力:正規化のうち、第一正規化と第二正規化の練習問題を作ってください

出力:

もちろんです。以下に、第一正規化と第二正規化の練習問題を作成しました。

練習問題

問題1: 第一正規化

以下の非正規形のテーブルを見て、第一正規化を行い正規形のテーブルに変換してください。

Non-Normalized Table: Orders

order_idcustomer_nameproductsquantities
1AliceBread, Milk, Eggs2, 1, 12
2BobApple, Banana3, 5
3CharlieBread, Milk1, 2

質問1.1: 上記のテーブルを第一正規化し、正規形のテーブルに変換してください。

問題2: 第二正規化

以下の第一正規形のテーブルを見て、第二正規化を行い正規形のテーブルに変換してください。

1NF Table: Orders

order_idcustomer_nameproductquantity
1AliceBread2
1AliceMilk1
1AliceEggs12
2BobApple3
2BobBanana5
3CharlieBread1
3CharlieMilk2

質問2.1: 上記のテーブルを第二正規化し、正規形のテーブルに変換してください。

回答例

回答1.1:

第一正規化では、各カラムが単一の値を持つようにテーブルを変換します。元のテーブルでは、productsquantities カラムに複数の値が含まれていますので、それらを分割して新しい行を作成します。

Normalized Table: Orders (1NF)

order_idcustomer_nameproductquantity
1AliceBread2
1AliceMilk1
1AliceEggs12
2BobApple3
2BobBanana5
3CharlieBread1
3CharlieMilk2

回答2.1:

第二正規化では、すべての非キー属性が、テーブルの主キーに完全に従属するようにテーブルを分割します。元のテーブルでは、customer_nameorder_id に従属していますが、product には従属していません。これを解消するために、テーブルを分割します。

Normalized Table: Customers (2NF)

order_idcustomer_name
1Alice
2Bob
3Charlie

Normalized Table: Order_Products (2NF)

order_idproductquantity
1Bread2
1Milk1
1Eggs12
2Apple3
2Banana5
3Bread1
3Milk2

これで、テーブルが第一正規形から第二正規形に変換されました。それぞれの非キー属性が完全に主キーに従属するようになり、データの冗長性が排除されます。

 情報を詰め詰めにしないように、1カラム1データ、1テーブル1従属(1主キーから複数従属データor複数主キーから1従属データが上限)にせよってことか。第三正規化もこれでカバーされてそう。しかしどうするかはわかったがなぜがわからんな。

入力:第一~第三正規化をしていない場合、どのような弊害が発生しますか?代表的な害をそれぞれ1つ挙げてください

出力:

データベースの正規化を行わない場合、以下のような代表的な問題が発生する可能性があります。それぞれの正規化段階に対応する問題を一つずつ挙げます。

第一正規化をしていない場合の弊害

重複データの問題:

  • 第一正規化は、各カラムに単一の値を持たせることを求めます。正規化されていない場合、複数の値が1つのカラムに格納されることがあります。これにより、データの整合性が損なわれ、重複や不一致が発生しやすくなります。
  • 例: 商品リストが1つのカラムにカンマ区切りで格納されている場合、検索や更新が困難になり、データの重複や誤りが発生しやすくなります。

第二正規化をしていない場合の弊害

部分関数従属による冗長性:

  • 第二正規化は、部分関数従属を排除し、すべての非キー属性が主キーに完全に従属するようにします。正規化されていない場合、冗長なデータが発生し、データの一貫性が損なわれます。
  • 例: 顧客名が注文IDに部分的に依存している場合、同じ顧客名が複数のレコードに重複して格納されるため、顧客名の変更が必要な場合にすべての該当レコードを更新しなければならず、ミスが発生しやすくなります。

第三正規化をしていない場合の弊害

推移的関数従属による異常:

  • 第三正規化は、推移的関数従属を排除し、非キー属性が他の非キー属性に依存しないようにします。正規化されていない場合、データの挿入、更新、削除時に異常が発生します。
  • 例: 社員テーブルに部署IDと部署名が含まれている場合、部署名が部署IDに依存しているため、部署名を変更する必要がある場合にすべての該当レコードを更新する必要があります。これにより、一貫性のある更新が難しくなります。

まとめ

  • 第一正規化をしていない場合: 重複データの問題が発生し、データの整合性が損なわれます。
  • 第二正規化をしていない場合: 部分関数従属による冗長性が発生し、データの一貫性が損なわれます。
  • 第三正規化をしていない場合: 推移的関数従属による異常が発生し、データの挿入、更新、削除時に問題が発生します。

これらの問題を回避するために、データベースの正規化は非常に重要です。

 基本的にデータベース作成後の検索、更新の不具合が理由。第一正規化と検索の関係はなんとなくわかるし、第二正規化と更新の関係も更新箇所最小限にしないと更新でミスりやすい、第三正規化とデータ操作もデータ操作時に操作したいデータと従属関係にあるデータを更新する必要が出てきて、従属データの更新を忘れるとデータが間違ってしまう。あーなるほどね。完全に理解した

次回に続く

この記事をシェアする