Сергей Дуплик
дата публикации 25-10-2009 01:18

---

Версия для печати

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

Статья написана на основе разработки реального и довольно большого проекта автоматизации работы ВУЗа, которой автор посвятил более 6 лет. Большая и сложная задача требует разработки сложной структуры базы данных, с которой работают многие разработчики. Чтобы унифицировать имена объектов был разработан ряд правил их именования, которых придерживались все разработчики.

В качестве примера возьмем распространенную задачу (как учебную, так и реальную): автоматизация деятельности одного деканата, работающего с несколькими специальностями. Данная задача будет рассматриваться в предельно упрощенном виде, т.к. автоматизация деятельности реального деканата гораздо сложнее и сильно выходит за рамки статьи.

1. Общие правила именования объектов

В базе данных могут присутствовать следующие типы объектов:

1. таблицы (tables)
2. представления (views)
3. хранимые процедуры (stored procedures)
4. функции пользователей (user functions)
5. иные объекты

В зависимости от конкретной СУБД этот набор может меняться. Например, для Dbase будут только таблицы, для MS Access — таблицы и представления, а для MS SQL Server и Oracle — все типы объектов (да еще и масса других).

Для нашего примера понадобятся:

1. Таблицы: статусы студентов, специальности, предметы, люди, студенты, персональные планы студентов.
2. Хранимые процедуры: создание записи о человеке, изменение записи о человеке, создание/изменение записи о студенте, получение персонального плана, открытие персонального плана на следующий семестр.
3. Функции: получить ФИО, получить количество предметов в текущем семестре.

Предлагаются следующие общие правила именования объектов.

1. Имя объекта составляется из трех частей:

префикс типа объекта + префикс проекта + название объекта

Префикс типа объекта указывает, к какому типу относится данный объект. Предлагается использовать следующие префиксы:

Префикс проекта используется, когда в одной базе данных содержатся объекты, относящиеся к разным проектам. В частности, в разрабатываемой нами системе были объекты, относящиеся к управлению работой ВУЗом и объекты, относящиеся к анкетированию студентов, которые не входили в систему управления, но использовали некоторые ее таблицы.

После префикса проекта рекомендуется ставить символ подчеркивания ("_").

2. Название объекта должно отражать суть или назначение данного объекта.

3. Название объектов составляются из одного или нескольких слов, причем сокращения не допускаются. Сокращения могут применяться только в том случае, если название получается очень длинным (больше 25-30 символов). Первые буквы слов пишутся заглавными, остальные — строчными, либо разделение слов производится с помощью символа подчеркивания ("_").

4. Наименования полей, параметров и т.д. подчиняются правилу 3, но допускаются сокращения без потери смысла.

2. Таблицы

Таблицы являются основой любой базы данных и предназначены собственно для хранения данных.

При создании таблиц предлагается придерживаться следующих правил:

1. имя таблицы отражает суть хранящихся в ней данных и дается во множественном числе.
   Например, tStudents — таблица с данными о студентах, tPerson-alPlans — персональные планы студентов
2. каждая таблица должна иметь поле-идентификатор, значение которого автоматически увеличивается на 1 при добавлении записи в таблицу. Данное поле имеет имя ID (без префиксов и окончаний), не может содержать пустых значений (NULL), значения являются уникальными.
   В зависимости от задачи иногда может оказаться, что в качестве подобного идентификатора лучше использовать не абстрактный счетчик, а числовое или текстовое поле, содержащее реальный атрибут объекта (например, идентификатор из другой таблицы или глобальный идентификатор — GUID) с соблюдением требований к уникальности значения. Например, когда таблица разбивается на две таблицы, в первой из которых используется автоинкрементный идентификатор, а во второй идентификатором является значение идентификатора из первой таблицы.
3. имена остальных полей должны отражать суть хранящихся в них данных и составляются, исходя из правила 4 Общих правил именования объектов.
4. поле, хранящее текстовое наименование объекта, называется Name (без префиксов и окончаний). Данное поле обязательно для заполнения, т.е. не может содержать пустых значений (NULL).
5. поле, хранящее расшифровку наименования объекта (полное, сокращенное и т.д.), называется в соответствии с этим наименованием и в конце содержит "Name".
   Например, ShortName, FullName, DisplayName
6. поле, содержащее ссылку на запись другой таблицы, составляется из имени таблицы, на которую оно ссылается без префиксов типа и проекта и в единственном числе, в конце имени добавляется окончание "ID". Для таких полей обязательно построение связи с таблицей, на которую оно ссылается для обеспечения ссылочной целостности базы данных.
   Например, StudentID, DepartmentID или DepID, PersPlanID
7. поля, содержащие дату, оканчиваются на "Date".
   например, StartDate, EndDate, CheckDate, EntranceDate
