Робота з базами даних 2

Зміст

Введення. Поняття інформації та інформаційної системи. Вимоги до організації даних

Глава 1. Бази даних

1.1 Моделі баз даних

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

1.1.2 Ієрархічна модель

1.1.3 Мережева модель

1.1.4 Об'єктно-орієнтована модель даних

1.2 Теорія нормальних форм

1.3 Достовірність і безпека інформації

Глава 2. Основи розробки бази даних

2.1 Методи проектування БД

2.1.1 Метод декомпозиції

2.1.2 Метод синтезу

2.1.3 Метод об'єктної зв'язку

2.2 Організація СУБД

2.2.1 Вимоги до сучасної СУБД

2.2.2 Архітектура СУБД

2.2.3 Робота СУБД

2.3 Організація даних

2.3.1 Фізична організація даних

2.3.2 Організація індексних таблиць

2.4 Оновлення і відновлення даних

2.4.1 Типи ключових полів

2.4.2 Створення та зміна ключових полів

2.5 БД в мережах

2.6 Доступ до даних у Windows

Глава 3. Робота з таблицями бази даних на прикладі СУБД Microsoft Access

3.1 Структура таблиці, її створення

3.1.1 Створення нової порожній таблиці

3.1.2 Створення таблиці в режимі конструктора

3.2 Ключі та індекси

3.2.1 Типи ключових полів

3.2.2 Індекси

3.2.3 Створення та зміна ключових полів

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

3.3.1 Обмеження в базі даних

3.3.2 Типи обмежень у базі даних

3.3.3 Підтримка цілісності даних

Висновок

Введення. Поняття інформації та інформаційної системи. Вимоги до організації даних

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

Інформаційні системи (ІС) можна умовно розділити на фактографічні та документальні.

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

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

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

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

• Ім'я;

• Дата народження у форматі ДД.ММ.РРРР;

• Національність (російська або іноземець);

• Біографія (довільний текст);

• Назви праць вченого.

Вимоги до організації даних інформаційних систем:

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

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

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

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

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

У даній роботі розглядаються фактографічні ІС, які використовуються буквально у всіх сферах людської діяльності, а практика роботи з ними буде розглянута на прикладі сучасної системи управління базами даних (СКБД) Microsoft Access.

Глава 1. Бази даних

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

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

• За допомогою алгоритмічних мов програмування, таких як Basic, Pascal, C + + і т.д. Даний спосіб застосовується для створення унікальних баз даних.

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

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

В даний час існує декілька видів СУБД. Найбільш відомими і популярними СУБД є Access, FoxPro і Paradox.

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

Властивості можуть бути:

у часі:

1. статичні;

2. динамічні;

за структурою:

1. неподільні (атомарні);

2. складові.

Байт - найменша одиниця адресованих бітів.

Елемент даних - найменша одиниця пойменованих даних, називають полем.

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

Приклад:

Тип об'єкта (запису) "СПІВРОБІТНИК".

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

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

1. Моделі баз даних

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

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

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

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

1. допустимої структурою даних, різноманітністю та кількістю типів даних, які можна описати за допомогою МД;

2. безліччю допустимих операцій над даними;

3. обмеженнями контролю цілісності.

Залежно від підтримуваної структури даних, МД поділяються на:

1. мережні;

2. ієрархічні;

3. реляційні.

Більшість БД реляційні.

1. Реляційна модель

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

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

• Кожен елемент таблиці - один елемент даних.

• Всі поля в таблиці є однорідними, тобто мають один тип.

• Кожне поле має унікальне ім'я.

• Однакові запису в таблиці відсутні.

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

_{Реляційна таблиця - безліч відносин містять всю необхідну інформацію про предметну область.}

Відношення реляційної БД в залежності від вмісту підрозділяється на два класи:

1. об'єктні;

2. пов'язані.

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

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

Зв'язок між об'єктами зазвичай виражається дієсловами: "Службовці працюють у відділах". Тому назва таблиці зв'язків часто дають по імені зв'язку або в назві вказують імена об'єктів беруть участь у зв'язку.

Відмітна ознака об'єкта:

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

Приклад:

СТУДЕНТ (СТ #, ПІБ, Група, Адреса);

ПРЕДМЕТ (П #, Назва, Вид контролю);

ВИВЧАЄ (СТ #, П #, Оцінка).

Допустимі і недопустимі зв'язку.

Приклад:

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

Три таблиці:

Зв'язки:

Співробітники - Проекти. Співробітники - Відділ.

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

Якщо прибрати зв'язок СПІВРОБІТНИКИ - Проекти, щось зміниться постановка завдання, тоді проекти

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

Співробітники не закріплені за відділами і вільно переходять у відділ зайнятий їх проектом.

Реляційні моделі зв'язків не можуть замикатися, які зв'язки заборонені, а які дозволені, залежить від постановки завдання. Для двох об'єктів можлива один зв'язок, для трьох - дві, а для n - (n -1). Для моделі з n об'єктів необхідно (2 n -1) об'єктів.

Робота з БД має на увазі завдання і виконання запитів.

Приклад:

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

1. реляційної алгебри;

2. реляційному численні.

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

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

Реляційна модель крім РА може також включати операції реляційного присвоювання Target: = Source, де ліві і праві частини - реляційні вирази, які подають сумісні за типом відносини. Target - базове ставлення.

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

Зауваження: мова РА не застосовується. Використовується мова реляційного числення.

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

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

Розглянемо дві мови, широко використовуються в СУБД: SQL і QBE.

Мова Структурних Запитів (SQL)

SQL розроблений фірмою IBM. Схвалено в якості стандарту для великих і малих ЕОМ. Якщо D - Base орієнтована на операції з даними у вигляді запису, то SQL - на операції з даними, у вигляді таблиць. Крім звичайних таблиць SQL дозволяє створювати особливий тип таблиць - вибірку (підмножина рядків і стовпців з однієї або декількох таблиць). Часто вибірку називають віртуальною таблицею.

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

1. кошти запитів;

2. засоби маніпулювання даними;

3. засоби визначення даних;

4. засоби контролю даних;

5. кошти вбудовування в основну мову.

Засоби запитів

Більшість запитів на вилучення даних з БД будується на основі команди SELECT.

SELECT <список атрибутів і / або функцій від атрибутів>

FROM <список відносин>

WHERE <умова>

GROUP BY <список колонок>

HAVING <умова>

ORDER BY <список сортування>

TO FILE | TO PRINTER | TO SCREEN | INTO

Принципова схема виконання запиту:

1. утворюється декартово твір таблиць, перелічених у FROM;

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

3. якщо задано GROUP BY, то що залишилися рядка діляться на групи відповідно значенням зазначених у ній колонок;

4. для кожної групи або рядка обчислюється вираз, заданий у фразі SELECT;

5. для кожної групи проводиться перевірка умов заданого фразою HAVING, варіанти з false видаляються;

6. результат сортується по колонках з ORDER BY, відповідно до заданого порядком сортування.

У рядку SELECT вказуються через кому імена стовпців у вихідний таблиці. Символ "*" означає, що вибираються всі стовпці, зазначені в пропозиції FROM. Якщо в кількох таблицях є колонки з однаковим ім'ям, то перед цими іменами вказуються імена таблиці, розділені ".". Щоб вивести всі стовпці таблиці, можна вказати <ім'я таблиці>; .*. Для того, щоб вивести лише унікальні стовпці таблиці, використовують слово DISTINCT <стовпці>. Пропозицією SELECT можна задавати висновок символьного виразу і так само обчислюється колонку (віртуальну).

Приклад:

SELECT Tab_No, Fam, Oklad + Prem AS "оклад + премія".

У команді SELECT можна використовувати спеціальні агрегатні функції:

COUNT () - кількість відображуваних рядків.

SUM () - підсумовує значення числових стовпців

MIN () - знаходить мінімум числового стовпця

MAX () - знаходить максимум числового стовпця

AVG () - знаходить середнє значення числової колонки, в дужках назву стовпця.

Приклад:

SELECT SUM (Oklad);

SELECT Name, SUM (Cena * Kol-vo) AS "Сума";

SELECT COUNT (*);

SELECT MAX (Oklad), MIN (Oklad), AVG (Oklad).

Для відбору рядків по заданому критерію використовують пропозицію WHERE:

Приклад:

SELECT ім'я покупця

FROM замовлення

WHERE Вид # = 139

Предикат IN в неявному вигляді замінює квантор існування.

Приклад:

WHERE X IN P (X) (еквівалентно $ xP (x))

WHERE X NOT IN P (X) (еквівалентно "x Ø P (x))

Безліч, задається в реченні IN (), можна визначити не тільки перерахуванням її елементів, але і побічно, використовуючи вкладений підзапит:

Приклад:

WHERE X IN (SELECT ... FROM ...)

Предикат LIKE здійснює вибір на включаються надбудови, що задається змінною або константою. Підрядок визначається заданими символами, заміщеними "-" (заміщає один символ) і "%" (будь-яке число символів):

Приклад:

WHERE ПІБ LIKE "ПЕТ%"

У пропозиції WHERE предикати BETWEEN, IN, LIKE можуть об'єднуватись зв'язками AND, OR, NOT.

Два додаткових пропозиції GROUP BY і HAVING дозволяють розташовувати рядки по групах. Потім можна виконувати операції з цими групами. Наприклад, використовувати операцію агрегування.

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

Пропозиція HAVING дозволяє відображати складові групи рядків, що задовольняють заданим умовам. Дія HAVING аналогічне WHERE, але визначає умову, якій повинна задовольняти кожна група для виведення результуючої таблиці. Наприклад, для виведення впорядкованого за алфавітом переліку деталей вартістю понад 300р., Наявних на складі в кількості більше 10 шт., Можна використовувати команду SELECT.

SELECT <номер>, SUM (<кількість>), <вартість>, <назва>

FROM <склад>

WHERE <вартість>> 300

GROUP BY <назва>, <номер>, <вартість>

HAVING SUM (<кількість>)> 10

ORDER BY <назва>

Якщо HAVING використовується без GROUP BY, то його дія поширюється на всю таблицю і еквівалентно WHERE.

ORDER BY '<колонка | ціле число [ASC, DESC]>'

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

Особливості мови SQL

1. фактичний - стандарт звернення до сучасних БД;

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

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

Об'єкти сучасних реляційних БД

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

Представлення

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

CREATE VIEW <ім'я подання>

[(<Ім'я поля> [, <ім'я поля> ...])]

AS SELECT

FROM

WHERE

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

Синоніми

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

CREATE TABLE Primer,

тоді Петро може використовувати таблицю Ivan. Primer. щоб уникнути довгих звернень, Петро може створити синонім

CREATE SYNONYM P1 FOR Ivan.Primer

і звертатися до таблиці через P 1.

Ім'я Р1 є приватним для користувача Петра. Інший користувач може створити власний синонім. Опис усіх таблиць, уявлень, синонімів зберігається в спеціальному каталозі.

Каталог

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

SYS TABLES - таблиці й подання. Зазвичай містять поля:

Name - ім'я таблиці;

Creator - ім'я користувача;

ColCount - кількість стовпців.

SYS COLUMNS - колонки БД. У кожному рядку цієї таблиці міститься інформація про стовпці будь-якої таблиці. Для цього служать поля

Name - ім'я стовпця;

TBName - ім'я таблиці;

ColType - тип даних для стовпця.

SYS INDEX - будь-якому індексу в системі відводиться один рядок у таблиці. Для кожного індексу в ній зазначено його ім'я, ім'я індексного таблиці TBName, ім'я користувача і т.д.

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

Приклад:

SELECT FROM SYSIBM.SYS COLUMNS WHERE Creator =''

Збережені програми та процедури

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

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

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

Використання збережених команд і процедур переслідує такі цілі:

1. Підвищення продуктивності;

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

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

Тригери

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

Тригери використовуються для вирішення трьох основних завдань:

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

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

3. Реєстрація змін даних. Творець таблиці, або адміністратор БД може побажати мати інформацію про час кожної зміни даних у таблиці, а також який користувач ... Для цього він створює тригер, який надходить в системний час операції UPDATE ім'я користувача. Процедура тригера потім вводить цю інформацію в спеціальну таблицю реєстрації змін. Тригер може бути визначений для виконання або перед операцією (BEFORE), або після (AFTER) INSERT, UPDATE, DELETE.

Формат команди

CREATE TRIGGER ON <ім'я таблиці>

FOR DELETE | UPDATE | INSERT

AS <логічний вираз>

<Логічний вираз> - задає вираз, визначається для вираження тригера. Параметром логічного виразу може бути функція або збережена процедура, яка повертає логічне вираження.

2. Ієрархічна модель

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

де A, B, C, D, E - типи записів (сегменти)

з'єднуються за допомогою зв'язку з одним вузлом більш високого рівня.

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

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

Властивості ієрархічної моделі даних:

• Кілька вузлів нижчого рівня пов'язано тільки з одним вузлом вищого рівня.

• Ієрархічне дерево має тільки одну вершину (корінь), не підпорядковану ніякий інший вершині.

• Кожен вузол має своє ім'я (ідентифікатор).

• Існує тільки один шлях від кореневої запису до більш приватної запису даних.

Особливості ієрархічної моделі даних

• Дані організовані в ієрархічній структурі;

• При відображенні мережевих структур необхідно дублювання даних і заходи з підтримки семантичної цілісності;

• Основна одиниця обробки - запис;

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

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

Операції над даними:

1. Витягти за значенням ключа;

2. Запам'ятати;

3. Оновити;

4. Видалити.

3. Мережева модель

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

Кожну мережеву структуру можна представити у вигляді ієрархічної моделі, але при цьому мережа потребує перетворення:

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

Особливості мережевої моделі

• Дозволяє встановлювати кілька ознак однаково спрямованих групових відносин між двома типами запису;

• Допускає циклічні структури.

Можливі операції над даними

1. Запам'ятати - занести новий запис у БД і автоматично включити її в групове відношення (ГО), де вона оголошена підпорядкованої відповідних режимів включення;

2. Включити - дозволяє підпорядковану запис зв'язати із записом-власником;

3. Поміняти - переключити підпорядковану запис на іншого власника в тому ж ГО;

4. Виключити - розриває зв'язок між власником і підпорядкованої записом, зберігши обидва записи в БД.

Кожен тип ГО характеризується:

1. способом упорядкування підпорядкованої запису (ПЗ)

2. a) довільний;

б) хронологічний;

в) обратнохронологіческій;

