Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

ОБДЗ / Лекции Access / Проектування РБД / 3_концептуальне_проектування

.pdf
Скачиваний:
9
Добавлен:
03.03.2016
Размер:
143.49 Кб
Скачать

3 КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ

3.1 Розробка постановки задачі

За результатами передпроектного обстеження діючі стандарти на автоматизовані системи рекомендують оформляти документ "Опис постановки задачі або комплексу задач". Цей документ може містити розділи:

1)характеристики задачі (комплексу задач);

2)вихідна інформація;

3)вхідна інформація.

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

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

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

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

Постановку задачі рекомендують затверджувати як документ, що підписується сторонами замовників та розробників ІС. Це дозволить уникнути небажаних протиріч на стадії реалізації та впровадження.

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

Такі речення дозволяють одночасно зафіксувати дані разом із семантикою. Наприклад, у реченні “Оцінка студента – “відмінно” даним є слово “відмінно”, а слова “оцінка студента” – це його семантика.

Але природна мова часто не може бути використана у чистому вигляді для моделювання. Цьому заважає складність комп'ютерної обробки текстів, громіздкість опису та неоднозначності трактування. Тому при опису ПО застосовують штучні формальні мовні засоби, близькі до природної мови, або графічне представлення. Таке моделювання назвали семантичним чи інфологічним. Відповідні моделі називають інфологічними моделями (ІМД).

12

3.2 Інфологічне моделювання

Основною вимогою до ІМД, що випливає з її призначення, є вимога адекватного відображення ПО.

ІМД містить у собі ряд компонентів:

опис об’єктів;

опис зв’язків між об’єктами;

опис інформаційних потреб користувачів.

Мова для представлення ІМД повинна володіти достатніми виразними можливостями для відображення явищ, що мають місце в ПО. Реальний світ є по своїй природі нескінченним, а будь-яка модель кінцева й обмежена. Проте ІМД повинна дозволяти вводити нові об'єкти і вилучати дані. Тому ІМД повинна мати властивість розширюваності, що забезпечує введення і вилучення даних без зміни раніше визначених. У зв'язку з великою розмірністю моделей повинна забезпечуватися можливість її композиції і декомпозиції.

Основними конструктивними елементами ІМД є сутності, їхні властивості, а також зв'язки між ними.

Якщо уважно розглянути постановку задачі як подання ПО, то іменники можуть бути сутностями, а дієслова – зв’язками.

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

Наприклад, сутність “Студент” відбиває інформацію про студента вищого навчального закладу (ВНЗ) з наступним набором даних: прізвище, ім’я, побатькові (ПІБ), дата народження, стать, спеціальність, група та ін. Сутність “Розклад занять” відбиває розклад занять у навчальному процесі студентів з даними: день тижня, час початку, час закінчення, група (потік), дисципліна, вид занять (лекція, лабораторна робота, практичне заняття, тощо), місце проведення, викладач (або кілька викладачів).

Для сутності необхідно розрізняти такі поняття, як тип і екземпляр. Тип сутності (далі просто сутність) відносять до набору однорідних особистостей, предметів чи подій, що виступають як єдине ціле. Вище ми розглянули сутності “Студент” та “Розклад занять”.

Екземпляр сутності відноситься до конкретної речі в цьому наборі. Наприклад, для сутності “Студент” екземплярами можуть бути окремі студенти: Петров П.П., Іванов І.І., Андрєєв А.А., які навчаються в ДонНТУ. Для сутності “Розклад занять” екземпляром може бути лекція з вищої математики, лабораторна робота з ОБДЗ.

Для зручності при визначенні назв (імен) сутностей будемо використовувати наступне правило іменування: назва записується з прописної букви без лапок одним словосполученням.

Таким чином ім’я сутності “Розклад занять” можна записати як РозкладЗанять, коли кожне слово записується з прописної букви, або Розклад_занять, коли замість пропуску між словами використано знак

13

підкреслення (_). Будемо в основному використовувати другий варіант іменування.

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

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

Для атрибутів також існує розходження між типом і екземпляром. Тип атрибута (далі просто атрибут) Прізвище має багато екземплярів значень: Петров, Іванов, Андрєєв. Однак кожному екземпляру сутності привласнюється тільки одне значення атрибута.

Абсолютне розходження між сутностями та атрибутами відсутнє. Атрибут є атрибутом тільки в зв'язку з сутністю. В іншому контексті атрибут може виступати як самостійна сутність. Наприклад, для автомобільного заводу колір – це тільки атрибут продукту виробництва, а для лакофарбового заводу колір може бути сутністю.

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

Для сутностей, що нас оточують, у більшості випадків вже реально визначені та існують ключі. Наприклад, для сутності Люди ключем може бути ідентифікаційний номер (Ід_номер, ІН), для громадянина – номер та серія паспорту, для студента – номер залікової книжки, для працівників підприємства

