Соглашения об именах звездных схем

Question

Является ли обычной практикой в ​​схеме типа "звезда" префикс таблиц в качестве таблицы измерений или фактов? Является ли обычной практикой использование имен столбцов с префиксом имени таблицы?

В моих обычных базах данных OLTP я этого не делаю, но я вижу примеры такого типа именования в звездообразных схемах.

Имеет ли смысл иметь другой набор стандартов именования для схем хранилища данных по сравнению со схемой OLTP?

Спасибо, Дуайт

Answer 1

Имена таблиц:

• Мне нравится это соглашение: [тип] [тема] [имя]
• где типом является "тусклый" или "факт" (или "факты" для агрегатов)
• , где субъект - это предметная область на складе («comm» для общего, «fw» для брандмауэра, «ids», и т.д.)
• , где в идеале имя - это отдельное слово name или сокращение размеров в случае сводная таблица
• например: dim_comm_org для организационного измерения
• ex: fact_scan для таблицы фактов сканирования
• ex: fact_scan_org_sev_daily - сводная таблица проверки фактов, сгруппированная в org, sev & day level

Имена столбцов:

• не ставить префикс перед полным именем таблицы - это слишком долго
• делать префикс только с осмысленной его частью - это очень помогает при написании или чтении запросов.

Warehouse vs OLTP Naming:

• они очень разные. Имена таблиц и столбцов хранилища часто заканчиваются метаданными в отчетах, которые читают как разработчики, так и пользователи. Не так много с OLTP.
• Я думаю, что префиксы таблиц все еще полезны в OLTP - но там, я думаю, было бы лучше, если бы в этом подмножестве модели было что-то значимое, а не различие фактов / измерений.

Answer 2

Соглашение об именах tablename_column используется, чтобы гарантировать, что все поля в базе данных являются уникальными, хотя это несколько чрезмерно, его можно использовать, когда есть стандарт / требование для уникального именования (которого требуют некоторые клиентские ИТ-отделы.)

Product.Name => Product.Product_Name
Part.Name => Part.Part_Name

Это устраняет любую неопределенность в отношении того, откуда придет Name.

Я предпочитаю вообще не называть таблицы с предпочтением (при условии, что это не нарушает местные стандарты компании), поскольку, хотя это может быть таблица сегодня, она может быть повторно реализована как представление или разделенное представление завтра но выставьте ту же схему, и тогда мне придется принять объекты с неправильным префиксом или обновить каждую ссылку на новое имя / создать синоним.

Несмотря на то, что последовательность имеет тенденцию быть победителем, если бы каждый DBA / Dev реализовывал свою собственную версию, это было бы хаосом, поэтому я склонен находить стандарты компании и применять их.

Answer 3

В DW часто называют столбцы «длинными именами», потому что эти столбцы заканчиваются заголовками столбцов в отчетах (результатах запросов) и должны быть удобными для бизнес-пользователей. Таким образом, вместо Product.Name и Customer.Name, которые будут отображаться как «Имя» (если не используется псевдоним), обычно используются Product.ProductName и Customer.CustomerName, поэтому они отображаются как «ProductName» и «CustomerName» в верхней строке отчета (запроса), когда звезда сглаживается с помощью объединений. Подчеркивания часто используются вместо верблюжьего футляра и пробелов, если это разрешено БД. Префиксы dim и fact рекомендуются в больших DW, когда роль таблицы в схеме может быть неочевидна; Они мне действительно нравятся.

Answer 4

Кен, мне нравится ваше соглашение [тип] [субъект] [имя], где типом является «тусклый» или «факт» (или «факты» для агрегатов). Проблема в том, что при создании модели схемы Star в Oracle В хранилище бизнес-аналитики рекомендуется использовать псевдонимы для таблиц измерений и фактов с префиксами DIM_ (или dim) и префиксами FACT (или fact_) для таблиц измерений и фактов. Чтобы таблицы измерения и псевдонима псевдонимов не читались как dim_dim [имя таблицы] или fact_fact_fact_ [имя_таблицы], предпочтительно указывать таблицы измерений с суффиксом _DM (или _dm), а таблицы фактов - _FT (или _ft ) суффикс.