Осуществление интеграции программных модулей

Содержание

Введение

Практическая подготовка будущего специалиста в области информационных технологий является основой формирования профессиональных компетенций, поскольку позволяет закрепить теоретические знания и освоить реальные инструменты разработки программного обеспечения. Деятельность современной аптечной организации неразрывно связана с обработкой больших объёмов данных о лекарственных препаратах, поставщиках, закупках, сроках годности и реализации товаров, поэтому проектирование надёжной базы данных приобретает особую актуальность: именно она обеспечивает целостность, непротиворечивость и оперативность доступа к сведениям, а следовательно, и эффективность управления предприятием. Кроме того, требования к учёту лекарственных средств ужесточаются, а ассортимент постоянно расширяется, что делает централизованное хранение данных не удобством, а обязательным условием корректной работы аптеки. Этим обусловлена практическая значимость настоящей работы.

Практика проходила на базе ООО «Аптека-Сервис», основным направлением деятельности которого является розничная реализация лекарственных препаратов, изделий медицинского назначения и сопутствующих товаров. Предприятие имеет складской запас, работает с несколькими поставщиками и ведёт ежедневный учёт движения товаров, что формирует устойчивый поток учётной информации. Объектом исследования выступает аптечная организация и её информационная среда, предметом — процессы проектирования, реализации и интеграции базы данных аптеки средствами СУБД Microsoft SQL Server.

Цель практики — закрепление теоретических знаний и приобретение практических навыков разработки и интеграции программных модулей, обеспечивающих хранение и обработку данных аптеки.

Для достижения поставленной цели предусмотрено решение следующих задач:

– ознакомиться с организационно-правовой формой, структурой и основными направлениями деятельности предприятия;<br>– изучить нормативно-правовую базу и внутреннюю документацию, регламентирующую учёт товаров и работу с данными;<br>– проанализировать предметную область и информационные потоки аптечной организации;<br>– спроектировать логическую и физическую модели базы данных и реализовать её средствами T-SQL;<br>– протестировать базу данных и обеспечить интеграцию её модулей с прикладным приложением.

При выполнении работы применялись методы наблюдения, изучения документации, анализа и синтеза, сравнения, беседы с сотрудниками, а также практическое моделирование и нормализация данных. Информационную базу отчёта составили учредительные документы организации, её внутренняя отчётность, нормативно-правовые акты и должностные инструкции работников.

Результатом практики стала реализованная в Microsoft SQL Server база данных аптеки, включающая таблицы, ограничения целостности, представления, хранимые процедуры и триггеры, а также проверенный механизм обмена данными между базой и прикладным приложением. Отчёт состоит из введения, трёх разделов, заключения и списка использованных источников: в первом разделе рассматриваются теоретические основы проектирования баз данных и характеристика выбранной СУБД, во втором — практическая реализация базы данных средствами T-SQL и её интеграция с программными модулями, в третьем приведены результаты тестирования и выработанные рекомендации по совершенствованию работы предприятия.

Теоретические основы проектирования и реализации базы данных аптеки в СУБД Microsoft SQL Server

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

Анализ предметной области аптечной организации занимает исходное положение в первой главе отчета, поскольку представляет собой начальный этап проектирования базы данных: от полноты и корректности этого анализа зависят состав сущностей, структура таблиц и требования к целостности данных будущей системы.

Объектом исследования выступает общество с ограниченной ответственностью «Аптека», осуществляющее фармацевтическую деятельность на основании лицензии. Организационно-правовая форма определена уставом общества, а порядок деятельности регулируется учредительным договором и локальными нормативными актами. [1] Миссия организации заключается в обеспечении населения качественными лекарственными препаратами и сохранении здоровья граждан. Основными целями являются удовлетворение спроса на фармацевтические товары, получение прибыли и расширение ассортимента. Лицензирование подтверждает соответствие аптеки установленным требованиям.

Этапы создания и ключевые вехи развития организации раскрываются в исторической справке и уставных документах. Согласно уставу, общество создано для розничной торговли лекарственными средствами и изделиями медицинского назначения. Аптека последовательно прошла этапы становления, расширения торговых площадей и внедрения автоматизированных систем учёта. [2] Локальные нормативные акты закрепляют правила отпуска препаратов, ведения учёта и разграничения ответственности сотрудников.

Организационная структура аптеки включает руководство, отдел закупок, склад, торговый зал, рецептурно-производственный отдел, бухгалтерию и IT-службу. Руководство осуществляет стратегическое управление, отдел закупок взаимодействует с поставщиками, склад обеспечивает хранение партий, торговый зал обслуживает покупателей, рецептурно-производственный отдел изготавливает и отпускает препараты, бухгалтерия ведёт финансовый учёт, IT-служба поддерживает программное обеспечение.

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

Необходимость автоматизации учёта движения лекарственных средств и сопутствующих товаров подтверждается сложностью документооборота и высокими требованиями к достоверности данных.

