Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Инфологическое проектирование



 

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

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

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

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

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

база поликлиника реляционная выборка

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

 

Таблица 1 - Классификация связей

Родительская таблица Дочерняя таблица

Ключи

Вид связи
1 Пациенты Учёт работы Код пациента Код пациента 1: М
2 Врачи Учёт работы Код врача Код врача 1: М
3 Смены Учёт работы Код смены Код смены 1: М
4 Специализация Учёт работы Код специализации Код специализации 1: M

 

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

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

Реляционная модель БД

 

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

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

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

 

Таблица 2 - Функциональные зависимости между атрибутами сущности "Врачи"

Наименование атрибутов Функциональные зависимости
Код врача Фамилия Имя Отчество Адрес Дата рождения Телефон Специализация Стоимость приёма без НДС Стоимость приёма с учётом НДС  

 

Таблица 3 - Функциональные зависимости между атрибутами сущности "Пациенты"

Наименование атрибутов Функциональные зависимости
Код пациента Фамилия Имя Отчество Адрес Телефон Диагноз  

 


Таблица 4 - Функциональные зависимости между атрибутами сущности "Специализации"

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

 

Таблица 5 - Функциональные зависимости между атрибутами сущности "Смены"

Наименование атрибутов Функциональные зависимости
Код смены Дата смены Время смены Номер смены  

 

Таблица 6 - Функциональные зависимости между атрибутами сущности "Учёт работы"

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

 

Для каждой таблицы должны быть определены свои ключи:

 

Таблица 7 - Ключи

Таблица Ключ
Учёт работы Код врача Код пациента Код смены Код специализации
Врачи Код врача
Пациенты Код пациента
Смены Код смены
Специализации Код специализации



Нормализация отношений

 

Проанализировав таблицу "Врачи", можно сказать, что она находится в первой нормальной форме, так как она имеет первичный ключ, каждое поле таблицы представляет уникальный тип информации, все поля атомарны. Так же данная таблица находится и во 2НФ, так как она удовлетворяет условиям 1НФ,а так же я убедилась в том, что каждое поле функционально зависит от первичного ключа, который идентифицирует исходный объект таблицы. Таблица "Врачи" находится в 3НФ, так как она находится во 2НФ и не содержит транзитивных зависимостей, т. е. столбцы, не являющиеся ключевыми, зависят от первичного ключа таблицы и не зависят от всех остальных столбцов. Имеется возможность изменять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей.

Таблицы "Пациенты", "Учёт работы", "Смены", "Специализация" аналогично таблице "Врачи" находятся во всех трех нормальных формах.

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


Поделиться:



Последнее изменение этой страницы: 2019-06-19; Просмотров: 191; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.022 с.)
Главная | Случайная страница | Обратная связь