Правильный путь к таблице фактических данных хранилища данных

Question

При наборе таблицы FACT в хранилище данных лучше всего использовать первичный ключ из внешней таблицы или уникальный ключ или идентификатор, используемые бизнесом?

Например, (см. Иллюстрацию ниже), предположим, что у вас есть две таблицы размеров «DimStores» и «DimCustomers» и одна таблица FACT с именем «FactSales». Обе таблицы измерений имеют индексное поле первичного ключа, которое является целым типом данных и имеет имя «ID». Они также имеют индексированное уникальное поле бизнес-ключа, которое представляет собой буквенно-цифровой текстовый тип данных с именем «Число».

Как правило, вы должны использовать первичный ключ таблиц измерений в качестве внешних ключей в таблице FACT. Тем не менее, мне интересно, если это лучший подход.

Используя первичный ключ, чтобы просмотреть или выполнить вычисления по фактам в таблице FACT, вам, вероятно, всегда придется делать запрос соединения на первичный ключ и использовать бизнес-ключ в качестве поиска , Причина в том, что большинство пользователей не знают значения первичного ключа для поиска в таблице FACT. Однако они, вероятно, будут знать бизнес-ключ. Поэтому для использования этого бизнес-ключа вам нужно будет выполнить запрос соединения, чтобы сделать отношения.

Поскольку бизнес-ключ индексирован в любом случае, было бы лучше просто использовать это как внешний ключ в таблице FACT? Таким образом, вам не нужно было бы присоединяться и просто выполнять поиск или вычисления напрямую?

Я думаю, это сводится к тому, что запросы на вступление стоят так дорого? Представьте, что вы имеете дело с миллиардной таблицей FACT и ее размерами с десятками миллионов записей.

Пример таблицы:

DimStores: 
+------------+-------------+-------------+ 
| StoreId | StoreNumber | StoreName | 
+------------+-------------+-------------+ 
| 1   | S001  | Los Angeles | 
| 2   | S002  | New York | 
+------------+-------------+-------------+ 

DimCustomers: 
+------------+----------------+--------------+ 
| CustomerId | CustomerNumber | CustomerName | 
+------------+----------------+--------------+ 
| 1   | S001   | Michael  | 
| 2   | S002   | Kareem  | 
| 3   | S003   | Larry  | 
| 4   | S004   | Erving  | 
+------------+----------------+--------------+ 

FactSales: 
+---------+------------+------------+ 
| StoreId | CustomerId | SaleAmount | 
+---------+------------+------------+ 
| 1  | 1   |  $400 | 
| 1  | 2   |  $300 | 
| 2  | 3   |  $200 | 
| 2  | 4   |  $100 | 
+---------+------------+------------+ 

В выше, чтобы получить общий объем продаж в магазине Лос-Анджелесе, я должен был бы сделать это:

Select Sum(SaleAmount) 
From FactSales FT 
Inner Join DimStores D1 ON FT.StoreId = D1.StoreId 
Where D1.StoreNumber = 'S001' 

Если бы я использовал «StoreNumber» и «CustomerNumber» в качестве внешних ключей вместо таблицы «FactSales». Я не пришлось бы сделать запрос присоединиться и мог непосредственно сделать это вместо:

Select Sum(SaleAmount) 
From FactSales 
Where StoreNumber = 'S001' 

Answer 1

Причина использовать искусственные первичные ключи, чтобы изолировать хранилище данных от бизнес-решений.

Ваш бизнес растет. Теперь у вас более 1000 магазинов. Клавиши для магазинов меняются. Как вы справляетесь с этим?

Если ключ магазина распространяется по всему хранилищу данных, это болезненная операция. Если ключ магазина является атрибутом в таблице измерений, это легко.

Следует также отметить, что во многих случаях размеры могут быть размерами 2-го уровня, что означает, что они меняются со временем. Например, клиенты могут изменять свои имена, но вы можете знать, как их имя было в определенный момент времени.

И третья причина. Искусственные первичные ключи обычно целые. Они лучше индексируются, чем строки (в частности, строки с переменной длиной). Разница в производительности незначительна, но это причина для использования первичных ключей. Фактически, если ключи являются строками и длиннее целых чисел, возможно, более эффективно использовать искусственные ключи с точки зрения пространства.