Один-багато

Записи

Запис – це екземпляр фізичного або концептуального об’єкта (або окремий елемент інформації) усередині таблиці. Якщо представити таблицю у вигляді деякої множини об’єктів (клієнтів, цибулин або постачальників), то запис являє собою елемент цієї множини. У таблиці „Клієнти” кожен запис представляє одного клієнта. Можна провести деяку аналогію між записом таблиці бази даних і рядком електронної таблиці. У термінології деяких постачальників СКБД запис – це екземпляр рядка або просто рядок.

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

2.4 Стовпці (поля)

Таблиця містить деяке число дескрипторів, кожен з яких відповідає певному атрибуту або властивості запису. Наприклад, наша таблиця цибулин складається зі стовпців „Ім’я”, „Кольори” і „Батько”. Кожен стовпець окремого запису містить деякий елемент даних (правда, самих даних в цьому елементі може не бути). В електронних таблицях застосовується та ж сама термінологія – тобто, кожен стовпець описується певним дескриптором. У деяких базах дані стовпці йменуються полями або атрибутами.

Стовпцям, як і таблицям, потрібно привласнювати осмислені імена.

2.5 Демонстраційний проект та його проблеми

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

Сорти (версія 01)

КодСорту	Ім‘я	Колір	Батько	Постачальник
	PAK’s Pride	Голубий	Gorgeous	Уманський дендропарк „Софіївка”
	Gorgeous	Жовтогарячий	Americana	Уманський дендропарк „Софіївка”
	Sylvania	Жовтий	Sebetha	ПП „Анжеліка”
	Millette	Червоний	Sebetha	ПП „Анжеліка”

Клієнти (версія 01)

КодКлієнта	НазваКлієнта	ТелефонКлієнта	ФаксКлієнта
	Магазин „Зелений Світ”	2-44-55	2-44-55 або 2-25-55
	Магазин „Флора”	(8-097) 678-01-23
	Магазин „Насіння”	2-25-55	2-25-55

Як бачимо, обидві таблиці містять запису (Сорти – 4, Клієнти – 3). Крім цього, обидві містять стовпці з дескрипторами – як, приміром, найменування сорту або телефонний номер клієнта. Зверніть увагу, що кожен елемент інформації відповідає формату стовпця, у якому розташовується. Наприклад, якщо клієнт має два телефони, ми не можемо записати їх у стовпці Клієнти.Телефон у такий спосіб:

«123-4567 або 234-5678»

Причина в тому, що кожен стовпець може вписувати тільки один елемент інформації, що відповідає загальним вимогам організації бази даних для нашого бізнесу, тоді як наведений приклад містить два елементи. Однак, якщо уважніше придивитися до наведених таблиць, тримаючи в пам‘яті застосування їх у реальному бізнесі, важко не помітити певні недоліки в їхніх структурах. Приміром, у таблиці „Сорти” чомусь немає стовпця з телефонами постачальників батьківських сортів. Додавши новий стовпець „Сорти.ТелефонПост”, одержимо таблицю наступного виду:

Сорти версія 02

КодСорту	Ім‘яСорту	КолірСорту	БатькоСорту	ПостачальникСорту	ТелефонПостСорту
	PAK’s Pride	Голубий	Gorgeous	Уманський дендропарк „Софіївка”	3-23-45
	Gorgeous	Жовтогарячий	Americana	Уманський дендропарк „Софіївка”	3-23-45
	Sylvania	Жовтий	Sebetha	ПП „Анжеліка”	5-67-89
	Millette	Червоний	Sebetha	ПП „Анжеліка”	5-67-89

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

P необхідність двічі змінювати в базі даних записи, якщо Уманський дендропарк „Софіївка” вирішить змінити номер телефону;

P подвійний запис телефонних номерів займає вдвічі більше місця на диску;

P якщо два телефонних номери компанія Уманський дендропарк „Софіївка” не збігаються, неможливо визначити, який з них правильний;

