ВВЕДЕНИЕ
1. АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1Обзор предметной области
2.1 Моделирование проектируемой БД
2.1Разработка технического задания
2. КОНСТРУКТОРСКАЯ ЧАСТЬ
1.2Нормализация структуры БД
2.2Разработка таблиц БД
3.2 Конструирование визуальных форм
4.2 Разработка запросов
5.2Разработка отчетов
6.2 Разработка кнопочной формы
3. ЭКСПЕРИМЕНТАЛЬНО-ПРИКЛАДНАЯ ЧАСТЬ
3.1Тестирование системы
3.2 Руководство пользователя
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
ВВЕДЕНИЕ
Курсовая работа посвящена анализу проектирования баз данных, а также
освещению методов построения форм и отчетов на примере построения
программы ведения электронной документации учебного заведения.
Одной из составных задач можно рассматривать проблему составления
расписания учебного процесса, а так же оперативную корректировку
расписания при возникновении необходимости в этом.
О своевременности и актуальности рассматриваемой проблемы говорит
тот факт, что большую часть своего времени администраторы заведений и
преподаватели тратят на оформление различной документации и отчетов. Базы
данных (БД) составляют в настоящее время основу компьютерного обеспечения
информационных процессов, входящих практически во все сферы человеческой
деятельности.
В настоящее время среди разработчиков базы данных (БД) большой
популярностью пользуется реляционная СУБД ACCESS, входящая в состав
пакета Microsoft Office 2010. Дружественный интерфейс и простота настройки,
эффективные средства создания таблиц, форм, запросов, интеграция с другими
приложениями пакета, средства организации работы с базами данных и защита
информации - вот далеко не полный перечень достоинств этого приложения.
Основные функции СУБД - это описание структуры базы данных,
обработка данных и управление данными.
База данных - это совокупность сведений о реальных объектах, процессах,
событиях или явлениях, относящихся к определённой теме или задаче,
организованная таким образом, чтобы обеспечить удобное представление этой
совокупности, как в целом, так и любой её части. Реляционная база данных
представляет собой множество взаимосвязанных таблиц, каждая из которых
содержит информацию об объектах определённого типа. Каждая строка
таблицы содержит данные об одном объекте (например, клиенте, автомобиле,
документе), а столбцы таблицы содержат различные характеристики этих
объектов - атрибуты (например, наименования и адреса клиентов, марки и цены
автомобилей). Строки таблицы называются записями, все записи имеют
одинаковую структуру - они состоят из полей, в которых хранятся атрибуты
объекта. Каждое поле в записи содержит одну характеристику объекта и имеет
строго определённый тип данных (например, текстовая строка, число, дата). Все
записи имеют одни и те же поля, только в них содержатся разные значения
атрибутов.
АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1 Обзор предметной области
Предметная область - это часть реального мира, данные о которой мы
хотим отразить в базе данных. В качестве предметной области в данной
курсовой работе используется Университет. Предметная область бесконечна и
содержит как существенно важные понятия и данные, так и малозначащие или
вообще не значащие данные. Так, в предметной области Университет, понятия
«Преподаватель», «Лекция», «Дисциплина», «Учебники» являются существенно
важными, а понятие «Зарплата преподавателей»- менее важной. Однако, с точки
зрения отделал кадров эти данные являются существенно важными. Таким
образом, важность данных зависит от выбора предметной области.
Для исследования данной предметной области и построения
инфологической модели, в общем, был использован материал о специфике
работы подобных учреждений, а так же, в частности, материал об должностях и
ученых степенях преподавателей ВУЗов, материал о структуре и особенностях
работы ВУЗов.
2.1 Моделирование проектируемой БД
Модель предметной области - это наши знания о предметной области.
Знаний могут быть как в виде неформальных знаний в мозгу эксперта,так и
выражены формально при помощи каких-либо средств. В качестве таких
средств могут выступать текстовые описания предметной области, наборы
должностных инструкций, правила ведения дел в компании и т.п. Опыт
показывает, что текстовый способ представления модели предметной области
крайне неэффективен. Гораздо более информативным и полезным при
разработке баз данных являются описания предметной области, выполненные
при помощи специализированных графических нотаций. Имеется большое
количество методик описания предметной области. Модель предметной области
описывает скорее процессы, происходящие в предметной области и данные,
используемые этими процессами. От того, насколько правильно смоделирована
предметная область, зависит успех дальнейшей разработки приложений.
3.1 Разработка технического задания
НАЗНАЧЕНИЕ РАЗРАБОТКИ
Данная разработка предназначена для хранения и использования
информации по предметной области Университет. С помощью данной
разработки можно составлять расписание лекций, рассчитывать число лекций за
год, вести учет доходов преподавателей, а так же вносить и изменять все
необходимые данные, используемые в данной предметной области.
КОНСТРУКТОРСКАЯ ЧАСТЬ
1.2 Нормализация структуры БД
После того, как построена инфологическая модель, наступает этап
нормализации структуры БД, суть которой заключается в составлении схемы
таблиц с указанными связями. Для того чтобы связи между таблицами работали
надежно и по записи из одной таблицы можно было однозначно найти записи в
другой таблице, надо предусмотреть уникальные поля. Уникальное поле - это
поле, значения в котором не могут повторяться.
Для указания уникального поля используется понятие ключевого поля.
При создании структуры таблиц одно поле (или одну комбинацию полей).
Можно назначить ключевым. С ключевыми полями компьютер работает особо.
Он проверят их уникальность. Ключевое поле - очевидный кандидат для
создания связей. Иногда ключевое поле называют первичным ключевым.
Как правило, уникальное поле создают искусственно. Для этого нужно
первым свойством каждой сущности указать номер отдельного экземпляра по
порядку. Это поле должно иметь тип Счетчик. Ввести два одинаковых значения
в такое поле нельзя по определению, поскольку приращение значения поля
производится автоматически. Связь между таблицами будет вестись в
дальнейшем именно по этому полю.
Нормализация представляет собой построение так называемой
концептуальной модели БД, которое сводится к представлению инфологической
модели в терминах выбранной СУБД (в данном случае Access). Концептуальная
модель имеет вид, немного отличающийся от инфологической, но строится на
основе инфологической.
2.2 Разработка таблиц БД
Следующим шагом в создании БД является разработка таблиц и
дальнейшая работа над ними непосредственно уже в самой программе (данная
операция называется построением физической модели БД).
Объектами физической модели является таблицы и поля с типами данных
определёнными для выбранной СУБД.
Системы управления базами данных (СУБД) - это программные средства,
с помощью которых можно создавать базы данных, наполнять их и работать с
ними. В мире существует немало различных систем управления базами данных.
Одна из самых популярных - находящаяся в составе пакета Microsoft Office
система управления базами данных Access.
С организационной точки зрения в работе с любой базой данных есть два
разных режима: проектировочный и эксплуатационный (пользовательский).
Создатель базы имеет право создавать в ней новые объекты (например,
таблицы), задавать их структуру, меняться свойства полей, устанавливать
необходимые связи. Он работает со структурой базы и имеет полный доступ к
базе. У одной базы может быть один, два или несколько разработчиков.
Пользователь базы - это лицо, которое наполняет её информацией с
помощью форм, обрабатывает данные с помощью запросов и получает
результат в виде результирующих таблиц или отчетов. У одной базы могут быть
миллионы пользователей и, конечно, доступ к структуре базы для них закрыт.
И так для создания таблиц воспользуемся конструктором таблиц.
Проанализируем ход построения на основе таблицы «Преподаватель».
Вносим в поле «имя поля» названия полей, а в поле «тип данных» тип
данных в соответствии с выбранными характеристиками (к примеру: если поле
«ФИО», то тип данных - текстовый). Следует учесть, что первым полем должно
быть ключевое поле «код преподавателя», тип данных этого поля Счетчик.
Чтобы это поле стало ключевым, нужно во вкладке «конструктор» нажать на
значок ключа, под которым написано «ключевое поле». Далее поля вводятся по
смыслу. (Следует учесть, что поле «Сумма» в таблице «Заработная плата»
имеет тип данных «числовой», это нужно для того, чтобы в дальнейшем
произвести расчеты при составлении запросов).
Экспериментально-прикладная часть
1.3 Тестирование системы
Для тестирования системы приведем два примера:
В качестве первого примера для тестирования системы попробуем
изменить данные в форме Заработная плата, в поле Сумма (данное поле
является числовым). Результаты тестирования приведены в следующей таблице.
Таблица 3.1
Тестирование системы на примере формы Актер
Этапы Проверка в Проверка в Проверка в
тестирования нормальных экстремальных исключительны
Описание условиях условиях х ситуациях
тестового примера
Перечень Система должна Система должна Система
требований к нормально отреагировать и должна
системе отреагировать, откорректировать предупредить
данные должны данные. пользователя об
измениться во ошибке.
всех разделах,
где они были
применены
ранее.
Перечень данных Изменяем Вводим данные: Вводим в
вводимых данные с 11310 а) добавим буквы данное поле:
пользователем на 17 в Номер состава $256
б)0,524655252
Описание ошибок Ошибок при При вводе При нажатии
при вводе данных вводе данных данных, мы не «сохранить»
и реакции нет, если сможем система
системой на них запустить запрос сохранить незамедлительн
на обновление, данные о сообщает об
то ошибка изменения, нам ошибке:
высветиться сразу Введенное
высвечивают значение не
ошибку о том, подходит для
что введенное данного поля.
значение не Так же система
подходит для приводит ряд
данного поля.. возможных
ошибок (см.
Рис.3.1.)
Таблица 3.2
Тестирование системы на примере Запроса с параметром
Этапы Проверка в Проверка в Проверка в
тестирования нормальных экстремальных исключительных
Описание условиях условиях ситуациях
Тестового
примера
Перечень Система должна Система Система должна
требований к нормально должна предупредить
системе отреагировать на отреагировать пользователя об
ввод данных и найти на ошибке.
информацию несоответствие.
Перечень Вводим в Вводим Введем
данных появившемся окне Возраст в буквенное
вводимых Введите сумму : следующем значение.
пользователем «10000» формате:
10000,00
Описание Ошибок нет. Ошибок нет. Система
ошибок при Появляется Система сообщает об
вводе данных и соответствующий выводит ошибке.
реакции список актеров нужную
системой на них таблицу.