Пильов В.О., Шеховцов А.Ф. Двигуни внутрішнього згоряння: Серія підручників. Том 4. Основи САПР ДВЗ

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

9 контролю цілісності БД;

9 оновлення даних на основі інформації резервної БД.

2. Гнучкість організації і відкритість структури дозволяють допов-

нювати і реорганізовувати дані без перебудови або повторного створення

усієї системи ІЗ.

3. Логічна структуризація даних за їх формальними ознаками забез-

печує мінімізацію інформації, що зберігається (усуває її надмірність), шви-

дкість пошуку даних.

4. Достовірність і доречність інформації, що знайдена за її форма-

льними

ознаками. Ця вимога гарантує точність отриманих даних та відпо-

відно достовірність прийнятих проектних рішень. Важливо, що невірний

результат тут може бути отримано в разі неповноти чи помилковості авто-

матично знайденої інформації в БД.

5. Доступ до даних повинен здійснюватись за достатньо простими

запитами користувачів у режимі діалогу або програм у пакетному

режимі

їх роботи. Тут підтримка роботи БД у максимальній мірі повинна бути ав-

томатизованою.

6. Захист від несанкціонованого доступу повинен забезпечувати до-

ступ до відповідної інформації тільки особам і програмам, які мають на то

право. Такий підхід відповідає меті досягнення певної методології проек-

тування.

7. Використання типових і уніфікованих програм і технічних

засобів

у значній мірі полегшує і прискорює процес створення і експлуатації ком-

понентів ІЗ.

Наданої сукупності вимог досягають шляхом використання спеціа-

льних методів організації, розміщення й обробки даних.

5.3. Організація обробки даних в АС. База даних, СКБД,

банк даних

Відповідно до виконання вимог, що подані в п.5.2, організація збе-

реження даних

та спосіб їх взаємодії з програмами пройшли в своєму роз-

витку два основних етапи. Це роз’різнений фонд даних та база даних.

Роз’різнений фонд даних використовували перші АС, що розробля-

лись на основі, так званого, позадачного методу автоматизації. Цей метод

відповідно до рис.5.4 передбачає використання для кожної програми

230

свого набору даних . Ці

набори іншими програмами

для розв’язання інших задач

не сприймаються.

При впровадженні по-

задачного методу викорис-

тання програм націлено на

максимальну ефективність

розв’язання кожної окремої

задачі. Але при створенні й

впровадженні складних АС

розробники і, особливо, ко-

ристувачі САПР зіткнулися з наступними труднощами, які природно від-

повідають сутності

позадачного методу:

Програма

Набір даних

исунок 5.4 – Схема позадачного методу

автоматизації в АС

втоматизована система

1. Виникла проблема контролю надмірності даних, оскільки останні

могли дублюватися. Наприклад, розрахунок робочого процесу двигуна,

динаміки, коливань КВ, розрахунки на міцність деталей КШМ та багато

інших задач потребують частково однакових даних. Складність

розв’язання сукупності перелічених задач при цьому полягає в тому, що

зміни початкових даних довільної задачі висувають

необхідність одночас-

ної корекції даних для інших задач.

2. Має місце взаємозв’язок між даними і програмами. Це означає,

що програми, поряд з алгоритмом розв’язання задачі, вміщують алгоритми

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

пису тощо). В результаті будь-яка зміна в організації даних призводила до

необхідності виконання змін в програмі. Крім того, практично ідентичні

алгоритми взаємодії з даними повинні були міститися в кожній з програм.

3. Не можливо вийти на якісно новий рівень інформаційних техно-

логій, оскільки не реалізється „принцип нових задач” як поєднання прин-

ципів системної єдності, сумісності і розвитку САПР. З використанням по-

задачного

методу здійснюється автоматизація тільки окремих несумісних

задач.

Ці та інші труднощі привели до розуміння того, що при переході від

автоматизації окремих задач до створення складних АС потрібна не тільки

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

231

ганізації даних – використання інтегрованої бази даних.

Створення інтегрованої бази даних (скорочено – бази даних) спира-

ється на виконання наступних двох вимог щодо організації даних в АС:

1. Реалізація інтеграції даних. Ця інтеграція передбачає, що всі дані,

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

ня. Утворена модель може динамічно оновлюватись.

2. Дотримання

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

них.

Виконання цих вимог привело до створення єдиної для всіх задач ба-

зи даних та розробки єдиної керуючої програми для роботи з даними –

си-

стеми керування базою даних

