2.Організація бази даних

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

• ієрархічну;

• мережеву;

• реляційну;

• об'єктно-орієнтовану.

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

У мережевій моделі дані організовуються у вигляді довільного графа. Недолік мережевої моделі - жорсткість структури і висока складність її реалізації.

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

У об'єктно-орієнтованій моделі окремі записи бази даних представлені у вигляді об'єктів. Між записами бази даних і функціями їх обробки встановлюються взаємозв'язки за допомогою механізмів, подібних до відповідних засобів в об'єктно-орієнтованих мовах програмування. Об'єктно-орієнтовані моделі поєднують особливості мережевої і реляційної моделей і використовуються для створення великих БД із складними структурами даних.

Реляційна модель дістала свою назву від англійського терміну relation (відношення) і була запропонована в 70-х роках співробітником фірми IBM Едгаром Коддом. Реляційна БД є сукупністю таблиць, пов'язаних віднощеннями. Достоїнствами реляційної моделі даних є простота, гнучкість структури, зручність реалізації на комп'ютері, наявність теоретичного опису. Більшість сучасних БД для персональних комп'ютерів є реляційними. При наступному викладі матеріалу мова піде саме про реляційні БД.

Залежно від взаємного розташування додатка і БД можна виділити:

• локальні БД;

• виддалені БД.

Для виконання операцій з локальними БД розробляються і використовуються так звані локальні застосування, а для операцій з видаленими БД - клієнт серверні застосування.

C++Builder - програма здійснює доступ до БД через BDE (Borland Database Engine - процесор баз даних фірми Borland). BDE є сукупністю динамічних біб-ліотек і драйверів, що забезпечують доступ до даних. BDE повинен встановлюватися на усіх комп'ютерах, на яких виконуються C++Builder - додатки, які здійснюють роботу з БД. Додаток через BDE передає запит до бази даних, а назад отримує необхідні дані.

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

Для доступу до локальної БД процесор баз даних BDE використовує стандартні драйвери, які дозволяють працювати з форматами БД dBase, Paradox, FoxPro, а також з текстовими файлами.

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

При роботі з даними на кожному призначеному для користувача комп'ютері мережі використовується локальна копія БД. Ця копія періодично оновлюється даними, що містяться в БД на сервері.

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

Проте архітектура "файл-сервер" має і істотні недоліки.

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

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

• Управління БД здійснюється з різних комп'ютерів, тому в значній мірі ускладнена організація контролю доступу, дотримання конфиденційності і підтримки цілісності БД.

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

Клієнт - це додаток користувача. Для отримання даних клієнт формує і посилає запит віддаленому серверу, на якому розміщена БД. Запит формулюється на мові SQL, яка є стандартним засобом доступу до сервера при використанні реляційних моделей даних. Після отримання запиту віддалений сервер направляє його SQL - серверу (серверу баз даних) - спеціальній програмі, що управляє, і що забезпечує виконання запиту і видачу його результатів клієнтові.

Таким чином, в архітектурі "клієнт-сервер" клієнт посилає запит на обробку даних і отримує тільки ті дані, які дійсно потрібні. Уся обробка запиту виконується на віддаленому сервері. Така архітектура має наступні достоїнства.

• Зниження навантаження на мережу, оскільки тепер в ній циркулює тільки потрібна інформація.

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

• Зменшення складності клієнтських застосувань за рахунок відсутності в них коду, пов'язаного з контролем БД і розмежуванням доступу до неї.

Для реалізації архітектури "клієнт-сервер" зазвичай використовуються багатокористувальницькі СУБД, наприклад, Oracle або Microsoft SQL Server. Подібні СУБД також називають промисловими, т. як. вони дозволяють створити інформаційну систему організації або підприємства з великим числом користувачів. Промислові СУБД є складними системами і вимагають потужної обчислювальної техніки і відповідного обслуговування.

Описана архітектура є дворівневою - додаток-клієнт і сервер БД. Клієнтське застосування також називають сильним, або "товстим", клієнтом. Подальший розвиток цієї архітектури привів до появи трирівневого варіанту "клієнт-сервер" - додаток-клієнт, сервер додатків і сервер БД.

Мал. 14.4. Трирівнева архітектура "клієнт-сервер" ("тонкий" клієнт)

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

Основні достоїнства трирівневої архітектури "клієнт-сервер" полягають в наступному:

• розвантаження сервера від виконання частини операцій, перенесених на сервер додатків;

• зменшення розміру клієнтських застосувань за рахунок розвантаження їх від зайвого коду;

• єдина поведінка усіх клієнтів;

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

Відмітимо, що локальні додатки БД називають однорівневими, а клієнт серверні додатки БД - багаторівневими.