---------------------------------------------------------------------

（データベースの設計について）

---------------------------------------------------------------------

---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
１． システムの概要と特徴
---------------------------------------------------------------------
１−１．システムの概要
----
　当社は、システムの受託開発を主に手がける中堅のソ
フトウエア開発会社である。私は、当社の販売管理シス
テムの再構築プロジェクトに基本設計・詳細設計を担当
するアプリケーションエンジニアとして参画した。
　当社の売上形態の特徴は、１つの取引先に対して複数
の業務が発生し、その業務を担当する人員ごとに売上を
計上する。旧システムは、８年前にオフコン上に構築さ
れおり、新規取引先や業務の登録および各業務ごとの売
上・入金情報を経理部門が一括して入力し、必要な集計
帳票を出力していた。
　新システムは、今まで経理部門が一括で入力していた
各種情報を現場部門から分散入力させることを重要な課
題として新規構築されることとなった。新システムは、
データベースにリレーショナルデータベース、現場部門
からのデータ入力にはＷｅｂブラウザを使用し、通信媒
体にインターネットを用いて取引先・業務・売上・仕入
の各情報を入力できるシステムにすることとなった。
----
１−２．データベース設計の観点から見た特徴
----
　新システムは、旧システムからほぼ全てのデータを移
行する必要があった。しかし、旧システムは理想的な
データの正規化がされていなかったため、データ移行の
ためにある程度のプログラム作成は予想していたが、
データベース設計についても、ある程度，旧システムの
構造を引き継がざるを得ないと予想していた。また、旧
システムは、人事や給与システムとデータ交換を行って
おり、新システムもそれが求められた。したがって、他
システムと共通するコード（部門や取引先コードなど）
については、コード体系の変更は許されなかった。

---------------------------------------------------------------------
（設問イ）
---------------------------------------------------------------------
 ２． データベース設計時に起こった問題と解決方法
---------------------------------------------------------------------
　データベース設計時に起こった問題とその解決方法に
ついて以降に記述する。

a. 厳密な正規化が行えない

　旧システムのデータ構造を参考にしてデータベース設
計を進めていくうちに、旧システムではデータの正規化
が充分に行われていない点に気が付いた。具体例をあげ
ると、業務ごとの毎月の売掛金残高を管理するファイル
は、業務コードと当月の年月が主キーである。そのレ
コードに、業務が発生した時点で既に決まっているはず
の取引先コードが入っており、１つしかない関係である
業務と取引先をいくつものテーブルで定義することにな
り、このままデータ移行を行うと、矛盾したデータを許
すテーブル構造となってしまう点に気づいた。新システ
ムは今後更に拡張が予定されており、現時点で矛盾のな
いデータベースにしておかなければ、今後の拡張に影響
を与える可能性があった。
　この対策として、旧システムのデータを機械的に移行
するのではなく、専用のプログラムを準備して一次的に
データを加工してから新システムのデータベースに実装
する方法を取った。その結果、新システムのテーブルは、
旧システムの影響を最小限にして正規化した形で設計す
ることができた。

b.　コードの一部に持つ意味の外部データ化

　旧システムは、各種コードの一部分に意味を持たせて
管理しているが，コードは他システムとの関係上、変更
できないことが担当者の話からわかった。具体例をあげ
ると、業務コードは７桁で構成されているが、先頭から
２桁は営業拠点を意味するコードであり、各部署ごとに
付与される部門コードの先頭２桁も同様のコードである
ことがわかった。旧システムは、プログラムがこれらの
コードを分解して意味を解析し、集計や並び替えを行っ
ている。こように、コードの一部に意味を持たせてしま
うと，帳票作成や集計を行うＳＱＬが複雑化し、開発効
率およびシステムの保守性が低下する恐れがあった。
　この対策として、新システムでは各種コードの一部に
意味を持たせることをやめることにした。その代わりに、
拠点コードなどのコードの一部に隠れていた意味を持つ
別のカラムをテーブルに追加することにした。

c. 　機能変更によるテーブル設計の変更

　本開発は、旧システムの機能仕様書などの資料がほと
んど残っていなかったことや、開発を札幌で行い、旧シ
ステムは東京で稼動していたために、システムの機能を
調査する時間が充分取れなかったことから、後工程に
なって漏れている機能が発覚し、テーブル構造の変更が
度々発生した。それに伴い、データベース設計書の修正
やテーブルの再定義が発生した。この点から、最初に設
計したデータベース仕様が変更されることが多くなり、
仕様書とデータベースが一致しなくなる恐れがあった。
　この対策として、テーブル設計書の電子ファイルから
テーブル定義ＳＱＬを作成するプログラム（表計算ソフ
トのマクロ）を作成した。これに加え、開発担当者に対
し、電子ファイルを修正し、マクロにより作成したＳＱ
Ｌでテーブル定義を行う運用を厳格に守らせることにし
た。その結果、仕様書と実際のデータベースが常に同期
が取れていることになり、データベースの変更を検討す
る時などに時間の節約になった。

---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
３． データベース設計に対する評価と今後の課題
---------------------------------------------------------------------
３−１．今回のデータベース設計に対する評価
----
　２章に述べた工夫をしながらデータベース設計を行っ
た結果、正規化されていないデータベースから正規化さ
れたデータベースへ移行するという問題を解決すること
ができた。しかし、データ移行プログラムの作成に予想
以上の開発工数がかかってしまったため、システムの開
発工数が増大し、運用開始の時期も１ヶ月遅れることと
なったが、後に残す資産を理想的なものにするという私
の意見を経理担当者や上司が理解してくれたため、理想
的なデータベース設計を行うことができた。
　また、テーブル定義ＳＱＬを設計書から作成するマク
ロの使用を徹底した結果、仕様書とデータベースが常に
同期が取れた状態で開発作業を行うことができた。今ま
での開発では、テーブルに変更を加えた場合、テーブル
定義ＳＱＬは修正するものの、ドキュメント修正は後回
しなる傾向があり、カラムの意味が開発者全体に伝わら
ない結果、テーブルに似たような意味のカラムが追加さ
れていくことが見受けられた。今回のプロジェクトでは
仕様書をもとにテーブルの拡張を検討することができた
ため、無駄なカラムの追加を抑えることができたと思っ
ている。
----
３−２．今後の課題
----
　本開発業務から得られた今後の課題について以降に記
述する。

a.　データ移行についての作業量見積
　３−１章でも述べたとおり、新システムにおいては正
規化したデータベースとするため、データ移行に予想以
上の工数がかかった。今後は、事前に移行対象のデータ
の分析やデータ移行の作業工数を適正に見積もれるよう
に改善したい。

b.　テーブル以外のデータベースオブジェクトの管理
　今回、テーブルのドキュメント管理は成功したものの、
ビュー（仮想表）に関しては電子ファイルから定義ＳＱ
Ｌを作成するマクロを作成しなかったため、管理が野放
しになってしまった。この点についても今後改善してい
きたい。