ЗАГАЛЬНЕ ВИЗНАЧЕННЯ БАЗИ ДАНИХ

12 Перманентні дані

Зазвичай дані в базі даних називають перманентними або постійно збереженими

(Хоча іноді насправді вони не залишається новою) Під словом перманентні

(Persistent) маються на увазі дані, які відрізняються від інших, більш мінливих даних, таких як проміжні результати, вхідні і вихідні дані, керуючі оператори, робочі черги, програмні керуючі блоки і взагалі всі дані, тимчасові (Transient) за своєю суттю Точніше кажучи, можна стверджувати, що дані в базі є перманентними, оскільки після того як вони були прийняті засобами СУБД для приміщення в базу, їх подальше видалення можливо лише при використанні відповідного явного запиту до бази даних, але не в результаті будь-якого побічного ефекту від виконання деякої програми Подібний погляд на поняття перманентності дозволяє точніше визначити термінбаза даних

■&nbsp&nbsp&nbsp База даних – Це деякий набір перманентних (постійно збережених) даних, що використовуються прикладними програмними системами якого підприємства

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

1 Промислова компанія

2 Банк

3 Лікарня

4 Університет

5 Міністерство

Будь-яке підприємство неминуче використовує велику кількість даних, повязаних з його діяльністю Це і є перманентні дані, про які йшла мова у наведеному вище визначенні Серед перманентних даних згаданих підприємств зазвичай зустрічаються дані, перераховані нижче

1 Дані про продукцію

2 Бухгалтерські дані

3 Дані про пацієнтів

4 Дані про студентів

5 Дані про плановану діяльність

Примітка У перших шести виданнях цієї книги замість терміна перманентні дані використовувався термін операційні дані Старий термін спочатку акцентував увагу на особливому значенні оперативних, або виробничих, додатків баз даних, тобто рутинних, часто виконуються додатків, призначених для підтримки повсякденної роботи підприємства (наприклад, додатків для підтримки операцій зарахування та списання коштів на рахунках у банківській системі) Для середовища такого роду останнім часом використовується термін оперативна обробка транзакцій (On-Line Transaction Processing-OLTP) Однак тепер бази даних все частіше застосовуються і в додатках іншого роду, наприклад, в додаткахпідтримки прийняття рішень (Decision support), і термін операційні дані для них вже не підходить На практиці сьогоднішні підприємства використовують дві окремі бази даних – з операційними даними і з даними для підтримки прийняття рішень останню зазвичай називають сховищем даних (Data warehouse) У сховищах даних часто міститься агрегована інформація (наприклад, підсумкові та середні значення), яка, в свою чергу, періодично (наприклад, раз на добу або раз на тиждень) витягується з операційної бази даних Обговорення баз даних і додатків, які служать для підтримки прийняття рішень, буде продовжено в главе22

Сутності та звязку

Розглянемо більш детально приклад деякої промислової компанії (припустимо, вона має назву KnowWare, Inc) Зазвичай подібного підприємству потрібно записувати інформацію про наявні проектах (Projects), що використовуються в цих проектах

деталях (Parts), постачальниках (Suppliers) деталей, складах (Warehouses), на яких зберігаються деталі, службовців (Employees), що працюють над проектами і тд Проекти, деталі, постачальники і тд являють собою основні сутності (entity), про які компанії KnowWare, Inc необхідно зберігати інформацію У теорії баз даних термін сутність зазвичай використовується для позначення будь-якого помітного обєкта, який може бути представлений в базі даних (рис 15)

Рис 15 Приклад діаграми сутність-звязок (ER-діаграми) для бази даних компанії KnowWare, Inc

Крім цих основних сутностей (в даному прикладі це постачальники, деталі і тд), є ще й звязку (Relationship) між ними, які обєднують ці основні сутності На рис 15 звязку представлені ромбами з сполучними лініями Наприклад, між постачальниками і деталями існує звязок SP (скорочення від Shipments / Parts): кожен постачальник поставляє певні деталі, і навпаки, кожна деталь поставляється певними постачальниками (Точніше, кожен постачальник поставляє певні види деталей, і кожен вид деталей поставляється певними постачальниками) Аналогічно, деталі використовуються в проектах, а для реалізації проектів потрібні деталі (звязок PJ – скорочення від Parts / proJects) деталі зберігаються на складах, а склади зберігають деталі (звязок WP – скорочення від Warehouses / Parts) і тд Зверніть увагу, що ці звязки – бінарні (Або двосторонні), тобто їх можна простежувати в будь-якому напрямку Зокрема, використовуючи звязок SP між постачальниками і деталями, можна відповісти на такі питання:

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

■ задана деталь, і необхідно знайти постачальників, що надають таку деталь

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

Слід зазначити, що на рис 15 наведено приклад інформаційної структури, яку прийнято називати (з очевидних причин) діаграмою сутність-звязок (Скорочено ER-діаграмою) Більш докладно такі схеми розглядаються в розділі 14

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

Хоча більшість звязків на цій діаграмі обєднують два типу сутностей (тобто вони є бінарними звязками), це зовсім не означає, що всі звязки повинні бути бінарними У прикладі є одна звязок (SPJ), що охоплює три типи сутностей (Suppliers, Parts і Projects) Це приклад тернарной (Тристоронньої) звязку Інтерпретація даної звязку така: певні постачальники поставляють певні деталі для певних проектів Зверніть особливу увагу на те, що в загальному випадку така тернарного звязок (постачальники поставляють деталі для проектів)НЕ еквівалентна простій комбінації з трьох бінарних звязків: постачальники поставляють деталі, деталі використовуються в проектах і проекти забезпечуються постачальниками. Як приклад розглянемо наведені нижче утвержденія2

