Головна

Система управління базами даних MS Access

  1. AB0-СИСТЕМА
  2. b. при медичному обстеженні учнів шкіл району частина даних про зростання представлена ??в сантиметрах, а частина - в метрах
  3. Схема управління і сигналізації масляного вимикача з електромагнітним приводом
  4. ERP має виходи в зовнішнє середовище і призначена для вирішення завдань комплексного управління підприємством.
  5. I. 1.5. Двухпірамідная система Хеопса-Голоду в структурі подвійного квадрата
  6. I.3.4. Методи підготовки даних для перенесення проекту на місцевість.
  7. IV період школи управління - інформаційний період (1960 року по теперішній час).

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

СУБД Access забезпечує:

- Набір засобів для управління даними і забезпечення цілісності даних;

- Розвинений користувальницький інтерфейс, який дозволяє вводити і модифікувати інформацію, виконувати пошук і представляти інформацію в текстовому і графічному вигляді;

- Засоби програмування високого рівня, за допомогою яких можна створювати власні додатки.

За допомогою СУБД Access є можливість:

- Вибирати інформацію, що представляє інтерес, наприклад, відомості про покупки певного клієнта;

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

- Відображати дані в графічному вигляді;

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

СУБД Access відноситься до реляційних СУБД.

Детально розглянемо основні поняття реляційних БД.

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

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

- Код споживача;

- Код деталі;

- дата надходження;

- Кількість заявлених деталей;

- дата виконання;

- Кількість відпущених деталей;

- Ціна відпускна.

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

Інформація всередині записи складається з полів. Інформація має постійну структуру даних.

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

 Номер заявки  Кодпотребітеля  Коддеталі  Дата надходження  замовлено  Дата виконання  відпущено  Ценаотпускная
 1.01.02  12.01.02  1,025.00
 2.01.02  12.01.02  2,600.00
 3.01.02  17.01.02  625.00
 5.01.02  23.01.02  620.00
 5.01.02  23.01.02  27.00

Ріс.10.5. Таблиця «Книга реєстрації заявок»

В даній таблиці є поля «Код споживача», «Код деталі», «Ціна відпускна» і ін. На рис.5 подвійною лінією виділені один запис і одне поле в книзі реєстрації замовлень.

Поля таблиці БД можуть бути різних типів, однак число типів полів в Access обмежена переліком, наведеним в табл.10.1.

Таблиця 10.1.

 № пп.  Тип поля  опис
 текстовий  Може містити літери, цифри і спеціальні символи. Довжина поля - не більше 255 символів
 числовий  Може містити тільки цифри
 грошовий  Може містити тільки цифри + символ грошового знака (наприклад, 5 $, 700 руб.)
 Лічильник  Містить тільки натуральні неповторним числа для рахунку записів таблиці
 Дата час  Може містити цифри та літери в різних форматах, прийнятих для відображення дати і часу
 логічний  Може містити одне з двох можливих значень «Істина» або «Брехня»
 Текстовий довільної довжини  Може містити ті ж символи, що і поле типу 1. Довжина поля до 65535 символів
 об'єктний  Будь-який об'єкт Windows - малюнок, таблиця Excel, документ Word і інші.
 гіперпосилання  Адреса гіперпосилання в Internet

Кожна таблиця має унікальне ім'я в БД.

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

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

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

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

- Забезпечення швидкого доступу до даних;

- Уникати зайвого повторення даних (надмірності);

- Забезпечення цілісності даних (коли при зміні одних об'єктів автоматично відбувається відповідна зміна пов'язаних з ними об'єктів).

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

Як приклад розглянемо таблицю «Продажі», яка містить наступну інформацію:

- Відомості про покупців;

- Дату замовлення і кількість замовленого товару;

- Дату виконання замовлення і кількість проданого товару;

- Характеристику проданого товару.

Структура таблиці «Продажі» приведена на ріс.10.6.

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

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

- При зміні адреси або телефону покупця необхідно коригувати всі записи, що містять всі відомості про замовлення цього покупця;

- Наявність повторюваної інформації призведе до невиправданого збільшення розмірів БД. Звідси зниження швидкості виконання запитів і неефективне використання дискового простору ПК;

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

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

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

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

Важливою особливістю індексів є те, що їх можна використовувати для створення первинних ключів.

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

Продовжимо опис реляційної структури БД «Продажі».

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

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

Для виключення повторюваних записів в таблиці «Замовлення» будується унікальний складовою індекс - первинний ключ, відповідно до конструкції «Код клієнта» + «Код товару» + «Дата замовлення» (рис.1.10). Логічно прийняти цю конструкцію ключа, якщо вважати, що клієнт N товар M не замовлятиме більше 1-го разу в один день D.

Для повного виключення надмірності даних необхідно мати ще дві таблиці (рис.1.9) - «Товари» і «Менеджер». Так, в таблиці «Товари» ведеться список всіх товарів, а в таблиці «Менеджер» розміщені дані про керівників фірм.

Первинним ключем в таблиці «Товари» є простою індекс на основі поля «Код товару», а в таблиці «Менеджер» - простий індекс на основі поля «Підприємство».

Нарешті уточнимо останній, центральне питання, пов'язаний з поняттям реляційних БД.

Ріс.10.6. Структура таблиці «Продажі»

 поле 1  поле 2  Поле3  ...  поле 12  поле 13  поле 14  поле 15  ...
 КодКліента  Прізвище  ім'я  ...  Код товару  Дата замовлення  замовлено  Дата продажу  
 Петров  Олексій    12.01.02  13.01.02  
 Іванов  Іван    12.01.02  14.01.02  
 Іванов  Іван    17.01.02  18.01.02  
 Сидоров  Самсон    23.01.02  27.01.02  
 Петров  Олексій    23.01.02  23.01.02  

Ріс.10.7. Таблиця «Продажі»

 Ріс.10.8. Схема відносин реляційної БД «Продажі»

 Ріс.10.9. Таблиці «Клієнти» і «Замовлення»

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

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

Крім відносини типу «один-ко-многим» Access підтримує ще три типи відносин: «один-до-одного», «багато-до-одного», «багато-до-багатьох».

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

Ставлення «багато-до-одного» аналогічно відношенню «один-ко-многим». Тип відносини між об'єктами залежить від точки зору. Якщо розглядати відношення між замовленнями і клієнтами, то будемо мати відношення «багато-до-одного» (ріс.10.8 і 10.9).

Ставлення «багато-до-багатьох» виникає між двома таблицями в тих випадках, коли:

- Один запис із першої таблиці може бути пов'язана більш, ніж з одним записом з другого таблиці;

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

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

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

Класифікація систем управління базами даних | GPS позиціонування з мережевою підтримкою


Склад банків даних та їх користувачі | Функції баз даних і вимоги до них | Принципи побудови баз даних | Класифікація та архітектура баз даних | Моделі даних в базах даних |

© 2016-2022  um.co.ua - учбові матеріали та реферати