Мал.3.2. Архітектура з використанням файлового сервера

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

3.3.Технологія "клієнт/сервер"

Мал.3.3. Загальна схема побудови систем з архітектурою "клієнт/сервер"

Технологія "клієнт/сервер" була розроблена з метою усунення недоліків, що мають місце в перших двох підходах.

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

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

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

На практиці прийнято розміщати сервер на одному вузлі локальної мережі, а клієнти — на інших вузлах. На мал. 3.3 показана архітектура типу "клієнт/сервер"

Цей тип архітектури має такі переваги:

-Забезпечується більш широкий доступ до існуючих баз даних.

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

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

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

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

-Ця архітектура досить природно відображається на архітектуру відкритих систем.

3.4.Розподілена архітектура.

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

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

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

3.5.Інтернет - архітектура.

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

Це ставить мінімальні вимоги до клієнтського обладнання. Такі програми називають «тонкими клієнтами», бо вони здатні працювати навіть на ПК з процесором 80386.

У цьому випадку не потрібно розробляти спеціальні клієнтські програми або придумувати власні специфікації обміну даними між сервером і клієнтськими місцями, достатньо скористатись готовими рішеннями.

Лекція 4. Моделі даних.

Об'єктні моделі даних. Моделі даних на основі записів. Ієрархічна та мережна моделі даних. Проблеми маніпулювання даними та обмеження цілістності даних. Реляційна модель та її характеристики. Фізичні моделі даних. Концептуальне моделювання.

4.1.Модель даних, мета побудови, класифікація, область застосування

Метою побудови моделі даних є представлення даних у зрозумілому виді. Якщо таке представлення можливо, то модель даних можна буде легко застосувати при проектуванні бази даних.

З лекціїї №1 відомо:

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

Для відображення архітектури ANSI-SPARC можна ідентифікувати наступні три зв'язані моделі даних:

-зовнішню модель даних, що відображає представлення кожного існуючого в організації типу користувачів, що іноді називають предметною областю (Universe of Discourse — Uo);

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

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

На сьогодні існує досить багато моделей даних. Вони поділяються на три категорії:

моделі даних на основі записів (record-based)

об'єктні (object-based) моделі даних,

фізичні моделі даних.

Перші дві використовуються для опису даних на концептуальному і зовнішньому рівнях, а остання — на внутрішньому рівні.

4.2. Об'єктні моделі даних

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