ПРОЕКТУВАННЯ БАЗИ ДАНИХ ДЛЯ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ

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

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

2 Після цього створюється фізичний проект, який повинен бути похідним від логічного проекту На цьому рівні, безумовно, основна увага приділяється ефективності зберігання даних і продуктивності В принципі, допустимо будь-яка фізична розташування даних, за умови, що між логічної і фізичної схемами вводиться зберігає інформацію перетворення, яке може бути виражене за допомогою реляційної алгебри [25] Відзначимо, в приватно сті, що з наявності такого перетворення випливає, що існують реляційні уявлення фізичної схеми, які відображають її подібно логічною схемою, і навпаки

Безумовно, логічна схема може бути згодом змінена, наприклад, в цілях включення нових видів даних, а також нових або нововиявлених залежностей Внесені зміни, природно, зажадають також відповідних змін у фізичній схемою Але це питання в даній главі не розглядається Тут нас більше цікавить те, що фізична схема може змінюватися, у той час як логічна схема буде залишатися незмінною Наприклад, припустимо, що операція зєднання таблиць SP (Поставки) і Р (Деталі) значною мірою застосовується набагато частіше порівняно з іншими операціями доступу до даних Тоді може виникнути прагнення виконати попереднє зєднання таблиць SP і Р на фізичному рівні, щоб скоротити тим самим кількість операцій введення-виведення і витрати на зєднання цих таблиць Але логічна схема повинна залишатися незмінною, якщо ми хочемо зберегти фізичну незалежність від даних (Безумовно, оптимізатор запитів повинен мати інформацію про існування зберігається попереднього зєднання і діяти відповідним чином, щоб досягти бажаного підвищення продуктивності) Крім того, якщо модель доступу надалі зміниться таким чином, що стане переважати доступ до окремих таблицями, а не до зєднання, повинна існувати можливість знову змінити фізичну схему, щоб фізично розєднати таблиці SP і р, знову-таки, без будь-якого впливу на логічний рівень

Зі сказаного вище має бути ясно, що проблема забезпечення незалежності від фізичних даних – це в основному проблема підтримки уявлень (виключаючи проблему оновлення фрагментів, розглянуту у розділі 21, яка проявляється на

іншій ділянці загальної архітектури системи) Зокрема, необхідно мати можливість оновлювати такі подання А саме, якщо базові таблиці розглядаються на логічному рівні як уявлення, а збережені версії цих уявлень на фізичному рівні розглядаються як таблиці, то повинна застосовуватися така фізична схема, щоб СУБД дозволяла здійснювати операції оновлення цих уявлень в термінах зазначених базових таблиць

Отже, як показано в розділі 9, теоретично все уявлення є оновлюваними Тому, з теоретичної точки зору, якщо фізична схема розроблена на основі логічної схеми за принципом, описаним вище, то може бути досягнута максимальна фізична незалежність від даних Будь-яке оновлення, виражене в термінах логічної схеми, буде автоматично перетворено в оновлення, виражене в термінах фізичної схеми, і навпаки, а самі зміни фізичної схеми не вимагатимуть змін до логічної схемою Але, на жаль, сучасні продукти SQL не підтримують в необхідній мірі поновлення уявлень Тому набір допустимих фізичних схем в цих продуктах дуже обмежений (причому абсолютно зайве)

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

Логічне проектування

Правила логічного проектування не залежать від передбачуваного використання бази даних Те ж саме відноситься і до всіх без винятку видах додатків Отже, зокрема, не повинно мати значення, якими є ці програми – оперативними додатками (OLTP) або додатками підтримки прийняття рішень У кожному разі, повинна використовуватися одна і та ж процедура проектування Тому ще раз проаналізуємо три логічні характеристики баз даних підтримки прийняття рішень, визначені на початку розділу 222, а також розглянемо, наскільки вони важливі з точки зору логічного проектування

■&nbsp&nbsp&nbsp Використання сполучень стовпців і зменшення кількості залежностей

