3.7 Современные подходы разработки и внедрения информационных систем.
Вопросы для самостоятельного изучения:
Теория нормализации отношений.
Построение логической модели данных.
Понятие хранилищ данных и основы их создания.
Архитектура хранилищ данных.
Модели хранилищ данных.
Опорные знания:
Лекционный материал:
Тема 3. Современные подходы разработки и внедрения информационных систем.
Понятие машинного информационного обеспечения. Предпосылки создания и основные преимущества БД. Понятие и классификация автоматизированного банка данных (АБД). Состав АБД.
Материал предыдущего самостоятельного занятия:
1. Характеристика инфологичной и даталогичной модели баз данных.
2.Методы создания оптимальной модели баз данных.
Знания и умения, которыми необходимо овладеть
После изучения темы студент должен:
знать архитектуру хранилищ данных, модели хранилищ данных;
уметь ориентироваться в теории нормализации отношений;
отвечать на контрольные вопросы
Указания:
информация по всем вопросам данной темы представлена ниже.
Теория нормализации отношений
Нормализация отношений — это итерационный обратный процесс декомпозиции начального отношения на несколько более простых отношений меньшей размерности. Под обратным процессом понимают то, что операция объединения отношений, полученных в результате декомпозиции, должна дать начальное отношение. В результате нормализации состав атрибутов отношений БД должен отвечать таким требованиям:
• между атрибутами должны исключаться нежелательные функциональные зависимости;
• группирование атрибутов не должно иметь убыточного дублирования данных;
• обеспечивать обработку и возобновление атрибутов без осложнений.
Аппарат нормализации был разработан американским ученым Е.Ф. Коддом. Каждая нормальная форма ограничивает тип допустимых зависимостей между атрибутами. Кодд выделил три нормальных формы (сокращенное название 1НФ, 2НФ и ЗНФ). Самая совершенная из них — это ЗНФ. Сейчас уже известны и определены 4НФ, 5НФ.
Нормализация отношений выполняется несколькими шагами (рис. 3.15).
Рис. 3.15. Схема этапов нормализации отношений
1-й шаг (1-ая итерация) — преобразование отношений к первой нормальной форме (1НФ).
Отношение в 1НФ должны отвечать таким требованиям:
• все атрибуты отношения должны быть атомарными, то есть неделимыми;
• все строки таблицы должны быть одинаковой структуры, то есть иметь одно и то же количество атрибутов с именами, которые соответственно совпадают;
• имена столбцов должны быть разными, а значения однородными (иметь одинаковый формат);
• порядок строк в таблице несущественный.
Каждое отношение БД содержит как структурную, так и семантическую информацию. Структурная информация задается схемой отношения, а семантическая выражает функциональные связи между атрибутами.
На 2-ом шаге (2-ая| итерация) нормализации выявляются ключи атрибуты и анализируются соответствующие зависимости с целью исключения неполных функциональных зависимостей.
Определение 1. Атрибут Б функционально зависит от А в отношении R тогда, когда в каждый момент времени одному и тому же значению А отвечает не более как одно значение Б. Функциональной зависимости отвечает отношение 1:1 между атрибутами.
Определение 2. Атрибут находится в полной функциональной зависимости, если он зависит от всего ключа и не зависит от его составляющих.
Если отношение имеет неполные функциональные зависимости, то выполняют его декомпозицию на два или больше других отношений, которые не имеют неполных функциональных зависимостей и объединение которых даст начальное отношение.
3-й шаг (3-я| итерация) нормализации — это исключение транзитивных зависимостей. Отношение в 2НФ должно анализироваться на присутствие транзитивных зависимостей.
Транзитивная зависимость — это зависимость между неключевыми атрибутами.
Транзитивные зависимости исключаются также с помощью декомпозиции отношения на другие два или больше отношений, которые не содержат транзитивных отношений и объединения которых даст начальное отношение. В результате декомпозиции получим два новых отношения R1 (А*, В) но R2 (В*, С).
На 4-ом шаге (4-я итерация) нормализации выполняется анализ на присутствие независимых многозначительных зависимостей в отношении. Если они есть, то выполняется декомпозиция отношения.
Многозначительная зависимость — это разновидность функциональной зависимости. Атрибут В находится в многозначительной зависимости от атрибута А, тогда коду одного значения атрибута А отвечает много значений атрибута В. Существуют понятия тривиальной и нетривиальной многозначительной зависимости.
Определение 3. Отношение R содержится в 4НФ, когда в структуре многозначительной зависимости, которая определена на множестве атрибутов, есть лишь тривиальные или такие нетривиальные многозначительные зависимости, что левая часть любой из них является ключом.
Декомпозиция начального отношения на несколько других должна гарантировать его оборотность, то есть обеспечивать получение начального отношения объединением отношений, найденных в результате декомпозиции.
Однако не всегда декомпозиция гарантирует оборотность. Отношение, которое содержит более чем три многозначительных зависимости, нуждается в специальных мероприятиях по обеспечению оборотности декомпозиции. Для этого существует 5НФ. При декомпозиции с 4НФ получают такие проекции, чтобы каждая из них содержала не менее как один возможный ключ и по меньшей мере один неключевой атрибут начального отношения.
5НФ устраняет избыточность и в то же время аномалии пополнения БД. В конце отметим, что нормализация отношений устраняет между атрибутами такие зависимости: неполные функциональные, транзитивные, нетривиальные (независимые) многозначительные. Устраняя эти зависимости, исключаем дублирование данных и возможность возникновения аномалий при выполнении операций пополнения, замены и исключения данных с БД. Кроме того, нормализованная база данных требует гораздо меньше памяти для ее хранения, чем ненормализованная база данных.
Построение логической модели данных.
Следующим шагом, который выполняется после нормализации отношений есть построение логической модели БД.
Логическая модель является основой базы данных, она должна отображать взаимосвязь между реляционными таблицами. Между реляционными таблицами могут быть следующие типы связей 1:1, 1:∞ и ∞:∞. Наиболее распространенной связью является связь 1:. Связь 1:1 встречается реже, потому что данные, между которыми существует такой тип связи, в подавляющем большинстве случаев входят в состав одной реляционной таблицы. Связь : непосредственно не поддерживается в реляционных СУБД. Для реализации такой связи необходимо создавать дополнительную реляционную таблицу, которая будет играть роль связной. Связочная таблица должна обязательно содержать первичные ключи таблиц, между которыми устанавливается связь.
Некоторые современные СУБД имеют инструментальные средства построения логической модели данных. Рассмотрим построение такой модели средствами СУБД Microsoft Access. Логическая модель в среде СУБД Microsoft Access называется схемой. Для построения схемы данных предварительно необходимо создать таблицы, определив в них первичные ключи. Пример схемы, построенной средствами Access приведено на рис. 3.16
На этой схеме отображенные связи между таблицами реляционной БД. Между всеми таблицами установленная связь типа 1: (знак помечает в Access много).
Связь устанавливается между полем первичного ключа объектного отношения и полем вторичного ключа связанного отношения. Связь между полем первичного и полем вторичного ключа устанавливается, если поля заданы одним типом и поданы в одном формате.
Схема в Access обеспечивает целостность и согласованность данных, которые хранятся в разных таблицах. Например, Access не позволит дозаписать в таблицу «Реализация» данные о реализации изделия какому-то потребителю, если данные об этом изделии и соответствующем потребителе отсутствуют в таблицах «Изделие» и «Справочник потребителей». Кроме того, если пользователь системы сделает попытку изъять данные о каких-то изделиях или об определенных потребителях из таблиц справочной информации «Изделие» и «Справочник потребителей» тогда, когда данные об этих изделиях и о потребителях занесены в таблицы «Реализация» и «Договор», то Access сообщит пользователю о том, что исключение соответствующих строк, которые предлагаются к исключениюв главной таблице невозможно, так как этой записи есть соответствующие записи в подчиненных таблицах.
.
Рис. 3.16. Схема базы данных
Понятие хранилищ данных и основы их создания
Разновидностью баз данных является хранилище данных (Data WarenHouse). Понятие хранилищ данных возникло совсем недавно. Необходимость разработки новой концепции хранилищ данных обусловлена такими факторами:
• Развитие информационных технологий привело к системам нового типа, которые получили название систем поддержки принятия решений. Эти системы основаны на новой технологии, которая получила название OLAP-технологии. Основой OLAP-технологии является реализация аналитических запросов.
• Системы поддержки принятия решений, основанные на формировании аналитических запросов, начали конфликтовать с транзакционными системами оперативной обработки данных (OLTP-системами). Одновременное решение оперативных и аналитических запросов на одной базе данных часто приводит к недостатку ресурсов.
• Формирование аналитических отчетов на основе традиционных баз данных, которые вмещают оперативную информацию, занимает очень много времени. Причем расходы времени, необходимые для формирования аналитических отчетов, непрестанно растут с ростом объемов оперативной информации в базе данных. Это приводит к тому, что менеджеры не успевают готовить соответствующие решения на основании полученных аналитических отчетов.
• Очень часто на предприятии или в организации функционирует несколько OLTP-систем, каждая из которых имеет свою отдельную базу данных, в которых используются разные структуры данных, способы кодировки, единицы измерения. Построение сведенного аналитического запроса на основе нескольких баз данных является очень сложной проблемой, которая сначала нуждается в решении проблемы согласованности данных, которые хранятся в разных базах данных.
Решение перечисленных выше проблем было найдено в разработке концепции хранилища данных. Хранилище данных должно выполнять функции предыдущего отбора, агрегации и подготовки оперативных данных OLTP-системам. То есть, в хранилище данных хранятся не первичные данные, а определенным образом интегрированные данные, которые создают основу для решения аналитических задач и функционирования систем поддержки принятия решений. Взаимосвязь между системами отражает рис. 3.17.
Рис. 3.17. Схема взаимосвязи OLTP и OLAP систем
Таким образом хранилище данных (Data WarenHouse )- это особенная форма организации базы данных, которая предназначена для хранения в согласованном виде агрегированной информации, которая получается на основе баз данных разных OLTP-систем и внешних источников.
Хранилища данных характеризуются предметной ориентацией, интегрированностью, поддержкой хронологии, неизменностью и минимальной избыточностью. Эти основные особенности хранилищ данных были определены в 1992 году их изобретателем Биллом Инмоном (Bill Inmon). Они, независимо от реализации, присущи всем хранилищам данных и заключаются вот в чем.
Предметная ориентация. Данные в хранилище данных организованы в соответствии с основными направлениями деятельности предприятия или фирмы (заказчики, продажа, состав и т.п.). В этом заключается отличие хранилищ данных от организации оперативной БД, в которой данные подаются в соответствии с процессами (отгрузка товара, выписка счетов и т.п.) Предметная организация данных не только упрощает анализ, но и значительно ускоряет проведение аналитических расчетов. То есть, хранилища ориентированы на бизнес-понятии, а не на бизнес процессы.
Интегрированность. Первичные данные оперативных баз данных проверяются, определенным образом подбираются, приводятся к одному виду, агрегируются (то есть обсчитываются суммарные показатели) и загружаются в хранилище данных. Такие интегрированные данные намного проще анализировать.
Поддержка хронологии. Данные, которые выбираются из оперативных баз данных накапливаются в хранилище данных в виде «исторических пластов», каждый из которых характеризует определенный период времени. Это позволяет проводить анализ изменения показателей во времени.
Неизменность. Данные хранилища данных, которые характеризуют каждый «исторический пласт», ни в коем случае не подлежат изменениям. Это тоже является существенным отличием данных, которые хранятся в хранилища данных, от оперативных данных. Оперативные данные могут очень часто изменяться, с данными хранилища возможны лишь операции их первичной загрузки, поиска и их чтения.
Минимальная избыточность. Невзирая на то, что информация в хранилища данных загружается с БД OLTP-систем, это не приводит к избыточности данных. Приведение к минимуму данных обеспечивается тем, что прежде чем загружать данные в хранилища, их фильтруют и определенным образом очищают от таких данных, которые ненужны и не могут быть используемы в OLAP-системах.
Архитектура хранилищ данных
Хранилища данных могут включать такие компоненты: виртуальное хранилище данных, корпоративное хранилище данных, киоски или витрины данных.
Виртуальное хранилище данных — это репозитарий метаданных, которые описывают источники поступления информации, структуру данных хранилища, методы агрегации и загрузки данных, сведения о структуре понятий бизнеса и других данных о данных, которые хранятся в хранилище.
Корпоративные хранилища данных (enterprise data warehouses) вмещают информацию, собранную из определенной множества оперативных БД, которая характеризует всю корпорацию и необходима для выполнения консолидированного анализа деятельности корпорации в целом. Такие хранилища охватывают все многочисленные направления деятельности корпорации и используются для принятия как тактических так и стратегических решений. Разработка корпоративного хранилища данных очень трудоемкий процесс, который может занять от одного до нескольких лет, а объемы хранилища могут достигать от 50 Гбайт до нескольких терабайт.
Киоски или витрины данных (data marts) это подмножество корпоративных данных, которые характеризуют конкретный аспект деятельности корпорации, например работу какого-то ее подраздела. Киоск может получать данные из корпоративного хранилища данных (зависимый киоск) или быть независимым, и тогда источником пополнения его данными будет оперативная БД. Разработка киоска данных требует гораздо меньше времени и в среднем длится около трех-четырех месяцев.
Корпоративные хранилища данных и киоски строятся по подобным принципам и используют практически одинаковые технологии.
В последнее время появилось понятие глобального хранилища данных, в котором хранилище данных рассматривается как единый источник интегрированных данных
Модели хранилищ данных
Хранилища должны предоставлять возможность параметризации данных по разным признакам, например банковские операции во время их анализа необходимо группировать по времени их выполнения, по клиентам, по их объемам в стоимостном выражении, по контрагентам, видам валют и другим признакам. То есть, данные должны быть представлены в хранилище таким образом, чтобы осуществлять возможность их многомерного анализа. Основы многомерного анализа были предложены Е.Ф. Коддом (Е. F. Codd) в 1993г.
Наиболее удачной формой представления данных, которая дает возможность многомерной их параметризации, это представление данных в виде не плоской реляционной модели, а многомерной модели. В основу OLAP-систем положено понятие гиперкуба, то есть многомерного куба, в ячейках которого хранятся необходимые для анализа данные.
Однако в настоящее время существует три варианта построения систем на основе хранилищ данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP). В MOLAP-системе гиперкуб реализуется как специальная модель нереляционной структуры, которая быстрее обеспечивает доступ к данным, чем реляционные модели, но требует дополнительных расходов памяти.
В ROLAP-системах гиперкуб - это лишь интерфейс пользователя, который моделируется на традиционной реляционной базе данных. Данные в хранилище представляются в виде модели, которая получила название «звезда» (star schema). Эта модель состоит из таблиц двух типов: одной таблицы данных, которые анализируются, то есть фактов (fact table) — центр звезды, и нескольких таблиц, которые характеризуют определенные измерения этих фактов (demension table). Таблица фактов вмещает числовые характеристики какого-то направления деятельности компании или фирмы, например, объемы продаж, а также ключи таблиц измерений. Таблицы измерений содержат дополнительные характеристики ключевых полей, как правило, это справочные данные, например данные о названии товара, названии его производителя, типе товара и другие. Заметим, что данные таблиц измерений денормализованы. Если же таблицы измерений нормализованы, то такая модель называется «снежинкой» (snowflake schema). В ROLAP- системах хранятся агрегированные данные.
Такой подход позволяет хранить большие объемы данных, но они не достаточно эффективны при выполнении аналитических операций, поэтому системы, построенные на реляционных моделях, рассматриваются быстрее как интеллектуальные генераторы отчетов. Но до сих пор эти системы преобладают, так как в реляционные модели вложены большие инвестиции и они более понятны и привычны.
HOLAP-системы — это комбинированный вариант хранения данных, который использует оба типа СУБД. Во многомерной СУБД хранятся агрегаты данных, а подробные данные, которые имеют небольшой объем, хранятся в реляционной СУБД.