Организация мониторинга и настройка функционирования системы

Разработка механизмов защиты.

Проектирование физического представления баз данных.

Перенос глобальной логической модели данных в среду целевой СУБД.

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

а) Проектирование основных таблиц с ориентацией на среду целевой СУБД.

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

Необходимо принять решение о способе проектирования таблиц, например, на языке SQL или с помощью конструктора.

Подготовленный проект набора таблиц баз данных должен быть описан в сопроводительной документации.

б) Реализация бизнес-правил предприятия в среде целевой СУБД.

Обновление информации в таблицах может быть ограничено бизнес- правилами, регулирующими ручное выполнение тех операций, которые связаны с проведением обновления данных. В некоторых системах отсутствует поддержка реализации ряда или всех типов бизнес-правил. В этом случае соответствующие действия должны быть реализованы непосредственно в приложениях. Например, существуют реляционные СУБД, которые позволяют реализовывать ограничения по времени, например: “В 17.30 последнего рабочего дня каждого года выполняется архивирование всех строк, относящихся к товарам, проданным в течение этого года, после чего соответствующие записи удаляются”.

Одной из важных целей физического проектирования баз данных является организация эффективного хранения данных.

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

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

5. Проектирование базы данных учебного примера

Постановка задачи

Рассматриваемая предметная область – ВУЗ.

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

Предполагается, что в расписании для каждого экзамена должны содержаться следующие сведения: Группа, Дисциплина, Преподаватель, Должность преподавателя, Дата проведения экзамена, Время начала, Время окончания, Аудитория. Каждая группа сдает несколько экзаменов, каждый преподаватель может принимать несколько экзаменов, по каждому курсу сдается несколько экзаменов.

Определение сущностей, свойств и связей

Входные данные предполагают, что центральным в данном внешнем представлении будет тип сущностей Экзамены.

В первом приближении тип сущностей Экзамены характеризуется такими свойствами

· Группа

· Дисциплина

· Преподаватель

· Должность преподавателя

· Дата проведения

· Время начала

· Время окончания

· Аудитория

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

Замечание1. Поскольку может быть два преподавателя с одинаковыми фамилиями, именами и отчествами, в этом случае их различают по табельному номеру, который однозначно определяет преподавателя, это поле следует объявить ключевым.

Замечание2. Поскольку преподавательможет проводить занятия в нескольких группах, то между двумя полученными типами сущностей возникает связь 1:M.

ER-диаграмма Преподаватель – Расписание представлена на рис. 4.2.

Рис. 13.2. ER-диаграмма Преподаватель - Расписание

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

Поэтому, выделим типы сущностей Группы (со свойствами: Код группы, наименование группы, Форма обучения, Коэффициент углубленности изучения дисциплин), Дисциплины ( со свойствами: Код дисциплины, Наименование дисциплины, Количество часов).

Замечание1. При определении характеристик двух указанных типов сущностей к каждой добавлена характеристика Код, которая однозначно идентифицирует экземпляр сущности и объявляется первичным ключом.

Замечание2. Связь этих сущностей с сущностью Зкзамены будет так же иметь тип 1: М.

И так, первое внешнее представление (учебный отдел) описывается внешней схемой (ER – моделью), представленной на рис. 4.3.

Рис.13.3. ER-модель первого внешнего представления

Дата добавления: 2014-10-31