Коротко про важливе.

нормалізація БД

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

• відсутні повторювані групи даних
• гарантується елементарності (atomicity) даних (всі дані є автономними і незалежними).

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

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

• таблиця задовольняє умовам 1НФ
• кожен стовпець залежить від усього ключа, а не від його частини.

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

• таблиця задовольняє умовам 2НФ
• жоден стовпець не залежить від стовпчика, який не є частиною первинного ключа
• не містить похідних даних

Інші нормальні форми, які не мають особливої \u200b\u200bпрактичної цінності:

Нормальна форма Бойса-Кодда (Boyce-Codd)

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

Четверта нормальна форма

Призначена для вирішення питання з багатозначними залежностями. Такі ситуації виникають, якщо в наведеній до 3НФ таблиці один стовпець складеного первинного ключа залежить від іншого шпальти первинного ключа.

П'ята нормальна форма

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

Шоста нормальна форма (нормальна форма доменного ключа)

Гарантує відсутність аномалій модифікації в базі даних. В реальних умовах практично не досяжна.

Відносини.

Одного разу я почув від жінок, що чоловіки
негайно намагаються покинути приміщення, в якому
прозвучало слово "відносини".<...> ключем до успіху
відносин є поінформованість кожного про свою роль
в даному відношенні, а також про правила і обмеження,
накладаються даними ставленням.
(С) Robert Viera, "Professional SQL Server 2000 Programming "

типи відносин

• Одного-к-одному (иммет сенс, коли в різних базах потрібно зберігати збігаються дані або коли відбувається перевищення максимального розміру даних рядка)
• Нуля- або одного-к-одному
• Одного-ко-многим
• Одного до -нулю, -одна або -Багато
• Багатьох-ко-многим (развязочние таблиці)

об'єднання

INNER JOIN

Що виключає об'єднання (exclusive join). В результат вибірки потрапляють тільки ті записи таблиць, у яких є відповідності в парній таблиці по заданій умові.

LEFT | RIGHT JOIN

Що включає об'єднання (inclusive join). В результат вибірки потрапляють записи з таблиці, що стоїть зліва / справа від JOIN відповідно. При цьому дані з якої бракує «парної» записи будуть заповнені NULL.
FROM left_table LEFT JOIN right_table - щоб використовувати всі записи з лівої таблиці left_table
FROM left_table RIGHT JOIN right_table - щоб використовувати всі записи з правої таблиці right_table

FULL JOIN

Що включає об'єднання (inclusive join). В результат вибірки потрапляють не тільки записи, які мають відповідність в іншій таблиці, але і записи з обох таблиць, для яких у відповідність до іншого таблиці не знайдено. При цьому дані з якої бракує «парної» записи будуть заповнені NULL.

CROSS JOIN

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

Принципи упорядкування кількох JOIN'ов

У разі, якщо необхідно провести об'єднання декількох таблиць, потрібно пам'ятати про двох принципах:

1. Всі об'єднання лівіше JOIN сприймаються як одиночна таблиця для включення або виключення із запиту.
2. Всі об'єднання права JOIN ТАКОЖ сприймаються як одиночна таблиця для включення або виключення із запиту.

Наслідком з цих принципів є наступна рекомендація для формування складних об'єднань:

• Скрізь, де тільки можна, слід використовувати INNER JOIN.
• Якщо виникає необхідність використання OUTER JOIN - їх потрібно ставити останніми, а на початку об'єднання розміщуються INNER JOIN.

P.S. Все вищевикладене є загальними "постулатами" теорії реляційних баз даних, які не прив'язаними до особливостей певних СУБД.

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

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

СУБД загального призначення повинна дозволяти визначення, створення, зміна, адміністрування і твір запитів до БД.

Як приклади СУБД можна назвати такі широко відомі пакети, як

• MySQL
• PostgreSQL
• Microsoft SQL Server
• Oracle
• IBM DB2
• Microsoft Access
• SQLite

Бази даних зазвичай не є переносяться між різними СУБД, проте можлива взаємодія між СУБД (і з призначеним для користувача ПО) з використанням різних стандартів, Таких, як SQL, ODBC або JDBC.

