Розробка реляційної бази даних "Музей"

Размещено на http://www.allbest.ru/

Міністерство освіти і науки України

Дніпропетровський національний університет

Факультет фізики, електроніки та комп'ютерних систем

Кафедра автоматизованих систем обробки інформації

Курсова робота

« Організація баз даних та знань »

на тему :

«Музей»

Виконала:

Студентка групи КС-10-1

Демура Оксана

Перевірив :

Ст.викл.

Єгоров А.О.

Дніпропетровськ

2013



Анотація

Мета курсової роботи полягає в розробці реляційної БД „Музей”, яка б зберігала усі необхідні дані й автоматизувала процес керування та ведення обліку.

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



Зміст

1. Анотація

2. Зміст

3. Вступ

Теоретична частина

4. Призначення та класифікація систем управління базами даних (СУБД)

5. Реляційна модель даних

6. Цілісність бази даних

7. Надлишковість

8. Нормалізація, нормальні форми та функціональні залежності

9. Алгоритм декомпозиції

10. Найпопулярніші СУБД, Access

11. Зв'язки в Access

12. Запити та форми Access

13. Звіти в Access

14. Макроси в Access

Практична частина

15. Проектування БД "Музей"

16. Висновок

17. Використана література



Вступ

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

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

Звичайно об'єми інформації, з якими доводиться мати справу таким системам, достатньо великі, а сама інформація має достатньо складну структуру.

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

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

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

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

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

В Microsoft Access у якості складових бази даних використовуються об'єкти, до котрих відносяться таблиці, звіти, форми, модулі, запити; кожному з них відповідає певне функціональне призначення. В Microsoft Access є можливість створення додатків на мові програмування Visual Basic, що використовується для баз даних зі складними, розповсюдженими можливостями, котрі не можна створити за допомогою стандартного набору інструментів. Отже маємо два головних етапи розробки бази даних - проектування та практичної реалізації у СУБД Access.



Теоретична частина

Призначення та класифікація систем управління базами даних (СУБД)

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

Рис. 1. Архітектура СУБД

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

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

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

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

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

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

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

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

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

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

Банк даних містить два основних компоненти: базу даних (БД) і систему управління базами даних (СУБД). Базою даних називають сукупність взаємопов'язаних даних деякої предметної галузі, що зберігаються в пам'яті ЕОМ та організовані так, що їх можна використовувати для розв'язування багатьох задач різними користувачами.

БД -- датологічне подання інформаційної моделі предметної галузі.

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

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

Найпопулярніші СУБД, що встановлюються в невеликих організаціях і орієнтовані на роботу з кінцевими користувачами, є Access, FoxPro, Paradox.

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

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

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

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

Реляційна модель баз даних

Реляційна модель баз даних надає можливість маніпулювати над доменами відношень. Для цих цілей існує два види апарата маніпулювання відношеннями: реляційна алгебра (алгебра відношень) і реляційне обчислення (обчислення відношень). маніпулювання відношеннями: реляційна алгебра (алгебра відношень) і реляційне обчислення (обчислення відношень).

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

Реляційне обчислення дозволяє шляхом використання обчислення предикатів та кванторів змінних описувати відношення та операції над ними в вигляді аналітичного виразу або формули.

В реляційній алгебрі використовують п'ять основних операцій: об'єднання, різниця, декартовий добуток, проекція і селекція.

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

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

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

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

Двохвимірні таблиць в математиці отримали назву відношення .

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

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

Як правило, не вказується максимально допустиме число стовпців у таблиці, однак майже у всіх комерційних СКБД ця межа існує і , як правило, складає приблизно 255 стовпців.

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

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

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

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

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

