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

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

Міністерство освіти і науки України

Львівський Державний коледж харчової і переробної промисловості

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

Розрахунково-пояснювальна записка курсової роботи

з дисципліни «Об'єктно-орієнтоване програмування»

на тему: Розробка бази даних універмагу

студента ІІІ курсу групи ПК-3

спеціальності 122 «Комп'ютерні науки і інформаційні технології»

Захаряк О.І.

Львів - 2019 рік



ВСТУП

діаграма атрибут даталогічний база

Все більше інформації опрацьовується у світі. Якщо ще століття тому ніхто і подумати не міг про гігабайти даних, то на даний час людство задумується про терабайти та петабайти, що відповідно на 3 та 6 порядків більше [1].

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

Метою курсової роботи є розробка бази даних універмагу.

Для досягнення даної мети слід вирішити наступні завдання:

· Більш докладно дослідити об'єкт універмаг.

· Дослідити принципи здачі приміщень в оренду.

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



1. ВИЗНАЧЕННЯ ТА ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ

1.1. Опис предметної області бази даних

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

Облік орендарів та приміщень зручніше всього вести в електронних таблицях. Проте засоби табличних процесорів на кшталт Excel не дозволяють пов'язувати дані. На щастя даний функціонал присутній в Access.

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

1.2. Мета і завдання дослідження

Завдання бази даних є автоматизувати процес обробки та обліку даних у торговому центрі. А саме дані про приміщення, орендарів, працівників та графік оренди.

Основними завданнями бази даних є:

· Створення, редагування, перегляд та видалення даних про приміщення.

· Створення, редагування, перегляд та видалення даних про працівників універмагу.

· Створення, редагування, перегляд та видалення даних про орендарів.

· Створення, редагування, перегляд та видалення даних про оренду приміщень орендарями.

· Можливість перегляду заробітніх плат працівників.

· Можливість перегляду звільнених працівників.

· Перегляд посад працівників.

1.3. Специфікація вимог для користувачів

Вимоги до даних для користувача системи:

· Основним обліковим активом є приміщення, що здаються в оренду.

· Орендарі орендують приміщення на певний час.

· У кожного приміщення є орендар, якщо воно орендується

· У кожного приміщення є список працівників, що мають до нього доступ.

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



2. КОНЦЕПТУАЛЬНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ

2.1. Відомості про тими сутностей

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

· Пиміщення

· Орендар

· Працівник

· Оренда

Результати представлено в таблиці 2.1.

Таблиця 2.1 Відомості про тими сутностей

Ім'я сутності	Опис	Псевдоніми	Особливості використання
Приміщення	Описує приміщення	Приміщення	Його орендують
Орендар	Людина, що орендує приміщення	Орендар	Орендує приміщення
Працівник	Людина, що працює в певному приміщенні	Працівник	Працює в приміщенні
Оренда приміщення	Сутність що описує терміни та сторони оренди приміщення	Оренда	Містить орендаря, приміщення, працівника та терміни оренди

2.2. Визначення типів зв'язків

Наступний крок - визначення кратності та рівня участі для кожного зв'язку. Кратність зв'язку буває один до одного(1:1), один до багатьох(1:Б), багато до одного (Б:1) та багато до багатьох (Б:Б).

Результати аналізу представлені в таблиці 2.2.



Таблиця 2.2. Визначення типів зв'язків

Сутність А	Сутність Б	Тип зв'язку	Кратність
Приміщення	Оренда	Орендується	1:Б
Орендар	Оренда	Орендує	1:Б
Працівник	Оренда	Працює	1:Б

2.3. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків

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

Зведення про атрибути наведено в таблиці 2.3.

Таблиця 2.3 Зведення про атрибути

Тип сутності	Атрибут	Тип даних	Обмеження	Значення за замовчуванням	Допустмість	Похідний
Приміщення	ID приміщення	INT	Первинний ключ		Ні	Ні
	Номер приміщення	INT			Ні	Ні
Приміщення	Поверх	INT			Ні	Ні
	Площа	Double			Ні	Ні
	Кошторис	Double			Ні	Ні
	Короткий текст	String(200)			Ні	Ні
Орендар	ID орендаря	INT	Первинний ключ		Ні	Ні
	ПІБ	String(200)			Ні	Ні
	Назва	String(200)			Ні	Ні
	Email	String(200)			Ні	Ні
