Створення бази даних будівельної компанії

«Створення бази даних Будівельної компанії»

Зміст Вступ

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

1.1 Проектування та побудова діаграми потоків даних (DFD)

1.2 Проектування діаграми «сутність-зв'язок» (ERD)

1.3 Проектування та побудова діаграми переходів станів (STD)

2. Створення бази даних Висновок Список літератури

Вступ Для проектування бази даних, що реалізує звіти про графік робіт на об'єктах впродовж місяця необхідно:

· побудувати діаграму потоків даних (DFD);

· побудувати діаграму «сутність-зв'язок» (ERD);

· побудувати діаграму переходів стану (STD);

· створити інформаційну базу (базу даних) в інструментальній середі Microsoft Access.

Мета i задачі виконання курсової роботи — визначення здібностей студента щодо самостійного застосування одержаних знань при розв’язанні конкретної задачі, пов’язаної з реалізацією інформаційної системи; вміння користуватися спеціальною i довідковою літературою.

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

1.1 Проектування та побудова діаграми потоків даних (DFD)

Діаграми потоків даних (DFD — Data Flow Diagram) є основним засобом моделювання функціональних вимог проектованої системи. З їх допомогою ці вимоги розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, зв’язаної потоками даних. Головна мета таких засобів — продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити стосунки між цими процессами.

Основними компонентами діаграм потоків даних є:

· зовнішні сутності;

· процеси;

· нагромаджувачі даних;

· потоки даних.

Зовнішня сутність є матеріальним предметом або фізичною особою, яка виступає джерелом або приймачем інформації. Зовнішня сутність позначається квадратом. В нашому випадку зовнішніми сутностями є Керівник № 1 та Розрахунковий центр№ 2 (рис. 1.1).

Рис. 1.1. Графічне зображення зовнішніх сутностей Процесом є перетворення вхідних потоків даних у вихідні відповідно до певного алгоритму. Крім того, кожен процес повинен мати унікальний номер для заслань на нього усередині діаграми. Цей номер може використовуватися спільно з номером діаграми для здобуття унікального індексу процесу у всій моделі. Процесами в нашому випадку є (рис. 2):

Рис. 1.2. Графічне зображення процесу Нагромаджувач даних — це абстрактний пристрій для зберігання інформації, яку можна у будь-який момент помістити в накопичувач і через деякий час витягувати, причому способи приміщення і витягання можуть бути різними. На рис. 3 представлені нагромаджувачі даних. В них буде зберігатися інформація про керівників, підрозділи, робот та їх об'єкти .

Рис. 1.3. Графічне зображення нагромаджувачів даних Потоки даних — механізми, що використовуються для моделювання передачі інформації (або фізичних компонентів) з однієї частини системи в іншу. Потоки зображуються на діаграмі іменованими стрілками, орієнтація яких вказує напрямок руху інформації. Стрілки можуть підходити до будь-якої сторони прямокутника роботи і можуть бути двонаправленими для опису взаємодії типу «команда-відповідь».

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

Діаграми потоків даних була побудована в середовищі Microsoft Visio (рис. 1.4).

Рис. 1.4. Графічне представлення діаграми потоків даних

1.2 Проектування діаграми «сутність-зв'язок» (ERD)

