Инфологическое моделирование - Инфологическая модель базы данных: рабочее место регистратуры поликлиники

2.1

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

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

    1. Системный анализ и словесное описание информационных объектов предметной области. 2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели. 3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных. 4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

Схема. 1. Этапы проектирования БД

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

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

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

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.

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

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

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

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

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

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

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

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

Таблица 1

Таблица VRACH

Название

Тип данных

Размер

Ограничения

Назначение

CODE_VRACH

Integer

Primary Key

Код врача

FAM_VRACH

Char

25

Not NULL

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

IMYA_VRACH

Char

25

Not NULL

Имя врача

OTCH_VRACH

Char

25

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

CODE_DOLGN

Integer

Код специализации

CODE_KABINET

Integer

Код занимаемого кабинета

CODE_TIME

Integer

Код времени приема

Справочник пациентов хранится в таблице STUD, структура и правила поддержки целостности данных которой приводятся в табл. 2.

Таблица 2

Таблица STUD

Название

Тип данных

Размер

Ограничения

Назначение

CODE_STUD

Integer

Primary Key

Код пациента

FAM_STUD

Char

25

Not NULL

Фамилия пациента

IMYA_STUD

Char

25

Имя пациента

OTCH_STUD

Char

25

Отчество пациента

CODE_VRACH

Integer

Not NULL

Код врача

CODE_DATE

Integer

Код даты приема

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

Таблица 3

Таблица DOLGN

Название

Тип данных

Размер

Ограничения

Назначение

CODE_DOLGN

Integer

Primary Key

Код специализации

DOLGN

Char

25

Название специализации

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

Таблица 4

Таблица KABINET

Название

Тип данных

Размер

Ограничения

Назначение

CODE_KABINET

Integer

Primary key

Код кабинета

KABINET

Integer

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

SUMMATOR

Integer

Not NULL

Количество врачей в кабинете

CODE_DOLGN

Integer

Код специализации

POLOJENIE

Char

25

Положение кабинета

( свободен или занят)

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

Таблица 5

Таблица TIME

Название

Тип данных

Размер

Ограничения

Назначение

CODE_TIME

Integer

Primary key

Код времени приема

TIME

Char

25

Время приема

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

Таблица 6

Таблица DATE_PRIEM

Название

Тип данных

Размер

Ограничения

Назначение

CODE_DATE

Integer

Primary Key

Код даты

DATE_PR

Date

Дата приема

CODE_VRACH

Integer

Not NULL

Код врача

SUMMATOR

Integer

Количество пациентов

2.2

Разработку информационного обеспечения АРМ проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP.

СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.

При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.

Данная СУБД была выбрана по следующим причинам:

    § простота средств реализации, § легкость освоения инструментарием разработчика (VBA), § наглядность визуализации информации.

Также "Microsoft Access" предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:

    § загрузка модулей по требованию; § оптимизация дерева вызовов; § использование файлов MDE; § автоматическая поддержка компилированного состояния; § использование библиотек Windows API; § индивидуальная настройка системы; § эффективное использование индексов; § встроенный оптимизатор запросов.

Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:

    - один-к-одному (одной записи в первой таблице соответствует одна запись во второй); - один-ко-многим (одной записи в первой таблице соответствует много записей во второй); - много-к-одному (многим записям в первой таблице соответствует одна запись во второй); - много-ко-многим (одной записи в первой таблице соответствует много запией во второй и одной записи во второй таблице соответствует много записей в первой).

Инфологическая модель применяется после словесного описания предметной области.

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

Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).

Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.

Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

Связь "многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.

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

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

Похожие статьи




Инфологическое моделирование - Инфологическая модель базы данных: рабочее место регистратуры поликлиники

Предыдущая | Следующая