モジュール単位のプログラムを組む上では、データやシステムについて考慮することは少ないと思います。
ただ、これがシステム全体となってくると、データ抜きで工程を進めることは極めて困難となるでしょう。ファイルであれデータベースであれ、システムにデータは不可欠です。
そこで、考えるべき事柄が出てきます。
システム開発において、データベース設計を先に行うべきか？
それとも、プログラムを先に組んでしまうべきか？
この記事では、その答えに迫っていきます。
POA：まずプログラムから入るアプローチ
システムを構築するにあたり、先にプロセス（処理のこと、つまりプログラム）から入る考え方をプロセス中心アプローチ（Process Oriented Approach : POA）といいます。
ようは、先にプログラムを組んでしまい、それに基づいてデータベース設計を進めていく方式ですね。システムを組み立てるということは「プログラムを書く」ことと同じ意味といえますから、プログラムから先に入ることは直感的でいたって自然なように思いますよね。
DOA：まずデータベースを先に設計するアプローチ
一方、先にプログラムを組み立てることはせずに、データベース設計から入る考え方をデータ中心アプローチ（Data Oriented Approach : DOA）といいます。こちらは先にデータベース設計を進めそれに基づいてプログラムを組んでいく方式です。
プログラムを組むのに、どうして先にデータについて考えなければならないのか。こちらはいささか不自然な感じがしますよね。
で、POAとDOAはどっちがいいの？
以降、プロセス中心アプローチを「POA」、データ中心アプローチを「DOA」とします。
ここまで「POAが自然な方法でDOAは不自然だ」といったことを書いてきましたが、現在においてはDOAが主流です。POAが採用されるケースはごく少ないと言われています。
わたしもこの２つのアプローチについて知るまでは、先にプログラムを組んでいました（特に初心者のころ）。業務においてはごく一部の機能しか触っていなかった上開発よりも不具合修正の方が多かったため、実務でPOAやDOAについて考慮する機会はありませんでした。
しかし、今では小規模であれシステムを組む際には必ずデータベース設計を行ってからプログラムを組んでいます。というよりそうしないと上手く組めません。
しかし、なぜデータベース設計から先に行った方がいいのでしょうか？
POAでは「変化」に柔軟に対応できない
これはどの業界においてもいえることかもしれませんが、業務内容の変更は頻繁に発生します。もし業務システム等を利用していれば、業務内容の変更に伴いシステムの仕様も変わることになるでしょう。
そうした場合、そのシステムそのもの、つまりプログラムを修正することになりますよね。もしシステムをプロセス中心でかっちり組んでしまっていたら、変更による影響範囲は広くなるかもしれません。なぜならそのシステムはプロセスそのものに依存して組み立てられているわけですから。
そして、もしプログラム単位でデータ設計を行うとするなら、それは複数のプログラムで同じデータをそれぞれ持つことになるでしょう。これではそのシステムは余分なデータを持つことになってしまいます。
プログラムにおいて冗長であることは避けるべきことです。
DOAなら「変化」に柔軟に対応できる
一方、データの方はどうでしょうか？
データはプログラムとは異なり、よほど変化することはありません。データの内容は日々追加されたり更新されたり、削除されることもありますが、データの形式や種類が勝手に変わることはありません。
そこで、あらかじめシステムに必要なデータの形式や種類を挙げて適切に設計しておけば、業務や使用の変化に柔軟に対応できるようになるというわけです。
ほぼ不変である「データ」に基づいてプログラムを組んでいけば、もし仕様変更が発生したり業務手順などが変わってしまったとしても、柔軟に対応することができます。
データベース設計はシステム開発の「かなめ」
以上より、システム開発については次のようなことがいえそうです。
データベース設計こそシステム開発の要（かなめ）である
変化に柔軟に対応でき、なおかつ冗長性もない高品質なシステムを造り上げる上では、データベース設計を先に行うことはとても重要なことだといえます。
システムの大小にかかわらず何かをプログラミングする際には、まずは必要なデータを挙げていくことから始めてみるといいでしょう。
それでは今回は以上です。
最後までお付き合いいただきありがとうございます。