Зміст

1. Нормальні форми відносин

1.1. Етапи розробки бази даних

1.2. Критерії оцінки якості логічної моделі даних

1.3 Адекватність бази даних предметної області

1.4 Легкість розробки й супроводу бази даних

1.5 Швидкість операцій відновлення даних (вставка, відновлення, видалення)

1.6 Швидкість операцій вибірки даних

1.7 Основний приклад

1.8 1НФ (Перша Нормальна Форма)

1.8.1 Аномалії

1.8.1.1 Аномалії відновлення

1.8.1.2 Аномалії вставки (INSERT)

1.8.1.3 Аномалії відновлення (UPDATE)

1.8.1.4 Аномалії видалення (DELETE)

1.8.2 Функціональні залежності

1.8.2.1 Визначення функціональної залежності

1.8.2.2 Функціональні залежності відносин і математичне поняття функціональної залежності

1.9 2НФ (Друга Нормальна Форма)

1.9.1 Аналіз декомпозированных відносин

1.9.2 Аномалії

1.9.2.1 Аномалії, що залишилися, вставки (INSERT)

1.9.2.2 Аномалії, що залишилися, відновлення (UPDATE)

1.9.2.3 Аномалії, що залишилися, видалення (DELETE)

1.10 3НФ (Третя Нормальна Форма)

1.10.1 Алгоритм нормалізації (приведення до 3НФ)

1.11 Аналіз критеріїв для нормалізованих і ненормалізованих моделей даних

1.12 Порівняння нормалізованих і ненормалізованих моделейОшибка! Закладка не определена.

1.13 OLTP й OLAP-системи

1.14 Коректність процедури нормалізації - декомпозиція без втрат. Теорема Хеза

2. Транзакції й цілісність баз даних

2.1 Пример порушення цілісності бази

2.2 Поняття транзакції

2.3 Обмеження цілісності

2.4 Докласифікация обмежень цілісності

2.4.1 Класифікація обмежень цілісності по способах реалізації

2.4.2 Класифікація обмежень цілісності за часом перевірки

2.4.2 Класифікація обмежень цілісності по області дії

2.5 Обмеження домена

2.6 Обмеження атрибута

2.7 Ограничения кортежу

2.8 Ограничения відносини

2.9 Обмеження бази даних

2.10 Реалізація декларативних обмежень цілісності засобами SQLОшибка! Закладка не определена.

2.11 Загальні принципи реалізації обмежень засобами SQL

2.12 Синтаксис обмежень стандарту SQL

2.13 Синтаксис операторів SQL, що використають обмеження

Висновок

2.11 Синтаксис обмежень стандарту SQL

Поняття обмеження використається в багатьох операторах визначення даних (DDL).

Обмеження check::= CHECK Предикат

Обмеження таблиці ::=[CONSTRAINT Ім'я обмеження] { {PRIMARY KEY (Ім'я стовпця.,..)} | {UNIQUE (Ім'я стовпця.,..)} | {FOREIGN KEY (Ім'я стовпця.,..) REFERENCES Ім'я таблиці [(Ім'я стовпця.,..)] [Посилальна специфікація]} | { Обмеження check } } [Атрибути обмеження]

