忍者ブログ
[PR]
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。


2019/10/15 15:05 |
設計の失敗:データベースの関連を纏めずに開発した時に起きる不幸
こんにちは! @nekoasukaです。

設計で失敗した時の事も纏めておこうと思い、今回のエントリへ落とします。

今回は、

データベースの関連を纏めずに開発したら何が起きるのか

についてです。

まとめに入る前に、背景について補足します。

  • 業務系ソフトウェアが開発対象である
  • 複数名で外部設計を担当している(担当は機能ごとに分割されている)
  • 3層環境で動作するアプリケーションである
  • リレーショナル・データベースを利用している
  • マスタデータ(※1)とトランザクションデータ(※2)とが別管理されている

ウォーターフォール型の開発手順に則り、
要件定義→外部設計(基本設計)→内部設計(詳細設計)→開発
と進む中、【外部設計】の段階でデータベースに保存するデータの構造を決定します。

この時、「機能に紐付けて、特定のテーブルの構造のみを設計書へ記述」を進めていた頃から、不幸は始まります。

機能に紐付けて作成された設計書のそれぞれは、「その設計書の中では」整合性が取れた状態で済んでいました。

しかし、時が経つにつれて徐々に設計のほつれが明らかになりました。

  • 期待したデータが対象の項目に保存されない
  • 特定条件を満たすデータの件数が、想定していた件数と異なる
  • 検索を想定していたテーブルとは別のテーブルに情報が保存されている

といった具合に。

上記のような現象が発生した理由を考えてみました。

  • 複数の外部設計担当者が読み書きするテーブルが多数あった
  • データベースの関連を表す資料が存在しなかった
  • 各機能やデータ構造について、充分考察できる時間が用意されていなかった

業務の流れに沿って、業務の担当者が切り替わるタイミングなどに合わせてテーブルが切られています。
その都合上、機能を横断するテーブルが多数存在します。
機能ごとに区切って外部設計の担当者が割り当てられているため、複数名が同じテーブルの構造について考察する環境が頻発しました。

また、各外部設計書を横断するような、テーブルの構造を示す資料がありませんでした。
そのため、担当者間の設計思想が共有されづらい状況にありました。
※もちろん、担当者間で相談をしながら進めましたが、限度がありました。

更に、よくある話ですが、「納期」が重たい錨として降ろされており、人も少ない状況での設計でした。
自身の設計力のなさを嘆きつつ、「個人の担当範囲においてはおおよそ整合性が取れている」という状況にするので手一杯でした。
他の設計者の方も、精度の個人差はあれ、似た状況で開発フェーズを迎えました。

開発の途中、データベースの関連図をいよいよ作ろうという話が上がり、作成に踏み切りました。
すると、ぽろぽろと音を立てて、積み上げたデータベースの穴が、乱雑に配置されたテーブルの中から見えて来ました。
「一枚の絵を囲んで設計者間で議論」をし、穴がなくなるように改造をしていきました。

「一枚の絵」(※3)を書き始めたことで、データの整合については、鎮火の兆しが見えました。

以上が、データベースの関連を纏めずに開発した時に起きる不幸と、その回避の一策です。
僅かながらの備忘録として。


※1 マスタデータ
ソフトウェア全体に対して、動作を制御したり、情報を整理したりする場合に用いるデータの総称。
変更の少ない情報を取りまとめる事が多い。
例) ログインユーザの情報、企業の情報、取り扱う商品の情報など

※2 トランザクションデータ
ソフトウェアの機能が動作する上で、機能の動作途中や、ユーザの操作によって発生するデータの総称。
変更や新規発生の多い情報を取りまとめる事が多い。
例) 商品の発送状況、商品購入履歴、ユーザー投稿コメントなど

※3 一枚の絵
通称ER図。
テーブル間で、データがどのように結びつくかを表現する図。
各テーブルの主キーとその他、テーブル間のデータが1:1なのか、1:nなのかなどの関連を示す図。
今回のプロジェクトでは、特殊な外部結合の条件なども色で結びつけて、表現してみました。
PR

2013/08/04 23:20 | Comments(0) | アーキテクト

コメント

コメントを投稿する






Vodafone絵文字 i-mode絵文字 Ezweb絵文字 (絵文字)



| HOME | 読書録:峡谷に橋を架けるために>>
忍者ブログ[PR]