データベース内のエンティティのタイプ。 データベース設計入門。 冗長属性のモデリング
エンティティは、ドメインに不可欠な実際のエンティティまたは抽象的なエンティティです。 エンティティには、単数形の名詞で表される名前が必要です。
エンティティを識別する非公式な方法は、オブジェクト、プロセス、ロール、およびその他の概念を説明する抽象化を探すことです。 エンティティを識別する正式な方法は、主題領域のテキストによる説明を分析し、名詞を抽出して、それらを抽象化として選択することです。
エンティティインスタンスは、そのエンティティの特定のインスタンスです。 たとえば、従業員Ivanovは、Employeeエンティティのインスタンスになることができます。
各エンティティには、次のプロパティが必要です。
一意の名前があります。
エンティティに属するか、リレーションシップを通じて継承される1つ以上の属性を持っている。
各エンティティインスタンスを一意に識別する1つ以上の属性があります。
属性-検討中のサブジェクト領域にとって重要であり、エンティティの状態を識別、分類、定量化、または表現することを目的としたエンティティの特性。
次のタイプの属性があります。
シンプル-1つのデータ要素で構成されます。
コンポジット-いくつかのデータ要素で構成されます。
明確-1つのエンティティに対して1つの値が含まれます。
multivalued-1つのエンティティの複数の値が含まれています。
オプション-空の（未定義の）値を持つ場合があります。
派生-別の属性の値から派生した値。
一意の識別子は、集合体の値がエンティティインスタンスごとに一意である属性のセットです。 識別子から属性を削除すると、その一意性が失われます。 図では、一意の識別子に下線が引かれています。
各エンティティは、他のエンティティと任意の数の関係を持つことができます。
エンティティ間の関係
関係は、問題のドメインにとって意味のあるエンティティ間の名前付きの関連付けです。
関係の程度は、関係に参加しているエンティティの数です。
リンクパワー-リンクに参加しているエンティティインスタンスの数。
電力値に応じて、接続には次の3つのタイプのいずれかを使用できます。
1対1（1：1と表示）。
1対多（1：Nと表示）。
多対多（M：Nで示されます）。
1対1。 このような関係では、1つの役割を持つエンティティは、常に別の役割を持つ1つのエンティティにしか対応しないことを意味します。 各エンティティの接続度は1であるため、1本の線で接続されています。
1対多。 1つの役割を持つエンティティは、異なる役割を持つ任意の数のエンティティと一致させることができます。
多対多。 この場合、関連付けられた各エンティティは、任意の数のインスタンスで表すことができます。
「リレーショナル」という用語は、「リレーションシップベース」を意味します。 リレーショナルデータベースは、相互に何らかの関係を持つエンティティ（テーブル）で構成されます。 名前は英語の単語の関係に由来します。
データベース設計は、論理モデリングと物理モデリングの2つの主要なフェーズで構成されています。
論理モデリング中に、要件を収集し、特定のDBMS（リレーショナルデータベース管理システム）に依存しないデータベースモデルを開発します。 それはあなたの家の青写真を作成するようなものです。 キッチン、寝室、居間など、すべてを考えて描くことができます。 しかし、これはすべて紙とレイアウトにあります。
物理モデリング中に、特定のアプリケーションとDBMS用に最適化されたモデルを作成します。 実際に実装されているのはこのモデルです。 前の段落から家に戻ると、この段階でどこかに家を建てる必要があります-丸太、レンガを運ぶ...
データベース設計プロセスは、次の手順で構成されています。
- 情報の収集;
- エンティティの定義;
- 各エンティティの属性を定義します。
- エンティティ間の関係を定義する。
- 正規化;
- 物理モデルへの変換。
- データベースの作成。
最初の5つの段階は論理設計段階を形成し、残りの2つの段階は物理モデリング段階を形成します。
論理フェーズ
論理フェーズはいくつかのステージで構成されます。 それらはすべて以下で説明されています。
要件の収集
この段階で、データベースがどのように使用され、どの情報がデータベースに格納されるかを正確に決定する必要があります。 システムが実行すべきことと実行すべきでないことについて、可能な限り多くの情報を収集します。
エンティティ定義
この段階で、データベースを構成するエンティティを定義する必要があります。
エンティティは、データを格納するデータベース内のオブジェクトです。 エンティティは、現実のもの（家、人、物、場所）または抽象的なもの（銀行取引、会社の部門、バス路線）の場合があります。 物理モデルでは、エンティティはテーブルと呼ばれます。
エンティティは、属性（テーブルの列）とレコード（テーブルの行）で構成されます。
通常、データベースは、多数の従属エンティティに関連付けられたいくつかのプライマリエンティティで構成されています。 コアエンティティは独立と呼ばれ、他のエンティティに依存しません。 従属エンティティは依存と呼ばれます。それらの1つが存在するためには、それに関連付けられたメインテーブルが存在する必要があります。
ダイアグラムでは、エンティティは通常、長方形として表されます。 エンティティの名前は長方形の中に示されています：
どのテーブルにも次の特徴があります。
- その中に同じ行はありません。
- テーブル内のすべての列（属性）は異なる名前である必要があります。
- 同じ列内の要素は同じタイプ（文字列、数値、日付）を持ちます。
- テーブル内の行の順序は任意です。
この段階で、データベースに保存される情報（エンティティ）のすべてのカテゴリを識別する必要があります。
属性定義
属性は、エンティティを説明するプロパティを表します。 多くの場合、属性は数値、日付、またはテキストです。 属性に格納されるすべてのデータは、同じタイプであり、同じプロパティを持っている必要があります。
物理モデルでは、属性は列と呼ばれます。
エンティティを定義した後、これらのエンティティのすべての属性を定義する必要があります。
ダイアグラムでは、属性は通常、エンティティの長方形内にリストされます。 この図には、「住宅」データベースの例がありますが、このデータベースのエンティティに対して一部の属性が定義されているだけです。 
各属性は、データ型、サイズ、許可される値、およびその他のルールを定義します。 これらには、必須、変更可能、および一意性のルールが含まれます。
必須ルールは、属性がエンティティの必須部分であるかどうかを決定します。 属性がエンティティのオプション部分である場合、それはNULLになる可能性があり、そうでない場合はそうではありません。
また、属性が変更可能かどうかを判断する必要があります。 一部の属性値は、エントリの作成後に変更できません。
そして最後に、属性が一意であるかどうかを判断する必要があります。 その場合、属性値を繰り返すことはできません。
キー
キーは、エントリを一意に識別する属性のセットです。 キーは、単純と複合の2つのクラスに分けられます。
単純なキーは、1つの属性のみで構成されます。 たとえば、「国の市民のパスポート」データベースでは、パスポート番号は単純なキーになります。結局のところ、同じ番号のパスポートは2つありません。
複合キーは、いくつかの属性で構成されています。 同じデータベース「国の市民のパスポート」には、次の属性を持つ複合キーがあります。
家系の名前、名前、父称、生年月日。 この複合キーは、理論上、レコードの一意性が保証されていないため、これは単なる例です。
キーにはいくつかの種類があり、以下で説明します。
可能なキー
候補キーは、テーブル内のエントリを一意に識別する属性のセットです。 候補キーは、単純または複合にすることができます。
複数の可能なキーが存在する場合もありますが、各エンティティには少なくとも1つの可能なキーが必要です。 主キー属性のいずれもNULL値を持つことはできません。
候補キーは、代理キーとも呼ばれます。
主キー
主キーは、テーブル（エンティティ）内のレコードを一意に識別する属性のセットです。 可能なキーの1つが主キーになります。 ダイアグラムでは、主キーは属性のメインリストの上に表示されるか、特殊文字で強調表示されることがよくあります。 図のエンティティには、キー属性と通常の属性の両方があります。 
代替キー
主キーではない可能性のあるキーは、代替キーと呼ばれます。 エンティティは複数の代替キーを持つことができます。
外部キー
外部キーは、別のエンティティの主キーまたは代替キーを参照する属性のコレクションです。 外部キーがプライマリエンティティに関連付けられていない場合、null値のみを含めることができます。 キーも複合である場合、外部キーのすべての属性が未定義である必要があります。
ダイアグラムでは、外部キーに結合される属性は特別な記号で示されます。 この図は、2つの関連エンティティ（家とその所有者）とそれらによって形成された外部キーを示しています（結局のところ、1人が複数の家を所有できます）。 
キーは論理構造であり、物理オブジェクトではありません。 リレーショナルデータベースには、キーを格納するメカニズムがあります。
エンティティ間の関係の定義
リレーショナルデータベースを使用すると、さまざまなエンティティに属する情報を組み合わせることができます。
関係とは、1つのエンティティが2番目のエンティティの主キーを参照する状況です。 たとえば、前の図のエンティティHouseとMasterのように。
関係は、基本設計プロセス中に定義されます。 これを行うには、エンティティを分析し、エンティティ間に存在する論理的な関係を特定する必要があります。
リレーションシップタイプは、別のエンティティレコードに関連付けられているエンティティレコードの数を決定します。 関係は、以下に説明する3つの主要なタイプに分けられます。
1対1
最初のエンティティの各エントリは、2番目のエンティティからの1つのエントリにのみ対応します。 また、2番目のエンティティの各レコードは、最初のエンティティの1つのレコードにのみ対応します。 たとえば、人と出生証明書の2つのエンティティがあります。 また、1人の出生証明書は1つしか持てません。
1対多
最初のエンティティの各レコードは、2番目のエンティティの複数のレコードに対応できます。 ただし、2番目のエンティティの各エントリは、最初のエンティティからの1つのエントリにのみ対応します。 たとえば、OrderとOrderItemの2つのエンティティがあります。 また、1つの注文に多くのアイテムが含まれる場合があります。
多対多
最初のエンティティの各レコードは、2番目のエンティティの複数のレコードに対応できます。 ただし、2番目のエンティティの各レコードは、最初のエンティティの複数のレコードに対応できます。 たとえば、AuthorとBookの2つのエンティティがあります。 1人の著者がたくさんの本を書くことができます。 しかし、本には複数の著者がいる可能性があります。
必須の関係の基準に従って、必須とオプションに分けられます。
- 必須の関係とは、最初のエンティティからのエントリごとに、2番目のエンティティに関連するエントリが存在する必要があることを意味します。
- オプションの関係とは、最初のエンティティのレコードが2番目のエンティティにレコードを持たない可能性があることを意味します。
正規化
正規化は、データベースから冗長データを削除するプロセスです。 各データ要素は、1つのインスタンスでデータベースに保存する必要があります。 正規化には5つの一般的な形式があります。 原則として、データベースは第3正規形に縮小されます。
正規化プロセス中に、冗長データを削除するために特定のアクションが実行されます。 正規化により、パフォーマンスが向上し、並べ替えとインデックスの作成が高速化され、エンティティごとのインデックスの数が減り、挿入および更新操作が高速化されます。
正規化されたデータベースは通常、より柔軟性があります。 クエリまたは永続化されたデータを変更する場合、正規化されたデータベースは通常、必要な変更が少なく、変更による影響も少なくなります。
第一正規形
エンティティを最初の正規形に変換するには、重複する値のグループを削除し、各属性に1つの値のみが含まれていることを確認する必要があります。値のリストは許可されていません。
つまり、エンティティの各属性は1つのインスタンスにのみ保存する必要があります。
たとえば、この図では、Houseエンティティは正規化されていません。 これには、家の所有者に関するデータを格納するためのいくつかの属性が含まれています（家のエンティティは最初の正規形に対応していません）。 
Houseエンティティを最初の正規形にするには、値の繰り返しグループを削除する必要があります。つまり、Owner 1-3属性を削除して、別のエンティティに配置する必要があります。 結果（エンティティハウスは最初の正規形に縮小されました）： 
2番目の正規形
第2正規形のテーブルには、それに適用されるデータのみが含まれます。 非キーエンティティ属性の値は、主キーによって異なります。 より正確には、属性は主キー、主キー全体、および主キーのみに依存します。
エンティティは、第2正規形に準拠するために、第1正規形である必要があります。
たとえば、図のエンティティHouseには、ガソリン1リットルあたりの価格という属性があります。これは住宅とは関係ありません。 この属性は削除されます（または別のエンティティに移動できます）。 また、Mayor属性を別のエンティティに移動します。この属性は、家ではなく、家が配置されている都市に依存します。
この図は、第2正規形のエッセンスハウスを示しています（エッセンスハウスは第2正規形に縮小されています）。 
3番目の正規形
3番目の正規形は、キー全体に依存しない属性を除外します。 第3正規形のエンティティは、第2正規形でもあります。 これは、データベースの最も一般的な形式です。
第3正規形では、すべての属性はキー、キー全体、およびキーのみに依存します。
たとえば、図の家の所有者エンティティには、家の所有者の名前（キー）ではなく、家の所有者の誕生日に依存する星座属性があります。
家の所有者のエンティティをキャストするには、干支の記号のエンティティを作成し、そこに干支の属性の記号を転送する必要があります（家の所有者のエンティティ、3番目の通常の形式に縮小）： 
制限
制約データベース管理システムによって適用されるルールです。 制約は、1つまたは複数の列に入力できる値のセットを定義します。
たとえば、非常にクールな店舗での注文額を500ルーブル未満にしたくないとします。 [注文金額]列に制限を設定するだけです。
ストアドプロシージャ
ストアドプロシージャは、データベースに格納されているプリコンパイル済みのプロシージャです。 ストアドプロシージャは、ビジネスルールを定義するために使用でき、制約のみよりも複雑な計算を実行するために使用できます。
ストアドプロシージャには、プログラムフローロジックとデータベースクエリを含めることができます。 それらはパラメータを取り、結果をテーブルまたは単一の値として返すことができます。
ストアドプロシージャは、他のプログラムの通常のプロシージャや関数とまったく同じです。
ノート
ストアドプロシージャはデータベースに常駐し、データベースサーバーで実行されます。 これらはコンパイルされた形式で格納されるため、一般にSQLステートメントよりも高速です。
データの整合性
データをテーブルに整理し、それらの間の関係を定義することにより、ビジネス環境を正しく反映するモデルが作成されたと想定できます。 ここで、データベースに入力されたデータが問題の状態について正しい考えを与えることを確認する必要があります。 つまり、ビジネスルールを適用し、データベースの整合性を維持する必要があります。
たとえば、あなたの会社は本の配達に従事しています。 不明なクライアントからの注文を受け入れる可能性は低くなります。そうすると、注文を配達することさえできなくなるからです。 したがって、ビジネスルール：注文は、情報がデータベースにある顧客からのみ受け入れられます。
リレーショナルデータベースのデータの正確性は、一連のルールによって保証されます。 データ整合性ルールは4つのカテゴリに分類されます。
- エンティティの整合性-各エンティティレコードには一意の識別子があり、データが含まれている必要があります。 結局のところ、データベース内のこれらすべてのレコードを何らかの方法で区別する必要があります。
- 属性の整合性-各属性は有効な値のみを受け入れます。 たとえば、購入金額は間違いなくゼロ以上にすることはできません。
- 参照整合性-レコードを挿入、更新、および削除するときに、主キーと外部キーの論理的な一貫性を保証する一連のルール。 参照整合性により、すべての外部キーに対応する主キーが確実に存在します。 エンティティHomeOwnerとHomeを使用して前の例を見てみましょう。 あなたがVasyaIvanovで、家を所有しているとしましょう。 家系の名前をSidorovに変更し、Houseownerエンティティに適切な変更を加えました。 間違いなく、あなたはあなたの家があなたの新しい名前であなたのものであり続け、もはや存在しない特定のヴァシャ・イワノフに属していないことを望んでいます。
- カスタム整合性ルール-リストされたカテゴリのいずれにも属さない整合性ルール。
トリガー
引き金はストアドプロシージャの類似物であり、テーブル内のデータが変更されると自動的に呼び出されます。
トリガーは、データベースの整合性を維持するための強力なメカニズムです。 トリガーは、テーブル内のデータ変更の前または後に呼び出されます。
トリガーを使用すると、これらの変更を元に戻すだけでなく、他のテーブルのデータを変更することもできます。
たとえば、インターネットフォーラムを作成していて、フォーラムリストに最新のフォーラム投稿が表示されていることを確認したいとします。 もちろん、Forum Postsエンティティからメッセージを受け取ることはできますが、これにより、リクエストとその実行時間が複雑になります。 フォーラムエンティティに追加された最後の投稿を記録するトリガーを、フォーラム投稿エンティティの[最後の投稿]属性に追加する方が簡単です。 これにより、クエリが大幅に簡素化されます。
ビジネスルール
ビジネスルールは、ビジネスの要件（ベースを作成する対象）に従ってデータに課せられる制限を定義します。 ビジネスルールは、特定のタスクを完了するために必要な一連の手順で構成されている場合もあれば、入力されたデータが正しいことを確認するためのチェックである場合もあります。 ビジネスルールには、データ整合性ルールが含まれる場合があります。 他のルールとは異なり、それらの主な目的は、商取引が正しく行われるようにすることです。
たとえば、Very Tough Guysの会社では、公用に白、青、黒の車だけを購入するのが通例かもしれません。
CompanyVehiclesエンティティのVehicleColor属性のビジネスルールは、車両は白、青、または黒のみであるということです。
ほとんどのDBMSは、次の手段を提供します。
- デフォルト値を指定します。
- データベースに入力する前にデータをチェックします。
- テーブル間の関係を維持するため。
- 値の一意性を確保するため。
- ストアドプロシージャをデータベースに直接保存するため。
これらの機能はすべて、データベースにビジネスルールを実装するために使用できます。
物理モデル
論理モデルを作成した後の次のステップは、物理モデルを構築することです。 物理モデルは、データベースの実際の実装です。 物理モデルは、実装する必要のあるすべてのオブジェクトを定義します。
論理モデルから物理エンティティに移動すると、それらはテーブルに変換され、属性は列に変換されます。
エンティティ間の関係は、テーブルに変換することも、外部キーとして残すこともできます。
主キーは主キー制約に変換されます。 可能なキーは一意性制約にあります。
非正規化
非正規化-これは、正規形の規則に違反するベースの構造の意図的な変更です。 これは通常、データベースのパフォーマンスを向上させるために行われます。
理論的には、常に完全に正規化されたベースを目指して努力する必要がありますが、実際には、完全に正規化されたベースは、ほとんどの場合、パフォーマンスの低下を意味します。 データベースを過度に正規化すると、データを取得するたびに複数のテーブルにアクセスする可能性があります。 通常、4つ以下のテーブルがクエリに参加する必要があります。
標準の非正規化手法は、複数のテーブルを1つに結合し、同じ属性を複数のテーブルに格納し、要約データまたは計算データをテーブルに格納することです。
属性。
サブジェクトエリア。
データベース。 意味。
DBMS。 意味。
データベース。 意味。
3番目の正規形。 意味。 例。
関係変数Rは、次の条件が当てはまる場合に限り、第3正規形になります。
Rは第2正規形です。
・非キー属性Rは、潜在的なキーRから推移的な関数従属性にありません（つまり、依存性は別の属性を介して表現されません）。
リレーションRの非キー属性は、Rの候補キーのいずれにも属していない属性です。
データベース-これは、相互接続された大量の情報を保存、変更、および処理するように設計された1つ以上のデータファイルであり、これらの資料を電子コンピューター（コンピューター）を使用して検索および処理できるように体系化されています。
データベース管理システム（DBMS）は、ユーザーがデータベースを定義、作成、および保守できるようにし、エンドユーザーアプリケーションからのデータベース呼び出しを処理するソフトウェアです。
データベース-一元化されたストレージとデータの集合的使用の自動化された情報システム。 データバンクには、1つ以上のデータベース、データベースディレクトリ、DBMS、およびクエリとアプリケーションプログラムのライブラリが含まれます。
サブジェクトエリアは、管理プロセスを自動化するデータベースを作成するために調査する現実の世界の一部です。
属性データ構造の最小単位です。 データベースの作成時に、各要素に一意の名前が割り当てられます。 処理中にこの名前で参照されます。
エッセンス-検討中のサブジェクトエリア内の具体的または抽象的なオブジェクト。 エンティティは、データベースに格納される基本的なタイプの情報です（リレーショナルデータベースでは、各エンティティにテーブルが割り当てられます）。
DBMSの機能を一覧表示します
DBMSの主な機能：
1）作成されたデータベースの構造の決定、その初期化および初期ロード。
2）ユーザーにデータを操作する機能を提供します（必要なデータの選択、計算の実行、入出力インターフェースの開発、視覚化）。
3）データの論理的および物理的な独立性を確保します。
4）データベースの論理的整合性の保護-データがデータベースに入力されたとき、またはデータ処理手順の違法なアクションがデータベースに誤ったデータを受信して入力したときに、データの信頼性が侵害される可能性があります。 システム内のデータの信頼性を高めるために、いわゆる整合性制約が宣言されています。
5）物理的整合性の保護-データベース回復ツール（トランザクション）。
6）データベースにアクセスするためのユーザー権限の管理。
7）複数のユーザーの作業の同期。
8）ストレージ環境のリソース管理-DBMSは、新しいデータにメモリリソースを割り当て、解放されたメモリを再配布し、外部メモリへの要求のキューイングを整理します。
9）システム担当者の活動のサポート
数年前、私の他の活動の中で、論理データベース構造とSQL言語の構築の基本に関するオンラインレッスンがありました。 今はレッスンをしていませんが、レコーディング自体は残っていたので、投稿することにしました。 🙂
今日は、実体関連モデル、または実体関連モデルについて説明します。
仮説
実体関連モデルまたはERモデルは、データベース構造の設計タスクを簡素化するために開発された高レベルの概念データモデルです。
このモデルは、データベース構造をエンティティ、属性、および関係のセットとして記述する一連の概念です。 このようなデータモデルを開発する主な目標は、データに対するユーザーの認識を高め、データベース設計に関連する多数の技術的側面について合意することです。 概念データモデルは、データベースの実装に使用される特定のDBMSまたはハードウェアプラットフォームに依存しないことに特に注意してください。
「実体関連」図の目的は、実際のサブジェクト領域（SbD）の正確で完全な表現を作成することです。これは、自動情報処理システム（DB ASOI）のデータベースを構築するための情報源として後で使用されます。
この図またはObDの概念モデルは、次の要件を満たしている必要があります。
- SbAが適切に表示されていることを確認します。
- ASOIの将来のユーザーとデータベース開発者の両方が理解できる言語で提示します。
- さらなるデータベース設計（論理および物理モデルの開発）に十分なObDに関する情報が含まれています。
- ObAモデルの明確な解釈または解釈を保証します。
このモデルの主な概念は、 エンティティ、属性、および関係。
エッセンス同じプロパティを持つ実世界のオブジェクトのセットです。 エンティティは独立した存在によって特徴付けられ、物理的（または実際の）存在を持つオブジェクトまたは概念的（または抽象的な）存在を持つオブジェクトにすることができます。
エンティティは、情報を収集する必要がある現象またはプロセス（トランザクションまたは要求）の主要なコンテンツであり、情報収集の節点です。 エンティティとは、同種のオブジェクトまたはモノのセットを指します。 各エンティティは、名前とプロパティ（属性）のリストによって識別されます。 エンティティは、人、場所、物などであり、それらに関する情報をデータベースに保存する必要があります。
練習
例。 サブジェクトエリア" 映画館でのチケットの予約"。 映画は映画館で上映され、チケットはショー当日に購入するか、事前に予約することができます。 データベースには、古い映画を含む、特定の映画館での上映されたすべての映画に関する情報が含まれています。 各映画の上映には独自の費用がかかります。 同じ映画のチケットが異なる時間に価格が異なる場合があります。 映画上映は映画で構成され、その情報はデータベースにも保存されます。
プロ向け」 映画館でのチケットの予約」エンティティは次の概念になります。
映画上映
映画
ビューア
チケット
予約
価格
グラフィカルに、エンティティ関係図のエンティティは長方形として表されます。
属性— これは、エンティティまたはリレーションのプロパティを定義するための手段です。 属性は、エンティティの名前付き特性です。 属性名は特定のエンティティに対して一意である必要がありますが、異なるエンティティに対して同じである場合があります。
エンティティの特定の属性セットは、それらが使用されるタスクによって決定されます。 たとえば、ObAの「映画館でのチケットの注文」のエンティティは、次の一連の属性を使用して説明できます。
映画上映（上映番号、上映番号、上映日、費用番号）;
映画（映画番号、タイトル、長さ、簡単な説明）;
ビューア（観客番号、氏名、生年月日）;
チケット（観客番号、映画上映番号、チケット価格）;
予約（審査員番号、上映番号、予約日）;
価格（費用番号、スクリーニング番号、費用）。
グラフィカルに、エンティティの属性は、属性名のリストをリストするコールアウトとして表されます。 例えば：
太字のイタリック体と下線は、主キーを示します。これは、エンティティを一意に特徴付けるエンティティの属性です。 下線は外部キーを示します-それらが参照するエンティティを一意に特徴付ける属性。
繋がり 2つ（またはそれ以上）の異なるエンティティのインスタンス間の関係です。 関係メカニズムは、ObA内のエンティティ間の関係を定義するために使用されます。 さらに、別のエンティティの属性間には関係があります（論理モデルを構築するときに考慮されます）。
各リンクには、その機能を説明する名前が付けられています。 関係には、接続の名前、カーディナリティインデックス、参加の程度、接続の程度、接続の存在時間などの特性があります。
関係の名前は、エンティティがどのように関連しているかを理解しやすくするために、特定の意味を持つ必要があります。 たとえば、エンティティSpectatorとTicketの間の関係は、「購入」として定義できます。
ひし形は、実体関連図で関係をグラフィカルに表すために使用されます。 ひし形の内部では、接続の名前が定義されており、この接続に参加しているエンティティは線を使用して接続されています。
関係カーディナリティインジケーター（明確性の特性）は、エンティティ間の関係の程度を示し、参加している各エンティティの可能な関係の数を示します。
- 1対1（1：1）;
- 1対多（1：N）;
- 多対多（N：M）。
Zaitsev S.L.、Ph.D。
パート1。エッセンスの概念
この記事では、エンティティとエンティティキーについて詳しく説明します。 あなたが知っているように、 エンティティさらなる処理のためにどの情報を保存する必要があるかについての概念です。 の ERwinエンティティデータの論理グループのグラフィック表現です。 エンティティは、有形、実物、または無形の概念的抽象化である可能性があります。 エンティティは、単一のエンティティを表すことを意図したものではありません。 むしろ、それらは複数のインスタンスに関する情報を含む属性を含むクラスを表します。
エンティティに関する次の質問については、以下で説明します。
- エンティティリレーショナル図
- エンティティの強調表示
- エンティティタイプの定義
- エンティティの命名と説明
- エンティティを操作する際のよくある間違い
ERwinはデータモデリング手法を使用しているため ER（エンティティリレーショナル）、ERの概念の簡単な紹介から始めましょう。 まず、論理モデルの情報を格納するためのエンティティ（「コンテナ」）の調査を始めましょう。
エンティティリレーショナル図の概要
このトピックに関するこの出版物および他の出版物では、ERD図（実体関連図）を使用して、 ERwin。 拡張リレーショナル分析（ERA）、オブジェクト指向（OO）、オブジェクトロールモデリング（ORM）など、他のデータモデリング手法もありますが、ER手法の基本的な概念が存在します。
ERモデリング手法は、1970年代後半にP.Chenによって開発されました。 長方形は、ER方法論でエンティティを表すために使用されます。 Chenの元のER表記では、関係には属性が含まれています。 エンティティと関係で属性を使用する可能性が同じであるため、エンティティと関係を区別することは非常に困難です。
ERアプローチは時間の経過とともに進化および拡張されてきましたが、基本的な概念は、優れたデータモデリングの強固な基盤を提供し続けています。
以下は、エンティティの詳細な説明であり、エンティティの主キーの検索に特に重点を置いて、キーの概要を示しています。 エンティティタイプの説明も提供され、エンティティの命名と説明に関する推奨事項が示されています。 最後のセクションでは、エンティティとキーに関連する一般的なエラーの分析について説明します。
エンティティとは何ですか？
エッセンスデータの論理グループの物理的表現です。 エンティティは、PERSONやICE CREAMなどの有形の実際のオブジェクト、またはCOSTCENTERやMARKETなどの無形の概念的な抽象化です。 エンティティは、単一のエンティティを表すことを意図したものではなく、一意性の観点から関心のある情報を含むインスタンスのコレクションを表します。 たとえば、エンティティPERSONは、Personタイプのオブジェクトのインスタンスです。 Ivan Petrov、Maria Rusanova、およびSavely Bogdanovは、PERSONエンティティのインスタンスの具体例です。 特定のエンティティインスタンスはテーブル行で表され、主キーで識別されます。
エンティティには次の属性があります。
- 名前と説明があります。
- これは、抽象化の単一のインスタンスではなく、クラスを表します。
- その特定の代表（インスタンス）は一意に識別できます。
- これには、企業が関心を持つ情報を表す属性の論理グループが含まれています。
エンティティの正式な定義
以下は、認識されているデータモデリング機関のエンティティ定義のリストです。 それらの類似点に注意してください：
- Chen（1976）：「一意に識別できるもの」。
- 日付（1986）：「データベースで表される識別可能なオブジェクト。」
- Finklestein（1989）：「情報エンティティは、将来の参照用に保存される「もの」を表します。エンティティという用語は、データの論理表現を指します。」
エンティティの強調表示
エンティティを抽出するプロセスを開始するにはどうすればよいですか？ ほとんどの実体は、作業セッションとインタビューの間に明らかにされます。 対象分野の専門家およびエンドユーザーから受け取った情報の要件の分析は、最良の情報源です。
もう1つの良い情報源は、企業モデルです。
名詞とオブジェクト名に注意してください-それらが論理エンティティになる可能性は十分にあります。 エンティティがロールの観点からモデル化されている場合によくあるように、単一のインスタンスをエンティティとして表すことは避けてください。 役割の観点からエンティティをモデル化することは、かなり一般的な間違いです。 エンティティは、正規化プロセスにも表示されます。 論理モデルを第3正規形にすると、いくつかの追加エンティティが表示される可能性があります。
エンティティには主に2つのグループがあります。 依存および独立。 独立したエンティティは、一意のインスタンスを識別するために別のエンティティからの情報を必要としません。 彼女はに登場します ERwin長方形の形で。 独立したエンティティの主キーには、他のエンティティの主キーは含まれていません。
依存エンティティは、一意のインスタンスを識別するために別のエンティティからの情報を利用する必要があります。 ERダイアグラムでは、角が丸い長方形として表されます。 依存エンティティの主キーには、1つ以上の親エンティティの主キーが含まれます。
米。 2.1。 アイスクリーム会社のコアエンティティの例。
図に注意してください。 2.1。ここで、独立エンティティSHOPとICE CREAMの直角と、依存エンティティICECREAMSHOPの丸みを帯びた角が示されています。
エンティティタイプの定義
依存エンティティと独立エンティティの両方をいくつかのタイプに分けることができます。
- コアエンティティ-これらは、コアエンティティまたはプライマリエンティティと呼ばれることもあります。 これらは、情報を保存する必要がある重要なオブジェクトを表します。
- コード/参照/分類子-これらのエンティティには、属性の値セットまたはスコープを定義する文字列が含まれています。
- 連想エンティティ-これらのエンティティは、関係を解決するために使用されます 多対多.
- 特徴的なエンティティ-これらのエンティティには、排他的エンティティと包括的エンティティの2つのタイプがあります。
コアエンティティ
コアエンティティ最も重要な企業情報オブジェクトを表します。 それらは、プライマリ、メイン、またはメインエンティティと呼ばれることもあります。 これらのエンティティは非常に重要であるため、企業の多くの部門で使用される可能性があります。 コアエンティティは再利用可能である可能性が高いため、時間をかけて同様のエンティティを探してください。 企業内では、コアエンティティを均一にモデル化する必要があります。 優れたモデラーは、このアプローチが非常に役立つと感じています。
コアエンティティは、独立している場合と依存している場合があります。 図2.1は、アイスクリーム会社のコアエンティティの例を示しています。 ICE CREAMエンティティは、企業の基本製品を表します。 SHOPエンティティは、製品の販売における流通チャネルまたは仲介業者の例です。
企業が順調に進んでおり、追加のSHOPを開くことが決定されたと仮定します。 SHOPエンティティの新しいインスタンスを追加するためにモデルを変更する必要はありません。 同じことがアイスクリームの本質にも当てはまります。
コアエンティティのICECREAMとSHOPに注意してください。 この例はやや単純に見えるかもしれませんが、コアエンティティモデリングの背後にある概念の力を示しています。
コアエンティティをスケーラブルで拡張可能なコンテナとしてモデル化する必要性を理解するには、モデラーは、現在の使用に関係なく、エンティティを抽象的な概念およびモデル情報として見る必要があります。 この例では、ICE CREAMエンティティモデルはSHOPエンティティのコンテキストから完全に外れており、その逆も同様です。 したがって、企業がインターネットや宅配などの新しい流通チャネルを通じてICE CREAMを販売することを決定した場合、他のエンティティを変更せずに新しい流通チャネルを追加できます。
コードエンティティ
コードエンティティ常に独立しています。 それらは、使用される方法に応じて、参照、分類子、またはエンティティタイプと呼ばれることがよくあります。 コードエンティティによって表される一意のインスタンスは、他のエンティティに属する属性値のスコープを定義します。 コードエンティティと他のエンティティの関係については、このトピックに関する次の出版物のいずれかで説明します。 コードシートで単一の属性を使用したくなるかもしれません。 コードエンティティには、識別子、名前（短い名前と呼ばれることもあります）、および定義の3つ以上の属性を含めることをお勧めします。
図2.2 上-独立したエンティティ（直角に注意してください）。 TOPは、コードエンティティまたは分類子でもあります。 TOPエンティティのインスタンス（文字列）は、使用可能なトップのリストを定義します。
コードエンティティには通常、限られた数の属性が含まれています。 これらのエンティティが1つの属性しか持たない実装があります。 人工識別子を使用してコードエンティティをモデル化することをお勧めします。 人工識別子は、名前と定義とともに、新しい種類のTOPをインスタンス（文字列）としてエンティティに追加できるようにします。 TOPエンティティの3つの属性に注意してください。
専門家は、コードエンティティを企業のビジネスオブジェクトと呼ぶことがよくあります。 エンタープライズビジネスオブジェクトという用語は、エンティティが単一のアプリケーション、システム、または組織単位のレベルではなく、企業レベルで定義および共有されることを示します。 これらのエンティティは、多くのデータベース間で共有されることが多く、要約レポートと傾向分析への全体的なアプローチを提供します。
米。 2.2。 コードエンティティを使用すると、企業は企業内で一元的に使用される一連の値を定義できます。 コードエンティティインスタンスは、モデルの他の部分で使用する値の範囲を定義します。
連想エンティティ
連想 2つ以上の他のエンティティの主キーを含むエンティティです。 連想エンティティは常に依存しています。 これらは、他のエンティティの多対多の関係を解決するために使用されます。 多対多の関係は、あるエンティティの多くのインスタンスが別のエンティティの多くのインスタンスに関連している場合に発生します。 連想エンティティを使用すると、2つのエンティティインスタンスの共通部分をモデル化して、連想の各インスタンスが一意になるようにすることができます。
図2.1では、連想エンティティを使用して関係を解決しています 多対多エンティティSHOPとICECREAMの間。 連想エンティティの導入により、各ストアで同じ種類のアイスクリームを販売する必要なしに、ストアの複数のコピーで同じアイスクリームを販売することが可能になります。 ICE CREAM SHOP連想エンティティは、SHOPインスタンスが多くのICE CREAMインスタンスを販売し、ICECREAMインスタンスが多くのSHOPインスタンスによって販売される可能性があるという事実を考慮に入れています。
特徴的なエンティティ
特徴的なエンティティ常に依存しています。 エンティティインスタンスがさまざまな属性のセットを格納することが理にかなっている場合は、特性エンティティを使用する必要があります。 Finklesteinは、特性エンティティをセカンダリエンティティと呼びます。 特性エンティティには、常に1つ以上の「ピア」エンティティがあります。 ピア特性エンティティは、排他的または包括的である可能性がある特別なタイプの関係によって親エンティティに関連付けられます。
図2.3は、エンティティCONTAINERと、特性エンティティHORNおよびGLASSを示しています。 アイスクリームショップは、明らかに、重量ではなく、個別に販売しています。 CONTAINERのインスタンスはCONEまたはCUPでなければならないことに注意してください。 CONTAINERは、同時にHORNとGLASSの両方になることはできません。 これらは排他的な特性エンティティです。
図2.3のPERSONエンティティには、EMPLOYEEとCLIENTの2つの特徴的なエンティティがあります。 排他的な特性エンティティでは、PERSONの単一のインスタンスにEMPLOYEEとCUSTOMERに共通のファクトを含めることができないことに注意してください。 当然、これは実際の慣行に反します。 従業員は間違いなく顧客になることができます。 サプライヤーは顧客としての役割を果たすこともできます。 これは、包括的特性エンティティの例です。
米。 2.3。 特徴的なエンティティPERSONとCONTAINERの2つの例。 どちらの例でも、ERwin IE表記を使用して、排他的および包括的特性エンティティを表します。 特性エンティティシンボルに（X）がない場合は、包括的関係を示します。
構造物
同じエンティティのインスタンスが関連している場合があります。 彼の1992年の本で 「戦略的システム開発」 K. Finklesteinは、同じエンティティのインスタンス間の関係を表すために構造エンティティを使用することを提案しました。 同じエンティティのインスタンス間の関係は、再帰的関係と呼ばれます。 漸化式については、「関係の概念」の記事で説明します。 再帰的な関係は論理的な概念であり、ユーザーはその概念を簡単に理解できません。
図2.4は、EMPLOYEEエンティティのインスタンス間の関係を説明する追加の構造エンティティを示しています。 この図は、エンティティPERSONの特性エンティティEMPLOYEEに2つの特性エンティティEXECUTORとMANAGERがあることを示しています。 EMPLOYEE STRUCTUREエンティティは、EMPLOYEEエンティティのインスタンス間の関係を表します。
米。 2.4。 構造的実体-漸化式の解決に対するK.フィンクルスタインのアプローチの図解。
主キーの定義
特定のエンティティインスタンスを識別するには、主キーを定義する必要があります。 主キーエンティティの単一のインスタンスを一意に識別する属性または属性のセットです。 つまり、主キーは1つの属性にすることも、複数の属性で構成することもできます。 複数の属性で構成される主キーは、複合キーまたはコンポーネントキーと呼ばれます。 以下では、この用語を使用します 複合キー。
主キーは静的で不揮発性でなければなりません。 静的で非破壊的であるということは、主キーを変更してはならないことを意味します。 主キーへの変更は維持が難しく、多くの場合、非常にコストのかかるやり直しが発生するため、主キーがエンティティインスタンスから完全に独立している場合が最適なオプションです。
主キーを見つけるには、エンティティを定義するデータを解析する必要があります。 通常、コアエンティティの主キーは、作業セッションとディスカッション中に決定されます。 ドメインの専門家とユーザーは、潜在的な主キーを選択するための優れた情報源です。 サンプルデータは、主キーを選択する際の貴重な情報も提供します。
キー候補と呼ばれるすべての潜在的なキー属性を識別することにより、主キーを識別するプロセスを開始します。 重要な候補は、単一の属性または複数の属性の組み合わせです。 候補キーが存在しない場合、または候補キーが大きすぎて扱いにくい複合キーである場合は、人工的な一意の識別子の使用を検討してください。 親エンティティから借用したキーは、外部キーと呼ばれます。 外部キーについては、このトピックに関する後続の出版物の1つで説明されます。 以下は、さまざまなタイプのキーの説明です。
- 主要な候補者。 重要な候補は、エンティティの単一のインスタンスを識別する属性または属性のセットです。 エンティティの単一のインスタンスは、複数の属性またはそれらの組み合わせによって識別される場合があります。
- 複合キー。 複数の属性で構成されるキーは、複合キー、複合キー、またはコンポーネントキーと呼ばれます。 複合キーの場合、キーの各コンポーネントには各インスタンスの値が必要です。 キーのどの部分もNULLであってはなりません。 キーのすべての部分が必須であり、省略できません。
- そして、人工的な主キー。 単一の属性も属性の組み合わせもインスタンスを定義しない場合があります。 このような場合、人為的な一意の識別子を使用しています。 人工主キーは、多くの場合、各インスタンスまたはコードに番号を付けるだけです。
- 外部キー。 あるエンティティの主キーが別のテーブルに移行する場合、それは外部キーと呼ばれます。 外部キーは、エンティティ間の関係を表すことによってエンティティを「リンク」します。 外部キーについては、このトピックに関する今後の記事で詳しく説明します。
モデルを第3正規形にすることには、機能依存性がないことを確認し、主キーまたは複合キーを識別することが含まれます。 この記事で説明されている機能の依存関係は、主キーとキー候補を識別する上で重要な役割を果たします。
エンティティの命名
エンティティに割り当てられた名前は、エンティティのインスタンスを特徴付ける必要があります。 名前は明確で、一般的に受け入れられている必要があります。 名前を選択するときは企業の観点を使用し、別のビジネスユニットではなく、企業内でのデータの使用方法を反映した名前を使用するようにしてください。 ユーザーコミュニティとドメインの専門家にとって意味のある名前を使用してください。
おそらく、開発中またはガイドとなるエンタープライズデータモデルを構築するときに使用する一連の命名規則が企業にあります。 規則を使用すると、誰が名前を作成するかに関係なく、名前が企業内で均一に作成されることが保証されます。 次のセクションでは、命名規則の初期セットを提供し、良い命名規則と悪い命名規則の例を示します。
エンティティの命名規則
ユーザーが少ない小規模な組織で作業している場合、命名規則は無関係に見える場合があります。 ただし、複数の開発チームと多数のユーザーがいる大規模な組織では、命名規則がコミュニケーションとデータ共有に大いに役立ちます。 理想的には、命名規則を一元的に開発および維持し、それを企業全体に公開して文書化する必要があります。
組織にまだ命名規則がない場合に備えて、命名規則の初期セットを作成するためのガイドラインを次に示します。
- エンティティの名前は、十分に説明的である必要があります。 広く使用されている概念の名前である場合にのみ、単一の単語の名前を使用してください。 名詞句の使用を検討してください。
- エンティティ名は、名詞または単数名詞に基づくフレーズである必要があります。 PERSONまたはPEOPLEの代わりにPERSONを使用し、CONTAINERSの代わりにCONTAINERを使用します。
- エンティティ名は一意である必要があります。 異なるデータを含むエンティティに同じ名前を使用したり、同じデータを含むエンティティに異なる名前を使用したりすると、開発者とエンドユーザーを不必要に混乱させることになります。
- エンティティ名は、各インスタンスに保存されるデータを示す必要があります。
- エンティティ名には、特殊文字（！、@、＃、$、％、＆、*など）を含めたり、所有権を示したりすることはできません（PERSONAL ICECREAM）。
- エンティティ名には、受け入れられている命名規則の一部でない限り、頭字語や略語を含めることはできません。
適切なエンティティ名の例
企業内では常に一貫した名前を使用することをお勧めします。 表2.1に、エンティティの良い名前と悪い名前の例を示します。
表2.1説明付きのエンティティ名の例
|
いい名前 |
悪い名前 |
説明 |
| 数学の公式 | 方式 | 数式-あいまいすぎて、形容詞MATHEMATICALを追加すると、意味がはるかに明確になります。 |
| 本 | BOOKS | BOOKは単数名詞です。 |
| ソファー | ソファー ソファー |
SOFAとCOUCHは同じ意味です。 一つを選ぶ。 |
| アイスクリーム | 少しのアイスクリーム | 代名詞SOMETHINGは、この用語に追加の意味や意味を追加しません。 不必要な追加は避けてください。 |
| 写真 | 画像 | 写真-間違いなく。 画像-ややぼやけています。 |
| 到着予定時間 | ORP | 略語OVPは、ユーザーを混乱させる可能性があります。 |
| 会社 | COMPANY XYZ | XYZは特定の会社インスタンスであり、COMPANYエンティティの文字列である必要があります。 |
エンティティの説明
エンティティに期待する情報をユーザーに伝える良い名前でさえ、通常は十分ではありません。 すべてのエンティティは、企業内で明確に解釈されるために、明確で正確かつ完全な説明または定義を必要とします。 事業体の説明は、事業体の意味と企業にとってのその意味を説明する必要があります。
説明、定義、および目的はしばしば同じ意味で使用されますが、ユーザーが理解できる用語でエンティティを説明することを奨励するため、説明という用語が好まれます。
適切な説明を作成するためのルール
エンティティの説明は、エンティティの情報がどのように使用されるかではなく、その意味を説明する必要があります。 エンティティの識別中にエンティティの説明を収集する必要があります。 使用情報を含める場合は注意してください。このような情報は、例として、または説明のためにのみ使用してください。 情報の使用方法は、情報自体よりも頻繁に変更されるため、使用情報は一定ではありません。
エンティティの説明は、明確、正確、完全かつ一貫している必要があります。 専門用語を使用せずに作成する必要があります。説明されている概念に少なくとも少し精通している人なら誰でも理解できます。 説明がビジネス用語であり、エンティティの価値の説明が含まれていることを確認してください。
良い説明の例
表2.2は完全であるとは主張していませんが、良い説明と悪い説明が主要なポイントを満たさない理由を示すのに役立ちます。
表2.2。 説明付きのエンティティの説明
|
良い説明 |
悪い説明 |
説明 |
| PERSONには、入社した個人に関する情報が含まれています 相互作用に 法人と。 情報 o PERSONは、企業の計画、製品開発、および販促活動を支援します。 |
クライアントまたは従業員。 | 適切な説明には、エンティティの定義と企業にとってのその意味が含まれます。 |
| 名前、生年月日などが含まれます。 人のために。 | エンティティの属性をリストするだけでは、エンティティが何であるか、およびそれが企業にとって重要である理由に関する追加情報は伝達されません。 | |
| クライアント情報 と従業員。 |
クライアントと従業員は、PERSONが果たすことができる役割の例です。 例だけを使用しても、エンティティが何であるか、またはそれが企業にとって重要である理由を説明することはできません。 | |
| エンティティには、抽出された文字と数値データが含まれています POS（Point Of Sale-トレーディングターミナル）から、標準の圧縮とパックされた10進数を使用して保存されます。 |
この人為的な例は、技術的な説明と略語がビジネスユーザーにとって理解しにくいことを説明することを目的としています。 |
エンティティモデリングとキー選択の一般的な間違い
一般的なモデリングエラーに関するこのセクションは、完全であるとは主張していません。 その目的は、モデラーが犯す最も一般的な間違いを指摘することです。
ロールモデリング
ロールモデリングとはどういう意味ですか？ 作業セッション中に、ユーザーは従業員に関する情報を保存する必要があるとあなたに言うかもしれません。 エンティティEMPLOYEEを作成したいという誘惑があります。 たとえば、名前、住所、社会保障番号など、企業が関心を持つ情報を詳しく調べると、これらの値はEMPLOYEEエンティティから独立していることがわかります。 特定のEMPLOYEEの場合、NAME属性の値はEMPLOYEEエンティティから独立しています。 これは、あなたが従業員であるかどうかにかかわらず、あなたの名前がまだあなたの名前であると考えると理解しやすいです。
エンティティのオーバーロード
エンティティに複数の概念オブジェクトに関する情報が含まれている場合、エンティティはオーバーロードされます。 エンティティの一部の属性が同じ概念を記述している場合は、それらのエンティティをチェックする必要があります。 オーバーロードされたエンティティには、すべての属性の値があるわけではありません。
企業内のさまざまな分野の専門家が、同じように聞こえ、綴りが同じであるが、専門家ごとに意味が異なるエンティティ名を使用する場合があります。 同じ名前が同じオブジェクトを記述していることを確認する唯一の方法は、記述を確認することです。 エンティティに単一の概念を説明するデータが含まれていることを確認してください。
たとえば、エンティティEQUIPMENTは、情報技術部門とマスメディアおよび通信部門でまったく異なる意味を持つ場合があります。
冗長エンティティ
冗長エンティティとは、名前は異なりますが、同様の概念に関する情報が含まれているエンティティです。 英語には同じことを表す多くの単語が含まれています。 このようなエンティティを見つける1つの方法は、同様の属性を含むエンティティを探すことです。 これらの各エンティティの説明を比較して、それらが類似した概念を表しているかどうかを判断します。 冗長なエンティティは、エンティティとしての役割をモデル化する傾向の結果として現れることがよくあります。
たとえば、エンティティMANAGERとEMPLOYEEは、どちらもPERSONエンティティのインスタンスが果たすことができる役割であるため、同様の情報を含む場合があります。
間違った主キーを選択する
間違った主キーを選択したということは、テストに耐えられない主キーを選択したことを意味します。 主キーに関連する一般的な間違いは次のとおりです。
- 非一意：主キーは、インスタンスごとに一意ではありません。 たとえば、モデラーは、社会保障番号が各人に固有であると考える場合があります。 ただし、元の所有者が亡くなった場合は、社会保障番号を再利用できます。
- 必要な値/不確実性：一部のインスタンスでは、主キーに値がありません。 たとえば、PERSONエンティティのすべてのインスタンスに社会保障番号があるわけではありません。 外国人と小さな子供はそれを逃す人々の2つのカテゴリーです。
不正なエンティティ名の使用
名前があいまい、あいまい、または不正確なため、新しいユーザーや開発チームが既存のモデルを再利用または拡張することは困難です。
名前の一部として略語や頭字語を使用しないでください。 略語や頭字語は誤解されやすく、主題分野によって意味が異なる場合もあります。
名前の一部として場所を含めないでください。 原則として、必然的に別の場所が必要になります。 場所のある名前は、エンティティクラスではなく特定のインスタンスをモデル化していることを示します。
不正なエンティティの説明の使用
辞書からのみ借用した説明は使用しないでください。 辞書の説明には、ビジネス関連の情報は含まれません。
エンティティ名を言い換えようとしないでください。 説明にエンティティの名前を使用しないでください。
あいまいな、あいまいな、またはさらに悪いことに、不完全な説明は、既存のモデルを再利用および拡張することを困難にします。 ユーザーは、エンティティに必要なすべての情報が含まれているかどうかを確認できなくなります。
これにより、過負荷のエンティティと、さまざまなオブジェクトに関する情報を格納するためのエンティティの使用のリスクが大幅に高まります。
新しい開発チームが既存のモデルの拡張を任されている場合、作業セッションのすべての参加者にとって明白に見える概念は、時間の経過とともにそれほど明白ではなくなる可能性があります。
結論
エンティティは、情報を蓄積および維持する必要があるオブジェクトです。 これらは、ビジネスファクトを整理およびグループ化するための「コンテナ」です。 最も重要なエンティティは通常、作業セッションまたはインタビュー中、および正規化プロセスの結果として識別および文書化されます。
エンティティは、依存と独立の2つの主要なグループに分けられます。 依存エンティティは、インスタンスを一意に識別するために他のエンティティからの情報を必要としますが、独立エンティティは必要ありません。 エンティティの2つの主要なグループ内で、より特殊なタイプが区別され、主要エンティティと従属エンティティ間の特定のタイプの関係をサポートする機能があります。
各エンティティには、候補キーである1つ以上の属性セットが含まれている必要があります。 主要な候補者は、特定のエンティティインスタンスを一意に識別します。 主要な候補は、単一の属性または属性のグループで構成されます。 キー候補が存在しないか、保守が難しい場合は、人工的な主キーを作成する必要があります。 分析と調査は、長期にわたって一意で信頼性の高い主キーを決定する上で重要な役割を果たします。
エンティティには適切な名前と説明が必要です。 命名規則と規則は、名前と説明を作成するための全体的なアプローチを提供します。 エンティティの特性は、エンティティに含まれる属性によって決まります。 エンティティ属性は、企業が蓄積および維持することに関心のあるエンティティに関する事実を表します。
このシリーズの次の記事では、属性とその特性を識別し、キー属性と非キー属性、スコープとオプションのデータを定義し、適切な属性名と説明を作成するための規則を作成するプロセスについて説明します。
パート2。属性の概念
「基本的なデータモデリングの概念」の記事では、データモデリングに関連する基本的な概念を紹介しました。 記事の中でERwin図の主なコンポーネント-エンティティ、属性、関係。 パート1。エンティティの概念には、エンティティとエンティティキーに関する初期情報が与えられました。 この記事では、属性について説明し、正規化とキーについて詳しく説明します。
この記事では、次の方法を学習します。
- 属性を明らかにする
- 属性分析中に正規化を実行します
- 属性の命名と説明、および属性の命名に関する規則について学習する
- スコープやブールデータ型などの属性タイプと特性を定義し、属性の観点からキーを検証します
- 属性を操作するときによくある間違いを避ける
ERダイアグラムでは、エンティティと関係は属性をグループ化して組み合わせるのに役立ちます。 モデルの本質を構成するのは属性です。 それでは、属性、つまり論理モデルの情報を構成する事実の調査を始めましょう。
属性とは何ですか？
属性は、企業が保持することに関心のある事実を論理的に表したものです。 ERwinでは、エンティティは属性の論理グループを視覚的に表すのに役立つことを思い出してください。 一方、属性は、論理モデル内のエンティティについて蓄積されたファクトを表します。 属性は、エンティティインスタンスの状態を識別、分類、数値化、またはその他の方法で説明するのに役立つファクトです。
属性は単一の概念を表す必要があります。 属性は、エンティティの各インスタンスを説明する論理グループを形成します。 特定の属性インスタンスは 意味。 たとえば、Nameという名前の属性は、PERSONという名前のエンティティに関するファクトのスコープを定義します。 Gabriel、RJ、Will、およびVanessaは、特定のPERSONインスタンスの特定の名前の意味の例です。 エンティティの各属性の特定の値は、単一のインスタンスを表します。
有効な属性モデルには、次の特性があります。
- 属性の値は、企業にとって重要です。
- 論理モデルには属性インスタンスが1つだけあります。
- 属性にはブールデータ型とスコープがあります。
- 属性値は、必須またはオプションとして定義されています。
- 属性には名前と説明があります。
- エンティティインスタンスごとに使用できる値は1つだけです。
Ice Cream Trade Corporation Betty Wilsonは、最も人気のあるフレーバーをより多く注文し、最も人気のないフレーバーをより少なく注文したいと考えています。 ベティの会社はアイスクリームスペシャルを行っており、スペシャル中にバナナのデザートとファッジにアイスクリームの顧客がどのフレーバーを選ぶかを知りたいと考えています。 ビジネス要件を満たすには、バナナデザートとファッジアイスクリームのフレーバーデータと日付を収集する必要があります。
図3.1には、BANANADESSERTとCREAMFENDERの2つのエンティティがあります。 各エンティティには、各料理のコンポーネントを表す属性が含まれています。 バナナデザートエッセンスは、バナナ、ホイップクリーム、チェリーの3種類のフレーバー、3種類のトップスをお選びいただけます。 CREAM FENDERの例では、2つのフレーバーとバナナ、ホイップクリーム、チェリーを選択できます。
米。 3.1。 2つの主要な概念を表すエンティティと属性：CREAMFENDERとBANANADESSERT
属性の検出
属性を識別するプロセスを開始するにはどうすればよいですか？ ほとんどの属性は、作業セッション中およびエンティティ定義中のインタビュー中に識別されます。 ドメインの専門家やエンドユーザーからの情報要件の分析は、属性を特定するための最良の情報源です。
企業モデルは、属性を強調するための優れた基盤でもあります。 エンタープライズモデルのエンティティと属性を、新しい論理モデルのエンティティと属性と比較します。 エンタープライズモデルには、各エンティティ、特にコアエンティティに対して以前に定義された属性があります。 属性がエンタープライズモデルに存在しない場合、追加の分析により、属性を追加する必要があるかどうか、または別のエンティティに属しているかどうかが判断されます。
情報要件に従った属性の順序付け
論理モデルの属性は、情報要件に厳密に準拠している必要があります。 モデルに存在する各属性は、1つ以上の情報要件を満たすために機能する必要があります。 モデルには、検討中のサブジェクトエリア内の企業が関心を持っている事実を表すために必要な属性のみを含める必要があります。
企業の観点から関心のあるすべての事実は、論理モデルで正確かつ完全に表現される必要があります。 情報要件は、属性を強調表示する必要があるかどうかの尺度として機能します。 属性と情報要件の関係を文書化すると役立ちます。
属性分析
各属性を分析して、モデル内の他のすべての属性との関係を判断する必要があります。 正しく実行された分析により、各属性が単一のインスタンスでモデルに存在し、3番目の正規形に従ってエンティティに配置されることが保証されます。
各主キーと複合主キーの各部分を解析して、それらの値が各エンティティインスタンスに存在することを確認することが特に重要です。 また、主キーが1つのエンティティインスタンスのみを識別することを確認する必要があります。
分析により、企業が属性自体に関する情報の蓄積と維持に関心があるかどうかを判断することもできます。 属性が非常に重要で、その属性に関するデータを格納するために追加の属性が必要な場合は、新しいエンティティを作成する可能性について検討する必要があります。
論理モデルの各属性を分析して、各属性が単一のインスタンスのモデルに存在し、各エンティティインスタンスに1つの属性値のみが存在することを確認する必要があります。 正規化ルールを使用して適切なエンティティに属性を配置し、その特性を定義する必要があります。
1つだけ残しておく必要があります
属性は、単一インスタンスの論理モデルに存在する必要があります。 「1つの場所に1つの事実」（日付、1986年）。 各ファクトが単一の属性で表されていることを確認するには、類似した名前または説明を持つ属性を確認してください。 さらに、属性が実際のインスタンスなのか、モデル内で異なる属性によって誤って表されている特定の値なのかを判断する必要があります。
名前と説明が類似している属性は、実際には同じ概念を表す場合があり、同じ属性で表す必要があります。 自然言語では、同じ単語がいくつかの概念を表すことができます。 しかし、さらに悪いことに、英語では、同じ概念を表すためにいくつかの異なる単語が存在する可能性があります。
名前の一部に「indicator」または「flag」が含まれている属性は、属性のスコープからの特定の値を表している可能性があります。 具体的な値は属性インスタンスです。 モデルで属性インスタンスを使用することはよくある間違いです。 たとえば、「黒髪インジケータ」の値は、黒髪が存在する場合は「はい」、黒髪が存在しない場合は「いいえ」です。 モデルで「髪の色」属性を使用することをお勧めします。この属性は、特定の値「黒」を持つことができます。
属性は、1つのビジネスコンセプトのみを表す必要があります。 同じエンティティインスタンスに対して複数の値を含めることはできません。 図3.1は、BANANADESSERTとCREAMFENDERの2つのエンティティを示しています。 両方のエンティティには、「特別オファーの開始日または終了日」という名前の複数値の属性が含まれています。 属性名は、その値が特別オファーの開始日または特別オファーの終了日を表すことができることを示しており、それらを区別する方法はありません。 この属性は2つに分割する必要があり、それぞれが1つのファクトを表します。
属性に複数の値を許可すると、密接に関連する「非表示」属性につながる可能性があります。 前の例はかなり明白です。 すべての複数値属性をそれほど簡単に変換できるわけではありません。 コメントやメモなどのテキストを含む属性に、テキストに隠されている多くの重要な属性値があることに驚かれるかもしれません。
正規化：対応するエンティティに属性を配置する
属性は、論理モデルに存在するエンティティの数を3番目の正規形に減らすことを定義します。 正規化プロセスは、属性の相互依存性と属性の主キーへの依存性を分析することで構成されます。
適切に実行された正規化により、適切なエンティティに属性を配置することにより、モデルがスケーラブルで拡張可能になります。
論理モデルを第3正規形にすることは、多くの場合、新しいエンティティの出現につながります。
正規化のその他の利点は次のとおりです。
- 冗長性を排除または最小化します。 冗長データは、同じ概念を表すが異なる名前の属性、または繰り返しグループに存在する場合があります。 各ファクトを1つの場所に一度表示すると、冗長性が最小限に抑えられます。
- 挿入、削除、または更新するときの異常を排除または最小化します。 非正規化されたデータ構造により、同じファクトが複数の場所に存在し、主キーに部分的または部分的に依存する可能性があります。 挿入、削除、または更新の異常はデータの不整合であり、これらの条件下では、データアクセスに驚きや不正確さが生じる可能性があります。
- 属性へのnull値の使用を排除または最小限に抑えます。 重複する属性グループには、多くの場合、null値が含まれることがよくあります。これは、一部のエンティティが複数の値を持つことができ、他のエンティティは持つことができないという事実を表すためです。 null値のインスタンスを含むエンティティが存在すると、データ構造がまばらになります（まばらになります）。
モデルが第3正規形にキャストされると、各属性は対応するエンティティに属します。 モデルを第3正規形にすると、多くの場合、新しい属性とエンティティが明らかになります。
機能従属性
関数従属性は、モデル内の属性間の関係を記述するために使用されます。 各エンティティ属性は、エンティティの主キーに機能的に依存している必要があります（他のモデル属性に機能的に依存してはなりません）。 そうでない場合は、この規定が尊重される新しいエンティティに属性を移動する必要があります。
属性間の機能的な関係を判断するには、まず属性を共通のテーマを共有するセットにグループ化します。 類似性の観点からトピックを注意深く分析します。 トピック内の属性をチェックして、トピック内の属性の機能依存性があるかどうかを判別します。 属性または属性のグループがエンティティの主キーに依存しない場合は、別のエンティティに移動する必要があります。
同じトピックに属する属性は冗長である可能性があります。 冗長属性は、単一のエンティティにグループ化することも、親エンティティの特性エンティティとしてより高いレベルの一般的な抽象化を使用することもできます。 図3.1には、少なくとも2つの共通のテーマがあります。 上。 これらの属性は、他のエンティティに転送するための適切な候補です。 関数従属性の観点からそれらを考えてみましょう。 属性値 フレーバー添加剤アイスクリームは主キーの値に依存しません- バナナデザートの材料。 キーについても同じことが言えます。 クリーミーなファッジ.
図3.2は、ソリューションを示しています。 アイスクリーム用香料添加物と 上それらの値が主キーに依存するエンティティで強調表示されます。 このソリューションは、いくつかの明らかな冗長性の問題を修正します。
第一正規形
第一正規形にキャストするということは、重複するすべての属性を別のエンティティに移動することを意味します。 重複する属性は、次のように単純に番号が付けられることが多いため、簡単に見つけることができます。 トップ1と トップ2また 味1と 味2。
重複する属性を表す一連の属性を含む依存エンティティを作成します。 依存エンティティの主キーは、親エンティティの主キーと、一意性を確保するための少なくとも1つの追加属性を含む複合主キーになります。
図3.2では、繰り返されるグループが移動されています アイスクリーム用香料添加物と 上従属エンティティに。 エンティティTASTEの作成に注意してください。
米。 3.2。 冗長な属性を排除する
2番目の正規形
第2正規形に変換することは、冗長な属性を削除することを意味します。 冗長属性には次のものがあります。
- 同じ概念を表すさまざまな属性
- 同じトピックに関連するさまざまなエンティティの属性
- 各エンティティインスタンスの値を持たない属性
同じ概念を表す属性は、単一の属性に変換する必要があります。 冗長属性は、エンティティインスタンスごとに値を持たない可能性があるため、それらの存在は主キーの値に依存しません。 これらの属性をエンティティに移動します。エンティティには、各インスタンスの値が含まれます。
冗長属性を表す属性を持つエンティティを作成します。 新しいエンティティには、単一のインスタンスを識別する主キーがあります。 この主キーは、元のエンティティの外部キーになります。 外部キーについては後で説明します。
図3.2は、BANANADESSERTおよびCREAMFANDYエンティティのいくつかの冗長属性のソリューションを示しています。 2つのコアエンティティの観点から冗長性を検討してください。 どちらのエンティティにも共通のテーマがあります。アイスクリームのフレーバーとトップです。 これは、コアエンティティをより高いレベルの抽象化で組み合わせることができることを示しています。
図3.3は、MIXという名前のスーパータイプの作成を示しています。このスーパータイプの実装は、BANANADESSERTとCREAMFENDERです。 MIXがBANANADESSERTエンティティまたはCREAMFANDYエンティティのインスタンスであるかどうかを識別するために、MIX親エンティティに「ブレンドタイプ」分類属性を追加しました。 MIXエンティティのインスタンスは、BANANADESSERTまたはCREAMFANDYエンティティのインスタンスにすることができますが、両方にすることはできません。
米。 3.3。 共通の属性をより一般的なMIXエンティティに移動することで、コアエンティティの冗長性が排除されました。 主キー「MixID」は、BANANADESSERTエンティティとCREAMFENDERエンティティの両方に配置されていることに注意してください。
3番目の正規形
第3正規形にキャストするということは、主キー以外の属性の値に依存する属性を削除することを意味します。 これは、推移的な依存関係と呼ばれることもあります。
新しいエンティティを作成し、元のエンティティの主キーから独立している属性をそのエンティティに移動します。 一意性が保証されるように、新しいエンティティの主キーを定義します。
図3.3では、属性 ホイップクリームと チェリー BANANADESSERTおよびCREAMFANDYエンティティの主キーに依存しないでください。 実際、属性がそうでないかどうかを判断する必要があります ホイップクリームと チェリー TOPエンティティのインスタンス。
図3.4では、追加のBlend Date属性に注目してください。これは、MIXエンティティがいつインスタンス化されたかに関する情報を提供します。 BANANADESSERTエンティティとCREAMFANDYエンティティから開始日属性と終了日属性を削除しました。 新しいSPECIALOFFERエンティティには、これら2つの日付と、オファーの対象となるアイスクリームのタイプを示すIceCreamFlavour属性が含まれるようになりました。
米。 3.4。 各属性は、主キー、完全な主キー、およびキー以外の何物にも依存しません .
属性特性の定義
属性は2つのグループに分けられます。 属性はキーであるか、そうでないかのどちらかです。 図3.5は、MIXエンティティの論理モデルの主要な属性を示しています。 基本的に、主キー属性はエンティティ内の線より上にあり、残りの属性は線より下にあることに注意してください。
米。 3.5。 主キーの一部ではないすべての属性は、本質的に区切り文字の下にあります。 これらは、キー候補、外部キーと代替キー、および単純な属性にすることができます。
主な属性
キー属性は、その値が他の属性の値を決定する属性です。 キー属性の値は、他の属性の値に依存しません。 キーは、単一の属性で構成されている場合と、複数の属性で構成されている場合があります。 これらの属性は、主キー、複合主キー、キー候補、外部キー、または代替キーにすることができます。
主キー属性
主キーが単一の属性であるかグループであるかにかかわらず、その値は他のすべての属性の値を決定します。
優れた主キーには、次の機能があります。
- この値は、各インスタンスの一意性を保証します
- 意味には隠された意味はありません
- 値の範囲は時間の経過とともに一定のままになります
- エンティティインスタンスごとに値が存在します
人工主キー
人工主キーは、エンティティの特定のインスタンスを識別することのみを目的として作成された属性です。 場合によっては、エンティティインスタンスを一意に識別する属性またはグループがありません。 その他の場合、複合主キーは扱いにくく、保守が困難です。 人工主キーは、疑似キーまたはシステム生成キーと呼ばれることもあります。 これは、その目的を示す人工的な一意の識別子としても知られています。
人工主キーは、多くの場合、各エンティティインスタンスの単純な連続番号付けによって形成されます。 このような人工キーの追加の利点は、一意性を保証する以外に、それらに関連付けられたエンティティインスタンスの意味を気にする必要がないことです。 実際、この方法で作成された人工主キーは、優れた主キーの特性を備えていることが保証されています。
図3.5の主キーのほとんどは人工的なものであることに注意してください。 ほとんどの場合、主キーは各インスタンスの一意の番号です。
主な候補者
重要な候補は、エンティティの特定のインスタンスを識別する属性または属性のグループです。 キー候補は、エンティティの特定のインスタンスを識別するための潜在的な主キーを決定するためのメカニズムを提供します。
主キーとして選択されていないキー候補は、代替キーとも呼ばれます。 代替キーは、インデックス作成に使用できる属性または属性のグループです。
外部キー
外部キーは、別のエンティティの主キーを構成する属性または属性のグループです。 外部キーは、関連エンティティのキー属性である場合とそうでない場合があります。 関連エンティティという用語に注意してください。 外部キーはエンティティ間の関係を表します。これについては、次の記事で詳しく説明します。
主キー属性の移行
外部キー属性は、リレーションシップを通じてそのエンティティに移行された別のエンティティの主キーの属性です。 外部キーは、識別または非識別のいずれかになります。 外部キーの識別は、移行先のエンティティの主キーの一部になります。 非識別外部キーは非キー属性になります。
非キー属性
非キー属性は、その値が主キーまたは複合主キーの値に依存する属性です。 これらの非キー属性は、キーの値、完全なキー、およびキー以外の何物にも依存しない必要があります。
彼の本の中で 戦略的システム開発 K. Finklesteinは、いくつかのタイプの非キー属性を定義しています。
- 選択属性は、キーが一意でない場合にエンティティの単一インスタンスを識別するために使用される属性です。 二次キーとも呼ばれます。
- グループ属性-より詳細な属性のグループを組み合わせた属性。
- 繰り返しグループ属性は、エンティティ内の同じ属性の複数のオカレンスを表す属性です。
- 派生属性は、その値が他の属性の値から派生した属性です。
- マスターデータ属性は、選択的、グループ化、繰り返しグループ、または派生属性ではない属性です。
選択的、グループ化、および繰り返しグループ属性は、第3正規形論理モデルに存在してはなりません。 エンティティの単一のインスタンスを識別するために必要な場合、選択属性は主キーの一部になる必要があります。 グループ属性は複数値です。 私の意見では、グループ属性は、モデル内でコードまたは分類エンティティとして最もよく表されます。 上記のように、繰り返しグループは従属エンティティにレンダリングする必要があります。
第3正規形では、非キー属性は単純（基本）または派生属性である必要があります。
単純な属性
単純な属性は、分解の結果として最高レベルの詳細がもたらされた属性であり、したがって、それらの値は主キーに完全に依存し、エンティティインスタンスごとに定義されます。 これらは選択基準ではなく、エンティティをグループ化するために使用することはできません。 それらは、企業が関心を持っている単純な原子的事実を表しています。
派生属性
派生属性は、その値が1つ以上の他の属性の値から派生または計算された属性です。 論理モデルにおける派生属性の存在の許容性の問題は活発に議論されています。 一部の専門家は、派生属性値はソース属性値に依存するため、派生属性は論理モデルで表現されるべきではないと考えています。
論理モデルは、情報の要件を完全かつ正確に表すことを目的としています。 使用要件に応じて、物理モデルレベルで属性を導出することを決定できます。
派生属性を除外するための引数は理解できますが、論理モデルは、すべての属性の名前と説明を入力するのに最適な場所です。 したがって、論理モデルに派生属性を含めることが望ましいです。 ただし、モデラーは、派生属性を主キーとして、または複合主キーの一部として使用することは控えてください。 また、派生属性の説明に推論規則を含めることを忘れないでください。
属性のスコープを見つける
属性のスコープは、属性が特定のエンティティインスタンスで取ることができる許可された値のリストを定義します。 スコープには、少なくともジェネリックデータ型のスコープが含まれ、ユーザーが指定したスコープが含まれる場合があります。 完成した論理モデルで、各属性のスコープを見つける必要があります。
属性のスコープには少なくとも2つの値が含まれている必要があると言えます。 常に1つの値のみが許可される属性は、モデルに正しく表示されない可能性があります。 図3.5には、バナナとファッジの2つの属性があります。
BANANADESSERTエンティティにはBanana属性があります。 ビジネスルールでは、BANANADESSERTエンティティの各インスタンスにバナナが含まれていると規定されています。 したがって、Banana属性は1つの値しか持つことができず、おそらく必要ありません。 代わりに、BANANA DESSERTエンティティの説明には、バナナがそのすべてのインスタンスに含まれていることを記載する必要があります。 CREAMYFENDERエンティティのFudge属性についても同じことが言えます。
表3.1は、MIX論理モデルのSPECIALOFFERエンティティの論理データ型のドメインを示しています。
表3.1。 ブールデータ型の例
単純および拡張データ型の範囲
データ型スコープは、属性値がどのように表されるかを決定します。 完全な論理モデルでは、属性ごとにデータ型スコープが必要です。 次のリストは、ERwinブールデータ型の例を示しています。
- 日時-日時
- 番号-番号
- 文字列-文字列
新しいデータベースプラットフォームの多くは、より高度なデータ型をサポートしています。 ただし、これらの複雑なデータ型は、いくつかの例外を除いて、プラットフォームに依存することを覚えておくことが重要です。 いずれの場合も、ユーザーが属性を必要とする場合は、データ型に関係なく、その属性をモデルに含める必要があります。 広く使用されている拡張データ型のいくつかを以下に示します。
- 画像-画像
- 音-音
- ビデオ-ビデオ
ユーザー定義のスコープ
ユーザー提供のスコープは、属性に許可されている値のセットを改良する特殊なスコープです。 これらのスコープは多くの場合組織固有であり、企業内で一貫して定義および使用する必要があります。 たとえば、スコープデータ型がNumberの属性には、ユーザーが入力したスコープを設定して、可能な値を1〜100に制限することもできます。整合性の原則により、企業は1つのエンティティに変更を加えてスコープを拡張できます。使用する属性ごとに。
オプションの属性の定義
属性値は必須の場合と必須でない場合があります。 値が必要な場合、または必要な場合は、インスタンスの作成時に値が存在している必要があります。 値がオプションの場合、値なしでインスタンスを作成できます。
本の中で 情報工学：戦略的システム開発 K. Finklesteinは、一連の「編集ルール」を通じて属性の必須プロパティを定義します。
- 一度に追加しますので、後から変更することはできません。
- すぐに追加され、後で変更されます。
- 後で追加、後で変更。
- 後で追加され、後で変更することはできません。
オプションの属性に注意してください。 属性または属性のセットにエンティティの特定のインスタンスの値しかない場合は、各インスタンスの値が存在するエンティティに移動することを検討してください。
表3.2に、SPECIALOFFERエンティティの属性の必須プロパティを示します。 SPECIAL OFFERエンティティをインスタンス化する場合、Special OfferEndDate属性を除くすべての属性に値が必要であることに注意してください。
表3.2。 属性必須の例
表3.2は、SPECIALOFFERエンティティのインスタンスには次の情報が必要であるというビジネスルールを示しています。
- エンティティID（特別オファーID）
- スペシャルオファーフレーバーID（アイスクリームIDとフレーバーID）
- 特別オファー開始日（特別オファー開始）
SPECIALOFFERエンティティの各インスタンスの終了日はオプションです。 ビジネスルールでは、特別オファーには開始が必要ですが、終了が必要ではないと規定されています。
値が必須である属性は、空の値を持つことはできません。 一部の専門家は、エンティティのすべてのインスタンスに値が必要であると考えています。 当然、インスタンスが作成される前に、エンティティインスタンスの各属性の値が検出または認識されていると想定します。
値がオプションである属性は、空の値を持つことができます。 一部の専門家は、属性の値が各インスタンスで利用できない場合、属性はエンティティに存在してはならないと考えています。 1つの理由は、空の値を解釈するのが難しいことです。 空の値は、その値がインスタンスに不明であることを意味しますか、それとも単に受信されていないことを意味しますか？
|
属性の命名
各属性には、明確で正確で一貫性のある名前を付ける必要があります。 属性名はその説明と競合してはなりません。 属性名は、属性インスタンス用に収集された値を参照する必要があります。 属性名は理解可能であり、企業によって一般的に受け入れられている必要があります。
企業内で開発した、または企業データモデルを作成したときに、企業内に一連の属性命名規則がある可能性があります。 属性の命名規則を使用すると、名前の作成者に関係なく、企業内で名前が均一に作成されます。
小規模な組織でも大規模な組織でも、属性の命名規則は重要です。 ただし、複数の開発チームと多数のユーザーがいる大規模な組織では、命名規則が基本データの相互作用と理解に大いに役立ちます。 理想的には、属性の命名規則を一元的に開発および維持してから、それらを文書化して企業全体に公開する必要があります。
組織にまだ属性の命名規則がない場合に備えて、属性の命名規則の初期セットを作成するためのガイドラインを次に示します。
- 属性名は十分に説明的である必要があります。 オブジェクト/修飾子/クラスの形式で名詞句を使用することを検討してください。
- 可能な限り、属性名にはエンティティの名前を含める必要があります。 「名前」だけでなく「人の名前」を使用します。
- 属性名は、属性の特定のインスタンスの値を参照する必要があります。 異なるデータを含む属性に同じ名前を使用したり、同じデータを含む属性に異なる名前を使用したりすると、開発者とエンドユーザーを不必要に混乱させることになります。
- 属性名は、データシート言語ではなくビジネス言語を使用する必要があります。
- 属性名には、特殊文字（！、@、＃、$、％、l、＆、*など）を含めたり、所有権（個人に属する名前）を示したりすることはできません。
- 受け入れられている命名規則の一部でない限り、属性名に頭字語や略語を含めることはできません。
モデラーは、適切な命名規則が存在する場合はそれを使用し、存在しない場合はそれらを開発することが望ましいです。
Object / Modifier/Classの形式の属性名
オブジェクト/修飾子/クラス形式は、属性に名前を付けるための業界全体の規則です。 この規則では、3つの部分からなる属性名の使用を推奨しています。 オブジェクトの一部は、サブジェクトまたはメインワードと呼ばれることもあります。 エンティティの名前は通常、オブジェクトとして使用されます。
修飾子は、単一の用語または用語のグループにすることができます。 標準の修飾子のリストはありませんが、モデラーは短くて意味のある修飾子を作成することが望ましいです。 修飾子を使用すると、わかりやすく意味のある属性名を作成できます。 企業の要求に応じて、名前がユーザーにとって許容できないほど重いものになったり、広く使用されたりした場合は、三音節の属性名を削除することで妥協することができます。
属性名の基本部分は、属性が表す情報のタイプを定義するクラスです。 一般的に使用されるクラス：
- 識別子
- 番号
- 価値
- 量
- 周波数
属性名の例
企業内では、一貫した属性名を使用することをお勧めします。 表3.3に、属性の良い名前と悪い名前の例を示します。 属性名の単語はスペースで区切られ、大文字で始まり、残りは小文字であることに注意してください。
表3.3。 説明付きの属性名
|
いい名前 |
悪い名前 |
説明 |
| 人の名 （人の名前） |
名前 （名前） |
Name（Name）-クラスの名前であり、Personオブジェクト（person）とFirst修飾子（first）を指定する必要があります。 |
| アイスクリーム販売数量 （アイスクリーム販売数量） |
売上高 （売上高） |
数量（数量）-クラスの名前であり、最後の場所にある必要があります（英語版の属性名）。 「the」と「of」は特別な意味を追加しません。 |
| アイテムコスト額 （位置値値） |
アイテムのコスト （位置値） |
「of」は特別な意味を追加しません。 クラス名「Amount」は、属性に何を含めるかをユーザーに指示します。 |
| 製品識別子 （製品番号） |
製品識別子 （製品ID） |
「識別子」は複数形です。 属性名は単数名詞でなければなりません。 |
| POSロケーションコード |
POSコード （POSコード） |
「POS」は略語です。 使用するクラス名「Code」（コード）には修飾子が必要です。 |
| 人の誕生日 （本人の生年月日） |
誕生日 （誕生日） |
誕生日（Birthday）には、クラスDate（Date）の名前は含まれていません。 修飾子とオブジェクト名を含めると、属性名の意味が明確になります。 |
属性の説明
属性の説明は、属性の使用方法ではなく、属性の意味の簡単な説明である必要があります。 属性の説明は、その名前と矛盾してはならず、名前の単純な繰り返しであってはなりません。 データを正確に説明するには、クレーム内のクラスとオブジェクトの名前を使用します。 属性が表示または計算される場合は、推論規則または計算式を含めます。 次のルールが属性の説明に適用されます。
- 属性の説明は、明確で、完全で、明確である必要があります。
- 属性の説明はその名前と一致する必要があります。
- 属性の説明は、別の属性の説明に依存してはなりません。
- 属性の説明は、技術的な説明の言語ではなく、ビジネスの言語である必要があります。
- 属性の名前は、その使用方法ではなく、その意味を反映している必要があります。
- 属性の説明では、その名前に使用されているすべての略語と頭字語を解読する必要があります。
モデラーは、各属性について適切な説明を提供することをお勧めします。 優れた属性の説明により、誰もがモデルを簡単に使用できます。 優れた開発者によって作成されたモデルを使用する人は、モデル内の明確な情報要件の喜びを体験します。 表3.4の例を比較してください。
表3.4。 属性名と説明と説明
|
属性名 |
良い説明 |
悪い説明 |
説明 |
|
人の名 （人の名前） |
企業が友好的な言葉でその人とコミュニケーションをとることができる人の名前。 |
長さが40文字のフィールド。 |
ビジネス言語は使用されません。 適用される専門用語。 |
|
アイスクリーム販売数量 （アイスクリーム販売数量） |
特定の販売イベントで販売された特定の種類のアイスクリームの量。 |
販売量。 |
新しい意味を追加するのではなく、あいまいな用語で属性名を言い換えるだけです。 |
|
アイテムコスト額 （位置値値） |
特定の期間における特定のポジションの値。 売上と送料の合計を表します。 |
小数点以下2桁の6桁の10進数。 |
技術的な説明が多すぎます。 アイテムのユーザーにはほとんど何の意味もありません。 |
|
製品識別子 （製品番号） |
特定の製品の人為的な一意の数値識別子。 |
製品識別子。 |
属性名の簡単な言い換え。 |
|
POSロケーションコード （POSロケーションコード） |
POSの地理的位置を識別する一意のコード。 |
使用されている頭字語は、ユーザーには明確でない場合があります。 また、重要な修飾子は説明から省略されています。 |
|
|
人の誕生日 （本人の生年月日） |
人の生年月日。 |
人の誕生日。 |
説明では、クラス名「date」が省略されています。 |
属性を操作する際のよくある間違い
一般的な属性モデリングの間違いに関するこのセクションは、完全であるとは主張していません。 その目的は、モデラーが犯す最も一般的な間違いを指摘することです。
時々、特定の方法で何かをモデル化するとき、モデラーは非常に正しい原則に導かれて意識的な選択をします。 決定の因果連鎖全体とそれらが導くことができる結果を理解することは非常に重要です。
価値観によるモデリング
値の観点からモデリングとはどういう意味ですか？ 作業セッション中に、ユーザーは、PERSONエンティティインスタンスの年齢カテゴリを示す一連の属性が必要であると言う場合があります。 このシナリオには、少なくとも3つの問題があります。
- 企業が年齢カテゴリを定義する方法は、時間の経過とともに変化する可能性があります。
- 特定の人の年齢は時間とともに確実に変化します。
- すべての属性は属性値を表します 人の年齢。 当然、 人の年齢時間の経過とともに変化するため、モデルで単純な属性を使用するのが最善の解決策です。 人の生年月日。
多値属性のモデリング
複数値の属性は、概念に対して複数の値を持つ属性です。 同じ概念の複数の値を示す属性の説明を確認してください。
企業内のさまざまな分野の専門家が、同じスペルと発音の属性名を使用することがありますが、専門家ごとに意味が異なります。 同じ名前の属性が同じオブジェクトを記述していることを確認する1つの方法は、記述を確認することです。 属性値が単一の概念を記述していることを確認してください。
たとえば、1つまたは複数のコードを接続して、以前は無関係だったデータをリンクすることにより、人工的なコードを作成できます。 テキストスニペットは、多くの貴重な属性と値を隠すことができます。
複数値の属性を解決できないと、いくつかの重要なビジネスルールが検出されず、文書化されないままになる可能性があります。
冗長属性のモデリング
冗長属性とは、名前は異なるが、類似した概念に関する情報を含む属性です。 すべての言語で、同じことを表す多くの単語があります。 冗長な属性を見つける1つの方法は、類似した属性を持つエンティティを調べることです。 すべての属性の説明を比較して、これらのエンティティに同様の概念に関するデータが含まれているかどうかを確認します。 冗長な属性は、多くの場合、値を属性としてモデル化する傾向の結果です。 たとえば、MANAGERエンティティとEXECUTORエンティティには、ManagerName属性とExecutiveName属性を含めることができます。 MANAGERとEXECUTORはどちらも、PERSONエンティティのインスタンスが機能できるロールであるため、この属性をそこに移動して、PERSONNameという名前を付けることができます。
属性に不正な名前を使用する
属性名が不明確、あいまい、または不正確であると、新しいユーザーや開発チームが既存のモデルを再利用または進化させることが困難になります。
属性名の一部として略語や頭字語を使用しないでください。 略語や頭字語は誤解されやすく、主題分野によって意味が異なる場合もあります。
特定のインスタンスの値を指す適切な名前を使用しないでください。 固有名を使用する属性名は、不適切な命名を超えた深刻なモデリングの問題の指標です。 属性名の一部として場所を含めないでください。 ある場所に値が存在する場合、それは別の場所にも確実に存在します。 場所を含む属性名は、クラスではなく特定のインスタンスをモデル化していることを示します。
属性に不適切な説明を使用する
辞書からのみ借用した属性の説明は使用しないでください。 辞書の説明には、属性を企業にとって重要にするビジネス関連の情報は含まれません。 属性名の単純な言い換えは使用しないでください。 説明に属性名を使用しないでください。
属性のあいまいであいまいな説明、またはさらに悪いことに、属性がないため、既存のモデルを再利用または進化させることが困難になります。 ユーザーは、モデルにすべての情報要件が含まれていることを確認できなくなります。 また、モデルの属性の代わりに具体的な値と複数値の属性を使用する可能性が高くなります。
新しい開発チームが既存のモデルに基づいて構築することを任されている場合、作業セッションのすべての参加者に明白に見える概念は、時間の経過とともにそれほど明白ではなくなる可能性があります。
結論
エンティティは、企業が情報の蓄積と維持に関心を持っている事実です。 それらはモデルの本質を構成し、主に作業セッション中に明らかになります。 モデル内の属性を完全かつ正確に反映するには、属性が情報要件に正確に一致することを確認するために注意深い分析が必要です。 属性は、単一のインスタンスのモデルに存在する必要があり、単一のビジネスコンセプトを表す必要があります。 適切なエンティティに属性を配置するには、正規化ルールを使用する必要があります。
属性には、キーまたは非キーを指定できます。 キーは、単一の属性または属性のグループにすることができます。 主キーは、エンティティインスタンスを一意に識別するキー候補から選択されます。 主キー属性は元のエンティティから移行して、二次エンティティの外部キーになります。 非キー属性の値は、主キーの値に機能的に依存している必要があります。
スコープは、属性値のセットを定義します。 論理スコープは、数値や文字列などの単純なデータ型にすることができます。 また、企業の特定の要件を満たすように調整された複雑なユーザー定義のデータ型にすることもできます。 新しいDBMSは、画像や音声などの拡張データ型をサポートしています。
属性値は必須またはオプションです。 値が必須の場合、属性にnull値を含めることはできません。 属性には名前と説明が必要です。 属性に名前を付けるときは、オブジェクト/修飾子/クラスの形式で名前付け標準を使用することをお勧めします。 各属性には、属性の使用方法ではなく、ビジネス用語を使用して属性の性質を定義する適切な説明を含める必要があります。