Файл: 1. Введение в теорию баз данных Вопрос Основные понятия.docx
Добавлен: 07.12.2023
Просмотров: 826
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Схема снежинка. Преимущества и недостатки.
Схема типа снежинки (Snowflake Schema) - схема реляционной базы данных, служащая для поддержки многомерного представления содержащихся в ней данных, является разновидностью схемы типа «звезда» (Star Schema).
*Особенности ROLAP-схемы типа «снежинка»*
Одна таблица фактов (fact table), которая сильно денормализована. Является центральной в схеме, может состоять из миллионов строк и содержать суммируемые или фактические данные, с помощью которых можно ответить на различные вопросы.
Несколько таблиц измерений (dimensional table), которые нормализованы в отличие от схемы «звезда». Имеют меньшее количество строк, чем таблицы фактов, и содержат описательную информацию. Эти таблицы позволяют пользователю быстро переходить от таблицы фактов к дополнительной информации. Первичные ключи в них состоят из единственного атрибута (соответствуют единственному элементу измерения).
Таблица фактов и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу фактов в качестве внешних ключей. Первичный ключ таблицы факта целиком состоит из первичных ключей всех таблиц размерности.
В схеме «снежинка» агрегированные данные могут храниться отдельно от исходных.
Преимущества.
Нормализация таблиц измерений в отличие от схемы «звезда» позволяет минимизировать избыточность данных и более эффективно выполнять запросы, связанные со структурой значений измерений.
Недостатки.
За нормализацию таблиц измерений иногда приходится платить временем выполнения запросов.
Рис. 42
Вопрос 4. Склады данных.[19]
Склад данных - это логически интегрированный источник данных для систем поддержки принятия решений (DSS) и информационных систем руководителя (EIS). Мы говорим о логической интегрированности, потому что, хотя некоторые простые модели складов данных, которые мы обсудим далее, могут быть централизованными (независимо от того, распределенными или централизованными являются источники данных для них).
Склад данных и база данных – это не одно и то же. Склад данных может быть реализован на основе некоторой СУБД или РаСУБД. Поскольку предназначение склада данных - это информационная поддержка принятия решений, а не оперативная обработка данных и транзакции, то многие принципы технологий баз данных утрачивают для них свое значение.
Склад данных ориентирован на определенную предметную область и организован на основе некоторого подмножества данных, поступающих из операционных баз данных. Источником информации для них являются различные приложения, которые могут выполняться на разных платформах, следовательно, необходимы средства интеграции. Кроме того, на складе данных хранится не все множество строк данных (как в операционной базе), а в той или иной степени обобщенная информация.
Данные, поступившие на склад, приобретают статус постоянной информации, то есть вносимые изменения носят характер «пополнения» (путем регулярных плановых выборок из операционных баз), а не произвольных поэлементных модификаций, как в операционных базах данных.
Процесс пополнения обычно включает сложные процедуры согласования данных в отношении типов, размеров, кодировок и других свойств данных. Для этих целей пригодны алгоритмы, аналогичные тем, которые применяются в среде разнородных распределенных баз данных, построенных по методике «снизу вверх».
Над складом данных, наполненным исходной информацией, может выполняться множество разнообразных приложений поддержки принятия решений и информационных систем руководителя. В таких приложениях применимы процедуры последовательного уточнения, то есть продвижения на уровни более тонкой детализации. Возможности складов данных полезны в областях, связанных с долговременным управлением информацией, таких как электронные библиотеки и хранилища данных.
Одна из нерешенных критически важных проблем для многих руководителей корпораций и правительственных учреждений, ответственных за принятие решений, - невозможность получения оперативных, консолидированных своевременных и гибких отчетов на основе корпоративных данных. Руководителям необходима точная и актуальная информация, которая, в большинстве случаев, присутствует на предприятии, но ее извлечение из многих разрозненных операционных баз и хранилищ данных сопряжено с трудностями. Технология складов данных дает адекватную основу для создания систем поддержки принятия решений и информационных систем руководителя.
Информация из среды оперативного информационного управления (как правило, из одной или более баз данных) извлекается в соответствии с определенными принципами и помещается в склад данных. Важно понимать, оперативная обработка данных и транзакции не является целью создания складов данных и многие принципы технологий баз данных утрачивают для них свое значение. В частности, в складах данных не поддерживаются операции модификации данных в том смысле, как это понимается в базах данных.
Ниже перечислены четыре основополагающих для организации складов данных принципа.
Предметная ориентация. В операционной базе данных обычно поддерживается несколько предметных областей, каждая из которых может послужить источником данных для склада. Например, для магазина, торгующего видео- и музыкальной продукцией, интерес представляют следующие предметные области: клиенты; видеокассеты; CD-диски и аудиокассеты; сотрудники; поставщики.
Нетрудно провести аналогию между предметными областями склада данных и классами объектов в объектно-ориентированных базах данных. Очевидно, что методы проектирования и моделирования, применяемые в объектно-ориентированных СУБД, могут оказаться полезными и при проектировании предметных областей складов данных.
Средства интеграции. Существует ряд проблем при интеграции данных, возникающие при построении глобальных схем для баз данных. Например, одна и та же сущность в разных базах данных и приложениях может быть представлена совершенно по-разному, и все эти представления должны быть приведены к некоторому общему типу.
Постоянство данных. В складах данных не поддерживаются операции модификации в смысле традиционных баз данных. Для разных окружений баз данных характерные различны степени изменяемости данных. Так, в реляционных базах данных допускаются вставки строк, изменения значений столбцов, удаления строк, выполняемые регулярно в процессе обычной деятельности. В складах данных поддерживается модель «массовых загрузок» данных, производимых в заданные моменты времени согласно установленным правилам. Массовая загрузка может выполняться с централизованной базы данных, находящейся на той же системе, что и склад данных, а может осуществляться и путем одновременных извлечений данных из распределенных операционных баз данных (либо даже из разрозненных баз данных или информационных систем, не объединенных какой-либо глобальной схемой). Таким образом, модель индивидуальных модификаций объектов к складам данных неприменима.
Хронологизм данных. Благодаря средствам интеграции, склад данных - это нечто большее, чем просто изощренная последовательность «моментальных снимков»; она всегда имеет определенный хронологический, временной аспект, присущий ее содержимому. Хронологизм - принцип, гласящий, что время есть ключевой компонент базы данных и ее содержимого
, в той же мере можно отнести и к складам данных.
«Мгновенные снимки» операционных данных извлекаются из баз данных или других информационных источников и поступают в склад данных в интегрированном виде. Однако склад данных не поддерживает тот же высокий уровень гранулярности информации, который характерен для баз данных.
Рассмотрим разницу между операционными приложениями и приложениями поддержки принятия решений или информационной поддержки руководителя. Операционным приложениям, для того чтобы они могли выполнять свои функции, нужен максимально высокий уровень гранулярности. В базе данных должна быть представлена информация о каждом клиенте, сотруднике, поставщике, каждом компакт-диске, каждой видеокассете и т. п.
Пользователей систем DSS или EIS, напротив, вряд ли будет интересовать список всех клиентов или полный отчет о прокате или продажах каждого CD. Менеджеру-аналитику высокого ранга не понадобится даже месячный отчет с подобной информацией. Скорее всего будет необходим отчет о среднем месячном объеме проката и продаж в расчете на одного клиента с детализацией по коду города в пределах того или иного региона, охваченного деятельностью компании. Понадобится также сравнение такого рода информации с данными за прошлый месяц, либо за тот же месяц прошлого и/или позапрошлого года.
Ключ к эффективности приложений склада данных - это обобщение информации. Возможно, приложения DSS или EIS могли бы самостоятельно проводить обобщение подробной информации, выбираемой из операционных баз данных или из складов данных (где она поддерживается с той же высокой степенью гранулярности). Но это абсолютно непрактично, по крайней мере, по одной из двух причин: дополнительная нагрузка на операционную базу данных, создаваемая в результате выполнения многочисленных выборок и обобщений данных, приведет к снижению производительности на текущих операциях; неоправданное увеличение объема необходимой памяти в складе данных для хранения элементов данных, которые никогда не используются индивидуально.
В складе данных, разумеется, можно поддерживать несколько уровней гранулярности (т. е. более или менее обобщенную информацию), что очень желательно для проведения анализа «вглубь» (drill-down analysis). Анализ «вглубь» полезен в тех случаях, когда пользователь обнаруживает интересное для него явление и стремится докопаться до его причин, истоков и подробностей. Если в складе данных поддерживаются связи от каждого уровня обобщения к уровням, «питающим» его, то соответствующие приложения могут производить обход данных по этим ссылкам.
Вопрос 5. Архитектуры хранилищ данных.[20]
Централизованное хранилище данных с ETL.
Виртуальные хранилища данных и независимые витрины показали, что для эффективной работы аналитических систем необходим единый репозитарий данных. Для наполнения этого репозитория необходимо извлечь, согласовать разнородные данные из различных источников и загрузить эти данные в репозиторий.
Средства извлечения, преобразования и загрузки данных (ETL) должны знать все об источниках данных: структуры хранящихся данных и их форматы, различия в алгоритмах обработки данных, смысл хранящихся данных, график выполнения обработки информации в транзакционных системах. Игнорирование этих данных о данных (метаданных) неизбежно приводит к ухудшению качества информации, загружаемой в хранилище. В результате пользователи теряют доверие к хранилищу данных, стараются получать информацию напрямую из источников, что приводит к неоправданным временным затратам специалистов, эксплуатирующих системы – источники данных.
Таким образом, информация об источниках данных должна использоваться средствами ETL. Поэтому средства ETL должны работать в тесной связке со средствами ведения метаданных.
При обработке извлеченных данных необходимо преобразовать их к единому виду. Поскольку основные данные хранятся в реляционных базах данных, нужно учесть различие в кодировке данных. Даты могут кодироваться в разных формата; адреса могут использовать различные сокращения; кодировка продуктов может следовать различным номенклатурам. Первоначально информация о нормативно справочной информации (НСИ) заносилась в алгоритмы преобразования данных ETL. По мере роста числа источников данных объема обрабатываемых данных (он может достигать терабайтов в сутки), стало ясно, что необходимо отделить средства управления НСИ от средств ETL, и обеспечить их эффективное взаимодействие.
Таким образом, средства ETL извлекают данные из источников, во взаимодействии со средствами ведения метаданных и НСИ преобразуют их к требуемым форматам и загружают в репозиторий данных. В качестве репозитория чаще всего выступает репозиторий хранилища данных, но также может быть и оперативный склад данных (ОСД), и зоны временного хранения, и даже витрины данных. Поэтому одним из ключевых требований к средствам ETL является их способность взаимодействовать с различными системами.