Проектирование реляционных баз данных 2 (стр. 1 из 6)
Поволжский государственный университет телекоммуникаций и информатики
Кафедра экономических и информационных систем
Проектирование реляционных баз данных
Рецензия
Содержание
Введение…………………………………………………………………………5
1. Инфологическое проектирование…………………………………………...6
1.1. Анализ предметной области……………………………………………….6
1.2. Анализ информационных задач и круга пользователей системы……….6
1.3. Составление реляционных отношений……………………………………7
2. Определение требований к операционной обстановке…………………….16
3. Выбор СУБД и других инструментальных программных средств………..16
4. Логическое проектирование БД……………………………………………...17
4.1. Нормализация полученных отношений…………………………………...17
4.2. Определение дополнительных ограничений целостности……………….26
4.3. Описание групп пользователей и прав доступа…………………………..26
5. Физическое проектирование БД……………………………………………..27
6. Реализация проекта БД……………………………………………………….28
Заключение……………………………………………………………………….37
Список использованных источников…………………………………………...39
Цели и задачи.
Цель курсового проектирования – применение на практике знаний, полученных в процессе изучения курса "Базы данных", и приобретение практических навыков при проектировании и создания информационных систем (ИС),основанных на базах данных.
Номер варианта
Вариант 6 – Больница
Задача – информационная поддержка деятельности регистратуры больницы. БД должна осуществлять:
− учёт поступления пациентов (по отделениям);
− учёт проведённого лечения;
− учёт платных услуг с выдачей счетов на оплату;
− ведение архива выписанных пациентов.
Необходимо предусмотреть определение (по отделениям):
− пропускной способности больницы;
− среднего времени пребывания больных в стационаре;
− наличия свободных мест в палатах (отдельно для мужчин и для женщин);
− количества прооперированных пациентов (из них – с осложнениями и умерших);
− смертности.
Введение
Проектирование баз данных - одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы.
База данных- это совокупность данных конкретной предметной области,при чем данные организованы по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования, и не зависят от программ обработки. В базе данных обеспечивается интеграция логически связанных данных при минимальном дублировании хранимых данных.
Одно из важнейших достоинств реляционных баз данных состоит в том, что вы можете хранить логически сгруппированные данные в разных таблицах и задавать связи между ними, объединяя их в единую базу.
VisualFoxPro - это система управления базами данных (СУБД). Под системой управления понимается комплекс программ, который позволяет не только хранить большие массивы данных в определенном формате, но и обрабатывать их, представляя в удобном для пользователей виде. VisualFoxPro дает возможность также автоматизировать часто выполняемые операции (например, расчет заработной платы, учет материальных ценностей и т.п.). С помощью VisualFoxPro можно не только разрабатывать удобные формы ввода и просмотра данных, но и составлять сложные отчеты.
Основная цель проектирования баз данных состоит в получении такого проекта, который удовлетворяет следующим требованиям:
1)Корректность схемы БД, то есть база должна быть гомоморфным образом моделируемой предметной области, где каждому объекту предметной области соответствует данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных.
2)Обеспечение ограничений
3) Эффективность функционирования
4)Защита данных
5)Простота и удобство эксплуатации
6)Гибкость, т.е. возможность развития БД.
1. Инфологическое проектирование
1.1. Анализ предметной области
База данных создаётся для поддержки деятельности регистратуры больницы. БД должна содержать данные о пациентах, проведенном лечении, платных услугах, количестве мест в палатах и смертности.
В соответствии с предметной областью система строится с учетом следующих особенностей:
-пациента могут лечить сразу несколько врачей, при чем один из них главный врач;
-диагноз выписывается врачом;
-врач может лечить сразу несколько пациентов;
-в одной палате могут жить сразу несколько пациентов;
-в каждом отделении больницы много палат.
Рассмотрение такой структуры базы данных начинается с построения простой модели взаимосвязи объектов.
В самых общих чертах такое моделирование(оно называется моделированием сущностей) подразумевает определение сле-
дующих элементов: объектов (сущностей), информация о которых будет содержаться в БД; свойств этих объектов(атрибутов); взаимосвязей между ними. Выделим базовые сущности этой предметной области. Без учета финансовой информации список сущностей будет следующим:
-ВРАЧИ. Атрибуты-ФИО, номер телефона.
-ПАЦИЕНТЫ. Атрибуты-ФИО, телефон, возраст
-СТАЦИОНАР ПАЦИЕНТОВ. Атрибуты - дата начала лечения, номер палаты, дата окончания лечения, результат
Каждый пункт этого списка описывает отдельное свойство или атрибут рассматриваемой сущности и является потенциальным столбцом в БД. Названия столбцов должны быть предельно ясными (назначение столбца должно быть понятно из его названия) и краткими (чтобы упростить ввод и названий и уменьшить их ширину).
1.2. Анализ информационных задач и круга пользователей системы
Система создается для обслуживания следующих групп пользователей:
-врачей;
-медсестер;
-сотрудников, которые регистрируют больных.
1) Функциональные возможности:
− ведение БД (запись, чтение, модификация, удаление в архив);
− обеспечение логической непротиворечивости БД;
− обеспечение защиты данных от несанкционированного или случайного доступа (определение прав доступа);
− реализация наиболее часто встречающихся запросов в готовом виде;
− предоставление возможности сформировать произвольный запрос на
языке манипулирования данными.
2) Готовые запросы:
-вывод пациентов с летальным исходом;
-вывод количество мест в мужских палатах;
-вывод количество мест в женских палатах;
-вывод количество пациентов, которым делали операцию
1.3. Составление реляционных отношений
Для того, чтобы сделать работы регистратуры эффективнее необходимо учитывать всех больных, поступавших в больницу. А также время и дату поступления, к какому врачу, то есть кабинет и результат обследования или лечения. После выделения сущностей, необходимо определить первичные ключи.
Рассмотрим таблицу Пациенты. Среди ее столбцов очевидным кандида-
том на первичный ключ является ID-пациента. Первичные ключи
выделяют подчеркиванием.
Примечание: суррогатный первичный ключ также может вводиться в тех случаях, когда потенциальный ключ имеет большой размер (например, длинная
символьная строка) или является составным (не менее трёх атрибутов).
Сурагатныйключ в нашем случаи будет ID-пац_стационар. В таблице Врачи первичным ключом будет ID-врача. В таблице Прием-ID-приема, таблицу Диагноз можно идентифицировать ключом ID-диагноза.
После определения ключей необходимо определить связи между сущностями. В моей базе данных практически все связи один ко многим. Рассмотрим одну из них: в одном стационаре может находится много врачей. Единственная связь один к одному между процедурами и пац_стационаром.
Тип связи M:N реализуется путем ввода ассоциативного объекта, кото-
рый является соединением первичных ключей соответствующих отношений
(рис. 1.1), а связь M:N разбивается на две связи типа 1:N (рис. 1.2).
