※当サイトの記事には、広告・プロモーションが含まれます。

イミュータブルデータモデルでのマスタ管理の扱いが難しい気がするが...

gigazine.net

従来のコンピューターで使われている暗号化の技術は、一般的なコンピューターではほぼ解読が不可能とされてきました。しかし、古典コンピューターとは文字通り桁違いの計算能力を持つ量子コンピューターが登場すれば、暗号化技術の安全性が崩れるのではないかといわれています。

WindowsやLinuxに実装された「量子コンピューターでも解読が難しい暗号技術」とは? - GIGAZINE

Microsoftが将来の量子コンピュータによるサイバー攻撃に備えるため、暗号ライブラリ「SymCrypt」および「SymCrypt-OpenSSL」にポスト量子暗号(PQC)技術を導入しました。このアップデートはWindows 11 Canaryビルド27852以降でテストが開始されており、Linux向けにも提供されています。

WindowsやLinuxに実装された「量子コンピューターでも解読が難しい暗号技術」とは? - GIGAZINE

PQCアルゴリズムは、現在使われている古典コンピューターだけでなく、将来登場するであろう量子コンピューターを使っても解くことが非常に困難とされる数学的問題に基づいて設計されています。これにより、量子コンピュータによる解読の試みに対抗することを目指しています。

WindowsやLinuxに実装された「量子コンピューターでも解読が難しい暗号技術」とは? - GIGAZINE

⇧ 目指しています、とあるが、「PQCアルゴリズム」の要件(機能・非機能)が担保されているかについて検証はされていないんだろうか?

どこまで対応できているのかをハッキリさせてくれないと非常に困るのだが...

まぁ、私用のPCは、「Windows 11」へのアップグレードの要件を満たせていないので、どうしようもないのだが...

そもそも、

gigazine.net

Microsoftが開発するOS「Windows」は、1985年に誕生したWindows 1.0からスタートして2012年にWindows 8が登場するまでたくさんのバージョン改訂を行い、それに伴ってOSとしての機能も大きく変化させてきました。

「Windows 10がWindowsの最後のバージョンになる」とMicrosoftが明言 - GIGAZINE

そんなWindowsシリーズの最新バージョンとなるのが「Windows 10」ですが、Microsoftのジェリー・ニクソン氏が「Windows 10はWindowsの最後のバージョンとなる」と発言して話題になっています。

「Windows 10がWindowsの最後のバージョンになる」とMicrosoftが明言 - GIGAZINE

Microsoftで開発部門に属するジェリー・ニクソン氏は、アメリカ・シカゴで開催されたMicrosoft Igniteというイベントの中で、Windows 10がデスクトップソフトウェアの「最後のバージョンになる」と発言しています。

「Windows 10がWindowsの最後のバージョンになる」とMicrosoftが明言 - GIGAZINE

さらに、Microsoftも「Windowsは新しいイノベーションとアップデートを継続して提供していく」と声明を出しており、今後は独立した新しいバージョンを提供していくのではなく、既にリリースされているWindowsを数ヶ月ごとあるいは1年ごとに「大幅アップデート」していくことになるとコメント。

「Windows 10がWindowsの最後のバージョンになる」とMicrosoftが明言 - GIGAZINE

⇧ 2015年頃に「Windows 10」が最後のバージョンになると謳っていたのに、「Windows 11」にバージョンアップグレードしますを強制するあたり、「消費者」を馬鹿にしてるとしか思えない対応してくる「Microsoft」の傲慢さは許せませんな。

マスターデータとは

英語版のWikipediaによると、

Master data represents "data about the business entities that provide context for business transactions".

https://en.wikipedia.org/wiki/Master_data

The most commonly found categories of master data are parties (individuals and organisations, and their roles, such as customers, suppliers, employees), products, financial structures (such as ledgers and cost centres) and locational concepts.

https://en.wikipedia.org/wiki/Master_data

Master data should be distinguished from reference data. While both provide context for business transactions, reference data is concerned with classification and categorisation, while master data is concerned with business entities.

https://en.wikipedia.org/wiki/Master_data

