Теория и практика построения баз данных (1088289), страница 143
Текст из файла (страница 143)
Чтобы проиллюстрировать зто, рассмотрим определение куба в листингах 17.1 и 17.2. Используемый здесь синтаксис основан на документации !лз(егозю(1 01.Е Е)В для 0!.АР, но сходные конструкции используются и другими производителя- ми. Оператор Сгеаге СцЬе определяет четыре измерения и дла уронил логической структуры. Измерения Время и Место имеют уровни, а измерения КатегорияЖилья п ТипЖилья — нет. Хотя это здесь не показано, измерение можег иметь более одного набора уровней.
В этом случае для измерения определяется две или более иерархии. Листинг 17.1. Использование расширенного ЗОЕ: описание данных ОЕАР СКЕЯТЕ СОВЕ КубПродаждилья ( О!МЕМ510М Время ТУРЕ Т!МЕ. ЕЕЧЕЕ Гад ТУРЕ УЕАК, СЕЧЕЕ Квартал ТУРЕ ОЦАКТЕК, ЕЕЧЕЕ Месяц ТУРЕ МОМТН, 8!МЕМ5!ОМ Место, ЕЕЧЕЕ СШЯ ТУРЕ ЯЕС, СЕЧЕЕ Жуат ЕЕЧЕЕ Город, 01МЕИ51ОМ Категорилжилья.
СЦМЕИ5!ОМ Тмпжилья, МЕА5ЦКЕ ЦенаПродаж, ГЦМСТ!ОМ СРЕДНЕЕ МЕАВЦКЕ ЗалращиваемаяЦена. РЦМСТ!ОИ СРЕДНЕЕ ) Листинг 17.2. Пример многомерного оператора ВЕЕЕСТ 5Е( ЕСТ Сй055801М ((Существующие дома. Новые дона). (Калифорния.СЬУ!дгеп, Невада)) ОМ СОЕЦММ5. (1998,К1.С)М)г(геп, 1998.К2, 1998 КЗ, 1998 К4, 1999.К1.С(п !г(геп, 1999.К2. 1999.КЗ. 1999.К4) ОИ КОИ5 ГйОМ Кубпродажжилья ИНЕКЕ (ЦенаПродажи. Тилдилья = 'Односемейный' ) Структура в листингах 17.1 и 17.2 — ато определение способа интерпретации, или осмысления данных о жилье. Она не является представлением данных.
Для определения представления, илп матсрпализапии, для потребностей 01.АР был расширен синтаксис 50Е. В листинге 17.1 показаны операторы 01.АР 5(2Е, создающие материализацию куба, показанного в табл. 17.1. Единственное, что ляжет смущать в этом операторе, — термин СК055ЗО!М. Результатом выполнения оператора СК055З01М ИА, В), (1, 2)) является следующее отображение; Выполнение оператора СК05х)01М ((1, 2), (А, В)) приводит к отображению Если несколько развить эту идею, можно составить оператор СК055ЗО!М ((Существующее жилье, Строящееся жилье), (Калифорния.СЬйг(гоп, Невада)), результатом которого будет Новые дома Невада Калифорния Существующие дома Калифорния Невада Сан- ЛосФранциско Анджелес Сан- Диего Сан- Лос- СанФранциско Анджелес Диего Структуры схемы О1.АР Все данные из примера в табл.
17.1 н 17.2 взяты из одной таблицы. Такая ситуация нетипична: обычно данные по крайней мере нескольких измерений хранятся не в той таблице, что содержит меры. На рис. 17.11 показан пример табличной структуры ОЕАР для базы данных галереи Ч!еи К189е. Данные измерений, например 5а!езРпсе, хранятся в таблице ТКАМ5, а данные о прочих измерениях хранятся в родительских таблицах, соединенных с таблицей ТКАМ5 через внешние ключи. Куб, основанный на данных, представленных ва рпс.
17.11, и, может иметь измерения СЦ5ТОМЕК, АКТ ОЕАЕЕК, 5АЕЕ5РЕК50М и У(ОКК. Данные членов этих измерений будут считываться из соответствующих таблиц. Структура, изображенная на рис. 17.11, а, столь распространена, что ей было дано спецпюгьное название— схема «звезда» (згаг зсйеп1а), которое отражает принцип расположения таблиц с данными измерений вокруг таблицы с данными мер.
Единственное добавление к последнему оверагору — выражение Калифорния. Сййдгеп, которое означает, что нужно провести разбиение по всем потомкам члена Калифорния для всех уровней куба. 50Е-оператор в тистинге 17.2 содержит выражения ОМ СОСЦММ5 и ОМ КОЧЧ5. Тем самым объявляются оси, по которым будут откладываться измерения.
Обратите также внимание, что для задания слоев представления используется предложение ЧЧНЕКЕ. В соответствии с рисунком, показываться должны только продажная цена и тпп жилья для односемейного дома. Заметьте, что расслоение может осуществляться как по измерению, так и по мере.
666 Глава 17. Совместное использование данных предприятия Оперативная аналитическая обработка данных !ОЕАР) 66? б Рис. 17.11. Типы схем ОГАР: а — пример схемы «звезда; б — пример схемы «снежинка» Обратите внилиание, что на этом рисунке отсутствует атрибут имени художника (АРТ15Т.йате). Чтобы добавить этот атрибут, 01 АР-проектировщик может соединить столбец АРТ15Т.)1аше с таблицей ЙОРК через ключ А1тн11О.
Но в этом случае таблица ЙОРК не будет находиться в доменно-ключевой нормальной форме, в результате чего возникнет дублирование данных. Альтернатива хранению таких соединений изображена на рис. 17.11, б. Здесь таблица АРТ15Т не соединяется с таблицей ЙОРК, а хранится в нормализованной форме. Добавлена также другая таблица, ОЕ))РЕ (жанр). Такая структура также возникает регулярно, и ей было дано название схема «снежинка» (зпощйа1те зс11еша).
Разница между структурамп, имеющими форму звезды и снежинки, заключается в том, что в структуре типа «звезда» каждая таблица с данными измерения непосредственно связана с таблицей, где хранятся значения мер. Этц таблицы еногут (но не обязаны) быть нормализованными. Структура типа «снежипка» может иметь несколько уровней таблиц, и каждая таблица в ней нормализована. Выбор между этими двумя структурами зависит от объема н природы данных, а также от нагрузки ОЕАР. В общем случае схема «звезда» требует большего количества памяти, но она быстрее в обработке.
Схема «сцежинка» обрабатывается медленнее, зато требует меныпе памяти. Способы хранения данных О!.АР !ВОЕАР, МО1.АР и НОЕАР! ВОЕАР, МО! АР и НОЕАР представляют собой различные способы хранения данных 01.АР. В сущности, вопрос заключается в следующем: что позволит достичь максимальной производительности — внедрение средств ОЕАР в реляционные СУБД, использование специализированных автономных средств цли и то и другое одновременно? Сторонники н01.АР (реляционной 01 АР) заявляют, что СУБД с расширенными возможностями, включающими предварительную обработку определенных запросов и некоторые другие функции, могут служить вполне адекватными средствами хранения данных ОЕАР.
Сторонники МОЕАР (многолеерной ОЕАР) считают, что хотя СУБД хорошо подходят для обработки транзакций, выполнения запросов и создания отчетов, требования ОЕАР к обработке данных настолько специфичны, что ни одна СУБД не может достичь в этой сфере приемлемой производительности. Сторонники третьего пути, НО!АР (гибридной 01.АР), считают, что и СУБД, и специализированные ОЕАР-процессоры могут успешно использоваться для этих целей, и каждая пз составляющих имеет свою роль. Мщгозой использует эти термины более узко в контексте средств оперативной аналитической обработки СУБД Щ! 5егтег. Для Мвтгозой термин В.ОЕАР означает, что хранение исходных данных и заранее вычисленных агрегацпй данных происходит в базе данных 50Е 5егтег. При М01.АР данные, структура куба и заранее вычисленные агрегации данных хранятся в специализированной многомерной структуре данных. При Н01.АР данные остаются в реляционной базе данных, но агрегации данных хранятся в многомерной структуре.
МОЕАР дает максимальную производительность, но и требует больше всего памяти. РОЕАР требует меныпе памяти, но работает медленней. КОЕАР предназначена для больших баз данных, информация из которых запрашивается редко. Информационные хранилища 669 Хранилище МОьАР Хранилище йОьАР Браузе Клиентский компьютер Рис. 17.12. Архитектура Оьдр Мютозоц 668 Глава 1?.
Совместное использование данных предприятия В способе НОЕАР высокоуровневая обработка дает большую производительность, но при исследовании мелких деталей быстродействие снижается. На рпс. 17.12 показана архитекгура 01.АР, заявленная М!сгозо11 для применения в 5ОЕ 5егт ег 7.0 и ОНке 2000. Это гибридная архитектура, которая включает 01 АР-обработку на центральных серверах ланных, ууеЪ-сервере и клиентских компьютерах.
Организационные базы ланных обрабатываются центральными серверами данных, показанными на диаграмме справа. Доступ к резулыагам этой обработки предоставляется через главную службу таблиц (Ргеос ТаЫе 5егч!се) на гуеЬ-сервере пли локальном компьютере. Кроме того, на меЬ-сервере или на локальном компьютере могут храниться локальные версии данных ОЕАР. У этой архитектуры есть несколько ключевых элементов. Во-первых, это главная служба таблиц, которая представляет собой ОЕАР-процессор, доступ- ный в виде службы НТ и тт'1пг)втуз 2000.
Эта служба работает н в других версиях !ттг)пг1оууз, где используется О!!!се 2000. Фактически, главная сл„.жба таблиц вызывается всякий раз, когда в Ассезз создаются страницы лоступа к данным. Вще чаще она используется Вхсе!. Доступ к главной службе таблиц осуществляется через расширение 01 В ПВ, которое называется ОЕВ ОВ для ОЕАР. Это расширение построено на базе технологии ОЕЕ ОВ, рассматривавшейся в главе 15; в суп!ности, оно расширяет понятие набора строк, вкл1очая в него не только наборы записей, но и наборы данных, являющиеся абстракциями кубов. Расширение АЕ)0 для обработки 01 Е ОВ для 0!.АР называется АОО МР (многомерная АЕ)0).
В АЕ)0 МО обьекгы Соппесбоп и Сотп1папг) могут открывать наборы данных и обрабатывать их динамически подобно тому, как вто делалось уыя наборов записей в главе 15. Данные могут как считываться, так и записываться. Эта архитектура в максимально возможной степени приближает О! АР к клиенту, поскольку вычислительные требования ОЕАР могут быть огромны. Это не представляет трудностей при обработке локальных данных, но для создания кубов, требующих загрузки данных с центрального сервера прелпрнятия, может попа- добиться передача значительных объемов данных. Возможно, это окажется неосуществимым. Определенно, такие системы нужно будет настраивать по мере накопления опыта. Как указано на рис. 17.12, 01.АР-обработке могут подвергаться централизованные, загруженные или локальные данные. По мере того как организации передают все большее количество своих данных в распоряжение пользователей, возрастают проблемы с управлением данными.
Возможным решением этих проблем являются информационные хранилища, обсуждаемые в слелуюшем разделе. Информационные хранилища Загрузка данных действительно приближает их к пользователю, тем самым повышая их эффективность. Управление одним или двумя компьютерами, осуществляю- шими загрузку, не представляет трудностей. Однако если каждый отдел пожелав~ иметь свой источник загруженных данных, возникновение управленческих проблем неизбежно. В связи с этим у организаций возникла потребность в стандартизированной службе, обеспечивающей перемещение данных к пользователю н увеличение их полезности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
