Проектування бази даних та розробка інформаційної підсистеми

Таблиця 2.2 - Опис реквізитів вхідної інформації

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

Уся вхідна інформація вводиться через форми та зберігається у таблицях.

Форма 2.1 - Форма вхідного документа «Клієнти»

Код клієнту

Прізвище

Адреса

Місто

Форма 2.2 - Форма вхідного документа «Співробітники»

Код співробітника

ПІБ

Стать

Заробітна плата

Стаж

Форма 3.3 - Форма вхідного документа «Фірма виробник»

Код виробника

Виробник

Країна

Місто

Форма 2.4 - Форма вхідного документа «Товари»

Порядковий номер

Товар

Виробник

Початкова кількість

Кількість

Ціна

Дата поставки

Умови зберігання

2.3 Опис вихідної інформації

Вихідною інформацією задачі для користувача будуть звіти.

Вихідна інформація зазначена у таблиці

Таблиця 2.3 - Вихідна інформація

Форма вихідного документа зі списком замовлень на дату

Звіт

Замовлення на дату

Форма вихідного документа з інформацією про замовленням по відділу

Звіт

Замовлення за період

Форма вихідного документа з загальною вартістю проданих товарів

Звіт

Видати чек

Форма вихідного документа з відомостями про замовлення

Звіт

Номер замовлення

Назва товару

Кількість

Виробник

Кількість замовлення

Ціна

Підсумок

3. Алгоритм проектування

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

Рисунок 3.- Алгоритм проектування підсистеми

4. Проектування інформаційної моделі

4.1 Визначення концептуальної моделі

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

- аналіз інформаційних потреб користувачів/замовника та попереднє визначення звітів та/або форм, які їм потрібні;

- аналіз елементів даних, що використовуються в кожному із звітів та/або формі;

- вилучення синонімії, омонімії та узагальнення атрибутів;

- визначення основних процедур перетворення інформації (бізнес-правил).

Ці моделі частіше за все класифікують як об'єктні. В якості засобів моделювання найчастіше обирають семантичне моделювання за допомогою ER-діаграм. ER- діаграма предметної області наведена в рисунку 4.1 (див с.17). Концептуальний проект є обґрунтуванням обраних об'єктних множин та зв'язків між ними[6].

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

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

Існують наступні нормальні форми:

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

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

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

Рисунок 4.1 - ER- діаграма предметної області

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

Таблиця 4.1 - Реквізитний склад інформаційних об'єктів

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

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

Таблиця 4.2 - Зв'язки інформаційних об'єктів

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

21).

Рисунок 4.2 - Логічна структура реляційної бази даних

4.3 Тестування підсистеми

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

Дані, призначені для тестування, налагодження і демонстрації рішення, наведені в рисунках 4.3- 4.8.

Рисунок 4.3 - Дані звіту «Видати чек»

Рисунок 4.4 - Дані звіту «Замовлення за період»

Рисунок 4.5 - Дані звіту «Замовлення на дату»

Рисунок 4.6 - Дані звіту «Замовлення по відділу»

Рисунок 4.7 - Дані звіту «Список товарів за виробником»

Рисунок 4.8 - Дані звіту «Товарний залишок»

4.4 Побудова запитів на мові SQL

Запит 1

Завдання: Побудувати запит, який знаходив би інформацію про товар за назвою.

SELECT Товары.[Порядковый номер], Товары.[Название товара], Товары.[Код производителя], Товары.Количество, Товары.Цена

FROM Товары

WHERE (((Товары.[Название товара])=[Введите название товара]));

Запит 2

Завдання: Побудувати запит, який виводив би інформацію про всі замовлення.

SELECT Заказы.[Номер заказа], Заказы.[Номер отдела], Заказы.[Дата заказа], Заказы.Оплачено, Заказы.[Код клиента], Товары.[Название товара], Товары.[Код производителя], Товары.Количество, Товары.Цена, [Заказ Товара].Заказано_количество

FROM Товары INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN [Заказ Товара] ON Заказы.[Номер заказа] = [Заказ Товара].[Код заказа]) ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер]

ORDER BY Товары.[Название товара];

Запит 3

Завдання: Створити запит, який би змінював кількість товару.

