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

Составным первичным ключом отношения Товары являются поля Артикул и Дата поставки. Атрибуты Название товара и Цена, руб. функционально зависят только от атрибута Артикул, входящего в состав составного ключа. Для устранения этой неполной функциональной зависимости можно разделить исходное отношение на два отношения (получить его проекции) (табл. 7.9 и 7.10):

Таблица 7.9

Номенклатура товаров

Таблица 7.10

Поставки

Разделение отношения Товары на отношения Номенклатура товаров и Поставки позволяет существенно уменьшить избыточность данных. Значительно проще и надежнее теперь выполняются операции обновления данных. Например, при изменении названия поставщика соответствующие исправления необходимо внести только в отдельные кортежи отношения Номенклатура товаров. Число исправляемых кортежей будет намного меньше, чем в отношении Товары, так как оно равно количеству разных товаров, а не общей численности партий товаров, поступающих от данного поставщика. Информацию о заключении нового договора о поставках товаров можно вносить в отношение Номенклатура товаров, не дожидаясь момента, когда поступит первая партия товара. Удаление второго кортежа из отношения Поставки не помешает сохранить в базе данных информацию о том, что торговым предприятием заключен договор с организацией Факел о поставке сапог с артикулом 200, ценой 5 000 рублей с доставкой этих товаров железнодорожным транспортом (второй кортеж отношения Номенклатура товаров).

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

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

Третья нормальная форма (3НФ)

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

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

Для устранения транзитивной зависимости в отношении Номенклатура товаров, данное отношение необходимо разделить на два отношения (табл. 7.11 и 7.12):

Таблица 7.11

Договоры

Таблица 7.12

Доставка

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

Отношения Договоры и Доставка находятся в третьей нормальной форме.

В большинстве случаев достижение третьей нормальной формы считается достаточным для реальных проектов баз данных [ 12 ], однако в теории нормализации существуют нормальные формы высших порядков (НФБК, 4НФ, 5НФ), некоторые из которых связаны уже не с функциональными зависимостями между атрибутами отношений, а отражают более тонкие вопросы смыслового содержания предметной области [ 4 ]. Подробную информацию о нормальных формах высших порядков можно найти в книгах [ 1, 2, 4 – 6, 11, 14 ].

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

7.5. Автоматизированные технологии проектирования баз данных

Средства автоматизации проектирования и разработки информационных систем, в том числе и банков данных, появились относительно недавно (первая версия CASE-системы фирмы Oracle была представлена в 1989 г.) [ 3 ].

Термин «CASE» (Computer Aided Software Engineering) дословно переводится как разработка программного обеспечения с помощью компьютера. В CASE-системы входят программные средства, позволяющие выполнять анализ предметной области и построение ее модели, проектирование баз данных, разработку приложений, генерацию кодов, тестирование и т.д.

CASE-системы, применяемые для проектирования баз данных, могут не зависеть от СУБД или встраиваться в них. Независимые системы не входят в состав конкретной СУБД и обычно поддерживают несколько форматов баз данных через интерфейс ODBC. В качестве примеров таких систем можно привести S-Designor (PowerDesignor) (фирмы SDP, Powersoft), Erwin (LogicWorks), Silverrun (Computer Systems Advisers Inc.) [ 15 ]. Встроенные CASE-системы в основном поддерживают формат баз данных СУБД, составной частью которой они являются. Пример встроенной системы – Designer/2000 (СУБД Oracle одноименной фирмы) [ 15 ].

Рассмотрим некоторые CASE-системы.

S-Designor (PowerDesigner). Эта система позволяет с помощью графических средств в некоторой степени автоматизировать процесс проектирования реляционных баз данных. Система работает с СУБД Oracle, MS Access, Ingress, Informix, Sybase, MS SQL Server и т. д.

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

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

База данных с помощью системы может быть создана двумя способами. В рамках первого из них необходимо подключиться к работающему серверу СУБД через интерфейс ODBC. Другой способ – формирование текстовых файлов (пакетов) SQL-операторов по созданию структуры БД. База данных создается после обработки этих файлов СУБД [ 15 ].

В версии PowerDesigner 6.0 реализовано проектирование многомерных информационных моделей для хранилищ данных (см. Заключение) [ 3 ].

Erwin. Данная система в целом близка по функциональным возможностям системе S-Designor (PowerDesigner), но она менее универсальна и поддерживается меньшим числом СУБД. В системе имеются ограничения на размеры модели (не более 500 сущностей и 1500 атрибутов) [ 3 ].

Silverrun. Система работает с СУБД Oracle, Informix, Ingress, MS SQL Server и т. д. С помощью системы можно строить два вида моделей: функциональные (в виде диаграмм потоков данных) и информационные (диаграммы типа «сущность – связь», применяемые для создания схем баз данных).

Система включает встроенную экспертную систему, приводящую неполную и некорректную исходную информацию к виду, необходимому для построения реляционной базы данных [ 15 ].

Designer/2000. Эта система является встроенной в СУБД Oracle.

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

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

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

Опыт применения CASE-систем для проектирования баз данных позволяет сделать следующие выводы [ 3 ]:

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

2. Наиболее полезными CASE-системы являются на начальных стадиях проектирования.

3. Современные CASE-системы ориентированы на квалифицированного пользователя, так как для их использования необходимы знания теории баз данных и принципов их проектирования.

4. В некоторых ситуациях целесообразно использовать несколько CASE-систем совместно. Это позволяет объединить достоинства этих систем и сократить сроки проектирования.

