Спробуйте!
Бази даних і веб-програми можуть принести великі бізнес-переваги. Розробка баз даних дуже важлива для досягнення цілей, незалежно від того, чи потрібно керувати відомостями про працівників, надавати щотижневі звіти проти даних або відстежувати замовлення клієнтів. Інвестуючи час, щоб зрозуміти структуру бази даних, ви допоможете вам побудувати бази даних, які працюють правильно вперше, і що відповідає мінливим потребам.
Увага!: Веб-програми Access відрізняються від класичних баз даних. У цій статті не обговорюється оформлення веб-програм.
Поняття та терміни
Давайте почнемо з вивчення деяких основних термінів і понять. Щоб створити корисну базу даних, потрібно створити таблиці, які зосереджуються на одній темі. У таблицях відображаються всі дані, потрібні для цієї теми, у полях, які містять найменшу можливу одиницю даних.
|
Реляційні бази даних |
База даних, у якій дані розділено на таблиці, які схожі на електронні таблиці. Кожна таблиця містить лише одну тему, наприклад клієнти (одна таблиця) або товари (інша таблиця). |
|
Записи та поля |
Зберігання дискретних даних у таблиці. Рядки (або записи) містять кожну унікальну точку даних, наприклад ім'я клієнта. Стовпці (або поля) ізолюють дані, які записуються про кожну точку даних, у найменшу можливу одиницю: ім'я може бути одним стовпцем, а прізвище – іншим. |
|
Первинний ключ. |
Значення, яке гарантує, що кожен запис унікальний. Наприклад, може бути два клієнти з однаковим іменем Елізабет Андерсен. Але один з записів Елізабет Андерсен має номер 12 як свій первинний ключ, а інший має первинний ключ 58. |
|
Зв'язки між батьками та дітьми |
Спільні зв'язки між таблицями. Наприклад, один клієнт може мати кілька замовлень. Батьківські таблиці мають первинні ключі. Дочірні таблиці мають зовнішні ключі ( значення з первинного ключа, які показують, як записи дочірніх таблиць зв'язані з батьківською таблицею). Ці клавіші пов'язано за допомогою зв'язку. |
Правильна структура бази даних
Два принципи є основними для хорошого дизайну бази даних:
-
Уникайте повторюваних відомостей (які також називаються надлишковими даними). Він витрачає простір і підвищує ймовірність помилок.
-
Переконайтеся, що дані правильні та повні. Неповні або помилкові інформаційні потоки в запитах і звітах і в кінцевому підсумку можуть призвести до дезінформованих рішень.
Щоб вирішити ці проблеми, виконайте наведені нижче дії.
-
Розділіть відомості бази даних на тематичні таблиці з вузьким фокусом. Уникайте дублювання даних у кількох таблицях. (Наприклад, імена клієнтів мають відображатися лише в одній таблиці.)
-
Об'єднуйте таблиці за допомогою клавіш, а не дублювання даних.
-
Включити процеси, які підтримують і забезпечують точність і цілісність відомостей про базу даних.
-
Спроектувати базу даних із урахуванням потреб обробки даних і звітування.
Щоб покращити довгострокову корисність баз даних, виконайте наведені нижче п'ять кроків розробки.
Крок 1. Визначення призначення бази даних
Перш ніж почати, маєте мету для бази даних.
Щоб зосередитися на макеті, узагальнюйте призначення бази даних і часто звертайтеся до зведення. Наприклад, якщо вам потрібна невелика база даних для домашнього бізнесу, можна написати щось просте, наприклад: "База даних клієнтів зберігає список відомостей про клієнтів для створення розсилки та звітів". Для корпоративної бази даних може знадобитися кілька абзаців, щоб описати, коли та як користувачі з різними ролями використовуватимуть базу даних і її дані. Створення конкретну і детальну заяву про місію, щоб посилатися на весь процес проектування.
Крок 2. Пошук і впорядкування обов'язкових відомостей
Зберіть усі типи відомостей, які потрібно записати, наприклад назви продуктів і номери замовлень.
Почніть із наявних відомостей і методів відстеження. Наприклад, ви зараз записуєте замовлення на придбання в бухгалтерській книзі або зберігаєте відомості про клієнтів у паперових формах. За допомогою цих джерел можна перелічити інформацію, яку ви зараз записуєте (наприклад, усі поля у формах). Якщо ви зараз не записуєте важливу інформацію, подумайте про те, яка окрема інформація вам потрібна. Кожен окремий тип даних стає полем бази даних.
Не турбуйтеся про те, щоб зробити перший список ідеальним – ви можете точно налаштувати його з часом. Але врахуйте всіх людей, які використовують цю інформацію, і попросіть свої ідеї.
Далі подумайте про те, що потрібно зробити з бази даних, а також про типи звітів або розсилки, які потрібно створити. Потім переконайтеся, що ви записуєте інформацію, необхідну для досягнення цих цілей. Наприклад, якщо потрібно відобразити звіт про збут за регіонами, потрібно записати дані про збут на регіональному рівні. Спробуйте створити ескіз звіту з актуальними відомостями, які потрібно переглянути. Потім перелічіть дані, потрібні для створення звіту. Зробіть те ж саме для розсилки або інших результатів, потрібних із бази даних.
Приклад
Припустімо, ви надаєте клієнтам можливість періодично отримувати (або не виходити з) періодичних оновлень електронної пошти, і хочете роздрукувати список тих, хто вибрав цю програму. У таблиці "Клієнти" потрібен стовпець "Надіслати повідомлення електронної пошти" з допустимими значеннями "Так" і "Ні".
Для тих, хто бажає отримувати електронні листи, потрібна адреса електронної пошти, для якої також потрібне поле. Якщо потрібно додати правильне привітання (наприклад, "Містер", "Місіс" або "Пані"), додайте поле привітання. Якщо потрібно звернутися до клієнтів за їхнім ім'ям у повідомленнях електронної пошти, додайте поле "Ім'я".
Порада.: Не забудьте розбити кожен фрагмент інформації на найменшу корисну частину, наприклад ім'я та прізвище для таблиці клієнта. Загалом, якщо потрібно сортувати, шукати, обчислювати або звітувати на основі елемента інформації (наприклад, прізвища клієнта), слід помістити цей елемент у відповідне поле.
Крок 3. Розділення інформації на таблиці
Розділіть елементи інформації на основні сутності або предмети, наприклад продукти, клієнтів і замовлення. Кожна тема стає таблицею.
Отримавши список обов'язкових відомостей, визначте основні сутності (або предмети), необхідні для впорядкування даних. Уникайте дублювання даних у сутностях. Наприклад, попередній список бази даних про продаж продуктів може мати такий вигляд:
Основні сутності: клієнти, постачальники, продукти та замовлення. Отже, почніть з цих чотирьох таблиць: одна для фактів про клієнтів, одна для фактів про постачальників тощо. Можливо, це не остаточний макет, але це хороша відправна точка.
Примітка.: Найкращі бази даних містять кілька таблиць. Уникайте спокуси розмістити всю свою інформацію в одній таблиці. Це призводить до повторюваних відомостей, більшого розміру бази даних і збільшених помилок. Дизайн, щоб записати кожен факт тільки один раз. Якщо ви знайшли собі повторювану інформацію, наприклад адресу постачальника, переструктуруйте базу даних, щоб розмістити ці відомості в окремій таблиці.
Щоб зрозуміти, чому більше таблиць краще, ніж менше, розгляньте наведену тут таблицю.
Кожен рядок містить відомості про товар і його постачальника. Оскільки у вас може бути багато товарів від одного постачальника, ім'я й адреса постачальника потрібно повторювати багато разів. Це призведе до використання зайвого дискового простору. Натомість запишіть відомості про постачальника лише один раз в окремій таблиці "Постачальники", а потім зв'яжіть цю таблицю з таблицею "Товари".
Друга проблема з цією конструкцією стає очевидною, якщо потрібно змінити відомості про постачальника. Припустімо, потрібно змінити адресу постачальника. Оскільки вона з’являється в багатьох місцях, ви можете випадково змінити її один раз, але забути зробити це в інших місцях. Записування адреси постачальника лише в одному місці вирішує цю проблему.
Нарешті, припустімо, що є лише один товар, наданий компанією Coho Winery, і ви хочете видалити продукт, але зберегти ім'я та адресу постачальника. З цією структурою, як би ви видалили запис продукту, не втрачаючи відомості про постачальника? Це неможливо. Оскільки кожен запис містить факти про товар на додачу до фактів про постачальника, його неможливо видалити, не видаляючи інший. Щоб зберегти ці факти окремо, розділяйте цю таблицю на дві: першу для відомостей про продукт, а другу – на відомості про постачальника. Потім, видаляючи запис продукту, ви видаляєте лише факти про товар, а не факти про постачальника.
Крок 4. Перетворення елементів відомостей на стовпці
Вирішіть, які відомості потрібно зберігати в кожній таблиці. Ці дискретні фрагменти даних стають полями в таблиці. Наприклад, таблиця "Працівники" може містити такі поля, як "Прізвище", "Ім'я" та "Дата прийому на роботу".
Після того як тему для таблиці бази даних вибрано, стовпці в цій таблиці мають містити лише відомості про цю тему. Наприклад, у таблиці товарів мають зберігатися факти лише про товари, а не про їхніх постачальників.
Щоб вирішити, які відомості слід відстежувати в таблиці, скористайтеся списком, створеним раніше. Наприклад, таблиця "Клієнти" може містити такі елементи: Ім'я, Прізвище, Адреса, Надіслати повідомлення електронної пошти, Привітання та Адреса електронної пошти. Кожен запис (клієнт) у таблиці містить однаковий набір стовпців, тому ви зберігаєте однакову інформацію для кожного клієнта.
Створення перший список, а потім перегляньте та уточніть його. Не забудьте розбити інформацію на найменші можливі поля. Наприклад, якщо початковий список містить поле Адреса як поле, розведіть його на адресу вулиці, місто, область і поштовий індекс або, якщо клієнти глобальні, на ще більше полів. Таким чином, наприклад, можна робити розсилки в належному форматі або звітувати про замовлення за штатом.
Після уточнення стовпців даних у кожній таблиці можна вибрати первинний ключ кожної таблиці.
Крок 5. Визначення первинних ключів
Виберіть первинний ключ для кожної таблиці. Первинний ключ, наприклад "Ідентифікатор товару" або "Ідентифікатор замовлення", однозначно визначає кожен запис. Якщо у вас немає явного унікального ідентифікатора, скористайтеся програмою Access, щоб створити його для вас.
Вам потрібен спосіб унікальної ідентифікації кожного рядка в кожній таблиці. Пам'ятаєте попередній приклад, у якому два клієнти мають однакове ім'я? Оскільки вони мають спільне ім'я, вам потрібен спосіб окремо ідентифікувати кожне ім'я.
Отже, кожна таблиця має містити стовпець (або набір стовпців), який однозначно ідентифікує кожен рядок. Це називається первинним ключем і часто є унікальним номером, наприклад ідентифікаційним номером працівника або серійним номером. Програма Access використовує первинні ключі, щоб швидко зв'язувати дані з кількох таблиць і об'єднувати їх.
Іноді первинний ключ складається з двох або більше полів. Наприклад, у таблиці "Відомості про замовлення", де зберігаються позиції для замовлень, первинний ключ може містити два стовпці: "Ідентифікатор замовлення" та "Ідентифікатор товару". Якщо первинний ключ використовує кілька стовпців, він також називається складеним ключем.
Якщо у вас уже є унікальний ідентифікатор інформації в таблиці, наприклад номери продуктів, які однозначно ідентифікують кожен товар у каталозі, використовуйте його, але лише якщо значення відповідають цим правилам первинних ключів:
-
Ідентифікатор завжди буде різним для кожного запису. Повторювані значення не дозволені в первинному ключі.
-
Для елемента завжди є значення. Кожен запис у таблиці має містити первинний ключ. Якщо для створення ключа (наприклад, "Родина" та "Номер частини" використовується кілька стовпців, обидва значення мають бути завжди присутні.
-
Первинний ключ – це значення, яке не змінюється. Оскільки на ключі посилаються інші таблиці, будь-яка зміна первинного ключа в одній таблиці означає зміну всюди, де на нього посилаються. Часті зміни підвищують ризик виникнення помилок.
Якщо у вас немає явного ідентифікатора, як первинний ключ використовуйте довільне унікальне число. Наприклад, ви можете призначити кожному замовленню унікальний номер замовлення з єдиною метою визначення замовлення.
Порада.: Щоб створити як первинний ключ унікальне число, додайте стовпець за допомогою типу даних "Лічильник". Тип даних "Автонумерація" автоматично призначає кожному запису унікальне числове значення. Цей тип ідентифікатора не містить фактичних відомостей, що описують рядок, який він представляє. Його зручно використовувати як первинний ключ, оскільки числа не змінюються, на відміну від первинного ключа, який містить відомості про рядок, наприклад номер телефону або ім'я клієнта.
Бажаєте отримати додаткову інформацію?
Керівні принципи іменування полів, елементів керування та об’єктів
Потрібна додаткова довідка?
Потрібні додаткові параметри?
Ознайомтеся з перевагами передплати, перегляньте навчальні курси, дізнайтесь, як захистити свій пристрій тощо.
Спільноти допомагають ставити запитання й відповідати на них, надавати відгуки та дізнаватися думки висококваліфікованих експертів.
