Классика баз данных - статьи


         

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


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

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

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

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

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

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

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

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

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

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

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



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





    Forekc.ru
    Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий