schema types data warehouse modeling star snowflake schema
Този урок обяснява различни типове схеми на хранилище за данни. Научете какво е схема на звездите и схемата на снежинката и разликата между схемата на звездите срещу схемата на снежинката:
В това Уроци за склад за дати за начинаещи , разгледахме задълбочено Модел на измерените данни в хранилището на данни в предишния ни урок.
В този урок ще научим всичко за схемите за съхранение на данни, които се използват за структуриране на таблици с данни (или) на хранилище на данни.
въпроси за интервю за ръчно тестване и автоматизация
Да започваме!!
Целева аудитория
- Хранилище за данни / ETL разработчици и тестери.
- Професионалисти в базата данни с основни познания за концепции за бази данни.
- Администратори на бази данни / експерти за големи данни, които искат да разберат областите за съхранение на данни / ETL.
- Завършили колеж / Преподаватели, които търсят работа в склад за данни.
Какво ще научите:
Схема за съхранение на данни
В хранилище за данни се използва схема, за да се определи начинът за организиране на системата с всички обекти на базата данни (таблици с факти, таблици с размери) и тяхната логическа асоциация.
Ето различните видове схеми в DW:
- Звезден график
- Схема SnowFlake
- Диаграма на галактиката
- Схема на звездни клъстери
# 1) График на звездите
Това е най-простата и ефективна схема в хранилище за данни. Фактическа таблица в центъра, заобиколена от таблици с множество измерения, прилича на звезда в модела Star Schema.
Фактическата таблица поддържа връзки 'един към много' с всички таблици с измерения. Всеки ред в таблица с факти е свързан с редовете на таблицата с измерения с препратка към външен ключ.
Поради горната причина навигацията между таблиците в този модел е лесна за заявки за обобщени данни. Крайният потребител може лесно да разбере тази структура. Следователно всички инструменти за бизнес интелигентност (BI) значително поддържат модела на схемата Star.
Докато се проектират звездни схеми, таблиците с размери са целенасочено денормализирани. Те са широки с много атрибути за съхраняване на контекстуалните данни за по-добър анализ и докладване.
Ползи от звездната схема
- Заявките използват много прости съединения, докато извличат данните и по този начин се повишава производителността на заявките.
- Извличането на данни за отчитане е лесно по всяко време за всеки период.
Недостатъци на звездната схема
- Ако има много промени в изискванията, съществуващата звездна схема не се препоръчва да се променя и използва повторно в дългосрочен план.
- Излишъкът на данни е повече, тъй като таблиците не са йерархично разделени.
Пример за звездна схема е даден по-долу.
Заявка за звездна схема
Крайният потребител може да поиска отчет с помощта на инструментите за бизнес разузнаване. Всички такива заявки ще бъдат обработени чрез вътрешно създаване на верига от “SELECT заявки”. Изпълнението на тези заявки ще окаже влияние върху времето за изпълнение на отчета.
От горния пример на схема Star, ако бизнес потребител иска да знае колко романи и DVD-та са продадени в щата Керала през януари 2018 г., тогава можете да приложите заявката, както следва в таблиците на схемата Star:
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Product pdim, Sales sfact, Store sdim, Date ddim WHERE sfact.product_id = pdim.product_id AND sfact.store_id = sdim.store_id AND sfact.date_id = ddim.date_id AND sdim.state = 'Kerala' AND ddim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name Резултати:
| Име на продукта | Количество_Продадено | |
|---|---|---|
| 7 | Всеки може лесно да разбере и проектира схемата. | Трудно е да се разбере и проектира схемата. |
| Романи | 12 702 | |
| DVD дискове | 32 919 |
Надявам се, че сте разбрали колко лесно е да направите заявка за звездна схема.
# 2) Схема на SnowFlake
Схемата Star действа като вход за проектиране на схема SnowFlake. Снежното лющене е процес, който напълно нормализира всички таблици с размери от звездна схема.
Подреждането на таблица с факти в центъра, заобиколено от множество йерархии на таблици с измерения, изглежда като SnowFlake в модела на схемата SnowFlake. Всеки ред на таблица с факти е свързан със своите редове на таблици с измерения с референтен външен ключ.
При проектирането на схеми SnowFlake таблиците с размери са целенасочено нормализирани. Външните ключове ще бъдат добавени към всяко ниво на таблиците с измерения, за да се свържат с неговия родителски атрибут. Сложността на схемата SnowFlake е пряко пропорционална на йерархичните нива на таблиците с измерения.
Предимства на схемата SnowFlake:
- Излишъкът от данни се премахва напълно чрез създаване на нови таблици с измерения.
- В сравнение със звездната схема, по-малко място за съхранение се използва от таблиците с размери Snow Flaking.
- Лесно е да актуализирате (или) поддържате таблиците Snow Flaking.
Недостатъци на схемата SnowFlake:
- Поради нормализирани таблици с размери, системата ETL трябва да зареди броя на таблиците.
- Може да са ви необходими сложни съединения за изпълнение на заявка поради броя на добавените таблици. Следователно ефективността на заявката ще бъде влошена.
Пример за схема на SnowFlake е даден по-долу.
Таблиците с размери в горната диаграма SnowFlake са нормализирани, както е обяснено по-долу:
- Измерението за дата се нормализира в тримесечни, месечни и седмични таблици, като се оставят идентификатори на външни ключове в таблицата Date.
- Размерът на хранилището се нормализира, за да включва таблицата за състояние.
- Размерът на продукта се нормализира в Марка.
- В измерението „Клиент“ атрибутите, свързани с града, се преместват в новата таблица „Сити“, като се оставя идентификатор на външен ключ в таблицата „Клиент“.
По същия начин едно измерение може да поддържа множество нива на йерархия.
Различните нива на йерархии от горната диаграма могат да бъдат посочени както следва:
- Тримесечен идентификатор, месечен идентификатор и седмични идентификатори са новите заместващи ключове, които са създадени за йерархии на измерения на Дата и са добавени като външни ключове в таблицата с измерения на дата.
- Идентификатор на състоянието е новият заместващ ключ, създаден за йерархия на измерението Store и е добавен като външен ключ в таблицата с размери Store.
- Идентификационният номер на марката е новият заместващ ключ, създаден за йерархията на измерението на продукта и е добавен като външен ключ в таблицата с измерения на продукта.
- Идентификаторът на града е новият заместващ ключ, създаден за йерархията на измерението на клиента и е добавен като външен ключ в таблицата с измерения на клиента.
Заявка за схема на снежинка
Можем да генерираме същия вид отчети за крайните потребители като тези на структурите на звездни схеми и със схеми SnowFlake. Но въпросите тук са малко сложни.
От горния пример за схема SnowFlake ще генерираме същата заявка, която сме проектирали по време на примера за заявка за схема Star.
Това е така, ако бизнес потребител иска да знае колко романи и DVD-та са продадени в щата Керала през януари 2018 г., можете да приложите заявката, както следва в таблиците на схемата SnowFlake.
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Sales sfact INNER JOIN Product pdim ON sfact.product_id = pdim.product_id INNER JOIN Store sdim ON sfact.store_id = sdim.store_id INNER JOIN State stdim ON sdim.state_id = stdim.state_id INNER JOIN Date ddim ON sfact.date_id = ddim.date_id INNER JOIN Month mdim ON ddim.month_id = mdim.month_id WHERE stdim.state = 'Kerala' AND mdim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name Резултати:
| Име на продукта | Количество_Продадено |
|---|---|
| Романи | 12 702 |
| DVD дискове | 32 919 |
Точки, които трябва да запомните, докато отправяте запитване към звездни (или) таблици на схемата SnowFlake
Всяка заявка може да бъде проектирана със следната структура:
Клауза SELECT:
- Атрибутите, посочени в клаузата за избор, са показани в резултатите от заявката.
- Операторът Select също използва групи за намиране на обобщените стойности и следователно трябва да използваме group by clause в условието where.
Клауза FROM:
- Всички основни таблици с факти и таблици с измерения трябва да бъдат избрани според контекста.
Клауза WHERE:
- Подходящите атрибути на измерения са споменати в клаузата where чрез присъединяване към атрибутите на таблицата с факти. Сурогатните ключове от таблиците с измерения се обединяват със съответните външни ключове от таблиците с факти, за да се определи обхватът на данните, които трябва да бъдат заявени. Моля, обърнете се към написания по-горе пример за заявка за схема на звезда, за да разберете това. Можете също така да филтрирате данни в самата клауза от, ако в случая използвате вътрешни / външни съединения там, както е написано в примера на схемата SnowFlake.
- Атрибутите на измерението също се споменават като ограничения на данните в клаузата where.
- Чрез филтриране на данните с всички горепосочени стъпки се връщат подходящи данни за отчетите.
Според бизнес нуждите можете да добавите (или) да премахнете фактите, размерите, атрибутите и ограниченията към звездна схема (или) заявка за схема SnowFlake, като следвате горната структура. Можете също да добавяте подзаявки (или) да обединявате различни резултати от заявки, за да генерирате данни за всякакви сложни отчети.
# 3) Диаграма на галактиката
Схема на галактика е известна също като схема на съзвездията на фактите. В тази схема множество таблици с факти споделят еднакви таблици с измерения. Подреждането на таблици с факти и таблици с размери изглежда като колекция от звезди в модела на схемата на Galaxy.
Споделените размери в този модел са известни като Съобразени размери.
Този тип схема се използва за сложни изисквания и за обобщени таблици с факти, които са по-сложни, за да се поддържат от схемата Star (или) SnowFlake. Тази схема е трудна за поддръжка поради нейната сложност.
Пример за схема на Galaxy е даден по-долу.
# 4) Схема на звездни клъстери
Схема SnowFlake с много таблици с измерения може да се нуждае от по-сложни съединения по време на заявка. Звездата схема с по-малко таблици с размери може да има повече излишък. Следователно схема на звезден клъстер се появи в картината чрез комбиниране на характеристиките на горните две схеми.
Звездната схема е основата за проектиране на схема на звезден клъстер и няколко основни таблици с размери от звездната схема са снежни и това от своя страна формира по-стабилна структура на схемата.
Пример за схема на звездни клъстери е даден по-долу.
Коя е по-добра схема на снежинка или звезда?
Платформата за съхранение на данни и BI инструментите, използвани във вашата DW система, ще играят жизненоважна роля при избора на подходящата схема, която ще бъде проектирана. Star и SnowFlake са най-често използваните схеми в DW.
Схемата звезда е за предпочитане, ако BI инструментите позволяват на бизнес потребителите лесно да взаимодействат със структурите на таблиците с прости заявки. Схемата SnowFlake е за предпочитане, ако BI инструментите са по-сложни за директното взаимодействие на бизнес потребителите със структурите на таблицата поради повече обединения и сложни заявки.
Можете да продължите със схемата SnowFlake или ако искате да спестите малко място за съхранение, или ако вашата DW система има оптимизирани инструменти за проектиране на тази схема.
Звезда Схема срещу Снежинка Схема
Дадени по-долу са основните разлики между схемата Star и схемата SnowFlake.
| S.No | Звезден график | Схема за снежна люспа |
|---|---|---|
| 1 | Излишъкът на данни е повече. | Излишъкът на данни е по-малък. |
| две | Мястото за съхранение на таблици с размери е повече. | Мястото за съхранение на таблици с размери е сравнително по-малко. |
| 3 | Съдържа денормализирани таблици с размери. | Съдържа нормализирани таблици с размери. |
| 4 | Таблицата с един факт е заобиколена от таблици с множество измерения. | Таблицата с един факт е заобиколена от множество йерархии на таблици с измерения. |
| 5 | Заявките използват директни съединения между факт и измерения за извличане на данните. | Заявките използват сложни съединения между факт и измерения за извличане на данните. |
| 6 | Времето за изпълнение на заявката е по-малко. | Времето за изпълнение на заявката е повече. |
| 8 | Използва подход отгоре надолу. | Използва подход отдолу нагоре. |
Заключение
Надяваме се, че сте разбрали добре различните видове схеми за съхранение на данни, заедно с техните предимства и недостатъци от този урок.
Също така научихме как могат да се проверяват Star Schema и SnowFlake Schema и коя схема да се избира между тези две заедно с техните разлики.
Следете нашия предстоящ урок, за да научите повече за Data Mart в ETL !!
=> Внимавайте тук за поредицата от учебни програми за просто съхранение на данни.
Препоръчително четене
- Типове данни на Python
- Типове данни на C ++
- Урок за тестване на хранилище на данни с примери | Ръководство за тестване на ETL
- Топ 10 популярни инструменти за съхранение на данни и технологии за тестване
- Размерен модел на данни в хранилището на данни - Урок с примери
- Урок за тестване на хранилище на данни за ETL (Пълно ръководство)
- Какво представлява процесът ETL (извличане, преобразуване, зареждане) в хранилището на данни?
- Извличане на данни: процес, техники и основни проблеми при анализа на данни