19277

Проектирование фактографических ИС и хранилищ данных. Подходы к проектированию БД

Лекция

Информатика, кибернетика и программирование

Лекция 9. Проектирование фактографических ИС и хранилищ данных. Подходы к проектированию БД. Этапы нисходящего подхода к проектированию баз данных. Проектирование хранилищ данных. 9.1. Подходы к проектированию баз данных Можно выделить два основных подхода к про

Русский

2013-07-11

298.35 KB

39 чел.

Лекция 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. Организация мониторинга и настройка функционирования системы

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

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

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

9.3. Проектирование хранилищ данных

Хранилище данных – Предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

Типичная архитектура хранилища данных показана на слайде 18

Исходные данные, помещаемые в хранилище, поступают из следующих источников.

  •  Оперативные данные мейнфреймов, содержащиеся в иерархических и сетевых базах данных первого поколения.
  •  Данные различных подразделений, сохраняемые в специализированных файловых системах типа VSAM, RMS и базах данных таких реляционных СУБД, как Informix и Oracle.
  •  Закрытые данные, которые хранятся на рабочих станциях и закрытых серверах.
  •  Внешние системы, например Internet, коммерчески доступные базы данных или базы данных, принадлежащие поставщикам или клиентами организации.

Менеджер загрузки (load manager), который часто называют внешним (front-end) компонентом, выполняет все операции, связанные с извлечением и загрузкой данных в хранилище.

Менеджер хранилища (warehouse manager) выполняет все операции, связанные с управлением информацией, помещенной в хранилище данных.

Менеджер запросов (query manager), который часто называют внутренним (back-end) компонентом, выполняет все операции, связанные с управлением пользовательскими запросами.

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

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

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

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

Средства доступа к данным конечного пользователя могут быть:

  •  инструменты создания отчетов и запросов;
  •  инструменты разработки приложений;
  •  инструменты информационной системы руководителя (Executive Information SystemEIS);
  •  инструменты оперативной аналитической обработки (OLAP-инструменты);
  •  инструменты разработки данных.

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

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

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

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

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

Метапоток – Процессы, связанные с управлением метаданными.

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

Основные отличительные черты магазина данных от хранилища данных:

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

Метод проектирования базы данных как компонента хранилища или магазина данных, который называется моделированием размерностей (dimensionality modeling)

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

Проектирование схем типа „звезда"

Схема "звезда" –Логическая структура, в центре которой находится таблица фактов (с детальными данными), окруженная таблицами размерностей (со ссылочными данными).

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

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

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

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

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

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

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

Схема „снежинка"

Схема "снежинка" –Вариант схемы "звезда", в котором каждая размерность может иметь свои собственные размерности.

В этом случае таблицы размерностей не содержат денормализованных данных.

Схема „звезда-снежинка"

Схема "звезда-снежинка" – Гибридная структура, которая включает комбинацию денормализованной схемы "звезда" и нормализованной схемы"снежинка".

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


 

А также другие работы, которые могут Вас заинтересовать

6489. Использование темы глобальных катастроф в современной рекламе 32.38 KB
  Использование темы глобальных катастроф в современной рекламе Во второй половине ХХ столетия, цивилизация, достигнув не малых высот в различных сферах общественной жизни-науке, технике, культуре- столкнулась лицом к лицу, с казалось, бы с неразреши...
6490. Тема тюрьмы и воли в творчестве Игоря Гамаюнова (по материалам Литературной газеты) 51.98 KB
  Тема тюрьмы и воли в творчестве Игоря Гамаюнова (по материалам Литературной газеты) В содержании многих неспециализированных газет особое место занимают материалы, повествующие читателям о криминальных происшествиях, судебных разбирательствах, а так...
6491. Подиумная дискуссия: опыт проведения на примере подиумной дискуссии на тему Глобализация: добро или зло 32.67 KB
  Подиумная дискуссия: опыт проведения В рамках предмета Экологическая проблематика в СМИ помимо лекционных занятий, проводятся разные интерактивные формы работы со студентами, в том числе подиумные дискуссии. Данный формат предлагает выступление не...
6492. Климат: мы уже прошли точку невозврата 33.14 KB
  Климат: мы уже прошли точку невозврата Климат будет меняться. В следующие 10 лет нам следует резко поменять свои привычки: контролировать потребление ресурсов, ископаемых, скорее переходить на альтернативные источники энергии, а значит, мен...
6493. Разработка устройства, исключающего образование ползунов на поверхности катания колёс ВСНТ 141.5 KB
  Разработка устройства, исключающего образование ползунов на поверхности катания колёс ВСНТ Вся история развития железнодорожного транспорта связана со стремлением обеспечить максимальные скорости движения, минимальное время нахождения пассажиров и г...
6494. Автоматический стояночный тормоз исключающий самодвижение подвижного состава на станционных путях, перегонах и в пунктах его отстоя 137 KB
  Автоматический стояночный тормоз исключающий самодвижение подвижного состава на станционных путях, перегонах и в пунктах его отстоя. Известно, что при движении железнодорожного подвижного состава под действием силы тяги локомотива последняя расходуе...
6495. Индексный метод в статистических задачах 93.5 KB
  Индексный метод в статистических задачах Цель работы: научиться выполнять расчеты индексов переменного, постоянного состава и структурных сдвигов, расчет индексов с использованием формул взаимосвязи индексов...
6496. Индивидуально–изменчивое поведение 90 KB
  А.Р. Лурия. Индивидуально–изменчивое поведение Прошлые занятия были посвящены наследственно закрепленным формам поведения, которые позволяют животному осуществлять наиболее адекватные формы поведения к медленно изменяющейся или неизменной среде...
6497. А.Р. Лурия. Инстинктивное поведение животных 112.5 KB
  А.Р. Лурия. Инстинктивное поведение животных В прошлый раз мы остановились на проблеме происхождения психики и на основных механизмах наиболее простых форм поведения. Мы видели, какое решающее значение имеет факт возникновения реакций на нейтральные...