P якщо службовець при введенні імені постачальника сорту № 2 випадково введе „Софіївка”, у таблиці виявляться представлені три постачальники – Уманський дендропарк „Софіївка”, „Софіївка” й ПП „Анжеліка”, – у той час як ми маємо всього двох.

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

Ще одна проблема – пропуски даних у таблицях, на зразок відсутності номера факсу у магазину „Флора” з таблиці Клієнти. Це не порушує цілісності даних, як у випадку зі здвоєними телефонними номерами, але знижує ефективність системи, оскільки запис, що нагадує скибочку швейцарського сиру, займає на диску місце також і для тих своїх стовпців, які не містять ніяких даних. Знову ж, при користуванні таблицею із пропусками, користувачеві щораз доводиться ворожити, чи знайде він потрібні дані. При наявності множини пропусків у стовпці номера факсу, дані із цього стовпця мало придатні як для звіту, так і для зв’язку із клієнтами.

Трохи менш очевидна третя проблема, що криється в таблиці Клієнти. Що робити, якщо в магазині виявиться більше одного телефонного номера або його власник повідомить вам ще й номер свого мобільного? Можна додати пару стовпців – Клієнти.Телефон2, Клієнти. ТелефонМобільний, – але тоді утворяться пропуски в записах користувачів з одним телефонним номером.

2.6 Реляційні бази даних

Рішення всіх трьох розглянутих нами проблем було знайдено д-ром Е. Ф. Коддом у його концепції реляційних баз даних. У стислому виді його ідеї виражаються у двох правилах:

I. Дані треба, по можливості, підрозділяти на велику кількість невеликих таблиць із твердими правилами відбору даних для кожної з них.

II. Між таблицями потрібно створювати відношення, що дозволяють СКБД переходити від однієї таблиці до іншої при зборі даних для результату.

Для демонстрації, перетворимо наші таблиці ще раз.

Сорти (версія 03)

КодСорту	Ім‘яСорту	КолірСорту	БатькоСорту	КодКонтактПостСорту
	PAK’s Pride	Голубий	Gorgeous
	Gorgeous	Жовтогарячий	Americana
	Sylvania	Жовтий	Sebetha
	Millette	Червоний	Sebetha

Постачальники (версія 01)

КодПостСорту	НазваПост
	Уманський дендропарк „Софіївка”
	ПП „Анжеліка”

КонтактПостСорту (версія 01)

КодКонтактПостСорту	ТипКонтПостСорту	ТелефонПостСорту
	Голос	3-23-45
	Голос	5-67-89

Клієнти (версія 02)

КодКлієнта	НазваКлієнта
	Магазин „Зелений Світ”
	Магазин „Флора”
	Магазин „Насіння”

КонтактКлієнт (версія 01)

КодКонтКл	КодКлієнта	ТипКонтКлієнт	НомТелАбоФаксуКл
		Голос	2-44-55
		Факс	2-44-55
		Голос	(8-097) 678-01-23
		Голос	2-25-55
		Факс	2-25-55

Тепер можна встановити наступні відношення:

Яку роль грають ці відношення? Вони служать покажчиками (дороговказами) з однієї таблиці в іншу, що допомагають СКБД у пошуку потрібних даних. Наприклад, нам може знадобитися номер голосового зв’язку постачальника 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) зменшення числа стовпців у таблиці.

Реальні рішення цих завдань породили терміни, що описують два види відношень між таблицями: «один-багато» і «один-один».

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

У більшості випадків відношення «один-багато» установлюється для усунення дублювання й пропусків даних. Сторона «багато» може розростатися або звужуватися залежно від обсягу даних, ніяк не торкаючись числа записів з боку «один». Втім, ми це обговорили досить докладно, коли шукали рішення проблем бази даних тюльпанового бізнесу.

Дата добавления: 2014-12-07