Відносини та Power Pivot

Щоб використовувати Power Pivot, не потрібно бути експертом із моделювання баз даних. Але важливо розуміти стосунки. Чим краще ви розумієте, як дані зберігаються та керуються в базах даних, тим ефективніше ви будете використовувати Power Pivot для створення звітів.

Відносини є механізмом , з допомогою якого окремі таблиці пов'язані один з одним. Ви можете розглядати зв’язок як VLOOKUP, в якому ви зв’язуєте дані в одному діапазоні даних з даними в іншому діапазоні даних за допомогою індексу або унікального ідентифікатора. У базах даних відносини роблять те ж саме, але без клопоту з написанням формул.

Відносини важливі, оскільки більшість даних, з якими ви працюєте, вписуються в багатовимірну ієрархію. Наприклад, у вас може бути таблиця з покупцями, які купують товари. Ці клієнти вимагають рахунки-фактури з номерами рахунків-фактур. Ці рахунки-фактури містять кілька рядків трансакцій із зазначенням того, що вони купили. Там існує ієрархія.

Тепер у світі одновимірних електронних таблиць ці дані зазвичай зберігатимуться в плоскій таблиці, як показано тут.

Дані зберігаються в електронній таблиці Excel у форматі плоскої таблиці.

Оскільки клієнти мають більше одного рахунка-фактури, інформацію про клієнта (у цьому прикладі CustomerID та CustomerName) потрібно повторити. Це викликає проблему, коли ці дані потрібно оновити.

Наприклад, уявіть, що назва компанії Aaron Fitz Electrical змінюється на Fitz and Sons Electrical. Подивившись на таблицю, ви побачите, що кілька рядків містять стару назву. Ви повинні переконатися, що кожен рядок, що містить стару назву компанії, оновлюється, щоб відобразити зміни. Будь-які рядки, які ви пропустите, не будуть належним чином відображені для потрібного клієнта.

Чи не було б логічніше та ефективніше записати ім’я та інформацію клієнта лише один раз? Тоді, замість того, щоб постійно писати ту саму інформацію про клієнта, ви можете просто мати певну форму довідкового номера клієнта.

Це ідея відносин. Ви можете відокремити клієнтів від рахунків-фактур, помістивши кожного в свої власні таблиці. Потім ви можете використовувати унікальний ідентифікатор (наприклад, CustomerID), щоб зв’язати їх разом.

Наступний малюнок ілюструє, як ці дані виглядатимуть у реляційній базі даних. Дані будуть розділені на три окремі таблиці: Customers, InvoiceHeader і InvoiceDetails. Кожна таблиця буде пов’язана за допомогою унікальних ідентифікаторів (у даному випадку — CustomerID і InvoiceNumber).

Бази даних використовують зв’язки для зберігання даних в унікальних таблицях і просто зв’язують ці таблиці одна з одною.

Таблиця Customers міститиме унікальний запис для кожного клієнта. Таким чином, якщо вам потрібно змінити ім’я клієнта, вам потрібно буде внести зміни лише в цей запис. Звичайно, в реальному житті таблиця Customers включатиме інші атрибути, такі як адреса клієнта, номер телефону клієнта та дата початку роботи клієнта. Будь-який з цих інших атрибутів можна легко зберігати та керувати в таблиці Customers.

Найпоширенішим типом відносин є відносини « один до багатьох» . Тобто для кожного запису в одній таблиці один запис можна зіставити з багатьма записами в окремій таблиці. Наприклад, таблиця заголовка рахунка-фактури пов’язана з таблицею деталей рахунка-фактури. Таблиця заголовка рахунка-фактури має унікальний ідентифікатор: Номер рахунка-фактури. Деталі рахунка-фактури використовуватимуть номер рахунка-фактури для кожного запису, що представляє деталі цього конкретного рахунка-фактури.

Інший тип зв’язку — це зв’язок « один до одного» : для кожного запису в одній таблиці один і тільки один відповідний запис знаходиться в іншій таблиці. Дані з різних таблиць у зв’язку «один до одного» технічно можна об’єднати в одну таблицю.

Нарешті, у відношенні багато до багатьох записи в обох таблицях можуть мати будь-яку кількість відповідних записів в іншій таблиці. Наприклад, база даних банку може мати таблицю різних видів кредитів (позика на житло, автокредит тощо) і таблицю клієнтів. Клієнт може мати багато видів позик. При цьому кожен вид кредиту може бути наданий багатьом клієнтам.