Повна версія

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

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


<<   ЗМІСТ   >>

Моделювання процесів обробки даних

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

Реалізація представлення здійснюється, як правило, на основі заздалегідь зафіксованих в коді запиту параметрів або без параметричних елементів. Ця особливість накладає дуже серйозні обмеження на їх (подання) використання, оскільки не дозволяє використовувати дані, введені користувачем, і отримувати в результаті відомості з бази даних на їх основі. Збережені процедури є другим по частоті використання інструментом обробки даних і використовуються, коли необхідно провести операції по модифікації даних в таблицях бази даних, а також вони застосовуються при організації вибірки даних на основі відомостей, введених користувачем в екранну форму. Фізично збережена процедура реалізується в СУБД у вигляді програмного коду на мові маніпулювання даними (DML) і (або) вбудованої в СУБД власної модифікації такого мови, а також може реалізовуватися на інших мовах програмування, як, наприклад, Java або С.

Для різних СУБД мову уявлення збережених процедур може бути різним, як, наприклад, SQL-Server використовує мову Transact- SQL, Oracle Database - PL / SQL, IBM DB2 - SQL, PostgreSQL - pgPL / SQL і т.д. Така особливість в СУБД накладає певні обмеження на правила обробки даних, але всі зазначені та аналогічні мови побудовані на основі єдиної мови - SQL. Ця мова описує основні конструкції з маніпулювання даними, загальний синтаксис яких є стандартом для сучасних СУБД.

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

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

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

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

image357

Мал. 5.50. Операції обробки даних

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

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

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

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

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

Застосування інструментарію IBM WebSphere Business Modeler для моделювання обробки даних дозволяє візуалізувати ал го- ритми роботи програм і запитів, позначаючи місце і послідовність використання таблиць бази даних. На основі таких моделей фахівець, який займається програмуванням елементів бази даних (представлення, збережені процедури, тригери), зможе правильно реалізувати відповідні операції, а проект інформаційної системи отримає якісну документацію з питань програмної реалізації бази даних.

Інтеграція інструменту з системою моделювання та реалізації бази даних IBM InfoSphere Data Architect дозволяє синхронізувати структури таблиць, які подаються в інструменті бізнес-елементами (рис. 5.51). Для моделювання запитів і збережених процедур необхідно скористатися механізмом моделювання бізнес-процесів.

image358

Мал. 5.51. інструмент моделювання


Також для моделювання необхідно визначати бізнес-елементи, які, маючи можливість описати атрибутивний складу, можуть представляти структури таблиць, а можливості інтеграції з IBM InfoSphere Data Architect дозволяють перенести ці структури в модель бази даних, а згодом в саму фізичну базу даних.

З палітри процесу для формування моделей запитів і збережених процедур будуть потрібні елементи, перераховані в табл. 5.5

Таблиця 5.5

Застосування компонентів моделювання

компонент

модель запитів

модель обробки

