Звездната схема

Днес отчетите и анализите са почти толкова важни, колкото и основният бизнес. Отчетите могат да бъдат изградени от вашите живи данни; често този подход ще свърши работа за малки и средни компании без много данни. Но когато нещата станат по-големи – или количеството данни започне да се увеличава драстично – е време да помислите за разделяне на вашите оперативни и отчетни системи.

Преди да се заемем с основното моделиране на данни, се нуждаем от известна информация за включените системи. Можем грубо да разделим системите на две категории:оперативни и системи за отчитане. Операционните системи често се наричат онлайн обработка на транзакции (OLTP). Системите за отчитане и анализ се наричат онлайн аналитична обработка (OLAP). OLTP системите поддържат бизнес процеси. Те работят с „живи“ оперативни данни, силно нормализирани са и реагират много бързо на действията на потребителите. От друга страна, основната цел на OLAP системите е анализ. Тези системи използват обобщени данни, които обикновено се поставят в денормализирана структура за съхранение на данни като звездната схема. (Какво е денормализация? Просто казано, има излишни записи на данни за по-добра производителност. Прочетете повече.)

Сега, когато знаем малко за системите, нека започнем да разглеждаме хранилището за данни и неговите части и процеси.

Хранилища за данни срещу витрини за данни

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

Защо са необходими витрини с данни? Всички релевантни данни се съхраняват във фирмата DWH. Повечето потребители обаче имат нужда само от достъп до определени подмножества от данни, като тези, свързани с продажби, производство, логистика или маркетинг. Витрините с данни са важни както от гледна точка на сигурността (ограничаване на ненужен достъп), така и от гледна точка на потребителя (не искаме да ги объркаме или да ги принудим да преминават през външни данни).

Има два различни подхода към връзката хранилище на данни – база данни:

Отгоре надолу :Витрините с данни се създават от хранилището за данни. (Това е нещо, с което Бил Инмън, „бащата на склада за данни“, би се съгласил, заедно с идеята, че складовете трябва да бъдат в 3NF.)
Отдолу нагоре :Първо се създават витрини с данни, след което се комбинират в склад за данни. (Този подход е по-близо до това, което застъпва Ралф Кимбъл, експерт по складове на данни и моделиране на размери.)

Процесът ETL се използва за редовно добавяне на „нови“ данни към OLAP системата. ETL е съкращение от Извличане, Трансформиране и Зареждане. Както подсказва името, ще извлечем данни от една или повече оперативни бази данни, ще ги трансформираме, за да паснат на нашата складова структура, и ще заредим данните в DWH.

Размерно моделиране , който е част от проектирането на хранилище за данни, води до създаването на модел на размерите. Има два типа таблици:

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

В схемата със звезда обикновено ще открием, че някои атрибути са подмножество от други атрибути в същия запис. Това съкращаване е умишлено и се прави в името на по-добра производителност. Можем да използваме измерения за дата, местоположение и агент по продажбите, за да обобщим (частта за трансформиране на ETL процеса) и да съхраняваме данни в DWH. При моделирането на размери е много важно да дефинирате правилните размери и да изберете правилното гранулиране.
Таблици с факти съдържат данните, които искаме да включим в отчети, обобщени въз основа на стойности в свързаните таблици с измерения. Таблицата с факти има само колони, които съхраняват стойности и външни ключове, препращащи към таблиците с измерения. Комбинирането на всички външни ключове формира първичния ключ на таблицата с факти. Например таблица с факти може да съхранява редица контакти и броя на продажбите, произтичащи от тези контакти.

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

Звездната схема

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

Звездните схеми се използват много често в витрините с данни. Можем да ги свържем с подхода на модела на данните отгоре надолу. Ще анализираме две звездни схеми (витрини с данни) и след това ще ги комбинираме, за да направим един модел.

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

Отчетът за продажбите е един от най-често срещаните отчети днес. Както споменахме по-рано, в повечето случаи можем да генерираме отчети за продажбите от системата на живо. Но когато данните или размерът на бизнеса правят това твърде тромаво, ще трябва да изградим склад за данни или витрина с данни, за да рационализираме процеса. След проектиране на нашата звездна схема, ETL процесът ще получи данните от оперативната(ите) база(и), ще трансформира данните в правилния формат за DWH и ще зареди данните в склада.

Представеният по-горе модел съдържа една таблица с факти (оцветена в светло червено) и пет таблици с измерения (оцветена в светло синьо). Таблиците в модела са:

fact_sales – Тази таблица съдържа препратки към таблиците с размери плюс два факта (цена и продадено количество). Имайте предвид, че всичките пет външни ключа заедно образуват първичния ключ на таблицата.
dim_sales_type – Това е таблица с измерения от тип продажби само с един атрибут, „type_name “.
dim_employee – Това е таблица с измерения на служителите, която съхранява основните атрибути на служителите:пълно име и година на раждане.
dim_product – Това е таблица с размери на продукта само с два атрибута (различни от първичния ключ):име на продукт и тип продукт.
dim_time – Тази таблица обработва измерението на времето. Той съдържа пет атрибута освен първичния ключ. Данните от най-ниско ниво са продажбите по дата (action_date ). action_week атрибутът е номерът на седмицата през тази година (т.е. първата седмица на януари ще получи числото 1; последната седмица на декември ще получи числото 52 и т.н.) actual_month и actual_year атрибутите съхраняват календарния месец и година, когато е извършена продажбата. Те могат да бъдат извлечени от action_date атрибут. action_weekday атрибутът съхранява името на деня, когато е извършена продажбата.
dim_store – Това е измерение на магазина. За всеки магазин ще запазим града, региона, щата и държавата, където се намира. Тук можем ясно да забележим, че схемата на звездата е денормализирана.

Пример за звездна схема:Поръчки за доставки

Има много прилики между този модел, показан по-долу, и модела за продажби.

Този модел е предназначен да съхранява историята на направените поръчки. Имаме една таблица с факти и таблици с четири измерения. Таблиците с измерения dim_employee , dim_product и dim_time са абсолютно същите като в модела за продажба. Следните таблици обаче са различни:

fact_supply_order – съдържа обобщени данни за направените поръчки.
dim_supplier – е таблица с измерения, която съхранява данни за доставчика по същия начин като dim_store съхранява данни от магазина в модела на продажбите.

Предимства и недостатъци на звездната схема

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

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

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

Схема на галактиката

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

Галактична схема, изградена от нашите два примерни витрини с данни, е показана по-долу:

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