Лекция №3 Процесс разработки бд.
С чего начать разработку БД?
Общие стратегии. Для того, чтобы построить эффективную базу данных, разработчики должны ясно представлять себе пользовательскую модель. Для этого они строят модель данных. Существует 2 общие стратегии.
1. Сверху-вниз: это когда задача решается от общего к частному, крупные задачи разбиваются на более мелкие, которые разбиваются еще на более мелкие и т.д. пока для каждой не найдется простого решения.
Плюсы: когда мы доходим до написания кода у нас уже есть проект системы
Минусы: не всегда очевидно как разбивать задачу, можно попасть в паралич анализа
2. Снизу-вверх: от малого к большему, решаются конкретные задачи, их результаты объединяются в более крупное решение
Плюсы: начать можно здесь и сейчас, после первой итерации можно уже что-то показывать заказчику
Минусы: качество постановки задач и собрание всего этого в кучу так, что бы работало, да еще и как надо зависит от профессионализма разработчиков, а так же представителей заказчика
В общем, в первом случае молятся (делают основной упор) на процесс, а во втором на людей
Таким образом, наиболее важная часть стадии разработки БД – это создание модели данных пользователя. Как бы это не делалось, сверху-вниз или наоборот, моделирование включает в себя изучение предметной области, опрос пользователей, документирование их требований, составляется тех. задание, которое должно показать, какие объекты будут в БД, их структуру, как они будут связаны между собой.
Логическая структура БД. Схема БД определяет структуру БД, ее таблицы, связи, домены, а также деловой регламент.
Пример. Колледж права и экономики в Москве. Бывшие студенты добились большого успеха и решили поблагодарить колледж и проспонсировали спортивные секции. Теперь студенты колледжа на досуге готовятся и участвуют в спортивных соревнованиях, отстаивают честь колледжа. Все было бы ничего, но колледж стал испытывать проблемы с учетом выдаваемого спортивного инвентаря. Схема БД для системы учета спортинвентаря будет содержать следующие компоненты:
1. Таблицы:
Капитаны (ФИО, Адрес, Телефон)
Инвентарь (Наименование, Количество, Описание, ДатаНач, ДатаКон)
Т.к. ни ФИО, ни наименование уникальными не являются, то мы добавим к этим таблицам еще столбцы, содержащие уникальный номер, получим:
Капитаны (Капитан_ИД, ФИО, Адрес, Телефон)
Инвентарь (Инвентарь_ИД, Наименование, Количество, Описание, ДатаНач, ДатаКон)
2. Связи:
Эти две таблицы могут быть связаны следующим образом: Одна строка таблицы Капитаны связана с несколькими строками таблицы Инвентарь, но одна и только одна строка таблицы Инвентарь связана только с одной строкой таблицы Капитаны. В данном случае нам не видно и не понятно как же связаны эти таблицы. Для формирования связи мы должны добавить еще один столбец в таблицу Инвентарь, который будет показывать номер капитана.
Получим:
Капитаны (Капитан_ИД, ФИО, Адрес, Телефон)
Инвентарь (Инвентарь_ИД, Наименование, Количество, Описание, ДатаНач, ДатаКон, капитан_ИД)
По такой структуре мы легко сможем определить, кому из капитанов был выдан тот или иной инвентарь.
3. Домены. Это множество значений, которое может принимать столбец. В нашем примере, получим следующие домены:
Столбец |
Домен |
Уникальный |
Инвентарь_ИД |
Целое число |
+ |
Наименование |
Текст |
|
Количество |
Целое число |
|
Описание |
Текст |
|
ДатаНач |
Дата |
|
ДатаКон |
Дата |
|
Капитан_ИД |
Целое число |
|
4. Деловой регламент. Это ограничения на возможные действия пользователя, которые необходимо отразить в БД и ее приложениях. Для нашего примера, это могут быть следующие ограничения:
- Чтобы капитан мог получить инвентарь у него должен быть местный домашний телефон;
- Нельзя выдавать капитанам инвентаря в количество более 7 штук;
- По окончании каждого семестра капитан обязан сдать весь инвентарь;
- Нельзя выдавать новый инвентарь, если есть задолженность по-старому.