Размещено на http://www.allbest.ru/

16

• Содержание
• Введение

1. Постановка задачи

1.1 Описание базы данных

1.2 Создание базы данных при помощи языка SQL

2. Создание Базы дынных в форме таблиц

Заключение

Список используемых литератур

• Введение

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

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

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

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

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

Таким образом, для достижения цели данного проекта была проделана работа следующего содержания:

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

- обоснование выбора SQL - в этом разделе курсового проекта описан универсальный язык для создания, модификации и управления данными в реляционных базах данных;

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

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

- представления - в этом разделе курсового проекта описано создание шаблонов вывода информации, построенных на запросах к базе данных;

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

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

ER-модель, или ER-диаграмма (Entity - Relation; в русском переводе - модель «объект - отношение» или «сущность - связь») предназначена для формализованного описания предметной области на этапе концептуального проектирования базы данных. Модель представляет собой графическое описание предметной области с использованием стандартизированного набора обозначений. На основе ER-модели по определенным правилам строится логическая модель для реализации в конкретной СУБД.

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

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

Правила перевода из логической модели данных в физическую следующие:

*объекты становятся таблицами в физической базе данных

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

*уникальные идентификаторы становятся колонками, не допускающими значение NULL. В физической базе данных они называются первичными ключами (primary key).

1. Постановка задачи

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

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

ER-модель, или ER-диаграмма (Entity - Relation; в русском переводе - модель «объект - отношение» или «сущность - связь») предназначена для формализованного описания предметной области на этапе концептуального проектирования базы данных. Модель представляет собой графическое описание предметной области с использованием стандартизированного набора обозначений. На основе ER-модели по определенным правилам строится логическая модель для реализации в конкретной СУБД.

Модель «сущность - связь» относится к семантическим моделям. ER-модели используется для повышения эффективности и точности проектирования баз данных. Основными понятиями ER-модели являются сущность, связь и атрибут.

Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа.

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

Основные элементы, входящие в состав ER-моделей:

- сущности (объекты) предметной области;

- связи между объектами;

- атрибуты (свойства) объектов.

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

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

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

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

Правила перевода из логической модели данных в физическую следующие:

*объекты становятся таблицами в физической базе данных

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

*уникальные идентификаторы становятся колонками, не допускающими значение NULL. В физической базе данных они называются первичными ключами (primary key).

1.1 Описание базы данных

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

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

Диспетчеру в оперативном порядке подчиняются все работающие на постах ТО и ремонта автомобилей, а в отсутствие начальника производства на работе ему подчиняется весь коллектив производства. При принятии решений по управлению производством диспетчер учитывает: общий объем работ, который необходимо выполнить, какие автомобили нуждаются в обслуживании и ремонте в первую очередь, содержание ремонта по каждому автомобилю, наличие производственного персонала и запасных частей и агрегатов, состояние технологического оборудования, время выхода автомобилей на линию и др. Если при выполнении обслуживания или ремонта рабочий обнаруживает необходимость выполнения такой работы, которая не записана в листке учета, он сообщает об этом своему руководителю или диспетчеру производства, выполняет работу, и ее записывают в листок.

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

1.2 Создание базы данных при помощи языка SQL

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

Объекты физической базы данных создаются с помощью языка описания данных SQL (команды DDL). CREATE TABLE используется для первоначального создания объекта базы данных.

Запрос на создание таблицы Договор

