Разработка информационной системы для аптечного склада

Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 32 страниц
В избранное:

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ

Учреждение образования
Гродненский государственный университет имени Янки Купалы

Факультет математики и информатики
Кафедра современных технологий программирования

ТАРАСОВА НАДЕЖДА АЛЕКСАНДРОВНА
САКОМСКАЯ ВЕРОНИКА ИГОРЕВНА

Разработка информационной системы
для аптечного склада

Курсовая работа по дисциплине
Системы баз данных
студенток 3 курса специальности
1 - 26 03 01 Управление информационными ресурсами дневной формы получения образования

Научный руководитель
Гуща Юлия Вальдемаровна,
старший преподаватель
кафедры современных технологий программирования

Гродно 2022
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 4
1.1 Описание предметной области 4
1.2 Используемые программные средства 7
1.2.1 СУБД PostgreSQL 7
1.2.2 JPA 10
ГЛАВА 2. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ 16
2.1 Концептуальная модель базы данных 16
2.2 Логическая модель базы данных 21
2.3 Физическая модель базы данных 25
ГЛАВА 3. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ПРИЛОЖЕНИЯ 26
3.1 Разработка структуры приложения 26
3.2 Программная реализация приложения 27
ГЛАВА 4. ТЕСТИРОВАНИЕ ПРИЛОЖЕНИЯ 30
4.1 Postman 30
4.2 Тестирование 30
ЗАКЛЮЧЕНИЕ 39
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 40

ВВЕДЕНИЕ

Во всем мире организации накапливают или уже накопили в процессе своей административно-хозяйственной деятельности большие объемы данных, в том числе и в электронном виде. Эти коллекции данных хранят в себе большие потенциальные возможности по извлечению новой аналитической информации, на основе которой можно и необходимо строить стратегию организации, выявлять тенденции развития рынка, находить новые решения, обусловливающие успешное развитие в условиях конкурентной борьбы. Для некоторых организаций такой анализ является неотъемлемой частью их повседневной деятельности, другие только начинают активно приступать к нему.
База данных (БД) - это некоторый набор данных, организованный по определенным правилам и имеющий определенную структуру. Другими словами база данных это хранилище данных. Базой данных можно считать не только таблицы, индексирующие файлы со знаниями разных форматов, но и сами эти файлы, потому что они являются не типизированными хранилищами знаний в такой базе данных. БД могут применяться как вспомогательное средство, позволяющее реализовать какую-то полезную функцию.
Целью данной курсовой работы является разработка базы данных для частной сети аптек, а также приложения, которое будет взаимодействовать с данной базой.
Проектирование базы будет проводиться на основе кроссплатформенной системы управления базами данных (СУБД) Postgres (PostgresSQL) и ее GUI-оболочки - DBeaver.
Для взаимодействия с созданной базой, будет разработано приложение на языке программирования Java и его EE-фреймворка Spring Boot, которой включает в себя проект Spring Data, который добавляет дополнительный уровень абстракции поверх реализации JPA и использует Hibernate, в качестве ORM провайдера чтобы выполнять запросы.
Для реализации поставленной цели необходимо сформулировать определенные задачи по рассмотрению программ-аналогов, выявлению методики проектирования и на основе структурирования полученного материала.

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

Описание предметной области