г) сортований;

3. режимом включення ПЗ

а) автоматичний - підлегла запис включається у відношення одночасно із запам'ятовуванням в БД, тобто відбувається автоматичне закріплення ПЗ за її власником;

б) при ручному - дозволяє запам'ятати ПЗ в БД, а не включати відразу в ГО;

4. режимом виключення ПЗ вводиться поняття класу приналежності

Для мережевої моделі:

a) фіксований - ПЗ жорстко закріплюється за власником і не може існувати без нього (поет і твір). При видаленні запису-власника (ЗВ) система автоматично видаляє ПЗ;

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

в) необов'язковий - дозволяє виключити ПЗ з примірника ГО, але зберегти її в БД, не прикріплюючи до іншого власника.

Основні особливості обробки даних в мережевих моделях

1. Обробка може бути розпочата з запису будь-якого типу, незалежно від її розташування в структурі БД;

2. Від витягнутої запису можливі переходи, як до її підлеглим записів, так і до тих, яким вона підпорядкована;

3. Основна структурна одиниця - набір, одиниця обробки - запис.

2. Об'єктно-орієнтована модель даних

На даний момент часу до кінця не розроблена.

1. Теорія нормальних форм

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

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

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

1. Однозначна ідентифікація запису: запис повинна однозначно визначатися значенням ключа.

2. Відсутність надмірності: ніяке полі не можна видалити з ключа, не порушуючи при цьому властивості однозначної ідентифікації.

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

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

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

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

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

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

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

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

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

Склад атрибутів відносин БД повинен відповідати двом основним вимогам:

1. Між атрибутами не повинно бути небажаних функціональних залежностей (ФЗ);

2. Угруповання атрибутів повинна забезпечувати мінімальну дублювання даних.

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

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

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

I нормальна форма

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

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

Відношення знаходиться в першій нормальній формі (НФ), якщо всі атрибути прості (атомарні) і немає повторюваних груп. Ставлення в I НФ має бути перш за постановки питання про розбивку на два або більше відносин, тобто до I НФ необхідно привести універсальне відношення.

Універсальне відношення - відношення, до складу якого входять всі атрибути проектованої БД.

Приклад:

Співробітники

ПІБ	Таб. №	Відділ	Тел.	Діти
				Ім'я	Вік
Борисов Борисов	211 211	СС СС	3-57 3-57	Іван Міша	10 15
Андрєєв Андрєєв	364 364	УП УП	2-15 2-15	Маша Єгор	6 4

II нормальна форма

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

Щоб привести ставлення до 2 НФ необхідно:

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

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

Приклад:

Універсальне відношення "Співробітник" розбивається на два відношення:

Співробітники Діти

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

1. Має місце дублювання інформації для співробітників одного відділу;

2. Існує проблема контролю надмірності, оскільки зміна номера телефону відділу веде до необхідності пошуку і заміни номерів співробітників відділу;

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

Таким чином, ставлення в II НФ також може зажадати подальших перетворень.

III нормальна форма

Ставлення перебувати в III НФ, якщо воно знаходиться в II НФ і в ньому відсутня Транзитивне залежність неключових атрибутів від ключа.

Для перетворення до III НФ необхідно побудувати кілька проекцій.

Приклад:

(У нашому випадку - відношення "Співробітник" розбити на два: Відділ - Тел.,

Таб. № - ПІБ - Відділ).

У підсумку отримали три таблиці: "Співробітники", "Відділ", "Діти"

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

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

Посилена III нормальна форма (Бойса-Кодда) НФБК

Ставлення знаходяться в НФБК, якщо воно знаходиться в III НФ, і в ньому відсутні залежності ключів від не ключових атрибутів.

Нехай є відношення R (А, В, С) з ключем К = {А, В}. Між атрибутами цього відносини існують ФЗ А, В ® С і С ® В:

А, В ® З - залежить від ключа

З ® В - залежність ключа від не ключових атрибутів

Приклад:

А - адреса, В - місто, С - індекс;

