2.1.2 Розробка інфологічної моделі предметної області
Завданняконцептуального інфологічного проектування полягає в одержанні логічної моделіБД у термінах об’єктів ПС та зв’язків між ними, що не залежить від конкретноїСУБД й узагальнює інформаційні вимоги потенційних користувачів ІС. Розрізняютьдва основні методи концептуального інфологічного проектування: низхіднепроектування (метод формулювання та аналізу сутностей) і висхідне проектування(метод синтезу атрибутів). Ці методи недостатньо формалізовані, єдиних правилвикористання їх не існує.
Найпридатнишимдля практичного застосування є перший метод. Він складається з двох етапівпроектування БД: ідентифікації та моделювання локальних інформаційних структур.
БД у вигляділокальних ER-діаграм і побудови глобальної інформаційної моделі – глобальної ER-діаграми.
Локальніінформаційні структури відповідають локальним задачам.
Проектуванняглобальної інфологічної моделі даних полягає в інтеграції локальнихінформаційних структур, здобутих на попередньому етапі. При об’єднаннілокальних інформаційних структур у глобальну використовують поняття –ідентичність, агрегація, узагальнення. Усі вони однаковою мірою належать дотипів сутностей або об’єктів ПС та їхніх атрибутів, зв’язків між об’єктами ПСта їхніх атрибутів
Розробляємотільки в одному Загальному представленні на базі ER-моделі (модель„сутність-зв’язок”). В зв’язку з тим, що предметна область не складна –виділяємо тільки одне локальне уявлення.
1. Формуємосутності (об’єкти ПС)
1) Начальниккафедри
2) Лабораторія
3) Співробітникилабораторії
4) Майно
5) Технічнеобслуговування
2. Формуємоатрибути сутностей
Аналізуємозв’язки між сутностіми.
Встановимо такизв’язки в своєму проектуванні бази даних: науково-викладницький склад можевикладати багато навчальних дисциплін, одна навчальна група має один напрямпідготовки, викладач може викладати і викладає в декількох навчальних групах, анавчальна група вивчає декілька навчальних дисциплін.
1. Аналізуємо зв’язки міжсутностями
Рис.4.
Складемо схемуінфологічної моделі ПО
Рис.5.
Відношення, щостворені на підставі реляційної моделі даних характеризуються властивостями:
1. В таблицівідсутні рядки з однаковими значеннями.
2. Відношеннямає домени, або стовпці, значення яких відповідає атрибутам, або назвамстовпців.
3. Кожнийатрибут має унікальне і’мя
4. Порядокслідування рядків в таблиці довільний.
Кожне відношенняявляється динамічною моделлю деякого об’єкту предметної області. Для отриманняінформації з відношення необхідно мати засоби маніпуляції даними.
Існують 3 типизасобів маніпуляції даними:
1 тип – реляційнаалгебра,
2 тип – реляційнезчислення зі змінними кортежами
3 тип – реляційнезчислення зі змінними доменами.
Операціїреляційної алгебри ми розглянемо пізніше на прикладі нашої бази даних.
2.2 Даталогічне проектування.
2.2.1 Вибір типу моделі даних
Тип моделі данихв нас – реляційний. Також MS Access – це реляційна офісна програма, що допомагаєрозробляти реляційні БД, тобто БД, що влючають в себе декілька повязаних міжсобою таблиць за допомогою ключьових полів. Кожне поле таблиці в реляционноймоделі містить визначені фактичні дані по сутностях (об'єктам), як наприклад,конкретні зведення про співробітників лабораторії (посада, освіта, телефон), чизведення про технічне обслуговування майна лабораторії (дата обслуговування, видобслуговування і т.п.). Для автоматизації рішення задач нам необхідна могутняреляційна СУБД і система розробки додатків. Практично всі існуючі СУБД маютьзасоби розробки додатків, які можуть бути використаний програмістами абокваліфікованими користувачами при створенні процедур для автоматизації управлінняі обробки даних. На жаль, багато систем розробки додатків для створенняпроцедур вимагають знання деякої мови програмування, наприклад С або XBase. ВMS Access програмувати можна за допомогою макросів, що ми продемонструємо упрактичній частині курсового проекту.
2.2.2 Розробка композиційної системи бази даних
Етапконцептуального моделювання – це побудова опису ПО в термінах деякої формальноїмови. На підставі змістовного опису ПО, побудованого в результаті виконанняетапу аналізу, будується строгий формальний опис інформаційного забезпеченняПО, що автоматизується.
Концептуальнемоделювання призначене для інтегрованого опису інформаційного забезпечення ПО,що автоматизується не залежно від її спрійняття окремими користувачами й відспособів її реалізації в комп’ютерній системі.
Композиційнасхема – це проміжний елемент при переході від інфологічної схеми до логічноїсхеми бази данних.
Результатомкомпозиції являється логічна схема відношень реляційної бази даних.
Відобразимо насхемі всі транзитивні залежності, після цього можемо розробити кінцеву схемувідношень перед побудовою логічної (концептуальної) схеми бази даних „Кафедра”.
Рис.6.
Розробимокомпозиційну схему в який будуть відсутні транзитивні залежності (рис.7), післячого на підставі цієї схеми будемо розробляти логічну (концептуальну) схемубази даних.
Рис.7.
Перевіримопобудовану композиційну схему на відсутність протирічь (рис.8)
Рис.8.
Логічні ітимчасові протиріччя в БД відсутні, таблиці БД поділяти не рекомендується.
2.2.3 Розробка логічної схеми бази даних
Логічнепроектування – це розробка логічної структури системи баз даних. Відстранив всілогічні і тімчасові протиріччя, ми отримали логічну схему бази даних „Кафедра”(рис.9).
Начальник кафедри | ||||
№ кафедри | Назва кафедри | Назва факультету | Корпус | Телефон |
1 | Кріптографії | Інформаційних систем | 1 | 345-76-65 |
2 | ТСП | Інформаційних систем | 1 | 659-45-32 |
3 | Зв'язку | Зв'язку | 2 | 876-56-43 |
4 | Експлуатації | Експлуатації систем | 3 | 659-69-87 |
5 | Комп'ютерних наук | Кибернетиці | 4 | 564-65-11 |
Лабораторія | ||||
Код лабораторії | № кафедри | В/звання | ПІБ начальника лабораторії | Телефон |
11 | 1 | Магистр | Абель П.С. | 345-98-19 |
21 | 2 | к.т.н. | Бабич Р.О. | 659-64-44 |
31 | 3 | Магистр | Бубка П.Р. | 876-86-27 |
41 | 4 | к.т.н. | Валин К.Д. | 659-88-79 |
51 | 5 | Магистр | Ганин Н.Л. | 564-67-77 |
Співробітники лабораторії | ||||
ПІБ | № кафедри | Посада | Освіта | Телефон |
Абель П.С. | 1 | Завлаб | Вища | 345-98-19 |
Бабин К.П. | 3 | Лаборант | Середня | 876-86-27 |
Бабич Р.О. | 2 | Завлаб | Вища | 659-64-44 |
Бубка П.Р. | 3 | Завлаб | Вища | 876-56-43 |
Валин К.Д. | 4 | Завлаб | Вища | 659-88-79 |
Волин Н.Г. | 2 | Лаборант | Середня фахова | 659-35-55 |
Врубель А.Т. | 1 | Лаборант | Середня фахова | 345-78-67 |
Вунин Ш.Б. | 4 | Лаборант | Середня | 659-34-43 |
Ганин Н.Л. | 5 | Завлаб | Вища | 564-67-77 |
Гунин К.П. | 5 | Лаборант | Середня | 564-11-22 |
Майно | ||
Інв.№ | Рік випуску | Відповідальний |
101 | 01.02.1999 | Абель П.С. |
102 | 01.03.2008 | Абель П.С. |
103 | 15.03.2008 | Врубель А.Т. |
104 | 21.04.2008 | Врубель А.Т. |
201 | 18.02.2008 | Бабич Р.О. |
202 | 23.03.2008 | Бабич Р.О. |
203 | 24.01.2008 | Волин Н.Г. |
204 | 14.02.2008 | Волин Н.Г. |
301 | 12.01.2008 | Бубка П.Р. |
302 | 23.02.1993 | Бубка П.Р. |
303 | 21.02.2008 | Бабин К.П. |
304 | 25.04.1995 | Бабин К.П. |
401 | 12.03.1997 | Валин К.Д. |
402 | 17.05.2008 | Валин К.Д. |
403 | 24.04.1998 | Вунин Ш.Б. |
404 | 18.08.2007 | Вунин Ш.Б. |
501 | 25.04.1999 | Ганин Н.Л. |
502 | 30.12.2007 | Ганин Н.Л. |
503 | 21.02.2000 | Гунин К.П. |
504 | 30.01.2008 | Гунин К.П. |
Технічне обслуговування | ||
Дата | Інв.№ майна | Вид обслуговування |
05.05.1999 | 101 | Гарантийне |
27.06.2003 | 403 | Профілактичне |
24.08.2003 | 503 | Профілактичне |
30.03.2004 | 401 | Профілактичне |
27.04.2005 | 302 | Профілактичне |
23.05.2005 | 304 | Профілактичне |
18.09.2006 | 501 | Профілактичне |
09.12.2007 | 101 | Профілактика |
30.01.2008 | 404 | Гарантийне |
18.02.2008 | 203 | Гарантийне |
26.02.2008 | 504 | Гарантийне |
16.03.2008 | 201 | Гарантийне |
22.03.2008 | 303 | Гарантийне |
23.03.2008 | 502 | Гарантийне |
25.03.2008 | 204 | Гарантийне |
02.04.2008 | 102 | Гарантийне |
20.04.2008 | 103 | Гарантийне |
22.04.2008 | 202 | Гарантийне |
25.04.2008 | 201 | Гарантийне |
26.04.2008 | 301 | Гарантийне |
15.05.2008 | 104 | Гарантийне |
20.05.2008 | 402 | Гарантийне |
Рис.9.