База даних лікарських препаратів

Курсова робота

"База даних лікарських препаратів"

Вступ

Останнім часом відбувається значний розвиток у хімічній промисловості, а саме в розробці лікарських препаратів. Щорічно реєструється понад чотири тисячі нових лікарських препаратів. Це свідчить про збільшення інформації в цій сфері, яку необхідно згрупувати. Тому темою моєї курсової роботи є розробка бази даних для лікарських препаратів.

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

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

Тобто користувачем базою даних може бути безпосередньо як споживач, так і розповсюджувачі лікарських препаратів (постачальники, виробники).

1. Постановка задачі

Темою моєї курсової роботи обрано створення бази даних лікарських препаратів. Тому перед тим як створювати логічний та фізичний проекти БД необхідно було ознайомитись з даною темою.

Крім цього необхідно було вирішити ще ряд задач, таких як:

Визначити основні властивості та характеристики лікарських препаратів, які повинні бути в базі даних;

Встановити головні сутності;

Визначити типи зв’язків між сутностями;

Визначити якими типами даних повинні бути атрибути сутностей. [6]

Створення фізичного проекту БД відбувалося в такому порядку:

Намалювати ER-діаграму з усіма атрибутами, яка відображатиме зв’язок між сутностями;

Проаналізувати якість створеного логічного проекту БД;

Вибрати оптимальну модель СКБД для створення БД;

На основі логічного проекту створити фізичний проект БД.

Вхідною інформацією для даної бази даних буде інформація про виробників лікарських препаратів, постачальників, групи, властивості лікарських препаратів та багато інших характеристик. Користувач даною базою даних зможе змінювати дані про лікарські препарати за допомогою запитів на мові SQL.

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

2. Теоретична частина

Відношення можна класифікувати по типам аномалій модифікацій, яким вони підтверджені. Класи відношень та способи попередження аномалій називаються нормальними формами. В залежності від своєї структури, відношення може бути в першій, другій або в якійсь – іншій формі.

В 1970 р., Кодд та інші визначили першу, другу та третю нормальні форми (1НФ, 2НФ та 3НФ). Пізніше була виведена нормальна форма Бойса – Кодда (НФБК), а потім четверта та п’ята нормальні форми. Ці форми являються вкладеними, тобто відношення в 2НФ є також відношенням в 1НФ. [5, c. 175]

Перша нормальна форма.

Про будь – яку таблицю даних, яка задовольняє визначенню відношення, говорять, що вона знаходиться в першій нормальній формі.

Для того, щоб таблиця була відношенням, повинно виконуватися: комірки таблиці повинні містити одиночні значення та в якості значень не допускаються ні групи, які повторяються, ні масиви. Всі записи в одному стовпці повинні мати один і той самий тип. Кожен стовпець повинен мати унікальне ім’я. В таблиці не повинно бути двох однакових строк.

Тобто, відношення знаходиться в 1НФ, якщо всі його атрибути являються простими (мають єдине значення). [6, c. 151]

Дане відношення знаходиться в першій нормальній формі. Проте, як ми бачимо, воно може мати аномалії модифікації.

Для того, щоб усунути аномалії, треба розбити відношення на два або більше нових відношень. Коли ми це робимо, нові відношення перебувають в деякій іншій нормальній формі, а якій саме, залежить від того, які аномалії ми усунули, а також від того, яким аномаліям підтверджені отримані форми.

Друга нормальна форма.

Відношення знаходиться в другій нормальній формі, якщо воно знаходиться в першій нормальній формі та всі його не ключові атрибути залежать від всього ключа. [3 c. 50]

У відповідності з цим визначенням, якщо відношення має в якості ключа одиночний атрибут, то воно автоматично знаходиться в другій формі. Оскільки ключ є одиночним атрибутом, то при замовчуванні кожний не ключовий атрибут залежить від всього ключа, та часткових залежностей бути не може. Таким чином, друга нормальна форма містить інтерес тільки для тих відношень, які мають композитні ключі. [5]

Щоб зрозуміти, що таке друга нормальна форма, розглянемо попереднє відношення Поставщик – Производитель. Проблема з цим відношенням в тому, що воно містить залежність, яка стосується тільки частини ключа. Ключем комбінації (НазваниеПоставщика, НазваниеПроизводителя), проте містить залежність НазваниеПоставщика – КодПоставщика. В цій залежності НазваниеПоставщика являє собою лише частину ключа. Тому можна сказати, що атрибут Код поставщика частково залежить від ключа таблиці. Аномалії модифікації не було б, якщо б КодПоставщика залежив від всього ключа.

