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

1. Основи роботи з базами даних
2. Вимоги до баз даних
3. Основні концепції реляційних баз даних
4. Кроки проектування бази даних
5. Приведення до першої нормальної формі
6. Приведення до другої нормальної форми
7. Приведення до третьої нормальної формі
8. Висновок

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

зміст

огляд

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

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

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

Вимоги до баз даних

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

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

Наступні пункти представляють основні кроки проектування бази даних:

1. Визначити інформаційні потреби бази даних.
2. Проаналізувати об'єкти реального світу, які необхідно змоделювати в базі даних. Сформувати з цих об'єктів суті і характеристики цих сутностей (наприклад, для сутності "деталь" характеристиками можуть бути "назва", "колір", "вага" і т.п.) і сформувати їх список.
3. Поставити у відповідність сутностям і характеристикам - таблиці і стовпчики (поля) в нотації обраної Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle і т.д.).
4. Визначити атрибути, які унікальним чином ідентифікують кожен об'єкт.
5. Виробити правила, які будуть встановлювати і підтримувати цілісність даних.
6. Встановити зв'язки між об'єктами (таблицями і стовпцями), провести нормалізацію таблиць.
7. Спланувати питання надійності даних і, при необхідності, збереження секретності інформації.

Основні концепції реляційних баз даних

Перш ніж докладно розглядати кожен з цих кроків, зупинимося на основних концепціях реляційних баз даних. У реляційної теорії одним з головних є поняття відносини. Математично відношення визначається наступним чином. Нехай дано n множин D1, D2, ..., Dn. Тоді R є відношення над цими множинами, якщо R є безліч впорядкованих наборів вигляду <d1, d2, ..., dn>, де d1 - елемент з D1, d2 - елемент з D2, ..., dn - елемент з Dn. При цьому набори вигляду <d1, d2, ..., dn> називаються кортежами, а безлічі D1, D2, ..., Dn - доменами. Кожен кортеж складається з елементів, які обирають зі своїх доменів. Ці елементи називаються атрибутами, а їх значення - значеннями атрибутів. Мал. помилка! текст зазначеного стилю в документі отсутствует.-a являє нам графічне зображення відношення з різних точок зору.

Мал. Помилка! Текст зазначеного стилю в документі відсутня. -A: Терміни реляційної теорії і їх співвідношення з обробкою даних

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

• відношення, таблиця, файл (для локальних баз даних)
• кортеж, рядок, запис
• атрибут, стовпець, поле.

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

Атрибут (або набір атрибутів), який може бути використаний для однозначної ідентифікації конкретного кортежу (рядка, записи), називається первинним ключем. Первинний ключ не повинен мати додаткових атрибутів. Це означає, що якщо з первинного ключа виключити довільний атрибут, що залишилися атрибутів буде недостатньо для однозначної ідентифікації окремих кортежів. Для прискорення доступу по первинному ключу у всіх системах управління базами даних (СКБД) є механізм, званий індексуванням. Грубо кажучи, індекс являє собою інвертований деревовидний список, який вказує на справжнє місце розташування записи для кожного первинного ключа. Природно, в різних СУБД індекси реалізовані по-різному (в локальних СУБД - як правило, у вигляді окремих файлів), однак, принципи їх організації однакові.

Можливо індексування відносини з використанням атрибутів, відмінних від первинного ключа. Даний тип індексу називається вторинним індексом і застосовується з метою зменшення часу доступу при знаходженні даних щодо, а також для сортування. Таким чином, якщо саме ставлення не впорядковано якимось чином і в ньому можуть бути присутніми рядки, що залишилися після видалення деяких кортежів, то індекс (для локальних СУБД - індексний файл), навпаки, відсортований.

Для підтримки посилальної цілісності даних в багатьох СУБД є механізм так званих зовнішніх ключів. Сенс цього механізму полягає в тому, що якомусь атрибуту (або групі атрибутів) одного відношення призначається посилання на первинний ключ іншого відношення; тим самим закріплюються зв'язку підпорядкованості між цими відносинами. При цьому відношення, на первинний ключ якого посилається зовнішній ключ іншого відношення, називається master-ставленням, або головним відношенням; а відношення, від якого виходить посилання, називається detail-відношенням, або підлеглим ставленням. Після призначення такого посилання СУБД має можливість автоматично відстежувати питання "непорушення" зв'язків між відносинами, а саме:

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

Зауваження. Існує два підходи до видалення і зміни записів з головної таблиці:

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

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

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

Кроки проектування бази даних

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

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

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

Формування концептуальної моделі бази даних включає в себе:

