リレーションシップとPower Pivotダミー

Power Pivotを使用するには、専門家のデータベースモデラーである必要はありません。しかし、関係を理解することが重要です。データがデータベースに格納され、どのように管理されるかを理解すればするほど、Power Pivotをより効果的に活用してレポートを作成できます。

関係 は、別々のテーブルが互いに関連するメカニズムである。リレーションシップはVLOOKUPと考えることができます。この場合、あるデータ範囲のデータを、インデックスまたは一意の識別子を使用して別のデータ範囲のデータに関連付けることができます。データベースでは、関係は同じことをしますが、数式を書くのは面倒ではありません。 <！ - 1 - >

作業のデータの大部分が多次元の階層構造に適合しているため、関係が重要です。たとえば、製品を購入する顧客を示す表があるとします。これらの顧客は、請求書番号のある請求書が必要です。これらの請求書には、購入したものを列挙した複数行の取引があります。そこに階層が存在します。今、1次元スプレッドシートの世界では、このデータは通常、ここに示すようなフラットなテーブルに格納されます。

<！ - 2 - >

データは、フラットテーブル形式を使用してExcelスプレッドシートに格納されます。

顧客は複数の請求書を持っているため、顧客情報（この例ではCustomerIDとCustomerName）を繰り返す必要があります。これは、そのデータを更新する必要があるときに問題を引き起こします。

たとえば、Aaron Fitz Electrical社の名前がFitz and Sons Electricalに変更されたとします。テーブルを見ると、複数の行に古い名前が含まれていることがわかります。古い会社名を含むすべての行が変更を反映するように更新する必要があります。欠けている行は、適切な顧客に正しくマップされません。

<！ - 3 - >

顧客の名前と情報を一度だけ記録する方が論理的で効率的ではないでしょうか？次に、同じ顧客情報を繰り返し記述するのではなく、単純に顧客参照番号の形式を使用することができます。

これは関係の背後にあるアイデアです。顧客を請求書から分離し、それぞれを独自のテーブルに配置することができます。次に、一意の識別子（CustomerIDなど）を使用してそれらを関連付けることができます。

次の図は、このデータがリレーショナルデータベースでどのように見えるかを示しています。データは、Customers、InvoiceHeader、およびInvoiceDetailsの3つの別々のテーブルに分割されます。各テーブルは、一意の識別子（この場合はCustomerIDとInvoiceNumber）を使用して関連づけられます。

データベースは、リレーションシップを使用して一意のテーブルにデータを格納し、単にこれらのテーブルを互いに関連付けます。

Customersテーブルには、顧客ごとに固有のレコードが含まれます。そうすれば、顧客の名前を変更する必要がある場合は、そのレコードだけを変更する必要があります。もちろん、実際には、Customersテーブルには、顧客の住所、顧客の電話番号、顧客の開始日などの他の属性が含まれています。これらの他の属性も、Customersテーブルに簡単に格納して管理することができます。

最も一般的な関係タイプは、

一対多

の関係です。つまり、1つのテーブルの各レコードに対して、1つのレコードを別のテーブルの多数のレコードに一致させることができます。たとえば、請求書ヘッダテーブルは請求書明細テーブルに関連しています。請求書ヘッダテーブルには、一意の識別子：請求書番号があります。請求書の詳細は、その特定の請求書の詳細を表すすべてのレコードの請求書番号を使用します。 もう1つの種類の関係タイプは、 一対一の

関係です。あるテーブルの各レコードについて、一致するレコードは1つだけが異なるテーブルにあります。 1対1の関係にある異なるテーブルのデータは、技術的には1つのテーブルに結合することができます。 最後に、 多対多

関係では、両方のテーブルのレコードは、他のテーブル内の任意の数の一致するレコードを持つことができます。たとえば、銀行のデータベースにはさまざまなタイプのローン（住宅ローン、自動車ローンなど）のテーブルと顧客のテーブルがあります。顧客は多くの種類の融資を受けることができます。一方、各タイプのローンは多くの顧客に付与することができます。