В реляційній моделі зв'язок "багатьох до багатьох" (В:В) указує на те, що декільком значенням елементів даних А відповідає декілька значені елементів даних В. Наприклад, поміж елементами даних "код операції технологічного процесу" і "табельний номер працівника" існує зазначені взаємозв'язок, так як багато операцій технологічного процесу можуть виконувати різні працівники (табельні номери) і навпаки. Реляційна модель даних являє собою набір двомірних плоских таблиць, що складаються з рядків і стовпців. Первинний документ або лінійний масив являє собою плоску двомірну таблицю. Така таблиця називається відношенням, кожний стовбець-атрибутом, сукупність значень одного типу (стовпця) -доменом, а рядка - кортежем. Таким чином, стовпці таблиці являються традиційними елементами даних, а рядки - записами. Таблиці (відношення) мають імена. Імена також присвоюються і стовпцям таблиці. Кожний кортеж (запис ) відношення має ключ. Ключі є прості і складні. Простий ключ-це ключ, який складається з одного атомарного атрибуту, значення якого унікальне (яке не повторюються).Складний ключ складається з двох і більше атрибутів. Для зв'язків відношень друг з другом в базі даних є зовнішні ключі. Атрибут або комбінація атрибута відношення є зовнішнім ключем, якщо він не є основним (первинним) ключем цього відношення, але являється первинним ключем для другого відношення. Основні принципи створення БД: цілісність, вірогідність, контроль, захист від несанкціонованого доступу, єдність і гнучкість, стандартизація та уніфікація, адаптивність, мінімізація введення і виведення інформації (однократність введення інформації, принцип введення - виведення тільки змін).

Цілісність бази даних

Цілісність бази даних [database integrity] -- стан бази даних, коли всі значення даних правильні в тому сенсі, що відображають стан реального світу (в межах заданих обмежень по точності та часовій узгодженості) і підпорядковуються правилам взаємної не суперечливості. Підтримка цілісності бази даних включає перевірку цілісності і відновлення з будь-якого неправильного стану, яке може бути виявлено; це входить у функції адміністратора бази даних.

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

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

Не допускається, щоб який-небудь атрибут, що бере участь в первинному ключі, приймав невизначене значення.

Значення зовнішнього ключа повинне або:

1. бути рівним значенню первинного ключа цілі;

2. бути повністю невизначеним, тобто кожне значення атрибута, що бере участь в зовнішньому ключі повинне бути невизначеним.

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

1. унікальність тих або інших атрибутів;

2. діапазон значень ;

3. приналежність набору значень.

Встановити цілісність даних можна, якщо виконані такі умови:

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

- зв'язані поля мають однаковий тип даних. Тут є й винятки. Так, поле типу Счетчик може бути зв'язане з числовим полем, властивість якого Размер поля (FieldSize) має значення Длинное целое;

- обидві таблиці належать до однієї бази даних MS Access; для визначення цілісності даних ця БД має бути відкрита.

Для встановлення цілісності слід:

- установити покажчик миші на графічному зображенні одного із зв'язків між таблицями на Схеме данных;

- виконати пункти меню Связи\Изменить связь;

За встановлення цілісності даних неможливо:

- ввести до поля зовнішнього ключа зв'язаної таблиці значення, якого немає в ключовому полі головної таблиці;

- вилучити запис з головної таблиці, якщо існують зв'язані з ним записи у підпорядкованій таблиці з боку «много».

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

Надлишковість

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

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

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

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

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

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

Інформаційна ентропія - це міра невизначеності інформації, невизначеність появи якого-небудь символу.

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

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

Нормалізація, нормальні форми та функціональні залежності

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

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

Перша нормальна форма

Перша нормальна форма вимагає, щоб кожне поле таблиці було неподільним і не містило повторюваних груп.

Неподільність означає, що поле даних не повинно поділятися на більш дрібні. Наприклад, якщо мова йде про БД для відділу кадрів, то у таблиці з інформацією про співробітників поле "Прізвище" є неподільним, подільність поля "ПІП" залежить від контексту використання відповідної таблиці. Якщо у процесі експлуатації БД не передбачається використовувати такі запити, як "Обрати всіх Івановичів", то поле ПІП теж можна вважати неподільним. А от адресу краще розділити на вулицю, будинок і квартиру, тобто на 2 чи 3 поля, тоді буде простіше здійснити відюір всіх, то живе на одній вулиці. Хоча, можуть бути випадки, коли його доцільно вважати неподільним (наприклад, якщо адреса є другорядною та рідковживаною інформацією).

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

Друга нормальна форма

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

Дуже простий варіант - створювати поле-лічильник і вказувати його в якості первинного ключа.

Третя нормальна форма

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

Нормальна форма Бойса-Кодда

