База даних "Відділ кадрів"

Размещено на http://www.allbest.ru/

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

Полтавський національний технічний університет

імені Юрія Кондратюка

Навчально-методичний центр дистанційної та післядипломної освіти

Кафедра комп'ютерних та інформаційних технологій і систем

КУРСОВА РОБОТА З ДИСЦИПЛІНИ

"СТРУКТУРА БАЗИ ДАНИХ"

на тему:

БАЗА ДАНИХ "ВІДДІЛ КАДРІВ"

Виконавець: Студентка 2 курсу

Шмиголь Ірина Олександрівна

Перевірив: доцент, кандидат технічних наук

Головко Геннадій В'ячеславович

Полтава

2015



Зміст

Вступ

1. Проектування бази даних

1.1 Загальне уявлення про бази даних

1.2 Процес проектування бази даних

2. Створення бази даних "відділ кадрів" у субд access-2007

2.1 Інфологічна модель бази даних "відділ кадрів"

2.2 Даталогічна модель бази даних "відділ кадрів"

Висновки

Список використаних джерел



Вступ

За свою свідому історію людство накопичувало певний обсяг нових знань, тобто інформації. Це накопичення відбувалося різними темпами. Якщо на початку нашої ери для подвоєння обсягу знань знадобилося біля 1750 років, то у першій половині ХХ сторіччя за 50 років відбулося збільшення інформації у 8-10 разів. А наприкінці ХХ віку відбувся так званий "інформаційний вибух": обсяг інформації за 50 років збільшився більше ніж у 30 разів.

На початку 70-х років ХХ століття світове співтовариство вразила інформаційна криза, що насамперед проявилася в зниженні ефективності інформаційного обміну. Криза була обумовлена наступними причинами:

· різко зріс обсяг даних;

· між групами різних фахівців стало важко спілкуватися;

· зріс обсяг неопублікованої інформації;

· виросла проблема міжмовного обміну у світі.

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

Активна діяльність по пошуку прийнятних способів усуспільнення безупинно зростаючого обсягу інформації призвела до створення на початку 60-х років ХХ сторіччя спеціальних програмних комплексів, названих "Системи управління базами даних" (СУБД).

Основна особливість СУБД - це наявність процедур для введення й збереження не тільки самих даних, але й описів їхньої структури. Файли, оснащені описом збережених у них даних і знаходяться під управлінням СУБД, стали називати "Бази даних" (БД).

Предметом цієї курсової роботи є створення реляційної бази даних "Відділ кадрів" у середовищі Access-2007.

1. Проектування бази даних

1.1 Загальне уявлення про бази даних

Інформація в базі даних (БД) зберігається в таблицях. Таблиця зберігає неопрацьовані дані. У БД може зберігається одна чи більше таблиць. Розміщаючи інформацію в багатьох таблицях у межах однієї бази даних, ми зменшимо працезатрати на підтримку БД. У таблиці інформація групується по рядках і стовпцях.

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

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

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

Функціонування БД забезпечується сукупністю мовних і програмних засобів, названих системою управління базами даних (СУБД).

СУБД забезпечують:

а) визначення даних, що підлягають збереженню в БД (визначення логічних властивостей даних, що відповідають уявленням користувача які називаються структури даних у БД, а також фізична організація збереження даних, які називаються структурами збереження БД);

б) початкове завантаження даних у БД - так зване створення БД;

в) відновлення даних;

г) доступ до даних по різних запитах користувача, добір і добування деякої частини БД, редагування витягнутих даних і видачу їх користувачеві.

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

1.2 Процес проектування бази даних

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

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

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

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

Процес проектування бази даних містить у собі 3 етапи:

· інфологічне проектування;

· даталогічне проектування;

· фізичне проектування.

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

На кожному етапі проектування створюється відповідний опис і модель даних.

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

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

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

У цій роботі ми розглянемо моделювання БД "Відділ кадрів" за допомогою так званих ER-діаграм.

Потім ми проведемо даталогічне проектування для СУБД ACCESS. Створимо і заповнимо таблиці БД, розробимо форми для введення і виведення інформації, побудуємо запити і звіти.

Умови задачі:

1. Відділ кадрів веде облік співробітників освітньо-тренінгового центру.

2. Кількість співробітників -



2. Створення бази даних "відділ кадрів" у субд access-2007

2.1 Інфологічна модель бази даних "відділ кадрів"

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

