|
Основы проектирования баз данных.
|
Содержание
|
Создание ER-диаграммы в среде MySQL Workbench
|
Словарь данных
Недостатком ER-диаграмм является их недостаточная детализация данных, поэтому они часто дополняются более подробным описанием, которые собираются в словари данных.
Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ...
Словарь данных содержит описание сущностей (таблиц), включающее в себя определение атрибутов, а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.
В каталоге docs этого репозитория лежит шаблон словаря данных.
Возьмем описание предметной области одного из предыдущих демо-экзаменов и заполним словарь данных:
Подсистема работы с клиентами
Подсистема работы с клиентами включает в себя возможность добавления новых клиентов, отслеживание их посещений, а также контроль их бонусной программы.
Запись о клиенте содержит следующие данные: фамилию, имя, отчество, дату рождения, телефон, электронную почту, пол, дату первого посещения (регистрации), фотографию клиента. В связи с тем что у компании большое количество клиентов, то их удобно собирать с помощью определенных ярлыков (тегов), которые позволят очень удобно помечать клиентов (например, новый, постоянный, проблемный, горячий). Теги помимо названия должны иметь еще и определенный цвет.
Посещения клиента в рамках оказания услуг должны обязательно фиксироваться в БД.
Для начала, размеремся какие параметры заносятся в словарь данных
Key - признак, что поле является ключём. Для разных типов ключей приняты определенные обозначения:
- PK - первичный ключ (primary key)
- FK - внешний ключ (foreign key)
- IDX - индекс (альтернативный ключ)
Не нашёл как описывать составные ключи
Field Name - название атрибута (латиницей). Ещё раз напоминаю, что мы везде используем CamelCase
Data Type/Field Size - тип данных / размерность поля
Required? - вписывается "Y", если поле обязательное (для не обязательных ничего не пишем)
Notes - примечание. Заполняется, если назначение поля не самоочевидно из названия или для поля есть домен
Пример заполнения элемента словаря данных
Во-первых, Выделим из описания предметной области сущности:
- Клиент
- Пол клиента
- Теги клиента
- Посещения клиента
Заполним элемент словаря данных на примере таблицы Клиент
| Key |
Field Name |
Data Type/Field Size |
Required? |
Notes |
Мои примечания |
| PK |
Id |
INT |
Y |
|
Синтетический первичный ключ, тип всегда INT (целое) |
| |
LastName |
varchar(30) |
Y |
|
Фамилия (строка), обязательное поле |
| |
FirstName |
varchar(30) |
Y |
|
Имя (строка), обязательное поле |
| |
MiddleName |
varchar(30) |
|
|
Отчество (строка), НЕ обязательное поле |
| |
BirthDay |
DATE |
Y |
|
Дата рождения |
| |
Phone |
varchar(20) |
Y |
|
Телефон (тут тип данных может быть INT) |
| |
EMail |
varchar(20) |
Y |
|
Электронная почта |
| FK |
GenderId |
INT |
Y |
|
Ссылка на словарь Gender |
| |
FirstVisit |
DATE |
|
|
Дата первого посещения (регистрации). В принципе эту дату можно достать из таблицы "Посещения клиента" |
| |
Photo |
BLOB |
|
|
Фотографию клиента можно хранить в базе, но можно и в каком-либо каталоге на сервере |
| FK |
TagId |
INT |
|
|
Ссылка на словарь Теги клиента. Причем тут опять же в зависимости от ТЗ может понадобиться промежуточная таблица, если у клиента может быть несколько тегов |