Каждая аптека определяется следующими параметрами:
Название;
Адрес;
Телефон;
Банковский счет.
Аптеки различаются своим уникальным идентификатором, однозначно характеризующим каждую аптеку.
С каждой аптекой связаны её сотрудники. Каждый сотрудник имеет уникальный идентификатор и о нём следует хранить следующую информацию:
Имя;
Фамилия;
Отчество;
Дата рождения;
Телефон;
E-mail;
Должность;
Аптека.
У аптеки имеется банковский счёт для закупки товара, а у поставщика для получения оплаты заказа. Счёт в банке характеризуется следующими параметрами:
Номер(IBAN);
Баланс.
Номер каждого счёта уникален и редко меняется, поэтому используется в качестве его уникального идентификатора.
К каждой аптеке относится ее личный склад. Данное решение было принято на основе работы частных аптек. Склад имеет уникальный идентификатор и характеризуется следующими параметрами:
Адрес;
Телефон;
Сотрудник (ответственный за доставку товара с каждого склада);
Аптека.
На складе хранятся товары. Каждая единица товара имеет свой уникальный идентификатор и характеризуется следующими параметрами:
Название;
Название действующего вещества;
Стоимость;
Поставщик.
Каждый товар на складе уникален. Нашими поставщиками являются сами фармакологические компании, поэтому на каждый препарат есть патент, из-за этого повторы в названиях исключаются.
Товар на склад поставляют поставщики. Каждый поставщик имеет уникальный идентификатор и характеризуется следующими параметрами:
Название;
Адрес;
Телефон;
Банковский счет.
Для каждого заказа, сделанного аптекой по поводу определенного количества товаров, фиксируется:
Дата;
Время;
Аптека.
Также в отдельную таблицу вынесен список городов. Это сделано в первую очередь из соображений нормализации. Данная таблица содержит уникальный ID для каждого города и следующие поля:
Название.
Создан список улиц. Данная таблица также содержит уникальный ID для каждой улицы и следующие поля:
Название;
Город.
И для хранения полных адресов складов, аптек и поставщиков создана таблица адрес. Каждый адрес имеет свой уникальный идентификатор и следующие поля:
Улица;
Дом.
Следует учесть также и некоторые ограничения:
Каждая единица товара может входить в несколько заказов и один заказ может содержать несколько товаров.
Запись о каждом заказе должна содержать количество единиц каждого заказываемого товара.
Каждая поставщик может поставлять несколько видов товаров, но каждый товар уникален для своего поставщика.
Общая сумма заказа формируется из расчёта стоимость каждого товара, умноженная на его количество.
Каждая аптека может совершать неограниченное количество заказов.
В базе должны храниться данные всех работников каждой из аптек.
Для каждого склада хранится информация о сотруднике ответственном за данный склад.
Каждый заказ должен содержать хотя бы одну единицу товара.
Каждый поставщик должен поставлять хотя бы один вид товара.
К автоматизированной системе будут иметь доступ следующие группы пользователей:
руководство аптеки;
сотрудники аптеки;
поставщики товара для аптечных складов.
При работе с системой Аптечный склад руководство аптек должно производить следующие действия:
модифицировать (добавлять, удалять, изменять) любую информацию, касающуюся аптек, сотрудников, складов, поставщиков, банковских счетов и заказов.
Сотрудники аптек должны выполнять следующие действия:
оформлять заказы на товар у определенных поставщиков;
получать(читать) информацию обо всех сделанных данной аптекой заказах (в том числе и за конкретный период времени).
Поставщики смогут выполнять следующие действия:
модифицировать (добавлять, удалять, изменять) информацию, касающуюся них и поставляемых ими лекарств;
выполнять доставку товара по заказу из аптеки.
Итак, целью создания автоматизированной системы "Аптечный склад" является программный продукт, удовлетворяющий перечисленным ранее требованиям, а также реализованный с использованием соответствующих СУБД и программного обеспечения.

Используемые программные средства

СУБД PostgreSQL

