ЗМІСТ

Вступ ……………………………………………………………4

Розділ 1. Постановка задачі ………………………………….9

Розділ 2. Структура програмного комплексу …………….11

Розділ 3. Інструкція користувача ………………………….13

Розділ 4. Програмний комплекс ……………………………15

Висновок ………………………………………………………31

Література …………………………………………………….32

Додатки …………………………………………………….33,34

ВСТУП

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

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

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

Те, що потрібно розглянути при розробці бази даних, включає:

призначення бази даних;

необхідні таблиці і поля;

необхідні зв'язки між таблицями;

вказівка, як уникнути зайвих даних;

вказівка, як переконатися в узгодженості даних.

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

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

максимізацію швидкості і ефективності вашої бази даних;

забезпечення того, що однакові дані ніколи не будуть поміщені більш ніж в одне поле;

економію дискового простору шляхом уникнення зайвих даних;

забезпечення узгодженості і одноманітності даних, будь то вхідні або вихідні дані;

створення механізму для пошуків по умові в запитах, формах або звітах.

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

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

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

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

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

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

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

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

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