У запитах підтримки прийняття рішень, а також в оновленнях, якщо вони застосовні, поєднання стовпців часто розглядаються як єдине ціле Мається на увазі, що до стовпців, що входять до складу подібних поєднань, ніколи не доводиться звертатися окремо (наочним прикладом може служити адресу, ADDRESS) Домовимося називати такі поєднання стовпців складовими стовпцями Але з логічної точки зору подібні складові стовпці поводяться так, як ніби насправді вони НЕскладові Припустимо, що СС – це складовою стовпець, а с – небудь інший стовпець у тій же таблиці Тоді залежності між стовпцем С і компонентом (компонентами) стовпця СС зводяться до залежностей між стовпцем с і складовим стовпцем СС як єдиним цілим Більш того, залежності, що включають компоненти складеного стовпця СС і не включають ніякі інші стовпці, не мають сенсу і можуть просто ігноруватися В результаті загальне число залежностей скорочується і логічний проект стає простіше, з меншою кількістю стовпців і, можливо, навіть з меншим числом таблиць

■&nbsp&nbsp&nbsp&nbsp&nbsp Загальні обмеження цілісності

Як вже було описано вище, бази даних підтримки прийняття рішень в основному призначені тільки для читання, і обмеження цілісності перевіряються тільки при завантаженні (або оновленні) бази даних Тому часто вважають, що немає ніякого сенсу оголошувати обмеження цілісності в їх логічній схемі Але цей довід звучить непереконливо Якщо база даних дійсно призначена тільки для читання, такі обмеження насправді не можуть бути порушені Але не можна недооцінювати семантичне значення цих обмежень Як вже зазначалося в розділі 9, обмеження служать для визначення формального сенсу таблиць і формального сенсу всієї бази даних в цілому Тому визначення обмежень надає спосіб передачі користувачам відомостей про сенс даних, а це допомагає їм вирішувати завдання формулювання запитів Крім того, оголошення обмежень може надавати вкрай важливу інформацію для оптимізатора (Див обговореннясемантичної оптимізаціїв главі 18) Примітка У деяких програмних продуктах оголошення певних обмежень призводить до автоматичного створення відповідних індексів і / або інших механізмів примусового вибору шляхів доступу, що може істотно збільшити вартість операцій завантаження та поповнення бази даних У свою чергу, для проектувальників це може послужити приводом для відмови від обяапеній обмежень І знову повторимо, що ця проблема виникає через плутанину між логічними та фізичними аспектами проектування Повинна існувати можливість визначити обмеження цілісності декларативно, на логічному рівні, після чого окремо визначити відповідні механізми примусового вибору шляхів доступу на фізичному рівні На жаль, сучасні програмні продукти не дозволяють належним чином провести відмінності між логічним і фізичним рівнями (більше того, розробники цих продуктів рідко взагалі визнають семантичне значення обмежень)

■&nbsp&nbsp&nbsp Тимчасові ключі

Оперативні бази даних зазвичай містять тільки поточні дані Бази даних підтримки прийняття рішень, навпаки, зазвичай містять архіви історично накопичених даних і тому більша частина даних або навіть всі дані включають тимчасової штамп,або тимчасову позначку Ключі в таких базах даних часто містять стовпці з тимчасовими позначками Наприклад, знову звернемося до бази даних постачальників і деталей Припустимо, що необхідно розширити її таким чином, щоб для кожної поставки був показаний конкретний місяць (від 1 до 12), в який проводилася поставка У цьому випадку таблиця поставок SP може виглядати, як показано на рис 221 Зверніть увагу на те, що додатковий стовпець MID (ідентифікатор місяці) входить до складу ключа розширеній версії таблиці SP Слід також відзначити, що тепер запити до даних з таблиці SP необхідно формулювати дуже уважно для того, щоб доступ здійснювався саме до тих даних, які потрібні, не більше і не менше Ці питання вже коротко розглядалися в розділі 222, а в главі 23 вони описані більш докладно

Примітка У результаті додавання стовпців з тимчасовими відмітками може виникнути необхідність провести коригування проекту бази даних Припустимо, наприклад (хоча це і трохи надумано), що кількість деталей