Відношення Поставщик – Производитель може бути розбито на два відношення в другій нормальній формі, а саме НазваниеПроизводителя – НазваниеПоставщика та НазваниеПоставщика – КодПоставщика. Нові відношення знаходяться в другій нормальній формі, оскільки обидва мають в якості ключів одиничні атрибути.

Третя нормальна форма.

Відношення знаходиться в третій нормальній формі, якщо воно знаходиться в другій нормальній формі та не має транзитивних залежностей.

Транзитивні залежності породжують надлишкове дублювання інформації у відношеннях. [5]

Ключем тут є ЛекарственныйПрепарат, та існують функціональні залежності ЛекарственныйПрепарат – ЛекарственнаяФорма та ЛекарственнаяФорма – КодЛекарственнойФормы. Оскільки ЛекарственныйПрепарат визначає атрибут ЛекарственнаяФорма, а ЛекарственнаяФорма визначає атрибут КодЛекарственнойФормы, тоді непрямим образом ЛекарственныйПрепарат – КодЛекарственнойФормы. Така структура функціональних залежностей називається транзитивною залежністю, оскільки атрибут ЛекарственныйПрепарат визначає атрибут КодЛекарственнойФормы через атрибут ЛекарственнаяФорма.

Для того, щоб видалити аномалії з відношення в другій нормальній формі необхідно позбутися транзитивної залежності.

Відношення ЛекарственныйПрепарат можна розділити на два відношення в третій нормальній формі: ЛекарственныйПрепарат – ЛекарственнаяФорма та ЛекарственнаяФорма – КодЛекарственнойФормы.

На практиці побудова третьої нормальної форми схем відношень в більшості випадків являється достатнім та приведенням до них процесу проектування реляційної бази даних закінчується.

Нормальна форма Бойса – Кодда (НФБК).

Оригінальне визначення Коддом для 3НФ не зовсім підходить для відношення з умовами:

Відношення має два (або більше) потенційних ключа

Два потенційних ключа є складними

Вони перетинаються (тобто, мають по крайній мірі, один спільний атрибут). [6]

Тому оригінальне визначення 3НФ було замінено більш строгим визначенням Бойса – Кодда, для якого було прийнято окреме визначення – нормальна форма Бойса – Кодда. Комбінації умов 1, 2 та 3 не часто зустрічаються на практиці, та для відношень без цих умов 3НФ та НФБК еквівалентні. [3]

Відношення знаходиться в НФБК, якщо кожен детермінант є ключем – кандидатом.

Відношення в НФБК не мають аномалій, які відносяться до функціональних залежностей, проте аномалії можуть бути обумовлені і іншими причинами, крім функціональних залежностей. [5]

3. Логічне проектування

Логічне проектування полягає в визначенні кількості та структури таблиць, форматуванні запитів до бази даних, створення форм для введення та редагування даних в базі та розв’язку інших задач.

Процес проектування бази даних включає етапи:

Виділення сутностей і зв'язків між ними;

Побудова ER – діаграми;

Формування набору попередніх відношень з вкладанням первинного ключа для кожного відношення та використанні діаграми ER – типа;

Додавання не ключових атрибутів у відношення;

Приведення відношень до нормальної форми Бойса – Кодда;

Перегляд ER – діаграм у випадках:

деякі відношення не приводяться до нормальної форми Бойса – Кодда;

деяким атрибути не знаходяться логічного обґрунтованих місць у відношеннях.

Метод «сутність – зв'язок» називають також методом ER – діаграм: по-перше, ER – абревіатура від слів Essence (сутність) та Relation (зв'язок), по-друге, метод основане на використанні діаграм, які називаються відповідно діаграмами ER – екземплярів та діаграмами ER – типа. [6]

Перед тим, як створювати фізичний проект БД необхідно створити первісний проект. Він вже буде містити всі необхідні сутності та зв’язки.

В первісному проекті бази даних будуть такі сутності:

ПроизводительПоставщик – виробник лікарських препаратів;

АнкетаПроизводителя – дані про виробника;

АнкетаПоставщика – дані про постачальника лікарських препаратів;

ГруппаЛекарственныхПрепаратов – поділ лікарських препаратів відповідно до їх груп;

ЛекарственныеПрепараты – лікарські препарати та їх властивості;

Розглянемо дані сутності та зв'язок між ними та зобразимо їх на ER – діаграм, яка зображена на додатку «Додаток А».

ПроизводительПоставщик (Счетчик, КодМенеджера) – де Счетчик – номер п/п, КодМенеджера – код менеджера виробника лікарських препаратів.

АнкетаПроизводителя (КодМенеджера, НазваниеПроизводителя, ФИОМенеджера, Город, Адрес, Телефон) – де КодМенеджера – код менеджера виробника лікарських препаратів, НазваниеПроизводителя – назва виробника лікарських препаратів, ФИОМенеджера – прізвище, ім’я та по батькові менеджера виробника, Город – місто розташування виробника, Адрес – адреса виробника, Телефон – телефон виробника.

