Правила именования объектов базы данных

Алексей Михайличенко,

"Всякое приказание должно быть отдано

в должное время, в должном месте,

и в выражениях, исключающих двоякое толкование"

(Из Устава Петровских времен)

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

Проблема чем-то похожа на выбор имен для переменных при написании программного кода. Но разница в том, что в написании процедур мир давно уже пришел к идее локальных переменных, и их имена остаются на совести автора-программиста - согласуются только параметры вызова. А вот база данных - штука глобального характера. Имена таблиц и полей используются в процедурах обработки, в клиентских формах ввода, в отчетах. Стройная система имен позволит "протащить" логику организации данных сквозь весь проект, сделать все его части более читабельными, за что вы получите немало благодарностей как от коллег по команде, так и от себя лично, когда вернетесь к задаче эдак через полгодика. С другой стороны, полтысячи разношерстных огрызков вроде 'trb_zrplt_mumu', по десятку на одно и то же понятие, выведут из себя кого угодно.

Итак, какова бы ни была система имен, она должна решить следующие задачи:

Единство именования программных единиц во всем проекте. Другими словами, если у нас есть, скажем "документ" (doc), или "номер документа" (docnum), то именно так должны называться таблица БД, ее соответствующее поле, соответствующие поля всевозможных VIEW, поля клиентских наборов данных, локальные переменные в процедурах обработки, классы, представляющие эту сущность на клиенте, поля (свойства) в этих классах, объекты во всех отчетах, и вообще все, что содержит в себе документ (номер). Другими словами, нельзя допускать размножения сущностей без необходимости. Нередко проектировщики свято соблюдают этот принцип Оккама при моделировании "внешних" данных, но напрочь игнорирую его во внутренней "кухне".

Самодокументируемость структуры базы данных. Сформулировать это зыбкое понятие трудно, но без него работать еще труднее.

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

О конкретной цели статьи. Описываемая схема не является ни единственно правильной, ни вообще оптимальной в каком-либо смысле. Скорее это исторически сложившийся взгляд автора, применяемый лишь потому, что лучше хоть какая-то система, чем никакой. Основная цель - обсудить основные принципы и проблемы "именования", и предложить один из вариантов. Если кто-то предложит лучше - буду рад.

Содержание Вперед