в кожній поставці залежить від того місяця, коли проводилася ця поставка (на рис 221 дані відповідають цьому обмеженню) Тоді переглянута версія таблиці SP задовольнятиме функціональної Залежно MID -> QTY і тому не буде знаходитися в пятій нормальній формі і навіть у третій нормальній формі Таким чином, виникає необхідність провести її подальшу нормалізацію, як показано на рис 222 На жаль, проектувальники баз даних підтримки прийняття рішень рідко замислюються над тим, що база даних повинна враховувати такі залежності Додаткові відомості про це також наведені в главі 23

Рис 221 Приклад таблиці SP, що включає поле ідентифікатора місяці

Рис 222 Нормалізований аналог таблиці SP, представленої на рис 221

Фізичне проектування

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

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

Спочатку розглянемо підхід до організації бази даних, званий секціонуванням (Відомий також під назвою фрагментації)Секціонування (partitioning) являє собою можливий підхід до вирішення проблеми великих баз даних Кожна таблиця ділиться на групу непересічних секцій, або фрагментів, призначених для незалежного фізичного зберігання (див обговорення питання про фрагментацію у розділі 21) Таке секціонування дозволяє істотно розширити можливості управління і доступу до розглянутої таблиці Зазвичай за кожною секцією закріплюються певні виділені (в тій чи іншій мірі) апаратні ресурси, наприклад диск або процесор, внаслідок чого конкуренція між секціями за такі ресурси зводиться до мінімуму Таблиці секціонуючою по горізонталі4 за допомогою функції секціонування, яка використовує значення вибраних стовпців, складових ключ секції, в якості фактичних параметрів, а повертає номер або адресу секції Такі функції зазвичай підтримують секціонування за діапазоном (range partitioning), за допомогою хеш-функції(Hash partitioning) і циклічне секціонування (Round-robin partitioning), не рахуючи інших видів секціонування (див анотацію до [1856] в главі 18)

Тепер звернемося до питання індексації Відомо, що використовуючи підходящий індекс, можна різко скоротити кількість фізичних операцій введення-виведення У ранніх продуктах SQL надавався лише один вид індексів, а саме – індекси, представлені у вигляді В-дерев Пізніше, через кілька років, стали застосовуватися і деякі інші види індексів, особливо у звязку з використанням баз даних підтримки прийняття рішень Серед них найбільше поширення отримали бітові індекси, хешіро ванні індекси, мультітаблічние індекси, логічні індекси, функціональні індекси, а також вже відомі нам індекси у вигляді В-дерев Розглянемо кожен з цих пидов індексів, як описано нижче

■&nbsp&nbsp&nbsp Індекси у вигляді В-дерев Індекси у вигляді В-дерев надають для запитів ефективний доступ до діапазонів значень, за винятком тих випадків, коли до лічество підходящих рядків стає занадто велике Оновлення В-дерев здійснюється відносно ефективно

■&nbsp&nbsp&nbsp Бітові індекси Припустимо, що в індексованої таблиці т міститься п рядків Тоді бітовий індекс для стовпця з таблиці т міститиме вектор з л бітів для кожного можливого значення С і встановлений біт буде відпо вовать рядку R, якщо в рядку R міститься відповідне значення з шпальти С Такі індекси дозволяють ефективно виконувати запити, в яких викорис товуються безлічі значень, але їх ефективність знижується, якщо ці безлічі стають занадто великі Зверніть увагу на те, що кілька Реляційних них операцій (зєднання, обєднання, скорочення з рівності і тп) можуть бути виконані виключно з індексами за допомогою простих логічних операцій (AND, OR, NOT) над бітовими векторами Доступ до реальних даних під загально не відбувається до тих пір, поки не буде потрібно одержання остаточного

4 Хотявертикальноесекционированиетакжеможетиметьопределенныепреимущества,оноиспользуетсядовольноредко,поскольку большинствопрограммныхпродуктовегонеподдерживает

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

■&nbsp&nbsp&nbsp&nbsp Хешірованние індекси (Доступ з їх використанням називається також хеш-адресацієюабо просто хешем) Хешірованние індекси ефективні для доступу до кон конкретним рядкам, а не до діапазонів Обчислювальна вартість залежить від кіль пра ці рядків лінійно, за тієї умови, що хеш-функцію не потрібно доповнювати з урахуванням додаткових значень ключа Хешування може також вико тися для ефективної реалізації сполук, як описано в главі 18