Відношення знаходиться в нормальній формі Бойса-Кодда тоді і тільки тоді, коли детермінанти є потенційними ключами.

Концепція НФБК дозволяє позбавитися проблем, властивих формам, відповідним визначенню ЗНФ. Більш того, нове визначення концептуально простіше старого, оскільки в ньому не використовуються поняття 1НФ, 2НФ, первинного ключа або транзитивної залежності. Поняття потенційного ключа може бути замінене введенням фундаментальнішого поняття функціональної залежності. З другого боку, концепції первинного ключа, транзитивної залежності і т.д. вельми корисні на практиці, оскільки дозволяють представити ідею поступового процесу, виконуваного розробником для приведення довільного відношення до еквівалентного набору відносин в НФБК.

Схема відношення R з залежностями F знаходиться в нормальній формі Бойса-Кодда, якщо кожен раз, коли в R має місце залежність xA і Ax , х включає деякий ключ R. Іншими словами допукаються тільки такі нетривіальні залежності, в яких ключ функції визначає один або більше інших атрибутів.

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

Метод: декомпозицію r для R конструюємо ітеративним методом. При цьому r весь час буде володіти властивістю з'єднання без втрат відносно F. Якщо S схема ... з r і s не знаходиться в НФБК, то нехай x A - залежність, що має місце в S, де х - не містить ключа S, а А не належить х (A x). Тоді в S повинен існувати деякий атрибут, який не належить А і не належить х. В іншому випадку х повинен містити ключ S. Задінемо S на S1 і S2, де S1 складається з А і атрибутів х (S1={А,х}), а S2 з усіх атрибутів S за виключенням А.

Оскільки в S1 та S2 менше атрибутів ніж в S, ми досягаємо деякого моменту, коли еквівалентна схема відношення r буде знаходитись в НФБК. При цьому r володіє властивістю з'єднання без втрат.

Теорія нормалізації ґрунтується на наявності функціональної залежності між полями таблиці.

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

Алгоритм декомпозиції

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

Нехай R не знаходиться в третій нормальній формі відносно множини F-залежностей F. Необхідно розкласти цю схему бази даних так, щоби вона була приведеною до третьої нормальної форми, тобто нормалізованою. Розклад схеми відношень позначає розбиття схеми відношення на пару схем відношень R1 і R2 (які, можливо, перетинаються) так, щоб будь-яке відношення r (R), що задовольнить F, розкладалося без втрат на R1 і R2. Тобто розбиття відбувається таким чином, що при будь-якому значенні атрибута з dom r - відношення чи проекція ПрR1 (r) *ПрR2 (r) = r для всіх R. Якщо щось з R1 і R2 не буде знаходитися в 3-й нормальній формі, то необхідно буде повторити процес декомпозиції.

Розглянемо дії по розбиванню схем, нехай існує транзитивна залежність від ключа в схемі R. Існує ключ, котрий не є власною підмножиною для схеми R і не первинний атрибут А, що є елементом схеми R, такі, що К > У і У функціонально визначає А. видно, що існує транзитивна залежність. У функціонально не визначає К - виключена умова "один в один". Тоді нехай R1 буде представлене як R1=R-A і R2=YA (розрізаємо транзитивність). А може бути не єдиним атрибутом, а множиною атрибутів. Тоді умова зберігання буде виконуватися, R2 буде знаходитися в 3-й нормальній формі, а R1 може не знаходитися. Це твердження стосується випадку, коли А - окремий атрибут..

Негативні моменти:

1. Нормалізація призводить до збільшення об'єма даних та зв'язків між таблицями.

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

3. Процес декомпозиції може давати неоднозначні результати.

Найпопулярніші СУБД, що встановлюються в невеликих організаціях і орієнтовані на роботу з кінцевими користувачами, є Access, FoxPro, Paradox.

Системою управління базами даних є додаток Access, що входить в Microsoft Office. У Access використовується стандартний для середовища Windows & Offiсе багатовіконний інтерфейс, але на відміну від інших додатків, що не багатодокументний. Одноразово може бути відкрита тільки одна база даних, що містить обов'язкове вікно бази даних і вікна для роботи з об'єктами бази даних. У кожен момент часу одне з вікон є активним і в ньому курсором відзначається активний об'єкт. На рис. 1 зображене головне вікно бази даних, після входа в меню Пуск