СУБД часто класифікуються за підтримуваної ними моделі даних. З 1980х років, практично всі популярні СУБД підтримують реляційну модель даних, представлену стандартом мови запитів SQL (Хоча останні роки набирає популярність NoSQL).

Отже, основні завдання, що виконуються СУБД включають

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

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

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

моделі БД

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

• Ієрархічна, або навігаційна модель
• мережева модель

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

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

У 1970х Едгаром Коддом (співробітник IBM) була запропонована реляційна модель, яка значно полегшила завдання пошуку інформації в БД. Про реляційної моделі можна думати як про "таблицях", в яких "рядки" - це записи в БД. Записи в реляційної БД так само називаються кортежами (tuples), а групи записів ( "таблиці") - відносинами (relations). Реляційна модель здатна висловити зв'язку ієрархічної та мережевий моделей, І додавала власні зв'язки, відповідні табличній моделі.

На основі пропозицій Кодда до середини 1970х була розроблена СУБД System R, а до кінця в ній з'явилася підтримка стандартизованого мови запитів SQL.

У 1980х, з появою об'єктно-орієнтованого програмування, все частіше виникали складності в трансляції об'єктів на реляційну модель. Зрештою це призвело до появи підходів NoSQL і NewSQL, які на поточний момент тільки розвиваються. Прикладами реалізації NoSQL підходу можуть бути т.зв. документо-орієнтовані БД, побудовані на основі XML. Основна перевага NoSQL - висока горизонтальна масштабованість, тобто можливість збільшувати продуктивність за рахунок додавання серверів. З появою хмарних технологій, NoSQL став особливо затребуваний.

Проте, реляційна модель поки залишається найпоширенішою, тому більш детально зупинимося саме на ній.

реляційна модель

Реляційна модель оперує поняттями записів, атрибутів і відносин. Ставлення можна уявити собі у вигляді двовимірної таблиці, тоді атрибути - це стовпці таблиці (точніше, назви стовпців), а записи - рядки таблиці.

Реляційна модель вимагає суворого визначення структури даних, що зберігаються в БД, тобто відносини і атрибути для даної БД фіксовані.

Введемо деякі визначення.

Домен Безліч, що містить повний набір всіх можливих значень деякої змінної. Домени часто так само називають типом даних. Атрибут Упорядкована пара назви атрибута і домену \\ (D_j \\). Кортеж Кінцеве впорядкована множина \\ ((d_1, d_2, \\ ldots, d_n) \\) Заголовок (схема) відносини Кортеж \\ ((A_1, A_2, \\ ldots, A_n) \\), де \\ (A_j \\) - атрибути. Значення атрибута Конкретне значення, що належить домену атрибута. Тіло відносини Безліч кортежів, де \\ (d ^ i_j \\ in D_j \\), \\ (D_j \\) - домени. запис Кортеж \\ ((D ^ i_1, d ^ i_2, \\ ldots, d ^ i_n) \\) при фіксованому \\ (i \\). Ставлення Сукупність заголовка відносини і тіла відносини. Схема бази даних Безліч схем всіх відносин, що входять в БД.

Можна уявити ставлення у вигляді таблиці. Тоді тіло відносини - це тіло таблиці, заголовок відносини - заголовок таблиці, атрибути - назви стовпців, записи - рядки, а значення атрибутів знаходяться в осередках:

\\ (A_1 \\)	\\ (A_2 \\)	\\ (\\ Ldots \\)	\\ (A_n \\)	← Тема
\\ (D ^ 1_1 \\)	\\ (D ^ 1_2 \\)	\\ (\\ Ldots \\)	\\ (D ^ 1_n \\)	← Запис
\\ (D ^ 2_1 \\)	\\ (D ^ 2_2 \\)	\\ (\\ Ldots \\)	\\ (D ^ 2_n \\)	← Запис
\\ (\\ Ldots \\)	\\ (\\ Ldots \\)	\\ (\\ Ldots \\)	\\ (\\ Ldots \\)	← Запис
\\ (D ^ m_1 \\)	\\ (D ^ m_2 \\)	\\ (\\ Ldots \\)	\\ (D ^ m_n \\)	← Запис

Реляційна модель накладає такі додаткові вимоги на відносини:

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

