«Розробка бази даних діяльності реєстратури поліклініки»




Скачать 339.88 Kb.
Название«Розробка бази даних діяльності реєстратури поліклініки»
страница1/3
Дата публикации28.03.2013
Размер339.88 Kb.
ТипКурсовой проект
www.vbibl.ru > Медицина > Курсовой проект
  1   2   3


МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

Кафедра інформаційних систем
" Розробка бази даних діяльності реєстратури поліклініки"

Пояснювальна записка до курсового проекту

з дисципліни «Інструментальні методи розробки та

підтримки розподілених баз даних»

Спеціальність «7.080401 Інформаційні управляючі системи та технології в економіці»


Студент

Краснянська М.В.. _______________ 12.03.2008
Керівник

Юхно И. А. _______________ 30.05.2008

Харків, 2008

^ МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

Кафедра інформаційних систем

«ЗАТВЕРДЖУЮ»
Зав. кафедрой
ЗАВДАННЯ

З курсового проектування
студенці 2 курсу 3 групи факультета ЕІ

Краснянській Марії Вікторівні

1.Тема: «Розробка бази даних діяльності реєстратури поліклініки».

2. Вихідні дані до проекту: Створення основних видів забезпечень для рішення задачі " Реєстратура поліклініки ".

3. Зміст пояснювальної записки: Вступ. 1. Дослідження предметної області. 2. Концептуальне проектування. 3. Інфологічне проектування БД. 4. Реляційна модель БД. 5. Датологічне проектування БД. 6. Запити до БД. 7. Розробка механізмів захисту даних від несанкціонованого втручання. 8.Вимоги до технічного забезпечення. 9. Інструкція з використання БД. Висновки.

4. Перелік графічного матеріалу з точним указанням необхідних креслень: Інфологічна модель.

5. Дата видачі завдання 19.03.2008.

6. Срок сдачи закінченого проекту 30.05.2008.



Керівник проекту _______________

Завдання прийняв для виконання 19.03.2008 _______________


РЕФЕРАТ

^


Сведения о проекте: 33 стр., 5 рис., 8 табл., 6 источников, 1 приложения.


Курсовой проект состоит из девяти разделов. Первый раздел представляет собой обследование предметной области, 2 раздел – концептуальное проектирование, 3- инфологическое проектирование, 4- реляционную модель, 5 - даталогическое проектирование БД, 6 – запросы к БД, в 7 были разработаны механизмы защиты данных от несанкционированного доступа. Восьмой раздел содержит требования к техническому обеспечению. Инструкция по использованию БД находится в девятом разделе.

Ключевые слова: РЕЛЯЦИОННАЯ БД, ЗАПРОСЫ, КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ, АТРИБУТЫ, СВЯЗЬ.


СОДЕРЖАНИЕ

Введение…………………………………………………………………………..5

1.Обследование предметной области…………………………………………...7

2. Концептуальное проектирование……………………………………………..8

    1. Перечень сущностей (обосновать список)…………………………………..8

    2. Перечень атрибутов…………………………………………………………...8

3. Инфологическое проектирование БД………………………………………...10

    1. Модель "сущность-связь"………………………………………………...…..10

    2. Классификация связей………………………………………………………..12

4.Реляционная модель БД……………………………………………………….13

4.1 Функциональные зависимости между атрибутами………………………..13

4.2 Выбор ключей………………………………………………………………..12

4.3 Нормализация отношений…………………………………………………..14

5.Даталогическое проектирование БД………………………………………….16

  1. Состав таблиц БД…………………………………………………………….16

  2. Средства поддержания целостности………………………………………..18

6.Запросы к БД…………………………………………………………………....19

7.Разработка механизмов защиты данных от несанкционированного доступа…………………………………….........................………………………21

  1. .Требования к техническому обеспечению…………………………………..23

  2. . Инструкция по использованию БД………………………………………….25




  1. Вызов программы……………………………………………………………25

  2. Экранные формы……………………………………………………………..25

  3. Описание отчетов…………………………………………………………….26

Выводы…………………………………………………………………………..27

Список использованных источников………………………………………….28

Приложение А…………………………………………………………………..29

ВВЕДЕНИЕ
Целью создания этого курсового проекта является закрепление теоретических и практических знаний относительно проектирования, разработки и введение в эксплуатацию базы данных. Для этого спроектируем базу данных для регистратуры ведомственной поликлиники «Эскулап», которая организуют запись пациентов на прием к врачам поликлиники. База данных необходимая для учета и систематизации информации о пациентах данной поликлиники, врачах, а так же о ведении према и оплате услуг. Также база данных будет нужна для автоматизации разнообразных бизнесов-процессов, получение разнообразных статистических данных и запросов на получение необходимой информации.

