База данных станции технического обслуживания автомобилей

Реферат

Пояснительная записка к исследовательской работе: 22 стр., 30 рис.

Объект исследования — база данных станции технического обслуживания автомобилей.

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

В процессе разработки использовались следующие программные средства: WindowsXP, Access 2003.

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

СОДЕРЖАНИЕ

Введение

1 Описание предметной области

2 Моделирование структур данных

2.1 Разработка концептуальной модели базы данных

2.2 Разработка логической модели данных

2.3 Разработка модели «сущность – связь»

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

3.1 Преобразование модели «сущность-связь» в реляционную модель данных

3.2 Физическое проектирование таблиц базы данных

3.3 Разработка запросов к базе данных

3.4 Разработка отчетов

4 Проектирование управляющей программы

4.1 Разработка форм для ввода данных

4.2 Разработка интерфейса пользователя

4.3 Разработка средств администрирования базы данных

Выводы

Перечень ссылок

ВВЕДЕНИЕ

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

В БД должны храниться сведения о владельцах автомобилей: ФИО, адрес, марка автомобиля, № госрегистрации; характеристики автомобилей: год выпуска, изготовитель, перечень устраненных неисправностей; ФИО работника станции и время устранения каждой неисправности. Возможно введение в БД сведения о новых владельцах и новых неисправностей.

Диспетчеру могут потребоваться следующие сведения:

– ФИО и адрес владельца автомобиля с данным номером госрегистрации,

– изготовитель, марка и год выпуска автомобиля данного владельца,

– перечень устраненных неисправностей у автомобиля данного владельца,

– ФИО работника станции, устранявшего данную неисправность автомобиля данного владельца, и время устранения,

– какие автомобили ремонтировал данный работник станции,

– ФИО владельцев автомобилей с указанной неисправностью.

Диспетчер может вносить следующие изменения:

– добавить информацию о владельце ремонтируемого автомобиля,

– удалить информацию о работнике станции,

– изменить номер госрегистрации автомобиля.

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

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

1 Описание предметной области

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

Администратору базы данных «СТО» может понадобиться информация о неисправностях, владельцах, работниках, а также время ремонта неисправности и отчет о работе СТО.

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

1. Предоставление большой совокупности информации в виде таблиц базы данных

2. Формирование различных запросов по:

· неисправности (описание и время устранения),

· работники (ФИО, личный номер),

· владельцы (адрес, ФИО, паспортные данные)

· обслуживаемые автомобили (№ госрегистрации, марка, модель и год его выпуска).

3. Вывод информации в виде отчетов

В связи с постоянным перемещением ОС, их обновлением, модернизацией, ремонтом и ликвидацией к СУБД, осуществляющей аналитический учет ОС предъявляются следующие требования:

- к информации, содержащейся в базах данных: значимость, полнота, достоверность, понятность, эффективность;

- к самой реляционной базе данных: целостность данных, отсутствие дублирования, отсутствие связей типа «многие-ко-многим», отсутствие рекурсивных связей, связей с атрибутами, множественных атрибутов;

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

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

В результате создания и внедрения АСУ получим следующие источники эффективности:

- снижение времени при внесения новых данных и изменения старых, а, следовательно, повышение производительности труда;

- быстрое и полное получение необходимой информации.

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

Для функционирования СУБД «Учет ОС» необходима операционная система Windows 98 или последующие ее версии со стандартным приложением.

Работа производиться с базами данных, созданных в приложении Microsoft Access, которое является частью пакета Microsoft Office 2003. Для СУБД никакого дополнительного программного обеспечения не требуется, так как программа работает автономно.

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

2 моделирование структур данных

2.1 Разработка концептуальной модели базы данных

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

Из описания предметной области извлечем все типы сущностей:

Владельцы

Автомобили

Ремонтные работы

Работники

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

Будем использовать ключ с минимальным набором атрибутов

Использовать следует тот ключ, вероятность изменения значений которого минимальна.

Значение ключа должно иметь минимальную длину.

С выбранным ключом пользователю будет удобнее работать.

Ниже представлены рисунки таблиц с ключами.

Владельцы

Рисунок 1

Автомобили

Рисунок 2

Ремонтные работы

Рисунок 3

Работники

Рисунок 4

Разработанная концептуальная модель.

Рисунок 5

2.2 Разработка логической модели данных

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

- связи типа «многие-ко-многим»;

- рекурсивные связи;

- связи с атрибутами.

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

Логическая модель базы данных

Рисунок 6

2.3 Разработка модели «сущность – связь»

