Размери на измеренията:Поглед към най-често срещаните типове таблици с размери на съхранението на данни

Когато стартираме проект за съхранение на данни, първото нещо, което правим, е да дефинираме таблиците с размери. Таблиците с размери са интересните битове, рамката, около която изграждаме нашите измервания. Те идват в много форми и размери. В тази статия ще разгледаме по-отблизо всеки тип таблица с размери.

Таблиците с размери предоставят контекст на бизнес процесите, които искаме да измерим. Те ни казват всичко, което трябва да знаем за дадено събитие. Тъй като те дават съдържание на измерванията (т.е. таблици с факти) на системата за съхранение на данни (DWH), ние отделяме повече време за тяхното дефиниране и идентифициране, отколкото за всеки друг аспект на проекта. Таблиците с факти дефинират измерванията; таблиците с размери дават контекст. (За да прочетете повече за таблиците с факти, разгледайте тези публикации относно съхранението на данни, схемата звезда, схемата снежинка и фактите за таблиците с факти).

Основната характеристика на таблиците с размери е тяхното множество от атрибути . Атрибутите са колоните, които обобщаваме, филтрираме или обобщаваме. Те имат ниска мощност и обикновено са текстови и времеви. Таблиците с измерения имат един първичен ключ въз основа на основния бизнес ключ или сурогатен ключ . Този първичен ключ е основата за присъединяване на таблицата с измерения към една или повече таблици с факти.

В сравнение с таблиците с факти, таблиците с размери са малки по размер, лесни за съхранение и имат малко влияние върху производителността.

Нека сега да разгледаме някои от таблиците с измерения, които ще срещнете в среда на склад за данни.

Обща таблица с размери:Съобразеното измерение

Ще започнем с основен тип:съобразеното измерение. Те съдържат множество атрибути, които могат да бъдат адресирани в няколко таблици източник, но се отнасят до един и същ домейн (клиент, договор, сделка и т.н.) Съобразените размери се използват с много факти и трябва да бъдат уникални за стойността на зърно/домейн в хранилището на данни.

Пример:

Нека разгледаме една типична таблица с размери, DIM_CUSTOMER .

Ние дефинираме:

id – Първичен ключ на таблицата с размери.
cust_natural_key – Естественият ключ за клиента.
first_name – Име на клиента.
last_name – Фамилия на клиента.
address_residence – Жилищният адрес на клиента.
date_of_birth – Датата на раждане на клиента.
marital_status – Клиентът женен ли е? Дефинира се като Y (да) или N (не).
gender – Полът на клиента, M (мъж) или F (жена).

Атрибутите на таблицата с измерения зависят от нуждите на бизнеса. Можем да разширим този тип таблица, за да съхраняваме специфична за индустрията информация (дата на подразбиране, дейност и т.н.)

Бавно променящи се таблици с размери

С течение на времето измеренията могат да променят стойностите си. В следващите параграфи ще разгледаме измерения, класифицирани според начина, по който съхраняват (или не съхраняват) исторически данни.

Да кажем, че имате клиентско измерение. Някои атрибути вероятно ще се променят през живота на клиента – напр. телефонен номер, адрес, семейно положение и т.н. Този тип таблица Ралф Кимбъл нарича бавно променящо се измерение или SCD.

SCD се предлага в много видове; осем от тях са доста често срещани. От тях най-много ще виждате типове от 0 до 4; типове 5, 6 и 7 са хибриди на първите пет. (Забележка:Схемата за номериране на тези SCD започва с 0 вместо с 1.)

Хибридните SCD осигуряват повече гъвкавост и по-добра производителност, но с цената на простотата. Използваме тези типове таблици, когато трябва да направим аналитичен анализ на ток данни с някои исторически съображения.

SCD Тип 0:Попълване веднъж

Това е най-основният тип таблица с размери:попълвате я веднъж и никога напълнете го отново. Считайте това като референтни данни. Типичен пример за това е измерението дата. Не е необходимо да запълваме това измерение с всяко зареждане на DWH. Таблицата с размерите не се променя с времето. Не можете да получите повече дати или да промените дати.

Таблицата с факти се свързва с оригиналните атрибути на измерението.

Пример

Нека разгледаме измерението на времето:

Структурата е доста проста:

id – Сурогатен ключ
time_date – Действителна дата
time_day – Ден от месеца
time_week – Седмица в годината
time_month – Месец в годината
time_year – Числово представяне на година

