データ入出力


データ変換(1)

  • Name
    データ変換
    Type
    Description
    • システムに蓄積されているデータを抽出して新しく開発したシステムで運用できるように変換し、読み込むプロセス
    • 抽出: Extraction, 変換: Transformation, 読み込み: Loading
    • データ移行またはデータ転送とも呼ばれる
  • Name
    データ変換計画書
    Type
    Description
    • データ変換が必要な対象を分析し、データ変換作業に必要なすべての計画を記録する文書
데이터 전환

データ検証(2)

  • Name
    データ検証
    Type
    Description
    • データ変換プロセスが正しく実行されたかどうかを確認するプロセス
    • データ検証は、検証方法検証段階に分類できます。
  • Name
    検証方法
    Type
    Description
    • ログ検証: データ変換プロセスで生成される抽出、変換、読み込みログを検証
    • 基本項目検証: ログ検証以外に要求された個別の検証項目を検証
    • アプリケーション検証: アプリケーションを通じたデータ変換の整合性検証
    • アプリケーションデータ検証: 事前定義された業務ルールに基づいてデータ変換の整合性を検証
    • 値検証: 数値項目の合計検証、コードデータの範囲検証、属性変更による値検証を実施
  • Name
    検証段階
    Type
    Description
    • 抽出: 元のシステムデータの整合性確認(ログ検証)
    • 変換: 定義書に記載された内容が正確に反映されたかを確認(ログ検証)
    • DB読み込み: SAMファイルを読み込むプロセス中に発生するエラーやデータの欠落を確認(ログ検証)
    • DB読み込み後: 読み込み完了の整合性確認(基本項目検証)
    • 変換完了後: 検証プロセスを通じてデータ変換の整合性を確認(アプリケーション検証、アプリケーションデータ検証)
데이터 검증

エラーデータの計測とクレンジング(3)

  • Name
    エラーデータの計測とクレンジング
    Type
    Description
    • 高品質なデータの運用と管理

    進行過程

    1. データ品質分析: エラーデータを見つけるために、データの整合性を確認する作業
    2. エラーデータの計測: データとエラーデータの数を計測し、エラー管理リストを作成
    3. エラーデータのクレンジング: エラー管理リストの各項目を分析し、元のデータを定義したり変換プログラムを修正する
  • Name
    エラー状態
    Type
    Description
    • オープン: エラーが報告され、分析されていない状態
    • アサイン: エラーの影響分析と修正のために、開発者にエラーが伝えられた状態
    • フィックス: 開発者がエラーを修正した状態
    • クローズド: 修正されたエラーに対してテストが再実行され、エラーが見つからなかった状態
    • ディファード: エラーの修正が延期された状態
    • クラシファイド: エラーを確認し、実際にはエラーではないと確認された状態
  • Name
    データクレンジング要求書
    Type
    Description
    • データクレンジングに関連する全体的な内容を文書化したもの
    • エラー管理リストを基にしてデータクレンジング要件リストを作成し、リストの項目ごとにデータクレンジング要求書を作成します。
  • Name
    データクレンジングレポート
    Type
    Description
    • クレンジングされた元データが正常にクレンジングされたかを確認した結果を文書化したもの
오류 데이터 측정 및 정제

データベース概要(4)

  • Name
    データの保存庫
    Type
    Description
    • データを論理的な構造に整理したり、物理的な領域に構築したりしたもの
    • 論理データ保存庫: データとその関連性、制約条件を特定し、論理的な構造に整理したもの
    • 物理データ保存庫: 論理データ保存庫をソフトウェアが動作する環境の物理的特性を考慮して実際の記憶装置に保存したもの
  • Name
    データベース
    Type
    Description

    共同で使用されるデータを重複を排除して統合し、簡単にアクセスして処理できるように記憶装置に保存して常に利用できるように運用される運用データ

    • 統合されたデータ: データの重複を排除したデータの集合
    • 保存されたデータ: コンピュータがアクセスできる保存媒体に保存されたデータ
    • 運用データ: 組織の固有の業務を実行するために必要なデータ
    • 共有データ: 複数のアプリケーションシステムが共有し、維持するデータ
  • Name
    DBMS
    Type
    Description
    • ユーザーの要求に従って情報を生成し、データベースを管理するソフトウェア
    • 既存のファイルシステムが持つデータの依存性と重複性の問題を解決するために提案されたシステム

    必須機能 3つ

    1. 定義機能: データのタイプと構造の定義、使用方法、制約条件を示す機能
    2. 操作機能: データの検索、更新、削除、挿入などのためのインターフェースを提供する機能
    3. 制御機能: データの整合性、セキュリティ、権限、制御を提供する機能
  • Name
    データの独立性
    Type
    Description
    • 論理的独立性と物理的独立性がある。

    論理的独立性: アプリケーションプログラムとデータベースを独立させ、データの論理的構造を変更してもアプリケーションプログラムは影響を受けない 物理的独立性: アプリケーションプログラムと補助記憶装置などの物理的デバイスを独立させ、ディスクを追加/変更してもアプリケーションプログラムは影響を受けない

  • Name
    スキーマ
    Type
    Description
    • データベースの構造と制約条件に関する全般的な仕様を記述したもの

    外部スキーマ: ユーザーやアプリケーションプログラマーがそれぞれの立場で必要とするデータベースの論理的構造を定義したもの 概念スキーマ: データベース全体の論理的構造 内部スキーマ: 物理的な記憶装置の観点から見たデータベースの構造

데이터베이스 개요

データベース設計(5)

  • Name
    データベース設計
    Type
    Description
    • ユーザーの要求を分析し、それをコンピュータに保存できるデータベースの構造に変換し、DBMSを使用して一般ユーザーが利用できるようにすること
  • Name
    データベース設計時の考慮事項
    Type
    Description
    • 完全性: 挿入、削除、更新などの操作後、データベースに保存されたデータが定められた制約条件を常に満たす必要がある
    • 一貫性: データは特定のクエリに対して一貫性がある必要がある
    • 回復性: システム障害後に復旧した場合、データは元と同じである必要がある
    • セキュリティ: 保護 - 効率性: 応答時間の短縮、生産性、スペースの最適化など
    • 拡張性: データを継続的に追加できる必要がある
  • Name
    データベース設計手順
    Type
    Description
    1. 要求条件の分析: 要求条件仕様書の作成(データベース利用者の必要な用途を把握)
    2. 概念設計: 概念スキーマ、トランザクションモデリング、E-Rモデル(現実世界の認識を抽象的な概念で表現するプロセス)
    3. 論理設計: DBMSに適した論理スキーマの設計、トランザクションインターフェースの設計(特定のDBMSがサポートする論理的データ構造に変換するプロセス)
    4. 物理設計: DBMSに適した物理的構造のデータに変換(論理的構造で表現されたデータを物理的な構造のデータに変換するプロセス)
    5. 実装: DBMSのデータベース作成、トランザクションの記述(論理設計と物理設計から導かれたデータベーススキーマをファイルとして生成するプロセス)