Автор работы: Пользователь скрыл имя, 12 Декабря 2010 в 23:52, курсовая работа
Целью данной курсовой работы является автоматизация учета информации о рейсах и билетах ж/д вокзала.
Для достижения поставленной цели в работе необходимо решить следующие задачи:
•Изучить теоретические основы разработки приложения для
автоматизации учета информации о рейсах и билетах ж/д вокзала.;
•Смоделировать базу данных;
•Создать приложение базы данных в среде Microsoft Access 2003;
•Протестировать разработанное приложение.
Введение……………………………………………………………………………….4
1. Основные теоретические положения……………………………………………...6
1.1 Базы данных и системы управления базами данных……………………….. 6
1.2 Структурные элементы базы данных………………………………………...7
1.3 Свойства полей базы данных, типы данных…………...................................8
1.4 Объекты базы данных……………………………………………………….10
2. Моделирование баз данных………………………………………………………12
2.1. Виды моделей данных………………………………………………………12
2.2. Концептуальное проектирование…………………………………………..15
2.3. Модель «сущность – связь»..........................................................................15
2.4. Метод нормальных форм……………………………………………………18
3. Создание приложения для автоматизации учета информации о билетах и рейсах ж/д вокзала
3.1. Проектирование базы данных……………………………………...............19
3.2. Создание таблиц базы данных……………………………………………...21
3.3 Создание запросов…………………………………………………………...26
3.4 Создание отчетов базы данных…………………………………………….33
4. Тестирование приложения......................................................................................35
Заключение...................................................................................................................42
Список используемой литературы.............................................................................43
Поскольку в разных полях могут содержаться данные разного типа, то и свойства у полей могут различаться в зависимости от типа данных. Так, например, список вышеуказанных свойств полей относится в основном к полям текстового типа. Поля других типов могут иметь или не иметь эти свойства, но могут добавлять к ним и свои. Например, для данных, представляющих действительные числа, важным свойством является количество знаков после десятичной запятой.[7]
Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.
1.4. Объекты базы данных
Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).
Запросы объекты служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняют такие операции как отбор данных, их сортировку и фильтрацию. С помощью запросов можно выполнять преобразования данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнения таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое.[4]
Если
запросы – это специальные
средства для отбора и анализа
данных, то формы – это средства
для ввода данных. Смысл их тот
же – предоставить пользователю средства
для заполнения только тех полей,
которые ему заполнять
По своим свойствам и структуре отчеты во многом похожи на формы, но предназначены только для вывода данных, причем для вывода не на экран, а на принтер. В связи с этим отчеты отличаются тем, что в них приняты специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных документов.
Страницы – это специальные объекты баз данных, реализованных в последних версиях СУБД Microsoft Access (начиная с Access 2000). Правда, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данной, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, позволяют работать также с базами данных Microsoft SQL Server.[12]
Макросы
и модули предназначены как для автоматизации
повторяющихся операций при работе с СУБД,
так и для создания новых функций путем
программирования. В СУБД Microsoft Access макросы
состоят из последовательности внутренних
команд СУБД и являются одним из средств
автоматизации работы с базой. Модули
создаются средствами внешнего языка
программирования, в данном случае языка
Visual Basic for Applications.
2.Моделирование баз данных
2.1. Виды моделей данных
Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных — совокупность структур данных и операций их обработки.
СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве.[4]
Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевернутое дерево).
К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.[4]
К каждой записи базы данных существует только один (иерархический) путь от корневой записи.
Кроме того, существенным недостатком иерархической и сетевой моделей является то, что структура данных задается на этапе проектирования БД и не может быть изменена при организации доступа к данным. [4]
Реляционная модель получила свое название от английского термина relation (отношение) и была предложена в 1970-х годах сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Разница между таблицей в привычном смысле и понятием отношения заключается в том, что в отношении нет порядка - это неупорядоченное множество записей. Порядок определяется не отношением, а конкретной выборкой из отношения. Связь между таблицами существует на логическом уровне и определяется предметной областью. Практически связь между таблицами устанавливается путем использования логически связанных данных в разных таблицах.
Для работы с реляционными СУБД используется стандартизированный язык структурированных запросов SQL. Достоинствами реляционной модели данных являются простота, гибкость структуры, удобство реализации на компьютере, высокая стандартизованность и использование математического аппарата реляционной алгебры и реляционного исчисления.[10]
К
недостаткам можно отнести
В объектно-реляционной модели отдельные записи база данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.
Выбор объектно-реляционной модели решил бы проблемы с реализацией связей, однако возникли бы неоправданные проблемы с созданием математического представления и выбором СУБД. Принимая во внимание всё вышесказанное, делаем выбор – реляционная модель данных.[1]
Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
-каждый элемент таблицы — один элемент данных;
-все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
-каждый столбец имеет уникальное имя;
-одинаковые строки в таблице отсутствуют;
-порядок следования строк и столбцов может быть произвольным.
Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы — атрибутам отношений, доменам, полям.
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ — ключ второй таблицы.
2.2. Концептуальное проектирование
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема – это сама база данных.[5]
Концептуальное проектирование – сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
По
окончании данного этапа
2.3. Модель «сущность – связь»
Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.
Информация о работе Автоматизация учета информации о билетах и рейсах ж/д вокзала