Основними конструктивними елементами інфологічної моделі є:

· сутності;

· зв'язки між ними;

· їх властивості (атрибути).

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

Поняття "тип сутності" відноситься до набору однорідних особистостей, предметів, подій чи ідей, що виступають як ціле.

Екземпляр сутності відноситься до конкретної речі в наборі. Кожен екземпляр сутності повинен відрізнятися від будь-якого іншого екземпляра тієї ж сутності.

Атрибут - це пойменована характеристика сутності. Його ім'я повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДІМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР, ПОТУЖНІСТЬ ДВИГУНА і т.д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів значень: червоний, синій, банановий, біла ніч і т.д., однак кожному екземпляру сутності привласнюється тільки одне значення атрибута.

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

Для асоціювання двох чи більше сутностей існують зв'язки. Якби призначенням бази даних було тільки збереження окремих, не зв'язаних між собою даних, то її структура могла б бути дуже простою. Однак, одна з основних вимог до організації БД - це забезпечення можливості відшукання одних сутностей за значеннями інших, для чого необхідно установити між ними визначені зв'язки. А через те, що в реальних базах даних нерідко містяться сотні чи навіть тисячі сутностей, то теоретично між ними може бути встановлено більше мільйона зв'язків.

Можна виділити такі етапи інфологічного проектування:

Ш дослідження предметної області;

Ш аналіз даних (сутностей та їх атрибутів);

Ш визначення зв'язків між сутностями та визначення первинних і вторинних ключів.

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