8. битовые поля начинаются с префикса "Is". Желательно, чтобы данное поле имело предопределенное разработчиком значение по умолчанию (0 или 1) в зависимости от его назначения.
   Например, IsActual, IsVisible, IsCheck
9. другие префиксы и окончания в именах полей не используются.
10. одинаковые по смыслу поля в разных таблицах называются одними и теми же именами, даже если хранящиеся данные относятся к разным областям.
    Например:
    1. если в разных таблицах есть ссылка на таблицу студентов, то поле называется StudentID
    2. поле Name может хранить полное название специальности, предмета, чего-либо еще, но все это — название. Поэтому и поля называются одинаково. Уточнение, к чему относится данное название (т.е. SpecName, SubjName и т.д.), давать не стоит, т.к. это ясно из того, в какой таблице находится поле (и соответственно из имени этой таблицы)

Таблицы бывают следующих типов:

1. системные классификаторы
2. пользовательские классификаторы
3. таблицы данных

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

Имена системных классификаторов оканчиваются на "Types" (например, tStudentStatusTypes, tPersPlanRecordTypes).

Структура системных классификаторов состоит из следующих полей:

• ID — идентификатор записи
• Name — название, отображаемое пользователям
• другие поля, относящиеся к записи; могут отсутствовать

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

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

Структура таких таблиц произвольна, обязательным полем является только поле-идентификатор ID. Как правило, подобные таблицы не содержат большого количества полей и записей.

Таблицы данных — это таблицы, хранящие данные, с которыми постоянно работают пользователи. Содержимое этих таблиц постоянно изменяется, добавляются и удаляются записи.

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

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

Примеры

Таблица "Статусы студентов"
Тип таблицы: системный классификатор
Название: tStudentStatusTypes
Структура:

В таблицу заносятся следующие записи: абитуриент, обучаемый, закончивший семестр, дипломник, выпускник, академотпускник, отчисленный.

Таблица "Специальности"
Тип таблицы: пользовательский классификатор
Название: tSpecialities
Структура:

Таблица "Предметы"
Тип таблицы: пользовательский классификатор
Название: tSubjects
Структура:

Таблица "Люди"
Тип таблицы: таблица данных
Название: tPeople
Структура:

Таблица "Студенты"
Тип таблицы: таблица данных
Название: tStudents
Структура:

Таблица "Персональные планы студентов"
Тип таблицы: таблица данных
Название: tPersonalPlans
Структура:

Деление на таблицы людей и студентов сделано по двум причинам:

1. один и тот же человек может обучаться на нескольких специальностях (как параллельно, например, на разных формах обучения, так и последовательно — закончить обучение по одной специальности и поступить на другую)
2. если в плане развития системы необходимо будет завести таблицу сотрудников, то персональные данные о сотрудниках (ФИО, паспортные данные и т.д.) можно будет хранить в таблице "Люди", а данные о месте работы (подразделение, должность и т.д.) — в новой таблице. Кроме того, один и тот же человек может быть и сотрудником, и студентом.

3. Представления

Представления нужны для упрощения запросов и для предоставления пользователю готовых сводных данных из нескольких таблиц.

Представления фактически представляют собой запросы к базе данных и строятся по правилам, описанным далее.

4. Написание запросов на выборку данных из таблиц и представлений

При написании запросов предлагается использовать следующие правила:

1. запросы на выбор всех полей (select *) являются нежелательными, т.к. могут выбирать много ненужных данных, особенно при наличии в таблице больших текстовых и двоичных полей. В результате это приводит к большому трафику при передаче результатов запроса по сети и большому объему памяти для их хранения у клиента. Поэтому в запросе рекомендуется явно указывать, какие поля из каких таблиц выбирать. Исключением являются запросы, выбирающие все или подавляющее большинство полей из таблицы или связки таблиц; однако если в выборке будут присутствовать ненужные поля большого объема (например, "Фотография"), рекомендуется перечислить все поля отдельно
2. при соединении в запросе нескольких таблиц каждой таблице присваивается псевдоним, состоящий из первых (заглавных) букв слов, входящих в наименование таблицы. Псевдонимы пишутся маленькими буквами
3. при соединении в запросе нескольких таблиц перед именем каждого поля через точку обязательно указывается псевдоним таблицы, из которой берется это поле
4. если в выборку попадают поля с одинаковыми наименованиями, этим полям даются псевдонимы, состоящие из имени таблицы и имени поля. Имена таблиц пишутся в единственном числе без префикса типа объекта и проекта, также в них допускаются сокращения
5. для имен полей в выборке могут использоваться псевдонимы в виде сокращений этих имен, либо расшифровывающие суть полей

Все сказанное для таблиц подходит и для написания запросов с использованием представлений, а также для создания самих представлений.

