У наведених нижче розділах показано, як було розроблено зв'язки між таблицями бази даних. Імена об'єктів надаються, тому їх можна легко перевірити в базі даних Northwind 2.0 Starter Edition.
Щоб відкрити схему зв'язків із шістьма таблицями та зв'язками між ними, виберіть Знаряддя бази даних > Зв'язки.
На цій схемі відображено всі шість таблиць. На схемі лінії між таблицями визначають зв'язки між ними. 1 і символ нескінченності (∞) у кінцях рядків позначають односторонній зв'язок (наприклад, один клієнт) і зв'язок "багато". Наприклад, один клієнт надсилає багато замовлень. Докладні відомості див. в статті Посібник зі зв'язків між таблицями.
Наведені нижче принципи застосовуються до таблиць у Northwind 2.0 Starter Edition, а також до таблиць у цілому.
Первинні ключі Унікальний ідентифікатор кожного запису в таблиці. Усі таблиці мають первинний ключ. На схемі зв'язків символи ключів визначають ці первинні ключі. Правила іменування первинних ключів називаються для таблиці, у якій вони знаходяться, наприклад "TableNameID".
Ефективність Для підвищення продуктивності та ефективнішого зберігання первинні ключі мають бути числовими. Крім того, зручніше, щоб програма Access автоматично створюла нове унікальне значення для первинного ключа кожного нового запису. Тип даних "Автонумерація" має обидві характеристики. Функції "Автонумерація" – це інакше незнані числа та не призначені для інших цілей. Докладні відомості див. в статті Додавання поля автонумерації як первинного ключа.
Зовнішні ключі Таблиця також може мати один або кілька зовнішніх ключів залежно від того, чи пов'язано вона з іншими таблицями в базі даних. Зовнішній ключ містить значення, які відповідають значенням первинного ключа пов'язаної таблиці.
Унікальні індекси Інші поля в таблицях також можуть мати власні унікальні індекси, наприклад OrderStatus.StatusCode. Нелогічно мати в таблиці OrderStatus два стани замовлень з однаковим кодом, навіть якщо StatusCode не є первинним ключем. Унікальний індекс повідомляє Access про запобігання повторюваним значенням у цьому полі.
Неунікальний індекс Таблиці також можуть містити індекси, щоб прискорити пошук і сортування за цими полями, наприклад Orders.OrderDate. Багато замовлень можна розмістити в один день, і вам часто потрібно виконати пошук і сортування за датами замовлень. У цьому полі є неунікальний індекс, який дає змогу прискорити пошук і сортування.
Імена таблиць і полів Ви можете назвати елементи будь-яким способом, але послідовність важлива. Радимо, щоб імена таблиць і полів були одним або кількома словами без пробілів між ними, а спеціальні символи, як-от скісна риска (/), знак фунта (#) або відсоток (%). Наприклад, використовуйте "Дата_замовлення", але не "Дата замовлення"; використовуйте "Номер замовлення" або "Номер замовлення", але не "Замовлення#".
Верблюжий регістр Щоб виділити окремі частини імені з великої букви, наприклад "Дата_замовлення", але не "Дата_замовлення" або "Дата_замовлення", зробіть ось що.
Обов'язкове значення Цей принцип викликає важливість бізнес-правил для програми. У деяких ситуаціях потрібні значення або навіть певні значення в деяких полях. Наприклад, що таке замовлення, не знаючи, хто його розмістив? Це означає, що CustomerID – обов'язкове поле для таблиці "Замовлення".
Обчислювані поля Access підтримує обчислювані поля в таблицях, наприклад поле Employees.FullName. Можливо, вам зручніше створювати обчислювані поля в запиті, а не в таблиці.
Поля вкладень Програма Access підтримує поля вкладень, наприклад Employees.Picture із зображенням працівника. Вкладення можуть зберігати зображення, документи, повідомлення електронної пошти та іншу двійкову інформацію. Вкладення займають багато місця в базі даних. натомість ефективніше зберігати вкладення на файловому сервері.
Багатозначні поля Як випливає з назви, багатозначні поля зберігають одне або кілька значень в одному полі, наприклад Employees.Title. Радимо використовувати їх економно, особливо якщо потрібно змінити розмір бази даних. Більшість інших систем баз даних не мають їх, тому для цього потрібно буде багато повторної роботи.
Докладні відомості про типи даних див. в статті Загальні відомості про типи даних і властивості поля.
У цьому розділі описано найважливіші функції кожної таблиці. Щоб переглянути структуру таблиці, виберіть її в області переходів, клацніть її правою кнопкою миші, виберіть конструктор або знаряддя бази даних > зв'язки, а потім клацніть об'єкт таблиці правою кнопкою миші. Докладні відомості див. в статті Загальні відомості про таблиці.
Увага!: Уникайте використання зарезервованих слів, які можуть спричинити конфлікти іменування. Докладні відомості див. в статті Відомості про зарезервовані слова та символи Access.
Таблиця "Працівники"
У цій таблиці зберігаються відомості про співробітників компанії Northwind.
|
Поля |
Опис |
|
Ім'я, прізвище |
Обидва імена обов'язкові, і в Northwind разом вони повинні бути унікальною комбінацією. У макеті таблиці, коли ви відкриваєте діалогове вікно Індекси , ви можете побачити, що ім'я + прізвище мають унікальний індекс. Оскільки імена "Ім'я" та "Прізвище" індексуються унікальним чином, у таблиці Northwind не можна зберігати двох працівників з однаковим іменем. В інших випадках можна використовувати інше бізнес-правило. |
|
FullNameFNLN, |
Перегляньте властивість виразу обчислюваних полів, щоб дізнатися, як Access об'єднує значення в обчислюваних полях. Щоб додати середній ініціал, додайте його до наявного виразу з відповідним інтервалом між компонентами. |
|
Поля телефона |
Ділове правило для телефонів полягає в тому, що параметри працівників більш актуальні, ніж тип обслуговування. Тому основний і додатковий номери телефонів використовуються замість клітинок, офісів, дому тощо. |
|
Привітання |
Привітання – це поле "Короткий текст". Щоб проілюструвати функцію багатозначного поля в Access, це поле зі списком із доступним для редагування списком попередньо визначених значень. Короткі статичні списки, як це часто є кандидатами на багатозначні поля, тому що вони не змінюються багато, якщо коли-небудь. |
|
Заголовок завдання |
JobTitle – це ще одне обов'язкове поле. |
Таблиця "Клієнти"
У цій таблиці зберігаються відомості про клієнтів компанії Northwind.
|
Поля |
Опис |
|
Ім'я клієнта |
Клієнти компанії Northwind є компаніями, і потрібно імені клієнта. На відміну від імен працівників, вона не індексується унікальним чином, що дозволяє двом або більше клієнтам мати однакове ім'я. |
|
PrimaryContactFirstName, PrimaryContactLastName, |
Імена та прізвища та посада основного контакту не обов'язкові, оскільки клієнти можуть не мати одну особу як основну контактну особу. Контакти не можуть надати посаду для замовлення. |
|
BusinessPhone |
Для компанії Northwind для кожного клієнта потрібен лише один номер телефону, хоча це дає змогу записувати кілька номерів телефонів для клієнтів або контактів із клієнтів. У реальних ситуаціях більш складні бізнес-правила зазвичай застосовуються до контактної інформації. |
|
Адреса, місто |
Компанії Northwind потрібна адреса для доставки замовлень клієнтам. Клієнту призначено лише одну загальну адресу. У реальних ситуаціях клієнти часто мають окремі адреси для виставлення рахунків, доставки або інші адреси. Для іншого бізнес-правила для організації потрібні додаткові поля. |
|
Примітки |
Поле Notes – це тип даних "Довгий текст", у якому зберігається до 1 ГБ тексту. Це дає змогу вводити докладні коментарі про клієнтів для використання в подальших ситуаціях замовлення. |
Таблиця "Замовлення"
У цій таблиці зберігаються відомості про замовлення компанії Northwind.
|
Поля |
Опис |
|
Дата замовлення, дата доставки, платна дата |
Замовлення потребують трьох дат. Усі вони мають тип даних "Дата й час", але мають два формати. Дата_замовлення містить дату та час, оскільки вам може бути цікаво проаналізувати обсяг замовлень для різних частин дня. Для двох інших дат потрібна лише дата. Правило перевірки таблиці для "Дата доставки" та "Оплачено_ дата" гарантує, що ці дати не передують даті "Дата_замовлення". |
|
Ідентифікатор статистики замовлення |
Стан замовлення вказує, де розташовано порядок у робочому циклі Компанії Northwind. Замовлення переміщуються через чотири етапи: новий –> виставлений рахунок-фактура –> доставлено – > Закрито.Зовнішній ключ для поточного OrderStatus використовує OrderStatusID із таблиці підстановки OrderStatus. Використання таблиці підстановки стану гарантує, що замовлення можна призначити лише чотирьом попередньо визначеним статусам. |
Таблиця відомостей про замовлення
У цій таблиці зберігаються відомості про замовлення компанії Northwind.
|
Поля |
Опис |
|
Ідентифікатор замовлення |
Кожен елемент рядка в таблиці OrderDetails має належати до одного замовлення в таблиці "Замовлення". OrderID – це зовнішній ключ, який визначає цей порядок. Як зазначалося раніше, один порядок, який містить один або кілька елементів рядка, ілюструє зв'язок "один-до-багатьох". |
|
Ідентифікатор продукту |
Кожен запис у таблиці OrderDetails містить код товару, замовленого. ProductID – це зовнішній ключ у таблиці OrderDetails, який визначає, що Продукт у такому порядку. Це також зв'язок "один-до-багатьох". |
|
Ідентифікатор замовлення+ ідентифікатор товару |
Як показано в таблиці "Працівники", кілька полів можуть мати унікальний індекс. Унікальний індекс за кодом замовлення та ідентифікатором товару в таблиці OrderDetails гарантує, що кожне замовлення містить продукт лише один раз. Якщо відкрити аркуш властивостей Індекси на стрічці, відобразиться цей унікальний індекс. |
Таблиця "Товари"
У цій таблиці зберігаються відомості про продукти компанії Northwind.
|
Поля |
Опис |
|
Код продукту |
Окрім первинного ключа, продукти ProductID, Northwind мають унікальний індексований код продукту для людей. Працівники зазвичай посилаються на коди продуктів, а не значення первинного ключа. Код продукту – це складене значення, яке складається з позначення категорії та числа, наприклад B-1 для "Напої", продукту 1. |
|
"Назва товару", |
Окрім коротких назв продуктів, до продуктів застосовується довгий текстовий опис. Це значення можна використовувати в описі каталогу або відповіді на запитання клієнтів. |
|
Ціна за одиницю |
Усі продукти продаються з ціною за одиницю для кожного елемента, що спрощує базу даних як демонстрацію функцій. У більшості реальних ситуацій ціни часто значно складніші. |
Див. також
