データモデリング：概念モデル、論理モデル、物理モデル
デビッドカーター
⚡ スマートサマリー
データモデリングは、データベース内のデータオブジェクト間の関係性を構造化された視覚的な設計図として構築し、ルール、命名規則、および整合性を強制します。この資料では、概念レベル、論理レベル、物理レベルの3つのコアレベルについて説明し、各レベルが設計と実装の意思決定をどのように導くかを示します。
データモデリングとは?
データモデリング（データモデリング） データモデルとは、データベースに格納するデータのデータモデルを作成するプロセスです。データモデルは、データオブジェクト、それらのオブジェクト間の関連性、およびそれらを管理するルールを概念的に表現したものです。このようにデータを視覚化することで、チームはテーブルを作成する前に、ビジネスルール、規制遵守、および政府の方針を適用することができます。
データモデルは、命名規則、デフォルト値、意味論、セキュリティの一貫性を確保するとともに、データ全体の品質向上にも貢献します。下の図は、データモデリングの3つの主要レイヤーが、詳細度に応じてどのように連携するかを示しています。
DBMSのデータモデル
その データ・モデル 腹筋tracデータ記述、データ意味論、およびそのデータに適用される一貫性制約を整理するモデル。このモデルは、 何 データが必要であり、 の データモデルは、どのような操作を実行するかではなく、その構造を整理するものであるべきです。データモデルは、建築家が建物の設計図を作成するようなものだと考えてください。データベースが実際に作成されるずっと前に、概念的な構造とデータ項目間の関係性を設定するものです。
データモデリング手法として一般的に使用される表記法は2つあります。
- エンティティ関係 (ER) モデル — 実体、属性、およびそれらの間の関係を図示する図式表記法。
- UML (統一モデリング言語) ―データ構造設計に適したクラス図をサポートする、より広範な視覚言語。
このデータモデリングチュートリアルは、概念層、論理層、物理層について復習が必要な初心者、経験者、およびデータモデリングの初心者の方に最適です。
データモデルを使用する理由
各レイヤーを詳しく見ていく前に、適切なデータモデルがもたらすビジネス上の価値を理解しておくと役立ちます。データモデルを使用する主な目的は以下のとおりです。
- データベースに必要なすべてのデータオブジェクトが正確に表現されていることを保証します。データの欠落は、レポートの誤りや結果の不正確さにつながります。
- 概念レベル、論理レベル、物理レベルにおけるデータベースの設計を支援します。
- データベースに必要なリレーショナルテーブル、主キーと外部キー、およびストアドプロシージャを定義します。
- 基本データを明確に把握できるため、データベース開発者は自信を持って物理データベースを構築できます。
- 欠陥が下流工程に波及する前に、欠落データや重複データを早期に特定するのに役立ちます。
- 初期構築には労力と時間がかかるものの、将来のITインフラのアップグレードやメンテナンスをより安価かつ迅速に行うことができる。
DBMS のデータ モデルの種類
データモデルの種類： データモデルには、概念モデル、論理モデル、物理モデルの3つの主要な種類があり、それぞれに特定の目的があります。これら3つのモデルは、データとその格納方法を記述し、データ項目間の関係を定義します。
- 概念的なデータモデル: 定義する WHAT システムには、ビジネスの概念やルールを整理、範囲設定、定義するために、ビジネス関係者やデータアーキテクトによって作成されるのが一般的です。
- 論理データモデル: 定義する HOW このシステムは、使用するDBMSの種類に関わらず実装されるべきである。通常、データアーキテクトとビジネスアナリストが、ルールとデータ構造の技術的なマップを作成するためにこのシステムを構築する。
- 物理データモデル: 説明 HOW システムは特定のDBMSを使用して実装されます。これは通常、DBAと開発者によって作成され、データベースの実際の実装を表します。
概念データ モデル
A 概念データ モデル 概念データモデルとは、データベースの概念とその関係性を体系的に整理したものです。概念データモデルを作成する目的は、エンティティ、その属性、およびそれらの間の関係性を確立することです。このレベルでは、実際のデータベース構造に関する詳細はほとんど記述されません。通常、この成果物はビジネス関係者とデータアーキテクトが管理します。
概念データモデルの3つの基本原則は以下のとおりです。
- エンティティ： 現実世界の話だ。
- 属性： 実体の特性または性質。
- 関係： 2つの実体間の依存関係または関連性。
データモデルの例:
- 顧客と製品は2つのエンティティです。顧客番号と顧客名は、顧客エンティティの属性です。
- 商品名と価格は、商品エンティティの属性です。
- 販売とは、顧客と製品との間の関係のことである。
概念データモデルの特徴
- 組織全体にわたるビジネスコンセプトの網羅性を提供します。
- ビジネスユーザー向けに設計・開発されました。
- データストレージ容量や設置場所といったハードウェア仕様、およびDBMSベンダーや技術といったソフトウェア仕様とは独立して構築されています。その目的は、ユーザーが「現実世界」で目にするであろうデータを表現することです。
概念データモデル（ドメインモデルとも呼ばれる）は、基本的な概念と範囲を確立することで、すべての関係者にとって共通の語彙を作り出す。
論理データ モデル
その 論理データ モデル データ要素の構造を定義し、それらの間の関係を設定します。概念データモデルの要素に詳細情報を追加し、物理データモデルが最終的に構築される基盤を提供しますが、モデリング構造自体はDBMSに依存しません。
このデータモデリング段階では、主キーや副キーはまだ確定していません。以前に設定したリレーションシップのコネクタの詳細を確認・調整し、カーディナリティを精緻化します。
論理データモデルの特性
- 単一プロジェクトのデータ要件を説明するものですが、プロジェクトの範囲に応じて他の論理データモデルと統合することも可能です。
- DBMS から独立して設計および開発されました。
- データ属性は、正確な精度と長さを持つデータ型を格納します。
- 正規化は通常、第三正規形（3NF）まで適用されます。
物理データモデル
A 物理データモデル これは、データベース固有のデータモデルの実装について説明します。データベースの絶対値を提供します。trac物理データモデルは、豊富なメタデータのおかげでスキーマを直接生成するのに役立ちます。また、列キー、制約、インデックス、トリガーなどを複製することで、データベース構造を視覚化するのにも役立ちます。 RDBMS 機能。
物理データモデルの特性
- 単一のプロジェクトまたはアプリケーションに必要なデータについて説明するものですが、プロジェクトの範囲に応じて他の物理データモデルと統合することも可能です。
- テーブル間の関係を定義し、各関係のカーディナリティとNULL許容性を考慮します。
- プロジェクトで使用される特定のバージョンのDBMS、場所、データストレージのレイアウト、またはテクノロジー向けに開発されています。
- 列には、正確なデータ型、長さ、およびデフォルト値が設定されます。
- 主キーと外部キー、ビュー、インデックス、アクセスプロファイル、および権限は明示的に定義されています。
概念データモデル、論理データモデル、物理データモデル
各レイヤーを個別に理解したら、その違いを記憶に留める最も簡単な方法は、それらを並べて比較することです。以下の表は、各段階における焦点、担当者、および詳細レベルをまとめたものです。
| 側面 | 概念的 | 論理的 | 物理的な |
|---|---|---|---|
| 目的 | システムに何が含まれているかを定義する | システムがどのように動作するべきかを定義する（DBMSに依存しない） | システムが特定のDBMSでどのように実装されているかを定義する |
| Audience | ビジネス関係者、データアーキテクト | データアーキテクト、ビジネスアナリスト | DBA、開発者 |
| 詳細レベル | 高レベルのエンティティ、属性、関係 | データ型、正規化、属性 | テーブル、列、キー、インデックス、トリガー |
| キーが定義されました | なし | 概念的な主キーと外部キー | 具体的な主キー、外部キー、および代理キー |
| DBMSの依存関係 | 独立した | 独立した | 特定のDBMSに紐づいている |
データモデルの長所と短所
データモデルの利点：
- データモデルの主な目的は、機能チームから提供されるデータオブジェクトが正確に表現されていることを保証することです。
- データモデルは、物理データベースを構築するための設計図として使用できるほど詳細である。
- データモデルの情報は、テーブル間の関係、主キーと外部キー、およびストアドプロシージャを定義するために使用できます。
- データモデルは、企業が組織内および組織間で一貫性のあるコミュニケーションを行うのに役立ちます。
- データモデルはデータマップの文書化に役立ちますpingETLプロセスにおけるs。
- これは、モデルにデータを入力するのに適したデータソースを認識するのに役立ちます。
データモデルの欠点：
- データモデルを開発するには、保存されているデータの物理的な特性を理解する必要があります。
- データモデルに基づいて構築されたナビゲーションシステムは、複雑なアプリケーション開発および管理作業を必要とする可能性があり、そのためには深い専門知識が不可欠となる。
- 構造にわずかな変更を加えるだけでも、アプリケーション全体にわたる修正が必要になる場合がある。
- あらゆるデータ操作に共通する言語は存在しない。 DBMSそのため、モデルはプラットフォームごとに調整する必要がある場合が多い。
