Зміст

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, що використають обмеження

Висновок

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

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

Метою розробки будь-якої бази даних єзберігання й використання інформації про яку-небудь предметну область. Для реалізації цієї мети є наступні інструменти:

1.Реляційна модель даних - зручний спосіб подання даних предметної області.

2.Мова SQL - універсальний спосіб маніпулювання такими даними.

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

У даному розділі розглядаються методи "гарного" або "правильного" проектування реляційних відносин. Спочатку ми обговоримо, що значить "гарні" або "правильні" моделі даних. Потім будуть уведені поняття перших, других і третьоїнормальних форм відносин (1НФ, 2НФ, 3НФ) і показане, що "гарними" євідносини в третій нормальній формі.

При розробці бази даних звичайно виділяється кілька рівнів моделювання, за допомогою яких відбувається перехід від предметної області до конкретної реалізації бази даних засобамиконкретноїСУБД. Можна виділити наступні рівні:

  • Сама предметна область
  • Модель предметної області
  • Логічна модель даних
  • Фізична модель даних
  • Властиво база даних і додатка

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

Модель предметної області. Модель предметної області - це наші знання про предметну область. Знання можуть бути як у вигляді неформальних знань у мозку експерта, так і виражені формально за допомогою яких-небудь засобів. Як такі засоби можуть виступати текстові описи предметної області, набори посадових інструкцій, правила ведення справ у компанії й т.п. Досвід показує, що текстовий спосіб подання моделі предметної області вкрай неефективний. Набагато більше інформативними й корисними при розробці баз даних є описи предметної області, виконані за допомогою спеціалізованих графічних нотацій. Є велика кількість методик опису предметної області. З найбільш відомих можна назвати методику структурного аналізу SADT і засновану на ньому IDEF0, діаграми потоків данихГейна-Сарсона, методику об’ктно-орієнтованого аналізу UML і ін. Модель предметної області описує скоріше процеси, що відбуваються в предметній області й дані, використовувані цими процесами. Від того, наскільки правильно змодельована предметна область, залежить успіх подальшої розробки додатків.

Логічна модель даних. На наступному, більше низькому рівніперебуває логічна модель даних предметної області. Логічна модель описує поняття предметної області, їхній взаємозв'язок, а також обмеження на дані, що накладають предметною областю. Приклади понять - "співробітник", "відділ", "проект", "зарплата". Приклади взаємозв'язків між поняттями - "співробітник значиться рівно в одному відділі", "співробітник може виконувати кілька проектів", "над одним проектом може працювати кілька співробітників". Приклади обмежень - "вік співробітника не менш 16 і не більше 60 років".

Логічна модель даних є початковим прототипом майбутньої бази даних. Логічна модель будується в термінах інформаційних одиниць, але без прив'язки до конкретного СУБД. Більше того, логічна модель даних необов'язково повинна бути виражена засобами саме реляційної моделі даних. Основним засобом розробки логічної моделі даних у даний момент є різні варіанти ER-діаграм (Entity-Relationship, діаграми сутність-зв'язок). Ту саму ER-модель можна перетворити як у реляційну модель даних, так й у модель даних для ієрархічних і мережнихСУБД, або в постреляційну модель даних. Однак, тому що ми розглядаємо саме реляційніСУБД, те можна вважати, що логічна модель даних для нас формулюється в термінах реляційної моделі даних.

Рішення, прийняті на попередньому рівні, при розробці моделі предметної області, визначають деякі границі, у межах яких можна розвивати логічну модель даних, у межах же цих границь можна приймати різні рішення. Наприклад, модель предметної області складського облікумістить поняття "склад", "накладна", "товар". При розробці відповідноїреляційної моделі ці терміни обов'язково повинні бути використані, але різних способів реалізації отут багато - можна створити одне відношення, у якому будуть присутні як атрибути "склад", "накладна", "товар", а можна створити три окремих відношення, по одному на кожне поняття.

При розробці логічної моделі даних виникають питання: чи добре спроектовані відносини? Чи правильно вони відбивають модель предметної області, а отже й самій предметній області?

Фізична модель даних. На ще більш низькому рівні перебуває фізична модель даних. Фізична модель даних описує дані засобамиконкретноїСУБД. Ми будемо вважати, що фізична модель даних реалізована засобами саме реляційноїСУБД, хоча, як уже сказано вище, це необов'язково. Відносини, розроблені на стадії формування логічної моделі даних, перетворяться в таблиці, атрибути стають стовпцями таблиць, для ключових атрибутів створюються унікальні індекси, домени перетворюють у типи даних, прийняті в конкретноїСУБД.

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

При розробці фізичної моделі даних виникають питання: чи добре спроектовані таблиці? Чи правильно обрані індекси? Наскільки багато програмного коду у вигляді тригерів і збережених процедур необхідно розробити для підтримки цілісності даних?

Властиво база даних і додатка. І, нарешті, як результат попередніх етапів з'являється властиво сама база даних. База даних реалізована на конкретній програмно-апаратній основі, і вибір цієї основи дозволяє істотно підвищити швидкість роботи з базою даних. Наприклад, можна вибирати різні типи комп'ютерів, міняти кількість процесорів, обсяг оперативної пам'яті, дискові підсистеми й т.п. Дуже велике значення має також настроювання СУБД у межах обраної програмно-апаратної платформи.

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

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

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

Диплом

Кількість сторінок: 80

Безкоштовна робота

Закрити

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

Замовити дану роботу можна двома способами:

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

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