Проектирование реляционных баз данных 2 (стр. 4 из 6)

где 250 – количество рабочих дней в году, а 12 мес./2 мес. = 6. Объём памяти

будет увеличиваться ежегодно на столько же при сохранении объёма работы.

Объём памяти, занимаемый программными модулями пользователя,

обычно невелик по сравнению с объёмом самих данных, поэтому может не

учитываться. Требуемый объём оперативной памяти определяется на основа-

нии анализа интенсивности запросов и объёма результирующих данных.

3. Выбор СУБД и других программных средств

Анализ информационных задач показывает, что для реализации требуе-

мых функций подходят почти все СУБД для ПЭВМ (FoxPro, Clipper, MS Access

и др.). Все они поддерживают реляционную модель данных и предоставляют

разнообразные возможности для работы с данными.

14

Объём внешней и оперативной памяти, требующийся для функциониро-

вания СУБД, обычно указывается в сопроводительной документации.

Я выбрала СУБД FOXPRO.

4. Логическое проектирование реляционной БД

4.1. Нормализация полученных отношений (до 4НФ)

1НФ. Для приведения таблиц к 1НФ необходимо, чтобы все атрибуты

были атомарны. Для этого необходимо разбить сложные атрибуты на простые,а многозначные атрибуты вынести в отдельные отношения.

Примечание: В реальных БД сложные атрибуты разбиваются на простые, если:

а) этого требует внешнее представление данных;

б) в запросах поиск может осуществляться по отдельной части атрибута.

Разделим атрибуты Фамилия Имя Отчество на три атрибута Фамилия,

Имя, Отчество.

2НФ. В нашем случае составные первичные ключи имеют отношения

Процедуры, Палаты, Лечение. Неключевые атрибуты этих отношений функционально полно зависят от первичных ключей.

3НФ. В отношении Диагноз атрибут код лечения зависит от кода диагноза,поэтому код лечение следует вынести в отдельное отношениет Лечение.

4НФ. Отношения данного примера не нарушают 4НФ, т.к. не содержат

нетривиальных многозначных зависимостей.

После проведённых преобразований схема БД выглядит так (рис. 1.3):