📝

【輪読会】楽々ERDレッスン (CodeZine BOOKS)

2023/05/13に公開

第1章

諸口問題

「その他もろもろ」を管理する時にコードやidなどのユニークキーを「顧客コード: 9999」などと設定して複数の顧客に対してこのIDを設定して管理する問題。

顧客でも取引が多い顧客、少ない顧客が存在するが取引が少ない顧客に対してあまり管理する必要性がないために9999として適当に管理する。

データ指向アプリケーションで現実世界の取引顧客の数 != データ上の顧客の数となるのはもはや敗北宣言である。

もしそのように運用したい場合は以下のようにして顧客管理をすれば良い

CREATE TABLE 顧客
(顧客ID               INTERGER PRIMARY KEY,
 顧客コード       VARCHAR(9),
 名前                  VARCHAR(50),
....
);

このようにすれば、顧客コードに9999を入れても別の顧客として管理できるし、特に9999じゃなくてもいいのであればnullを入れることも可能。

関数従属性

  • 関数従属性
  • 部分関数従属性
  • 推移的関数従属性

関数従属性

https://atmarkit.itmedia.co.jp/ait/articles/1703/01/news181.html

関数従属性:

上記図のように、商品コードをを決めると、単価・商品名が一位に決まるので「単価(または商品名)は商品コードに関数従属している」と表現する。

  • 決定項 → 商品コード
  • 被決定項 → 単価(or商品名)

決定項、被決定項が複数となる倍の関数従属もある

部分関数従属性

説明の通り、

「候補キー[1]{社員番号、部門コード}の一部である部門コードに部門名が関数従属している」

ここでは一部のみ(部門コードのみ)で従属関係が表せるが、候補キーの一部ではなく全てに対して関数従属している状態を、「完全関数従属している」という

推移的関数従属性

関数従属が推移的に行われている。

画像のものでは、社員番号がわかれば社員が住んでいる住所が特定できる。
社員が住んでいる住所がわかれば、その郵便番号がわかる。というように推移的に関数従属している状態。

計画系のコードの扱い

XXXコードを主キーとするということに囚われすぎると、このパートで紹介している計画系のコードの扱いができなくなる。

商品開発などでコードがスペックと対になっていたりして開発が進んでいく上で商品コードが変わっていく場合などのことを考えると今までのように商品コードをPKとして処理するとうまくデータとして持てない。そのため商品コードに履歴テーブルのように開始・終了を管理することで対応できる

m:m問題(コード体系の統一不可能問題)

これは社内と社外で商品コードが別で使われてをおり、しかも社外取引が複数社にわたって別のコードを使っている場合などはどうするかという問題。

これはシンプルに中間テーブル(本書では交差エンティティ・関連エンティティと呼ばれている)を使って解決できる。

https://simply-k.hatenadiary.org/entry/20100716/1279234458

データライフサイクルとID

このパートでは、物理削除と論理削除について話されていた。

  • 物理削除したくない場合は論理削除使ってね。
  • 物理・論理削除してデータのIDは再利用しないほうがよい

また、OLTP(オンライントランザクション処理)と、DSS(意思決定支援)という単語も出てきた。

OLTP

OLTP(オンライン・トランザクション処理)は通常、インターネット経由で多数の人により実行される膨大なデータベース・ トランザクションを、リアルタイムで処理できるようにするものです。
参考: https://www.ibm.com/jp-ja/topics/oltp#:~:text=OLTP(オンライン・トランザクション処理)は通常、インターネット経由,照会を意味します。

DSS

意思決定支援システム(いしけっていしえんシステム、Decision support system;DSS)とは、コンピュータを利用した情報システムの一種で、その名の通り企業や組織の意思決定を支援する。組織の経営・運用・計画などに使用され、現象が複雑で、事前には結果を推定しにくい意思決定を支援する。

とのことなのでBIとかのツールのことだと思う

2-6 重複の排除

前半では正しく正規化(無理なく無駄なくみたいなこと言ってた)しましょうというのを言っている。

ここでSQLのVIEWの概念が出てきたのでお勉強

ビューの作成
ビューとはテーブルから取得したいデータの条件を定義してあたかも独立したテーブルのように扱えるようにしたものです。ビューそのものはデータを持たず、元となったテーブルからデータを参照します。例えばテーブルの一部のカラムだけを取り出したビューを作成し、他のユーザーにはビューだけを閲覧できるように権限を設定するといった利用ができます。ここでは MySQL でビューを使用する方法について解説します。
参考:https://www.javadrive.jp/mysql/view/

要は物理的にテーブルは持たないけれども、VIEWを作成することで色々なテーブルからデータを集めてきてあたかもテーブルがあるように見せるよ。ということ

viewの使い所
参考: https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0058#sec3

viewの機能を利用することでメリットとなる部分は

  • 特定のカラムだけを表示させることが可能になる。(⁠それ以外のカラムを表示させないようにできる)
  • JOINが多いSQLは再利用するのであればviewによって簡潔に記述することができ、他人でも理解し易いSQLになる

なるほど、いらない情報は削ってユーザーにとって使いやすいようにする時とかに便利なわけか。

脚注
  1. 候補キー:候補キーは主キーの候補となるもの。候補キーの中から主キーを選んで運用する。候補キーは複合キーもあり得る。
    https://nwdb.exblog.jp/862558/ ↩︎

Discussion