Проектування реалізації бази даних

⇐ ПредыдущаяСтр 6 из 6

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

Формулювання СУБД - орієнтованої логічної структури, або даталогічної концептуальної моделі БД. На цьому етапі виконується перетворення інфологічної моделі ПС на даталогічну модель.

Наявність зв'язків між сутностями типу М:М дає змогу подати ER-діаграму у вигляді складної мережної моделі даних, показаної на рис. 30.

Для усунення зв'язку типу М:М у модель даних вводять додаткові записи. Дані перетину, що належать обом типам сутностей, будуть атрибутами додаткових записів. Завдяки цьому складна мережа зводиться до простої мережної моделі. На рис. 31 зображено даталогічну просту мережну модель даних. У цій моделі кожній сутності відповідає окремий запис. Крім того, наявні записи-зв'язки “Замовлення” та “Ціна-знижка”. В моделі відсутня залежність від шляху, кожен запис є автономним і може бути поданий як елемент реляційної даталогічної моделі даних.

Здобуту даталогічну модель даних слід проаналізувати на наявність відношень, що потребують нормалізації. Відношення “Постачальник” має первинний ключ “Код фірми-постачальника” й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: “Назва фірми”, “Адреса фірми”. Обидві ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв’язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення “Товар” має первинний ключ “Код товару” й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: “Назва товару”, “Параметр 1”, “Параметр 2”, “Параметр 3”, “Параметр 4”. Обидві ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв’язки між атрибутами відсутні. Відношення є такими, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення “Ціна - знижка” знаходиться в першій нормальній формі. Непервинний атрибут “Знижка” залежить від складного ключа “Код товару + Код фірми – постачальника + Кількість, що зумовлює знижку”, непервинний атрибут “Ціна” - від частини цього ключа “Код товару + Код фірми - постачальника”. У цьому випадку порушено вимогу другої нормальної форми про повну функціональну залежність непервинних атрибутів від будь-якого можливого ключа. Під час роботи з цим відношенням можуть виникати аномалії операцій включення, вилучення і редагування даних. Наприклад, поки не буде внесений розмір знижки на замовлення, не можна вносити інформацію про ціну товару. При вилученні єдиного запису з певною знижкою буде вилучена інформація про ціну товару постачальника. Такі самі проблеми виникають при редагуванні даних. Тому треба виконати проеціювання цього відношення.

Рис. 30. Даталогічна складна мережна модель даних

Перша проекція — відношення ЦІНА (Код товару, Код фірми-постачальника, Ціна) має первинний ключ “Код товару + Код фірми-постачальника” і непервинний атрибут “Ціна”, що функціонально повно і нетранзитивно залежить від ключа.

Друга проекція — відношення ЗНИЖКА (Код товару, Код фірми-постачальника, Кількість/знижка, Знижка) має первинний ключ “Код товару + Код фірми-постачальника + Кількість/знижка” і непервинний атрибут “Знижка”, що функціонально повно і нетранзитивно залежить від ключа.

Здобуті відношення “Ціна” і “ЗНИЖКА” знаходяться у другій і третій нормальних формах. Інші ключові детермінанти, крім первинних ключів, у них відсутні. Тому обидва відношення знаходяться у посиленій третій нормальній формі. У цих відношеннях відсутні множинні зв’язки між групами даних. Відношення “ЦІНА” та “ЗНИЖКА” є такими, що не зводяться, і позбавлені аномалій включення, вилучення, редагування.

Операція природного з’єднання цих відношень дає змогу відновити початкове відношення “Ціна-знижка”, оскільки вони мають спільні атрибути “Код товару”, “Код фірми-постачальника”, які у відношенні “ЦІНА” складають первинний ключ.

Рис. 31. Даталогічна проста мережна модель даних

Відношення ЗАМОВЛЕННЯ (№ замовлення, Код товару, Код фірми-постачальника, Дата замовлення, Кількість у замовленні) знаходиться в першій, другій та третій нормальних формах. Непервинний атрибут “Кількість у замовленні” залежить від двох можливих ключів: “Дата замовлення + Код фірми-постачальника + Код товару” та “Дата замовлення + № замовлення + Код товару, які перетинаються по атрибутах “Дата замовлення + Код товару”. Транзитивних залежностей немає. Проте існує залежність атрибута “№ замовлення” від ключової детермінанти “Код фірми-постачальника + Дата замовлення”. Отже, у відношенні “Замовлення” кількість ключових детермінантів перевищує кількість можливих ключів, тому воно не знаходиться у третій посиленій нормальній формі і потребує декомпозиції на такі проекції:

