Теория и практика построения баз данных

Ошибки проще и дешевле исправлять на ранних стадиях процесса разработки базы данных, чем на поздних. Например, изменение максимального кардинального числа связи с 1:N на N:M на стадии моделирования данных сводится просто к внесению соответствующего исправления в ER-диаграмму. Но когда база данных уже разработана и наполнена данными и написаны прикладные программы для ее обработки, такое изменение потребует значительной переделки, возможно, даже недель труда. Поэтому важно определить, какая модель данных требуется, прежде чем начинать ее воплощать.
На какие вопросы может дать ответ база данных, реализованная на основе данного проекта?
♦ Какие и кем были проведены индивидуальные занятия?
♦ Какие клиенты посещали индивидуальные занятия у Джека?
♦ Кто является постоянным инструктором клуба?
♦ Какие инструкторы должны прийти на танцевальный вечер в пятницу?
При проверке модели данных вы можете формулировать такие вопросы и задавать их пользователям, которых затем можно попросить составить свой список вопросов. Они могут задавать вопросы, касающиеся структуры базы данных, чтобы проверить ее соответствие поставленным требованиям. Например, представьте, что пользователи спрашивают, какие клиенты посетили вечер танцев в прошлую пятницу. Разработчики модели данных, изображенной на рис. 3.19, должны прийти к заключению, что их структура неверна, поскольку на поставленный вопрос с помощью данной ER-модели ответить невозможно. Если требуется ответ на этот вопрос, необходимо ввести связь между сущностями КЛИЕНТ и ВЕЧЕР_ТАНЦЕВ.
Очевидно, что посредством такого неформального и нечетко структурированного процесса невозможно доказать, что структура является правильной. Тем не менее, это прагматичный метод, пригодный для определения потенциальной правильности структуры. И даже такой метод все же лучше, чем отсутствие проверки вообще!