1. Анализ и описание предметной области

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

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

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

Могут существовать следующие ограничения при работе с подобной базой данных:

1.  Изготовитель может производить множество препаратов;

2.  Из базы удаляются препараты, срок годности которых истек;

3.  Каждая аптека должна иметь контактный телефон;

4.  Каждый изготовитель должен иметь электронный адрес;

5.  Некоторые препараты отпускаются только по рецепту врача;

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

Работать с базой данных «Аптеки-Препараты» будут следующие пользователи:

·  Аптекарь;

·  Покупатель;

·  Администратор.

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

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

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

2. Цели и задачи создания базы данных «Аптеки-препараты»

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

Целью разработки базы данных «Аптеки-Препараты» и автоматизированной системы для работы с ней является повышение качества обработки данных и систематизация хранимой информации об аптеках и препаратах.

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

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

1.  Регистрация новых препаратов

2.  Регистрация новых изготовителей

3.  Систематизация препаратов по аптекам

4.  Систематизация препаратов по изготовителям

5.  Контроль срока годности препаратов

6.  Контроль препаратов выдаваемых по рецепту

7.  Подготовка сведений о лицензиях аптек

8.  Выписка чеков на препараты

 

3. Проектирование базы данных

 

3.1  Входные и выходные данные задач

Входными данными задач являются: данные об аптеках, препаратах, изготовителях препаратов и т.д.

Информация об аптеке:

·  Уникальный код аптеки

·  Название

·  Адрес аптеки

·  Владелец

·  Лицензия

·  Телефон

Информация об изготовителе:

·  Уникальный код изготовителя

·  Наименование

·  Адрес

·  Год основания

·  Телефон

·  Электронный адрес

Информация о препарате:

·  Код препарата

·  Название

·  Код аптеки

·  Код изготовителя

·  Упаковка

·  Стоимость

·  Рецепт

·  Дата выпуска

·  Срок годности

 

3.2  Инфологическое проектирование базы данных

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

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

·  сущность «Аптека»;

·  сущность «Изготовитель»;

·  сущность «Препарат».

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

 

3.3 Выбор СУБД

Система управления базами данных Access (СУБД Access) входит в стандартный набор прикладных программ пакета Microsoft Office, который – так сложилось исторически – используется практически в каждой организации нашей страны. Она предоставляет значительные возможности по работе с хранящимися данными, их обработке и совместному использованию.

Можно производить обмен данными между компонентами СУБД Access и другими приложениями Windows. Это могут быть рисунки и т.д.

СУБД Access – система сложная и многозначная. Одинаковый результат может быть достигнут различными путями. При начальном освоении материала бессмысленно показывает все возможные варианты поведения в сложившейся ситуации.

Все объекты, относящиеся к одной базе данных, Access хранит в одном большом файле с расширением mdb, среди объектов разрабатываемой базы данных мы предусмотрели:

1. Таблицы – основные объекты любой базы данных. В таблицах хранятся все данные, имеющиеся в базе, кроме того, таблицы хранят и структуру базы (поля, их типы и свойства).

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

3. Если запросы – это специальные средства для отбора и анализа данных, то формы – это средства для ввода данных. Смысл их тот же – предоставить пользователю средства для заполнения только тех полей, которые ему заполнять положено. Одновременно с этим в форме можно разместить специальные элементы управления (счетчики, раскрывающиеся списки, переключатели, флажки и прочее) для автоматизации ввода. Преимущества форм раскрываются особенно наглядно, когда происходит ввод данных с заполненных бланков. В этом случае форму делают графическими средствами так, чтобы она повторяла оформление бланка – это заметно упрощает работу наборщика, снижает его утомление и предотвращает появление печатных ошибок.

4. Отчеты по своим свойствам и структуре во многом похожи на формы, но предназначены только для вывода данных, причем для вывода не на экран, а на принтер. В связи с этим отчеты отличаются тем, что в них приняты специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных документов.

 

3.4  Даталогическое проектирование базы данных

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

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

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

Аптека (Код аптеки, Название, Адрес аптеки, Владелец, Лицензия, Телефон)

Изготовитель (Код изготовителя, Наименование, Адрес, Год основания, Телефон, Электронный адрес)

Препарат (Код препарата, Название, Код аптеки, Код изготовителя, Упаковка, Стоимость, Рецепт, Дата выпуска, Срок годности)

3.4.1  Нормализация отношений

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

Отношения «Аптека», «Изготовитель» и «Препарат» находятся в 1-ой нормальной форме, т. к. не имеют сложных атрибутов.

Поскольку отношения «Аптека», «Изготовитель» и «Препарат» имеют простые ключи, они уже во 2-ой нормальной форме.

Реляционная база данных «Аптеки-Препараты».

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

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

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

Название таблицы	Имя поля	Тип данных	Размер поля	Первичный ключ / вторичный ключ / индексированное поле
Аптека	Код аптеки	Счетчик	Длинное целое	Первичный ключ
	Название	Текстовый	20
	Адрес аптеки	Текстовый	50
	Владелец	Текстовый	20
	Лицензия	Дата / Время (с маской)
	Телефон	Текстовый (с маской)	50

Таблица 2. Структура таблицы «Изготовитель» РБД «Аптеки-Препараты»

Название таблицы	Имя поля	Тип данных	Размер поля	Первичный ключ / вторичный ключ / индексированное поле
Изготовитель	Код изготовителя	Счетчик	Длинное целое	Первичный ключ
	Наименование	Текстовый	20
	Адрес	Текстовый	50
	Год основания	Текстовый (с маской)	50
	Телефон	Текстовый (с маской)	50
	Электронный адрес	Гиперссылка

