Разработка базы данных для АСУ «Компьютерные курсы»

В модели O2 поддерживается множественное  наследование классов на основе отношения  супертип/подтип. В подклассе допускается  добавление и/или переопределение  атрибутов и методов. Возможные  при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.

Поддерживается предопределенный класс "Оbject", являющийся корнем решетки классов; любой другой класс является неявным наследником класса "Object" и наследует предопределенные методы ("is_same", "is_value_equal" и т.д.).

Специфической особенностью модели O2 является возможность объявления дополнительных "исключительных" атрибутов и методов для именованных объектов. Это означает, что конкретный именованный объект-представитель класса может обладать типом, являющимся подтипом типа класса. Конечно, с такими атрибутами не работают стандартные методы класса, но специально для именованного объекта могут быть определены дополнительные (или переопределены стандартные) методы, для которых дополнительные атрибуты уже доступны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному объекту, а к имени, за которым в разные моменты времени могут стоять вообще говоря разные объекты. Для реализации исключительных атрибутов и методов требуется развитие техники позднего связывания.

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 Нормализованная база данных

Выводы

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

Далее в ходе обоснования выбора модели данных описаны существующие модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), указаны их достоинства и недостатки, и сделан выбор в пользу реляционной модели.

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

 

 

 

Глава III. Программная реализация

В данной главе проведен анализ и  выбрана СУБД, в которой осуществлено физическое проектирование базы данных. Также указаны особенности разработки представлений, форм и отчетов, методы реализации ограничений и способы обеспечения безопасности информации, хранимой в базе данных. В конце главы приведены выводы.

3.1. Анализ и выбор  СУБД

Для программной реализации информационной системы выбрана СУБД Microsoft SQL Server 2005 Express Edition. Эта СУБД бесплатна для некоммерческого использования, имеет все средства для разработки реляционной базы данных, использует язык Transact-SQL, поддерживает проверочные ограничения(constraints), представления, процедуры и триггера. Данная СУБД более подробно описана в разделе 1.2.

Для отображения отчетов и форм написана программа на языке  C# на платформе .NET Framework 3.5, используя технологию LINQ для доступа к базе данных Microsoft SQL Server.

C# - объектно-ориентированный язык программирования. Разработан в 1998 – 2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как основной язык разработки приложений для платформы Microsoft .NET. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нем можно создавать и компилировать даже без инструментальных средств, вроде Visual Studio.

C# относиться к семье языков с С-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов(в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщенные типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

LINQ(Language Integrated Query) – проект Microsoft по добавлению синтаксиса языка запросов, напоминающего SQL, в языки программирования платформы .NET Framework.

Изначально поддерживая механизм запросов для коллекций объектов в памяти, реляционных баз данных и данных в формате XML, LINQ обладает расширяемой архитектурой, которая позволяет сторонним разработчикам реализовать доступ к их хранилищам данных через механизм LINQ. Для этого необходимо реализовать стандартные операторы запросов, используя методы расширения, или реализовать интерфейс IQueryable, позволяющий разбирать дерево выражения во время выполнения, транслируя его в свой язык запросов.

3.2. Физическое проектирование  базы данных в СУБД.

При физическом проектировании базы данных созданы следующие таблицы:

• Преподаватель
• Направление
• Студент
• Группа
• Аудитория
• Преп_Ауд – сущность связка между Преподаватель и Аудитория.

 

 

Схема разработанной в СУБД базы данных приведена на рисунке 6.

Рис.6 Схема базы данных в СУБД  Microsoft SQL Server

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

• AddTeacher – добавляет нового преподавателя в таблицу Преподаватель;
• AddStudent – добавляет нового студента в таблицу Студент;

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

• TriggerPrepClass – вводит ограничение на преподавателей, которые могут вести только один предмет у одной группы;
• TriggerGroupCabinet – вводит ограничение на зачисление в группу большего кол-ва человек, чем вмещает аудитория, которая числится за преподавателем;
• TriggerZaved – вводит ограничение на кол-во заведующих в учебном заведении;

3.3. Разработка представлений

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

• PrepView – отображает информацию о преподавателях:
• ФИО – полное имя преподавателя;
• Должность – название должности, занимаемое преподавателем;
• Аудитория – номер аудитории закрепленный за данным преподавателем;
• Возраст – текущий возраст преподавателя;
• Адрес – домашний адрес преподавателя;
• Кол-во групп (вычисляется из подзапроса) – количество групп, у которых преподаватель ведет занятия;
• Оклад – зарплата преподавателя;
• Стаж – стаж данного преподавателя;
• StudentView – отображение информацию о студентах:
• ФИО – полное имя студента;
• Адрес – домашний адрес студента;
• Возраст – текущий возраст студента;
• Дата зачисления – дата зачисления студента;
• Группа – номер группы, в которой числится студент;
• ClassView – отображает информацию об учебном процессе:
• ФИО преподавателя – полное имя преподавателя;
• Группа – номер группы, у которой преподает данный преподаватель;
• Предмет – название предмета;