• ідентифікацію функціональної діяльності Вашої предметної області. Наприклад, якщо мова йде про діяльність підприємства, то в якості функціональної діяльності можна ідентифікувати ведення обліку працюючих, відвантаження продукції, оформлення замовлень і т.п.
• ідентифікацію об'єктів, які здійснюють цю функціональну діяльність, і формування з їх операцій послідовності подій, які допоможуть Вам ідентифікувати всі сутності і взаємозв'язку між ними. Наприклад, процес "ведення обліку працюючих" ідентифікує такі сутності як ПРАЦІВНИК, ПРОФЕСІЯ, ВІДДІЛ.
• ідентифікацію характеристик цих сутностей. Наприклад, сутність ПРАЦІВНИК може включати такі характеристики як Ідентифікатор Працівника, Прізвище, Ім'я, По батькові, Професія, Зарплата.
• ідентифікацію взаємозв'язків між сутностями. Наприклад, яким чином сутності ПРАЦІВНИК, ПРОФЕСІЯ, ВІДДІЛ взаємодіють один з одним? Працівник має одну професію (для простоти!) І значиться в одному відділі, в той час як в одному відділі може перебувати багато працівників.

III. Третій крок полягає у встановленні відповідності між сутностями і характеристиками предметної області і відносинами і атрибутами в нотації обраної СУБД. Оскільки кожна сутність реального світу володіє якимись характеристиками, в сукупності утворюють повну картину її прояви, можна поставити їм у відповідність набір відносин (таблиць) і їх атрибутів (полів).

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

IV. На четвертому кроці визначаються атрибути, які унікальним чином ідентифікують кожен об'єкт. Це необхідно для того, щоб система могла отримати будь-яку одиничну рядок таблиці. Ви повинні визначити первинний ключ для кожного з відносин. Якщо немає можливості ідентифікувати кортеж за допомогою одного атрибута, то первинний ключ потрібно зробити складовим - з кількох атрибутів. Хорошим прикладом може бути первинний ключ в таблиці працівників, що складається з прізвища, імені та по батькові. Первинний ключ гарантує, що в таблиці не буде міститися двох однакових рядків. У багатьох СУБД є можливість крім первинного визначати ще ряд унікальних ключів. Відмінність унікального ключа від первинного полягає в тому, що унікальний ключ не є головним ідентифікує фактором записи і на нього не може посилатися зовнішній ключ іншої таблиці. Його головне завдання - гарантувати унікальність значення поля.

V. П'ятий крок передбачає вироблення правил, які будуть встановлювати і підтримувати цілісність даних. Будучи певними, такі правила в клієнт-серверних СУБД підтримуються автоматично - сервером баз даних; в локальних же СУБД їх підтримку доводиться покладати на користувальницький додаток.

Ці правила включають:

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

VI. На шостому етапі встановлюються зв'язки між об'єктами (таблицями і стовпцями) і виробляється дуже важлива операція для виключення надмірності даних - нормалізація таблиць.

Кожен з різних типів зв'язків повинен бути змодельований в базі даних. Існує кілька типів зв'язків:

• зв'язок "один-до-одного"
• зв'язок "один-ко-многим"
• зв'язок "багато-до-багатьох".

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

Зв'язок "один-ко-многим" в більшості випадків відображає реальну взаємозв'язок сутностей в предметної області. Вона реалізується вже описаною парою "зовнішній ключ-первинний ключ", тобто коли визначено зовнішній ключ, що посилається на первинний ключ іншої таблиці. Саме цей зв'язок описує широко поширений механізм класифікаторів. Є довідкова таблиця, яка містить назви, імена і т.п. і деякі коди, причому, первинним ключем є код. У таблиці, яка щороку збирає інформацію - назвемо її інформаційної таблицею - визначається зовнішній ключ, що посилається на первинний ключ класифікатора. Після цього в неї заноситься не назва з класифікатора, а код. Така система стає стійкою від зміни назви в класифікаторах. Є способи швидкої "підміни" у видимій таблиці кодів на їх назви як на рівні сервера БД (для клієнт-серверних СУБД), так і на рівні користувальницького додатка. Але про це - в подальших уроках.

Зв'язок "багато-до-багатьох" в явному вигляді в реляційних базах даних не підтримується. Однак є ряд способів непрямої реалізації такого зв'язку, які з успіхом відшкодовують її відсутність. Один з найбільш поширених способів полягає у введенні додаткової таблиці, рядки якої складаються із зовнішніх ключів, що посилаються на первинні ключі двох таблиць. Наприклад, є дві таблиці: КЛІЄНТ і ГРУППА_ІНТЕРЕСОВ. Одна людина може бути включений в різні групи, в той час як група може об'єднувати різних людей. Для реалізації такого зв'язку "багато-до-багатьох" вводиться додаткова таблиця, назвемо її КЛІЕНТИ_В_ГРУППЕ, рядок якої матиме два зовнішніх ключа: один буде посилатися на первинний ключ в таблиці КЛІЄНТ, а інший - на первинний ключ в таблиці ГРУППА_ІНТЕРЕСОВ. Таким чином в таблицю КЛІЕНТИ_В_ГРУППЕ можна записувати будь-яку кількість людей і будь-яку кількість груп.

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

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

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

