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

9.1. Подходы к проектированию баз данных

Можно выделить два основных подхода к проектированию баз данных: нисходящий и восходящий (слайд 2).

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

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

• реляционная модель не предоставляет достаточных средств для фиксации смысла данных, т.е. семантика предметной области не фиксируется непосредственно в отношениях;

• для многих приложений трудно моделировать предметную область на основе плоских таблиц;

• хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не имеет средств представления (отражения семантики) этих зависимостей;

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

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

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

Кроме этих подходов для проектирования могут применяться другие подходы, например, подход «от общего к частному» или «смешанная стратегия проектирования».

9.2. Этапы нисходящего подхода к проектированию баз данных

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

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

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

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

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

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

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

Этап 1.1.1. Выявление типов сущностей

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

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

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

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

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

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

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

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

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

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

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

Этап 1.2.3. Документирование типов связей

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

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

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

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

Этап 1.3.1. Выявление простых и составных атрибутов

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

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

Этап 1.3.2. Выявление производных атрибутов

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

Этап 1.3.3. Документирование атрибутов

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

• имя атрибута и его описание;

• любые алиасы, или синонимы, имеющиеся для данного атрибута;

• тип данных и размерность значения;

• значение, принимаемое для атрибута по умолчанию (если таковое имеется);

• является ли атрибут обязательным (т.е. может ли он отсутствовать или иметь значение NULL);

• является ли атрибут составным и, если это так, из каких простых атрибутов он состоит;

• является ли данный атрибут производным и, если это так, какой метод следует использовать для вычисления его значения;

• является ли данный атрибут множественным

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

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

Этап 1.4.1. Определение доменов

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

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

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

Этап 1.4.2. Документирование доменов атрибутов

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

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

Этап 1.5.1. Определение потенциальных ключей

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

Этап 1.5.2. Выбор первичного ключа

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

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

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

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

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

Этап 1.5.3. Документирование первичных и альтернативных ключей

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

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

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

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

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

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

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

Методы логического проектирования баз данных реляционного типа

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

Этап 2. Построение и проверка локальной логической модели данных для отдельных представлений каждого из типов пользователей (слайд 5)

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

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

1. Удаление связей типа M:N (слайд 6).

2. Удаление сложных связей(слайд 7).

3. Удаление рекурсивных связей (слайд 8).

4. Удаление связей с атрибутами(слайд 9).

5. Удаление множественных атрибутов (слайд 10).

6. Перепроверка связей типа 1:1.

7. Удаление избыточных связей.

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

Связи, которые сущность имеет с другими типами сущностей, представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута(ов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая — дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть роль внешнего ключа. Операции пересылки внешних ключей проверяются для связей 1:1, 1:М, суперклассподкласс

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

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

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

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

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

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

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

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

Создание окончательного варианта диаграмм "сущность-связь" (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.

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

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

Этап 2.6.1. Обязательные данные

Некоторые атрибуты не могут иметь пустого значения.

Этап 2.6.2. Ограничения для доменов атрибутов

Этап 2.6.3. Целостность сущностей

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

Этап 2.6.4. Ссылочная целостность (слайд 12)

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

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

Случай 2. Удаление строки из дочернего отношения. При удалении строки из дочернего отношения никаких нарушений ссылочной целостности не происходит.

Случай 3. Обновление внешнего ключа в строке дочернего отношения. Этот случай подобен случаю 1.

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

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

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

CASCADE. При удалении строки из родительского отношения автоматически удаляются все ссылающиеся на нее строки дочернего отношения.

SET NOLL. При удалении строки из родительского отношения во всех ссылающихся на нее строках дочернего отношения в атрибут внешнего ключа записывается пустое значение.

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

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

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

Этап 2.6.5. Требования данного предприятия

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

Этап 2.6.6. Документирование всех ограничений целостности данных

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

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

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

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

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

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

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

1. Анализ имен сущностей и их первичных ключей.

2. Анализ имен связей.

3. Слияние общих сущностей из отдельных локальных моделей.

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

5. Слияние общих связей из отдельных локальных моделей.

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

7. Проверка на наличие пропущенных сущностей и связей.

8. Проверка корректности внешних ключей.

9. Проверка соблюдения ограничений целостности.

10. Выполнение чертежа глобальной логической модели данных.

11. Обновление документации.

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

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

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

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

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

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

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

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

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

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

баз данных реляционного типа

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

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

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

Необходимо принять решение о способе реализации таблиц базы данных. Это решение зависит от типа выбранной целевой СУБД. Таблицы можно реализовывать с помощью визуальных компонент СУБД или с помощью SQL-запросов.

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

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

Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД

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

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

Документирование проекта реализации бизнес-правил

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

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

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

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

Понятие о системных ресурсах

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

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

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

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

• Ожидаемая частота выполнения транзакций.

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

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

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

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

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

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

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

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

Целью выполнения данного этапа является выбор оптимальной файловой органи­зации для каждой из таблиц. Рекомендации по выбору файловой организации дают­ся исходя из следующих вариантов типов файлов:

• последовательные файлы (heap);

• хешированные файлы (hash);

• индексно-последовательные файлы (ISAM);

• двоичные деревья (В⁺-Тгее).

Этап 5.2.5. Документирование результатов выбора структуры файлов таблиц

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 5.4.1. Анализ целесообразности использования производных данных

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

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

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

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

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

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

Этап 5.4.2. Анализ целесообразности дублирования атрибутов или объединения отношений

Объединение членов связей типа "один к одному" (1:1). Объединять имеет смысл только такие пары отношений, которые часто используются совместно и значительно реже — по отдельности.

Дублирование неключевых атрибутов в связях типа "один ко многим" (1:М) с целью сокращения числа выполняемых соединений отношений. Поставив своей це­лью возможное сокращение или полное устранение необходимости выполнять соединения отношений при обработке часто выполняемых или критических запросов, необходимо про­анализировать преимущества, которые могут быть получены от дублирования одного или нескольких неключевых атрибутов родительского отношения в дочернем отношении для всех связей типа 1:М.

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

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

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

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

Дублирование атрибутов внешних ключей в связях типа "один ко многим" (1:М ) с целью сокращения числа выполняемых соединений отношений.

Дублирование атрибутов связей типа "многие ко многим" (M:N) с целью сокра­щения числа выполняемых соединений отношений. В процессе создания логической модели базы данных каждая связь типа M:N была преобразована в две связи типа 1:М. Чтобы получить данные через связь типа M:N, необходимо выполнить соединение трех отношений — двух исходных и еще одного, вновь добавленного промежуточного отношения. В некоторых случаях может потребоваться сократить количество выполняемых соединений отношений за счет дублирования атрибутов од­ного из исходных отношений в промежуточное отношение.

Введение повторяющихся групп атрибутов. Повторяющиеся группы атрибутов были удалены из логической модели данных при приведении всех сущностей к пред­ставлению в первой нормальной форме. Повторяющиеся группы были выделены в отдельные отношения, образующие с исходным (родительским) отношением связь ти­па 1:М. Тем не менее повторное введение в отношения групп повторяющихся атрибу­тов является эффективным способом повышения производительности системы.

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

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

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

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

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

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

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

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

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

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

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

Как правило, представления создаются с помощью операторов языка SQL. (слайд 17)

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

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

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

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

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

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

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

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

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

• Устранить необходимость приобретения дополнительного оборудования.

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

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

• Уменьшение времени ответа системы повышает психологический комфорт пользователей

• Уменьшение времени ответа системы повышает удовлетворение клиентов от общения с персоналом