Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Аналіз потоків даних

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


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

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

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

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

Модель потоків даних може представлятися в двох варіантах: діаграма потоків даних (ДПД / ОРО), де вказуються завдання учасника процесу по перетворенню вихідних відомостей в результуючі, і діаграма робіт з даними, коли описуються операції обробки даних, які проводять в автоматизованій системі перетворення відомостей, включаючи їх збереження в базі даних або видалення існуючих відомостей.

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

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

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

image66

Мал. 2.21. Технологія взаємодії компонентів програмного додатка


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

  • • інтерфейс користувача:
    • - Уявлення екранних форм для введення вихідних даних,
    • - Уявлення результату обробки даних в зручному для користувача вигляді,
    • - Візуалізація інтерфейсу користувача;
  • • інтерфейс програми:

формування структури і наповнення екранних форм користувача,

  • - Передача відомостей від користувача в обробку на рівень СУБД,
  • - Передача користувачеві результату обробки в СУБД,
  • - Специфічна обробка даних з використанням механізмів, що не реалізовуються в СУБД;
  • • робота з базою даних:
  • - Модифікація даних в базі даних,
  • - Вибірка даних по інформаційним потребам користувачів,
  • - Алгоритмічна обробка даних в базі даних з використанням інструментів програмування.

Для такого чіткого поділу функцій між модулями програмного додатку повинно бути визначено угоду форматів повідомлень, що де-факто сформувалася на рівні стандартів комунікації, які визначають:

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

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

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

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

 
<<   ЗМІСТ   >>