» DRI通信81~90号

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
DRI通信81~90号

創業者、椿正明の過去の発信のアーカイブです

【第90号】データモデルの進化

2004/12/27

DRI通信90号「データモデルの進化」  2004.3.1
氷の張るのを見ないまま、22日には21度になって、あっけなく冬が通り過ぎ、冬大好きのスキーファンにとっては、ちょっとさびしい気がします。花粉を防ぐためのマスクが目立ち始めましたが、皆様お元気ですか。
昨年暮れから始めたDOA+コンソーシアムには、皆様の関心が予想以上に高く、分科会も会場探しに苦労するほどの参加をいただき、今後どう運用しようかが、幹事会の課題となっている状況です。このエネルギーを日本の情報システムのレベルアップにどう活かすか、皆様とともに考えて行きたいと思っています。
■ データモデル
データモデルとは、データ構造、データ仕様を把握する枠組み・型・パターンと言う意味で用いられていますが、2つの使われ方があります。ひとつは「A社の販売システムのデータモデル」、「B社の生産管理システムのデータモデル」といったデータモデル個体に、もうひとつは「ERモデル」、「THモデル」といったデータモデルの種別を表すものに、です。学者は後者をDMF(Data Modeling Facility)と呼ぼうと提案しましたが使われていないようです。ここでは後者についてその進化を検討します。やや独断が混じりますが、ことの性質上客観は難しいので、ひとつの見方としてご容赦いただきたいと思います。
■ DMMM
前々回から進化を成熟度モデルとして扱ってきましたので、今回のはDMMM(Data Model Maturity Model)ということになります。次の5段階に分けて考えました。
(1)構造型DBMSモデル
(2) リレーショナルモデル
(3)ERモデル
(4) THモデル
(5) THeモデル

『【第90号】データモデルの進化』の続きを読む・・・


【第89号】メタデータ扱いの進化

DRI通信89号「メタデータ扱いの進化」  2004.2.2
本格的な冬を迎えていますが、いかがお過ごしですか。
さる1月20日、50名の出席者を迎えDOA+コンソーシアム分科会をスタートしました。初回で「各種DOA方法論の特徴・相互関係を理解するためにどのように議論を進めるべきか」がテーマでしたが、私の資料がややPLAN−DBの中身の見えすぎるものだったためか、議論を呼びました。しかし今後出てきそうな議論の片鱗が見えたので、対策を講ずると言う意味ではかえってよかったのかも知れません。参加の皆様から期待と貢献を伺いましたが、非常に熱心で今後の展開が楽しみです。
また、1月27日は35名の参加により、K2W勉強会(第15回)を行いました。ブレイズコンサルティングの鈴木秀美さまから「戦略経営とIT戦略の整合の重要性−エンタープライズ・アーキテクチャ」のプレゼンを頂いた後、「EAへの取り組み」として小島薫さま(BIT)、羽生田栄一さま(豆蔵)、萩原正義さま(MS)、真野正さま(CAC)、黒澤基博(DRI)によるパネル討論を行いました。足掛け4年続けかなりフランクな話ができるようになりましたが、DOA+に注力することもあって、これをもって第1期は終了とすることにいたしました。ご協力の皆様大変ありがとうございました。
■ メタデータ
「メタデータとは、データのデータである」などと説明されています。これは定義として不十分ですが、たとえば社員レコード
[1] −(椿正明、男、68、会長)
[2] −(竹下茂、男、62、専務)

 [社員番号]−(社員氏名、性別、年齢、役職)
として捉えるときの、社員番号、社員氏名、性別などである、と言えばおおむね理解していただけるでしょう。

『【第89号】メタデータ扱いの進化』の続きを読む・・・


【第88号】情報システムのアーキテクチャの進化