табельні номери, для квартировинаймачів – особисті рахунки, для автомобілів

державні номери, тощо.

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

Реальні БД нерідко містять сотні сутностей. Теоретично між ними може

14

бути встановлене необмежене число зв'язків.

Розглянемо приклади зв'язків. Наприклад, відомо, що кожен студент може навчатися в кількох вузах, на кількох спеціальностях. Сутності Студент і Залікова_книжка (далі Книжка) зв'язані. Трактуванням зв'язку Студент – Книжка наступне:

кожна Книжка призначена для одного і тільки одного Студента;

кожен Студент може мати одну чи більш Книжок.

У загальному випадку між двома сутностям, наприклад, А і Б, можливі кілька видів (типів) зв'язку:

1)один-до-одного; цей зв'язок означає, що кожному представнику (екземпляру) сутності А може відповідати один представник сутності Б або не відповідає ні одного (0 представників), а кожному представнику сутності Б відповідає тільки один представник сутності А; такий зв’язок позначається як

1:1;

2)один-до-багатьох (1:М); при такому зв'язку кожному представнику сутності А може відповідати 0, 1 або кілька (більше одного) представників сутності Б, а кожному представнику сутності Б відповідає тільки один представник сутності А;

3)багато-до-одного (М:1); при такому зв'язку кожному представнику сутності Б відповідає кілька представників сутності А, а кожному представнику сутності А відповідає тільки один представник сутності Б;

4)багато-до-багатьох (М:N); при такому зв'язку кожному представнику сутності Б може відповідати кілька (М) представників сутності А, а кожному представнику сутності А у свою чергу може відповідати кілька (N) представників сутності А.

Видно, що зв’язки виду 2 та 3 однакові. Тобто якщо вид 2 визначає зв’язок 1:М зі сторони сутності А до сутності Б, то у виді 3 розглядається цей же зв’язок зі сторони сутності Б до сутності А, а цей зв’язок має вид М:1. Таким чином, тип зв’язку М:1 можна вважати зворотнім (протилежним) до зв’язку типу 1:М;

Для зв’язку виду M:N можливий окремий випадок, коли М=N.

Звертаю увагу на формулювання відповідності: може відповідати, а не відповідає.

Розглянемо зв’язки між сутностями Батьки та Діти. У кожного батька (чоловіка) може бути 0, 1 або більше дітей. У кожної дитини може бути тільки один фізіологічний батько. Таким чином між сутностями Батьки і Діти існує зв’язок 1:М. У цьому прикладі сутність Батьки розглядається як батьківська, а сутність Діти – як дочірня.

Відмітимо, що якщо екземплярами сутності Батьки будуть і чоловіки, і жінки, то в такому випадку між сутностями Батьки і Діти існує зв’язок М:N, а точніше 2:N.

По аналогії у зв’язку між двома сутностями можна визначити батьківську

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

15

Тип зв’язку залежить від ПО, яка розглядається. Розглянемо ще кілька прикладів.

Одна людина може одержати ідентифікаційний номер або в силу різних причин не одержати його. Один номер може відповідати тільки одній людини. Таким чином, між сутностями Люди та Ід_номери існує зв’язок типу 1:1.

Розглянемо сутності Люди і Паспорти громадянина. Людина може мати один громадянський паспорт або не мати його, якщо їй не виповнилося 16 років. Звичайно, якщо розглядається законослухняний громадянин. Один паспорт може відповідати (належати) тільки одній людини. Таким чином, у повсякденному житті між сутностями Люди та Паспорти (громадянські) існує зв’язок типу 1:1.

Якщо ми розглядаємо роботу обліку паспортів у відповідних відділах внутрішніх справ, то там зберігається інформація про всі видані паспорти, навіть якщо вони були втрачені, зіпсовані або вкрадені. Таким чином, в паспортних відділах одній людини можуть в загальному випадку видаватися кілька паспортів різних номерів та серій. В любому випадку один паспорт відповідає тільки одній законослухняній людині. Таким чином, при паспортному обліку між сутностями Люди та Паспорти (громадянські) існує зв’язок типу 1:М.

Розглянемо ще більш загальну задачу обліку паспортів. Відомо, що людина крім громадянського паспорту може мати ще закордонні, дипломатичні, службові паспорти або не мати їх. При цьому один паспорт може відповідати тільки одній людини. Таким чином, між сутностями Люди та Паспорти загалом існує зв’язок типу 1:М.

Розглянемо облік студентів.

Студентський потік може складатися з однієї або кількох груп, а група може відноситися тільки до одного потоку. Таким чином між сутностями Потоки і Групи існує зв’язок типу 1:М.