. При цьому з прикладних програм позадач-

ного методу до СКБД було перенесено засоби обробки даних. Тепер зміна

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

а зміна логіки прикладної програми не потребує реорганізації доступу до

даних.

База даних – найважливіший елемент інформаційного

забезпечення САПР.

Важливо, що не кожен блок даних можна вважати базою даних. БД –

це сукупність даних, яка має наступні властивості:

інтегрованість, що спрямована на розв’язання загальної задачі

проектування. Тут вирішення окремо взятої задачі буде менш ефективним,

ніж у позадачному методі, але ефективність використання інтегрованої БД

та СУБД зростає з підвищенням інтеграції САПР;

модельність, що відображає деяку частину реального світу. За дві

основні риси модельності прийнято достатність опису СТС та відсутність

надмірності даних;

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

рігання не тільки даних, а і описів структури СТС;

незалежність описів даних від прикладних програм, оскільки дані і

їх описи зберігаються разом у БД.

Розрізняють терміни „фактографічна БД” та „документальна БД”.

Фактографічна БД зберігає множину відомостей щодо певних

об’єктів, їх властивостей, зв’язків між об’єктами. Саме фотографічна БД

відтворює множину конструктивних параметрів двигуна, що проектуєть-

232

ся, – ; множину вибраних для проектування двигуна кри-

теріїв ефективності конструкції

(

xxxx ,...,,

)

(

)

xxxf ,...,,

; модель експлуатації дви-

гуна –

{

}

ξξ=Ξ ,...,,

. Документальна БД накопичує і обробляє довільні

документи. Такими документами в САПР ДВЗ, в першу чергу, є набір

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

проекту. Таким чином, САПР ДВЗ повинна мати в своєму складі змішану

документально-фактографічну БД.

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

ти з БД є СКБД.

СКБД – це програмний комплекс, який виконує сервісні функції

щодо організації, накопичення, зберігання, пошуку даних за

зовнішнім запитом.

СКБД повинна забезпечити:

• користувачів і прикладні програми мовними засобами для описів і

обробки даних;

• підтримку логічної моделі даних; тут модель даних визначає ло-

гічне уявлення фізичного розміщення даних;

• виконання операцій створення і обробки логічних структур даних,

одночасне виконання цих операцій над фізичними даними;

• захист і цілісність даних

При колективному використанні БД можливим є робота зі спільними

фізичними даними. З цього приводу необхідно забезпечувати захист даних

від некоректного оновлення, від несанкціонованого доступу, від втрати

при системних збоях. При

цьому обов’язковою функцією

сучасних СКБД є можливість

обробки БД як на окремому

комп’ютері, так і в

комп’ютерній

мережі.

Схема взаємодії прикла-

дних програм з даними за до-

помогою СКБД зображена на

рис.5.5.

втоматизована система

СКБД

БД

Програма

исунок 5.5 – Схема взаємодії програм з

даними за допомогою СКБД

233

Таким чином, використання БД і СКБД повинно забезпечувати міні-

мально можливу надмірність інформації, максимальну незалежність про-

грам від даних, простоту запитів до даних від користувачів і програм.

Інформаційна система, до якої залучено такі компоненти як

БД, СКБД, апаратні засоби і службу обслуговування БД носить

назву банк даних або автоматизованийо банк даних (АБД).

Перелічемо переваги використання концепції банку даних:

1. Можливість централізованого керування інформаційними ресур-

сами відповідно до методичного забезпечення САПР, синхронне обслуго-

вування даними усіх користувачів.

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

інтеграції.

3. Одноразове введення та багаторазове використання інформації.

4. Уніфікація засобів організації даних і незалежність програм САПР

від організації

даних.

АБД є найбільш ефективною формою організації ІЗ. Водночас вище-

вказане не виключає використання в САПР позадачного методу автомати-

зації зі збереженням певної інформації в окремих файлах. Наприклад, в

окремих файлах доречним є зберігання результатів роботи АСТПВ, тобто

файлів керування верстатами з ЧПК. Ці файли утворюють розрізнений

фонд даних САПР.

Відповідно до рис.5.2 внутрішньомашинна інформація, окрім файлів

і баз даних, може зберігатись у бібліотеках. Тут бібліотеки займають про-

міжне положення між роз’єднаним фондом і інтегрованою базою даних. Ці

бібліотеки відносять до

централізованого фонду даних.

Централізований фонд даних утворює блок даних, який не

відповідає всім властивостям БД.

