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

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

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

Технологическая часть

1.1 История развития программных средств разработки

баз данных

На ранних стадиях разработки информационно-поисковых систем

разрабатывались специальные языки манипулирования данными

(ЯМД) — языки запросов. Они были ориентированы на

операции с данными, представленными в виде иерархически связанных

файлов, и имели соответствующие алгоритмы поиска информации.

Появление реляционных баз данных создало предпосылки для

других, более быстрых алгоритмов поиска информации.

Для обработки информации, структурированной в виде таблиц

— двумерных массивов, в конце 70-х гг. XX в. фирмой IBM

был разработан соответствующий язык, который в дальнейшем

получил название Structured Query Language (SQL) — язык структурированных

запросов. В настоящее время SQL является международным

стандартом языка обработки данных в реляционных

СУБД. Язык SQL является ядром всех программных продуктов для

разработки СУБД.

Набольшее распространение среди пользователей и разработчиков

СУБД получили следующие программные продукты:

• специальные языки программирования — Visual FoxPro, SQL,

MS SQL-Server;

• прикладные программные системы — Microsoft Access, Oracle

и др.

1.2 Виды Баз Данных.

1.2.1 Иерархические БД.

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

Основываясь на данной аналогии, родительские записи занимают верх пирамиды и имеют название корневые записи. Записи потомки всегда имеют только одного родителя, который с ними связан, точно так же, как и в нормальном семейном дереве. А родительские записи, напротив, могут иметь более одной дочерней записи. Иерархическая БД работает сверху вниз. Поиск записи начинается с верха пирамиды и проходит через все дерево, пока не будет найдена соответствующая запись. Так же стоит заметить, что каждая дочерняя запись может является родителем для других более младших записей.

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

Сетевая БД

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

Как и в иерархической БД, сетевая база данных в основном используется на главных ПК, т.е. серверах. С тех пор, как стало возможным установление связей между различными типами данных, сетевые БД считаются более гибкими. Однако стоит учесть два ограничения при использовании данной базы данных. Так же, как и иерархические, сетевые БД должны определяться в ходе работы. И здесь так же имеется ограничение на количество связей между записями.

1.2.2 Реляционные Базы Данных

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

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

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

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

- для переопределения записей не нужно изменять структуру

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

1.2.3 Объектно-ориентированные базы данных

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

Объектно-ориентированные БД используют маленькие, повторно используемые куски программы, которые называются объектами. Каждый объект состоит из двух частей: 1) это данные (например, видео, аудио, фото или текст) и 2) инструкции, или в программировании – методы, которые дают понять, что можно сделать с данными.

Объектно-ориентированные базы данных имеют два недостатка:

- они более дорогостоящие в разработке

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

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

1.3 Термины и определения

Рассмотрим термины, применяемые в системах управления базами данных.

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

Система управления базами данных — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

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

Архитектура БД — организация взаимодействия аппаратных средств.

Архитектура ODBC (Open DataBase Connectivity) — откры­тый интерфейс доступа к базам данных, т.е. взаимодействие про­цессора (ядра) базы данных Jet с внешними источниками дан­ных.

Модели данных — схемы, характеризующие базы данных с раз­ных сторон с целью определить оптимальное построение инфор­мационной системы.

Ядро базы данных — внутренняя структура СУБД, обеспечива­ющая доступ ко всем компонентам базы данных.

Пользователь БД — программа или человек, обращающийся к базе данных.

Запрос — процесс обращения пользователя к БД с целью вве­сти, получить или изменить информацию.

Транзакция — последовательность операций модификации дан­ных в БД, переводящая ее из одного непротиворечивого состоя­ния в другое непротиворечивое состояние.

Логическая структура БД — определение БД на физически не­зависимом уровне, что ближе всего соответствует концептуаль­ной ее модели.

Топология БД или структура распределенной БД — схема рас­пределения физической организации базы данных в сети.

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

В соответствии с определением К. Дж. Дейта, таблица является прямым и верным представлением некоторого отношения, если она удовлетворяет следующим пяти условиям:

Нет упорядочивания строк сверху-вниз (другими словами, порядок строк не несет в себе никакой информации).

Нет упорядочивания столбцов слева-направо (другими словами, порядок столбцов не несет в себе никакой информации).

Нет повторяющихся строк.

Каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена (и больше ничего).

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

