会話による ソフトウェア工学の開発実践13 - データベース設計

単語

ポイント

• システムの性格によると思います。 → 我认为这取决于系统的性质。

• メンテナンスには役立つと思います。 → 我认为对维护有效果。

• 以下のことを念頭においてほしいです。 → 希望大家记住以下几点。

• 成果物をゴールとして作業をお願いします。 → 请以成果物为目标来工作。

• 皆：ご苦労様でした。

会話

会話の背景

• 詳細設計のもう1つ重要な作業はデータベース設計である。
• データベース設計の目的は永続的なオブジェクトをどういう風にデータベースに格納したり、アクセスしたりするかを決定することである。そのため、データベースのスキーマ、あるいはテーブルおよび項目やタイプの定義、テーブル間の関係、テーブルの正規化、および検証ルールなどを検討しなければならない。

登場人物

• 鈴木：開発チームリーダー
  山田、田中：開発チームメンバー

会話内容

• 鈴木：

  • おはようございます。
  • 今日はデータベースの設計について、これからの作業をどう展開するかを話したいです。

• 田中：

  • 現時点ではクラス設計が終わったところで、ここまで、我々は大抵データベース設計を後回しにしましたが、今ではもう遅いのではないでしょうか？

• 鈴木：

  • 詳細設計ではクラス設計とデータベース設計両方とも不可欠な部分です。どちらを先にするかはシステムの性格によると思います。
  • 一般的に言うと、もし帳票や入力、また照会が多いシステムならば、データベースの設計が先行した方がいいかもしれません。一方、ビジネスロジックが複雑な場合はおそらくクラス設計を先にしたほうがいいと思います。実はどちらにしても、相互の関係があるので、ある程度くると、並行的にまた反復的に改訂されていくと思います。

• 田中：

  • そうすると、今できたクラス設計の中のエンティティクラスをテーブルの候補と考えればいいでしょうか？

• 鈴木：

  • 基本的にはそうです。ここでは、判断の条件はそのエンティティクラスが永続的なものであるかどうか。それに基づいて論理データモデルが設計できます。言い換えると、1つの永続的なエンティティクラスを1つのテーブルに対応させます。

• 山田：

  • それで、クラスの属性とテーブルの項目およびそのタイプをどうすればいいでしょうか？

• 鈴木：

  • 我々が設計したクラスはオブジェクトの世界で、データベースはリレーショナルの世界なので、その間をまったく同じようにマッピングするわけではありません。たとえば、Javaでは、Stringというタイプがありますが、データベースに対応すると、そのタイプはおそらくCharまたVarCharになると思います。
  • また、クラスの一部の属性は構成できる属性であることがあります。それらはデータベースに反映しなくてもいいです。たとえば、年齢というものが生年月日から構成できます。これはクラス設計上でおそらくビジネスからの理由でこの構成属性を持つ必要があるが、それをデータベースにもわざわざ項目として作る必要はほとんどありません。

• 山田：

  • そうですか。
  • それと、クラスの関係、例えば汎化関係や1対mまたm対nの関係などをどうすればよろしいでしょうか？

• 鈴木：

  • それはリレーショナルデータベースの正規化にもかかわっているかもしれません。
  • まず、リレーショナルデータベースなので、主キーの候補を考えないといけない。それを考えると、例えば、汎化関係の場合は、同じ主キーを持つ場合は、汎化関係にあるクラスはスーパークラスとサブクラスがあるが、サブクラスの属性をスーパークラスの属性と合わせて一つのテーブルの項目にすることもあるし、また別々のテーブルにする可能性もあります。
  • また、1対mの関係を持つクラスに対しては、大抵普通のテーブルで設計すればいいでしょう。m対nの場合はほとんど関係付けための1つテーブルを追加した方がいいと思います。とにかく、関係を反映するため、必要に応じて新たな主キーや外部キーを作ることは度々あります。

• 山田：

  • そうですか。

• 鈴木：

  • それと、今回設計するシステムは外部システムからデータを読み出すことがあります。あれは、外部システムのテーブルより落としてもらうものですから、直接使うといろいろな不便があるかもしれません。そのときには、ストアドプロシージャによりビューを作ることが必要になります。それらのビューの設計も今回データベース設計の一部になると思います。

• 田中：

  • 分かりました。ビューの設計もちゃんとやりますから。
  • ところで、最近ORMという言葉をよく耳にしますが、あれもデータベース設計にも関係あるのでしょうか？

• 鈴木：

  • ORMとはObject‐Relational Mappingの略で、これはオブジェクト世界とリレーショナル世界とうまくマッピングすることで、コーディングに生産性を上げる方法論とツールです。本来はプログラミングと直接関連していますが、データベースの設計にはあまり関係ありません。
  • といっても、今のORMツールはクラスからテーブルへ、またテーブルからクラスへの連動ができていますので、我々が設計したデータベースがある程度定まってから、ORMツールを導入すれば、これからの微調整やメンテナンスには役立つと思います。

• 山田：

  • 最後に、今回の成果物はどうなるでしょうか？

• 鈴木：

  • 今回のデータベース設計には、以下のことを念頭においてほしいです。
  • まずは、もちろんテーブルのスキーマです。そのスキーマとはテーブルの各項目の名前、タイプ、サイズ、主キー、外部キー、また空にできるかどうかなどを記述すべきです。
  • テーブル間の関係はツールを使って、E-R図を書く必要があります。
  • また、もし画面ごとに、入力のために検証することがある場合は、これらはほとんどテーブルの項目と対応していますので、ぜひその検証ルールを記述してください。
  • 最後の最後、まだ早いかもしれませんが、テスティングのことを考えると、サンプルデータを準備する時には、データベースの定義の正しさが再び検証され、矛盾などを検出することもできると思いますから。

• 皆：

  • 分かりました。

• 鈴木：

  • そうでしたら、さっき言った成果物をゴールとして作業をお願いします。
  • 今日のミーティングはここまでで終わらせましょう。
  • 皆さん、ご苦労様でした。

• 皆：

  • ご苦労様でした。

× WZhong

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →