Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Концептуальне моделювання за допомогою моделі "сутність-зв’язок".
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Системи автоматизованого проектуваня
Інформація про роботу
Рік:
2004
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Основи автоматизованого проектування складних об’єктів і систем
Частина тексту файла (без зображень, графіків і формул):
МIНIСТЕРСТВО ОСВIТИ І НАУКИ УКРАЇНИ
Національний унiверситет "Львiвська полiтехнiка"
Концептуальне моделювання за допомогою моделі "сутність-зв’язок".
МЕТОДИЧНІ ВКАЗІВКИ
до лабораторної роботи № 4
з курсу "Основи автоматизованого проектування складних об’єктів і систем"
для студентiв базового напрямку 6.0804
"Комп'ютернi науки"
Затверджено на засiданнi кафедри Системи автоматизованого проектування"
Протокол N 1 вiд 27.08.2004р.
Львiв 2004
Концептуальне моделювання за допомогою моделі "сутність-зв’язок".
Методичні вказівки до лабораторної роботи №1 з курсу “Основи автоматизованого проектування складних об`єктів і систем” для студентiв базового напрямку 6.0804 - "Комп'ютернi науки" / Укл. А.Б.Керницький - Львiв: НУ “ЛП”, 2004. - 13с.
Укладач: А.Б.Керницький, др.–інж.т.н.
Вiдповiдальний за випуск С.П.Ткаченко, канд.техн.наук, доц.
Рецензенти: Ю.В.Стех, канд.техн.наук, доц.
I.I.Мотика, канд.техн.наук, доц.
1. МЕТА РОБОТИ
Мета роботи – ознайомититися з основними властивостями мереж Петрі..
2. КОРОТКІ ТЕОРЕТИЧНI ВIДОМОСТI
1.1 Призначення сутнісної моделі.
Перш, ніж приступати до створення системи автоматизованої обробки інформації, розробник повинен сформувати поняття про предмети, факти і події, якими оперуватиме розроблювана система. Для того, щоб представлення ці поняття до однієї або іншої моделі даних, необхідно замінити їх інформаційними представленнями. Одним із найзручніших інструментів уніфікованого представлення даних, незалежного програмного забезпечення яке його реалізує, є модель "сутність-зв’язок (entity - relationship model, ER - model).
Призначення сутнісної моделі — у компактному і не створюючому різночитань представленні описати структуру предметної області. У даному випадку під структурою предметної області розуміється набір понять (об'єктів) предметної області і зв'язків між цими поняттями (об'єктами).
Зауваження 1.1 Модель сутність-зв'язок не є моделлю даних оскільки не визначає операцій над даними і обмежується описом лише їхньої логічної структури.
Модель "сутність-зв'язок була запропонована в 1976 р. Ченом (Chen) і отримала подальший розвиток у роботах Баркера (Barker). Нотація Чена надає багатий набір засобів моделювання даних, включаючи власне ERD, а також діаграми атрибутів і діаграми декомпозиції.
1.2 Ступінь точності сутнісної моделі
Критерієм виявлення "достатньої глибини" опису предметної області, тобто "значущості" концептуальних понять і/або фізичних об'єктів (основний/не основний), є критерій точності, що висувається до проектованої системи. Зв'язок між "глибиною" опису і критерієм точності лінійний: чим вищим є критерій точності, тим більша глибина опису, отже, тим вища відповідність сутнісної моделі і предметної області.
Під критерім точності розуміється ступінь адекватності (точність) сутнісної моделі і предметної області, описуваною цією моделлю. Отже критерій точності, що пред'являється до проектованої системи, найефективныше все працює на етапі сутнісного моделювання.
У процесі проектування і розробки інформаційної системи мають місце два види факторів, які впливають на критерій точності, — це технічні і політичні фактори.
До технічних факторів звичайно відносять:
Функціональні і технічні вимоги до проектованої системи; технічні вимоги, такі як тимчасові і кількісні обмеження; або функціональні вимоги, такі як обмеження точності.
Досвід фахівця, задіяного у проектування системи: чим вище досвід, тим "відчуття" достатньої адекватності проектованої моделі і предметної області.
Зауваження 1.2 Предметна область є частиною довкілля і тому носить аналоговий характер: повністю завершити процес декомпозиції фізичних об'єктів або концептуальних понять, як правило, не представляється можливим. Але, головне, подібна гіпердекомпозиція не має практичного сенсу, оскільки у результаті уточнення моделі зведеться до опису настільки дрібних об'єктів, що модель втратить свій первинний смисл — бути компактною.
До політичних факторів звичайно відносять:
Планований життєвий цикл (ЖЦ) проектованої системи: тривалість і траєкторія планованого ЖЦ напряму визначається планами компанії відносно проектованої системи, що у свою чергу впливає на характер бюджету проекту.
Бюджет проекту, який має три складові: людські, часові і фінансові ресурси; бюджет проекту значно впливає на величину критерію точності.
На величину критерію точності нелінійно впливають всі вищеперелічені фактори: збільшення кількості якого-небудь з них, як правило, підвищує критерій точності і навпаки, зменшення — знижує його, а підвищення критерію точності до проектованої системи автоматично тягне за собою підвищення витрат на розробку. Виходячи з цього можна констатувати нелінійний зв'язок між підвищенням критерію точності і вартістю розробки: зростання витрат перевищує зростання критерію точності.
Характер зв'язку між вартістю розробки і критерієм точності у загальному випадку формально визначити не вдалося, але, як правило, в експертних оцінках різних методологів мовиться про експоненціальний характер даного зв'язку.
1.3 Елементи моделі.
Будь-який фрагмент предметної області може бути представлений як множина сутностей, між якими існує певна множина зв'язків.
ER-діаграма предметної області представляється множиною сутностей, атрибутів та зв’язків. Елементи кожної з цих множин представляються вузлами графа для яких ми використовуємо спеціальні форми для визначення їхнього виду:
Множина сутностей представляється прямокутниками.
Атрибути представляються овалами.
Зв’язки представляються ромбами.
Приклад 1.1 На Рис.2.1 представлена ER-діаграма, яка зображає просту базу даних про працівників. Набори сутностей - це Працівник, Посада і Відділ.
Рис. 2.1 Діаграма сутність-зв’язок для бази даних працівників
Визначення 1.1 Сутність (entity) є безліччю множин реальних або абстрактних об'єктів (людей, подій, станів, ідей, предметів тощо), що володіють загальними атрибутами або характеристиками. Будь-який об'єкт системи може бути представлений лише однією сутністю, яка повинна бути унікально ідентифікована. При цьому ім'я сутності повинне відображати тип або клас об'єкту, а не його конкретний екземпляр (наприклад, МІСТО, а не ЛЬВІВ).
Визначення 1.2 Набір сутностей (entity set) - множина сутностей одного типу (володіють однаковими властивостями). Приклади: всі люди, підприємства, свята тощо. Набори сутностей не обов'язково повинні не перетинатися. Наприклад, сутність, що належить до набору ЧОЛОВІКИ, також належить набору ЛЮДИ.
Сутність фактично представляє з себе безліч атрибутів, які описують властивості всіх членів даного набору сутностей.
Приклад 1.2 Розглянемо множину співробітників певного відділу. Кожного працівника можна описати за допомогою характеристик табельний номер, прізвище, вік. Тому сутність ПРАЦІВНИК має атрибути ТАБЕЛЬНИЙ_НОМЕР, ПРІЗВИЩЕ, ВІК. Використовуючи нотацію мови Pascal цей факт можна представити наступним чином:
type employe = record
number : string[6];
name : string[50];
age : integer;
end;
Надалі для визначення сутності та її атрибутів використовуватимемо позначення наступного вигляду:
ПРАЦІВНИК (ТАБЕЛЬНИЙ_НОМЕР, ПРІЗВИЩЕ, ВІК).
Визначення 1.3 Множина значень (область визначення) атрибута називається доменом. Наприклад, для атрибута ВІК домен (назвемо його КІЛЬКІСТЬ_РОКІВ) задається інтервалом цілих чисел більших за нуль, оскільки людей з від’ємним віком не буває.
Визначення 1.4 Звідси визначається ключ сутності - група атрибутів, така, що відображення набору сутностей у відповідну групу наборів значень є взаємооднозначним відображенням. Іншими словами: ключ сутності - це один або більше атрибутів які унікально визначають дану сутність. У нашому випадку ключем сутності СПІВРОБІТНИК є атрибут ТАБЕЛЬНИЙ_НОМЕР (звичайно, лише у тому випадку, якщо всі табельні номери на підприємстві унікальні).
Визначення 1.5 Зв'язок (relationship) - це асоціація, встановлена між декількома сутностями.
Приклад 1.3:
оскільки кожний співробітник працює у якому-небудь відділі, між сутностями СПІВРОБІТНИК і ВІДДІЛ існує зв'язок "працює в" або ВІДДІЛ-ПРАЦІВНИК;
оскільки один з працівників відділу є його керівником, то між сутностями СПІВРОБІТНИК і ВІДДІЛ існує зв'язок "керує" або ВІДДІЛ-КЕРІВНИК;
можуть існувати і зв'язки між сутностями одного типу, наприклад зв'язок БАТЬКО - НАЩАДОК між двома сутностями ЛЮДИНА;
Зауваження 1.3 У методиці проектування баз даних є своєрідне правило хорошого тону, згідно з яким сутності позначаються за допомогою іменників, а зв'язки - дієслівними формами.
Зв'язок може мати атрибути. Наприклад, для зв'язку ВІДДІЛ-ПРАЦІВНИК можна задати атрибут СТАЖ_РОБОТИ_У_ВІДДІЛІ.
Визначення 1.6 Роль сутності у зв'язку - функція, яку виконує сутність у даному зв'язку. Наприклад, у зв'язку БАТЬКО-НАЩАДОК сутність ЛЮДИНА може мати ролі "батько" і "нащадок". Вказання ролей у моделі "сутність-зв'язок не є обов'язковою і служить для уточнення семантики зв'язку.
Візначення 1.7 Набір зв'язків (relationship set) - це відношення між n (причому n не менше 2) сутностями, кожна з яких відноситься до деякого набору сутностей.
Приклад 1.4
сутність набори сутностей
---------- ----------------
t1 належить T1
t2 належить T2
. . .
tn належить Tn
тоді [t1,t2...,tn] - набір зв'язків R
Поняття "зв'язок" і "набір зв'язків" різні (перша є елементом другого), їх, проте, часто вживають для позначення одного і того самого. Не претендуючи на академічну строгість, надалі також часто користуватимемося термінами "зв'язок" маючи на увазі "набір зв'язків" і "сутність" маючи на увазі "набір сутностей".
У випадку n=2, тобто коли зв'язок об'єднує дві сутності, він називається бінарним. Доведено, що n-арний набір зв'язків (n>2) завжди можна замінити безліччю бінарних, проте перші краще відображають семантику предметної області.
Визначення 1.8 Кількість сутностей, які можна асоціювати через набір зв'язків з іншим сутностями, називають степінню зв'язку.
Розгляд степенів особливо корисно для бінарних зв'язків. Можуть існувати наступні степені бінарних зв'язків:
один до одного (позначається 1:1). Це означає, що в такому зв'язку сутності з однією роллю завжди відповідає не більше однієї сутності з іншою роллю. У розглянутому прикладі це зв'язок "керує", оскільки у кожному відділі може бути лише один начальник, а співробітник може керувати лише в одному відділі. Даний факт представлений на наступному рисунке, де прямокутники позначають сутності, а ромб - зв'язок. Оскільки степінь зв'язку для кожної сутності дорівнює 1, то вони з'єднуються однією лінією.
Іншою важливою характеристикою зв'язку крім його степені є клас належності сутностей які до нього входять. Оскільки у кожному відділі обов'язково повинен бути керівник, то кожній сутності "ВІДДІЛ" неодмінно повинна відповідати сутність "СПІВРОБІТНИК". Проте, не кожний співробітник є керівником відділу, відповідно у даному зв'язку не кожна сутність "СПІВРОБІТНИК" має асоційовану з нею сутність "ВІДДІЛ".
Таким чином, говорять, що сутність "СПІВРОБІТНИК" має обов'язковий клас належності (цей факт є також вказівкою інтервалу кількості можливих входжень сутності у зв'язок, у даному випадку це 1,1), а сутність "ВІДДІЛ" має необов'язковий клас належності (0,1). Тепер даний зв'язок ми можемо описати як 0,1:1,1. Надалі клас належності бінарних зв'язків степены 1 будемо позначати наступним чином:
INCLUDEPICTURE "../../2004-10-01/toc/Модель%20сущность-связь_files/r5.gif" \* MERGEFORMATINET
один до багатьох (1:n). У даному випадку сутності з однією роллю може відповідати будь-яка кількість сутностей з іншою роллю. Таким є зв'язок ВІДДІЛ-СПІВРОБІТНИК. У кожному відділі може працювати довільна кількість співробітників, але співробітник може працювати лише в одному відділі. Графічно степінь зв'язку n відображається "деревоподібною” лінією, як це зроблено на наступному рисунку.
Даний рисунок додатково ілюструє той факт, що між двома сутностями може бути визначено декілька наборів зв'язків.
Тут також необхідно враховувати клас належності сутностей. Кожний співробітник повинен працювати у якому-небудь відділі, але не обов’язково кожний відділ (наприклад, щойно сформований) повинен включати хоча б одного співробітника. Тому сутність "ВІДДІЛ" має обов'язковий, а сутність "СПІВРОБІТНИК" необов'язковий класи належності. Степінь зв’язку бінарних зв'язків степені n будемо позначати наступним чином:
INCLUDEPICTURE "../../2004-10-01/toc/Модель%20сущность-связь_files/r6.gif" \* MERGEFORMATINET
багато до одного (n:1). Цей зв'язок аналогічний відображенню 1:n. Припустимо, що представлення нами підприємство будує свою діяльність на підставі контрактів, що підприємство, яке ми розглядаємо, будує свою діяльність на основі контрактів, які укладаються із замовниками. Цей факт відображається у моделі "сутність-зв'язок за допомогою зв'язку КОНТРАКТ-замовник, який об'єднує сутності КОНТРАКТ(НОМЕР, ТЕРМІН_ВИКОНАННЯ, СУМА) і ЗАМОВНИК(НАЗВА, АДРЕСА). Оскільки з одним замовником може бути укладено більше одного контракту, то зв'язок КОНТРАКТ-замовник між цими сутностями матиме степінь n:1.
У даному випадку, по представлення очевидних міркуваннях (кожний контракт укладений представлення конкретним замовником, а кожний замовник має хоча б один контракт, інакше він не був би таким), кожне представлення має обов'язковий клас приналежності.
багато до багатьох (n:n). У цьому випадку кожне з асоційованих сутностей може бути представлена будь-якою кількістю екземплярів. Нехай на підприємстві для виконання кожного контракту створюється робоча група, у яку входять співробітники різних відділів. Оскільки кожний співробітник може входити в кілька (у тому числі і в жодну) робочих груп, а кожна група повинна включати не менше одного співробітника, то зв'язок між сутностями СПІВРОБІТНИК і РОБОЧА_ГРУПА має степінь n:n.
Візначення 1.9 Якщо існування сутності x залежить від існування сутності у, то x називається залежною сутністю (інколи сутність x називають "слабкою", а сутність у – “сильною”).
Приклад 1.5 Розглянемо зв'язок між раніше описаними сутностями РОБОЧА_ГРУПА і КОНТРАКТ. Робоча група створюється лише після того, як буде підписаний контракт із замовником, і припиняє своє існування по виконанню контракту. Таким чином, сутність РОБОЧА_ГРУПА є залежною від сутності КОНТРАКТ. Залежна сутність позначається подвійним прямокутником, а її зв'язок із сильною сутністю лінією із стрілкою:
Зауваження 1.4 Степінь зв'язку для сильної сутності завжди буде (1,1). Клас належності і степінь зв'язку для залежної сутності можуть бути будь-якими. Припустимо, наприклад, що розглянуте нами підприємство користується декількома банківськими кредитами, які представляються набором сутностей КРЕДИТ(НОМЕР_ДОГОВОРА, СУМА, ТЕРМІН_ПОГАШЕННЯ, БАНК). По кожному кредиту повинні здійснюватися виплати процентів і платежі у рахунок його погашення. Цей факт представляється набором сутностей ПЛАТІЖ(ДАТА, СУМА) і набором зв'язків "здійснюється по". У тому випадку, коли отримання запланованого кредиту відміняється, інформація про нього повинна бути видалена з бази даних. Відповідно, повинні бути видалені і всі відомості про планові платежі по цьому кредиту. Таким чином, сутність ПЛАТІЖ залежить від сутності КРЕДИТ.
1.4. Категоризація сутності
Сутність може бути розділена і представлена у вигляді двох або більше сутностей-категорій, кожна з яких має загальні атрибути і/або відносини, які визначаються одноразово на верхньому рівні і наслідуються на нижньому. Сутності-категорії можуть мати і свої власні атрибути і/або відносини, а також, у свою чергу, можуть бути декомпоновані своїми сутностями-категоріями на наступному рівні. Розщеплювана на категорії сутність отримала назву загальної сутності (зауважимо, що на проміжних рівнях декомпозиції одна і та ж сутність може бути як загальною сутністю, так і сутністю-категорією).
Для демонстрації декомпозиції сутностей на категорії використовуються діаграми категоризації. Така діаграма містить загальну сутність, дві і більше сутностей-категорій і спеціальний вузол-дискримінатор, який описує способи декомпозиції сутності (див. Рис. 5.4).
Рис. 5.4. Діаграма категоризації
Існує 4 можливі типи дискримінаторів (рис.5.5):
Повне і обов'язкове входження E/M (exclusive/mandatory) – сутність повинна бути однією і лише однією з випливаючих категорій. Для прикладу на рис. 5.4 це означає, що ВИКЛАДАЧЕМ є ФІЗИК, або ХІМІК, або МАТЕМАТИК.
Повне і необов'язкове входження E/O (exclusive/optional) - сутність може бути однією і лише однією з випливаючих категорій. Це означає, що ВИКЛАДАЧЕМ є ФІЗИК, або ХІМІК, або МАТЕМАТИК, або викладач якої-небудь іншої дисципліни (наприклад, ІСТОРИК).
Неповне і обов'язкове входження I/M (inclusive/mandatory) - сутність повинна бути принаймні однією з випливаючих категорій. Це передбачає у доповнення до 1) задавати наступну ситуацію: ВИКЛАДАЧЕМ є одночасно і ФІЗИК і ХІМІК.
Неповне і необов'язкове входження I/O (inclusive/optional) - сутність може бути принаймні однією з випливаючих категорій. У доповнення до 2) ВИКЛАДАЧЕМ є викладач якої-небудь іншої дисципліни (наприклад, ІСТОРИК).
INCLUDEPICTURE "../er/Interface%20Ltd_files/defs5_files/defs5_5.gif" \* MERGEFORMATINET
Рис 5.5. Типи дискримінаторів.
1.5. Побудова моделі
Дуже важливою властивістю моделі "сутність-зв'язок є те, що вона може бути представлена у вигляді графічної схеми. Це значно полегшує аналіз предметної області. Існує декілька варіантів позначення елементів діаграми " сутність -зв'язок, кожний з яких має свої позитивні риси. Ми використовуватимемо певний гібрид нотацій Чена (позначення представлення, зв'язків і атрибутів) і Мартіна (позначення степенів і класу належності зв’язків).
У процесі побудови діаграми можна виділити декілька очевидних етапів:
Ідентифікація сутностей і зв'язків, які викликають інтерес.
Ідентифікація семантичної інформації у наборах зв'язків (наприклад, чи є деякий набір зв'язків відображенням 1:n).
Визначення класу належності зв'язків.
Визначення атрибутів і наборів їх значень (доменів).
Організація даних у вигляді відношень "сутність-зв'язок.
Як приклад розглянемо діаграму, яка відображає зв'язок даних для підсистеми обліку персоналу підприємства.
Перший етап є визначальним при побудові моделі, його початковою інформацією виступає вміст сховищ даних, який визначається його вхідними та вихідними потоками даних.
Виділяються сутності і зв'язки, які нас цікавлять:
Перш за все підприємство складається з відділів, у яких працюють співробітники. Оклад кожного співробітника залежить від посади яку той займає (інженер, провідний інженер, бухгалтер, прибиральник тощо). Далі припустимо, що на нашому підприємстві допускається суміщення посад, тобто кожний співробітник може мати більше ніж одну посаду (і працювати більше ніж в одному відділі), причому може займати неповну ставку. У той же час, одну і ту ж посаду можуть займати одночасно декілька співробітників. У результаты цих міркувань ми повинні ввести набори сутностей
ВІДДІЛ(НАЗВА_ВІДДІЛУ)
СПІВРОБІТНИК(ТАБЕЛЬНИЙ_НОМЕР, ІМ'Я)
ПОСАДА(ІМ’Я_ПОСАДИ, ОКЛАД)
і набір зв'язків ПРАЦЮЄ_В із атрибутом ставка між ними. Атрибут ставка може приймати значення з інтервалу ]0,1] (більше нуля, але менше або дорівнює одиниці), він визначає яку частину посадового окладу отримує даний співробітник.
Як уже наголошувалося, кожний n-арний набір зв'язків можна замінити декількома бінарними наборами. Розглянемо переваги кожного з цих способів представлення зв'язків.
Тренарний зв'язок, показаний тут, безумовно несе повнішу інформацію про предметну область. Дійсно, вона однозначно відображає той факт, що оклад співробітника залежить від його посади, відділу, де він працює і ставки. Проте, у цьому випадку виникають деякі проблеми із визначенням степені зв'язку. Хоча, як було сказано, кожний працівник може займати декілька посад, а у штаті кожного відділу існують вакансії із різними посадами, проте клас належності сутності ПОСАДА на наведеному рисунку встановлений у (1,1). Це пояснюється тим, що ПОСАДА асоціюється фактично не з сутностями СПІВРОБІТНИК і ВІДДІЛ, а із зв'язком між ними. Цей факт позначається так, як це зображено на наступній діаграмі:
Тут сутності СПІВРОБІТНИК, ВІДДІЛ і зв'язок ПРАЦЮЄ_В агрегуються у деяку нову абстрактну сутність, яка асоціюється із сутністю ПОСАДА за допомогою зв'язку степені n:1.
Відобразимо асоціації співробітників, відділів і посад за допомогою бінарних зв'язків.
INCLUDEPICTURE "../../2004-10-01/toc/Диаграмма%20сущность-связь_files/binary.gif" \* MERGEFORMATINET
У цому випадку для адекватного опису семантики предметної області необхідно ввести ще одне сутність ШТАТНА_ОДИНИЦЯ, яка фактично замінює собою зв'язок ПРАЦЮЄ_В в абстрактній сутності і тому має атрибут ставка.
Перехід від n-арного зв'язку через аггрегацию сутностей до набору бінарних зв'язків можна розглядати як послідовні етапи одного процесу, який приволить до однозначного породження реляційної моделі даних. При побудові діаграми "сутність-зв'язок" можна використовувати будь-який з цих трьох способів представлення даних.
Перерахуємо низку об'єктів, які описані вище і будуть корисними під час моделювання даних вибраного підприємства. Їм відповідають наступні сутності:
ЗАМОВНИК(ІМ’Я_ ЗАМОВНИКА,АДРЕСА)
КОНТРАКТ(НОМЕР,ТЕРМІН_ПОЧАТКУ, ТЕРМІН _ЗАВЕРШЕННЯ,СУМА)
РОБОЧА ГРУПА(ПРОЦЕНТ_ВИНАГОРОДИ)
Атрибут "процент_винагороди" відображає ту частку вартості контракту, яка призначена для оплати праці членів відповідної робочої групи. Зміст решти атрибутів зрозумілий без додаткових пояснень. Зв'язки між перерахованими сутностями також описані вище
Як правило, один із членів робочої групи є керівником по відношенню до інших співробітників, що входять до її складу. Для відображення цього факту необхідно ввести зв'язок "керує" із класои належності 1,1:0,n між сутностями СПІВРОБІТНИК і РОБОЧА_ГРУПА (співробітник може керувати у довільній кількості робочих груп, але кожна робоча група має одного і лише одного керівника).
Розглянемо уважніше інформаційний об'єкт "замовник". На практиці дуже часто виникає необхідність розрізняти національну приналежність юридичних осіб, із якими підприємство вступає у договірні відносини. Це пов’язано із тим, що для зарубіжних фірм необхідно зберігати, наприклад, інформацію про валюту, у якій здійснюються розрахунки, мову, на якій підписана угода тощо. У свою чергу, для українських компаній необхідно мати відомості про їхню форму власності (приватна або державна), оскільки від цього може залежати порядок оподаткування засобів, отриманих за виконання робіт за контрактом.
Таким чином, ми приходимо до висновку, що необхідно ввести ще дві множини, які не перетинаються, ЗАРУБІЖНЕ_ПІДПРИЄМСТВО(ВАЛЮТА, МОВА) і УКРАЇНСЬКЕ_ПІДПРИЄМСТВО(ФОРМА_ВЛАСНОСТІ), об'єднання яких складає повну сутність ЗАМОВНИК. Асоціацію між цими об'єктами називають відношенням наслідування або ієрархічним зв'язком, оскільки сутність ЗАРУБІЖНЕ_ПІДПРИЄМСТВО і УКРАЇНСЬКЕ_ПІДПРИЄМСТВО наслідують атрибути сутності ЗАМОВНИК(ІМ’Я_ ЗАМОВНИКА,АДРЕСА)
Для того, щоб визначити до якої підмножини відноситься конкретна сутність з набору ЗАМОВНИК (і, відповідно, який набір атрибутів вона має) необхідно ввести атрибут "національна приналежність", який називається дискримінантом. Цей тип зв'язку відображається на діаграмі наступним чином:
INCLUDEPICTURE "../../2004-10-01/toc/Диаграмма%20сущность-связь_files/ieralink.gif" \* MERGEFORMATINET
Узагальнюючи всі проведені вище міркування, отримуємо діаграму "сутність-зв'язок, яка показана на наступному рисунку.
INCLUDEPICTURE "../../2004-10-01/toc/Диаграмма%20сущность-связь_files/er.gif" \* MERGEFORMATINET
Контрольні запитання
1. Для чого будується ER- діаграма?
2. Дайте визначення компонентів ER – моделі.
3.У чому відмінність сутності від поняття?
4. Які властивості називають ключовими?
5. Якому компоненту ER - діаграми відповідає поняття?
6. Що таке домен і як він описується?
7. Які із перерахованих термінів є синонімами: зв'язок, поняття, атрибут, клас сутностей, сутність, відношення, екземпляр відношення, екземпляр сутності, властивість?
8. Які види зв'язків можуть бути між поняттями?
9. Які зв'язки називають бінарними?
10. Наведіть приклад не бінарного відношення між поняттями і покажіть, як його представити у вигляді декількох бінарних зв'язків.
11. Як зміниться діаграма "сутність-зв'язок" у тому випадку, якщо процент винагороди по всіх контрактах буде однаковий?
12. Що зміниться у діаграмі, якщо буде заборонено сумісництво посад, тобто кожний співробітник матиме право займати лише одну посаду із ставкою 1?
4. ЛАБОРАТОРНЕ ЗАВДАННЯ
1
Примітка: Індивідуальний варіант задається викладачем.
5. ЗМІСТ ЗВІТУ
Мета роботи.
Теоретичний аналіз опрацьованого матеріалу.
Відповіді на контрольні запитання.
Індивідуальне завдання.
Аналіз отриманих результатів і висновки.
Список використаної літератури.
6. СПИСОК ЛІТЕРАТУРИ
Abrial, J.R. Data semantics. In Data Base Management, J.W. Klimbie and K.L. Koffeman, Eds.,North-Holland Pub. Co., Amsterdam, 1974, pp. 1-60.
Bachman, C.W. Software for random access processing. Datamation 11 (April 1965), 36-41.
Bachman, C.W. Data structure diagrams. Data Base 1,2 (Summer 1969), 4-10.
Bachman, C.W. Trends in database management - 1975. Proc., AFIPS 1975 NCC, Vol.44, AFIPS Press, Montvale, N.J., pp. 569-576.
Birkhoff, G., and Bartee, T.C. Modern Applied Algebra. McGraw-Hill, New York, 1970.
Chamberlin, D.D., and Raymond, F.B. SEQUEL: A structured English query language. Proc. ACM-SIGMOD 1974, Workshop, Ann Arbor, Michigan, May, 1974.
CODASYL. Data base task group report. ACM, New York, 1971.
Codd, E.F. A relational model of data for large shared data banks. Comm. ACM 13,6 (June 1970), 377-387.
Codd, E.F. Normalized data base structure: a brief tutorial. Proc. ACM-SIGFIDET 1971, Workshop, San Diego, Calif., Nov. 1971, pp. 1-18.
Codd, E.F. A data base sublanguage founded on the relational calculus. Proc. ACM-SIGFIDET 1971, Workshop, San Diego, Calif., Nov. 1971, pp. 35-68.
Codd, E.F. Recent investigations in relational data base systems . Proc. IFIP Congress 1974, North-Holland Pub. Co., Amsterdam, pp. 1017-1021.
Deheneffe, C., Hennebert, H., and Paulus, W. Relational model for data base. Proc. IFIP Congress 1974, North-Holland Pub. Co., Amsterdam, pp.1022-1025.
Dodd, G.G. APL - a language for associate data handling in PL/I. Proc. AFIPS 1966 FGCC, Vol. 29, Spartan Books, New York, pp. 677-684.
Eswaran, K.P. and Chamberlin, D.D. Functional specifications of a subsystem for data base integrity. Proc. Very Large Data Base Conf., Framingham, Mass., Sept. 1975, pp. 48-68.
Hainaut, J.L. and Lecharlier, B. An extensible semantic model of data base and its data language. Proc. IFIP Congress 1974, North-Holland Pub. Co., Amsterdam, pp. 1026-1030.
Hammer, M.M., and McLeod, D.J. Semantic integrity in a relation data base system. Proc. Very Large Data Base Conf., Framingham, Mass., Sept. 1975, pp.25-47.
Lindgreen, P. Basic operations on information as a basis for data base design. Proc. IFIP Congress 1974, North-Holland Pub. Co., Amsterdam, pp.993-997.
Mealy, G.H. Another look at data base. Proc. AFIPS 1967 FJCC, Vol. 31, AFIPS Press, Montvale, N.J., pp. 525-534.
Nijssen, G.M. Data structuring in the DDL and the relational model. In Data Base Management, J.W. Klimbie and K.L. Koffeman, Eds., North-Holland Pub. Co., Amsterdam, 1974, pp. 363-379.
Olle, T.W. Current and future trends in data base management systems. Proc. IFIP Congress 1974, North-Holland Pub. Co., Amsterdam, pp. 998-1006.
Roussopoulos, N., and Mylopoulos, J. Using semantic networks for data base management. Proc. Very Large Data Base Conf., Framingham, Mass., Sept. 1975, pp. 144-172.
Rustin, R. (Ed.). Proc. ACM-SIGMOD 1974 - debate on data models. Ann Arbor, Mich., May 1974.
Schmid, H.A., and Swenson. J.R. On the semantic of the relational model. Proc. ACM-SIGMOD 1975, Conference, San Jose, Calif., May 1975, pp.211-233.
Senko, M.E. Data description language in the concept of multilevel structured description: DIAM II with FORAL. In Data Base Description, B.C.M. Dougue, and G.M. Nijssen, Eds., North-Holland Pub. Co., Amsterdam, pp.239-258.
НАВЧАЛЬНЕ ВИДАННЯ
Концептуальне моделювання за допомогою моделі "сутність-зв’язок".
Методичні вказівки
до лабораторної роботи № 4
з курсу “Основи автоматизованого проектування складних об`єктів і систем”
для студентiв базового напрямку 6.0804 - "Комп'ютернi науки"
Укладач Керницький Андрій Богданович
Редактор Черничевич О.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора