Проектирование базы данных

структура оТчЕта по курсовому проекту

 

1. Описание предметной области

2. Проектирование базы данных

2.1. Объекты предметной области

2.2. Построение ER – модели

2.3. Реляционная модель

3. Проектирование информационной  системы

3.1. Функции информационной системы

3.2. Архитектура информационной  системы

4. Реализация информационной системы

4.1. Средства реализации

Литература

 

Разработка приложения конкретной задачи

1. Описание предметной области

6. РОДДОМ 
Объекты: младенцы, матери, врачи, медсестры (акушерки). 
Условия: Если у матери родились близнецы, то каждый младенец учитывается отдельно. 
Задачи: Проверить, есть ли за заданный период среди родившихся детей близнецы, первый раз мать находится в этом роддоме или нет. Сколько родов принял тот или ной врач, медсестра. Кто принимал роды у данных матери и ребенка. Роды были с осложнениями или без. Сколько времени в роддоме провели мать (до и после родов), ребенок.

- Мать: IDМ, ФИО,  дата рождения, адрес, телефон,  палата, дата поступления. 
- Младенец: IDР, пол, дата рождения, вес, рост. 
- Врач: IDВ, ФИО, дата рождения, дата приема на работу, квалификация, зарплата. 
- Медсестра: IDА, ФИО, дата рождения, дата приема на работу, квалификация, зарплата.

 

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

Роддом принимает  рожениц как непосредственно  перед родами, так и за 2–3 месяца до родов — на сохранение. На каждую роженицу заводится учетная карточка, которая сохраняется в течение длительного времени. В карточку заносятся сведения обо всех пребываниях роженицы в стационаре.

Во время пребывания в стационаре за каждой роженицей  закрепляется врач, наблюдающий ее до момента выписки, и медсестры.

Процесс родов  подлежит специальному учету: регистрируется начало и окончание родов, фиксируется ход родов. После родов каждый ребенок получает специальную бирку, по которой он будет идентифицироваться в первые дни своей жизни. В регистрационной книге сохраняется информация о точном времени рождения ребенка, его имени, росте и весе.

2. Проектирование базы данных

Как известно, целью  проектирования базы данных (БД) является получение эффективной БД. Структура БД должна быть гибкой и адаптивной, алгоритмы обработки должны быть эффективными.

Структура БД зависит  от того, что мы собираемся делать с  данными, характеризующими предметную область.

Процесс разработки структуры  базы данных в соответствии с требованиями пользователей называется проектированием базы данных. Поэтому перед проектировщиком базы данных (администратором базы данных) возникают следующие вопросы:

1) что представляют собой  требования пользователей и в  какой форме они могут быть  выражены;  

2) как эти требования  могут быть преобразованы в  эффективную структуру базы данных;

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

При проектировании базы данных можно пользоваться широко известными методами проектирования программного обеспечения, а именно, методом нисходящего проектирования с последовательными итерациями.

Информационные требования пользователей удобно разделять  на информацию, формирующую концептуальное структурное представление, и информацию, формирующую концептуальное прикладное представление.

Информация, отнесенная к  концептуальному структурному представлению (ISP - information structure perspective), описывает естественные концептуальные связи всех данных в базе данных. Она не связана ни с конкретным способом обработки, ни с конкретным приложением. ISP-информация отображает образы реального мира в сущности и атрибуты (свойства сущности), а взаимосвязи между образами реального мира – в связи между элементами данных.

Информация, отнесенная к  концептуальному прикладному представлению (UP - usage perspective), определяет требования организации к обработке данных. Эта информация описывает (в отличие от естественных концептуальных связей и данных) данные и связи, используемые в приложениях.

Между этими двумя  представлениями существует значительное пересечение. Используемые в приложениях элементы данных, входящие в состав UP-информации, представляют собой соответствующее подмножество элементов данных, содержащихся в ISP-информации, при условии, что набор ISP-информации является полным и согласованным.

