проектирование информационной системы коипьютерных курсов. Я комп курсы 57 стр. Разработка базы данных для асу "Компьютерные курсы" Курсовая работа Студента 4 курса группы по0701
 Скачать 233.37 Kb.
|
2.3 Логическое проектированиеДля логического проектирования выбрана реляционная модель данных, т.к. она наиболее полно соответствует требованиям, предъявленным к разрабатываемой информационной системе: отсутствие дублируемой информации; поддержание целостности данных при вставке, удалении или изменении записей; возможность организации всех видов связи между отношениями 1: 1, 1: N и M: N. В реляционной базе данных даталогическое проектирование приводит к разработке корректной схемы базы данных, т.е. такой схемы, в которой отсутствуют нежелательные зависимости между атрибутами. При этом можно использовать процесс проектирования с помощью декомпозиции, т.е. последовательно нормализовывать схему отношений, тем самым накладывая ограничения и избавляясь от нежелательных зависимостей между атрибутами. Чтобы перейти к реляционной модели и построить даталогическую модель ИС, каждой сущности из инфологической модели данных поставим в соответствие отношение реляционной модели. В таком случае, каждый атрибут сущности становится атрибутом соответствующего ему отношения. Также укажем каждому атрибуту тип данных и признак обязательности. Обозначим первичные и внешние ключи. После всего проведем нормализацию получившейся модели данных. Приведем список атрибутов для каждого отношения в схеме базы данных: Преподаватель ФИО - varchar (70) NOT NULL (первичный ключ, PK) Адрес - varchar (100) NOT NULL Телефон - int NOT NULL Дата рождения - date NOT NULL Должность - varchar (20) NOT NULL Оклад - int NOT NULL Стаж - int NOT NULL Направление ФИО преподавателя - varchar (70) NOT NULL (внешний ключ, FK) Номер группы - int NOT NULL (внешний ключ, FK) Название предмета - varchar (40) NOT NULL Время начала - int NULL День недели - varchar (15) NULL Студент ФИО - varchar (70) NOT NULL Адрес - varchar (100) NOT NULL Дата рождения - date NULL Телефон - int NOT NULL Номер группы - int NOT NULL (внешний ключ, FK) Срок зачисления - date NOT NULL Срок выпуска - date NULL Группа Номер группы - int NOT NULL (первичный ключ, PK) Кол-во учащихся - int NOT NULL Аудитория ФИО преподавателя - varchar (70) NOT NULL (внешний ключ, FK) Номер аудитории - int NOT NULL Кол-во мест - int NULL Кол-во оборудования - int NULL  Рис. 4 Схема базы данных до нормализации 2.4 Нормализация схемы базы данныхНормальная форма - свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Нормализация - это процесс преобразования базы данных к виду, отвечающему нормальным формам. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации. Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). Таблица находится в первой нормальной форме, если каждый её атрибут атомарен, то есть может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц. Отношение находится во второй нормальной форме (2NF), если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа. Для исходной схемы базы данных, полученной в предыдущем разделе и находящейся в первой нормальной форме, нормализация ко второй нормальной форме не требуется, т.к. в схеме отсутствуют отношения, имеющие составной первичный ключ. Т.е. исходная схема базы данных уже находится во второй нормальной форме. Отношение находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме 2NF и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK). Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. В схеме базы данных разрабатываемой ИС, приведенной ко второй нормальной форме, присутствует транзитивная зависимость между атрибутами в отношении Аудитория: атрибут Номер аудитории зависит от внешнего ключа ФИО преподавателя, а атрибуты Кол-во мест и кол-во оборудования зависят от неключевого атрибута Номер аудитории. Таким образом, нормализацией к третьей нормальной форме в данном случае представляет собой вынесение атрибутов Номер аудитории, кол-во мест и кол-во оборудования в отдельное отношение Аудитория. Отсюда получаем следующие изменения в списке атрибутов: Аудитория Номер аудитории - int NOT NULL (внешний ключ, FK) Кол-во мест - int NULL Кол-во оборудования - int NULL Преп_Ауд ФИО преподавателя - varchar (70) NOT NULL (внешний ключ, FK) Номер аудитория - int NOT NULL (первичный ключ, PK) Результирующее отношение, находящееся в третьей нормальной форме, приведено на рисунке 5.  Рис. 5 Нормализованная база данных |