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

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

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

Диаграмма

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

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

СУБД

База данных реализована в сетевой СУБД IMAGE/1000 фирмы Hewlett-Packard. Устройство ее следующее. Общие сведения о базе данных хранятся в корневом файле. Наборы-владельцы (ключевые наборы), как и наборы-члены (детальные наборы) реализованы в виде отдельных файлов, структура которых различна.

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

Диаграмма фрагмента БД «Санатории»

Детальные наборы представлены файлами произвольной длины. Их структура – совокупность линейных однонаправленных списков, каждый из которых соответствует одной записи-владельцу. Владелец ссылается на голову списка, остальные записи-члены выбираются по ссылочной цепочке. Каждая запись детального файла может участвовать в наборах, принадлежащих различным типам владельцев. Например, запись описания санатория может относиться к владельцу типа «Номер санатория» и к владельцу типа «Группа санаториев», но разным номерам санаториев не может соответствовать одна и та же запись описания.