Основные виды деятельности аптечной организации охватывают розничную реализацию лекарственных препаратов, изделий медицинского назначения и парафармацевтической продукции, а также оказание консультационных услуг населению по вопросам рационального применения лекарств. Розничная реализация сопряжена с соблюдением правил отпуска рецептурных препаратов, ведением предметно-количественного учёта и обеспечением условий хранения. В отдельных случаях предусмотрено изготовление лекарственных форм по рецептам врачей, что требует организации рецептурно-производственного отдела и соблюдения санитарных норм. Целевой сегмент рынка дифференцирован: физические лица, приобретающие препараты для личного потребления, медицинские организации, осуществляющие закупки по договорам, льготные категории граждан, обслуживаемые в рамках государственных программ, и корпоративные клиенты. Территориальная доступность аптеки определяет устойчивый спрос и формирует поток покупателей. [7] Экономические и технические показатели деятельности включают годовой товарооборот, широту ассортиментной матрицы, количество обслуживаемых рецептов в смену, объём складских запасов, число автоматизированных рабочих мест и используемое программное обеспечение. Ключевыми ресурсами выступают персонал с фармацевтическим образованием, складские и торговые площади, холодильное оборудование для термолабильных препаратов, кассовые узлы и информационная инфраструктура. [27]

В предметной области идентифицируются сущности: товар, партия, поставщик, покупатель, рецепт, сотрудник, продажа, заказ, складское движение. Каждая сущность характеризуется набором атрибутов и участвует в устойчивых связях, отражающих движение товара от поставщика до конечного потребителя. Проблемные зоны текущего документооборота проявляются в дублировании данных, риске ошибок при ручном вводе, слабой оперативности отчётности и необходимости разграничения прав доступа. Отчётность формируется с временной задержкой, что затрудняет оперативное принятие управленческих решений. Следовательно, будущая база данных должна обеспечивать хранение нормативно-справочной информации, учёт партий и сроков годности, поддержку рецептурного отпуска, формирование аналитических отчётов, а также целостность и безопасность данных. Разграничение прав доступа должно обеспечивать защиту персональных данных покупателей и коммерческой информации.

Проведённый анализ предметной области и информационных потоков, а также выявленные требования к хранению и обработке данных подтверждают целесообразность проектирования базы данных аптеки в СУБД Microsoft SQL Server, обладающей необходимыми инструментальными средствами для реализации сложных запросов и обеспечения целостности.

Характеристика СУБД Microsoft SQL Server и её инструментальных средств для реализации базы данных аптеки

Выбор СУБД Microsoft SQL Server в качестве платформы для реализации базы данных аптеки обусловлен требованиями предметной области, а именно необходимостью обеспечения многопользовательского доступа, высокой частоты операций учёта лекарственных средств и формирования строгой отчётности. Аптечная организация предполагает одновременную работу нескольких сотрудников с общими данными, что требует надёжного разграничения прав и устойчивости к параллельным транзакциям. Кроме того, учёт партий, сроков годности и рецептурного отпуска предполагает интенсивную обработку записей и высокую точность операций.

Microsoft SQL Server представляет собой класс реляционных систем управления базами данных, построенных на клиент-серверной архитектуре и поддерживающих стандарт ANSI SQL, а также собственный диалект Transact-SQL. Продукт эволюционировал от версии SQL Server 2000 до современных выпусков 2019 и 2022 годов, занимая устойчивые позиции на рынке корпоративных СУБД за счёт интеграции с экосистемой Microsoft и развитых средств администрирования. [21]

Редакции Microsoft SQL Server включают Express, Standard, Enterprise и Developer. Для учебного проекта аптеки обоснованно применение бесплатной редакции Express, которая имеет ограничения по объёму оперативной памяти и размеру базы данных, однако полностью поддерживает основные объекты и механизмы целостности, достаточные для демонстрации интеграции программных модулей.

Архитектурные компоненты СУБД включают ядро, реляционный движок, подсистему хранения, буферный пул, журнал транзакций, механизм блокировок и уровни изоляции. Ядро обеспечивает обработку запросов, реляционный движок управляет выполнением операторов, подсистема хранения отвечает за размещение данных на диске, буферный пул кэширует страницы, журнал транзакций гарантирует восстановление, а блокировки и уровни изоляции регулируют параллельный доступ.

Средствами СУБД создаются основные объекты базы данных: таблицы, схемы, ограничения целостности PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE, NOT NULL, DEFAULT, а также индексы, представления, хранимые процедуры, функции и триггеры. [6] Перечисленные объекты позволяют формализовать структуру аптечной базы и обеспечить ссылочную и доменную целостность.

Инструментальные средства Microsoft SQL Server подразделяются на графические клиенты разработки и администрирования, консольные утилиты, средства проектирования и развёртывания, а также программные интерфейсы доступа к данным.

