Лабораторна робота № 8 Розробка інфологічної моделі інформаційної системи ( іс ).
Мета роботи: Практично реалізувати опис предметної галузі і розробити інфологічну модель інформаційної системи.
Зміст роботи та звіту. 1. Розробити інфологічну модель предметної галузі. 2. Виділити об’єкти, атрибути , структурні та запитові зв’язки предметної галузі . 3. Проаналізувавши предметну галузь, надати визначені коди для них . 4. Подати таблиці кодів до звіту.
Варіанти предметних галузей для розробки ІС : 1. Газове господарство міста. 2. Розклад руху поїздів дальнього слідування 3. Автозаправочна станція. 4. Розклад руху поїздів приміського сполучення 5. База промислових товарів. 6. Розклад руху автобусів дальнього слідування 7. База продовольчіх товарів. 8. Розклад польотів літаків аеропорту. 9. Відділок постачання металургійного комбінату. 10. Поперередній продаж квитків на поїзди дальнього слідування 11. Відділок постачання хімічного комбінату. 12. Поперередній продаж квитків на автобуси. 13. Відділок постачання університету. 14. Студентська поліклініка. 15. Податкова служба району. 16. Фермерське господарство. 17. Поперередній продаж квитків на літаки аеропорту. 18. Електричне господарство міста. 19. Дільничний інспектор. 20. Поштовий відділок. Короткі теоретичні відомості. ІНСТРУМЕНТАЛЬНІ ЗАСОБИ ІНФОЛОГІЧНОГО МОДЕЛЮВАННЯ
8.1 МОДЕЛЬ «ОБ'ЄКТИ-ЗВ'ЯЗКИ»
У сучасній інформаційній системі підтримується кілька рівнів представлень (абстракцій). Їхній різновид прийнято асоціювати з поняттям архітектури інформаційної системи (мал. 8.1).
Початковий рівень абстракції відповідає представленням про предметну область кінцевих користувачів— назвемо їх локальними користувальницькими представленнями (ЛКП).
Другий рівень називається інфологічним, він являє собою інтеграцію ЛКП, що відповідає «погляду» на предметну область її адміністратора (директора, міністра, ректора вузу і т.д.). Він бачить усю безліч інформаційних об'єктів, усі можливі асоціації між ними, у той час як кожен кінцевий користувач переглядає лише обмежений фрагмент предметної області. Відзначимо, що локальні користувальницькі представлення і інфологічне представлення про предметну область існують поза яким-небудь зв'язком із засобами реалізації інформаційної системи. Вони визначають лише інформаційні потреби розроблювальної системи, відбивають особливості предметної області, але не торкаються питання: як відповідні дані будуть представлені в пам'яті ЕОМ?
Мал. 8.1 Рівні абстракції в інформаційній системі
Концептуальний рівень абстракції відповідає уявленню про логічну організацію даних адміністратора БД. Цей рівень абстракції дуже схожий з інфологічним, але його відмінність складається в прив'язці до засобів реалізації — СУБД. Опис БД на концептуальному рівні задається мовою опису даних використовуваної СУБД, у термінах і обмеженнях, прийнятих у цій системі. Оскільки кожна СУБД на концептуальному рівні підтримує свою модель даних, перетворення інфологічного опису ПО в концептуальний опис для БД різних систем приводить до різних результатів.
Представлення даних у пам'яті ЕОМ, їхню організацію збереження визначає внутрішній рівень абстракції. Відзначимо, що параметри внутрішнього рівня представлення БД впливають на ефективність ІС, наприклад, на обсяг зовнішньої пам'яті, час реакції системи. У процесі функціонування ІС адміністратор може змінювати внутрішній опис БД, залишаючи без змін описи, що задаються на інших рівнях абстракції. Це дозволить змінювати параметри ефективності системи, не вносячи ніяких коректувань у розроблені додатки.
Нарешті, підтримувані СУБД зовнішні представлення дані відповідають початковим ЛПП.
На кожнім рівні абстракції визначається своя модель ПО. Опису цих моделей прийнято називати схемами, тому говорять, що схеми ЛПП відображаються в инфологическую схему ПО, остання відображається в концептуальну схему БД і т.д. Відзначимо, що усі відображення, відзначені стрільцями на мал. 8.1., повинні бути гомоморфними. Вимога гомоморфізму означає, що в БД повинні міститися дані, що відповідають всім об'єктам ПО, з одного боку, а з іншого боку - будь-якій процедурі обробки об'єктів ПО в інформаційній системі повинна відповідати деяка процедура обробки відповідних даних, що дозволяє одержати адекватний результат.
Архітектура сучасної СУБД (наприклад, побудованої на основі пропозицій КОДАСИЛ) припускає незалежне завдання концептуального і внутрішнього опису БД. Для завдання першого служить мова опису данних схеми (МОДС), а внутрішній опис БД складається мовою опису збереження даних (МОЗД). Однак частіше параметри логічної і фізичної організації даних задаються єдиним описом, що прийнято називати схемою БД.
Як синонім зовнішньої схеми використовується термін підсхема. Відзначимо, що підсхема аж ніяк не завжди представляється частиною схеми БД. У ряді СУБД на зовнішньому рівні можна визначати віртуальні дані (обчислюва алгоритмічно непомітно для користувача); зовнішні записи й асоціації можуть бути похідними від тих, що визначено на концептуальному рівні. Наприклад, зовнішні записи можуть мати структури, ідентичні приведеної на мал. 8.1. У цьому випадку кожен зовнішній запис формується алгоритмічно з декількох записів БД, але процедури формування зовнішніх записів сховані від користувачів.
8.2. МОДЕЛІ ДАНИХ
Система баз даних підтримує в пам'яті ЕОМ модель предметної області. Однак результат моделювання залежить не тільки від предметної області, але і від використовуваної СУБД, оскільки кожна система надає свій інструментарій для відображення предметної області
Цей інструментарій прийнятий називати моделлю даних. У той же час результат відобра-ження предметної області в термінах моделі даних називається моделлю баз даних.
Модель даних визначається трьома компонентами:
■ припустимою організацією даних;
■ обмеженнями цілісності (семантичної);
■ безліччю операцій, припустимих над об'єктами моделі даних.
Припустима організація даних визначається розмаїтістю і кількістю типів об'єктів моделі даних, обмеженнями на структуру даних. Наприклад, у СУБД БАНК можна визначити до 255 типів записів і 500 типів зв'язків, а БД має довільну мережну ациклическую структуру. У той же час модель даних системи ОКА допускає наявність у БД до 256 типів записів, між якими встановлюються так називані фізичні зв'язки для того, щоб БД мала деревоподібну структуру не більш 15 рівней. Крім того, між записами однієї чи різних БД допускається встановлювати додаткові асоціації, називані логічними зв'язками.
Обмеження цілісності підтримуються засобами, передбаченими в моделі даних для вира-ження обмежень на значення даних і асоціації, що (обмеження) характеризують достовірні стани БД.
Ряд обмежень цілісності підтримується моделлю даних за замовчуванням і поширюється на всі типові ситуації, виникнення яких можливо при внесенні змін у БД. Для приклада звернемося до моделі дані системи СЕТОР. Якщо між записами типу ПОЛІКЛІНІКА і ЖИТЕЛЬ встановле-ний ієрархічний зв'язок, то СУБД перешкодить видаленню зведень про поліклініку, якщо з цією поліклінікою зв'язана хоча б одна запис про пацієнта.
Інші обмеження цілісності можуть задаватися явно і також поширюватися на безліч однотипних ситуацій. Розглянемо приклад. Припустимо, що при визначенні запису для якого-небудь полю задано властивість унікальності значень, тоді СУБД перешкодить появі в БД двох записів з однаковим значенням цього полю.
Обмеження цілісності можуть поширюватися і на значення окремих полів. Наприклад, у системі ДИСОД при описі запису можна задати область припустимих значень. Система не допустить відновлення даного, якщо нове значення буде кваліфіковано як некоректне.
Модель дані системи МЕРЕЖА містить механізм процедур, що дозволяє розроблювачам інформаційної системи розширити можливості СУБД. Адміністратор БД визначає процедури перевірки коректності станів даних і вказує умови, при яких ці процедури повинні автоматично виконуватися.
Безліч операцій визначає види обробок, яким можуть піддаватися об'єкти моделі даних. Сюди в першу чергу входять операції вибірки даних і операції, що змінюють стан БД.
Підтримувані СУБД моделі даних, описані в науковій літературі, традиційно розбивають на мережні, ієрархічні і реляційні. Ця класифікація дуже умовна, тому що кожна СУБД під тримує оригінальну модель даних.
В методиці проектування використовується модель, названа «об'єкти-зв'язки». Вона визначається в термінах: атрибут, об'єкт, структурний зв'язок і запитовий зв'язок.
Атрибут -це логічно неподільний елемент структури інформації, характеризуемий безліччю атомарних значень. Кожен атрибут ідентифікується ім'ям.
Об'єкт инфологічної схеми відповідає деякої сутності реального світу, що представляє інтерес для предметної області. Об'єкту відповідає набір атрибутів, що описують властивості цього об'єкта. Так, якщо СПІВРОБІТНИК — об'єкт, то його атрибути — П І П, ПОСАДА, ОКЛАД, СТАЖ-РОБОТИ, ТЕЛЕФОН і ін. — дозволяють деталізувати представлення про цей об'єкт, задати його властивості. Структурний зв'язок - ієрархічне відношення між об'єктами двох типів: власником і підлеглим. Екземпляр структурного зв'язку представляється одним екземпляром власника і безліччю зв'язаних з ним екземплярів підлеглого об'єкта. Для зображення інформаційних структур використовуються діаграми Бахмана. Об'єкти позначаються вершинами графа, а структурні зв'язки — дугами. Очевидно, що значення цієї й іншої ознак структурних зв'язків багато в чому визначаються вимогами процесів обробки об'єктів.
Кожному процесу ставиться у відповідність сукупність так званих запитових зв'язків. Запитовий зв'язок •— це деяка операція, що передбачає в алгоритмі процесу перехід від екземплярів одних об'єктів, називаних вихідними, до безлічі екземплярів об'єкта, називаного кінцевим у запитовому зв'язку.
АТРИБУТИ.Кожен атрибут описується набором ознак.
Код Назва ознаки
А1 Шаблон значень атрибута
А2 Відсоток наявності значень атрибута в екземплярах об'єкта
A3 Обмеження на право звертання до значень атрибута
А4 Частота використання атрибута
А5 Область припустимих значень
А6 Ознака виводимості значень
А7 Ознака дублювання значень
Значення ознак атрибутів об'єкта задаються у виді таблиці (мал. 8.2).
Мал 8.2. Приклад заповнення бланка опису атрибутів об'єкта
ОБ'ЄКТИ.Подібно атрибуту, кожен об'єкт инфологічної схеми предметної області описується переліком ознак. Код Найменування ознаки В1 Спосіб звертання до екземплярів об'єкта В2 Структурна активність об'єкта В3 Обмеження на право звертання до екземплярів об'єкта В4 Частота використання В5 Кількість екземплярів об'єкта В6 Мінливість складу екземплярів об'єкта Значення ознак усіх виділених об'єктів задаються в табличному виді (мал. 8.3.).
СТРУКТУРНІ ЗВ'ЯЗКИ.Кожного структурного зв'язку привласнюється унікальне ім'я, і він описується своїми ознаками, що приведені нижче:
Код Найменування ознаки
С1 Напрямок руху по структурному зв'язку
С2 Спосіб упорядкування екземплярів підлеглого об'єкта
СЗ Обмеження на право руху по структурному зв'язку
С4 Частота використання
С5 Кількість екземплярів підлеглого об'єкта в структурному зв'язку
С6 Клас членства підлеглого об'єкта
С7 Перемещуємість екземплярів підлеглого об'єкта по структурному зв'язку
С8 Обмеження на час руху по структурному зв'язку
Мал 8.3. Ознаки об' эктів.
ЗАПИТОВІ ЗВ'ЯЗКИ. Знайомство з ознаками запитових зв'язків проведемо на коментарях до бланка їхнього опису, представленому на мал. 8.4. Номер запитового зв'язку. Власне кажучи цей номер є ідентифікатором.
Вихідні і кінцеві об'єкти. Для багатомірних запитових зв'язків приводяться імена декількох вихідних об'єктів, як показано на прикладі для запитового зв'язку 2.1.
Тип відповідності. Припустимі типи відповідності між об'єктами.
Тип відповідності «один до одному» між об'єктами X і Y позначається Т(X, Y) = 1:1 і означає, що в будь-який момент одному екземпляру об'єкта X може відповідати не більш ніж один екземпляр об'єкта Y, і навпаки.
Тип відповідності «один до многим» позначається T(X,Y) = 1:M і означає, що одному екземпляру об'єкта X може відповідати нуль, один чи багато екземплярів об'єкта Y. У той же час будь-якому екземпляру об'єкта Y може відповідати не більш ніж один екземпляр об'єкта X.
Тип відповідності «багато хто до одному» позначається T(X,Y)=M:1.При цьому кожному екземпляру об'єкта X може відповідати максимум один екземпляр об'єкта Y, але будь-якому екземпляру об'єкта Y може відповідати нуль, один чи кілька екземплярів об'єкта X.
Тип відповідності «багато хто до многим» позначається T(X,Y)=M:M і означає, що будь-якому екземпляру X може відповідати нуль, один чи кілька екземплярів об'єкта Y і в той же час кожному екземпляру об'єкта Y може відповідати нуль, один чи багато екземплярів об'єкта X.
5. Для повноти необхідно розглянути і ситуацію, коли між двома об'єктами немає відповідності. На цей випадок скористаємося позначенням Т(Х, Y)=Q.
Параметри вибірки. Якщо вихідний об'єкт описуваного структурного зв'язку не був кінцевим у якім-небудь попереднім зв'язку з тієї ж сукупності, то указують, як варто вибирати його екземп-ляри (що повинно бути виконане перед виконанням запитового зв'язку).
Стосовно до запитового зв'язку 1.1 (див. мал. 1.4) параметра-вибірки вказують, що запитовий зв'язок повинний послідовно виконуватися для всіх екземплярів об'єкта ОРГАНІЗАЦІЯ, а для кожної організації вибирається або вся безліч співробітників, або тільки співробітники з зазначеними посадами.
Частота, обмеження на час і право виконання. Якщо частота задається, вона вказує число виконань запитового зв'язку за деякий часовий інтервал.
Мал. 8.4. Запитові зв'язки
Запити до захисту. 1. Рівні представлень (абстракцій) інформаційної системи ? 2. Якою мовою задається опис БД на концептуальному рівні ? 3. До якого рівня абстракції відноситься концептуальний рівень ? 4. Які дані повинні міститися в БД по вимогам гомоморфізму ? 5. Як традиційно розбивають підтримувані СУБД моделі даних ? 6. Яка модель використовується в методиці проектування ІС ? 7. В яких термінах визначається модель, названа «об'єкти-зв'язки » ? 8. Чим ідентифікується кожен атрибут ? 9. Що таке об'єкт ? 10.Що називають структурний зв'язок ? 11.Чим реалізується в програмі запитовий зв'зок ?