Що таке база данихНад визначенням цього поняття ламали голови багато спеціалістів (і навіть деякі філософи). Мабуть, для початку підійде наступне, досить ємне визначення: Організована множина інформації певного призначення. Зверніть увагу: у визначенні немає навіть натяку на комп’ютер. Приміром, телефонна книга – прекрасний приклад бази даних Крім того, цінність баз даних залежить не від самої інформації, а, скоріше, від її організації. Інформація про телефонні номера, записана на аркушах паперу, що розкидані по кабінеті, не представляє базу даних і є менш цінною за телефонний довідник. 2.1 Демонстраційний проект – тюльпанний бізнес Спробуємо проаналізувати визначення на наступному прикладі. Припустимо, ми займаємося вирощуванням тюльпанів і зберігаємо наступну інформацію: P кольори тюльпана сорту № 1; P кольори тюльпана сорту № 2; P ідентифікаційний номер батьків тюльпана сорту № 3; P адреса квіткаря, що продав нам сорт тюльпана № 3. Щоб ця інформація перетворилася в базу даних, її потрібно організувати. Ми повинні згрупувати окремо всі дані про сорт № 1 і сорті № 2. Нарешті, потрібно відобразити якимсь чином відношення всіх цих відомостей до бізнесу, пов’язаному з вирощуванням тюльпанів. Протягом цієї теми нам доведеться часто приймати рішення. У цей момент нам потрібно вирішити, які елементи інформації включати в базу даних – тобто, які з них можна віднести до «певного призначення». Так, кожен з перерахованих вище пунктів можна розглядати як частину нашого наміру вирощувати й продавати цибулини тюльпанів, але до якого розряду віднести телефонний номер місцевої пожежної команди? Пожежні – це не клієнти, не постачальники, не наймані робітники – для них просто немає місця в базі даних. З іншого боку, якщо база даних має функцію друку телефонних довідників, у цьому списку повинні бути номера, по яких доводиться дзвонити в різних позаштатних ситуаціях, і, отже, номер пожежної служби – приміром, у розділі «911». Вище сказане і є прикладом прийняття рішення. База даних – не єдиний засіб організації інформації. Із цим прекрасно справляються електронні таблиці, але в цьому випадку доводиться миритися із обмеженнями обсягу – як теоретичними, так і практичними. До того ж незрозуміло, як можна розібратися з виведеною на екран таблицею, якщо вона містить кілька тисяч одиниць інформації. Таблиці текстових процесорів також можуть уміщати багато інформації, але вони обмежені в обсязі ще більше. В цілому, до організації бази даних спонукують наступні дві ситуації: обсяг збереженої інформації перевищує кілька тисяч одиниць, кожна з яких підрозділяється на кілька десятків більше дрібних елементів; і неможливо обмежитися найпростішими відношеннями між елементами інформації. Розглянемо приклад застосування електронних таблиць і баз даних для нашого тюльпанового бізнесу. Припустимо, спочатку ми вирощували щовесни партію цибулин тюльпана одного сорту й продавали її одному покупцеві, що представляє мережу квіткових магазинів. У цій ситуації ми робили щороку одну або кілька угод, тому для зберігання інформації про угоди за кілька років цілком достатньо було однієї електронної таблиці, яку було неважко скласти. Однак компанія розвивалася успішно й незабаром ви стали вирощувати багато сортів тюльпанів, що було спричинено зростанням числа клієнтів. Обсяг збереженої інформації зріс і став перевищувати можливості електронної таблиці. До того ж виникли деякі непрості відношення – наприклад, між замовленням, безліччю коробок різних цибулин у ньому й інформацією про клієнта, від якого надійшло це замовлення. Для підтримки даних не тільки великого обсягу, але також великої складності, потрібна вже база даних. Однак розуміння цих принципів недостатньо для конструювання гарної бази даних. У декількох наступних темах ми обговоримо основні організаційні структури сучасних баз даних – таблиці, записи й стовпці. 2.2 Таблиці Таблиці – це організаційні форми зберігання інформації, оптимізовані для використання в комп’ютерах. Інформація рідко записується в наочному для людини форматі. Скоріше формат вибирається з міркувань швидкості й надійності апаратного забезпечення й СКБД. Далі до таблиць застосовуються інші засоби баз даних – наприклад, SQL-оператори, – які збирають і переводять інформацію в більш підходящу для людського сприйняття форму. Потрібно пам‘ятати, що таблиця в СКБД не файл. Вірніше буде представити SQL-таблицю як деяка підмножина інформації, що зберігається в базі даних. Ще одна особливість, про яку потрібно завжди пам’ятати: таблиця в реляційній базі даних не зобов’язана зберігатися в якомусь певному порядку. Звичайно зберігається порядок, у якому інформація записувалася в базу даних, або ж він установлюється в результаті застосування певних оптимізаційних схем СКБД. Зчитувані з бази дані повертаються в порядку, що зазначений у запиті; при цьому, однак, таблиці бази даних не піддаються ніякій реорганізації. Імена таблиць – як правило, іменники в множині. Для нашого тюльпанового бізнесу знадобляться, імовірно, таблиці з іменами: Цибулини, Клієнти, Постачальники і Замовлення – короткі й виразні імена таблиць роблять більш наочними SQL-оператори, у яких ці таблиці згадуються. Звичайно, СКБД немає ніякої справи до того, наскільки вдало обране ім’я тої або іншої таблиці (аби тільки воно задовольняло деяким формальним умовам), однак складання SQL-операторів з осмисленими іменами об’єктів набагато зручніше. Записи Запис – це екземпляр фізичного або концептуального об’єкта (або окремий елемент інформації) усередині таблиці. Якщо представити таблицю у вигляді деякої множини об’єктів (клієнтів, цибулин або постачальників), то запис являє собою елемент цієї множини. У таблиці „Клієнти” кожен запис представляє одного клієнта. Можна провести деяку аналогію між записом таблиці бази даних і рядком електронної таблиці. У термінології деяких постачальників СКБД запис – це екземпляр рядка або просто рядок. Записам не привласнюються імена, як таблицям; проте, існує необхідність якось ідентифікувати їх. Це ми обговоримо далі в цій же темі, зараз же зауважимо тільки, що будь-який запис можна виділити із загального числа по одному або сполученню декількох його атрибутів. 2.4 Стовпці (поля) Таблиця містить деяке число дескрипторів, кожен з яких відповідає певному атрибуту або властивості запису. Наприклад, наша таблиця цибулин складається зі стовпців „Ім’я”, „Кольори” і „Батько”. Кожен стовпець окремого запису містить деякий елемент даних (правда, самих даних в цьому елементі може не бути). В електронних таблицях застосовується та ж сама термінологія – тобто, кожен стовпець описується певним дескриптором. У деяких базах дані стовпці йменуються полями або атрибутами. Стовпцям, як і таблицям, потрібно привласнювати осмислені імена. 2.5 Демонстраційний проект та його проблеми Проілюструємо викладені вище принципи простим прикладом (який породжує проблеми, вирішення яких ми відкладемо на якийсь час). Розглянемо дві таблиці з бази даних нашого тюльпанового бізнесу: Сорти (версія 01)
Клієнти (версія 01)
Як бачимо, обидві таблиці містять запису (Сорти – 4, Клієнти – 3). Крім цього, обидві містять стовпці з дескрипторами – як, приміром, найменування сорту або телефонний номер клієнта. Зверніть увагу, що кожен елемент інформації відповідає формату стовпця, у якому розташовується. Наприклад, якщо клієнт має два телефони, ми не можемо записати їх у стовпці Клієнти.Телефон у такий спосіб: «123-4567 або 234-5678» Причина в тому, що кожен стовпець може вписувати тільки один елемент інформації, що відповідає загальним вимогам організації бази даних для нашого бізнесу, тоді як наведений приклад містить два елементи. Однак, якщо уважніше придивитися до наведених таблиць, тримаючи в пам‘яті застосування їх у реальному бізнесі, важко не помітити певні недоліки в їхніх структурах. Приміром, у таблиці „Сорти” чомусь немає стовпця з телефонами постачальників батьківських сортів. Додавши новий стовпець „Сорти.ТелефонПост”, одержимо таблицю наступного виду: Сорти версія 02
Однак тепер ми маємо ситуацію дублювання даних, оскільки телефони постачальників виявляються представленими в базі даних двічі. Це породжує ряд проблем, серед яких: P необхідність двічі змінювати в базі даних записи, якщо Уманський дендропарк „Софіївка” вирішить змінити номер телефону; P подвійний запис телефонних номерів займає вдвічі більше місця на диску; P якщо два телефонних номери компанія Уманський дендропарк „Софіївка” не збігаються, неможливо визначити, який з них правильний; P якщо службовець при введенні імені постачальника сорту № 2 випадково введе „Софіївка”, у таблиці виявляться представлені три постачальники – Уманський дендропарк „Софіївка”, „Софіївка” й ПП „Анжеліка”, – у той час як ми маємо всього двох. Неважко представити, які труднощі виникнуть із ростом числа записів до декількох сотень або тисяч. Ще одна проблема – пропуски даних у таблицях, на зразок відсутності номера факсу у магазину „Флора” з таблиці Клієнти. Це не порушує цілісності даних, як у випадку зі здвоєними телефонними номерами, але знижує ефективність системи, оскільки запис, що нагадує скибочку швейцарського сиру, займає на диску місце також і для тих своїх стовпців, які не містять ніяких даних. Знову ж, при користуванні таблицею із пропусками, користувачеві щораз доводиться ворожити, чи знайде він потрібні дані. При наявності множини пропусків у стовпці номера факсу, дані із цього стовпця мало придатні як для звіту, так і для зв’язку із клієнтами. Трохи менш очевидна третя проблема, що криється в таблиці Клієнти. Що робити, якщо в магазині виявиться більше одного телефонного номера або його власник повідомить вам ще й номер свого мобільного? Можна додати пару стовпців – Клієнти.Телефон2, Клієнти. ТелефонМобільний, – але тоді утворяться пропуски в записах користувачів з одним телефонним номером. 2.6 Реляційні бази даних Рішення всіх трьох розглянутих нами проблем було знайдено д-ром Е. Ф. Коддом у його концепції реляційних баз даних. У стислому виді його ідеї виражаються у двох правилах: I. Дані треба, по можливості, підрозділяти на велику кількість невеликих таблиць із твердими правилами відбору даних для кожної з них. II. Між таблицями потрібно створювати відношення, що дозволяють СКБД переходити від однієї таблиці до іншої при зборі даних для результату. Для демонстрації, перетворимо наші таблиці ще раз. Сорти (версія 03)
Постачальники (версія 01)
КонтактПостСорту (версія 01)
Клієнти (версія 02)
КонтактКлієнт (версія 01)
Тепер можна встановити наступні відношення:
Яку роль грають ці відношення? Вони служать покажчиками (дороговказами) з однієї таблиці в іншу, що допомагають СКБД у пошуку потрібних даних. Наприклад, нам може знадобитися номер голосового зв’язку постачальника Sylvania. Указуємо запис „Sylvania” таблиці „Сорти”, з якої СКБД визначає значення Сорти.КодКонтПостСорту = 2. Дотримуючись відношення, СКБД звертається до таблиці „КонтактПостСорту”, і знаходить запис у стовпці КонактПостСорту.КодКонтПостСорту якої записане значення 2. Тепер залишається перейти до стовпця ТелефонПостСорту і повідомити, що записаний там номер телефону дорівнює 5-67-89. Аналогічно ми можемо дізнатись назву постачальника цього сорту, просто для цього система буде змушена звернутись ще й до таблиці „Постачальники” до поля НазваПост. 2.7 Чи позбулися ми проблем? Проблема номер один полягала в дублюванні телефонних номерів постачальників і була вирішена перерозподілом даних в окремі таблиці таким чином, щоб кожен телефонний номер міг бути зазначений тільки один раз. У таблиці Сорти залишився тільки стовпець ідентифікаторів постачальників КодКонтПостСорт. Якщо знадобляться номери телефонів обох постачальників – Уманського дендропарку „Софіївка” й приватного підприємства „Анжеліка”, СКБД може виконати пошук двічі. Якщо знадобиться поміняти один з номерів, досить зробити це один раз. Таким чином, ми позбулися проблем, породжуваних дублюванням даних. i Якщо ще раз глянути на таблицю „КонтактКлієнт”, неважко помітити, що ми як і раніше маємо дублювання даних, оскільки в стовпці типу контакту наявні численні значення «Голос» й «Факс». У більшості випадків ця ситуація не викличе утруднень, однак існує ймовірність того, що службовець при введенні даних замість стандартного значення «Голос» уведе «Телефон», «Тел.» або інший еквівалент. Природно, такі значення не будуть розпізнані далі. Проблема вирішується створенням таблиці з одним стовпцем і дозволом записувати в стовпець тип контакту значення тільки із цієї таблиці. Друга й третя проблеми пов’язані з різним числом телефонних номерів у клієнтів, включаючи повну їхню відсутність. Ми видалили з таблиці „Клієнти” стовпці з номерами телефонів і факсів, а в новій таблиці „КонтактКлієнт” склали пари значень стовпця КодКлієнта і відповідних номерів телефонів або факсів. І в цьому випадку СКБД використає відношення для повернення потрібної інформації. Виділивши телефонні номери в окрему таблицю „КонтактКлієнт”, ми можемо тепер визначати кожному клієнтові будь-яке число номерів телефонів або факсів. Перш ніж продовжити, дозвольте зробити кілька важливих зауважень щодо викладених вище методів установки відношень між таблицями, які ми будемо розвивати в наступних темах. Теорія реляційних баз даних і мова SQL розвиваються рука об руку. І SQL має деякі додаткові засоби, що дозволяють прискорити зіставлення один одному записів, між якими встановлені відношення. Найцінніший із цих засобів – індекс, – ми будемо розглядати далі. Індекс дозволяє коротко знаходити запис за значенням в одному з її стовпців. Якщо знову звернутися до розглянутого вище прикладам, то установка індексу на стовпець КодКлієнта дозволить коротко знаходити запис потрібного клієнта. Інші засоби SQL, що забезпечують безперебійну роботу механізму зіставлення записів один одному, ми розглянемо далі. 3 Зіставлення записів – роль ключів Отже, ми знаємо, що СКБД може встановлювати відношення між двома таблицями й виконувати пошук для зіставлення один одному записів у цих таблицях. Це дає можливість усувати дублювання й, одночасно, пропуски даних. Розглянемо докладніше конструювання таблиць реляційних бази даних. Потрібно мати у виді, що СКБД не відслідковує записів, які потрібно зіставити один одному. Не існує ніяких метаданих, які вказували б, що, приміром, запис номер 45 в одній таблиці зіставляється із записом номер 22 в іншій. Зіставлення здійснюються тільки при виконанні запиту, на основі фактичних даних, записаних у стовпцях, тому потрібна перевірка наявності як самих стовпців, так і даних у них, які забезпечують зіставлення єдиним чином. Для цього довелося ввести поняття ключів. i Які дані потрібно групувати в таблиці? Конструктори баз даних при рішенні цього питання розділилися на дві школи; «об’єднувачів» й «роздільників». 3.1 Первинні ключі Первинний ключ – це стовпець або кілька стовпців, які ідентифікують кожен запис у таблиці. Наприклад, у таблиці громадян України як первинний ключ можна використати стовпець ідентифікаційних кодів. Оскільки не існує двох громадян України, у яких би ці номери збігалися, дані цього стовпця ідентифікують кожен запис єдиним чином. Однак знайти подібну унікальну інформацію вдається далеко не завжди. Приміром, прізвища не мають цю властивість, оскільки серед декількох тисяч українців напевно найдеться декілька Петренків. У цій ситуації можна створити додатковий стовпець, що містить деякий штучний унікальний ідентифікатор, який був би генерований під час створення кожного нового запису. Якщо процедура визначення цього ідентифікатора буде працювати надійно, ми можемо використати новий стовпець як первинний ключ. Для такого стовпця підійде ім’я на зразок КодСорту або КодКонтактКлієнт. Методи генерування унікальних значень ми розглянемо далі. Ключі нічим не відрізняються від інших полів запису (на відміну від ключового гравця в команді), але вони слугують „ключами” для співставлення записів. 3.2 Зовнішні ключі Зовнішній ключ – це стовпець, що містить дані, які служать покажчиками на дані первинного ключа в іншій таблиці. Таким чином, щоб зв’язати запису таблиці „Замовлення” із записами таблиці „Клієнти”, треба встановити в першій з них зовнішній ключ, що містить правильні значення „КодКлієнта”. Тоді СКБД зможе прочитати дані в стовпці „КодКлієнта” таблиці „Замовлення” й, скориставшись первинним ключем таблиці „КодКлієнта” таблиці „Клієнти”, знайти в цій таблиці єдиний запис, що відповідає прочитаним даним. Якщо скористатися терміном «один-багато», то зовнішній ключ виявляється представлений на множинній стороні відношення. Зверніть увагу на розходження в правилах визначення первинного й зовнішнього ключів. Первинні ключі містять унікальні (неповторювані) значення; значення зовнішнього ключа можуть мати «двійників» у первинному ключі іншої таблиці. Значення вторинного ключа, як правило, повторюються від рядка до рядка, оскільки покажчик на унікальне значення первинного ключа (наприклад, у таблиці „Клієнти”) може вказувати на більш ніж один запис (в таблиці „Замовлення”). 3.3 Як діють ключі Застосуємо викладені вище ідеї до нашого приклада з тюльпановим бізнесом. У таблицях Клієнти й КонтактКлієнт нам знадобляться ключі, по яких СКБД буде зіставляти записи двох таблиць. У таблиці Клієнти первинним ключем буде стовпець КодКлієнта, у якому зберігаються значення, унікальні для кожного клієнта; зовнішній ключ у таблиці КонтактКлієнт – стовпець КодКлієнт, кожному значенню яких зіставляється один й тільки один запис таблиці Клієнти. Отже, ми розглянули принцип дії ключів, і тепер самий час зробити два важливих зауваження. Перше: щоб відношення діяло бездоганно, дані в первинному й зовнішньому ключах повинні бути максимально подібні один одному; типи даних, їхній розмір, що накладають обмеження повинні бути, по можливості, однакові в обох стовпцях, інакше СКБД буде виконувати перетворення, які не завжди можуть завершуватися успішно. Друге: у деяких розвинених проектах для оптимізації характеристик намагаються уникати застосування, в якості первинних ключів, стовпців послідовної нумерації, а утворюють ключ сполученням значень декількох стовпців. У цьому випадку первинний ключ уже не є стовпцем, але деяким загальним поданням декількох стовпців, сполучення значень у які ідентифікують єдиним чином кожен запис. Підсумуємо сказане, перелічивши найбільш важливі моменти. P Ключі використовуються для зіставлення записів двох зв’язаних таблиць. P Ключ представляється одним або декількома полями. Відношення не описуються ніякими метаданими. P Кожне значення первинного ключа унікально. P Зовнішній ключ містить значення, кожне з яких збігається зі значенням первинного ключа в іншій таблиці. P Як правило, у відношенні «один-багато» сторона «один» відповідає первинному ключу, сторона «багато» – зовнішньому. P Коли потрібно виконати зіставлення, СКБД зчитує значення зовнішнього ключа й по ньому знаходить в іншій таблиці запис, що містить таке ж значення первинного ключа. Багато студентів мають досвід роботи з великими наборами даних і знають, як легко можна зштовхнутися в таких наборах із проблемами й невідповідностями. І вони задають питання. Яким чином можна забезпечити унікальність значень первинного ключа й наявність у зовнішньому ключі іншої таблиці тільки значень, що збігаються зі значеннями первинного ключа? Що трапиться, приміром, після видалення з таблиці одного із клієнтів? Тоді одному із записів у таблиці „КонтактКлієнт” не буде що зіставити. Ми розглянемо деякі способи дозволу подібних проблем далі. Більшість постачальників баз даних пропонують засоби виявлення й автоматичного виправлення невідповідності значень ключів. 4 Альтернативний спосіб опису відношень Розбивка (нормалізація) таблиць переслідує найчастіше дві мети: 1) зменшення дублювання й пропусків даних; 2) зменшення числа стовпців у таблиці. Реальні рішення цих завдань породили терміни, що описують два види відношень між таблицями: «один-багато» і «один-один».
|
