Організація баз даних та знань (стр. 21 из 26)

· TDBImage - клас, що реалізує об'єкт "рисунок", у якому можна відображати й змінювати значення поля набору даних формату BLOB.

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

· TDBCheckBox - клас, що реалізує компонент "прапорець", що пов'язаний з полем БД.

· TDBListBox - клас, що реалізує компонент "список", який використовується для відображення значень поля набору даних. Значення, відображувані в списку, утримуються у властивості Items.

· TDBComboBox - клас, що реалізує компонент "список, що розкривається", який використовується для відображення значень поля набору даних. Значення, відображувані в списку, утримуються у властивості Items.

· TDBLookupListBox - клас, що дозволяє виконувати перегляд списку, заповненого значеннями полів з іншого набору даних. Набір даних, які переглядаються, вказується властивістю ListSource, що переглядає поле (або поля) - властивістю ListField. Властивість KeyField указує поле набору, що переглядається, відповідному полю поточного набору даних, що вказується властивостями DataField й DataSource. Даний клас дозволяє вибирати значення поля поточного набору даних з іншого набору даних, які переглядаються;

· TDBCtrlGrid - клас, що реалізує особливий вид таблиці, у якій кожен запис відображається на окремій панелі (кількість панелей у компоненті вказується значенням властивості RowCount).

3.3.6 Події, які ініціюються для наборів даних

AfterCancel і BeforeCancel - відбувається після/до скасування в додатку всіх змін, зроблених для поточного запису.

AfterClose і BeforeClose - відбувається після/до закриття набору даних і перекладу БД у стан dsInactive.

AfterDelete і BeforeDelete - ініціюється після/до видалення додатком поточного запису, перекладу набору даних у стан dsBrowse і переміщення позиції курсору на попередній запис.

AfterEdit і BeforeEdi - відбувається після/до початку редагування додатком поточного запису.

AfterInsert і BeforeInsert - відбувається після/перш ніж додаток вставить новий запис.

AfterOpen і BeforeOpen - відбувається після/перш ніж додаток відкриє набір даних, але до того, як які-небудь доступні дані будуть відображені.

AfterPost і BeforePost - відбувається до завершення переносу значень активного запису в БД або внутрішній кеш.

AfterRefresh і BeforeRefresh - відбувається після/до відновлення набору даних.

AfterScroll й BeforeScroll - відбувається після/до переміщення позиції курсору на інший запис.

OnCalcFields - відбувається при відкритті набору даних, перекладу його в стан dsEdit, переміщенні фокуса уведення від одного компонента до іншого або від одного стовпця до іншого, при змінах запису або при добуванні запису з БД, але тільки в тому випадку, якщо значення властивості AutoCalcFields дорівнює True;

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

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

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

OnFilterRecord - відбувається при зміні активного запису й тільки в тому випадку, якщо властивість State набору даних установлено таким, що дорівнює dsFilter, а властивість Filtered дорівнює True. Щоб запис був включений у набір даних, для нього варто встановити параметр Accept таким, що дорівнює True.

OnNewRecord - відбувається при вставці або додаванні нового запису.

3.4 Проектування модулів додатків

3.4.1 Аналіз функціональної моделі ПО БД

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

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

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

3.6 показана функція "2. Обробити заяву". Виконання цієї функції включає виконання чотирьох функцій такого рівня: "2.1. Зареєструвати заяву", "2.2. Ухвалити рішення щодо заяви", "2.3. Здійснити платіж за заявою", "2.4. Закрити заяву".

На рис. 3.6 показана подальша декомпозиція функції "2.2. Ухвалити рішення щодо заяви". Отримана на цьому етапі функція "2.2.5. Дозволити ремонт", є атомарною функцією.

Ремонт дозволяється або не дозволяється.

При розгляді ієрархії функцій розробникові БД варто звернути увагу на такі моменти:

· у функціональній моделі БД описуються бізнес-функції, і не всі вони будуть безпосередньо підтримуватися додатком БД;

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

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

3.4.2 Визначення функцій

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

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

Приклад. Визначення функції "2.2.2. Перевірити чи ухвалена заява".

"Одержати й зареєструвати всі необхідні страховою компанією відомості про заяву (ВІДОМОСТІ ПРО ЗАЯВУ), включаючи всі докладні відомості про треті сторони (СТОРОННІ ЮРИДИЧНІ ОСОБИ) і свідках (ФІЗИЧНІ ОСОБИ).

Вивчити страховий поліс (ПОЛІС) на предмет наявності виняткових ситуацій (ВИКЛЮЧЕННЯ) і визначити, чи діють ці ситуації у випадку даної заяви (ЗАЯВА).

Якщо є виключення, то закрити заяву й скласти стандартний лист заявникові про відмову у виплаті (ЛИСТ) заявникові (ЗАЯВНИК).

Якщо ніяких виключень ні, то змінити статус заяви на очікування оцінки, призначити й повідомити оцінювача (ОЦІНЮВАЧ)."

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

Із приклада зрозуміло, що на цьому етапі розробник БД у якості вхідних даних використає також інформаційну модель ПО БД (опис сутностей).

При виконанні аналізу функцій корисно мати деяку таблицю (матрицю) "ФункціяСутність". Ця матриця повинна дати відповідь на такі запитання:

· чи має кожна сутність конструктор (функцію, що створює всі екземпляри сутності);

· чи має вона деструктор (функцію, що видаляє екземпляри сутності); · чи є посилання на цю сутність (функції, які використовують цю сутність).

Процес аналізу взаємодії функції й сутності прийнято позначати абревіатурою CRUD (Create, Reference, Update, Delete - створення, посилання, модифікація, видалення).

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

3.4.3 Відображення функцій у модулі

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

Як правило, вирішення завдання відображення функцій у модулі виконується в чотири етапи:

1. Аналіз роботи функції.

2. Побудова моделі сутностей, що підтримує ці функції.

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

4. Завершення проектування розробленням специфікацій модулів, які реалізують функції на запропонованій схемі БД.

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

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

Розглянемо нашу БД, що містить інформацію про співробітників, відділи й проекти організації. Припустимо, вона буде підтримувати бізнес-функцію "Керування проектами в організації". Функціональна модель ПО БД у термінах ієрархії функцій наведена на рис. 3.7, а на рис. 3.8 наведений перелік функцій керування проектами в організації.

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

· призначити куратора проекту; сповістити керівників підрозділів;

· сповістити співробітників; зібрати нараду;

· приступити до виконання; скласти список робіт;