Cтворення фізичної моделі в erwin. Створення логічної моделі інформаційної системи. Лабораторна робота з Проектування інформаційних систем. Робота № 527433

Перехід до торгівельного партнера Binance

Cтворення фізичної моделі в erwin. Створення логічної моделі інформаційної системи

Інформація про навчальний заклад

ВУЗ:

Національний університет Львівська політехніка

Інститут:

Не вказано

Факультет:

КН

Кафедра:

Не вказано

Інформація про роботу

Рік:

2014

Тип роботи:

Лабораторна робота

Предмет:

Проектування інформаційних систем

Завантажити

Частина тексту файла (без зображень, графіків і формул):

Міністерство освіти і науки України Національний університет «Львівська політехніка» Лабораторна робота №5-6 з дисципліни: Проектування інформаційних систем на тему: «Cтворення фізичної моделі в erwin. Створення логічної моделі інформаційної системи» Львів 2014 Мета роботи: на основі заданої функціональної моделі необхідно створити логічну модель інформаційної системи з використанням пакета ERwin. ТЕОРЕТИЧНІ ВІДОМОСТІ ERwin – засіб концептуального моделювання БД, який використовує методологію IDEF1X. ERwin реалізує проектування схеми БД, генерацію її опису на мові цільової СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress та ін.) та реінжиніринг існуючої БД. ERwin випускається в декількох різних конфігураціях, орієнтованих на найпоширеніші засоби розробки додатків 4GL. Версія ERwin/OPEN повністю сумісна із засобами розробки додатків PowerBuilder та SQLWindows і дозволяє експортувати опис спроектованої БД безпосередньо в репозиторії даних програмних продуктів. Для ряду засобів розробки додатків (PowerBuilder, SQLWindows, Delphi, VisualBasic) можна виконати генерацію форм і прототипів додатків. Мережева версія ERwin ModelMart забезпечує узгоджене проектування БД та додатків у робочій групі. Основні переваги використання пакета ERwin:  істотне підвищення швидкості розробки за рахунок потужного редактора діаграм, автоматичної генерації бази даних, автоматичної підготовки звітної документації;  немає необхідності ручної підготовки SQL-запитів при створенні бази даних;  можливість легко вносити зміни в модель при розробці і розширенні системи;  можливість автоматичної підготовки звітів щодо спроектованої бази даних; причому ці звіти завжди точно відповідають реальній структурі БД;  розробники прикладного програмного забезпечення мають зручні в роботі діаграми;  тісна інтеграція із засобами 4GL дозволяє вже на стадії інформаційного моделювання задавати відображення даних у створюваних додатках;  зворотне проектування дозволяє документувати і вносити зміни в існуючі інформаційні системи;  підтримка розрахованих на одного користувача СУБД, що дозволяє використовувати для персональних систем сучасні технології, які значно спрощують перехід від настільних систем до систем в технології клієнт-сервер (upsizing). Типи зв’язку між сутностями (ідентифікуючий / неідентифікуючий) У методології IDEF1X розрізняють залежну і незалежну сутності. Тип сутності визначається її зв’язком з іншою сутністю. Ідентифікуючий зв’язок встановлюється між незалежною (батьківський кінець зв’язку) і залежною (дочірній кінець зв’язку) сутністю. У випадку, коли зображається ідентифікуючий зв’язок, ERwin автоматично перетворить дочірній зв’язок у залежний. Залежна сутність зображається прямокутником з округлими кутами. Екземпляр залежної сутності визначається тільки через її відношення до батьківської сутності. При встановленні ідентифікуючого зв’язку атрибути первинного ключа батьківської сутності автоматично переносяться до складу первинного ключа дочірньої сутності. Ця операція доповнення атрибутів дочірньої сутності при створенні зв’язку називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як зовнішні ключі – (мають примітку FK). При встановленні неідентифікуючого зв’язку дочірня сутність залишається незалежною, а атрибути первинного ключа батьківської сутності мігрують до складу неключових компонентів дочірньої сутності. Неідентифікуючий зв’язок служить для зв’язку незалежної сутності. Ідентифікуючий зв’язок показується на діаграмі суцільною лінією з жирною крапкою на дочірньому кінці зв’язку (див. рис. 1.1), неідентифікуюча – пунктирною. Для неідентифікуючого зв’язку можна вказати обов’язковість (Nulls в закладці Generalдіалогу Relationship Editor). У випадку обов’язкового зв’язку (No Nulls) при генерації схеми БД атрибут зовнішнього ключа набуде значення NOT NULL, незважаючи на те, що зовнішній ключ не ввійде до складу первинного ключа дочірньої сутності. У разі необов’язкового зв’язку (Nulls Allowed) зовнішній ключ може набувати значення NULL. Необов’язковий неідентифікуючий зв’язок позначається прозорим ромбом з боку батьківської сутності. Ім’я зв’язку (Verb Phrase) – це фраза, яка характеризує відношення між батьківською і дочірньою сутностями. Для зв’язку “один-до-багатьох” ідентифікуючого або неідентифікуючого зв’язку досить вказати ім’я зв’язку, який характеризує відношення батьківської сутності до дочірньої (Parent-to-Child). Для зв’язку “багато-до-багатьох” потрібно вказувати імена як Parent-to-Child, так і Child-to-Parent. Для відображення імені необхідно з контекстного меню до вільної області побудови діаграми вибрати пункт Display Options/Relationship і включити опцію Verb Phrase. Ім’я ролі або функціональне ім’я (Rolename) – це синонім атрибута зовнішнього ключа, що показує, яку роль виконує атрибут у дочірній сутності. Задати ім’я ролі можна на в закладці Rolename/RI Actions діалогу Relationship Editor. У прикладі, наведеному на рис. 1.3, у сутності “Співробітник” зовнішній ключ “Номер відділу” має ім’я ролі “Де працює”, яке показує, яку роль виконує цей атрибут по сутності. За замовчуванням у списку атрибутів показується тільки ім’я ролі. Для відображення повного імені атрибута (як функціонального імені, так і імені ролі) слід з контекстного меню до вільної області діаграми вибрати пункт Display Options/Entities і потім включити опцію Rolename/Attribute. Повне ім’я показується як функціональне ім’я і базове ім’я, розділені крапкою. Обов’язковим є застосування імен ролей у тому випадку, коли два або більше атрибутів однієї сутності визначені по одній і тій самій області, тобто у них одна і та ж область значень, але вони мають різні значення. Рис. 1.3. Імена ролей зовнішніх ключів На рис. 1.4 сутність “Продаж валюти” містить інформацію про акт обміну валюти, у якому беруть участь дві валюти – продана і куплена. Інформація про валюти знаходиться у сутності “Валюта”. Отже, сутності “Продаж валюти” і “Валюта” повинні бути зв’язані двічі, і первинний ключ – “Номер валюти” повинен двічі мігрувати в сутність “Валюта” як зовнішній ключ. Тому необхідно розрізняти атрибути, які містять інформацію про номер проданої і купленої валюти (мають різне значення), але посилаються на одну і ту ж сутність “Валюта” (мають спільну область значень). Рис. 1.4. Випадок обов’язковості імен ролей У прикладі на рис. 1.4 атрибути мають імена ролей “Продана” і “Куплена”. Іншим прикладом обов’язкового застосування імен ролей є рекурсивні зв’язки, коли одна і та ж сутність є і батьківською, і дочірньою одночасно. Правила посилальної цілісності (Referential Integrity (RI)) – це логічні конструкції, які виражають бізнес-правила використання даних і є правилами вставки, заміни і видалення. Задати правила посилальної цілісності можна в закладці Rolename/RI Actions діалогу Relationship Editor. При генерації схеми БД на основі опцій логічної моделі будуть згенеровані правила декларативної посилальної цілісності, які повинні бути вказані для кожного зв’язку, і тригери, які забезпечують посилальну цілісність. На рис. 1.5 існує ідентифікуючий зв’язок між сутністю “Команда” і “Гравець”. Що буде, якщо видалити команду? Екземпляр сутності “Гравець” не може існувати без команди (атрибут первинного ключа Команда. Номер команди не може набувати значення NULL), отже, потрібно або заборонити видалення команди, доки в ній є хоча б один гравець, або видаляти разом з командою і всіх її гравців. Такі правила вилучення (Parent Delete) називаються Parent Restrict (обмеження) і Parent Cascade (каскад). Сутності “Гравець” і “Гол”, у свою чергу, теж зв’язані ідентифікуючим зв’язком і, якщо на видалення гравця накладено правило каскадного видалення всіх записів про його голи, то при видаленні команди будуть видалені всі гравці команди і всі голи, забиті цими гравцями. Рис. 1.5. Міграція імен ролей Зв’язок багато-до-багатьох можливий тільки на рівні логічної моделі даних. Такий зв’язок позначається суцільною лінією з двома крапками на кінцях. Для внесення зв’язку слід спочатку натиснути на кнопку на палітрі інструментів (ERwin Toolbox ), а потім по черзі клацнути по обох зв’язаних сутностях. Зв’язок багато-до-багатьох повинен іменуватися (Verb Phrase) двома фразами – в обидві сторони. Це полегшує читання діаграми. Створення ключів Кожен екземпляр сутності повинен бути унікальним і відрізнятися від інших атрибутами. Первинний ключ (primary key) – це атрибут або група атрибутів, які однозначно ідентифікують екземпляр сутності. Атрибути первинного ключа на діаграмі не вимагають спеціального позначення – це ті атрибути, які знаходяться в списку атрибутів вище горизонтальної лінії. При внесенні нового атрибуту в діалозі Attribute Editor для того, щоб зробити його атрибутом первинного ключа, потрібно включити прапорець Primary Key в нижній частині закладки General. На діаграмі ключовий атрибут можна внести до складу первинного ключа, скориставшись режимом перенесення атрибутів. У однієї сутності може бути декілька атрибутів або наборів атрибутів, що претендують на роль первинного ключа. Такі претенденти називаються потенційними ключами (candidate key). Ключі можуть бути складними, тобто складатися з декількох атрибутів. При виборі первинного ключа перевага повинна віддаватися простішим ключам, тобто ключам, які мають меншу кількість атрибутів. Багато сутностей мають тільки один потенційний ключ. Такий ключ стає первинним. Деяка сутність може мати більше одного можливого ключа. Тоді один з них стає первинним, а інші – альтернативними ключами. Альтернативний ключ (Alternative Key) – це такий потенційний ключ, який не став первинним. Кожному ключу відповідає індекс, ім’я якого також присвоюється автоматично. Імена ключа і індексу при бажанні можна змінити. На діаграмі атрибути альтернативних ключів позначаються як (AК n.m.), де n – порядковий номер ключа, m – порядковий номер атрибута в ключі. Якщо альтернативний ключ має декілька атрибутів, позначка (AКn.m.) ставиться після кожного атрибута. Зовнішні ключі (Foreign Key) створюються автоматично, коли зв’язок сполучає сутності: зв’язки утворюють посилання на атрибути первинного ключа в дочірній сутності і ці атрибути утворюють зовнішній ключ у дочірній сутності (міграція ключа). Атрибути зовнішнього ключа позначаються символом (FK) після свого імені (рис. 1.6). Атрибути зовнішнього ключа “Місце роботи. Номер відділу” (“Де працює” – ім’я ролі) сутності “Співробітник” є атрибутом первинного ключа (PK) по сутності “Відділ”. Виконання: Створила новий проект Logical/Physical і вибрала сервера. / Створила логічну модель системи. / Задаю англійською мовою на фізичному рівні імена таблиць відповідно до логічної моделі: / Встановлюю своє прізвище як автора таблиць і встановлюю рівень відображення інформації на екрані – відображення власників таблиць і назв колонок: / Валідація: / Нова наочна область: / Визначення типів даних в колонках: / Висновок: на лабораторній роботі на основі заданої функціональної моделі я створила логічну модель інформаційної системи з використанням пакета ERwin.

Лабораторна робота Проектування інформаційних систем

Edited

06.12.2015 18:12-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!

поділитись