Задача Проектирование реляционных баз данных 2
Работа добавлена на сайт bukvasha.net: 2015-10-29Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Поволжский государственный университет телекоммуникаций и информатики
Кафедра экономических и информационных систем
Проектирование реляционных баз данных
Рецензия
Содержание
Введение…………………………………………………………………………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 –
Больница
Задача – информационная поддержка деятельности регистратуры больницы. БД должна осуществлять:
− учёт поступления пациентов (по отделениям);
− учёт проведённого лечения;
− учёт платных услуг с выдачей счетов на оплату;
− ведение архива выписанных пациентов.
Необходимо предусмотреть определение (по отделениям):
− пропускной способности больницы;
− среднего времени пребывания больных в стационаре;
− наличия свободных мест в палатах (отдельно для мужчин и для женщин);
− количества прооперированных пациентов (из них – с осложнениями и умерших);
− смертности.
Введение
Проектирование баз данных - одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы.
База данных- это совокупность данных конкретной предметной области,при чем данные организованы по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования, и не зависят от программ обработки. В базе данных обеспечивается интеграция логически связанных данных при минимальном дублировании хранимых данных.
Одно из важнейших достоинств реляционных баз данных состоит в том, что вы можете хранить логически сгруппированные данные в разных таблицах и задавать связи между ними, объединяя их в единую базу.
Visual Fox Pro - это система управления базами данных (СУБД). Под системой управления понимается комплекс программ, который позволяет не только хранить большие массивы данных в определенном формате, но и обрабатывать их, представляя в удобном для пользователей виде. Visual Fox Pro дает возможность также автоматизировать часто выполняемые операции (например, расчет заработной платы, учет материальных ценностей и т.п.). С помощью Visual Fox Pro можно не только разрабатывать удобные формы ввода и просмотра данных, но и составлять сложные отчеты.
Основная цель проектирования баз данных состоит в получении такого проекта, который удовлетворяет следующим требованиям:
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).
|
|
|
имеет
Стационар
| Код отделения Кол-во палат Этаж |
записывает
|
|
|
палаты
| ID -лечения ID -пац_стационара |
Процедуры
Рис. 1.1. Диаграмма сущность-связь БД больницы
|
|
|
R
3
R
4
R
1
R9 R11
R5 R7
Стационар
| Код отделения Кол-во палат Этаж |
R10
|
|
|
палаты
|
R12
R16
| ID -лечения ID -пац_стационара |
Процедуры
Рис. 1.2. Уточненная диаграмма сущность-связь БД больницы
В таблице 1.1 приведено описание связей
Таблица описания связей таблица 1.1
| Название связи | Обозначение связи | Главный объект | Связанный объект | Вид связи | Условие связи | Способ реализации | Примечание |
| имеет | R1 | Прием | Врачи | М:1 | | По коду врача | |
| имеет | R2 | Врачи | Прием | 1:М | | По коду врача | |
| записывает | R3 | Пациенты | Прием | 1:М | | По коду пациента | |
| записываются | R4 | Прием | Пациенты | М:1 | | По коду пациента | |
| имеются | R5 | Пациенты | Пац_стационар | 1:М | | По коду пациента | |
| имеют | R6 | Пац_стационар | Пациенты | М:1 | | По коду пациента | |
| записывает | R7 | Прием | Диагноз | М:1 | | По коду диагноза | |
| записывается | R8 | Диагноз | Прием | 1:М | | По коду диагноза | |
| имеет | R9 | Врачи | Стационар | М:1 | | По коду отделения | |
| имеются | R10 | Стационар | Врачи | 1:М | | По коду отделения | |
| имеют | R11 | Врачи | Палаты | 1:М | | По коду отделения | |
| имеются | R12 | Палаты | врачи | М:1 | | По коду отделения | |
| содержит | R13 | Диагноз | Лечение | М:1 | | По коду лечения | |
| содержится | R14 | Лечение | Диагноз | 1:М | | По коду лечения | |
| имеются | R15 | Пац_стационар | Процедуры | M:1 | | По коду пац_стационара | |
| имеются | R16 | Процедуры | Пац_стационар | 1:M | | По коду пац_стационара | |
| содержит | R17 | Пац_стационар | Палаты | М:1 | | По коду номера палаты | |
| содержатся | R18 | палаты | Пац_стационар | 1:М | | По коду номера палаты | |
| содержит | R19 | Процедуры | Лечение | М:1 | | По коду лечения | |
| содержится | R20 | лечение | процедуры | 1:М | | По коду лечения | |
Отношения приведены в табл. 1.2 – 1.8. В столбце "Динамичность" бу-
дем помечать буквой D изменяемые атрибуты (динамические), S - неизменяемые (статические). "Количество повторений" означает, сколько раз повторяется множественный атрибут. В столбце "Область возможных значений" указывается тип (C - символы, D - дата, N - число) и, возможно, диапазон изменения атрибута. В столбце "Вывод значений" указываются номера атрибутов, из которых можно получить данный атрибут. Выводимый атрибут можно не хранить. В столбце "Ограничение доступа" указано, кто имеет право изменять сведения.
Таблица 1.2
Описание атрибутов объекта Пациенты
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-пациента | ID_pacien | S | - | N(4) | | см. п.4.3 | первичный ключ |
| ФИО | FIO | D | 1 | C(50) | | см. п.4.3 | Обязательное поле |
| Номер телефона | Nomer_telefona | D | 1 | C(15) | | см. п.4.3 | Многозначное поле |
| Возраст | Vozrast | D | 1 | N(10) | | см. п.4.3 | Обязательное поле |
Таблица1.3
Описание атрибутов объекта Врачи
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-врача | ID_pacien | S | - | N(4) | | см. п.4.3 | первичный ключ |
| ФИО | FIO | D | 1 | C(50) | | см. п.4.3 | Обязательное поле |
| Номер телефона | Nomer_telefona | D | 1 | C(15) | | см. п.4.3 | Многозначное поле |
Таблица1.4
Описание атрибутов объекта Пац_Стационара
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-пац_стационара | id_pac_sta | S | - | N(4) | | см. п.4.3 | Сурагатный первичный ключ |
| ID-пациента | ID_pacien | S | - | N(5) | | см. п.4.3 | Внешний ключ(к Пациенты) |
| Код отделения | kod_otdel | S | - | N(4) | | см. п.4.3 | Внешний ключ(к Стационар) |
| Дата начала лечения | data_nachala_lecheniya | D | 1 | D(10) | | см. п.4.3 | Обязательное поле |
| Номер палаты | nomer_pal | D | 1 | N(10) | | см. п.4.3 | Обязательное поле |
| Дата окончания лечения | data_okonchaniya_lecheniya | D | 1 | D(10) | | см. п.4.3 | Обязательное поле |
| Результат | rezultat | D | 1 | C(10) | | см. п.4.3 | Обязательное поле |
Таблица1.5
Описание атрибутов объекта Прием
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-приема | id_priema | S | - | N(10) | | см. п.4.3 | первичный ключ |
| ID-пациента | id_pacien | S | - | N(4) | | см. п.4.3 | внешний ключ(к Пациенты) |
| ID-врача | id_vracha | S | - | N(10) | | см. п.4.3 | Внешний ключ(к Врачи) |
| ID-диагноза | id_diagnoz | S | - | N(10) | | см. п.4.3 | Внешний ключ(к Диагноз) |
| Дата | data | D | 1 | D(10) | | см. п.4.3 | Обязательное поле |
| Время | vremya | D | 1 | C(15) | | см. п.4.3 | Обязательное поле |
| Кабинет | kabinet | D | 1 | C(20) | | см. п.4.3 | Обязательное поле |
| Исход | isxod | D | 1 | C(20) | | см. п.4.3 | Многозначительное поле |
Таблица 1.6
Описание атрибутов объекта Стационар
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| Код отделения | kod_otdel | S | - | N(4) | | см. п.4.3 | первичный ключ |
| Количество палат | kollichestvo_palat | D | 1 | C(10) | | см. п.4.3 | Обязательное поле |
| этаж | etag | D | 1 | C(10) | | см. п.4.3 | Обязательное поле |
Таблица 1.7
Описание атрибутов объекта Диагноз
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-диагноза | id_diagnoz | S | - | N(4) | | см. п.4.3 | первичный ключ |
| Название | nazvanie | D | 1 | C(27) | | см. п.4.3 | Обязательное поле |
| ID-лечения | id_lechen | S | - | N(10) | | см. п.4.3 | Внешний ключ(к Лечение) |
Таблица 1.8
Описание атрибутов объекта Лечение
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-лечения | id_lechen | S | - | N(4) | | см. п.4.3 | первичный ключ |
| Название | nazvanie | D | 1 | C(22) | | см. п.4.3 | Обязательное поле |
| стоимость | stoimost | D | 1 | Cur(10) | | см. п.4.3 | Обязательное поле |
| Статус | statys | D | 1 | C(10) | | см. п.4.3 | Многозначное поле |
Таблица 1.9
Описание атрибутов объекта Палаты
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| Номер палаты | nomer_pal | S | - | N(4) | | см. п.4.3 | первичный ключ |
| статус | status | D | 1 | C(10) | | см. п.4.3 | Многозначное поле |
| Количество мест | kollichestvo_mest | D | 1 | C (10) | | см. п.4.3 | Обязательное поле |
| Код отделения | kod_otdel | S | - | N(10) | | см. п.4.3 | Внешний ключ(к Стационар) |
Таблица 1.10
Описание атрибутов объекта Процедуры
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-лечения | id_lechen | S | - | N(4) | | см. п.4.3 | первичный ключ |
| ID-пац_стационара | nazvanie | S | - | C(22) | | см. п.4.3 | Обязательное поле |
2. Определение требований к операционной обстановке
Для выполнения этого этапа необходимо знать (хотя бы ориентировоч-
но) объём работы издательства (т.е. количество книг, авторов и заказчиков), а
также иметь представление о характере и интенсивности запросов.
Объём внешней памяти, необходимый для функционирования системы,
складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные( Д
М ). Наиболее существенным обычно является Д
М . Объём памяти Д
М , требуемый для хранения данных, можно приблизительно оценить по формуле
Мд=2∑ni=1li*(Ni+Nai)
где l
i – длина записи в i-й таблице (в байтах), N
i – примерное (максимально
возможное) количество записей в i-й таблице, i
N
a – количество записей в архиве i-й таблицы. Коэффициент 2 перед суммой нужен для того, чтобы выделить память для хранения индексов, промежуточных данных, для выполнения объёмных операций (например, сортировки) и т.п.
Посчитаем приблизительно, какой объём внешней памяти потребуется
для хранения данных. Примем ориентировочно, что:
− одновременно осуществляется около пятидесяти приемов, работа над
ними продолжается в среднем два месяца (по 0,3К);
− в компании работает 100 сотрудников (по 0,2К на каждого сотрудни-
ка);
− больница сотрудничает с тридцатью врачами (по 0,2К);
− в день приема порядка двадцати заявок (по 0,1К);
− устаревшие данные переводятся в архив.
Тогда объём памяти для хранения данных за первый год примерно со-
ставит:
M
Д = 2(100 ⋅ 0,2 + 6(50 ⋅ 0,3) + 30 ⋅ 0,2 + 250(20 ⋅ 0,1)) = 1232К ≈ 1,2М ,
где 250 – количество рабочих дней в году, а 12 мес./2 мес. = 6. Объём памяти
будет увеличиваться ежегодно на столько же при сохранении объёма работы.
Объём памяти, занимаемый программными модулями пользователя,
обычно невелик по сравнению с объёмом самих данных, поэтому может не
учитываться. Требуемый объём оперативной памяти определяется на основа-
нии анализа интенсивности запросов и объёма результирующих данных.
3. Выбор СУБД и других программных средств
Анализ информационных задач показывает, что для реализации требуе-
мых функций подходят почти все СУБД для ПЭВМ (FoxPro, Clipper, MS Access
и др.). Все они поддерживают реляционную модель данных и предоставляют
разнообразные возможности для работы с данными.
14
Объём внешней и оперативной памяти, требующийся для функциониро-
вания СУБД, обычно указывается в сопроводительной документации.
Я выбрала СУБД FOX PRO.
4. Логическое проектирование реляционной БД
4.1. Нормализация полученных отношений (до 4НФ)
1НФ. Для приведения таблиц к 1НФ необходимо, чтобы все атрибуты
были атомарны. Для этого необходимо разбить сложные атрибуты на простые,а многозначные атрибуты вынести в отдельные отношения.
Примечание: В реальных БД сложные атрибуты разбиваются на простые, если:
а) этого требует внешнее представление данных;
б) в запросах поиск может осуществляться по отдельной части атрибута.
Разделим атрибуты Фамилия Имя Отчество на три атрибута Фамилия,
Имя, Отчество.
2НФ. В нашем случае составные первичные ключи имеют отношения
Процедуры, Палаты, Лечение. Неключевые атрибуты этих отношений функционально полно зависят от первичных ключей.
3НФ. В отношении Диагноз атрибут код лечения зависит от кода диагноза,поэтому код лечение следует вынести в отдельное отношениет Лечение.
4НФ. Отношения данного примера не нарушают 4НФ, т.к. не содержат
нетривиальных многозначных зависимостей.
После проведённых преобразований схема БД выглядит так (рис. 1.3):
|
|
|
R
3
R
4
R
1
R9 R11
R7
R5 Стационар
| Код отделения Кол-во палат Этаж |
R10
|
|
|
R20
палаты
|
R12
R16
| ID -лечения ID -пац_стационара |
Процедуры
Рис. 1.3. Окончательная ER-модель БД больницы
| Название объекта | Обозначе- ние объекта | Количе- ство экземп- ляров | Про- цент изме- нений | Ограни- чение доступа | Связанные объекты | Примечания |
| Пациенты | Пациенты | 100 | 20% | больница | Пац_стационар,Прием | |
| Прием | Прием | 200 | 20% | больница | Пациенты,диагноз,врачи | |
| Стационар | Стационар | 400 | 30% | больница | Пац_стационар,врачи,палаты | |
| Диагноз | Диагноз | 100 | 10% | больница | Прием,лечение | |
| Врачи | Врачи | 300 | 20% | больница | Прием,стационар | |
| Пац_стационар | Пац_стационар | 100 | 30% | больница | Процедуры,палаты,пациенты,стационар | |
| Лечение | Лечение | 100 | 20% | больница | Диагноз,процедуры | |
| Палаты | Палаты | 400 | 20% | больница | Стационар,пац_стационар | |
| Процедуры | Процедуры | 100 | 10% | больница | Пац_стационар,лечение | |
В таблице 1.11 приведено уточненное описание связей.
Таблица 1.11
Таблица описания связей
| Название связи | Обозначение связи | Главный объект | Связанный объект | Вид связи | Условие связи | Способ реализации | Примечание |
| имеет | R1 | Прием | Врачи | М:1 | | По коду врача | |
| имеет | R2 | Врачи | Прием | 1:М | | По коду врача | |
| записывает | R3 | Пациенты | Прием | 1:М | | По коду пациента | |
| записываются | R4 | Прием | Пациенты | М:1 | | По коду пациента | |
| имеются | R5 | Пациенты | Пац_стационар | 1:М | | По коду пациента | |
| имеют | R6 | Пац_стационар | Пациенты | М:1 | | По коду пациента | |
| записывает | R7 | Прием | Диагноз | М:1 | | По коду диагноза | |
| записывается | R8 | Диагноз | Прием | 1:М | | По коду диагноза | |
| имеет | R9 | Врачи | Стационар | М:1 | | По коду отделения | |
| имеются | R10 | Стационар | Врачи | 1:М | | По коду отделения | |
| имеют | R11 | Врачи | Палаты | 1:М | | По коду отделения | |
| имеются | R12 | Палаты | врачи | М:1 | | По коду отделения | |
| содержит | R13 | Диагноз | Лечение | М:1 | | По коду лечения | |
| содержится | R14 | Лечение | Диагноз | 1:М | | По коду лечения | |
| имеются | R15 | Пац_стационар | Процедуры | M:1 | | По коду пац_стационара | |
| имеются | R16 | Процедуры | Пац_стационар | 1:M | | По коду пац_стационара | |
| содержит | R17 | Пац_стационар | Палаты | М:1 | | По коду номера палаты | |
| содержатся | R18 | палаты | Пац_стационар | 1:М | | По коду номера палаты | |
| содержит | R19 | Процедуры | Лечение | М:1 | | По коду лечения | |
| содержится | R20 | лечение | процедуры | 1:М | | По коду лечения | |
Окончательные схемы отношений базы данных с указанием ключей и
других ограничений целостности приведены в табл. 1.12 – 1.20.
Описание атрибутов объекта Пациенты
Таблица 1.12
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-пациента | ID_pacien | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| Фамилия | familiya | D | 1 | C(50) | | см. п. 2.4.3 | Обязательное поле |
| Имя | imya | D | 1 | C(20) | | см. п. 2.4.3 | Обязательное поле |
| Отчество | otchestvo | D | 1 | C(20) | | см. п. 2.4.3 | Обязательное поле |
| Номер телефона | Nomer_telefona | D | 1 | C(15) | | см. п. 2.4.3 | Многозначное поле |
| Возраст | Vozrast | D | 1 | N(10) | | см. п. 2.4.3 | Обязательное поле |
Таблица 1.13
Описание атрибутов объекта Врачи
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-врача | id_vracha | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| Фамилия | familiya | D | 1 | C(50) | | см. п. 2.4.3 | Обязательное поле |
| Имя | imya | D | 1 | C(50) | | см. п. 2.4.3 | Обязательное поле |
| Отчество | otchestvo | D | 1 | C(50) | | см. п. 2.4.3 | Обязательное поле |
| Номер телефона | Nomer_telefona | D | 1 | C(15) | | см. п. 2.4.3 | Многозначное поле |
Описание атрибутов объекта Пац_стационар
Таблица 1.14
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-пац_стационара | id_pac_sta | S | - | N(4) | | см. п. 2.4.3 | Сурагатный первичный ключ |
| ID-пациента | ID_pacien | S | - | N(5) | | см. п. 2.4.3 | Внешний ключ(к Пациенты) |
| Код отделения | kod_otdel | S | - | N(4) | | см. п. 2.4.3 | Внешний ключ(к Стационар) |
| Дата начала лечения | data_nachala_lecheniya | D | 1 | D(10) | | см. п. 2.4.3 | Обязательное поле |
| Номер палаты | nomer_pal | D | 1 | N(10) | | см. п. 2.4.3 | Обязательное поле |
| Дата окончания лечения | data_okonchaniya_lecheniya | D | 1 | D(10) | | см. п. 2.4.3 | Обязательное поле |
| Результат | rezultat | D | 1 | C(10) | | см. п. 2.4.3 | Обязательное поле |
Описание атрибутов объекта Прием
Таблица 1.15
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-приема | id_priema | S | - | N(10) | | см. п. 2.4.3 | первичный ключ |
| ID-пациента | id_pacien | S | - | N(4) | | см. п. 2.4.3 | внешний ключ(к Пациенты) |
| ID-врача | id_vracha | S | - | N(10) | | см. п. 2.4.3 | Внешний ключ(к Врачи) |
| ID-диагноза | id_diagnoz | S | - | N(10) | | см. п. 2.4.3 | Внешний ключ(к Диагноз) |
| Дата | data | D | 1 | D(10) | | см. п. 2.4.3 | Обязательное поле |
| Время | vremya | D | 1 | C(15) | | см. п. 2.4.3 | Обязательное поле |
| Кабинет | kabinet | D | 1 | C(20) | | см. п. 2.4.3 | Обязательное поле |
| Исход | isxod | D | 1 | C(20) | | см. п. 2.4.3 | Многозначительное поле |
Описание атрибутов объекта Стационар
Таблица 1.16
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| Код отделения | kod_otdel | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| Количество палат | kollichestvo_palat | D | 1 | N(10) | | см. п. 2.4.3 | Обязательное поле |
| этаж | etag | D | 1 | C(10) | | см. п. 2.4.3 | Обязательное поле |
Описание атрибутов объекта Диагноз
Таблица 1.17
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-диагноза | id_diagnoz | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| Название | nazvanie | D | 1 | C(27) | | см. п. 2.4.3 | Обязательное поле |
| ID-лечения | id_lechen | S | - | N(10) | | см. п. 2.4.3 | Внешний ключ(к Лечение) |
Описание атрибутов объекта Лечение
Таблица 1.18
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-лечения | id_lechen | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| Название | nazvanie | D | 1 | C(22) | | см. п. 2.4.3 | Обязательное поле |
| стоимость | stoimost | D | 1 | Cur(10) | | см. п. 2.4.3 | Обязательное поле |
| Статус | statys | D | 1 | C(10) | | см. п. 2.4.3 | Многозначное поле |
Описание атрибутов объекта Палаты
Таблица 1.19
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| Номер палаты | nomer_pal | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| статус | status | D | 1 | C(10) | | см. п. 2.4.3 | Многозначное поле |
| Количество мест | kollichestvo_mest | D | 1 | C (10) | | см. п. 2.4.3 | Обязательное поле |
| Код отделения | kod_otdel | S | - | N(10) | | см. п. 2.4.3 | Внешний ключ(к Стационар) |
Описание атрибутов объекта Процедуры
Таблица 1.20
| Название атрибута | Обозначение атрибута | Динамичность | Количество повторений | Область возможных значений | Вывод значений | Ограничение доступа | Примечание |
| ID-лечения | id_lechen | S | - | N(4) | | см. п. 2.4.3 | первичный ключ |
| ID-пац_стационара | id_pac_sta | S | - | C(22) | | см. п. 2.4.3 | Обязательное поле |
4.2. Определение дополнительных ограничений цело-
стности
Перечислим ограничения целостности, которые не указаны в табл. 1.12–1.20.
1. Значения всех числовых атрибутов – больше 0 (или null, если атрибут
необязателен).
2. Область значений атрибута Статус от ношения Палаты-символы м,ж.
А в отношении Лечение – платное,бесплатное.
3. В отношении Пациентыпорядковые номера пациентов должны идти подряд, начиная с 1.
Ограничения (3) нельзя реализовать в схеме отношения. В реальных
БД подобные ограничения целостности реализуются программно (через внешнее приложение или специальную процедуру контроля данных).
4.3. Описание групп пользователей и прав доступа
Опишем для каждой группы пользователей права доступа к каждой таб-
лице и к каждому полю (атрибуту).
1. Администратор БД: имеет доступ ко всем данным (по записи), может из-
менять структуру базы данных и связи между отношениями. Устанавли-
вает права доступа для всех остальных групп.
2. Представители администрации компании: имеют доступ по чтению ко
всем данным и доступ по записи к отношениям Врачи, Палаты и Стационар
3. Менеджеры: имеет доступ по чтению ко всем данным, кроме отношения
Диагноз. Имеют доступ по записи к отношениям Пациенты,Прием,Стационар,Врачи,Лечение,Процедуры,Палаты,Пац_стационар
4. Сотрудники: имеют доступ по чтению к отношениям Палаты, Стационар,.
6.
Реализация проекта базы данных
Данный проект реализуется в СУБД FOX PRO. Для нормального функ-
ционирования базы данных создаются таблицы, запросы, отчеты и формы. Для
удобства пользователя – кнопочная форма. Также целесообразно определить
пользователей базы данных и разграничить права доступа.
Представим последовательность реализации в семь этапов.
1 Этап. Создание таблиц
На данном этапе в режиме Конструктора, Мастера или Путем ввода
данных задаются названия полей, типы данных, маски ввода, размеры и описа-
ния полей, выбираются первичные и вторичные ключи.
Рис. 1.5. Таблица Прием в режиме Конструктора
Аналогичным образом создаются все остальные таблицы базы данных
2 Этап. Схема данных
На данном этапе на Схему данных MS Access выносятся все созданные
таблицы и устанавливаются связи между ними. При установлении связей между таблицами необходимо установить режим Обеспечения целостности данных.
Рис. 1.6. Схема данных реализуемого проекта
Visual Fox Pro также позволяет просматривать сведения о зависимостях между объектами базы данных. Просмотр списка объектов, использующих указанный объект, помогает осуществлять поддержку базы данных и предотвращать ошибки, связанные с потерей источников записей. Реализована возможность просматривать объекты, зависящие от данного объекта, а также объекты, от которых зависит он. Также с помощью анализа зависимостей можно найти и локализовать возможные ошибки схемы данных.
Чтобы посмотреть зависимости объекта БД (таблицы, запроса, формы,
отчета) нужно выбрать из контекстного меню объекта пункт "Зависимости объектов" (рис. 1.7).
Рис. 1.7. Просмотр объектов зависящих от таблицы врачи
Теперь рассмотрим готовые запросы:
-вывод пациентов с летальным исходом;
-вывод количество мест в мужских палатах;
-вывод количество мест в женских палатах;
-вывод пациентов, которым делали операцию.
Вывод пациентов с летальным исходом:
SELECT Пац_стационар.id_pacien, Пац_стационар.rezultat;
FROM ;
data1!пац_стационар;
WHERE Пац_стационар.rezultat LIKE ( "л%" )
Количество мест в мужских палатах
SELECT Палаты.status, Палаты.kollichestvo_mest;
FROM ;
data1!стационар ;
INNER JOIN data1!палаты ;
ON Стационар.kod_otdel = Палаты.kod_otdel;
WHERE Палаты.status = ( "м" )
Количество мест в женских палатах
SELECT Палаты.kollichestvo_mest, Палаты.status;
FROM ;
data1!стационар ;
INNER JOIN data1!палаты ;
ON Стационар.kod_otdel = Палаты.kod_otdel;
WHERE Палаты.status = ( "ж" )
вывод пациентов, которым делали операцию
SELECT Пациенты.id_pacien, Прием.isxod;
FROM ;
data1!пациенты ;
INNER JOIN data1!прием ;
ON Пациенты.id_pacien = Прием.id_pacien;
WHERE Прием.isxod LIKE ( "операция" )
3 Этап. Создание отчетов
Отчет является эффективным средством представления данных в печатном формате. Имея возможность управлять размером и внешним видом всех
элементов отчета, пользователь может отобразить сведения желаемым образом.
Пример отчета основанного на одной таблице(в режиме Конструктора) представлен на рис. 1.10 и 1.11
Рис.1.10 отчет в режиме конструктора
Рис.1.11. отчет в режиме просмотра
Этап 4. Создание экранных форм
Для удобства ввода значений в таблицы базы данных в Visual Fox Pro
предусмотрена возможность создания экранных форм.
Формы можно создавать с помощью мастера построения и конструктора. На формы можно выносить не только поля и их названия, но и дополни-
тельные кнопки (навигации, поиска, открытия других форм, отчетов, обработки записей), а также информацию, такую как дата и время.
В режиме конструктора
В режиме просмотра
Отчет основанный на одной таблице
В режиме конструктора
В режиме просмотра
Этап 5. Разграничение доступа
Учетные записи пользователей предоставляют отдельным пользователям определенные привилегии доступа к сведениям и ресурсам базы данных.
Учетные записи групп содержат несколько учетных записей пользователей и
предоставляют средства контроля и управления разрешениями и доступом этих групп к объектам базы данных.
Заключение
Я научилась создавать и проектировать базы данных. В нашей жизни это очень важно и необходимо, так как современные информационные системы характеризуются огромными объёмами хранимых данных, их сложной организацией, необходимостью удовлетворять разнообразные требования пользователей.
Поэтому мы и рассматриваем понятие баз данных (БД), возможности систем управления базами данных (СУБД) и их использование.
База данных- это совокупность данных конкретной предметной области,при чем данные организованы по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования, и не зависят от программ обработки. В базе данных обеспечивается интеграция логически связанных данных при минимальном дублировании хранимых данных.
Одно из важнейших достоинств реляционных баз данных состоит в том, что вы можете хранить логически сгруппированные данные в разных таблицах и задавать связи между ними, объединяя их в единую базу.
Visual Fox Pro - это система управления базами данных (СУБД). Под системой управления понимается комплекс программ, который позволяет не только хранить большие массивы данных в определенном формате, но и обрабатывать их, представляя в удобном для пользователей виде. Visual Fox Pro дает возможность также автоматизировать часто выполняемые операции (например, расчет заработной платы, учет материальных ценностей и т.п.). С помощью Visual Fox Pro можно не только разрабатывать удобные формы ввода и просмотра данных, но и составлять сложные отчеты
СУБД основывается на трех основных типов моделей данных и их комбинациях:
– Иерархическая,
– Сетевая;
– Реляционная.
СУБД позволяют вводить и корректировать данные двумя способами:
· с помощью стандартной формы в виде таблицы;
· с помощью экранных форм, специально созданных для этого пользователем.
Форма – это средство для ввода данных в таблицу.
В форме можно разместить элементы управления: счётчики, списки, переключатели, флажки и прочие элементы. Использование формы снимает утомление оператора и предотвращает появление печатных ошибок.
При работе с СУБД используются запросы.
Запрос – это инструкция на отбор записей.
Запросы служат для извлечения данных из таблиц и предоставления их в удобном виде пользователю.
С их помощью можно выполнить операции:
- отбора данных;
- сортировку и фильтрацию данных;
- преобразования данных по заданному алгоритму;
- создания новых таблиц;
- автоматического наполнения таблиц данными, импортированными из других источников;
- простейшего вычисления в таблицах.
Используются запросы следующих типов:
· запрос – выборка, предназначенный для отбора данных, хранящихся в таблицах, и не изменяющий эти данные (самый распространённый тип запроса);
· запрос – изменение, предназначенный для изменения или перемещения данных.
К ним относятся:
- запрос на добавление записей,
- запрос на удаление записей;
- запрос на создание таблицы;
- запрос на обновление.
· запрос с параметром, позволяющий определить одно или несколько условий отбора во время выполнения запроса.
Отчёты предназначены для вывода данных на печатающее устройство (принтер), а не на экран. В отчетах размещаются колонтитулы, номера страниц, время создания отчёта и другая служебная информация.
При создании отчётов предусмотрены дополнительные возможности вывода данных:
· включать в отчёт выборочную информацию из таблиц БД;
· добавлять информацию, не содержащуюся в БД;
· выдавать итоговые данные на основе информации БД;
· располагать вводимую в отчёте информацию в любом, удобном для пользователя виде;
· включать в отчёт информацию из разных связанных таблиц БД.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Амелина Н.И., Мачулина Л.А. Методические указания по курсовому
проектированию по курсу "Базы данных". – Ростов-на-Дону.: Изд-во
Ростов. гос. Ун-та 1999. – 39 с.
2. Бекаревич Ю.Б., Пушкина Н.В., Смирнова Е.Ю. Управление базами
данных: Учеб. пособие. СПб.: Изд-во С.-Петер. ун-та 1999. – 172 с.
3. Боуман Джудит С., Эмерсон Сандра Л., Дарновски Марси Практиче-
ское руководство по SQL, 4-е издание.: Пер. с англ. – М.: Издатель-
ский дом "Вильямс", 2001. – 352 с.: ил.
4. Диязитдинова А.Р., Качков Д.А. Проектирование баз данных. Учебное
пособие. – Самара: ПГАТИ,
5. Карпова И.Н. Введение в базы данных: Методические указания к кур