SCD тип 1:Пренаписване на данни

Както подсказва името, ние пренаписваме този тип таблица с размери с всяко натоварване на DWH. Не е необходимо да водим история за тях, но очакваме да има някои промени.

Разликата между тип 0 SCD и тип 1 не е в структурата на таблицата. Това е свързано с опресняване на данните. Никога не опреснявате данните в Тип 0, но понякога го правите в Тип 1.

Презаписваемата таблица е най-простият начин за обработка на промените (изтриване/вмъкване), но добавя малка бизнес стойност. След като дефинирате таблица с измерения като тази, е трудно да се инсталира историческо проследяване.

Таблицата с факти се свързва с текущите атрибути на измерението.

Пример

Нека разгледаме измерението на акаунта:

Структурата му е следната:

id – Сурогатният ключ на масата
account_name – Името на акаунта
account_type – Категорията на акаунта
account_activity – Маркира различни видове дейности

Ако погледнем данните преди промяната, ще видим това:

Ако типът на акаунта се е променил, данните просто ще бъдат презаписани:

SCD тип 2:Проследяване на исторически атрибути по ред

Това е най-често срещаната форма на историческо проследяване в DWH система. Таблиците SCD тип 2 добавят нови редове за всяка историческа промяна на атрибутите на измерения между БГВ зареждата . В този тип ние дефинираме първичния ключ като сурогатен ключ, тъй като бизнес ключът ще има множество представяния във времето. Когато редовете, които съдържат промяната на данните, се променят, ние дефинираме нова стойност за сурогатния ключ, която съответства на стойността в таблицата с факти. Трябва да добавим поне две колони, valid_from и valid_to , за да съхранявате историята по този начин.

Таблицата с факти се свързва с историческите атрибути на измерението чрез сурогатния ключ. Обединяването се извършва на естествения ключ .

Пример

Нека да разгледаме предишната таблица с величини на клиентите, сега разширена с две колони за дати:

Нека разгледаме данните:

Точки, които трябва да обмислите:

Как можем да маркираме текущия ред, valid_to ? (Обикновено с 31.12.9999 или NULL .)
Как можем да маркираме първия ред, valid_from ? (Обикновено с 01.01.1900 г. или датата на първото вмъкване).
Определяте ли включващ или изключителен ред? (По-горе използваме включващ valid_from и изключителен valid_to ).

SCD тип 3:Проследяване на исторически атрибути по колона

Както при тип 2 SCD, този тип добавя нещо, което да представя исторически стойности. В този случай обаче добавяме нови колони. Те представляват стойността на атрибут на ред с размери, преди той да се промени. Обикновено запазваме само предишната версия на атрибута.

Забележка:Този SCD се използва рядко.

Таблицата с факти се свързва с текущите и предишни атрибути на измерението.

Пример

Нека разгледаме измерението на клиента, този път с предишен адрес:

В този пример добавихме нова колона, previous_address_residence , за да представлява стария адрес на клиента. Ако погледнем нашия първоначален пример, данните в тази таблица ще изглеждат така:

Цялата историческа информация, с изключение на предишния адрес на клиента, се губи.

SCD тип 4:Добавяне на мини-измерение

Този тип измерение не се основава на структурни (Тип 3) или на стойностни (Тип 2) промени. По-скоро се основава на промени в дизайна на модела. Ако нашата таблица с размери съдържа силно променливи данни – т.е. данни, които се променят често – размерът на таблицата с измерения ще нарасне значително.

За да смекчим това, ние извличаме променливите атрибути в мини-измерение . След това тези мини-измерения могат да бъдат обобщени до релевантното за бизнеса ниво. Въпреки това, това агрегиране трябва да не да се бърка с агрегиране на факти . Примерът ще изясни това.

Таблицата с факти се свързва с историческите атрибути на измерението.

Пример

Нека да разгледаме пример от обикновен магазин с финансови данни. Да предположим, че трябва да проследите колко закъсняват определени клиенти с плащанията си. Нека наречем този атрибут просрочени дни или DPD. Ако трябваше да проследяваме DPD всеки ден в измерение тип 2, размерът на таблицата скоро ще експлодира отвъд управляемите граници. Така че извличаме атрибута и намираме релевантни за бизнеса периоди на DPD – да речем с 30-дневни стъпки (0-30 DPD, 30-60 DPD, 60-90 DPD и т.н.)

