Навигация
Логическая модель базы данных
21060
знаков
0
таблиц
27
изображений
3.2 Логическая модель базы данных
Логическая модель представлена на рисунке 3.2.
Рисунок 3.2 – Логическая модель базы данных
В базе данных имеется 9 таблиц. Первая самая главная таблица "Отделения", которая является главной для таблиц "Персонал", "Пациенты" и "Диагнозы", с которыми она связана по полю "Код отделения" и имеет место связь "1-ко многим". В свою очередь таблица "Персонал" является главной для таблицы "Процедуры", которая связана по полю "Код медсестры", связь также "1-ко многим".
Две таблицы "Диагноз-Лекарства" и "Диагноз-Процедуры" имеют составные ключи и связаны с двумя таблицами, по коду диагноза с таблицей "Диагнозы" и по коду лекарства и процедуры с таблицами "Лекарства" и "Процедуры" соответственно. Получилась связь "многие – ко многим". Такая связь нужна, для того чтобы можно было для одного диагноза выбрать много процедур и лекарств. Соответственно, для процедур и лекарств могут соответствовать много диагнозов.
4. Нормализация отношений
Нормализация – это процесс проектирования базы данных с целью исключения аномалий модификаций, избыточности данных и приведения отношений к нормальным формам.
Аномалии модификации – последствия, которые могут возникнуть вследствие изменения отношения (таблицы).
Аномалии устраняются путем разбиения отношения на 2 и более новых отношений. Аномалии делятся на 2 основных вида: аномалия удаления, аномалия вставки.
Можно сказать, что в данном курсовом проекте все таблицы находятся в 1НФ, так как все они удовлетворяют требованиям, необходимым для того, чтобы таблица считалась отношением. Главным образом, это требование атомарности.
Отношение находится во 2НФ, если оно находится в 1НФ и все неключевые атрибуты в отношении зависят только от всего ключа в целом.
Принадлежность к 2НФ всех таблиц, кроме двух таблиц ("Диагноз-Процедуры", "Диагноз-Лекарства"), можно определить по наличию 1 первичного простого ключа, состоящего из одного атрибута. А эти две таблицы состоят только из двух ключевых атрибутов, т.е. первичный ключ является составным. Таким образом, в этих таблицах нет неключевых атрибутов, независящих от всего ключа в целом.
Отношение находится в 3НФ, если отношение находится во 2НФ и не имеет транзитивных зависимостей.
В данном курсовом проекте все таблицы находятся в 3НФ. Хотя в начале курсового проекта предполагалось, что таблица "Персонал" будет включать в себя атрибуты "Должность" и "Оклад", что говорило бы о наличие транзитивной зависимости. В результате нормализации таблица "Персонал" была разбита на два отношения "Персонал" и "Должности", которые теперь находятся в 3НФ.
Отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант является ключом-кандидатом.
Можно сказать, что во всех таблицах данной базы данных, кроме первичных ключей ключей-кандидатов не наблюдается, поэтому нельзя сказать, что они находятся в НФБК.
В 4НФ таблицы не могут находиться, так как они не находятся в НФБК.
Таким образом, все отношения находятся в 3НФ.
5. SQL–запросы
В данном курсовом проекте были выполнены следующие запросы:
По сотрудникам:
1. Вывести список сотрудников по определенной должности.
SELECT Personal. Fio as 'ФИО', Otdeleniya. Nazvanie_otdel as 'Название отделения'
FROM Otdeleniya INNER JOIN Personal ON Otdeleniya. Kod_otdel = Personal.kod_otdel
WHERE Personal. Doljnost like "Должность"
order by Otdeleniya. Nazvanie_otdel
2. Вывести список сотрудников по должности, учитывая отделение.
SELECT Personal. Fio as 'ФИО', Otdeleniya. Nazvanie_otdel as 'Название отделения'
FROM Otdeleniya INNER JOIN Personal ON Otdeleniya. Kod_otdel = Personal.kod_otdel
WHERE Otdeleniya. Nazvanie_otdel = "Отделение’ AND Personal. Doljnost like ‘Должность’
3. Вывести список сотрудников, оклад которых превышает n-й суммы
SELECT Personal. Fio as 'ФИО', Personal. Doljnost as 'Должность', Personal. Oklad as 'Оклад'
FROM Personal
where Personal. Oklad> (Сумма)
4. Вывести общий список сотрудников.
SELECT Personal. Fio as 'ФИО', Personal.doljnost as 'Должность', otdeleniya.nazvanie_otdel as 'Название отделения'
FROM Otdeleniya INNER JOIN Personal ON Otdeleniya. Kod_otdel = Personal. Kod_otdel
group by otdeleniya.nazvanie_otdel, Personal. Fio, Personal.doljnost
order by Personal. Fio
По пациентам:
1. Вывести список пациентов по определенному диагнозу.
SELECT Pacienty. Fio as "Ф.И.О.", Otdeleniya. Nazvanie_otdel as "Название отделения", Diagnozy. Nazvanie_diagnoza as "Название диагноза"
FROM Otdeleniya INNER JOIN (Diagnozy INNER JOIN Pacienty ON Diagnozy.kod_diagnoza = Pacienty. Kod_diagnoza) ON Otdeleniya. Kod_otdel = Pacienty.kod_otdel
WHERE Diagnozy. Nazvanie_diagnoza like ‘%Диагноз % '
order by Pacienty. Fio
2. Вывести список пациентов по определенной дате поступления.
SELECT Pacienty. Fio as "Ф.И.О.", Pacienty. Data_postup as "Дата поступления", Otdeleniya. Nazvanie_otdel as "Название отделения", Diagnozy. Nazvanie_diagnoza as "Название диагноза"
FROM Otdeleniya INNER JOIN (Diagnozy INNER JOIN Pacienty ON Diagnozy.kod_diagnoza = Pacienty. Kod_diagnoza) ON Otdeleniya. Kod_otdel = Pacienty.kod_otdel WHERE Pacienty. Data_postup= ‘Дата поступления’ and Diagnozy. Nazvanie_diagnoza like ' % Диагноз % '
order by Pacienty. Fio
Похожие работы
... мире. Внутренняя схема - это сама база данных. Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы: Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия: обследование предметной области, изучение ее информационной структуры выявление всех фрагментов, каждый ...
... сущностей реализуется с помощью отношения. Мощность связи – один-ко-многим (1: М). 1 М М 1 Взаимодействие сущностей 2.2. Связи между сущностями инфологической модели Разработку информационного обеспечения АРМ проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP. СУБД Access предназначена для ...
... ). Причем, дата начала заболевания не может быть больше даты окончания заболевания. 2 ПОСТАНОВКА ЗАДАЧИ Перед разработчиком была поставлена задача спроектировать и разработать базу данных автоматизации учета больных студентов. Она включает в себя подробное изучение предметной области данного курсового проекта: сбор и группировка информации о заболеваниях студентов, лечащих врачах, типа лечения ...
... контроля входной и выходной информации; - автоматизация проведения расчетов. 2. Разработка АРМ сотрудника отдела АИО ФОМС 2.1 Техническое задание Полное название проектируемой системы – «Автоматизированное рабочее место специалиста отдела автоматизации информационного обеспечения Ивановского отделения Фонда обязательного медицинского страхования». Цель проектирования данного АРМ – ...
0 комментариев