Як відомо, студент може навчатися за кількома напрямами підготовки, а відповідно у кількох групах. В одній групі може навчатися кілька студентів, а один студент може навчатися в кількох групах. При цьому таке навчання не обов’язково має бути одночасним. Тоді між сутностями Студенти і Групи повинен існувати зв’язок типу M:N.

Розглянемо процес реєстрації громадян за місцями проживання. Визначимо сутності Квартири і Люди . При реєстрації в квартирі може бути зареєстровано 0, 1 або кілька мешканців. При цьому одна людина може бути постійно зареєстрованою лише за однією адресою, тобто в одній квартирі. Таким чином, з першого погляду можна вважати, що при реєстрації між сутностями Квартири і Люди існує зв’язок типу 1:М. Але аналіз ПО показує, що такий підхід дуже спрощений. Адреси реєстрації можуть змінюватися в часі. І тому в загальному випадку між сутностями Квартири і Люди існує зв’язок типу N:М.

При оформленні прав власності одна квартира може належати одному або кільком власникам, або не належати нікому (0 власників). При цьому одна людина може володіти кількома квартирами. Таким чином в цьому випадку між

16

сутностями Квартири і Люди існує зв’язок типу М:N.

Характерним прикладом різних видів зв’язків є зв'язок між сутностями Чоловік і Жінка, який оформлюється як Шлюб. Теоретично існують чотири можливих види такого зв'язку:

традиційний шлюб (1:1);

багатоженство (1:M);

багатомужжя (M:1);

груповий шлюб (M:N).

Ці види розглядаються на якийсь визначений момент часу. Але якщо розглядати навіть традиційний шлюб з точки зору реєстрації актів громадянського стану, то в загальному випадку шлюб – це зв’язок типу N:M: протягом життя у кожного Чоловіка може бути зареєстровано кілька шлюбів з Жінками, а у кожної Жінки кілька шлюбів з Чоловіками.

Таким чином, якщо враховувати зміни в часі, то більшість зв’язків мають тип N:M. Наприклад, Працівники – Місця роботи, Підпрємства – Керівники, тощо.

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

Розглянемо дві сутності Лікарі та Пацієнти. При лікуванні кожен лікар може мати кілька пацієнтів, а пацієнт має одного основного дільничого лікаря (зв’язок 1:M). А при консультаціях пацієнт може мати кількох лікарівконсультантів, кожен з яких може одночасно консультувати інших пацієнтів

(зв’язок N:M).

Розглянемо три сутності Лікарі, Пацієнти та Аналізи. Лікар може призначити декількох пацієнтів на декілька аналізів, аналіз може бути призначений декількома лікарями декільком пацієнтам і пацієнт може бути призначений на декілька аналізів декількома лікарями. Маємо приклад тренарного зв’язку.

Розглянемо сутність Люди. Нехай її екземплярами є як батьки, так і діти. Існують такі зв’язки:

кожна людина (екземпляр сутності) є дитиною одного і тільки одного чоловіка (людини);

кожна людина є дитиною однієї і тільки однієї жінки (людини);

кожна людина (чоловік) може бути батьком для однієї дитини або більше дітей (людей);

кожна людина (жінка) може бути матір’ю для однієї дитини або більше дітей (людей).

Таким, чином для сутності Люди маємо досить складний рекурсивний зв'язок, який зв'язує сутність з нею самою.

При зростанні порядку зв'язків їхня семантика ускладнюється. Між тими самими сутностями може існувати безліч складних зв'язків. Їх наявність визначає складність ІМД. Наприклад, інформація про прийомних дітей значно ускладнює вищенаведену МД.Тому з метою спрощення моделі всі види зв’язків звичайно переформуються до зв’язків двох типів: 1:1 або 1:М.

Атрибути, що беруть участь у зв’язку з боку дочірньої сутності,

17

називають зовнішнім ключем. Його значення однозначно характеризують сутності, представлені атрибутами батьківської сутності і задаються значеннями її первинного ключа.

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

Стрижень – це незалежна сутність. У розглянутих раніше прикладах стрижнями є сутності Студенти, Квартири, Люди.

Асоціативна сутність або асоціація – це зв'язок виду "-до-багатьох" між двома чи більш сутностями чи екземплярами сутності. Для однієї сутності може також існувати рекурсивна асоціація.

Асоціації розглядаються як повноправні сутності. Вони можуть:

брати участь в інших асоціаціях так, як і стрижні;

мати властивості, тобто мати будь-яке число атрибутів, що характеризують зв'язок.

Характеристики – це сутності, що характеризують інші сутності. Характеристика розглядається як окремий випадок асоціації, що відбивають зв'язки виду "-до-одного" між двома сутностями. Необхідність у характеристиках виникає в зв'язку з тим, що сутності реального світу мають іноді багатозначні властивості. І ціль характеристики полягає в уточненні деякої іншої сутності.

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

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

