– определение атрибутов сущностей;

       – приведение модели к требуемому уровню нормальной формы.

       Инфологическая  модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

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

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

       Атрибут – поименованная характеристика сущности [5].

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

       Атрибуты  сущности студенты:

• номер зачетной книжки;
• ФИО студента;
• год рождения
• адрес;
• факультет;
• специальность;
• курс;
• староста.

       Эта сущность отводится для хранения основных сведений о студентах.

Сведения  могут быть как неизменяемые за весь период ведения автоматизированной информационной системы (АИС) (ФИО студента, год рождения, номер зачетной книжки) так и изменяемые (адрес, факультет, специальность и курс). Может возникнуть ситуация совпадения ФИО студентов, поэтому существует необходимость включения атрибута «номер зачетной книжки», который и станет ключом (ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности) в сущности «студенты». Нет необходимости знать этот код для работы с базой данных. Так как он служит только для внутренних целей, то его можно скрыть от пользователей.

       Атрибуты  сущности ведомость:

• номер зачетной книжки;
• семестр;
• дисциплина;
• форма отчетности;
• оценка.

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

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

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

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

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

       Нормализация  выполняется поэтапно. Первые три  шага были описаны доктором Э.Ф. Коддом в статье "Дальнейшая нормализация реляционной модели базы данных" в 1972г [5].

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

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

       Вторая  нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.

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

       Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

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

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

       Разложение  отношений из 4НФ в пятую нормальную форму должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.

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

       3 Выбор СУБД

       Опыт  применения ЭВМ для построения прикладных систем обработки данных показывает, что самым эффективным инструментом здесь являются не универсальные  алгоритмические языки высокого уровня, а специализированные языки  для создания систем управления данными. Такие средства обычно включаются в состав систем управления базами данных (СУБД).

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

       СУБД  имеет следующие компоненты:

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

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

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

       Группа  реляционных СУБД представлена на рынке  программных продуктов очень широко. Это, например, такие системы, как Paradox, R:base, Clarion, Oracl, MS Access, MS Visual FoxPRO.

       Одним из наиболее распространенных программных  продуктов является Oracle.

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

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

       Встраивание в СУБД Oracle JavaVM, полномасштабная  поддержка серверных технологий (Java Server Pages, Java-сервлеты, модули Enterprise JavaBeans, интерфейсы прикладного программирования CORBA), привело к тому, что Oracle на сегодняшний день является стандартом СУБД для Internet.

       Еще одной составляющей успеха СУБД Oracle является то, что она поставляется практически для всех существующих на сегодня операционных систем. Работая под Sun Solaris, Linux, Windows или на другой операционной системе с продуктами Oracle не будет возникать никаких проблем в работе. СУБД Oracle одинаково хорошо работает на любой платформе. Таким образом, компаниям, начинающим работу с продуктами Oracle не приходится менять уже сложившееся сетевое окружение. Существует лишь небольшое количество отличий при работе с СУБД, обусловленных особенностями той или иной операционной системы. В целом же это всегда та же самая безопасная, надежная и удобная СУБД Oracle.

       Последние версии СУБД Oracle значительно проще  в установке и первоначальной настройке. Также возросли возможности по специализированной настройке работы СУБД под конкретную задачу. В результате, и при работе с OLTP-системой, и с хранилищем данных, используя эти возможности по настройке СУБД Oracle, можно достичь впечатляющих результатов [7].

       Не  менее известной является СУБД Access.

       СУБД Access входит в пакет Microsoft Office, что  во многом определяет ее популярность. Сегодня используется третья версия пакета. По сравнению с более ранними версиями изменений произведено очень мало, они практически ограничились введением типа полей OLE и гиперссылками, внедренными в 1996 году во 2 версию. Все остальные изменения Access связаны с изменением базовой ОС Windows, библиотеки которой Access использует, не имея собственных, что делает его СУБД с самым низким быстродействием.

       Разработка  приложения в Access начинается с создания таблиц в режиме конструктора таблиц или путем импорта из электронных таблиц или файлов баз данных. Мастера таблиц создают таблицы по американским стандартам и потому мало применимы. Очень легко создаются поля с возможностью выбора одного данного из предлагаемого списка, т.е. поля подстановки. Для внедрения графики существуют две возможности – поля OLE, хранящие графику непосредственно в базе данных, что увеличивает объем приложения и понижает его быстродействие, и введение гиперссылок на внешние файлы, что затрудняет переносимость приложения, но не влияет на быстродействие.