データモデル設計の3ポイント
それではさっそく、データモデルを設計するためのポイントについて紹介しましょう。
先ほど「データモデルは行×列の表形式をベースに考えるのが良い」と説明しましたが、だからといって帳票アプリケーションで使うデータモデルが、何もかもRDBのテーブルと同じ形になるわけではありません。データモデルを設計するときに考えるべきポイントは、ズバリ、以下の3つになります。
- 抽出条件の定義
- フィールドの型を定義
- 並び順の定義
最初の「抽出条件の定義」では、レポートデータソースから読み取るデータの範囲を定義します。データベース帳票の場合は、RDBMSに対して発行するSQL文のWHERE句を指定することで、抽出条件を規定することができます。ファイル帳票の場合はあらかじめ抽出条件に一致するデータだけを含むファイルを用意して、それを読み取ることが多いと思いますが、場合によってはファイル読み取り時に不正なデータをスキップするなどの処理が必要かもしれません。
次の「フィールドの型を定義」では、データモデルの各フィールドがどのようなデータ型になるのかを考えていきます。RDBのテーブルでは、フィールドを定義する列の型として文字列型や数値型、日付・時刻型などのデータ型を利用できますが、ファイル帳票の場合は、（データの読み取り時点では）すべてのデータが文字列として扱われます。データの集計結果を表示する帳票であれば、数値が期待されるフィールドで「aaaa」などの文字が入ってくるとデータを正しく集計することができなくなってしまいます。
最後の「並び順の定義」では、データモデル内の行がどのような順番で並んでいるかを定義します。データベース帳票の場合はRDBMSに対して発行するSQL文のORDER BY句で並び順を定義します。ファイル帳票の場合は、ファイル提供元がどのような順序でデータを並べているかを確認しておけばOKでしょう。万が一データの並び順が保証されていない場合は、帳票アプリケーションで読み込む前に、データを並べ替える処理が必要になるでしょう。ただし、データの並べ替え処理自体は帳票出力の本質ではないため、帳票アプリケーションとは分離しておくのが賢明です。
ここからは、今挙げた3つのポイントについて、気をつけたいポイントをそれぞれ解説します。
抽出条件だけでなく、イレギュラーケースについても考えておこう
帳票アプリケーションのデータモデルを設計するポイントとして、最初に「抽出条件の定義」を挙げました。毎回出力するデータの件数があらかじめ決まっているような場合や、読み込んだデータを全件出力するような場合は特に抽出条件を考える必要は特にありません。しかし、通常は出力するタイミングによってデータの件数は変わると考えるのが自然です。データモデルの定義内容にはまずどのような条件のデータを対象とするのかをはっきり指定しましょう。もし、特に条件がなくすべてのデータが対象となる場合でも、設計意図は明示的に「すべてのデータを対象とする」と記述すべきです。
データモデル側では取り扱うデータの範囲を抽出条件として定義しますが、同時に、帳票レイアウト側でも考えておかなければいけないことがあります。それは「検索結果が0件だったときはどうしたらいいのか」ということです。帳票アプリケーションの開発中はあらかじめ用意したテスト用のデータを繰り返し表示しながら、プログラムを作成していくことが多いのではないかと思います。そうしているとつい、データがないケースについてのテストを忘れてしまいがちです。
抽出条件に合致するデータが得られなかった場合、帳票レイアウトでは特別な項目を表示する必要があるかもしれません。データ全体がゼロ件になるケースはもちろん、グループ単位で該当するデータがゼロ件になったときはどうしたらいいのかについても、漏れなく指定するようにしましょう。