Рис. 1. Головне вікно бази даних

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

Таблица 2. Типы данных , использование и их размер

ТИП ДАННЫХ	ИСПОЛЬЗОВАНИЕ	РАЗМЕР
Краткий текст (ранее известный как "Текст")	Алфавитно-цифровые данные (имена, названия и т.д.)	До 255 знаков.
Полный текст (ранее известный как Memo)	Большие объемы алфавитно-цифровых данных: предложения и абзацы.	До 1 гигабайта (ГБ), но контроль отображения полного текста ограничен первыми 64 000 знаков.
Числовой	Числовые данные.	1, 2, 4, 8 или 16 байт.
Date/Time	Значения даты и времени.	8 байт.
Денежный	Денежные данные, хранящиеся с точностью до 4 десятичных знаков после запятой.	8 байт.
AutoNumber	Уникальные значения, сгенерированные Access для каждой новой записи.	4 байта (16 байт для кода репликации).
Yes/No	Логические (истина/ложь) данные. Access хранит числовое значение нуль (0) для лжи и -1 для истины.	1 байт.
Объект OLE	Изображения, графики или другие объекты ActiveX из другого приложения Windows.	До 2 ГБ.
Гиперссылка	Адрес ссылки на документ или файл в Интернете, интрасети, локальной сети или на локальном компьютере	До 8192 (каждая часть типа данных гиперссылки может содержать до 2048 знаков).
Вложение	Можно вкладывать изображения, документы, электронные таблицы или диаграммы. Каждое поле вложений может содержать неограниченное количество вложений на одну запись, вплоть до допустимого размера файла базы данных.	До 2 ГБ.
Вычисляемый	Можно создать выражение, использующее данные из одного или более полей. Из выражения можно назначить различные типы данных результатов.	Зависит от типа данных свойства "Тип результата". Результат типа данных "Краткий текст" может содержать до 243 знаков. Данные типа "Полный текст", "Числовой", "Да/нет" и "Дата/время" должны соответствовать своим типам данных.
Мастер подстановок	Запись "Мастер подстановок" в колонке "Тип данных" в "Конструкторе" фактически не является типом данных. При выборе этой записи запускается мастер, чтобы помочь определить простое или сложное поле подстановки. Простое поле подстановки использует содержимое другой таблицы или списка значений, чтобы проверить правильность содержимого единственного значения в ряду. Сложное поле подстановки позволяет хранить множественные значения одного типа данных в каждом ряду.	Зависит от типа данных поля подстановки.

Зв'язки

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

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

Реляційна база даних може містити велику кількість взаємозв'язаних таблиць. Зв'язку встановлюється між двома загальними полями (стовпцями) двох таблиць. Зв'язувані поля можуть мати різні імена, але повинні мати однакового типа даних за винятком випадку, коли поле первинного ключа є полем типа Лічильник. Поле лічильника зв'язується з числовим полем, якщо значення властивості Розмір поля (FieldSize) обоє полів збігаються. Наприклад, якщо властивість обоє полів має значення Довге ціле. Навіть у тому випадку, коли зв'язуються поля типа «Числовою», їх властивості Розмір поля (FieldSize) повинні мати однакові значення.

Задавши зв'язки між таблицями, можна створити запити, форми і звіти для відображення відомостей, представлених в декількох таблицях. Між двома таблицями можуть існувати наступні зв'язки:

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

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

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

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

Запити та форми Access

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

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

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

Запити дозволяють:

* Відобразити дані з кількох таблиць та відсортувати їх у необхідному порядку;

* Виконати обчислення над групами таблиць;

* Обчислити підсумкові значення, вивести їх в компактному форматі, що є подібним до формату електронної таблиці та багато іншого.

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

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

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

Звіти в Access

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

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

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

- Верхній колонтитул звіту. Ця частина друкується лише один раз, на початку звіту. У ній використовуються дані, які зазвичай розміщуються на титульній сторінці, наприклад емблема, назва або дата. Якщо у верхньому колонтитулі звіту розмістити обчислюваний елемент керування, у якому використовується агрегатна функція Sum, сума обчислюватиметься для всього звіту. Спочатку друкується верхній колонтитул звіту, а потім - верхній колонтитул сторінки.

