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

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

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

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

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

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

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

• Мне нравится это соглашение: [type][subject][name]
• где тип — «тусклый» или «факт» (или «факты» для агрегатов)
• где тема — это предметная область внутри хранилища («comm» для общего, «fw» для брандмауэра, «id» и т. д.)
• где имя в идеале представляет собой имя из одного слова или аббревиатуры измерений в случае сводной таблицы.
• пример: dim_comm_org для организационного измерения
• пример: fact_scan для таблицы фактов сканирования
• например: fact_scan_org_sev_daily — сводная таблица сканирования фактов, сгруппированная на уровне организации, группы и дня.

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

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

Именование хранилища и OLTP:

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

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

Кен, мне нравится ваше соглашение [тип] [тема] [имя], где тип — это 'dim' или 'fact' (или 'facts' для агрегатов). Проблема заключается в том, что при создании модели схемы Star в репозитории Oracle Business Intelligence Repository , рекомендуется создавать псевдонимы для таблиц измерений и фактов с префиксами DIM_ (или dim) и FACT (или fact_) для таблиц измерений и фактов. Чтобы избежать использования псевдонимов измерений и таблиц фактов для чтения dim_dim[имя_таблицы] или fact_fact_fact_[имя_таблицы), предпочтительно именовать таблицы измерений с суффиксом _DM (или _dm), а таблицы фактов — с _FT (или _ft). ) суффикс.