Центральным инструментом разработки является SQL Server Management Studio, объединяющая обозреватель объектов для навигации по серверам, базам данных и их элементам, редактор запросов Transact-SQL с подсветкой синтаксиса и средствами отладки, конструктор таблиц, а также построитель диаграмм, позволяющий визуализировать связи между сущностями аптечной базы. [14] Существенным преимуществом признаётся визуализация планов выполнения запросов, дающая возможность оценить стоимость отдельных операций и оптимизировать обращения к таблицам учёта лекарственных препаратов. Дополнительный инструментальный контур образуют Azure Data Studio и консольная утилита sqlcmd, применяемые для автоматизации типовых сценариев, SQL Server Data Tools с проектным подходом к развёртыванию объектов, средства импорта и экспорта данных, а также планировщик заданий SQL Server Agent. [30] Надёжность хранения сведений о партиях товара и движении денежных средств обеспечивается поддержкой ACID-транзакций, автоматическим восстановлением, журналированием операций и процедурами резервного копирования. Подсистема безопасности реализует аутентификацию средствами Windows и самого сервера, разграничение прав через роли и разрешения, шифрование соединения и данных, а также аудит действий пользователей. Интеграция с прикладными модулями достигается за счёт провайдеров ADO.NET, ODBC, JDBC и OLE DB, поддержки веб-служб и форматов обмена.

Сопоставление с MySQL, PostgreSQL и Oracle показывает, что Microsoft SQL Server уступает части альтернатив по стоимости лицензий, однако превосходит их по инструментальной оснащённости и простоте сопровождения в среде Windows. [9] Возможности платформы полностью покрывают задачи аптечной предметной области: учёт партий и сроков годности, разграничение рецептурного и безрецептурного отпуска, формирование регламентированной отчётности.

Таким образом, Microsoft SQL Server занимает устойчивое положение среди корпоративных реляционных СУБД и в совокупности с SSMS и Transact-SQL образует полноценную среду проектирования, реализации и сопровождения базы данных аптеки. Специфика её применения в рассматриваемой предметной области определяется многопользовательским режимом работы, высокой интенсивностью операций учёта и жёсткими требованиями к целостности и отчётности, что создаёт методическую основу для перехода к построению логической и физической моделей данных.

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

Корректное проектирование базы данных аптеки выступает фундаментом для последующей интеграции программных модулей и обеспечивает достоверный учёт лекарственных средств. Результаты анализа предметной области позволили перейти к построению логической модели, в рамках которой выделены ключевые сущности: «Лекарства», «Партии», «Поставщики», «Продажи», «Сотрудники», «Рецепты» и «Категории». Для каждой сущности определены атрибуты, типы связей и кардинальность, назначены первичные и внешние ключи, а избыточность устранена за счёт нормализации до третьей нормальной формы. Первичные ключи обеспечивают уникальность записей, а внешние ключи поддерживают ссылочную целостность между таблицами. Нормализация до третьей нормальной формы исключила транзитивные зависимости и дублирование данных. Логическая модель представлена в виде ER-диаграммы и табличного представления, где таблица «Лекарства» хранит номенклатуру с указанием формы выпуска и дозировки, «Партии» отражают поступление с учётом срока годности и поставщика, «Поставщики» содержат реквизиты контрагентов, «Продажи» фиксируют факты реализации, «Сотрудники» — данные персонала, «Рецепты» — информацию о рецептурных препаратах, а «Категории» обеспечивают классификацию (таблица 1).

Таблица 1 — Основные сущности логической модели базы данных аптеки и их ключевые атрибуты

Рисунок 1 — Логическая модель базы данных аптеки (ER-диаграмма) приведён в приложении к отчёту и отражает перечисленные сущности, их атрибуты и связи.

Переход к физической модели обоснован выбором Microsoft SQL Server, что позволяет определить схемы, типы данных, файловые группы и первичные индексы. Выбор Microsoft SQL Server обусловлен поддержкой транзакций ACID, развитыми средствами администрирования и возможностью интеграции с прикладными модулями. Определены схемы dbo и sales, файловые группы для данных и индексов, а также кластерные первичные индексы. Базовые механизмы обеспечения целостности включают ограничения NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK и DEFAULT. Ограничение CHECK контролирует положительные значения цены и количества, а DEFAULT устанавливает текущую дату для полей учёта. Ограничения связаны с бизнес-правилами аптеки: запрет отрицательных остатков, контроль сроков годности, обязательность поставщика для партии, корректность цены и количества (таблица 2).

Таблица 2 — Соответствие бизнес-правил аптеки ограничениям целостности базы данных

Запрет отрицательных остатков реализуется через проверку количества на складе, а контроль сроков годности — через сравнение даты реализации с датой истечения. Текущий остаток партии рассчитывается по формуле

Ост = П − Р − Сп,

где Ост — текущий остаток партии, ед.; П — объём поступления по накладной, ед.; Р — количество реализованных упаковок, ед.; Сп — количество списанных упаковок (истёкший срок годности, бой, возврат), ед.

Обязательность поставщика для партии обеспечивается ограничением NOT NULL на соответствующем внешнем ключе. [19] Это гарантирует непротиворечивость данных при многопользовательской работе. [5] Таким образом, спроектированная модель готова к реализации средствами T-SQL и использованию в программных модулях аптеки. [26]

