Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Posibnik.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
5.62 Mб
Скачать

Тема 5 Методология проектирования баз данных Введение в методологию проектирования баз данных

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

Что такое методология проектирования

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

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

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

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

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

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

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

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

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

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

Важнейшие факторы успешного завершения проектирования базы данных

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

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

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

  • Разрабатывать систему исходя из существующих характеристик данных.

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

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

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

  • Для описания дополнительных семантических требований к данным ис­пользовать средства языка DBDL (Database Design Language).

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

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

Общий обзор процедуры проектирования базы данных

В целом, проце­дура разработки включает следующие этапы:

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

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

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

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

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

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

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

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

первичными ключами.

Этап 1.6. Специализация или генерализация типов сущностей (необя­зательный

этап).

Этап 1.7. Создание диаграммы "сущность-связь".

Этап 1.8. Обсуждение локальных концептуальных моделей данных с

конечными пользователями.

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

Этап 2. Построение и проверка локальной логической модели данных на ос­нове

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

Этап 2.1. Преобразование локальной концептуальной модели данных

в локальную логическую модель.

Этап 2.2. Определение набора отношений исходя из структуры ло­кальной

логической модели данных.

Этап 2.3. Проверка модели с помощью правил нормализации.

Этап 2.4. Проверка модели в отношении транзакций пользователей.

Этап 2.5. Создание диаграмм "сущность-связь".

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

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

конечными пользователями.

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

Этап 3.1. Слияние локальных логических моделей данных в единую

глобальную модель данных.

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

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

Этап 3.4. Создание окончательного варианта диаграммы "сущность-связь".

Этап 3.5. Обсуждение глобальной логической модели данных с

пользователями.

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

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

Этап 4.1. Проектирование основных отношений.

Этап 4.2. Разработка способов получения производных данных.

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

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

Этап 5.1. Анализ транзакций.

Этап 5.2. Выбор файловой структуры.

Этап 5.3. Определение индексов.

Этап 5.4. Оценка потребности в дисковом пространстве.

Этап 6. Проектирование пользовательских представлений.

Этап 7. Проектирование средств защиты.

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]