Министерство общего и профессионального образования свердловской области

Государственное автономное образовательное учреждение

среднего профессионального образования
Свердловской области
"Верхнепышминский механико-технологический техникум «Юность»"

ПРОЕКТНАЯ РАБОТА
по предмету "Основы проектирования баз данных"
специальность 09.02.04 Информационные системы (по отраслям)
проектирование базы данных по теме “Аптека”

Выполнил студент группы Ис-336п: Тасаев Михаил Юрьевич

Верхняя Пышма, 2023г.

 Содержание

Введение 3
1. Описание и анализ предметной области. 4
2. Инфологическая модель. 6
2.1. Концептуальная модель. 6
2.2. ER-модели по сущностям концептуальной модели. 8
3. Нормализация отношений. 12
3.1. Исходные данные. 12
3.2. 1НФ 16
3.3. Вторая нормальная форма отношений. 18
3.4. Третья нормальная форма отношений. 20
4. Физическая модель. .
5. Контрольный пример.
5.1. Данные. .
5.2. Запросы. .
5.3. Отчёты. .
6. Техническое задание. .
7. Инструкция пользователя .
8. Заключение .
9. Список использованных ресурсов .

2
 Введение
Аптечный бизнес в последние годы считается одним из самых доходных. О
том, насколько он привлекателен, говорит и все возрастающее число аптек. Их
возникает все больше - больших и маленьких, независимых или входящих в
крупные аптечные торговые сети. И для создание конкурентоспособного бизнеса
необходимо быстро обрабатывать большой поток данных для оптимизированного
и ускоренного обслуживания клиентов.
Важными критериями баз данных сегодня являются скорость обработки
информации, удобство использования баз данных. От данных информационной
системы во многом зависит эффективность работы любого предприятия ли
учреждения. Такая система должна:
- обеспечивать получение общих или детализированных отчетов по итогам
работы;
- позволять легко определять тенденции изменения важнейших показателей;
- обеспечивать получение информации, критической по времени, без
существенных задержек;
- выполнять точный и полный анализ данных.
Предмет исследования – структура и содержание информационных
потоков в процессе основного вида деятельности аптеки.
Целью данной работы является: проект по индивидуальное теме базы
данных «Аптека».
Поставленная цель исследования определила необходимость
постановки и решения следующих основных задач:
1. Провести описание и анализ предметной области.
2. Построить инфологическую модель базы данных.
3. Провести логическое проектирование базы данных.
4. Построить физическую модель базы данных.
5. Составить техническое задание.
6. Составить инструкцию по эксплуатации для пользователя системы.

3
 1. Описание и анализ предметной области.
1. Предметная область деятельности предприятия.
Предметной областью деятельности предприятия “Аптека” является
“Торговля”.
2. Характеристика предприятия.
Аптека представляет собой организацию осуществляющую розничную
торговлю лекарственными средствами.
Аптека является общедоступным предприятием обслуживающим все
контингенты населения, имеющим в своем распоряжении небольшой торговый
зал. В аптеке работают 10 сотрудников представляющие собой фармацевтов и
уборщиц.
Аптека имеет в своем ассортименте лекарственные препараты, средства
личной гигиены, медицинские измерительные приборы, а также терапевтические
аппараты домашнего пользования. Торговля лекарственными средствами
квалифицируются на общую и рецептурную. Продажа и контроль препаратов
осуществляется под контролем аптеки внутри которой создается учет
рецептурных средств на основе законов и приказов министерства
здравоохранения.
3. Основной вид деятельности предприятия и его характеристики.
Основной вид деятельности аптеки это розничная продажа и контроль
проданных лекарственных средств, особенностью которого является строгий
контроль и учет всех поступающих товаров. Розничная продажа лекарственных
средств осуществляется по двум видам:
- по рецепту - продажа происходит с разрешения и под ответственность
врача, на определенный вид лекарственных средств по строгой отчетности.
- свободная продажа (без рецепта).
В процессе основного вида деятельности покупатель приобретает
необходимые лекарственные средства, получая консультацию фармацевта в
случае необходимости. В случае покупки рецептурных лекарственных средств
предварительно происходит запрос разрешения (рецепта) на покупку.

4
 4. Участники основного вида деятельности и их характеристики.