Дальнейшее углубление анализа физической модели связано с оценкой её производительности. Кластерные индексы, формируемые по первичным ключам таблиц «Лекарства», «Партии» и «Продажи», обеспечивают упорядоченное хранение записей и ускоряют выборки по диапазонам дат и идентификаторов, тогда как некластерные индексы, создаваемые по внешним ключам и по столбцам с высокой избирательностью, снижают стоимость операций соединения. Использование включаемых столбцов позволяет покрывать часто исполняемые запросы без обращения к базовой таблице, а регулярная актуализация статистики средствами Microsoft SQL Server сохраняет оптимальные планы выполнения. [1]

Ссылочная целостность поддерживается на уровне ограничений FOREIGN KEY с различными реакциями на изменение родительских записей: для связи «Поставщики» — «Партии» применяется правило NO ACTION, исключающее удаление контрагента при наличии поставок, для позиций продажи используется CASCADE, а для необязательных ссылок — SET NULL. Удаление связанных записей дополнительно ограничивается проверками, что исключает появление «осиротевших» строк. Подобная конфигурация ограничений воспроизводит реальные бизнес-правила аптечной организации и предотвращает разрыв связей между документами учёта.

Транзакционность операций продажи, списания и инвентаризации реализуется через явные транзакции с соблюдением свойств ACID; при многопользовательской работе аптеки используется уровень изоляции READ COMMITTED, а при пересчёте остатков — блокировки, предотвращающие конфликтное обновление. [2] Поддержание целостности и аудит изменений обеспечиваются триггерами и хранимыми процедурами, которые фиксируют факты модификации данных и контролируют бизнес-правила. При этом сохраняется обоснованный компромисс между нормализацией и денормализацией: третья нормальная форма устраняет избыточность, а отдельные денормализованные атрибуты ускоряют построение отчётных выборок.

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

Практическая реализация базы данных аптеки средствами Microsoft SQL Server и интеграция её с программными модулями

Создание базы данных, таблиц и ограничений средствами T-SQL в Microsoft SQL Server

Целью настоящего параграфа является практическая реализация физической модели базы данных аптеки в Microsoft SQL Server средствами языка T-SQL. Работа выполнялась в среде Microsoft SQL Server Management Studio (SSMS), обеспечивающей подключение к экземпляру сервера, выполнение скриптов и визуальный контроль создаваемых объектов. Все действия оформлялись в виде T-SQL-скриптов, что гарантирует воспроизводимость развёртывания базы и документирование изменений её структуры [16].

На первом этапе была создана база данных PharmacyDB с указанием имени, параметров сортировки, файла данных и файла журнала транзакций, их начальных размеров, шага прироста и путей хранения. Файл данных размещён в каталоге DATA, журнал транзакций — в каталоге LOG, что упрощает последующее обслуживание и резервное копирование [2]:

```sql<br>CREATE DATABASE PharmacyDB<br>ON PRIMARY (<br> NAME = N'PharmacyDB_Data',<br> FILENAME = N'D:\DATA\PharmacyDB_Data.mdf',<br> SIZE = 64 MB,<br> FILEGROWTH = 16 MB<br>)<br>LOG ON (<br> NAME = N'PharmacyDB_Log',<br> FILENAME = N'D:\LOG\PharmacyDB_Log.ldf',<br> SIZE = 32 MB,<br> FILEGROWTH = 8 MB<br>);<br>GO<br>```

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

Типы данных выбирались с учётом предметной области: денежные показатели хранятся в типе decimal, даты — в типе date, наименования — в типе nvarchar. Для ключевых таблиц приведены фрагменты CREATE TABLE, в которых обоснованы применение суррогатных первичных ключей IDENTITY, обязательность полей и значения по умолчанию. Например, таблица лекарственных средств имеет вид [10]:

```sql<br>CREATE TABLE dbo.Medicine (<br> MedicineID INT IDENTITY(1,1) NOT NULL,<br> Name NVARCHAR(150) NOT NULL,<br> CategoryID INT NOT NULL,<br> ManufacturerID INT NOT NULL,<br> Barcode CHAR(13) NOT NULL,<br> Price DECIMAL(10,2) NOT NULL,<br> RequiresRecipe BIT NOT NULL DEFAULT 0,<br> CreatedAt DATETIME NOT NULL DEFAULT GETDATE(),<br> CONSTRAINT PK_Medicine PRIMARY KEY (MedicineID),<br> CONSTRAINT UQ_Medicine_Barcode UNIQUE (Barcode),<br> CONSTRAINT CK_Medicine_Price CHECK (Price > 0),<br> CONSTRAINT FK_Medicine_Category FOREIGN KEY (CategoryID)<br> REFERENCES dbo.Category(CategoryID),<br> CONSTRAINT FK_Medicine_Manufacturer FOREIGN KEY (ManufacturerID)<br> REFERENCES dbo.Manufacturer(ManufacturerID)<br>);<br>GO<br>```

Ограничения целостности PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, NOT NULL и DEFAULT обеспечивают корректность и непротиворечивость хранимых сведений [10]. Состав основных таблиц базы данных и назначенных им ограничений приведён в таблице 1.

Таблица 1 — Основные таблицы базы данных PharmacyDB и их ограничения