Функціональна залежність безліч атрибутів \\ (B \\) функціонально залежить від безлічі атрибутів \\ (A \\) (записується \\ (A \\ rightarrow B \\)), якщо для будь-яких двох записів, що мають однакові значення \\ (A \\), їх значення \\ ( B \\) збігаються. Інакше, кожному значенню \\ (A \\) відповідає єдине значення \\ (B \\) (не обов'язково унікальне, саме єдине).

Іншими словами, якщо певний набір атрибутів \\ (A \\) однозначно визначає (в рамках даного відносини) значення атрибутів \\ (B \\), то \\ (B \\) функціонально залежить від \\ (A \\).

Як більш звичного прикладу функціональної залежності, можна привести математичне визначення функції. Для функції, кожному значенню аргументів соответсвтует єдине значення функції. Зворотне в загальному випадку невірно, наприклад, для функції \\ (y \u003d sin (x) \\) будь-якому значенню \\ (y \\) з області визначення \\ (1 \\ geq y \\ geq -1 \\) відповідає безліч значень \\ (x \\ \\ (X \\ to y \\). Зауважимо, що поняття функціональної залежності так само можна застосувати і до функцій багатьох змінних. Для них, значення функції функціонально залежить від всіх аргументів одночасно. Скажімо, для функції \\ (z \u003d f (x, y) \\) виконується ФЗ \\ ((x, y) \\ to z \\), або скорочено, \\ (xy \\ to z \\).

Відносини в даному контексті можна розглядати як якісь табличні або дискретні функції.

Робота з ФЗ

Існують певні формальні правила роботи з ФЗ відносини.

Формальні правила тісно пов'язані з поняттями замикання і приводиться ФЗ.

аксіоми Армстронга

Існують правила виведення нових ФЗ з існуючих, звані аксіомами Армстронга.

аксіоми Армстронга

1. Правило рефлексивності: якщо \\ (B \\ subset A \\), то \\ (A \\ rightarrow B \\)
2. Правило доповнення: якщо \\ (A \\ rightarrow B \\), то \\ (AC \\ rightarrow BC \\)
3. Правило транзитивності: якщо \\ (A \\ rightarrow B \\) і \\ (B \\ rightarrow C \\), то \\ (A \\ rightarrow C \\)

З цих аксіом так само можуть бути виведені наступні додаткові правила:

1. Правило самовизначення: \\ (A \\ rightarrow A \\)
2. Правило декомпозиції: Якщо \\ (A \\ rightarrow BC \\), то \\ (A \\ rightarrow B \\) і \\ (A \\ rightarrow C \\)
3. Правило об'єднання: Якщо \\ (A \\ rightarrow B \\) і \\ (A \\ rightarrow C \\), то \\ (A \\ rightarrow BC \\)
4. Правило композиції: Якщо \\ (A \\ rightarrow B \\) і \\ (C \\ rightarrow D \\), то \\ (AC \\ rightarrow BD \\)

Можна помітити, що, внаслідок правила рефлексивності, будь-яка множина атрибутів \\ (A \\) має на увазі ФЗ виду \\ (A \\ to A \\). Такі ФЗ, а так само такі з них, не представляють інтересу, і називаються тривіальними.

Тривіальна функіональний залежність ФЗ \\ (A \\ to B \\), така, що \\ (B \\ subset A \\).

В принципі, цих правил досить для того, щоб знайти все ФЗ, що випливають із даних. У зв'язку з цим вводиться поняття замикання безлічі ФЗ.

Замикання безлічі ФЗ Замиканням безлічі ФЗ називається така безліч ФЗ, яке включає всі ФЗ вихідного безлічі, а так же все припускаються ними. Іншими словами, для відносини \\ (R \\), що володіє функціональними залежностями \\ (S \\), замиканням \\ (S ^ + \\) називається безліч всіх ФЗ, можливих для \\ (R \\), виходячи з \\ (S \\).

Як правило, потрібно встановити, чи буде якась ФЗ \\ (X \\ rightarrow Y \\) слідувати з даного безлічі ФЗ \\ (S \\). Виявляється, це можливо тоді і тільки тоді, коли безліч атрибутів \\ (Y \\) є підмножиною замикання атрибутів \\ (X ^ + \\) в \\ (S \\).

Замикання атрибутів Замиканням \\ (X ^ + \\) атрибутів \\ (X \\) по безлічі ФЗ \\ (S \\) називається безліч всіх атрибутів, які функціонально залежать від будь-якого підмножини \\ (X \\).

Для обчислення замикання безлічі атрибутів \\ (X ^ + \\) по безлічі ФЗ \\ (S \\) існує наступне правило: для кожної ФЗ \\ (A \\ rightarrow B \\) в \\ (S \\), якщо \\ (A \\ subset X ^ + \\), то і \\ (B \\ subset X ^ + \\), причому досить почати з припущення, що \\ (X ^ + \u003d X \\).

Слід зауважити, що для будь-якого замикання \\ (X ^ + \\), існують ФЗ виду \\ (X \\ to B \\), де \\ (B \\ subset X ^ + \\), таким чином, замикання всіх атрибутів відносини по його ФЗ описують замикання ФЗ цього відносини.

Це правило використовується для обчислення неприводимого безлічі ФЗ, еквівалентного даному (в сенсі еквівалентності їх замикань). Зменшення кількості ФЗ при збереженні замикання (і, отже, внутрішньої логіки, описуваної ФЗ) є важливим кроком в проектуванні БД.

Безліч ФЗ називається непріводімим, якщо:

1. Права частина кожної ФЗ містить лише один елемент
2. Жоден атрибут жодної лівої частини ФЗ безлічі не може бути видалений без зміни замикання
3. Жодна ФЗ безлічі не може бути видалена без зміни замикання.

Для будь-якого безлічі ФЗ існує хоча б одне еквівалентну неприводимого безліч. Таке безліч називається мінімальним покриттям.

Життєвий цикл інформаційних систем

Аналіз ситуації (складність розробки ІС, які не ефективне використання ІС), проведений вченими, показав, що такий стан було викликано тим, що при розробці програмного забезпечення не дотримувалися дуже важливими вимоги:

· Відсутність повної специфікації всіх вимог;

· Відсутність прийнятною методології (системи методів) розробки ІС;

· Відсутність поділу спільного глобального проекту на окремі компоненти, які піддаються ефективному контролю та управління.

Життєвий цикл (ЖЦ) інформаційних систем - це структурний підхід до розробки програмного забезпечення.

(Якась схема) за 26.09.12

1. Планування розробки ІС. Підготовчі дії, що дозволяють з максимальною ефективністю реалізовувати етапи ЖЦ ІС. Три основних компоненти: оцінка обсягу робіт; оцінка необхідних ресурсів; оцінка загальної вартості проекту.

2. Визначення вимог до системи. Визначення діапазону дій і кордонів програми бази даних, функцій, складу його користувачів і областей застосування.

3. Збір і аналіз вимог користувачів. Збір і аналіз інформації про ту частину організації, робота якої буде підтримуватися за допомогою створюваної ІС, визначення вимог користувачів до системи. Джерела: опитування та анкетування; спостереження; вивчення документів; попередній досвід.

4. Проектування бази даних. Створення проекту бази даних. Два основні підходи до проектування систем баз даних: « спадний»І« висхідний».

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

6. Розробка додатків. Проектування інтерфейсу користувача і прикладних програм, призначених для роботи з базою даних.

7. Створення прототипу. Створення робочої моделі програми баз даних.

8. Реалізація. Фізична реалізація бази даних і розроблених додатків.

9. Конвертація і завантаження даних. Перенесення існуючих даних в нову базу даних, завантаження і модифікація існуючих додатків з метою організації спільної роботи з новою БД.

10. Тестування. Процес виконання прикладних програм з метою пошуку помилок. Стратегії тестування: спадний тестування; висхідне тестування; тестування потоків; інтенсивне тестування.

11. Експлуатація та супровід. Спостереження за системою і підтримка її нормального функціонування: контроль продуктивності; супровід і модернізація додатків.

Реляційна теорія баз даних

Термінологія

У 1970 р Реляційна модель вперше була запропонована Е.Ф. Коддом.

У реляційної СУБД передбачається, що користувач сприймає БД як набір таблиць (і не як інакше).

Математичні відносини.

Теорія реляційних БД заснована на математичної теорії відносин.

Нехай D1, D2, ... Dn деякі множини.

Декартових твір D1 D2 ... Dn \u003d ((X1, X2, ..., Xn) | X1 D1, X2 D2, ... Xn Dn)

Ставлення - підмножина R D1 * D2 * ... * Dn

Наприклад, n \u003d 2, D1 \u003d (2,4) і D2 \u003d (1,3,5), D1 * D2 \u003d ((2,1), (2,3), (2,5), (4, 1), (4,3), (4,5)), R \u003d ((2,1), (4,1))

Підмножина м. Б. задано умовою, наприклад:

R \u003d ((x1, x2) | x1 D1, x2 D2, X2 \u003d 1), A1, A2, ... An - імена атрибутів з доменами D1, D2, ... ВТБ тоді відношення будемо записувати у вигляді:

R (A1: D1, A2: D2, ... An: Dn)

Властивості відносин:

· Ставлення має унікальне ім'я;

· Кожен атрибут має унікальне ім'я (щодо);

· Кожна осередок відносини містить тільки атомарному значення і немає повторюваних груп (відношення нормалізовано);

D1 - студенти
D2 - дисципліни: Математика, Інформатика

· Порядок проходження атрибутів не має ніякого значення;

· Порядок проходження кортежів довільний;

· Кожен кортеж є унікальним.

реляційні ключі

Реляційні ключі служать для унікальної ідентифікації кортежу опису зв'язків між відносинами.

Реляційна цілісність.

реляційна алгебра

Результат операції, може використовуватися в якості операнда для іншої операції, що дозволяє створювати вкладені вирази (замкнутість РА).

Реляційна алгебра є мовою, в якому все кортежі обробляються однією командою.

П'ять основних операцій:

· Вибірка,

· Проекція,

· Декартово твір,

· Об'єднання,

· Різниця.

На основі цих операцій можуть бути отримані інші:

· З'єднання,

· Перетинання,

· Поділу.

У предикате можуть використовуватися знаки логічних операцій ^ (And), v (Or), ~ (not).

Приклад. Отримати список всіх співробітником з окладом понад 300.

Проекція.

Визначає ставлення, атрибутами якого є атр1, ..., атрn і містить тільки унікальні кортежі.

декартово твір

Декартово твір використовується рідко, до результату застосовують вибірку.

об'єднання

різниця

Операції з'єднання.

Тета-з'єднання

природне з'єднання

Зовнішнє з'єднання

Те при лівому зовнішньому з'єднанні зберігається вся вихідна інформація з відносини R. Аналогічно також можна визначити праве зовнішнє з'єднання.

напівз'єднання

Операцію напівз'єднання можна визначити за допомогою операторів проекції і з'єднання.

перетин

уявлення

Призначення уявлень:

· Надає гнучкий механізм захисту БД за рахунок приховування деякої її частини від визначених користувачів;

· Дозволяє організувати доступ користувачів до даних найбільш зручним для них способом;

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

Правила, які повинні задовольнити
реляційні СУБД

Для визначення того, чи є Субоу реляційної Кодд (1985 г.) запропонував 13 правил, яким вони повинні задовольняти.

№		правило
		Фундаментальне правило. Реляційна СУБД повинна бути здатна управляти базами даних виключно з допомогу її реляційних функцій
		Подання інформації. Вся інформація в реляційної БД представляється в явному вигляді на логічному рівні тільки одним способом - у вигляді значень в таблицях. В тому числі, метадані.
		Гарантований доступ. Для кожного елемента даних реляційної БД повинен бути гарантований логічний доступ на основі комбінації імені таблиці, значення первинного ключа і імені стовпця.
		Підтримка невизначених значень. СУБД підтримує невизначені значення (Null).
		Реляційний системний каталог. Опис БД повинен подаватися для логічному рівні таким чином, як і звичайні дані, що дозволяє користувачам використовувати для звернення до них той же реляційний мову.
		Вичерпний под'язик даних. реляційна СУБД може підтримувати кілька мов. Однак повинен існувати по крайней мерее одна мова, оператори якого дозволяли б виконати наступні функції: 1. Визначення даних; 2. Визначення уявлень; 3. Команди маніпулювання даними; 4. Обмеження цілісності; 5. Авторизации користувачів; 6. Організації транзакцій
		Високорівневі операції вилучення, вставки, видалення, оновлення. Здатність СУБД виконувати операції вилучення даних команд вставки, видалення і оновлення як єдиної операції.
		Фізична незалежність від даних. Від способу зберігання
		Логічна незалежність від даних. Незалежність додатків від зміни базових таблиць.
		Незалежність обмежень цілісності. Обмеження цілісності повинні визначатися на підмові реляційних даних і зберігатися в системному каталозі, а не в прикладних програмах.
		Незалежність від розподілу даних.
		Правило заборони обхідних шляхів. Якщо СУБД має низькорівневий мову (з послідовною порядкової обробкою), він не повинен дозволяти обходити правила і обмеження цілісності, описаних на реляционном мовою високого рівня.

Моделювання даних на основі процесу нормалізації

Мета нормалізації.

Процес нормалізації був запропонований в 1972 році Е. Ф. Коддом - три нормальні форми (НФ): перша (1НФ), друга (2НФ) і третя (3НФ).

Більш суворе визначення третьої НФ (Р. Бойс і Е. Ф. Кодд, 1974) - нормальна форма Бойса-Кодда (НФБК).

Надмірність даних і аномалії обробки.

Відсутність нормалізації призводить:

· Надмірність даних

· Аномалії вставки (неможливо додавати записи)

· Аномалії видалення (при видаленні інформації втрачається інша інформація)

· Аномалії оновлення (потрібне оновлення багатьох записів)

· Властивості збереження без втрат і збереження залежності.

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

База даних - сукупність пов'язаних даних, організованих за певними правилами, які передбачають загальні принципи опису, зберігання і маніпулювання, незалежна від прикладних програм. Реляційна база даних - це база даних, в якій інформація представлена \u200b\u200bу вигляді двовимірних таблиць, які зберігаються в файлах. Таблиця складається з рядків, званих записами, записи складаються із стовпців, які називаються полями.

Система управління базами даних (СКБД) - це сукупність мовних і програмних засобів, Призначених для створення, ведення та спільного використання БД багатьма користувачами. Користувачів СУБД можна розділити на три великі групи:

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

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

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

• всі дані концептуально представляються як упорядковане набір рядків і стовпців, які називаються ставленням;
• всі дані є скалярними;
• рядок даних називається кортежем, кількість кортежів називається кардинальним числом;
• кожен стовпець в кортежі називається атрибутом, кількість атрибутів називається ступенем відносини;
• відсутність інформації описується значенням NULL;
• потенційний ключ K для відносини R - це підмножина безлічі атрибутів R, завжди володіє властивістю унікальності (тобто немає двох кортежів у відношенні R з однаковим значення K) і властивістю не надмірності (тобто жодне з підмножин K не володіє властивістю унікальності). Потенційний ключ, що складається з більш ніж одного атрибута, називається складовим, а з одного - простим. Первинний ключ - це потенційний ключ, за яким фізично впорядковані кортежі в відношенні.
• зовнішній ключ визначається наступним чином. Нехай R2 - деяке відношення. Тоді зовнішній ключ FK щодо R2 - це таке підмножина безлічі атрибутів R2, що існує відношення R1 з потенційним ключем K і значення FK в будь-якому кортежі R2 завжди збігається зі значенням K деякого кортежу в R1. Обмеження, за яким значення зовнішнього ключа повинні бути адекватні значенням відповідного потенційного ключа, називають посилальним обмеженням. Відповідно, під посилальної цілісністю розуміють вимогу того, щоб в базі даних не було порушень посилальних обмежень.

Наступні операції допустимими над даними в реляційній моделі:

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

ПРОГРАМУВАННЯ В СЕРЕДОВИЩІ DELPHI 6

Бази даних. Створення звіту з допомогою Word.

Затверджено Редакційно-видавничим радою

університету в якості лабораторного практикуму

Воронеж 2004

681.3

Воробйов Е.І., Короткевич Д.Е .. Програмування в середовищі Delphi 6: Лабораторний практикум: Ч. 2: Бази даних. Створення звіту за допомогою Word. Потоки. Воронеж: Воронеж. держ. техн. ун-т, 2004. 107 с.

У другій частині лабораторного практикуму розглядаються теоретичні та практичні відомості для написання програм у середовищі Delphi 6 на тему: «Проектування баз даних, створення звітів в програмі Word і використання потоків при створенні високопродуктивних додатків ».

Видання відповідає вимогам Державного освітнього стандарту вищої професійної освіти за напрямом 230100 «Інформатика та обчислювальна техніка», спеціальності 230104 «Системи автоматизованого проектування», дисципліни «Програмування на мовах високого рівня».

Табл. 3. Іл. 19. Бібліогр .: 7 назв.

Науковий редактор: д-р техн. наук, проф. Я.Е. Львович

Рецензенти: кафедра обчислювальної техніки Воронеж ської лісотехнічний академії (зав. Кафедрою д-р техн. Наук, проф. В.Є. Межов);

д-р техн. наук, проф. О.Ю.Макаров

© Воробйов Е.І., Короткевич Д.Е., 2004

© Оформлення. Воронезький державний

технічний університет, 2004

Вступ

Концепція баз даних

Бази даних вважаються основною перевагою Delphi. Навіть спеціалізовані мови для роботи з базами даних (такі, як MS Visual FoxPro) Явно поступаються по простоті і мощі програмування цього типу додатків. Delphi приховує всі складності і в той же час дає найбільшу міць. Ще не було такого завдання, яку не змогли б реалізувати на Delphi за короткий проміжок часу. А головне, що все це реалізовано дуже зручно і легко для розуміння. У Delphi можна створювати прості програми, Навіть зі складними базами, без єдиної строчки коду. В данному навчальному посібнику розглянуті лабораторні завдання для освоєння прийомів роботи з локальними базами даних.

Теорія реляційних баз даних

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

Бази даних діляться на локальні (встановлені на комп'ютері клієнта, там же де і працює програма) і віддалені (встановлені на сервері, віддаленому комп'ютері). серверні бази даних розташовуються на віддаленому комп'ютері і працюють під управлінням серверного програмного забезпечення. До їх головних переваг можна віднести можливість роботи з однією базою даних одночасно кількома користувачами, і при цьому здійснюється мінімальне навантаження на мережу. Є ще мережеві бази даних, які створюють дуже велике навантаження на мережу і незручні в роботі як для програміста, так і для кінцевого користувача. Коли програма приєднується до мережевої бази даних, то вона викачує з сервера практично повну його копію. Якщо Ви внесли зміни, то Ваша копія повністю закачується назад. Це дуже незручно, тому що створюється велике навантаження на мережу через зайву перекачування даних. При клієнт-серверної технології програма клієнт посилає простий текстовий запит на сервер на отримання будь-яких даних. Сервер обробляє його і повертає тільки необхідну порцію даних. Коли потрібно змінити якісь дані знову надсилається запит до сервера на їх зміну, і сервер змінює дані в своїй базі. Таким чином, по мережі відбувається перекачування в основному тільки текстових запитів, які в основному займають менше кілобайт. Всі дані обробляє сервер, а значить, машина клієнта завантажується набагато менше і не так сильно вимоглива до ресурсів. Сервер відсилає клієнтові тільки найнеобхідніші дані, а значить, відсутня зайва перекачування копії всієї бази. Завдяки всьому цьому мережеві бази даних вже застаріли і практично не використовуються. Їх практично повністю витісняє технологія клієнт-сервер. А ось локальні бази даних будуть жити завжди. Може змінитися формат їх зберігання або додатися якісь нові функції, але самі бази даних будуть існувати. Для подальшого розгляду нам треба визначити нове поняття - таблиця. Поки що говорилися тільки загальні принципи, тому використовувалося загальне поняття баз даних. Таблиця бази даних - це як двомірний масив, в якому в стовпець збудовані дані (яскравий приклад таблиці - Excel). База даних - грубо кажучи, це всього лише файл, в якому може зберігатися від однієї до кількох таблиць. Більшість локальних баз даних можуть зберігати лише одну таблицю (dBase, Paradox, XML). Але є представники локальних баз, де в одному файлі укладено кілька таблиць (наприклад Access).

Локальні бази даних

З локальних баз даних розглянемо реляційні як найпоширеніші. Що таке реляційна база даних? Це таблиця, в якій в якості стовпців виступають імена зберігаються в ній даних, а кожен рядок зберігає самі дані. Таблиця бази даних схожа на електронну таблицю Excel (Якщо бути точніше, то Excel зберігає свої дані у вигляді власного формату, Побудованого на основі технології баз даних). Локальні таблиці баз даних можуть зберігатися на локальному жорсткому диску або централізовано зберігатися на мережевий диск файлового сервера. Ці файли можна копіювати за допомогою стандартних засобів як будь-який інший файл, тому що самі таблиці бази даних не прив'язані до певного місця розташування. Головне, щоб програма могла знайти таблицю. У кожній таблиці має бути одне унікальне поле, яке однозначно буде ідентифікувати рядок. Це поле називається ключовим. Ці поля дуже часто використовуються для зв'язування декількох таблиць між собою. Але навіть якщо таблиця не пов'язана, ключове поле все одно обов'язково. Як ключ бажано використовувати чисельний тип і якщо дозволяє база даних, то буде краще якщо він буде типу "autoincrement" (автоматично збільшується / меншу кількість або лічильник). Імена стовпців в таблиці бази даних також повинні бути унікальними, але в цьому випадку не обов'язково числовими. Їх можна називати як завгодно, лише б було унікально і зрозуміло. Кожен стовпець (поле бази даних) обов'язково повинен мати певний тип. Кількість типів і їх різновиди залежать від типу бази даних, наприклад формат dBASE (файли з розширенням DBF) підтримує тільки 6 типів, а Paradox вже до 15. База даних може зберігатися в одному файлі (Access) або в декількох (Paradox, dBase). Точніше сказати, дані таблиці завжди зберігаються в одному файлі, а ось додаткова інформація може розташовуватися в окремих файлах. В якості додаткової інформації можуть бути індекси, обмеження або список значень за замовчуванням для конкретних полів. Якщо хоча б один з файлів зіпсувати або буде видалений, то дані можуть стати недоступними для редагування.

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

Якщо треба, щоб якась таблиця була впорядкована по полю « Прізвище», То це поле треба спочатку проіндексувати. Потім потрібно тільки вказати, що таблиця повинна працювати зараз з таким-то індексом, і вона сортується автоматично.

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

Життєвий цикл будь-якого програмного продукту, в тому числі і системи управління базою даних, складається (по-крупному) зі стадій проектування, реалізації та експлуатації.

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

Вимоги до баз даних

Отже, добре спроектована база даних:

1. Чи задовольняє всім вимогам користувачів до вмісту бази даних. Перед проектуванням бази необхідно провести великі дослідження вимог користувачів до функціонування бази даних.

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

3. Забезпечує природне, легке для сприйняття структурування інформації. Якісне побудова бази дозволяє робити запити до бази більш "прозорими" і легкими для розуміння; отже, знижується ймовірність внесення некоректних даних і поліпшується якість супроводу бази.

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

починають відігравати головну роль, відразу "висвічуючи" всі недоліки етапу проектування.

Наступні пункти представляють основні кроки проектування бази даних:

1. Визначити інформаційні потреби бази даних.

2. Проаналізувати об'єкти реального світу, які необхідно змоделювати в базі даних. Сформувати з цих об'єктів суті і характеристики цих сутностей (наприклад, для сутності "деталь" характеристиками можуть бути "назва", "колір", "вага" і т.п.) і сформувати їх список.

3. Поставити у відповідність сутностям і характеристикам - таблиці і стовпчики (поля) в нотації обраної Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle і т.д.).

4. Визначити атрибути, які унікальним чином ідентифікують кожен об'єкт.

5. Виробити правила, які будуть встановлювати і підтримувати цілісність даних.

6. Встановити зв'язки між об'єктами (таблицями і стовпцями), провести нормалізацію таблиць.

7. Спланувати питання надійності даних і, при необхідності, збереження секретності інформації.

Схожа інформація.