Master data is, by its nature, almost always non-transactional in nature. There exist edge cases where an organization may need to treat certain transactional processes and operations as "master data". This arises, for example, where information about master data entities, such as customers or products, is only contained within transactional data such as orders and receipts and is not housed separately.

https://en.wikipedia.org/wiki/Master_data

⇧「ビジネス」の領域の「情報」を定義したものだとは思われるのだが、ファジーな部分が多過ぎて、定義や分類がハッキリしない...

マスターデータ管理(MDM:Master Data Management)とは

「マスターデータ(Master Data)」の定義がハッキリしないのだが、

Master data management (MDM) is a discipline in which business and information technology collaborate to ensure the uniformity, accuracy, stewardship, semantic consistency, and accountability of the enterprise's official shared master data assets.

https://en.wikipedia.org/wiki/Master_data_management

概要

マスターデータとは、一般的に企業が社内や業務に構築する際の、データベースであり、共通となる基本的な情報で代表的なものには「商品」「顧客」「単価」「社員」「取引先」など多岐にわたる。マスターデータ管理とはその情報管理する手法である。

MDM - Wikipedia

背景と意義

通常マスターデータは個々の情報管理アプリケーション内で定義されるが、マスターデータが適切管理されていない場合や、複数の情報管理システムで同じマスターデータを使用する場合には、マスターデータ間の整合性が保たれない、または重複が存在するという事態が発生しうる。マスターデータの重複不整合は、そのマスターデータと関連するデータが検索・同定できなくなる、といった不都合を生むため、マスターデータ自体を管理する必要からMDMという概念が生まれている。

MDM - Wikipedia

MDM やマスターデータの広義な概念としては、コンピュータで管理されるデータだけとは限らない。個人のノートや手帳に、手書きで書いた顧客情報でもマスターデータであり、MDM の対象である。そういった意味では、保存方法や規模こそ違えど、MDM の考え方は昔から存在していたと言える。

MDM - Wikipedia

⇧ とあるように、「マスターデータ(Master Data)」の定義がハッキリしないことから、一元的な管理が困難という課題を解決するためのアプローチとして「マスターデータ管理(MDM:Master Data Management)」という手法が登場したらしいのだが、未だに「一元管理」を実現するには至っていないように思われる。

イミュータブルデータモデルでのマスタ管理の扱いが難しい気がするが...

で、

ts0818.hatenablog.com

⇧ 前回の時と同じく、「JJUG CCC 2025 Spring(Japan Java User Group Cross Community Conference 2025 Spring)」の話になるのですが、

『シンプルは作れる! - 実験からも見えてきたイミュータブルデータモデルの効果』

のセッションで、「データモデリング」に関連する話ですと。

登壇者のお一人の「川島 義隆」氏が「イミュータブルデータモデル」の情報を公開してくれている。

scrapbox.io

Step2. エンティティを分類する

洗い出したエンティティをリソースイベントに分類する。基準は明確で属性に”日時”を持つかどうかである。

イミュータブルデータモデル - kawasima

これはエンティティ名に「〜する」を付けてみることによって識別もできる。上記例では、「注文する」というのは自然に成り立つが、「会員する」というのは成り立たない。すなわちイベントは動詞から抽出したエンティティであることを意味する。

イミュータブルデータモデル - kawasima

また、5W1Hの分類において、
    Who, What, When, Where → リソース
    Why, How → イベント
になる。

イミュータブルデータモデル - kawasima

ここでの分類をER図に表すときには、エンティティ名に (R) や (E) を付けて、ひと目で識別できるようにしておくとよい。

イミュータブルデータモデル - kawasima

日時属性とは…?

「請求予定日」のように将来の予定を表すものや、「有効期限」「適用開始日」のようにデータのライフサイクルを表すものは、ここでいう"日時"属性ではない。業務のアクティビティを記録するのがイベントエンティティであり、その行われた時刻を記録するのがここでいう”日時”属性である。

イミュータブルデータモデル - kawasima

⇧ 物凄く大雑把に言うと、「データ」の分類において、

  1. エンティティ
    1. リソース
    2. イベント

