【DB】データベース設計のアンチパターンを学んだので復習しておこう

おはようございます。タカヒデです。

エンジニア界隈では「アンチパターン」と呼ばれる「やってはいけない、真似してはいけないパターン」があるようです。

エンジニアになったみたいでかっこいいですよね。
後輩に「それアンチパターンだからやめときな」とか使ってみたいものです。

そんなアンチパターンがデータベース設計においても存在します。

本日はこの、「データベース設計におけるアンチパターン学んだので復習しておこう」という記事です。

なお、私が参考にさせていただいた書籍は「達人に学ぶDB設計徹底指南書」です。

分かりやすくて初学者の方にもおすすめですよ。
（とあるエンジニアは「エンジニア1,2年目の人が読むべき」とコメントしていました）

それではアンチパターンを見ていきましょう。

１：非スカラ値

1つ目のアンチパターンは「非スカラ値」です。

言いたいことは「第1正規形は最低限守れー」ってことです。

では第1正規形ってなんでしたっけ？

それは「１つのセルには１つの値だけを入れろー」というものです。

詳しくは↓の記事でも紹介していますが、ここでも軽く復習しておきましょう。

あわせて読みたい

【DB】第1正規形と第3正規形は覚えられるんだけど第2正規形だけ忘れるので整理してみた

具体例で見ていきます。

■NGな例

このテーブルでは、マリオ社員は「ピーチ奪還」と「トレーニング」の２つのプロジェクトを１つのセルに入っている状態のため第1正規形とは言えません。

これをアンチパターンと言っています。

ではこれを正規形に直すとこんな感じ。

■第1正規形

同じように、マリオ社員の行数を増やすことで「１つのセルには１つの値」が守れました。

これでアンチパターンを回避できていますね。

２：ダブルミーニング

２つ目のアンチパターンは「ダブルミーニング」です。

言い換えると「テーブルや列の意味を途中で変えるな」ということです。

こちらも具体例で見ていきましょう。

■NGな例

この「列」、2025年度は「年齢」2026年度は「勤続年数」を表しています。

つまり列の意味が「年齢」から「勤続年数」に変わっているのです。

これでは一つの列で2つの意味を持ってしまっています。

このテーブルを設計した方でなければこの変更は把握することができません。

■OKな例

仮に2025年度は「年齢」2026年度は「勤続年数」という条件があるのであれば、上記のように列を追加する必要があります。

これで列名もデータに合ったものを設定できるため、初めて見る方でもわかるデータになります。

「それは当たり前でしょ」って思う方もいるかもしれませんが、実際にそんなテーブルは存在するようです。

これもやらないように注意しましょう。

３：単一参照テーブル

3つ目のアンチパターンは「単一参照テーブル」です。

これは「あらゆるIDやコードを1つのテーブルにまとめてしまう設計」という感じです。

正規化を進めていくと、「コード：値」みたいなテーブルがたくさんできていきますよね。

テーブルが増えてしまうと煩雑なので1つのテーブルにまとめるとスッキリしそうじゃないですか？

それが「単一参照テーブル」です。

■単一参照テーブル

こんな感じのものです。
「会社」「部課」「趣味」のコードが同じ列に記載されています。

これでは、

• SQLで誤った値をしてもエラーに気づきにくい
• 正しい参照を保証してくれる外部キーが定義できない

といったデメリットがあるのです。

このような「単一参照テーブル」をやめましょうというのが今回のアンチパターンです。

４：テーブル分割

4つ目のアンチパターンは「テーブル分割」です。

これは「テーブルをレコード単位に分割する「水平分割」と、列単位に分割する「垂直分割」はするなー」というものです。

まずは水平分割から具体例で見ていきましょう。

■水平分割されていないもの

■水平分割されたもの

こんな感じで年度別でレコードを切ってしまうパターンですね。

これは主に「分割することの論理的な理由が無い」ことからやるべきではありません。

さらに年度別の変化を一つのテーブルで確認することができないことからアンチパターンとされています。

同じように垂直分割も見ていきましょう。

■垂直分割されていないもの

■垂直分割されたもの

今度は縦に列を切ってしまっています。

こちらも「分割することに論理的な意味を持たない」ことからアンチパターンとされています。

他のアンチパターンと比べると「絶対にNG」というほどではなさそうですね。

５：不適切なキー

5つ目のアンチパターンは「不適切なキー」です。

これはもう名前からも大体予想が出来そうですね。

ただ、ここではもう少し具体的に「主キーや外部キーには可変長文字列を使うな」と言っています。

これがアンチパターンである理由は大きく2点です。

1. 不変性を満たすことができない
2. 固定長文字列と混同してしまう

理由の1つ目に「不変性を満たすことができない」があります。

キーは本来「不変性」を備えていなければなりません。

しかし、キーが可変長文字列だと、不変性を満たすことができません。

続けて理由の2つ目に「固定長文字列と混同してしまう」があります。

これは「同じ文字列でも空白により同じ値にならない」ということです。

こんな形で同じ文字列を使っているにもかかわらず、別の値として認識されてしまうことがあります。

これらの理由から、「不適切なキー」がアンチパターンとされいるようです。

６：ダブルマスタ

6つ目のアンチパターンは「ダブルマスタ」です。

この「ダブルマスタ」は著者の方が名づけられた名称なので一般的ではないとのこと。

これは「同じ役割のテーブルを複数存在させるなー」というものです。

具体例で見てみます。

■ダブルマスタになっているテーブル

社員情報を正しく取得しようと思うと、2つのテーブルを結合しなければなりません。

これではパフォーマンスが低下してしまいます。

対処としては、もちろんテーブルを一つにしてあげる必要があります。

■ダブルマスタを解消したテーブル

これでテーブルの結合処理が不要になりアンチパターンも解消されます。

このようなダブルマスタは別のシステムと統合する際に発生することが多いようです。

少し手間かもしれませんが、きちんとデータを精査するようにしましょう。

７：ゾンビマートと多段マート

最後のアンチパターンは「ゾンビマートと多段マート」です。

ゾンビマートとは、「誰もアクセスしていないが、詳細が分からず、怖くて削除できないデータマート」を指します。

そして多段マートとは、「データマートから連結して次のデータマートを作成すること」です。

まずは、ここで出てきている「データマート」の理解を深めておきましょう。

「自分たちのために必要なデータだけを切り出したテーブル」ってそんな感じですね。

そんなデータマートが「手を付けられず消せない」のがゾンビマート。

「データマートのデータマートが生まれごちゃごちゃしている」のが多段マート。

こんなイメージでしょうか。

ゾンビマートのデメリットは

• 誰も削除できないため、無駄にストレージの容量を食ってしまう

というところにあります。

多段マートもデメリットとして、

• データマートが増えていく分、ストレージの容量を食ってしまう
• 連結されている分データソースが追いにくく、データの出元が分かりにくい

ということがあります。

これでは本当にこのデータを使って良いものなのか、判断ができなくなってしまいますよね。

「ゾンビマート」「多段マート」どちらもアンチパターンとして納得できるものでした。

まとめ

以上が「データベース設計におけるアンチパターン学んだので復習しておこう」の記事でした。

何となくアンチパターンのイメージができましたか？

説明が分かりづらい部分もあったかと思いますが、もっと分かりづらい表現や、改善ポイントあればぜひご指摘ください。

以上です。お疲れさまでした。

タカヒデ

ITを楽しく勉強中

X

通信会社の企画職で働く30代 非エンジニアでありながら半分趣味でITエンジニアリングやプログラミングを学習中 IT初心者が楽しいと思えるように発信することを目指しています ↓Xもやっているのでフォローしてね