UPDATE Товары INNER JOIN [Заказ Товара] ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер] SET Товары.Количество = [Товары]![Количество]-[Заказ Товара]![Заказано_количество]

WHERE ((([Заказ Товара].[Код заказа])=[Формы]![Новый заказ]![Номер заказа]));

Запит 4

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

SELECT Заказы.[Номер заказа], [Заказ Товара].[Порядковый номер], Товары.Цена, [Заказ Товара].Заказано_количество, [Цена]*[Заказано_количество] AS Стоимость

FROM Товары INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN [Заказ Товара] ON Заказы.[Номер заказа] = [Заказ Товара].[Код заказа]) ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер]

ORDER BY Заказы.[Номер заказа];

Запит 5

Завдання: Створити запит, який би виводив інформацію про замовлення за деякий період.

SELECT Заказы.[Номер заказа], Заказы.[Номер отдела], Заказы.[Дата заказа], Заказы.Оплачено, Заказы.[Код клиента], [Заказ Товара].[Порядковый номер], Товары.Цена, [Заказ Товара].Заказано_количество, [Цена]*[Заказано_количество] AS Стоимость, Сотрудники.ФИО

FROM Сотрудники INNER JOIN (Товары INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN [Заказ Товара] ON Заказы.[Номер заказа] = [Заказ Товара].[Код заказа]) ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер]) ON Сотрудники.[Код сотрудника] = Заказы.[Код сотрудника]

WHERE (((Заказы.[Дата заказа]) Between [Введите начало периода] And [Введите конец периода]))

ORDER BY Заказы.[Номер заказа];

Запит 6

Завдання: Побудувати запит, який би виводив інформацію про замовлення за дату.

SELECT Заказы.[Номер заказа], Заказы.[Номер отдела], Заказы.[Дата заказа], Заказы.Оплачено, Заказы.[Код клиента], [Заказ Товара].[Порядковый номер], Товары.Цена, [Заказ Товара].Заказано_количество, [Цена]*[Заказано_количество] AS Стоимость, Сотрудники.ФИО

FROM Сотрудники INNER JOIN (Товары INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN [Заказ Товара] ON Заказы.[Номер заказа] = [Заказ Товара].[Код заказа]) ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер]) ON Сотрудники.[Код сотрудника] = Заказы.[Код сотрудника]

WHERE (((Заказы.[Дата заказа])=[Введите дату заказов]))

ORDER BY Заказы.[Номер заказа];

Запит 7

Завдання: Створити запит, який би виводив інформацію про залишок товарів.

SELECT Товары.[Порядковый номер], Товары.[Название товара], Товары.[Начальное количество], Товары.Количество, [Количество]-[Начальное количество] AS Заказано

FROM Товары;

Запит 8

Завдання: Побудувати запит, який би виводив інформацію про замовлення за його номером.

SELECT Заказы.[Номер заказа], Заказы.[Номер отдела], Заказы.[Дата заказа], Заказы.Оплачено, Заказы.[Код клиента], [Заказ Товара].[Порядковый номер], Товары.[Название товара], Товары.Цена, [Заказ Товара].Заказано_количество, [Цена]*[Заказано_количество] AS Стоимость, Сотрудники.ФИО

FROM Сотрудники INNER JOIN (Товары INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN [Заказ Товара] ON Заказы.[Номер заказа] = [Заказ Товара].[Код заказа]) ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер]) ON Сотрудники.[Код сотрудника] = Заказы.[Код сотрудника]

WHERE (((Заказы.[Номер заказа])=[Введите номер заказа]))

ORDER BY Заказы.[Номер заказа];

Запит 9

Завдання: Побудувати запит, який виводив би інформацію про замовлення за відділом.

SELECT Заказы.[Номер заказа], Заказы.[Номер отдела], Заказы.[Дата заказа], Заказы.Оплачено, [Заказ Товара].[Порядковый номер], [Заказ Товара].Заказано_количество, [Цена]*[Заказано_количество] AS Стоимость, Сотрудники.ФИО