Процес нормалізації полягає в приведенні таблиць в так звані нормальні форми. Існує кілька видів нормальних форм: перша нормальна форма (1НФ), друга нормальна форма (2НФ), третя нормальна форма (3НФ), нормальна форма Бойса-Кодда (НФБК), четверта нормальна форма (4НФ), п'ята нормальна форма (5НФ). З практичної точки зору, досить трьох перших форм - слід враховувати час, необхідний системі для "з'єднання" таблиць при відображенні їх на екрані. Тому ми обмежимося вивченням процесу приведення відносин до перших трьох форм.

Цей процес включає:

• усунення повторюваних груп (приведення до 1НФ)
• видалення частково залежних атрибутів (приведення до 2НФ)
• видалення транзитивно залежних атрибутів (приведення до 3НФ).

Розглянемо кожен з цих процесів детальніше.

Приведення до першої нормальної формі

Коли поле в даному записі містить більше одного значення для кожного входження первинного ключа, такі групи даних називаються повторюваними групами. 1НФ не допускає наявності таких багатозначних полів. Розглянемо приклад бази даних підприємства, що містить таблицю ВІДДІЛ з наступними значеннями (атрибут, виділений курсивом, є первинним ключем):

Табл. A: ВІДДІЛ

Для приведення цієї таблиці до 1НФ ми повинні усунути атрибут (поле) Розташування з таблиці ВІДДІЛ і створити нову таблицю РАСПОЛОЖЕНІЕ_ОТДЕЛОВ, в якій визначити первинний ключ, який є комбінацією номера відділу і його розташування (Номер_отдела + Розташування - див. Табл. B). Тепер для кожного розташування відділу існують різні рядки; тим самим ми усунули повторювані групи.

Табл. B: РАСПОЛОЖЕНІЕ_ОТДЕЛОВ

Приведення до другої нормальної форми

Наступний важливий крок в процесі нормалізації полягає у видаленні всіх неключових атрибутів, які залежать тільки від частини первинного ключа. Такі атрибути називаються частково залежними. Неключових атрибути містять в собі інформацію про даної суті предметної області, але не ідентифікують її унікальним чином. Наприклад, припустимо, що ми хочемо розподілити працівників за типовими проектами, що ведуться на підприємстві. Для цього створимо таблицю ПРОЕКТ з складовим первинним ключем, що включає номер працівника і ідентифікатор проекту (Номер_работніка + ІД_проекта, в табл. C виділені курсивом).

Табл. C:: ПРОЕКТ

У цій таблиці виникає наступна проблема. Атрибути Назв_проекта, Опісаніе_проекта і Продукт відносяться до проекту як сутності і, отже, залежать від атрибута ІД_проекта (що є частиною первинного ключа), але не від атрибуту Номер_работніка. Отже, вони є частково залежними від складеного первинного ключа. Те ж саме можна сказати і про атрибут Прізвище, який залежить від атрибута Номер_работніка, але не залежить від атрибута ІД_проекта.

Для нормалізації цієї таблиці (приведення її в 2НФ) видалимо з неї атрибути Номер_работніка і Прізвище і створимо іншу таблицю (назвемо її РАБОТНІК_В_ПРОЕКТЕ), яка буде містити тільки ці два атрибути, і вони ж будуть складати її первинний ключ.

Приведення до третьої нормальної формі

Третій етап процесу приведення таблиць до нормальної форми полягає у видаленні всіх неключових атрибутів, які залежать від інших неключових атрибутів. Кожен неключових атрибут повинен бути логічно пов'язаний з атрибутом (атрибутами), що є первинним ключем. Припустимо, наприклад, що ми додали поля Номер_руководітеля і Телефон в таблицю ПРОЕКТ, що знаходиться в 2НФ (первинним ключем є поле ІД_проекта). Атрибут Телефон логічно пов'язаний з атрибутом Номер_руководітеля, неключових полем, але не з атрибутом ІД_проекта, що є первинним ключем (табл. D).

Табл. D: ПРОЕКТ

Для нормалізації цієї таблиці (приведення її в 3НФ) видалимо атрибут Телефон, змінимо Номер_руководітеля на Керівник і зробимо атрибут Керівник зовнішнім ключем, що посилаються на атрибут Номер_работніка (первинний ключ) в таблиці ПРАЦІВНИКИ. Після цього таблиці ПРОЕКТ і ПРАЦІВНИКИ будуть виглядати наступним чином:

Табл. E: ПРОЕКТ

Табл. F: ПРАЦІВНИКИ

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

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

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

Висновок

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

назад | Зміст | вперед