Сущность — это то, о чем необходимо записывать информацию. Отсюда следует, что сущности (а значит, и связи) имеют некоторые свойства (properties), соответствую- щие тем данным о них, которые мы желаем записать, эти свойства должны сохранять- ся в базе данных. В общем случае свойства могут быть как простыми, так и слож- ными, причем настолько, насколько это потребуется. Домен представляет собой множество всех возможных значений определенного атрибута отношения. В процедурных языках программирования каждое переменное должно иметь тип, т. е. принадлежать некоторому типу данных, в реляционных БД каждый элемент данных должен принадлежать некоторому домену. Понятие домена, на практике, иногда отождествляют с типом данных (даже один из идеологов РБД Кристофер Дейт практически стирает различие между доменом и типом данных). Домен определяется путем задания базового типа данных, к которому относятся элементы домена и произвольного логического выражения, применяемого к элементу этого типа данных (ограничения домена). Элемент данных является элементом домена в том и только в том случае, если вычисление этого логического выражения дает резуль- тат истина. С каждым доменом связывается имя, уникальное среди имен всех доменов соответствующей базы данных. Отношение СТУДЕНТ включает 4 домена. Домен 1 содержит номера всех личных дел студентов, домен 2 – фамилии и имена студентов, домен 3 - названия (код) группы, до- мен 4 –название специальности. Каждый домен образует значения одного типа данных, например, числовые или символьные.

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

Кортежем называется последовательность упорядоченных триплетов вида, по одному такому триплету для каждого атрибута. Третий элемент – v – триплета должен являться допустимым значением типа данных или домена T. В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако в реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сор- тирует кортежи по возрастанию или убыванию. Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода. Иногда в литературе встречается определение кортежа, как множества элементов, но с математической точки зрения это не верно, множества в математике не упорядочены, а кортеж это всегда упорядоченный набор элементов.

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

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

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

1.4 Основные этапы проектирования баз данных

Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.

1.4.1 Концептуальное (инфологическое) проектирование

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

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

Чаще всего концептуальная модель базы данных включает в себя:

· описание информационных объектов или понятий предметной области и связей между ними.

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

1.4.2 Логическое проектирование

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

1.4.3 Физическое проектирование

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

1.5 СУБД Microsoft Access.

Microsoft ACCESS. Это одна из самых популярных прикладных

программных систем для разработки баз данных.

Microsoft ACCESS — это программная среда, разработанная

фирмой Microsoft. Она предназначена для создания систем управления

реляционными базами данных с достаточно большими объемами

информации (сотни мегабайт). Microsoft ACCESS предоставляет

пользователю все необходимые средства для автоматизации

создания и обработки данных, а также для управления

данными при работе.

Основным достоинством данной системы является ее ориентация

не на программиста, а на конечного пользователя.

Последние версии Microsoft Access позволяют применять ее для

создания многопользовательских баз данных. В этом случае таблицы

баз данных могут быть переданы на сервер, а пользовательский

интерфейс сохранен на компьютере клиента. В этом случае

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

СУБД с применением Microsoft Access, а задачи управления

многопользовательскими базами данных возложить на MS

SQL-Server.

Другим достоинством Microsoft Access является ее неоспоримое

преимущество перед всеми другими программными продуктами

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

Oracle. Эта система предназначена для разработки корпоративных

реляционных баз данных, объемы информации в которых превышают

терабайты. Основу системы составляет также язык SQL.

Oracle отличается возможностью высокой степени защиты данных.

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

Microsoft Access предоставляет вам максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Вы можете задать также форматы хранения (длина строки, точность представления чисел и даты времени) и предоставления этих данных при выводе на экран или печать. Для уверенности, что в базе данных хранятся только корректные значения, можно задать условия на значения различной степени сложности.

Так как Microsoft Access является современным приложением Windows, то можно использовать все возможности DDE (Dynamic Data Exchange, динамический обмен данными) и ОLЕ (Оbject. Linking and Embedding, связь и внедрение объектов). DDE позволяет осуществлять обмен данными между Access и любым другим поддерживающим DDE приложениями. В Access вы можете при помощи макросов или Access Basic осуществлять динамический обмен данными с другими приложениями. OLE является более изощренным средством Windows, которое позволяет установить связь с объектами другого приложения или внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть картинки, диаграммы, электронные таблицы или документы из других поддерживающих ОLЕ приложений Windows.

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

Учитывая возможности и доступность Microsoft Access, создание базы данных «Медицинская карта» будет осуществляться в этой среде

.