濁りあふれる川を制御せよ：3つのデータモデリングの歴史を追う

静かな夜が更けていく。
コンピュータの青白い光が部屋を照らす。
データは流れ、止まることを知らない。
その姿は、まるで川のようだ。

1. Inmonのスタースキーマ：データの星座

1990年代初頭、ビル・インモンはスタースキーマを提唱した。
それは、データウェアハウスの夜空に、新たな星座を描くようなものだった。

中心にファクトテーブルがあり、その周りにディメンションテーブルが星のように輝く。
その姿は、こんなふうだった。

スタースキーマの美しさは、その整然とした構造にあった。
分析のためのクエリは、簡潔で優雅だった。

SELECT 
    p.name AS product_name,
    c.name AS customer_name,
    s.name AS store_name,
    d.full_date,
    f.amount,
    f.quantity
FROM 
    FACT_SALES f
JOIN DIM_PRODUCT p ON f.product_id = p.product_id
JOIN DIM_CUSTOMER c ON f.customer_id = c.customer_id
JOIN DIM_STORE s ON f.store_id = s.store_id
JOIN DIM_DATE d ON f.date_id = d.date_id;

しかし、時は流れ、データの川は膨れ上がった。
スタースキーマは、その流れを制御しきれなくなっていった。

新たな属性を追加するたび、ディメンションテーブルを変更しなければならなかった。
それは、こんなふうだった。

ALTER TABLE DIM_PRODUCT ADD COLUMN color VARCHAR(50);
UPDATE DIM_PRODUCT SET color = '青' WHERE product_id = 1;
UPDATE DIM_PRODUCT SET color = '緑' WHERE product_id = 2;

履歴の管理も難しかった。
顧客の住所が変わるたび、新たな行を追加するか、既存の行を更新するか、決断を迫られた。

データの川は、次第に濁り始めていた。

2. Kimballの非正規化：データの流れを加速させる

1990年代後半、ラルフ・キンボールは、新たな風を吹き込んだ。
彼の非正規化アプローチは、データの流れを加速させた。

キンボールの手法は、ディメンションテーブルを減らし、データを平坦化した。
それは、こんなふうだった。

キンボールの手法は、データの川を一つの大きな流れにまとめた。それは、こんなふうだった。

キンボールの手法は、クエリをさらに簡素化した。
それは、こんなふうだった。

SELECT 
    product_name,
    customer_name,
    store_name,
    d.full_date,
    amount,
    quantity
FROM 
    SALES s
JOIN DIM_DATE d ON s.date_id = d.date_id;

新たな属性の追加も、より簡単になった。

ALTER TABLE SALES ADD COLUMN product_color VARCHAR(50);
UPDATE SALES SET product_color = '青' WHERE product_name = '青い瀬戸物の茶碗';
UPDATE SALES SET product_color = '緑' WHERE product_name = '竹製の茶筅';

しかし、キンボールの手法にも課題があった。
データの一貫性を保つのが難しくなったのだ。
同じ製品の情報が、複数の行に散らばっていた。

データの川は、確かに速く流れるようになった。
しかし、その流れの中で、データの純度は薄れていった。

3. データボルト：データの流れを制御する

2000年代初頭、ビル・インモンは再び立ち上がった。
彼は、データの川の新たな治水法を提案した。
それが、データボルトだった。

データボルトは、データの流れを三つの要素に分けた。
ハブ、リンク、サテライトである。
それは、こんなふうだった。

データボルトの美しさは、その柔軟性にあった。
新たな属性を追加するのも、履歴を管理するのも、容易だった。

例えば、製品の色を追加するのは、こんなふうだった。

ALTER TABLE SAT_PRODUCT ADD COLUMN color VARCHAR(50);
INSERT INTO SAT_PRODUCT VALUES
('SP003', 'P001', '青い瀬戸物の茶碗', '食器', 2000, '2023-05-03 10:00:00', 'PRODUCT_SYSTEM', '青');

顧客の住所が変わった場合も、新たな行を追加するだけだった。

INSERT INTO SAT_CUSTOMER VALUES
('SC003', 'C001', '川端 太郎', 'taro@example.com', '京都市右京区', '2023-05-04 09:00:00', 'CRM_SYSTEM');

しかし、データボルトにも課題はあった。
クエリが複雑になったのだ。
データの流れを再構築するには、多くのテーブルを結合する必要があった。

SELECT 
    p.name AS product_name,
    c.name AS customer_name,
    s.name AS store_name,
    l.sale_date,
    ss.amount,
    ss.quantity
FROM 
    LINK_SALE l
JOIN SAT_SALE ss ON l.link_id = ss.link_id
JOIN HUB_PRODUCT hp ON l.product_id = hp.product_id
JOIN SAT_PRODUCT p ON hp.product_id = p.product_id
JOIN HUB_CUSTOMER hc ON l.customer_id = hc.customer_id
JOIN SAT_CUSTOMER c ON hc.customer_id = c.customer_id
JOIN HUB_STORE hs ON l.store_id = hs.store_id
JOIN SAT_STORE s ON hs.store_id = s.store_id
WHERE 
    p.load_date = (SELECT MAX(load_date) FROM SAT_PRODUCT WHERE product_id = hp.product_id)
    AND c.load_date = (SELECT MAX(load_date) FROM SAT_CUSTOMER WHERE customer_id = hc.customer_id)
    AND s.load_date = (SELECT MAX(load_date) FROM SAT_STORE WHERE store_id = hs.store_id);

データボルトは、データの川を細分化し、その流れを制御した。
しかし、その代償として、データの再構築に時間がかかるようになった。

結び：データモデリングの未来

夜が明け、新たな朝が訪れる。
データの川は、今も流れ続けている。

スタースキーマ、キンボールの非正規化、そしてデータボルト。
それぞれのアプローチは、データの川を制御しようとした。しかし、完璧な解決策はなかった。

スタースキーマは整然としていたが、変化に弱かった。
キンボールの手法は柔軟だったが、一貫性を保つのが難しかった。
データボルトは履歴管理に優れていたが、クエリが複雑だった。

データモデリングの世界は、まるで茶道のようだ。
完璧な一碗を求めて、絶え間ない改良が続く。
しかし、その過程こそが、美しさなのかもしれない。

データの川は、これからも流れ続けるだろう。
そして私たちは、その流れを見つめ、理解しようと努力し続けるのだ。