論理データモデルと概念データモデルの違いは何ですか？
概念データモデルでは、どのようなテーブルが存在し、どのようなテーブル間の接続が必要かという、ハイレベルな設計にのみ関心を持ちます。このフェーズでは、モデル内のエンティティおよびエンティティ間の関係を認識します。
論理モデルは、概念的なモデリングの後に、各テーブルのカラムが何であるかを明示的に定義するときに登場します。論理モデルを書いている間、あなたが設計している実際のデータベースシステムも考慮するかもしれませんが、それは設計に影響を与える場合のみです（例えば、トリガーがない場合、冗長なカラムを削除した方がいいかもしれません等）。
また、論理モデルを発展させた物理モデルもあり、各カラムに型や長さなどを割り当てる。
3つのレベルのそれぞれを説明する良い表と絵がこちらにあります。
|----------------------|------------|---------|----------| | 特徴｜概念的｜論理的｜物理的｜など |----------------------|------------|---------|----------| | エンティティ名｜X｜X｜｜｜｜。 | エンティティ間の関係｜X｜X｜｜｜｜。 | 属性 | 主キー｜X｜X｜｜｜。 | 外部キー｜X｜X｜｜｜｜。 | テーブル名 | カラム名 | 列のデータ型 |----------------------|------------|---------|----------|
https://www.1keydata.com/datawarehousing/data-modeling-levels.htmlからの[!]データモデリングレベル
この表では、各モデルの違いを確認できます。 データモデル間の違い。! 詳細および一部のデータモデルの例については、http://www.1keydata.com/datawarehousing/data-modeling-levels.htmlを参照してください。
これらの用語は、残念ながら、いくつかの可能な定義でオーバーロードされています。例えばANSI-SPARCの3つのスキーマモデルによると、概念スキーマまたは概念モデルは、ユーザーが見るオブジェクトである外部スキーマとは対照的に、データベース内のオブジェクトのセット（テーブル、ビューなど）で構成されています。
データ管理の専門家、特にデータモデラーやアーキテクトの間では、概念モデルという用語は意味的なモデルという意味でよく使われ、論理モデルという用語は予備的または仮想的なデータベース設計という意味で使われることが多いようです。これは、おそらく皆さんが職場で最もよく目にする使い方でしょう。
しかし、学術的な使用やDBMSアーキテクチャを説明する場合、論理レベルはデータベース・オブジェクト（テーブル、ビュー、表、キー、制約など）を意味し、物理レベル（ファイル、インデックス、ストレージ）とは区別されます。さらに混乱させるのは、職場では物理モデルという用語が、実際のデータベースに実装された、または実装が計画された設計を意味するものとして使われることが多いことです。この場合、quot;物理レベルおよびquot;論理レベルの構成（たとえばテーブルとインデックスの両方）が含まれることがあります。
これらの用語に遭遇した場合、文脈から明らかな場合を除き、何が説明されているのかを明確にする必要があります。
これらの違いについては、SimsionとWittの「Data Modelling Essentials」などを参照してください。
論理データベースモデル。
ビジネス要件をコンパイルし、要件をモデルとして表現するには、論理データベースモデリングが必要です。 これは主に、データベース設計ではなく、ビジネスニーズの収集に関連しています。 収集する必要がある情報は、組織単位、事業体、およびビジネスプロセスに関するものです。
情報が編集されると、以下を含むレポートと図が作成されます。
ERDとエンティティの関係図は、データの異なるカテゴリ間の関係を示し、データベースの開発に必要なデータの異なるカテゴリを示します。 ビジネスプロセス図–社内の個人の活動を示しています。 これは、設計できるアプリケーションインターフェイスに基づいて、組織内でデータがどのように移動するかを示しています。 ユーザーによるフィードバックドキュメント。
論理データベースモデルは基本的に、ビジネスのすべての要件が収集されたかどうかを判断します。 開発者、管理者、そして最後にエンドユーザーによってレビューされ、物理的なモデリングを開始する前に、より多くの情報を収集する必要があるかどうかを確認します。
物理データベースモデル。 物理データベースモデリングは、論理データベースモデリング中に収集された要件に基づいて実際のデータベースを設計することを扱います。 収集されたすべての情報は、リレーショナルモデルとビジネスモデルに変換されます。 物理モデリング中、オブジェクトはスキーマレベルと呼ばれるレベルで定義されます。 スキーマは、データベース内で相互に関連するオブジェクトのグループと見なされます。 テーブルと列は、論理モデリング中に提供された情報に従って作成されます。 制約を提供するために、主キー、一意のキー、および外部キーが定義されています。 インデックスとスナップショットが定義されています。 データを要約することができ、テーブルが作成されると、ユーザーは別の視点が提供されます。
物理データベースモデリングは、組織ですでに使用されているソフトウェアによって異なります。 ソフトウェア固有です。 物理モデリングには以下が含まれます。
サーバーモデル図–データベース内に存在するテーブルと列、およびさまざまな関係が含まれます。 データベース設計のドキュメント。 ユーザーのフィードバックドキュメント。
概要:
1.Loギカルデータベースモデリングは、主にビジネスニーズに関する情報を収集するためのものであり、データベースの設計は含まれません。一方、物理的なデータベースモデリングは、主にデータベースの実際の設計に必要です。 2.Loギカルデータベースモデリングには、インデックスと制約は含まれていません。アプリケーションの論理データベースモデルは、さまざまなデータベースソフトウェアと実装で使用できます。一方、物理データベースモデリングはソフトウェアとハ ードウェア固有であり、インデックスと制約があります。 3.Loギカルデータベースモデリングには以下が含まれます。 ERD、ビジネスプロセス図、およびユーザーフィードバックドキュメント。一方、物理データベースモデリングには以下が含まれます。サーバーモデル図、データベース設計ドキュメント、およびユーザーフィードバックドキュメント。
続きを読む:論理データベースと物理データベースモデルの違い|の違い|論理対物理データベースモデルhttp://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg。
これは古い質問であり、おそらくこれは遅すぎるかもしれませんが、質問に答えるのに必要な非常に重要な側面が1つわかりません。 つまり、データモデルのTARGETオーディエンスです。 概念データモデルは、ビジネス分析から、データに関するビジネスへのインタビューから生成されたモデルです。 それは、企業がデータを理解していること、「候補」エンティティ間の関係に取り込まれているビジネスルールであるため、それほど「高レベル」ではありません。 この時点で、ビジネスにとって重要なもの(従業員、顧客、契約、アカウントなど)をキャプチャしています。)とそれらの間の関係。 たとえば、最終的な概念データモデルは、やや抽象的な場合があります。, 契約を結んでいる個人および組織を"のサブタイプとして扱います。;Party"。; 従業員のサブタイプとしての請負業者および正社員。, 従業員と顧客のサブタイプも"。;人と引用。; -しかし、データモデラーがビジネスSMEとの議論から発展し、検証のためにビジネスに提示するドキュメントです。
論理データモデルは単に「詳細」ではありません-有用で重要な場合、概念データモデルには属性が含まれている可能性があります-これはARCHITECTUREドキュメントであり、ソフトウェアアナリスト/エンジニアに説明および指定するために提示されるモデルですデータ要件。 連想テーブルへの多対多の関係を解決し、例と制約を使用してすべての属性を定義するため、コードをアーキテクチャに対して記述できます。
物理モデルは、SQL ServerやTeradata、Oracleなどの特定の環境用に特別に生成された論理モデルです。 サイズ、アクセス頻度、セキュリティ制約などに基づいて、キー、インデックス、パーティション、または実装に必要なものがすべて揃います。
したがって、概念データモデルの開発を求められている場合は、ソリューション(またはその一部)をゼロから設計して、ビジネスから情報を入手するよう求められます。 まだまだありますが、質問にお答えいただければ幸いです。
論理モデルと概念モデルの両方を作成する必要があるのですが。ここでの説明はすべて本当に曖昧です。上のリンクは、概念モデルがフィールドのない論理モデルであるという違いを示しているだけです。わかりました、私はデータベースの名前に言及しません。それは完全に冗長であるように見えます。
私は本当に 'semantic' の意味がわかりません。誰か私が 'english' を使ってどう違うのか説明してくれませんか、そしておそらく、フィールドを持つ絵と持たない絵を示す絵より良い例へのリンクを投稿してください。また、フィールドを持つ画像と持たない画像を示す画像よりも良い例へのリンクを掲載することもできます。
論理モデル（基本的に物理モデルをDBから逆引きしたもの）を取り出し、当該ツールのボタンをクリックすると、画像が少し変わって見え、その後データ型を外す以外に何かすることはありますか？
私が実際に見ることができるもの（そしてバズワードなしで）。
物理モデル：実際にテーブルがある。小さな絵の中にデータ型があり、pk/fk制約という名前がついている。 論理モデル：私のツール（Oracles SQL Developer Data Modellerを使用、私はerwinライセンスと2010 visioはもはやDBからリバースエンジニアリングを持っていない）の小さなボタンをクリックし、画面上の画像が少し変更されます。データ型がなくなり、制約の名前もなくなり、テーブル表現の色が紫に変わります（だから、今はエンティティと呼んでいます）。
論理モデルとまったく同じものからフィールドを除いたものです。これ以上のものがあると思います。そのデータの 'semantic' 表現は、本当に素敵で空想的に聞こえますが、これらの1つを以前に作ったことがない人には意味がありません。
概念スキーマ-エンティティと関係をカバーします。 最初に作成する必要があります。 他のいくつかの回答とは対照的です。ここではテーブルは定義されていません。 たとえば、「多数から多数」のテーブルは概念的なデータモデルには含まれていませんが、エンティティ間の「多数から多数」の関係として定義されています。
論理スキーマ-物理的な実装に関係なく、テーブル、属性、キー、必須の役割の制約、および参照の整合性をカバーします。 インデックスのようなものは定義されていません。属性タイプは論理的に保たれる必要があります。 varchar2の代わりにテキスト。 概念スキーマに基づいて作成する必要があります。
まず、データモデルは抽象化ツールであり、データベースモデル(またはスキーム/ダイアグラム)はモデリング結果です。
概念データモデルはDBMSに依存せず、機能/ドメイン設計領域をカバーします。 最もよく知られている概念データモデルは「エンティティ関係」です。 通常、概念スキームを再利用して、リレーショナルだけでなく、さまざまな論理スキームを生成できます。
論理データモデルは、一部のDBMSによって実装されることを意図しており、主にANSI / SPARCアーキテクチャ(1975年に提案)の概念レベルに対応しています。この点は、用語のいくつかの衝突を与えます。 ザックマンフレームワークは、10年後にこの種の衝突を解決しようとし、概念的、論理的、物理的なモデルを導入しました。
多くの論理データモデルがあり、最もよく知られているのはリレーショナルモデルです。
したがって、概念データモデルの主な違いは、ドメインとDBMSに依存しないことに焦点を当てているのに対し、論理データモデルは、使用する予定の具体的なDBMSの最も抽象的なレベルです。 最新のDBMSはいくつかの論理モデルを同時にサポートしていることに注意してください。
詳細については、私の本と記事もご覧ください。
ここでのほとんどの回答は、抽象化のさまざまなレベルでのデータモデルの表記と構文に厳密に関連しています。 重要な違いは誰にも言及されていません。 概念モデルは表面の概念です。 概念は、エンティティが抽象化の論理レベルで別のエンティティに関連する別の方法で他の概念に関連しています。 概念はタイプに近いです。 通常、概念レベルでは、物事のタイプ(これは、命名規則で「タイプ」という用語を使用する必要があるという意味ではありません)とそのようなタイプ間の関係を表示します。 したがって、多対多の関係の存在はルールではなく、タイプごとの要素間の関係の結果です。 論理モデルでは、エンティティは現実の世界でそのことの1つのインスタンスを表します。 概念モデルでは、エンティティのインスタンスとその関係の説明ではなく、その特定のエンティティの「タイプ」または「クラス」の説明が期待されます。 例: -車両にはホイールがあり、ホイールは車両で使用されます。 概念レベルでは、これは多対多の関係です。 -特定の車両(インスタンスごとの車)には、1つの特定の登録番号に5つの車輪があり、特定の車輪ごとに、シリアル番号を持つ各車両はその特定の車にのみ関連しています。 論理レベルでは、これは1対多の関係です。
コンセプトは「タイプ/クラス」をカバーしています。 論理は「インスタンス」をカバーします。
データベースについて別のコメントを追加します。 概念モデルと論理モデルはデータベースについてまったく何もないと上記でコメントした同僚の1人に同意します。 概念モデルと論理モデルは、ERやUMLなどの表記を使用して、データの観点から現実の世界を説明します。データベースベンダーは、スマートに、世界を論理的にモデル化するために使用されるのと同じ哲学に従って製品を設計し、リレーショナルデータベースを作成して、全員の生活を楽にしました。 概念モデルと論理モデルを使用して、組織のデータランドスケープをすべてのレベルで説明でき、リレーショナルデータベースを使用しないでください。
さて、これは私の2セントだと思います。..
論理データモデル。
論理データモデルは、データベースに物理的にどのように実装されるかに関係なく、データを可能な限り詳細に説明します。 論理データモデルの機能は次のとおりです。 ·すべてのエンティティとその間の関係が含まれます。 ·各エンティティのすべての属性が指定されています。 ·各エンティティの主キーが指定されます。 ·外部キー(異なるエンティティ間の関係を識別するキー)が指定されます。 ·正規化はこのレベルで発生します。 概念データモデル。
概念的なデータモデルは、異なるエンティティ間の最高レベルの関係を識別します。 概念的なデータモデルの機能は次のとおりです。 ·重要なエンティティとその間の関係が含まれます。 ·属性は指定されていません。 ·主キーは指定されていません。
概念データモデルでは、どのようなテーブルが存在し、どのようなテーブル間の接続が必要かという、ハイレベルな設計にのみ関心を持ちます。このフェーズでは、モデル内のエンティティおよびエンティティ間の関係を認識します。
論理モデルは、概念的なモデリングの後に、各テーブルのカラムが何であるかを明示的に定義するときに登場します。論理モデルを書いている間、あなたが設計している実際のデータベースシステムも考慮するかもしれませんが、それは設計に影響を与える場合のみです（例えば、トリガーがない場合、冗長なカラムを削除した方がいいかもしれません等）。
また、論理モデルを発展させた物理モデルもあり、各カラムに型や長さなどを割り当てる。
3つのレベルのそれぞれを説明する良い表と絵がこちらにあります。
https://www.1keydata.com/datawarehousing/data-modeling-levels.htmlからの[!]データモデリングレベル
この表では、各モデルの違いを確認できます。 データモデル間の違い。! 詳細および一部のデータモデルの例については、http://www.1keydata.com/datawarehousing/data-modeling-levels.htmlを参照してください。
これらの用語は、残念ながら、いくつかの可能な定義でオーバーロードされています。例えばANSI-SPARCの3つのスキーマモデルによると、概念スキーマまたは概念モデルは、ユーザーが見るオブジェクトである外部スキーマとは対照的に、データベース内のオブジェクトのセット（テーブル、ビューなど）で構成されています。
データ管理の専門家、特にデータモデラーやアーキテクトの間では、概念モデルという用語は意味的なモデルという意味でよく使われ、論理モデルという用語は予備的または仮想的なデータベース設計という意味で使われることが多いようです。これは、おそらく皆さんが職場で最もよく目にする使い方でしょう。
しかし、学術的な使用やDBMSアーキテクチャを説明する場合、論理レベルはデータベース・オブジェクト（テーブル、ビュー、表、キー、制約など）を意味し、物理レベル（ファイル、インデックス、ストレージ）とは区別されます。さらに混乱させるのは、職場では物理モデルという用語が、実際のデータベースに実装された、または実装が計画された設計を意味するものとして使われることが多いことです。この場合、quot;物理レベルおよびquot;論理レベルの構成（たとえばテーブルとインデックスの両方）が含まれることがあります。
これらの用語に遭遇した場合、文脈から明らかな場合を除き、何が説明されているのかを明確にする必要があります。
これらの違いについては、SimsionとWittの「Data Modelling Essentials」などを参照してください。
論理データベースモデル。
ビジネス要件をコンパイルし、要件をモデルとして表現するには、論理データベースモデリングが必要です。 これは主に、データベース設計ではなく、ビジネスニーズの収集に関連しています。 収集する必要がある情報は、組織単位、事業体、およびビジネスプロセスに関するものです。
情報が編集されると、以下を含むレポートと図が作成されます。
ERDとエンティティの関係図は、データの異なるカテゴリ間の関係を示し、データベースの開発に必要なデータの異なるカテゴリを示します。 ビジネスプロセス図–社内の個人の活動を示しています。 これは、設計できるアプリケーションインターフェイスに基づいて、組織内でデータがどのように移動するかを示しています。 ユーザーによるフィードバックドキュメント。
論理データベースモデルは基本的に、ビジネスのすべての要件が収集されたかどうかを判断します。 開発者、管理者、そして最後にエンドユーザーによってレビューされ、物理的なモデリングを開始する前に、より多くの情報を収集する必要があるかどうかを確認します。
物理データベースモデル。 物理データベースモデリングは、論理データベースモデリング中に収集された要件に基づいて実際のデータベースを設計することを扱います。 収集されたすべての情報は、リレーショナルモデルとビジネスモデルに変換されます。 物理モデリング中、オブジェクトはスキーマレベルと呼ばれるレベルで定義されます。 スキーマは、データベース内で相互に関連するオブジェクトのグループと見なされます。 テーブルと列は、論理モデリング中に提供された情報に従って作成されます。 制約を提供するために、主キー、一意のキー、および外部キーが定義されています。 インデックスとスナップショットが定義されています。 データを要約することができ、テーブルが作成されると、ユーザーは別の視点が提供されます。
物理データベースモデリングは、組織ですでに使用されているソフトウェアによって異なります。 ソフトウェア固有です。 物理モデリングには以下が含まれます。
サーバーモデル図–データベース内に存在するテーブルと列、およびさまざまな関係が含まれます。 データベース設計のドキュメント。 ユーザーのフィードバックドキュメント。
概要:
1.Loギカルデータベースモデリングは、主にビジネスニーズに関する情報を収集するためのものであり、データベースの設計は含まれません。一方、物理的なデータベースモデリングは、主にデータベースの実際の設計に必要です。 2.Loギカルデータベースモデリングには、インデックスと制約は含まれていません。アプリケーションの論理データベースモデルは、さまざまなデータベースソフトウェアと実装で使用できます。一方、物理データベースモデリングはソフトウェアとハ ードウェア固有であり、インデックスと制約があります。 3.Loギカルデータベースモデリングには以下が含まれます。 ERD、ビジネスプロセス図、およびユーザーフィードバックドキュメント。一方、物理データベースモデリングには以下が含まれます。サーバーモデル図、データベース設計ドキュメント、およびユーザーフィードバックドキュメント。
続きを読む:論理データベースと物理データベースモデルの違い|の違い|論理対物理データベースモデルhttp://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg。
これは古い質問であり、おそらくこれは遅すぎるかもしれませんが、質問に答えるのに必要な非常に重要な側面が1つわかりません。 つまり、データモデルのTARGETオーディエンスです。 概念データモデルは、ビジネス分析から、データに関するビジネスへのインタビューから生成されたモデルです。 それは、企業がデータを理解していること、「候補」エンティティ間の関係に取り込まれているビジネスルールであるため、それほど「高レベル」ではありません。 この時点で、ビジネスにとって重要なもの(従業員、顧客、契約、アカウントなど)をキャプチャしています。)とそれらの間の関係。 たとえば、最終的な概念データモデルは、やや抽象的な場合があります。, 契約を結んでいる個人および組織を"のサブタイプとして扱います。;Party"。; 従業員のサブタイプとしての請負業者および正社員。, 従業員と顧客のサブタイプも"。;人と引用。; -しかし、データモデラーがビジネスSMEとの議論から発展し、検証のためにビジネスに提示するドキュメントです。
論理データモデルは単に「詳細」ではありません-有用で重要な場合、概念データモデルには属性が含まれている可能性があります-これはARCHITECTUREドキュメントであり、ソフトウェアアナリスト/エンジニアに説明および指定するために提示されるモデルですデータ要件。 連想テーブルへの多対多の関係を解決し、例と制約を使用してすべての属性を定義するため、コードをアーキテクチャに対して記述できます。
物理モデルは、SQL ServerやTeradata、Oracleなどの特定の環境用に特別に生成された論理モデルです。 サイズ、アクセス頻度、セキュリティ制約などに基づいて、キー、インデックス、パーティション、または実装に必要なものがすべて揃います。
したがって、概念データモデルの開発を求められている場合は、ソリューション(またはその一部)をゼロから設計して、ビジネスから情報を入手するよう求められます。 まだまだありますが、質問にお答えいただければ幸いです。
論理モデルと概念モデルの両方を作成する必要があるのですが。ここでの説明はすべて本当に曖昧です。上のリンクは、概念モデルがフィールドのない論理モデルであるという違いを示しているだけです。わかりました、私はデータベースの名前に言及しません。それは完全に冗長であるように見えます。
私は本当に 'semantic' の意味がわかりません。誰か私が 'english' を使ってどう違うのか説明してくれませんか、そしておそらく、フィールドを持つ絵と持たない絵を示す絵より良い例へのリンクを投稿してください。また、フィールドを持つ画像と持たない画像を示す画像よりも良い例へのリンクを掲載することもできます。
論理モデル（基本的に物理モデルをDBから逆引きしたもの）を取り出し、当該ツールのボタンをクリックすると、画像が少し変わって見え、その後データ型を外す以外に何かすることはありますか？
私が実際に見ることができるもの（そしてバズワードなしで）。
物理モデル：実際にテーブルがある。小さな絵の中にデータ型があり、pk/fk制約という名前がついている。 論理モデル：私のツール（Oracles SQL Developer Data Modellerを使用、私はerwinライセンスと2010 visioはもはやDBからリバースエンジニアリングを持っていない）の小さなボタンをクリックし、画面上の画像が少し変更されます。データ型がなくなり、制約の名前もなくなり、テーブル表現の色が紫に変わります（だから、今はエンティティと呼んでいます）。
論理モデルとまったく同じものからフィールドを除いたものです。これ以上のものがあると思います。そのデータの 'semantic' 表現は、本当に素敵で空想的に聞こえますが、これらの1つを以前に作ったことがない人には意味がありません。
概念スキーマ-エンティティと関係をカバーします。 最初に作成する必要があります。 他のいくつかの回答とは対照的です。ここではテーブルは定義されていません。 たとえば、「多数から多数」のテーブルは概念的なデータモデルには含まれていませんが、エンティティ間の「多数から多数」の関係として定義されています。
論理スキーマ-物理的な実装に関係なく、テーブル、属性、キー、必須の役割の制約、および参照の整合性をカバーします。 インデックスのようなものは定義されていません。属性タイプは論理的に保たれる必要があります。 varchar2の代わりにテキスト。 概念スキーマに基づいて作成する必要があります。
まず、データモデルは抽象化ツールであり、データベースモデル(またはスキーム/ダイアグラム)はモデリング結果です。
概念データモデルはDBMSに依存せず、機能/ドメイン設計領域をカバーします。 最もよく知られている概念データモデルは「エンティティ関係」です。 通常、概念スキームを再利用して、リレーショナルだけでなく、さまざまな論理スキームを生成できます。
論理データモデルは、一部のDBMSによって実装されることを意図しており、主にANSI / SPARCアーキテクチャ(1975年に提案)の概念レベルに対応しています。この点は、用語のいくつかの衝突を与えます。 ザックマンフレームワークは、10年後にこの種の衝突を解決しようとし、概念的、論理的、物理的なモデルを導入しました。
多くの論理データモデルがあり、最もよく知られているのはリレーショナルモデルです。
したがって、概念データモデルの主な違いは、ドメインとDBMSに依存しないことに焦点を当てているのに対し、論理データモデルは、使用する予定の具体的なDBMSの最も抽象的なレベルです。 最新のDBMSはいくつかの論理モデルを同時にサポートしていることに注意してください。
詳細については、私の本と記事もご覧ください。
ここでのほとんどの回答は、抽象化のさまざまなレベルでのデータモデルの表記と構文に厳密に関連しています。 重要な違いは誰にも言及されていません。 概念モデルは表面の概念です。 概念は、エンティティが抽象化の論理レベルで別のエンティティに関連する別の方法で他の概念に関連しています。 概念はタイプに近いです。 通常、概念レベルでは、物事のタイプ(これは、命名規則で「タイプ」という用語を使用する必要があるという意味ではありません)とそのようなタイプ間の関係を表示します。 したがって、多対多の関係の存在はルールではなく、タイプごとの要素間の関係の結果です。 論理モデルでは、エンティティは現実の世界でそのことの1つのインスタンスを表します。 概念モデルでは、エンティティのインスタンスとその関係の説明ではなく、その特定のエンティティの「タイプ」または「クラス」の説明が期待されます。 例: -車両にはホイールがあり、ホイールは車両で使用されます。 概念レベルでは、これは多対多の関係です。 -特定の車両(インスタンスごとの車)には、1つの特定の登録番号に5つの車輪があり、特定の車輪ごとに、シリアル番号を持つ各車両はその特定の車にのみ関連しています。 論理レベルでは、これは1対多の関係です。
コンセプトは「タイプ/クラス」をカバーしています。 論理は「インスタンス」をカバーします。
データベースについて別のコメントを追加します。 概念モデルと論理モデルはデータベースについてまったく何もないと上記でコメントした同僚の1人に同意します。 概念モデルと論理モデルは、ERやUMLなどの表記を使用して、データの観点から現実の世界を説明します。データベースベンダーは、スマートに、世界を論理的にモデル化するために使用されるのと同じ哲学に従って製品を設計し、リレーショナルデータベースを作成して、全員の生活を楽にしました。 概念モデルと論理モデルを使用して、組織のデータランドスケープをすべてのレベルで説明でき、リレーショナルデータベースを使用しないでください。
さて、これは私の2セントだと思います。..
論理データモデル。
論理データモデルは、データベースに物理的にどのように実装されるかに関係なく、データを可能な限り詳細に説明します。 論理データモデルの機能は次のとおりです。 ·すべてのエンティティとその間の関係が含まれます。 ·各エンティティのすべての属性が指定されています。 ·各エンティティの主キーが指定されます。 ·外部キー(異なるエンティティ間の関係を識別するキー)が指定されます。 ·正規化はこのレベルで発生します。 概念データモデル。
概念的なデータモデルは、異なるエンティティ間の最高レベルの関係を識別します。 概念的なデータモデルの機能は次のとおりです。 ·重要なエンティティとその間の関係が含まれます。 ·属性は指定されていません。 ·主キーは指定されていません。