Автор: Пользователь скрыл имя, 05 Декабря 2012 в 20:33, курсовая работа
Любая организация нуждается в своевременном доступе к информации. Ценность информации в современном мире очень высока. Роль распорядителей информации в современном мире чаще всего выполняют базы данных. Базы данных обеспечивают надежное хранение информации, структурированном виде и своевременный доступ к ней. Практически любая современная организация нуждается в базе данных, удовлетворяющей те или иные потребности по хранению, управлению и администрированию данных.
Введение…………………………………………….….………………………….....6
1.Анализ предметной области……………………..…………………………..7
2. Описание документооборота в предметной области ………….………….9
3. Информационные потребности пользователей …………………………..11
4. Описание основных объектов ПО………………………………………....12
5. Разработка инфологической модели данных……………………………..14
6. Нормализация БД…………………………………………………………...15
7. Выбор и обоснование СУБД……………………………………………….18
8. Разработка даталогической модели базы данных………………………...21
9. Анализ ограничений целостности в БД и разработка методов их поддержания …………………………………................................................…......24
10. Разработка интерфейса пользователя. Алгоритм работы программного комплекса и его состав …………………………………………………………….28
Заключение…………………………………….……………..……..………………31
Список использованной литературы……………………………………...…
Таблица 2. Список атрибутов объекта «Медсанчасть»
№п.п. |
Наименование атрибута |
Краткое описание |
1. |
ID МСЧ |
Идентификационный номер |
2. |
Наименование МСЧ |
Название МСЧ |
3. |
Адрес МСЧ |
Место расположения МСЧ |
4. |
Контактный телефон |
Контактный телефон |
5. |
Начальник МСЧ |
ФИО начальника МСЧ |
Таблица 3. Список атрибутов объекта «ПАциент»
№ п/п |
Наименование атрибута |
Краткое описание |
1 |
ФИО пациента |
Свойства, определяющие личность человека |
2 |
Адрес пациента |
Место, по которому проживает пациент |
3 |
№ страхового полиса |
№ документа, удостоверяющего право застрахованного лица на бесплатное оказание медицинской помощи |
4 |
Заболевание |
Расстройство здоровья, нарушение деятельности организма. |
5 |
Симптомы |
Частное проявление какого-либо заболевания |
6 |
Дата заболевания |
Число устанавливающее, когда пациент заболел |
7 |
ФИО врача |
Свойства, определяющие личность человека |
8 |
Специализация врача |
Углублённое изучение относительно узкого поля деятельности врача |
9 |
№ кабинета |
№ кабинета, в котором проходил прием |
10 |
ID МСЧ |
Идентификационный номер |
На основе анализа информационных потребностей выявим связи между объектами. Для выявления связей данные представим в Таблице 4.
Таблица 4.Список связей предметной области
№ п.п. |
Наименование |
Объекты, участвующие в связи |
Краткое описание |
1. |
1 ко многим |
Медсанчасть, пациент |
У одной медсанчасти может быть много пациентов |
5. Разработка инфологической модели данных
Рис.1 Инфологическая модель данных
6. Нормализация БД
Составленные сущности необходимо проверить на оптимальность выбора атрибутов. Наличие повторяющихся данных приведет к неоправданному увеличению размера файла базы данных. Кроме нерационального использования дискового пространства, это также вызовет заметное замедление работы приложения.
Первая нормальная форма
Рис.2 Первая нормальная форма
Покажем зависимости для первой нормальной формы.
Сущность «Пациент» имеет следующие атрибуты: ФИО пациента, адрес пациента, № страхового полиса, симптомы, дата заболевания, симптомы, заболевание, ФИО врача, специализация врача, № кабинета, ID МСЧ.
ФИО пациента, Дата заболевания, ФИО врача в данной ситуации являются ключевыми полями.
- функциональные зависимости:
ФИО пациента, Дата заболевания, ФИО врача à Адрес пациента;
ФИО пациента, Дата заболевания, ФИО врача à № страхового полиса.
- частичные функциональные зависимости:
ФИО пациента, Дата заболевания à Симптомы;
ФИО пациента, Дата заболевания à Заболевание;
ФИО пациента, ФИО врача à Специализация врача;
ФИО пациента, ФИО врача à № кабинета.
ID МСЧ - внешний ключ и служит для связи сущностей Медсанчасть – Пациент.
Сущность «Медсанчасть» имеет следующие атрибуты :ID МСЧ, наименование МСЧ, контактный телефон, начальник МСЧ, адрес МСЧ.
ID МСЧ является ключевым полем.
ID МСЧ à Наименование МСЧ;
ID МСЧ à Контактный тлф;
ID МСЧ à Начальник МСЧ;
ID МСЧ à Адрес МСЧ.
Для перехода ко второй нормальной форме рассмотрим объект Пациент , для этого нужно поместить в отдельную таблицу данные, которые только частично зависят от первичного ключа.
Вторая нормальная форма
Рис.3 Вторая нормальная форма
Теперь каждый из этих отношений находятся во второй нормальной форме. Для приведения к третьей нормальной форме нужно, чтобы отсутствовали зависимости атрибутов от других атрибутов, не являющихся ключевыми.
В нашем случае отсутствуют зависимости атрибутов от других атрибутов не являющихся ключевыми, значит отношения уже находятся в третьей нормальной форме.
7. Выбор и
обоснование СУБД для
В наш век информационных технологий программное обеспечение для создания и управления базами данных стало одним из базовых элементов IT-инфраструктуры. Действительно, базы данных сейчас используются практически повсеместно например информационные порталы (архивы музыки и фильмов).
Для создания баз данных и работы с ними используют различные СУБД. Базы данных различаются по своей структуре: дореляционные (на инвертированных списках, иерархические системы и сетевые СУБД), реляционные и постреляционные (например, объектные).
Локальные СУБД
Локальными или настольными называют СУБД такие как Access, Paradox. В них уже есть свой формат данных, который учитывает параллельное выполнение операций, возможность доступа к БД нескольких пользователей.
Недостатки становятся очевидными не сразу, а по мере увеличения количества данных и числа пользователей. К недостаткам можно отнести: снижение производительности и сбои, неэффективное расходование сетевого трафика и низкая эффективность при большом количестве пользователей. Существует решение этой проблемы при помощи распространенной технологии "клиент-сервер"[1].
Технология «клиент-сервер».
Принцип централизации хранения и обработки данных лежит в основе архитектуры "клиент-сервер". При использовании этой технологии вся работа по обработке данных полностью перекладывается на сервер. Машина-клиент посылает запросы, а сервер их выполняет и посылает ответы клиенту. При таком подходе разгружается сеть и пропадает необходимость использовать мощные рабочие станции.
Серверные СУБД обладают расширенными возможностями управления привилегиями пользователей. Кроме того, современные серверные СУБД предоставляют много возможностей резервного копирования и оптимизации запросов. Поддерживают параллельную обработку запросов, а также предоставляют возможность параллельной обработки данных сразу несколькими процессорами (при использовании в качестве сервера БД многопроцессорной системы).
Рынок корпоративных серверных СУБД представлен Oracle, MS SQL, Sybase и InterBase
MS SQL
Первая версия была разработана совместно с Sybase в 1988 году и предназначалась только для платформы OS/2. Следующие версии этого продукты были созданы для NT-based систем и тесно интегрированы с ОС.
Oracle
Oracle была первой коммерческой реляционной СУБД, поддерживающей язык SQL, который в последствии стал стандартом. Первая версия продукта появилась на свет в 1979 году. В наши дни компания является лидером рынка производителей коммерческих СУБД и, как написано на официальном сайте, крупнейшим в мире поставщиком корпоративного программного обеспечения.
InterBase
Продукт компании Borland Inc. Довольно компактная, устойчивая и производительная СУБД, способная работать на различных ОС. Положительная сторона системы достаточно проста при разработке БД. Так как в другие пакеты этой фирмы (например, Delphi) встроены весьма удобные средства для разработки приложений на базе Interbase. Продукт стал известным вследствие того, что долгое время распространялся бесплатно вместе со средствами разработки. В настоящее время продукт платный.
Sybase
Изначально компания разрабатывала серверную СУБД совместно с Microsoft. В 1994 году компании разошлись и стали разрабатывать свои программные продукты независимо друг от друга. В результате у Sybase получился продукт под названием Adaptive Server Enterprise. Продукт существует под разные операционные системы и предназначен для применения на крупных предприятиях. Существует еще одна линия серверных продуктов Sybase, которая ведет свое начало от СУБД Watcom SQL Anywhere. Этот продукт называется SQL Anywhere Studio, отличается своей компактностью и простотой администрирования. Предназначен в основном для обслуживания небольших групп пользователей. Также существуют версии для применения в мобильных устройствах.
Бесплатные СУБД
Бесплатных СУБД тоже существует немало, наиболее распространенными являются MySQL и PostgreSQL. Обе СУБД довольно динамично развиваются и повсеместно используются. Обе системы очень стабильны, гибки и производительны. У каждой есть свои плюсы и минусы.
MySQL – быстрая, но немного ограниченная СУБД. Хорошо подходит для проектов, не требующих сложных баз (например, для web-проектов).
PostgreSQL – мощная и тяжелая система, отвечающая всем современным стандартам СУБД. Больше подходит для серьезных проектов, требующих сложных баз данных. По скорости работы PostgreSQL уступает MySQL. PostgreSQL - это реляционно-объектная СУБД, в которой есть некоторые расширения для работы с таблицами, на которые можно легко отображать иерархии объектов.
Для реализации информационной системы в данном курсовом проекте будет использована СУБД Microsoft Access, так как выбранный программный продукт сможет полностью удовлетворять как текущие, так и будущие потребности пользователей.
К тому же СУБД Microsoft Access рассчитана для хранения не очень больших объемов информации. Нецелесообразно, к примеру, использовать такую СУБД как Oracle для выполнения данного проекта, так как она рассчитана на крупные предприятия с большим количеством пользователей и крупными объемами информации.
8. Разработка даталогической модели базы данных
Для каждого объекта предметной области приведем схему отношений с указанием всех ее атрибутов и их характеристик, описание первичного и внешнего ключей. Данные занесем в Таблицы.
Таблица 5. Медсанчасть
Имя поля |
Тип данных |
Первичный ключ |
Внешний ключ |
ID МСЧ |
Числовой(длинное целое) |
Является первичным ключом |
|
Наименование МСЧ |
Текстовый(50) |
||
Контактный телефон |
Числовой(длинное целое) |
||
Адрес МСЧ |
Текстовый(50) |
||
Начальник МСЧ |
Текстовый(50) |
Таблица 6. Пациент
Имя поля |
Тип данных |
Первичный ключ |
Внешний ключ |
ФИО пациента |
Текстовый(50) |
Является первичным ключом |
|
Адрес пациента |
Текстовый(50) |
||
Дата рождения пациента |
Дата/время |
||
№ страхового полиса |
Числовой(длинное целое) |
||
Дата заболевания |
Дата/время |
Является первичным ключом |
|
ФИО врача |
Текстовый(50) |
Является первичным ключом |
|
ID кабинета |
Числовой(длинное целое) |
||
ID МСЧ |
Числовой(длинное целое) |
Является внешним ключом | |
ID специализации врача |
Числовой(длинное целое) |
||
ID заболевания |
Числовой(длинное целое) |
||
ID симптома |
Числовой(длинное целое) |
Таблица 7. Специализация врача
Имя поля |
Тип данных |
Первичный ключ |
Внешний ключ |
ID специализации |
Числовой(длинное целое) |
Является первичным ключом |
|
Спецмализация врача |
Текстовый(50) |
Таблица 8. Симптомы
Имя поля |
Тип данных |
Первичный ключ |
Внешний ключ |
ID симптома |
Числовой(длинное целое) |
Является первичным ключом |
|
Симптом |
Текстовый(50) |
Таблица 9. Кабинеты