Основными понятиями модели «сущность- связь» являются:

- сущность;

- связь;

- атрибуты.

Сильные сущности имеют только одно ключевое поле, а слабые – столько же, сколько и связей. Исходя из вышесказанного, выделим у имеющихся сущностей ключевые поля.

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

3.1 Преобразование модели «сущность-связь» в реляционную

модель данных

Преобразование модели «сущность-связь» в реляционную модель данных осуществляется путем последовательного выполнения ряда шагов:

- каждой сущности ставится в соответствие отношение реляционной модели данных;

- каждый атрибут сущности становится атрибутом соответствующего отношения;

- первичный ключ сущности становится первичным ключом соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом.

3.2 Физическое проектирование таблиц базы данных

В качестве СУБД предполагается использовать MicrosoftAccess. На клиентских машинах используется операционная система MicrosoftWindowsXP, а также офисные средства этой же фирмы (MicrosoftOffice 2003).

Физическое проектирование заключается в создании БД в среде конкретной СУБД.

Разработка производится последовательно:

- создаются таблицы БД;

Рисунок 7

Рисунок 8

Рисунок 9

Рисунок 10

- вводятся необходимые ограничения;

- определяются ключевые поля;

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

Рисунок 11

- обеспечиваются условия целостности данных.

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

3.3 Разработка запросов к базе данных

Запросы обеспечивают простой доступ к определенному подмножеству полей и записей.

Рисунок 12

Запросы в базе данных формируются на основании информации представленной в описании предметной области. Запросы записываются в виде выражений SQL.

Рисунок 13

Рисунок 14

Рисунок 15

Рисунок 16

Рисунок 17

3.4 Разработка отчетов

Рисунок 18

Рисунок 20

Рисунок 21

Рисунок 22

Рисунок 23

4 Проектирование управляющей программы

4.1 Разработка форм для ввода данных

Формы для ввода данных

Рисунок 24

Рисунок 25

Рисунок 26

Рисунок 27

Рисунок 28

Рисунок 29

4.2 Разработка интерфейса пользователя

В части интерактивного общения с пользователем СУБД отвечает следующим требованиям:

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

- должен быть обеспечен удобный, простой windows-совместимый интерфейс, интуитивно понятный для пользователя, который знает свою предметную область и не является специалистом в области информационных технологий; интерфейс должен быть оптимизирован для выполнения типовых и часто используемых прикладных операций. Внешний вид форм должен быть спроектирован в соответствии с требованиями, разработанными фирмой Microsoft.

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

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

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

Интерфейс главной формы

Рисунок 30

4.3 Разработка средств администрирования базы данных

Доступ к базе данных разграничен на пользователей «Admin», «User», «Woker».

Admin (Администратор) – оператор с неограниченным доступом ко всем функциям администрирования и работы с базой данных.

Worker (Работник). Имеет права доступа, позволяющие работать с таблицами БД (чтение, запись, удаление записей, вставка записей). Не имеет прав доступа к административным функциям;

User (Пользователь). Имеет права доступа, позволяющие только просматривать (читать) данные из таблиц БД. Самый низкий уровень доступа.

В режиме работы Worker кнопка «Администрирование» на главной форме не доступна.

В режиме работы User доступны только запросы, отчеты и просмотр таблиц БД.

Администратор имеет право изменять пароль пользователей, добавлять и удалять пользователей.

Выводы

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

Были разработаны концептуальная, логическая модели и модель «сущность-связь» на основе рассмотренной предметной области.

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

На основе полученных моделей была разработана управляющая программа.

ПереченЬ ССЫЛОК

1. Евдокимов В. В. и др. Экономическая информатика. Учебник для вузов/ Под. ред. д. э. н., проф. В. В. Евдокимова. – СПб.: Питер, 1997. – 592 с.

2. Информационные технологии управления: Учебное пособие/ Под ред. Ю.М. Черкасова.– М.: ИНФРА-М, 2001.– 216 с.

3. Козырев А.А. Информационные технологи в экономике и управлении: Учебник. – СПб.: Изд-во Михайлова В.А., 200.– 360 с.

4. Конноли Томас, Бэгг Каролин, Страчан Анна. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. : Пер. с англ.: Уч.пос. – М.: Издательский дом «Вильямс», 2000. – 1120 с.: ил. – Парал. тит. англ.

5. Ситник В.Ф., Краєва О.С. Технологія обробки економічної інформації: Навч. посібник. – К.: КНЕУ, 1998. – 200 с.

6. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем/ Под. ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2001.—512 с.