やあ。データの世界へようこそ。
今日は少し「古くて新しい」話、階層型データベース（DBMS）と、それが現代の主流であるリレーショナルデータベース（RDB）に変わる時に起きる「痛みを伴う革命」について話をしよう。
君がもし「データベースなんてテーブルを並べるだけでしょ？」と思っているなら、その固定観念は今日で捨てていい。歴史を知ることで、君は単なるプログラマーから、システムの本質を見抜くアーキテクトへ一歩近づけるはずだ。
—
1. 階層型DBMSとは何か？「家系図」を想像してほしい
階層型DBMSを理解するのに、小難しい理論は必要ない。「家系図」や「会社の組織図」を思い浮かべてみてくれ。
- 親がいて、その下に子供がいる。
- 子供は一人だけど、親は複数選べない。
これだけだ。例えば「会社」というデータの下に「部署」があり、その下に「社員」がいる。この上下関係がガチガチに固定されているのが階層型だ。
ここがポイント：
データを取り出すとき、階層型は「親から順に辿る（ポインタを追う）」という動きをする。これが信じられないほど速い。あらかじめ道が決まっているから、迷子にならないんだ。かつてのメインフレーム全盛時代、このスピードはまさに神業だった。
2. なぜ「非正規化」がデフォルトだったのか？
階層型DBMSの時代、私たちはデータを「あえてバラバラにしない」ことで性能を稼いでいた。
例えば「顧客」データの中に「注文履歴」を直接埋め込む。さらにその中に「商品情報」を突っ込む。これを「非正規化（冗長化）」と呼ぶんだ。本来なら別々に管理すべきデータを、親子関係の中に「同居」させることで、検索のたびに別の場所を探しに行く手間を省いていたんだよ。
日常の例えで言えば：
君が旅に出る時、荷物を「服」「靴」「洗面用具」とバラバラにパッキングする（正規化）のではなく、「着るもの一式を一つの大きな袋にまとめておく」ようなものだ。探す時間は短いけれど、袋の中身が重複したり、整理が大変だったりするよね。
3. RDBへの移行という名の「地獄の整理整頓」
さて、ここからが本題だ。古い階層型システムを、現代のRDB（テーブルを関連付ける方式）へ移行するとしよう。ここで多くのエンジニアが絶望する。
① パフォーマンスの「裏切り」
階層型では「親を辿れば一瞬で全部見つかった」データが、RDBではバラバラに切り刻まれる。
- 「顧客テーブル」からIDを引き、
- 「注文テーブル」へ飛び、
- 「商品テーブル」を結合する……。
これを「JOIN地獄」と呼ぶ。コンピュータは「あちこちの棚から荷物を集めてくる」という作業に追われ、元の階層型よりも遅く感じることがあるんだ。
② ロジックの「再構築」
階層型ではデータ構造そのものが「物語（ビジネスルール）」だった。
「この部署に属しているから、この給与計算ができる」というルールが、物理的な構造に埋め込まれていたんだ。RDBへ移行すると、その「構造の物語」を、プログラムのコード（SQLやアプリケーションのロジック）でわざわざ書き直さなければならない。
—
4. 先輩からのアドバイス：どう向き合うべきか
「じゃあ、階層型はダメな子なの？」と聞かれたら、僕は全力で否定する。階層型は「特定の目的」に対しては、今でも最強のスピードを誇る構造だ。ただ、柔軟性がなかっただけなんだ。
移行の際に君が直面する「非正規化問題」への処方箋はこれだ。
1. 「正しさ」と「速さ」のバランスを見極める: すべてを美しく正規化しようとせず、頻繁に参照されるデータは、あえて「非正規化（冗長化）」してテーブルに持たせる勇気を持つこと。
2. インデックスという武器を信じる: RDBの「JOIN」を恐れないでくれ。適切にインデックス（目次）を貼れば、現代のハードウェアは君が想像するより遥かに賢い。
最後に
階層型からRDBへの移行は、単なる技術の乗り換えじゃない。「データの持ち方の哲学を、構造から関係性に変える」という、エンジニアとしての思考の転換なんだ。
この壁を乗り越えた時、君はデータの「物理的な配置」と「論理的な関係」を自在に操れるようになる。そうなれば、もう怖いものはない。
さあ、まずは今のシステムの「親と子」の関係を紙に書いて整理してみよう。それが、伝説のアーキテクトへの第一歩だ。応援しているよ。
コメント