イチから全部作ってみよう（29）3つのノート整理法からたどるRDBMSの基礎知識：山浦恒央の“くみこみ”な話（198）（2/3 ページ）

ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第29回は、お題「店長の頭の中を設計しよう」の解答例となる3つのノート整理法を基に、リレーショナルデータベース（RDBMS）の基礎知識について説明する。

LINE

Hatena

　ツリー構造スタイルとは、Windowsのフォルダ管理のように、情報を木構造のカテゴリーごとに分けて管理するスタイルです（図1）。図書館の蔵書を管理する方式が、大分類、中分類、小分類のこれですね。

図1　ツリー構造のイメージ［クリックで拡大］

　例えば、図1に示すように、ツリー構造のようにページ分けを行い、更新時に書き込みます。

　この管理方法は、Excelで「商品」のシート、「顧客」のシートのように、分割して管理するイメージに近いでしょう（図2）。

図2　Excelを使ったツリー構造スタイルのイメージ

　日記帳スタイルでは、ノートの1行に対して、商品、顧客、金額のデータが混ぜこぜになっていました。ツリー構造では、「住所を知りたいので顧客データ」「今日の売り上げだから売り上げデータ」というように、探したい情報がはっきり決まります。日記帳スタイルに比べ、大きく進化しています。

　ツリー構造スタイルの問題点は、「重複」するデータの管理です。

　お客さまが商品を購入した際、住所を確認するために、「顧客データ」のページを開き、配送のために注文データのページにも同じ住所を書き込む必要があります（表1）。

表1　重複データのイメージ［クリックで拡大］

　表1の通り、注文が入るたびに顧客データを開き、注文データに住所を転記する必要があります。これでは、時間がかかり、書き間違えるミスにつながる「もったいない」状態ですね。

　なお、表1には書いていませんが、現実の運用では、実際の注文データには、「誰が買ったか（注文した人）」と「どこに送るか（配送先）」の2つの情報が必要です。よって、この二つの情報を混ぜて管理しようとすると、さらに複雑怪奇になるでしょう。

　常連のお客が住所を変更する場合は、顧客データの変更と同時に、過去の注文データも修正する必要があります（表2）。

表2　住所変更が別のカテゴリーに波及する例［クリックで拡大］

　表2の通り、顧客データの住所を変更しても、過去の注文データは古いままです。もし、修正しないと、過去の履歴を見て、古い住所に送るかもしれませんね。かといって、過去の記録を全て修正することは現実的ではありません。

　このように、ある1箇所の変更が、ノート全体の整合性を破壊する可能性があります。これが、情報をバラバラに詰め込んだツリー構造の最大のデメリットです。