Разработка автоматизированной информационной системы учета продаж фармацевтических препаратов

Задачами автоматизированной системы являются:

1. Запись нового препарата
2. Поиск препарата из существующих и их заменителей
3. Удаление препарата
4. Отображение фирм, поставляющих данный препарат
5. Отображение цен в фирмах, поставляющих препарат
6. Отображение сведений фармакологические свойства
7. Отображение сведений способ применения
8. Отображение сведений показания к применению
9. Сортировка препаратов по типу(витамины, БАК, лекарства, косметика)
10. Возможность добавления нового заболевания
11. Подготовка сведений о фирмах
12. Удаление фирмы
13. Добавление фирмы
14. Формирование заказа определенного препарата, с выбором его из каталога фирмы
15. Формирование общей суммы «к оплате»

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

На этапе инфологического проектирования базы данных строится инфологическая модель предметной области, которая  должна отображать семантику (смысл  взаимосвязи объектов) предметной области. ИЛМ строится не для отдельного объекта, а отображает классы объектов и связи  между ними. Диаграмма, отражающая связи  объектов предметной области, называется диаграммой ER-типа (так как Entity – сущность, Relationship – связь).

Выделим основные сущности:

сущность  «Препараты»;

сущность  «Фирмы»;

сущность  «Прайс цен»;

сущность  «Показания к применению»;

сущность  «Заболевания»

сущность  «Заказ по фирме»

сущность  «Содержание заказа»

 

Инфологическая модель базы данных «Библиотека» представлена на рис. 1.

 

 

 

Рис.1. Инфологическая модель предметной области (ПО) «Аптека – препараты»

 

Сущность  «Препараты» содержит информацию обо  всех препаратах, имеющихся в аптеке. Отдельный препарат этой сущности может поставляться различными фирмами и иметь различные цены в различных фирмах, поэтому водиться сущность «Прайс цен». Каждый препарат сущности «Прайс цен» содержит информацию поставляющей фирме и о цене конкретного препарата. Между сущностью «Препараты» и сущностью «Прайс цен» существует связь типа «1:М», обязательная с обеих сторон (если есть информация о препарате, то есть хотя бы одна фирма, поставляющая данный препарат цена препарата, если есть цена препарата и поставляющая его фирма, то должна быть информация о препарате). Сущность «Фирмы» содержит информацию о фирмах поставляющих препараты. Отдельная фирма этой сущности содержит информацию об одной цене отдельного препарата. Существует связь между сущностью «Фирмы» и сущностью «Прайс цен» типа «1:М»,  не обязательная с обеих сторон (ни одна фирма  может не поставлять ни одного препарата).

Сущность  «Препараты» содержит информацию обо  всех препаратах, имеющихся в аптеке. Отдельный препарат этой сущности иметь  различные  показания к применению, поэтому водиться сущность «Показания к применению». Каждое показание  к применению сущности «Показание к  применению» содержит информацию применению отдельного препарата. Между сущностью  «Препараты» и сущностью «Показания к применению» существует связь  типа «1:М», обязательная с обеих  сторон (если есть информация о препарате, то обязательно должно быть показание  к применению, если есть показание  к применению, то обязательно должна быть информация о препарате). Сущность «Заболевания» содержит информацию о показания к применению, ведь при разных заболеваниях показания  к применению могут быть различными. Отдельное заболевание   сущности «Заболевания» содержит информацию об одном показании к применению одного препарата. Существует связь  между сущностью «Заболевания»  и сущностью «Показания к применению»  типа «1:М»,  обязательная с обеих  сторон (если есть показание к применению, то должно быть и заболевание, для лечения которого оно предназначено). «Заказ по фирме» относиться к «Фирмы» как 1:М, то есть каждому шифру фирмы соответствует одна фирма. «Содержание заказа » относится к таблице  «Заказ по фирме» также 1:М, то есть в одном заказе содержится лишь товар, заказанный у одной фирмы, к таблице «Препараты» также отношение 1:М, то есть определенному номеру препарата соответствует один препарат.