PostgreSQL - свободная объектно-реляционная система управления базами данных, основанная на языке SQL.
PostgreSQL является одной из наиболее популярных систем управления базами данных. Сам проект postgresql эволюционировал из другого проекта, который назывался Ingres. Формально развитие postgresql началось еще в 1986 году. Тогда он назывался POSTGRES. А в 1996 году проект был переименован в PostgreSQL, что отражало больший акцент на SQL.
С тех пор вышло множество версий postgresql. Текущей версией является версия 14. Однако регулярно также выходят подверсии.
Cписок возможностей предоставляемых PostgreSQL:
Надежность PostgreSQL является проверенным фактом и обеспечивается следующими возможностями:
полное соответствие принципам ACID - атомарность, непротиворечивость, изолированность, сохранность данных.
Atomicity - транзакция рассматривается как единая логическая единица, все ее изменения или сохраняются целиком, или полностью откатываются.
Consistency - транзакция переводит базу данных из одного непротиворечивого состояния (на момент старта транзакции) в другое непротиворечивое состояние (на момент завершения транзакции). Непротиворечивым считается состояние базы, когда выполняются все ограничения физической и логической целостности базы данных, при этом допускается нарушение ограничений целостности в течение транзакции, но на момент завершения все ограничения целостности, как физические, так и логические, должны быть соблюдены.
Isolation - изменения данных при конкурентных транзакциях изолированы друг от друга на основе системы версионности.
Durability - PostgreSQL заботится о том, что результаты успешных транзакций гарантировано сохраняются на жесткий диск вне зависимости от сбоев аппаратуры.
многоверсионность (Multiversion Concurrency Control,MVCC) используется для поддержания согласованности данных в конкурентных условиях, в то время как в традиционных базах данных используются блокировки. MVCC означает, что каждая транзакция видит копию данных (версию базы данных) на время начала транзакции, несмотря на то что состояние базы могло уже измениться. Это защищает транзакцию от несогласованных изменений данных.
наличие Write Ahead Logging (WAL) - общепринятый механизм протоколирования всех транзакций, что позволяет восстановить систему после возможных сбоев. Основная идея WAL состоит в том, что все изменения должны записываться в файлы на диск только после того, как эти записи журнала, описывающие эти изменения будут и гарантировано записаны на диск.
Point in Time Recovery (PITR) - возможность восстановления базы данных (используя WAL) на любой момент в прошлом, что позволяет осуществлять непрерывное резервное копирование кластера PostgreSQL.
Репликация также повышает надежность PostgreSQL. Существует несколько систем репликации, например, Slony, который является свободным и самым используемым решением, поддерживает master-slaves репликацию. Ожидается, что Slony-II будет поддерживать multi-master режим.
Целостность данных является сердцем PostgreSQL. Помимо MVCC, PostgreSQL поддерживает целостность данных на уровне схемы - это внешние ключи (foreign keys), ограничения (constraints).
Модель развития PostgreSQL, которая абсолютно прозрачна для любого, так как все планы, проблемы и приоритеты открыто обсуждаются. Пользователи и разработчики находятся в постоянном диалоге через мэйлинг листы. Все предложения, патчи проходят тщательное тестирование до принятия их в программное дерево. Большое количество бета - тестеров способствует тестированию версии до релиза и вычищению мелких ошибок.
Открытость кодов PostgreSQL означает их абсолютную доступность для любого, а либеральная BSD лицензия не накладывает никаких ограничений на использование кода.
Производительность PostgreSQL основывается на использовании индексов, интеллектуальном планировщике запросов, тонкой системы блокировок, системой управления буферами памяти и кэширования, превосходной масштабируемости при конкурентной работе.
Поддержка индексов:
Стандартные индексы - B-tree, hash, R-tree, GiST (обобщенное поисковое дерево);
Частичные индексы (partial indices);
Функциональные индексы.
Планировщик запросов основывается на стоимости различных планов, учитывая множество факторов. Он предоставляет возможность пользователю отлаживать запросы и настраивать систему.
Система блокировок поддерживает блокировки на нижнем уровне, что позволяет сохранять высокий уровень конкурентности при защите целостности данных. Блокировка поддерживается на уровне таблиц и записей. На нижнем уровне, блокировка для общих ресурсов оптимизирована под конкретную ОС и архитектуру.
Управление буферами и кэширование используют сложные алгоритмы для поддержания эффективности использования выделенных ресурсов памяти.
Tablespaces (табличные пространства) позволяют гибкое использование дискового пространства для хранения объектов системы, что также повышает производительность и масштабируемость.
Масштабируемость основывается на описанных выше возможностях. Низкая требовательность PostgreSQL к ресурсам и гибкая система блокировок обеспечивают его шкалирование, в то время как индексы и управление буферами обеспечивают хорошую управляемость системы даже при высоких загрузках.
Расширяемость PostgreSQL означает, что пользователь может настраивать систему путем определения новых функций, агрегатов, типов,языков, индексов и операторов. Объектно - ориентированность PostgreSQL позволяет перенести логику приложения на уровень базы данных, что сильно упрощает разработку клиентов, так как вся бизнес-логика находится в базе данных. Функции в PostgreSQL однозначно определяются названием, количеством и типами аргументов.

