Лекция №3 Процесс разработки БД.

С чего начать разработку БД?

1. Общие стратегии. Для того, чтобы построить эффективную базу данных, разработчики должны ясно представлять себе пользовательскую модель. Для этого они строят модель данных. Существует 2 общие стратегии.

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

Плюсы: когда мы доходим до написания кода у нас уже есть проект системы

Минусы: не всегда очевидно как разбивать задачу, можно попасть в паралич анализа

2. Снизу-вверх: от малого к большему, решаются конкретные задачи, их результаты объединяются в более крупное решение

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

Минусы: качество постановки задач и собрание всего этого в кучу так, что бы работало, да еще и как надо зависит от профессионализма разработчиков, а так же представителей заказчика

В общем, в первом случае молятся (делают основной упор) на процесс, а во втором на людей

Таким образом, наиболее важная часть стадии разработки БД – это создание модели данных пользователя. Как бы это не делалось, сверху-вниз или наоборот, моделирование включает в себя изучение предметной области, опрос пользователей, документирование их требований, составляется тех. задание, которое должно показать, какие объекты будут в БД, их структуру, как они будут связаны между собой.

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

Пример. Колледж права и экономики в Москве. Бывшие студенты добились большого успеха и решили поблагодарить колледж и проспонсировали спортивные секции. Теперь студенты колледжа на досуге готовятся и участвуют в спортивных соревнованиях, отстаивают честь колледжа. Все было бы ничего, но колледж стал испытывать проблемы с учетом выдаваемого спортивного инвентаря. Схема БД для системы учета спортинвентаря будет содержать следующие компоненты:

1. Таблицы:

Капитаны (ФИО, Адрес, Телефон)

Инвентарь (Наименование, Количество, Описание, ДатаНач, ДатаКон)

Т.к. ни ФИО, ни наименование уникальными не являются, то мы добавим к этим таблицам еще столбцы, содержащие уникальный номер, получим:

Капитаны (Капитан_ИД, ФИО, Адрес, Телефон)

Инвентарь (Инвентарь_ИД, Наименование, Количество, Описание, ДатаНач, ДатаКон)

2. Связи:

Эти две таблицы могут быть связаны следующим образом: Одна строка таблицы Капитаны связана с несколькими строками таблицы Инвентарь, но одна и только одна строка таблицы Инвентарь связана только с одной строкой таблицы Капитаны. В данном случае нам не видно и не понятно как же связаны эти таблицы. Для формирования связи мы должны добавить еще один столбец в таблицу Инвентарь, который будет показывать номер капитана.

Получим:

Капитаны (Капитан_ИД, ФИО, Адрес, Телефон)

Инвентарь (Инвентарь_ИД, Наименование, Количество, Описание, ДатаНач, ДатаКон, капитан_ИД)

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

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

4. Деловой регламент. Это ограничения на возможные действия пользователя, которые необходимо отразить в БД и ее приложениях. Для нашего примера, это могут быть следующие ограничения:

- Чтобы капитан мог получить инвентарь у него должен быть местный домашний телефон;

- Нельзя выдавать капитанам инвентаря в количество более 7 штук;

- По окончании каждого семестра капитан обязан сдать весь инвентарь;

- Нельзя выдавать новый инвентарь, если есть задолженность по-старому.