Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Концепция баз данных уже давно стала определяющим фактором при создании эффективных систем автоматизированной обработки информации. Важнейшим компонентом концепции должна быть единая методология проектирования баз данных. Это объясняется не только тем, что проектирование новых баз данных представляет собой длительный и трудоемкий процесс, но и тем, что, будучи информационной моделью части непрерывно меняющегося реального мира, базы данных также должны меняться, чтобы адекватно отражать действительность. В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных, CASE-систем автоматизации проектирования и других.
Целью курсовой работы является закрепление теоретических знаний и практическое использование принципов и методологий проектирования, а также машинная разработка системы управления базой данных.
В процессе выполнения курсовой работы необходимо охватить основные этапы проектирования баз данных:
Требования к курсовой работе:
3.1) вставка данных;
3.2) редактирование данных;
3.3) удаление данных;
3.4) просмотр содержимого каждой из таблиц;
3.5) осуществление простого и сложного поиска данных на основе запросов, построенных с помощью языка SQL;
3.6) построение отчетов.
При оценке курсового проекта особое внимание уделяется поисковым функциям и функциям построения отчетов. В каждой из таблиц должен выполняться простой поиск – по одному или нескольким полям и условиям, вводимым пользователем. Количество сложных запросов должно быть не менее пяти: запрос должен включать несколько полей из нескольких таблиц (более двух) и должен включать условия, вводимые пользователем с клавиатуры (динамические запросы).
Документация курсовой работы включает:
1) Введение – краткое описание предметной области;
2) Формулирование и анализ требований (информационная схема, схема задач, ISP и UP-информация);
3) Концептуальное проектирование (несколько вариантов концептуальных схем с анализом выбора рабочей схемы);
4) Переход к реляционной модели данных (определение первичных и внешних ключей в отношениях);
5) Анализ отношений на 1, 2, 3-ю нормальные формы (пропись функциональных зависимостей и проверка на соответствие определениям 1, 2, 3-ей нормальных форм);
6) Конечная схема отношений со связями;
7) Выбор языка реализации СУБД-приложения;
8) Скрипт SQL-запросов (двух простых и четырех сложных).
Пример выполнения курсовой работы
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
Министерство образования и науки Российской Федерации
Государственное образовательное учреждение высшего профессионального образования
«Волгоградский государственный технический университет»
Кафедра «Вычислительная техника»
Курсовая работа
по курсу «Базы данных»
«Разработка СУБД « Т Е М А»»
Выполнил ст. гр. №№- ФИО
Проверил ст. преподаватель Приходькова И.В.
Волгоград, 2012г.
Содержание
1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
В качестве предметной области данной работы была выбрана автоматизация деятельности приемной комиссии средних специальных и высших учебных заведений.
Основными элементами предметной области должны быть: абитуриенты; специальности, на которые они поступают; баллы, получаемые абитуриенты на вступительных экзаменах; льготы поступающих; списки предметов для каждого поступающего в зависимости от того, на какую специальность абитуриент подает документы.
Проектируемое изделие в нормальном режиме работы должно обеспечить обработку не менее 200 заявлений абитуриентов за одну 8-часовую смену с последующим формированием стандартных отчетов.
2 ФОРМУЛИРОВАНИЕ И АНАЛИЗ ТРЕБОВАНИЙ
2.1 Информационная схема процесса приема документов и проведения экзаменов
Дает понятие об основных процессах, реализуемых в предметной области в действительности. Информационная схема к данной предметной области приведена на рисунке 1.
Рисунок 1 Информационная схема процесса проведения приемной кампании
2.2 Схема задач
В зависимости от сложности предметной области схем задач может быть несколько. В рассматриваемом случае автоматизации подлежит прием документов, проведение экзаменов, прием абитуриента в учебное заведение, если он имеет проходной балл. Изображаем эту последовательность действий более глубоко по сравнению с информационной схемой с помощью схемы задач (рис.2).
Рисунок 2 Схема производственных задач приемной комиссии
2.3 ISP и UP – информация
Данные, полученные на этапе формулирования и анализа требований удобно разделить на ISP и UP-информацию.
Описание ISP-информации (сущности, атрибуты и связи) и UP-информации (процессы и операторы) представим в виде таблиц.
Таблица 1 - Описание сущностей
|
№ п/п |
Наименование |
Мощность |
|
1 |
АБИТУРИЕНТ |
1000 |
|
2 |
СПЕЦИАЛЬНОСТЬ |
9 |
|
3 |
ЛЬГОТА |
50 |
|
4 |
ПРЕДМЕТ |
10 |
|
5 |
БАЛЛЫ |
10000 |
|
6 |
ГРУППА |
50 |
|
7 |
ФОРМА |
1000 |
Таблица 2 - Описание атрибутов сущности АБИТУРИЕНТ
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
Фамилия |
Текст |
30 |
А-Я |
1 |
1 |
|
Имя |
Текст |
15 |
А-Я |
1 |
1 |
|
Отчество |
Текст |
30 |
А-Я |
1 |
1 |
|
Адрес |
Текст |
30 |
А-Я, 0-9 |
1 |
0 |
|
Документ об образовании |
Текст |
50 |
А-Я, 0-9 |
1 |
0 |
|
Дата рождения |
Числовой |
10 |
1-31.1-12.1985-20.. |
1 |
1 |
|
Место работы |
Текст |
50 |
А-Я |
0 |
1 |
|
Номер договора |
Числовой |
10 |
0-9 |
0 |
0 |
|
Взнос |
Числовой |
10 |
0-9 |
0 |
1 |
|
Форма договора |
Текст |
30 |
А-Я |
0 |
1 |
Таблица 3 - Описание атрибутов сущности СПЕЦИАЛЬНОСТЬ
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
Название |
Текст |
50 |
А-Я |
1 |
0 |
|
Шифр |
Числовой |
6 |
0-9 |
1 |
0 |
|
Примечания |
Текст |
50 |
А-Я |
1 |
0 |
Таблица 4 - Описание атрибутов сущности ЛЬГОТЫ
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
Название |
Текст |
50 |
А-Я |
1 |
0 |
|
Шифр |
Числовой |
6 |
0-9 |
1 |
0 |
Таблица 5 - Описание атрибутов сущности ПРЕДМЕТЫ
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
Название |
Текст |
20 |
А-Я |
1 |
0.95 |
|
Шифр |
Текст |
10 |
А-Я,0-999 |
1 |
0.95 |
Таблица 6 - Описание атрибутов сущности БАЛЛЫ
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
ФИО абитуриента |
Текст |
60 |
А-Я |
1 |
1 |
|
Шифр предмета |
Текст |
6 |
0-9 |
1 |
1 |
|
Балл |
Числовой |
3 |
0-100 |
1 |
1 |
Таблица 7 - Описание атрибутов сущности ГРУППЫ
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
Шифр |
Текст |
10 |
А-Я,0-999 |
1 |
1 |
|
Количество студентов в группе |
Числовой |
2 |
15-25 |
1 |
1 |
Таблица 8 - Описание атрибутов сущности ФОРМА
|
Наименование |
Тип |
Длина |
Диапазон значений |
Вероятность существования |
Коэффициент повторения |
|
Название формы |
Текст |
20 |
А-Я |
1 |
0 |
|
Шифр формы |
Числовой |
6 |
0-9 |
1 |
0 |
Таблица 9 - Описание связей
|
Наименование |
Связываемые объекты |
Мощность |
Отображение |
Вероятность существования |
Тип связи |
|
Включает |
Абитуриент, Группа |
2000 |
1:n |
1 |
m:n |
|
Получает |
Абитуриент, Баллы |
2000 |
1:n |
1 |
1:n |
|
Имеет |
Абитуриент, Льготы |
50000 |
1:n |
0 |
m:n |
|
Оценивается |
Предмет, Баллы |
2000 |
1:1 |
1 |
1:n |
|
Определяет |
Группа, Специальность |
20 |
1:1 |
1 |
n:1 |
|
Характеризуется |
Специальность, Форма обучения |
20 |
1:n |
1 |
m:n |
|
Определяет |
Специальность, Предмет |
20 |
1:n |
1 |
m:n |
Таблица 10 - Содержание UP- информации
|
Процессы: |
Оператор |
|
|
1. |
Прием документов |
- поиск; - добавление |
|
2. |
Анализ конкурентоспособности абитуриента |
- поиск; - добавление. |
|
3. |
Предложение специальности-замены |
- поиск; - добавление. |
|
4. |
Сдача экзамена |
-поиск; -добавление. |
|
Наименование |
Прием документов |
|
Частота применения |
Ежедневно |
|
Вероятность применения |
1.0 |
Продолжение таблицы 11
|
Приоритет |
Высший |
|
Необходимые данные |
Абитуриент, Льгота,Форма обучения, Специальность |
|
Объем данных |
1000 |
|
Операция |
Поиск |
Добавление |
|
Критерий поиска |
Фамилия, Имя, Отчество |
Шифр, Фамилия, Имя, Отчество, Все основные данные |
|
Количество поисковых образов |
Все |
- |
|
Вероятность события |
0.9 |
0.9 |
|
Вероятность использования поискового образа |
0.95 |
- |
|
Наименование |
Анализ конкурентоспособности абитуриента |
|
Частота применения |
По окончании экзаменов |
|
Вероятность применения |
1.0 |
|
Приоритет |
Высший |
|
Необходимые данные |
Баллы, Абитуриент, Специальность |
|
Объем данных |
1000 |
Таблица 14 - Описание операторов процесса «Анализ конкурентоспособности абитуриента»
|
Операция |
Поиск |
Добавление |
|
Критерий поиска |
Шифр абитуриента |
Отметка о зачислении |
|
Количество поисковых образов |
Все |
Все |
|
Вероятность события |
0.9 |
0.9 |
|
Вероятность использования поискового образа |
0.95 |
0.95 |
|
Наименование |
Предложение специальности-замены |
|
Частота применения |
По окончании экзаменов |
|
Вероятность применения |
0.6 |
|
Приоритет |
Средний |
|
Необходимые данные |
Абитуриент, Балл, специальность |
|
Объем данных |
1000 |
|
Операция |
Поиск |
Добавление |
|
Критерий поиска |
Шифр-абитуриента, Баллы экзаменов, Название специальности |
Данные абитуриента |
|
Количество поисковых образов |
Все |
Все |
|
Вероятность события |
0.9 |
0.9 |
|
Вероятность использования поискового образа |
0.95 |
0.95 |
|
Наименование |
Сдача экзамена |
|
Частота применения |
Ежедневно |
|
Вероятность применения |
1.0 |
|
Приоритет |
Высший |
|
Необходимые данные |
Абитуриент, Предмет, Группа |
|
Объем данных |
1000 |
|
Операция |
Поиск |
Добавление |
|
Критерий поиска |
Шифр абитуриента, Шифр группы |
Шифр предмета, Балл |
|
Количество поисковых образов |
Все |
Все |
|
Вероятность события |
0.9 |
0.9 |
|
Вероятность использования поискового образа |
0.95 |
0.95 |
3. Концептуальная схема
Данные, полученные на предыдущем этапе, используются для концептуального анализа системы.
Для разрабатываемой базы данных мною было спроектировано два варианта концептуальной схемы (см. рисунки 3, 4).
Рисунок 3 - Первый вариант концептуальной схемы системы
Анализ первого варианта показывает, что недостатком указанной схемы является наличие цикла (кольца). Кольцо возникает из-за сложных связей между сущностями. Избежать этого недостатка позволяет процесс нормализации, который будет изложен ниже.
Рисунок 4 - Второй вариант концептуальной схемы системы
Недостатком второго варианта является также наличие двух колец, а также то, что абитуриент включается в группу, выбирая специальность и напрямую. Таким образом, наличие такой связи, с одной стороны, накладывает определенные ограничения на работу системы, а с другой стороны, становится лишним. Поэтому данный вариант концептуальной схемы нежелателен.
Следовательно, наилучшим вариантом концептуальной схемы из предложенных является первый, представленный на рисунке 2.2. Примем его за основу при переходе к схеме отношений БД.
4 Переход к реляционной модели данных
Абитуриент (Шифр абитуриента*, Фамилия, Имя, Отчество, Дата рождения, Адрес, Документ об образовании, Место работы, Сумма договора при бюджетной форме, Сумма договора при коммерческой форме, Дата заключения договора на коммерческое обучение, Форма договора);
Формы обучения (Шифр формы обучения*, Название формы обучения).
Специальность (Шифр специальности*, Название специальности, Примечание).
Льготы (Шифр льготы*, Название льготы, Порядок установления).
Группа (Рабочий шифр абитуриента*, Шифр абитуриента, Шифр специальности);
FK= Шифр абитуриента – ссылается на Абитуриента;
FK= Шифр специальности – ссылается на специальность.
Баллы (Рабочий шифр абитуриента+Шифр предмета*, Балл);
FK=Рабочий шифр абитуриента-ссылается на Группу;
FK= Шифр предмета – ссылается на Предмет).
Для установления связей многие-ко-многим необходимо образовать стыковочные таблицы между Абитуриентом и Льготами, Специальностью и Предметами, Специальностью и Формами обучения:
ОПРЕДЕЛЕНИЕ ЛЬГОТ(Шифр абитуриента+Шифр льготы*);
FK= Шифр абитуриента – ссылается на Абитуриента;
FK= Шифр льготы – ссылается на Льготы.
СПЕЦИАЛЬНОСТЬ-ПРЕДМЕТ(Шифр специальности+Шифр предмета*);
FK= Шифр специальности – ссылается на Специальность;
FK=Шифр предмета – ссылается на Предмет.
СПЕЦИАЛЬНОСТЬ-ФОРМА ОБУЧЕНИЯ (Рабочий шифр специальности*, Шифр специальности, Шифр формы обучения, Коммер/Бюджет);
FK=Шифр специальности –ссылается на специальность;
FK= Шифр формы обучения – ссылается на Формы обучения.
5 Функциональные зависимости и проверка на нормальные формы
Проведем анализ получившихся отношений с помощью функциональных зависимостей:
АБИТУРИЕНТ
Шифр абитуриента -> {Фамилия, Имя, Отчество, Дата рождения, Адрес, Документ об образовании, Шифр формы обучения, Форма договора, Место работы, Шифр группы};
{Шифр абитуриента, Форма договора (бюд.)} -> Сумма договора при бюджетной форме;
{Шифр абитуриента, Форма договора (ком.)} -> {Сумма договора при коммерческой форме, Дата заключения договора на коммерческое обучение, Номер договора};
Очевидно, что вышеуказанные поля зависят от составных ключей (причем по булевому условию), следовательно, происходит нарушение второй нормальной формы – часть полей зависит от составного ключа, другие поля – только от части первичного ключа. Поэтому необходимо декомпозировать отношение Абитуриент на три проекции по функциональным зависимостям.
Также для устранения повторяющихся данных по полю Место работы нужно выделить Место работы в отдельный справочник: Шифр работы -> Название места работы.
СПЕЦИАЛЬНОСТЬ
Шифр специальности -> {Название специальности, Примечание}
Формы обучения
Шифр формы обучения -> Название формы обучения.
Льготы
Шифр льготы -> {Название льготы, Порядок установления}
Группа
Рабочий шифр абитуриента -> {Шифр абитуриента, Шифр специальности}
В указанных отношениях первичные ключи простые. Поэтому отношения автоматически находятся во второй нормальной форме.
БАЛЛЫ
{Рабочий шифр абитуриента+Шифр предмета} -> Балл
В данном отношении вторая нормальная форма не нарушается.
Во всех полученных отношения отсутствуют функциональные зависимости неключевых атрибутов между собой. Следовательно, они находятся в третьей нормальной форме.
Итак, конечная схема отношений после проведения декомпозиции будет выглядеть следующим образом: (рис. 5).
6 SQL-запросов
Далее необходимо привести SQL- скрипты шести запросов (на проведение поиска или построение отчетов, каскадное удаление и т.п.).
Рисунок 5 – Схема отношений БД приемной комиссии
Приложение
Министерство образования и науки Российской Федерации
Волгоградский государственный технический университет
Кафедра «Вычислительная техника»
док. тех. наук Ю.П. Муха
СЕКРЕТАРЯ ПРИЕМНОЙ КОМИССИИ
Техническое задание
ЛИСТ УТВЕРЖДЕНИЯ
Приходькова И.В.________
Исполнитель
Студент гр.
ФИО ________________
2012
УТВЕРЖДЕН
АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО
СЕКРЕТАРЯ ПРИЕМНОЙ КОМИССИИ
Техническое задание
ЛИСТОВ 14
СОДЕРЖАНИЕ
1 Общие сведения 5
1.1 Наименование разрабатываемой системы 5
1.2 Область применения 5
2 Основание для создания системы 5
2.1 Документ, на основании которого ведется разработка 5
2.2 Организация, утвердившая документ, и дата его утверждения 5
2.3 Наименование темы разработки 5
3 Название и цели создания системы 6
4 Требования к системе 7
4.1 Требования к функциональным характеристикам 7
4.1.1 Состав выполняемых функций 7
4.1.2 Организация входных и выходных данных 8
4.1.3 Временные и характеристики 8
4.2 Требования к надежности 8
4.2.1 Требования к надежному функционированию 8
4.2.2 Контроль входной и выходной информации 9
4.2.3 Время восстановления после отказа 9
4.3 Условия эксплуатации 10
4.4 Требования к составу и параметрам технических средств 10
4.5 Требования к информационной и программной совместимости 11
4.5.1 Требования к информационным структурам на входе 11
4.5.2 Требования к информационным структурам на выходе 11
4.5.3 Требования к методам решения 11
4.5.4 Требования к языкам программирования 12
4.5.5 Требования к программным средствам, используемым программой
12 5 Требования к программной документации 13
6 Технико-экономические показатели 13
7 Стадии и этапы разработки 13
8 Порядок контроля и приемки 13
Разработке подлежит система по автоматизации рабочего места секретаря приемной комиссии. В дальнейшем будем использовать краткое название – Comiss.
1.2 Область применения
Разработанная программа может применяться как модуль автоматизации работы секретаря приемной комиссии в колледжах, училищах и т.п.
2 Основание для создания системы
2.1 Документ, на основании которого ведется разработка
Разработка ведется на основании задания, выданного старшим преподавателем каф. ВТ ВолгГТУ Приходьковой И.В.
2.2 Организация, утвердившая этот документ, и дата его утверждения
Утверждено на заседании каф. ВТ __.__.____
2.3 Наименование темы разработки
Наименование темы разработки «Автоматизированное рабочее место секретаря приемной комиссии». Разработка ведется в целях упрощения труда секретаря приемной комиссии и увеличения скорости его работы.
3 Назначение и цели создания системы
Данная система предназначена для автоматизации работы приемных комиссий в процессе конкурсного отбора абитуриентов средних и высших учебных заведений.
Проектируемое изделие в нормальном режиме работы должно обеспечить обработку не менее 200 заявлений абитуриентов за одну 8-часовую смену с последующим формированием стандартных отчетов, позволяющих:
Программа предназначена для:
1) хранения данных об абитуриентах (Фамилия, Имя, Отчество, Адрес, Дата рождения, Документ об образовании, Место работы, Сумма договора при бюджетной форме, Номер договора, Сумма договора при коммерческой форме, Дата заключения договора на коммерческое обучение, Форма договора, Место работы);
2) хранения данных о формах обучения (Название формы обучения, Шифр формы обучения);
3) хранения данных о специальностях (Шифр специальности, Название специальности, Примечание);
4) хранения данных о льготах (Шифр, Название льготы);
5) хранения данных о группах (Шифр, Количество студентов в группе);
6) хранения данных о предметах (Шифр предмета, Название);
7) хранения данных о баллах(ФИО абитуриента, Шифр предмета, Балл );
8) программа должна обеспечить помимо хранения ввод, просмотр, редактирование перечисленной выше информации;
9) выполнять все указанные в п.4.1.1.
4.1 Требования к функциональным характеристикам
4.1.1 Состав выполняемых функций
Основной функцией программы должно быть хранение и обработка информации об абитуриентах, специальностях, формах обучения, льготах, баллах, предметах, группах, а также выполнять следующие функции:
4.1.2 Организация входных и выходных данных
Входными данными программы являются новые данные, вводимые пользователем в базу данных.
Выходными данными программы являются данные, хранимые в БД.
4.1.3 Временные характеристики
Программное изделие должно обеспечивать в режиме ввода обработку не менее 200 заявлений абитуриентов за 8-часовую рабочую смену при средней скорости ввода информации 100 символов/мин.
В режиме генерации отчетов изделие должно выдавать отчет на экран монитора в течении 1-5 минут (в зависимости от сложности отчета) с момента подачи запроса пользователем при среднем количестве абитуриентов равном 1500 чел.
Время вывода сгенерированного отчета на бумажный носитель должно составлять не менее 5 стр. формата А4 в минуту
Объем занимаемой оперативной памяти не должен превышать 640Кбайт.
Программное изделие должно занимать не более 1 Mb дискового пространства без учета пространства, необходимого для хранения данных и сопутствующих программ внешних производителей.
4.2.1 Требования к надежному функционированию
Программное изделие должно обеспечивать бесперебойную работу приемной комиссии при условии выполнения правил эксплуатации. Стандартные отчеты должны обеспечивать контроль соответствия введенной информации с бумажными носителями.
4.2.2 Контроль входной и выходной информации
Программа должна контролировать строки, вводимые пользователем. Контроль выходной информации в процессе работы должен осуществляться путем анализа изменение строки ввода и остальной информации, отображаемой в формах программы.
4.2.3 Время восстановления после отказа
Время восстановления после сбоя должно состоять из времени перезапуска пользователем операционной системы и программного приложения (при условии наличия установочного комплекта изделия и архивной копии введенной информации по состоянию на предыдущий рабочий день).
Носители информации должны храниться в соответствии с условиями эксплуатации, предъявляемых производителями того или иного типа носителей.
Установочный комплект изделия должен храниться на диске CD-ROM в специально отведенном для этого месте и содержать все необходимые компоненты для восстановления работоспособности программного изделия.
Помимо этого для восстановления исходных данных, обрабатываемых программным изделием в процессе эксплуатации, создаются архивные копии информации, хранящиеся на внешних носителях информации.
Для эксплуатации программного изделия необходимо выполнять 3 вида обслуживания : установка программного изделия, архивирование введенной информации, восстановление работоспособности изделия.
Установка программного изделия должна производиться при помощи установочного комплекта однократно при организации автоматизированного рабочего места члена приемной комиссии. Повторная установка должна производится при возникновении нештатной ситуации, при которой нарушается работоспособность изделия.
Архивирование введенной информации должно производится средствами изделия с целью сокращения времени восстановления после сбоя.
Восстановление работоспособности изделия производится при возникновении сбоя работы. Восстановление работоспособности должно состоять из следующих этапов:
-повторная установка изделия;
-проверка работоспособности изделия при помощи анализа стандартных отчетов и их сверки с бумажными носителями;
-при возникновении повторной ошибки должно производится восстановление введенной информации с последней архивной копии с последующей сверкой стандартных отчетов с бумажными носителями и добавлением информации введенной с момента создания архивной копии и до момента возникновения нештатной ситуации.
Для эксплуатации программного изделия необходимы:
- ПЭВМ типа IBM/AT с процессором Intel 800 МГц;
- стандартная клавиатура 101/102;
- манипулятор типа мышь;
- ОЗУ в объем, обеспечивающем нормальное функционирование ОС;
- НЖМД со свободным местом не менее 50 Мb;
- монитор VGA;
-принтер лазерный HP 1100.
Входные данные вводятся в программное изделие при помощи консоли оператора. При восстановлении с архивной копии данные вводятся посредством замены поврежденных информационных файлов резервными копиями. Внутри изделия данные должны храниться в виде файлов баз данных формата Paradox 7.0 .
4.5.2 Требования к информационным структурам на выходе
Выходная информация изделия должна состоять из стандартных отчетов, выводимых как на консоль оператора так и на принтер. Создание архивных копий введенной информации должно производится автоматически по запросу оператора путем копирования информационных файлов на указанный оператором носитель.
Методы решения должны обеспечить выполнение всех этапов проектирования программы в соответствии с их порядком и сроками выполнения, указанными в разделе 6 данного документа.
Реализации программного изделия должна производится при помощи Borland Delphi 6.0. с использованием стандартных компонент.
Реализация запросов к базе данных в процессе работы изделия должна производиться при помощи языка запросов SQL.
Программное изделие должно эксплуатироваться под управлением операционных системы MS Windows-9x , Windows 2000, Windows Nt, Windows XP .
Доступ программного изделия к информационным файлам должно осуществляться через Borland Database Engine 6.0.
Программное изделие должно поставляется на носителе CD-ROM в пластиковой упаковке. Маркировка изделия должна наноситься как на носитель так и на и упаковку. Маркировка носителя должна состоять из логотипа изделия, полного наименования изделия с указанием версии. Маркировка упаковки должна содержать логотип изделия, полное наименование изделия с указанием версии программного продукта, краткую инструкцию по установке и восстановлению работоспособности изделия.
В состав программной документации необходимо включить следующие документы:
1) Пояснительная записка, отражающая все этапы работы над курсовым проектом;
Ориентировочная экономическая эффективность 10000рублей…..
Предполагаемая годовая потребность 10экземпляров
1) разработка и утверждение технического задания – 2 недели;
2) исследование предметной области поставленной задачи, изучение теоретических основ баз данных – 4 недель;
3) проектирование базы данных – 6 недель;
4) разработка и написание пояснительной записки – 2 недели.
Этап проектирования базы данных разбивается на следующие подэтапы:
Испытания работоспособности и быстродействия программного изделия должно производиться:
Изделие считается годным к эксплуатации при прохождении тестовых примеров и выполнении всех пунктов технического задания, с учетом ранее согласованных изменений к нему.
По результатам испытаний составляется акт приемо-сдаточных работ в котором (при наличии) указывается несоответствий программного обеспечения техническому заданию. Несоответствия программного изделия, обнаруженные в процессе устраняются разработчиком.