Database
 sql >> база данни >  >> RDS >> Database

Звездна схема срещу схема със снежинка

В предишните две статии разгледахме двата най-често срещани модела на хранилища за данни:схемата звезда и схемата снежинка. Днес ще разгледаме разликите между тези две схеми и ще обясним кога е по-добре да използвате едната или другата.

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

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

Нека да разгледаме още един модел на продажбите както в схемата звезда, така и в схемата със снежинка.

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



Най-очевидната характеристика на звездната схема е, че таблиците с размери не са нормализирани. В горния модел розовото fact_sales таблицата съхранява обобщени данни, създадени от нашата оперативна база(и). Светлосините таблици са таблици с размери. Решихме да използваме тези пет измерения, защото трябва да създаваме отчети, използвайки ги като параметри. Гранулирането във всяко измерение също се определя от нашите нужди за отчитане.

От този модел можем лесно да разберем защо тази схема се нарича „звездна схема“:тя изглежда като звезда, с таблиците с размери, обграждащи централната таблица с факти.

Схема на снежинката



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

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

Първата разлика:Нормализация

Както споменахме, нормализирането е ключова разлика между схемите със звезда и снежинка. Във връзка с това трябва да знаете няколко неща:

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

Нека да преминем към втората основна разлика между тези две схеми.

Втората разлика:Сложност на заявката

В първите ни две статии демонстрирахме заявка, която може да се използва в модела на продажбите, за да получите количеството на всички продукти от телефонен тип, продадени в магазините в Берлин през 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

За да получим същия резултат от схемата на снежинката, трябва да използваме тази заявка:

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_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

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

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

Присъединяването на две таблици отнема време, защото DMBS отнема повече време за обработка на заявката. dim_store и dim_city таблиците са поставени в непосредствена близост в нашия модел, но те може да не са разположени никъде близо една до друга на диска. Има по-добра възможност данните да бъдат физически по-близо на диска, ако живеят в същата таблица.

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

Ускоряване на нещата

За да ускорим отчитането, можем:

  • Агрегирайте данни до нивото, от което се нуждаем в отчетите. Това ще компресира значително данните. Ще трябва да създадем процедури, които ще трансформират нашите живи данни, за да се впишат в структурата на схемата за отчитане (процесът ETL).
  • Изградете централно складово пространство за всички обобщените данни на компанията, а не само данните за продажбите.
  • Давайте на потребителите само данните, от които се нуждаят за анализ и отчети.

Снежинка срещу звездни схеми:кое да използвате?

След като разгледахме теорията и скоростите на заявки, нека да влезем направо в същността на въпроса:как да разберете коя схема да използвате за даден проект?

Помислете за използването на схемата на снежинката :

  • В складове за данни. Тъй като складът е Data Central за компанията, бихме могли да спестим много място по този начин.
  • Когато таблиците с размери изискват значително пространство за съхранение. В повечето случаи таблиците с факти ще бъдат тези, които заемат по-голямата част от пространството. Те вероятно също ще растат много по-бързо от таблиците с размери. Но има определени ситуации, в които това не е приложимо. Например, таблиците с измерения могат да съдържат много излишни, но необходими атрибути. В нашия пример използвахме град атрибут за описание на града, в който се намира магазинът. Ами ако искаме много по-подробно описание на града, включително население, пощенски код, демографски данни и т.н.? Описване на други подизмерения – например магазин , регион , състояние и държава – с повече атрибути ще превърне dim_store таблица с размери в една голяма таблица с много излишества.
  • Ако използвате инструменти, които изискват схема на снежинка във фонов режим. (За щастие повечето съвременни инструменти поддържат и двете схеми и дори схемата на галактиката.)

Помислете за използването на схемата със звезда :

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

    От друга страна, звездната схема опростява анализа. Тук става дума не само за ефективността на заявките, но и за опростяване на бъдещите действия за бизнес потребителите. Те може да разбират бази данни и да знаят как да пишат заявки, но защо да усложняват нещата и да включват повече обединявания, ако можем да го избегнем? Бизнес потребител може да има заявка за шаблон, която се присъединява към таблицата с факти с всички таблици с измерения. След това те трябва само да добавят подходящите селекции и групи. (Този подход е близък до обобщените таблици на Excel.)

  • Ако използвате инструменти, които изискват звездна схема на заден план. (Отново, това обикновено не е проблем.)

Както звездната схема, така и схемата снежинка са релационни модели, използвани за организиране на складове с данни и/или витрини с данни. Колкото и да си приличат, те демонстрират два различни подхода и имат своите предимства и недостатъци. Лично аз бих използвал схемата снежинка, когато внедрявам склад за данни (за да се спести място за съхранение) и схемата звезда за витрините с данни (за да улесня живота на бизнес потребителите).


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Модел на данни за доставка в ресторант

  2. Как да форматирате дата в T-SQL

  3. Как да актуализирате колона въз основа на друга колона в SQL

  4. SQL кръстосано присъединяване

  5. Какво да правите (или да не правите) относно най-добрите статистики за чакане