Довідники, MS Office, Програмні керівництва, статті








Довідники.

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


    Ідею статті підказало таке повідомлення на am.rusimport.ru/MSAccess/f2.aspx?type=1&id=42149


    Підкажіть, як правильно розробити структуру бази для реалізації поштової бази. Цікавить правильна зв’язок таблиць: Країна, Регіон, Місто, Вулиця.

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


    Створюємо чотири таблиці: Адресат, Довідник країни, Довідник регіони, Довідник міста. У кожній таблиці обов’язково має бути відповідне їй ключове поле (Тип Лічильник) – idАдресат, idСтрана, idРегіон, idГород. Назвати їх зрозуміло можна і по іншому.


    Зазвичай ключове поле таблиці, яке є унікальним ідентифікатором запису в цій таблиці, називають внутрішнім ключем (В нашому випадку це поля типу «Лічильник»), а ключові поля, через які зовнішні таблиці прив’язані до даної – відповідно зовнішніми ключами (В нашому випадку це числові поля Довге ціле)





























































Ім’я таблиці

Ім’я поля

Тип поля

Пов’язана таблиця

Поле в пов’язаної таблиці


Адресат


idАдресат


лічильник


Довідник країни


idСтрана


idСтрана


Довге ціле


idРегіон


Довге ціле


Довідник регіони


idРегіон


idГород


Довге ціле


Вулиця


Текстове


Довідник міста


idГород


Будинок


Текстове


Довідник країни


idСтрана


лічильник


Адресат


idСтрана


Позначення


Текстове


Довідник регіони


idРегіон


лічильник


Адресат


idРегіон


Позначення


Текстове


Довідник міста


idГород


лічильник


Адресат


idГород


Позначення


Текстове


    В посібниках для початківців розробників часто присутні міркування, яке поле зробити ключовим. Дається визначення ключових полів і наводяться приклади зв’язків між ними. На мій погляд, такі міркування тільки збивають з пантелику початківців. Адже в принципі, все досить просто: в 99% випадків краще ключове поле – лічильник. Воно 100% унікально (без повторень) і при установці зв’язку з основною таблицею (до якої підставляються дані з цього довідника) з відповідним полем Числове (Довге ціле) зв’язок автоматично визначається як один до багатьох (одна запис в довіднику і багато аналогічних записів в основний таблиці).


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


    Як видно, в довідниках тільки два поля: ключове та позначення. А основна таблиця складається в основному з числових полів, крім поля «Вулиця». Ось тут то і виявляється основна особливість побудови реляційних баз даних:


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


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


    Довідники «Вулиці» і «Дома» створювати, як мені здається, немає сенсу. Вулиць буде занадто багато, їх простіше ввести вручну.
Так само в довідкових таблицях не завадить зробити поле “Позначення” унікальним, не допускає повторень. Для цього в конструкторі таблиці у властивості поля «Індексовані поле» виберемо «Так. Повторення не допускаються ». Якщо тепер натиснути в конструкторі таблиць на кнопку «Індекси» (на ній значок блискавки), то побачимо, що в таблицю крім основного індексу ключового поля додався ще один – «Позначення».


    Імена полів таблиць не повинні містити пробілів, інакше можуть бути проблеми з VBA, і однозначно виникнуть проблеми, при перенесенні бази на SQL Server. Якщо ім’я поля складається з двох слів, то можна вибрати наприклад Такай варіант: НазваніеУліци або Названіе_уліци.


    Хоча згідно Help, ім’я може включати будь-яку комбінацію букв, цифр, і спеціальних знаків за винятком точки (.), Знаку оклику (!), Надрядкового знака (`) і квадратних дужок ([]), але бажано не використовувати в іменах полів таблиці ніяких символів, окрім букв і цифр. Справа в тому, що наприклад ім’я поля таблиці типу «Вулиця №» в проекті mdb скоріше за все не викличе ніяких конфліктів, а ось при перенесенні бази на SQL Server, майстер перенесення просто «викине» його з таблиці.


    При створенні однотипних таблиць справа піде швидше, якщо у вікні проекту «Таблиці» виділити таблицю, потім Ctrl + C або в контекстному меню при правом натисканні миші вибрати «копіювати», потім вибираємо вставити, у вікні задаємо ім’я нової таблиці і тиснемо «ОК». Залишилося тільки в ключовому полі «id …» змінити позначення (було наприклад «idГород», а тепер зробимо «idРегіон»). Останнє змінювати не потрібно. Ось тому то я у всіх довідниках ввів однотипне поле «Позначення». У таблиці «Адресат» так само створюємо зовнішні ключові поля (Довге Ціле) – idСтрана, idРегіон, idГород. Не забудьте прибрати в них значення за замовчуванням = 0.


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


    Маємо таблиці наприклад так: зліва основна – «Адресат», праворуч інші. Наводимо курсор в таблиці «Адресат» на полі «idСтрана» натискаємо і тягнемо на поле «idСтрана» в таблиці «Довідник країни». У діалоговому вікні «Зміна зв’язків» встановлюємо прапорці: «Забезпечення цілісності даних», «Каскадне оновлення пов’язаних полів» і тиснемо «ОК».



Прапорець «Забезпечення цілісності даних»


    Його встановили для того, щоб виключити можливість введення в таблицю «Адресат» в полі «idСтрана» значення, якого немає в аналогічному поле довідкової таблиці «Довідник країни». Раджу завжди так робити. Цим Ви багато в чому позбавитеся від проблеми «сміття» в базі даних – наявність ні з чим не пов’язаних записів. Правда є й інші способи «засмічення», але не зайвим буде вже у структурній схемі бази постаратися звести їх до мінімуму.



Прапорець «Каскадне оновлення пов’язаних полів»


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


    А ось прапорець «Каскадне видалення пов’язаних записів» в даному прикладі я б не рекомендував ставити. Інакше може виникнути дуже сумна ситуація: користувач вирішить видалити назву міста з відповідного довідника (мовляв, більше не потрібний), а разом з ним втечуть і всі пов’язані з ним записи в таблиці «Адресат» – це і є каскадне видалення. Правда, при всякій спробі видалення Access видає відповідне попередження, але сподіватися на те, що користувач адекватно зреагує на нього, я б не став. Каскадне видалення має сенс ставити у випадку, наприклад при зв’язку таблиць «Замовлення» та «Замовлення дані». Видаляєте замовлення, а разом з ним автоматично і всі дані по ньому, так як навіщо дані по замовленню, якого більше немає.


    Зупинюся ще на одному моменті: багатьом напевно доводилося стикатися з помилкою «Занадто велике число». Якщо не хочете мати з цим проблем, візьміть собі за правило не робити поля зі списками в таблиці (Початківці зазвичай для цього використовують майстер підстановок). Справа в тому, що через невідповідність форматів одиниць вимірювання ширини стовпців в різних версіях Access, ця сама ширина може замість стандартної 2,54 см стати … 57,2 см (дуже великим). Тому список краще зробити на формі, а в таблиці залиште просто поле.
В наступному випуску я розповім про варіанти реалізації довідкової системи без використання довідкових таблиць

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*