База даних - це сумісно використовуваний набір логічно зв'язаних даних ы опис цих даних що призначений для задоволення інформацыйних потреб організації.

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

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

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

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

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

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

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

1.3 Моделі даних

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

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

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

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

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

1.4 Основні визначення

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

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

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

Ключ - елемент даних, котрий дозволяє унікально ідентифікувати окремі екземпляри деякого типу сутності. Наприклад: Для сутності Розклад ключем є атрибут Номер_ чи рейса набір: Пункт_відправлення, Час_вильоту і Пункт_призначення (за умови, що з пункту в пункт вилітає в кожен момент часу один літак).

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

1.5 Типи сутноностей

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

Слабкий тип сутності - тип сутності, існування котрого залежить від будь-якого іншого типу сутності.

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

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

1.6 Про первинні та зовнішні ключі

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

Тепер про зовнішні ключі:

Ш Якщо сутність ЗІ зв'язує сутності А и В, те вона повинна включати зовнішні ключі, що відповідають первинним ключам сутностей А и В.

Ш Якщо сутність У позначає сутність А, те вона повинна включати зовнішній ключ, що відповідає первинному ключу сутності А.

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

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

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

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

Властивості обмежень цілісності в базі даних

1) Обмеження цілісності володіють наступними властивостями:

2) Обмеження цілісності нав'язують правила на рівні таблиці.

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

4) Обмеження до таблиці можуть бути накладені на момент створення таблиці, а також після створення таблиці

Виділяють три групи правил цілісності:

1.Цілісність по сутностях.

2.Цілісність по посиланнях.

3.Цілісність, обумовлена користувачем.

1.8 Реляційна структура даних

Реляційна модель вперше була запропонована Е.Ф.Коддом в 1970 р. в його основоположній статті “Реляційна модель даних для великих сумісно використовуваних банків даних”. В нинішній час публікацію цієї статті принято вважати поворотним пунктом в історії розвитку систем баз даних, хоча варто помітити, що ще раніше булла запропонована модель, основана на множинах. база дані реляційний аccess

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

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

Відношення на доменах D1, D2, ..., Dn (не обов'язково, щоб усі вони були різні) складається з заголовка і тіла.

Заголовок складається з такого фіксованої безлічі атрибутів A1, A2, ..., An, що існує взаємно однозначну відповідність між цими атрибутами Aі і визначальними їхній доменами Dі (і=1,2,...,n).

Кортеж - це строка відносини.

Тіло складається з мінливого в часі безлічі кортежів, де кожен кортеж складається у свою чергу з безлічі пар атрибут-значення (Aі:Vі), (і=1,2,...,n), по одній такій парі для кожного атрибута Aі в заголовку. Для будь-якої заданої пари атрибут-значення (Aі:Vі) Vі є значенням з єдиного домена Dі, що зв'язаний з атрибутом Aі.

Оскільки відношення - це безліч, а безлічі по визначенню не містять співпадаючих елементів, те ніякі два кортежі відносини не можуть бути дублікатами один одного в будь-який произвольно-заданный момент часу. Нехай R - відношення з атрибутами A1, A2, ..., An. Говорять, що безліч атрибутів K=(Aі, Aj, ..., Ak) відносини R є можливим ключем R тоді і тільки тоді, коли задовольняються два незалежних від часу умови:

1.Унікальність: у довільний заданий момент часу ніякі два різних кортежі R не мають того самого значення для Aі, Aj, ..., Ak.

2.Мінімальність: жоден з атрибутів Aі, Aj, ..., Ak не може бути виключений з K без порушення унікальності.

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

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

1.9 Маніпулювання реляційними даними

В алгебрі Кодда мається деcять операцій : об'єднання ( UNION ) , перетин ( INTERSECT ) , віднімання ( MINUS ) , взяття розширеного декартова твори ( TIMES ) , перейменування атрибутів ( RENAME ) , проекція ( PROJECT ), обмеження ( WHERE ), з'єднання ( - JOIN ) , розподіл ( DIVIDE BY ) і присвоювання .

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

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

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

4 ) При виконанні декартова твори ( TIMES ) двох відносин , перетин заголовків яких порожньо, здійснюється ставлення , кортежі якого виробляються шляхом об'єднання кортежів першого і другого операндів.

5 ) Операція перейменування ( RENAME ) виробляє ставлення , тіло якого збігається з тілом операнда , але імена атрибутів змінені ; ця операція дозволяє виконувати перші три операції над відносинами з «майже» співпадаючими заголовками ( співпадаючими у всьому, крім імен атрибутів ) і виконувати операцію TIMES над відносинами , перетин заголовків яких не є порожнім.

6 ) Результатом обмеження ( WHERE ) відносини по деякому умові є ставлення , що включає кортежі відносини - операнда , яке задовольняє цій умові.

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

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

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

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

1.10 Цілі проектування

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

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

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

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

1.11 Нормалізація функціональних та багатозначних залежностей

Кортежі мають бути унікальними. Кожен з кортежів може ідентифікуватися двома способами - власним фізичним ім'ям (номером) та за допомогою ключа. Ключ k - підмножина схеми R, де R - множина імен атрибутів (R={A1, A2, . . . An}), для якої виконується - Ti(k) <> Tj(k), причому i<>j, де T - це кортежі, що визначені на згаданій схемі.

2.2 Вибір первинного ключа

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

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

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

За замовчуванням Microsoft Access сортує дані за первинним ключем;

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

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

2.3 Зв'язки між таблицями

Ё Один - до - багатьох

Ё Один - до - одного

Ё Багато - до - одного

Ё Багато - до - багатьох

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

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

Зв'язок багато-до-одного вказує Microsoft Access, що кілька записів одної таблиці зв'язані з одним записом з іншої таблиці.

Зв'язок багато-до-багатьох: пара зв'язків один-до-багатьох утворює зв'язок багато-до-багатьох.

2.4 Нормалізація

Введемо позначення схеми - R(S,K). В подальшому будемо вважати, що схема відношення R складається з двох частин S і K, де S - множина атрибутів, а К - множина виділених ключів. Нехай U - множина атрибутів, кожен з котрих співвідноситься з визначеним доменом. Схемою реляційної бази даних R над U називається сукупність схем відношень {R1, R2,. . . Rp}, де Ri=(S,K), 1 i p, , и S i Sjпри i j.