Приклади виникнення «брудних даних»

Фіктивні значення

Можуть бути уведені фіктивні значення, такі, як ідентифікаційний код 9999999999, або вік клієнта 999, або поштовий індекс 99999. Наявність строгих перевірок змушує оператора видумувати значення в тих місцях, де реальні значення невідомі. Такі значення відносно просто виявити, але особа, що вводить дані, може використовувати свій ідентифікаційний код, вік або поштовий індекс.

Іноді зустрічаються фіктивні значення, які дійсно мають якийсь зміст (наприклад, ідентифікаційний код 8888888888 для вказівки на статус клієнта-іноземця, або місячний дохід у розмірі 99999.99 для вказівки на те, що клієнт має роботу. Якби довелося підраховувати середньомісячний дохід клієнтів, результати були б некоректні.

Відсутність даних

Це відбувається тому, що різні бізнес-підрозділи мають різні потреби в існуванні конкретних значень даних для виконання своєї роботи. Відділ, що видає іпотечні кредити, може мати необхідність у формуванні звітів для виявлення статі й етнічної приналежності клієнта, тоді як відділ, що видає комерційні кредити, її не має.

Багатоцільові поля

Два кредитних відділи з наведеного вище приклада, можливо, мають загальні системи для видачі й обслуговування своїх кредитів і 80% потреб у даних є загальними для обох типів кредитів. Проблема є у використанні тих 20% полів, що не є загальними. Тут можуть бути поля даних, що використовуються для множини цілей, де те саме значення в деякому полі в підсумку означає багато різних речей залежно від (1) того, який відділ його ввів, і (2) наявності конкретних значень в одному, або в декількох полях даних. Розмір і вміст таких записів може бути чим завгодно, починаючи з рядка дат або рядка сум. Причому значення можуть згодом перевизначатися. Окремі користувачі можуть використовувати це поле зовсім з іншою метою для виконання своїх функціональних обов'язків, не інформуючи про це кого-небудь, і видалення «поганих значень» просто прикриє всю роботу. Хтось взагалі не знав про перевизначення поля й міг видавати важливу фінансову інформацію на підставі цих «поганих значень».

Незрозумілі (кодовані) дані

Наприклад, скажемо, кредитна система спочатку відслідковувала, чи виконуються з іпотечного кредиту податкові відрахування. Код «О» міг використовуватися для позначення «Ні, податкові відрахування з рахунку відсутні». Потім компанія почала стягувати страхові внески. Оскільки код «О» уже використовувався для терміна «Податкові відрахування відсутні», використовувався код «С» для вказівки «Страхові відрахування відсутні». Необхідно пам'ятати, що обоє вони являють собою заперечення і є такими, що перемикаються. Ще через кілька років потрібно було відслідковувати деякі іпотечні кредити, застраховані державним органом і не потребуючі звичайного страхування. Код «С» уже використовувався для позначення відсутності страхових відрахувань, однак він має інше значення з погляду нових вимог, тому був доданий новий код "Г". І оскільки необхідно відслідковувати в цьому полі «виключення з обробки платежів», додане «І» як загальне позначення всіх і будь-яких виключень. Нехай є кредити, для яких необхідно знати, що ні податків, ні страхових відрахувань із них не виробляється. Можна написати логіку для опитування поля Сальдо Відрахувань; і якщо там знаходиться значення, більше 0, варто перевірити, чи існує заключний запис про відрахування.

Суперечливі дані

Наприклад, адреса нерухомості показує поштовий індекс Київської області й Одесу як місто й область. Перевірка вулиці показує, що такої вулиці в Одесі немає.

Невідповідне використання адресних полів

Адреса складається з декількох складових. Адресне поле 1 було спочатку призначено для особистого П.І.Б. або найменування компанії, можливо, що випереджається зірочкою для вказівки на те, що це адреса юридичної особи, адресне поле 2 - для номера будинку й назви вулиці, і так далі. При уведенні може бути плутанина й змішання значень.

Порушення бізнес-логіки

Наприклад, іпотека з регульованою процентною ставкою, у якій величина мінімальної процентної ставки вище, ніж максимальної, або коли множинні процентні ставки виявляються в кредиту з фіксованою процентною ставкою, що має той самий її рівень протягом усього часу існування кредиту.

Повторне використання первинних ключів

Оскільки OLTP-системи рідко зберігають дані за весь період, значення первинних ключів часто використовуються повторно. Наприклад, відділення банку № 84, що видало й обслуговує більше 1000 іпотечних кредитів, закривається й передає обслуговування цих кредитів відділенню № 207. Протягом одного року номер 84 привласнюється новому відділенню. Вхідні 1000 кредитів продовжують указувати на відділення № 84 як на таке, що видало їх, і всі ці кредити помилково приписуються новому відділенню № 84. 

Неунікальні ідентифікатори

Наприклад, те саме фізичне відділення має два або більше ідентифікатори. Наприклад, те саме відділення може бути позначене як відділення № 65 у кредитній і як відділення № 389 у депозитній системах.

Проблеми інтеграції даних

Ці проблеми існують у двох видах: дані, які повинні, але не можуть бути зв'язані, і дані, які ненавмисно зв'язані, хоча й не повинні б. Останнє трапляється найбільше часто, коли поля або записи використовуються для множини цілей. Наприклад, якщо й для покупок і для продажів використовується та сама програма для обліку продажів, і якщо первинний ключ продавців може приймати ті ж значення, як і первинний ключ покупців, і якщо продажі від покупок відрізняються тільки по різних прапорцях або перемикачам або деякому спектру значень у певних полях, для того, щоб уникнути асоціювання продавця або покупця не з тим типом транзакції, буде потрібною розширена програмна логіка.

Серйозною проблемою є неможливість з'єднати дані, які повинні бути з'єднані. Іноді це пов'язане з попередньою проблемою неунікальних ключів, але частіше через відсутність ключів взагалі. Наприклад, усі банки привласнюють унікальні номери рахунків, але тільки деякі привласнюють унікальний номер клієнта. Десятиліттями клієнти асоціювалися зі своїми рахунками згідно з полем з іменем клієнта в записі по рахунку. У результаті з'являються різні написання або абревіатури того самого імені клієнта, іноді клієнт фігурує під псевдонімом або дошлюбним ім'ям, а час від часу двоє або троє клієнтів мають об'єднаний рахунок і всі їхні імена стиснуті в одне поле імені. У результаті проаналізувати рахунки одного клієнта стає просто неможливо.

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

Виникає також питання, чи очищати оперативні дані в рамках OLTP-систем або перетворення, що очищають, виконувати протягом процесу витягу й завантаження в СД. Часто користувачі OLTP-системи для оперативних цілей не мають потреби в більш чистих даних, чим вони мають на даний момент, і будуть заперечувати проти їхньої зміни. Крім того, часто це досить трудомістке завдання, до того ж неефективне з погляду ціни або просто нереалізоване; тоді очищення виконується в процесі витягу й завантаження.

Користувачі й ІТ-фахівці повинні зрозуміти, як кожний випадок «брудних даних» може перешкодити одержанню відповіді на питання бізнесу, і які зусилля знадобляться для очищення таких даних.

Якщо вигоди перевищують вартість таких зусиль, дані певно повинні бути очищені. Далі повинне бути ухвалене рішення, вносити чи ні необхідні зміни в OLTP-системи для:

- очищення існуючих даних;

- для запобігання уведення «брудних даних» у майбутньому.

Потрібно поліпшити OLTP-системи, якщо зусилля для цього не занадто великі (наприклад, у випадку багаторічних архівних даних або коли це просто неможливо зробити через те, що вхідні джерела даних більше не існують). Найчастіше більша частина очищення в підсумку виконується під час процесів витягу й завантаження.

Якщо ціна переважує виграш, необхідно прийняти інше важливе рішення: чи варто поміщати «брудні дані» у сховище як є або їх варто виключити. Знову, користувачі й ІТ-фахівці повинні зважити кожну можливу вигоду від включення таких даних з можливим збитком, що вони можуть принести, наприклад, з перекручуванням результатів аналізу важливих тенденцій, роблячи їх у такий спосіб марними, або, ще гірше, забезпечуючи помилкову інформацію, що веде до невірних рішень для бізнесу.

Питання для самоперевірки

1. Які методи очищення даних Ви знаєте?

2. Перелічите етапи підготовки окремого джерела до інтеграції з іншими джерелами.

3. Чи потрібно виконувати очищення даних у самих джерелах даних?

Методичні вказівки до лекції:[2, с. 31–37]; [6,с. 91–102, 189-251].

Вправи

1. Приведіть приклади виникнення брудних даних у предметній області «Поліклініка».

2. Приведіть приклади процедур очищення даних в предметній області «Деканат».

Змістовний модуль 5
Мова багатомірних виражень MDХ

ЛЕКЦІЯ №12
 МОВА БАГАТОМІРНИХ ВИРАЖЕНЬ MDX. ОСНОВНІ ПОНЯТТЯ

Розглядаються наступні питання:

· історія виникнення мови MDX;

· задачі мови;

· основні концепції мови MDX;

· доступ до члена виміру;

· поняття кортежу;

· поняття множини (набору);

· основні операції з множинами.

Мова MDX (Multi-Dimensional eXpressions – мова багатомірних виражень) була вперше представлена як складова OLE DB for OLAP в 1997 р. компанією Microsoft. Незабаром з’явилася комерційна реалізація мови в Microsoft OLAP Services 7.0 (1998 р.), потім – в Microsoft Analysis Services. Незважаючи на те, що MDX не є загальним стандартом, а тільки внутрішньою специфікацією Microsoft, вона була прийнята багатьма провідними розповсюджувачами технології OLAP. У їхньому числі розроблювачі серверних застосувань, такі, як Applix, Microstrategy, SAS, SAP, Whitelight, NCR, а також розроблювачі клієнтських застосувань: Panorama Software, Proclarity, AppSource, Cognos, Business Objects, Brio Technology, Crystal Reports, Microsoft Excel, Microsoft Reporting Services і інші. З появою XML for Analysis, у якому MDX була прийнята як стандартна мова запитів, все більше число компаній (у їхньому числі, наприклад, Hyperion Solutions), стали підтримувати MDX. Деякі компанії розширюють стандарт, щоб забезпечити додаткову функціональність, але передбачається, що всі компоненти таких розширень MDX розроблені відповідно до стандарту.

Задачі мови можна визначити в такий спосіб:

- MDX «розуміє» багатомірну модель устрою даних (куб, вимір, міра, комірка);

- мова дозволяє здійснювати навігацію по багатомірному просторі й визначеним над ним ієрархіям;

- MDX потрібна не тільки розроблювачам і адміністраторам — вона може бути корисною практично всім користувачам аналітичних застосувань.

MDX має два режими. При використанні як вираження MDX дозволяє визначати багатомірні об'єкти й дані для обчислення значень, а також управляти ними. Як мова запитів вона використовується для добування даних з багатомірних баз даних.

Хоча мова запитів MDX використовує синтаксис, подібний до синтаксису мови SQL, ці мови значно відрізняються.

Основні концепції

Кожний вимір має одну або кілька ієрархій, а кожна ієрархія містить один або кілька рівнів. Кожна ієрархія виміру містить один або кілька елементів, називаних членами (members). Кожний член відповідає одному або декільком входженням цього значення в базову таблицю вимірів.

Простір куба – це сукупність елементів ієрархій вимірів куба з мірами куба. Тому простір куба визначається комбінаторним сполученням всіх елементів ієрархії виміру в кубі й мер куба й визначає максимальний розмір куба. Важливо мати на увазі, що цей простір включає всі можливі сполучення елементів ієрархії виміру, навіть сполучення, які можуть здатися неможливими в реальному світі, наприклад сполучення, де містом є Париж, а країнами — Англія, Іспанія, Японія або Індія, і т.д.

Поняття автоматичної перевірки існування обмежує простір куба комірками, які дійсно існують. Елементи ієрархії виміру можуть не існувати з елементами іншої ієрархії у тому  же вимірі.

Наприклад, простір куба, що містить ієрархію Місто, ієрархію Країна й міру ОбсягПродажу, включає тільки ті елементи, які існують один з одним. Наприклад, якщо ієрархія Місто містить елементи Київ, Одеса, Москва, Тула й Краків, а ієрархія Країна містить країни Україна, РФ, Польща, то простір куба не містить комірку на перетинанні елементів Москва й Україна.

Запит до неіснуючих комірок повертає значення NULL.

Об'єкт Measures (міри), по суті, являє собою спеціальний вимір, що є набором мір.

Доступ до члена виміру

Можна одержати доступ до члена виміру за допомогою імені цього виміру, імені ієрархії й імені рівня. Наприклад:

[Місце]. [Ієрархія_Місце].[Україна].[Одеса].[Проспект Гагаріна].[будинок №10].[квартира №123],

[Місце]. [Ієрархія_Місце].[Україна].[Одеса]

У наведених прикладах використаний докладний запис:

[<Вимір>].[<Ієрархія>].[<Член верхнього рівня>]. … ... . [<Член нижнього рівня>]

У деяких випадках унікальні в межах виміру елементи такого запису можна опускати.

Наприклад, якщо перший квартал кожного року називається Q1, то такий член виміру не можна опускати, необхідно буде уточнити вираження MDX, використовуючи ім'я рівня. Якщо все-таки використовувати даний формат звертання до члена ієрархії, MDX завжди буде витягати член Q1 для першого із представлених в ієрархії років.

Можна організувати кілька ієрархій для одного виміру, наприклад:

[Дата].[Ієрархія1].[<Рік>].[<Місяць>].[<Число>] і

[Дата].[Ієрархія2].[<№ тижня>].[<День тижня>]

У випадку єдиної ієрархії на неї можна послатися по імені виміру, тобто:

[Дата].[Ієрархія1].Members еквівалентно [Дата].Members ,

[Місце].[Ієрархія_Місце].[Міста].Members еквівалентно [Місце].[Міста].Members .

Кожному рівню ієрархії (Level) привласнене своє ім'я. Імена рівнів застосовуються в конструкціях виду:

[<Вимір>].[<Ієрархія>].[<Рівень>].Members .

Наприклад: [Дата].[ Ієрархія1].[Місяця].Members - всі можливі місяця;

 [Місце].[Ієрархія_Місце].[Вулиці].Members - всі вулиці, незалежно від країни й міста.

Імена вимірів, ієрархій, рівнів і членів обов'язково потрібно брати у квадратні дужки, якщо в ім'ї зустрічається пробіл, цифра або ім'я являє собою ключове слово MDX.

Таким чином, у МDХ існують три способи посилання на об'єкти вимірів, ієрархій, рівнів і елементів:

- по імені;

- по повному імені;

- по унікальному імені.

Для визначення члена, посилання на який виконується по імені, сервер повинен пройти по всіх вимірах і всіх їхніх ієрархіях у пошуку елемента із заданим ім'ям. Це вимагає великої кількості ресурсів, особливо коли елементи виміри зберігаються в реляційній базі даних (ROLAP-виміри). Крім того, посилання на об'єкт по імені можуть привести до неоднозначних результатів, наприклад, коли елементи з однаковими іменами існують у різних вимірах, наприклад, елемент Україна існує у вимірі Клієнт і у вимірі Магазин.

Посилання на об'єкти по повному імені швидше, ніж посилання на об'єкти по їхніх іменах. Вона працює добре для вимірів, ієрархій і рівнів, але має недоліки при використанні для посилання на елемент. Якщо повне ім'я створене з'єднанням імен батьків елемента, елемент перестає бути мобільним. Повне ім'я стане неправильним, якщо елемент перейде від одного батька до іншого. Якщо розглядати покупця в ієрархії Покупці, який може переїхати жити в інше місто, і ім'я елемента, що його представляє, поміняється.

Третій спосіб посилання на об'єкти складається у використанні їхніх унікальних імен. Сервер привласнює унікальне ім'я кожному виміру, ієрархії, рівню й елементу. Клієнтськезастосування, що генерує МDХ, або програміст, що пише запит, може одержувати унікальне ім'я об'єкта, використовуючи опис схеми або з результатів іншого запиту.

Існують досить складні правила для генерації унікальних імен. Постачальники, що підтримують МDХ, можуть мати різні алгоритми для генерації унікальних імен. Тому при написанні запитів унікальні імена повинні запитуватися із сервера, наприклад, за допомогою функції UniqueName

Якщо у вибірці обрано осей менше, ніж кількість вимірів у кубі, не задані значення атрибутів призначаються.

У кожного виміру існує член за замовчуванням. Як правило, у ролі Default Member виступає єдиний член спеціального рівня ієрархії [All], автоматично створюваного при створенні виміру. Цей рівень містить сукупні результати по всім вимірі.

Вказівка на член за замовчуванням можна записати за допомогою вираження DefaultMember:

[Клієнти].DefaultMember .

Якщо рівень [All] відсутній, у його ролі виступає перший член наступного рівня.

У деяких системах членом за замовчуванням можна призначити будь-який член або MDX-вираження виміру.

Оскільки сукупність мер ([Measures]) теж є одним з вимірів, те й серед мір є елемент за замовчуванням.

Кортеж (tuple) – це набір членів одного або декількох різних вимірів. Кортеж однозначно визначає зріз даних у кубі. Кортеж представлений членами вимірів куба даних (по одному члену з кожного виміру), розділеними комами. Кортеж указує на конкретнукомірку або набір комірок усередині куба. Кортежі задаються за допомогою круглих дужок.

Приклади:

([Місце].[Україна].[Київ].[вулиця Хрещатик], [Піл].[Ж], [Тип місця].[Місце проживання] ) - усі жінки, що живуть на вулиці Хрещатик у Києві;

([Місце].[Україна].[Харків], [Тип місця].[Місце народження] ) – всі клієнти, що народилися в Харкові.

Кортеж необов'язково повинен явно містити члени всіх вимірів куба даних.

Елемент кортежу повинен належати різним ієрархіям.

([2010], [Франція]) - правильно

 ([США], [Франція]) - неправильно, елементи кортежу з однієї ієрархії

Порядок, у якому представлені члени вимірів у кортежі, не має значення.

Кортеж, представлений єдиним членом, називають простим кортежем. Простий кортеж можна не брати в круглі дужки. Наприклад, кортеж ([Клієнт].[Стана].[Україна]) є простим кортежем і може бути представлений у вигляді [Клієнт].[Країна].[Україна] або просто Клієнт.Країна.Україна.

Множина (або набір) (set) – це сукупність (об'єднання) кортежів, певних з використанням однакової кількості тих самих вимірів.

Приклади:

{[Дата].[1980].[Січень], [Дата].[1980].[Лютий] } – всі клієнти, що народилися в січні або в лютому 1980 р.

{([Місце].[Україна].[Одеса], [Тип місця].[Місце проживання], [Дата народження].[1980]), ([Місце].[Україна].[Херсон], [Тип місця].[Місце проживання], [Дата народження].[1980])} – всі клієнти 1980 року народження, що проживають в Одесі або в Херсоні.

Множинаукладається у фігурні дужки.

Кортежі (Клієнт.Країна.Україна, [Товар].[Категорія].[Продукти]) і (Клієнт.Країна.РФ, [Дата].[2010].1 квартал]) не можна об'єднати для формування множини. Хоча обоє вони засновані на двох вимірах, але збігається тільки перше із включених у їхній состав вимірів (Клієнт).

Множина може містити нуль, один або кілька кортежів. Множина із нульовою кількістю кортежів називається порожньою множиною. Порожній множині відповідає запис { }.

Множина може містити кортежі, що дублюються.

{ Клієнт.Країна.Україна, Клієнт.Країна.РФ, Клієнт.Країна.Україна }

Перетинання кортежу або множини з якою-небудь мірою дає значення міри на даній множині. 

Набір всіх членів в інтервалі задається за допомогою двокрапки:

{[Час].[2007]:[Час].[2010]}

Основні операції з множинами

Множина або набір в MDX – це множина у математичному розумінні, і всі закони, установлені алгеброю множин, можуть бути застосовані до цих множин.

Існують три операції алгебри множин і дві основні операції з множинами, які дозволяють створювати нові множини із уже існуючих множин:

Об'єднання (Union);

Перетинання (Intersect);

Різниця (Except);

Перехресне з'єднання (Crossjoin);

Добування (Extract)

Union поєднує дві й більше множини однієї розмірності в одна множину. Результуюча множина містить всі кортежі з кожної множини. Якщо кортеж існує в обох первісних множинах, у новумножину Union він буде доданий тільки один раз – повторюваний кортеж доданий не буде. Операція Union ({[Іванов],[Петров]},{[Сидоров]}) повертає множину

{Іванов, Петров, Сидоров}

Union являє собою еквівалент операції додавання, тому для створення об'єднання множин також можна використовувати оператор +.

{[Іванов],[Петров]}+{[Сидоров]}

Крім того, MDX підтримує синтаксис операції Об'єднання (Union) з використанням фігурних дужок, але ця операція не є точним еквівалентом функції Union або оператора +. Якщо дві множини, поєднувані з використанням фігурних дужок, містять повторювані кортежі, у результуючій множині дублікати зберігаються.

{{[Іванов],[Петров],[Сидоров]},{[Сидоров]}} повертає наступну множину

{Іванов, Петров, Сидоров, Сидоров}

Перетинання (Intersect) створює нову множину, що містить кортежі, загальні для двох множин.

Наприклад, код

INTERSECT({[Шевченко], [Іванов], [Петров]}, {[Іванов], [Петров],[Сидоров]})

поверне наступнумножину {Іванов, Петров}

Різниця (Ехсерt) знаходить розходження між двома множинами. Ця операція створює нову множину, що містить елементи, що є елементами однієї множини, але не елементами іншого.

Наприклад, код

Except({[Іванов],[Петров],[Сидоров]},{[Сидоров]}} поверне наступну множину {Іванов, Петров}.

Тому що операція Ехсерt еквівалентна операторові вирахування, її можна записати за допомогою знака «-»:

{[Іванов],[Петров],[Сидоров]}-{[Сидоров]}

Перехресне з'єднання (Crossjoin) генерує множину, що містить всі можливі комбінації двох (або більше) множин зі збереженням у результуючій множині порядку ієрархій, використаних в оригінальних множинах.

Ця функція часто використовується для проектування елементів з різних ієрархій на ту саму вісь куба. Операція Crossjoin еквівалентна операторові множення.

Наприклад, код:

CROSSJOIN({[2009], [2010]},{[Україна] , [РФ], [Польща]})

поверне наступнумножину:

{([2009],[Україна]),([ 2009],[РФ]),([2009],[Польща]), ([2010], [Україна]), ([2010], [РФ]), ([2010], [Польща])}

І цей код:

{[2009],[2010]}*{[Україна],[РФ],[Польща]}

поверне та ж сама множину.

Добування (Extract) створює множину, що містить кортежі тільки заданої ієрархії. Ця операція протилежна Crossjoin. Наприклад, код:

Extract(CROSSJOIN({[2009],[2010]},{[Україна],[РФ], [Польща]}), [Дата].[Рік])

поверне наступнумножину:

{[2009],[2010]}

Питання для самоперевірки

1. Як можна одержати доступ до члена виміру?

2. Для чого призначений вимір Measures?

3. Як визначається член за замовчуванням?

4. Що таке кортеж?

5. Які обмеження накладаються на кортежі, які можна поєднувати в множину?

6. Перелічите операції над множинами.

Методичні вказівки до лекції:[8, с. 84–93].

Вправи

1. Створіть куб К на основі бази даних Борею з вимірами Клієнт, Співробітник, Товар, Час виконання замовлення й мірами Кількість і Ціна замовлення.

2. Приведіть приклади кортежів для кожного виміру.

3. Приведіть приклади множин для пар вимірів.

4. Створіть БД для предметної області «Біржа праці». На її основі розробіть СД. При необхідності виконайте денормалізацію.

5. Створіть для СД із п.4 багатомірний куб зі схемою "сніжинка". Куб повинен містити таблицю фактів з 2-3 мірами й не менш трьох вимірів. Хоча б один з вимірів повинен представлятися двома зв'язаними таблицями. Один вимір повинне бути виміром часу.

ЛЕКЦІЯ №13
 МОВА БАГАТОМІРНИХ ВИРАЖЕНЬ MDX. ЗАПИТ ДО КУБУ

Розглядаються наступні питання:

·  синтаксис оператора SELECT;

· завдання осей результуючого куба;

· речення WHERE;

· іменовані множини;

· контекст запиту й контекст сеансу;

· члени, що обчислюються.

Для запиту MDX використовується наступний синтаксис.

[WITH <formula_expression> [, <formula_expression> ...]]

SELECT [<axis_expression>, [<axis_expression>...]]

FROM [<cube_expression>]

[WHERE [slicer_expression]]

Найпростіший запит виглядає в такий спосіб.

SELECT

FROM [Mycube]

Цей запит MDX повертає єдине значення, отримане в результаті агрегації значень всіх комірок куба, що ставляться до заданої за замовчуванням міри, для заданих за замовчуванням значень кожного виміру куба.

Вираження axis_expression визначає вимір, дані з якого потрібно витягти й має наступний синтаксис.

<axis_expression> := <набір> ON Axis (номер осі)

В інструкції SELECT можна вказати до 128 осей.

Для спрощення уведення можна опускати слово axis, дужки й писати тільки номер, що відповідають осі: on 0 або on 1.

Перші п'ять осей мають псевдоніми. Це осі COLUMNS (стовпці), ROWS (рядки), PAGES (сторінки), SECTIONS (розділи) і CHAPTERS (глави). Наступні осі вказуються за допомогою слова Axis, за яким слідує номер осі.

Приклад:

SELECT Measures.[Обсяг продажів] ON COLUMNS,

[Клієнти].[Країна].MEMBERS on ROWS,

[Товар].[Категорія].MEMBERS on PAGES

FROM [Mycube]

В MDX не можна пропускати «нижчі» осі (тобто осі з меншими порядковими номерами). Якщо необхідно вказати в запиті вісь PAGES, то необхідно вказати осі COLUMNS і ROWS.

В SQL речення SELECT використовується для визначення розміщення стовпців у результуючій таблиці. У МDХ речення SELECT використовується для завдання осей у результуючому багатомірному просторі.

Можна спроектувати на різні осі множини, що посилаються на той самий вимір, якщо вони повинні посилатися на різні ієрархії цього виміру.

Приклад:

SELECT

{([Побутова хімія], [Квартал1]), ([Побутова хімія], [Квартал 2]),

([Напої], [Квартал 1]),( [Напої], [Квартал 2])} ON COLUMNS,

{[Measures].[Сума продажів],[Measures].[Витрати] } ON ROWS

FROM [Mycube]

Вимірами куба є: Клієнт, Товар, Час, Магазин і Міри (Measures). Координати по трьох із цих вимірів визначені оператором SELECT. Виміри Клієнт і Магазин залишені невизначеними в запиті.

Коли кількість вимірів, спроектованих на осі, менше кількості вимірів у кубі, система створює додаткову вісь, називану Вісь Зрізу (Slicer Axis), що містить всі інші виміри. Вісь зрізу складається з одного члена кожного із цих атрибутів – елемента за замовчуванням.

Речення FROM у запиті MDX визначає куб, з якого витягають дані для аналізу. Воно нагадує речення FROM мови SQL, у якому вказується ім'я таблиці.

Вираження cube_expression позначає ім'я куба або підрозділу куба, з якого потрібно витягти дані. Мова SQL допускає використання в реченні FROM декількох таблиць, однак у запиті MDX можна вказати ім'я тільки одного куба даних. Куб, зазначений у речення FROM, називають контекстом куба (cube context), і запит MDX виконується усередині цього контексту. Тобто, кожна частина вираження axis_expression буде витягатисяі з контексту куба, зазначеного в реченні FROM.

Приклад запиту, що витягає розмірність [Обсяг продажів] по осі X.

SELECT {[Measures].[Сума продажів]} ON COLUMNS

FROM [Mycube]

Зазначена в SELECT міра витягається з контексту куба [Mycube].

Можна одержувати дані з інших кубів, використовуючи спеціальну функцію LookupCube. Якщо є два (або більше) куби із загальними членами вимірів, то ця функція дає можливість за допомогою цих членів витягти розмірності, що не входять у поточний контекст куба.

У запитах MDX використовуються аналогічні SQL інструкції, що задають умову відбору, яка забезпечує повернення запитами тільки необхідних даних.

SELECT {Measures.[Сума продажів]} ON COLUMnS,

[Товар].MEMBERS on ROWS

FROM MyCube

WHERE [Час].[2010]

Вимір зрізу (slicer dimension) створюється при визначенні речення WHERE; по суті, це фільтр, що виключає небажані виміри й члени.

Речення WHERE не обов'язково повинне бути в запиті; і навіть якщо в запиті воно є, необов'язково вказувати в ньому координати із всіх можливих ієрархій.

Речення WHERE в SQL і МDХ відрізняються концептуально. Речення WHERE в SQL використовується для обмеження записів, що читаються з таблиць. Речення WHERE у МDХ використовується для визначення зрізу куба. Основне його призначення – уточнення координат вимірів, які не були визначені в реченні SELECT.

Контекст виконання запиту

Коли сервер одержує запит, він у першу чергу проходить по елементах множин, спроектованим на осі.

Ці елементи будуть повернуті клієнтському застосуванню, і клієнтськезастосування звичайно відображає їх у вигляді заголовків таблиці або, можливо, у вигляді міток уздовж осей діаграми.

Потім сервер обчислює значення комірок на перетинанні від кожної осі. Координати, у контексті яких обчислюється значення, називаються поточними координатами.

У простому випадку існує тільки один кортеж у реченні WHERE, і сервер створює поточні координати кожного виміру в кубі. Якщо в реченні WHERE задана множина кортежів, то це вже більш складна структура даних – підкуб.

Поточні координати створюються зі членів вимірів, які використовувалися в реченні WHERE, і зі членів вимірів, що відповідають поточної ітерації по кожній осі. Для вимірів, на які немає посилань ні на осях, ні в реченні WHERE, сервер використовує члени за замовчуванням. Розглянемо, що відбувається усередині сервера, коли обчислюється однакомірка у простому запиті.

SELECT { (Клієнт.Країна.Україна) } ON COLUMNS,

{(Товар.Категорія.Напої, Час.Рік.[2010])} ON ROWS

FROM MyCube

WHERE [Measures].[Продана кількість]

//Крок 1. Поточна координата заповнюється елементами за замовчуванням всіх ієрархій вимірів. Усередині системи це виглядає в такий спосіб:

(Measures. DefaultMember,

Клієнт.All, Клієнт.Місто.All, Клієнт.Країна.All, Клієнт.Освіта.All, Клієнт.Стать. All,...,

Товар.All, Товар.Виробник.All, Товар.Категорія.All, ...,

Час.All, Час.Дата.All, Час.День.All, Час.Місяць.All, Час.Квартал.All, Час.Рік.All, ...,

Магазин.All, Магазин.[Місто магазина].All, Магазин.[Країна магазина].All, Магазин. Менеджер.All,...

)

//Крок 2. Поточна координата перезаписується елементами, використовуваними в реченні WHERE.

([Measures].[Продана кількість],

Клієнт.All, Клієнт.Місто.All, Клієнт.Країна.All, Клієнт.Освіта.All, Клієнт.Стать. All,...,

Товар.All, Товар.Виробник.All, Товар.Категорія.All, ...,

Час.All, Час.Дата.All, Час.День.All, Час.Місяць.All, Час.Квартал.All, Час.Рік.All, ...,

Магазин.All, Магазин.[Місто магазина].All, Магазин.[Країна магазина].All, Магазин. Менеджер.All,...

)

//Крок 3.Поточна координата перезаписується елементами, заданими на осях Columns і Rows.

([Measures].[Продана кількість],

Клієнт.All, Клієнт.Місто.All, Клієнт.Країна.Україна, Клієнт.Освіта.All, Клієнт.Стать. All,...,

Товар.All, Товар.Виробник.All, Товар.All, Товар.Категорія.Напої, ...,

Час.All, Час.Дата.All, Час.День.All, Час.Місяць.All, Час.Квартал.All, Час.Рік.2010, ...,

Магазин.All, Магазин.[Місто магазина].All, Магазин.[Країна магазина].All, Магазин. Менеджер.All,...

)

//Значення першоїкомірки обчислюється з координати, отриманої на кроці 3.

У багатьох випадках у вираженнях МDХ необхідно посилатися на поточну координату. Для цього МDХ надає функцію доступу до поточного елемента: <ієрархія>.CurrentMember. Ця функція повертає проекцію поточної координати на задану ієрархію.

Побудова іменованих множин у багатомірних вираженнях

Щоб полегшити роботу з довгими, складними або часто використовуваними вираженнями, у багатомірних вираженнях можна визначити таке вираження як іменована множина.

По суті, іменованамножина являє собою вираження множини, якому призначений псевдонім. В іменовану множину можуть входити будь-які елементи або функції, які можуть звичайно включатися в множину. Псевдонім може використовуватися скрізь, де припустимі множини.

Іменована множина можна визначити в одному з наступних контекстів:

Контекст запиту. Щоб створити іменованумножину, що визначена як частина запиту, з областю, обмеженої цим запитом, використовується ключове слово WITH. Потім іменованумножину можна використовувати усередині оператора MDX SELECT. У такому випадку іменована множина, створена з використанням ключового слова WITH, може бути змінена без змін в інструкції SELECT.

Контекст сеансу.Щоб створити іменованумножину, область якої ширше контексту запиту, тобто множина, що діє протягом сеансу багатомірних виражень, варто використовувати інструкцію CREATE SET. Іменований набір, визначений з використанням інструкції CREATE SET, доступний для всіх запитів багатомірних виражень у цьому сеансі. Наприклад, інструкція CREATE SET корисна в клієнтському застосуванні, у якому набір багаторазово застосовується в різних запитах.

Створення іменованих множин з областю дії запиту

Вираження – припустиме багатомірне вираження, що повертає множину.

Набір кортежів не обов'язково заключати в одинарні лапки (''). Одинарні лапки використовуються для версії Analysis Services 2000.

Приклад. Нехай потрібно витягти відомості про продажі вин Шардоне й Каберне. Цей запит повертає досить простий результуючий набір, однак є дуже довгим і громіздким з погляду його обслуговування.

Щоб спростити запит, можна створити іменованумножину[ШардонеКаберне] за допомогою ключового слова WITH:

/Синтаксис оператора створення іменованої множини з областю сеансу для поточного куба.

Для звертання до поточного куба замість вказівки імені куба рекомендується використовувати змінну CURRENTCUBE.

Ключове слово HIDDEN позначає елементи, що обчислюються, як сховані. Такі елементи, що обчислюються, не видні користувачам, що звертаються до куба із запитом.

Іменована множина, створена за допомогою оператора CREATE SET, видаляється тільки при закритті сеансу багатомірних виражень.

Область запиту має пріоритет у порівнянні з областю сеансу.

 Член, щообчислюється, можна створити в будь-якому місці ієрархії. Крім того, члени,що обчислюються, можуть залежати не тільки від існуючих елементів куба, але й від інших елементів, що обчислюються, визначених у тім же багатомірному вираженні.

При визначенні члена, що обчислюється, для нього можна задати один з наступних контекстів.

· Область запиту. Для створення члена, що обчислюється, обумовленого як частина багатомірного запиту, застосовується ключове слово WITH. Після створення обчислюється член, що, можна використовувати в операторі SELECT.

· Область сеансу. Для створення члена, що обчислюється, область якого ширше контексту запиту й поширюється на весь сеанс багатомірних виражень, застосовується оператор CREATE MEMBER. Такий член, що обчислюється, доступний для всіх запитів поточного сеансу.

Створення членів, що обчислюються, для області запиту

У синтаксисі WITH аргумент Псевдонім – це повне ім'я члена, що обчислюється. Повне ім'я містить у собі вимір або рівень, з яким зв'язаний член, що обчислюється. Можна задати значення властивостей комірки для члена, що обчислюється, указавши ім'я властивості комірки й значення властивості. Також речення WITH забезпечує можливість змінювати вміст комірок за допомогою виклику функцій із зовнішніх бібліотек, реалізувати деякі складні концепції типу порядку обчислення й черговості проходу й ін.

Приклад. Визначити член, що обчислюється, [Measures].[Спеціальна знижка], що розраховує особливу знижку, виходячи з початкової суми знижки.

 Члени, що обчислюються, можна створювати в будь-якій точці ієрархії. Наприклад, у наступному запиті визначається член, що обчислюється, [Гарний продавець], за допомогою якого визначається, чи продав заданий магазин більше 100 пляшок пива й вина. Однак у запиті член, що обчислюється, [Гарний продавець], створюється не як нащадок виміру [Товар], а як нащадок члена [Пиво й вина].

Для виміру Measures також можна створювати члени, що обчислюються. Фактично більшість членів, що обчислюються, застосовуваних у реальних бізнес-процесах, звичайно створюється саме для виміру Measures. Члени, що обчислюються, створені для виміру Measures, прийнято називати мерами, що обчислюються.

 Члени, що обчислюються, також можуть створюватися на основі інших членів, що обчислюються, обумовлених у тім же багатомірному вираженні. Наприклад, у наступному запиті значення, створене в першому члені, що обчислюється, [Measures].[Спеціальна знижка], використовується для формування значення другого члена, що обчислюється, [Measures].[Сума спеціальної знижки].

Параметр SOLVE_ORDER визначає порядок, у якому повинні обчислюватися члени, якщо задано кілька членів, що обчислюються.

Нехай потрібно зрівняти якість роботи компаній між двома роками й побачити зміни. Можна побудувати запит, що використовує {[2010], [2011]}як осі й переглядати пари чисел для кожної міри. А можна визначити член, що обчислюється, на рівні Рік, паралель між 2010 і 2011, що буде визначати різницю між ними:

WITH MEMBER Час.[11 до 10] AS 'Час.[2011] -Час.[2010]'

WITH MEMBER Час.[2010].[Дек до Окт] AS 'Час.[2010].[12] - Час.[2010].[10]'

Створення елементів, що обчислюються, з областю дії сеансу

Аргумент <Властивість> може відноситися до стандартних або додаткових властивостей елемента, що обчислюється.

У кожного елемента, що обчислюється, є набір стандартних властивостей. При підключенні клієнтського застосування до Analysis Services стандартні властивості або підтримуються, або доступні для підтримки на вибір адміністратора.

Додаткові властивості можуть бути доступні залежно від визначення куба.

Наступні властивості відображають відомості, що відносяться до рівня виміру в даному кубі.

Питання для самоперевірки

1. Перелічите речення оператора SELECT.

2. У чому відмінність між однаковими реченнями мов SQL і MDX?

3. Чим відрізняються контекст запиту й контекст сеансу?

4. Як створюється іменована множина?

5. Що таке член, що обчислюється?

Методичні вказівки до лекції:[3, с. 165–180]; [8, с. 94–100].

Вправи

1.Напишіть запит до куба К, створеному у вправах до попередньої лекції, що формує двовимірну таблицю з виводом членів одного з вимірів.

2.Одержати результати запитів до куба, створеному у вправі 5 лекції №10. Продемонструвати наступні можливості MDX (для кожного випадку окремий запит):

1) простий запит, що повертає двовимірну таблицю, на одній осі виводяться члени виміру, на іншій – міри куба;