Як правило, позначення та характеристики не розглядаються як повноправні сутності. Вони не цілком незалежні сутності, оскільки припускають наявність іншої сутності, що буде "позначатися" чи "характеризуватися". Однак вони все-таки являють собою окремі випадки сутності і можуть мати властивості. Вони можуть брати участь в асоціаціях і позначеннях, а також мати свої власні характеристики більш низького рівня.

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

18

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

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

Недостатньо продумана модель може призвести до невдало спроектованого проекту ІС. У більшості випадків такий вмираючий проект неможливо реанімувати за допомогою змін в ПД. Доведеться знову починати з уточнення ІМД.

Рекомендації з побудови ІМД формувалися десятиліттями кращими фахівцями в області обробки даних. Пік робіт з концептуального моделювання припав на кінець 70-х років минулого століття. коли були розроблені кілька різних методологій.

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

3.3 Мова інфологічного моделювання

Для опису ІМД може бути використана мова інфологічного моделювання

(МІМ).

У МІМ для опису сутностей використовують окремі речення. Синтаксис речень залежить від виду сутностей і має наступний вигляд:

СУТНІСТЬ (атрибут 1, атрибут 2 , ..., атрибут n) АСОЦІАЦІЯ [СУТНІСТЬ S1, СУТНІСТЬ S2,...]

(атрибут 1, атрибут 2, ..., атрибут n) ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)

{СПИСОК СУТНОСТЕЙ, ЩО ХАРАКТЕРИЗУЮТЬСЯ}. ПОЗНАЧЕННЯ (атрибут 1, атрибут 2, ...)

[СПИСОК СУТНОСТЕЙ, ЩО ПОЗНАЧАЮТЬСЯ].

У цих реченнях атрибути, що входять у ключ, відзначаються підкресленням. Але ключі краще відзначати не підкресленням, а знаком (*). Інакше, наприклад, в атрибуті Код_студента можемо загубити підкреслення в назві атрибуту.

У асоціації буквами S1,S2 позначені числа, які характеризують ступінь зв'язку між сутностями.

19

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

Для ІМД реєстрації людей опис може мати наступний вид: Квартири (*Код_квартири, Адреса, Поверх, Площа,…) Мешканці (*Ід_номер, Прізвище, Ім’я, По_батькові, Стать,…)

Реєстрація [Квартири M, Мешканці] (Дата_реєстрація, Дата_вибуття,…) Інші приклади будуть розглянуті в розділі 8.

Опис ІМД на МІМ може бути дуже змістовним, особливо при побудови великих моделей.

3.4 Діаграми "Сутності-Зв'язки"

Частина методологій рекомендують при побудові ІМД використовувати графічне представлення у вигляді моделі типу "Сутності-Зв'язки". Основним видом таких моделей вважають ER-моделі або ER-діаграми (від англ. EntityRelationship).

Загальний набір елементів ЕR-діаграм наведено на рис. 3.1.

Рисунок 3.1 – Елементи ER-діаграм

Кожна сутність має унікальне для МД ім’я. Ці імена записуються в елементи діаграми. Зазвичай для імен сутностей використовують іменники в однині. Але для кращого розуміння краще використовувати імена у множині.

Зв'язок між сутностями графічно зображується як асоціація. У будь-якому зв'язку виділяються два кінці.

На кожному кінці зв’язку може бути вказано:

ім'я кінця зв'язку;

ступінь кінця зв'язку (скільки екземплярів даної сутності зв'язується);

обов'язковість зв'язку (тобто чи будь-який екземпляр даної сутності повинен брати участь у даному зв'язку).

Атрибути сутностей і ключі можуть бути наведені як безпосередньо у

20

сутностях, так і окремо (рис. А1а). Перший варіант можна вважати більш наочним. Але іноді для підвищення ілюстративності МД на великих діаграмах взагалі не показують атрибути.

На рис. 3.2 наведені приклади ER-діаграм для зв’язків двох основних

типів.

 

1

 

1

 

ЛЮД И

 

П Р И ЗН АЧЕН Н Я

 

ІД _НОМЕР И

 

 

 

 

 

 

 

а)зв’язок типу 1:1

б)зв'язок типу 1:М Рисунок 3.2 – Приклади ERдіаграм

Інші приклади будуть розглянуті в розділі 7.

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

ER-діаграми застосовують як при ручному, так і при автоматизованому проектуванні ІС.

У першому випадку зазвичай використовують графічні можливості пакетів Microsoft Word (фігури та рисунки SmartArt), Microsoft Visio (режим Basic flowshart shapes), тощо.

В другому випадку використовують спеціальні програмні продукти автоматизованої розробки ІС, які отримали загальну назву CASE-засобів

(Computer-aided software engineering), а точніше їх інструменти проектування МД, БД і сховищ даних.

21