БАЗА ДАНИХ ПОСТАЧАЛЬНИКІВ І ДЕТАЛЕЙ

У цій книзі в більшості прикладів використовується база даних, відома під назвою бази даних постачальників і деталей Призначення цього розділу – ознайомити читача з цією базою даних, яка буде служити прикладом для посилань в наступних розділах На рис 39 показано безліч значень її даних Саме ці конкретні значення будуть фактично використовуватися надалі (де це має сенс) 8 На рис 310 показано визначення бази даних, для якого знову використовується мова Tutorial D (в цій мові ключове слово VAR означає змінна) Зверніть увагу на те, що кілька стовпців мають типи даних, яким присвоєно назву, аналогічне назві відповідного стовпця Стовпці STATUS І CITY визначені як мають не користувальницький, а вбудований тип даних, відповідно, INTEGER (ціле) і CHAR (рядок символів довільної довжини) Нарешті, необхідно відзначити, що стосовно до значень, показаним в шпальтах на рис 39, повинно бути зроблено одне важливе зауваження, проте ми ще не готові до цього Тому обговорення згаданого зауваження буде відкладено до глави 5, точніше, до кінця підрозділу

“Можливі формати представлення, селектори і оператори ТНЕ_ в розділі 53

Передбачається, що ця база даних має наступне призначення

■ Мінлива відносини S представляє постачальників (Точніше, постачальників, рабо танучих за контрактом) Кожен постачальник має унікальний номер (s #) імя (SNAME), не обовязково унікальне (хоча воно може бути унікальним, як в слу чаї, представленому на рис 39) значення рейтингу чи статусу (STATUS) місце розташування (CITY) Передбачається, що для кожного постачальника може бути вказаний тільки одне місто

■ Мінлива відносини Р являє деталі (Точніше, види деталей) У кожного виду деталі є номер деталі (Р #), який є унікальним назва дета чи (PNAME) колір (COLOR) вага (WEIGHT) місто, де знаходиться склад з деталями цього виду (CITY) Передбачається, що якщо вага деталі має значення, то він вказаний у фунтах (ознайомтеся також з тим, що сказано про одиниці вимірювання в розділі 5,

8 Для тих читачів, які знайомилися з цими зразками даних у попередніх виданнях, відзначимо, що деталь РЗ передана з Риму в Осло Така ж зміна внесено на рис 45 в наступному розділі

розділ 54) Передбачається також, що кожен окремий вид деталі має тільки один колір і зберігається на складі тільки в одному місті

Рис 39 База даних постачальників і деталей (приклад значень)

TYPE S# .. TYPE NAME .. TYPE P# .. TYPE COLOR .. TYPE WEIGHT ..

; TYPE QTY ..

VAR S BASE RELATION { S# S#,

SNAME NAME, STATUS INTEGER, CITY CHAR

PRIMARY KEY { S# }

VAR P BASE RELATION

{ P# P#,

COLOR COLOR, WEIGHT WEIGHT, CITY CHAR }

VAR SP BASE RELATION

{ S# S#,

P# P#,

QTY QTY }

PNAME NAME,

PRIMARY KEY { p# }

PRIMARY KEY {    S#, P# }

FOREIGN KEY {    S# } REFERENCES S

FOREIGN KEY {    P# } REFERENCES P

Рис 310 База даних постачальників і деталей (визначення даних)

■ Мінлива відносини SP представляє поставки Вона у відомому сенсі служить для організації логічного звязку двох інших змінних відносини Наприклад, перший рядок змінної відносини SP на рис 39 повязує постачальника з номером S1 із змінної відносини S з відповідною деталлю, що має номер Р1 у змінній відносини Р, тобто представляє факт поставки деталей типу Р1 постачальником з номером S1 (а також вказує кількість деталей – 300 штук) Таким чином, кожна поставка характеризується номером постачальника (S #), номером деталі (Р #) і кількістю (QTY) Передбачається, що в один і той же час може бути виконано не більше однієї поставки для одного постачальника і одного виду деталей, тому для кожної поставки комбінація значень стовпців s # і Р # унікальною з точки зору набору поточних поставок, представлених у змінній відносини SP Зверніть увагу на те, що на рис 39 з одним з постачальників (з номером S5), не повязане ні однієї поставки

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

І ще декілька заключних зауважень

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

■ По-друге, безумовно, не було б помилкою, якби ми використовували більш описові назви змінних відносини, подібні SUPPLIERS (постав щики), PARTS (деталі) і SHIPMENTS (Поставки), замість скорочених назв S, Р і SP Більше того, на практиці рекомендується використовувати саме такі опи сательние назви Однак у нашому конкретному випадку у наступних розділах назви цих змінних відносини будуть вживатися так часто, що целесо образніше використовувати саме короткі назви

З10 РЕЗЮМЕ

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

Реляційна база даних – Це така база даних, яка сприймається її користувачами як безліч змінних (Тобто змінних відносини – Relvar), значеннями яких є відносини або, менш формально, таблиці Реляційна система – Це система, яка підтримує реляційні бази даних і операції над ними, включаючи, зокрема, операцію скороченняRESTRICT (Інакше звану вибіркою, SELECT), операцію проекції PROJECT І операцію зєднання JOIN Ці та подібні їм операції, відомі під назвою операцій реляційної алгебри9, виконуються на рівні множин Властивість замкнутості реляційних систем означає, що результат виконання операції має той же тип, що і обєкти, над якими проводилася операція (всі вони є відносинами) А це, в свою чергу, дозволяє використовувати вкладені реляційні вирази Значення змінних відносини змінюються за допомогою операцій реляційного присвоювання, причому звичні нам операції оновлення INSERT, UPDATE і DELETE можна вважати скороченою формою запису операцій реляційного присвоювання певних типів

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

Кожне відношення має заголовок і тіло заголовок – це набір пар імя_стовпця: імя_тіпа , а тіло відношення складається з набору рядків, які відповідають заголовку Тема будь-якого відношення можна розглядати як предикат, а кожен рядок в тілі відносини – як деякий справжнє висловлювання, утворене в результаті підстановки певних значень фактичних параметрів відповідного типу замість формальних параметрів цього предиката Це визначення поширюється і на основні, і на похідні відносини, а також, у певному сенсі, на змінні відносини Іншими словами, типи – це те (безліч чогось), що може стати предметом обговорення, а відносини – це те (безліч чогось), що можна сказати про цей предмет І типи, і відносини необхідні і достатні для представлення будь-яких даних (на логічному рівні)

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

9 Цей термін вже згадувався у формальному визначенні реляційної моделі в розділі 32 Але повною мірою він буде використовуватися тільки починаючи з глави 6

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

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

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

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 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>

*

*