Проект (Деталь #, Проект #, Постачальник #);

Дет #, Пр # ® Пост #, Пост # ® Пр #

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

Для приведення до НФБК необхідно виконати

1. ;

2. .

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

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

IV нормальна форма

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

Наприклад, для відношення викладач Препод (ПІБ, група, предмет) при появі у викладача нової групи у відношення доводиться додавати не один кортеж, а стільки, скільки предметів він читає в цій групі. Аналогічна ситуація виникає при додаванні в ставлення нового предмета.

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

У нашому випадку "Препод" розбивається на:

Предмет (ПІБ, предмет)

Група (ПІБ, група)

2. Достовірність і безпека інформації

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

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

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

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

Існують різні аспекти безпеки:

• правовий;

• фізичний;

• апаратне забезпечення;

• безпеку БД.

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

Виборче управління доступом.

Для визначення правил безпеки потрібно використовувати деякий мову:

CREATE SECURITY RULE <правило>

GRANT <список привілеїв>

ON <вираз>

TO <список користувачів>

[ON ATTENTED VIOLATION <дію>]

<Правило> - ім'я нового правила безпеки;

<Список привілеїв> може бути представлений:

RETRIEVE [<список атрибутів>]

INSERT

UPDATE [<список атрибутів>]

DELETE

ALL

<Вираз> - має на увазі вислів реляційного числення, в якому задано діапазоном дію даного правила. Діапазоном є деяка підмножина кортежів єдиного відносини.

<Дію> - процедура довільної складності, наприклад, заблокувати клавіатуру, записати порушення правил безпеки. Тобто виконати відстеження загроз.

Приклад:

CREATE SECURITY RULE Пс3 / / створення правил секретності

GRANT RETRIEVE (У #, ЛФУ, Разр), DELETE

ON Вузол WHERE ЛФУ <> "Суматор"

TO Іванов, Петров, Сидоров / / для користувачів

ON ATTENTED VIOLATION REJECT / / не виконувати при порушенні цього правила

У системі повинен бути передбачений спосіб усунення існуючих правил безпеки.

DESTROY SECURITY RULE

Обов'язкове управління доступом

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

Можна сформулювати два простих правила:

1. Користувач А має доступ до об'єкта В, якщо його рівень доступу більше або дорівнює рівню класифікації об'єкта;

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

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

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

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

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

1. Розбийте відкритий текст на блоки, довжина яких дорівнює довжині ключа шифрування. нехай у якості відкритого тексту дана рядок:

AS KINGFISHERS CATCH FIRE

ключ: ELIOT

розбивка: "AS_KI", "NGFIS", "HERS_", "CATCH", "_FIRE"

2. Замініть кожен символ відкритого тексту цілим числом в діапазоні від 0 до 26, використовуючи для прогалин число 00. У результаті вийде рядок чисел

0119001109 1407060919 0805181900 0301200308 0006091805,

ключ: 0512091520.

3. Значення для кожного символу в кожному блоці відкритого тексту підсумуйте з відповідними значеннями кожного символу ключа шифрування по модулю 27.

Для нашого прикладу отримаємо

0604092602 1919152412 1317100620 0813021801 0518180625

4. Замініть кожне число в рядку відповідним текстом символів:

"FDIZB", "SSOXL", "MQJFT", "HMBRA", "ERRGY"

зашифрований текст: FDIZBSSOXLMQJFTHMBRAERRGY

Якщо ключ відомий, розшифровка може бути виконана досить швидко.

Глава 2. Основи розробки бази даних

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

• Наочність подання інформації;

• Простота введення інформації;

• Зручність пошуку та відбору інформації;

• Можливість використання інформації, введеної в іншу базу;

• Можливість швидкого перенастроювання бази даних (додавання нових полів, нових записів, їх видалення).

При розробці БД можна виділити наступні етапи роботи.

I етап. Постановка проблеми

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

II етап. Аналіз об'єкта

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

III етап. Синтез моделі

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

IV етап. Способи подання інформації, програмний інструментарій

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

• З використанням форм;

• Без використання форм.

Форма - створений користувачем графічний інтерфейс для введення даних у базу.

V етап. Синтез комп'ютерної моделі об'єкта і технологія його створення

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

Стадія 1. Запуск СУБД, створення нового файлу бази даних або відкриття створеної раніше бази

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

Стадія 2. Створення вихідної таблиці або таблиць.

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

Стадія 3. Створення екранних форм.

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

Стадія 4. Заповнення БД.

Процес заповнення БД може проводитися у двох видах: у вигляді таблиці і у вигляді форми. Числові і текстові поля можна заповнювати у вигляді таблиці, а поля типу МЕМО і OLE - у вигляді форми.

VI етап. Робота із створеною базою даних

Робота з БД включає в себе такі дії, як:

• Пошук необхідних відомостей;

• Сортування даних;

• Відбір даних;

• Висновок на друк;

• Зміни та доповнення даних.

Розглянемо всі етапи створення та принципи роботи з базами даних на прикладі СУБД Microsoft Access.

2.1 Методи проектування реляційної БД

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

Існує кілька підходів до проектування РБД.

1. Декомпозиція (для невеликих БД);

2. Синтез;

3. Використання моделі об'єкта зв'язку (метод ER-діаграм).

2.1.1 Метод декомпозиції

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

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

Детермінант - якщо А => В - ФЗ і В не залежить функціонально від будь-якої підмножини А, то говорять, що А є детермінант В.

Більшість потенційних аномалій в БД буде усунуто при декомпозиції будь-якого відношення в НФБК.

Відношення знаходиться в НФБК, якщо і тільки якщо кожен детермінант відносини є можливим ключем.

Приклад:

1. Функціональні залежності:

2. Діаграма ФЗ:

З діаграми видно, що УО на знаходиться ні в 2НФ, ні в 3НФ.

Розташуємо поруч перелік всіх детермінантів і всіх можливих ключів.

Можливий ключ	Детермінант
1. Таб №, Імя_Р	Таб №, Імя_Р, ПІБ Відділ Таб № Телефон

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

Загальний підхід декомпозиції полягає у наступних кроках:

1. Розробка універсального відносини БД; для збудованого УО знаходиться первинний ключ.

2. Визначення всіх ФЗ між атрибутами відносини;

1. Визначення того, чи знаходиться ставлення в НФБК, якщо так, то проектування завершується, якщо ні, то ставлення має бути розбите на два.

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

Розбиття відносини на два відносини на кроці 2) здійснюється за наступним правилом.

Нехай ставлення не знаходиться в НФБК. Визначається ФЗ, наприклад, , Яке є причиною того, що r не знаходиться в НФБК, тобто С є детермінантою але не є можливим ключем.

Створюються два нових відносини, і , Де залежна частина була виділена з відносини і опущена при формуванні ставлення r 1, і повністю використана при формуванні ставлення r2. Тепер потрібно перевірити, чи знаходиться отримане ставлення в НФБК. Про ставлення кажуть, що воно є проекцією відносини r. Цей тип декомпозиції називається декомпозицією без втрат.

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

Це правило можна сформулювати й так: слід уникати вибору ФЗ, права частина якої сама (цілком або частково), є детермінантою інший ФЗ.

Відношення, що отримується в результаті декомпозиції, повинен задовольняти вимогам:

1. Можливість відновити в точності вихідне відношення шляхом природного з'єднання відносин - результатів декомпозиції;

2. Збереження всіх ФЗ вихідного відносини.

Нехай у відношенні r зі схемою R є безліч ФЗ. Кажуть, що схема R розкладені без втрат на відносини із збереженням ФЗ, якщо для будь-якого кортежу . Кортеж може бути відновлений



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

Умови розкладання без втрат:

а) для розкладання, що складається з двох відносин. Якщо відношення R 1 і R 2 є розкладанням зі збереженням безлічі ФЗ, це розкладання забезпечує з'єднання без втрат, якщо або . Тут операції "Ç" і "-" визначені над списками атрибутів відносин. Це правило можна сформулювати по-іншому: відсутність втрат при декомпозиції гарантується, якщо від загальної атрибуту двох одержуваних відносин залежить хоча б один атрибут з двох, що залишилися.

б) для розкладання, що складається більш ніж з двох відносин (метод табло). Процедура полягає в побудові таблиці, рядками якої є імена, отримані при декомпозиції відносин, а стовпці - список атрибутів цих відносин без повторень. Таблиця заповнюється символами , Якщо елемент i-го рядка в j-му стовпці відповідає атрибуту Aj щодо Ri, в іншому випадку нічого не ставиться. Після заповнення таблиці слід ітеративний перегляд всіх ФЗ . Якщо для атрибутів з Х знайдуться рядки, де у відповідних місцях стоять aj, то порожні елементи цих рядків, що відповідають стовпцям атрибутів з Y, замінюються на aj *. Якщо в результаті з'явиться рядок таблиці, заповнена повністю aj і aj *, то дане з'єднання без втрат. В іншому випадку - з втратами.

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

2.1.2 Метод синтезу

Відзначимо ще одне важливе правило, що лежить в основі методу синтезу.

Всі ФЗ з однаковими детермінантами потрібно виділяти в одну групу і кожній такій групі відводити свої власні відносини. Отримувані відносини перевіряються на відповідність до НФБК.

Цей прийом слід застосовувати в тому випадку, коли використання методу декомпозиції може призвести до втрати ФЗ, наприклад, при виділенні з залежно будуть отримані відносини і , Жодне з яких не буде містити залежність . У цьому випадку метод декомпозиції не працює.

Правильно (метод синтезу): ,

Використання описаного вище правила декомпозиції може бути ускладнене присутністю надлишкових ФЗ (ИФЗ).

