連載 [第1回] :
即活用!ツールを活用したデータモデリングソフトウェア産業に産業革命を起こすデータモデリング
2006年2月15日(水)
ソフトウェア産業にも"近代化"が必要
日進月歩で技術革新するハードウェア産業や、ドッグイヤーで進化するITビジネスに比べ、ソフトウェア開発の現場はいまだに20〜30年前のやり方と大差がありません。徒弟制度での教育、開発ドキュメントの標準化の遅れ、精神主義がまかり通るプロジェクト管理、そして開発手段も相変わらず昔ながらの家内制手工業です。このような労働集約的なやり方を続けた結果、日本のソフトウェア産業の国際競争力は地をはっています。
「生産性向上」「コスト削減」「品質向上」、これらは製造業における共通課題です。日本のメーカ各社は、この目標を実現するために"カイゼン活動"や"最新設備導入"などの絶え間ない努力を行い、その結果、世界に冠する強さを持つまでにいたっています。
一方、ソフトウェア産業はどうでしょうか。派遣主体の会社には課題認識すら希薄です。また多くの企業にとってこれらの言葉は単なるスローガンであり、具体策が現場に根付いていません。働いた時間だけお金を得るという派遣から成長した業界体質のため、先行投資という決断に抵抗を持つ管理職が実に多いようです。
ソフトウェア産業も製造業のようにもっと"機械化"をはかり、効率的な開発をしなければなりません。開発プロセスを見直し、プロジェクト管理ツールや設計/開発/テストといった開発支援ツールを積極的に評価・導入すべき時代が来ていると思います。
みなさんはER図を描いていますか
本連載のテーマは「ツールを活用したデータモデリング」です。データモデリングといえば、データモデラー(最近はアーキテクトと称すようです)の書いた解説書も多いのですが、そういったものを意識すると教科書的な説明になってしまいます。
本連載では、もっと実践的・現場的・具体的な内容に話を落として説明します。"データモデリング"というよりも"ER図を使ったDB設計"というクリティカルな課題に焦点を当て、それを実現するためのツールの活用法を積極的に取り上げていきます。
先日データベース設計に関するセミナーで講演したのですが、その際に次の2つの質問をして聴衆の方に手を上げてもらいました。
質問1:
「皆さんはテーブル設計する際にER図を描いていますか?」
質問2: 「ER図を描く人は、データモデリングツールを使っていますか?」
質問2: 「ER図を描く人は、データモデリングツールを使っていますか?」
この結果、2割程度の人しかER図を描かないこと、ER図を描いているという人の中でも3割くらいしかツールを使っていないという状況がわかりました。
さて、みなさんはどうでしょう。「ER図を作成していますか?」という質問に対し、「いいえ」と答える人が多いのではないでしょうか。実は、著者自身も以前は「いいえ」と答える流派でしたし、今でもいわゆる概念モデルの作成というモデリング用途では使っていません。
しかし、「RDBMSのテーブル設計のために」という具体的用途で「リバース可能なツールを使う」という前提なら、「Why not?」という回答になります。専用ツールを使ってER図を描くことは、それほど設計作業を効率化するのです。この観点から、本連載のテーマを単なるデータモデリングではなく、ツールを使ったデータモデリングとしているのです。
ER図とは
具体的名モデリングの話に入る前に、まずはデータモデリングの基礎から説明します。ERとはE(エンティティ:実在)とR(リレーション:関連)の略で、エンティティの中には属性(アトリビュート)と呼ばれる付加情報が定義されます。ER図において、エンティティは四角、リレーションは線であらわされ、エンティティの枠内にアトリビュートが記述されます。
図1の例でいえば、「受注」と「顧客」がエンティティであり、その2つのエンティティに関連性があることを線で結んで示しています。そして四角の中にある「受注番号」「顧客番号」「社員番号」などがアトリビュートになります。
エンティティやアトリビュートなどというとなんだか難しそうですが、RDBMSのテーブル設計においては、次のように置き換えてしまえば簡単です。
ER | RDBMS |
---|---|
エンティティ | テーブル |
リレーション | 参照整合性制約 |
アトリビュート | 列名 |
そして、アトリビュートの中で主キーになるものを四角の上部に記載して線で区切ります。エンティティやリレーションにはいくつかの種類があります。これらを使いわけて図示することにより、テーブルの属性とその関連を一目で把握できるのがER図なのです。
概念モデル/論理モデル/物理モデル
データモデリングとは、一般的に「実在する事象をモデル化してデータベース設計に結びつける手法」をいいます。例えば、「顧客から注文を受けて、商品を出荷して売上をあげる」という業務があった場合、この販売業務全体が事象です。
これをモデル化して「受注」「顧客」「商品」「出荷」「出荷先」「売上」などのエンティティに分割し、その関連性を定義して、最終的にはデータベースのテーブル設計につなげるのがデータモデリング作業となります。
データモデリングには、図2のように「概念モデル」「論理モデル」「物理モデル」という3種類のモデルがあります。最初に事象全体の関連を大まかにあらわす「概念モデル」を作成し、次にもう少し詳細な「論理モデル」に落とし込みます。最後に実際のテーブルと1対1関係となる「物理モデル」まで展開して、RDBMSに実装するというのが典型的なアプローチとされています。
連載バックナンバー
Think ITメルマガ会員登録受付中
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。