Скороходов В.А., Худякова І.М. Автоматизоване робоче місце менеджера

Подождите немного. Документ загружается.

Частина 5

РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

321

Таблиця 5.3

Номер

свідоцтва

Код — Ч

Прізвище

дружини

Ім’я дружини

Дата

реєстрації

1ЮБ

154745

111 Курочкіна Августина 06/03/1991

1ЮБ

163489

111 Пеструшкіна Маріана 11/08/1991

1ЮБ

169887

112 Рябова

Мілана

12/12/1992

1ЮБ

169878

112 Уточкіна Вероніка 12/12/1992..

1ЮБ

154746

113 Свинюшкіна Ельвіра 06/03/1991..

1ЮБ

169879

113 Хавронія Руфіна 12/12/1992..

Зазначимо, що ER-діаграма рис. 5.9., а описує структуру розміщення

даних про шлюби у відділах ЗАГС країн, що допускають групові шлюби,

а ER-діаграми прикладу 5.9., описи будь-яких видів шлюбів у організаціях,

де є сутність «чоловіка» і «жінки», включаючи неодружених.

Що ж таке «зв’язок»? У ER-діаграмах це лінія, що з’єднує гео-

метричні фігури, що відображають сутність, атрибути, асоціації та

інші інформаційні об’єкти. У тексті ж цей термін використовується

для вказівки на взаємозалежність сутності. Якщо ця взаємозалеж-

ність має атрибути, то вона називається асоціацією.

На завершення розглянемо приклад побудови інфологічної мо-

делі бази даних «харчування», де повинна зберігатися інформація

про страви (рис. 5.5.), їх щоденне споживання, продукти, з яких го-

туються ці страви, і постачальників цих продуктів. Інформація буде

використовуватись кухарем і керівником невеликого підприємства

громадського харчування, а також його відвідувачами.

Скороходов В. А., Худякова І. М.

АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

322

1. Лобіо по@грузинськи

Ламану очищену квасолю, нашаткований лук посолити, посипати пе

рцем і припустити в маслі з невеликою кількістю бульйону; додати

кинзу, зелень петрушки, рейган (базилік) і довести до готовності.

Потім запекти в духовці. Квасоля стручкова (свіжа або консервова

на) 200, Цибуля зелена 40, Масло вершкове 30, Зелень 10. Вихід

210. Калорій 725.

Рис. 5.5.

Приклад кулінарного рецепту

За допомогою зазначених користувачів виділені такі об’єкти і

характеристики бази, що проектується:

1. Страви, для опису яких потрібні дані, що входять до складу ку-

лінарних рецептів: номер страви (наприклад, з книги кулінар-

них рецептів), назва та вид (закуска, суп, cмаженина т.ін.), ре-

цепт (технологія приготування блюда), вихід (вага порції), на-

зва, калорійність і вага кожного продукту, що є

інгредієнтом

страви.

2. Для кожного постачальника продуктів: найменування, адреса,

назва продукту, що постачається, дата поставки і ціна на мо-

мент поставки.

3. Щоденне споживання страв (витрати): страва, кількість порцій,

дата.

Аналіз об’єктів дозволяє виділити:

• Основи: Страви, Продукти і Міста;

• асоціації: Склад (пов’язує Страви з Продуктами) і

Поставки (пов’язує Постачальників з Продуктами);

• позначення Постачальники;

• характеристики Рецепти і Витрати.

ER-діаграма моделі наведена на рис. 5.10. а модель на мові

МІМ має наступний вигляд:

Частина 5

РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

323

Рис. 5.10.

Інфологічна модель бази

даних «Харчування»

Скороходов В. А., Худякова І. М.

АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

324

Страви (СТ, Страва, Вид)

Продукти (ПР, Продукт, Калорійність)

Постачальники (ПОС, Місто, Постачальник) [Місто]

Склад [Страви M, Продукти N] (Ст, ПР, Вага (г))

