文書ドリブン開発 DB設計文書編
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 システム開発プロジェクトにて作成される文書にフォーカスしての連載の第3回です。今回はDB（データベース）設計文書について考えたいと思います。なお、以下は筆者の私見であることをあらかじめおことわりしておきます。また、特に指定のない場合、本稿で指すDBとはRDBのことです。 高いプレッシャーと闘うDB設計者 大半のシステム開発プロジェクトには、DB設計者としての役割を持つ方が専任・兼任の差はあれアサインされていると思います。わたしが考えるに、DB設計者は中堅からベテランのSEが担当されているケースが大半です。これはシステム開発においてDB設計の難解さと重要さが認識されているためですが、DB設計者の立場というのはその責任の重さの割には軽視されていると思える
基本設計で作るべき「論理データモデル」の考え方
データモデリング作業の大きな流れ システム企画段階で作成した「概念データモデル」は、ビジネス活動を販売、製造などの機能分野単位で大きくとらえ、ER図で表現したものでした。データの視点で俯瞰（ふかん）的にビジネス活動をとらえることにより、企業が管理すべきデータが明確になります。販売機能分野における、販売計画から販売管理までなど、ビジネス活動のつながりも、データの視点で可視化することでシステム化対象範囲を確定することができました。次はこの「概念データモデル」をベースにデータモデリングを行っていきます。 一般的にデータモデリングは、論理データベース設計、物理データベース設計、データベース適用設計という流れで進めます。それぞれの設計段階で行うことを簡単に述べると、「データ整理」「データ調節」「データ実装準備」になります。 論理データベース設計（データ整理）： 管理対象となるデータを洗い出し、整理し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
