База даних лiкарських препаратiв
Курсова робота
"База даних лiкарських препаратiв"
Вступ
iнформацiї в цiй сферi, яку необхiдно згрупувати. Тому темою моєї курсової роботи є розробка бази даних для лiкарських препаратiв.
В результатi використання даної бази даних можна дiзнатися iнформацiю про лiкарський препарат починаючи вiд його виробника, постачальника, до властивостей лiкарського препарату та його застосування.
1.
Постановка задачi
Темою моєї курсової роботи обрано створення бази даних лiкарських препаратiв. Тому перед тим як створювати логiчний та фiзичний проекти БД необхiдно було ознайомитись з даною темою.
Крiм цього необхiдно було вирiшити ще ряд задач, таких як:
· Встановити головнi сутностi;
· Визначити типи зв’язкiв мiж сутностями;
· Визначити якими типами даних повиннi бути атрибути сутностей. [6]
Створення фiзичного проекту БД вiдбувалося в такому порядку:
· Проаналiзувати якiсть створеного логiчного проекту БД;
· Вибрати оптимальну модель СКБД для створення БД;
· На основi логiчного проекту створити фiзичний проект БД.
даних зможе змiнювати данi про лiкарськi препарати за допомогою запитiв на мовi SQL.
2. Теоретична частина
вiдношення може бути в першiй, другiй або в якiйсь – iншiй формi.
В 1970 р., Кодд та iншi визначили першу, другу та третю нормальнi форми (1НФ, 2НФ та 3НФ). Пiзнiше була виведена нормальна форма Бойса – Кодда (НФБК), а потiм четверта та п’ята нормальнi форми. Цi форми являються вкладеними, тобто вiдношення в 2НФ є також вiдношенням в 1НФ.[5, c. 175]
Перша нормальна форма.
Про будь – яку таблицю даних, яка задовольняє визначенню вiдношення, говорять, що вона знаходиться в першiй нормальнiй формi.
Для того, щоб таблиця була вiдношенням, повинно виконуватися: комiрки таблицi повиннi мiстити одиночнi значення та в якостi значень не допускаються нi групи, якi повторяються, нi масиви. Всi записи в одному стовпцi повиннi мати один i той самий тип. Кожен стовпець повинен мати унiкальне iм’я. В таблицi не повинно бути двох однакових строк.
Тобто, вiдношення знаходиться в 1НФ, якщо всi його атрибути являються простими (мають єдине значення). [6, c. 151]
Дане вiдношення знаходиться в першiй нормальнiй формi. Проте, як ми бачимо, воно може мати аномалiї модифiкацiї.
Для того, щоб усунути аномалiї, треба розбити вiдношення на два або бiльше нових вiдношень. Коли ми це робимо, новi вiдношення перебувають в деякiй iншiй нормальнiй формi, а якiй саме, залежить вiд того, якi аномалiї ми усунули, а також вiд того, яким аномалiям пiдтвердженi отриманi форми.
Друга нормальна форма.
У вiдповiдностi з цим визначенням, якщо вiдношення має в якостi ключа одиночний атрибут, то воно автоматично знаходиться в другiй формi. Оскiльки ключ є одиночним атрибутом, то при замовчуваннi кожний не ключовий атрибут залежить вiд всього ключа, та часткових залежностей бути не може. Таким чином, друга нормальна форма мiстить iнтерес тiльки для тих вiдношень, якi мають композитнi ключi. [5]
Ключем комбiнацiї (НазваниеПоставщика, НазваниеПроизводителя), проте мiстить залежнiсть НазваниеПоставщика – КодПоставщика. В цiй залежностi НазваниеПоставщика являє собою лише частину ключа. Тому можна сказати, що атрибут Код поставщика частково залежить вiд ключа таблицi. Аномалiї модифiкацiї не було б, якщо б КодПоставщика залежив вiд всього ключа.
Вiдношення Поставщик – Производитель може бути розбито на два вiдношення в другiй нормальнiй формi, а саме НазваниеПроизводителя – НазваниеПоставщика та НазваниеПоставщика – КодПоставщика. Новi вiдношення знаходяться в другiй нормальнiй формi, оскiльки обидва мають в якостi ключiв одиничнi атрибути.
Третя нормальна форма.
Вiдношення знаходиться в третiй нормальнiй формi, якщо воно знаходиться в другiй нормальнiй формi та не має транзитивних залежностей.
Транзитивнi залежностi породжують надлишкове дублювання iнформацiї у вiдношеннях. [5]
Ключем тут є ЛекарственныйПрепарат, та iснують функцiональнi залежностi ЛекарственныйПрепарат – ЛекарственнаяФорма та ЛекарственнаяФорма – КодЛекарственнойФормы. Оскiльки ЛекарственныйПрепарат визначає атрибут ЛекарственнаяФорма, а ЛекарственнаяФорма визначає атрибут КодЛекарственнойФормы, тодi непрямим образом ЛекарственныйПрепарат – КодЛекарственнойФормы. Така структура функцiональних залежностей називається транзитивною залежнiстю, оскiльки атрибут ЛекарственныйПрепарат визначає атрибут КодЛекарственнойФормы через атрибут ЛекарственнаяФорма.
Для того, щоб видалити аномалiї з вiдношення в другiй нормальнiй формi необхiдно позбутися транзитивної залежностi.
Вiдношення ЛекарственныйПрепарат можна роздiлити на два вiдношення в третiй нормальнiй формi: ЛекарственныйПрепарат – ЛекарственнаяФорма та ЛекарственнаяФорма – КодЛекарственнойФормы.
На практицi побудова третьої нормальної форми схем вiдношень в бiльшостi випадкiв являється достатнiм та приведенням до них процесу проектування реляцiйної бази даних закiнчується.
Нормальна форма Бойса – Кодда (НФБК).
Оригiнальне визначення Коддом для 3НФ не зовсiм пiдходить для вiдношення з умовами:
· Вiдношення має два (або бiльше) потенцiйних ключа
· Два потенцiйних ключа є складними
· Вони перетинаються (тобто, мають по крайнiй мiрi, один спiльний атрибут). [6]
Тому оригiнальне визначення 3НФ було замiнено бiльш строгим визначенням Бойса – Кодда, для якого було прийнято окреме визначення – нормальна форма Бойса – Кодда. Комбiнацiї умов 1, 2 та 3 не часто зустрiчаються на практицi, та для вiдношень без цих умов 3НФ та НФБК еквiвалентнi. [3]
Вiдношення знаходиться в НФБК, якщо кожен детермiнант є ключем – кандидатом.
Вiдношення в НФБК не мають аномалiй, якi вiдносяться до функцiональних залежностей, проте аномалiї можуть бути обумовленi i iншими причинами, крiм функцiональних залежностей. [5]
3. Логiчне проектування
Логiчне проектування полягає в визначеннi кiлькостi та структури таблиць, форматуваннi запитiв до бази даних, створення форм для введення та редагування даних в базi та розв’язку iнших задач.
Процес проектування бази даних включає етапи:
· Видiлення сутностей i зв'язкiв мiж ними;
· Побудова ER – дiаграми;
· Додавання не ключових атрибутiв у вiдношення;
· Приведення вiдношень до нормальної форми Бойса – Кодда;
Перегляд ER – дiаграм у випадках:
· деякi вiдношення не приводяться до нормальної форми Бойса – Кодда;
· деяким атрибути не знаходяться логiчного обґрунтованих мiсць у вiдношеннях.
Метод «сутнiсть – зв'язок» називають також методом ER – дiаграм: по-перше, ER – абревiатура вiд слiв Essence (сутнiсть) та Relation (зв'язок), по-друге, метод основане на використаннi дiаграм, якi називаються вiдповiдно дiаграмами ER – екземплярiв та дiаграмами ER – типа. [6]
Перед тим, як створювати фiзичний проект БД необхiдно створити первiсний проект. Вiн вже буде мiстити всi необхiднi сутностi та зв’язки.
В первiсному проектi бази даних будуть такi сутностi:
· ПроизводительПоставщик – виробник лiкарських препаратiв;
· АнкетаПроизводителя – данi про виробника;
· АнкетаПоставщика – данi про постачальника лiкарських препаратiв;
· ГруппаЛекарственныхПрепаратов – подiл лiкарських препаратiв вiдповiдно до їх груп;
· ЛекарственныеПрепараты – лiкарськi препарати та їх властивостi;
Розглянемо данi сутностi та зв'язок мiж ними та зобразимо їх на ER – дiаграм, яка зображена на додатку «Додаток А».
ПроизводительПоставщик (Счетчик, КодМенеджера) – де Счетчик – номер п/п, КодМенеджера – код менеджера виробника лiкарських препаратiв.
АнкетаПроизводителя (КодМенеджера, НазваниеПроизводителя, ФИОМенеджера, Город, Адрес, Телефон) – де КодМенеджера – код менеджера виробника лiкарських препаратiв, НазваниеПроизводителя – назва виробника лiкарських препаратiв, ФИОМенеджера – прiзвище, iм’я та по батьковi менеджера виробника, Город – мiсто розташування виробника, Адрес – адреса виробника, Телефон – телефон виробника.
АнкетаПоставщика (КодМенеджераПоставщика, НазваниеПоставщика, ФИОМенеджераПоставщика, ГородПоставщика, АдресПоставщика, ТелефонПоставщика) – де КодМенеджераПоставщика – код менеджера постачальника лiкарських препаратiв, НазваниеПоставщика – назва постачальника лiкарських препаратiв, ФИОМенеджераПоставщика – прiзвище, iм’я та по батьковi менеджера постачальника, ГородПоставщика – мiсто розташування постачальника лiкарських препаратiв, АдресПоставщика – адреса постачальника, ТелефонПоставщика – телефон постачальника.
ГруппаЛекарственныхПрепаратов (ЛекарственныеФормы, КодЛекарственнойФормы) – де ЛекарственныеФормы – назва лiкарської форми, КодЛекарственнойФормы – код лiкарської форми.
ЛекарственныеПрепараты (КодЛекарственногоПрепарата, НазваниеЛекарственногоПрепарата, ДействующееВещество, Применение, ПобочныеДействия) – де КодЛекарственногоПрепарата – код лiкарського препарату, НазваниеЛекарственногоПрепарата – назва лiкарського препарату, ДействующееВещество – дiюча речовина, яка є складовою лiкарського препарату, Применение – застосування, тобто при яких хворобах можна застосовувати даний лiкарський препарат, ПобочныеДействия – побiчнi дiї, якi пов’язанi з використанням даного лiкарського препарату.
iншi вiдношення.
Зв’яжемо таблицi ПроизводительПоставщик та ЛекарственныеПрепараты за допомогою вiдношення перетину – ЛекарственныйПрепаратПроизводитель, проте тодi мiж даними вiдношеннями буде зв'язок «багато до багатьох». Щоб представити цей зв'язок визначимо три вiдношення: по одному вiдношенню для кожного з об’єктiв та вiдношення перетину. Вiдношення перетину представляє зв'язок двох об’єктiв та складається з ключiв своїх батькiв. [5, c. 262]
ГруппаЛекарственныхПрепаратов мають зв'язок «багато до багатьох»
Зв’яжемо таблицi Производитель та АнкетаПоставщика за допомогою допомiжного поля у вiдношеннi Производитель КодМенеджераПоставщика – код менеджера постачальника лiкарських препаратiв.
Тобто пiсля того, як ми зв’язали таблицi утворилися новi вiдношення, а саме:
ПроизводительПоставщик (Счетчик, КодМенеджера, КодМенеджераПоставщик)
АнкетаПроизводителя (КодМенеджера, НазваниеПроизводителя, ФИОМенеджера, Город, Адрес, Телефон)
ЛекарственныйПрепаратПроизводитель (Счетчик, КодЛекарственногоПрепарата)
ЛекарственныеПрепараты (КодЛекарственногоПрепарата, НазваниеЛекарственногоПрепарата, ДействующееВещество, Применение, ПобочныеДействия)
ГруппаЛекарственныхПрепаратов (ЛекарственныеФормы, КодЛекарственнойФормы)
ЛекарственныйПрепаратГруппа (КодЛекарственнойФормы, КодЛекарственногоПрепарата)
АнкетаПоставщика (КодМенеджераПоставщика, НазваниеПоставщика, ФИОМенеджераПоставщика, ГородПоставщика, АдресПоставщика, ТелефонПоставщика).
Перевiримо данi вiдношення на нормальнi форми.
залежностей, тобто вони знаходяться в 3НФ. Всi вiдношення належать до НФБК, так як не мають складних ключiв.
Реляцiйна схема мiститься на Додатку Б.
Логiчний проект, який ми розглянули в попередньому роздiлi, бази даних є простим у розумiннi i простим для реалiзацiї на ЕОМ, тому найзручнiше використовувати реляцiйний тип бази даних.
При розробцi бази даних не було застосовано Oracleта SQLServer, оскiльки вони використовуються для баз даних з великою кiлькiстю користувачiв.
Дана курсова робота була написана на мовi запитiв SQL при використаннi MicrosoftAccess, оскiльки MicrosoftAccess використовується для невеликих персональних i колективних баз даних, на MicrosoftAccess можливо швидко розробляти БД, вiдносно невисока вартiсть СУБД та те, що в iнститутi є лiцензiя на використання.
5. Фiзичне проектування
Першою створювалась таблиця ПроизводительПоставщик, з трьома полями, Счетчик – первiсний ключ для таблицi ПроизводительПоставщик. Ця таблиця мiстить данi про код менеджера виробника лiкарського препарату, код постачальника лiкарського препарату.
Потiм створювалась таблиця АнкетаПроизводителя, у якої первiсним ключем є поле КодМенеджера, яке також є зовнiшнiм ключем для таблицi АнкетаПроизводителя. Таблиця АнкетаПроизводителя мiстить данi про виробникiв, а саме прiзвище менеджера, мiсто розташування виробника, адресу та телефон.
препаратiв, а саме прiзвище менеджера, мiсто розташування виробника, адресу та телефон.
мiстить назву лiкарських форм.
Таблиця ЛекарственныеПрепараты, у якої первiсним ключем є поле КодЛекарственногоПрепарата для таблицi ЛекарственныеПрепараты та зовнiшнiм ключем. Таблиця ЛекарственныеПрепараты мiстить назву лiкарських препаратiв та їх властивостi:
Програми створення таблиць зображено на додатку «Додаток В».
З’ясуємо можливостi даної бази даних.
Запит про лiкарськi препарати, якi виробляє Здоровье показано на додатку «Додаток Г».
Запит про лiкарськi препарати, якi виробляє Дарница показано на додатку «Додаток Д».
Запит про лiкарськi препарати, його застосування, побiчнi дiї та форму випуску показано на додатку «Додаток Д».
Запит про лiкарський препарат, його форму та виробника показано на додатку «Додаток Е».
Запит про зв'язок мiж виробником, постачальником та лiкарським препаратом показано на додатку «Додаток Ж».
6. Розробка iнтерфейсу
Важливе значення для сприйняття користувачем бази даних є її iнтерфейс. В данiй базi даних iнтерфейс будемо проектувати за допомогою форм та звiтiв.
Звiт – форматоване вiдображення iнформацiї з бази даних. Звiти предназначенi для виводу даних на друк.
Форми i звiти в данiй базi даних зробленi за допомогою майстра.
· АнкетаПоставщика та АнкетаПроизводителя: зовнiшнiй вигляд – в один стовпець, стиль – промисловий.
· Всi останнi таблицi: зовнiшнiй вигляд – стрiчковий, стиль – промисловий.
Форми запитiв мають такi характеристики:
· Данные о поставщике и лекарственных препаратах: зовнiшнiй вигляд – в один стовпець, стиль – промисловий.
· Всi останнi запити: зовнiшнiй вигляд – стрiчковий, стиль – промисловий.
Звiти по запитам мають такi характеристики: макет для звiту – табличний, стиль – дiловий.
Висновки
Дану базу даних можна застосовувати на пiдприємствах якi займаються виробництвом, постачанням або реалiзацiї лiкарських препаратiв. База даних дозволяє знаходити потрiбну iнформацiю не застосовуючи тривалого пошуку, що цiлком заощаджує час. Вона дозволяє вносити змiни у данi чи додавати iнформацiю, не руйнуючи практичної будови самої системи.
логiчного та фiзичного проекту бази даних.
Спроектована база даних мiстить основну iнформацiю про лiкарськi препарати, але цю базу даних можна значно розширити, додаючи таблицi з аптеками якi реалiзують данi лiкарськi препарати, їх вартiсть, та в свою чергу з якими постачальниками та виробниками ефективнiше працювати з економiчної точки зору.
Список використаної лiтератури
4. Смирнов І.І. Збiрка лабораторних робiт з СУБД Жовтi Води 2003 р.
5. Д. Крёнке Теория и практика построения баз данных Питер 2003 г.
6. А. Хомоненко Базы данных Санки – Петербург Корона 2004 г.
7. Ф. Тринкус Фармако – терапевтический справочник Киев Здоровье 2004 г.
8. Б. Петровський Популярная медицинская энциклопедия Москва 2003 г.
9. О. В. Гаврилова Бази даних. Санкт-Петербург, «Питер», 2002.
| 