JPA

Разработка приложения осуществлялась на языке программирования Java. Стек технологий Java позволяет эффективно хранить и обрабатывать данные с помощью ORM.
ORM - Object-Relational Mapping или в переводе на русский объектно-реляционное отображение. Это технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования. Если упростить, то ORM это связь Java объектов и записей в БД.
ORM - это, по сути, концепция о том, что Java объект можно представить как данные в БД (и наоборот). Она нашла воплощение в виде спецификации JPA - Java Persistence API.
Спецификация - это уже описание Java API, которое выражает эту концепцию. Спецификация рассказывает, какими средствами должны быть обеспечены программисты (т.е. через какие интерфейсы им работать), чтобы работать по концепции ORM и как использовать эти средства.
JPA (Java Persistence API) это спецификация Java EE и Java SE, описывающая систему управления сохранением Java объектов в таблицы реляционных баз данных в удобном виде. Сама Java не содержит реализации JPA, однако есть существует много реализаций данной спецификации от разных компаний (открытых и нет). Это не единственный способ сохранения Java объектов в базы данных (ORM систем), но один из самых популярных в Java мире.
JPA оперирует таким понятием, как сущность Entity, которая является POJO - классом (простой Java-объект, не унаследованный от какого-то специфического объекта и не реализующий никаких служебных интерфейсов сверх тех, которые нужны для бизнес-модели) и связана с БД с помощью аннотации @Entity. К такому классу предъявляются следующие требования:
наличие пустого public или protected конструктора;
не должен быть вложенным, являться интерфейсом или enum;
не должен быть final и не должен содержать final-свойств;
должен включать хотя бы одно @Id-поле.
Каждый Entity-компонент характеризуется своим уникальным идентификатором - primary key. Это тот же самый primary key, что и идентификатор данных в БД, например, совокупность ключевых полей записи в таблице.
При этом сущность может иметь непустые конструкторы, наследоваться или быть унаследованной, содержать методы, не связанные со свойствами (методы getset), и реализовывать интерфейсы. Entities могут быть связаны друг с другом (один-к-одному, один-ко-многим, многие-к-одному и многие-ко-многим).
JPA обрабатывает это с помощью аннотаций. Есть четыре аннотации отношений:
@OneToOne;
@OneToMany;
@ManyToOne;
@ManyToMany.
Entity-компоненты представляют собой объектное представление данных из БД. Например, Entity-компонент может моделировать одну запись из таблицы реляционной базы данных. Несколько клиентов могут одновременно обращаться к одному экземпляру такого Компонента. Entity-компоненты изменяют состояние сопоставленных с ними баз данных в контексте транзакций.
Состояние Entity-компонентов в нужно сохранять, и существуют они столько, сколько существуют в базе данных те данные, которые они представляют. Остановка контейнера EJB не приводит к уничтожению содержащихся в нем Entity-компонентов.
Преимущества использования JPA:
Для выполнения статических и динамических запросов в JPA используется собственный язык запросов, схожий с SQL. При использовании языка запросов Java Persistence Query Language (JPQL) приложения можно переносить между базами данных различных поставщиков.
Можно избежать написания низкоуровневого кода JDBCSQL.
JPA предоставляет прозрачные службы для кэширования данных и оптимизации производительности.
Реализацию средств спецификация не описывает. Это даёт возможность использовать для одной спецификации разные реализации. Можно упростить и сказать, что спецификация - это описание API.
Реализации JPA называется JPA Provider. Одной из самых заметных реализаций JPA является Hibernate. Она и была выбрана нами в качестве ORM для нашего приложения "Аптечный склад".
Hibernate одна из самых популярных открытых реализаций спецификации JPA. То есть JPA только описывает правила и API, а Hibernate реализует эти описания, впрочем у Hibernate (как и у многих других реализаций JPA) есть дополнительные возможности, не описанные в JPA (и не переносимые на другие реализации JPA).
Hibernate - это библиотека с открытым исходным кодом (open source) для Java, предназначенная для решения задач ORM (object-relational mapping, объектно-реляционного отображения). Hibernate Framework имеет легкий в использовании каркас для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных и предоставляет стандартные средства JPA.
Библиотека Hibernate является одним из самых востребованных ORM фреймворков для Java, поскольку:
позволяет разработчику сосредоточиться на бизнес логике, не отвлекаясь на управление ресурсами;
предоставляет собственный язык запросов (HQL), внешне похожий на SQL. Необходимо отметить, что HQL полностью объектно-ориентирован и понимает такие принципы, как наследование, полиморфизм и ассоциации (связи);
может использовать также чистый SQL, а, следовательно, поддерживает возможность оптимизации запросов и работы с любым сторонним провайдером БД;
поддерживает JPA аннотации, что позволяет сделать реализацию кода независимой;
поддерживает разные уровни cache, следовательно может повысить производительность;
поддерживает ленивую инициализацию используя proxy объекты и выполняя запросы к базе данных только по необходимости;
интегрируется с другими Java EE фреймворками; например, Spring Framework поддерживает встроенную интеграцию с Hibernate;
является широко распространенным open source продуктом. Благодаря этому доступны тысячи открытых статей, примеров, а также документация по использованию фреймворка.
Важные аннотации для отображения в Hibernate.
Наиболее употребляемые аннотации Hibernate из пакета javax.persistence представлены в следующей таблице:

Таблица 1.1 - Основные аннотации Hibernate

Аннотация
Действие
@Entity
Определение класса как сущность entity bean
@Table, @Column
Определение таблицы в БД и наименования колонки в таблице
@Id
Поле Primary Key в сущности entity bean
@GeneratedValue
Определение стратегии создания основных ключей
@SequenceGenerator
Определение генератора последовательности
@OneToMany, @ManyToOne, @ManyToMany
Определение связи между сущностными бинами

Hibernate может использовать прокси для поддержки отложенной загрузки. При соответствующем атрибут fetch аннотации связи (fetch определяет стратегию загрузки дочерних объектов) из базы данных не загружаются связанные объекты. При первом обращении к дочернему объекту с помощью метода get, если связанная сущность отсутствует в кэше сессии, то прокси код перейдет к базе данных для загрузки связанной сущности. Мы воспользовались данной функцией в нашем приложении для увеличения быстродействия.
При наличии зависимостей (связей) между сущностями необходимо определить влияние различных операций одной сущности на связанные. Это можно реализовать с помощью аннотации каскадных связей @Cascade. Пример использования @Cascade в нашем приложении:

----------------------------------- ----------------------------------- ----------
@Data
----------------------------------- ----------------------------------- ----------
@NoArgsConstructor
----------------------------------- ----------------------------------- ----------
@AllArgsConstructor
----------------------------------- ----------------------------------- ----------
@Entity
----------------------------------- ----------------------------------- ----------
@Table(name = "pharmacies")
----------------------------------- ----------------------------------- ----------
public class Pharmacy {
----------------------------------- ----------------------------------- ----------

----------------------------------- ----------------------------------- ----------
@Id
----------------------------------- ----------------------------------- ----------
@GeneratedValue(strategy = GenerationType.IDENTITY)
----------------------------------- ----------------------------------- ----------
private long id;
----------------------------------- ----------------------------------- ----------
@Column(name = "name")
----------------------------------- ----------------------------------- ----------
private String name;
----------------------------------- ----------------------------------- ----------
@OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
----------------------------------- ----------------------------------- ----------
@JoinColumn(name = "address_id")
----------------------------------- ----------------------------------- ----------
private Address address;
----------------------------------- ----------------------------------- ----------
@Column(name = "phone")
----------------------------------- ----------------------------------- ----------
private String phone;
----------------------------------- ----------------------------------- ----------
@OneToOne(cascade = CascadeType.ALL)
----------------------------------- ----------------------------------- ----------
@JoinColumn(name = "account_iban")
----------------------------------- ----------------------------------- ----------
private Account account;
----------------------------------- ----------------------------------- ----------
@OneToOne(mappedBy = "pharmacy", cascade = CascadeType.ALL)
----------------------------------- ----------------------------------- ----------
private Warehouse warehouse;
----------------------------------- ----------------------------------- ----------
@OneToMany(mappedBy = "pharmacy", cascade = CascadeType.ALL)
----------------------------------- ----------------------------------- ----------
private ListEmployee staff;
----------------------------------- ----------------------------------- ----------
@OneToMany(mappedBy = "pharmacy", cascade = CascadeType.ALL)
----------------------------------- ----------------------------------- ----------
private ListOrder orders;
----------------------------------- ----------------------------------- ----------
}