Определим ключи  – уникальные идентификаторы  каждой сущности: для сущности «Препараты» - это номер препарата (№Препарата), для сущности «Прайс цен» - номер  препарата, шифр фирмы, для сущности «Фирмы» - шифр фирмы, для сущности «Показания к применению» номер препарата  и шифр заболевания, для сущности «Заболевания» - шифр заболевания, в  «Заказ по фирме»- номер заказа(№Заказа), в «Содержимое заказа»-номер заказа(№Заказа),номер препарата (№Препарата).

 

2.1.2 Реализация базы данных

 

Реляционная модель - модель представления данных, которая описывает  структуру данных, допустимые операции над данными и специальные  правила, обеспечивающие целостность  данных.

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

Следующим шагом  в проектировании РБД является нормализация отношений. Даталогическое концептуальное проектирование состоит в разработке корректной схемы в виде совокупности взаимосвязанных отношений отражающих объекты предметной области и их семантические связи. В такой схеме должны отсутствовать нежелательные функциональные зависимости между атрибутами. Нормализированный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем любой другой набор таблиц представляющий те же данные. Проектирование может выполняться путем декомпозиции или путем синтеза. При проектировании с использованием декомпозиции переходят от одной нормальной формы к другой нормальной форме более высокого уровня, сохраняя эквивалентность схем Базы Данных. Выделяют несколько нормальных форм (НФ): 1НФ, 2НФ, 3НФ, 4НФ, 5НФ. Каждая следующая НФ улучшает свойство схемы, сохраняя свойства предыдущей НФ.

 

Отношение «Препараты»

№ препарата

Регистрационный номер

Торговое патентовое название препарата

Международное непатентовое название препарата

Химическое название

Срок хранения, месяцы

Изображение

Тип препарат

Примечание

Форма выпуска

Состав и лекарственная  форма

Фармокотерапевтическая группа

Фармакодинамика

Фармакокинетика

Производитель

 

Отношение «Прайс цен»

№Препарата

Шифр фирмы

Оптовая цена

Количество штук

 

 

 

Фирмы-поставщики

Шифр  фирмы

Название фирмы

Адрес

Телефон

Идентификационный номер

Банк

Расчетный счет

БИК

К/с

Индекс

Сайт

Показания к применению

№Препарата

Шифр заболевания

Доза

Побочные действия

Противопоказания

Взаимодействия с другими  препаратами

Показания к применению

Особые указания

Передозировка

 

Информация о заболеваниях

Шифр  заболевания

Название заболевания

Тип препарат

 

 

Заказ по фирме

№Заказа

Шифр фирмы

Дата заказа

К оплате за заказ

 

Содержание заказа

№Препарата

№Заказа

Кол_во заказа

К_оплате_за товар

 

2.1.3 Даталогическая модель

 

Даталогическим (логическим) проектированием называют проектирование логической структуры БД в среде конкретной СУБД. Выберем в качестве модели данных реляционную базу данных (РБД).

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

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

Ограничения или свойства таблиц:

1. Каждая таблица представляет  собой реальный объект- сущность.

2. Элементы таблиц должны  быть неделимыми.

3. Столбцы- поименованы.

4. Элементы столбца должны  быть однородными. В таблице  не должно быть двух одинаковых  строк.

5. Каждая таблица должна  иметь первичный ключ для идентификации  каждой строки таблицы.

В результате получили следующие  отношения:

Препараты   (№ Препарата, Регистрационный номер, Торговое патентовое название препарата, Международное непатентовое название препарата, Химическое название, Срок хранения, месяцы, Изображение, Тип препарата,  Примечание, Форма выпуска, Состав и лекарственная форма, Фармокотерапевтическая группа, Фармакодинамика, Фармакокинетика, Производитель).

Прайс цен  (№Препарата, Шифр фирмы, Оптовая цена, Количество штук,).

Фирмы (Шифр фирмы, Название фирмы, Адрес, Телефон, Идентификационный номер, Банк, Расчетный счет, БИК, К/с, Индекс, Сайт).

Показания к применению (№Препарата, Шифр заболевания, Доза, Побочные действия, Противопоказания, Взаимодействия с  другими препаратами, Показания  к применению, Особые указания, Передозировка).

Заболевания (Шифр заболевания, Название заболевания, Тип препарата).

Заказ_по_фирме (№заказа,Шифр фирмы, Дата заказа, Итого к оплате за заказ).

Содержимое заказа(№Препарата, №Заказа, Кол_заказа, К оплате за товар).

