達人に学ぶDB設計徹底指南書第2版・読んだまとめpart4

はじめに

本記事では、第4・5章を読んで得られた学びや感想をまとめました。

※前回記事はこちら

第4章の目次

ER図　〜複数のテーブルの関係を表現する
４ー１　テーブルが多すぎる！
４ー２　テーブル同士の関連を見抜く
４ー３　ER図の描き方
４ー４　「多対多」と関連実体

第5章の目次

論理設計とパフォーマンス　〜正規化の欠点と非正規化
５ー１　正規化の功罪
５ー２　非正規化とパフォーマンス
５ー３　冗長性とパフォーマンスのトレードオフ

第4章で習得したこと

・ER図を描くとき、最初に着目するポイントは、あるテーブルの主キーが、他のテーブルに列として含まれているかどうか

・カーディナリティ
相手のエンティティと対応するレコードの数を表す

・多対多がリレーショナルデータベースの世界において問題となる理由は、両者のエンティティが共通のキーとなる列を保持していないため、両エンティティを結合した情報を得ることができないこと。

→この問題を解決するための方法が「関連実体（associative entity）」。二つのエンティティの間に作られる、第3のエンティティ。
この関連実態には、人工的なエンティティという印象を受けることもある。ただ、作り方は単純であり、リレーショナルデータベースを使ったシステムを作る上では必ずと言って良いほど使用する技術。

第５章で習得したこと

データの整合性を保つために、正規化は必要。ただ、正規化すればするほど、SQLのパフォーマンスが悪くなる。正確には、JOINしないといけなくなるから。
このJOINにはSQLの処理の中でもう高コスト。

非正規化テーブル結合を行わなくて済むが、原則として非正規テーブルは使用は許されない。。

結合しないSQLを作るためのテーブル設計をすることによって正規形ではなくなった場合、
更新時における問題が発生することになるが、
そのトレードオフとして検索機能が非常に簡単でハイパフォーマンスなものにできる。

正規化は可能な限り高次にすることが大原則だが、性能のために非正規化が必要になる時もある🥺

論理設計を行う際には「システムの品質は（ひいては開発が成功するかどうかは）今ここで決まる！」という気概を持って臨む必要がある。かつ、論理設計を担当する人間は、正規形の論理を理解しているだけでなく、それによって生じる様々なトレードオフを知り尽くした上で、あらゆる要件を同時に満たせる平衡点を探し出せる能力が必要とされる。

そして、パフォーマンスの問題について考える時は、どうしてもファイルやハードウェアといった
物理層に踏み込まざるを得ないため、
本当の論理設計とは、論理と物理のトレードオフを理解して初めて可能になる。

感想

3章では正規化を学び、第5まであった正規法が実現すればするほど良いのかと思いきや・・
今度は正規化すればするほどパフォーマンスが悪くなるなんて🥺
読んでいて、いったいどうすれば良いんだ！という気持ちに思わずなってしまいました。

論理設計をする＝システムの品質が決まる
めちゃくちゃ重要な役割で、
それこそどんなデータがあるのか、業務ドメインも理解していないとできないことだと思います。
前回の章でも、業務で使用している200テーブルたちは
正規化されてるんだ・・と思いましたが、
この章を読んで、正規化➕パフォーマンスも考慮して非正規化も行なっているのだろうと考えました。
多分ベースは数理技研さんが作ったと思うのですが・・
いやあすごい。。

DBの設計ってめちゃくちゃ大変なんですね。
しかも、正規論理を熟知して、美しい論理モデルを考えられたとしても、
物理レベルは全くの無知・・じゃ意味がないことを改めて学びました。

次の第6章では、パフォーマンスについて、インデックスなどについて習得したいと思います。

関連

達人に学ぶDB設計徹底指南書第2版・読んだまとめpart1
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart2
達人に学ぶDB設計徹底指南書第2版・読んだまとめpart3