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

1.1. Анализ предметной области БД. (Приложение 1.)

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

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

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

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

- на основе описания предметной области выявить документы и их атрибуты, подлежащие хранению в базе данных;

- определить функциональную зависимость между атрибутами;

- выбрать все зависимые атрибуты и указать для каждого все его ключевые атрибуты, т.е. те от которых он зависит;

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

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

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

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

1.2. Проектирование физической  и логической моделей БД. (Приложение 2, 3.)

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

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

Разработка базы данных.

2.1. Обоснование выбора СУБД.

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

2.2. Представление логической модели БД в выбранной СУБД. Заполнение таблиц данными.

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

2.3. Разработка запросов, отчетов, форм и макросов. (Приложение 4.)

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

3.2. Разработка интерфейса пользователя. (Приложение 4.)

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

3.3. Организация парольной защиты

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

 

 

 ЗАЩИТА КУРСОВОГО ПРОЕКТА

 

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

Для защиты студенту отводится 10 минут на изложение содержания работы; в процессе защиты преподаватель высказывает свои замечания.

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

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