|
|
РЕФЕРАТ. Пояснительная записка содержит 127 страниц, 65 таблиц, 39 рисунков
Проектирование баз данных
На этапе внешнего проектирования были выявлены объекты, которые должны использоваться для представления предметной области. Для каждого вида объектов была зафиксирована совокупность свойств, посредством которых должны описываться объекты этого вида в БД, виды отношений между этими объектами. Следующий шаг – решение вопроса, какая информация должна быть представлена в БД и представление ее с помощью данных. Сущностью инфологического этапа проектирования является установление связей между сущностями и представлением в БД.
На этапе инфологического проектирования используется неформальная модель предметной области типа «сущность-связь». Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Основное назначение неформальной модели «сущность-связь» является семантическое описание предметной области и представление информации для обоснования выбора видов и моделей и структур данных, которые в дальнейшем будут использоваться в системе. Для построения модели типа «сущность-связь» используются три основных конструктивных элемента для представления составляющих предметную область – сущность, атрибут и связь.
Описание инфологической модели
В результате проработки предметной области были выделены сущности (Поликлиника, Отделение, Врач, Пациент, Направление к врачу, Направление на анализ, Анализ, Направление на процедуру, Процедура, Лаборатория, Рецепт, Лекарство, Расписание), их атрибуты, взаимосвязь между ними и построена инфологическая модель базы данных.
Спецификация инфологической модели:
Таблица 1.2.
Поликлиника
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
Название
|
Полное название учреждения
|
Адрес
|
Юридический адрес учреждения
|
Телефон
|
Контактный телефон учреждения
|
Таблица 1.3.
Отделение
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_поликлиники
|
Идентификатор соответствующей записи в таблице «Поликлиника»
|
Название
|
Полное название отделения
|
Таблица 1.6.
Таблица 1.5.
Таблица 1.4.
Врач
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_отделения
|
Идентификатор отделения, в котором работает врач
|
ФИО
|
Фамилия, имя и отчество врача
|
Специализация
|
В какой должности работает врач
|
Дата рождения
|
Дата рождения врача
|
№ кабинета
|
№ кабинета, в котором принимает врач
|
Расписание
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_врача
|
Идентификатор врача
|
День
|
День недели
|
Начало
|
Время начала работы
|
Окончание
|
Время окончания работы
|
Пациент
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ФИО
|
Фамилия, имя и отчество пациента
|
Дата рождения
|
Дата рождения пациента
|
Полис
|
Номер страхового полиса
|
Адрес
|
Адрес места жительства пациента
|
Дата учёта
|
Дата постановки на учёт в поликлинику
|
Таблица 1.7.
Направление к врачу
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_пациента
|
Идентификатор записавшегося пациента
|
ID_врача
|
Идентификатор врача, к которому записался пациент
|
Дата
|
Дата, на которую записался пациент
|
Время
|
Время, на которое записался пациент
|
Прохождение
|
Отметка о прохождении
|
Таблица 1.8.
Анализ
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
Название
|
Название анализа
|
Номер кабинета
|
Номер кабинета, где принимается анализ
|
Часы работы
|
Часы работы данного кабинета
|
Таблица 1.9.
Направление на анализ
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_анализа
|
Идентификатор сдаваемого анализа
|
ID_врача
|
Идентификатор врача, выписавшего направление
|
ID_пациента
|
Идентификатор пациента, сдающего (сдавшего) анализ
|
ID_лаборатории
|
Идентификатор лаборатории, где будет исследоваться анализ
|
Дата
|
Дата сдачи анализа
|
Время
|
Время сдачи анализа
|
Таблица 1.11.
Таблица 1.10.
Лаборатория
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
Название
|
Название лаборатории
|
Адрес
|
Юридический адрес лаборатории
|
Телефон
|
Телефон лаборатории
|
Результат анализа
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_направления
|
Идентификатор направления на анализ
|
Дата
|
Дата исследования
|
Результат
|
Результат исследования
|
Таблица 1.13.
Таблица 1.12.
Процедура
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
Название
|
Название анализа
|
Номер кабинета
|
Номер кабинета, где принимается анализ
|
Часы работы
|
Часы работы данного кабинета
|
Направление на процедуру
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_процедуры
|
Идентификатор проходимой процедуры
|
ID_врача
|
Идентификатор врача, выписавшего направление
|
ID_пациента
|
Идентификатор пациента, проходящего (прошедшего) процедуру
|
Количество
|
Количество процедур, прописанных врачом пациенту
|
Таблица 1.15.
Таблица 1.14.
Процедурный лист
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_направления
|
Идентификатор направления на процедуру
|
Дата
|
Дата прохождения
|
Время
|
Время прохождения
|
Отметка
|
Отметка о прохождении
|
Лекарство
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
Название
|
Название лекарства
|
Лечение
|
Описание данного лекарства, от каких болезней помогает
|
Побочный эффект
|
Описание побочного эффекта лекарства
|
Таблица 1.16.
Рецепт
Описание атрибута
|
Название атрибута
|
ID
|
Уникальный идентификатор записи
|
ID_лекарства
|
Идентификатор лекарства
|
ID_врач
|
Идентификатор врача, выписавшего рецепт
|
ID_пациент
|
Идентификатор пациента, которому был выписан рецепт
|
Дата
|
Дата выписки рецепта
|
Таблица 1.17.
Связи между сущностями
Родительская сущность
|
Дочерняя сущность
|
Описание
|
Тип связи
|
Поликлиника
|
Отделение
|
Поликлиника имеет несколько отделений
|
1:М
|
Отделение
|
Врач
|
В отделении работает несколько врачей
|
1:М
|
Врач
|
Расписание
|
Врач работает по расписанию
|
1:М
|
Врач
|
Направление на анализ
|
Врач выдаёт направления на анализы
|
1:М
|
Врач
|
Направление на процедуру
|
Врач выдаёт направления на процедуры
|
1:М
|
Врач
|
Направление к врачу
|
Врач принимает по направлению к врачу
|
1:М
|
Врач
|
Рецепт
|
Врач выписывает рецепт
|
1:М
|
Пациент
|
Направление на анализ
|
Пациент получает направление на анализ
|
1:М
|
Пациент
|
Направление на процедуру
|
Пациент получает направление на процедуру
|
1:М
|
Пациент
|
Направление к врачу
|
Пациент получает направление к врачу
|
1:М
|
Пациент
|
Рецепт
|
Пациент получает рецепт
|
1:М
|
Анализ
|
Направление на анализ
|
Направление выдаётся на определённый анализ
|
1:М
|
Процедура
|
Направление на процедуру
|
Направление выдаётся на определённую процедуру
|
1:М
|
Лекарство
|
Рецепт
|
Рецепт выписывается на определённое лекарство
|
1:М
|
Лаборатория
|
Направление на анализ
|
Анализ, сданный по определённому направлению, исследуется в лаборатории
|
1:М
|
Лаборатория
|
Результат анализа
|
Результат анализа получается после исследования анализа в лаборатории
|
1:М
|
Результат анализа
|
Направление на анализ
|
Результат анализа соответствует определённому направлению
|
1:1
|
Направление на процедуру
|
Процедурный лист
|
Направлению на процедуру соответствует запись в процедурном листе
|
1:М
|
Выбор СУБД
Для интернет-приложений используются множество различных баз данных: MySQL, PostgreSQL, MS SQL Server и другие. Для анализа воспользуемся некоторыми из них.
Таблица 1.18.
Сравнение аналогов СУБД
Аналоги
Критерии сравнения
|
Весовой коэффициент
|
PostgreSQL
|
MySQL
|
MS SQL Server
|
Скорость работы
|
0,25
|
4
|
4
|
5
|
Настройка
|
0,15
|
4
|
5
|
4
|
Простота БД
|
0,2
|
4
|
5
|
5
|
Поддержка хостинг-провайдерами
|
0,2
|
4
|
5
|
3
|
Максимальный размер БД
|
0,1
|
5
|
5
|
4
|
Платформа
|
0,1
|
Unix
|
Unix, Windows
|
Windows
|
Итого
|
1
|
4,2
|
4,75
|
4,25
|
MySQL является решением для малых и средних приложений, хорошо подходит для среды, где доминирует считывание информации и где транзакционная нагрузка очень мала. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты.
Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.
Помимо Windows (поддерживаются версии от Windows95 до Windows Vista) и Unix ОС MySQL портирована на большое количество платформ, таких как Mac OS X, OpenBSD и др.
В 5 версии поддерживаются вложенные запросы и производные таблицы, триггеры, обработчики ошибок, представления.
Учитывая результаты сравнения с аналогами и поддержку множества ОС, для реализации проекта была выбрана СУБД MySQL.
Разработка даталогической модели
Таблица 1.19.
Таблица «Поликлиника»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
Название
|
Name
|
VarChar
|
20
|
-
|
Адрес
|
Address
|
VarChar
|
50
|
-
|
Телефон
|
Phone
|
VarChar
|
15
|
-
|
Таблица 1.20.
Таблица «Отделение»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_поликлиники
|
ID_hospital
|
int
|
|
Вторичный ключ
|
Название
|
Name
|
VarChar
|
20
|
-
|
Таблица 1.22.
Таблица 1.21.
Таблица «Врач»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_отделения
|
ID_department
|
int
|
-
|
Вторичный ключ
|
ФИО
|
FIO
|
VarChar
|
100
|
-
|
Специализация
|
Specialization
|
VarChar
|
20
|
-
|
Дата рождения
|
Birthdate
|
Date
|
-
|
-
|
№ кабинета
|
Number
|
int
|
2
|
-
|
Таблица «Расписание»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_врача
|
ID_doctor
|
int
|
-
|
Вторичный ключ
|
День
|
Day
|
VarChar
|
11
|
-
|
Начало
|
Begin
|
Time
|
-
|
-
|
Окончание
|
End
|
Time
|
-
|
-
|
Таблица 1.24.
Таблица 1.23.
Таблица «Пациент»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ФИО
|
FIO
|
VarChar
|
100
|
|
Дата рождения
|
Birthdate
|
Date
|
-
|
-
|
Полис
|
Polis
|
VarChar
|
100
|
-
|
Адрес
|
Address
|
VarChar
|
100
|
-
|
Дата учёта
|
BeginDate
|
Date
|
-
|
-
|
Таблица «Направление к врачу»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_пациента
|
ID_patient
|
int
|
-
|
Вторичный ключ
|
ID_врача
|
ID_doctor
|
int
|
-
|
Вторичный ключ
|
Дата
|
Date
|
Date
|
-
|
-
|
Время
|
Time
|
Time
|
-
|
-
|
Прохождение
|
Check
|
VarChar
|
20
|
-
|
Таблица 1.26.
Таблица 1.25.
Таблица «Анализ»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
Название
|
Name
|
VarChar
|
20
|
-
|
Номер кабинета
|
Cabinet
|
int
|
1
|
-
|
Часы работы
|
Time
|
Time
|
-
|
-
|
Таблица «Направление на анализ»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_анализа
|
ID_analiz
|
int
|
-
|
Вторичный ключ
|
ID_врача
|
ID_doctor
|
int
|
-
|
Вторичный ключ
|
ID_пациента
|
ID_patient
|
int
|
-
|
Вторичный ключ
|
ID_лаборатории
|
ID_lab
|
int
|
-
|
Вторичный ключ
|
Дата
|
Date
|
Date
|
-
|
-
|
Время
|
Time
|
Time
|
-
|
-
|
Таблица 1.27.
Таблица «Лаборатория»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
Название
|
Name
|
Varchar
|
20
|
-
|
Адрес
|
Address
|
Varchar
|
50
|
-
|
Телефон
|
Phone
|
Varchar
|
15
|
-
|
Таблица 1.28.
Таблица «Результат анализа»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_направления
|
ID_aiming
|
int
|
-
|
Вторичный ключ
|
Дата
|
Date
|
Date
|
-
|
-
|
Результат
|
Result
|
Varchar
|
100
|
-
|
Таблица 1.29.
Таблица «Процедура»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
Название
|
Name
|
VarChar
|
-
|
-
|
Номер кабинета
|
Number
|
int
|
1
|
-
|
Часы работы
|
Time
|
Time
|
-
|
-
|
Таблица 1.31.
Таблица 1.30.
Таблица «Направление на процедуру»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_процедуры
|
ID_procedure
|
int
|
-
|
-
|
ID_врача
|
ID_doctor
|
int
|
-
|
-
|
ID_пациента
|
ID_patient
|
int
|
-
|
-
|
Количество
|
Count
|
int
|
1
|
-
|
Таблица «Процедурный лист»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_направления
|
ID_procedure
|
int
|
-
|
Вторичный ключ
|
Дата
|
Date
|
Date
|
-
|
-
|
Время
|
Time
|
Time
|
-
|
-
|
Отметка
|
Check
|
Bool
|
-
|
-
|
Таблица 1.32.
Таблица 1.33.
Таблица «Лекарство»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
Название
|
Name
|
VarChar
|
20
|
|
Лечение
|
Treatment
|
VarChar
|
100
|
-
|
Побочный эффект
|
BadEffect
|
VarChar
|
100
|
-
|
Таблица «Рецепт»
Поле
|
Физическое имя
|
Тип
|
Длина
|
Примечание
|
ID
|
ID
|
int
|
-
|
Первичный ключ
|
ID_лекарства
|
ID_treatment
|
VarChar
|
-
|
Вторичный ключ
|
ID_врач
|
ID_doctor
|
VarChar
|
-
|
Вторичный ключ
|
ID_пациент
|
ID_patient
|
VarChar
|
-
|
Вторичный ключ
|
Дата
|
Date
|
Date
|
-
|
-
|
1.1.2.6. Разработка архитектуры АСОИУ 1.2.6.1. Выбор архитектуры 1.2.6.1.1. Архитектура «Файл-сервер».
Здесь функционируют два компонента: это файл-сервер и рабочая станция.
Рисунок 1.12. - Архитектура «Файл-сервер»
Файл-сервер и станция работают на разных компьютерах, которые соединены между собой сетью. Запросы к серверу формируется на уровне доступа к файлам.
Недостатком данной системы является то, что данные обрабатываются на станциях, и хранятся на сервере. Это влечет за собой большую нагрузку на сеть и, следовательно, снижение производительности всей системы. Кроме того, проблемы одновременного доступа к данным, поддержки целостности и согласованности данных решаются копиями приложений на рабочих станциях, т.е. децентрализовано, что чревато конфликтами и трудностями в их решении.
1.2.6.1.2. Архитектура «Клиент-сервер».
Два основных компонента этой архитектуры – это два независимых процесса: клиент и сервер. Сервер работает на том компьютере, где хранятся данные, а клиент - на компьютере пользователя.
Рисунок 1.13. - Архитектура «клиент-сервер»
Клиент формирует пользовательский интерфейс и запросы к серверу на чтение и изменение данных, хранящихся в нем. Можно сказать, что клиент есть приложения, которые выполняются над СУБД. Сервер выполняет эти запросы, обработку данных, отслеживает хранение целостности и согласованности, а также права доступа к данным и возвращает клиенту результаты выполнения ее запроса.
1.2.6.1.3.Трёхуровневая архитектура
Трёхуровневая архитектура — вариант архитектуры клиент - сервер, в котором пользовательский интерфейс, доступ к данным и хранение данных разрабатываются и функционируют как независимые модули, зачастую на различных платформах.
Трёхуровневая архитектура представляет собой:
Терминал - это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры.
Сервер базы данных обеспечивает хранение данных и выносится на третий уровень . Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
Достоинствами трёхуровневой архитектуры являются:
Масштабируемость
конфигурируемость - изолированность уровней друг от друга быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней.
высокая безопасность
высокая надежность
низкие требования к скорости канала (сети) между терминалами и сервером приложений.
низкие требования к производительности и техническим характеристикам терминалов, как следствие, снижение их стоимости. Терминалом может выступать не только компьютер, но и мобильный телефон к примеру.
При разработке интернет-магазинов нужны поддержка транзакций, устойчивость к сбоям и способность справляться с массированной загрузкой. Интернет серверу иногда приходится обрабатывать сотни обращений в секунду. К тому же традиционная клиент-сервер схема чувствительна к потере соединения. Выход - оставить прикладной процесс рядом с сервером данных, чтобы иметь устойчивое соединение с последним и удерживать контекст транзакции.
Учитывая вышеизложенное, в качестве архитектуры для разработки интернет-магазина была выбрана трёхуровневая архитектура.
1.2.6.2. Выбор языка сценариев
Необходимо выбрать язык сценариев для реализации проекта. Язык сценариев (скриптовый язык) - язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере.
Самыми распространёнными языками сценариев являются PHP и Perl, поэтому они и будут сравниваться для нахождения оптимального варианта реализации проекта интернет-магазина.
Таблица 1.34. Сравнительный анализ языков сценария
Аналоги
Критерии сравнения
|
Весовой коэффициент
|
Perl
(Practical Extraction and Report Language)
|
PHP
(Personal Home Pages)
|
Простота и удобство в использовании
|
0,2
|
4
|
5
|
Поддержка хостинг-провайдерами
|
0,2
|
4
|
5
|
Решение административных задача в ОС Windows
|
0,2
|
5
|
4
|
Быстрота
|
0,2
|
4
|
5
|
Для работы с MySQL
|
0,2
|
Модули DBI, Msql-Mysql-modules, Data-Dumper, Data-ShowTable
|
Модуль
php5-mysql
|
Итого
|
1
|
4,2
|
4,8
|
PHP - язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. Входит в LAMP — «стандартный» набор для создания веб-сайтов (Linux, Apache, MySQL, PHP).
Область применения PHP сфокусирована на написании скриптов, работающих на стороне сервера; таким образом, PHP способен выполнять то, что выполняет любая другая программа CGI, например, обрабатывать данные форм, генерировать динамические страницы или отсылать и принимать cookies.
В результате проведённого сравнения было принято решение использовать для реализации проекта язык PHP.
|
|
|
Скачать 7.41 Mb.