DRI通信88号「情報システムのアーキテクチャの進化」  2004.1.5
あけましておめでとうございます。おだやかな年明けでした。皆様お元気ですか。昨年末DOA+コンソーシアムを立ち上げました。今年こそDOA氷河期を終わらせたいと期待しています。データの図面を共有して、環境変化に柔軟に対応できる全体最適化の条件を整備したいものです。どうぞよろしくお願いします。
■ アーキテクチャへの関心
EA(Enterprise Architecture)が話題となり、ITアーキテクトといった肩書きの名刺を頂いたりするこのごろ、情報システムにおけるアーキテクチャへの関心が高まりつつあるかに見えます。アーキテクチャはシステムの寿命に関わります。10億円かけて開発して、5年で陳腐化するか、15年持つかは大違いですが、従来あまり問題にされてこなかったようです。うすうすこれを感じて問題にし始めたということでしょうか。
ハードの世界では、90年代ホスト(主人)がサーバー(僕、しもべ)にリプレースされ、さらに今これがWebの海に浮かぶというアーキテクチャの変革が進みつつあるわけですが、最近のアーキテクチャは主に90年代、短期ソリューションを目指して出来上がったバラバラシステムを、統合連携させようという、ソフトや業務モデル寄りのものに見えます。

『【第88号】情報システムのアーキテクチャの進化』の続きを読む・・・


【第87号】情報システムのスケールアップ問題

DRI通信87号「情報システムのスケールアップ問題」 2003.12.1
日が短くなって、葉が落ち、平地の紅葉も終盤戦になりました。気を抜かず注意していると風邪も引きにくく、また引いても早めに対策が打て、軽症で済ますことができます。元気にお正月を迎えましょう。
すでに案内申し上げましたが、正しい先進的DOAを普及しようと、幹事会社22社とDOA+コンソーシアムの立ち上げを企画し、12月12日(金)にDOA+コンソーシアム設立記念セミナーをひらくことになりました。会場の都合で人数に限りがありますので、お断りする可能性もありますが、そのときはどうかご容赦ください。1月以降、月1回くらいのペースで開く2つの分科会を中心に活動を展開する予定です。皆様のご協力をお願いいたします。
■ スケールアップ問題
ナイロン、テトロン、ポリエチ、ポリプロ、合成ゴムなどが工業化された、もう半世紀も前の石油化学時代、われわれケミカルエンジニアは、ビーカーの中で起きた化学反応がプラントの中ではそのとおり起きないからと、スケールアップ問題の重要性を教えられました。「規模/量の問題と質の問題は決して独立ではない」ということです。
情報システムにはたくさんのプログラムが含まれています。これを1本1本作って繋いでいけばうまく大規模システムができるか、というのが今回の情報システムのスケールアップ問題かと思われます。

『【第87号】情報システムのスケールアップ問題』の続きを読む・・・


【第86号】データモデルの設計思想

DRI通信86号「データモデルの設計思想」     2003.11.4
11月を迎え、平地でも木々の葉が色づき始めました。朝早く自転車で北鎌倉駅
まで、ライトをつけ手袋をはめ、さらに冷気で涙が出るのを防ぐためゴーグルを
つけて下る時期となりました。
10月30日(木)第14回K2W勉強会は、35名の参加のもと、「経営に役
立つ情報システム企画を立てるには」というテーマで行いました。サヴィオンテ
クノロジーの宇野澤社長からはBPM、ヘッドストロング瀬賀取締役からは
EAIについてのプレゼンをいただき、活発な議論が展開されました。次回は1
月27日(火)やはりBPMやEA関係のテーマで行いたいと考えています。
■ モデル化の目的と適用範囲
データモデルに限らず、モデルがないとすると、本や新聞のように、対象を自然言語主体で記述しなければなりません。自由度がありすぎて、属人的になり、抜けや矛盾の摘出が難しくなります。モデル化は、対象の持つ構造を捉えて、この自由度を必要十分かつ最低限に抑え、できればパラメータを指定するだけで、記述を完成させようとするものです。したがって、ある対象に対して、自由度のある、いろいろな記述のできるモデルは一般的に自然言語よりの未完成なモデルと考えられます。
化学プラントやデータモデルなど構造を問題とする対象は、一般に要素とその関係から構成されるので、箱と線を主体とした図と表で記述することになります。コンピュータは、図が解釈できないので、コンピュータ処理のためには、これを表−リレーショナルテーブルなど−に変換します。3次元物体は、目に見えるので、これに制約され、図の描き方にバリエーションが出にくいのですが、情報がらみの対象は、目に見えないため、多様な表現が考えられ、その標準化が難しくなります。

