# Словарь данных
Недостатком ER-диаграмм является их недостаточная детализация данных, поэтому они часто дополняются более подробным описанием, которые собираются в словари данных.
>**Словарь данных** представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ...
*Словарь данных* содержит описание сущностей (таблиц), включающее в себя определение атрибутов, а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.
В каталоге `docs` этого репозитория лежит [шаблон](../docs/DataDictionary_Template.xlsx) словаря данных.
Возьмем описание предметной области одного из предыдущих демо-экзаменов и заполним словарь данных:
>**Подсистема работы с клиентами**
>
>Подсистема работы с клиентами включает в себя возможность добавления новых клиентов, отслеживание их посещений, а также контроль их бонусной программы.
>
>Запись о клиенте содержит следующие данные: фамилию, имя, отчество, дату рождения, телефон, электронную почту, пол, дату первого посещения (регистрации), фотографию клиента. В связи с тем что у компании большое количество клиентов, то их удобно собирать с помощью определенных ярлыков (тегов), которые позволят очень удобно помечать клиентов (например, новый, постоянный, проблемный, горячий). Теги помимо названия должны иметь еще и определенный цвет.
>
>Посещения клиента в рамках оказания услуг должны обязательно фиксироваться в БД.
Для начала, размеремся какие параметры заносятся в *словарь данных*
* **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 | | | Ссылка на словарь **Теги клиента**. Причем тут опять же в зависимости от ТЗ может понадобиться промежуточная таблица, если у клиента может быть несколько тегов