Найчастіше такий фонд характеризується наявністю даних, які не

мають зв’язків між собою. Наприклад, бібліотеку можуть утворювати різ-

номанітні дані щодо експериментальних випробувань двигуна. Інші біблі-

отеки вміщують параметричні графічні елементи системи інженерної гра-

фіки, методичні матеріали, математичні моделі, програми тощо.

Таким чином, інформаційний фонд САПР ДВЗ повинен раціонально

234

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

Основним елементом ІЗ САПР тут виступає база даних об’єкта проекту-

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

життєвого циклу конструкції.

Сутність – це об’єкт довільної природи, щодо якого необхідно

зберігати інформацію в базі даних.

5.4. Класифікація моделей даних в САПР

Для користувача САПР важливим є смислове наповнення БД. Тон-

кощі організації фізичного зберігання інформації його не цікавлять. Тому з

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

вальники розглядають лише інформаційну модель.

Інформаційна модель предметної області САПР оперує поняттями

сутність, атрибути, міжсутністні та міжатрибутні зв’язки. Тут під

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

ності – властивості цієї складової. Тоді зрозуміло, що міжсутнісні та між-

атрибутні зв’язки відображають в моделі реальні міжелементні зв’язки ЦС.

Абстрактна інформаційна модель предметної області САПР, тобто

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

описані в

ЕОМ. Цей опис виконують засобами

моделі даних, котру підтримує СКБД.

При цьому модель даних, яку підтримує СКБД на логічному рівні, повинна

забезпечити достовірне відображення предметної області САПР в БД.

Моделі даних, що підтримують СКБД, базуються на двох основних

підходах:

графовому і реляційному.

При графовому підході модель (структуру) даних зображують у ви-

гляді графа, в якому вузлами (вершинами) є типи даних, а дугами – їх від-

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

ієрархічних (дерево-

видних)

і мережних моделей даних.

Приклад ієрархічної структури даних подано на рис.5.6,

а. Вузол, що

знаходиться на вищому рівні ієрархії, тут зветься коренем (вузол 1). Вузли,

з яких виходять дуги на нижчий рівень, є початковими (вузли 2,3,4,5). Вуз-

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

не мають породжених вузлів, звуться листями (вузли 6 – 12). Особливістю

такої структури є наступне.

235

исунок 5.

– Ієрархічна (а)

та мережні (б, в) структур

даних:

1 – 12 – номери вузлів

З кожного вузла може виходити декілька дуг, а входити – лише одна.