- Верхній колонтитул сторінки. Ця частина друкується у верхній частині кожної сторінки. Наприклад, він використовується для повторення заголовка звіту на кожній сторінці.

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

Макроси в Access

У програмі Microsoft Access 2010 макроси, підключені до об'єктів інтерфейсу користувача, зокрема кнопок, текстових полів, форм і звітів, називають макросами інтерфейсу. Це відрізняє їх від макросів даних, які підключаються до таблиць. Макроси інтерфейсу використовуються для автоматизації ряду дій, зокрема відкриття інших об'єктів, застосування фільтрів, початку операцій експорту тощо. Макроси можуть міститися в об'єктах макросу (які іноді називають ізольованими макросами) або можуть бути вбудовані у властивості подій форм, звітів чи елементів керування. Вбудовані макроси стають частиною об'єкта або елемента керування, у які їх вбудовано. Об'єкти макросу відображаються в області переходів у розділі Макроси; вбудовані макроси не відображаються. Кожен макрос складається з однієї або кількох дій макросів. Залежно від ситуації, деякі дії макросів можуть бути недоступні для використання. Зокрема, під час конструювання веб-бази даних не можна використовувати певні дії макросів, не сумісні з функцією "Публікування у службах Access Services".

Макрос (macro) служить для автоматизації виконання операції, що часто повторюється. Він створюється в результаті вибору із списку можливих дій (макрокоманд), які виконуються послідовно або в заданому порядку. Наприклад, натискує кнопки, можна запустити макрос, який відкриє, роздрукує і закриє звіт.

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



Практична частина

Microsoft Access об'єднує зведення з різних джерел в одній реляційної базі даних. Утворювані форми, запити і звіти дозволяють швидко й ефективно обновляти дані, одержувати відповіді на питання, здійснювати пошук потрібних даних, аналізувати дані, друкувати звіти.

Було дано початкове раеляційне відношення «Експонати в музеї»: (Название экспоната, Тип экспоната, Год создания экспоната, Эпоха, Техническое состояние, Длина и Висота експоната, Название зала, Фото експоната, Описание экспоната). З метою мінімізації надлишковості, шляхом декомпозиції, було отримано 5 реаліційних відносин: «Зали музею», «Технічний стан експонатів», «Типи експонатів», «Епохи».

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

Проектування БД "Музей"

Запишемо визначені ключі, функціональні залежності та множину атрибутів.

R={Индекс экспоната, Название экспоната, Тип экспоната, Год создания експоната, Эпоха, Техническое состояние, Длина експоната, Высота експоната, Залы, Фото экспоната, Описание экспоната, Индекс эпохи, Название эпохи, Описание эпохи, Индекс типа експоната, Название типа експоната, Информация о типе, Код состояния, Техническое состояние, Информация о состоянии, Индекс зала, Название зала, Панорама зала };

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

Множина функціональних залежностей F :

Индекс экспоната (Название экспоната, Тип экспоната, Автор, Год создания экспоната, Эпохи, Техническое состояние, Длина экспоната, Высота экспоната, Залы, Фото экспонат, Описание экспоната);

Индекс зала (Название зала, Панорама зала);

Индекс эпохи (Название эпохи, Описание эпохи);

Индекс типа экспоната (Название типа экспоната, Информация о типе);

Код состояния (Техническое состояние, Информация о техническом состоянии);

Процес нормалізації при побудові БД "Музей"

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

Приведемо схему відношень R до III нормальної форми. Для цього використаємо алгоритм декомпозиції:

Индекс зала - Название зала, Панорама зала & Индекс экспоната - Название экспоната, Тип экспоната, Год создания экспоната, Эпохи, Техническое состояние, Длина экспоната, Высота экспоната, Залы, Фото экспонат, Описание экспоната.

В результаті отримаємо дві нових схеми відношень:

R12={ Индекс экспоната, Название экспоната, Тип экспоната, Год создания експоната, Эпоха, Техническое состояние, Длина експоната, Высота експоната, Залы, Фото экспонат, Описание экспоната, Индекс эпохи, Название эпохи, Описание эпохи, Индекс типа експоната, Название типа експоната, Информация о типе, Код состояния, Техническое состояние, Информация о состоянии };