CREATE TABLE Договор (

КодДоговора Autoincrement Constraint ДоговорыPK PRIMARY KEY,

КодСпециалиста Long Not Null Constraint СпециалистыFK

REFERENCES Специалисты (КодСпециалиста),

КодКлиента Long Not Null Constraint КлиентыFK

REFERENCES Клиенты (КодКлиента),

ДатаРемонта DateTime,

ВремяРемонта Text,

СтоимостьРемонта Currency,

ВидНеисправности Text

Из этой инструкции следует следующее описание структуры таблицы:

- КодДоговора - Отражает код текущего договора. Данное поле является первичным ключом;

- КодСпециалиста - тип Long. Это поле в которое вводится кодспециалиста;

- КодКлиента - тип Long. Поле, в которое вводится кодКлиента в договоре.

- ДатаРемонта - тип DateTime. Здесь необходимо поставить дату заключения договора.

- ВремяРемонта - тип Text. Необходимо указать время необходимое для ремонта неисправности.

- СтоимостьРемонта - тип Currency. Поле для введения стоимости ремонта.

- ВидНеисправности - тип Text. Оставляются данные о виде неисправности.

Запрос на создание таблицы Клиенты

CREATE TABLE Клиенты (

КодКлиента AUTOINCREMENT Constraint КлиентыPK PRIMARY KEY,

ФамилияК Text Not Null,

ИмяК Text Not Null,

ОтчествоК Text Not Null,

Телефон Integer,

Адрес Text,

ПаспортныеДанные Integer Not Null

Из этой инструкции следует следующее описание структуры таблицы:

- КодКлиента. Поле, в которое вводится кодКлиента в договоре. Данное поле является первичным ключом;

- ФамилияК - тип Text. Указывается фамилия нового клиента.

- ИмяК - тип Text. Указывается Имя нового клиента.

- ОтчествоК - тип Text. Указывается Отчество нового клиента.

- Телефон - тип Integer. Указывается телефон клиента.

- Адрес - тип Text. Указывается место проживание клиента.

- ПаспортныеДанные - тип Integer. Указываются паспортные данные.

Запрос на создание таблицы Рабочии

CREATE TABLE Рабочии (

КодСпециалиста AUTOINCREMENT Constraint РабочииPK PRIMARY KEY,

Фамилия Text Not Null,

Имя Text Not Null,

Отчество Text Not Null,

Квалификация Text,

ВремяРаботы DateTime

Отсюда следует описание структуры таблицы:

- КодРАбочии. Поле, в которое вводится кодспециалиста в договоре. Данное поле является первичным ключом;

- Фамилия - тип Text. Указывается фамилия Рабочии.

- Имя - тип Text. Указывается Имя Специалиста.

- Отчество - тип Text. Указывается Отчество Рабочии.

- Квалификация - тип Text. Указывается квалификация специалиста.

- Адрес - тип Text. Указывается место проживание клиента.

- ВремяРаботы- тип DateTime. Указываются время начало работы того или иного Рабочии.

Запрос на создание таблицы Ремонта

CREATE TABLE Ремонт (

КодРемонта Autoincrement Constraint РемонтPK PRIMARY KEY,

КодДоговора Long Not Null Constraint ДоговорFK

REFERENCES Договор (КодДоговора)

Название Text,

ПредварительнаяСтоимость Currency

Отсюда следует описание структуры таблицы:

- КодРемонта. Поле, в которое вводится номер ремонта. Данное поле является первичным ключом;

- Название - тип Text. Указывается название компонентов.

- ПредварительнаяСтоимость - тип Currency. Указывается стоимость на используемые компоненты.

Запрос на создание таблицы Израсходованные запчасти:

CREATE TABLE ИзрасходованныеЗапчасти (

КодИзрасходованныхЗапчастей Autoincrement Constraint ДеталиPK PRIMARY KEY,

КодДоговора Long Not Null Constraint ДоговорыFK

REFERENCES Договор (КодДоговора),

Детали Text

Отсюда следует описание структуры таблицы:

- КодИзрасходованныхЗапчастей. Поле, в которое вводится номера компонентов. Данное поле является первичным ключом;

- КодДоговора. Указывается код Договора, в котором необходимо использовать запчасти.

- Детали - тип Text. Список запчастей в данном договоре.

Создание запросов

Выполним запрос Информация о договорах:

SELECT Фамилия, КодДоговора, ДатаРемонта, ВремяРемонта, СтоимостьРемонта

FROM Специалисты INNER JOIN Договор ON Специалисты.КодСпециалиста=Договор.КодСпециалиста;

Выполним запрос на Поиск Клиентов по ФИО:

SELECT *

FROM Клиенты

WHERE ФамилияК=[введите фамилию] AND ИмяК=[введите имя] AND ОтчествоК=[введите отчество];

Выполним запрос на Информацию о специалистах :

SELECT КодСпециалиста, Фамилия, Имя, Отчество, ВремяРаботы, Квалификация

FROM Специалисты;

Выполним запрос на Информацию о стоимости запчастей

SELECT *

FROM Ремонт;

Основная задача РНР-языка - интерпретация сценариев (программ) для генерации web-страниц, отсылаемых программе-клиенту (браузеру). Сценарий (скрипт) может содержать как РНР-, так и HTML-код. HTML-код пересылается в литеральном представлении, а РНР- код выполняется, и клиенту отсылается результат его работы. Таким образом, пользователь никогда не видит РНР- кода. Для полноценной работы с РНР необходимо кроме самого языка ещё и web-сервер. В качестве web-сервера можно использовать Apache. Данный интернет-магазин реализуем с использованием языка гипертекстовой разметки html, языка программирования php и СУБД MySQL. Главная часть функционирования сайта - работа с базой данных. Листинг базы данных пишется в Текстовом редакторе Блокнот и сохраняется под именем SHEMA. реляционный база данный шаблон

2. Создание Базы дынных в форме таблиц

База данных ремонт машин в таксопарках с названиями таблиц

При создание этих полей мне понадобилось 6 полей каторые должны заполнятся с нужными информациями. И которые содержашие специальные информации каторые играюшии важную роль при дальнейшем использование этого Базы данныха. Каждая поля содержит своеобразные информациию к примеру мы можем видеть поля Мастерская оно содержит в себе своё “ID” , местоположение , данные о рабочих , данные о запчасти. И большенство остальных отделов присоединяюся именно с мастерской так оно подчиняются к этому автосервису.

В данном таблице существует 5 полей которые содержат своеобразные специфики такие как “ID” , “ Name” , “Mestopolojenie” , “Rabochiy_ID” , “Zapchasti_ID”. Тут для “ID” дано ключ PRIMARY KEY так как оно не будет повторятся так как оно уникальное.

Мы тут можем видеть особенные информации о наших полях.

Таблица “Машины” содержит 2 поля но, она могла б содержить более поля.

В 1ом поле указано машина модели “nexia” во 2ом поле указано машина модели “matiz” и они имееют непосредственно сових “ID” 1 для машины нексия и для мишны матиза 2. Машины содержат своих номеров каторые определяют их , номер нексии 123, номер матиза 321. И конечно же машины имеют модели, модель нексии “ nexia dons” модель матиза “ matiz best



Тут все информация показано досканально.

Таблица «Рабочие»

Данная таблица дает нам информации об рабочем составе мастерского

В катором работают две работники . Тут мы можем видет о них некоторые информации , такие как “ID” , имя работника “name” и тип его работы к примеру моторист или ходовик и т.д эти данные мы можем видет в поле “Tip”. Рабочие связаны с мастерской через их “ID” при приеме заказа изучается проблемы машины и направляются к рабочим этого мастерского. К примеру машине нужен облсуживание моториста его направляют к мотористу или машине нужен обслуживание ходовых то его направляют к ходовику так как они с этими и занимаютсяю.



В этом окошечке мы можем видет информации о наших полях.

Таблица «Шаферы»

Таблица «Шаферы» содержит 2 поля так как у нас пока есть только две водителя. Они имеют свои “ID” чтобы принимать работу. И они связаны с кассой чтобы получить зарплату, они связаны между собой через “ID” .

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

Таблица «Запчасти»

Табляца запчасти содержит в себе два поля и они имееют своих специфики. Поля имеем соих “ID” , “name” , “Vid” в таблице name мы видим название запчастей один из них Motornie zapchasti вторая Xodoviee zapchasti у нас есть два вида запчастей так как пока мы в нашем сервисном центре имеем два мастеров. В поле Vid мы можем разлчать запчастей они делятся на 2 вида первый Krupnie вторая Melkie крупные запчасти относятся к моторными запчастями а Melkie запчасти относятся к хововым запчастьям

В этой табличке мы можем видеть краткое информацие о нашем таблице.



В таблице кассы сушествует 2 поля в которых написано суммы обслуживание В первом мы можем видеть определенную сумму для обслуги моториста а во втором мы можем видеть сумму за которую выполнил ховодик . И оно соеденено с шаферами по ихнем “ID”.

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

Схема связей

Связь между таблицами

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

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

Для начала, движок таблиц должен быть InnoDB. Только он поддерживает внешние ключи (foreign key). Если у вас таблицы MyISAM, почитайте как их конвертировать в InnoDB.

Для того, чтобы связать таблицы по полям, необходимо сначала добавить в индекс связываемые поля:

В phpmyadmin выбираем таблицу, выбираем режим структуры, выделяем поле, для которого будем делать внешнюю связь и кликаем Индекс.

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

Заключение

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

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

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

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

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

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

Список используемых литератур

1. Информатика. 3-е изд. / А. Н. Степанов. -СПб.: Питер, 2002. - 608 с.: ил.

2. Информатика: Базовый курс / под ред. С. В. Симонович и др. - СПб.: Питер, 2003. - 640 с.

3. Могилев А.В., Пак Н.И., Хённер Е.К. Информатика. - М.: Академия, 2004. - 848 с.

4. Microsoft Access 2000: справочник. / Б. Карпов - СПб: Питер, 2001. - 416 с.

5. Томас Конноли, Каролин Бегг. Базы данных. Проектирование, реализация и сопровождение. Теория и практика: Пер. с англ. М.:Вильямс> 2001.-1440с.

6. К. Дж. Дейт. Введение в системы баз данных.: Пер. с англ. М.:Вильямс? 2001.-1072с.

7. Г.Н. Калянов. Консалтинг в автоматизации бизнес процессов. М.: Горячая линия - Телеком, 2002. - с.320.:ил.

Размещено на Allbest.ru

...