ОСНОВИ ER-МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ. Практичне завдання до теми 3 основи erмоделювання предметної області. Аналіз предметної області та концептуальне моделювання
 Скачать 206.09 Kb.
|
|
ПРАКТИЧНЕ ЗАВДАННЯ ДО ТЕМИ №3 ОСНОВИ ER-МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ Мета – засвоїти основні поняття ER- моделювання предметної області, навчитися визначати сутності предметної області, атрибути, що її характеризують, та ключові атрибути, що її однозначно ідентифікують. Форма звіту – електронний варіант звіту, оформлений згідно вимог викладача. ПРИКЛАД РОЗРОБЛЕННЯ ІНФОРМАЦІЙНОЇ МОДЕЛІ В ТЕРМІНАХ ER-ДІАГРАМИ 3.1 Рекомендації та правила побудови діаграм Готуючись до обговорення проектних рішень із замовниками системи, потрібно побудувати діаграму відповідного фрагмента предметної області. Переглядаючи цей фрагмент разом із вашим співрозмовником, ви часто знаходитимете помилки. Це абсолютно природно, адже побудова діаграми складної предметної області є ітеративним процесом, на першому етапі якого майже ніколи не отримують кінцевий результат. Діаграму слід спланувати в такий спосіб, щоб прямокутники сутностей розміщувалися на одних рівнях, а лінії зв’язків були прямими, горизонтальними або вертикальними. Кількість перетинів потрібно звести до мінімуму, також слід уникати побудови діаграм з великою кількістю близько розташованих паралельних ліній. Необхідно використовувати більше вільного місця, щоб не створювалося враження громіздкості. Розпізнавання зображень Більшість людей здатні миттєво розпізнавати зорові образи. Розробник моделі може використовувати цю особливість, створюючи діаграми, що відрізняються за формою і конфігурацією. Це дасть змогу легко повертатися до раніше узгодженої моделі та обговорювати її з максимальною продуктивністю. Якщо намалювати кілька різних діаграм однакової конфігурації, то здатність до швидкого відновлення деталей в пам’яті буде втрачено. Текст Тексти мають виключати двозначне тлумачення. Слід уникати скорочень і жаргону. Щоб текст легше читався, більшість написів має розташовуватися горизонтально. Для зручності написи можна розміщувати у кількох рядках. Два імені зв’язку слід розташовувати на протилежних кінцях лінії зв’язку по різні її боки. Центрування і вирівнювання тексту вліво або вправо потрібно здійснювати одноманітно, це значно підвищить якість документів і зручність їх сприйняття. Множинність зв’язку Закінчення зв’язку типу «багато» («пташину лапку») бажано розміщувати ліворуч від лінії зв’язку або над нею. Це поліпшує якість сприйняття моделі та її адекватність. Розміри та форма прямокутників Розміри та форма прямокутників, що зображують сутності, не мають особливого значення, їх можна змінювати — подовжувати, збільшувати або зменшувати 3.2 Приклад аналізу предметної області та розроблення концептуальної моделі. Поставимо задачу розроблення інформаційної системи на замовлення деякої машинобудівної торговельної фірми. ER-діаграми зручні тим, що процес виділення сутностей, атрибутів і зв'язків є ітераційним. Розробивши перший наближений варіант діаграм, ми уточнюємо їх, опитуючи експертів предметної області. При розробленні інформаційної моделі в термінах ER-моделей ми повинні отримати таку інформацію про предметну область: 1. Список сутностей предметної області. 2. Список атрибутів сутностей. 3. Опис взаємозв'язків між сутностями. У першу чергу ми повинні вивчити предметну область і процеси, що відбуваються в ній. Для цього ми опитуємо співробітників фірми, читаємо документацію, вивчаємо форми замовлень, накладних і т.п. Одним словом проводимо аналіз предметної області. У ході бесіди з менеджером у продажах, з'ясовується перелік функцій, які проектована система повинна виконувати: зберігати інформацію про покупців; друкувати накладні на відпущені товари; стежити за наявністю деталей на складі. Виділимо всі іменники в цих реченнях - це будуть потенційні кандидати на сутності й атрибути, і проаналізуємо їх (незрозумілі терміни будемо виділяти знаком питання): Покупець (Client) - явний кандидат на сутність. Накладна (Blank) - явний кандидат на сутність. Товар (Goods) - явний кандидат на сутність. (?)Склад (Sclad) - скільки складів має фірма? Якщо декілька, то це буде кандидатом на нову сутність. (?)Наявність товару – це швидше за все атрибут, але атрибут невідомо якої сутності? Відразу виникає очевидний зв'язок між сутностями - "покупці можуть купувати багато товарів" й "товари можуть продаватися багатьом покупцям". Перший варіант діаграми має такий вигляд: Рисунок 3.1 – Зв'язок між сутностями Client та Goods Припустимо, що фірма має декілька складів. Причому кожен товар може зберігатися на декількох складах і бути проданим з будь-якого складу. Куди помістити сутності "Blank" й "Sclad" і із чим їх пов'язати? Запитаємо себе, як пов'язані ці сутності між собою і з сутностями "Покупець" і "Товар"? Покупці купують товари, одержуючи при цьому накладні, у які внесені дані про кількість і ціну. Кожен покупець може одержати кілька накладних. Кожна накладна зобов'язана виписуватися на одного покупця. Кожна накладна зобов'язана містити кілька товарів (не буває порожніх накладних). Кожен товар, у свою чергу, може бути проданий декільком покупцям через декілька накладних. Крім того, кожна накладна повинна бути виписана з певного складу, і з будь-якого складу може бути виписано багато накладних. Таким чином, після уточнення діаграма буде мати такий вигляд: Рисунок 3.2 – Відображення зв’язків між виділеними сутностями Розглянемо властивості (кандидати в атрибути) сутностей: Кожен покупець є юридичною особою й має найменування, адресу, банківські реквізити. Client Client_Id Client_Name Client_Adress Bank_Date Blank Blank_Id Blank_Data Blank_Sum Blank_Goods Bank_Date Client_Id Goods Goods_Id Goods_Name Current_Price Units Sclad_Id Sclad Sclad_Id Sclad_Name Sclad_Adress Зберігати Зберігатися на Міститись у Містити Отримувати Виписуватись на Кожен товар має найменування, ціну, одиниці виміру. Кожна накладна має унікальний номер, дату виписки, перелік товарів з кількостями й цінами, загальну суму накладної. Накладна виписується з певного складу й на певного покупця. Кожен склад має своє найменування. Випишемо всі іменники, які будуть потенціальними атрибутами: Юридична особа - термін риторичний, ми не працюємо з фізичними особами. Не звертаємо уваги. Найменування покупця (Client_Name) - явна характеристика покупця. Адреса (Adress) - явна характеристика покупця. Банківські реквізити (Bank_Date) - явна характеристика покупця. Найменування товару (Goods_Name) - явна характеристика товару. Одиниця виміру - явна характеристика товару. Номер накладної (Blank_Number) - явна унікальна характеристика накладної. Дата накладної (Blank_Date)- явна характеристика накладної. Сума накладної - явна характеристика накладної. Ця характеристика не є незалежною. Сума накладної дорівнює сумі вартостей усіх товарів, що входять у накладну. Найменування складу (Sclad_Name)- явна характеристика складу. Доповнимо ER-діаграму атрибутами сутностей (див. рис. 3.3), що буде остаточним варіантом інформаційної моделі предметної області. Остання є вхідними даними для розроблення логічної моделі. Рисунок 3.3 – Концептуальна модель в термінах ER-діаграми Client Client_Id Client_Name Client_Adres s Bank_Date Blank Blank_Id Blank_Data Blank_Sum Blank_Goods Bank_Date Client_Id Goods_Amo Goods Goods_Id Goods_Name Current_Pric e Units Sclad_Id Sclad Sclad_Id Sclad_Name Sclad_Adress Зберігати Зберігатися на Міститись у Містити Отримувати Виписуватись на Виписуватись з Виписувати ЗАВДАННЯ Спираючись на теоретичний матеріал, наведений у відповідній лекції, рекомендовану літературу та приклад розробити концептуальну модель згідно із призначеним варіантом. У електронному звіті описати послідовно всі етапи розроблення моделі. А саме: Аналіз предметної області. Визначення сутностей Визначення атрибутів сутностей Визначення унікальних ідентифікаторів сутностей Встановлення зв’язків між сутностями. Документування концептуальної моделі в термінах ER-діаграми. Оформлений звіт надіслати викладачу на перевірку. Таблиця 3.1 – Варіанти завдання Номер варіанту Предметна область Вимоги 1 Автотранспорт Створити базу даних облікуздійснених автотранспортних послуг. Спроектована база даних повинна обов’язково надати користувачеві таку інформацію: по залучених у транспортних послугах автомобілях, по водіям; безпосередньо по транспортним послугам. 2 Транспортна логістика Створити базу данихоблікувідвантаження й одержання продукції. Спроектована база даних повинна обов’язково надати користувачеві таку інформацію: по транспортним засобам; типам вантажів; по рейсам; по поставкам. 3 ДАІ Створити базу данихоблікупорушень правил дорожнього руху. Спроектована база даних повинна надати користувачеві наступну інформацію: по автомобілях; по водіям; відомості про порушників. 4 Транспортна логістика Створити базу даних обліку виконаних транспортних послуг. Спроектована база даних повинна надати користувачеві наступну інформацію: по транспорту; по заявкам; по доставкам. 5 Автосервіс Створити базу даних обліку зроблених послуг автомайстерні. Спроектована база даних повинна надати користувачеві інформацію: по залучених у послугах автомобілях; по автомеханікам; по обслуговуванню. Номер варіанту Предметна область Вимоги 6 Міський транспорт Створити базу даних ведення звітності по роботі міського транспорту. Спроектована база даних повинна надати користувачеві наступну інформацію: по автотранспорту; по маршрутам; по рейсам. 7 Автосалон Створити базу даних організації закупівлі запасних частин і комплектуючих. Спроектована база даних повинна надати користувачеві наступну інформацію: по запчастинам і комплектуючим; по постачальникам; по закупкам. 8 Автосалон Створити базу даних обліку реалізованих авто. Спроектована база даних повинна надати користувачеві наступну інформацію: по автомобілях; по постачальникам; по реалізаціям. 9 Деканат вузу. Створити базу данихведення звітності щодо іспитів і заліків.Спроектована база даних повинна надати користувачеві наступну інформацію: по групам; по дисциплінам, що викладаються; по складанням. 10 Деканат вузу Створити базу даних ведення особистих справ студентів. Спроектована база даних повинна надати користувачеві наступну інформацію: по студентам; по групам; по стипендії. РЕКОМЕНДОВАНА ЛІТЕРАТУРА 1 К. Дж. Кейт Введення в системи баз даних Пер. с англ. 8-е изд. М.: Издательский дом «Вильямс», 2006.– 1328 С. 2 Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная модель данных: Учебное пособие/Изд-е Башкирского ун- та. - Уфа, 1999. - 108 с. 3 Томас Коннолли, Каролин Бегг. Базы данных. Проектирование, реализация и сопровождение. Теория и практика.– 3-е изд. М.: Издательский дом «Вильямс», 2003, 1436 с. 4 Джен Л. Харрингтон Проектирование реляционных баз данных — М.: Издательство «Лори», 2006 – 230 с. 5 Пасічник В.В.Організація баз даних та знань: підручник для ВНЗ/ В.В. Пасічник, В.А. Резніченко.– К.: Видавнича група BHV,2006.-384с. 6 В.Е. Туманов. Основы проектирования реляционных баз данных – http://www.intuit.ru 7 Д.В. Кознов. Визуальное моделирование: теория и практика – http://www.intuit.ru |