АнкетаПоставщика (КодМенеджераПоставщика, НазваниеПоставщика, ФИОМенеджераПоставщика, ГородПоставщика, АдресПоставщика, ТелефонПоставщика) – де КодМенеджераПоставщика – код менеджера постачальника лікарських препаратів, НазваниеПоставщика – назва постачальника лікарських препаратів, ФИОМенеджераПоставщика – прізвище, ім’я та по батькові менеджера постачальника, ГородПоставщика – місто розташування постачальника лікарських препаратів, АдресПоставщика – адреса постачальника, ТелефонПоставщика – телефон постачальника.

ГруппаЛекарственныхПрепаратов (ЛекарственныеФормы, КодЛекарственнойФормы) – де ЛекарственныеФормы – назва лікарської форми, КодЛекарственнойФормы – код лікарської форми.

ЛекарственныеПрепараты (КодЛекарственногоПрепарата, НазваниеЛекарственногоПрепарата, ДействующееВещество, Применение, ПобочныеДействия) – де КодЛекарственногоПрепарата – код лікарського препарату, НазваниеЛекарственногоПрепарата – назва лікарського препарату, ДействующееВещество – діюча речовина, яка є складовою лікарського препарату, Применение – застосування, тобто при яких хворобах можна застосовувати даний лікарський препарат, ПобочныеДействия – побічні дії, які пов’язані з використанням даного лікарського препарату.

На даному етапі проектування бази даних повтор атрибутів спостерігається в таблицях ПроизводительПоставщик і АнкетаПроизводителя. Проте повтор атрибутів буде необхідний для того щоб зв’язати між собою інші відношення.

Зв’яжемо таблиці ПроизводительПоставщик та ЛекарственныеПрепараты за допомогою відношення перетину – ЛекарственныйПрепаратПроизводитель, проте тоді між даними відношеннями буде зв'язок «багато до багатьох». Щоб представити цей зв'язок визначимо три відношення: по одному відношенню для кожного з об’єктів та відношення перетину. Відношення перетину представляє зв'язок двох об’єктів та складається з ключів своїх батьків. [5, c. 262]

Зв’яжемо таблиці ЛекарственныеПрепараты та ГруппаЛекарственныхПрепаратов аналогічним способом за допомогою допоміжного відношення – ЛекарственныйПрепаратГруппа. Тоді відношення ЛекарственныеПрепараты та ГруппаЛекарственныхПрепаратов мають зв'язок «багато до багатьох»

Зв’яжемо таблиці Производитель та АнкетаПоставщика за допомогою допоміжного поля у відношенні Производитель КодМенеджераПоставщика – код менеджера постачальника лікарських препаратів.

Тобто після того, як ми зв’язали таблиці утворилися нові відношення, а саме:

ПроизводительПоставщик (Счетчик, КодМенеджера, КодМенеджераПоставщик)

АнкетаПроизводителя (КодМенеджера, НазваниеПроизводителя, ФИОМенеджера, Город, Адрес, Телефон)

ЛекарственныйПрепаратПроизводитель (Счетчик, КодЛекарственногоПрепарата)

ЛекарственныеПрепараты (КодЛекарственногоПрепарата, НазваниеЛекарственногоПрепарата, ДействующееВещество, Применение, ПобочныеДействия)

ГруппаЛекарственныхПрепаратов (ЛекарственныеФормы, КодЛекарственнойФормы)

ЛекарственныйПрепаратГруппа (КодЛекарственнойФормы, КодЛекарственногоПрепарата)

АнкетаПоставщика (КодМенеджераПоставщика, НазваниеПоставщика, ФИОМенеджераПоставщика, ГородПоставщика, АдресПоставщика, ТелефонПоставщика).

Перевіримо дані відношення на нормальні форми.

Всі відношення належать до 1НФ, оскільки всі атрибути таблиць є простими, тобто мають єдине значення. Всі відношення належать до 2НФ, оскільки в якості ключа є одиночний атрибут. Відношення не мають транзитивних залежностей, тобто вони знаходяться в 3НФ. Всі відношення належать до НФБК, так як не мають складних ключів.

Реляційна схема міститься на Додатку Б.

4. Обрання програмного забезпечення

Логічний проект, який ми розглянули в попередньому розділі, бази даних є простим у розумінні і простим для реалізації на ЕОМ, тому найзручніше використовувати реляційний тип бази даних.

При розробці бази даних не було застосовано Oracle та SQL Server, оскільки вони використовуються для баз даних з великою кількістю користувачів.

