Лекция 8. Методология проектирования баз данных. Концептуальное проектирование

Цель лекции: Изучение общей методологии проектирования баз данных и этапа концептуального проектирования.

Время: 4 часа.

Учебные вопросы:

1. Обзор общей методологии проектирования баз данных

2. Создание локальной концептуальной модели данных

1. Обзор общей методологии проектирования баз данных

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

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

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

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

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

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

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

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

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

Можно сформулировать некоторые рекомендации, которым необходимо следовать для успешного проектирования базы данных.

• Поддерживайте постоянную и активную связь с будущими пользователями приложения.

• При проведении процедур моделирования данных придерживайтесь обоснованной методологии.

• Применяйте подходы, предусматривающие создание приложений, управляемых данными.

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

• В процессе реализации методологии моделирования данных применяйте методы разработки концептуальной модели, нормализации и проверки целостности транзакций.

• Для представления модели данных как можно шире используйте схемы.

• Для описания дополнительных семантических требований к данным используйте средства языка проектирования баз данных.

• Разработайте словарь описания данных.

• Возвращайтесь к уже выполненным ранее этапам, если это требуется для достижения оптимальных результатов

Изложенные выше рекомендации учтены в методологии проектирования баз данных, которая и рассматривается в данном курсе.

Рассмотрим теперь кратко содержание этапов разработки БД, а затем перейдем к подробному рассмотрению концептуального проектирования.

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

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

2. Определение типов сущностей.

3. Определение типов связей.

4. Определение атрибутов и связывание их с типами сущностей и связей.

5. Определение доменов атрибутов.

6. Определение атрибутов, являющихся потенциальными и первичными ключами.

7. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

8. Проверка модели на отсутствие избыточности.

9. Проверка соответствия локальной концептуальной модели конкретным пользова­тельским транзакциям.

10. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

Логическое проектирование базы данных (для реляционной модели) содержит следующие этапы:

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

2. Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап).

3. Определение набора отношений исходя из структуры локальной логической модели данных.

4. Проверка отношений с помощью правил нормализации.

5. Проверка соответствия отношений требованиям пользовательских транзакций.

6. Определение требований поддержки целостности данных.

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

8. Создание и проверка глобальной логической модели данных.

9. Слияние локальных логических моделей данных в единую глобальную модель данных.

10. Проверка глобальной логической модели данных.

11. Проверка возможностей расширения модели в будущем.

12. Обсуждение глобальной логической модели данных с пользователями.

Физическое проектирование базы данных (с использованием реляционной СУБД) предусматривает:

1. Перенос глобальной логической модели данных в среду целевой СУБД.

2. Проектирование базовых отношений в среде целевой СУБД.

3. Проектирование отношений, содержащих производные данные.

4. Реализация ограничений предметной области.

5. Проектирование физического представления базы данных.

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

9. Определение требований к дисковой памяти.

10. Разработку пользовательских представлений.

11. Разработку механизмов защиты.

12. Анализ необходимости введения контролируемой избыточности.

13. Организацию мониторинга и настройку функционирования операционной системы.

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

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

На третьем этапе выполняется объединение локальных логических моделей данных (отражающих представление о предметной области отдельных типов пользователей) в единую глобальную логическую модель данных всего предприятия (обобщающую представления о предметной области всех типов пользователей). Глобальная логическая модель проверяется по такому же принципу, как и локальные модели; это позволяет убедиться в том, что ее структура является правильной и поддерживает все необходимые транзакции. Этот этап обычно требуется, если приложение состоит более чем из одного представления.

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

2. Создание локальной концептуальной модели данных

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

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

Каждая локальная концептуальная модель данных состоит из следующих компонентов:

• типы сущностей;

• типы связей;

• атрибуты и домены атрибутов;

• первичные ключи;

• альтернативные ключи;

• ограничения целостности.

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

1. Определение типов сущностей.

2. Определение типов связей.

3. Определение атрибутов и связывание их с типами сущностей и связей..

4. Определение доменов атрибутов.

5. Определение атрибутов, являющихся потенциальными и первичными ключами.

6. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

7. Проверка модели на отсутствие избыточности,

8. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

9. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

Этап 1.1 .Определение типов сущностей

Целью данного этапа является определение основных типов сущностей, которые требуются для конкретного представления.

На этом этапе определяются основные объекты, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель. Один из методов идентификации сущностей состоит в изучении спецификаций по выполнению конкретных функций пользователя в данной организации. Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного и прилагательного (например, "личный номер", "фамилия сорудника", "номер подразделения", "адрес сотрудника", "оклад денежного содержания" и т.п.). Затем среди них выбираются самые значимые объекты (категории работников, направления деятельности) или важные концепции и исключаются все существительные, которые просто определяют другие объекты. Например, такие свойства, как "личный номер" и "фамилия сотрудника", могут быть объединены в сводном объекте под названием "сотрудник".

Альтернативный способ идентификации сущностей состоит в поиске объектов, которые существуют независимо от других. Например, объект «сотрудник», безусловно, является сущностью, поскольку очевидно, что организация не может не иметь сотрудников, хотя на каком-то этапе проектирования могут не рассматриваться такие атрибуты сущности "сотрудник", как имя, должность и дата рождения. В этой работе существенную помощь могут оказать пользователи создаваемого приложения.

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

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

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

Документирование типов сущностей

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