Моделювання предметної області базується на використанні графічних ER-діаграм (від англ. Entity-Relationship, тобто сутність-зв'язок), що включають невелику кількість різнорідних компонентів.

У ER-моделі сутності позначаються прямокутниками, асоціації (зв'язки) - ромбами або шестикутниками, атрибути позначаються овалами, а зв'язки між ними - ненаправленими ребрами, над якими може проставлятися ступінь зв'язку (1 та символ, що заміняє слово "багато") і необхідне пояснення.

На підставі викладеного вище, змоделюємо ER-діаграму БД "Відділ кадрів" (рис. 2.1.).

Рис. 2.1. ER-діаграма БД "Відділ кадрів"

2.2 Даталогічна модель бази даних "відділ кадрів"

Етап даталогічного проектування з використанням СУБД ACCESS-2007 складається в завданні таблиць і наборів стовпців для кожної таблиці. Кожній таблиці і кожному стовпцю дається ім'я. Для кожного стовпця вибирається потрібний ТИП ДАНИХ (такий як ТЕКСТОВИЙ, ДАТА, ЧИСЛОВИЙ тощо), а також ШИРИНА (яка може бути визначена типом даних, як у випадку ДАТА) чи МАСШТАБ і ТОЧНІСТЬ (тільки для типу даних ЧИСЛОВИЙ).

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

Виходячи з вищезазначеного, для БД "Відділ кадрів" створимо такі таблиці:

1. ВІДДІЛИ (рис. 2.2, 2.2а).

2. ВИДИ ДІЯЛЬНОСТІ (рис. 2.3, 2.3а).

3. ШТАТНИЙ РОЗКЛАД (рис. 2.4, 2.4а)

4. СПІВРОБІТНИКИ (рис. 2.5, 2.5а).

5. ДІТИ (рис. 2.6, 2.6а).

Рис. 2.2. Таблиця "Відділи".

Рис. 2.2а. Таблиця "Відділи" в режимі "Конструктор".

Рис. 2.3. Таблиця "Види діяльності".

Рис. 2.3а. Таблиця "Види діяльності" в режимі "Конструктор".

Рис. 2.4. Таблиця "Штатний розклад".

Рис. 2.4а. Таблиця "Штатний розклад" в режимі "Конструктор".

Рис. 2.5. Таблиця "Співробітники".

Рис. 2.5а. Таблиця "Співробітники" в режимі "Конструктор".

Рис. 2.6. Таблиця "Діти".

Рис. 2.6а. Таблиця "Діти" в режимі "Конструктор".

Слід зазначити, що деякі поля таблиць вимагають вибору значення серед існуючих. Для цього в режимі "Конструктор" обираємо вкладку "Подстановка" (рис. 2.7) і зазначаємо, з якої таблиці чи запиту необхідно обирати дані для підстановки (можливий варіант ручного введення значень списку для вибору, наприклад, при заповненні поля СТАТЬ задаємо значення для вибору: "чол.", "жін.").

Рис. 2.7. Таблиця "Співробітники", вкладка "Подстановка".

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

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

Якщо Таблиця має бути зв'язана з кількома іншими Таблицями, вона може мати кілька Зовнішніх ключів. Зокрема, Таблиця "Співробітники" повинна бути зв'язана з чотирма іншими Таблицями, тому вона має один Первинний ключ і чотири Зовнішніх ключа.

Після цього зв'язуємо Таблиці для забезпечення цілісності БД і для можливості добування повної інформації про об'єкт. З цією метою відкриваємо пункт меню "Работа з базами данных">"Схема данных" (рис. 2.8 на с. 16).

Рис. 2.8. Встановлення зв'язків між таблицями.

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

Форми бувають прості та складені (які включають інші Форми). Вони можуть містити різні елементи: поля БД та підписи до них, списки, прапорці, перемикачі, кнопки, вкладки та ін. У них можливі розрахунки для певних записів та їх груп, а також наочне графічне представлення даних у вигляді діаграм.

Форму можна спроектувати на базі однієї чи кількох Таблиць і/чи Запитів. На основі однієї Таблиці чи Запиту можна побудувати декілька Форм. Кількість Форм у нашому випадку відповідає кількості Таблиць.

У Формі імена полів беруться з опису Таблиці, а самі поля можна розташовувати відповідно до своїх уподобань та вимог і вносити різні елементи оформлення:лінії, малюнки, фон тощо.

Форма створюється "вручну" - за допомогою Конструктора Форм (через меню "Создание" > "Формы"), автоматизованим способом - за допомогою Майстра Форм або автоматично, з використанням автоформи.

Форми для нашої БД були створені за допомогою автоформи із наступним коригуванням їх через режим Конструктора та режим Макета.

Одну із створених для БД "Відділ кадрів" Форм можна подивитися на рисунку 2.9.

Рис. 2.9. Форма "Співробітники".

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

Відділу кадрів необхідно час від часу отримувати інформацію щодо загального списку працюючих, наявності вакансій (посад, не займаних на даний час працівниками), кількості і переліку ювілярів, багатодітних батьків тощо. Для цього створимо такі Запити:

1. Працюючі.

2. Вакансії (рис. 2.10).

3. Посади.

4. Ювіляри.

5. Співробітники жінки.

6. Співробітники чоловіки.

7. Максимальна зарплата.

8. Оклад на вибірку.

9. Багатодітні.

10. Премія.

Для створення Запиту ввійдемо в Меню "Создание" > "Конструктор запросов". Відкриється діалогове вікно "Добавление таблицы", у якому треба обрати таблиці, які стануть базою для створення запиту.

Рис. 2.10. Запит "Вакансії".

Вікно Конструктора Запиту складається з двох частин: верхня містить списки полів обраних таблиць, а нижня - бланк QBE для створення Запиту. Кожен стовпчик бланка описує одне поле, яке бере участь у Запиті.

Включення поля до Запиту виконується перетаскуванням його зі списку полів таблиць, який міститься у верхній частині екрану, в потрібний стовбець бланка QBE за допомогою "миші". Включення всіх полів відбувається, якщо перетягнути символ "*" згори списку полів цієї таблиці у верхній частині екрану.

Установлення зв'язків між таблицями відбувається автоматично, з використанням структури зв'язків, створеної при генерації проекту БД.

Умову для відбору потрібних полів визначаємо в рядку "Условие отбора" в нижній частині екрану. Декілька значень відбору можна ввести в один рядок, розділивши їх логічними умовами AND чи OR, або - в наступну комірку рядка "или".

Якщо в Запиті повинні бути поля, що треба обраховувати, використовуються функції та оператори, які пропонує Access для генерації розрахунків. Для цього використовується пункт меню "Построитель".

Для формування Запиту "Багатодітні" знадобилося створити проміжний Запит щодо кількості дітей у кожного співробітника: Запит "Кількість дітей" (рис. 2.11, 2.12 на с. 19), а потім задати умову, за якою визначається багатодітність за українським законодавством: "?3".

Рис. 2.11. Запит "Кількість дітей".

Рис. 2.12. Запит "Багатодітні".

Щоб подивитися результат Запиту, необхідно на Панелі натиснути кнопку "Выполнить" .

Для створення Запиту "Премія" необхідно ввести формулу для розрахунків у додаткове поле. Умовою нарахування премії, у нашому випадку, є зарплата, нижча від 15000,00 грн./міс. Розмір премії складає 15 % від окладу. Щоб створити обчислюване поле "Премія", в рядку "Поле" через Построитель введемо розрахунок (рис. 2.13), де зазначимо вихідне поле "Оклад" з Таблиці "Штатний розклад", дані з якого необхідно помножити на відсоток премії.

Рис. 2.13. Запит "Премія", введення формули розрахунку.

Як виглядає цей Запит в режимі Конструктора, можна побачити на рис. 2.14.

Рис. 2.14. Запит "Премія" в режимі Конструктор.

Для деяких звітів необхідно, щоб Прізвище, Ім'я та По батькові співробітника були об'єднані в одне поле. Для цього був створений Запит ПІБ, у якому за допомогою оператора конкатенації Амперсанд (&) було об'єднано вищевказані текстові рядки: "ПІБ: [Співробітники]![SURNAME] & " " & [Співробітники]![NAME_1] & " " & [Співробітники]![NAME_2]" (рис. 2.15).

Рис. 2.15. Запит "ПІБ" в режимі Конструктор, формула об'єднання текстових рядків.

Далі потрібно визначити, які необхідно створити Звіти і яку інформацію і як (таблиці, діаграми, текст) у них представити.

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

Існує три способи створення Звітів: за допомогою Конструктора, "Мастера отчетов" та автоматичного створення - "автоотчета". Конструктор надає можливість самостійного проектування звітів. "Мастер отчетов" дозволяє створювати Звіт на підставі відповідей проектанта на питання, що стосуються структури, змісту та оформлення Звіту. "Автоотчет" створює Звіт у стовпчик та стрічку.

Для приведення інформації, отриманої через Запити, у звичний для користувача вигляд створимо Звіти, використовуючи "Мастер отчетов":

1. Список співробітників (рис. 2.16).

2. Багатодітні.

3. Співробітники жінки

4. Співробітники чоловіки

5. Перелік посад по відділах

6. Вакансії.

7. Ювіляри.

8. Нарахована премія.

Рис. 2.16. Звіт "Список співробітників".

Для зручності користування списком необхідно пронумерувати кожен запис отриманого Звіту. Для цього відкриємо створений Звіт у режимі Конструктора (рис. 2.17 на с. 23) і створимо нове поле в Області даних, в якому задамо параметр для даних "=1" і поставимо позначку у рядку "Сумма с накоплением" - "Для всего".

Рис. 2.17. Звіт "Список співробітників", нумерування списку в режимі Конструктор.

У результаті отримаємо такий Звіт, як показано на рис. 2.18.

Рис. 2.18. Звіт "Список співробітників".

Зовнішнє оформлення Звіту можна змінити через режим "Макет". Тепер Звіт готовий для того, щоб його віддрукувати на папері.



Висновки

Дана робота була присвячена побудові реляційної БД "Відділ кадрів" у середовищі Access-2007.

Як видно з цієї роботи, реляційна база даних - це тіло пов'язаної інформації, яка зберігається у двомірних таблицях.

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

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



Список використаних джерел

1. Головко Г.В., Гафіяк А.М. Управління базами даних. Частина 1. Проектування баз даних. Бази даних та інформаційні системи: Конспект лекцій. - Полтава: Полтавський національний технічний університет імені Юрія Кондратюка, 2008. - 89 с.

2. Головко Г.В., Гафіяк А.М. Управління базами даних. Частина 2. Робота із СУБД Microsoft Access: Конспект лекцій. - Полтава: Полтавський національний технічний університет імені Юрія Кондратюка, 2009. - 147 с.

3. Клименко О.Ф., Головко Н.Р., Шарапов О.Д. Інформатика та комп'ютерна техніка: Навч.-метод. посібник /За заг. ред. О.Д. Шарапова. - К.: КНЕУ, 2002. - 534 с.

4. Пасічник В.В., Резніченко В.А. Організація баз даних та знань. - К.: Видавнича група ВНУ, 2006. - 384 с.: іл.

5. Сергеев А.П. Microsoft Offise 2007: Самоучитель. - М.: Издательский дом "Вильямс", 2007. - 432 с.: ил.

6. Эффективная работа: Access 2002/Э.Феддема. - СПб.: Питер, 2003. - 944 с.: ил.

Размещено на Allbest.ru