Дана курсова робота була написана на мові запитів SQL при використанні Microsoft Access, оскільки Microsoft Access використовується для невеликих персональних і колективних баз даних, на Microsoft Access можливо швидко розробляти БД, відносно невисока вартість СУБД та те, що в інституті є ліцензія на використання.

5. Фізичне проектування

На основі створеного логічного проекту будується фізична модель бази даних. Спершу створюються головні таблиці до яких потім додаються зовнішні ключі – зв’язки між таблицями.

Першою створювалась таблиця ПроизводительПоставщик, з трьома полями, Счетчик – первісний ключ для таблиці ПроизводительПоставщик. Ця таблиця містить дані про код менеджера виробника лікарського препарату, код постачальника лікарського препарату.

Потім створювалась таблиця АнкетаПроизводителя, у якої первісним ключем є поле КодМенеджера, яке також є зовнішнім ключем для таблиці АнкетаПроизводителя. Таблиця АнкетаПроизводителя містить дані про виробників, а саме прізвище менеджера, місто розташування виробника, адресу та телефон.

Таблиця АнкетаПоставщика, у якої первісним ключем є поле КодМенеджераПоставщика, яке також є зовнішнім ключем для таблиці АнкетаПоставщика. Таблиця АнкетаПоставщика містить дані про постачальників лікарських препаратів, а саме прізвище менеджера, місто розташування виробника, адресу та телефон.

Таблиця ГруппаЛекарственныхПрепаратов, у якої первісним ключем є поле КодЛекарственнойФормы, яке також є зовнішнім ключем для таблиці ГруппаЛекарственныхПрепаратов. Таблиця ГруппаЛекарственныхПрепаратов містить назву лікарських форм.

Таблиця ЛекарственныеПрепараты, у якої первісним ключем є поле КодЛекарственногоПрепарата для таблиці ЛекарственныеПрепараты та зовнішнім ключем. Таблиця ЛекарственныеПрепараты містить назву лікарських препаратів та їх властивості:

Програми створення таблиць зображено на додатку «Додаток В».

З’ясуємо можливості даної бази даних.

Запит про дані постачальника та лікарських препаратах, які він реалізовує показано на додатку «Додаток Г».

Запит про лікарські препарати, які виробляє Здоровье показано на додатку «Додаток Г».

Запит про лікарські препарати, які виробляє Дарница показано на додатку «Додаток Д».

Запит про лікарські препарати, його застосування, побічні дії та форму випуску показано на додатку «Додаток Д».

Запит про лікарський препарат, його форму та виробника показано на додатку «Додаток Е».

Запит про зв'язок між виробником, постачальником та лікарським препаратом показано на додатку «Додаток Ж».

6. Розробка інтерфейсу

Важливе значення для сприйняття користувачем бази даних є її інтерфейс. В даній базі даних інтерфейс будемо проектувати за допомогою форм та звітів.

Форма представляє собою об’єкт бази даних, в якому розробник розміщує елементи управління, які приймають дії користувачів та служать для вводу, відображення та зміни даних в полях.

Звіт – форматоване відображення інформації з бази даних. Звіти предназначені для виводу даних на друк.

Форми і звіти в даній базі даних зроблені за допомогою майстра.

Форми таблиць мають такі характеристики:

АнкетаПоставщика та АнкетаПроизводителя: зовнішній вигляд – в один стовпець, стиль – промисловий.

Всі останні таблиці: зовнішній вигляд – стрічковий, стиль – промисловий.

Форми запитів мають такі характеристики:

Данные о поставщике и лекарственных препаратах: зовнішній вигляд – в один стовпець, стиль – промисловий.

Всі останні запити: зовнішній вигляд – стрічковий, стиль – промисловий.

Звіти по таблицям мають такі характеристики: макет для звіту – табличний, стиль – напівжирний.

Звіти по запитам мають такі характеристики: макет для звіту – табличний, стиль – діловий.

Висновки

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

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

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

В процесі курсової роботи були виконані всі поставлені задачі.

Список використаної літератури

1.Смирнов І.І. Методичні вказівки до виконання курсової роботи Жовті Води 2003 р.

2.Смирнов І.І. Методичні вказівки до виконання курсової роботи Жовті Води 2002 р.

3.Смирнов І.І. Курс лекций по СУБД Желтые Води 2002 р.

4.Смирнов І.І. Збірка лабораторних робіт з СУБД Жовті Води 2003 р.

5.Д. Крёнке Теория и практика построения баз данных Питер 2003 г.

6.А. Хомоненко Базы данных Санки – Петербург Корона 2004 г.

7.Ф. Тринкус Фармако – терапевтический справочник Киев Здоровье 2004 г.

8.Б. Петровський Популярная медицинская энциклопедия Москва 2003 г.

9.О.В. Гаврилова Бази даних. Санкт-Петербург, «Питер», 2002.