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

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

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

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

Увага! : В Access можна створювати програми баз даних для Інтернету. Структура для Інтернету має багато особливостей. У цій статті не обговорюється структура програм баз даних для Інтернету. Докладні відомості див. в статті Створення бази даних для спільного використання в Інтернеті.

У цій статті

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

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

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

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

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

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

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

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

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

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

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


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

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

Зображення трьох таблиць у таблицях даних

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

уявний звіт про запаси товарів

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

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

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

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

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

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

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

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

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

рукописні елементи даних, згруповані відповідно до тем

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

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

Зображення таблиці, яка містить товари та постачальників

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зображення таблиці «Товари» з полем первинного ключа.

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

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

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

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


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

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

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

Форма «Замовлення»

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

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

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

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

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

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

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

Створення зв’язку "один-до-багатьох"

Розгляньмо такий приклад: таблиці "Постачальники" та "Товари" в базі даних замовлень товарів. Постачальник може постачати будь-яку кількість товарів. З цього випливає, що для будь-якого постачальника, представленого в таблиці "Постачальники", може бути кілька товарів у таблиці "Товари". Отже, між таблицями "Постачальники" та "Товари" існує зв’язок "один-до-багатьох".

поняття зв'язку «один-до-багатьох»

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

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

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

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

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

Створення зв’язку "багато-до-багатьох"

Давайте розглянемо зв’язок між таблицями "Товари" та "Замовлення".

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

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

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

зв'язок «багато-до-багатьох»

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

У базі даних про продажі таблиці "Замовлення" та "Товари" напряму не зв’язані між собою. Натомість вони зв’язані опосередковано через таблицю "Відомості про замовлення". Зв’язок "багато-до-багатьох" між замовленнями й товарами представлено в базі даних за допомогою двох зв’язків "один-до-багатьох":

  • Таблиці "Замовлення" та "Відомості про замовлення" мають зв’язок "один-до-багатьох". Кожне замовлення може містити кілька позицій, але кожна позиція зв’язана лише з одним замовленням.

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

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

Якщо включити таблицю "Відомості про замовлення", список таблиць і полів може мати приблизно такий вигляд:

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


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

Знімок екрана із зображенням доступних емограм і елемента керування для їх активації та деактивації

Ще один тип зв’язку – "один-до-одного". Припустімо, що потрібно записати певну спеціальну додаткову інформацію про товари, яка вам буде потрібна рідко або яка стосується лише кількох товарів. Оскільки ця інформація потрібна вам нечасто, а зберігаючи її в таблиці "Товари", ви отримаєте пусті поля для тих товарів, яких вона не стосується, слід розмістити таку інформацію в окремій таблиці. Як і в таблиці "Товари", як первинний ключ використовується "Ідентифікатор товару". Зв’язок між додатковою таблицею й таблицею "Товари" – "один-до-одного". Кожному запису в таблиці "Товари" відповідає єдиний запис у додатковій таблиці. Коли ви визначаєте такий зв’язок, в обидвох таблицях має бути спільне поле.

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

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

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

Визначення зв’язків між таблицями допомагає створити правильні таблиці та стовпці. За наявності зв’язку "один-до-одного" або "один-до-багатьох" у пов’язаних таблицях має бути один чи кільках спільних стовпців. Щоб реалізувати зв’язок "багато-до-багатьох", знадобиться третя таблиця.

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

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

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

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

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

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

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

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

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

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

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

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

Удосконалення таблиці "Товари"

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

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

Краще ввести в базу даних нову тему для відстеження – "Категорії". Вона матиме власну таблицю та власний первинний ключ. Потім ви можете додати первинний ключ із таблиці "Категорії" до таблиці "Товари" як зовнішній ключ.

Між таблицями "Категорії" та "Товари" є зв’язок "один-до-багатьох": категорія може містити більше одного товару, але товар може належати лише до однієї категорії.

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

  • Ідентифікатор товару;

  • Назва;

  • Ідентифікатор товару 1;

  • Назва 1;

  • Ідентифікатор товару 2;

  • Назва 2;

  • Ідентифікатор товару 3;

  • Назва 3.

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

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

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

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

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

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

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

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

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

Перша нормальна форма

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

Друга нормальна форма

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

  • Ідентифікатор замовлення (первинний ключ);

  • Ідентифікатор товару (первинний ключ);

  • Назва товару.

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

Третя нормальна форма

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

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

  • Ідентифікатор товару (первинний ключ);

  • Назва;

  • РРЦ;

  • Знижка.

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

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

Отримуйте нові функції раніше за інших
Приєднайтеся до оцінювачів Office

Ця інформація корисна?

Дякуємо за ваш відгук!

Дякуємо за відгук! Схоже, вам може стати в нагоді допомога одного з наших спеціалістів служби підтримки Office, з яким ми вас можемо з’єднати.

×