Поле або набір полів, однозначно ідентифікує запис.
Зовнішній ключ.
Набір атрибутів однієї таблиці, що є ключем іншої (або тієї ж самої) таблиці; використовується для визначення логічних зв'язків між таблицями. Атрибути зовнішнього ключа не обов'язково повинні мати ті ж імена, що й атрибути ключа, яким вони відповідають.
Рекурсивний зовнішній ключ.
Зовнішній ключ, посилається на свою власну реляційну таблицю.
Батьківська реляція (Таблиця)
Таблиця, поля якої входять в іншу таблицю.
Дочірня реляція (Таблиця)
Таблиця, поля якої використовують інформацію з полів іншої таблиці, що є по відношенню до даної батьківської.
Ставлення один-до-одного
Коли одного запису в батьківської таблиці відповідає один запис у дочірньої таблиці
Ставлення один-ко-многим
Коли одного запису в батьківської таблиці відповідає кілька записів у дочірньої таблиці
Ставлення багато-до-багатьох
Коли багатьом записам у батьківської таблиці відповідають кілька записів у дочірньої таблиці
Рекурсивне відношення.
Ставлення, що зв'язує об'єктне безліч з ним самим.
View (Представлення)
Інформаційна одиниця РБД (за структурою аналогічна таблиці), записи якої сформовані в результаті виконання запитів до інших таблиць.
Посилальна целлостность
Адекватне відтворення записів у посилальних полях таблиць.
Тригер
Засіб забезпечення посилальної цілісності на основі механізму каскадних змін.
Індекс
Механізми швидкого доступу до зберігаються в таблицях даних шляхом їх попереднього сортування.
Транзакція
Такий вплив на СУБД, яке переводить її з одного цілісного стану в інший.
Обмежувальні умови, підтримують цілісність бази даних.
Як випливає з визначення посилальної цілісності при наявності в посилальних полях двох таблиць різного представлення даних відбувається порушення посилальної цілісності, таке порушення робить інформацію в базі даних недостовірною. Щоб запобігти втраті посилальної цілісності, використовується механізм каскадних змін (який найчастіше реалізується спеціальними об'єктами СУБД - Тригерами). Даний механізм складається в наступній послідовності дій:
В· при зміні поля зв'язку в записі батьківської таблиці слід синхронно змінити значення полів зв'язку у відповідних записах дочірньої таблиці;
В· при видаленні запису в батьківській таблиці слід видалити відповідні записи та в дочірній таблиці.
Процес нормалізації
Нормалізація - Процес приведення реляційних таблиць до стандартного вигляду. У базі даних можуть присутні такі проблеми як:
В· Надмірність даних. Повторення даних в базі даних.
В· Аномалія поновлення. Суперечливість даних, викликана їх надмірністю та частковим оновленням.
В· Аномалія видалення. Ненавмисна втрата даних, викликана видаленням інших даних.
В· Аномалія введення. Неможливість ввести дані в таблицю, викликана відсутністю інших даних.
Для вирішення цих проблем застосовують розбиття таблиць - поділ таблиці на кілька таблиць. Для того щоб це зробити користуються нормальними формами або правилами структурування таблиць.
Перша
Реляційна В
Друга
Реляційна Таким
Функціональна залежність. Значення
Більш
Атрибут
Процес
1. Створюється
2.
3. Якщо
4. Якщо
Реляційна
Критерій атрибутів.
1.
2. Ключовий
Таким
Четверта
Таблиця
П'ята
П'ята залежностями.
Таблиця
В
Рис. 2.
1
2
3
4
5
6
7
1
2
3
4
5
6
7
1
2
3
пацієнта
4
5
6
7
8
9
10
Представлена
Перед Уважно
Для таблиць:
Наприклад,bsp;
CSL_ <ім'я модуля> _ <ім'я таблиці>.
Для стовпців:
<Псевдонім таблиці> _ <ім'я стовпця>.
Наприклад, як показано на рис.2. Реєстраційний номер пацієнта зберігатися в полі PT_REG_NUMBER, таблиці PATIENTS, що має псевдонім PT.
Звичайно, використання цих не хитрих правил не є обов'язковим, але дозволяє значно полегшити читаність розробленої інформаційної структуру. Припустіть, як було б все, якби поля таблиць називалися P111, P112 і т.п., а адже такі речі зустрічаються практично дуже часто, наприклад в FoxPro 2.6.
Перейдемо до розгляду питань стандартизації та забезпечення посилальної цілісності реляційних таблиць.
Перетворення відносин
Поля таблиць можуть перебувати між собою в одному з наступних відносин:
один-до-одного, один-до-багатьох, багато-до-багатьох і рекурсивних, визначення яких наведені в табл.1. Розглянемо перетворення відносин на прикладі АІС "ДОКТОР-ПАЦІЄНТ" (рис.2).
Ставлення один-до-одного являє собою таке ставлення, при якому кожного запису в таблиці А відповідає єдиний запис у таблиці В (рис.1). Застосування такого типу відносин зустрічається вкрай рідко і призначене в основному для функціонального поділу інформації на кілька таблиць, тобто коли не хочуть, щоб таблиця БД "розпухає" від другорядної інформації. На рис.10 представлено, як використовуючи відношення один-до-одного таблиця PATIENTS перетворена в дві таблиці: PATIENTS_REG і PATIENTS_KART (на малюнку показані тільки основні атрибути таблиць). Також необхідно брати до уваги, що БД використовують такі відносини не можуть бути повністю нормалізовані.
Рис.1. Відношення один до одному.
Ставлення один-ко-многим можна без перебільшення назвати основним типом відносин що використовується при проектуванні сучасних БД, так як дозволяє представляти ієрархічні структури даних. Під даним відношення розуміється таке ставлення, коли одного запису в батьківській таблиці відповідають записи в дочірній таблиці (причому число відповідних записів виражається рядом натуральних чисел 0,1,2,: N і т.п.) (рис.2). Відносини один-ко-многим можуть бути жорсткими і нежорсткими. Для жорстких відносин повинно виконувати вимогу, що кожного запису в батьківській таблиці повинна від...