ИФЗ - залежність, не містить у собі такої інформації, яка не могла б бути отримана на основі інших залежностей, використаних при проектуванні БД.

Оскільки ИФЗ не містить унікальної інформації, вона може бути вилучена з набору ФЗ. ИФЗ видаляється до початку проектування (тобто декомпозиції).

Виникнення ИФЗ пов'язане з:

1. наявністю транзитивних залежностей;

2. додаванням.

Приклад:

a) Вихідний набір ФЗ Після видалення ИФЗ



b) Ця форма надмірності має декілька видів:

1. Якщо , То є правильною, але надлишкової;

2. Якщо , То надмірна.

Розглянуті ПВ ФЗ з вихідних ФЗ входять до складу так званих аксіом виводу (АВ).

АВ - правило, згідно з яким, якщо відношення задовольняє певним ФЗ, то воно повинно задовольняти та іншим визначеним ФЗ.

Розглянемо 6 основних правил виводу (АВ).

1. Рефлексивність. А ® А,

2. Додавання (розширення)

а) якщо А ® В, то А, С ® У

б) якщо А à В, то А, З à В, С ИФЗ

3. Транзитивність. Якщо А ® B і B ® C, то А ® З ИФЗ

4) Псевдотранзітівность. Якщо А ® B і B, С ® D, то А, З ® D ИФЗ

5) Об'єднання (адитивність). Якщо А ® B і А ® С, то А ® В, С

6) Декомпозиція (проективного). Якщо А ® В, С, то А ® B і А ® З

Використовуючи аксіоми виведення f 1 - f 6 можна отримати інші правила виведення для ФЗ. Наприклад, з використанням аксіом f 1 і f 2 можна отримати A, B ® B. Перші три аксіоми називаються аксіомами Армстронга, що залишилися три випливають з них. Використання повної системи аксіом дозволяє вивести всі функціональні залежності, що дозволені в множині ФЗ. Нехай F - безліч ФЗ для схеми відносин R. Безліч ФЗ, які логічно випливають з F, називають замиканням F (F +). Якщо F = F +, то говорять, що F - повне сімейство залежності. Обчислення F + для F є трудомісткою завданням, оскільки потужність F + може бути велика навіть при невеликій потужності F. Обчислення ж X + для даної множини атрибутів Х не становить труднощі. Х + - це замикання Х щодо F, якщо є безліч атрибутів А таких, що залежність Х ® А може бути виведена з F по аксіомам f1, f2, f4.

2.1.3 Метод об'єктної зв'язку

Відрізняється від методу декомпозиції тим, що ФЗ залучаються не на початковому, а на кінцевому етапі проектування.

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

1. Метод ER-діаграм в ER-примірниках;

2. Метод ER-типів.

1) 2)

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

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

Загальний підхід до проектування

Зв'язок "читає" - бінарна, тому що поєднує дві сутності.

1. Будується діаграма ER-типу, що включає в себе всі сутності і зв'язку;

2. Будується набір попередніх відносин з зазначенням передбачуваного первинного ключа для кожного відносини;

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

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

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

1. Тип відповідності;

2. Клас приналежності;

як визначальні чинники.

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

Правило 2: Якщо ступінь бінарної зв'язку дорівнює 1:1 і клас однієї з сутностей необов'язковий, то необхідно побудова двох відносин, під кожну сутність необхідно виділення одного відносини. Ключ суті, для якого клас приналежності є необов'язковим, додається як атрибуту у відношення, виділений для сутності з обов'язковим класом приналежності.

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

Правило 3: Якщо ступінь бінарної зв'язку дорівнює 1:1 і клас приналежності жодної з сутностей не є необов'язковим, то використовується три відносини - по одному для кожної суті - ключі яких служать в якості первинних у відповідних відносинах і одного для зв'язку. Ставлення, виділений для зв'язку, буде мати по одному ключу сутності від кожної суті. Читає (Пр #, К #, ...)

Попередні відносини для бінарних зв'язків з типом відповідності 1: M.

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

K #	Курс	Пр #	ПІБ
12 11 03 01 -	історія політологія фізика математика -	3 3 4 5 6	Іванов Іванов Петров Сидоров Андрєєв

Правило 4: Якщо ступінь бінарної зв'язку дорівнює 1: М і клас приналежності М-зв'язковий сутності обов'язковий, то достатньо використовувати два відносини: по одному на кожну сутність, за умови що ключ сутності служить в якості первинного ключа для відповідного відношення. Ключ ж однозв''язної суті повинен бути доданий як атрибут у відношення, що відводиться М-зв'язковий сутності.

Тобто отримаємо таблиці

До #	Курс	Пр #	Пр #	ПІБ

Якщо однозв'язна сутність виродилися в атрибут, тобто має у своєму складі один атрибут, то виникає проблема.

Приклад:

1. Товар зберігається в осередках на складі. В одній клітинці можуть зберігатися товари різного роду, але кожен товар тільки в одній комірці.

Осередок виродилися.

2. Співробітники займають посаду

Аналіз прикладів дозволяє зробити висновок: якщо однозв'язна сутність представлена ​​тільки ключем, то, в залежності від класу приналежності однозв''язної суті, застосовують різні правила:

а) Коли клас приналежності однозв''язної сутності обов'язковий, то в "товар" додаємо "номер позиції", отримуємо одне відношення.

б) Якщо клас приналежності однозв''язної сутності необов'язковий, то маємо два відносини, так як "посада", яку ніхто не займає, потрібно зберігати в БД.

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

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

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

Попередні відносини для багатосторонніх зв'язків.

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

Якщо зв'язок n-стороння, потрібно N +1 відносин: N для сутностей і 1 для зв'язку.

За правилом 6 маємо три відносини. Кількість характеристика зв'язку.

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

Використання ролей в ER-моделях.

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

Приклад:

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

Використовуємо правило 4, отримаємо відношення:

Майстер (М #, ...)

Складальник (C #, ..., M #)

Проблема виникає при додаванні не ключових атрибутів в попередні відносини. Припустимо, що такими не ключовими атрибутами є ПІБ службовця, телефон робочий, телефон домашній, адреса, ставка, оклад, розряд. Немає проблем при розміщенні наступних атрибутів до відносин:

Майстер (М #, тел. Робочий, оклад)

Складальник (C #, ставка, розряд, М #)

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

Шифр М #, C # і Сл # визначені на одному домені.

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

Наведений приклад характеризується

а) наявністю зв'язку між рольовими об'єктами;

б) рольові об'єкти не виродилися;

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

Отримаємо дві відносини:

Команда (K #, ...)

Розклад (КХ #, КГ #, дата, рахунок)

Приклад:

2.2 Організація СУБД

Поняття СУБД відноситься до набору засобів ПЗ, необхідних для використання фактографічних БД. Розрізняють документальні і фактографічні БД.

Документальні БД зберігають сукупність довільних текстових документів.

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

СУБД - це набір ПС, що дозволяє:

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

2. Підтримувати моделі даних користувача.

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

Логічно в сучасних СУБД можна виділити:

1. Внутрішня частина - ядро СУБД (Data Base Engine - DBE).

2. Компілятор мови БД (SQL).

3. Набір утиліт.

Ядро відповідає за наступні процеси:

1. Керування даними у зовнішній пам'яті.

2. Управління буферами оперативної пам'яті.

3. Управління транзакціями.

4. Журналізація.

Виділяють наступні компоненти ядра (DBE):

1. Менеджер даних.

2. Менеджер буфера.

3. Менеджер транзакцій.

4. Менеджер журналу.

Ядро СУБД має власним інтерфейсом, недоступним користувачеві безпосередньо. Цей інтерфейс використовується програмами, виробленими компілятором SQL і утилітами БД.

При використанні архітектури "клієнт-сервер" ядро є основною складовою сервера.

Основна функція компілятора - компіляція операторів мови БД в деяку програму. Основною проблемою реляційних СУБД є те, що мови цих систем (SQL) є непроцедурного.

2.2.1 Вимоги до сучасної СУБД

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

Перелічимо основні проблеми, що виникають у файлових системах:

1. Залежність даних;

2. Жорсткість і статичність;

3. Дублювання даних;

4. Відсутність інтеграції;

5. Неможливість обробки нетипових запитів.

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

Основні вимоги:

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

• в глобальній логічній структурі;

• у вимогах даних інших прикладних програм.

Приклади можливих змін:

а) модифікація старих прикладних програм;

б) додавання нових прикладних програм, що використовують нові типи даних;

в) додавання нових полів та створення нових зв'язків.

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

Повинні існувати три окремих подання організації БД:

• фізична;

• общелогическими (концептуальна модель);

• подання даних у прикладних програмах.

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

2. Універсальність. СУБД повинна підтримувати різні моделі даних.

3. Сумісність. Збереження працездатності при розвитку програмного та апаратного забезпечення.

4. Мінімальна надмірність даних.

5. Цілісність даних.

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

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

в) семантична - підтримує осмислене поєднання різних даних.

6. Захист даних від несанкціонованого доступу.

а) конфіденційність-захист від несанкціонованого отримання даних;

б) цілісність - захист від несанкціонованої зміни даних;

в) доступність - захист від несанкціонованого утримання даних.

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

8. СУБД повинна підтримувати як централізовані, так і розподілені БД.

2.2.2 Архітектура СУБД

Існує кілька рівнів подання даних:

1. Опис конкретного кінцевого користувача, який має локальне опис;