Таблица 3. Структура таблицы «Препараты» РБД «Аптеки-Препараты»

Название таблицы	Имя поля	Тип данных	Размер поля	Первичный ключ / вторичный ключ / индексированное поле
Препараты	Код препарата	Счетчик	Длинное целое	Первичный ключ
	Название	Текстовый	50
	Аптека	Числовой (с подстановкой)	Длинное целое
	Изготовитель	Числовой (с подстановкой)	Длинное целое
	Упаковка	Текстовый	50
	Стоимость	Денежный
	Рецепт	Логический
	Дата выпуска	Дата / Время (с маской)
	Срок годности(лет)	Числовой	Длинное целое

Связи между таблицами в базе данных «Аптеки-Препараты» представлены на рис. 4

Рис. 4. Связи между таблицами в базе данных

4.  Автоматизированная информационная система на основе базы данных «Аптеки-Препараты»

 

4.1 Структура информационной системы

Для определения структуры информационной системы, необходимо распределить задачи, решаемые в АИС, по пользователям системы: Аптекарь, Покупатель, Администратор.

Аптекарь выполняет следующие задачи:

1.  Ввод и корректировка данных об аптеке

2.  Ввод и корректировка данных об изготовителе

3.  Ввод и корректировка данных о препарате

4.  Контроль срока годности препарата

5.  Обновление стоимости препарата

6.  Поиск данных об аптеке и препарате

7.  Поиск аптек с нужными препаратами

8.  Подготовка сведений о препаратах продаваемых в аптеке

9.  Подготовка сведений о препаратах производимых изготовителем

10.  Расчет стажа фирм изготовителей

11.  Проверка лицензии аптек

12.  Сведения о препаратах выдаваемых только по рецепту

Покупатель решает следующие задачи:

1.  Просмотр сведений о препаратах продаваемых в аптеке

2.  Просмотр сведений о препаратах производимых изготовителем

3.  Сведения о препаратах выдаваемых только по рецепту

Администратор:

1.  Проверка лицензии аптек

2.  Ввод и корректировка данных об аптеке

3.  Ввод и корректировка данных об изготовителе

4.  Контроль срока годности препарата

Информационную систему «Аптеки-Препараты» можно представить в виде 3-х подсистем (рис. 5):

Аптеки-Препараты

Аптекарь

Покупатель

Администратор

Рис. 5. Укрупненная структура АИС «Аптеки-Препараты»

Поскольку все задачи решаются в основном Аптекарем, а два других пользователя решают лишь некоторые задачи из этого списка, далее более подробно рассмотрим только подсистему «Аптекарь». Для выполнения задач, решаемых Аптекарем, используем 4 формы:

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

 

 

 

 

 

 

 

Рис. 6. Структура подсистемы «Аптекарь»

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

4.2 Запросы на выборку данных для решения поставленных задач

Рис. 11. Запрос для обновления стоимости препарата

Рис. 12. Параметрический запрос для определения препаратов поставляемых изготовителем

Рис. 13. Параметрический запрос для определения препаратов в заданной аптеке

Рис. 14. Параметрический запрос для поиска препаратов

Рис. 15. Параметрический запрос для поиска сведений об аптеке

Рис. 16. Запрос на выборку для определения препаратов отпускаемых по рецепту

Рис. 17. Запрос на выборку фирмы со стажем более 20 лет

Рис. 18. Запрос на выборку о просроченных лицензиях

Рис. 19. Запрос на выборку о просроченных препаратах

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

4.3 Отчеты по результатам решения задач

В качестве примера создадим отчет о просроченных лицензиях. Используем для этого конструктор отчетов и используем результаты запроса «Просроченные лицензии». Экранная форма конструктора отчетов приведена на рис. 20, а сам Отчет для контрольного примера – в приложении.

Рис. 20. Создание отчета об истекших лицензиях

Рис. 21. Создание отчета – Сведения о старейших фирмах

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

Данные отчеты приведены в приложении.

4.3 Организация интерфейса с пользователем

При разработке интерфейса пользователя необходимо помнить, что он создается для пользователя, возможно, имеющего слабые навыки работы за компьютером, т.е. не специалиста по АСОИУ. Поэтому, интерфейс должен быть «дружественным», понятным всем, без необоснованных сокращений слов и предложений, а также достаточно красочным. В нашем случае предлагается начать работу с главной формы, при нажатии же одной из кнопок на ней появляется форма для работы с соответствующей компонентой АИС, например, компонентой «Аптекарь» (рис. 22) и т.д.

Рис. 22. Главная форма АИС «Аптеки-Препараты» и компоненты «Аптекарь»

Литература

1. Ризаев И.С., Яхина З.Т. Базы данных. Учебное пособие. Казань.: КГТУ. 2002.

2. Ризаев И.С., Яхина З.Т. Базы данных. Лабораторный практикум. – Казань, КГТУ, 2002.

3. Захарова З.Х., Ризаев И.С., Яхина З.Т. Методические указания к курсовой работе по дисциплине «Базы данных». – Казань, КГТУ, 2006.

4. Карпова Т.С. Базы данных: Модели, разработка, реализация. Учебник. – СПб: Питер, 2001.

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

 

• 14:21 05 Июля 2016
  Российско-китайский медуниверситет откроет магистерскую программу по TCM
• 01:21 05 Июля 2016
  На форуме МГУ Россия и Китай обсудят научно-образовательное сотрудничество
• 11:00 04 Июля 2016
  Реморенко: "ЕГЭ-туризм" в России сходит на нет
• 10:52 04 Июля 2016
  Летняя российско-австрийская школа откроется в Москве
• 15:31 01 Июля 2016
  В СПбГУ могут воссоздать географический факультет

Заказать уникальную работу