В то же время нельзя не согласиться с точкой зрения на рассматриваемую проблему С. М. Диго: «… ни одна система автоматизации проектирования, насколько бы развитой она не была, не может гарантировать соответствия построенной концептуальной модели реалиям предметной области. Это определяется только квалификацией разработчиков, их пониманием предметной области и умением адекватно отобразить ее в модели» [ 3 ].

Заключение

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

1. Одним из таких направлений является создание «Хранилищ данных» (Data Warehouse), осуществляющих функции предварительной подготовки и хранения данных для систем поддержки принятия решений (СППР).

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

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

Для поиска и выборки данных в процессе работы системы используется стратегия, называемая «оперативной аналитической обработкой» (On-line Analytical Processing, OLAP).

OLAP-системы строятся на основе двух базовых принципов:

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

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

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

Дальнейшее усложнение модели данных может выполняться следующими способами:

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

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

3. Вводится иерархия в пределах одного измерения. Например, год состоит из кварталов, квартал из месяцев, месяц из недель, неделя из дней.

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

При работе с гиперкубами могут использоваться две стратегии.

В системах MOLAP (Multidimensional OLAP) гиперкуб реализуется как отдельная база данных специальной не реляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительных ресурсов памяти. Поэтому данные из хранилища вначале помещаются в специальную многомерную базу, а затем обрабатываются OLAP-сервером. Примерами таких систем являются Essbase (компания Arbor Software) и Oracle Express (Oracle).

Для систем ROLAP (Relational OLAP) гиперкуб – это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. В этой структуре можно хранить очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP-операций. Примеры таких систем – MetaCube (фирма Informix) и Discoverer 3.0 (Oracle).

Для подготовки решения в рамках OLAP-технологии пользователь анализирует срез данных по одному или нескольким измерениям.

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

Под витриной данных понимается специализированное хранилище данных, обслуживающее только одно из направлений деятельности предприятия, например, учет товаров. Для разработки такого хранилища требуется, чтобы происходящие в этой сфере бизнес процессы были относительно просты и достаточно хорошо изучены. Примеры витрин данных: PowerMart Suite (фирма Informatica), Data Mart Solution (Sagent Technology), DataMart Suite (Oracle).

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

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

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

Достоинствами этого подхода являются [ 7 ]:

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

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

3. Применение для обмена данными в сети протоколов (например, HTTP), не зависящих от платформ, используемых пользователями.

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

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

Динамическая публикация применяется при обращении к часто изменяемой информации и используется, например, при организации работы интернет-магазинов, систем бронирования мест в гостиницах и т. д. Web-страницы формируются только после поступления на сервер запроса пользователя. Для этого применяются различные средства и технологии: ASP, PHP и IDC/HTX- страницы, программы расширения сервера (Java-сервлеты, CORBA-объекты, ISAPI-модули и т. д.) [ 7 ].

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

Библиографический список

1. Гарсиа-Молина Г. Системы баз данных. Полный курс: пер. с англ. / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. – М.: Вильямс, 2003.– 1088 с.

2. Дейт К. Дж. Введение в системы баз данных: пер. с англ. / К. Дж. Дейт. – 6-е изд. – М.: Вильямс, 2000. – 848 с.

3. Диго С. М. Базы данных: проектирование и использование: учебник / С. М. Диго. – М.: Финансы и статистика, 2005. – 592 с.

4. Карпова Т. С. Базы данных: модели, разработка, реализация: учебное пособие / Т. С. Карпова. – СПб.: Питер, 2001. – 304 с.

5. Кренке Д. Теория и практика построения баз данных. – 9-е изд. – СПб.: Питер, 2005. – 859 с.

6. Марков А. С. Базы данных. Введение в теорию и методологию: учебник / А. С. Марков, К. Ю. Лисовский. – М.: Финансы и статистика, 2004. – 512 с.

7. Мещеряков Е. В. Публикация баз данных в Интернете / Е. В. Мещеряков, А. Д. Хомоненко. – СПб.: БХВ-Петербург, 2001. – 560 с.

8. Общеотраслевые руководящие материалы по созданию банков данных. – М.: ГКНТ, 1982. – 158 с.

9. Олле Т. Предложения КОДАСИЛ по управлению базами данных: пер. с англ. / Т. Олле. – М.: Финансы и статистика, 1981. – 286 с.

10. Риккарди Г. Системы баз данных. Теория и практика использования в Internet и среде Java: пер. с англ. / Г. Риккарди. – М.: Вильямс, 2001. – 480 с.

11. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление: пер. с англ. / К. Коронел, П. Роб. – 5-е изд., перераб. и доп. – СПб.: БХВ-Петербург, 2004. – 1040 с.

12. Ролланд Ф. Д. Основные концепции баз данных: пер. с англ. / Ф. Д. Ролланд. – М.: Вильямс, 2002. – 256 с.

13. Толковый словарь по вычислительным системам / под ред. В. Иллингоурта и др.: пер с англ. – М.: Машиностроение, 1990. – 560 с.

14. Харрингтон Д. Разработка баз данных: пер. с англ. / Д. Харрингтон. – М.: ДМК Пресс, 2005. – 272 с.

15. Хомоненко А. Д. Базы данных: учебник / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев. – СПб.: КОРОНА принт, 2002. – 672 с.

* В данном параграфе рассматриваются фундаментальные проблемы теории реляционных баз данных. Поэтому вместо терминов «таблица», «запись» и «поле» используются соответственно понятия «отношение», «кортеж» и «атрибут».