КІЛЬКІСТЬ ЗАМОВЛЕННЯ (Дата замовлення, Код фірми-постачальника,Код товару, Кількість у замовленні);

ЗАМОВЛЕННЯ (Дата замовлення, Код фірми-постачальника, № замовлення).

Атрибут “№ замовлення” є сурогатним ключем — порядковим номером фірм-постачальників у кошику замовлень.

Ключем у відношенні “Кількість замовлення” є “Дата замовлення + Код фірми-постачальника + Код товару”, а ключем у відношенні “Замовлення” - “Дата замовлення + Код фірми-постачальника”.

Неключові атрибути цих відношень функціонально повно і нетранзитивно залежать від можливих ключів. Тому відношення перебувають у третій нормальній формі. Інші ключові детермінанти в них відсутні. Отже, вони перебувають у третій посиленій нормальній формі. Множинні зв’язки в них відсутні. Відношення не потребують зведення і позбавлені аномалій включення, вилучення та редагування даних. Операція природного з’єднання цих проекцій дає змогу відновити початкове відношенні “Замовлення”.

Даталогічна реляційна модель, або схема БД, складається з набору відношень, що не зводяться:

ПОСТАЧАЛЬНИК (Код фірми-постачальника, Назва фірми, Адреса, Ім’я менеджера, Телефон, Рейтинг);

ТОВАР (Код товару, Назва товару, Параметр 1, Параметр 2, Параметр 3, Параметр 4);

ЦІНА (Код товару, Код фірми-постачальника, Ціна);

ЗНИЖКА (Код товару, Код фірми-постачальника, Кількість / знижка, Знижка);

КІЛЬКІСТЬ ЗАМОВЛЕННЯ (Код товару, Код фірми-постачальника, Дата замовлення, Кількість замовлення);

ЗАМОВЛЕННЯ (Код фірми-постачальника, Дата замовлення, № замовлення);

ФАЙЛ (Ім’я файлу, Кількість записів, Розмір, Дата створення, Ім’я розробника);

ПОЛЕ (Ім’я поля, Тип, Довжина, Точність);

ЗВ’ЯЗОК (Ім’я файлу, Ім’я поля).

У прийнятих у словнику даних позначеннях зазначені відношення мають такий вигляд:

ПОСТАЧАЛЬНИК (COD_SUP, NAM_SUP, ADR_SUP, MANAGER, TEL_SUP, REP_SUP);

ТОВАР (COD _ G, NAME_G, PAR1_G, PAR2_G, PAR3_G, PAR4_G) і так далі для усіх відношень.

Варіанти завдань

Визначення номера варіанту завдання: три останні цифри шифру студента поділити на 20 і додати до залишку від ділення 1.

Варіант 1. Специфіка діяльності фірми «Альфа» така, що вона має дуже обмежене коло господарських операцій. Відповідно на фірмі застосовується спрощена схема бухгалтерського обліку:

– ведеться хронологічний запис операцій в регістрі, що має назву «Журнал реєстрації господарських операцій». Для кожного номера операції зазначаються номер документа, зміст операції та сума, а також проведення за відповідними рахунками;

– план рахунків фірми містить такі рахунки:

склад засобів: 05-виробничі запаси; 20-основне виробництво; 41-товари; 50-каса; 51-розрахунковий рахунок; 76-розрахунки з дебіторами;

джерела формування засобів: 85-статутний фонд; 60-розрахунки з кредиторами; 68-розрахунки з бюджетом;

– один раз на місяць бухгалтерія складає баланс.

Потрібно виконати постановку задачі, яка б дала змогу автоматизувати ведення Бухгалтерського обліку на фірмі «Альфа».

Варіант 2. Підприємство «Бета» має три склади, на які надходять матеріали від 200 постачальників. Надходження оформляється приймальними актами, в яких зазначаються кількість, ціна і вартість матеріалу, що надійшов. Щоденно зі складів відпускаються матеріали в цехи основного виробництва. Відпуск оформляється накладною, в якій зазначаються цех-покупець, кількість та сума відпущених матеріалів. Бухгалтерія веде облік руху матеріалів на складах, одержуючи два види документів:

– відомість руху матеріалів за місяць (залишок- надходження- витрати- залишок);

– реєстр документів за добу.

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

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