а) Сміт поставляє розвідні гайкові ключі для Манхеттенського проекту.

Воно містить більше інформації, ніж наступні три окремих утвержде ня, які відносяться до тієї ж теми,

б) Сміт поставляє розвідні гайкові ключі.

в) Розвідні гайкові ключі використовуються в Манхеттенському проекті.

г) Манхеттенський проект забезпечується Смітом.

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

1 Характерною особливістю реляційних баз даних (див розділ 16) є те, що основні сутності і звязки між ними представлені за допомогою відносин (relation) або, іншими словами, за допомогою таблиць, подібних показаної в табл 11 Але слід враховувати, що термін звязок (Relationship), який використовується в поточному розділі, і термін ставлення, застосовуваний у контексті реляційних баз даних, позначають різні поняття

2 Вживаний в оригіналі англомовний термін statement має два різних значення: в даному випадку він вказує на твердження, що стосується деякого факту (яке в логіці прийнято називати висловлюванням див підрозділ Дані та моделі даних нижче в цьому розділі), а в іншому контексті може слугувати синонімом терміна command (Команда)

висновки, зроблені на підставі неповної інформації, називаються дефектом зєднання (connection trap)

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

3 Взагалі кажучи, для заданого набору типів сутностей може існувати будь-яку кількість звязків У представленій на рис 15 діаграмі присутні дві раз особисті звязку між сутностями Projects і Employees: перша (EJ) представ ляє той факт, що службовці зайняті в проектах, а друга (MJ) – що службовці управляють проектами

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

Властивості

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

У загальному випадку властивості можуть бути як простими, так і складними, причому настільки простими або складними, наскільки це буде потрібно Наприклад, властивість місцезнаходження постачальника – Відносно просте: воно складається тільки з назви міста

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

(Зокрема, в розділах 5, 6, 26 і 27), а поки що в більшості випадків (за винятком тих,

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

Дані та моделі даних

Існує й інший, не менш важливий, підхід до трактування даних і баз даних Слово дані (Data) походить від латинського слова дано (Напрошується продовження потрібно довести) Звідси випливає, що дані насправді є заданими фактами, з яких можна логічно вивести інші факти (Одержання похідних фактів із заданих – це саме те, що виконує СУБД, обслуговуючи запити користувача) Заданий факт, в свою чергу, відповідає тому, що в логіці називається істинним висловлюванням Наприклад, вислів Постачальник з номером S1 знаходиться в Лондоні цілком може виявитися істинним Висловлюванням в логіці називається таке твердження, яке може бути недвозначно визначено як істинне або помилкове Наприклад, Вільям Шекспір ​​написав Гордість і упередження – Це висловлювання (як видно, помилкове) Звідси випливає, що насправді база даних – це безліч справжніх висловлювань [ 12]

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

1 Дані представлені за допомогою рядків у табліцах3, і ці рядки можуть бути не посередньо інтерпретовані як істинні висловлювання Наприклад, рядок з номером комірки льоху (поле BIN #), рівним 72 (див табл 11), можна очевид ним чином інтерпретувати як наступне справжнє висловлювання:

“У комірці 72 знаходяться дві пляшки вина Zinfandel, випущені компанією Rafanelli в 1999 році, які будуть готові до вживання в 2007 році.

2 Для обробки рядків даних надаються оператори, які безпосередньо під витримують процес логічного виведення додаткових істинних висловлювань з існуючих висловлювань Наприклад, реляційна операція проекції (Розділ 16) дозволяє отримати з наведеного вище істинного висловлювання, крім інших істинних висловлювань, й таке:

“Деякі пляшки вина Zinfandel будуть готові до вживання в 2007 році.

(Точніше, Деякі пляшки вина Zinfandel в деякій комірці, вироблені деяким виробником в деякому році, будуть готові до вживання в 2007

році .)

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

Однак реляційна модель – не єдина можлива модель даних Існують і інші моделі (розділ 16), хоча багато з них відрізняються від реляційної моделі тільки тим, що вони певною мірою пристосовані для спеціальних випадків, а не строго засновані на формальній логіці, на відміну від реляційної моделі Виникає питання: що ж таке модель даних Це поняття можна визначити, керуючись [11] (але в іншому викладі), як показано нижче

■&nbsp Модель даних – Це абстрактне, самодостатнє, логічне визначення обєктів, операторів і інших елементів, в сукупності складових абстрактну машину доступу до даних, з якою взаємодіє користувач Згадані обєкти дозволяють моделювати структуру даних, а оператори – поведінку даних

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

реалізації

Реалізація (Implementation) заданої моделі даних – це фізичне втілення на реальній машині компонентів абстрактної машини, які в сукупності складають цю модель

Коротше кажучи, модель – це те, про що користувачі повинні знати, а реалізація-це те, чого користувачі не повинні знати

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

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

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

■ Модель даних у другому значенні подібна конкретній програмі, написаної на такій мові Інакше кажучи, модель даних в другому значенні використовує кошти, що надаються деякої моделлю (аналізованої в першому значенні) і застосовує їх для вирішення конкретної проблеми Її можна розглядати як деякий конкретний додаток деякої моделі в першому значенні

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

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

*

*