Выполним  физическое проектирование в среде  СУБД Microsoft SQL Server 2005. Зададим имена таблиц и полей, определим типы данных и размерность полей таблиц. В таблицах выберем первичные ключи и индексированные поля. Так же для поля определим его основные характеристики – является ли это поле внешним или первичным ключом, создан ли индекс по этому полю, задано ли для поля значение по умолчанию, какие ограничения заданы для данного поля (уникальность значений, маска ввода). Вся эта информация представлена в таблице 1.

 

Физическое  проектирование.

 

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

Таблица 1 –  Структура таблиц РБД «Аптека»

Название таблицы	Имя поля	Тип данных	Размер поля	Первичный ключ / вторичный ключ / индексированное  поле
Препараты	№ Препарата	Счетчик, int	Длинное целое	Первичный ключ
	Регистрационный номер	nchar	20
	Название препарата	nchar	150
	Международное непатентованное название	nchar	50
	Химическое название	nchar	100
	Срок хранения	int	Длинное целое
	Изображение	image
	Тип препарата	nchar	20
	Примечание	nchar	250
	Форма выпуска	int	Длинное целое
	Состав и лекарственная форма	nchar	255
	Фармакотерапевтическая группа	nchar	200
	Фармакодинамика	ntext
	Фармакокинетика	ntext
	Производитель	ntext
Фирмы	Шифр фирмы	Счетчик,int	Длинное целое	Первичный ключ
	Название фирмы	nchar	30
	Адрес	nchar	150
	Телефон	nchar	30
	Идентификационный номер	nchar	50
	Банк	nchar	100
	Расчетный счет	nchar	50
	БИК	int	Длинное целое
	К/с	nchar	50
	Индекс	int	Длинное целое
	Сайт	nchar	50
Заболевания	Шифр заболевания	nchar	50	Первичный ключ
	При заболеваниях	nchar	50
	Тип препарат	nchar	20
Показания к применению	№ Препарата	nchar	Длинное целое	Первичный ключ
	Шифр заболевания	nchar	50	Вторичный ключ
	Доза	nchar	255
	Побочные действия	ntext
	Противопоказания	ntext
	Взаимодействие с другими лекарствами	ntext
	Показания к применению	ntext
	Особые указания	ntext
	Передозировка	ntext
Прайс цен	№Препарата	int	Длинное целое	Первичный ключ
	Шифр фирмы	int	Длинное целое	Вторичный ключ
	Оптовая цена	money
	Количество, штук	int	Длинное целое
Заказ по фирме	№Заказа	Счетчик,int	Длинное целое	Первичный ключ
	Шифр фирмы	Текстовый	20
	Дата заказа	datetime
	Итого к оплате за заказ	money
Содержание  заказа	№Препарата	int	Длинное целое	Первичный ключ
	№Заказа	int	Длинное целое	Вторичный ключ
	Кол_заказа	int	Длинное целое
	К_оплате_за_заказ	money

 

 

2.1.3 Обоснование выбора среды  базы данных

 

Структурой  хранения данных в SQL Server 2005 является база данных (database). Вся работа SQL Server 2005 сводится к управлению базами данных (БД). Системные данные сервера, отвечающие за его функционирование, также хранятся в базах данных. Базу данных SQL Server 2005 можно рассматривать с двух сторон: физической и логической. При работе с любой базой данных SQL Server 2005 - пользовательской или системной - действуют одни и те же механизмы.

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

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

Microsoft SQL Server 2005 - это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В сервер SQL Server 2005 включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения. Кроме того, SQL Server 2005 полностью использует все возможности операционной системы Windows, включая поддержку до 32 процессоров и 64 ГБ ОЗУ.

Система управления базами данных SQL Server 2005 предоставляет пользователям широкие возможности по разработке и сопровождению баз данных. Для этого в составе системы имеется набор графических средств (Enterprise Manager, Query Analyzer), языковых средств (язык Transact-SQL), набор хранимых процедур.

Основными задачами в процессе разработки и сопровождения  баз данных в среде SQL Server 2005 являются создание, модификация и удаление баз данных, таблиц, а также объектов баз данных, таких как индексы, представления, запросы, хранимые процедуры и триггеры.