Зміст

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.5 Обмеження домена

Визначення 8. Обмеження цілісності домена являють собою обмеження, що накладають тільки на припустимі значення домена. Фактично, обмеження домена зобов'язані бути частиною визначення домена (див. визначення домена в розділі 2).

Наприклад, обмеженням домена "Вік співробітника" може бути умова "Вік співробітника не менш 18 і не більше 65".

Перевірка обмеження. Обмеження доменасамі по собі не перевіряються. Якщо на якому-небудь домені заснований атрибут, то обмеження відповідногодомена стає обмеженням цього атрибута.


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

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

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

Перевірка обмеження. Обмеження атрибута є обмеженням, що перевіряє негайно. Дійсно, обмеження атрибута не залежить ні від яких інших об'єктів бази даних, крім домена, на якому заснований атрибут. Тому ніякі зміни в інших об'єктах не можуть вплинути на істинність обмеження.


2.7 Обмеження кортежу

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

Приклад 6. Атрибут "Вік співробітника" у таблиці "Спецпідрозділ", може мати додаткове обмеження "Вік співробітника не менш 25 і не більше 45", крім того, що цей атрибут уже має обмеження, обумовленедоменом - "Вік співробітника не менш 18 і не більше 65".

Наведене обмеження кортежу, по суті, є додатковим обмеженням на значення одного атрибута. У цьому випадку припустимі два рішення. Можна оголосити новий домен "Вік співробітника спецпідрозділу " і тоді обмеження кортежу стає обмеженням домена й атрибута, або розглядати це обмеження саме як обмеження кортежу. Обоєрішення мають свої позитивні й негативні сторони.

Зауваження. Отут є деякі можливості для оптимізації. Формально, при зміні значення даного атрибута необхідно перевірити два обмеження - обмеження атрибута й обмеження кортежу. Але в цьому випадку обмеження кортежу сильніше обмеження атрибута й досить перевірити тільки обмеження кортежу. Розумно побудована СУБД могла б виявляти такі випадки й зменшувати зайву роботу.

Приклад 7. Для відношення "Співробітники" можна сформулювати наступне обмеження: якщо атрибут "Посада" приймає значення "Директор", те атрибут "Зарплата" містить значення не менш 1000$.

Це обмеження зв'язує два атрибути одного кортежу.

Приклад 8. У накладній можна встановити наступний взаємозв'язок атрибутів - "Ціна*Кількість=Сума", що зв'язує атрибути "Ціна", "Кількість", "Сума".

Даний приклад здається неприродним, тому що сума є явно надлишковим атрибутом, значення якого просто виводяться зі значень інших атрибутів. Тому здається, що краще зберігати тільки два базових атрибути "Ціна" й "Кількість", а суму обчислювати під час виконання запитів у міру необхідності. Так, властиво, вимагає реляційна теорія, що прагне звести надмірність до мінімуму. У практиці, однак, справавиглядає складніше. Наприклад, кожен рядок реальної накладної може містити наступні дані про товар:

Назва атрибута Опис атрибута Чи базовий атрибут Формула для обрахунку атрибута
Name Найменування товару Так
N Кількість Так
P1 Облікова ціна товару Так
S1 Облікова сума на всю кількість S1 = N*P1
PerSent Відсоток націнки на одиницю товару Так
P2 Націнка на одиницю товару P2 = P1*PerSent/100
S2 Суму націнки на всю кількість S2 = N*P2
P3 Ціну товару з урахуванням націнки P3 = P1+P2
S3 Суму на всю кількість із урахуванням націнки S3 = N*P3
NDS Відсоток ПДВ Так
P4 Сума ПДВ на одиницю товару P4 = P2*NDS/100
S4 Сума ПДВ на всю кількість S4 = N*P4
P5 Ціна товару із ПДВ P5 = P3+P4
S5 Сума на всю кількість із ПДВ S5 = N*P5

Таблиця 3 Атрибути товару

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

Рішення 1. Нехай у відношеннівирішено зберігати тільки базові атрибути.

Достоїнстварішення:

  • Структура відносиниповністю не надлишкове.
  • Не потрібно додаткового програмного коду для підтримки цілісності кортежу.
  • Заощаджується дисковий простір.
  • Зменшується трафікмережі.

Недолікирішення:

  • У бухгалтерії для формування проводок використаються, як правило, не базові, а обраховані атрибути. Ті самі формули використаються в багатьох місцях, тому всі оператори відбору даних будуть містити однакові фрагменти коду з тими самими формулами. Є ризик у різних місцях обчислювати ті самі дані по різних формулах.
  • При зміні логіки обчислень (що буває досить часто при зміні законодавства), необхідно змінити ті самі фрагменти коду у всіх місцях, де вони зустрічаються. Це сильно утрудняє модифікацію додатків.
  • Якщо виникає нерегламентований запит, то людина, що формулює запит повинен пам'ятати всі ці формули.

Рішення 2. Припустимо, що у відношеннівирішено зберігати всі атрибути, у тому числі й обраховані.

Перевагирішення:

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

Недолікирішення:

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

Як бачимо, обоєрішення мають свої переваги й недоліки. Важливо те, що програмний код, що містить ці формули, не зникає ні в якому із цих рішень (та й куди він дінеться, раз така предметна область!). Тільки в одному випадку код зберігається в одному місці, а в іншому може бути "розмазаний" по всьому додатку.

Насправді даний приклад сильно спрощений, тому що ще однією неприємною особливістю наших бухгалтерій є те, що всі розрахунки повинні вестися зпевною точністю, а саме - до копійок. Виникає проблема округлення, а це ще більше ускладнює формули для розрахунків цін. Простий приклад - обчислення ПДВ містить операцію розподілу, отже може приводити до нескінченних дробів типу 15,519999... Такий дріб необхідно округлити до 15.52. Якщо продається одна одиниця товару, те це не страшно, але якщо продається кілька одиниць товару, то суму ПДВ на всю кількість можна вважати по різних формулах:

1.S4 = N* ROUND(P2*NDS/100) - СПОЧАТКУ округлити при обчисленні ПДВ на одиницю товару, а ПОТІМ помножити на всю кількість, або

2.S4 = ROUND(N*P2*NDS/100) - СПОЧАТКУ помножити на всю кількість, а ПОТІМ округлити до необхідного знака.

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

Інші рішення. Можна спробувати використати й інші рішення, для полегшення розробки й супроводу в цьому випадку. Наприклад, можна зберігати в базовомувідношенні тільки базові атрибути, а для роботи бухгалтерії використати заздалегідь підготовлені подання (динамічні відносини, що задають оператором SQL). Тоді логіка розрахунків буде зберігатися в одному SQL-операторі, що визначає це подання. Іншим варіантом може бути збереження формул у вигляді збережених процедур і функцій бази даних.

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

Обмеження кортежу є обмеженням, що перевіряє негайно. Дійсно, обмеження кортежу не залежить ні від яких інших об'єктів бази даних, крім атрибутів, що входять до складу кортежу. Тому ніякі зміни в інших об'єктах не можуть вплинути на істинність обмеження. 

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

Диплом

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

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

Закрыть

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

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

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

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