2. Загальне логічне опис, що інтегрує опис локальних користувачів;

3. Опис фізичної організації БД.

Опис моделі на якому-небудь мові називається схемою. У відповідності до рівнів подання розрізняють:

1. Подсхема, або зовнішня схема - представлення локального користувача;

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

3. Фізична, або внутрішня схема.

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

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

Всі ці різновиди рівнів опису прийнято пов'язувати з поняттям архітектура СУБД.

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

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

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

1. Вибір типу носія;

2. Спосіб організації даних;

3. Метод доступу;

4. Визначення розміру фізичного блоку;

5. Вибір методів стиснення або відмова від них;

6. Проблема утилізації і т.д.

У більшості настільних СУБД цей етап проектування приховано від користувача.

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

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

2.2.3 Робота СУБД

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

1. Прикладна програма А видає запит СУБД на читання запису.

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

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

4. СУБД переглядає опис фізичної організації БД і визначає, яку фізичну запис потрібно рахувати.

5. СУБД видає операційній системі команду читання необхідної запису.

6. Операційна система взаємодіє з фізичною пам'яттю, в якій зберігаються дані.

7. Запитані дані передаються з пам'яті в системний буфер.

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

9. СУБД передає дані з системного буфера в робочу область прикладної програми А.

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

11. Прикладна програма обробляє дані, вміщені в робочу область.

2.3 Організація даних

2.3.1 Фізична організація даних

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

Аспекти проблеми:

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

Ключ ® машинний адресу

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

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

3. Яким чином деревоподібні мережеві структури можна представити у вигляді послідовності бітів?

4. Як додати новий запис до даних, знищити старі записи, не порушуючи структури адресації і пошуку, а також структуру даних?

Ключ БД - RID (Record IDentificator)

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

Приклад:

1. RID складається з номера сторінки і номера запису на сторінці;

2. Послідовний номер запису в файлі.

У деяких системах користувач не знає RID, в інших - він доступний користувачеві, який може його використовувати.

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

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

Характеристики файлу даних: Параметри блокування сторінок

Формат і довжина сторінки

Запис може бути сегментована, якщо вона не вміщується на одній сторінці.

Файл БД:



Як на первинному ключу визначити місце розташування запису з даними ключем?

1. Послідовне сканування файлу - сканується файл з перевіркою ключа кожного запису. Ефективний тільки для файлів з ​​послідовним доступом. Записи повинні бути впорядковані по ключу.

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

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

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

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

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

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

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

2.3.2 Організація індексних таблиць

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

Індексна таблиця повинна бути впорядкована по вхідному індексу.

Слід розрізняти індексування по первинному ключу і вторинне індексування.

Первинне індексування

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

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

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

1. Ключ індексування повинен мати унікальне незмінне значення;

2. Первісна завантаження має виконуватися обов'язково з попереднім сортуванням;

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

Вторинне індексування

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

Вторинні ключі можуть ідентифікувати запису неєдиним чином. Одному вторинному ключу можуть відповідати кілька записів

КБД - ключ БД

Особливості вторинного індексування:

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

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

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

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

Бінарне поділ

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

Кожна індексна запис (ІЗ) містить

1. Значення ключа запису;

2. Адреса цього запису (ключ БД);

3. Адресна посилання на ІЗ з ключем менше даного;

4. Адресна посилання на ІЗ з ключем більше даного.

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

Приклад:

# Запису

	1	2	3	4	5	6	7	8	9	10	11	12
Ключ запису	12	8	4	9	6	13	14	16	100	10	25	31



Пошук запису за значенням ключа виконується за тим же алгоритмом, починаючи з кореня БД. Механізм заснований на відомому дихотомічному пошуку. Поряд з достоїнствами, бінарні дерева мають значні недоліки. У нашому прикладі для вилучення запису з ключем запису, рівним 31, потрібно 7 кроків, а для запису, з КЗ = 6 - 4 кроки, хоча обидва записи кінцеві. Таке дерево називається незбалансованим.

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

По-дерево n-ого порядку повинно відповідати таким умовам:

1. Будь-яка вершина може містити n адресних посилань і n -1 ключів. Посилання вліво від ключа забезпечує перехід до вершин дерева з меншими значеннями ключа, вправо - з великими.

2. Будь-яка неконечная вершина може мати не менш n / 2 підлеглих вершин.

3. Якщо неконечная вершини містять k ключів, то їм підпорядкована k +1 вершина на наступному рівні ієрархії.

4. Всі кінцеві вершини В-дерева розташовані на одному рівні.

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

Приклад:

Нехай завантажується та ж послідовність записів з формуванням бінарного дерева з n = 3. Тоді кожен запис такого дерева розрахована на зберігання 2-х ключів і 3-х посилань. Спочатку коренева вершина містить тільки ключ 12.



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



Далі, оскільки для ключа 4 немає запису в кореневій запису, відбувається її розподіл. З трьох ключів (4, 8, 12) вибирається середній ключ (8), щоб ключі 4 і 12 потрапили у дві підлеглі запису.



При цьому буде виконано обмеження 2) і 3). Це загальне правило для дерев 3-го порядку.

У результаті отримаємо наступне дерево:



Зв'язані списки

У мережевих ієрархічних моделях даних зв'язок з даними

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

Остання підпорядкована запис містить або посилання на власника, або ознака кінця ланцюга (замкнутий або розімкнутий список). Розглянутий тип посилань називається посиланнями на наступний. У ланцюговому пов'язаному списку можуть використовуватися й інші типи посилань:

• посилання на власника забезпечує рух по груповому відношенню вгору;

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

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

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

Стор.1	А1	В1	М1	М2	В2
Стор.2	В3	М3	М4	М5	Н1

2.4 Оновлення і відновлення даних

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

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

Запам'ятовування нових записів

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

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

Коригування

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

Транзакція

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

Транзакція - це послідовність операцій над БД, розглянута СУБД як єдине ціле.

Особливості транзакції:

1. Завжди пов'язана із змінами в БД, що викликаються операціями INSERT, DELETE, ACCEPT в SQL;

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

Приклад:

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

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

Таким чином, можливі два результати виконання транзакції:

1. Транзакція повністю виповнюється;

2. Транзакція повністю анулюється.

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

1. COMMIT - фіксація;

2. ROLLBACK - відкат.

Залежно від типу МТ вони можуть виглядати по-різному.

Точка відліку часу (ТЗ) являє собою граничну точку між двома послідовними транзакціями. ТЗ встановлюється при ініціалізації програми і при виконанні команд МТ:

1. COMMIT - повідомляє про успішну транзакції і встановлює ТЗ. Всі оновлення, зроблені транзакцією, фіксуються. Знімаються всі блокування записів, всі відкриті курсори закриваються.

2. ROLLBACK - повідомляє про невдале завершення транзакції і встановлює ТЗ. Всі оновлення програми (після встановлення останньої ТЗ) анулюються. Знімаються всі блокування записів, всі відкриті курсори закриваються.

Відновлення транзакції

Виробляється в ситуаціях:

1. Індивідуальний відкат транзакції;

1. явне завершення оператором ROLLBACK,

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