Разработанная база данных должна помогать работникам регистратуры путем получения мгновенных ответов на отосланные запросы. Запросы могуть касаться деятельности как врачей (их загрузка, и т.п.), так и разнообразные данные о пациентах и их обслуживании. Экономический эффект от внедрения базы данных является очевидным, так как автоматизується сам процесс получения разнообразной информации на ряде со старинным сбором с бумажных архивов.

Для базы данных разработчик предъявляет такие требования:

информативность базы данных;

возможность иметь резервную копию данных;

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

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

выполнять точный и полный анализ данных;

защита информации от несанкционированного доступа.

Права пользователей базы данных, их права на разнообразные действия над информацией будет рассмотрено в пункте 7 "Разработка механизмов защиты данных от несанкционированного доступа".

Современные СУБД в основном являются приложениями Wіndows, так как данная среда разрешает более полно использовать возможности персональной ЭВМ, чем среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Wіndows, где разработчик программного обеспечения может в меньше степени проявлять заботу о распределении ресурсов, но также сделал программное обеспечение ПК в целому и СУБД в частности менее критическими к аппаратным ресурсам ЭВМ.

Среди наиболее ярких представителей систем управления базами данных можно отметить: Mіcrosoft Access, Borland dBase, Borland Paradox, Mіcrosoft Vіsual FoxPro, ADO.Net, а также баз данных MySQL, Mіcrosoft SQL Server и Oracle. Именно на последний мы и остановимся, как на одному з наилучших вариантов, построенной по технологии "клиент-сервер", так как на ряде с СУБД, современный подход к управлению базами данных имеет на внимании широкое использование технологии "клиент-сервер".

На сегодняшний день разработчик не связан рамками какого-нибудь конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения.

  1. ^ ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ


Данная база данных разрабатывается для отдела кадров регистратуры ведомственной поликлиники «Эскулап».

Работники регистратуры организуют запись пациентов на прием к врачам поликлиники. Так как поликлиника ведомственная, медицинское обслуживание работников предприятия – бесплатное (за счет средств предприятия).

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

Доступ к базе данных осуществляется благодаря языку SQL. Работу с данными пользователь может осуществлять с помощью SQL – запросов.

Разрабатываемая база данных обеспечивает реализацию следующих бизнес процессов:

  1. Запись на прием к врачу

  2. Определение стоимости лечения

  3. Ведение карточек пациентов

  1. ^ КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ




    1. Перечень сущностей (обосновать список).


Сущность - некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных, имеющий определенный набор свойств - атрибутов. Сущности могут быть как физические (реально существующие объекты), так и абстрактные. Для сущностей различают ее тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр - конкретными значениями свойств.

Набор сущностей – группа сущностей одного типа, которые имеют одни свойства.

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

  • Данные о врачах

  • Данные о пациентах

  • Данные о приемах

  • Специализации

  • Образование

  • Льгота




    1. Перечень атрибутов.


Атрибут (atribute) - поименованный столбец отношения. В качестве атрибутов была дана таблица с данными, рис.1.

№ 1

Поле

Тип

Размер

Описание

DoctorID

Числовой

2

Идентификационный номер врача

2

LastName

Текстовый

20

Фамилия врача

3

FirstName

Текстовый

20

Имя врача

4

Patronymic

Текстовый

20

Отчество врача

5

Room

Числовой

3

Номер кабинета

6

University

Текстовый

40

Образование (университет)

7

Type

Текстовый

20

Специализация (терапевт, лор...)

8

Experience

Числовой

2

Стаж работы

9

Phone

Текстовый

10

Номер рабочего телефона

10

Born

Числовой

4

Год рождения

11

Picture

Поле OLE

Авто

Фотография врача

12

Fio

Текстовый

60

ФИО пациента

13

Number

Текстовый

10

Номер карточки пациента

14

Address

Текстовый

80

Адрес пациента

15

District

Текстовый

20

Район города, где проживает

16

PolicyNumber

Текстовый

20

Номер страхового полиса

17

Year

Числовой

4

Год рождения пациента

18

Sign

Логический

1

Работник предприятия (да/нет)

19

Department

Текстовый

40

Отдел, в котором работает

20

TreatyID

Числовой

10

Идент. номер записи на прием

21

DateStart

Дата

Авто

Дата приема

22

TimeStart

Текстовый

10

Время приема

23

Cost

Денежный

15

Стоимость приема

24

ExemptID

Числовой

2

Идентификатор льготы

25

ExemptType

Текстовый

60

Название льготы (инвалид, ветеран)

26

Exempt

Денежный

15

Сумма льготы

27

Summa

Денежный

15

К оплате

28

Comment

Поле Memo

Авто

Примечания (результаты приема)


Рис.1. Набор данных к варианту