2) запит, що повертає тривимірний куб, з використанням конструкції Where;

3) застосування операцій з множинами Unіon, Іntersect або Except;

4) застосування операцій з множинами Crossjoіn;

5) створення й використання іменованих множин з областю дії запиту;

6) створення й використання елементів, які обчислюються, з областю дії запиту.

При необхідності відредагувати дані в СД, щоб мати можливість побачити результати запитів.

ЛЕКЦІЯ №14
 ФУНКЦІЇ МОВИ БАГАТОМІРНИХ ВИРАЖЕНЬ MDX

Розглядаються наступні питання:

·  категорії функцій;

· функції для навігації в ієрархіях;

· фільтрація даних;

· сортування даних.

Із синтаксичної точки зору функції МDХ можна розділити на методи й властивості.

Методи мають наступний синтаксис:

<function_name> ([<parameter> [, <parameter>...])

Наприклад:

CROSSJOIN({[2010],[2011]},{[Україна],[РФ], [Молдова]}), [Час])

А властивості мають наступний синтаксис:

<object_name>.<property_name>[ (<parameter>[,<parameter>...]

Наприклад:

[Час].DefaultMember

Обидві ці різновиди функцій повертають значення одного з наступних типів: Dimension (Вимір), Hierarchy (Ієрархія), Level (Рівень), Member (Член), Tuple (Кортеж), Set (Множина) і Scalar (Скалярне значення), які, у свою чергу, можуть бути передані як параметри в інші функції

Функції для навігації в ієрархіях

Функція Members застосовується до ієрархій або до рівнів.

При застосуванні до ієрархії функція повертає набір всіх членів ієрархії, незалежно від рівня.

Приклад:  

[Дата].[Ієрархія1].Members – повертає повний перелік всіх років, місяців і днів.

При застосуванні до рівня функція повертає набір всіх членів виміру, що перебувають на даному рівні.

Приклад: [Місце].[Ієрархія_Місце].[Міста].Members – повертає повний перелік всіх міст.

Функція AllMembers працює аналогічно функції Members, але Members повертає всі елементи ієрархії, крім тих, що обчислюються, а AllMembers повертає також і елементи, що обчислюються.

Для переміщення в межах одного рівня, використовуються функції PrevMember і NextMember:

[Дата].[2009].[Березень].NextMember – повертає квітень 2009 року,

[Дата].[2009].[Березень].PrevMember – повертає лютий 2009 року,

[Дата].[2009].[Березень].PrevMember.PrevMember – повертає січень 2009 року.

Для більш компактного запису застосовуються функції Lag(.) і Lеad(.):

[Дата].[2009].[Березень]. Lag(2) ­– повертає січень 2009 року,

[Дата].[2009].[Березень]. Lеad(5) – повертає серпень 2009 року,

[Дата].[2009].[Березень]. Lag(-1) – повертає квітень 2009 року.

Розглянемо приклад ієрархії Магазини (Stores) виміру Магазин (Store).

У цій ієрархії елемент ALL – батько (parent) елементів наступного рівня ієрархії: Україна, РФ і Молдова. Області Одеська, Київська й Херсонська є дочірніми (children) для Україна, і т.д. Області Одеська, Київська й Херсонська також є нащадками (descendants) елемента ALL, а ALL – це предок (ancestor) членів, що представляють області.

Для переміщення нагору й униз по рівнях використовуються функції Children і Parent:

[Дата].[2009].[Березень].Children – повертає всі дні березня,

[Дата].[2009].[Березень].Parent – повертає [Дата].[2009],

[Дата].[2009].[Березень].[25].Parent.Parent – повертає [Дата].[2009] .

Функція Children створює множину елементів, які є дочірніми стосовно заданого елемента

SELECT [Україна].Children ON COLUMNS FROM [MyCube]

Функція Descendants небагато складніше, але вона більш гнучка, чим функція Children. Вона використовується для одержання нащадків члена.

Наприклад, необхідно проаналізувати продажі магазинів, розташованих у різних містах України

SELECT DESCENDANTS([Україна],[Місто магазина]) ON COLUMNS

FROM [MyCube]

Функція Descendants повертає множину членів, які є нащадками заданого члена на заданому рівні ієрархії.

Щоб побачити листові елементи (leaf memebers) – елементи, у яких немає нащадків, що є нащадками елемента Україна, використовується ключове слово LEAVES.

SELECT DESCENDANTS([Магазин.[Країна магазина].[Україна], LEAVES)

on COLUMNS

FROM [MyCube]

МDХ підтримує цілий ряд функцій, які підпадають під категорію функцій для навігації по ієрархії, наприклад, FirstChild, LastChild, функції для роботи з елементами одного рівня, і т.д.

Функція Filter має два параметри: множина і вираження МDХ, що задає критерій і повертає значення типу Boolean. Для обчислення результату функції Filter сервер проходить множину, що була передана як перший параметр функції. Потім для кожного кортежу в множині обчислює вираження, передане як другий параметр. Якщо це вираження приймає значення True, кортеж включається в результуючу множину.

Наприклад, нехай потрібно визначити магазини, продажі в які знизилися в 2010 р., у порівнянні з 2009 р.

SELECT Filter([Магазин].members,

([Кількість продажів], [2010]) < ([Кількість продажів],[2009])) ON COLUMNS,

{[2009], [2010]} ON ROWS

FROM [MyCube]

WHERE [Кількість продажів]

Для виконання функції Filter сервер обчислює вираження фільтра ([Кількість продажів],[2010]) < ([Кількість продажів],[2009]). Це вираження містить тільки члени вимірів Measure і Час. Всі інші члени визначаються по кроках, описаних у визначенні контексту запиту: сервер спочатку встановлює в поточну координату члени за замовчуванням всіх атрибутів, а потім перезаписує їхніми членами вимірів, зазначеними в реченні WHERE. Потім сервер перезаписує члени, зазначені у вираженні критерію. І, нарешті, перезаписуються члени, зазначені у множині,яка фільтрується.

Інший приклад

SELECT Filter([Клієнт]. [Країна].members,

[Measures].[Кількість продажів].Value>1000) ON COLUMNS

FROM [MyCube]

WHERE ([Час].[Рік].[2009])

У цьому запиті фільтруються магазини в міру Кількість продажів. Нехай мережа магазинів спочатку була тільки в Україні; так що в 2009 р. всі продажі були тільки в Україні. Але в 2010 р. товари продавалися також у Росії й Молдові. Якби вираження Filter обчислювалося в контексті вираження, а не в контексті всього запиту, у результаті були б отримані всі три країни: Україна, РФ і Молдова. Для виміру Час використовується член за замовчуванням ALL. У запиті із приклада буде отримана тільки одна країна: Україна, тому що поточний контекст для виконання вираження включає члени, зазначені в реченні WHERE

Тобто речення WHERE впливає на обчислення вираження критерію й на результат функції Filter.

Щоб краще зрозуміти правила обчислення контексту у функції фільтрації, розглянемо, що відбудеться, якщо виміри, використовувані у вираженні критерію, були б тими ж самими, що й у реченні WHERE. Допустимо, що в запиті вимір Measure існує й у речнні WHERE, і у вираженні критерію. При виконанні вираження критерію сервер буде використовувати міру Кількість продажів, але для обчислення значень комірок буде використана міра Сума продажів.

SELECT Filter([Клієнт].[Країна].members,

[Measures].[Кількість продажів].Value>1000) ON COLUMNS

FROM [MyCube]

WHERE ([Час].[Рік].[2009], [Measures].[Сума продажів])

Функція Order сортує кортежі в множині у відповідності зі значенням вираження, що передається як другий параметр.

Приклад. Відсортувати магазини за значеннями міри Сума продажів.

SELECT Order( [Магазин].members, [Measures].[Сума продажів], BDESC)

ON COLUMNS

FROM [MyCube]

У цьому операторі результуюча множина відсортована в порядку убування. Але при цьому зігнорована ієрархічність множини.

Розглянемо приклад, що показує сортування зі збереженням ієрархічності. Наприклад, треба проаналізувати продуктивність магазинів, але потрібно зробити це в контексті країни, у якій розташований магазин. Тому необхідно не просто відсортувати магазини, порівнюючи їхній один з одним. Спочатку потрібно відсортувати значення для країн, у яких розташовані магазини. Потім будуть відсортовані області, міста й тільки після всього цього – магазини. Тепер можна порівнювати значення продажів в одному магазині зі значеннями продажів в інших магазинах того ж самого міста. Ключове слово DESC у функції Order указує системі, що при упорядкуваннімножини в убутному порядку треба зберегти ієрархічність, визанчену користувальницькою ієрархією.

SELECT Order(([Магазин].[Країна магазина].members,

[Магазин].[Область магазина].members),

[Measures].[Сума продажів], DESC) ON COLUMNS

FROM [MyCube]

Результати цього запиту показують, що найбільше продажів було зроблено в Україні, і серед областей в Україні найбільше продажів в Одеській області, потім ідуть магазини в Херсонській області й потім – у Київській.

Невизначені члени

Члени виміру, використані в MDX-Запиті, можуть не існувати в кубі (наприклад, вони можуть бути задані неправильно). Комірки багатомірного простору теж можуть виявитися порожніми.

Наприклад, в MDX-вираженні використовується член, що перебуває поза границями куба. Це може відбутися, наприклад, коли запит вибирає батьківський елемент елемента, що перебуває на верхньому рівні ієрархії. Для обробки таких випадків уведена концепція невизначених членів (Null Members) і невизначених кортежів (Null tuples):

- сервер використовує невизначений член для посилання на координату, що перебуває поза простором куба;

- якщо кортеж містить хоча б один невизначений член, він називається невизначеним кортежем.

У деяких випадках використання невизначених членів і кортежів дозволено, в інших– приводить до повідомлення про помилку. Деякі функції МDХ повертають помилку, якщо як параметр передається невизначений член або кортеж.

Якщо множина не містить кортежів або містить тільки невизначені кортежі, воно називається порожньою множиною (empty set). Якщо множина містить як звичайні, так і невизначені кортежі, користувачеві вертаються тільки звичайні кортежі. Наприклад, наступний запит поверне тільки один кортеж:

SELECT {[All], [All].Parent} ON COLUMNS

FROM [MyCube]

Режим відсутності члена

В Analysis Services 2000 при посиланні на член по імені, що не відповідає ніякому елементу в кубі, видавалася помилка, що приводило до проблем у деяких клієнтських застосуаннях. Наприклад, клієнтські затосувння зберігають текст запитів МDХ, які використовувалися для формування звітів. Згодом, якщо члени видалялися із системи, запити, що посилаються на вилучені елементи, переставали працювати, і звіти переставали відкриватися. Analysis Services 2005 представлена нова можливість – Режим Відсутності члена (Missing Member Mode).

Цей режим дозволяє запиту або вираженню МDХ посилатися на члени, які не існують у кубі. Система перетворить такі члени в невизначені.

Наприклад, якщо потрібно вибрати деяких покупців, можна написати наступний запит SQL

SELECT Прізвище, Ім'я, По батькові, Посада    

FROM Клієнт

WHERE Прізвище = 'Іванов' or Прізвище ='Петров'

Якщо в базі даних не існує покупця на прізвище Петров, запит поверне тільки один запис для клієнта Іванов і не викличе помилку.

Аналогічний МDХ-запит

 SELECT {[Клієнт].[Іванов],[ Клієнт].[Петров]} ON COLUMNS

FROM [MyCube]

В Analysis Services 2000 відсутність елемента Петров у базі даних привело б до помилки. Analysis Services 2005 у режимі відсутності елемента виконає запит успішно й поверне результат зі значенням тільки для покупця Іванов.

Режим відсутності члена може бути включений і виключений у рамках виміру. Деякі виміри більш гнучкі, і дані в них міняються частіше, чим в інших. Наприклад, вимір покупців буде часто мінятися, а вимір часу, наприклад, досить постійно.

Для керування режимом відсутності члена вимір має властивість Режим Відсутності члена (MdxMissingMemberMode), що може бути встановлена в стан Помилки (Error) або Ігнорувати Помилку (IgnoreError). За замовчуванням режим відсутності члена встановлений в Ігнорувати Помилку (IgnoreError).

Режим відсутності елемента не поширюється на імена вимірів, і неправильно зазначене ім'я виміру приведе до помилки.

Кортежі, автоматична перевірка існування

Відомо, що простір куба визначається елементами ієрархій атрибутів. Але в дійсності багатомірний простір обмежений. Існують комбінації елементів з різних ієрархій членів вимірів, які просто не існують у таблиці виміру або в кубі. Наприклад, покупець Ірина Петрова – Жінка, і в таблиці виміру Покупець існує запис Ірина Петрова, Ж. Це значить, що кортеж ([Клієнт].[Стать].[Ж], [Ірина Петрова]) існує у вимірі Клієнт. Чоловіка з ім'ям Ірина Петрова у вимірі не задано, тому кортеж ([Клієнт].[Стать].[M], [Ірина Петрова]) не існує. Коли вираження МDХ посилається на кортеж, що не існує у вимірі, то система перетворить його до невизначеного кортежу. Наприклад, наступний запит поверне порожній результат:

SELECT {([Клієнт].[Стать].[M], [Ірина Петрова]) } on COLUMNS

FROM [MyCube]

Результатом виконання вираження МDХ не може бути неіснуючий кортеж. Тому система видаляє неіснуючі кортежі з результуючої множини спеціальною операцією, називаної автоматична перевірка існування (Auto-Exists). Результати застосування системою операції Auto-Exists можна побачити при виконанні наступної функції Crossjoin. Якщо множини, що беруть участь у функції Crossjoin, належать тому самому виміру, неіснуючі кортежі видаляються. Наприклад, якщо взяти множину із двох покупців –Ірина Петрова (жінка) і Василь Іванов (чоловік) – і використовувати функцію Crossjoin для об'єднання цієї множини з множиною, що складається з одного елемента, [Клієнт].[Стать].[M], що результуючамножина не буде містити повне перехресне з'єднання ([Ірина Петрова], [M]), ([Василь Іванов], [M]), а тільки один кортеж ([Василь Іванов, [M]).

SELECT { [Ірина Петрова], [Василь Іванов] } * [Клієнт].[Стать].[M] on COLUMNS

FROM [MyCube]

WHERE [Measures].[Кількість продажів]

Сервер не виконує Auto-Exists між осями, але Auto-Exists виконується для множин, спроектованих на осі, з множиною, заданою в реченні WHERE. Наприклад, якщо помістити множину {[Ірина Петрова], [Василь Іванов]} на вісь, але елемент [Клієнт].[Стать].[M] у речення WHERE – кортеж [Ірина Петрова] буде вилучений з множини, спроектованої на вісь COLUMNS.

SELECT { [Ірина Петрова], [Василь Іванов] } ON COLUMNS

FROM [MyCube]

WHERE ([Measures].[ Кількість продажів],[Клієнт].[Стать].[M])

Для того щоб визначити, які елементи існують із іншими елементами, на додаток до операції Auto-Exists, можна використовувати МDХ-Функцію Exists, уведену в Analysis Services 2005. Функція Exists приймає як параметри дві множини й повертає множину кортежів з першої множини, які існують хоча б для кортежу із другої множини. Наприклад,

SELECT Exists({[Ірина Петрова], [Василь Іванов]}, [Клієнт].[Стать].[M]) ON COLUMNS

FROM [MyCube]

WHERE [Measures].[Кількість продажів]

Приклад. Одержати відомості про продажі для покупців, які працюють менеджерами.

SELECT [Measures].[ Кількість продажів] on COLUMNS,

Exists([Клієнт].members,

[Клієнт].[Посада].[Менеджер]) ON ROWS

FROM [MyCube]

Невизначені значення й порожні комірки

Логічний простір куба, до якого можна звертатися із запиту МDХ, є дуже великим. Воно включає комбінації всіх елементів всіх ієрархій, незалежно від того, чи існують які-небудь дані для цих комбінацій.

Нехай організація почала працювати в Україні, а потім розширила своє діяльність на РФ і Молдову. Тому в 2009 р. продажі були тільки в магазинах в Україні, так що в багатомірному просторі не існує даних про продажі в РФ і Молдові. Нехай є запит для одержання інформації про продажі в 2009 р. і про посади покупців, які зробили покупки в магазинах різних країн:

SELECT [Клієнт].[Посада].members ON COLUMNS,

[Магазин]. [Країна магазина].members ON ROWS

FROM [MyCube]

where ([Measures].[Сума продажів],[Час].[Рік].[2009])

Для видалення подібних координат з результуючого багатомірного простору можна використовувати оператор NON EMPTY.

SELECT [Клієнт].[Посада].members ON COLUMNS,

NON EMPTY [Магазин].[Країна магазина].members ON ROWS

FROM [MyCube]

WHERE ([Measures].[Сума продажів],[Час].[Рік].[2009])