Можем да вземем други атрибути с висока волатилност, като възраст, и да конструираме релевантни за бизнеса периоди за тях (напр. 20-30 години, 30-40 години и т.н.)

Ако погледнем данните в мини-измерението на клиента, ще имаме нещо подобно:

Атрибутите са:

id – Сурогатен първичен ключ
DPD_period – Просрочени дни
DEM_period – Демографски период

Простата звездна схема би изглеждала така:

Забележете, че за да направим каквито и да е анализи на атрибути от двете таблици, ще трябва да ги преведем през таблицата с факти.

SCD тип 5:Създаване на мини-измерение с презаписваемо разширение

Това е първата от нашите хибридни конструкции на таблица с размери. В тип 5 SCD добавяме текущата версия на мини-измерните данни към таблицата с размерите. Трябва да имаме предвид, че ще добавим само текущият представяне на мини-измерението към основното измерение.

Ние презареждаме това мини-размерно разширение с всяко натоварване („презаписваем“ SCD от тип 1).

Въпреки че историзирането на това разширение може много добре да доведе до проблеми с размера, ние вече сме ги смекчили с мини таблицата с измерения.

Използваме тази техника, когато искаме да правим анализ директно на таблиците с размери.

Пример

Разширявайки предишния пример с текущото мини-измерение, получаваме:

dim_mini_customer_current таблицата съдържа най-новите стойности на атрибути, които съответстват на dim_customer маса. Сега можем да правим специфични за клиента анализи, без да преминаваме през таблицата с факти (което е много бавно).

Таблицата с факти се свързва с историческите атрибути на измерението.

Тип 6:Измерение тип 2 (исторически ред) с презаписваем атрибут

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

Таблицата с факти се свързва със стойностите на размерите в момента на събитието с допълнителни текущи стойности на размерите.

Пример

Нека разширим предишната таблица с клиенти с current_address_residence колона.

Сега имаме атрибут, който ще актуализираме до текущата стойност, използвайки естествения ключ (cust_natural_key ).

Тип 7:Тип 2 (исторически ред) Размери с текущо огледало

Можем да използваме този тип само ако има естествен ключ в измерението на таблицата. Ключът не трябва да се променя по време на живота на субекта.

Идеята е проста:добавяме текущо представяне на таблицата с размерите към схемата на снежинката. След това вмъкваме естествения ключ на новото измерение в таблицата с факти. (Сурогатният ключ на историческото измерение все още присъства.)

Таблицата с факти се свързва със стойностите на размерите в момента на събитието и с текущите стойности на размерите.

Пример

Нека разгледаме нашата звездна схема на клиентски акаунт. Добавяме новото измерение dim_current_customer , към таблицата с факти. Тази таблица е свързана с таблицата с факти чрез естествен ключ, cust_natural_key .

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

Размери на домейна

Измерението на домейна е проста форма на таблица с размери. Той съдържа информация за домейна на основното измерване на атрибут на измерение. Тези таблици съхраняват различни кодове и обяснителни стойности.

Пример

Прост пример би била таблица с валути.

В тази таблица съхраняваме описателна информация за различни парични единици.

По мое лично мнение най-доброто използване на измерението на домейна е в документирането на стойностите на данните, които намираме в системата DWH.

Нежелани размери

Транзакционните изходни системи генерират много индикатори и флагове. Тези атрибути могат да се считат за категорични данни, но те не са релевантни за бизнеса или се обясняват сами. Можем да запишем всички тези индикатори и флагове в таблица с едно измерение, наречена нежелано измерение . Нежеланото измерение е алтернативата на използването на изродени измерения. Ако не искаме да натоварваме таблицата с факти с много изродени измерения, създаваме едно нежелано измерение.

Трябва да отбележим, че не попълваме всички възможни комбинации от индикатори и флагове. Попълваме само тези, които съществуват в изходната система.

Пример

Таблиците с измерения са скелетите на света на съхранението на данни:всичко е изградено около тях. Те не са толкова големи, колкото таблиците с факти, но структурата им може да бъде по-сложна.

Можете да съберете много видове таблици с размери, дори извън тези, които току-що обсъдихме. Какво ще кажете за вашия бизнес и индустрия? Ако сте комбинирали типове таблици с размери в нещо ново, разкажете ни за това!