はじめに

生成AIを活用するためには、現状のデータの品質を高めなければならないとよく言われます。そこで、データ品質を高めるためには、定期的にデータをクレンジングすることも重要ですが、一番の解決策は誤ったデータが混入しないようにしておくことです。

システムの改変時にいくらデータをクレンジングしても、運用後暫くすると、重複データが発生したり、誤ったデータが混入したり、必要なデータが抜け落ちたりしてきます。データモデルでデータの構造、型や長さ、データ間の関連を規定することにより、避けることができます。データモデルでデータの整合性を保ったデータベースを構築することにより誤ったデータの混入を防げるということです。

ちょっと難しい言葉では、メタレベルでのデータ品質向上施策といえます。

事実は1カ所に（one fact in one place）

第２回でもお話しましたが、2カ所以上で重複してデータを持たないことが不正なデータの混入を防ぐ第一歩です。よく言われる正規化しましょうということです。受注データはどの顧客からどんな商品の注文があったかを現わしていますが、顧客名や顧客住所、商品名や商品単価は各々顧客マスタや商品マスタを参照すれば、わかるので受注エンティティに参照結果を保持すると、データの重複保持となってしまいます。即ち、同じ顧客コードの顧客名が顧客と受注エンティティで違った値となり得るということです。

但し、受注上には注文を受けた時点の顧客や商品マスタの状態を記録しておくということであれば違ってきます。顧客の住所や商品単価が変わった場合に、変更前の状態で証跡として必要というケースです。そうであれば、受注時顧客名、受注時商品単価のように、名前を変えて現在のマスタの値とは別だということをわかるようにすることをお薦めします。
 

【図4-1.データ重複保持】

制約で誤データの混入を防ぐ

誤ったデータが混入しないように、データベース自身で制約を設定することが出来ます。一意制約とは、DB内に格納されるデータは、主キー（PK)として定められた項目で一意になっていなければならないという制約です。データモデルでは、エンティティの定義に際しては、必ず主キーを設定するというルールがあります。実務の世界では、実装されているテーブルに主キーが設定されていなく、データが重複していてデータクレンジングで「重複したデータのどちらを正として単一データに修正しますか」ということが多々あります。

一意制約を定めるほかに、モデル作成の効果としては、エンティティ間の関連付けによる参照制約を定義することがあります。参照制約は、必ずしもDBMSの参照制約機能を定義しましょうということではありません（DBMSの参照制約を張ってしまうとテストが進まないということになりかねませんので注意が必要です）。あくまでデータ間の関連として制約を設けて、何らかの方法でその制約に合致しないデータは登録できない仕組みを作っておくことです。

例えば社員は必ずある組織に所属するという関係があった場合に、組織と社員エンティティは、組織コードで関連付けが行われます。そうして、社員を登録しようとした場合、組織マスタに登録されていない組織コードの社員データは登録できないという関係にしておくことです。新たな組織コードが新設される場合は、必ず組織マスタに新組織を登録しなければ、社員登録はできないという運用上のルールが発生します。

​​​​

【図4-2.制約】

Null値を作らない

システムの改変に伴って、現行のデータをきれいにして新システムに移行したいというデータ整備の業務において、現行のデータベースを見てみると値が入っていない、いわゆるNull状態の項目が多くあるのを目にします。

条件（ある区分）によって値が入ったり、入らなかったりという構造が、データ品質劣化を招く一番の要因となります。

例えば、見積、受注、出荷、請求に関する全てのデータを含んだ取引というエンティティを作成したとします。取引状態区分が、見積、受注、・・といった状態を表わします。即ち、取引状態区分が「見積」の時には、顧客コード、見積年月日、見積金額以外の項目はNull値となります。

ある取引番号のレコード内にNull値を含んだ属性が含まれると、本来設定されるべきところが未だ設定されていないのか否かの判断が付きません。取引状態区分の値によって、どの項目が設定されるという仕様を、一々確認しなければ正しくデータが設定されているのかが分からないということになってしまいます。

図の左側の取引というデータ構造でNull値を回避するべく、見積もり時には受注金額を０円に設定しておこうとしたとします。そうすると、営業政策上「０円受注」が可能だった場合に受注金額の０円が受注前の０円状態なのか、受注金額の０円なのか、AIが判断できるでしょうか。

図の右側のモデルのように、見積、受注、・・でエンティティを分けると、取引状態が見積時には見積エンティティが作成され、全ての項目値が埋まります。そして受注時になると受注エンティティが作成され、全ての項目値が埋まることになり、Null値のデータ項目は発生しません。このように、できるだけNull値を許さないデータ構造にすることがデータ品質を維持する上で有効となります。

【図4-3.Null値を発生させない】

掛け持ちデータ

一つのデータ項目で複数の意味・用途を持つデータを「掛け持ちデータ」あるいは「相乗りデータ」と筆者は呼んでいます。このようなデータ構造も汚れたデータの温床となります。

例えば、顧客マスタは設計当初は法人顧客のみだったのが、個人顧客も追加する必要に迫られた場合です。会社名に個人名を、会社種別に性別を、設立年月日に誕生日といったように、個人の顧客情報が法人をベースとした顧客マスタ上に相乗りした形となります。ビジネスの変化によってもDB構造をできるだけ変えたくないという苦肉の策です。このようなケースは、多くの現場で目にしてきました。データ項目名は、データの実態を表わす表札でありデータカタログとして管理し、データ活用に役立てようという方向性からも避けたいところです 。

生成AIの利用に際しては、このデータは何を記録したものであるという定義を明確にしておく必要があります。データが何を表しているかをメタデータと呼んでいます。この例で、資本金が1億円以上の企業を選択しようとした場合、個人年収が１億円以上の人も含まれてしまうのことになります。AIはメタデータである属性名からデータ値を見ているので、法人データしか登録されていないと判断してしまうこととなります。

この問題に対処するためには、一旦作成したデータモデルを維持していくためのデータ統制が必要となってきます。
 

【図4-4.掛け持ちデータ】