на тему рефераты
 
Главная | Карта сайта
на тему рефераты
РАЗДЕЛЫ

на тему рефераты
ПАРТНЕРЫ

на тему рефераты
АЛФАВИТ
... А Б В Г Д Е Ж З И К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я

на тему рефераты
ПОИСК
Введите фамилию автора:


Дипломная работа: Анализ информационной системы автосалона "Питер-Лада" и улучшение ее при помощи СУБД MySQL, PHP и HTML


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

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

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

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

ü  Производительность. Характеризуется временем ответа на запросы пользователей.

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


2.2 Проектирование базы данных в Rational Rose Data Modeler

При создании программных систем процесс создания структуры данных (модели) является одним из важнейших этапов. Однако до недавнего времени аналитики-проектировщики, работающие с Rational Rose, должны были обращаться к другим CASE-средствам для автоматизации этого процесса, например, к ERwin компании PLATINUM. С появлением подключаемого модуля (Add-In) под названием Data Modeler у разработчиков появилась возможность не отказываться от своего любимого инструмента и использовать Rational Rose не только для создания логического представления системы, но и для моделирования физического представления данных.

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей, приведенное в таблице 2.1.:

Таб. 2.1. Соответствие логической и физической модели


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

Таким образом, концептуально модуль Data Modeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД. Результатом работы Data Modeler будет являться построение диаграммы «сущность – связь» и последующая генерация описания базы данных на SQL. [6]

Подводя итог, к основным особенностям Data Modeler стоит отнести:

o  Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

o  Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

o  Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

o  Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей;

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

2.3 Проектирование логической модели базы данных

К основным компонентам диаграммы Data Modeler стоит отнести сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться ото всех остальных экземпляров. Атрибут выражает определенное свойство объекта. На физическом уровне сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.

Работа Data Modeler основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы «сущность – связь» и последующая генерация описания базы данных на SQL.

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

Далее более подробно рассмотрим сущности таблиц диаграммы классов.

Рис. 2.2. Таблица «СТО».


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

Рис. 2.3. Таблица «клиенты».

В таблице «клиенты» содержатся данные о клиентах компании, без разделения на клиентов СТО и клиентов отдела продаж автомобилей Lada.

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

Рис. 2.4. Таблица «Новые автомобили».

В данной таблице отображаются сведения о новых автомобилях приобретаемых компанией «Питер-Лада». Таблица содержит данные о модели автомобиля, его цвете, VIN – номере, комплектации и статус, в котором находится автомобиль. Если в статусе стоит Spb, значит автомобиль находится в наличии, и стоит на складе автосалона. Так же в статусе могут стоять следующие данные:

Таб. 2.2 Статусы новых автомобилей

Значение находящееся в таблице: Расшифровка
20 Сборка автомобиля запланирована на конкретную дату следующего месяца (время ожидания примерно 1.5 месяца)
32 Автомобиль поступил на сборку (ожидание от одной недели до месяца)
40 Автомобиль собран и ждет очереди на покраску.* (ожидание от одной недели до месяца)
48 Автомобиль полностью собран и находится на складе в Тольятти
60 Автомобиль находится в пути от Тольятти до Санкт-Петербурга (срок ожидания 3-4 дня)

*Покраска автомобилей в определенный цвет производится строго по графику, например в цвет 606 - «Млечный путь» 11-12 числа каждого месяца, а цвет 105 – «Франкония» только 1-го числа.

Рис. 2.5. Таблица «Заказы».

Таблица «Заказы» определяет заказ клиента на конкретный автомобиль. В таблице отображаются данные о номере заказа, модели выбранного автомобиля, дате сборки , дате оформления договора с клиентом, ФИО менеджера составившего договор, данные об оставленной клиентом предоплате. Отдельное внимание стоит уделить графе «автомобиль в зачет». Если клиент сдает свой старый автомобиль по программе утилизации, то в графе ставится значение «Да», и клиенту предоставляется скидка в 50 000 рублей, в противном случае ставится значение «Нет» и скидка не предоставляется.

Рис.2.6. Таблица «Утилизация».

В этой таблице содержатся данные об утилизируемых автомобилях, такие как марка автомобиля, год выпуска (под программу утилизации попадают все автомобили произведенные до 2000 года), VIN –номер, а так же данные о владельце данного автомобиля.

Рис. 2.7. Таблица «Пользователи».

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

Рис. 2.8. Таблица «Дополнительное оборудование».


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

