真のデータベースエンジニアを目指そう！：データベースエンジニアへの道（1）（2/3 ページ）

本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する（編集局）

[阿尾操, 下平浩由，アクセンチュア・テクノロジー・ソリューションズ]

データベースエンジニアに求められるスキルとは？

　データベースエンジニアのタスクは、大きく分けると「設計・構築（データとデータベースが対象）」「運用設計（データベースを存続させるための実装寄りの設計）」「保守・運用」の3つのフェイズがあります（図1）。各フェイズともさまざまなスキルが要求されますが、本連載では設計・構築フェイズにフォーカスします。

　設計フェイズはさらに、概念設計、論理設計、物理設計から成り、各設計フェイズのアウトプットとして「データモデル」が作成されます。このデータモデルを作成する「データモデリング」がデータベースエンジニアの中心的な作業になります。

　役割別に見ると、DAは実世界の情報を分析し業務領域全体を表現する「概念データモデル」と、システム化領域を表現する「論理データモデル」を作成します。これには、対象となる業界の業務知識とそれをモデリングするスキルが必要となるため多くの場合、DAはある業界・業務領域に特化し、得意とする業界・業務領域をいくつか持っています。

　一方、DBAは、「論理データモデル」を基に、実装するデータベース製品に合わせた物理データモデルを作成します。これには、論理データモデルの理解に必要な業務スキル、モデリングスキルに加えて、実装するデータベース製品の深いスキルが必要となります。多くの場合、DBAはデータベース製品特化型の職種で、得意とするデータベース製品をいくつか持っています。

　両者は、データモデリングという共通のスキルを持ち、DAは業務領域に、DBAはデータベース実装に特化した高度なスキルを持つスペシャリストです（図2）。

図2　データベースエンジニアのスキル

　データベースエンジニアを目指すなら、まず共通のスキルであるデータモデリングを学び、徐々に業務領域やデータベース製品といった特化スキルの充実を図るのがいいでしょう。データモデリングと一言でいってもその中には多く作業があり、必要なスキルもさまざまです。本連載ではその中から、業務への即効性が期待でき、職場や自宅で実践しながら理解できるトピックを選んで紹介していきます。

　本連載は、以下のような構成となります。

連載回	タイトル
第1回	真のデータベースエンジニアを目指そう！（今回）
第2回	30分間データモデリング 〜ER図を書こう！〜
第3回	素早く正規形を見抜く実践テクニック
第4回	システムの寿命はコードで決まる！
第5回	データへの最短ルートを確保せよ！
第6回	そのデータベース壊せますか？ そして直せますか？

　　　　　　本連載の記事構成

　以降では、概念データモデル、論理データモデル、物理データモデルの各モデルをできるだけ分かりやすく解説しながら、各モデルを作成するためのポイントに触れていきます。

概念データモデル

　概念データモデルでは「対象業務の現実の世界」を対象とし、「データにはどんな意味があるのか？」という視点から、意味的な集まりを見いだすことでグループ化、およびグループ間の関連付けを行い、概念データモデルを作っていきます。

　実際には「ユーザーからの要求」や「既存システムの画面や帳票」などから「データ項目」を洗い出し、ここではアプリケーションの範囲やシステムの範囲などは気にせず（いい換えれば、コンピュータで記憶されるデータ以外のものも）、業務の中で扱っているデータであれば、細かいデータ項目まですべてを扱います。概念データモデルといっても、決して概念レベルのものを扱っているだけではありません。というのも「既存システムの画面や帳票」から「データ項目」を洗い出すのは、業務機能が変わっても、そこで扱われるデータは継続して利用される場合がほとんどだからです。データ中心で考えるメリットがここにあります。

　「業務の中で扱っているデータであれば」と述べましたが、それは例えば、製造業のシステムを開発することが目的であっても、対象とする製造業のシステム領域だけでなく、業務の中で扱っているデータであれば、ほかの会計システムや生産管理システムもここで扱うデータの対象となるということです。

　この段階から、ほかのシステムとのインターフェイスまで含めた広い範囲のモデルを構築しておくことは重要です。その方法として、「既存システムの画面や帳票」からデータを集めること（ボトムアップ・アプローチ）はもちろん必要ですが、ありのままの姿だけでなく、経営層まで参画させて、企業として将来像（ゴール）を決めていくこと（トップダウン・アプローチ）も必要になってきます。ゴールが決まれば、おのずと必要なデータも見えてくるものです。そもそもデータが安定していても、データのライフサイクルが短いのでは元も子もありません。企業の変革のスピードが速い時代だからこそ、先を見据えた安定的なデータモデルの構築が企業競争力につながるといえるでしょう。

　概念データモデルを描く際には、「ER図（ERD：entity-relationship diagram）」が用いられることが多く、概念データモデルを表現したER図は「概念ER図」と呼ばれます。ER図では、「意味的な集まり」を「エンティティ」と呼び、「グループ間の関連付け」を「リレーションシップ」と呼びます。

Point

• 「対象業務の現実の世界」を対象とする。ここでは、システムの範囲は意識しない。
• 「トップダウン・アプローチ」と「ボトムアップ・アプローチ」で設計を進める。
• 「概念データモデル」は、概念ER図で表すことが多い。