Обмеження стовпця::=[CONSTRAINT Ім'я обмеження] { {NOT NULL} | {PRIMARY KEY} | {UNIQUE} | {REFERENCES Ім'я таблиці [(Ім'я стовпця)] [Посилальна специфікація]} | { Обмеження check } } [Атрибути обмеження]

Посилальна специфікація::=[MATCH {FULL | PARTIAL}] [ON UPDATE {CASCADE | SET NULL | SET DEFAULT | NO ACTION}] [ON DELETE {CASCADE | SET NULL | SET DEFAULT | NO ACTION}]

Атрибути обмеження::={DEFERRABLE [INITIALLY DEFERRED | INITIALLY IMMEDIATE]} | {NOT DEFERRABLE}

Обмеження типу CHECK. Обмеження типу CHECK містить предикат, що може приймати значення TRUE, FALSE й UNKNOWN (NULL). Приклади предикатів різного видунаведені в главі 5. Обмеження типу CHECK може бути використане як частина опису домена, таблиці, стовпця таблиці або окремого обмеження цілісності - ASSERTION. Обмеження вважаєтьсяпорушеним, якщо предикат обмеження приймає значення FALSE.

Приклад 15. Приклад обмеження типу CHECK:

CHECK (Salespeaple.Salary IS NOT NULL) OR (Salespeaple.Commission IS NOT NULL)

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

Приклад 16. Ще приклад обмеження типу CHECK:

CHECK EXIST(SELECT * FROM Salespeaple)

Дане обмеження затверджує, що список продавців не може бути порожнім.

Обмеження таблиці й обмеження стовпця. Обмеження таблиці й обмеження стовпця таблиці входять як частина опису відповідно таблиці або стовпця таблиці. Обмеження таблиці може ставитися до декількохстовпців таблиці. Обмеження стовпцяставиться тільки до одного стовпця таблиці. Будь-яке обмеження стовпця можна описати як обмеження таблиці, але не навпаки.

Обмеження таблиці або стовпця можуть мати найменування, за допомогою якого надалі можна скасовувати це обмеження або міняти час його перевірки.

Обмеження PRIMARY KEY. Обмеження PRIMARY KEY для таблиці або стовпця означає, що група з одного або декількохстовпців утворять потенційний ключ таблиці. Це означає, що комбінація значень в PRIMARY KEY повинна бути унікальної для кожного рядка таблиці. Дубльовані значення або значення, що містять NULL, будуть відкинуті. Для однієї таблиці може бути визначене єдине обмеження PRIMARY KEY. У термінах стандарту SQL це називається первинним ключем таблиці.

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

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

Обмеження FOREIGN KEY й REFERENCES. Обмеження FOREIGN KEY... REFERENCES... для таблиці й обмеження REFERENCES... для стовпцявизначають зовнішній ключ таблиці. Обмеження REFERENCES... для стовпцявизначає простий зовнішній ключ, тобто ключ, що складається з однієїколонки. Обмеження FOREIGN KEY... REFERENCES... для таблиці може визначати як простий, так і складний зовнішній ключ, тобто ключ, що складається з декількохколонок таблиці. Стовпець або група стовпців таблиці, на яку посилається зовнішній ключ, повинна мати обмеження PRIMARY KEY або UNIQUE. Стовпці, на які посилається зовнішній ключ, повинні мати той же тип даних, що й стовпці, що входять до складу зовнішнього ключа. Таблиця може мати посилання на себе. Обмеження зовнішнього ключа порушується, якщо значення, що є присутнім у зовнішньому ключі, не збігаються зі значеннями відповідного ключа батьківської таблиці для жодного рядка з батьківської таблиці. Операції, що приводять до порушення обмеження зовнішнього ключа, відкидаються. Як повинні збігатися значення зовнішнього ключа й ключа батьківської таблиці, а також, які дії необхідно виконати при змінах ключів у батьківській таблиці, описані нижче в посилальній специфікації.

Обмеження NOT NULL. Обмеження NOT NULL стовпця не допускає появи в стовпці NULL-значень.

Посилальна специфікація. Посилальна специфікація визначає характеристики зовнішнього ключа таблиці.

Пропозиція MATCH {FULL | PARTIAL}. Пропозиція MATCH FULL вимагає повного збігу значень зовнішнього й первинного ключів. Пропозиція MATCH PARTIAL допускає частковий збіг значень зовнішнього й первинного ключів. Пропозиція MATCH може бути також пропущеним. Для випадку MATCH PARTIAL у дочірній таблиці можуть з'явитися рядки, що мають значення зовнішнього ключа, що не унікально збігаються зі значеннями батьківського ключа так ,як один рядок дочірньої таблиці може мати не унікальні посилання не кілька рядків батьківської таблиці. Це дуже сильно відрізняється від реляційної моделі даних, і ця відмінність провокується допущенням NULL-значень. Щоб розглянути різні варіанти збігів зовнішнього й батьківського ключів, розглянемо наступний приклад.

Приклад 17. Нехай є дві таблиці:

X Y
1 Aa
1 Bb
2 Cc
2 Dd
3 Ee
3 Ff
Таблиця 4 таблиця A (Батьківська)
Z X Y
1 1 Aa
2 1 Null
3 Null Cc
4 Null Null
5 4 Gg
Таблиця 5 Таблиця B (Дочірня) Таблиця A має первинний ключ (X, Y). Таблиця B має первинний ключ Z, і зовнішній ключ (X, Y), що посилається на первинний ключ таблиці A. Різні варіанти збігу рядків дочірньої таблиці B з рядками батьківської таблиці A наведені нижче:
Колонки X й Y таблиці B допускають null-значення Колонки X й Y таблиці B не допускають null-значень
MATCH відсутній 1 рядок - припустимий, збігається з 1 рядком таблиці A.
2 рядок - припустима, не збігається ні із чим.
3 рядок - припустима, не збігається ні із чим.
4 рядок - припустима, не збігається ні із чим.
5 рядок - не припустимий.
1 рядок - припустимий, збігається з 1 рядком таблиці A.
2 рядок - не припустимий.
3 рядок - не припустимий.
4 рядок - не припустимий.
5 рядок - не припустимий.
MATCH FULL 1 рядок - припустимий, збігається з 1 рядком таблиці A.
2 рядок - не припустимий.
3 рядок - не припустимий.
4 рядок - припустима, не збігається ні із чим.
5 рядок - не припустимий.
1 рядок - припустимий, збігається з 1 рядком таблиці A.
2 рядок - не припустимий.
3 рядок - не припустимий.
4 рядок - не припустимий.
5 рядок - не припустимий.
MATCH PARTIAL 1 рядок - припустимий, збігається з 1 рядком таблиці A.
2 рядок - припустима, не унікально збігається з 1 й 2 рядками таблиці A.
3 рядок - припустима, унікально збігається з 3 рядком таблиці A.
4 рядок - припустима, не збігається ні із чим.
5 рядок - не припустимий.
1 рядок - припустимий, збігається з 1 рядком таблиці A.
2 рядок - не припустимий.
3 рядок - не припустимий.
4 рядок - не припустимий.
5 рядок - не припустимий.

Пропозиція MATCH ігнорується, якщо всі стовпці зовнішнього ключа мають обмеження NOT NULL.

Пропозиції ON UPDATE й ON DELETE. Пропозиції ON UPDATE й ON DELETE визначають дії, що виконують по посиланню. Дії, що виконують по посиланню, в основному описані вище в цій главі. Складності в розумінні того, як виконуються ці дії, виникають якщо встановлено MATCH PARTIAL і колонки, що входять до складу зовнішнього ключа, допускають NULL-значення. Докладно ці дії з урахуванням можливих складностей описані .

Атрибути обмеження. Атрибути обмеження визначають, у який момент перевіряються обмеження. Обмеження може бути визначене як NOT DEFERRABLE ( що не відкладає) або DEFERRABLE ( що відкладає). Якщо атрибути обмеження не зазначені, то за замовчуванням приймається NOT DEFERRABLE.

Якщо обмеження визначене як NOT DEFERRABLE ( що не відкладає), то обмеження завжди перевіряється відразу після виконання кожного оператора INSERT, UPDATE або DELETE, які можуть привести до порушення обмеження.

Якщо обмеження визначене як DEFERRABLE ( що відкладає), то обмеження може мати два режими перевірки - негайно після виконання операції або наприкінці транзакції. Режим перевірки може бути змінений у будь-який момент усередині транзакції командою SET CONSTRAINTS. При визначенні обмеження можна вказати початковий режим перевірки INITIALLY DEFERRED (спочаткувідкладене) або INITIALLY IMMEDIATE (спочатку перевіряне негайно). 

Характеристики работы

Диплом

Количество страниц: 80

Бесплатная работа

Закрыть

Розробка бази даних для сфери торгівлі комп'ютерною технікою

Заказать данную работу можно двумя способами:

  • Позвонить: (097) 844–69–22
  • Заполнить форму заказа:
Не заполнены все поля!
Обязательные поля к заполнению «имя» и одно из полей «телефон» или «email»

Чтобы у вас была возможность удостовериться в наличии вибраной работы, и частично ознакомиться с ее содержанием,ми можем за желанием отправить часть работы бесплатно. Все работы выполнены в формате Word согласно всех всех требований относительно оформления работ.