【このテーマの目的・ねらい】
目的：
昔の仲間でありデータ総研創業者の椿正明博士の 偉業を偲びます。
ねらい：
ご冥福を心からお祈りいたします。
ーーーーーーーーーーーーーーーーーーーーーーーーー
８月最後の日３１日に以下（全文、原文のまま）の葉書が届きました。
たいへんな衝撃で、誠に残念なことでした。
心からご冥福をお祈りいたします。
夫、椿正明儀、去る８月25日早朝、老衰のため
天に召されました。86歳8か月でした。
ここに謹んでご通知申し上げます。
なお葬儀は29日、近親者にて滞りなく済ませました。
ここに生前中賜りましたご厚誼を深謝して
心より御礼申し上げます。
正明は2014年8月心因性脳梗塞で死線をさまよい、
重い半身麻痺が残りましたが、
リハビリも頑張って幸い皆様のお力添えで
創立30年のＤＲＩのお祝いにはご挨拶も出来ました。
東大化工の親しい友人の方々にも
何回もお見舞いやクラス会を開いていただいたり、
深謝しております。
2017年9月から翌年3月まで
高明一家の協力で自宅でも過ごせました。
その後正明が大好きな北鎌倉の自然を窓から楽しめる
ソンポケア北鎌倉で、手厚い看護を受けることができて
介護の皆様にも心から感謝しております。
丸7年間の長い闘病生活で
皆様から常にお励ましやお力をいただき
心から感謝しております。
大変恐縮でございますが、
自宅へのご焼香並びにご香典、ご供花、ご供物
につきましてはご遠慮いただきたく
お願い申し上げます。
皆様のご多幸を心からお祈りいたしております。
住所 氏名（奥様）拝
注：死因に老衰とあります。
８６歳で老衰というのは違和感がありますが、
特別な病因がなく心肺停止になる状態を老衰というのでしょう。
８月１０日に８５歳で亡くなった友人二木英徳氏の「老衰」も
違和感ありました。
８月２４日に９０歳で亡くなられた
京セラの稲盛和夫氏の「老衰」の場合は、
「そうかな？」とは思いますが。
注：老衰につきましては、
別項「敬老の日の話題です！」をご参照ください。
そこで以下に、椿正明博士の偉業を確認させていただき、
そのご冥福をお祈りしたいと思います。
「概念ＤＢ構造図の発明」椿博士の貢献は、何といってもビジネスのデータモデルを表記する
概念ＤＢ構造図の発明です。
当初は、この方式はＴＨモデルと称して、当時筑波大学教授だった
穂高良介氏との共同開発でしたが、その後、実用に持ち込んだのは
椿博士です。
「概念ＤＢ構造図の例」以下の図は、簡単な受注・出荷・売上処理を例に
教材用として上野が作成しました。
概念ＤＢ構造図の内容とその特長を以下に解説します。
「概念ＤＢ構造図作成ガイド 簡略版」
以下の内容は、
椿博士（以下椿氏と表記）の「データ中心システムの概念データモデル」の記述を基に、２０１６年に上野が教材用に作成したものです。
0. 概念ＤＢ構造図の特長・利点・概念ＤＢ構造図は、㈱データ総研創業者の椿正明博士（原典ママ）
が開発した、一般的には「ＥＲ図」と言われるものである。
・一般的なＥＲ図に対するその特長・利点は以下のとおりである。
|
1
|
忠実なビジネスの写像となっている
|
・
同図を見ると、対象のビジネスモデルを読み取ることができる。
＝ビジネスの登場人物、
ビジネスの主要プロセスが分かる。
|
|
2
|
作成ルールは単純明快である。 （２．参照）
|
・
「適当に作成」ということがない。
|
|
3
|
専門家でなくても作成できる
＝ビジネス従事者が作成できる。
|
・
ビジネスの分かるビジネス従事者に作成ルールを説明すると、すぐに作成できるようになる。
|
|
4
|
作成した概念ＤＢ構造図を
ビジネス従事者がレビュできる。
|
・
３．と同様に、ビジネス従事者に作成ルールを説明すれば、その人たちが作成された図のレビュができる。
⇒ システム仕様上の重大な誤認識を避けることができる。
|
1. 表記するエンティティ（管理対象）の種類
|
区分
|
説明
|
備考
|
|
リソースファイル
|
経営資源等を表すファイル。
|
いわゆるマスタファイル系である。
|
|
タイプ
リソース
|
・ 性別などの種類・分類を示すもの。
|
|
オカレント
リソース
|
・ 人（社内・社外）、物（設備・原材料・部品・中間製品・商品・製品・サービス）。
|
|
関連リソース
|
・ 製品別倉庫方式の場合の製品の出荷倉庫など、リソースの関連付けをするもの。
|
|
イベントファイル
|
ビジネス活動を示すファイル。
|
いわゆるトランザクションファイル系である。
|
|
通常イベント
|
・ 契約、受注、出荷、等々
|
|
異動イベント
|
・ オカレンスリソースの異動を示す。
・ 所属の異動、役職異動など。
|
|
在庫型ファイル
|
保持量の増減変動があるファイル（在庫や勘定）
|
|
|
断面ファイル
|
リソースファイルまたは在庫型ファイルのある時点の状況を示すファイル（「１６年３月末残高」等）
|
|
|
要約ファイル
|
イベントの集約（合計）ファイル
「１６年３月Ａ商品売上高」等
|
|
2. 概念ＤＢ構造図の書き方
|
1
|
規則1
|
リソース系とイベント系を分ける。
（簡単な場合は、リソース系を上、イベント系を下に示す）
|
|
2
|
規則2
|
リソース系においては,
タイプリソース（○）,オカレンスリソース（□）,関連リソース（◇）,リソースの断面（ ）や異動イベント（◆）の順に,矢線が上から下に向かうように配置する。
|
|
3
|
規則3
|
リソース系においては,左から右へ,社内,設備,社外,もの,その他の順に, しかも似ているものを近くに配置する。
|
|
4
|
規則4
|
イベント系においては,在庫（ ）,在庫の断面（ ）,要約（ ),イベント(■),イベントの異動(◆)の順に,矢線が上から下に向かうように配置する。
|
|
5
|
規則5
|
イベントの左右に関しては先行イベントを左に,後続イベントを右に配置する。
|
|
6
|
規則6
|
要約の左右に関しては厳密な規則はなく,基になるイベントの上部の空スペースに適宜配置する。ただし,本格的なデータウェアハウスなどの場合は別紙にまとめるのでこの限りではない。
|
|
7
|
規則7
|
サブタイプ（リソースまたはイベントの部分集合）は原則として基になる概念ファイルの右に展開する。スーパタイプ（リソースまたはイベントの上位集合）は左に展開する。
|
出典：椿 正明 著「データ中心システムの概念データモデル」一部、上野則男が修正
個々の表記法については精緻な部分もあるのですが、
全体配置のガイドがありませんので、
「ビジネスの写像」として見ることができません。
「オブジェクト指向のクラス図との違い」
データ項目の定義内に、その処理方法（メソッド）をカプセル化する
という発想はよいのですが、そのために記述量が増加し、
全体の見通しが悪くなります。
レイアウトルールの規定がないのは、一般のＥＲ図と同じです。
カプセル化は、ソフトウェアの自動生成には有効ですので、
オブジェクト指向のクラス図は、ソフトウェア製造用のツールであって
企画や分析段階のツールとしての有効性は今一ということになります。
因みに、概念ＤＢ構造図の場合の処理ロジックの記述は
別様式のＳＰＦチャートで記述するようになっています。
要約しますと、概念ＤＢ構造図は、
作成表記ルールが網羅的かつ明快で、
作成した図によって、システム屋でなくても対象ビジネスの構造
（ビジネスモデル）が把握できることです。
データの記述モデルではなくビジネスモデルの記述法である
といっても良いくらいのものです。
（前掲の２手法ではそれは叶いません）
「社業としての概念ＤＢ構造図ビジネス」椿氏の創業された㈱データ総研では、
概念ＤＢ構造図を既存の画面データや帳票を分析して作成する手順を確立して主要なビジネスにされました。
日本では、ノウハウよりも作業がお金になるのです。
このビジネスモデルは成功し、
多くの若いデータ分析人材を養成することができました。
ビジネスを知らない人（含む椿氏）が、
標準的な手順によってデータモデル（ビジネスモデル）を作成できるのは
奇跡に近いことでした（これも発明です）
「概念ＤＢ構造図が生まれた背景」
「データ中心システムの概念データモデル」に、
以下の記述があります。
化学プロセスでは、物質の状態を捕らえ、
これに加熱、反応、分離などの処理を施して
所期の物質の状態を作り出す。
したがって、
状態０→処理１→状態１→処理２→状態２→・・・・処理ｎ→状態ｎ
のような連鎖（本当はもっと複雑なネットワークだが）を考える。
状態と処理の２元論は1965年頃からのテーマである。
状態として各種データの成果物を考えれば、
情報システムでも同じになる。
データベースは、ある実務領域の状態を表す。
これが更新処理によって次の状態に変化する。
大学で応用化学を学ばれた椿氏の発想の原点はここにあるようです。
リソース系とイベント系を峻別する発想も
そこから来ているように思われます。
リソース系は化学反応だと触媒のようなものでしょう。
「実装独立」
椿氏たちは、概念ＤＢ構造図を中核にしたデータマネジメントの推進を
ビジネスにしていた時に、こういう主張をしていました。
「まずは概念ＤＢを明確にする必要がある。
概念ＤＢは実装独立である」
これに対して、多くの旧来型ソフト技術者から
「我々は結局動くソフトを作らなければならない。
物理こそが価値あるもの、概念にこだわる意味が分からない」
という批判を浴びました。
概念ＤＢは本質的なデータ体系を把握する上で重要なのですが、
「このモデルは実装独立なのだから、
物理へのつなぎ方は自分たちで考えなさい」
と言っていました。
しかし、時間の経過と共に、物理へのつなぎ方もガイドした方が
概念モデルの普及のためにも有効だと考え
「概念データベースから物理データベースへ」
という1項が設けられてその留意事項が解説されています。
「One Fact in One Place」
これは「データの不整合は、
一つのデータが複数個所に存在することによって発生するのだから、
一つのデータ項目は１か所の身に存在するようにしなければならない」
という一般的な指導原理です。
椿氏はこれについて、徹底して主張していました。
この思考の原点として（想定）、前掲書にこういう記述がありました。
「中学時代、因数分解が好きだった。
システムには多くの要素が絡むが、それらが独立に動けるのが美しい。
だから独立した要素に分解したいと思う。
データモデルを考えるときも無意識のうちに要素の独立性を追及するらしい。
正規化し、データ項目としてエンティティごとの属性を扱うのは
そこからきているのではないかと思う」
「傘を持ち歩く」
最後に一つエピソードです。
椿氏はいつも中身がたくさん入っている重いカバンを持ち歩いていました。
その中に、いつも折り畳み傘が入っていました。
私が「雨でないののなぜ傘を持っているのですか？」と尋ねますと、
こういう答えが返ってきました。
「傘がいるかどうか考えるのはめんどうくさい。だからいつも持っている」
椿氏らしい割きりだと感心しました。
そのことをいまだに覚えていて、ときどき私も真似をしています。
「椿さん、いろいろ教えてくださってありがとうございました。
安らかに樹々の緑の中でお休みください！」
９／２追記
「名人椿正明が教えるデータモデリングの技」（２００５年11月刊）
今回、この著書を読んでみました。
そうしましたら、「技」以上のことが多数記述されていました。
１．データモデルの６類型
手がけられた600件のデータモデリング事例に基づき、
「データモデル構造は以下の6タイプに分けられる」
と主張されています。
建設業、生産財製造業、消費財製造業、小売業、卸業、サービス業
これは一つの道を究めたからできた大発見です。
２．情報システム開発・保守のあるべき論
横断的データマネジメントを基本にした姿を描かれています。
これができていれば「２０２５年の崖」はなかったのです。
２００５年時点で、椿氏はすでにこう言われています。
「３５年間主張し続けていることが未だに実現できていない」
こうなると、哲学者の域です。素晴らしい達観です。
本当に「名人」でした。
しかし、情報システムにおけるデータマネジメントはインフラですから、
アプリの華々しさと異なり
社会的には「縁の下の力持ち」の扱いだったのです。
それである事例を思い出しました。
椿氏の理論にほれ込んで、全社内システムをコツコツと数年かけて、
上記「あるべき論」に移行させた準建設業のＸ部長が
社内でまったく評価されなかったのです。
おそらく累計で２桁の億円の効果があったはずなのですが、
門外漢のトップには見えなかったのです。
