Курсовая работа: Создание базы данных аптек
Выделим основные сущности:
· сущность «Аптека»;
· сущность «Изготовитель»;
· сущность «Препарат».
Сущность «Аптеки» содержит информацию обо всех аптеках, в которых ведется продажа препаратов. Отдельный экземпляр этой сущности соответствует не конкретному экземпляру аптеки, а описанию аптеки в целом. В аптеках продается множество препаратов, поэтому вводится сущность «Препарат». Каждый экземпляр сущности «Препарат» содержит информацию о конкретном препарате. Между сущностью «Аптека» и сущностью «Препарат» существует связь типа «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. Структура таблицы «Аптека» РБД «Аптеки-Препараты»
|
К-во Просмотров: 579
Бесплатно скачать Курсовая работа: Создание базы данных аптек
|