1.3. Курс в двух словах.

Перед тем как начнем знакомство с концептуальным и логическим проектированием базы данных попробуем на простом примере раскрыть суть всего курса ОБДЗ. Допустим, что Вам поставлена задача создать базу данных, позволяющую оперативно выдавать информацию о прогульщиках занятий. Необходимо, чтобы было известно по каждому прогульщику, сколько часов и какой предмет он не посещал.

Начнем с того, что базу данных назовем совокупностью двухмерных таблиц. Каждая таблица состоит из столбцов и строк. Каждый столбец имеет свой заголовок.

Разделим информацию, которая содержится в базе данных на два типа: справочную и оперативную. Исходя из этого, в нашей базе данных учета посещаемости занятий напрашиваются две справочные таблицы: список студентов и список предметов, и одна таблица с оперативной информацией, в которой будем вести учет посещаемости студентов (рис. 1.2). Остается добавить, что сначала необходимо вносить данные в таблицы, которые относятся к справочной информации, а затем – к оперативной.

Рис. 1.2. База данных учета посещаемости занятий.

Обратите внимание, что в столбцах «№ зач.» и «Шифр пр.» таблицы «Посещаемость» находятся только значения, содержащиеся в столбце «№ зач.» таблицы «Студенты» и «Шифр» таблицы «Предметы» соответственно. Таким образом, можно по № зачетки из таблицы «Посещаемость» узнать фамилию прогульщика, а по шифру предмета определить какой предмет он прогулял. С другой стороны, можно сказать, кто из студентов не входит в число прогульщиков, и какой предмет посещают все студенты. Попробуйте назвать фамилию добросовестного студента самостоятельно. Назовите предмет, который никто не прогуливает.

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

На рис. 1.2. представлен взгляд со стороны разработчика базы данных. Попробуйте самостоятельно изобразить таблицу, в которой вам было бы удобно увидеть, сколько и по какому предмету было пропущено занятий каждым студентом. Этим вопросом мы займемся во второй половине нашего курса, когда будем изучать «Представления данных».

Такая кажущаяся простота не должна Вас обманывать. Только опыт создания баз данных поможет Вам выработать свои собственные приемы и подходы. Но для этого Вы должны приобрести некоторую базу. В предлагаемом курсе рассмотрены концепции и приемы проектирования баз данных, с которыми полезно ознакомиться и взять их за основу.

1.4. Концептуальное и логическое проектирование базы данных.

Концептуальное проектирование базы данных. Процесс создания модели используемой на предприятии информации, не зависящей от любых физических аспектов ее представления.

Первая фаза процесса проектирования базы данных называется концептуальным проектированием базы данных. Она заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации. При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для фазы логического проектирования базы данных.

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

Вторая фаза проектирования базы данных называется логическим проектированием базы данных. Ее цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная или сетевая модель).

Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой — реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные аспекты выбранной СУБД — например, любые особенности физической организации ее структур хранения данных и построения индексов.

В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки корректности логической модели данных используется метод нормализации. Нормализация гарантирует, что выведенные из существующей модели данных отношения не будут обладать избыточностью данных, способной вызвать аномалии обновления после их физической реализации.

Построенная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами нахождения компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных также играет важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе.

Концептуальное и логическое проектирование — это итеративные процессы, которые начинаются в определенный момент времени и продолжаются в виде практически бесконечного ряда уточнений и улучшений. Их следует рассматривать как некий процесс изучения. По мере углубления разработчиками понимания принципов работы предприятия и смысла используемых данных, они выражают это понимание в виде той или иной модели данных. Собранная информация, в свою очередь, может потребовать внесения определенных изменений в другие части создаваемого проекта.

Концептуальное и логическое проектирование базы данных — важнейшие факторы общего успеха разрабатываемой системы. Если созданный проект не является точным отражением методов работы и структуры предприятия, то будет очень сложно, если вообще возможно, определить все необходимые пользователям представления (внешние схемы) или организовать поддержку целостности базы данных. Кроме того, могут возникнуть трудности с физической реализацией базы данных или обеспечением приемлемой производительности системы. В то же время способность адаптации к изменениям является признаком удачно спроектированной базы данных. Следовательно, всегда имеет смысл потратить необходимые время и энергию на создание наилучшего из возможных проектов.

Логическая модель, отражающая особенности представления о функционировании предприятия одновременно многих типов пользователей, называется глобальной логической моделью данных. Существует два основных подхода к созданию глобальной логической модели данных предприятия — это централизованный подход и подход на основе интеграции представлений.

Централизованный подход. Слияние требований отдельных пользователей, выраженных в виде различных пользовательских представлений, в единый набор требований всех пользователей, который исполь­зуется для создания глобальной логической модели данных.

При использовании первого подхода, который принято называть централизованным, требования всех существующих типов пользователей в отношении различных областей применения приложения объединяются с образованием единого списка требований. Характерной особенностью этого подхода является то, что списки требований состав­ляются до создания глобальной логической модели данных. Этот подход применим только при условии, что описываемая база данных не слишком велика или сложна.

Метод интеграции представлений. Слияние отдельных локальных логических моделей данных, отражающих представления различных групп пользователей, в единую глобальную логическую модель данных.

При использовании второго подхода, который принято называть методом интеграции представлений, осуществляется слияние отдельных моделей данных, отражающих представлениях разных групп пользователей и называемых локальными логическими моделями данных, в единую глобальную логическую модель данных всего предприятия. Этот подход более управляем, поскольку вся работа предварительно разделяется на более мелкие и легко контролируемые части. Трудности обычно возникают лишь при попытках слияния локальных моделей данных, созданных разными разработчиками, которые могут использовать различные термины для одного и того же понятия или, наоборот, связывать один и тот же термин с разными понятиями.