Листинг 1.1 - Entity-класс для описания свойств аптеки, её связей с другими сущностями и сопоставлением со столбцами таблицы pharmacies в БД.

Также мы использовали фреймворк Spring Data JPA, который добавляет дополнительный уровень абстракции поверх ORM реализации JPA. По умолчанию Spring Data JPA использует Hibernate, в качестве ORM провайдера (чтобы выполнять запросы).
Так как мы использовали Spring Boot вместе с Spring Data JPA, то обладали всеми необходимыми настройками подключения Java приложения к базе данных. В настроечном yml-файле мы указали это хост для нашей базы данных, имя пользователя и пароль для доступа к ней. Spring Boot обеспечивает автоматическую настройку для всего подключения к базе. В том числе и пул соединений:

----------------------------------- ----------------------------------- ----------
spring:
----------------------------------- ----------------------------------- ----------
datasource:
----------------------------------- ----------------------------------- ----------
url: jdbc:postgresql:localhost:5434ph armacyWarehouseDB
----------------------------------- ----------------------------------- ----------
username: nadezhda
----------------------------------- ----------------------------------- ----------
password: nadezhda
----------------------------------- ----------------------------------- ----------
driver-class-name: org.postgresql.Driver
----------------------------------- ----------------------------------- ----------
jpa:
----------------------------------- ----------------------------------- ----------
hibernate.ddl-auto: none
----------------------------------- ----------------------------------- ----------
database-platform: org.hibernate.dialect.PostgresPlusD ialect
----------------------------------- ----------------------------------- ----------
show-sql: true
----------------------------------- ----------------------------------- ----------
liquibase:
----------------------------------- ----------------------------------- ----------
change-log: classpath:changelog-master.xml
----------------------------------- ----------------------------------- ----------
enabled: true

Листинг 1.2 - Настроечный yaml файл Spring Boot проекта.

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

Концептуальная модель базы данных

Концептуальная модель - это отражение предметной области, для которой разрабатывается база данных. Не вдаваясь в теорию, отметим, что это некая диаграмма с принятыми обозначениями элементов. Так, все объекты, обозначающие вещи, обозначаются в виде прямоугольника. Атрибуты, характеризующие объект - в виде овала, а связи между объектами - ромбами. Мощность связи обозначаются стрелками (в направлении, где мощность равна многим - двойная стрелка, а со стороны, где она равна единице - одинарная).
Концептуальная модель данных разрабатывается независимо от ограничений, вытекающих из ... продолжение

Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.