Основи розробки баз даних

У цій статті

• Основні терміни з області баз даних

• Правильна структура бази даних

• Процес розробки структури

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

• Пошук і впорядкування потрібних відомостей

• Розподілення інформації по таблицях

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

• Указання первинних ключів

• Створення зв’язків між таблицями

• Удосконалення структури

• Застосування правил нормалізації

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

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

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

На початок сторінки

Правильна структура бази даних

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

Отже, правильна структура бази даних:

• розподіляє ваші дані на тематичні таблиці, щоб зменшити надлишкові дані;

• надає Access інформацію, потрібну для з’єднання відомостей у таблицях за необхідності;

• допомагає підтримувати та забезпечувати точність і цілісність даних;

• відповідає вашим потребам щодо обробки даних і звітування.

На початок сторінки

Процес розробки структури

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

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

  Це допомагає підготуватися до решти кроків.

• Пошук і впорядкування необхідної інформації     

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

• Розподілення інформації по таблицях    

  Розподіліть елементи інформації на основні сутності (або теми), наприклад "Товари" чи "Замовлення". Кожна тема потім стане таблицею.

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

  Вирішіть, які відомості зберігати в кожній із таблиць. Кожний елемент стає полем і відображається як стовпець таблиці. Наприклад, таблиця "Працівники" може містити такі поля, як "Прізвище" та "Дата прийому на роботу".

• Указання первинних ключів    

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

• Створення зв’язків між таблицями    

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

• Удосконалення структури    

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

• Застосування правил нормалізації    

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

На початок сторінки

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

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

На початок сторінки

Пошук і впорядкування потрібних відомостей

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

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

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

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

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

Доцільно створити прототип кожного звіту або виводу та розглянути елементи, необхідні для створення звіту. Наприклад, якщо проаналізувати форму листа, може виникнути кілька моментів. Якщо потрібно додати правильне привітання, наприклад рядок "Містер", "Пані" або "Пані", у якому починається привітання, потрібно створити привітальний елемент. Крім того, ви зазвичай можете почати лист з "Шановний пане Сміте", а не "Шановний. О. Сильвестр Коваль». Це свідчить про те, що зазвичай прізвище потрібно зберігати окремо від імені.

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

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

Зібравши ці відомості, ви будете готові перейти до наступного кроку.

На початок сторінки

Розподілення інформації по таблицях

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

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

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

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

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

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

Нарешті, припустимо, що компанія Coho Winery постачає лише один товар, який ви хочете видалити, але при цьому зберегти ім’я й адресу постачальника. Як видалити запис товару, не втрачаючи відомості про постачальника? Це неможливо. Оскільки кожен запис містить відомості і про товар, і про постачальника, не можна видалити одне, не видаляючи іншого. Щоб окремо зберігати ці дані, таблицю потрібно розділити на дві: одна міститиме відомості про товар, а інша – про постачальника. Видалення запису товару має призводити до видалення відомостей лише про товар, а не про постачальника.

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

На початок сторінки

Перетворення елементів інформації на стовпці

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

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

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

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

• Не додавайте обчислювані дані.    

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

• Зберігайте інформацію найменшими логічними частинами.    

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

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

На початок сторінки

Указання первинних ключів

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

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

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

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

Часто як первинний ключ використовуються довільні унікальні числа. Наприклад, можна призначити кожному замовленню унікальний номер замовлення. Номер замовлення має лише одне призначення – визначати порядок. Він не змінюється після призначення.

Якщо жоден із наявних стовпців або наборів стовпців не може стати хорошим первинним ключем, слід використати стовпець із типом даних "Лічильник". У такому стовпці Access призначає значення автоматично. Такий ідентифікатор не містить фактів – жодних фактичних даних, що описують рядок, який він представляє. Ідентифікатори, які не містять фактів, ідеально підходять для використання як первинні ключі, тому що вони не змінюються. Первинний ключ, який містить фактичну інформацію про рядок, наприклад номер телефону або ім’я клієнта, може змінитися, оскільки сама фактична інформація може змінюватися.

1. Стовпці з типом даних "Лічильник" часто є хорошими первинними ключами. Жодні ідентифікатори товарів не є однаковими.

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

Для кожної з таблиць бази даних про продажі товарів можна створити стовпець "Лічильник", який використовуватиметься як первинний ключ: "Ідентифікатор товарів" для таблиці "Товари", "Ідентифікатор замовлень" для таблиці "Замовлення", "Ідентифікатор клієнта" для таблиці "Клієнти" та "Ідентифікатор постачальника" для таблиці "Постачальники".

На початок сторінки

Створення зв’язків між таблицями

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

1. Ця форма містить відомості з таблиці "Клієнти"...

2. …таблиці "Працівники"…

3. …таблиці "Замовлення"…

4. …таблиці "Товари"…

5. …таблиці "Відомості про замовлення".

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

На початок сторінки

Удосконалення структури

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

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

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

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

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

• Чи доводиться вам повторно вводити повторювані відомості в одну з таблиць? Якщо так, можливо, необхідно розділити таблицю на дві зі зв’язком "один-до-багатьох".

• Чи є таблиці, які містять багато полів, обмежену кількість записів і багато пустих полів в окремих записах? Якщо так, варто змінити структуру таблиці, зменшивши кількість полів і збільшивши кількість записів.

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

• Чи містить кожен стовпець факт про тему таблиці? Якщо стовпець не містить відомостей про тему таблиці, він належить до іншої таблиці.

• Чи всі зв’язки між таблицями реалізовано (за допомогою спільних полів або третьої таблиці)? Для зв’язків "один-до-одного" та "один-до-багатьох" потрібні спільні стовпці. Для зв’язків "багато-до-багатьох" потрібна третя таблиця.

Застосування правил нормалізації

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

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

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