Использование данных правил позволяет:

1. писать достаточно легко читаемые запросы
2. сразу понимать, из какой таблицы взяты данные
3. значительно укоротить тексты запросов
4. свести к минимуму корректировку запроса при переименовании входящих в него таблиц (можно исправить только имя таблицы, но не менять ее псевдоним, хотя это и выходит за рамки описываемых правил)

Примеры

1. Данные о студентах, находящихся в определенном семестре

SELECT s.ID, p.ID AS PeopleID, p.LastName, p.FirstName, p.SirName, sp.Name AS SpecName, sst.Name AS StatusName FROM tStudents s INNER JOIN tPeople ON p.ID = s.PeopleID INNER JOIN tSpecialities sp ON sp.ID = s.SpecID INNER JOIN tStudentStatusTypes sst ON s.ID = sst.ID WHERE s.Semester = :Semester ORDER BY p.LastName, p.FirstName, p.SirName

2. Актуальный персональный план указанного студента на весь срок обучения

SELECT pp.Semester, s.Name AS SubjName, pp.Result, pp.ResultDate FROM tSubjects s INNER JOIN tPersonalPlans pp ON s.ID = pp.SubjectID WHERE pp.StudentID = :StudentID AND pp.IsActual <> 0 ORDER BY pp.Semester, s.Name

3. Количество студентов по каждой специальности

SELECT sp.FullName, COUNT(*) as StudCount FROM tSpecialities sp INNER JOIN tStudents s ON sp.ID = s.SpecID GROUP BY sp.FullName ORDER BY sp.FullName

4. Результаты сдачи предмета

SELECT p.LastName, p.FirstName, p.SirName, sp.Name AS SpecName, pp.Result, pp.ResultDate FROM tPeople p INNER JOIN tStudents s ON p.ID = s.PeopleID INNER JOIN tSpecialities sp ON s.SpecID = sp.ID INNER JOIN tPersonalPlans pp ON s.ID = pp.StudentID WHERE pp.IsActual <> 0 AND pp.SubjectID = :SubjectID AND pp.Result Is Not Null ORDER BY p.LastName, p.FirstName, p.SirName

5. Хранимые процедуры

Хранимые процедуры являются очень удобным инструментом, позволяющим изменять данные в базе данных, а также делать сложные выборки (имеются в виду хранимые процедуры, не изменяющие данные, а возвращающие наборы данных).

В названии хранимых процедур рекомендуется придерживаться следующих правил:

1. название процедуры состоит из слов, кратко описывающих основное действие этой процедуры
2. процедуры, основной задачей которых является добавление записей или групп записей, начинаются со слова "Add", "Insert" или "Create"
3. процедуры, изменяющие записи, начинаются со слова "Update" или "Modify"
4. процедуры, удаляющие записи, начинаются со слова "Delete" или "Erase"
5. процедуры, основной задачей которых является возврат параметров или наборов данных, начинаются со слова "Get"
6. процедуры, устанавливающие параметры, начинаются со слова "Set"
7. остальные процедуры именуются в соответствии с выполняемыми функциями без префиксов, либо с префиксами, уточняющими их смысл

Допускается и иная схема именования процедур. Сначала идет название процедуры, а в конце добавляется слово, отражающее смысл основного действия.

Для названий параметров процедур предлагается следующее правило. Название параметров должно начинаться с префикса, состоящего из первых (заглавных) букв слов в названии процедуры (префиксы пишутся маленькими буквами), после префикса может идти символ подчеркивания ("_"), а затем — собственно название параметра, отражающее его смысл. Таким образом, обеспечивается достаточно высокий уровень уникальности имен параметров, что актуально при вызове одной процедуры из другой.

Примеры

1. Создание записи о человеке

2. Изменение записи о человеке

3. Создание/изменение записи о студенте

4. Получение персонального плана

Возвращает таблицу с персональным планом указанного студента.

5. Открытие персонального плана на следующий семестр

6. Функции пользователей

В названии функций пользователей рекомендуется придерживаться только одного правила: название функции подчиняется общим правилам именования объектов.

Параметры функций именуются по правилам именования параметров процедур.

Примеры

1. Получить ФИО

2. Получить количество пройденных предметов в текущем семестре

Заключение

Применение предлагаемых правил позволяет унифицировать пространство имен объектов базы данных и упростить работу с ними. На первый взгляд они могут показаться сложными, но на самом деле к ним быстро привыкаешь.

Данные правила были применены при разработке системы автоматизации работы реального ВУЗа, которая на данный момент времени охватывает все подразделения ВУЗа в головном учебном центре и во всех филиалах. Кроме того, данная система была внедрена в нескольких ВУЗах по России. Краткое описание системы можно найти по адресу: http://isu.tisbi.ru/booklet/.