楽々ERDレッスン

https://gyazo.com/f0f292a1de6f828c60183e8d83f5c88c

#読書

レッスン自体は3部を中心にしているが、全体をとおして読みやすく、わかりやすい書籍だった

なんだか自分もできそうだとページをめくりたくなるのはいい書籍だと思う

第1部の解説はkawasimaさんのイミュータブルデータモデルの記事に近しいものを感じる

事実を更新しない解法パターン#6309b9969929f00000671c0a

設計の基本手順は

ID導入

データモデリングの世界において、IDという恣意的な属性を追加するということは好ましくないとされています。しかしながら、その教義に忠実となるあまり実務において不自由になっているきらいがあります

業務視点からの正規化

業務の視点からの正規化は、値も見るということです。データの格納される器だけを見て考えるのではなく、そこに格納される値の重複も排除するということ

データベースの設計の要点となるのは「One Fact in One Place」という、1つの事実は1つの場所にのみ存在するということ

正規化というと1つの事実を2つ以上の場所に置くのを排除するということに目が向きすぎるあたまり、分けて保持すべきものまで一緒にしてしまい窮屈なデータ構造にしてしまうとケースに良く出会います

あまりにも短絡的になると事実、これはイベントといってもいいけど、付帯する情報をすべてイベント系エンティティに詰め込みがちではある

コード問題はよく出会いがち。本書でも多く触れている

コードは「あだ名」です。呼びやすい・親しみやすいものであれば、それでよいのです。ですから、自由に設定すればよいのです。

ただし従来型のコード体系をそのまま主キーにしてはいけない。重要な識別子としアイデンティティ(アイデンティファイア)を用意する

アイデンティファイア

インスタンスを一意に特定する座標の役割を果たす

エンティティ内におけるインスタンスのライフサイクルを表現する

DLC

レコード削除文脈でに対して「OLTP（オンライントランザクション処理）とDSS（意思決定支援）を混在させる」とあったがよくわからなかった

https://gyazo.com/17a01f938df908f3247b718b4e4371c8

4.2 物理設計とアプリケーションの種類（OLTPとDSS）｜人材育成・研修のエディフィストラーニング

データライフサイクルというものを考えた場合に、アイデンティファイアも厳密な意味では重なることはありえないということです。結論からいえば、虫食いの再利用は避けるべきです。そして通常であれば（エンティティごとに連番を振っている限りにおいて）、使い切ってしまうという問題はない

重複の削除。正規化とはつまり…

いかに無理なくムラなく無駄なくするかというふうに考えるとよい

バリデーションとデリベーション

妥当性検証（バリデーション）ルール

GUI であれば選択リストによる入力支援のためのマスタ項目的に扱われたりもしますが、あくまでも「関係」を管理していることになります

例えば都道府県から市町村の絞り込みなどはエンティティ間の関係を示している

リレーションシップ

レコードを全部箱から出してばら撒いてしまえば、2つのレコードの間には赤い糸が結ばれています。この赤い糸の一本ずつを管理するための箱が交差エンティティになっているのです。糸を結んだりほどいたりするという「事実」を記録しておくのです

イベント系エンティティの見出し方

実は意外とイベント系のエンティティは少ないことに気が付きます。見分け方は、動詞で言えるものがイベント系ということになります。タイムスタンプを打てるものがイベント系ということになります。「いつ（When）」が属性として設定できるもの

組織体の入力系業務、出力系業務を見ていくとあたりがついていく

設計手順をまとめると

いきなり全体像を見ようとすると手がつけられなくなる

まずはイベント系を中心に考えていくこと

リソース系は分類という概念を意識すること

最初から性能を出すことを考えすぎない

正規化

よく「画面のユーザインターフェイスから作るべきではない」と言われますが、個人的には、まず基本的に必要とされるアウトプットを並べるところから始めるのが、手っ取り早いと考えています。

ビジネスプロセスというのが、ユーザインターフェイスを境にしてコンピュータ側のプロセスとヒューマンプロセスが分離しているから

つまり画面に出力されないということはビジネスに直結するわけではないから

プライマリーキーとアイデンティファイア、物理設計

データそのものは非常に静的なものに過ぎません。それを、動的なプロセスがその時々指差して読み出したり、書き換えたりとということを繰り返して、ビジネスプロセスが流れていきます。その時々で呼びやすい、名指ししやすいキーを設定してやればよいのです。そういった形でキーを見出して、それをインデックスとして実装することが、実は物理設計なのです。

レッスン

同じテーブルでJOINして当月検針指示数・前月検針指示数の差から利用量を出すとか、ふつうにSQLやデータベースの知識が不足していて思いついてなかった

導出について

導出項目の排除というのは、データベース設計における正規化の基本のように言われています。導出項目を考えることで、保持するデータ項目がシンプルになります。そうすると、それを扱うソフトウェアも当然シンプルになりますし、保持するデータ量も小さくなります。昔と違って今はハードウェアの性能が非常に充実しています。積極的に導出項目の排除を意識してみてください。

レッスン6の深掘り出て出てきた多段階層やレベルを揃えるために出てきた手法は

俗に言う「マスタ管理」の典型例になります。複数のリソース系の多：多の関連を整理したいり階層構造を管理したりするのは、少し規模の大きなシステムを扱うときには必須と言っても過言ではありません。今回のような図を見たときにすぐにピンと来るようになれば、データベース設計で迷うことが大幅に減少します。