Каждый из этих наборов требований воздействует на результаты проектирования в разных направлениях: ISP обеспечивает гибкость и адаптивность, а UP - эффективность.

 

1. Объекты предметной области

Определим объект как «нечто, о чем мы хотим хранить  информацию».

Тогда для нашей  задачи можно определить объекты Младенец, Мать, Врач, Медсестра, Роды. Между объектами существуют связи или отношения, объединяющие их друг с другом. Связи между объектами могут рассматриваться как объекты. Объект Роды связывает объекты Младенец, Мать, Врач и Медсестра.

Обоснование выделения  родов как объекта состоит в следующем.

Если нужно  иметь полный список врачей, медсестер, детей или консультантов, то его можно получить из объекта Консультант. Если же такого объекта нет, то получить список консультантов можно из объекта Заказ. Но, во-первых, это не так просто, как из объекта Консультант, а во-вторых, может быть, не все консультанты есть в объекте Заказ.

То же самое  относится к клиентам. Если объекта Клиент нет, то получить список клиентов можно только из объекта Заказ.

 

2. Построение ER-модели

Структуру базы данных (БД) представим, используя терминологию модели высокого уровня – ER–модели (Entity – Relationship сущность – связь). ER–модель – это средство представления схемы предметной области, не зависящей от СУБД.

Базовыми структурами  в ER-модели являются типы сущностей  и типы связей. Структура базы данных, соответствующая ER-модели, может быть изображена в форме ER-диаграммы (ERD).

Множество сущностей  представляется в ERD помеченным прямоугольником. Множества связей изображается в ERD помеченным ромбом. Множества сущностей, которые участвуют во множестве связей, присоединяются к последнему дугами. В ER-модели связи могут быть N-арными, взаимно однозначными, функциональными или относящиеся к типу "многие-ко-многим".

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

На рис. 1.1 показана ERD – диаграмма ER–модели ПО.

ER – модель  позволяет определить структуру  БД в терминах объектов задачи: Клиент, Консультант, Товар, Заказ.

В терминологии ER – модели Клиент, Консультант, Товар, Заказ являются сущностями (E – entity). Сущность представляет собой основное содержание явления или процесса, о котором необходимо собрать и хранить информацию.

 

 

 

 

 

 

 

 

 

Рис. 1.1 ERD – диаграмма модели ПО

 

3. Реляционная модель

Модель данных определяет правила, в соответствии с которыми структурируются данные. Структуризация данных определяется разнообразием и количеством типов объектов модели данных, ограничениями на структуру данных.

Реляционная модель данных базируется на отношениях и их представлении в виде таблиц. Единственным средством структуризации данных в реляционной модели является отношение (Relation). Отношения обладают всеми свойствами множеств. Важнейшим свойством языков данных реляционной модели является возможность определять новые отношения, основываясь на существующих отношениях.

В терминологии реляционной модели объекты предметной области представляются отношениями (таблицами). Объекты Клиент, Консультант, Товар, Заказ характеризуют предметную область, то есть имеют отношение к предметной области. Отношение Заказ связывает отношения Товар и Консультант. Связь означает, что «много» Консультантов заказывают один и тот же товар и «много» товаров заказываются одним и тем же консультантом.

Отношение Консультант связано с отношением Клиент. Связь означает, что у одного и того же консультанта может быть несколько клиентов, число которых может увеличиваться.

Отношение отображается таблицей, каждая строка которой представляет кортеж. Столбцы таблицы называют атрибутами. Количество столбцов таблицы равно степени отношения, а число строк (кортежей) – его мощности.

Единственными отношениями, допустимыми в реляционной модели, являются те, которые удовлетворяют  следующему условию: «Каждое значение в отношении, то есть значение каждого атрибута в каждом кортеже, является атомарным (неделимым)». Отношение, удовлетворяющее этому условию, называется нормализованным.