Поставки [Постачальники M, Продукти N] (ПОС, ПР, Дата П, Ціна, Вага (кг)

Міста (Місто, Країна)

Рецепти (Ст, Рецепт) {Страви}

Витрати (СТ, Дата Р, Порцій) {Страви}

У цих моделях Страва, Продукт і Постачальник — найменуван-

ня, а СТ., ПР і ПОС — цифрові коди блюд, продуктів і організацій,

що постачають ці продукти.

5.1.4. Реляційна структура даних

В кінці 60-х років з’явилися наукові праці, в яких обговорю-

валися можливості застосування різних табличних даталогічних

моделей даних, тобто можливості використання звичних і подання

способів подання даних. Найбільш значною була стаття співробітни-

ка фірми IBM д-ра Е. Кодда (Codd E. F., А Relational Model of Data

for Large Shared Data Banks. CACM 13: 6, June 1970), де, ймовірно,

вперше був застосований термін «реляційна модель даних».

Будучи математиком за освітою, Е. Кодд запропонував викори-

стовувати для обробки даних апарат теорії множин (об’єднання, пе-

ретин, різниця, декартовий твір). Він показав, що будь-яке подання

даних зводиться до сукупності двовимірних таблиць особливого ви-

ду, відомого в математиці як відношення — relation (англ.)

У реляційній моделі даних предметну область подають у вигля-

ді певної кількості однорідних таблиць. Таблицю можна в думках

уявляти собі як файл, а базу даних — як набір таблиць. Таблиця є

складовою одиницею інформації, яка фіксує деякі відносини її еле-

ментів (реквізитів, полів, атрибутів). У цьому значенні термін «таб-

лиця» замінюють терміном «відношення».

Частина 5

РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

325

Число стовпців в таблиці називається порядком відношення.

Значення всіх стовпців, пов’язані в одному рядку таблиці, назива-

ють кортежем, а значення всіх рядків, що знаходяться в одному

стовпці — доменом.

Фундаментальною характеристикою баз даних є можливість

опису властивостей відносин. Реляційне відношення має такі влас-

тивості:

1. Відносини нормалізовані, якщо кожна клітина кортежу є прос-

тим значенням, що не складається з груп. (Альтернатива: у таб-

лиці СЛУЖБОВЕЦЬ може існувати стовпець ДІТИ, що є групою

реквізитів (ім’я, рік народження, місяць, дата народження). Це

викликає необхідність заміни поля ДІТИ іншою таблицею, що

порушує вимоги реляційної моделі даних

і призводить до мере-

жевого або ієрархічного відношення.

2. Нормалізовані відносини подаються у вигляді таблиці, що має

ім’я (ім’я відношення), порядок (кількість стовпців), а також

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

ці відповідають кортежам.

3. Впорядкування кортежів необов’язкове, хоча це може відобра-

жатися на ефективності пошуку кортежів

4. Всі кортежі повинні відрізнятися хоча б в одному символі.

5. Кілька одиничних атрибутів (полів) однозначно ідентифікують

кортеж. Наприклад, у відношенні СЛУЖБОВЕЦЬ — це прізви-

ще, ім’я і по батькові; у відношенні ТОВАР — код товару і

найменування товару; у відношенні ПОСТАВКА — код поста-

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

за пер-

винний ключ.

6. Нормалізовані зв’язки реляційної БД можуть мати зв’язки між

собою через загальні домени. БД — це сукупність зв’язків, які

змінюються в часі.

Ключ — це основне поле БД, по якому в ній сортують записи

або ведеться пошук даних. Не слід зберігати одні і ті ж дані в кіль-

кох місцях БД, оскільки це неекономна витрата дискового простору

Скороходов В. А., Худякова І. М.

АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

326

і збільшення вірогідності помилки. Дані повинні міститися в БД в

одному зразку. Теоретичну ідею і практичну процедуру звільнення

від зайвих даних в БД називають нормалізацією. Пошук даних в

СУБД базується на складному теоретико-множинному формальному

апараті, який прихований за зовнішньою простотою пошукових діа-

логів з ЕОМ призначені для користувача.

Найменша одиниця даних реляційної моделі — це окреме ато-

марне для даної моделі значення даних. Так, в одній предмет-

ній області прізвище, ім’я і по батькові можуть розглядатися як

єдине значення, а в іншій — як три різні значення.

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

Так, домен пунктів відправлення (призначення) — безліч назв насе-

лених пунктів, а домен номерів рейса — безліч цілих позитивних чисел.

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

Так, домен пунктів відправлення (призначення) — безліч назв

населених пунктів, а домен номерів рейсу — безліч цілих позитив-

них чисел. Значення доменів полягає в наступному. Якщо значення

двох атрибутів беруться з одного і того ж домена, то, ймовірно, ма-

ють сенс порівняння, що використовують ці два атрибути (напри-

клад, для організації транзитного рейсу можна дати запит «Видати

рейси, в яких час вильоту з Києва до Сочі більше часу прибуття з

Архангельська до Одеси»). Якщо ж значення двох атрибутів беруть-

ся з різних доменів, то їх порівняння, ймовірно, позбавлене значен-

ня: чи варто порівнювати номер рейса з вартістю квитка?

Відношення на доменах D1, D2,..., Dn (не обов’язково, щоб всі

вони були різні) складається із «заголовка» і «тіла». На рис. 5.11. на-

ведений приклад відношення для розкладу руху літаків.

Заголовок складається з такої фіксованої безлічі атрибутів

A1, A2,..., An, що існує взаємно однозначна відповідність між цими

атрибутами Ai і визначальними їх доменами Di (i=1,2,..., n).

Частина 5

РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

327

Відношення з математичної точки зору (Ai — атрибути, Vi —

значення атрибутів)

«Тіло» складається зі змінної в часі безлічі кортежів, де кожен

кортеж складається в свою чергу з безлічі пар атрибут-значення (Ai:

Vi), (i=1,2,..., n), по одній такій парі для кожного атрибуту Ai в за-

головку. Для будь-якої заданої пари атрибут-значення (Ai: Vi) Vi є

значенням з єдиного домена Di, який пов’язаний з атрибутом Ai.

Ступінь відношення — це число його атрибутів. Відношення

ступеня один називають унарним, ступеня два — бінарним,

ступеня три — тринарним,..., а ступеня n — n-арным. Ступінь

відношення «Рейс» — 8.

Рис. 5.11.

Скороходов В. А., Худякова І. М.

АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

328

Кардинальне число або потужність відношення — це число

його кортежів.

Потужність відношення «Рейс» рівна 10. Кардинальне число

відношення змінюється в часі на відміну від його ступеня.

Оскільки відношення — це множина, а множини за визначенням

не містять елементів, що співпадають, то ніякі два кортежі відношен-

ня не можуть бути дублікатами один одного в будь-який довільно-

заданий момент часу. Нехай R — відношення з атрибутами A1,

A2,..., An. Говорять, що безліч атрибутів K=(Ai, Aj,..., Ak) відношення

R є можливим ключем R тоді і тільки тоді, коли задовольняються

два незалежних від часу умови:

1. Унікальність: у довільний заданий момент часу ніякі два різні

кортежі R не мають одного і того ж значення для Ai, Aj,..., Ak.

2. Мінімальність: жоден з атрибутів Ai, Aj,..., Ak не може бути ви-

ключений з Ко без порушення унікальності.

Кожне відношення має хоча б один можливий ключ, оскільки,

щонайменше, комбінація всіх його атрибутів задовольняє умові уні-

кальності. Один з можливих ключів (вибраний довільним чином)

приймається за його первинний ключ. Решта можливих ключів, як-

що вони є, називається альтернативними ключами.

Вищезгадані і деякі інші математичні поняття стали теоретич-

ною базою для створення реляційних СУБД, розробки відповідних

мовних засобів і програмних систем, що забезпечують їх високу

продуктивність, і створення основ теорії проектування баз даних.

Проте для звичайного користувача реляційних СУБД можна з успі-

хом використовувати неформальні еквіваленти цих понять:

Відношення — Таблиця (іноді Файл),

Кортеж — Рядок (іноді Запис),

Атрибут — Стовпець, Поле.

При цьому приймається, що «запис» означає «зразок запису», а

«поле» означає «ім’я і тип поля».

Частина 5

РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

329

5.1.5. Реляційна база даних

Реляційна база даних — це сукупність відношень, що містять

всю інформацію, яка повинна зберігатися в БД. Проте користу-

вачі можуть сприймати таку базу даних як сукупність таблиць.

1. Кожна таблиця складається з однотипних рядків і має унікальне

ім’я.

2. Рядки мають фіксоване число полів (стовпців) і значень (мно-

жинні поля і групи, що повторюються, недопустимі). Інакше

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

завжди є в точності одне значення або нічого.

3. Рядки таблиці обов’язково відрізняються один від одного хоча

б єдиним значенням, що дозволяє однозначно ідентифікувати

будь-який рядок такої таблиці.

4. Стовпцям таблиці однозначно привласнюються імена, і в кож-

ному з них розміщуються однорідні значення даних (дати, прі-

звища, цілі числа або грошові суми).

5. Повний інформаційний зміст бази даних подається у вигляді яв-

них значень даних і такий метод подання є єдиним. Зокрема, не

існує будь-яких спеціальних «зв’язків» або покажчиків, що

з’єднують одну таблицю з іншою.

6. При виконанні операцій з таблицею її рядки і стовпці можна

обробляти у будь-якому порядку безвідносно до їх інформацій-

ного змісту. Цьому сприяє наявність імен таблиць і їх стовпців,

а також можливість виділення будь-якого їх рядка або певного

набору рядків із зазначеними ознаками (наприклад, рейсів з

пунктом призначення «Париж» і часом прибуття до 12 годин).

Створені мови маніпулювання даними, що дозволяють реалізу-

вати всі операції реляційної алгебри і практично будь-які їх поєд-

нання. Серед них найбільш поширені SQL (Structured Query

Language — структурована мова запитів) і QBE (Quere-By-Example —

запити за зразком). Обидві належать до мов дуже високого рівня,

Скороходов В. А., Худякова І. М.

АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

330

за допомогою яких користувач зазначає, які дані необхідно одержа-

ти, не уточнюючи процедуру їх отримання.

За допомогою єдиного запиту на будь-якій з цих мов можна

з’єднати декілька таблиць в тимчасову таблицю і вилучити з неї не-

обхідні рядки і стовпці (селекція і проекція).

5.2. Цикл розробки АРМ

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

ми. Для вдосконалення управління за рахунок радикального поліп-

шення інформаційної системи використовують системний підхід.

Отже, і розробка додатків пов’язана з необхідністю їх систематично-

го поліпшення. При огляді і плануванні розробки додатків можуть

використовуватися різні схеми стадій і етапів створення додатків.

Наприклад, традиційна системотехнічна розробка завдань і компле-

ксів автоматизованих систем управління (АСУ) і окремих автомати-

зованих робочих місць зазвичай розглядається за трьохстадійною

схемою:

1) передпроектна стадія;

2) проектна;

3) введення в експлуатацію.

Через деякий час після закінчення упровадження виконується

ще етап аналізу ефективності. При цьому кожен етап розробки за-

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

значається єдиною методологією системних досліджень. На рис.

5.12. наведена схема типового циклу, логічно обумовленого цією

методологією.

Автоматизоване робоче місце є підсистемою інформаційної си-

стеми (ІС). Тому всі принципи розробки окремого АРМа відповіда-

ють принципам розробки будь-якої ІС.

Цикл розвитку системи охоплює етапи дослідження, аналізу,

проектування, введення в експлуатацію, супроводу (підтримки).