■&nbsp&nbsp&nbsp&nbsp Мултітаблічние індекси (Іноді вони називаються індексами зєднанні) За су ществу, елемент мультітаблічного індексу містить покажчики на рядки в скількох таблицях, а не просто покажчики на рядки в одній таблиці Такі індек си дозволяють підвищити продуктивність операцій зєднання і прискорити перевірку обмежень цілісності для декількох таблиць (тобто для бази даних), як описано в [2233]

■&nbsp&nbsp&nbsp&nbsp Логічні індекси (Більш відомі як індекси на основі логічних виразів)

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

■&nbsp&nbsp&nbsp&nbsp Функціональні індекси Функціональні індекси індексують рядка таблиці не на основі значень в цих рядках, а на основі результату застосування до цих значень деякої функції

На додаток до сказаного слід зазначити, що передбачені також різні види змішаних,або гібридних, індексів, що представляють собою поєднання перерахованих вище індексів Сенс таких поєднань важко викласти в загальних словах Також пропонується безліч спеціалізованих видів індексів, таких як R-дерева, які призначені для обробки просторових даних У справжній книзі не робиться спроба вирішити таку трудомістку задачу, як опис всіх видів індексів зацікавлені читачі можуть звернутися до [2637], де міститься вичерпний виклад цієї теми

Нарешті, розглянемо питання контрольованої надмірності Контрольована надмірність – Це важливий інструмент скорочення кількості операцій введення-виведення та мінімізації конкурентного доступу до даних в базі Як пояснювалося в розділі 1, надмірність контрольована, якщо вона управляється СУБД і прихована від користувачів (Зазначимо, що за визначенням надмірність, яка належним чином контролюється на фізичному рівні, залишається невидимою на логічному рівні і тому не впливає на правильність даних на логічному рівні) Існує два загальні види такої надмірності, які описані нижче

■ Перший вид включає обслуговування в базі даних точних копій або реплік

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

■ Другий вид включає обслуговування похідних даних на додаток до базових даних Найбільш часто використовується у формі підсумкових таблиць та / або розрахункових (обчислених або похідних) стовпців

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

Реплікація

Основні поняття реплікації були розглянуті в розділах 213 і 214 глави 21 (див, зокрема, підрозділ Поширення оновлень в розділі 214) Тут ми просто повторимо кілька основних пунктів з цих розділів і наведемо деякі додаткові зауваження Насамперед, нагадаємо, що реплікація може бути синхронної або асинхронної, як описано нижче

■ У випадку синхронної реплікації, якщо дана репліка оновлюється, всі інші ре плікі того ж фрагмента даних також повинні бути оновлені в одній і тій же транзакції Логічно це означає, що існує лише одна версія даних У більшості продуктів синхронна реплікація реалізується за допомогою тригерних процедур (можливо, прихованих і керованих системою) Але синхронна реплікація має той недолік, що вона створює додаткове навантаження при виконанні всіх транзакцій, в яких оновлюються які-небудь репліки (крім того, можуть виникати проблеми, повязані з доступністю даних)

■ У випадку асинхронної реплікації оновлення однієї репліки поширюється на інші через деякий час, а НЕ в тій же транзакції Таким чином, при асинхронної реплікації вводиться затримка, або час очікування, протягом кото рого окремі репліки можуть бути фактично неідентичними (тобто визначення репліка виявляється не зовсім відповідним, оскільки ми не маємо справу з точними і своєчасно створеними копіями) У більшості продуктів асинхронна реплікація реалізується за допомогою читання журналу транзакцій або постійної черги тих оновлень, які підлягають поширенню

Перевага асинхронної реплікації полягає в тому, що додаткові витрати реплікації не повязані з транзакціями оновлень, які можуть мати важливе значення для функціонування всього підприємства і предявляти високі вимоги до продуктивності До недоліків цієї схеми відноситься те, що дані можуть виявитися несумісними (тобто несумісними з точки зору користувача) 5 Іншими словами, надмірність може проявлятися на логічному рівні, а це, строго кажучи, означає, що термін контрольована надмірність в такому разі не застосуємо

