Ноу Інти, лекція, різні архітектурні рішення, які використовуються при реалізації

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

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

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

3.1. централізована архітектура

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

База даних у вигляді набору файлів знаходиться на жорсткому диску комп'ютера.
На тому ж комп'ютері встановлено СУБД і додаток для роботи з БД.
Користувач запускає додаток. Використовуючи надається додатком призначений для користувача інтерфейс, він ініціює звернення до БД на вибірку / оновлення інформації.
Всі звернення до БД йдуть через СУБД, яка інкапсулює в собі всі відомості про фізичну структуру БД.
СУБД ініціює звернення до даних, забезпечуючи виконання запитів користувача (здійснюючи необхідні операції над даними).
Результат СУБД повертає в додаток.
Додаток, використовуючи призначений для користувача інтерфейс, відображає результат виконання запитів.

Мал. 3.1. централізована архітектура

Подібна архітектура використовувалася в перших версіях СУБД DB2. Oracle. Ingres [[3.1]].

Розрахована на багато користувачів технологія роботи забезпечувалася або режимом мультипрограммирования (одночасно могли працювати процесор і зовнішні пристрої - наприклад, поки в прикладній програмі одного користувача йшло зчитування даних з зовнішньої пам'яті, програма іншого користувача оброблялася процесором), або режимом поділу часу (користувачам по черзі виділялися кванти часу на виконання їх програм). Така технологія була поширена в період "панування" великих ЕОМ (IBM-370, ЄС-1045, ЄС-1060). Основним недоліком цієї моделі є різке зниження продуктивності при збільшенні числа користувачів.

3.2. Технологія з мережею і файловим сервером (архітектура "файл-сервер")

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

Мал. 3.2. Архітектура "файл-сервер"

Робота побудована таким чином:

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

В рамках архітектури "файл-сервер" були виконані перші версії популярних так званих настільних СУБД. таких, як dBase і Microsoft Access.

В літературі [[3.2]] вказуються такі основні недоліки даної архітектури:

При одночасному зверненні безлічі користувачів до одних і тих же даних продуктивність роботи різко падає, тому що необхідно дочекатися поки користувач, що працює з даними, завершить свою роботу. В іншому випадку можливе затирання виправлень, зроблених одними користувачами, змінами інших користувачів.
Весь тягар обчислювального навантаження при доступі до БД лягає на додаток клієнта, так як при видачі запиту на вибірку інформації з таблиці вся таблиця БД копіюється на клієнтську машину і вибірка здійснюється на клієнті. Таким чином, не оптимально витрачаються ресурси клієнтського комп'ютера і мережі. В результаті зростає мережевий трафік і збільшуються вимоги до апаратних потужностей для користувача комп'ютера.
Як правило, використовується навігаційний підхід, орієнтований на роботу з окремими записами.
В БД на файл-сервері набагато простіше вносити зміни в окремі таблиці, минаючи програми, безпосередньо з інструментальних засобів (наприклад, з утиліти Database Desktop фірми Borland для файлів Paradox і dBase); подібна можливість полегшується тією обставиною, що фактично у таких СУБД база даних - поняття більш логічне, ніж фізичне, оскільки під БД розуміється набір окремих таблиць, що співіснують в окремому каталозі на диску. Все це дозволяє говорити про низький рівень безпеки - як з точки зору розкрадання та завдання шкоди, так і з точки зору внесення помилкових змін.
Недостатньо розвинений апарат транзакцій служить потенційним джерелом помилок в плані порушення смислової і посилальної цілісності інформації при одночасному внесенні змін в одну і ту ж запис.