|
|
@@ -1,10 +1,6 @@
|
|
|
-<table style="width: 100%;"><tr><td style="width: 40%;">
|
|
|
-<a href="../articles/5_1_1_1_erd2.md">Основы проектирования баз данных.
|
|
|
-</a></td><td style="width: 20%;">
|
|
|
-<a href="../readme.md">Содержание
|
|
|
-</a></td><td style="width: 40%;">
|
|
|
-<a href="../articles/5_1_1_1_erd_workbench.md">Создание ER-диаграммы
|
|
|
-</a></td><tr></table>
|
|
|
+Предыдущая лекция | | Следующая лекция
|
|
|
+:----------------:|:----------:|:----------------:
|
|
|
+[Основы проектирования баз данных. ERD.](./5_1_1_1_erd2.md) | [Содержание](../readme.md#проектирование-баз-данных) | [Основы SQL](./sql_for_beginner.md)
|
|
|
|
|
|
# Словарь данных
|
|
|
|
|
|
@@ -12,7 +8,7 @@
|
|
|
|
|
|
>**Словарь данных** представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ...
|
|
|
|
|
|
-*Словарь данных* содержит описание сущностей (таблиц), включающее в себя определение атрибутов, а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.
|
|
|
+**Словарь данных** содержит описание сущностей (таблиц), включающее в себя определение атрибутов, а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.
|
|
|
|
|
|
В каталоге `docs` этого репозитория лежит [шаблон](../docs/DataDictionary_Template.xlsx) словаря данных.
|
|
|
|
|
|
@@ -26,7 +22,7 @@
|
|
|
>
|
|
|
>Посещения клиента в рамках оказания услуг должны обязательно фиксироваться в БД.
|
|
|
|
|
|
-Для начала, размеремся какие параметры заносятся в *словарь данных*
|
|
|
+Для начала, разберёмся какие параметры заносятся в *словарь данных*
|
|
|
|
|
|
* **Key** - признак, что поле является ключём. Для разных типов ключей приняты определенные обозначения:
|
|
|
|
|
|
@@ -34,8 +30,6 @@
|
|
|
* **FK** - внешний ключ (foreign key)
|
|
|
* **IDX** - индекс (альтернативный ключ)
|
|
|
|
|
|
- >Не нашёл как описывать составные ключи
|
|
|
-
|
|
|
* **Field Name** - название атрибута (латиницей). Ещё раз напоминаю, что мы везде используем **CamelCase**
|
|
|
|
|
|
* **Data Type/Field Size** - тип данных / размерность поля
|
|
|
@@ -57,23 +51,19 @@
|
|
|
|
|
|
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 | | Электронная почта
|
|
|
+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 | | | Ссылка на словарь **Теги клиента**. Причем тут опять же в зависимости от ТЗ может понадобиться промежуточная таблица, если у клиента может быть несколько тегов
|
|
|
-
|
|
|
-
|
|
|
-<table style="width: 100%;"><tr><td style="width: 40%;">
|
|
|
-<a href="../articles/5_1_1_1_erd2.md">Основы проектирования баз данных.
|
|
|
-</a></td><td style="width: 20%;">
|
|
|
-<a href="../readme.md">Содержание
|
|
|
-</a></td><td style="width: 40%;">
|
|
|
-<a href="../articles/5_1_1_1_erd_workbench.md">Создание ER-диаграммы
|
|
|
-</a></td><tr></table>
|
|
|
+ | firstVisit | DATE | | | Дата первого посещения (регистрации). В принципе эту дату можно достать из таблицы "Посещения клиента"
|
|
|
+ | photo | BLOB | | | Фотографию клиента можно хранить в базе, но можно и в каком-либо каталоге на сервере
|
|
|
+FK | tagId | INT | | | Ссылка на словарь **Теги клиента**. Причем тут опять же в зависимости от ТЗ может понадобиться промежуточная таблица, если у клиента может быть несколько тегов
|
|
|
+
|
|
|
+
|
|
|
+Предыдущая лекция | | Следующая лекция
|
|
|
+:----------------:|:----------:|:----------------:
|
|
|
+[Основы проектирования баз данных. ERD.](./5_1_1_1_erd2.md) | [Содержание](../readme.md#проектирование-баз-данных) | [Основы SQL](./sql_for_beginner.md)
|