Працівники	ID працівника	INT	Первинний ключ		Ні	Ні
	ПІБ працівника	String(200)			Ні	Ні
	Домашня адреса	String(200)			Ні	Ні
	Номер телефону	String(200)			Ні	Ні
	email	String(200)			Ні	Ні
Працівники	Посада	String(200)			Ні	Ні
	Заробітна плата	INT			Ні	Ні
	Дата прийому на роботу	DateTime			Ні	Ні
	Дата звільнення	DateTime			Ні	Ні
Оренда	ID запису	INT	Первинний ключ		Ні	Ні
	ID приміщення	INT	Зовнішній ключ		Ні	Ні
	ID орендаря	INT	Зовнішній ключ		Ні	Ні
	Початок оренди	DateTime			Ні	Ні
	Кінець оренди	DateTime			Ні	Ні
	ID працівника	INT	Зовнішній ключ		Ні	Ні

2.4. Визначення доменів атрибутів

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

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

Таблиця 2.4. Зведення про домени атрибутів поміщені в документацію

Ім'я домену	Характеристики домену	Зразки допустимих значень
Номер приміщення	Ціле від 1 до 9999	1, 3, 15, 26, 458, 654, 9999
Поверх	Ціле, від 1 до 999	1, 2, 3, 5, 9
Площа	Число з плаваючою крапкою від 0 до 999,99	24.65, 64.87, 67.32, 12.71
Дата	Дата від 2000 року	16.11.2019, 06.08.2019, 01.11.2019
ПІБ	Прізвище, ім'я, по батькові	Волошин Марія Іванівна, Тереско Петро Віталійович
Номер телефону	Код країни та 10 цифр	+382987654321, 380981234567
Email	Правила назв емейлів	Voloshun@gmail.com, Petrosyan@gmail.com

2.5. Визначення атрибутів що є потенційними та первинними ключами

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

Таблиця 2.5 Зведення про альтернативні та первинні ключі поміщені в документацію

Сутність	Первинний ключ	Альтернативний ключ
Приміщення	ID приміщення	Номер приміщення
Орендар	ID орендаря	ПІБ
Працінивк	ID працівника	ПІБ працівника
Оренда	ID запису	-

2.6. Створення діаграми “сутність-зв'язок”

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



Рис. 2.1 Діаграма “сутність-зв'язок”



3. ЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ

3.1. Аналіз реляційної схеми на коректність об'єднання атрибутів в одному відношенні

Створений на попередніх етапах набір відношень логічної моделі бази даних повинен бути перевірений на коректність об'єднання атрибутів у кожному відношенні. Перевірка відбувається шляхом застосування до кожного відношення процедури нормалізації. Атрибути після нормалізації будуть згруповані відповідно до своїх зв'язків [3,4].

3.2. Створення логічної моделі бази даних на основі створеної ER-моделі

Як результат попередніх етапів була створена ER-модель представлена на рисунку 3.1.

Рис.3.1. ER-моделі “Універмаг”



3.3. Застосування послідовної нормалізації до відношень

У даній базі даних представлено наступні відношення:

· Приміщення.ID приміщення та Оренда приміщень.ID приміщення

· Орендарі.ID орендаря та Оренда приміщень.ID орендаря

· Працівники.ID працівника та Оренда приміщень.ID працівника

Кожна пара ключів має тип INT

Оскільки відношення багато до багатьох на даному етапі відсутнє, то подальша нормалізація не має сенсу.

3.4. Обґрунтування вибору СУБД

Для реалізації даної роботи була обрана СУБД MS Access 2016, оскільки дана лінійка СУБД являється частиною пакету MS Office і є відносно простою для освоєння [5-7].

Основні компоненти MS Access:

· конструктор таблиць;

· конструктор екранних форм;

· конструктор SQL-запитів (мова SQL в MS Access не відповідає стандарту ANSI);

· конструктор звітів, що виводяться на друк.

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

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

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

Цілісність даних в Access забезпечується також за рахунок механізму транзакцій[9-11].

Кнопка «Зберегти» в Access теж є, але в Access у режимі перегляду даних вона потрібна, в першу чергу, для збереження зміненого режиму показу таблиці або іншого об'єкта - тобто, для збереження таких змін, як:

· зміна ширини стовпців і висоти рядків,

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

· зміна сортування,

· застосування нового фільтра,

· зміна шрифту; кольору тексту, сітки і тла

· і багато іншого

Крім того, в Access ця кнопка потрібна в режимі «Конструктор» для збереження змін структури об'єкта бази даних, зроблених в цьому режимі [9, 13].



