Модель системи. 
Розробка бази даних з архітектурою "клієнт-сервер". Розробка серверної та клієнтської частини

Автоматна модель розподіленої ІС описується традиційним впорядкованим набором.

де Q — вхідні запити ІС, R — відповіді нижчих систем, A — вихідний алфавіт ІС, St-множина станів системи, ?, ш — функції переходів та виходів.

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

де множина IdQ — множина унікальних ідентифікаторів запитів.

Множину символів, що складають вихідний алфавіт системи, опишемо у такий спосіб:

де IdA — множина унікальних ідентифікаторів відповідей.

Множину символів, що складають відповіді нижчих систем, опишемо наступним чином:

де IdR — множина унікальних ідентифікаторів відповідей нижчих систем.

Кожен запит до ІС та її відповідь містить дві частини: ідентифікаційну та параметричну. Ідентифікаційна — однозначно визначає тип запиту (наприклад: запит на отримання даних, оновлення, розміщення замовлення тощо). Параметри є фактично додатковою інформацією, що супроводжує запити та відповіді на них ІС (наприклад: текст Web-сторінки, вибірка з бази даних, прайс-лист системи Internet-маркетингупараметри відповіді, критерії на вибірку даних, нове замовлення — параметри запиту). Опис стану системи також базується на аналогічному підході: Загальну схему конкретного стану St інформаційної системи можна описати так:

Де St1… StNst — стани компонент інформаційної системи.

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

Кожен стан St (i) містить ідентифікатор стану IdSt та стани усіх підсистем, що належать до ІС. Кількість станів обмежується кількістю можливих станів підсистем.

Проте реально їх кількість істотно менше внаслідок обмежень та взаємозв'язків, що можуть існувати між станами системи. Серед таких обмежень виділимо два основні типи:

• * внутрішні стосовно одне одного (типу обмежень на унікальність або простих обмежень типу Check);
• * зовнішні (типу зовнішніх ключів).

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

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

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

Функція переходу:

Функція виходу:

Ми отримаємо імовірнісно-автоматну модель ІС. Розглянемо проблему формування імовірностей для опису реакції системи на запит. Можливі два підходи до її розв’язання:

• 1. визначення імовірності конкретної реакції системи на запит користувача зі врахуванням значення конкретного параметра;
• 2. визначення загальної імовірності конкретної реакції системи на запит користувача без врахування значення конкретного параметра;

Перший підхід забезпечує максимально можливу визначеність реакції інформаційної системи на запит користувача. Проте недоліком такого підходу є велика складність визначення імовірності переходу. Крім того, при використанні операції усунення параметра потрібно буде перераховувати імовірності переходів. Для проведення фізичної оптимізації також доцільно використовувати загальні значення імовірностей реакції системи. Тому доцільніше використовувати другий підхід. У такому разі імовірність реакції визначається для кожної пари (St, Q) без врахування значень параметрів запиту до системи та її бази даних. Визначеність поведінки системи буде меншою ніж у першому випадку, проте для усунення параметрів з розгляду та фізичної оптимізації системи непотрібно буде додаткових перетворень. Якщо в системі існуть запити з такими параметрами, що суттєво впливають на реакцію системи та є важливими для її оптимізації, тоді пару (параметр, запит) можна перетворити в окремий запит.