「達人に学ぶDB設計徹底指南書」を読んでDB設計の復習ができた

以下の内容は、著者:ミックさんの「達人に学ぶDB設計徹底指南書」の内容を一部抜粋して記載しております。

読んだ目的

私の働いている会社は、某WEB広告の代理店でデータエンジニアとして働いております。(正式には、データエンジニアみたいな細かく設計して、構築して、運用しているってわけではなくて、SaaSのサービスを社内に導入して、それを使ってレポートを効率的に作っているっていうだけなんですが。)

ただ、現状まだ社内にデータ分析基盤があるわけではなく、導入したSaaSのサービスをつかってまずはデータを可視化し、「データをきちんと使いましょうね」「BIツールの良さはこういうところです」というのを社内に浸透させるという段階です。

ある程度社内にBIツールをきちんと使いましょうというのは浸透できてきたので、次のステップとして、0からデータ基盤を構築していくという流れになっています。

とはいえ、私は知識0のような状態なので、まずは基礎をしっかり固めないとと思い「達人に学ぶDB設計徹底指南書」を手にとって読んでみた。というところです。

この本を一言でいうと

「DB設計・構築において、ベストプラクティス、バッドノウハウの考え方が理解できる」というところでしょうか。

ターゲットとしては、これからデータベースエンジニアを目指されている方アプリケーションエンジニアを目指されている方等の初級者向けかと思われます。

最近当たり前の技術となってきたクラウドやプログラミング言語のPython,Javascript等の技術的なことというより、データベース設計における考え方というイメージです。

これからデータ基盤を構築していこうという方には、非常にためになる本かと思います!

ぜひ手にとっていただけると嬉しいです。

以下になるほど!と感じた箇所を章ごとに一部抜粋してまとめてみました

ご参考までに。

第1章 データベースを制する者はシステムを制す

★データ設計がシステムの品質を大きく左右する

第1章では、世の中のデータベースと言われるDBMSの種類や設計の大事さ、システム開発のフローなど、「設計の大事さ」が主に記載されております。

すでにエンジニアとして働いている方は設計の大事さは、十二分に理解されつつ、その大変さと面倒さを日々実感しておられるかと思います。

データベースも同じで、最初の設計を間違えてしまうとあとから変えたいとなった場合、非常にコストが大きくなってしまい、心の折れる作業になってしまいますよね。その大事さを著者は大前提として記載しています。

「プログラミングってなんか黒い画面に英語がばらーとあってかっこいい」からはいっちゃって実際の業務はほとんど設計で地味やなってがっかりされる方、意外と多いのではないでしょうか….。

  → 

  →  

でも、、、

私も「黒い画面かっこいい!」から入ってきた人です。システムのこと自体が好きであれば続けられるので、きっかけなんて何でもいいのではないでしょうか(笑)

第2章 論理設計と物理設計

★DB設計とは、
・何をどのようなフォーマットで保存する必要があり
・どんなツールが最適か
・どのような構成に整備するか
考えること

第2章から本格的にDB設計のお話がスタートします。

上記★にも記載のとおり、DB設計とは、何をどのようなフォーマットで保存する必要があり、どんなツールが最適か、どのような構成に整備するか考えることです。

その中で設計は、以下のように大きく2つに分割することができます。

論理設計→「何をどのようなフォーマットで保存する必要があるか」

物理設計→「どんなツールが最適か、どのような構成に整備するか」

具体的な詳細は以降の章で詳しく説明されています。どちらがより大事というのはなく、どちらも大事というのが正です。システムは本当に覚える事が多いですよね。

第3章 論理設計と正規化

★テーブルの分割の意味は「冗長性」と「非一貫性」をなくすため!

テーブルの正規化についてメインに記載されています。

正規化というのは、簡単にいうと「テーブルを分割して管理・運用しやすくしよう」ということです。

例えば以下のような形です。

県ID県名市区町村ID市区町村名人口
A001北海道23札幌市300,000
A002千葉県24市川市500,000
表現したいVIEW

↑下記2つのテーブルを県IDをキーにSQLで結合して表現します。

県ID県名
A001北海道
A002千葉県
都道府県

県ID市区町村ID市区町村名人口
A00123札幌市300,000
A00224市川市500,000
市区町村

詳しく説明する前に、「表」と「テーブル」の違いについて。

カラム1カラム2カラム3
田中太郎30000田中商店
りんご10個東京

社員ID社員名担当店舗
A01田中太郎田中商店
B01佐藤翔佐藤商店
テーブル

表とテーブルの違いは「同一のカラムに共通点をもった情報がはいっているかどうか」です。表はどんな表現も可能ですが、テーブルは「共通点を持ったレコードの集合体」でないといけません。

DBMSで扱うのは表ではなく、テーブルということを大前提に考えておくのが基本です。

話を戻しますと、正規化はデータ基盤において必須なものと言えます。★の部分で記載していますが、正規化の目的は「冗長性」「非一貫性」をなくすために行います。

冗長性・・・データ領域の無駄使いや更新処理の多重化

非一貫性・・・データの不整合やデータの更新ができない

正規化していないと、データを正常に保つことがより難しくなるので注意が必要です。

正規化を行う(この情報はこのテーブルに分割して管理すること)で、データを管理・運用しやすくしましょう!というのがデータ基盤の基本です。

※正規化のレベルは1~5までありますが、ここでは割愛いたします。

 

第4章 ER図 -複数テーブルの関係を表現する-