Рис. 2.9. Таблица «Диски».

Содержит информацию о радиусе и фирме-производителе оригинальных дисков.

Рис. 2.10. Таблица «Мультимедиа»

Данная таблица отображает сведения о фирме мультимедийной системы, сведения о ее размерах (1-2 din), а так же информацию о ее основных функциях.

Для создания физической модели базы данных, из меню на пакете Моя модель выполняем команду Þ Data Modeler/Transform to Data Model.

В открывшемся окне в списке Target Database указать DB_0 и закрыть окно кнопкой ОК. В результате в логическом представлении в пакете Schemas появится пакет «Schema» S_0, в которую войдут все таблицы имеющие стереотип Сущность (entity). После чего из меню на пакете «Schema» S_0 выполняем команду Þ Data Modeler/New/Data Model Diagram. В пакете «Schema» S_0 появится новая диаграмма NewDiagram (диаграмма «сущность – связь»). Затем открываем эту диаграмму и наносим на нее все классы – таблицы, находящиеся в пакете «Schema» S_0.

В результате получаем диаграмму физической модели данных, изображенную на следующем рисунке:

После того, как мы создали физическую модель базы данных, приступим к генерации описания базы данных на SQL. Для этого из меню на пакете «Schema» S_0 выполняем команду Þ Data Modeler/Forward Engineer. Произойдет запуск генератора описания БД на SQL, после чего нажимаем клавишу Next. На следующем шаге мастера устанавливаем все флажки генерации и опять жмем Next. В следующем меню в графе «File Name» указываем имя и расположение текстового файла с результатами генерации. После чего доводим до конца работу с мастером.

После завершения генерации получаем следующий файл с описанием структуры БД на SQL:

CREATE TABLE DO (

name_option VARCHAR ( 255 ) NOT NULL,

cena INT NOT NULL,

DO_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_DO13 PRIMARY KEY NONCLUSTERED (DO_ID)

)

GO

CREATE TABLE Diski (

id_Disk INT NOT NULL,

radius INT NOT NULL,

firma VARCHAR ( 255 ) NOT NULL,

Diski_ID INT IDENTITY NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_Diski12 PRIMARY KEY NONCLUSTERED (Diski_ID)

)

GO

CREATE TABLE Multimedia_system (

id_system INT NOT NULL,

firma VARCHAR ( 255 ) NOT NULL,

din BIT NOT NULL,

function VARCHAR ( 255 ) NOT NULL,

Multimedia_system_ID INT IDENTITY NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_Multimedia_system14 PRIMARY KEY NONCLUSTERED (Multimedia_system_ID)

)

GO

CREATE TABLE Users (

id_users BIGINT NOT NULL,

FIO VARCHAR ( 255 ) NOT NULL,

Dostup INT NOT NULL,

Users_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_Users15 PRIMARY KEY NONCLUSTERED (Users_ID)

)

GO

CREATE TABLE Т_3 (

Zakazi_ID INT NOT NULL,

Clients_ID INT NOT NULL,

CONSTRAINT PK_220 PRIMARY KEY NONCLUSTERED (Zakazi_ID, Clients_ID)

)

GO

CREATE TABLE Т_2 (

Zakazi_ID INT NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_119 PRIMARY KEY NONCLUSTERED (Zakazi_ID, DO_ID)

)

GO

CREATE TABLE Т_1 (

CTO_ID INT NOT NULL,

Clients_ID INT NOT NULL,

CONSTRAINT PK_018 PRIMARY KEY NONCLUSTERED (CTO_ID, Clients_ID)

)

GO

CREATE TABLE Zakazi (

id_zakaz INT NOT NULL,

number INT NOT NULL,

model_avto VARCHAR ( 255 ) NOT NULL,

data_sborki DATETIME NOT NULL,

data_oforml_zakaz DATETIME NOT NULL,

FIO_manager VARCHAR ( 255 ) NOT NULL,

predoplata INT NOT NULL,

auto_v_zachet BIT NOT NULL,

Zakazi_ID INT IDENTITY NOT NULL,

New_auto_ID INT NOT NULL,

Users_ID INT NOT NULL,

CONSTRAINT TC_Zakazi4 UNIQUE NONCLUSTERED (New_auto_ID),

CONSTRAINT PK_Zakazi17 PRIMARY KEY NONCLUSTERED (Zakazi_ID)

)

GO