Участниками основного вида деятельности Аптеки являются: фармацевт и
покупатель.
- Фармацевты характеризуются информацией содержащей в себе личные
данные ФИО, адрес проживания а также номер телефона.
- Покупатели характеризуются информацией содержащей в себе личные
данные ФИО, адрес проживания, а также номер телефона.
5. Информационные потоки в процессе основного вида деятельности.
В процессе основного вида деятельности между участниками возникают
информационные потоки. Участниками в информационном потоке выступает
фармацевтом и покупатель между которыми фиксируется информация о:
- названии лекарственных запрашиваемых покупателем
- присутствии необходимых покупателю лекарственных средств в наличии
- цены названных покупателем препаратов
- поставщике названных лекарственных средств находящихся в наличии
Процесс продажи лекарств происходит через фармацевта, клиент находясь в
аптеке сообщает информацию о названии лекарств, после чего аптекарь через
терминал сверяет информацию о наличии необходимых лекарства на складах
аптеки в случае положительного результата сверяет необходимость наличия
рецепта, если он необходим запрашивает таковой у клиента после чего сверяет
цены марки и предлагает клиенту выбор и выдает необходимое количество
лекарств получая деньги и изменяя в учете данных количество оставшихся
лекарств. В случае если лекарство закончилось удаляет запись. После чего
связывается с поставщиками запрашивая необходимое количество лекарств.
После поступления заносит их в документацию.
6. Характеристики учёта по основному виду деятельности.
Основной характеристикой учета по основному виду деятельности является:
учёт продажа лекарственных средств.
В учете продаж лекарственных средств необходимо фиксировать
количество проданных лекарств с целью дальнейшего контроля розничного
5
товарного потока с одним физическим лицом для исключения преступной
деятельности и соблюдения приказов министерства здравоохранения по
розничной продаже лекарственных средств, а также учета личных данных
покупателей с рецептурными товарами. Для дальнейшего соблюдения норм и
ведения учета необходимо знать дату осуществления продажи, а также личные
данные ответственного фармацевта.

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

Схема 1 «Основные объекты данных и их взаимодействие»

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

Схема 2 «Основные принципы взаимодействия данных»

Исходя из схемы базы данных с основными принципами взаимодействия
данных возникает необходимость в создании четвертого объекта данных,
объединяющего все взаимодействия данным объектом стал «Учет продаж» на
схеме базы данных «Аптека»:

7
 Схема 3 «Схема БД с связующим объектом данных»
Для изображения наглядности, а также внесения сути и удобства работы
изображаем в концептуальной модели базы данных «Аптека», атрибуты каждого
объекта:

Схема 4 «Итоговая концептуальная модель базы данных»

8
 2.2. ER-моделирование по сущностям концептуальной модели.

ER-модель 1 «Покупатель»
На ER модели сущности «Покупателя» объявляются следующие атрибуты,
которые в СУБД (программе) могут иметь следующие типы:

− атрибут «Код покупателя» – есть уникальным целочисленным значением,

которое формируется автоматически. В СУБД это есть поле-счетчик;

− атрибут «№ телефона» – многозначный атрибут, который может быть

реализован как массив или коллекция и т.п.;

− атрибуты «Населенный пункт», «Улица», «Номер дома», «Номер

квартиры» – это атрибуты, которые образуют составной атрибут Адрес. Все эти
атрибуты могут быть строчного (текстового) типа (string, Text);

− атрибуты «Фамилия», «Имя», «Отчество» – это простые атрибуты,

которые являются частью составного атрибута «ФИО». Все эти атрибуты могут
быть строчного (текстового) типа (string, Text);

9
 ER-модель 2 «Фармацевт»
На ER модели сущности «Фармацевт» объявляются следующие атрибуты,
которые в СУБД (программе) могут иметь следующие типы:

− атрибут «Код фармацевта» – есть уникальным целочисленным значением,

которое формируется автоматически. В СУБД это есть поле-счетчик;

− атрибут «№ телефона» – многозначный атрибут, который может быть

реализован как массив или коллекция и т.п.;

− атрибуты «Населенный пункт», «Улица», «Номер дома», «Номер

