Зміст
Введення
Глава 1. Основні поняття БД і СУБД ... ... ... ... ... ... ... ... ... .. ... ... ... .5
4 Дані та ЕОМ ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. ... .. 5
5 Архітектура СУБД ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .... ... 7
6 Моделі даних ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. ... 10
Глава 2. Інфологіческая модель даних "Сутність-зв'язок" ... ... .... ... 12
8 Основні поняття ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .12
9 Характеристика зв'язків і мова моделювання ... ... ... ... ... ... .... ... 14
10 Класифікація сутностей ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 16
11 Первинні та зовнішні ключі ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 19
12 Обмеження цілісності ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .23
Глава 3. Реляційний підхід ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .... ... 25
14 Реляційна структура даних ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 25
15 Реляційна база даних ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 28
16 Маніпулювання реляційними даними ... ... ... ... ... ... ... .... ... .30
Висновок
Список використаної літератури
Введення
Основні ідеї сучасної інформаційної технології базуються наконцепції, відповідно до якої дані повинні бути організовані в бази даних зметою адекватного відображення мінливого реального світу і задоволенняінформаційних потреб користувачів. Ці бази даних створюються іфункціонують під управлінням спеціальних програмних комплексів,званих системами управління базами даних (СУБД).
Збільшення обсягу та структурної складності збережених даних, розширеннякола користувачів інформаційних систем призвели до широкогопоширенню найбільш зручних і порівняно простих для розумінняреляційних (табличних) СУБД. Для забезпечення одночасного доступу доданими безлічі користувачів, нерідко розташованих досить далекоодин від одного і від місця зберігання баз даних, створені мережевімультіпользовательскіе версії БД заснованих на реляційної структурі. У нихтим чи іншим шляхом вирішуються специфічні проблеми паралельних процесів,цілісності (правильності) і безпеки даних, а також санкціонуваннядоступу.
Завданнями даної роботи є:
- дати основні поняття баз даних, описати архітектуру СУБД, моделі даних;
- розкрити модель сутність-зв'язок, описати характеристику зв'язків, класифікацію сутностей, структуру первинних і зовнішніх ключів, визначити поняття цілісності даних;
- описати реляційну структуру даних, реляційні бази даних і способи маніпулювання ними.
Глава 1. Основні поняття БД і СУБД
23 Дані і ЕОМ
Сприйняття реального світу можна співвіднести з послідовністю різних,хоча іноді і взаємозалежних, явищ. З давніх часів люди намагалисяописати ці явища (навіть тоді, коли не могли їх зрозуміти). Такий описназивають даними.
Традиційно фіксація даних здійснюється за допомогою конкретногозасобу спілкування (наприклад, за допомогою природної мови та зображень)на конкретному носії (наприклад, камені чи папері). Зазвичай дані (факти,явища, події, ідеї або предмети) та їх інтерпретація (семантика)фіксуються спільно, тому що природна мова досить гнучка дляпредставлення того й іншого. Прикладом може служити твердження "Вартістьавіаквитка 128 ". Тут" 128 "- дане, а" Вартість авіаквитка "- йогосемантика.
Нерідко дані та інтерпретація розділені. Наприклад, "Розкладруху літаків "може бути представлено у вигляді таблиці, у верхнійчастини якої (окремо від даних) наводиться їх інтерпретація. Такеподіл ускладнює роботу з даними (важко швидко отримати відомості знижній частині таблиці).
Застосування ЕОМ для ведення та обробки даних зазвичай призводить до щебільшого розділення даних та інтерпретації. ЕОМ має справу головним чиномз даними як такими. Більша частина інтерпретує інформації взагалі нефіксується в явній формі (ЕОМ не "знає", чи є "21.50" вартістюавіаквитка або часом вильоту). Чому ж це сталося?
Є принаймні дві історичні причини, з якихзастосування ЕОМ призвело до відділення даних від інтерпретації. По-перше, ЕОМне володіли достатніми можливостями для обробки текстівприродною мовою - основній мові інтерпретації даних. По-друге,вартість пам'яті ЕОМ була спочатку досить велика. Пам'ятьвикористовувалася для зберігання самих даних, а інтерпретація традиційнопокладалася на користувача. Користувач закладав інтерпретацію даних усвою програму, яка "знала", наприклад, що шосте вводиться значенняпов'язане з часом прибуття літака, а четверте - з часом його вильоту.
Це суттєво підвищувало роль програми, тому що поза інтерпретації даніявляють собою не більш ніж сукупність бітів на запам'ятовуючомупристрої.
Жорстка залежність між даними і використовують їх програмамистворює серйозні проблеми у веденні даних і робить використання їх меншгнучкими.
Непоодинокі випадки, коли користувачі однієї і тієї ж ЕОМ створюють івикористовують у своїх програмах різні набори даних, що містять подібнуінформацію. Іноді це пов'язано з тим, що користувач не знає (або незахотів дізнатися), що в сусідній кімнаті або за сусіднім столом сидитьспівробітник, який вже давно ввів в ЕОМ потрібні дані. Найчастіше тому, що приспільне використання одних і тих самих даних виникає маса проблем.
Розробники прикладних програм (написаних, наприклад, на Бейсіку,
Паскалі або Сі) розміщують потрібні їм дані у файлах, організовуючи їх найбільшзручним для себе чином. При цьому одні й ті самі дані можуть мати у різнихдодатках абсолютно різну організацію (різну послідовністьрозміщення в записі, різні формати одних і тих самих полів і т.п.).
Усуспільнити такі дані надзвичайно важко: наприклад, будь-яка змінаструктури запису файла, вироблене одним з розробників, призводить донеобхідність зміни іншими розробниками тих програм, яківикористовують запису цього файлу.
24 Архітектура СУБД
СКБД повинна надавати доступ до даних будь-яким користувачам, включаючиі тих, які практично не мають і (або) не хочуть мати уявлення про:
. фізичному розміщенні в пам'яті даних та їх описів;
. механізмах пошуку запитуваних даних;
. проблеми, що виникають при одночасному запиті одних і тих самих даних багатьма користувачами (прикладними програмами);
. способах забезпечення захисту даних від некоректних оновлень і (або) несанкціонованого доступу;
. підтримці баз даних в актуальному стані і безлічі інших функцій СУБД.
При виконанні основних з цих функцій СУБД повинна використовуватирізні опису даних. А як створювати ці описи?
Природно, що проект бази даних треба починати з аналізу предметноїобласті та виявлення вимог до неї окремих користувачів (співробітниківорганізації, для яких створюється база даних). Докладніше цей процесбуде розглянуто нижче, а тут відзначимо, що проектування зазвичайдоручається людині (групі осіб) - адміністратора бази даних (АБД). Їмможе бути як спеціально виділений співробітник організації, так і майбутнійкористувач бази даних, досить добре знайомий з машинною обробкоюданих.
Об'єднуючи приватні уявлення про вміст бази даних, отримані врезультаті опитування користувачів, і свої уявлення про дані, якіможуть знадобитися в майбутніх програмах, АБД спочатку створює узагальнененеформальне опис створюваної бази даних. Цей опис, виконане звикористанням природної мови, математичних формул, таблиць, графіківта інших засобів, зрозумілих усім людям, що працюють над проектуванням базиданих, називають інфологіческой моделлю даних (рис. 1).
Малюнок 1 Рівні моделей даних
Така людино-орієнтована модель повністю незалежна відфізичних параметрів середовища зберігання даних. Зрештою цим середовищемможе бути пам'ять людини, а не ЕОМ. Тому інфологіческая модель неповинна змінюватися до тих пір, поки якісь зміни в реальному світі незажадають зміни в ній деякого визначення, щоб ця модельпродовжувала відображати предметну область.
Інші моделі, показані на рис. 1, є компьютеро -орієнтованими. З їх допомогою СУБД дає можливість програмам ікористувачам одержати доступ до що зберігається даними лише за їхніми іменами, непіклуючись про фізичне розташування цих даних. Потрібні дані відшукуються
СУБД на зовнішніх запам'ятовуючих пристроях з фізичної моделі даних.
Оскільки зазначений доступ здійснюється за допомогою певної БД, томоделі мають бути написані на мові опису даних цієї СУБД. Такеопис, що створюється АБД по інфологіческой моделі даних, називаютьдаталогіческой моделлю даних.
Трирівнева архітектура (інфологіческій, даталогіческій і фізичнийрівні) дозволяє забезпечити незалежність збережених даних від використовуютьїх програм. АБД може при необхідності переписати збережені дані наінші носії інформації та (або) реорганізувати їх фізичну структуру,змінивши лише фізичну модель даних. АБД може підключити до системи будь-якийчисло нових користувачів (нових додатків), доповнивши, якщо треба,даталогіческую модель. Зазначені зміни у фізичній та даталогіческоймоделей не будуть помічені існуючими користувачами системи (виявляться
"прозорими" для них), так само як не будуть помічені і нові користувачі.
Отже, незалежність даних забезпечує можливість розвиткусистеми баз даних без руйнування існуючих додатків.
26 Моделі даних
Інфологіческая модель відображає реальний світ у деякі зрозумілілюдині концепції, повністю незалежні від параметрів середовища зберіганняданих. Існує безліч підходів до побудови таких моделей: Графовамоделі, семантичні мережі, модель "сутність-зв'язок" і т.д. Найбільшпопулярної з них виявилася модель "сутність-зв'язок".
Інфологіческая модель повинна бути відображена в компьютеро -орієнтовану даталогіческую модель, "зрозумілу" СУБД. У процесі розвиткутеорії та практичного використання баз даних, а також коштівобчислювальної техніки створювалися СКБД, що підтримують різнідаталогіческіе моделі.
Спочатку стали використовувати ієрархічні даталогіческіе моделі.
Простота організації, наявність заздалегідь заданих зв'язків між сутностями,подібність з фізичними моделями даних дозволяли домагатися прийнятноїпродуктивності ієрархічних СКБД на повільних ЕОМ з дужеобмеженими обсягами пам'яті. Але, якщо дані не мали деревоподібнійструктури, то виникала маса складностей при побудові ієрархічноїмоделі і бажанні домогтися потрібної продуктивності.
Мережеві моделі також створювалися для мало ресурсних ЕОМ. Це доситьскладні структури, що складаються з "наборів" - пойменованих дворівневихдерев. "Набори" з'єднуються за допомогою "записів-зв'язок", утворюючи ланцюжкиі т.д. При розробці мережевих моделей було вигадано безліч "маленькиххитрощів ", що дозволяють збільшити продуктивність СУБД, але істотноускладнила останні. Прикладної програміст повинен знати масу термінів,вивчити декілька внутрішніх мов СУБД, детально представляти логічнуструктуру бази даних для здійснення навігації серед різнихпримірників, наборів, записів і т.п. Один з розробників операційноїсистеми UNIX сказав "Мережна база - це самий вірний спосіб втратитидані ".
Складність практичного використання ієрархічних та мережевих СУБДзмушувала шукати інші способи представлення даних. Наприкінці 60-х роківз'явилися СКБД на основі інвертований файлів, що відрізняються простотоюорганізації та наявністю досить зручних мов маніпулювання даними.
Однак такі СКБД володіють рядом обмежень на кількість файлів длязберігання даних, кількість зв'язків між ними, довжину запису і кількість їїполів.
Фізична організація даних надає основний вплив наексплуатаційні характеристики БД. Розробники СУБД намагаються створитинайбільш продуктивні фізичні моделі даних, пропонуючи користувачамтой чи інший інструментарій для поднастройкі моделі під конкретну БД.
Різноманітність способів коригування фізичних моделей сучаснихпромислових СУБД не дозволяє розглянути їх у цьому розділі.
Глава 2. Інфологіческая модель даних "Сутність-зв'язок"
1 Основні поняття
Мета інфологіческого моделювання - забезпечення найбільш природнихдля людини способів збору і представлення тієї інформації, якупланується зберігати в створюваній базі даних. Тому інфологіческуюмодель даних намагаються будувати за аналогією з природною мовою (останнійне може бути використаний в чистому вигляді через складність комп'ютерноїобробки текстів і неоднозначності будь-якої природної мови). Основнимиконструктивними елементами інфологіческіх моделей є сутності, зв'язкиміж ними та їх властивості (атрибути).
Сутність - будь-який помітний об'єкт (об'єкт, який ми можемо відрізнитивід іншого), інформацію про яке необхідно зберігати в базі даних.
Сутностями можуть бути люди, місця, літаки, рейси, смак, колір і т.д.
Необхідно розрізняти такі поняття, як тип сутності й екземпляр сутності.
Поняття тип сутності відноситься до набору однорідних особистостей, предметів,подій або ідей, які виступають як ціле. Примірник суті відноситься доконкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, аекземпляром - Москва, Київ і т.д.
Атрибут - пойменована характеристика сутності. Його найменуванняповинно бути унікальним для конкретного типу сутності, але може бутиоднаковим для різного типу сутностей (наприклад, КОЛІР може бутивизначений для багатьох сутностей: СОБАКА, АВТОМОБИЛЬ, дим і т.д.). Атрибутивикористовуються для визначення того, яка інформація повинна бути зібрана просутності. Прикладами атрибутів для сутності АВТОМОБИЛЬ є ТИП, МАРКА,
Номерний знак, колір і т.д. Тут також існує розходження між типом іекземпляром. Тип атрибута КОЛІР має багато екземплярів чи значень:
Червоний, Синій, банановий, Біла ніч і т.д., однак кожному екземплярусутності привласнюється тільки одне значення атрибута.
Абсолютна різниця між типами сутностей і атрибутами відсутній.
Атрибут є таким тільки в зв'язку з типом сутності. В іншомуконтексті атрибут може виступати як самостійна сутність. Наприклад,для автомобільного заводу колір - це тільки атрибут продукту виробництва,а для лакофарбової фабрики колір - тип сутності.
Ключ - мінімальний набір атрибутів, за значеннями яких можнаоднозначно знайти необхідний екземпляр сутності. Мінімальність означає, щовиключення з набору будь-якого атрибута не дозволяє ідентифікувати сутністьза що залишилися. Для суті Розклад ключем є атрибут Номер_рейсаабо набір: Пункт_отправленія, Время_вилета і Пункт_назначенія (за умови,що з пункту в пункт вилітає в кожний момент часу один літак).
Зв'язок - асоціювання двох чи більш сутностей. Якби призначеннямбази даних було тільки збереження окремих, не пов'язаних між собоюданих, то її структура могла б бути дуже простий. Однак один ізосновних вимог до організації бази даних - це забезпечення можливостівідшукання одних сутностей за значеннями інших, для чого необхідновстановити між ними певні зв'язки. А так як в реальних базах данихнерідко містяться сотні або навіть тисячі сутностей, то теоретично міжними може бути встановлено більше мільйона зв'язків. Наявність такої кількостізв'язків і визначає складність інфологіческіх моделей.
2 Характеристика зв'язків і мова моделювання
При побудові інфологіческіх моделей можна використовувати мову ER -діаграм (від англ. Entity-Relationship, тобто сутність-зв'язок). У нихсутності зображуються позначеними прямокутниками, асоціації --поміченими ромбами або шестикутниками, атрибути - поміченими овалами, азв'язку між ними - ненаправленої ребрами, над якими можепроставлятися ступінь зв'язку (1 чи буква, що заміняє слово "багато") інеобхідне пояснення.
Між двома сутностей, наприклад, А і В можливі чотири види зв'язків.
Перший тип - зв'язок ОДИН-К-ОДНОМУ (1:1): у кожен момент часу кожномупредставнику (екземпляру) сутності А відповідає 1 чи 0 представниківсутності В:
Студент може не "заробити" стипендію, одержати звичайну чи одну зпідвищених стипендій.
Другий тип - зв'язок ОДИН-КО-багато (1: М): одному представнику сутності
А відповідають 0, 1 або н?? скільки представників сутності В.
Квартира може пустувати, в ній може жити один чи кілька мешканців.
Так як між двома сутностями можливі зв'язки в обох напрямках , тоіснує ще два типи зв'язку БАГАТО-К-ОДНОМУ (М: 1) і БАГАТО-КО-багато
(М: N).
Приклад. Якщо зв'язок між сутностями ЧОЛОВІКА і ЖІНКИ називається ШЛЮБ,то існує чотири возможнихпредставленія такого зв'язку:
Характер зв'язків між сутностями не обмежується перерахованими.
Існують і більш складні зв'язку:
. безліч зв'язків між тими самими сутностями
(пацієнт, маючи одного лікуючого лікаря, може мати також кількалікарів-консультантів; лікар може бути лікуючим лікарем декількох пацієнтів іможе одночасно консультувати кілька інших пацієнтів);
. тренарние зв'язку
(лікар може призначити кілька пацієнтів на кілька аналізів, аналізможе бути призначений декількома лікарями декільком пацієнтам і пацієнтможе бути призначений на кілька аналізів декількома лікарями);
. зв'язку більш високих порядків, семантика (зміст) яких іноді дуже складна.
3 Класифікація сутностей
Існують три основні класу сутностей: стрижневі, асоціативні іхарактеристичні, а також підклас асоціативних сутностей - позначення.
Стрижнева сутність (стрижень) - це незалежна сутність (кількадокладніше вона буде визначена нижче).
У розглянутих раніше прикладах стрижні - це "Студент", "Квартира",
"Чоловіки", "Лікар", "Шлюб" та інші, назви яких поміщені впрямокутники. Асоціативна сутність (асоціація) - це зв'язок виду
"багато-ко-многим" ( "-ко-многим" і т.д.) між двома або більше сутностямиабо екземплярами сутності. Асоціації розглядаються як повноправнісуті:
- вони можуть брати участь в інших асоціаціях і позначення точно таксамо, як стрижневі сутності;
- можуть мати властивості, тобто мати не тільки набір ключовихатрибутів, необхідних для вказівки зв'язків, але і будь-яке число іншихатрибутів, що характеризують зв'язок.
Характеристична сутність (характеристика) - це зв'язок виду "багато-до -однієї "або" один-до-одного "між двома сутностями (окремий випадокасоціації). Єдина мета характеристики в рамках даноїпредметної області полягає в описі чи уточнення деякої іншоїсутності. Необхідність у них виникає у зв'язку з тим, що сутностіреального світу мають іноді багатозначні властивості. Чоловік може матикілька дружин, книга - кілька характеристик перевидання (виправлене,доповнене, перероблене, ...) і т.д.
Існування характеристики повністю залежить від характеризуєтьсясуті: жінки позбавляються статусу жінок, якщо вмирає їх чоловік.
що позначає сутність або позначення - це зв'язок виду "багато-до-одного"або "один-до-одного" між двома сутностями і відрізняється від характеристикитим, що не залежить від позначається сутності.
На закінчення розглянемо приклад побудови інфологіческой моделі базиданих "Харчування", де повинна зберігатися інформація про страви, їх щоденномуспоживанні, продукти, з яких готуються ці страви, іпостачальників цих продуктів. Інформація буде використовуватися кухарем ікерівником невеликого підприємства громадського харчування, а також йоговідвідувачами.
За допомогою вказаних користувачів виділені наступні об'єкти іхарактеристики проектованої бази:
1. Страви, для опису яких потрібні дані, що входять до їх кулінарні рецепти: номер страви (наприклад, з книги кулінарних рецептів), назва страви, вид блюда (закуска, суп, гаряче і т.п.), рецепт
(технологія приготування страви), вихід (вага порції), назва, калорійність і вага кожного продукту, що входить в блюдо.
2. Для кожного постачальника продуктів: найменування, адреса, назва поставляється продукту, дата поставки і ціна на момент поставки.
3. Щоденне споживання страв (витрата): страва, кількість порцій, дата.
Аналіз об'єктів дозволяє виділити:
. стрижні Страви, Продукти та Міста;
. асоціації Склад (пов'язує Страви з Продуктами) і
Постачання (пов'язує Поставщиков з Продуктами);
. позначення Постачальники;
. характеристики Рецепти і Витрата.
Малюнок 2. Інфологіческая модель бази даних "Харчування"
4 Первинні та зовнішні ключі
Нагадаємо, що ключ або можливий ключ - це мінімальний набіратрибутів, за значеннями яких можна однозначно знайти необхідний екземплярсутності. Мінімальність означає, що виключення з набору будь-якого атрибутуне дозволяє ідентифікувати сутність по що залишилися. Кожна сутністьволодіє хоча б одним можливим ключем. Один з них приймається запервинний ключ. При виборі первинного ключа слід віддавати перевагунесоставним ключів або ключів, складеним з мінімального числаатрибутів. Недоцільно також використовувати ключі з довгими текстовимизначеннями (краще використовувати цілочисельні атрибути). Так, дляідентифікації студента можна використовувати або унікальний номер заліковоїкнижки, або набір із прізвища, імені, по батькові, номер групи і може бутидодаткових атрибутів, так як не виключена поява у групі двохстудентів (а частіше студенток) з однаковими прізвищами, іменами та по батькові.
Погано також використовувати в якості ключа не номер страви, а його назва,наприклад, "Закуска з плавлених сирків" Дружба "з шинкою і солонимогірком "або" Заєць в сметані з картопляними крокетами і салатом з червоноїкапусти ".
Не допускається, щоб первинний ключ стрижневий суті (будь-якийатрибут, який бере участь в первинному ключі) брав невизначений значення.
Інакше виникне суперечлива ситуація: з `явиться не володієіндивідуальністю, і, отже не існуючий екземпляр стрижневийсутності. З тих же причин необхідно забезпечити унікальність первинногоключа.
Тепер про зовнішні ключі:
. Якщо сутність З пов'язує суті А і В, то вона повинна включати зовнішні ключі, що відповідають первинним ключів сутностей А і В.
. Якщо сутність У позначає сутність А, то вона повинна включати зовнішній ключ, що відповідає первинному ключу суті А.
Таким чином, при розгляді проблеми вибору способу представленняасоціацій і позначень у базі даних основне питання, на який слідотримати відповідь: "Які зовнішні ключі?". І далі, для кожного зовнішньогоключа необхідно вирішити три питання:
1. Чи може цей зовнішній ключ приймати невизначені значення (NULL -значення)? Інакше кажучи, чи може існувати деякий екземпляр сутностіданого типу, для якого невідома цільова сутність, що вказується зовнішнімключем? У разі поставок це, мабуть, неможливо - поставка,здійснювана невідомим постачальником, або поставка невідомого продуктуне мають сенсу. Але у випадку з співробітниками така ситуація однак могла бмати сенс - цілком можливо, що який-небудь співробітник в даний момент незарахований взагалі ні в який відділ. Зауважимо, що відповідь на це запитання незалежить від примхи проектувальника бази даних, а визначається фактичнимчином дій, прийнятим в тій частині реального світу, яка має бутипредставлена в розглянутій базі даних. Подібні зауваження маютьвідношення і до питань, що обговорюються нижче.
2. Що має статися при спробі ВИДАЛЕННЯ цільової суті, наяку посилається зовнішній ключ? Наприклад, при видаленні постачальника, якийздійснив принаймні одну поставку. Існує три можливості:
| КАСКАДІРУЕТСЯ | Операція видалення "каскадіруется" з тим, |
| | Щоб видалити також поставки цього |
| | Постачальника. |
| ОБМЕЖУЄТЬСЯ | Видаляються лише ті постачальники, які ще не |
| | Здійснювали поставок. Інакше операція |
| | Видалення відкидається. |
| ВСТАНОВЛЮВАТИСЯ | Для всіх поставок видаляється постачальника |
| | NULL-значення зовнішній ключ встановлюється в |
| | Невизначений значення, а потім цей |
| | Постачальник видаляється. Така можливість, |
| | Звичайно, не застосовується, якщо даний зовнішній |
| | Ключ не повинен містити NULL-значень. |
3. Що має відбуватися при спробі ОНОВЛЕННЯ первинного ключацільової суті, на яку посилається деякий зовнішній ключ? Наприклад,може бути зроблена спроба оновити номер такого постачальника, дляякого є принаймні один відповідна постачання. Цей випадокдля визначеності знову розглянемо докладніше. Є ті ж триможливості, як і при видаленні:
| КАСКАДІРУЕТСЯ | Операція оновлення "каскадіруется" з тим, |
| | Щоб оновити також і зовнішній ключ |
| | Впоставках цього постачальника. |
| ОБМЕЖУЄТЬСЯ | Оновлюються первинні ключі лише тих |
| | Постачальників, які ще не здійснювали |
| | Поставок. Інакше операція оновлення |
| | Відкидається. |
| ВСТАНОВЛЮВАТИСЯ | Для всіх поставок такого постачальника |
| | NULL-значення зовнішній ключ встановлюється в |
| | Невизначений значення, а потім оновлюється |
| | Первинний ключ постачальника. Така можливість, |
| | Звичайно, не застосовується, якщо даний зовнішній |
| | Ключ не повинен містити NULL-значень. |
Таким чином, для кожного зовнішнього ключа в проекті проектувальник базиданих повинен специфікувати не тільки поле або комбінацію полів,складають цей зовнішній ключ, і цільову таблицю, яка ідентифікуєтьсяцим ключем, але також і відповіді на зазначені вище питання (три обмеження,які відносяться до цього зовнішньому ключу).
Нарешті, про характеристики - позначають сутності, існуванняяких залежить від типу що позначаються сутностей. Позначення представляєтьсязовнішнім ключем в таблиці, що відповідає цій характеристиці. Але трирозглянуті вище обмеження на зовнішній ключ для даного випадку повинніспецифікувати наступним чином:
NULL-значення не припустимі
ВИДАЛЕННЯ З (мета) КАСКАДІРУЕТСЯ
ОНОВЛЕННЯ (первинний ключ цілі) КАСКАДІРУЕТСЯ
Зазначені характеристики являють залежність по існуваннюхарактеристичних сутностей.
5 Обмеження цілісності
Цілісність (від англ. integrity - незайманість, недоторканність,схоронність, цілісність) - розуміється як правильність даних у будь -момент часу. Але ця мета може бути досягнута лише у певнихмежах: СУБД не може контролювати правильність кожного окремогозначення, що вводиться в базу даних (хоча кожне значення можна перевірити направдоподібність). Наприклад, не можна виявити, що вводиться значення 5
(що представляє номер дня тижня) в дійсності має дорівнювати 3. Зіншого боку, значення 9 явно буде помилковим і СУБД повинна йоговідкинути. Однак для цього їй слід повідомити, що номери днів тижняповинні належати набору (1,2,3,4,5,6,7).
Підтримка цілісності бази даних може розглядатися як захистданих від невірних змін або руйнувань (не плутати з незаконнимизмінами і руйнуваннями, що є проблемою безпеки).
Сучасні СУБД мають ряд засобів для забезпечення підтримки цілісності
(так само, як і засобів забезпечення підтримки безпеки).
Виділяють три групи правил цілісності:
1. Цілісність по сутностей.
2. Цілісність за посиланнями.
3. Цілісність, що визначається користувачем.
У п. 2.3 була розглянута мотивування двох правил цілісності, загальнихдля будь-яких реляційних баз даних.
1. Не допускається, щоб будь-якої атрибут, який бере участь в первинному ключі, брав невизначений значення.
2. Значення зовнішнього ключа повинно або:
- бути рівним значенню первинного ключа мети;
- бути повністю невизначеним, тобто кожне значення ознаки, що бере участь в зовнішньому ключі має бути невизначеним.
Для будь-якої конкретної бази даних існує ряд додаткових специфічних правил, які ставляться до неї однієї і визначаються розробником.
Глава 3. Реляційний підхід.
7 Реляційна структура даних
Наприкінці 60-х років з'явилися роботи, в яких обговорювалися можливостізастосування різних табличних даталогіческіх моделей даних, тобтоможливості використання звичних і природних способів поданняданих. Найбільш значною з них була стаття співробітника фірми IBM д-ра
Е. Кодда (Codd EF, A Relational Model of Data for Large Shared Data Banks.
CACM 13: 6, June 1970), де, ймовірно, вперше був застосований термін
"реляційна модель даних".
Будучи математиком за освітою Е. Коддом запропонував використовувати дляобробки даних апарат теорії множин (об'єднання, перетин,різниця, декартовій твір). Він показав, що будь-яке представленняданих зводиться до сукупності двовимірних таблиць особливого виду, відомого вматематики як відношення - relation (англ.).
Найменша одиниця даних реляційної моделі - це окреме атомарному
(нерозкладних) для цієї моделі значення даних. Так, в одній предметноїобласті прізвище, ім'я та по батькові можуть розглядатися як єдине значення,а в іншій - як три різних значення.
домен називається безліч атомарних значень одного і того ж типу.
Сенс доменів полягає в наступному. Якщо значення двох атрибутів беруться зодного і того ж домена, то, ймовірно, мають сенс порівняння, що використовуютьці два атрибути (наприклад, для організації транзитного рейсу можна датизапит "Видати рейси, у яких час вильоту з Москви до Сочі більшечасу прибуття з Архангельська до Москви "). Якщо ж значення двохатрибутів беруться з різних доменів, то їх порівняння, ймовірно, позбавленесенсу: чи варто порівнювати номер рейсу з вартістю квитка? Ставлення надоменах D1, D2, ..., Dn (не обов'язково, щоб всі вони були різні)складається із заголовка і тіла. На рис. 3 наведено приклад відносини длярозкладу руху літаків.
Заголовок складається з такого фіксованого безлічі атрибутів A1, A2,
..., An, що існує взаємно однозначна відповідність між цимиатрибутами Ai і визначальними їх доменами Di (i = 1,2 ,..., n).
Малюнок 3. Відношення з математичної точки зору (Ai - атрибути, Vi --значення атрибутів)
Тіло складається з мінливого в часі безлічі кортежів, де коженкортеж складається у свою чергу з безлічі пар атрибут-значення (Ai: Vi),
(i = 1,2 ,..., n), по одній такій парі для кожного атрибута Ai в заголовку. Длябудь-якої заданої пари атрибут-значення (Ai: Vi) Vi є значенням зєдиного домену Di, який пов'язаний з атрибутом Ai.
Ступінь відносини - це число його атрибутів. Відношення ступеня одинназивають унарний, ступеня два - бінарним, ступені три - тернарним, ..., амірою n - n-арним.
Кардинальне число або потужність відносини - це число його кортежів.
Кардинальне число відносини змінюється в часі на відміну від йогоступеня.
Оскільки ставлення - це безліч, а безлічі за визначенням немістять співпадаючих елементів, то ніякі два кортежу відносини не можутьбути дублікатами один одного в будь-який довільно-заданий момент часу.
Нехай R - відношення з атрибутами A1, A2, ..., An. Кажуть, що безлічатрибутів K = (Ai, Aj, ..., Ak) відносини R є можливим ключем R тодіі тільки тоді, коли задовольняються дві незалежних від часу умови:
1. Унікальність: у довільний заданий момент часу ніякі два різних кортежу R не мають одного і того ж значення для Ai, Aj,
..., Ak.
2. Мінімальні: ні один з атрибутів Ai, Aj, ..., Ak не може бути виключений з K без порушення унікальності.
Кожне відношення має хоча б одним можливим ключем, оскільки защонайменше комбінація всіх його атрибутів задовольняє умовіунікальності. Один з можливих ключів (вибраний довільним чином)приймається за його первинний ключ. Інші можливі ключі, якщо вониє, називаються альтернативними ключами.
Вищенаведені та деякі інші математичні поняття з'явилисятеоретичною базою для створення реляційних СУБД, розробкивідповідних мовних засобів та програмних систем, які забезпечують їхвисоку продуктивність, і створення основ теорії проектування базданих. Однак для масового користувача реляційних СУБД можна з успіхомвикористовувати неформальні еквіваленти цих понять:
Ставлення - Таблиця (іноді Файл),
Кортеж - Рядок (іноді Запис),
Атрибут - Стовпець, Поле.
3.2 Реляційна база даних
Реляційна база даних - це сукупність відносин, що містять всюінформацію, яка повинна зберігатися в БД. Однак користувачі можутьсприймати таку базу даних як сукупність таблиць.
1. Кожна таблиця складається з однотипних рядків і має унікальне ім'я.
2. Строки мають фіксоване число полів (стовпців) і значень
(множинні поля і повторювані групи неприпустимі). Інакше кажучи, вкожній позиції таотлічаются один від одного хоча бєдиним значенням,що позбліци на перетині рядка і стовпця завжди є в точності однезначення або нічого.
3. Рядки таблиці обов'язково воля однозначно ідентифікувати будь-якурядок такої таблиці.
4. Стовпцях таблиці однозначно присвоюються імена, і в кожному з нихрозміщуються однорідні значення даних (дати, прізвища, цілі числа абогрошові суми).
5. Повний інформаційний зміст бази даних представляється у вигляді явнихзначень даних і такий метод подання є єдиним. УЗокрема, не існує будь-яких спеціальних "зв'язків" або покажчиків,з'єднують одну таблицю з іншого. Так, зв'язки між рядком із БЛ = 2таблиці "Страви" на рис. 4 та рядком з ПР = 7 таблиці продукти (дляприготування Харчо потрібен Рис), видається не за допомогою покажчиків, азавдяки існуванню в таблиці "Склад" рядки, в якій номер стравидорівнює 2, а номер продукту - 7.
6. При виконанні операцій з таблицею її рядки та стовпці можнаобробляти в будь-якому порядку безвідносно до їх інформаційногозмістом. Цьому сприяє наявність імен таблиць і їх стовпців, а такожможливість виділення будь-якої їх строки або будь-якого набору рядків із зазначенимиознаками.
| Страви | Продукти | Склад |
| БЛ | ПР | БЛ |
| Блюдо | Продукт | ПР |
| Вид | Калор. | Веc (г) |
| | | |
| 1 | 1 | 1 |
| Лобіо | Квасоля | 1 |
| Закуска | 3070 | 200 |
| | | |
| 2 | 2 | 1 |
| Харчо | Цибуля | 2 |
| Суп | 450 | 40 |
| | | |
| 3 | 3 | 1 |
| Шашлик | Масло | 3 |
| Гаряче | 7420 | 30 |
| | | |
| 4 | 4 | 1 |
| Кава | Зелень | 4 |
| Десерт | 180 | 10 |
| | | |
| | 5 | 2 |
| Витрата | М'ясо | 5 |
| БЛ | 1660 | 80 |
| Порцій | | |
| Дата_Р | 6 | 2 |
| | Томати | 2 |
| 1 | 240 | 30 |
| 158 | | |
| 1/9/94 | 7 | 2 |
| | Рис | 6 |
| 2 | 3340 | 40 |
| 144 | | |
| 1/9/94 | 8 | 2 |
| | Кава | 7 |
| 3 | 2750 | 50 |
| 207 | | |
| 1/9/94 | | 2 |
| | Рецепти | 3 |
| 4 | БЛ | 15 |
| 235 | Рецепт | |
| 1/9/94 | | 2 |
| | 1 | 4 |
| ... | Ламану очищу | 15 |
| ... | | |
| ... | ... | 3 |
| | ... | 5 |
| | | 180 |
| | | |
| | | 3 |
| | | 6 |
| | | 100 |
| | | |
| | | 3 |
| | | 2 |
| | | 40 |
| | | |
| | | 3 |
| | | 4 |
| | | 20 |
| | | |
| | | 4 |
| | | 8 |
| | | 8 |
| | | |
| Постачальники | Постачання |
| ПОС | ПОС |
| Постачальник | ПР |
| Місто | Вага (кг) |
| | Ціна |
| 1 | Дата_П |
| "Полісся" | |
| Київ | 1 |
| | 6 |
| 2 | 120 |
| "Наталка" | 0.45 |
| Київ | 27/8/94 |
| | |
| 3 | 1 |
| "Хуанхе" | 3 |
| Пекін | 50 |
| | 1.82 |
| 4 | 27/8/94 |
| "Лайма" | |
| Рига | 1 |
| | 2 |
| 5 | 50 |
| "Юрмала" | 0.61 |
| Рига | 27/8/94 |
| | |
| 6 | 2 |
| "Даугава" | 2 |
| Рига | 100 |
| | 0.52 |
| | 27/8/94 |
| Міста | |
| Місто | 2 |
| Країна | 5 |
| | 100 |
| Київ | 2.18 |
| Україна | 27/8/94 |
| | |
| Пекін | 2 |
| Китай | 4 |
| | 10 |
| Рига | 0.88 |
| Латвія | 27/8/94 |
| | |
| | 3 |
| | 1 |
| | 250 |
| | 0.37 |
| | 24/8/94 |
| | |
| | 3 |
| | 7 |
| | 75 |
| | 0.44 |
| | 24/8/94 |
| | |
| | 3 |
| | 8 |
| | 40 |
| | 2.87 |
| | 24/8/94 |
| | |
| | 4 |
| | 3 |
| | 70 |
| | 1.56 |
| | 30/8/94 |
| | |
| | 5 |
| | 5 |
| | 200 |
| | 2.05 |
| | 30/8/94 |
| | |
| | 6 |
| | 6 |
| | 15 |
| | 0.99 |
| | 30/8/94 |
| | |
Малюнок 4.База даних "Харчування".
3.3 Маніпулювання реляційними даними
Прагнення до мінімізації числа таблиць для зберігання даних можепризвести до виникнення різних проблем при їх оновлення і будуть данірекомендації з розбиття деяких великих таблиць на кілька маленьких.
Але як сформувати потрібний відповідь, якщо потрібні для нього дані зберігаються врізних таблиця