FROM Сотрудники INNER JOIN (Товары INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN [Заказ Товара] ON Заказы.[Номер заказа] = [Заказ Товара].[Код заказа]) ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Товары.[Порядковый номер] = [Заказ Товара].[Порядковый номер]) ON Сотрудники.[Код сотрудника] = Заказы.[Код сотрудника]

WHERE (((Заказы.[Номер отдела])=[Введите номер отдела]))

ORDER BY Заказы.[Номер заказа];

Запит 10

Завдання: Створити запит, який знаходив би інформацію про клієнта за прізвищем.

SELECT Клиенты.[Имя клиента], Клиенты.Город, Клиенты.Адресс

FROM Клиенты

WHERE (((Клиенты.[Имя клиента])=[Введите фамилию клиента]));

Запит 11

Завдання: Побудувати запит, який знаходив би інформацію про замовлення за його номером.

SELECT Заказы.[Номер заказа], Заказы.[Номер отдела], Заказы.[Код клиента], Заказы.Оплачено, Заказы.[Дата заказа], Заказы.[Код сотрудника]

FROM Заказы

WHERE (((Заказы.[Номер заказа])=[Введите номер заказа]));

5. Розробка інформаційної підсистеми

5.1 Інтерфейс підсистеми

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

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

- система повинна допомагати виконати завдання, а не ставати завданням для користувача;

- при роботі з системою користувач не повинен відчувати себе необізнаним.

Перший принцип - це прозорість інтерфейсу. Інтерфейс повинен бути легким для освоєння і не створювати перед користувачем перешкоду, яку він повинен подолати, щоб приступити до роботи [5].

При розробці поставленої задачі було використано об'єктно-орієнтоване програмування (ООП). ООП - це методологія програмування, яка ґрунтується на змалюванні програми у вигляді сукупності об'єктів[9].

Інтерфейс має складатися з таких частин:

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

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

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

Після запуску бази даних Торгівельна мережа «Єва».mdb на екрані з'являється стартова форма програми, представлена на рисунку 5.1.

Рисунок 5.1 - Стартова форма

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

5.2 Опис автоматизованих функцій

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

Пошук та додавання даних виконується вбудованими функціями програми.

При виконанні програми були перевірені усі її функції.

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

Усі форми виконані за допомогою Конструктора та Майстра форм.

Усі запити були створені за допомогою Конструктора та Майстра форм.

Звіти були створені через Майстер звітів.

Висновки

Був розроблений курсовий проект на тему: Проектування бази даних та розробка інформаційної підсистеми «Облік продажу продукції у торгівельній мережі «Єва»». Проект дозволяє автоматизувати роботу продавця, що веде облік продажу товару в магазині.

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

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

При розробці проекту були вдосконалені та отримані нові знання в області проектування та створення ІПС в СУБД Microsoft Office Access.

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

1. Апопій В.В., Міщук І. П., Ребицький В.М. та ін. Організація торгівлі[Текст]: Підручник. - 2-е вид., перероб і доп. / За ред. В.В. Апопія. - К.: Центр навчальної літератури, 2005. - 616 с.

2. Берко А.Ю., Верес О.М., Пасічник В.В. Організація баз даних та знань: Навчальний посібник. [Текст] - Л.: Магнолія 2006, 2008. - 456 с.

3. Гайна Г.А. Основи проектування баз даних: Навчальний по- сібник. Текст] -К., 2008; - 200 с;

4. Дейт, К. Дж. Введення до систем баз даних [Текст] / К. Дж. Дейт. - К. : Вільямс, 2002. - 1328 с.

5. Карпова, Т.С. Базы данных: модели, разработка, реализация [Текст] / Карпова Т.С. - СПб. : Питер, 2001. - 304 с.

6. Методичні вказівки щодо виконання курсового проекту з дисципліни «Бази даних» [Текст] Уклад.: Н.І. Карлова, Ю.В. Арбузова- Херсон: ХПТК ОНПУ.- 2012, 40c.

Додаток А

Роздрук екранних форм

Рисунок А.1 - Роздрук екранних форм (головна форма)

Рисунок А.2 - Роздрук екранних форм (каталог товарів)

Рисунок А.3 - Роздрук екранних форм (замовлення товару)

Рисунок А.4 - Роздрук екранних форм (робота з клієнтами)

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