Розглянемо коротко проблему узгодженості (або, швидше, неузгодженості) Справа в тому, що репліки можуть ставати несумісними в результаті таких ситуацій, яких важко (або навіть неможливо) уникнути і наслідки яких важко виправити Зокрема, конфлікти можуть виникати з приводу того, в якому порядку повинні застосовуватися оновлення Наприклад, припустимо, що в результаті виконання транзакції А відбувається вставка рядка в репліку х, після чого транзакція в видаляє цей рядок, а також припустимо, що Y – репліка X Якщо поновлення поширюються на Y, але вводяться в репліку Y у зворотному порядку

5 Див примітки на цю тему в попередньому розділі

(Наприклад, через різних затримок при передачі), то транзакція в не знаходить в Y рядок, що підлягає видаленню, та не виконує свою дію, після чого транзакція А вставляє цей рядок Сумарний ефект полягає в тому, що репліка У містить зазначену рядок, а репліка X – ні В цілому завдання усунення конфліктних ситуацій і забезпечення узгодженості реплік є досить складними Додаткові відомості з цієї теми виходять за рамки даної книги

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

Основна відмінність між реплікацією (яка розглядалася вище) і управлінням копіюванням полягає в наступному Якщо використовується реплікація, то оновлення однієї репліки в кінцевому рахунку поширюється на всі інші автоматично У режимі керування копіюванням, навпаки, не існує такого автоматичного розповсюдження оновлень Копії даних створюються і управляються за допомогою пакетного або фонового процесу, який відділений в часі від транзакцій оновлення Управління копіюванням в загальному більш ефективно в порівнянні з реплікацією, оскільки за один раз можуть копіюватися великі обсяги даних До недоліків можна віднести те, що більшу частину часу копії даних не ідентичні базовим даними, тому користувачі повинні враховувати, коли саме були синхронізовані ці дані Зазвичай управління копіюванням спрощується завдяки тому вимогу, щоб оновлення застосовувалися у відповідності зі схемою первинної копії того чи іншого виду (див главу 21)

Похідні дані

Ще одним видом надмірності, який розглядається у цій главі, є похідні дані, а саме розрахункові стовпці і підсумкові таблиці Ці обєкти особливо важливі в контексті систем підтримки прийняття рішень У них містяться попередньо підраховані значення даних – значення, які обчислюються на основі інших даних, що зберігаються в тій же базі даних Ясно, що такі обєкти дозволяють уникнути необхідності кожного разу повторно обчислювати підсумкові значення, коли вони знадобляться в якомусь запиті Розрахунковий стовпець – це такий стовпець, значення якого в цьому рядку є похідним від інших значень в тому ж рядку (Ще один варіант полягає в тому, що розрахункове значення може бути отримано на підставі значень з декількох рядків у тій же таблиці або в якійсь іншій таблиці (таблицях) Але такий підхід характеризується тим, що оновлення одного рядка може спричинити за собою також оновлення багатьох інших рядків зокрема, це може надати дуже негативно вплив на операції завантаження та поповнення бази даних) Підсумкова таблиця – це таблиця, в якій містяться агреговані значення з інших таблиць (сумарні, середні значення, дані про кількість рядків і тп) Такі агреговані значення часто попередньо обчислюються для декількох різних угруповань одних і тих же вихідних даних (див раздел226)

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

(Automatic Summary Table – AST), матеріалізовані таблицями запитів (Materialized

Query Table — MQT), знімками і матеріалізовані уявленнями Останні два з цих термінів вже зустрічалися раніше в цій книзі (див розділ 105 глави 10), де була висловлена ​​вкрай різка критика, зокрема, такого терміна, як матеріалізоване уявлення Але як би то не було, тепер це поняття стало темою великого розділу літератури, і в основній частині цієї літератури термін уявлення використовується виключно для позначення поняття матеріалізоване уявлення (Крім усього іншого, см [223] і [224])

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

Поширені помилки проектування

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