Проверка результата выполнялась посредством просмотра объектов в SSMS и системных представлений sys.tables, sys.columns и sys.foreign_keys. Созданная структура отражает сущности и связи логической модели аптеки и готова к наполнению данными.

В рамках практики за студентом были закреплены задачи по созданию базы данных PharmacyDB, таблиц справочников и операционных таблиц, а также ограничений целостности. Углублённый анализ ограничений CHECK позволил формализовать бизнес-правила аптеки: положительная цена, неотрицательный остаток, корректные сроки годности и допустимые статусы записей. Применение DEFAULT обеспечило автоматическое заполнение дат создания, статусов и служебных полей, а UNIQUE гарантировало уникальность штрихкодов и номеров лицензий. Внешние ключи с правилами ON DELETE и ON UPDATE предотвращали удаление связанных записей и допускали каскадные действия только там, где они безопасны. Созданы индексы по внешним ключам и часто используемым полям для повышения производительности запросов.

Ошибки создания объектов — неверный порядок таблиц, несоответствие типов, конфликты collation и повторный запуск скрипта — устранялись приёмами идемпотентного развёртывания с проверками IF DB_ID и IF OBJECT_ID. Созданные таблицы и ограничения образуют целостную основу базы аптеки, готовую к наполнению, запросам и серверной логике, что обеспечивает переход к следующему параграфу.

Реализация запросов, представлений, хранимых процедур и триггеров для обработки данных аптеки

Переход от этапа создания таблиц и ограничений к программному уровню базы данных аптеки обусловлен необходимостью автоматизации типовых операций и централизации бизнес-логики. Основными объектами становятся запросы, представления, хранимые процедуры и триггеры. Их назначение применительно к предметной области аптеки заключается в организации доступа к сведениям о лекарственных средствах, партиях, сроках годности, поставщиках, продажах и остатках. Запросы позволяют извлекать необходимые данные, представления — унифицировать доступ, хранимые процедуры — выполнять бизнес-операции, а триггеры — автоматически поддерживать целостность [4]. Такой подход снижает нагрузку на прикладной код и обеспечивает единые правила обработки информации.

Реализация аналитических и операционных запросов выполняется с использованием соединений таблиц, агрегации, фильтрации и сортировки. Для вычисления текущего остатка по каждому препарату применяется формула

O_i = Σ P_i − Σ S_i − Σ W_i,

где O_i — текущий остаток i-го препарата; Σ P_i — суммарное количество поступления по всем партиям; Σ S_i — суммарное количество продаж; Σ W_i — суммарное количество списаний (просроченные препараты, брак, возврат поставщику).

На языке T-SQL эта формула реализуется через левые соединения таблиц Batch, Sale и WriteOff с группировкой по идентификатору препарата:

```sql<br>SELECT m.MedicineID, m.Name,<br> ISNULL(SUM(b.Quantity), 0)<br> - ISNULL(SUM(s.Quantity), 0)<br> - ISNULL(SUM(w.Quantity), 0) AS Stock<br>FROM dbo.Medicine m<br>LEFT JOIN dbo.Batch b ON b.MedicineID = m.MedicineID<br>LEFT JOIN dbo.Sale s ON s.BatchID = b.BatchID<br>LEFT JOIN dbo.WriteOff w ON w.BatchID = b.BatchID<br>GROUP BY m.MedicineID, m.Name;<br>```

Представления выступают как виртуальные таблицы, скрывающие сложность схемы и предоставляющие прикладным модулям готовые наборы данных. Например, представление vw_ExpiringSoon возвращает партии, срок годности которых истекает в течение ближайших тридцати дней, что позволяет приложению своевременно формировать отчёт для списания.

Разработка хранимых процедур охватывает ключевые бизнес-операции: регистрацию поступления, продажу, списание просроченных препаратов, резервирование, возврат и формирование отчётности. При их создании используются параметры, транзакции, обработка исключений TRY/CATCH и разграничение прав доступа. Например, процедура оформления продажи одновременно уменьшает остаток партии и создаёт запись в таблице Sale:

```sql<br>CREATE PROCEDURE dbo.usp_SellMedicine<br> @BatchID INT, @Quantity INT, @EmployeeID INT<br>AS<br>BEGIN<br> SET NOCOUNT ON;<br> BEGIN TRY<br> BEGIN TRANSACTION;<br> UPDATE dbo.Batch<br> SET Quantity = Quantity - @Quantity<br> WHERE BatchID = @BatchID AND Quantity >= @Quantity;<br> IF @@ROWCOUNT = 0<br> THROW 50001, N'Недостаточно препарата в партии', 1;<br> INSERT INTO dbo.Sale (BatchID, Quantity, EmployeeID, SaleDate)<br> VALUES (@BatchID, @Quantity, @EmployeeID, GETDATE());<br> COMMIT TRANSACTION;<br> END TRY<br> BEGIN CATCH<br> IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;<br> THROW;<br> END CATCH;<br>END;<br>GO<br>```

