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

Інформатика, програмування

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

Зміст

Огляд

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

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

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

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

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

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

Висновок

4. Огляд

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

У вступному уроці (номер 1) ми дали короткий, "на пальцях", тлумачення локальних і серверних баз даних і пояснили суть технології клієнт-сервер. На даному уроці ми розглянемо процес проектування баз даних, загальний для обох технологій. І лише деталі його реалізації будуть відрізнятися в різних архітектури. Відразу скажемо, що ми будемо розглядати тільки реляційні бази даних: по-перше, реляційні бази одержали найбільше поширення в світі, по-друге, вони найбільш "просунуті" в науковому плані, а по-третє, ядро баз даних Borland Database Engine , на основі якого працюють всі останні продукти компанії Borland, призначена саме для роботи з реляційними базами даних.

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

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

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

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

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

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

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

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

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

2. Визначити інформаційні потреби бази даних.

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

6. Поставити у відповідність сутностям і характеристиками - таблиці і стовпчики (поля) в нотації вибраної Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle і т.д.).

8. Визначити атрибути, які унікальним чином ідентифікують кожен об'єкт.

10. Виробити правила, які будуть встановлювати і підтримувати цілісність даних.

11.

12. Встановити зв'язки між об'єктами (таблицями і стовпчиками), провести нормалізацію таблиць.

13.

14. Спланувати питання надійності даних і, при необхідності, збереження секретності інформації.

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

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

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

ставлення, таблиця, файл (для локальних баз даних)

кортеж, рядок, запис

атрибут, стовпець, поле.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

чи зможе нова система об'єднати існуючі програми або їх необхідно буде кардинально переробляти для спільної роботи з новою системою;

які дані використовуються різними додатками; чи зможуть Ваші програми спільно використовувати будь-які з цих даних;

хто буде вводити дані в базу і в якій формі; як часто будуть змінюватися дані;

чи достатньо буде для Вашої предметної області однієї бази або Вам буде потрібно кілька баз даних з різними структурами;

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

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

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

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

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

ідентифікацію характеристик цієї суті. Наприклад, сутність ПРАЦІВНИК може включати такі характеристики як Ідентифікатор Працівника, Прізвище, Ім'я, По батькові, Професія, Зарплата.

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

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

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

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

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

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

визначення типу даних

вибір набору символів, що відповідає даній країні

створення полів, що спираються на домени

установка значень за замовчуванням

визначення обмежень цілісності

визначення перевірочних умов.

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

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

зв'язок "один-до-одного"

зв'язок "один-ко-многим"

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

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

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

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

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

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

дані легко оновлювати або видаляти

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

зменшується можливість введення некоректних даних.

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

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

усунення повторюваних груп (приведення до 1НФ)

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

видалення транзитивній залежних атрибутів (приведення до 3НФ).

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

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

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

Табл. A: ВІДДІЛ Номер_отдела Назва Керівник Бюджет Розташування 100 продажів 000 1000000 Москва 100 продажів 000 1000000 Зеленоград 600 розробок 120 1100000 Тверь 100 продажів 000 1000000 Калуга

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

Табл. B: РАСПОЛОЖЕНІЕ_ОТДЕЛОВ Номер_отдела Розташування 100 Москва 100 Зеленоград 600 Тверь 100 Калуга

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

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

Табл. C: ПРОЕКТ       Номер_
працівника          ІД_проекта          Прізвище          Назв_проекта          Опісаніе_
проекту          Продукт         28         БРЖ         Іванов         Біржа                  програма         17         ДОК         Петров         Документи                  програма         06         УПР         Сидоров         Управління                  адм.мери

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

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

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

Табл. D: ПРОЕКТ       ІД_проекта          Номер_
керівника          Телефон          Назв_
проекту          Опісаніе_
проекту          Продукт         БРЖ         02         2-21         Біржа                  програма         ДОК         12         2-43         Документи                  програма         УПР         08         2-56         Управління                  адм.мери

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

Табл. E: ПРОЕКТ       ІД_проекта          Керівник          Назв_
проекту          Опісаніе_
проекту          Продукт         БРЖ         02         Біржа                  програма         ДОК         12         Документи                  програма         УПР         08         Управління                  адм.мери

Табл. F: ПРАЦІВНИКИ       Номер_
працівника          Прізвище          Назва          По батькові          Номер_
відділу          Код_
профес          Телефон          Зарплата         04         Іванов         Іван         Іванович         100         інж         2-69         500         08         Петров         Петро         Петрович         200         мндж         2-56         1000         23         Сидоров         Іван         Петрович         200         мндж         2-45         800

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

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

хто буде мати права (і які) на використання бази даних

хто буде мати права на модифікацію, вставку і видалення даних

чи потрібно робити відмінність у правах доступу

яким чином забезпечити загальний режим захисту інформації тощо

1. Висновок

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