Діаграми «сутність-зв'язок» (Entity-relationship) призначені для розробки моделей даних і забезпечують стандартний спосіб визначення даних і стосунків між ними. Фактично за допомогою ERD здійснюється деталізація сховищ даних проектованої системи, а також документуються суть системи і способи їх взаємодії, включаючи ідентифікацію об'єктів, важливих для наочної області (суті), властивостей цих об'єктів (атрибутів) і їх стосунків з іншими об'єктами (зв'язків).

Основними конструктивними елементами діаграми «сутність-зв'язок» є суть, зв’язки між ними і їх властивості (атрибути) .

Сутність — будь-який помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про яке необхідно зберігати в базі даних. Сутністю можуть бути люди, місця, літаки, рейси, смак, колір і т. д.

Зв’язок — це деяка асоціація між двома сутностями. Одна сутність може бути пов’язана з іншою сутністю або сама з собою. Зв’язки дозволяють по одній сутності знаходити іншу сутність, пов’язану з нею. Графічно зв’язок зображається лінією, що сполучає дві сутності. Кожен зв’язок має два кінці і одне або два найменування.

Діаграма «сутність-зв'язок» була побудована в середовищі Microsoft Access.

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

Таблиця 1.1 — Типи даних таблиці «Робітники»

Відношенню Робітники відповідає повна функціональна залежність: Робітників > ФІО, Номер паспорта, Номер спеціальності, Номер типу роботи, Номер підрозділу, Номер роботи. Всі поля окрім «ID_робітників» не можуть бути первинним ключем.

Таблиця 1.2 — Типи даних таблиці «Графік робіт»

Відношенню Графік робіт відповідає повна функціональна залежність:ДатаПочатку, ДатаЗакінчення, НомерОб'єкта, НомерРоботи, НомерПідрозділу, Номер Робітника, Номер керівника. Всі поля окрім «Номер Об'єкту, Роботи, Підрозділу, Робітника, Керівника «не можуть бути первинним ключем.

Таблиця 1.3 — Типи даних таблиці «Спеціальності»

Відношенню Спеціальності відповідає повна функціональна залежність: Номер спеціальності > Назва спеціальності. Всі поля окрім «Номер спеціальності» не можуть бути первинним ключем.

Таблиця 1.4 — Типи даних таблиці «Тип робіт»

Відношенню Тип робіт відповідає повна функціональна залежність: Номер типу роботи > Назва типу роботи. Всі поля окрім «Номер типу роботи» не можуть бути первинним ключем.

Таблиця 1.5 — Типи даних таблиці «Об'єкти «

Відношенню Об'єкти відповідає повна функціональна залежність: Номер об'єкту > Назва об'єкту. Всі поля окрім «Номер об'єкту» не можуть бути первинним ключем.

Таблиця 1.6 — Типи даних таблиці «Роботи»

Відношенню Роботи відповідає повна функціональна залежність: Номер роботи, Номер типу роботи > ціна. Всі поля окрім «Номер роботи та типу роботи» не можуть бути первинним ключем.

Таблиця 1.7 — Типи даних таблиці «Підрозділи»

Відношенню Підрозділи відповідає повна функціональна залежність: Номер підрозділу > Назва підрозділу, Номер керівника. Всі поля окрім «Номер Підрозділу та Керівника» не можуть бути первинним ключем.

Таблиця 1.8 — Типи даних таблиці «Керівники»

Відношенню Керівники відповідає повна функціональна залежність: Номер керівника > ФІО, Номер підрозділу. Всі поля окрім «Номер Керівника та Підрозділу» не можуть бути первинним ключем.

Аналіз функціональних залежностей, які мають місце для відношень Робітники, Графіки робіт, Спеціальності, Тип робіт, Об'єкти, Роботи, Підрозділи, Керівники показують, що вони повні.

Отже універсальне відношення Робітники — Графіки робіт — Спеціальності - Тип робіт — Об'єкти — Роботи — Підрозділи — Керівники нормалізовано.

1.3 Проектування та побудова діаграми переходів станів (STD)

За допомогою STD можна моделювати подальше функціонування системи на основі її попереднього і поточного функціонування. Модельована система в будь-який заданий момент часу знаходиться точно в одному з кінцевої безлічі станів. З часом вона може змінити свій стан, при цьому переходи між станами мають бути точно визначені.

STD складається з наступних об'єктів:

· стан;

· початковий стан;

· перехід;

· умова;

· дія.

Стан — може розглядатися як умова стійкості для системи. Знаходячись в певному стані, ми маємо досить інформації про минулу історію системи, щоб визначити черговий стан залежно від поточних вхідних подій.

Початковий стан — вузол STD, який є стартовим для початкового системного переходу. STD має рівно один початковий стан, який відповідає стану системи після її інсталяції, але перед початком реальної обробки, а також будь-яке (кінцеве) число станів, які завершаються.

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

Таким чином умовою є подія (або події), що викликає перехід і що ідентифікується ім'ям переходу. Якщо в умові бере участь вхідний потік процесу-предка, що управляє, що управляє, то ім'я потоку має бути поміщене в лапки.

Окрім умови з переходом може зв’язуватися дія або ряд дій, що виконуються, коли перехід має місце. Тобто дія — це операція, яка може мати місце при виконанні переходу.

Для процесу листування діаграма потоків даних буде виглядати так:

Запит на звіт Запит на звіт Підготовка звіту Генерація звіту Рис. 1.5. Графічне зображення діаграми потоків даних

2. Створення бази даних Для створення бази даних потрібно спочатку запустити програму Microsoft Office Access 2007, для цього потрібно виконати наступні дії: Пуск > Програми > Microsoft Office > Microsoft Office Access 2007.

Відобразиться вікно «Приступая к работе с Microsoft Office Access». У вкладці «Новая пустая база данных» виберемо «Новая база данных» та задамо цьому файлу ім'я.

Приступимо до створення таблиць в режимі «Конструктор». Після заповнення всіх таблиць, вони будуть мати такий вигляд.

база дане конструктор діаграма Таблиця 2.1 Робітники Таблиця 2.2 Спеціальності

Таблиця 2.3 Тип робіт Таблиця 2.4 Об'єкти Таблиця 2.5 Роботи Таблиця 2.6 Графік робіт

Таблиця 2.7 Підрозділи Таблиця 2.8 Керівники Далі вибираємо «Режим работы с таблицами», у вкладці «Связи» вибираємо «Схема данных» та будуємо діаграму «сутність-зв'язок» (рис. 2.1).

Наприклад, щоб встановити зв’язки між таблицями «Керівники» та «Графік робіт» необхідно в таблиці «Керівники» виділити первинний ключ «Номер керівники» та протягнути ЛКМ до атрибуту «Номер керівники» таблиці «Графік робіт». З’явиться діалогове вікно «Изменение связей», виберемо пункт «Обеспечение целостности данных» та у вкладці «Объединение» виберемо пункт «Объединение ВСЕХ записей из „Керівники“ и только тех записей из „Графік робіт“, в которых связанные поля совпадают». В цьому випадку відображається зв’язок «один к многим».

Рис. 2.1. Графічне зображення діаграми потоків даних Далі створюємо запит на вибірку за допомогою майстра. Для створення запиту необхідно в середовищі Microsoft Access у меню «Создание» у вкладці «Другие» вибрати «Мастер запросов».

У діалоговому вікні «Новый запрос» виберемо в списку строку «Простой запрос» та натиснемо кнопку «Ок». З’являється можливість вибору полів з різних таблиць в діалоговому вікні «Создание простых запросов». Виберімо поля «Дата початку», «Дата закінчення», із таблиці «Графік робіт», «Назва» із таблиці «Підрозділи», а також «ФІО» із таблиці «Керівники» та натиснемо кнопку «Далее» (рис. 2.2).

Рис. 2.2. Діалогове вікно «Создание простых запросов»

Потім задаємо ім'я запиту «Підрозділи Запит», вибираємо дію «Открыть запрос для просмотра данных» та натискаємо кнопку «Готово». В результаті отримуємо нову таблицю «Підрозділи Запит» (табл. 2.9).

Таблиця 2.9 Підрозділи запит Аналогічно можна створити інші запити.

Висновок У результаті виконання курсової роботи була створена база даних «Будівельна компанія», яка була основана на реляційній моделі даних. Ця модель характеризується простою структурою даних, зручним для користувача табличним представленням бази даних та можливістю використання формального алгебраїчного апарату відношення та реляційного числення для обробки даних, що і було зроблено на етапі проектування баз даних. Кожна таблиця представлена у вигляді двовимірного масиву (вигляд двовимірних таблиць).

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

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

Список літератури

1. Калянов Г. Н. Case — структурний системний аналіз. — Видавництво «ЛОРІ», 1996. — 246 с.

2. Курсовий проект з дисципліни «Розробка та експлуатація автоматизованих інформаційних систем». — Котельнич, 2010. — Золотова С.І. Практикум з Access. — Видавництво «Фінанси та статистика», 2008. — 144 с.

3. Методичні вказівки до лабораторної роботи на тему «Робота в середовищі MS Access. Частина 2. Створення запитів та звітів.» з дисципліни «Економічна інформатика"/ Укладач Л. О. Стеценко. — Суми: Вид-во СумДУ, 2009. — 41с.

4. Домашня сторінка Access: довідка та навчання. — Вілларіал Боб. Програмування Access 2002 в прикладах: пер. з англ. — М.:КУДИЦ-ОБРАЗ, 2003. — 496 с.

5. Киммел Пол. Освой самостоятельно программирование для Microsoft Access 2002 за 24 часа.: Пер. с англ. — М.: Издательский дом «Вильяме», 2003. — 480 с.