квартиры» – это атрибуты, которые образуют составной атрибут Адрес. Все эти
атрибуты могут быть строчного (текстового) типа (string, Text);

− атрибуты «Фамилия», «Имя», «Отчество» – это простые атрибуты,

которые являются частью составного атрибута «ФИО». Все эти атрибуты могут
быть строчного (текстового) типа (string, Text);

ER-модель 3 «Лекарства»
На ER модели сущности «Лекарства» объявляются следующие атрибуты,
которые в СУБД (программе) могут иметь следующие типы:

− атрибут «Код лекарства» – есть уникальным целочисленным значением,

которое формируется автоматически. В СУБД это есть поле-счетчик;

− атрибут «Юридическое имя поставщика» – простой атрибут, который

можно реализовать строковым значением (string, Text);

− атрибут «Количество лекарств» – простой атрибут, который можно

реализовать целочисленным значением (int, integer);

10
 − атрибут «Цена лекарств» – простой атрибут, который можно реализовать

целочисленным значением (int, integer);

− атрибут «Необходимость рецепта» – простой атрибут, который можно

реализовать логическим значением (bool, boolean);

− атрибут «Название лекарств» – простой атрибут, который можно

реализовать строковым значением (string, Text);

ER-модель 4 «Учет продаж»

На ER модели сущности «Учет продаж» объявляются следующие атрибуты,
которые в СУБД (программе) могут иметь следующие типы:

− атрибут «Код лекарства» – есть уникальным целочисленным значением,

которое формируется автоматически взятое из сущности «Лекарство». В СУБД

это есть поле-счетчик;

− атрибут «Код покупателя» – есть уникальным целочисленным значением,

которое формируется автоматически, взятое из сущности «Покупатель». В СУБД

это есть поле-счетчик;

− атрибут «Код покупки» – есть уникальным целочисленным значением,

которое формируется автоматически. В СУБД это есть поле-счетчик;

− атрибут «Код фармацевта» – есть уникальным целочисленным значением,

которое формируется автоматически взятое из сущности «Фармацевт». В СУБД

это есть поле-счетчик;

− атрибут «Дата продажи» – простой атрибут типа Дата (DateTime);

11
 − атрибут «Количество проданных лекарств» – простой атрибут, который

можно реализовать целочисленным значением (int, integer);

12
 3. Нормализация отношений.

3.1. Исходные данные

На основании концептуальной модели составим набор предварительных
таблиц. Для проведения процесса нормализации отношений, рассмотрим
исходные данные каждого отношения:
Таблица 1. “Лекарства”

1. У лекарства есть код. Каждое лекарство обязательно имеет уникальный

номер.
2. Лекарство производится производителем. При этом: у каждого лекарства
обязательно есть производитель, и каждый производитель производит хотя бы
один товар.
3. У лекарства есть тип. Каждое лекарство обязательно относится к какому-
либо типу (с рецептом или без него), причем, только к одному. В магазине могут
быть в наличии лекарства не всех типов. Лекарства одного типа может быть
несколько.
4. У лекарства есть название. Каждое лекарство обязательно имеет
название, причем, только к одно. В магазине могут быть в наличии не все
лекарства.
5. У лекарства есть цена. Каждое лекарство обязательно имеет цену,
причем, только одну.
6. Лекарств может быть несколько. Каждое лекарство обязательно имеет
количество, причем, только одно. В магазине могут быть в наличии не все
лекарства.

13
 Таблица будет иметь 6 полей: «Код лекарства» с данными о уникальном
номере лекарства, «Юр. имя поставщика» с данными о юридическом имени
производителя, «Количество лекарств» с данными о количестве имеющихся
лекарств, «Цена лекарств» с данными о стоимости, «Название лекарств» с
данными о названиях лекарств, «Необходимость рецепта» с данными о требуемых
рецептах. С учетом полученных сведений можно заключить, что будет иметь
место дублирование данных. (Табл. 1).
Таблица 2. “Фармацевт”

1. У фармацевта есть код. Каждый фармацевт обязательно имеет

