Структура і побудова інформаційної моделі предметної області
Процес створення інформаційної моделі починається з визначення концептуальних вимог майбутніх користувачів БД (працівники військової кафедри, деканатів та факультетів). На рис. 4 представлена загальна структура інформаційної моделі.
Відео: Синергія + UML HD
Проектування концептуальної моделі засновано на аналізі вирішуваних завдань по обробці даних, тобто зберігання і обробка навчальних планів груп, розрахунок академічних доручень по кафедрам, розподіл навантаження по викладачах і складання розкладу занять. При цьому зусилля розробника повинні бути спрямовані в основному на структуризацію даних, що належать майбутнім користувачам БД і виявлення взаємозв`язків між ними.
Можливо, що відображені в концептуальної моделі взаємозв`язку між об`єктами виявляться згодом нереалізованим засобами обраної СУБД. Це зажадає зміни концептуальної моделі. Логічна модель відображає логічні зв`язки між атрибутами незалежно від їх змісту і середовища зберігання і може бути реляційної, ієрархічної або реляційної.
Різним користувачам в інформаційній моделі відповідають різні підмножини її логічної моделі, які називаються зовнішніми моделями користувачів. Таким чином, зовнішня модель користувача являє собою відображення концептуальних вимог цього користувача в логічної моделі і відповідає тим уявленням, які користувач отримує про предметну область на основі логічної моделі. Отже, наскільки добре спроектована зовнішня модель, наскільки повно і точно інформаційна модель відображає предметну область і настільки повно і точно працює автоматизована система управління цією предметною областю.
В даний час розрізняють в основному три типи інформаційних моделей: ієрархічну, мережеву та реляційну.
Ієрархічна і мережна моделі даних стали застосовуватися на початку 60-х років. На початку 70-х років була запропонована реляційна модель даних, яка призначалася в БД для ПК.
Ці три моделі розрізняються в основному способами інформаційного відображення об`єктів і їх взаємозв`язків. Приймемо за базову реляційну модель.
Реляційні БД мають потужний теоретичний фундамент, заснований на математичної теорії відносин. Він був розроблений співробітником фірми IBM доктором Едгаром Коддом. Для побудови запитів до реляційних БД був також розроблений мову SQL (Structured Query Language, мова структурованих запитів). Він набув характеру промислового стандарту в реляційних СУБД. Тому, переходячи з однієї реляційної бази на іншу, користувач і розробник мають справу з одним і тим же мовою. Іншим важливим плюсом SQL є те, що ця мова орієнтований на високорівневі операції з даними. Видаючи запит, можна не турбуватися про низькорівневих проблеми доступу до даних, специфічних для кожної БД, оскільки інтерпретація запитів в команди низького рівня лежить у віданні конкретної СУБД.
Між двома або більше таблицями реляційної бази даних можуть існувати відносини підлеглості. Відносини підпорядкованості визначають, що для кожного запису головної таблиці (master, її називають іще батьківської) може існувати одна або кілька записів у підпорядкованій таблиці (detail, званої ще дочірньої).
База даних - це велика за обсягом сховище, в яке ми поміщаємо всі використовувані в ньому інформаційні дані, і з якого різні користувачі можуть їх отримувати, використовуючи різні додатки.
Така єдина база даних представляється ідеальною для всіх структурних підрозділів військової кафедри, факультету.
В основу досліджень з розробки оптимальної системи БД ми повинні покласти уявлення кінцевих користувачів і концептуальні вимоги до системи. Саме кінцевий користувач у своїй роботі приймає рішення з урахуванням інформації, одержуваної в результаті доступу до бази даних. Від оперативності і якості цієї інформації буде залежати ефективність роботи військової кафедри.
При розгляді вимог кінцевих користувачів до БД необхідно брати до уваги наступне:
1. БД повинна задовольняти актуальним інформаційним потребам підприємства. А це означає, що організація інформаційних даних в БД повинна за структурою і змістом відповідати важливість справ на підприємстві завданням.
2. БД повинна забезпечувати отримання необхідних даних за прийнятний час, тобто забезпечувати задану продуктивність.
3. БД повинна бути розрахована на можливість задоволення знову виникають вимог кінцевих користувачів.
4. База даних повинна бути розрахована на можливість розширення при реорганізації і розширенні предметної області.
5. БД повинна легко змінюватися при зміні програмної та апаратної середовища.
6. Завантажені в БД коректні дані повинні залишатися коректними.
7. Дані до включення в БД повинні перевірятися на достовірність.
8. Доступ до даних, розміщених в БД, повинні мати тільки особи з відповідними повноваженнями.
Етапи проектування бази даних з урахуванням розглянутих вище аспектів представлені на рис.5. В результаті аналізу поставленого завдання і
Рис.5.
Етапи проектування бази даних
Відео: WIAD 2017 SPb: Відкриття. Максим Цепков "Від монолітних моделей предметної області - до модульних"
обробки вимог кінцевих користувачів складається концептуальна модель.
При розробці логічної моделі БД, перш за все, необхідно вирішити, яка модель даних найбільш підходить для відображення конкретної концептуальної моделі предметної області.
Перехід від концептуальної до логічної моделі даних проводиться таким чином. Кожен прямокутник (об`єкт) концептуальної моделі в логічної моделі представляється таблицею, що містить його атрибути, які в зручній для користувача формі відображається візуальними засобами ПК, наприклад, на екрані дисплея.
Розглянемо процес створення БД для системи автоматизації діяльності навчальної частини військової кафедри.
Для отримання необхідної моделі необхідно враховувати зв`язку військової кафедри з факультетами, кафедрами вузу.
Поділитися в соц мережах:
Схожі