(З Завдання

Операції обробки даних

Вказівка ​​зв'язків, обмежень, угруповань, угруповань

Вказівка ​​операцій змін в таблиці бази даних, оголошення змінних і обчислень в змінних


компонент

модель запитів

модель обробки

процес

Операція обробки даних

підзапит

Запит, функція, збережена процедура

цикл While

циклічна обробка

-

Цикл з обмеженням, обробка курсора

цикл For

циклічна обробка

-

Цикл з відомою кількістю повторень

<£ Просте рішення

умовна конструкція

-

Умова обробки

Рішення з множинним вибором

умовна конструкція

Умови використання значення

Умова обробки, використання значення

сховище

Таблиця бази даних

Вказівка ​​на читання з таблиці бази даних

Вказівка ​​на збереження в таблиці бази даних, читання для підзапиту в операції модифікації даних

вибірка даних


приклад

11редположім, що потрібно вибрати відомості про товари на складі, що надійшли 1 листопада 2015 року (01.11.2015) і прийнятих на складі № 1. Результат повинен містити відомості про найменування товару, його артикул, ціною надходження, кількості надходження, поточну кількість. Вибрані записи необхідно відсортувати, але алфавітом найменувань товару.

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

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

Для початку моделювання необхідно визначитися зі структурою даних, які повинні бути отримані в результаті обробки. Для цього створюється бізнес-елемент "Вибірка процесу 1". Щоб не заплутатися у великій кількості бізнес-елементів, створюється каталог даних "Результати вибірок" (рис. 5.53). Для створення каталогу даних потрібно в дереві проектів викликати контекстне меню бізнес-елементів та вибрати


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

image359


Мал. 5.52. Створення каталогу даних

image360

Мал. 5.53. Діалогове вікно створення каталогу даних


Для створення бізнес-елемента, що описує структуру вихідних даних, аналогічним чином викликається контекстне меню каталогу даних "Результати вибірок", вибирається пункт меню "Створити / Бізнес елемент" і в діалоговому вікні визначається назва бізнес-елемента і опис його структури (рис. 5.54) . Як опису можна використовувати

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

image361

Мал. 5.54. Діалогове вікно створення бізнес-елемента


У підсумку за допомогою відповідного механізму описується атрибутивний складу виведення результату запиту, типи даних в якому належать до простих (рис. 5.55). * V

image362

Мал. 5.55. Опис атрибутів результату вибірки



Для того, щоб проводити моделювання запиту вибірки, необхідно представляти модель бази даних, з якою потрібно працювати. При моделюванні можна скористатися логічною моделлю, але для реалізації необхідно використовувати фізичну модель бази даних, де найменування таблиць і полів представлені ідентично фізичної реалізації бази даних. Тому найкращим варіантом опису запиту вибірки буде опис, засноване на фізичній моделі бази даних (IBM InfoSphere Data Architect, рис. 5.56).

image363

Puc. 5.56. Фізична модель бази даних


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

На наступному кроці разом з визначенням результуючих даних необхідно визначити набір вхідних даних. Оскільки даний приклад припускає одержання вихідних даних від користувача, то для цього необхідно визначити екранну форму, яка дозволить користувачеві ввести ці дані (IBM Form Designer, рис. 5.57).

image364

Мал. 5.57. Приклад форми для завдання параметрів вибірки


Також при моделюванні реалізації запиту вибірки необхідно визначити екранну форму для виведення результуючого електронного документа (IBM Form Designer, рис. 5.58).

image365

Мал. 5.58. Приклад форми виведення звіту



Опис фізичної моделі бази даних

п / п

Таблиця

опис

п / п

Атрибут

опис

Тип даних

1

t_product

Таблицями класифікатор списку товарів

1

id_product

ІДФ товару

Integer

2

name_product

Найменування товару

Varchar (50)

3

article

Артикул

Char (lO)

2

t_warchou.se

Таблиця-класифікатор списку складів

1

id_warchou.sc

ІДФ складу

Integer

2

name warehouse

Найменування складу

Varchar (50)

3

add ress_warehouse

Адреса складу

Varchar (255)

3

tsupplv

Таблиця-зв'язка отримання товарів на склад

1

id

Номер запису

Integer

2

id_warehouse

ІДФ складу

Integer

3

idproduct

ІДФ товару

Integer

4

date_supply

Дата надходження товару на склад

Date

5

pricesupply

Ціна надходження товару на склад

Decimal (5,2)

6

count_supply

Кількість надходження товару на склад

Integer

4

t_count Product

Сховище зведений і й про поточну кількість товарів на складах

1

id_warehouse

ІДФ складу

Integer

2

idproduct

ІДФ товару

Integer

3

countproduct

Поточне кількість товару на складі

Integer




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

Таблиця 5.7

Приклад відповідності атрибутів таблиці і моделі

№ п / п

Атрибут таблиці

Атрибут результату вибірки

1

1 (1_чагсЬоі.чс

ІДФ складу

2

паті _ 'аге1юі8е

Найменування складу



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

Починається процес з отримання вихідних даних, які визначені кількома бізнес-елементами. Допускається вказівку єдиного бізнес-елемента, склад якого визначає набір вхідних даних. У разі використання єдиного бізнес-елемента вихідних даних згодом, де це потрібно, необхідно буде робити явні коментарі про використання одного з атрибутів цього бізнес-елемента.

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

Наступним кроком є ​​визначення необхідних для вибірки таблиць. Ця процедура схожа на операції побудови алгоритму виконання програми і представляється послідовним міркуванням над процедурою формування результату з вихідних даних. Для простоти виконання цього завдання розробники, як правило, відштовхуються від результуючих даних, оскільки саме вони можуть на поточному етан однозначно підказати набір результуючих таблиць (рис. 5.60).

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

Модель виконання вибудовується на підставі зв'язків між таблицями в базі даних і можливих умов вибірки, які можуть бути виконані в процесі приєднання таблиць (рис. 5.61). Так, процедура починається з вибору товарів без умов обмеження, оскільки вихідні


image366

Мал. 5.60. Визначення результуючих таблиць



дані не містять відомостей, які можуть обмежити кількість обираних записів. Результатом вибірки з таблиці "Товари" виходить набір записів таблиці з усіма полями, наявними в таблиці. Це пояснює наявність в якості результату операції вибірки бізнес-елемента "Товар", який характеризує сховище "Товари". А оскільки інформація про товари повинна бути представлена ​​в результаті, то цей вихід з'єднується з завданням формування результату.

Оскільки таблиці "Надходження товарів" і "Кількість товарів" мають серед своїх атрибутів ідентифікатор товару, то зв'язування з цього атрибуту з таблицею "Товари" є обґрунтованим кроком, що і відбивається в моделі (рис. 5.62).

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

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

Тепер залишилося виконати просту операцію - зв'язати завдання з результатом виведення (рис. 5.64).

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

Додавши завдання сортування, необхідно вказати набір полів, за якими буде здійснюватися сортування даних. Якщо тип сортування (зростання, спадання) не вказано, то, як і в операціях вибірки мови 50, Ц мається на увазі сортування по зростанню.

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


image367

Мал. 5.61. Підключення вибірки товарів


image368

Мал. 5.62. Підключення інших таблиць


image369

Мал. 5.63. Накладення обмежень на таблиці


image370

Мал. 5.64. Приклад моделі вибірки


image371

Мал. 5.65. Додавання сортування



 
<<   ЗМІСТ   >>