エンジニアの上野 伸一です。フルスタックエンジニアで、クラウド・ネイティブな構成を積極的に採用しています。
要求分析・設計時にはアリスター・コーバーンのユースケースをベースとし、データドリブンなアプローチを好んでおり、TH-Model、TM（T字形ER）などをプロジェクトに応じて適用度を検討する、データモデリングから開発がチョットデキル人です。
なお、本記事の内容は個人としての見解であり、所属する組織とは関係がありません。
Key-Value ストレージの利用
ここではエンタープライズ・システムで利用するというコンテキストに絞ってお話します。
弊社ではAWSのDynamoDBをストレージの1つとして利用しています。
ストレージの選択について問題提起を行い再考してみます。
まずDynamoDBを上手く利用できる例を以下に挙げます。
- 秒間数万アクセスのような大規模サイトでは、RDBMSへの負荷分散としてユーザーID等に紐づくセッション情報等の一部をDynamoDBへ委譲することで、RDBMSに過負荷が発生する状況を安価なコストで防ぐことができます。
- 大量のIoTデバイスの個々が、一定時間ごとに記録するストレージとして、スケーラビリティが高く安価なコストで利用できます。
いずれもKey-Valueストレージの特性を上手く利用できる状況です。
RDBMSでも同じ事が出来ますが、DynamoDBと比べるとコスト面で不利です。特に秒間数万READなどのトランザクションをSaaSのRDBMSサービス（例えば、AWS RDSなど）で担保しようとすると、月間コストで大きな負担となります。
表面上のお話
DynamoDBはいわゆるスキーマレスのKey-Valueストレージです。任意の属性を自由に追加する事が出来ます。ネスト構造も型付きサポートされ、画面を構成する上で必要な情報を一つのスキーマで表現する事が可能です。（ここでは、その正しさを謳っているわけではありません。）
GraphQLをサポートし、定義を元に自動生成される他、カスタマイズしたものを利用して問い合わせる事で、クライアントから型セーフに柔軟なスキーマを取得する事が出来ます。Key-Valueストレージの利便性の一つとして主キー相当となるKeyを自動発行してくれます。
一方でエンタープライズ、中でもB2Bにおける業務実態の永続化先として選択した場合はどうでしょうか。以下のような事が考えられます。
- 利用者としては無為なKeyでデータを検索するよりも、任意の属性（Value）で、検索を行う事を希望する状況が発生してくる。
- 初期に作成した画面に紐づくDynamoDBのスキーマが、ローンチ後の経過に伴い、画面に様々な機能が追加、または廃止されていく事で、スキーマが肥大化する、または本来の用途とは異なるデータ構造となる。
これらが時間経過と共にジワジワとチームの生産性に影響を及ぼします。
前者ではパフォーマンスIssue、後者ではスキーマの破綻を（整合性担保が難しくなる）招く恐れがあります。
本質的なお話
業務実態の記録に利用するストレージ について、背景や成り立ちを通じて再考してみましょう。
ここではデータモデリングという業務実態を正確にモデル化する手法やRDBの背景を認識する事で、表面上では見えない本質的な課題発見につなげていきたいと思います。
RDBの起源について
1970年代、IBMの研究者であった エドガー・F・コッド（E.F. Codd）氏は、「A Relational Model of Data for Large Shared Data Banks」という論文を発表しました。
主題であるリレーショナルモデルの根底には、集合論や関係代数といった数学的概念が存在します。データを集合として扱い、リレーションを集合間の関係と定義することで、データ操作が数学的な裏付けを持つようになりました。
ただし、集合論は皆さんも記憶にあるド・モルガンの法則のように、識別に数学の命題記述を用います。
¬(P ∨ Q) ≡ (¬P) ∧ (¬Q) 「命題Pまたは命題Qの論理和の否定は、命題Pの否定と命題Qの否定の論理積に等しい。」
例では集合(P、Q) の2つしかない単純な式ですが、より複数の集合や条件があれば、専門の数学的知識を必要とします。
そこで、IBMの研究者は数学的に破綻せずに人が容易に問い合わせを行える言語として、「SEQUEL（Structured English Query Language）」を開発しました。これが後に「SQL（Structured Query Language）」と改名され、リレーショナルデータベースを操作するための標準言語として広く普及しました。
このような背景もあり、本来RDBは単純なストレージではなく、数学的な正しさを担保できる集合論を表現するストレージとしての役割を担っています。
データモデリングについて
SQLやRDBが集合論として数学的な正しさを担保する背景について前述しました。
つまり、PおよびQといった集合（分かりやすくテーブル）は、その概念に基づく固有の属性として正しく定義されている事が、数学として成立するための前提条件となります。
そこで、現実世界で業務としてシステムが記録する様々なデータを、数学的に破綻させずに集合として定義する手法として データモデリングが存在します。例を交えて紹介します。
以下に概念モデル図の例を示します。
上記の概念モデル図から論理モデル図を起こした例を示します。
このモデル図では、部門と社員を異なる集合として定義し、さらにそれを紐付ける概念として所属という関連エンティティ（対照表）を設けました。これはAという集合（部門）とBという集合（社員）では、その識別子と、持つべき属性が異なるためです。
部門という集合には部門IDという一意識別子と、その概念に固有の属性を集めます。
同様に社員も社員番号とそこに閉じた属性のみを持つ事が、集合論としての姿となります。
部門と社員 という二つの概念には、その集合間の関係を示す 所属という概念が存在し、更に分析を進めると過去の配属といった出来事に値する概念も存在します。
これは、△△部に所属する○○さんという一般的な会社員の情報を、改めてデータモデリング手法を利用して、文書化（図式化）しただけのものです。
稀にRDB設計例として社員に部門IDの属性を宣言しているものがありますが、RDBを単なるストレージとして利用する際のSQL JOIN（交差結合）技術に過ぎず、集合論としては不正確な文書化と言わざるを得ません。
現実世界では言葉（概念）に基づくデータの集合が至る所に存在します。
映画「マトリックス」において主人公のネオが覚醒したシーンでは、目に映る世界が0と1の集合として見えていました。同じように視点を変えれば、あらゆる概念を集合として認知する事も出来ます。
実際に今着ている服も、この文章を見ているディスプレイやスマホ・パソコンも、昼食時に受け取ったレシートの内容も、全ては第一次産業（農林水産鉱業）から始まり、食材・繊維・部品となり、事業者は、縫製・組み立て・調理し、最終的に消費者へ提供された物です。つまり各工程において全ては素材となる概念に紐づくデータの集合が存在しています。
IT を一切利用・意識していない事業者であったとしても、帳簿や知見などを通じて以下が適切に管理され 収入を得る事で事業が成り立つわけです。
- Who (誰が)
- What (何を)
- When (いつまで)
- Why (なぜ)
- How (どのように)
- How much (いくらで)
- How many (どのくらい)
なぜならば、『気づけば事務所に 誰が、いつ、いくらで、仕入れたかわからない商品が大量にあり、ほしいという人に受け渡し方法未定で言い値で好きなだけ販売する』といったビジネスモデルは、事業として成立しないからです。
事業形態のモデル図・文書化
事業形態をどこまで分析・文書化するかは、システムが記録として残し、利用者に提示する必要がある業務要求の範囲に絞れば、情報が発散する事がなくなります。
予算が限られているのであれば、予算を元にデータに価値あるものから文書化していく事も考えられます。（こういうデータも記録できたら便利だけど予算オーバー、となるとそのデータは分析対象から外れていくでしょう）
そうして作成した要求分析の成果物があるとします。ユースケース記述であれば、わかりやすいです。そこから拾い上げた業務固有の概念（日本語）を数学的な集合として整理するために、データモデリングでは言語学的なアプローチを活用して体系立てて文書化します。
ここで語るにはページが足りないので、私が人に分かりやすく伝える際のものこと分析 について紹介します。
これは、もの（資源）と、こと（出来事）として、モデリングで表す際のリソース、イベントを区別する簡便な方法です。（※厳密には異なります。これは数学的なアプローチではなく、pattern ofというデザインパターンからのアプローチです。）
ユースケース記述から、業務用語をピックアップすると、お客さま、発注、入金など様々な業務固有の概念が拾えます。その概念に対して『～する』という言葉を紐付けて、日本語として成立すれば、イベント（出来事）である可能性が高く、そうではないものはリソース（資源）である可能性が高いという簡便な方法です。
- お客さま → お客さまする とは日本語で成立しないので、リソース（資源）
- 発注 → 発注する として日本語で成立するので、イベント（出来事）
- 入金 → 入金する として日本語で成立するので、イベント（出来事）
といった具合です。
これに関係性を紐付けた成果物を概念モデル図と呼びます。
先に紹介しました部門と社員の概念モデル図もそうですが、概念の段階では属性の列挙や正規化を意識した エンティティまで記述する必要はありません。
補足すると、更に分析を進めて論理モデリング図に書き起こす段階では、『概念は一意な属性を持つか？』を考えます。
具体例を挙げると、社員である以上、入社するというイベントは必ず発生します。これを概念では入社イベントとしてマークしたとして、論理化する段階で入社番号や入社IDなどという一意な属性が存在しないと分かれば、この概念は社員に従属する構造体（みなしエンティティ）と判断します。社員に帰属する訳ではないです。
従属とは、1：1で存在する別概念であり、帰属とはその概念の主体となる属性です。
（結論は、社員に入社日の属性を持たせても良いよというお話です。）
概念を整理する工程を経てイベントとして出来事を記録する集合（テーブル）に区分けされたものに対しては、改変されるべきではないというのがあります。イミュータブル・モデルなどとも呼ばれます。
確かに、私が無駄遣いした通帳の引き落とし履歴は、現実世界で泣いても叫んでも改変できません。誘惑に負けて食べたスイーツのカロリーも、去年や一昨年などのみなさんの歩んできた歴史も全ては過ぎ去った過去なので、改変はできません。現実世界を写像したモデリングでも同じ考え方を採用する事があります。
まとめ
今回の問題提起は、DynamoDBのスキーマレスの利便性のみに着目し、本質的なデータ設計についての知見が欠落していませんか？というお話でした。
- 安易に設計した スキーマや追加した属性は、本当にその集合に持つべきですか？
- イベントとして記録・運用してきた集合に対して、安易な更新や後付け属性追加などにより、過去の記録を改ざんしていませんか？
データモデリングを通じて数学的な正しさを担保した上で業務実態をモデリングとして写像できた場合、仮に利用する側の画面にどのような変更があったとしても、業務実態が変わらない限りは、高いパフォーマンスと保守性を維持したままで影響を最小限に抑える事が可能です。
データモデリングの世界では、作成したモデル図を元に業務実態が推察できるレベルまで正しく落とし込む事がゴールとされます。
最後までお付き合いいただき、ありがとうございました。
シェルパ・アンド・カンパニーでは一緒に働く仲間を募集しています。