『【第86号】データモデルの設計思想』の続きを読む・・・


【第85号】DOAにおける処理の考え方

DRI通信85号「DOAにおける処理の考え方」     2003.10.1
8月と逆転したような9月でしたが、ここに来て秋らしくなってきました。厳しい状況が続きますが、皆様いかがお過ごしですか。
システムの規模をデータの共用される範囲とするならば、それは世界がひとつになるまで拡大しなければ止まないものように思われます。種々のトラブルを耳にするとき、このニーズへの対応力が企業競争力の要因のひとつとして、ますます大きくなっていくように感じられます。
「(情報)処理」という言葉が、いろいろな局面において使われますが、その内容、とくに粒度などが、まちまちとなって誤解が発生することが少なくないようです。以下その整理をDOAの観点から試みました。ご意見など歓迎です。気軽にお寄せください。
■データベースをハブにして
データ中心アプローチとは、それまでのプログラム中心アプローチを改めるべきものとして登場しました。プログラム中心の場合は、一般にその出力を次のプログラムが受け取るバケツリレー方式になりますので、インターフェースがスパゲッティになりやすく、またあるプログラムの変更がその下流のプログラムに次々と波及し保守性が非常に悪くなります。
データ中心の場合は、データベースをハブにして、プログラムはここから入力を受け取り、ここへ出力を返します。一般にデータベースはデータの記憶場所としての役割を果たすものと理解されていますが、むしろ通信の場としての役割の方が重要ではないかと考えられます。これによって各プログラムはデータベース通信場とのインターフェースだけ考えればよいので独立性が高まり保守性が向上します。

『【第85号】DOAにおける処理の考え方』の続きを読む・・・


【第84号】DOA第2ラウンド

DRI通信84号「DOA第2ラウンド」       2003.9.1
東京電力には良かったのでしょうが、大変涼しい夏でした。結局、海水浴はせず、ジョギングやサイクリングで体力維持を図ることになりましたが、皆様はいかがでしたか。
8月26日(火)第13回K2W勉強会は、「企業情報システムの役割、これまでと今後」というテーマで、8名の講師、45名の参加をいただき、やや発散気味の感もありましたが、熱心な討議が行われました。「業務システムは各部門の責任で開発・運用すべし」「システム部門は人的を含めたインフラ整備により全体最適をはかり、事業競争力のある先進的IT企業を実現すべき」などが指摘されました。
■DOA第1ラウンド
東京国際大学の堀内一先生(当時日立製作所)の命名されたDOA(Data Oriented Approach)が日経コンピュータ誌上で紹介されたのが1985年、その年の10月に弊社DRIは創立しました。ほぼ18年前になります。80年代は結構受けて、大企業の情報システム部門に対し、DOAによるシステム開発方法論「PLAN−DB」の教育・コンサルテーションを行うことができました。開発/再構築の手ごろなアプリケーションを選んで、3ヶ月くらいで概念DBを設計し、その中で人を養成します。従来のPOA(Process Oriented Approach)を脱し、DOA的考え方を身につけるには、どうしても3ヶ月くらいは必要でした。

『【第84号】DOA第2ラウンド』の続きを読む・・・


【第83号】LSVの目的と進め方