4. РЕАЛІЗАЦІЯ БАЗИ ДАНИХ В СУБД ACCESS

4.1. Створення бази даних засобами СУБД Access

Було створено 4 таблиці що описують приміщення, працівників, орендарів та сам процес оренди. Їх представлено на рис. 4.1. - 4.4. що зображено нижче

Рис.4.1. Інформація про приміщення

Рис.4.2. Працівники універмагу

Рис.4.3 Оренда приміщення



Рис.4.4. Орендарі

4.2. Побудова даталогічної моделі бази даних

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

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

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



Рис.4.5. Схема даних БД “Універмаг”

4.3. Засоби автоматизації управління системою

Для автоматизації управління системою було написано 7 макросів та 5 форм.

Рис.4.6. Список запитів у СУБД “Універмаг”

На рис 4.7. -4.10. наведені результати виконання запитів.



Рис.4.7. результат запиту З/П від 4500

Рис.4.8. результат запиту Звільнені у 2019

Рис.4.9. результат запиту Комірчини

Рис.4.10. результат запиту Перелік продавців

Також було реалізовано 4 форми для редагування записів та одна для швидкого доступу до всіх форм та записів.



Рис.4.11. Список форм у СУБД “Універмаг”

Рис.4.12. Форма Оренда



Рис.4.13. Форма Орендарі

Рис.4.14. Форма Працівники



Рис.4.15. Форма Приміщення

Рис.4.16. Форма Головне меню

4.4. Керівництво користувача

Для початку роботи з програмою потрібно відкрити проект бази даних в середовищі MS Access. Потім, відкрити форму головного меню зображену вище. На даній формі є відповідні кнопки для швидкого переходу на інші форми та запити, а також кнопка закриття бази даних.

В лівій частині форми є основні запити

Рис.4.17. Запити на головній формі

По центру головної форми є переходи на інші форми.

Рис.4.18. Переходи на інші форми

В правій частині форми, представлені деякі операції з таблицею орендарів в базі.



Рис.4.19. Операції з орендарями

І на сам кінець в правому верхньому кутку є кнопка закриття форми.

Рис.4.20. Кнопка закриття бази даних



ВИСНОВКИ

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

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

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



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

1. Лорі Ульріх Фуллер, Кен Кук. Access 2010 для чайников = Access 2010 For Dummies. -- М.: «Диалектика», 2010. -- С. 384. -- ISBN 978-5-8459-1707-2.

2. Элісон Балтер. Microsoft Office Access 2007: профессиональное программирование = Alison Balter's Mastering Microsoft Office Access 2007 Development. -- М.: «Вильямс», 2008. -- С. 1296. -- ISBN 978-5-8459-1505-4.

3. Майкл Грох, Джозеф Стокман, Гэвин Пауэлл. Microsoft Office Access 2007. Библия пользователя = Microsoft Office Access 2007 Bible. -- М.: «Диалектика», 2008. -- С. 1200. -- ISBN 978-5-8459-1485-9.

4. Джон Кауфельд , Microsoft Office Access 2003 для «чайников» / Пер. с англ. -- М.: 2006. -- 320 стр. с ил., Издательство «Диалектика».

5. Метью Мак-Дональд. Access 2007. Недостающее руководство = Access 2007 The missing manual. -- СПб.: «БХВ-Петербург», 2007. -- С. 784. -- ISBN 978-5-7502-0343-3.

6. Гандерлой Автоматизация Microsoft Access с помощью VBA / Гандерлой, Харкинз Майк; , Сейлз Сьюзан. - М.: Вильямс, 2013. - 416 c.

7. Голишева, А. В. Access 2007 без воды. Все, что нужно для уверенной работы / А.В. Голышева, И.А. Клеандрова, Р.Г. Прокди. - М.: Наука и техника, 2012.

8. Грінченко Проектирование баз данных. СУБД Microsoft Access / Гринченко, Н.Н. и. - М.: Горячая Линия Телеком, 2014.

9. Гурвіц, Г. Microsoft Access 2010. Разработка приложений на реальном примере / Г. Гурвиц. - М.: БХВ-Петербург, 2017.

10. Джонс, Эдвард Access 97: книга ответов / Эдвард Джонс , Джарел Джонс. - М.: Питер, 2016.

11. Епанешніков, А. М. Практика создания приложений в Access / А.М. Епанешников, В.А. Епанешников. - Москва: СИНТЕГ, 2017.

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