Триггеры обеспечивают автоматический контроль целостности, ведение аудита изменений, обновление остатков и предотвращение некорректных операций. В работе приведены фрагменты T-SQL-кода, демонстрирующие создание запросов, представлений, процедур и триггеров [25]. Это обеспечивает прозрачность и управляемость процессов.

Анализ эффективности реализованных программных объектов показывает, что использование представлений и хранимых процедур позволило существенно снизить объём кода прикладного приложения, перенеся типовые операции выборки и обработки данных на сторону сервера [13]. За счёт этого уменьшилось время разработки клиентских модулей и упростилось сопровождение системы, поскольку изменения бизнес-правил теперь вносятся централизованно в T-SQL-код без необходимости перекомпиляции приложения. Корректность работы хранимых процедур и триггеров подтверждается результатами тестовых запусков при конкурентном доступе: транзакции с уровнями изоляции READ COMMITTED и обработкой ошибок TRY/CATCH обеспечивают согласованность данных при одновременной продаже и поступлении лекарств [28]. Вместе с тем массовые операции, например списание просроченных препаратов, выявили рост времени выполнения при отсутствии некластерных индексов на полях срока годности и идентификатора партии. Анализ планов выполнения показал, что сложные аналитические запросы с соединением пяти и более таблиц требуют оптимизации, а статистика по составным индексам нуждается в регулярном обновлении. Централизация бизнес-логики в базе данных обеспечивает единые правила обработки данных для всех программных модулей аптеки, что особенно важно при интеграции кассового узла, складского учёта и модуля отчётности [8]. Однако триггеры, автоматически обновляющие остатки и ведущие аудит, создают риски: сложность отладки, каскадные срабатывания при групповых операциях и потенциальное снижение пропускной способности при высокой нагрузке. Кроме того, при ошибках ввода данных, например отрицательном количестве препарата, триггеры не всегда обеспечивают понятную диагностику, что усложняет выявление причин сбоев. Таким образом, реализованные запросы, представления, хранимые процедуры и триггеры в целом покрывают ключевые бизнес-операции аптеки, но требуют дополнительной оптимизации производительности и регламентации использования триггеров. Выявленные узкие места носят системный характер и подтверждают необходимость дальнейшего тестирования и интеграции с прикладным приложением, что определяет масштаб задачи и обосновывает её оптимизацию.

Тестирование базы данных и интеграция её модулей с прикладным приложением аптеки

Тестирование базы данных аптеки и последующая интеграция её модулей с прикладным приложением выполняются в рамках действующей на предприятии системы нормативно-правового регулирования, которая определяет как состав проверок, так и документальное оформление их результатов. Внешняя нормативная база имеет трёхуровневую структуру и включает федеральное законодательство, отраслевые стандарты и внутренние регламенты. На федеральном уровне основополагающими являются Гражданский кодекс Российской Федерации, устанавливающий общие требования к обязательствам и сделкам, Федеральный закон от 12.04.2010 № 61-ФЗ «Об обращении лекарственных средств», регламентирующий оборот препаратов, и Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», определяющий порядок обработки сведений о клиентах [15].

Отраслевой уровень образуют стандарты качества программной продукции, в частности ГОСТ Р ИСО/МЭК 25010, а также требования к программе и методике испытаний, задающие критерии функциональной полноты и надёжности [17]. Внутренние организационно-распорядительные документы предприятия — устав, коллективный договор, правила внутреннего трудового распорядка, должностные инструкции провизора, продавца, заведующего аптекой и оператора склада — закрепляют порядок доступа персонала к информационным ресурсам, режим коммерческой тайны и обязанности по вводу, проверке и корректировке сведений о лекарственных препаратах. Положения об отделах закупок и информатизации разграничивают зоны ответственности за актуализацию справочников, резервное копирование и восстановление базы. Регламент информационной безопасности устанавливает требования к парольной политике, смене учётных записей, журналированию действий пользователей и антивирусной защите рабочих станций [20].

Перечисленные акты образуют иерархию «федеральный закон — отраслевой стандарт — локальный акт», в которой общие требования к программному продукту конкретизируются вплоть до операций с рецептурными препаратами, учёта партий и контроля сроков годности. Согласно данной иерархии методика проверки предусматривает модульное, интеграционное, системное, нагрузочное и регрессионное тестирование, каждое из которых занимает определённое место в жизненном цикле базы данных аптеки. Подготовка тестового контура включала создание копии базы данных, формирование тестовых наборов справочников лекарственных препаратов, производителей, поставщиков и категорий рецептурного отпуска, а также применение инструментальных средств SQL Server Management Studio, Extended Events и анализа планов выполнения запросов.

Состав тест-кейсов охватывает проверку целостности и корректности объектов базы данных: ограничений PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE, представлений, хранимых процедур и триггеров. Основные сценарии приведены в таблице 2.

Таблица 2 — Основные тест-кейсы базы данных аптеки