Це означає, що для ієрархічних структур характерні відношення 1:Б (один

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

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

зв’язку може бути відношення “механізм – деталі механізму”, “двигун –

множина критеріїв якості двигуна”.

Найпростішим випадком відношення 1:Б є відношення 1:1 (один до

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

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

таль – найменування деталі”. Блоки останньої структури називаються пло-

скими, або прямокутними.

Ієрархічну структуру даних завжди можна замінити на прямокутну,

коли

кожне відношення 1:Б розкладають на Б відношень 1:1. Наприклад,

“деталь – найменування деталі”; “деталь – матеріал”; “деталь – маса деталі”

тощо. Такі ж відношення можна створити щодо двигуна в цілому:

“двигун

236

– найменування двигуна”; “двигун – призначення”; “двигун – потужність”;

“двигун – номінальна частота обертання КВ”; “двигун – середньоексплуа-

таційна витрата палива

”; “двигун – ресурс”; “двигун – маса” і т.д. Зрозумі-

ло, що при цьому в модель вноситься надмірність даних.

Спробуємо за рахунок використання ієрархічної моделі даних склас-

ти схему

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

Це пояснюється тим, що деякі вузли і механізми будуть складатися з пев-

ної кількості однакових деталей. Так до ієрархічної моделі кривошипно-

шатунного механізму буде залучено таку кількість однакових шатунів, по-

ршнів, шатунних підшипників КВ та інших складових конструкції, яка збі-

гається з кількістю

циліндрів. Те ж саме можна казати про механізм газо-

розподілу, елементи паливної апаратури тощо.

Ієрархічна структура даних накладає жорсткі зв’язки між

елементами моделі об’єкта проектування. Це викликає

надмірність даних в БД.

Для подолання надмірності даних виникає потреба у введенні мере-

жних структур (див. рис.5.6

б, в) і зв’язків типу Б:1 (прості мережі) та Б:Б

(складні мережі). Прикладом зв’язку Б:1 є відношення “деталі – матеріал”.

За приклад зв’язку Б:Б можна подати відношення “поршні – кільця”, коли

для кожного поршня використовуються кільця різних типів, а кільце пев-

ного типу використовується на кожному поршні.

Але й

на мережні структури накладаються певні обмеження. Це

пов’язано з тим, що для БД з великою кількістю вузлів реалізація графово-

го підходу стримується особливостями самого підходу. В даному випадку

обробка даних при зростанні кількості вузлів (а в ДВЗ кількість елементів

може визначатись тисячами) різко ускладнюється. Водночас графовий під-

хід слабко

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

нових вузлів і зв’язків.

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

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

CODASYL.

При реляційному підході структури даних, що утворюються, мо-

жуть бути позбавлені вище вказаних недоліків.

Концепцію реляційної

моделі було запропоновано Є.Ф.Коддом. В

237

основу такої моделі було покладено поняття відношення (relation). Відно-

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

Певне відношення зручно розглядати як інформацію, яка подана у

вигляді таблиці. Наприклад, для зберігання інформації щодо сутності

„клапан” слід розробити відношення за ім’ям „КЛАПАН”, де властивості

сутності буде розміщено в стовпцях таблиці. Приклад такої таблиці-

відношення подано в табл

.5.1.

Таблиця 5.1 – Відношення „КЛАПАН”

Найменування

клапана

Діаметр

тарілки

Діаметр

стрижня

Кут нахилу

фаски

тарілки

. . .

Матеріал

Окремі стовпці таблиці є атрибутами сутності. Список імен атрибу-

тів утворює

схему відношення. Так схема відношення „КЛАПАН” буде ма-

ти функціональний вигляд

КЛАПАН (Найменування клапана, Діаметр тарілки, Діаметр

стрижня, Кут нахилу фаски тарілки, . . . , Матеріал) (5.2)

При заповненні такої таблиці кожен новий рядок даних відповідати-

ме моделі опису окремого, ідентифікованого як відмінний від інших, еле-

мента предметної області.

Відношення в реляційній моделі є засобом опису структур

даних.

З урахуванням вказаного, схема реляційної БД буде утворена набо-

ром схем відношень:

(

)

()

,,...,,

. . . . . . . . . . . . . . . . . . . . . . . .

;,...,,

xxxR

(5.3)

де

– ім’я відношення; – ім’я атрибута сутності j.

Видно, що в (5.3) кожна сутність описана окремо. Це означає, що ко-

238

ли моделлю загального вигляду (5.3) описано сутність двигуна, то, напри-

клад, відношення “КЛАПАН” незалежно від реальної кількості клапанів в

моделі буде присутнє тільки один раз. Тим самим в реляційній моделі уни-

кають надмірності даних. Водночас реляційна БД відкрита до розширення.

Для цього вираз (5.3) достатньо доповнити новим відношенням.

Вказані переваги реляційної моделі даних

знайшли значне застосу-

вання при створенні сучасних СКБД.

5.5. Основні положення реляційної моделі бази даних

5.5.1. Відношення реляційної БД

Відношення реляційної БД залежно від їх змісту підрозділяють на

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

Об’єктне відношення зберігає дані щодо екземплярів сутності. При-

кладом об’єктного відношення є вираз (5.2). В об’єктному відношенні

один з атрибутів завжди однозначно ідентифікує окремий об’єкт.

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

об’єкт зветься ключем відношення або первинним атрибутом.

Неважко побачити, що у відношенні „КЛАПАН” первинним атрибу-

том є “Найменування клапана” (див. табл.5.1).

Для зручності аналізу відношень ключ завжди розміщують в першо-

му стовпці таблиці. Інші атрибути відношення вважаються залежними від

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

чень інших атрибутів, тобто відповідає переходу в інший

рядок таблиці.

В об’єктному відношенні не повинно бути рядків з однаковими клю-

чами, тобто не повинно бути дублювання об’єктів. Це є основним обме-

женням реляційної моделі даних.

Зв’язне відношення зберігає ключі двох або більшої кількості

об’єктних відношень. Саме по цих ключах визначаються зв’язки між

об’єктними відношеннями – міжсутністні відношення.

Розглянемо два конструктивних вузла, наприклад,

і 2

. Нехай до

кожного з них у переліку інших деталей залучено деталь

, яка має

об’єктне відношення з ключем

. Тоді зв’язні відношення

11d 1

і 2

бу-

дуть мати посилання, окрім іншого, на один і той самий ключ

: 11d

239