Варіант 4. Підприємство «Дельта» постачає випущену продукцію покупцям за договорами. Усього договорів за рік може бути близько 1000. Номенклатура виробів становить 100 найменувань. У договорі зазначається дата поставки. Фактична поставка може мати дату, що відрізняється від договірної. Відділ маркетингу повинен контролювати виконання поставок за договорами. Потрібно виконати постановку задачі, яка б дала змогу автоматизувати процес одержання відомостей про відхилення у постачанні.

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

Варіант 6. З метою розробки автоматизованої підсистеми обліку виконання робіт службовцями підприємства на сервері БД потрібно зберігати дані про відділи, службовців, які працюють у відділах, види робіт, що виконуються ними. При цьому кожний службовець працює у своєму відділі, може виконувати кілька видів робіт, а службовці різних відділів – однакові види робіт. Облік відділів, службовців, видів робіт виконується в межах підсистеми, яка розробляється.

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

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

Варіант 9. З метою розробки автоматизованої підсистеми маркетингових досліджень на сервері БД підприємства-виробника багатьох видів продукції потрібно зберігати дані про підприємства-конкуренти, що випускають аналогічну продукцію, про саму продукцію, про підприємства-споживачі цієї продукції, а також про її реалізацію на ринку. При цьому кожне підприємство-виробник випускає і реалізує безліч видів продукції багатьом підприємствам-споживачам. Кожен вид продукції випускається багатьма підприємствами-виробниками та реалізується багатьом споживачам. Кожен споживач купує безліч видів продукції різних виробників. Ціна однієї і тієї самої продукції у різних виробників може бути різною. Облік підприємств-виробників продукції, підприємств-споживачів виконується в межах підсистеми, що розробляється.

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

Варіант 11. На сервері зберігається електронний каталог з данними про книги : назва, автор, рік видання, бібліотечний шифр книги. З метою автоматизації абонентського відділу потрібно зберігати дані про читачів, які користуються електронним каталогом, та вести облік замовлень, видачу книг та їх повернення. Розробіть проект інформаційної системи абонентського відділу таким чином, щоб була можливість розраховувати відомості про замовленні книжки з вказівкою причини їх відсутності в бібліотеці, та про читачів – боржників ( вважати заборгованістю 15 діб з дня видачі книжки).

Варіант 12. Організуйте базу даних ІС обліку лізингових контрактів, коли підприємства – рентери укладають угоду на довгострокову оренду устаткування, що належать підприємству – ліссору.

Варіант 13. Організуйте БД ІС проектного бюро. В межах даної ІС треба зберігати дані про службовців, проекти, які вони розробляють та замовників проектів. Кожний службовець може брати участь в розробці декількох проектів і тим паче один конкретний проект розробляє декілька службовців. Замовники також можуть замовити більше ніж один проект.

Варіант 14. Організуйте БД ІС, яка веде облік стану рахунків клієнтів після введення платіжних документів, вкладів та зняття коштів з рахунків . В межах ІС проводиться щоденне складання сальдового балансу банку.

Варіант 15. Організуйте БД ІС страхового агентства. Страхові агенти укладають з клієнтами договори на страхування майна, особисте страхування, страхування відповідальності. Кожний агент працює не з одним клієнтом і кожен клієнт може укласти угоди різних видів. В рамках ІС повинен вестись облік договорів на страхування та облік страхових випадків.

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

Варіант 17. Управління мебельної фабрики має намір автоматизувати процес отримання матеріалів від постачальників, їх рух в цехи та отримання матеріалів з цехів у разі виявлення залишків. Матеріал фабрика отримує від декількох постачальників.

Варіант 18. Косметологічно-оздоровчий центр має намір автоматизувати облік клієнтів. Кожний клієнт може відвідувати декілька секцій та отримувати декілька послуг. Деякі працівники центру можуть надавати декілька послуг. Постійним клієнтам надається знижка.

Варіант 19. Торговельно-посередницька фірма має намір автоматизувати процес відправки товарів з одної країни в іншу. В межах підсистеми повинна накопичуватися інформація про відправників, товарах, декларантах, одержувачах. Однаковий товар може надходити від різних фірм-відправників однієї країни і транспортуватися різним фірмам-замовникам іншої країни. Фірма-відправник постачає декілька видів товарів. Фірма-замовник одержує декілька видів товарів.

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

Дата добавления: 2019-02-26; просмотров: 142; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 2 3 4 56

Мы поможем в написании ваших работ!