CREATE TABLE Utilization (

Id_Utiliz BIGINT NOT NULL,

Marka VARCHAR ( 255 ) NOT NULL,

God_v INT NOT NULL,

VIN INT NOT NULL,

Vladelec VARCHAR ( 255 ) NOT NULL,

Utilization_ID INT IDENTITY NOT NULL,

Zakazi_ID INT NOT NULL,

CONSTRAINT PK_Utilization16 PRIMARY KEY NONCLUSTERED (Utilization_ID)

)

GO

CREATE TABLE Clients (

id_client BIGINT NOT NULL,

FIO VARCHAR ( 255 ) NOT NULL,

Tel VARCHAR ( 255 ) NOT NULL,

Adr VARCHAR ( 255 ) NOT NULL,

N_pasport VARCHAR ( 255 ) NOT NULL,

N_VU VARCHAR ( 255 ) NOT NULL,

Clients_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_Clients11 PRIMARY KEY NONCLUSTERED (Clients_ID)

)

GO

CREATE TABLE CTO (

id_CTO INT NOT NULL,

nuber_zakaz-naryada SMALLINT NOT NULL,

zayavlennie_neispravnosti VARCHAR ( 255 ) NOT NULL,

data_nachala_remonta DATETIME NOT NULL,

viyavlennie_neispravnosti VARCHAR ( 255 ) NOT NULL,

gotovnost DATETIME NOT NULL,

cena INT NOT NULL,

CTO_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_CTO9 PRIMARY KEY NONCLUSTERED (CTO_ID)

)

GO

CREATE TABLE New_auto (

id_New_auto INT NOT NULL,

Model VARCHAR ( 255 ) NOT NULL,

Color INT NOT NULL,

VIN INT NOT NULL,

Complectation VARCHAR ( 255 ) NOT NULL,

status VARCHAR ( 255 ) NOT NULL,

New_auto_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_New_auto10 PRIMARY KEY NONCLUSTERED (New_auto_ID)

)

GO

CREATE INDEX TC_Diski6 ON Diski (DO_ID)

GO

CREATE INDEX TC_Multimedia_system8 ON Multimedia_system (DO_ID)

GO

CREATE INDEX TC_215 ON Т_3 (Zakazi_ID)

GO

CREATE INDEX TC_216 ON Т_3 (Clients_ID)

GO

CREATE INDEX TC_111 ON Т_2 (Zakazi_ID)

GO

CREATE INDEX TC_112 ON Т_2 (DO_ID)

GO

CREATE INDEX TC_00 ON Т_1 (CTO_ID)

GO

CREATE INDEX TC_01 ON Т_1 (Clients_ID)

GO

CREATE INDEX TC_Zakazi3 ON Zakazi (New_auto_ID)

GO

CREATE INDEX TC_Zakazi10 ON Zakazi (Users_ID)

GO

CREATE INDEX TC_Utilization14 ON Utilization (Zakazi_ID)

GO

ALTER TABLE Diski ADD CONSTRAINT FK_Diski3 FOREIGN KEY (DO_ID) REFERENCES DO (DO_ID)

GO

ALTER TABLE Multimedia_system ADD CONSTRAINT FK_Multimedia_system4 FOREIGN KEY (DO_ID) REFERENCES DO (DO_ID)

GO

ALTER TABLE Т_3 ADD CONSTRAINT FK_29 FOREIGN KEY (Zakazi_ID) REFERENCES Zakazi (Zakazi_ID)

GO

ALTER TABLE Т_3 ADD CONSTRAINT FK_210 FOREIGN KEY (Clients_ID) REFERENCES Clients (Clients_ID)

GO

ALTER TABLE Т_2 ADD CONSTRAINT FK_16 FOREIGN KEY (Zakazi_ID) REFERENCES Zakazi (Zakazi_ID)

GO

ALTER TABLE Т_2 ADD CONSTRAINT FK_17 FOREIGN KEY (DO_ID) REFERENCES DO (DO_ID)

GO

ALTER TABLE Т_1 ADD CONSTRAINT FK_00 FOREIGN KEY (CTO_ID) REFERENCES CTO (CTO_ID)

GO

ALTER TABLE Т_1 ADD CONSTRAINT FK_01 FOREIGN KEY (Clients_ID) REFERENCES Clients (Clients_ID)

GO

ALTER TABLE Zakazi ADD CONSTRAINT FK_Zakazi2 FOREIGN KEY (New_auto_ID) REFERENCES New_auto (New_auto_ID)

GO

ALTER TABLE Zakazi ADD CONSTRAINT FK_Zakazi5 FOREIGN KEY (Users_ID) REFERENCES Users (Users_ID)

