Автор работы: Пользователь скрыл имя, 28 Февраля 2011 в 21:36, курсовая работа
Цель курсового проектирования – применение на практике знаний, полученных в процессе изучения курса "Базы данных", и приобретение практических навыков при проектировании и создания информационных систем (ИС),основанных на базах данных.
Введение…………………………………………………………………………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
Описание атрибутов объекта Стационар
| Название
атрибута |
Обозначение
атрибута |
Динамичность | Количество
повторений |
Область
возможных значений |
Вывод
значений |
Ограничение
доступа |
Примечание |
| Код отделения | kod_otdel | S | - | N(4) | см. п.4.3 | первичный ключ | |
| Количество палат | kollichestvo_palat | D | 1 | C(10) | см. п.4.3 | Обязательное поле | |
| этаж | etag | D | 1 | C(10) | см. п.4.3 | Обязательное поле |
Описание атрибутов объекта Диагноз
| Название
атрибута |
Обозначение
атрибута |
Динамичность | Количество
повторений |
Область
возможных значений |
Вывод
значений |
Ограничение
доступа |
Примечание |
| ID-диагноза | id_diagnoz | S | - | N(4) | см. п.4.3 | первичный ключ | |
| Название | nazvanie | D | 1 | C(27) | см. п.4.3 | Обязательное поле | |
| ID-лечения | id_lechen | S | - | N(10) | см. п.4.3 | Внешний ключ(к Лечение) |
Описание атрибутов объекта Лечение
| Название
атрибута |
Обозначение
атрибута |
Динамичность | Количество
повторений |
Область
возможных значений |
Вывод
значений |
Ограничение
доступа |
Примечание |
| 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 | Многозначное поле |
Описание атрибутов
объекта Палаты
| Название
атрибута |
Обозначение
атрибута |
Динамичность | Количество
повторений |
Область
возможных значений |
Вывод
значений |
Ограничение
доступа |
Примечание |
| Номер палаты | 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 | Внешний ключ(к Стационар) |
Описание атрибутов объекта Процедуры
| Название
атрибута |
Обозначение
атрибута |
Динамичность | Количество
повторений |
Область
возможных значений |
Вывод
значений |
Ограничение
доступа |
Примечание |
| ID-лечения | id_lechen | S | - | N(4) | см. п.4.3 | первичный ключ | |
| ID-пац_стационара | nazvanie | S | - | C(22) | см. п.4.3 | Обязательное поле |
2. Определение требований к операционной обстановке
Для выполнения этого этапа необходимо знать (хотя бы ориентировоч-
но) объём работы издательства (т.е. количество книг, авторов и заказчиков), а
также иметь представление о характере и интенсивности запросов.
Объём внешней
памяти, необходимый для
складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные( Д М ). Наиболее существенным обычно является Д М . Объём памяти Д М , требуемый для хранения данных, можно приблизительно оценить по формуле
где li – длина записи в i-й таблице (в байтах), Ni – примерное (максимально
возможное) количество записей в i-й таблице, i Na – количество записей в архиве 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НФ. В нашем случае составные первичные ключи имеют отношения
Процедуры, Палаты, Лечение. Неключевые атрибуты этих отношений функционально полно зависят от первичных ключей.