Раздел: Компьютерная документация -> Базы данных -> Разное

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

"Всякое приказание должно быть отдано
в должное время, в должном месте,
и в выражениях, исключающих двоякое толкование"
(Из Устава Петровских времен)

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

Выбор имени сущности

1. Имя должно быть существительным (полным, сокращенным либо аббревиатурой) в единственном числе.
2. Имя должно быть как можно короче. Оптимально - 2-4 буквы, максимум до 10.
   
3. Имя должно быть уникальным в пределах базы данных.
4. Имя должно быть мнемонически понятным проектантам без заглядывания в словарь (но словарь такой хорошо бы составить).
   
5. Желательно, чтобы имена не начинались и не заканчивались на другие имена сущностей.
   

Наименование таблиц

SELECT *
FROM cities, streets
WHERE streets.cityid = cities.cityid
 AND streets.name LIKE "%тупик Третьего Интернационала%"

• C - Catalog, список. Самая безобидная форма жизни информации. Представляет собой простейший справочник из десятка пунктов чего-то неизменного, или почти неизменного. Структурирует некую фундаментальную природу вещей. Например, перечисляет типы улиц - "улица", "переулок", "проезд", "тупик", "овраг". Через пару лет построят в деревне первый проспект - добавим "проспект".
  
  Можно ввести дополнительные соглашения, приятные для программистов. Например, что записи из таблиц типа 'C' не удаляются, а только иногда добавляются. Что в интерфейсе для работы с таким списком  будет достаточно унифицированной формы с полным просмотром содержимого и простейшим поиском-фильтром, а для выбора значения - выпадающего списка (ComboBox).
  
  
• S - Справочник. Относительно большая таблица, выходящая за пределы простого каталога. Могут требовать инкрементального поиска, времязависимости, древовидных показов и чего угодно.
  
  
• R - Реестр. Таблица объектов, для поголовного учета которых собственно предназначена система, например Абонентов, Приборов. Объекты интенсивно добавляются, редактируются, удаляются (или иным образом помечаются как выведенные из учета). Таблицы, как правило, времязависимы. Объем таблиц может быть велик. Просмотр всей таблицы обычно не имеет смысла, из-за чего применяются специальный поиск и фильтрация, зависящие от прикладной специфики. Обычно такие таблицы слегка растут со временем, скажем, на несколько процентов в месяц.
  
  
• J - Журнал. Таблица фиксирования событий, например журнал бухгалтерских операций, журнал регистрации пользователей в системе. Растет линейно со временем жизни системы (поэтому при больших объемах может понадобиться сбрасывание части информации в архив). Как правило, просмотр всей таблицы не имеет смысла, а нужен только в контексте какого-либо объекта в связи один-ко-многим, например - операции начисления данного абонента, отчет о вчерашних похождениях конкретного пользователя. Также используются для расчетов, отчетов.
  
  
• Разумеется, можно придумать и другие префиксы.

Наименование полей

SELECT cstrtype.name, sstreet.name, scity.name....
Хм.
FROM scity, cstrtype, sstreet
WHERE ... связи между таблицами и условия поиска...

• id - внутренний идентификатор, суррогатный ключ. Автоинкрементный. От пользователя скрывается. Никогда не модифицируется.
• code - пользовательский идентификатор, уникальный ключ. Например, табельный номер сотрудника. Как правило, неизменный; но при необходимости его можно менять (когда у отдела кадров сносит крышу), причем без каскадных обновлений БД.
• name - имя чего-либо (скорее идентификатор, или нечто каноническое)
• label - название (обычно человеческое удобное название)
• notes - поле типа TEXT, для примечаний
• num - номер чего-либо (может быть числовой либо текстовый, например Письмо N "1234/56-789")
• ...разумеется, список можно продолжать.

Множественные ссылки

SELECT vectorid,
ps.pointX AS pointX_start, ps.pointY AS pointY_start,
pe.pointX AS pointX_end, pe.pointY AS pointY_end

FROM svector v, spoint ps, spoint pe
WHERE v.pointid_start = ps.pointid
  AND v.pointid_end = pe.pointid

  

Другие объекты базы данных

• Первичные ключи называем так: PK_имя_таблицы.
  
• Уникальные: UN_имя_таблицы_имена_всех_полей (если хватит терпения и допустимой длины), или просто UN_имя_тфблицы_номер_ключа_по_порядку.
  
• Внешние ключи: FK_имя_таблицы_имя_поля_ссылки_имя_таблицы-справочника

Автор: Алексей Михайличенко
Источник: www.delphikingdom.com