Информационные хранилища

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

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

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

На втором уровне поддерживаются витрины данных на основе многомерной  системы управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Заметим, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.

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

 

Глава 3. Проектирование рекламного агентства

3.1. Описание  предметной области

Требуется разработать  информационную систему для автоматизации  учета заказов в рекламном  агентстве.

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

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

• № счета;
• Заказчик;
• Исполнитель;
• Вид услуги;
• Дата заказа;
• Дата выполнения;
• Количество;
• Сумма;

Каждый заказ имеет  своего заказчика, который имеет  следующие параметры:

• ФИО (название организации);
• Дата рождения;
• Адрес;
• Телефон.

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

• № счета;
• Дата открытия;
• Заказчик;
• Сумма.

В рекламном агентстве  числится картотека специалистов. На каждого специалиста в картотеку  заносятся следующие данные:

• Фамилия;
• Имя;
• Отчество;
• Должность;
• Дата рождения;
• Фотография.

В рекламном агентстве  ведется картотека предоставляемых  услуг. На каждую услугу в картотеку заносятся следующие сведения:;

• Вид услуги;
• №;
• Диапазон стоимости;
• Материал.

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

• Материал;
• Поставщики;
• Объем поставки.

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

• Агент по приему заказов;
• Заказчики;
• Специалисты;
• Администрация рекламного агентства.

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

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

Заказчик должен иметь возможность решать следующие задачи:

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

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

Администрация рекламного агентства должна иметь возможность получать сведения:

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

 

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

 

3.2. Проектирование базы данных методом нормальных форм

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

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

Отношение в 1 НФ должны отвечать таким требованиям:

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

Построим схему зависимостей между атрибутами (рисунок 1, приложение 1).

В данном отношении присутствует явное и неявное избыточное дублирование данных. Следствием избыточного дублирования данных является проблема редактирования. Часть избыточности устраняется  при переводе отношения в 2НФ.

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

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

В результате получим  четыре отношения R1, R2, R3, R4 (рисунок 2, приложение 1).

В отношении R1 ключ – № счета, в отношении R2 – атрибут Заказчик, в R3 – Исполнитель, а в R4 – Код товара.

Исследование  отношений показывает, что переход  к 2НФ позволил исключить явную избыточность в таблицах R1, R2, R3. В R4 по-прежнему имеет место неявное дублирование данных.

Для дальнейшего  совершенствования отношения необходимо преобразовать его в 3НФ.

Таблица находится  в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей.

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

В отношении R4 есть транзитивные зависимости:

Заказы → Вид услуги→ №, Диапазон стоимости, Материал;

Заказы → Вид услуги → Материал;

Заказы → Материал → Поставщики, Объем поставки.

Транзитивные  зависимости также продолжают избыточное дублирование информации. Устраним их. Для этого преобразуем отношение R4, получив при этом отношения R5, R6 и R7, каждое из которых находится в 3НФ (рисунок 3, приложение 2).

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

 

3.3. Проектирование  базы данных методом «сущность–связь»

Модель «сущность–связь» в 1976 году предложил Петер Чен.  Она является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме.

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

Основные преимущества ER-моделей:

• наглядность;
• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
• ER-модели реализованы во многих системах автоматизированного проектирования баз данных.

Приступаем к проектированию базы данных рекламного агентства методом «сущность–связь», содержащую следующие атрибуты:

№ счета – номер счета заказа (возможность совпадения номера счета исключена).

Заказчик – ФИО (название организации) заказчика (возможность совпадения ФИО (названия организации) заказчика исключена).

Исполнитель – фамилия  специалиста, выполняющего заказ.

Дата заказа – дата поступления заказа.

Дата выполнения –  дата выполнения заказа.

Количество – количество заказанной услуги.

Сумма – сумма, на которую  сделан заказ.

ФИО (название организации) – заказчик (возможность совпадения ФИО (название организации) исключена).

Дата рождения – дата рождения заказчика.

Адрес – адрес заказчика.

Телефон – номер телефона заказчика.

Дата открытия – дата открытия счета (дата, когда сделан заказ).

Фамилия – фамилия  сотрудника (возможность совпадения фамилии специалиста исключена).