Методология проектирования БД

к.э.н., доцент Д.Г. Корнеев
2009 год

Методология проектирования БД.

технических приемов, инструментов, документации и нацеленный на поддержку и упрощение

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

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

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

конструирования информационной модели предприятия на основе существующих конкретных моделей данных,

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

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

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

Физическое проектирование

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

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

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

Определение типов сущностей.
Этап1.2. Определение типов связей.
Этап1.3. Определение атрибутов и связывание их с типами сущностей и связей.
Этап1.4. Определение доменов атрибутов.
Этап1.5. Определение атрибутов, являющихся потенциальными и первичными ключами.
Этап1.6. Создание диаграммы "сущность-связь".
Этап1.7. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

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

пользователей.
Этап 2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель.
Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных.
Этап 2.3. Проверка модели с помощью правил нормализации.
Этап 2.4. Проверка модели в отношении транзакций пользователей.
Этап 2.5. Создание диаграмм "сущность-связь".
Этап 2.6. Определение требований поддержки целостности данных.
Этап 2.7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями.

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

модель данных.
Этап 3.2. Проверка глобальной логической модели данных.
Этап 3.3. Проверка возможностей расширения модели в будущем.
Этап 3.4. Создание окончательного варианта диаграммы "сущность-связь".
Этап 3.5. Обсуждение глобальной логической модели данных с пользователями.

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

основных таблиц в среде целевой СУБД.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.
Этап 5. Проектирование физического представления базы данных.
Этап 5.1. Анализ транзакций.
Этап 5.2. Выбор файловой структуры.
Этап 5.3. Определение вторичных индексов.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.
Этап 5.5. Определение требований к дисковой памяти.

механизмов защиты.
Этап 6.1. Разработка пользовательских представлений (видов).
Этап 6.2. Определение прав

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

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

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

общем поле деятельности предприятия - например, производство, маркетинг, сбыт, управление

кадрами или складской учет.

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

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

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

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

Концептуальное проектирование (продолжение)

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

типов связей.
• Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей.
• Этап 1.4. Определение доменов атрибутов.
• Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами.
• Этап 1.7. Создание диаграммы "сущность-связь".
• Этап 1.8. Обсуждение локальных концептуальных моделей данных с пользователями.

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

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

представляющие интерес концепции и исключаются все существительные, которые просто определяют

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

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

затруднено из-за способа, посредством которого они представлены в спецификациях. Зачастую

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

пользователи часто используют синонимы или омонимы. Синонимами называются слова, сходные

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

предыдущем этапе.
После выделения сущностей следующим этапом разработки будет установление всех

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

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

удовлетворения требований к проекту. Так, в предыдущем примере были выделены

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

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

существуют только между двумя сущностями.
Однако, следует проявлять осторожность и

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

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

сущностей было бы полезно проверить на наличие между ними некоторой

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

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

кардинальность каждой из них. Каждая связь может иметь кардинальность либо "один к одному" (1:1), либо "один ко многим" (l:М), либо "многие ко многим" (М:М). Если известны конкретные значения кардинальности или хотя бы верхний или нижний предел этих значений, то эту информацию обязательно нужно зафиксировать в документации.

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

типами сущностей или связей.
На этом этапе предлагаемой методологии необходимо выявить

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

может быть либо простым, либо составным.
Составные атрибуты представляют собой набор

простых атрибутов. Например, атрибут "Адрес" может быть простым и представлять все элементы адреса как единое значение: "115 Durnbarton Road, Partick, Glasgow, G11 6YG".
В другом варианте этот же атрибут может быть представлен как составной, Т.е. состоящий из серии простых атрибутов, содержащих различные элементы адреса. В этом случае то же самое значение может быть разделено на такие атрибуты, как "Улица" (115 Dumbarton Road), "Район" (Partick), "Город" (Glasgow) и "Почтовый код" (Gll 6YG).

определяется требованиями, предъявляемыми к приложению пользователем. Если пользователь не нуждается

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

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

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

работников данного отделения предприятия;
•возраст работника;
•общая сумма зарплаты всего персонала данного отделения предприятия;
•количество объектов недвижимости, которыми занимается персонал данного отделения предприятия.

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

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

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

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

локальной концептуальной модели данных состоит в определении доменов атрибутов для всех атрибутов, присутствующих в модели. Доменом называется некоторый пул значений, элементы которого выбираются для присвоения значений одному или более атрибутам. Ниже приведено несколько примеров доменов.
• Домен атрибута, включающий допустимые номера отделений предприятия. Он состоит из трехсимвольных строк, в которых первый символ является буквой, а остальных два - цифрами, задающими числа в диапазоне 1-99.
• Домен атрибута «Пол». Допустимыми значениями для атрибута "Пол" сущности "Работник" являются "М" и "Ж". Домен этого атрибута состоит из двух строк длиной в один символ, имеющих указанные значения.

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

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

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

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