Це відповідь на частину:
Я намагався зрозуміти, чи можуть таблиці розмірів також бути таблицею фактів чи ні?
Коротка відповідь (INMO) - Ні. Це тому, що два типи таблиць створюються з різних причин. Однак, з точки зору проектування бази даних, таблиця вимірів може мати батьківську таблицю, як у випадку з таблицею фактів, у якій завжди є таблиця вимірів (або більше) як батьківська. Також таблиці фактів можуть бути агреговані, тоді як таблиці розмірів не агреговані. Інша причина полягає в тому, що таблиці факти не повинні оновлюватися на місці, тоді як таблиці розмірів можуть бути оновлені на місці в деяких випадках.
Детальніше:
Таблиці фактів і розмірів відображаються у тому, що зазвичай називається «Зірка». Основна мета зіркової схеми - спростити складний нормований набір таблиць і консолідувати дані (можливо, з різних систем) в одну структуру бази даних, яку можна запитувати дуже ефективно.
У своїй найпростішій формі вона містить таблицю фактів (Приклад: StoreSales) та одну або кілька таблиць розмірності. Кожен запис параметрів має 0,1 або більше таблиць фактів, пов'язаних з ним (Приклад таблиць розмірів: Географія, Елемент, Постачальник, Замовник, Час тощо). Було б справедливим і розмір мати батьківський, і в цьому випадку модель має тип "Снігова луска". Однак дизайнери намагаються уникнути подібного дизайну, оскільки це спричиняє більше приєднань, які сповільнюють продуктивність. У прикладі StoreSales параметр Географія може складатися із стовпців (GeoID, ContenentName, CountryName, StateProvName, CityName, StartDate, EndDate)
У моделі Снігових пластівців у вас могли бути дві нормалізовані таблиці для геоінформації, а саме: Таблиця вмісту, Таблиця країн.
На Зоряній схемі ви можете знайти безліч прикладів. Також перевірте це, щоб побачити альтернативний вигляд зіркової схеми моделі Inmon vs. Kimball . У Kimbal є хороший форум, який ви також можете перевірити тут: Kimball Forum .
Редагувати: Щоб відповісти на коментар щодо прикладів для 4NF:
- Приклад таблиці фактів, що порушує 4NF:
Факт продажу (ID, BranchID, SalesPersonID, ItemID, сума, TimeID)
- Приклад таблиці фактів, що не порушує 4NF:
Зведені продажі (BranchID, TotalAmount)
Тут відношення знаходиться в 4NF
Останній приклад досить рідкісний.