В ходе практики установлено, что перечисленные документы не противоречат Гражданскому кодексу РФ, Федеральному закону № 61-ФЗ и Федеральному закону № 152-ФЗ, а их положения применяются персоналом последовательно. Интеграционный контур базы данных аптеки реализован по схеме «клиент — сервер приложений — СУБД» с доступом через ADO.NET и Entity Framework, строки подключения защищены, права учётных записей разграничены по ролям [23]. Тестирование сценариев приёмки товара, розничной продажи, отпуска рецептурных препаратов, списания по истечении срока годности и формирования отчётности выявило дефекты каскадного удаления и валидации рецептурных номеров, устранённые доработкой триггеров и ограничений CHECK. Проверка исключительных ситуаций подтвердила корректный откат транзакций и устойчивость модулей при параллельном доступе; созданные индексы сократили время типовых запросов [29]. Обобщённая схема интеграции базы данных аптеки с прикладными модулями приведена на рисунке 1.

Рисунок 1 — Схема интеграции базы данных аптеки с прикладными модулями

На схеме изображены три уровня: клиентское приложение (кассовый модуль, АРМ провизора, отчётные формы), сервер приложений (веб-сервис и модуль бизнес-логики, использующие ADO.NET и Entity Framework), а также СУБД Microsoft SQL Server с базой данных PharmacyDB. Стрелки отражают направления обмена: клиент обращается к серверу приложений, сервер приложений формирует параметризованные запросы и вызывает хранимые процедуры, а СУБД возвращает наборы данных из таблиц и представлений. Соответствие полученных результатов внешним и внутренним требованиям подтверждает надёжность защиты персональных данных и достоверность учёта лекарственных средств.

Выводы и рекомендации по разделу

По результатам практической реализации базы данных аптеки средствами Microsoft SQL Server сформулированы следующие выводы.

1. База данных PharmacyDB создана средствами T-SQL, содержит справочные и операционные таблицы, а также ограничения PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, NOT NULL и DEFAULT, что обеспечивает целостность и непротиворечивость хранимых сведений и воспроизводимость развёртывания.

2. Программный уровень базы данных реализован через запросы, представления, хранимые процедуры и триггеры, которые покрывают ключевые бизнес-операции аптеки и позволяют перенести значительную часть бизнес-логики на сторону сервера, снизив объём кода прикладного приложения.

3. Тестирование подтвердило корректность работы ограничений, транзакций и модулей интеграции, однако выявило узкие места производительности при массовых операциях и сложных аналитических запросах, а также сложность диагностики при срабатывании триггеров.

В качестве рекомендаций по совершенствованию работы предприятия предложено:

- добавить некластерные индексы на поля ExpiryDate и BatchID, а также регулярно обновлять статистику для ускорения аналитических запросов;<br>- ограничить число триггеров, оставив наиболее критичные, а часть логики перенести в хранимые процедуры с явным вызовом из приложения;<br>- предусмотреть понятные сообщения об ошибках в процедурах и триггерах для упрощения диагностики сбоев персоналом;<br>- регламентировать процедуру резервного копирования и восстановления базы данных, а также провести обучение сотрудников аптеки работе с новыми программными модулями.

Выполненные задачи соответствуют программе учебной практики по ПМ.02 «Осуществление интеграции программных модулей» и формируют практическую основу для дальнейшей интеграции базы данных аптеки с прикладным программным обеспечением.

Заключение

В ходе учебной практики по профессиональному модулю ПМ.02 «Осуществление интеграции программных модулей» все поставленные задачи были выполнены в полном объёме. Проведён анализ предметной области аптечной организации, изучены её информационные потоки и особенности бизнес-процессов, связанных с учётом лекарственных препаратов, оформлением заказов и контролем сроков годности. Рассмотрены ключевые возможности СУБД Microsoft SQL Server и её инструментальных средств, обоснован выбор данной платформы для реализации базы данных аптеки. Спроектированы логическая и физическая модели базы данных с учётом требований целостности и нормализации. Практически созданы база данных, таблицы, ограничения, а также реализованы запросы, представления, хранимые процедуры и триггеры средствами T-SQL. Проведено тестирование базы данных и выполнена её интеграция с прикладным приложением. В процессе работы выявлены потенциальные проблемы, связанные с производительностью запросов и поддержанием ссылочной целостности, для которых предложены технические решения: использование индексов, ограничений внешних ключей и триггеров.

Соответствие выполненных задач программе практики и полученные результаты обобщены в таблице 1.

Таблица 1 — Соответствие задач программы практики полученным результатам

Самоанализ показывает, что в ходе практики значительно развиты профессиональные компетенции. Закреплены навыки сбора и систематизации информации о деятельности предприятия, анализа нормативной и технической документации. Приобретён практический опыт проектирования реляционных баз данных, написания сложных SQL-запросов, создания хранимых процедур и триггеров. Освоены приёмы тестирования и отладки модулей, а также интеграции базы данных с прикладным программным обеспечением. Усовершенствованы умения работать с СУБД Microsoft SQL Server, включая использование Management Studio и языка T-SQL. Развита способность самостоятельно принимать обоснованные технические решения и оценивать их эффективность.

