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

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

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

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

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

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

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

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

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

Этапы концептуального проектирования базы данных:

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа существенно упрощается, если сложная система помимо обширного текстового описания имеет и некоторое визуальное представление. Для представления сущностей и связей между ними обычно используют диаграммы"сущность-связь" (ЕR-диаграммы).

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

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

- набор допустимых значений для атрибута;

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

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

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

- Используйте потенциальный ключ с минимальным набором атрибутов.

- Используйте тот потенциальный ключ, вероятность изменения значений которого минимальна.

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

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

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

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

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

19 Цель логического проектирования БД, правила генерирования реляционных таблиц для простых связей между сущностями и для связей типа «уточнение/обобщение»

(Подробнее о логическом проектировании см. пункт 20 – Методология логического проектирования базы данных)

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

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

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

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

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

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

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

2. Непосредственно на ЕR-диаграммах отобразить все пути доступа к данным, необходимые для выполнения транзакций.

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

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

Существует несколько стратегий обработки попыток удаления строки родительского отношения, на которую ссылаются одна или несколько строк дочернего отношения: NO ACTION, CASCADE, SET NULL, SET DEFAULT и NO СНЕСК.

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

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