はじめに

「データモデルは本当に必要か」の連載、第２回目です。データモデルを作らないでDB設計したらどのような結末を迎えるのかをみていきたいと思います。DB（データベース）という概念は、皆が使うデータを1カ所に集めて、共存させて使いましょうという考えで発祥し、DBMS（データベース管理システム）が登場してきたという経緯があります。

しかし、現実にはDBMS機能は使っているが、データベースとしての体をなしていないということは多々あります。データの重複無く、1カ所で保管するという大原則が守られていないDBが乱立していて、データ活用のために統合するという不思議な現象が起きています。

画面単位にDBを作成したら

画面ベースでユーザ要件を捉えて行くと、画面単位でのデータ設計となっていきます。画面あるいは機能単位で設計担当者が異なると、当然ながら担当の画面や機能を利用できるようにするのに必要なデータを備え、容易にデータ格納や取り出しが出来る構造のDBを作成してしまいます。

例えば、販売管理システムにおける見積入力と受注入力を考えてみます。見積入力では、商品については商品マスタが作成されていて参照して画面表示しますが、顧客については、あくまで見積顧客ということで登録し、見積金額等の見積データと併せて格納します。

一方、受注入力では、商品マスタについては見積入力と同じマスタを参照しますが、顧客については受注顧客として登録し、受注金額等の受注データと併せて格納します。見積で入力した顧客データが受注入力でも活かせるのではと思われますが、見積なしでの受注があり得るというビジネス前提では、見積顧客とは別に受注顧客を管理するのも致し方ありません。

このように、見積と受注で個別に設計を進めると、顧客情報では重複が発生します。また見積に基づく受注では、受注時に変化のない商品や顧客データを重複して持つことになってしまいます。即ち、見積データと受注データの間で同じデータを保有するという事象が発生してしまうことになります。

【図2-1.UI主導による開発】

データモデル主導によるアプリ開発

では、画面主導でない設計とはどうすれば良いのでしょうか。端的に言えば、業務で必要なデータおよびデータ間の関連をデータモデルとして捉えることにより、販売管理システムでデータの重複のないデータ構造となります。即ち、商品や顧客に関する情報はデータベース上1カ所で保管されようになります。

このようにして作成したデータ構造を持ったデータモデルを参照する見積や受注の画面を作成していきます。即ち、データモデルはそのまま実装すればテーブルとなりますので、見積入力や受注入力の設計とは必要なデータ項目を取りそろえた「ビュー」を作成することに他なりません。

【図2-2.データモデル主導による開発】

画面を先に決めてからDB設計を行うのでは無く、データモデルを作成してからUI（ユーザインタフェース）としての画面を設計していくという順番です。画面が無いとどんなデータ項目が必要なのかわからないではないかと思われるかも知れませんが、正式な画面では無くモックベースで必要なデータ項目を定義して行けば良いのです。重要なのは、画面を中心とした機能単位でDBの設計作業を進めるのではなく、システム全体を捉えてデータモデルを作成し、DBに落とし込んでいくことです。個々の画面、即ちUIを決める前に、画面間を跨がったデータモデルを先行して作成することであり、データ中心の設計とも言われています。データ中心の考え方は、古くからあるものですが、データの重要性が広く認知されるようになった昨今、再び注目されています。

ローコード、ノーコードツールもデータモデルが出来ていれば簡単にアプリケーションを生成してくれます。但し、画面・機能主導で作成したモデルでは、画面をテーブルに置き換えただけのモデルとなり、データが重複してくることになります。
 

同義語と異義語

名称は違っているが、同じモノを指しているのが異音同義語です。例えば、営業部門では出荷年月日、物流センターでは出庫年月日、配送を請け負う業者は配送年月日と別の名前で呼んでいますが、実態は同じ年月日を指しているというケースです。

もっと厄介なのは、呼び名は同じなのに異なったものを指している同音異義語です。例えば、「顧客」といった場合に営業担当者は接触中の見込顧客、見積を提示した顧客、そして既存の顧客を含めて捉えているとします。一方、営業事務担当者は、受注済みの顧客のみを対象としているといったケースです。B2B2C（Business to Business to Consumer）のビジネス形態では、最終消費者までを顧客に含めているか否かも、部署、業務によって異なる場合があります。

人はその時の文脈によって、頭の中で変換して「ああ、これはあの顧客を指しているんだな」と解釈しますが、システム化にあたってはできるだけ文脈によって意味が変わるような項目名を排除しておく必要があります。データモデリングでいうデータ項目名のネーミングです。理想的には、同じ名称の項目名は1カ所にしか現れないように定義しておくことになります。生成AIの精度を高めるためにも重要なことです。

個別の画面や機能を分析していただけでは、同義語や異義語は出てきません。スコープを広げてデータモデリングしていく中で初めてネーミング問題に遭遇することになります。

​​​​

【図2-3.同義語・異義語】

散在するマスタと異なったコード体系

商品マスタ、顧客マスタがシステムのあちこちに、複数存在していることは多くの企業で見られます。これらを統合してマスタを一元管理できないかということでMDM（Master Data Management）プロジェクトが動いています。

例えば、グローバルに工場を持っている企業で、同じ製品を製造しているにも拘わらず、品目コードが違っているということがあります。同じERPを導入していてもです。背景には、工場を早期に操業しなければならない、M&Aにより系列だった部品メーカーを統合したなどの様々なケースが考えられます。各工場でコード体系が異なる場合には、新たな統合コードに統一するか、お互いの工場間のコードを変換する仕組みが必要となります。お互いのコードが1対1に対応付くのであれば変換表で済むわけですが、1対多関係となると人手が介在しなければなりません。このような、マスタデータの統合・変換のためにはデータモデルを描いて何処に影響があるかを見定める必要があります。

【図2-4.マスタの異なったコード体系】

同じようなマスタが、あちこちに存在するケースは、システム化以前のExcelで業務を回しているケースにも多く見られます。部署内で共有されたマスタファイルを各担当者が自分専用のマスタファイルとして抱えこんでしまうことです。このように「自分マスタ」と呼ばれるものが横行するケースが多く見られます。即ち、同じマスタのコピーがあちこちに存在するといったことになります。業務システムにおいてもこれと同じことが起きていて、自システム用のマスタを抱え込むケースは多く見られます。その結果、あるマスタでの変更を伝搬したりして同期化するという余計な手間がかかってしまいます。