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

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

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

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

У цій статті

Термінологія баз даних

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

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

Визначення мети створення бази даних

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

Розділення даних на таблиці

Перетворення елементів даних на стовпці

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

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

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

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


Термінологія баз даних

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

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

Кожен рядок також називається записом, а кожен стовпець – полем. Запис – це осмислений і узгоджений спосіб поєднання відомостей про щось. Поле – це окремий елемент відомостей – тип елемента, відображений у кожному записі. Наприклад, у таблиці «Товари» кожен рядок або запис містить відомості про один товар. Кожен стовпець або поле містить певні типи відомостей про товар, наприклад назву або ціну.

Вгорі сторінки

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

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

Ознаки правильної структури бази даних:

  • Розділення даних на тематичні таблиці для зменшення обсягу надлишкових даних.

  • Забезпечення Access відомостями, необхідними для об'єднання даних у таблицях.

  • Допомога в підтриманні та забезпеченні точності й цілісності інформації.

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

Вгорі сторінки

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

Процес розробки складається з таких кроків:

  • Визначення мети створення бази даних    

    Допомагає підготуватися до виконання наступних кроків.

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

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

  • Розділення даних на таблиці    

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

  • Перетворення елементів даних на стовпці    

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

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

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

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

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

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

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

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

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

Вгорі сторінки

Визначення мети створення бази даних

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

Вгорі сторінки

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

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

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

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

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

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

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

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

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

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

Після того, як дані зібрано можна перейти до наступного кроку.

Вгорі сторінки

Розділення даних на таблиці

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

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

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

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

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

У цьому разі кожен рядок містить відомості про товари та постачальників. Оскільки один постачальник може постачати кілька товарів, ім'я постачальника та відомості про адресу потрібно повторити кілька разів. У разі виконання таких дій місце на диску витрачається марно. Найкраще рішення — внести відомості про постачальника лише один раз в окрему таблицю «Постачальники», відтак зв'язати цю таблицю з таблицею «Товари».

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

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

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

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

Вгорі сторінки

Перетворення елементів даних на стовпці

Для визначення стовпців у таблиці вирішіть, які дані потрібно відстежувати відповідно до теми таблиці. Наприклад, у таблицю «Клієнти» можна включити такі стовпці, як «Ім’я», «Адреса», «Місто/Область/Поштовий індекс», «Надсилання електронної пошти», «Привітання» й «Адреса електронної пошти». Кожен запис у таблиці містить однаковий набір стовпців, отже для кожного запису можна зберегти відповідні відомості у стовпцях «Ім’я», «Адреса», «Місто/Область/Поштовий індекс», «Надсилання електронної пошти», «Привітання» й «Адреса електронної пошти». Наприклад, стовпець «Адреса» містить адреси клієнтів. Кожен запис містить дані лише про одного клієнта, а поле адреси містить адресу цього клієнта.

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

Також слід визначити, чи база даних міститиме відомості місцевого або міжнародного походження. Наприклад, якщо заплановано зберігати міжнародні адреси, краще використати стовпець «Регіон» замість стовпця «Область», оскільки цей стовпець може об'єднувати області вашої країни та регіони інших країн. Аналогічно, краще використати стовпець «Поштовий індекс» або стовпець «Поштовий індекс для США» («Zip Code»), якщо заплановано збереження міжнародних адрес.

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

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

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

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

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

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

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

Вгорі сторінки

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

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

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

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

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

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

Якщо не вдалося вибрати стовпець або набір стовпців для використання як первинного ключа, краще використати стовпець із типом даних «Автонумерація». У разі використання типу даних «Автонумерація» Access автоматично призначає значення. Такий ідентифікатор не містить даних; він не містить фактичних даних, що описують рядок, якому він відповідає. Беззмістовні ідентифікатори є оптимальними для використання як первинного ключа, оскільки вони не змінюються. Первинний ключ, який містить дані про рядок  — наприклад, номер телефону або ім'я клієнта — може змінитися, оскільки можуть змінитися фактичні дані

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

1. Стовпець з типом даних «Автонумерація» є оптимальним для створення первинного ключа. Коди товарів не співпадають.

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

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

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


Вгорі сторінки

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

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

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

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

2. ...з таблиці «Працівники»...

3. ...з таблиці «Замовлення»...

4. ...з таблиці «Товари»...

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

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

Вгорі сторінки

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

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

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

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

Стовпець «Код постачальника» в таблиці «Товари» називається зовнішнім ключем. Зовнішній ключ — це первинний ключ іншої таблиці. Стовпець «Код постачальника» в таблиці «Товари» є зовнішнім ключем, оскільки він є також первинним ключем таблиці «Постачальники».

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

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

Вгорі сторінки

Створення зв'язку «багато-до-багатьох»

Розгляньмо зв'язок між таблицями «Товари» та «Замовлення».

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

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

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

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

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

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

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

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

У таблиці «Відомості про замовлення» можна визначити всі товари в певному замовленні. Також можна визначити всі замовлення на окремий товар.

Після застосування таблиці «Відомості про замовлення» список таблиць і полів може мати такий вигляд:

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


Вгорі сторінки

Створення зв'язку «один-до-одного»

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

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

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

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

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

Вгорі сторінки

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

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

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

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

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

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

  • Наявність багаторазових повторень даних у таблиці. У такому разі потрібно поділити таблицю на дві таблиці зі зв’язком «один-до-багатьох».

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

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

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

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

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

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

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

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

Таблиці «Категорії» та «Товари» мають зв'язок «один-до-багатьох»: категорія може містити кілька товарів, однак, товар може належати лише до однієї категорії.

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

  • Код товару

  • Назва

  • Код товару1

  • Назва1

  • Код товару2

  • Назва2

  • Код товару3

  • Назва3

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

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

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

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

Вгорі сторінки

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

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

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

Правила нормалізації застосовуються послідовно, отже на кожному кроці перевіряється відповідність одній із «нормальних форм». Широко використовуються п'ять нормальних форм — з першої нормальної форми до п'ятої. У цій статті описано перші три форми, оскільки їх застосування достатньо для структури більшості баз даних.

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

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

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

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

  • «Код замовлення» (первинний ключ)

  • «Код товару» (первинний ключ)

  • «Назва товару»

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

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

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

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

  • «Код товару» (первинний ключ)

  • «Назва»

  • «Рекомендована роздрібна ціна»

  • «Знижка»

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

Вгорі сторінки

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

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

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

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

×