GO

ALTER TABLE Utilization ADD CONSTRAINT FK_Utilization8 FOREIGN KEY (Zakazi_ID) REFERENCES Zakazi (Zakazi_ID)

GO

2.4 Средства, используемые для построения системы учета

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

В данном дипломном проекте для работы с базой данных «Автосалон» используется архитектура клиент-сервер. Каждая из составляющих эту архитектуру элементов играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность воспользоваться ими.

автосалон база учет моделирование

Рис. 2.13. Структура Клиент-сервер

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

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

Общеизвестно, что возможности настольных СУБД серьезно ограничены - это пять-семь пользователей и 30-50 Мб, соответственно. Цифры, разумеется, представляют собой некие средние значения, в конкретных случаях они могут отклоняться как в ту, так и в другую сторону. Что наиболее существенно, эти барьеры нельзя преодолеть за счет наращивания возможностей аппаратуры. Системы же на основе серверов баз данных могут поддерживать тысячи пользователей и сотни ГБ информации - дайте им только соответствующую аппаратную платформу.

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

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

MySQL - это ПО с открытым кодом. Применять его и модифицировать может любой желающий. Такое ПО можно получать по Internet и использовать бесплатно. При этом каждый пользователь может изучить исходный код и изменить его в соответствии со своими потребностями. Использование программного обеспечения MySQL регламентируется лицензией GPL (GNU General Public License), http://www.gnu.org/licenses/, в которой указано, что можно и чего нельзя делать с этим программным обеспечением в различных ситуациях.

MySQL состоит из двух частей: серверной и клиентской. Сервер MySQL постоянно работает на компьютере. Клиентские программы (например, скрипты PHP) посылают серверу MySQL SQL-запросы через механизм сокетов (то есть при помощи сетевых средств), сервер их обрабатывает и запоминает результат. То есть скрипт (клиент) указывает, какую информацио он хочет получить от сервера баз данных. Затем сервер баз данных посылает ответ (результат) клиенту (скрипту). Почему всегда передается не весь результат? Очень просто: дело в том, что размер результирующего набора данных может быть слишком большим, и на его передачу по сети уйдет чересчур много времени. Да и редко когда бывает нужно получать сразу весь вывод запроса (то есть все записи, удовлетворяющие выражению запроса). Например, нам может потребоваться лишь подсчитать, сколько записей удовлетворяет тому или иному условию, или же выбрать из данных только первые 10 записей. Механизм использования сокетов подразумевает технологию клиент-сервер, а это означает, что в системе должна быть запущена специальная программа — MySQL-сервер, которая принимает и обрабатывает запросы от программ. [10]

Для создания графического интерфейса было принято решение использовать PHP и HTML. PHP - это язык программирования, специально разработанный для написания web-приложений (сценариев), исполняющихся на Web-сервере. PHP и HTML тесно связаны: PHP генерирует HTML, а HTML содержит информацию, которая высылается в PHP. Значительным отличием PHP от какого-либо кода, выполняющегося на стороне клиента, например, JavaScript, является то, что PHP-скрипты выполняются на стороне сервера. Возможности PHP очень большие. Главным образом, область применения PHP сфокусирована на написание скриптов, работающих на стороне сервера; таким образом, PHP способен выполнять всё то, что выполняет любая другая программа CGI. Например, обрабатывать данных форм, генерировать динамические страницы, отсылать и принимать cookies. Но PHP способен выполнять и множество других задач. PHP — язык, который может быть встроен непосредственно в html -код страниц, которые, в свою очередь будут корректно обрабатываться PHP -интерпретатором. Очень важное преимущество PHP заключается в его «движке». «Движок» PHP не является ни компилятором, ни интерпретатором. Он является транслирующим интерпретатором. Такое устройство «движка» PHP позволяет обрабатывать сценарии с достаточно высокой скоростью.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8


на тему рефераты
НОВОСТИ на тему рефераты
на тему рефераты
ВХОД на тему рефераты
Логин:
Пароль:
регистрация
забыли пароль?

на тему рефераты    
на тему рефераты
ТЕГИ на тему рефераты

Рефераты бесплатно, реферат бесплатно, курсовые работы, реферат, доклады, рефераты, рефераты скачать, рефераты на тему, сочинения, курсовые, дипломы, научные работы и многое другое.


Copyright © 2012 г.
При использовании материалов - ссылка на сайт обязательна.