More Related Content
Similar to 開発の現場でも役に立つボトプアップによるデータモデリング活用実例 (20)
開発の現場でも役に立つボトプアップによるデータモデリング活用実例
Editor's Notes
- みなさん こんにちは。 本日のSencha RAD MIX も後残すところ Sencha, RAD ともに2セッションとなりました。
いつものエンバカデロのデベロッパーキャンプにおいては、ほぼ開発技術や実例のご紹介をしておりますが、
今日のSencha RAD MIXのこのセッションでは、データモデリング の活用について、ご紹介していきたいと思います。
エンバカデロのセミナーなどで私がしゃべる時にほぼ必ず行っていることが一つありまして、皆さんにアンケートをとらせていただいています。
皆さんに挙手をしてもらって、そのセミナーに参加されている皆様の、趨勢を図ることをいつもしているんです。
今日は、データモデリング周りのお話ということで、一つ伺ってみたいことがあります。
ということで質問です。データベース設計を専門、もしくは主体的に行われている型、または担当であるというかた、この中にどのくらいいらっしゃいますか？
一方で、データベース設計ではなく、開発のコーディング、プログラミング設計が主体、という方、どの程度いらっしゃいますでしょうか。
- データモデリングの話ということで、データベース設計者さんもいらっしゃいますね。開発者さんの方が圧倒的に多い。
データベース周りのお話なのに、この趨勢で大丈夫なのかと心配されてませんか。 大丈夫です。安心してください。今日の内容は開発者さん向けに、このような趨勢になることを予定して作っています。
ということで、今日のタイトル：開発の現場でも役に立つ・ボトムアップによるデータモデリング・活用実例
なんですが、どういう意味か、簡単に解説してまいります。
- 最初の「開発の現場でも役に立つ 」の部分は、つまり、システム開発・システムの連携を行う方々のことであります。
その方々に役立てていただける内容をお伝えしてまいります。
データベース設計専門の方、というわけではなく、とくに、ビジュアル開発を日々行っている現場の皆様に特に効果的となるようなデータベース周りのお話を中心に行ってまいります。
- そして、真ん中のワードを飛ばして、語尾の「活用実例」についてです。
これはそのまま、企業さんの実例をもとに、現場の皆様がお困りの内容に役立つ内容をお伝えするというものです。
データの整合性を確保や、データドキュメント、多くの工数と苦労を必要とすることでしょう。
そしてボトムアップによるデータモデリングで皆様の日々のデータ周りの課題・お悩みを解決する方法をご紹介してまいります。
- のこる真ん中のワード 「ボトムアップによるデータモデリング」について、話を進めてまいります。
- データベースを扱う皆様には、改めてご説明の必要はないかとおもわれますが、まず、「データモデリング」とは何かを簡単におさらい、説明します。
- ではこのデータモデル、設計図として、
共通の理解のための標準的な記法として、データの構造をあるルールにのっとってモデル化するというものであります。
それがこれ。参照や関連づけを受けるデータや、意味のひとまとまりを「エンティティ」（データ構造のひとかたまり）
それらエンティティの関連づけを表すとリレーションシップ（関連させる線）
そして、エンティティは属性を持つことができます。
たとえば、「患者入院情報」というエンティティは、入院日付や退院日付といった属性をもちますし、患者エンティティは、患者苗字や患者生年月日といった属性をもっています。
こういったデータモデルの図を、エンティティ・リレーション ダイアグラム またはER図 と呼んでいます。これがデータベースの設計図でありますね 。
これらER図は、最終的にはデータベースにテーブルの実装までを最終結果として設計されることが多いです。
- さて次、こんどは「ボトムアップ」についてです。
先ほド説明したER図を書き起こす方法として、つまりデータベースの設計書を作るうえで二つの手法があります。
トップダウン手法とボトムアップ手法です。
トップダウンはシステム化すべきビジネスフローは何か、かかわるエンティティは属性は？ といった具合に、関連の方々などにヒアリングをし、順にビジネスフローを明らかにして、 概念設計、から論理、設計、とおりてくるもの。
一方で「ボトムアップ」のほうは、実際にある画面帳票から必要な項目・属性を洗い出したり、設計を行っていきます。
場合によって既にあるDBからモデルを明らかにする場合も。
今回は、データベース設計として上から落とし込むトップダウンではなく、より開発現場使える、いわゆる開発現場に近い、画面や帳票、使うデータベースからデータモデルを作り出すボトムアップにフォーカスしてお話します。
- さて、タイトルにまつわる説明をおえたところで、もぅひとつのテーマ、があります。
みなさま、データ構造の把握、できていますでしょうか。
できている、ハズであります。
データ構造を把握することが必要であった企業様の実例をご紹介してまいります。
そして、日々の開発の中で、これできたらいいのに、という要望や課題についてもデータ把握を行うことで解決できるということをお伝えしてまいります。
まずは、いくつかの例を見てみましょう。
- まずはこんな声があります。 わからないわけはありません、探せば見つかります。最終的には。
それに、設計書があればいいんです。 それを見ればいいんですから。
もっとややこしいケースでは、設計書と、実際のDBとちょっとずつ違うところがあることもあります。しかし、古いシステムでは、設計書が失われていたり
また、最近のシステムでは、 開発現場で、その場でスキーマを作り、運用して、開発、変更・運用を繰り返すケースもあり、データベースの現状がつかみづらいケースもあります。
そして、今回ご紹介する「データどこにあるかわからない」例として、企業合併や買収で複数のシステムが短いスパンで次々に連結され、データがさまざまなシステムに分散されていた、という事例を見てみましょう
- それがこのTalk Talkさん
ビジネス・会社規模が急速に拡大して そのために複数のシステム導入したんですね。 その結果、いくつかのシステムにデータが分散してしまった
そして発生した問題は、ビジネスパーソンが必要なデータを望んでもシステム部が迅速に提供できない。場合によっては必要とされたデータもビジネスパーソンも技術者も意思疎通ができずに、狙いとは異なる間違ったデータを渡してしまう。 共に明確にデータが見えてない・把握していないが故の悪影響が発生し始めていたわけです。
さらには、急速な拡大は、顧客ばなれを招いていた。そこでビジネスパーソンは、データからそれを読み解く必要があったわけですね。
なので、データを理解し、簡潔なデータモデルを開発する必要性があったのですね。
ここで使われたのが、データモデルを可視化・モデリングするツールです。
- この試みはあたり、データを可視化して、ビジネスパーソンと 技術が会話をすることができるようになったわけです。
どのように可視化したか、できるのかは後ほどのデモでおみせすることとします。
データベースからデータ構造を可視化したことで、技術チームはデータの構造と属性を簡単に伝えることができるようになりました。 ビジネス・チームは要件の簡単な説明を提供するだけで、チームはそれらをお互いに理解して落とし込み、より効果的なデータの照会と報告を可能にしたのです。
ポイントを整理しますと、TalkTalkさんのケースは、技術陣でさえ、欲しいデータがどこにあるか、わかりずらい。
それを視覚化して簡潔なモデルとしたこと。結果、必要なデータを得ることができるようになったんです。
- 古いシステムで設計書が失われていたりすることがあります。そして長い期間、有効に運用されてきたDBは積み上げられ、より複雑化しています。
このような多数のテーブル、データ項目を扱う場合には、現場にも、それなりのリソースが必要です。リソース、つまり人員であったり、何らかの支援として活用できるもの・コトであります。
一方、レガシーシステムだけではなく、最近のシステムでは、データウエアハウスやBIツールの導入もあり、多くのデータをより効率的に解析、判断のための情報提供が望まれるケースも増えています。
このような両ケースにおいて、データの扱いの複雑さ、かかるエフォートはなかなか測りづらく、どれだけ人員が必要か説明することも難しかったりします。
そうして説明の難しさ故、さらなる追加支援を得ることができず、結局現場にしわ寄せが。うまく説明さえできれば必要なりリソースを得られるのに…といったケースがこちら。
- エントラストさんは、パブリック、キー、インフラストラクチャ（PKI）や、情報保護のサービスを世界に提供するグローバル企業です。
こんなときのエントラストさんの例はこうです。
状況として、レガシーシステム・データベースですでにドキュメントがほとんどないか、あっても少しだけ。
一方で与えられたタスクを成功させるためには、複雑なデータベースシステムを扱うだけのリソースと努力が必要
ただ、技術者たちは、マネジメント層に必要なだけのリソースを上手に伝える能力を有していなかった。
つまりこのデータを扱うことがどれだけ大変か、を説明することができなかった。
そこで取った手段が可視化でありました。
そのふくざつなコンセプトの説明をモデルにっよって議論し、意思決定ができるようにし、必要なサポートを受けたのです。
- この例は、データモデルその可視化を直接的に議論の資料としています。
そしてもうひとつ注目すべきことは、この、本来、用意すべき資料・データ構造が以下に複雑なのか、を表すデータモデルの作成がリバースエンジニアリングによって少ない工数で成し遂げられている、というポイントです。
モデル化した後の利用方法は企業によって様々ですが、この時短効果は、多くの現場でも適用できる可能性を持っていますよね。 想像できますでしょうか。
- 大きな二つの事例をご紹介しました。 それぞれの企業での問題と、データモデルの使い方、利用方法は異なりました。
必要なデータがどこにあるのか？を明らかにする。
データモデルを議論の対象とするため可視化する。しかも効率よく短時間に、です。
最初の、皆様への問い 「データの把握、できていますか？ 」 についての一つの答えは、こうです。
データを可視化すれば、把握できる！
- ではどのようにして把握するのか、エンバカデロのセッションではおなじみのライブデモに入りたいと思います。
実際にこのマシン上でオラクルのデータベースが稼働しています。このデータベース構造を解析、リバースエンジニアリングして開始化したいとおもいます 。
簡単なデモでありますが、このリバースエンジニアリングによって素早く可視化できる、データ構造が把握できる。
今回は小さなモデルをDBから引き出していますが、これが大規模になればなるほど、人の手で可視化するのは大事になります。
リバースエンジニアリングによって可視化できた。これがキモです。これによって現場のデータ周りの課題の解決の術とすることができてまいります。。
- ここまでで、大きな事例紹介と、デモをお見せしましたが、今度は、実際に現場で起こる課題についても落とし込んで見ていきたいと思います。
良く起こる課題、よくある話、または皆さんが時折思う・感じる不満があります
いくつか例が出ていますが、このなかでここで一つ注目してみましょう。
リバースエンジニアリングというと、既存の古いでDBに対しておこなうような感じもしますが、
それでけではありません。新規のシステム、新規のデータベースを開発している時にもリバースエンジニアリングは役立つんです。
システムの要件に合わせてデータ設計したものの、開発進行に合わせて要件も少しずつ変わってくる、要件がチマチマかわってくると、データベースも変わってくる。
開発に合わせてデータ構造を変える、変わっていくことになりますが、変わったデータベースをどうやってチームと共有していくのか、どうやって柔軟に反映させていくのか。リバースエンジニアリングによって、最新の状況を手に取れる効果があるわけです。
- また開発進行に合わせて変更した場合、最初に書いたドキュメントとは一致しないわけですね。
今どうなの_現在の設計もってきて！ なんでこともあるわけです。そうすると、現場側が「調査します、最新化します、更新します」といったことになり手間がかかる。
ドキュメントの更新、提出もそれなりに工数がかかります。
一方、既存データベースのドキュメントがある場合にも、油断できないです。設計書があるんだけど、なんかちょっと違う。結果的にいちいち確認しながらやることになる。
とても厄介なケースですよね。
- これらのケースにも役立つのがデータモデルを可視化できる ER/Studioです。
リバースエンジニアリングで可視化することはすでにお伝えしました。システム連携の際にデータ構造を把握するのに役立ちます。そして把握の際に、テンプレート・ドメインを作成しておくこともできます。
同じ型でデータの一貫性を保ちつつDBを新たに設計することもでき、システム連携がはかどります。
常づね変わるデータベース改変にも役立ちます。 小規模な変更が継続して行われているような場合、今現在のデータ構造をまさに実体から確認できます。
設計書が古くてちょっとずつ異なる、というケースにおいても、実体からデータ構造を確認できるので古い設計図をうのみにして後々合わない、失敗した、ということもないでしょう。
- そしてさらにドキュメントとして発行する機能が先ほどの課題を解決してくれます。
顧客から提出を迫られるドキュメント、 もうめんどくさくないです。 Wordベースで発行することもできます。 HTMLで出しておいて、みんなでブラウザで閲覧、かくにんするといったこともできます。
エクセルからの取り込み、出力もできます。
このエクセルへの入出力はマクロを使っています。 マクロはさらにER/Studioのほぼすべての機能を操ることができるので、オートメーション化もできます。
- このような便利な機能が「盛りだくさんではありますが、エンバカデロの開発ツールを使っている皆さんでも このツールの存在を知らなかった方はいらっしゃるかと思います。
現在使っているDelphiやC+は信用できても、このツールかどうか、ということですね。
では、その信頼度のあかし、証明も、今回は事例でご紹介します。
このデータモデリングツールは
エンバカデロ最大の競争相手、ともいえるこの会社がつかっています。
- 問題は各ユニットが自律的に動いて独自作成していて連携が妨げられていたんですね。
データ活用のためには起動としての出たモデルが必要。 通常このお客様は自社ソフトを使うこと優先なさるそうなんですが、
よりプロフェッショナルな専用ツールを求められて利用されたのです
- 競合が、これはUSの例ですけど、つかっている。 これはすごいことですね 。
- データベース設計は品質の要。モデリング、設計の工程は特に品質良く作らないといけない と言っている。
データベース設計を重要視している企業さんも使っています。しかも1000ラ位センス規模でう。
業務上で設計するだけでなく、これを使って研修・教育する徹底ぶりであります。
- それが、日本最大級規模のシステムインテグレーターさんのさNTT Dataさん。
彼らもんも驚くほど使っています。
この写真、データモデルの教育としてもつかわれているんですね。
- データモデリングツールで既存のデータベースを可視化しました
その結果、システム連携のデー構造が把握できて連携に役立ちました。
ドキュメントの生成ができますので、いつでも。ドキュメントは面倒なものですが、これがあっという間に。
データ構造の再利用も、一貫性の確保も促進できるということでありました。
もうおわかりですよね。つまり、ボトムアップによるデータモデリング、システム開発の現場においても、利用価値があります。
ツールを使う皆様においては時短・工数削減に。 早く帰っていっぱいやる時間が増えるかも知れません。
管理する皆様においては、工数、つまりお金の削減につながります。
