情報システム開発論

外部設計-3

学修内容

  • ファイルの論理設計の手順
  • データベースの論理設計

ファイルの論理設計

ファイル設計

  • ファイル
    • 内部で蓄積されている情報
    • データ処理にはほとんどファイルが存在

ファイルの論理設計の要件

  • ファイルの使用目的の明確化
  • ファイルの項目の明確化

ファイルの論理設計の手順

  1. 対象データの洗い出し
  2. 情報のファイル化
    • 将来的な拡張を考慮する必要
    1. ファイルの性格の検討
      • ファイル名称
      • 作成目的
      • ファイルの種別
      • 適用業務
    2. 項目の検討
      • 情報量
      • 項目名
  3. 対象業務の調査
    • 処理形態
      • 参照
      • 更新
      • 追加/削除
    • 更新形態と移動性
    • 処理サイクル
  4. 入出力データとの関連性の検討
  5. ファイルに必要な項目とファイル論理構造の決定
    • ファイル論理仕様
      • ファイル名
      • 目的
      • 種別
      • 適用業務(システム名)
      • データ件数
      • 処理形態
      • 更新形態
      • 処理サイクル
      • 項目番号
      • データ項目名
      • 項目の内容説明

データベースの論理設計

論理設計の手順

  • 一元管理してデータ更新に対し整合性を保つ。
  • 稼働率を上げ,無駄のない媒体管理を行うため極力共有化を図る。
  • アクセスに柔軟性を持たせる。
    • 処理手続き中心の設計技法に対してデータ中心アプローチ(DOA)の設計技法が優れている。
      • 但し,冗長性が高くなる。
  • 広い視点からの業務分析が必要
    1. 全社的なデータの流れを分析・把握
    2. 目的のシステムのデータ構造構築
  1. データ項目の洗い出し
    • データ分析中心の設計
  2. エンティティ分析
    • エンティティ
      • 一般性を持つよう抽象化したもの
    • 洗い出したデータ項目が何というエンティティの属性であるかを検討。
    • エンティティの候補を挙げ,エンティティ関連図にまとめる。
  3. 正規化
    • エンティティの構造を単純化し,データ更新に強いデータ構造を設計する。
    • 第1正規形
      • 繰り返しのあるデータ構造(非正規形)から,繰り返しを排除したもの。
      • それぞれの行を識別するデータ項目(キー)が必要
    • 第2正規形
      • キー以外の全てのデータ項目がキー全体に従属(完全従属)
    • 第3正規形
      • 推移従属を取り除いたもの。
  4. データ構造の補正
    • 代表的な処理を前提に,処理効率等を検討しておく。
      • 第3正規化を厳格に適用するとレスポンスが悪化する。
      • データ構造の補正(逆正規化)が必要。

論理設計の文書化

  • E-R図
  • エンティティ定義書
    • 正規化の最終形で記述。
    • エンティティ毎に属性を記述。
  • データ項目辞書
    • データ項目名は組織内で標準化しておく。
      • 徹底することが重要。
    • データ項目名とその定義,利用分野等を記述。
    • ツール
      • DD(Data Dictionary)

外部設計書

  1. システム概要
    • 新適用業務フロー
    • システム構成図
    • サブシステム定義書
  2. 入出力設計
    • 画面遷移図
    • 画面レイアウト
    • 出力要件仕様
    • 出力項目仕様
  3. コード設計
    • コード仕様
  4. ファイル設計
    • ファイル論理仕様

トップ   編集 凍結解除 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-10-25 (水) 11:43:19 (4795d)