K12={Индекс экспоната / Код состояния / Индекс типа экспоната / Индекс эпохи}.

R2={Индекс зала, Название зала, Панорама зал};

K2={ Индекс зала }.

При цьому функціональна залежність 2 перейшла до схеми R2. Для схеми R2 умова III нормальної форми виконується.

Индекс эпохи - Название эпохи, Описание эпохи & Индекс экспоната - Название экспоната, Тип экспоната, Год создания экспоната, Эпохи, Техническое состояние, Длина экспоната, Высота экспоната, Залы, Фото экспонат, Описание экспоната

В результаті отримаємо дві нових схеми відношень:

R13={ Индекс экспоната, Название экспоната, Тип экспоната, Год создания експоната, Эпоха, Техническое состояние, Длина експоната, Высота експоната, Залы, Фото экспонат, Описание экспоната, Индекс типа експоната, Название типа експоната, Информация о типе, Код состояния, Техническое состояние, Информация о состоянии };

K13={ Индекс экспоната / Код состояния / Индекс типа экспоната}.

R3={ Индекс эпохи, Название эпохи, Описание эпохи };

K3={ Индекс эпохи }.

При цьому функціональна залежність 3 перейшла до схеми R3. Для схеми R3 умова III нормальної форми виконується.

Индекс типа экспоната - Название типа экспоната, Информация о типе & Индекс экспоната - Название экспоната, Тип экспоната, Год создания экспоната, Эпохи, Техническое состояние, Длина экспоната, Высота экспоната, Залы, Фото экспонат, Описание экспоната

В результаті отримаємо дві нових схеми відношень:

R14={ Индекс экспоната, Название экспоната, Тип экспоната, Год создания експоната, Эпоха, Техническое состояние, Длина експоната, Высота експоната, Залы, Фото экспонат, Описание экспоната, Код состояния, Техническое состояние, Информация о состоянии };

K14={ Индекс экспоната / Код состояния}.

R4={ Индекс типа экспоната, Название типа экспоната, Информация о типе};

K4={ Индекс типа экспоната }.

При цьому функціональна залежність 4 перейшла до схеми R4. Для схеми R4 умова III нормальної форми виконується.

Код состояния - Техническое состояние, Информация о техническом состоянии & Индекс экспоната - Название экспоната, Тип экспоната, Год создания экспоната, Эпохи, Техническое состояние, Длина экспоната, Высота экспоната, Залы, Фото экспонат, Описание экспоната

В результаті отримаємо дві нових схеми відношень :

R1={ Индекс экспоната, Название экспоната, Тип экспоната, Год создания экспоната, Эпохи, Техническое состояние, Длина экспоната, Высота экспоната, Залы, Фото экспонат, Описание экспоната };

K1={ Индекс экспоната }.

R2={ Код состояния, Техническое состояние, Информация о техническом состоянии };

K2={ Код состояния }.

В результаті нормалізації вихідної схеми R, отримали 5 нормалізованих відношень. Базу даних подану такими відношеннями можна вважати реляційною.

Схема даних

Зв'язки між таблицями організовані відповідно до результатів проведеного алгоритму нормалізації, схема даних складається з 5 таблиць та має вигляд зображений на рис. 1. При побудові схеми даних Access автоматично визначає по вибраному полю тип зв'язку між таблицями. Якщо поле, по якому потрібно встановити зв'язок, є унікальним ключем, як в головній таблиці, так і в підпорядкованій, Access встановлює зв'язок типу один до одного. Якщо поле зв'язку є унікальним ключем в головній таблиці, а в підлеглій таблиці є не ключовим або входить у складений ключ, Access встановлює зв'язок типу один до багатьох від головної таблиці до підлеглої, в даному випадку головною таблицею являється таблиця «Главная» .



Рис. 1 Типи зв'язків між таблицями в базі даних „Музей”

Поле „Индекс типа экспоната”, таблиця „Тип экспоната” пов'язане з полем „Тип экспоната”, таблиця „Главная”. Тип зв'язку - один до багатьох. Тип зв'язування - внутрішнє.