Из того факта, что отношение есть множество, следует, что никакие два кортежа не совпадают и что упорядоченность  кортежей несущественна. Это ограничение  приводит к понятию ключа отношения.

Ключ отношения – это атрибут или набор атрибутов, однозначно идентифицирующих кортеж в отношении.

Таблица (отношение) может иметь и несколько ключей, называемых  
возможными ключами. Для того чтобы исключить тривиальные ключи, потребуем, чтобы ключ обладал следующими двумя свойствами: однозначностью идентификации и неизбыточностью (никакое подмножество атрибутов ключа не обладает свойством однозначности идентификации).

Один из возможных  ключей выбирается в качестве первичного ключа отношения. Ни одно из значений первичного ключа не может быть нулевым.

В отношении Клиент в качестве ключа можно использовать атрибут «ФИО» – это естественный ключ, так как связан непосредственно с семантикой предметной области.

Но можно в  качестве ключа использовать номер  строки (идентификатор строки) – тогда такой ключ называется искусственным ключом.

Для отношения Клиент введем искусственный ключ «номер клиента», для отношения Консультант – искусственный ключ «номер консультанта». Тогда отношение Заказ в качестве первичного ключа будет иметь набор атрибутов: «номер клиента», «номер консультанта», то есть составной ключ.

Введение ключа  приводит к уменьшению избыточности данных в отношении Заказ.

Аналогично для  отношения Товар введем искусственный ключ «номер товара». Тогда в отношении Заказ вместо названия заказанного товара будем использовать «номер товара», что приводит к уменьшению избыточности данных в отношении Заказ. Если бы отношения Товар не было, то его следовало бы создать с целью уменьшения избыточности данных в отношении Заказ.

Е.Кодд первоначально  определил три уровня нормализации, которые он назвал первой, второй и  третьей нормальными формами. Нормализованное отношение всегда находится в первой нормальной форме (1НФ).

Отношение, даже если оно находится в 1НФ, может  все же обладать некоторыми нежелательными свойствами.

Отношения Клиент, Консультант и Товар находятся во 2НФ, так как эти отношения находятся в 1НФ и атрибут «ФИО клиента» функционально полно зависит от первичного ключа «номер клиента», атрибут «название товара» функционально полно зависит от первичного ключа «номер товара» и атрибут «название Консультанта» функционально полно зависит от первичного ключа «номер консультанта».

Отношения Клиент, Консультант и Товар находятся в 3НФ, так как они находятся во 2НФ и неключевой атрибут в каждом отношении нетранзитивно зависит от первичного ключа.

Отношение Заказ  находится во 2НФ, так как оно находится в 1НФ и атрибут «количество товара» функционально полно зависит от первичного ключа «номер консультанта», «номер клиента» (составного ключа). Отношение Заказ находится в 3НФ, так как атрибут «сумма» нетранзитивно зависит от первичного ключа.

Уровень нормализации отношения определяется семантикой данных. Перед тем, как сделать  заключение, находится ли отношение  в 3НФ, необходимо знать содержание данных, то есть имеющиеся зависимости между данными. Выявление функциональных зависимостей является существенной частью понимания семантики данных.

 

3. Проектирование информационной системы

База данных –  это совокупность отношений (таблиц), характеризующих предметную область. Схему базы данных можно рассматривать как совокупность типов данных, определяемых отношениями. Ограничения, определенные в схеме, могут использоваться для контроля данных того или иного типа.

Схема отношения (таблицы) задается именем таблицы и  именем соответствующих атрибутов. Каждому отношению и его атрибутам (свойствам) поставим в соответствие имена латинскими буквами.

Таблица 1.1 Отношение Консультант – таблица Consul

Атрибут	Комментарий
n_consul	Номер консультанта – ключевой атрибут
fio	ФИО консультанта

 

Таблица 1.2 Отношение Клиент – таблица Client

Атрибут	Комментарий
n_cl	Номер клиента – ключевой атрибут
fio_cl	ФИО клиента
n_consul	Номер консультанта