■&nbsp&nbsp&nbsp&nbsp Дублювання рядків Проектувальники систем підтримки прийняття рішень часто стверджують, що застосовувані ними дані просто не мають унікальних иденти фікаторов, і тому допустимо дублювання рядків В [63] і [66] детально пояснено, чому відсутність коштів виключення дублікатів є помилкою Тут же ми просто відзначимо, що ця необхідність виникає через те, що фізична схема не є похідною від логічної схеми, яка, віз можна, ніколи і не створювалася Також відзначимо, що в подібних проектах рядки часто мають неоднорідне значення, особливо якщо в цих рядках присутні невизначені дані Інакше кажучи, не всі рядки є екземплярами од ного і того ж предиката (див розділ 34 або главу 9)

Примітка Іноді дублікати навіть розглядаються як корисний засіб, особливо тими фахівцями, які мають підготовку в області обєктно-орієнтованого

програмування (див останній абзац в розділі 252 глави 25) ■Денормализация і повязані з нею дії Керуючись необгрунтованим прагненням виключити

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

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

■&nbsp&nbsp&nbsp&nbsp Зіркоподібні схеми Зіркоподібні схеми, звані також багатовимірними схемами, найчастіше стають результатом спроби ігнорувати правильні методи проектування Однак від таких спроб мало користі У міру збільшен ня кількості даних в базі, знижується продуктивність і втрачається гнучкість, а дозвіл виникаючих труднощів за допомогою фізичного перепроектує вання вимагає внесення змін і в додатки (оскільки зіркоподібні

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

■&nbsp&nbsp&nbsp&nbsp Невизначені значення Проектувальники часто намагаються заощадити місце, до пускаючи наявність в стовпцях невизначених значень (цей прийом може виявитися виправданим, тільки якщо розглянутий стовпець має тип даних змін ної довжини, а у програмному продукті невизначені значення в таких стовпцях на фізичному рівні видаються порожніми рядками) Але в загальному випадку подібні спроби є помилковими Слід враховувати, що не тільки можливо, але і бажано розробляти проект просто таким чином, щоб відразу ж виключити необхідність використання невизначених значень [1919], так як при цьому результуючі схеми часто забезпечують більш висо кую ефективність використання памяті і кращу продуктивність опера ций введення-виведення

■&nbsp&nbsp&nbsp&nbsp Проектування підсумкових таблиць Необхідність логічного проектування підсумкових таблиць нерідко ігнорується, внаслідок чого виникають неконтрольо ється надмірність і труднощі з підтримкою узгодженості даних в базі В результаті користувачі стикаються з труднощами при інтерпретації сумарних значень і при формулюванні запитів з їх використанням Щоб уникнути подібних проблем, всі підсумкові таблиці, що відносяться до одного й того ж рівня агрегування (Розділ 226), необхідно проектувати так, як якщо б вони складали окрему базу даних У цьому випадку зявляється можливість виключити певні проблеми циклічного оновлення, забороняючи обновле ня, які охоплюють кілька рівнів агрегування даних, а також сін хронізіруя підсумкові таблиці за допомогою методу, який завжди предусматрива ет агрегування від рівня вихідних даних в напрямку все більшого узагальнення даних

■&nbsp&nbsp&nbsp&nbsp Множинні шляхи доступу Проектувальники систем підтримки прийняття ре шений і їх користувачі часто помилково вказують на множинність шляхів доступу до деяких необхідним ним даними, маючи на увазі, що одні й ті ж дані можуть бути отримані за допомогою декількох різних реляційних Вира жений Іноді такі вирази дійсно рівносильні, як у випадку, на приклад, А JOIN (В JOIN С) і (A JOIN В) JOIN С (див главу 18) Іноді вони рівносильні завдяки дії деякого обмеження цілісності (знову см главу 18), але найчастіше насправді вони виявляються аж ніяк не рівносильний вими Для ілюстрації останнього випадку припустимо, що таблиці А, в і з та кови: А, в мають загальний стовпець КАВ, в і с – загальний стовпець квс, а А і з – про щий стовпець КАС тоді зєднання таблиць А і в по стовпці КАВ, а потім соедине ня отриманого результату з таблицею з по стовпці квс, безумовно, не буде од ним і тим же, що й зєднання таблиць і з по стовпці КАС

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

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*