DRI通信83号「LSVの目的と進め方」   2003.8.1
長い梅雨ですね。皆様お元気ですか。私は大学4年の夏(1958)梅雨明けが待ちきれなくて、友達と二人でテントかついで北アルプスに出かけましたが、毎日雨、雲の平で往生したことを思い出します。ビールやクーラーも大変でしょうが、東北は地震もあって気の毒ですね。
会員の方にはすでにお知らせしましたが、8月26日(火)「企業情報システム部門の役割、これまでとこれから」という題でK2W勉強会を開きます。参加されたい方は弊社CRMグループまでご連絡ください。
■レガシーシステム
我が家の付近は昭和40年ころ開拓された住宅地ですが、世代交代の時期にあたり、更地にして売りに出される物件を良く見ます。この場合、建物はマイナスの評価とされているわけです。同様に、かつては資産であったソフトウエアが、もはや維持費のかかる負債であると評価されたりします。これは、高度成長期、短期的ニーズに対応して、田舎の温泉旅館の増築さながら、コピー機能を活用して、次々とソフトウエアを増産して作られたレガシーシステムに多いように思われます。
このところ2007年問題という言葉を耳にします。1947年生まれの団塊の世代が2007年に定年引退すると、彼らの作ったシステムのメンテナンスができなくなり、大きなトラブルが発生する、との心配です。度重なる場当たり的メンテナンスによって、ドキュメントとスパゲッティ化したソフトはすでに乖離していて、スーパーマンの暗黙知が頼りとなっている、その彼らがまもなく引退する、ということでの問題提起です。

『【第83号】LSVの目的と進め方』の続きを読む・・・


【第82号】高品質データモデリングの要諦

DRI通信82号「高品質データモデリングの要諦」   2003.7.1
厳しい第1四半期が終わりました。SARSも終盤のようです。梅雨は奄美大島までが明けたとか、風邪などにも注意してがんばりましょう。
弊社では恒例の夏のセミナーとして、今年はデータインフラ−?メタデータ、?コードデータ、?オペレーショナルDW−を取り上げました。?はリアルタイムDWとも言われますが、このところ非常に注目されてきています。システム間でやり取りされるハイレベルメッセージをストアし、オペレーショナル業務の意思決定のスピードと品質向上を狙うもの、ERPパッケージの狙いをより容易かつスマートに実現する可能性を持っていると期待されます。
■ データモデリング復活のきざし
情報産業はファッション産業でしょうか、90年代C/S、ERPなどに押されて影の薄かったデータモデリングが、こところ復活してきたように見えます。「既存システムのDB構造を見れば大体のデータ構造は分かる」、「小ぶりのC/Sシステムならデータモデリングと言うほどのものは必要ない」、「One Fact in One Placeなどと言っていると調整に時間がかかって間に合わない」、などの理由からしばらく敬遠されていたわけですが、SCM、CRM、連結会計など、出来上がった孤島システムを繋ぐニーズが顕在化して、「システム間インターフェースはデータから成る、その意味を合わせるデータモデリングと、その形式を合わせるコード統一が不可欠」となってきたのではないでしょうか。

『【第82号】高品質データモデリングの要諦』の続きを読む・・・


【第81号】ハイレベルLSVの提案

DRI通信81号「ハイレベルLSVの提案」   2003.6.1
梅雨のはしりの涼しい雨、風邪を引いたりする人が目立ちますが、皆様お元気ですか。
今年度も厳しいスタート、そして今は地球の限定された場所、限定された期間と思われているマスク姿が、100年後には「あちこち、いばしば」となったら悲しいなと思ったりする日々です。
今月は、聞いたこともない「ハイレベルLSV」をテーマとしました。LSVとはLegacy System Visualization すなわち「レガシーシステム可視化」という意味です。ハイレベルとは、「アプリケーション間で共通の」といった意味で、ロウレベルの「アプリケーション内固有の」という意味に対比するものです。したがって「アプリケーションの骨格構造の可視化」と理解していただいて良いかとも思います。
■成熟期に入った情報システム
企業による差はありますが、多くの企業において1990年ころまでに業務アプリケーションのシステム化と称するコンピュータ化が大幅に進められました。コンピューティングコストの低下とRDBMSの実用化が、これに大きく寄与したものと思われます。「白地」の未コンピュータ化業務は非常に少なくなり、処理の自動化による合理化が進んだわけですが、開発時期・スポンサー・開発担当者が違っていて、できたのは多くの場合、相互データ流通の難しい、いわゆる孤島システムでした。90年代に入っても、ユーザ主導のC/Sシステム開発など、この延長線上でたくさんの分散バラバラシステムがつくられました。

『【第81号】ハイレベルLSVの提案』の続きを読む・・・