Данные о врачах (идентификационный номер, фамилия, имя, отчество, номер кабинета, образование, специализация, стаж работы, номер рабочего телефона, год рождения, фотография);

Данные о пациентах (ФИО, номер карточки, адрес, район города, где проживает, номер страхового полиса, год рождения, работник предприятия, отдел, в котором работает, льгота );

Данные о приемах (идент. номер записи на прием, дата приема, время приема, стоимость приема, врач, пациент, к оплате, примечания (результаты приема));

Специализации (идентификатор специализации, специализация);

Образование (идентификатор вуза, вуз, адрес вуза);

Льгота (идентификатор льготы, название льготы, сумма льготы);


  1. ^ ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД




    1. Модель "сущность-связь"


Модель "сущность-связь" базируется на важной семантической информации про реальный мир и предназначена для логического представления данных. Она определяете значение данных в контексте их взаимосвязи с другими данными. Важным является то, что с модели "сущность-связь" могут быть порожденные все существующие модели данных (иерархическая, реляционная, объектная), поэтому она является наиболее общей.

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

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

Возможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый - логический уровень (точка зрения пользователя) означает прямое отображение фактов из реальной жизни. На физическом уровне модели рассматривается использование конкретной СУБД, определяются типы данных (например, целое или вещественное число), индексы для таблиц.

ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Термин "логический уровень" ERwin соответствует концептуальной модели.

ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERStudio автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).



Рис.3.1. Логическая модель



Рис. 3.2. Физическая модель


    1. Классификация связей


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

Существует несколько типов связей между двумя сущностями: это связи "один к одному", "один ко многим" и "многие ко многим".

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями.
^ 4.РЕЛЯЦИОННАЯ МОДЕЛЬ БД
4.1 Функциональные зависимости между атрибутами
База данных состоит из 6 таблиц, 5 из которых являются справочниками и 1 оперативной. В таблице «University» содержится информация об университетах. Таблица «Spetialization» содержит перечень возможных специализаций врачей. Так как эти две таблицы являются источника для таблицы «Doctors», но сами не содержат данные других, то они заполняются первыми.

Таблица «Doctors» содержит информацию о фамилии, имени и отчестве врача, дате его рождения, номере кабинета, номере рабочего телефона, данные о университете, специализацию, стаж работы.

Таблица «Exempt» включает информацию о возможных льготах пациентов, а именно наименование льготы и сумму льготы. Таблица «Pacient» - ФИО пациента, номер его карточки, адрес, район, где проживает пациент, номер страхового полиса, год рождения, являентся ли пациент работником предприятия, если да, то какого отдела. Все эти данные необходимы для эффективной работы регистратуры поликлиники. Так как эти таблицы являются источником для таблицы «Treaty», они заполняются первыми.

Таблица «Treaty» имеет связь c таблицами «Doctors» и «Pacient» и содержит следующую информацию: идентификационный номер записи на прием, дату приема, время приема, стоимость приема, льготу, сумму к оплате, номер врача, номер пациента, сумму к оплате и примечания, где можно указать результат приема.
4.2 Выбор ключей
Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующие экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии.

Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа).

Данные о врачах (идентификационный номер*, фамилия, имя, отчество, номер кабинета, образование, специализация, стаж работы, номер рабочего телефона, год рождения, фотография);

Данные о пациентах (ФИО, номер карточки*, адрес, район города, где проживает, номер страхового полиса, год рождения, работник предприятия, отдел, в котором работает, льгота );

Данные о приемах (идент. номер записи на прием*, дата приема, время приема, стоимость приема, врач, пациент, к оплате, примечания (результаты приема));

Специализации (идентификатор специализации*, специализация);

Образование (идентификатор вуза*, вуз, адрес вуза);

Льгота (идентификатор льготы*, название льготы, сумма льготы);
4.3 Нормализация отношений
Нормализация - процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных.

Нормализация позволяет:

- быть уверенным, что каждый атрибут определен для своей сущности;

- значительно сократить объем памяти для хранения информации

- устранить аномалии в организации хранения данных.

Нормализация отношений – это пошаговый обратимый процесс декомпозиции исходных отношений БД на другие, более мелкие и простые отношения. При этом устанавливаются все возможные функциональные зависимости.

Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам - формализованным требованиям к организации данных.

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

^ 5.ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД
5.1 Состав таблиц БД

Таблица 5.1 «University»

Наименование атри­бутов

Тип полей

Размер полей

Допустимость неопределенных значений

UniversityID

NUMBER

2

NOT NULL

Univ_name

VARCHAR

20

NOT NULL


Таблица 5.2 «Spesialization»

Наименование атри­бутов

Тип полей

Размер полей

Допустимость неопределенных значений

SpesializationID

NUMBER

