С точки зрения дизайна схемы реляционной базы данных:
Если целью является только аналитика / ad-ho c запросы / OLAP в целом, то вы можете использовать звездообразную схему, которая хорошо подходит для такого типа аналитики. Но будьте осторожны, базы данных OLAP ненормализованы и не подходят для оперативного хранилища транзакций / OLTP в целом, если вы планируете использовать и то, и другое в этой базе данных.
Красота схемы Star:
Таблицы fact обычно все числовые c, что делает таблицы очень маленькими, даже если записей слишком много. Маленькая таблица означает, что ее очень быстро читать (ввод-вывод).
Все соединения из таблицы фактов в таблицы измерений основаны на внешних ключах (один столбец, число c, индексируемые внешние ключи)
Все таблицы измерений имеют суррогатный ключ, который представляет собой первичный ключ для одного столбца. Первичный ключ с одним столбцом легче JOIN, чем первичный ключ с несколькими столбцами, а также его проще индексировать.
В таблицах фактов во внешних ключах нет NULL. Это упрощает JOIN операций, то есть всегда JOIN таблицу фактов для всех ее таблиц измерений. Если вам нужен регистр NULL, вам нужно добавить его как особый случай в таблицу измерений. Например: если компания не котируется на фондовом рынке, и одна из вещей, которые вы отслеживаете, это цена акций, тогда вы вводите 0 или NULL в факт для таблицы цен акций в зависимости от (как вы хотите выполнить СУММ ( ), AVG () et c позже), а затем добавьте особый случай в таблицу измерений StockSymbols под названием «Частная компания» и добавьте внешний ключ этого особого случая в таблицу фактов в качестве внешнего ключа.
Почти вся фильтрация выполняется через таблицы измерений, которые намного меньше, чем таблицы фактов. Для этого необходимо иметь измерение Date, чтобы иметь возможность выполнять запросы на основе даты.
Если вы можете оставаться в чистой схеме Star, тогда все ваши JOIN s являются однопроходными (т.е. соединение между двумя таблицами через другую таблицу).
Все это делает JOIN операции очень быстрыми, простыми и понятными. Вот почему схема Star лежит в основе проектов хранилищ данных.
https://en.wikipedia.org/wiki/Star_schema https://en.wikipedia.org/wiki/Data_warehouse
На один уровень выше этого - это OLAP (например, SSAS SQL Server Analyses Services), который выполняет предварительную обработку данных, чтобы ускорить запрос, но требует большего обучения, чем чистая стартовая схема, и в вашем случае это излишество
Для вашего примера
В схеме Star
Компании будут таблицей измерений
Вы понадобится Месяц размерность таблица. Это упрощенная версия измерения даты, только для информации о месяце. Пример измерения даты здесь.
https://www.codeproject.com/Articles/647950/Create-and-Populate-Date-Dimension-for-Data-Wareho
Информация о компании (15 вещей, которые вы скажем) будут таблицами фактов. Факты должны быть числовыми c (b / c в идеале все нечисловые c значения сохраняются в таблицах измерений). Это означает перенос нечисловой c части факта в таблицу измерений. Например: если вы сохраняете доход и хотели бы сохранить и тип валюты, тогда вам потребуется измерение «Валюта» и сохранить только сумму в таблице фактов и внешний ключ в таблице измерения «Валюта».
Если у вас есть какие-либо нечисловые c факты, вам необходимо сохранить отдельный список в таблице измерений и добавить внешний ключ в эту таблицу измерений внутри вашей таблицы фактов (это называется factless таблица фактов ). Единственное исключение из этого - если количество элементов измерения и таблица фактов очень похожи, тогда вы можете просто сохранить нечисловое c значение факта внутри таблицы фактов напрямую, поскольку нет никакой пользы от наличия таблицы измерений ( фактически недостаток).
Также факты могут быть сгруппированы по степени их детализации. Например, у вас может быть таблица фактов company_monthly_summary и хранить более одного факта в этой таблице (все они присоединяются к измерению «Компания» и измерению «Месяц»). Все зависит от вас, как вы хотите сгруппировать таблицу фактов. Но если их степень детализации не совпадает, их не следует группировать, так как это вызовет разреженные таблицы фактов и усложнит запрос.
Вы будете использовать внешние ключи в таблицах фактов для присоединения к вашим Таблицы измерений
Добавьте индекс для наиболее часто используемых столбцов ваших таблиц измерений
Добавьте суррогатный ключ numeri c к вашему измерению. Обычно это число автоматически увеличивается, но это зависит от вас. Одно исключение, которое люди предпочитают для суррогатного ключа измерения даты, - это использование формата ГГГГММДД (как целое число). Это упрощает работу с предложением WHERE: то есть вместо фильтрации столбца Date (значение DATETIME), который будет выполнять поиск суррогатных ключей, вы просто предоставляете суррогатные ключи напрямую b / c вы знаете формат . В зависимости от области вашего бизнеса у вас могут быть другие похожие полезные шаблоны суррогатных ключей, которые вы, возможно, захотите рассмотреть и использовать. Но знайте: в случае изменения бизнес-домена вам придется обновить все записи фактов. Простой суррогатный ключ с автоинкрементом не имеет этой проблемы. В вашем случае суррогатный ключ для месяца может быть фактическим номером месяца (1 для января)
При этом 1 миллион строк за 5 лет легко запросить даже без звезды -схема (при правильной индексации, ведении базы данных). Но если это часть более крупной системы аналитики, то go со схемой Star