База данных поликлиники

Размещено на http://www.allbest.ru/

Введение

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

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

В настоящее время наиболее широко распространены реляционные СУБД. Несмотряна очевидную привлекательность и растущую популярность объектно-ориентированныхСУБД, пока все же преобладаютреляционные базы данных, являющиеся хорошо отлаженными, развитыми,сопровождаемыми системами, поддерживающими стандарт SQL-92 (к таким системамотносятся, например, Oracle, Informix, Sybase, DB2, MSSQLServer).

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

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

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

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

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

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

1. Теоретическая часть

1.1 Диаграмма прецедентов

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

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

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

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

1.2 Системный анализ предметной области

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

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

a) функциональный подход реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая база данных. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны;

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

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

Системный анализ должен заканчиваться:

- подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД;

- формулировкой конкретных задач, которые будут решаться с использованием данной БД;

- описанием выходных документов, которые должны генерироваться в системе;

- кратким описанием алгоритмов решения задач;

- описанием входных документов, которые служат основанием для заполнения данными БД.

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

1.3 Концептуальная модель предметной области

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

Концептуальный уровень -- центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира. Концептуальный уровень можно представить себе определяющим обобщенное представление пользователей. Это представление ближе к данным «как они есть», чем какими их видят пользователи. Результатом концептуального проектирования базы данных, выполняемого на концептуальном уровне, является концептуальная схема или единое логическое описание всех элементов данных и отношений между ними.

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

Концептуальное проектирование, прежде всего, связано с попыткой представления семантики (смысла) предметной области в модели базы данных. В настоящий момент модельЧена «Сущность - Связь», или «Entity - Relationship», стала стандартом при концептуальном моделировании баз данных. Общепринятым стало ее сокращенное название - ER-модель. Для удобства вместо термина «сущность» будем использовать термин «объект» (объектное множество).

2. Задание

Регистратура больницы ведет учет поступления пациентов (по отделениям и палатам); учёт проведённого лечения; учёт платных услуг с выдачей счетов на оплату; ведение архива выписанных пациентов.

1. Построить диаграмму прецедентов

2. Выполнить системный анализ предметной области, разработать схему перемещения объектов и связей между ними.

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

4. Разработать информационно-логическую (концептуальную) схему для указанной предметной области. Концептуальная модель отображает данные предметной области в виде совокупности информационных объектов (объектных множеств) и связей между ними (с указанием мощностей).

3. Решение

3.1 Диаграмма прецедентов предметной области «Регистратура больницы»

Размещено на http://www.allbest.ru/

3.2 Описание предметной области «Регистратура больницы»

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

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

Каждое отделение может содержать сведения по нескольким областям. Каждое отделение больницы характеризуется следующими параметрами: номер; название; фамилия главного врача; количество мест; количество свободных мест.

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

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

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

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

С данной информационной системой должны работать следующие группы пользователей: регистратор; пациенты; врачи.

При работе с системой регистратор должен иметь возможность решать следующие задачи:

1)Принимать новых пациентов и регистрировать их.

2) Определять количество свободных мест по отделениям и палатам.

3) Записав жалобы, определять лечащего врача.

4)Вносить и изменять данные о врачах

5) Находить данные о пациентах в любой из палат.

6) Вести учет прооперированных пациентов.

7)Вести учет платных услуг выдавать чеки за услуги.

8) Регистрировать день выписки и состояние после проведенного лечения.

Пациент должен иметь возможность решать следующие задачи:

1) Просмотреть данные о лечащем враче.

2) Посмотреть стоимость платных услуг.

Врач должен иметь возможность решать следующие задачи:

1) Посмотреть данные о пациенте в момент поступления в больницу.

2) Занести в базу поставленный диагноз

3) Определить перечень платных услуг

4) Записать пациента в отделение и определить его в палату

3.3 Концептуальная модель предметной области «регистратура больницы»

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

Разработку модели начнем с выделения основных сущностей.

Прежде всего, существует объектное множество «Пациенты». Каждый пациент имеет уникальный номер и ряд атрибутов, которые взяты из описания предметной области.

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

Между сущностями «Палата» и «Пациент» существует связь «один-ко-многим» (1:М), необязательной ни с одной стороны (Н-Н). Чем определяется данный тип связи? Мы можем предположить, что каждая палата может иметь нескольких пациентов. При этом в больнице могут быть палаты, не имеющие ни одного пациента. Это означает, что со стороны палата связь необязательная. Что касается сущности «Пациент», то в больнице могут быть пациенты, не относящиеся ни к одной из палат, поэтому и со стороны «Пациенты» связь тоже необязательная.

Теперь необходимо определить, как в нашей системе будет представлен врач. Естественно предложить ввести для этого объектное множество «Врачи», каждый экземпляр которой будет соответствовать конкретному врачу. В библиотеке каждому врачу присваивается уникальный номер, который будет однозначно идентифицировать любого врача. Номер будет ключевым атрибутом сущности «Врачи». Кроме того, в сущности «Врачи» должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач, этими атрибутами будут: «Фамилия Имя Отчество», «Специализация», «Номер отделения» и «Стаж работы». В описании нашей предметной области существует ограничение на стаж врачей, поэтому в сущности «Врачи» надо ввести обязательный атрибут «Стаж работы», который позволит нам это контролировать.

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

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

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

Концептуальная модель предметной области «Регистратура больницы» представлена на рисунке 1-3.

Размещено на http://www.allbest.ru/

Рис. 1 Информационно-логическая модель на уровне сущности

Заключение

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

Размещено на Allbest.ru