2

NOT NULL

Spes_name

VARCHAR

20

NOT NULL


Таблица 5.3 «Doctors»

Наименование атри­бутов

Тип полей

Размер полей

Допустимость неопределенных значений

DoctorID

NUMBER

2

NOT NUL

Doc_ LastName

VARCHAR

20

NOT NUL

Doc_ FirstName

VARCHAR

20

NOT NUL

Doc_ Patronymic

VARCHAR

20

NOT NUL

Doc_ Room

NUMBER

3

NOT NUL

Doc_ Experience

NUMBER

2




Doc_ Phone

VARCHAR

10




Doc_ Born

NUMBER

4




UniversityID

NUMBER

2




SpesializationID

NUMBER

2





Таблица 5.4 «Exempt»

Наименование атри­бутов

Тип полей

Размер полей

Допустимость неопределенных значений

ExemptID

NUMBER

2

NOT NULL

ExemptType

VARCHAR

60

NOT NULL

Exempt

NUMBER

15

NOT NULL


Таблица 5.5 «Pacient»

Наименование атри­бутов

Тип полей

Размер полей

Допустимость неопределенных значений

Pac_Number

NUMBER

2

NOT NULL

Pac_ Fio

VARCHAR

60

NOT NULL

Pac_ Address

VARCHAR

80




Pac_ District

VARCHAR

20




Pac_ PolicyNumber

VARCHAR

20

NOT NULL

Pac_ Year

NUMBER

4

NOT NULL

Pac_ Sign

BOOL

1




Pac_ Department

VARCHAR

20




ExemptID

NUMBER

2




Таблица 5.6 «Treaty»

Наименование атри­бутов

Тип полей

Размер полей

Допустимость неопределенных значений

TreatyID

NUMBER

2

NOT NULL

Tr_ DateStart

DATE




NOT NULL

Tr_ TimeStart

VARCHAR

10

NOT NULL

Tr_ Cost

NUMBER

15

NOT NULL

Tr_ Comment

MEMO

15




Tr_ Summa

NUMBER

15

NOT NULL

Tr_ Exempt

VARCHAR

15




Pac_Number

NUMBER

2

NOT NULL

DoctorID

NUMBER

2

NOT NULL
  1   2   3

Добавить документ в свой блог или на сайт

Похожие:

«Розробка бази даних діяльності реєстратури поліклініки» iconРозробка бази даних засобами скбд access
Навчальні та виховні цілі: Ознайомити студентів з особливостями розробки бази даних засобами скбд access

«Розробка бази даних діяльності реєстратури поліклініки» iconПроекту
Спеціальна частина: «Розробка програмного забезпечення для організації бази даних І реалізації алгоритмів прийняття рішень»

«Розробка бази даних діяльності реєстратури поліклініки» iconЗаява про реєстрацію бази персональних даних Прошу зареєструвати...
Прошу зареєструвати базу персональних даних у Державному реєстрі баз персональних даних

«Розробка бази даних діяльності реєстратури поліклініки» iconНаказ
З метою створення умов для забезпечення захисту персональних даних працівників підприємства від незаконної обробки, а також від незаконного...

«Розробка бази даних діяльності реєстратури поліклініки» iconПро затвердження Порядку митного оформлення товарів, що переміщуються...
З метою подальшого впорядкування діяльності митних ліцензійних складів та у зв'язку зі змінами, які відбулися в митному регулюванні...

«Розробка бази даних діяльності реєстратури поліклініки» iconФізичні особи підприємці, які обрали ІІ групу на спрощеній системі...
Фізичні особи підприємці, які обрали ІІ групу на спрощеній системі оподаткування можуть здійснювати такі види діяльності

«Розробка бази даних діяльності реєстратури поліклініки» iconІндивідуального завдання
Розробка презентації з мов програмування. Мови штучного інтелекту: історія, сучасний стан, перспективи

«Розробка бази даних діяльності реєстратури поліклініки» iconФізичні особи підприємці, які обрали ІІІ групу на спрощеній системі...
Фізичні особи підприємці, які обрали ІІІ групу на спрощеній системі оподаткування можуть здійснювати такі види діяльності

«Розробка бази даних діяльності реєстратури поліклініки» iconНаказ Міністерства охорони навколишнього природного середовища та...
На виконання доручення Кабінету Міністрів України від 27. 07. 99 N інд. 33, 16927/16 з метою вдосконалення діяльності служби екологічного...

«Розробка бази даних діяльності реєстратури поліклініки» iconПро затвердження Ліцензійних умов провадження посередницької діяльності митного перевізника
Відповідно до статті 9 Закону України "Про ліцензування певних видів господарської діяльності" (зі змінами й доповненнями) І постанови...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
www.vbibl.ru
Главная страница