уникальный номер.
2. У фармацевта есть номер телефона. Каждый фармацевт обязательно
имеет номер телефона.
3. У фармацевта есть имя. Каждый фармацевт обязательно имеет имя.
4. У фармацевта есть адрес проживания. Каждый фармацевт обязательно
имеет номер телефона.
Таблица будет иметь 4 полей: «Код фармацевта» с данными о уникальном
номере фармацевта, «ФИО» с данными о имени фармацевта, «Адрес» с данными
о адресе проживания фармацевта, «№ телефона» с данными о номере телефона
фармацевта.С учетом полученных сведений можно заключить, что будет иметь
место дублирование данных. (Табл. 2).
Таблица 3. “Покупатель”

14
 1. У покупателя есть код. Каждый покупатель обязательно имеет
уникальный номер.
2. У покупателя есть номер телефона. Данные о номере телефона
покупателя могут отсутствовать.
3. У фармацевта есть имя. Данные о номере телефона покупателя могут
отсутствовать.
4. У покупателя есть адрес проживания. Данные о адресе проживания
покупателя могут отсутствовать.
Таблица будет иметь 4 полей: «Код покупателя» с данными о уникальном
номере покупателя, «ФИО» с данными о имени покупателя, «Адрес» с данными о
адресе проживания покупателя, «№ телефона» с данными о номере телефона
покупателя. С учетом полученных сведений можно заключить, что будет иметь
место дублирование данных, равно как и отсутствие значений некоторых полей в
записях (Табл. 3).
Таблица 4. “Учет продаж”

1. У покупки есть код. Каждая покупка обязательно имеет уникальный

номер.
2. У покупателя есть код. Каждый покупатель обязательно имеет
уникальный номер.
3. У лекарства есть код. Каждое лекарство обязательно имеет уникальный
номер.
4. У фармацевта есть код. Каждый фармацевт обязательно имеет
уникальный номер.

15
 5. У покупки есть дата. Каждая покупка обязательно имеет дату продажи.
6. Проданных лекарств может быть несколько. Каждое лекарство
обязательно имеет количество, причем, только одно.
Таблица будет имеет 6 полей: «Код покупки» с данными о уникальном
номере покупки, «Код покупателя» с данными о уникальном номере покупателя,
«Код лекарства» с данными о уникальном номере лекарства, «Код фармацевта» с
данными о уникальном номере фармацевта, «Дата продажи» с данными о дате
покупки, «Количество проданных лекарств» с данными о количестве проданных
лекарств. С учетом полученных сведений можно заключить, что будет иметь
место дублирование данных.(Табл. 4).

16
 3.2. Первая нормальная форма
Первая нормальная форма содержит следующий список требований:
- Отсутствие упорядоченных столбцов слева направо.
- Отсутствие повторяющихся строк.
- Каждое пересечение строки и столбца содержит ровно одно значение из
соответствующего домена (и больше ничего).
- Все столбцы должны являться обычными.
- Все атрибуты отношения должны быть простыми, то есть их значения
неделимы (на предварительной схеме не все атрибуты являются простыми).
После приведения отношения “Лекарства” к первой нормальной форме
можно получить, такое отношение (рис. 1).

Рис. 1. 1НФ таблицы “Лекарства”

После приведения отношения “Фармацевт” к первой нормальной форме
можно получить, такое отношение (рис. 2).

Рис. 2. 1НФ таблицы “Фармацевт”

17
 После приведения отношения “Покупателя” к первой нормальной форме
можно получить, такое отношение (рис. 3).

Рис. 3. 1НФ таблицы “Покупатель”

После приведения отношения “Учет продаж” к первой нормальной форме
можно получить, такое отношение (рис. 4).

Рис. 4. 1НФ таблицы “Учет продаж”

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

Рис. 5. Вторая нормальная форма таблицы “Лекарства”

Рис. 6. Вторая нормальная форма таблицы “Фармацевт”

19
Рис. 7. Вторая нормальная форма таблицы “Покупатель”

Рис. 8. Вторая нормальная форма таблицы “Учет продаж”

20
 3.4. Третья нормальная форма
Любой неключевой атрибут нетранзитивно зависит от ключа.
Транзитивная зависимость – ситуация, при которой в некоторой тройке
атрибутов первый зависит от второго, второй от третьего, а третий от первого. В
рассмотренном отношении транзитивные зависимости отсутствуют.

Рис. 9. Схема третьих нормальных форм отношений.

21