のような感じで、2つに大別するということらしい。

注: マスタとトランザクションの分類は使わない

エンティティの分類には、日本の開発の現場では伝統的に「マスタ」と「トランザクション」というものが使われてきた。
    マスタ - 変更されないもの
    トランザクション - よく変更されるもの
という意味合いであるが、これは判別・使用用途ともに曖昧で、自転車置き場の議論 を呼び時間を無駄にすることがある。会話の中で使うのはよいが、設計ドキュメント、コードには一切使わないようにした方が良い。

イミュータブルデータモデル - kawasima

⇧ とあり、伝統的な

  1. エンティティ
    1. マスタ系(M)
    2. トランザクション系(T)

の分類を行わないことを推奨しているのだが、ここで困ったことが起こる。

「イミュータブルデータモデル」において「マスタ」に関わる「情報」をどう分類すれば良いかである。

何故なら、「マスタ」に関わる「情報」についても全く不変というわけにはいかないことから、必然的に「履歴情報」が発生し得る。

つまり、「マスタ」に関わる「情報」についても「日時属性」が必要となって来ることになる。

このあたりは、伝統的な「マスタ・トランザクションスタイル」における分類においても、悩ましい問題であり、

  1. エンティティ
    1. マスタ系(M)
    2. マスタトランザクション系(MT)
    3. トランザクション系(T)

のような苦肉の策として、「マスタ」の「履歴情報」として「マスタトランザクション系(MT)」という分類が検討されることもあったと思われる。

「イミュータブルデータモデル」だと、

  1. エンティティ
    1. リソース
    2. イベント

の両方に「マスタ」の「情報」を分割することになるんだろうか?

「UPDATE」を利用したくないという方針は非常に理解できるのだが、「マスタ」に関わる情報をどう扱うべきなのかについての方針がハッキリしない...

このあたり、

qiita.com

⇧ 上記サイト様によりますと、従来通りの「マスタ・トランザクションスタイル」との棲み分けをするという考え方もあるのだが、「UPDATE」は極力無くしたい気はするので、可能であれば、「イミュータブルデータモデル」のアプローチで解決していきたいのよね...

「状態遷移図」とかも「データモデル」との関連を表すのが大変そうですし...

とは言え、複雑さがComplexとComplicatedに大別できる話は目から鱗

JJUG CCC 2025 Spring(Japan Java User Group Cross Community Conference 2025 Spring)」のセッション『シンプルは作れる! - 実験からも見えてきたイミュータブルデータモデルの効果』の資料が公開されているが、

scrapbox.io

本質的な複雑さはどう設計しても変わらない。

すなわち本質的複雑さは保存法則がある。

シンプルは作れる!イミュータブルデータモデルの真髄 - kawasima

だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも…

シンプルは作れる!イミュータブルデータモデルの真髄 - kawasima

したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。

シンプルは作れる!イミュータブルデータモデルの真髄 - kawasima

⇧ という話があって目から鱗

「情報」について「Complicated」な状態に持っていくことで、「暗黙知」が排除できるわけだ。

結局のところ、

  1. 何のための情報なのか
  2. どの機能で必要とされる情報なのか

が分からないと、対策の立てようがないですからな。

まぁ、どんな「タスク(作業)」をするにしても、

計算機科学において、Garbage In, Garbage Outガービッジ・イン、ガービッジ・アウト/ガベージ・イン、ガベージ・アウト)、略してGIGOとは、欠陥のある、または無意味な(garbage)入力データは無意味な出力を生み出すという概念である。直訳は「ゴミ入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。

Garbage in, garbage out - Wikipedia

⇧ 上記の話に落ち着くのよね...

我々は「エスパー(超能力者)」では無いので、不明瞭な「情報」に対しては「推測」するしか無くなり、結果、「認識齟齬」の雨霰といった惨状が引き起こされるわけなのだが、「ソフトウェア開発」の現場だと不特定多数の人間が関わることがほとんどなので、この状況に陥る発生頻度が高い...

 

毎度モヤモヤ感が半端ない…

今回はこのへんで。