2. Відновлення після раптової втрати вмісту ОЗУ (м'який збій);

3. Відновлення після поломки основного зовнішнього носія (жорсткий збій).

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

Якщо б запис про зміну БД відразу записувалася в зовнішню пам'ять, це призвело б до уповільнення роботи системи. Тому записи журналу теж буферизує.

Існують два види буферів:

1. Буфер журналу;

2. Буфер сторінок БД.

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

Індивідуальний відкат транзакції

1. Вибирається чергова запис зі списку даної транзакції;

2. Вибирається протилежна за змістом операція;

3. Будь-яка з цих зворотних операцій також журналізіруется;

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

Відновлення після м'якого збою

1. Сторінки БД буферизує в ОЗУ і відновлюються незалежно;

2. Незважаючи на застосування WAL після м'якого збою набір атрибутів БД у зовнішній пам'яті може виявитися неузгодженим, тобто частину сторінки в зовнішній пам'яті відповідає БД до зміни, частина - після зміни.

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

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

Нехай вдалося відновити зовнішню пам'ять БД до узгодженого стану і часу t фс, тоді для:

T1 - ніяких дій не виробляти.

T2 - потрібно повторно виконати частину, що залишилася операцій, так як у зовнішній пам'яті повністю відсутні сліди операцій, які виконувалися транзакцією після часу tфс.

Це призведе до узгодженого станом БД, тому що транзакція Т2 успішно завершилася до моменту м'якого збою і в журналі містяться всі дії (REDO).

T 3 - виконується в зворотному напрямку перша частина операцій (UNDO).

У зовнішній пам'яті БД повністю відсутні результати операцій транзакцій Т3, які були виконані після t фс. З іншого боку, у зовнішній пам'яті існують результати операцій Т3, які були виконані до t фс.

Т4 - виконуються повторно повністю всі операції (REDO).

Т5 - ніякі дії не робляться.

У зовнішній пам'яті БД повністю відсутні результати операцій транзакції Т5.

Відновлення після жорсткого збою

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

1. За журналу у прямому напрямку виконуються всі операції;

2. Для трансакцій, які не закінчилися до моменту збою, виконується відкат.

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

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

2.5 БД в мережах

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

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

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

3. Розподілені - такі БД, в яких дані поширюються по мережі.

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

Архітектура взаємодії клієнта і сервера

1. Локальні і файл-серверні БД.

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

Архітектура "файл-сервер" володіє наступними недоліками:

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

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

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

4. Недостатньо розвинений апарат транзакції локальної СУБД служить потенційним джерелом помилок при одночасному внесенні змін.

2. Клієнт-серверні БД.

В архітектурі "клієнт-сервер" між ядром і БД з'являється сервер БД.

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

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

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

3. Триланкового архітектура клієнт-сервер.

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

На малюнку показаний варіант розміщення сервера додатків на машині сервера БД. Це найбільш популярний варіант, але не обов'язковий. Сервер додатків може розміщуватися на будь-якій машині, оснащеною ядром

2.6 Доступ до даних у Windows

На сьогоднішній день існують дві паралельно розвиваються конкуруючі технології взаємодії між об'єктами та програмами. Це COM (Component Object Model) і CORBA (Command Object Require Broker Architecture). COM розвивається компанією Microsoft, CORBA - іншими.

Технологія COM

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

1. Розташовані на різних машинах;

2. Написані на різних мовах;

3. Використовуватися в різних ОС;

4. Розташовуватися на машинах різного типу.

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

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

Сервер СОМ представляє собою виконувану програму або. DLL, що містить один або кілька об'єктів СОМ. Залежно від місця розташування клієнта і сервера можливі 3 варіанти:

1. Клієнт і сервер розташовані на одній машині і запускаються в одному процесі. У цьому випадку сервер являє собою. DLL.

Клієнт за допомогою інтерфейсу об'єкта безпосередньо звертається до методів об'єктів у своєму власному адресному просторі.

2. Клієнт і сервер розташовуються на одній машині, але запускаються в різних процесах. Наприклад, таблиця Excel вставляється в документ Word. У цьому випадку сервер являє собою програму.

3. Клієнт і сервер розташовуються на різних машинах. Сервером може бути як програма, так і. DLL. У цьому випадку використовують поширений варіант COM - DCOM.

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

Клієнт відвідує параметри виклику в стек і звертається до методу інтерфейсу об'єкта. Це звернення перехоплюється Proxy, упаковує параметри виклику в пакет СОМ і направляє його в Stub іншого процесу. Stub розпаковує параметри, поміщає в стек і робить виклик потрібного методу об'єкта. Таким чином, метод об'єкта виконується у власному адресному просторі процесу сервера.

Поняття відкритого інтерфейсу Windows

Для уніфікації зв'язку Microsoft підтримує так звану відкриту архітектуру. Метою відкритої архітектури є з'єднання ПК і інформаційними службами. WOSA є певний ізолюючий шар між прикладною програмою і джерелом даних.

Такий архітектурою визначені два стандартних інтерфейсу:

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

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

Переваги:

1. Існує доступ користувача до інформаційних служб без вивчення різних додатків;

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

3. Розробники. Їх додатки отримують нові можливості без використання різних інтерфейсів.

Глава 3. Робота з таблицями бази даних на прикладі СУБД Microsoft Access

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

3.1 Структура таблиці, її створення

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

Структура таблиці включає наступну інформацію:

Ім'я таблиці	Ім'я, по якому до таблиці можна звернутися у властивостях, методах і операторах SQL.
Стовпці таблиці	Категорії інформації, що зберігається у таблиці. Кожен стовпець має ім'я і тип даного.
Табличні та стовпові обмеження	Обмеження цілісності, визначені на рівні таблиці або на рівні стовпця.

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

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

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

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

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

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

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

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

3.1.1 Створення нової порожній таблиці

У Microsoft Access існує кілька способів створення нової таблиці:

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

2. Майстер таблиць дозволяє вибрати поля для цієї таблиці з числа визначених раніше таблиць.

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

4. Визначення всіх параметрів структури таблиці в режимі конструктора.

5. Імпорт в поточну базу даних структур таблиць і даних із зовнішнього джерела.

6. Створення в поточній базі даних таблиць, пов'язаних з таблицями зовнішнього джерела.

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

3.1.2 Створення таблиці в режимі конструктора

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

1. Перейти у вікно бази даних. Переключитися з іншого вікна у вікно бази даних можна, натиснувши клавішу "F 11".

2. Вибравши вкладку Таблиці, натиснути кнопку Створити.

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

3. У вікні Нова таблиця вибрати елемент Конструктор.

4. Визначити в таблиці кожне поле. Поля таблиці містять дані, що представляють порції запису. Користувач має можливість визначати формат відображення даних, вказувати значення за замовчуванням і прискорювати операції пошуку і сортування, задаючи значення властивостей полів у розділі Властивості поля в режимі конструктора таблиці. У Microsoft Access властивості полів використовуються при перегляді або зміні даних користувачем. Наприклад, задані користувачем значення властивостей Формат поля, Маска вводу і Підпис визначають вид бази даних таблиці та запиту. Елементи управління в нових формах і звітах, приєднані до полів таблиці, успадковують ці властивості полів базової таблиці за замовчуванням. Інші властивості дозволяють визначити умови на значення полів або задати обов'язковий введення даних у полі. Microsoft Access буде перевіряти виконання цих умов при кожному додаванні або зміні даних у таблиці. Щоб додати поля в кінець структури таблиці потрібно вибрати перший пустий рядок структури. Для вставки поля в середину структури слід вибрати рядок, над якою потрібно додати нове поле, і натиснути кнопку Додати рядка на панелі інструментів. У стовпець Ім'я стовпця ввести ім'я поля; у стовпці Тип даних вибрати потрібний тип даних у списку або залишити налаштування (Текстовий). У стовпці Опис можна ввести необов'язкове короткий опис поля. Текст опису буде виводиться в рядку стану при додаванні даних в полі, а також буде включений в опис об'єкта таблиці. При необхідності можна задати значення властивостей поля в бланку властивостей в нижній частині вікна.

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

6. Для збереження таблиці натиснути кнопку Зберегти на панелі інструментів, ввівши припустиме ім'я таблиці.

Вибір для поля таблиці типу даного

Тип даного поля таблиці можна вибрати в списку у стовпці Тип даних. При виборі типу даних, використовуваних в полі, необхідно враховувати наступне:

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

2. скільки місця необхідно для збереження значень у полі;

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

4. значення можна в числових полях і в полях, що мають валютний формат, а в текстових полях і полях об'єктів OLE, - не можна;

5. чи потрібна сортування або індексування поля. Сортувати та індексувати поля МЕМО, гіперпосилання та об'єкти OLE неможливо;

6. чи будуть поля використовуватися в угрупованні записів в запитах або звітах. Поля МЕМО, гіперпосилання та об'єкти OLE використовувати для групування записів не можна;

7. яким чином мають бути відсортовані значення в полі. Числа в текстових полях сортуються як рядкові значення (1, 10, 100, 2, 20, 200 і т. д.), а не як числові значення. Для сортування чисел як числових значень необхідно використовувати числові поля або поля, що мають грошовий формат. Також багато форматів дат неможливо належним чином відсортувати, якщо вони введені в текстове поле. Для забезпечення сортування дат і часів слід використовувати поле типу Дата / Час.

У наступній таблиці представлені всі типи даних Microsoft Access та їх застосування.

Тип даних	Застосування	Розмір
Текстовий	Текст або комбінація тексту і чисел, наприклад адресу, а також числа, не вимагають обчислень, наприклад номери телефонів, номенклатурні номера або поштовий індекс.	До 255 символів. Зберігаються тільки введені в поле символи; позиції, не використані в текстовому полі, не зберігаються. Для управління максимальним числом символів, що вводять слід визначити властивість Розмір поля.
Поле МЕМО	Довгий текст або числа, наприклад коментарі або опис. Поля МЕМО не можуть бути індексовані або відсортовані. Для зберігання форматованого тексту або довгих документів, замість поля МЕМО, слід створити поле об'єкта OLE.	До 64 000 символів.
Числовий	Числові дані, використовувані для математичних обчислень, за винятком обчислень, що включають грошові операції (для яких використовується грошовий тип). Тип і розмір значень, які можуть знаходитися в числовому полі, можна змінити у властивості Розмір поля. Наприклад, в полі, що займає на диску 1 байт, допускається введення тільки цілих чисел (без десяткових знаків) від 0 до 255.	1, 2, 4 або 8 байт. 16 байт лише для кодів реплікації.
Дата / час	Дати та час. Зберігання значень дат і часу в полі типу Дата / Час забезпечує правильну сортування. Всі зміни, внесені у формати дат і часу у вікні Мова і стандарти Панелі управління Windows, будуть автоматично відображені в полях типу Дата / Час.

	8 байт.
Грошовий	Значення валют. Грошовий тип використовується для запобігання заокруглень під час обчислень. Передбачає до 15 символів в цілій частині числа та 4 - у дробовій.	8 байт.
Лічильник	Автоматична вставка послідовних (що відрізняються на 1) або випадкових чисел при додаванні запису. Для створення зростаючого лічильника варто залишити всі налаштування властивості в нижній частині вікна колишніми, за замовчуванням, у властивості Розмір поля задано значення Довге ціле, а властивості Нові значення - Послідовні. Для створення лічильника випадкових чисел для властивості Нові значення потрібно встановити значення Випадкові.	4 байти. Для кодів реплікації - 16 байт.
Логічний	Містять тільки одне або два значення, такі як Так / Ні, Істина / Брехня, Вкл / Викл.	1 біт.
Об'єкти OLE	Об'єкти (наприклад, документи Microsoft Word, електронні таблиці Microsoft Excel, малюнки, звуки та інші дані), створені в інших програмах, що використовують протокол OLE. Об'єкти можуть бути пов'язаними або впровадженими в таблицю Microsoft Access. Для відображення об'єкта OLE у формі або звіті необхідно використовувати елемент керування Приєднана рамка об'єкта.	До 1 гігабайта
Гіперпосилання	Поле, в якому зберігаються гіперпосилання. Гіперпосилання може бути або типу UNC (стандартний формат шляху файлу з включенням мережевого сервера), або URL (адреса об'єкта в 1п1егпе1 або внутрішньої мережі з включенням типу протоколу доступу).	До 64 000 символів
Майстер підстановок	Створюється поле, що дозволяє вибрати значення. З іншої таблиці або зі списку значень, використовуючи поле зі списком. При виборі даного параметра в списку типів даних для їх визначення завантажується майстер.	Розмір такої ж, як і розмір ключового поля

Важливо: Числові, грошові та логічні типи даних, а також Дата / час забезпечують стандартні формати відображення. Для вибору форматів для кожного типу даних слід визначити властивість Формат. Для всіх даних, крім об'єктів OLE, можна також створити користувальницький формат відображення. Докладніше див нижче, в розділі "Властивість Формат поля".

Властивість Розмір поля

Властивість Розмір поля визначає максимальний розмір даних, які можуть зберігатися в полях з типом даних Текстовий, Числовий або Лічильник.

Якщо властивість Тип даних має значення "Текстовий", значенням даного властивості має бути ціле число в діапазоні від 0 до 255. За замовчуванням задається розмір 50.

Якщо властивість Тип даних має значення "Лічильник", то допустимими значеннями властивості Розмір поля будуть "Довге ціле" або "Код реплікації".

Якщо поле має тип даних "Числовий", то допустимими є наступні значення властивості Розмір поля:

Значення	Опис	Дрібна частина	Розмір
Байт	Числа від 0 до 255	Відсутній	1 байт
Ціле	Числа від -32 768 до 32 767	Відсутній	2 байти
Довге ціле	(Значення за замовчуванням). Числа від -2 147 483 648 до 2147483647	Відсутній	4 байти
З плаваючою точкою (4 байти)	Числа від-3.402823Е38 до-1.401298Е-45 для від'ємних значень і від 1.401298Е-45 до 3.402823Е38 для позитивних.	7 знаків	4 байти
З плаваючою точкою (8 байт)	Числа від-1.79769313486232Е308 до-4.94065645841247Е для від'ємних значень і від 1.79769313486231Е308 до 4.94065645841247Е-324 для позитивних.	15 знаків	8 байт
Код реплікації	Глобальний унікальний ідентифікатор (GUID) при реплікації об'єктів даних	Не визначено	16 байт

Для отримання або завдання максимального розміру текстового поля в програмі Visual Basic слід використовувати властивість Size об'єктів доступу до даних (DAO). Для полів інших типів значення властивості Size автоматично визначається значенням властивості Туре.

Важливо: Користувач має можливість вказати стандартні розміри текстових і числових полів у групі Розміри полів за замовчуванням на вкладці Таблиці / запити (у діалоговому вікні Параметри, яке відкривається командою Параметри в меню Сервіс). Рекомендую ставити мінімально допустиме значення властивості Розмір поля, оскільки обробка даних меншого розміру виконується швидше і вимагає менше пам'яті. Перетворення більшого значення властивості Розмір поля до меншого в таблиці, яка вже містить дані, може призвести до втрати даних. Наприклад, при зменшенні розміру текстового поля з 255 до 50 всі значення, довжина яких перевищує 50 символів, будуть усічені. Дані в числовому полі, які виходять за межі діапазону, відповідного нового розміру поля, округлюються або замінюються порожніми значеннями. Наприклад, при заміні значення "З плаваючою точкою (4 байти)" на "Ціле" дробові числа будуть округлені до найближчого цілого числа, а значення поза діапазоном від -32 768 до 32 767 будуть перетворені у порожні значення. Скасувати зміни даних, що відбулися при модифікації властивості Розмір поля, після його збереження в режимі конструктора таблиці буде неможливо. Для полів, в яких планується зберігати числові значення з одним - чотирма знаками в дробовій частині, рекомендується використовувати грошовий тип даних. При обробці числових значень з полів типу "З плаваючою точкою (4 байти)" і "З плаваючою точкою (8 байт)" застосовуються обчислення з плаваючою точкою. При обробці числових значень з грошових полів використовуються більш швидкі обчислення з фіксованою точкою.

Поле типу Лічильник

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

Поле лічильника і реплікація

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

Властивість Формат поля

Властивість Формат поля дозволяє вказати формати виведення тексту, чисел, дат і значень часу на екран і на друк. Наприклад, для поля Ціна розумно вказати у властивості Формат поля формат Грошовий і встановити для його властивості - Число десяткових знаків - значення 2 або Авто. У цьому випадку введене в полі значення 4321,678 буде відображатися як 4 321,68 р. Можливе використання як вбудованих, так і спеціальних форматів, створених за допомогою символів форматування. Для елементів керування значення властивості Формат поля задається у вікні властивостей. Для поля в таблиці або запиті значення даної властивості задається в режимі конструктора таблиці (у розділі властивостей поля) або у вікні запиту (у вікні властивостей поля). Формати можна вибирати зі списку вбудованих форматів для полів, які мають числовий, грошовий, логічний типи даних, а також типи даних лічильника і дати / часу. Також для будь-яких типів даних полів, відмінних від об'єктів OLE; є можливість створення власних спеціальних форматів. Крім того, значення даної властивості можна задати в макросі або в програмі.

Властивість Формат поля визначає тільки спосіб відображення даних, не впливаючи на спосіб їх збереження. У Microsoft Access визначені стандартні формати для полів з ​​типами даних Числовий, Дата / час, Логічний, Текстовий і Поле МЕМО. В якості стандартних використовуються національні формати, обрані у вікні Мова і стандарти Панелі управління Windows. Набір форматів визначається налаштуваннями для конкретної країни. Наприклад, якщо на вкладці Мова і стандарти вказати Англійська (США), то число 1234.56 в грошовому форматі буде виглядати як $ 1,234.56. Але якщо вказати на цій вкладці Російська, то це число буде виглядати так: 1 234,56 р. Налаштування Формат поля, задана в режимі конструктора таблиці, використовується для відображення даних в режимі таблиці. Ця ж настройка застосовується при створенні пов'язаних з цим полем нових елементів керування у формі або звіті.

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

Символ	Значення
(Пробіл)	Виводить пробіл як символьну константу.
"АВС"	Усі символи всередині лапок вважаються символьними константами.
!	Вирівнює символи по лівому краю.
*	Заповнює доступне порожній простір наступним символом.
\	Виводить наступний символ як символьну константу. Для цієї ж мети можна використовувати лапки.
[Колір]	Встановлює колір, назва якого вказана в дужках. Допустимі імена кольорів: Чорний, Синій, Зелений, Бірюзовий, Червоний, Пурпурна, Жовтий, Білий.

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

Властивість Формат поля для дати / часу

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

Значення	Опис
Повний формат дати	(Значення за замовчуванням). Якщо значення містить тільки дату, то час не відображається, якщо значення містить тільки час, то дата не відображається. Даний формат є комбінацією двох: "Короткий формат дати" і "Довгий формат часу". Приклади: 01.11.95 1:07:19 і 23.01.96 23:01:04.
Довгий формат дати	Збігається з налаштуванням "Повний формат", задається у вікні Мова і стандарти Панелі управління Windows. Приклад: 1 червня 1995
Середній формат дати	Приклад: 03-Apr-95.
Короткий формат дати	Збігається з настройкою "Короткий формат дати", задається у вікні Мова і стандарти Панелі управління Windows. Приклад: 11.06.95. Значення короткого формату дати припускають, що дати з діапазону 01.01.00 і 31.12.29 відносяться до двадцять першого століття (тобто, передбачаються роки з 2000 по 2029). Передбачається також, що дати з проміжку 01.01.30 і 31.12.99 відносяться до двадцятого століття (тобто роки з 1930 по 1999).
Довгий формат часу	Збігається з форматом часу, задається у вікні Мова і стандарти на вкладці Час панелі керування Windows. Приклад: 20:58:10.
Середній формат часу	Приклад: 05:34 РМ.
Короткий формат часу	Приклад: 17:34.

Також існують спеціальні формати дати і часу. Спеціальні формати виводяться у відповідності зі значеннями, встановленими у вікні Мова і стандарти Панелі управління Windows. Спеціальні формати, які суперечать налаштувань вікна Мова і стандарти, ігноруються.

Властивість Формат поля для числових та грошових полів

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

Значення	Опис
Основний	(Значення за замовчуванням). Числа відображаються так, як вони були введені.
Грошовий	Використовуються роздільники груп розрядів; негативні числа виводяться в круглих дужках; властивість Число десяткових знаків за замовчуванням одержує значення 2.
Фіксований	Виводиться принаймні один розряд; властивість Число десяткових знаків за замовчуванням одержує значення 2.
З роздільниками	Числа виводяться з роздільниками груп розрядів; властивість Число розрядів десяткових знаків за замовчуванням одержує значення 2.
Процентний	Значення множиться на 100; додається символ відсотків (%); властивість Число десяткових знаків за замовчуванням одержує значення 2.
Експоненціальний	Числа виводяться в експоненційної (наукової) нотації.

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

Розділ	Опис
Перший	Формат позитивних чисел.
Другий	Формат негативних чисел.
Третій	Формат нульових значень.
Четвертий	Формат порожніх значень.

Властивість Формат поля для текстових та МЕМО-полів

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

Символ	Опис
@	Обов'язковий текстовий символ або пробіл.
&

	Необов'язковий текстовий символ.
<	Перетворює всі символи в рядкові.
>	Перетворює всі символи в прописні.

Спеціальні формати для текстових полів і полів МЕМО можуть включати один або два розділи, розділених крапкою з комою (;). Ці розділи описують специфікації формату різних порцій даних поля.

Розділ	Опис
Перший	Формат відображення тексту.
Другий	Формат відображення рядків нульової довжини і порожніх значень.

Формат поля і маска введення даних

У Microsoft Access до схожих результатів призводить зміна двох властивостей полів: властивість Формат поля і властивість Маска вводу. Властивість Формат поля використовується для відображення даних у постійному форматі. Наприклад, якщо властивість Формат поля для полів типу Дата / Час встановлено на Середній формат дати, то всі дані, що вводяться будуть відображатися в наступному форматі: 12-січ-97. Якщо ж користувач бази даних введе число у вигляді 12.01.97 (або в іншому визначеному вигляді), то при збереженні запису формат дати буде перетворений в Середній формат дати. При установці властивості Формат поля змінюється лише відображення значення, проте, дане властивість ніяк не впливає на зберігання значення в таблиці. Зміни у форматі відображення застосовуються тільки після збереження введених даних, до цього моменту визначити, в якому форматі були введені дані в полі, неможливо. Якщо ж введенням даних необхідно управляти, на додаток до формату відображення даних або замість нього використовується маска вводу. Якщо потрібно, щоб дані відображалися так, як вони були введені, властивість Формат поля взагалі не встановлюється. Маска введення забезпечує відповідність даних певному формату, а також заданому типу значень, що вводяться в кожну позицію. Наприклад, для поля Номер телефону потрібно, щоб всі вводяться значення телефонного номера містили точне число тільки цифрових знаків і становили повний номер телефону (наприклад, у США це код штату, код міста і номер абонента). Якщо для поля визначені як формат відображення, так і маска вводу, то при додаванні і редагуванні даних використовується маска вводу, а параметр Формат поля визначає відображення даних при збереженні запису. Якщо використовується як властивість Формат поля, так і властивість Маска вводу, необхідно забезпечити, щоб результати їх дії не суперечили один одному. Маска вводу для поля таблиці створюється в режимі конструктора за допомогою майстра.

3.2 Ключі та індекси

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

3.2.1 Типи ключових полів

У Microsoft Access можна виділити три типи ключових полів: лічильник, простий ключ і складовою ключ.

Ключові поля лічильника

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

Простий ключ

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

Складовою ключ

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

Іншим прикладом може служити складська база даних, в інвентарній книзі якій використовуються один основний та один або декілька допоміжних інвентарних номерів.

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

3.2.2 Індекси

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

3.2.3 Створення та зміна ключових полів

Для створення ключових полів таблиці:

1. У режимі конструктора виділити одне або кілька полів, які необхідно визначити як ключові. Для виділення одного поля потрібно клацнути область виділення рядка потрібного поля (кнопка зліва рядки). Виділити кілька полів можна, утримуючи при виборі кожного поля клавішу "З trl".

2. Натиснути кнопку Ключове поле на панелі інструментів.

Створення індексу

Створити індекси, як і ключі, можна по одному або декількох полях. Складові індекси дозволяють при відборі даних групувати записи, в ​​яких перші поля можуть мати однакові значення. Індексувати поля потрібно для виконання частих пошуків, сортувань або об'єднань з полями з інших таблиць в запитах. Ключові поля таблиці індексуються автоматично. Не можна індексувати поля з типом даних поле МЕМО, гіперпосилання або об'єкт OLE. Для решти полів індексування використовується, якщо поле має текстовий, числовий, грошовий тип або тип дати / часу і потрібно здійснювати пошук і сортування значень у полі. Якщо передбачається, що буде часто виконуватися сортування або пошук одночасно по двох і більше полів, можна створити складовою індекс. Наприклад, якщо для одного і того ж запиту часто встановлюється критерій для поля Назва та Прізвище, то для цих двох полів має сенс створити складовою індекс. Під час сортування таблиці за складеним індексу спочатку здійснюється сортування по першому полю, визначеного для даного індексу. Якщо в першому полі містяться записи з повторюваними значеннями, то сортування здійснюється по другому полю і т. д.

Щоб створити індекс для одного поля треба:

1. У режимі конструктора в панелі структури таблиці (верхня частина вікна) вибрати поле, для якого потрібно створити індекс.

2. У панелі властивостей (нижня частина вікна) для властивості Індексоване полі встановити значення "Так (Допускаються збіги)" або "Так (Збіги не допускаються)".

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

Щоб створити складовою індекс:

1. У режимі конструктора на панелі інструментів натиснути кнопку Індекси.

2. У першому пустому рядку поля Індекс ввести ім'я індексу. Для індексу можна використовувати або ім'я одного з індексованих полів, або інше відповідне ім'я.

3. У полі Ім'я поля натиснути стрілку і вибрати в списку перше поле, для якого потрібно створити індекс.

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

Важливо: За замовчуванням, встановлено порядок сортування "За зростанням". Для сортування даних полів за спаданням в полі Порядок сортування у вікні індексів потрібно вказати значення "По спаданню". Хочу зауважити, що поля індексу можуть не бути ключовими.

Обмеження Onigue

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

Щоб встановити обмеження U nigue для одного поля таблиці:

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

2. У панелі властивостей для властивості Індексоване полі встановити значення "Так (Збіги не допускаються)".

Щоб встановити обмеження U nigue для декількох полів таблиці:

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

2. Вибравши ім'я індексу, в панелі властивостей індексу в комірці властивості Унікальний індекс встановити значення "Так".

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

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

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

Обмеження можна визначати на двох рівнях:

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

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

3.3.1 Обмеження в базі даних

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

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

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

• простота. Обмеження бази даних прості у визначенні і не потребують ніякого програмного коду.

3.3.2 Типи обмежень у базі даних

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

Обмеження Not Null

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

Обмеження Unique

Обмеження Unique забороняє користувачеві введення в стовпець або набір стовпців дубльованих значень. Обмеження Unique може активуватися для окремого стовпця або для комбінації стовпців. В останньому випадку обмеження Unique іноді називається складовим обмеженням Unique. Обмеження Unique використовуються, щоб гарантувати, що в таблиці не буде дубльованих значень стовпців. Наприклад, воно може гарантувати, що кожному службовцю в базі даних буде привласнений унікальний номер. Обмеження Unique не забороняє користувачеві ввести в таблицю декількох порожніх значень - пусте значення в стовпці завжди задовольняє обмеження Unique. Щоб запобігти введення в стовпець з обмеженням Unigue порожніх значень, до колонку необхідно також додати обмеження Unique. У Access обмеження Unique ініціюється установкою значення "Так (Збіги не допускаються)" для властивості Індексоване полі, або установкою значення "Так" для властивості Унікальний індекс.

Обмеження Primary Key

Обмеження Primary Key гарантує, що кожен рядок у таблиці буде унікально ідентифікована значенням у стовпці або наборі стовпців первинного ключа. Обмеження по первинному ключу об'єднує межі обмеження 0пiціе і обмеження Unigue і Not Null.

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

Обмеження Foreign Key

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

3.3.3 Підтримка цілісності даних

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

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

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

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

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

Каскадне оновлення та каскадне видалення

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

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

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

Висновок

Microsoft Access - найпопулярніша в світі база даних для операційної системи Microsoft Windows. Крім того, система управління базами даних Access - також потужна платформа розробки з надзвичайно гнучкою та функціональної інтегрованим середовищем. Access - це інструмент, призначений для розробки та розгортання шірокопредметних інформаційних бізнес-систем. Можливості розробників програмного забезпечення, а також методи і технології вирішення цих завдань постійно змінюються і удосконалюються. Як тільки з'являється якесь перспективне рішення для забезпечення швидкої розробки додатків, технологія та інструментальні засоби змінюються на базі цього нововведення практично миттєво. З кожною новою версією Access такі рішення стають надбанням самої широкої спільноти розробників. Access 2007 для Windows дозволяє для обробки інформації і швидкого формування ділових рішень залучати міць реляційної бази даних, інтегрувати дані з електронних таблиць та інших баз даних, компоненти інших програм, а також використовувати інформацію спільного доступу у внутрішніх мережах і Internet. Середа Access може з успіхом використовуватися початківцями користувачами для пізнання секретів реляційних баз даних і захоплюючих занять зі створення нескладних (спочатку) програм і в той же час надає потужні інструменти розробки досвідченим програмістам. Надзвичайно розвинені довідкова система, засоби навчання, майстри і програми-надбудови дозволяють при побудові програми і роботі в Access 07 знайти вихід з будь-якої ситуації і отримати відповідь на будь-яке питання. Починати працювати з Access можна практично з будь-яким рівнем підготовки. Access 07 - це масштабована система. Створювані прикладні рішення можуть легко розширюватися для реалізації нових ділових завдань і управління даними.