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

частей:

• Титульный лист;

• 2 Введение;

а) цель;

б) задачи;

• Раздел 1. Описание предметной области;

1.1 Описание организационной структуры предприятия;

1.2 Описание бизнес-процессов предприятия

1.3 Описание схемы информационных потоков

• Раздел 2 Проектирование аис

2.1 Разработка ТЗ проектирования АИС;

2.2 Физическая модель БД;

1. Интерфейс;

2. Печатные формы;

3. Таблицы

4. Запросы

5. формы

6. Схема данных

2.3 Обеспечение АИС

2.3.1 Техническое обеспечение

2.3.2 Программное обеспечение

2.4 Руководство по установке и настройке АИС

2.5 руководство для пользователя при эксплуатации АИС

• Заключение;

• Библиографический список.

Выше перечисленные части курсового проекта должны располагаться

именно в том порядке, в котором они расположены в списке.

2. Требование к оформлению введения

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

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

Как правило, после формулировки цели осуществляется ее декомпозиция на задачи (обычно 2-3), решение которых позволяет ее достичь. Например: провести системный анализ предметной области; физическую модель базы данных и т.д.

В данном разделе пояснительной записки студент должен дать подробную характеристику предметной области, как минимум

В этом описании он должен подробно описать:

- предметную область;

- используемое в работе ПО;

- требования, предъявляемые пользователями к ПО.

Студент должен учесть следующие требования, предъявляемые пользователями к ПО:

- требования к интерфейсу, интерфейс должен быть эргономичным и обладать достаточной функциональностью;

- требования к отчетам информационной системы;

- требования к печатным формам.

На основе системного анализа требований предъявляемых пользователями ПО к разрабатываемой информационной системе студентом производится выбор необходимых инструментов для создания программного приложения и выбор наиболее оптимальной СУБД.

3. Требование к оформлению физической модели бд

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

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

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

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

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

Каждая строка таблицы соответствует полю. Назначения столбцов:

- Fields Name - имя поля;

- Type - тип поля;

- Size - размер поля (для строковых полей, поскольку иные поля

подразумевают размер, определяемый типом поля);

- Key - содержит звездочку '*', если поле входит в состав первичного ключа. Если в первичный ключ входит несколько полей, они должны определяться в той последовательности, в которой они присутствуют в первичном ключе. Кроме того, все поля, входящие в состав первичного индекса, должны определяться перед иными

полями, то есть быть в списка полей наверху.

Описание физической модели БД следует так же приводить в виде

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

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

Рис. 9 – Физическая модель данных

После описания физической модели студенту необходимо привести

список наиболее характерных запросов выполняемых приложением БД

и список индексов используемых в БД для улучшения производительности

этих запросов.