Разработка БД “Больницы города”

Сущность «Отделение» содержит атрибут название отделения.

Сущность «Медработник» имеет 3 атрибута: ФИО сотрудника, Оклад, Дата начала работы.

Сущность «Должность»  содержит атрибут название должности.

Сущность «Специализация» содержит атрибут название специализации.

Сущность «Категория»  содержит атрибут название категории.

Рассмотрим более подробно связи между сущностями.

В городе может существовать много больниц одного типа. Одна больница может быть какого-то конкретного  типа. Таким образом, «Тип больницы» и «Больница» имеют связь 1:∞.

В городе может существовать много больниц одного профиля. Одна больница может иметь только 1 профиль. Таким образом, «Профиль больницы»  и «Больница» имеют связь 1:∞.

В больнице может быть много отделений. Отделения с одинаковыми названиями могут существовать во многих больницах города. «Больница» и «Отделение» имеют связь ∞:∞. Эти две сущности связаны отношением «Отделения больниц», которое обладает свойством «Число койко-мест».

В одном отделении больницы работают много медработников. Один медработник работает только в одном отделении больницы. «Отделения больниц» и «Медработник» имеют связь 1:∞.

В больницах может  быть много медработников одной должности. Один работник может занимать только одну должность. Таким образом, «Должность» и «Медработник» имеют связь 1:∞.

В больницах может  быть много медработников с одинаковой специализацией. Один работник может иметь только одну специализацию. Таким образом, «Специализация» и «Медработник» имеют связь 1:∞.

В больницах может быть много медработников, имеющих одинаковую категорию. Один работник может иметь только одну категорию. Таким образом, «Категория» и «Медработник» имеют связь 1:∞.

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

 

Рисунок 3.1 – Схема объект-отношение

 

 

 

3.2 Выбор модели данных

 

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

 

3.2.1 Иерархическая модель  данных

 

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

Так как в иерархической  модели каждому входному сегменту данных соответствует N выходных, то такие  модели весьма удобны для представления  отношений типа 1:N в предметной области. Следует отметить, что в настоящее время не разрабатываются СУБД, поддерживающие на концептуальном уровне только иерархические модели. Как правило, использующие иерархический подход системы допускают связывание древовидных структур между собой и/или установление связей внутри них.

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

К достоинствам иерархической  модели данных относятся эффективное  использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.

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

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

В данной предметной области  необходима реализация связи N:N, эффективное  обеспечение целостности данных, при этом скорость поиска не играет является столь важной. Исходя из этого, иерархическая модель данных не подходит для заданной предметной области.

Построим иерархическую  модель данных для имеющейся предметной области. Иерархическая модель данных приведена на рисунке 3.2.

 

 

Рисунок 3.2 – Иерархическая модель данных

 

 

 

3.2.2 Сетевая модель данных

 

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

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

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

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

Построим сетевую модель данных для данной предметной области. Сетевая модель данных приведена на рисунке 3.3.

 

 

Рисунок 3.3 – Сетевая модель данных

 

 

 

3.2.3 Реляционная модель  данных

 

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

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

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

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

Достоинства реляционной  модели:

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

Недостатки реляционной  модели:

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

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

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

 

 

3.3 Нормализация таблиц

 

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

 

3.3.1 Приведение к нормальным формам

 

Согласно теории нормализации реляционных баз данных, выделяются шесть нормальных форм: первая, вторая, третья, форма Бойса-Кодда, четвертая и пятая нормальная форма.

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

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

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

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

При решении практических задач в большинстве случаев  третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к 3NF.

Представим модель заданной предметной области в виде 1NF. Результат представления показан на рисунке 3.4.

 

№

Адрес

ФИО глав врача

Тип

Профиль

Дата открытия

Отделение

Число койко-мест

ФИО медработника

Должность

Категория

Специализация

Начало работы

Оклад

 

Рисунок 3.4 – Первая нормальная форма

 

В качестве первичного ключа  в полученной таблице выделим объединение полей «№», «Отделение» и «ФИО медработника».

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

Поля «Адрес», «ФИО глав врача», «Тип», «Профиль» и «Дата  открытия» находятся в зависимости  от поля «№».

Поле «Число койко-мест»  находится в зависимости от полей «№» и «Отделение».

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

 

Адрес

ФИО глав врача

Тип

Профиль

Дата открытия

Число койко-мест

Должность

Категория

Специализация

Начало работы

Оклад

№

Отделение

ФИО медработника

 

 

Рисунок 3.5 – Функциональные зависимости в 1NF

 

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

 

№

Адрес

ФИО глав врача

Тип

Профиль

Дата открытия

№

Отделение

Число койко-мест

 

ФИО

Должность

Категория

Специализация

Начало работы

Оклад

 

 

 

 

 

 

 

Рисунок 3.6 – Вторая нормальная форма

 

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