Разработка БД

Этапы проектирования БД

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

1-й этап - концептуальный, который заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Результатом этапа является построение семантической модели предметной области. Модель создается без привязки к какой-либо СУБД или модели данных (средство абстракции, обращаем внимание на общую структуру, а не на конкретные значения). Характеризуется разнообразием используемых моделей (модель “сущность - связь” (ER-модель или модель Чена), бинарные и инфологические модели, семантические сети).

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

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

Иерархическая модель является разновидностью сетевой, являющейся совокупностью деревьев (лесом) (может быть только один предок).

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

3-й этап - физический (внутренний), связан с созданием схемы БД для конкретной СУБД.

Этап концептуального проектирования

Этап концептуального проектирования является специфическим, так как здесь требуется одновременно знание особенностей предметной области и методологии проектирования. Характерным является использование различных моделей (модель “сущность - связь”, бинарные модели данных, семантически сети, инфологические модели данных и др.). Отрицательным моментом является неадекватность получаемых результатов как при использовании различных моделей, так и в рамках коллектива исполнителей.

Одной из распространенных моделей является модель “сущность - связь” (entity - relationship), в литературе наряду с этим используется термин “ER - модель” или “модель Чена”. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов, которые называются ER-диаграммами. Основными понятиями ER – модели являются сущность, связь и атрибут сущности.

Атрибут сущности – это свойство сущности, существенное для решения задачи. Атрибуты сущности перечисляются внутри нее (нотация Чена и Баркера) или под прямоугольником, изображающим сущность (нотация Хау). Иногда на диаграммах изображают не все атрибуты сущности, а только ее идентификатор.

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

Этап логического проектирования

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

Домен - множество значений (например, множество целых чисел). Декартовым произведением доменов D₁, D₂,...,D_k (обозначается как D₁*D₂*...*D_k) называется множество всех кортежей (V₁, V₂,...,V_k) длины k, таких, что V₁ принадлежит D₁, V₂ принадлежит D₂ и т.д.

Например, если k=2, D₁={0,1} и D₂={a,b,c}, то D₁*D₂ есть{(0,a), (0,b), (0,c), (1,a), (1,b),(1,c)}. Отношением называется некоторое подмножество декартова произведения одного или более доменов. Например, {(0,a), (0,c), (1,b)} есть отношение, подмножество определенного выше D₁*D₂.

Элементы отношения называются кортежами. О каждом отношении, являющемся подмножеством декартова произведения D₁*D₂*...*D_k, говорят, что оно имеет арность k. Кортеж (V₁,V₂,...,V_k) имеет k компонентов, причем i-м компонентом является Vi. Отношение удобно представлять таблицей, где каждая строка есть кортеж и каждый столбец соответствует одному компоненту. Столбцы называются атрибутами, и им часто присваиваются имена. Список имен атрибутов отношения называется схемой отношения.

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

Логическая структура БД.

Рис. 3 – Поддержка оглавления с документами

На рис.3 мы видим две таблицы, относящиеся к первому блоку задачи (поддержка нормативно-справочных документов). Таблица Contents отвечает за содержание документов. С ней связана таблица Document (причем связь 1 – 1, так как у каждого пункта в оглавлении может быть один только один документ).

Рис. 4 – Поддержка меню водолазов

На рис. 4 показаны таблицы для недельной меню раскладки питания водолазов. Таблица Menu отвечает за текущую дату. Таблица Day отвечает за питание на завтрак, обед, ужин и вечерний чай. А таблица Foodstuffs в зависимости от части дня хранит набор продуктов питания с их количеством.

На рис. 5 изображены таблицы для автоматизации ручных расчетов. Каждая таблица отвечает за свой вид расчета, например calc_40_percentage_onm – расчет количества добавляемого кислорода в баллон с азотом при приготовлении 40% кислородно-азотной смеси, calc_ongm – расчет приготовления кислородно-азотной газовой смеси, calc_repl_pc_oxygen_cl - расчет пополнения газовой среды барокамеры кислородом при вентиляции по замкнутому циклу. В силу специфики предметной области связи между данными таблицами отсутствуют.

Рис. 5 – Поддержка автоматизации расчетов

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

Рис. 6 – Контроль выполнения требований к организации режима труда и отдыха водолазов