★大量のテーブルを管理・運用するのは大変。そのためのER図

ER図とは、テーブルの関係をひと目で把握できるようにした図のことです。

  • IE表記法
  • IDEF1X

の2種類があり、IE表記法のほうがシンプルな構成になっています。

IE表記法
IDEF1X

第5章 論理設計とパフォーマンス -正規化の欠点と非正規化-

★正規化の欠点は、SQLのパフォーマンスの低下

正規化をたくさん行い、テーブルを分割するということは、SQLで結合する回数が増えるということに繋がります。

SQLで結合が多くなってしまうとたくさんのテーブルデータを読みに行く必要があり、SQLのパフォーマンスが落ちてしまうといったことが考えられるわけです。

ただ、著者は、「正規化は必須」と述べております。私も同意見です。

データは正確なことが命のようなものです。第3章でも述べたようにデータの整合性が保てなくなった途端破綻してしまいます。

なので、SQLのパフォーマンスは考慮しつつ、正規化を行うというのがベストですね。難しいですが。

第6章 データベースとパフォーマンス

データベースのパフォーマンスを決めるインデックス、統計情報のことについて記載されています。

大変重要な点ですが、簡潔にまとめるのが難しいので、別途記事にしたいと思います。

なので、ここでは割愛いたします。

第7章 論理設計のバッドノウハウ

★「これはさすがにやらない」というテーブル設計は世の中に意外と多く存在している

テーブル設計におけるバッドノウハウ(やってはいけない考え方)をご紹介しています。

特に以下3点はさすがにやらないなーと思ってますが、意外とやってしまっている会社も多いとか。

1. 非スカラ値・・・これはテーブルではなく、表ですね

ID
A1田中悟
紀見
A2佐藤貴史ゆりか
かもめ

2. ダブルミーニング・・・一つのカラムデータの意味が途中で変わっている

年度学生名身長体重と年齢
2001田中太郎15450
2001佐藤正14949
2002田中太郎15614
2002佐藤正15515

3. 単一参照テーブル・・・同じ構造のマスタテーブルを一つにまとめてしまう

コードタイプコード値コード内容
comp_1CA001A広告会社
comp_2CA002B代理店
comp_3CA003C商店
pre_1P01北海道
pre_2P02青森
pre_3P03秋田
city_1c01市川市
city_2c02大阪市

第8章 論理設計とグレーノウハウ

★グレーノウハウは、有効に作用するときもあれば、大きな問題をおこすこともある。

グレーノウハウとは、バットノウハウほど絶対にしてはならないというレベルではないものの、使用するときはよく考えた上で使用しなければならないものを指します。

例としては、代理キー、アドホック設計、多段ビューがあります。

1. 代理キー・・・テーブルに一意なキー(主キー)がないときや主キーに限界値を迎えてしまったときなど、代理としてキーをテーブルに作成する方法

テーブルには意味のないキーを含めないというのが鉄則なので、基本は代理キーではなく、自然キー(タイムスタンプや年度など期日をカラムに追加し、一意にさせる)やオートナンバリング(空のカラムへのIDの自動付与)で対応するようにしましょう。

市町村コード市町村名人口(人)
A001A市300,000
A998X市400,000
A999Y市800,000

市町村管理コード市町村コード市町村名人口(人)
0A001A市300,000
998A998X市400,000
999A999Y市800,000
1000A001Z市900,000

2. アドホック集計・・・例えば以下のように都道府県テーブルから地方別に集計したいといったときに識別できるキーがテーブルに存在しない場合におこる

SQLのCASE WHENで仮想的にカラムを作成し、抽出する方法がベスト

県コード県名人口
01北海道550,000
02青森130,000
03秋田220,000

↓地方別に取得したい

SELECT 
CASE 
WHEN 県コード IN ('01') THEN '01'
WHEN 県コード IN ('02', '03') THEN '02'
ELSE NULL END AS 地方コード, 
SUM(人口)

FROM 都道府県

GROUP BY 
CASE 
WHEN 県コード IN ('01') THEN '01'
WHEN 県コード IN ('02', '03') THEN '02'
ELSE NULL END;

SQLで仮想的に「地方コード」を作成することで、青森県、秋田県の地方である東北地方の人口の合計値を抽出することができるようになりました。

3. 多段ビュー・・・ビュー同士を参照してしまい、SQLのパフォーマンスを著しく落としてしまうこと

ビューへのアクセスは、原則1段で終わらせることを心がける

VIEW3を見に行ったときにTABLE1,2まで深ぼって見に行くことになる

まとめ

以上、簡単にまとめてみました。

基礎という点で、一通り復習ができた気がします。基礎って何事においても大事だな〜と最近よく感じます。

「ビジネス課題を解決するためにデータを使って、データドリブンな提案ができるような環境にしたい」という目的があったとして、

→そのために「データ分析」ができるようになる

→そのためにデータを使える状態にする必要がある

→そのためにデータ基盤を構築する必要がある

→そのためにルールを設計し、整備する必要がある

となにか大きなことを成し遂げるためには、基盤が構築できていることが前提です。

世間的には最新技術を使って革新的なことを成し遂げることにスポットライトがあたっていますが、その裏には地道な努力によって基盤を支えてくれている縁の下の力持ちがいることを忘れてはいけないなと。

そういう方達が「すごい!」「こんな大変なことをやってくれているのか、ありがとう!」とたくさんの方から感謝されるような世の中にしていきたいですね。

私もそんなことが言われるような人間になれるようにがんばります!