По результатам практики сформулированы рекомендации по улучшению работы предприятия в части информационного обеспечения аптечной деятельности. Целесообразно внедрить регулярное резервное копирование базы данных и настройку планов обслуживания индексов для поддержания стабильной производительности при росте объёма данных. Для повышения безопасности следует разграничить права доступа пользователей через роли SQL Server и организовать журналирование критичных операций. Дальнейшее развитие системы предполагает расширение аналитической отчётности, автоматизацию контроля сроков годности препаратов и интеграцию с внешними сервисами поставщиков.

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

Список использованных источников

План-график (дневник) прохождения практики

Учебная практика по профессиональному модулю ПМ.02 «Осуществление интеграции программных модулей» проходила с 02.02 по 20.02 в аптечной организации на рабочих местах, связанных с эксплуатацией и сопровождением информационных систем. Содержание работ выстроено последовательно: от организационно-правового знакомства с предприятием и анализа предметной области до практической реализации базы данных аптеки в СУБД Microsoft SQL Server и её интеграции с прикладным приложением. Ниже приведён перечень выполненных работ с отметками о выполнении.

Приведённый план-график охватывает все разделы программы учебной практики и отражает полный цикл работ по теме: предварительный анализ предметной области, проектирование структуры данных, программную реализацию объектов базы данных на языке T-SQL, проверку корректности работы запросов и процедур, а также интеграцию разработанных модулей с прикладным приложением. Работы, предусмотренные программой, выполнены в полном объёме и в установленные сроки, отклонений от графика не зафиксировано.

Для оценки равномерности нагрузки и полноты охвата этапов практики выполнен сводный анализ распределения рабочих дней по укрупнённым этапам (данные приведены по фактическому дневнику и носят учебно-расчётный характер).

Сводные показатели подтверждают сбалансированное распределение трудозатрат: наибольший объём (по 33,3 % от общей длительности) приходится на подготовительный и проектировочный этапы, что закономерно для задач интеграции программных модулей — качество реализации напрямую зависит от полноты анализа предметной области и корректности модели данных. Собственно программная реализация и интеграция занимают 20,0 % времени, а завершающие работы — 13,3 %, что соответствует логике проектного жизненного цикла и не создаёт риска срыва сроков на финальной стадии.

Данные о распределении рабочих дней по этапам практики, использованные для построения диаграммы, приведены ниже.

Рисунок 1 - Распределение рабочих дней учебной практики по этапам

Диаграмма наглядно демонстрирует, что организационно-ознакомительный и аналитико-проектный этапы формируют основу трудоёмкости практики, тогда как реализационно-интеграционный и отчётно-заключительный этапы компактны и логически завершают цикл. Такое распределение подтверждает, что полученные результаты (рабочая база данных аптеки, набор запросов, представлений, хранимых процедур и триггеров, а также протестированная интеграция с прикладным приложением) были подготовлены на достаточной аналитической и проектной базе, а не получены формально.

По итогам практики закреплены умения разрабатывать требования к программным модулям, выполнять их интеграцию и отладку, готовить тестовые наборы и сценарии, а также проверять соответствие компонентов программного обеспечения принятым стандартам кодирования, что соответствует содержанию профессиональных компетенций ПК 2.1–ПК 2.5 по модулю ПМ.02.

Отзыв-характеристика руководителя практики от предприятия

Студент группы ИСП-251 проходил учебную практику по профессиональному модулю ПМ.02 «Осуществление интеграции программных модулей» в отделе информационных технологий ООО «Аптека» в полном объёме и в сроки, установленные учебным планом. Программа практики выполнена полностью, замечаний по трудовой дисциплине и срокам представления отчётных материалов не имеется. Претензий организационного характера к студенту не возникало.

За период практики студент зарекомендовал себя как дисциплинированный и ответственный исполнитель. Он успешно справился со всеми поставленными задачами: изучил структуру подразделения и особенности информационных потоков аптечной организации, проанализировал показатели её деятельности, рассмотрел действующую нормативную базу, а также подготовил обоснованные предложения по совершенствованию технических решений. Студент самостоятельно спроектировал и реализовал базу данных аптеки в СУБД Microsoft SQL Server, разработал таблицы, ограничения целостности, запросы, представления, хранимые процедуры и триггеры, выполнил интеграцию программных модулей с прикладным приложением и провёл их тестирование. Он продемонстрировал высокий уровень теоретических знаний и умение уверенно применять их в практической деятельности. Полученные результаты имеют практическую ценность для предприятия.

Соответствие выполненных работ программе практики подтверждается следующими результатами.

Таблица 1 — Выполнение программы учебной практики

Личностные качества студента заслуживают положительной оценки: он исполнителен, инициативен, пунктуален, корректно выстраивает деловые отношения, эффективно работает в команде, проявляет стремление к профессиональному росту и самообразованию. Поручения руководителя практики выполнялись своевременно и качественно, при возникновении вопросов студент самостоятельно находил решения и аргументированно их обосновывал.

Программа практики выполнена полностью, отчётный материал оформлен грамотно и представлен в срок. Уровень освоения профессиональных компетенций по модулю ПМ.02 «Осуществление интеграции программных модулей» соответствует требованиям образовательной программы, работа студента заслуживает оценки «отлично». Студент достоин присвоения соответствующей квалификации по специальности.