Проектирование сетевой базы данных "Автовокзал"

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

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

Министерство образования и науки Российской Федерации

Северо-Кавказский государственный технический университет

Кафедра информационных систем и технологий

“Проектирование сетевой базы данных Автовокзал”

Пояснительная записка к курсовому проекту

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

Специальность 071900 (230201) «Информационные системы и технологии»

Ставрополь

2011

АННОТАЦИЯ

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

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

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
• 1.1 Общее описание предметной области
• 1.2 Описание входных документов и сообщений
• 1.3 Описание выходных документов и сообщений
• 1.4 Список ограничений
• 2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
• 2.1 ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
• 2.1.1 Описание сущностей
• 2.1.2 Описание связей
• 2.1.3 ER-Диаграмма
• 2.2 ДАТАЛОГИЧЕСКАЯ МОДЕЛЬ
• 3. ОРГАНИЗАЦИЯ ВЫБОРКИ ИНФОРМАЦИИ ИЗ БАЗЫ ДАННЫХ
• 4. РАЗРАБОТКА ПРЕДСТАВЛЕНИЙ ДЛЯ ОТОБРАЖЕНИЯ РЕЗУЛЬТАТОВ ВЫБОРКИ
• 5. ПРОЕКТИРОВАНИЕ ХРАНИМЫХ ПРОЦЕДУР
• 6. Разработка механизмов управления данными в базе при помощи триггеров
• 6.1 Триггер для добавления данных
• 6.2 Триггер для удаления данных
• 6.3 Триггер для обновления данных
• 7. Разработка технологий доступа к базе данных
• 7.1 Выбор пользователей базы данных.
• 7.2 Разграничение полномочий пользователя
• 8. Проектирование клиентского приложения
• 9. Организация обмена данными между серверной частью и клиентским приложением
• 10. Экономическое обоснование результатов внедрения программного продукта
• 11. Требования к техническому обеспечению
• 12. ИНСТРУКЦИЯ ПО ЭКСПЛУАТАЦИИ БАЗЫ ДАННЫХ И ПОЛЬЗОВАТЕЛЬСКОГО ПРИЛОЖЕНИЯ
• 12.1 Инструкция пользователя
• 12.2 Инструкция администратора
• Список используемой литературы
• ПРИЛОЖЕНИЕ 1 -Программный код объектов базы данных

ВВЕДЕНИЕ

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

В данном курсовом проекте была разработана база данных в СУБД Microsoft SQL Server 2008 Express для автоматизированного учета пассажирских перевозок по Ставропольскому краю - это такая организация, которая работает с очень большим объемом информации, как о сотрудниках, так и о клиентах. Для этого нужна общая база данных, включающая всю необходимую информацию. Мощность базы данных обусловлена возможностью ее постоянного пополнения новыми данными, причем в неограниченном количестве информации. Это является очень удобным для пользователя. Таким образом, создание базы данных, обладающей такими свойствами, задача достаточно актуальная и полезная. Программа, работающая с БД, позволяет вести учет водителей, автобусов, маршрутов.

База данных, которой посвящена эта пояснительная записка, разработана для предприятия «Транс Агентство 1».

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

1. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

При разработке базы данных «Автовокзал» было проведено обследование предметной области.

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

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

1.2 Описание входных документов и сообщений

В результате в БД «Автовокзал» используются следующие входные данные:

- информация о водителях,

- информация об автобусах,

- информация об автостанциях,

- информация о пунктах назначения

- информация о маршрутах движения.

1.3 Описание выходных документов и сообщений

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

1.4 Список ограничений

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

2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

2.1 ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ

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

2.1.1 Описание сущностей

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

«Водители» - хранится информация о водителях автобусов;

«Автобусы» - хранится информация об автобусах;

«Автостанции» - хранится информация о сотрудниках фирмы;

«Пункты назначения» - хранится информация о пунктах назначения;

«Маршруты» - хранится информация о маршрутах движения.

и их атрибуты:

1. Таблица driver (Водители) содержит:

driver_id - уникальный код водителя;

driver_fio - фамилия водителя.

2. Таблица bus (Автобусы) содержит:

bus_id - уникальный код автобуса;

gos_number - государственный номер автобуса;

bus_name - марка автобуса;

driver_id - уникальный код водителя.

3. Таблица station (Автостанции) содержит:

station_id - уникальный код автостанции;

station_name - название станции.

4. Таблица town (Пункты назначения) содержит:

town_id - уникальный код пункта назначения;

town_name - название пункта назначения.

5. Таблица route (Маршруты) содержит:

route_id - уникальный код маршрута;

time_out- время отправления;

time_in- время прибытия;

town_id - уникальный код пункта назначения;

station_id - уникальный код автостанции;

bus_id - уникальный код автобуса.

2.1.2 Описание связей

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

Модель «сущность - связь» основана на использовании 3-х основных конструктивных элементах:

- Сущность.

- Атрибут.

- Связь.

Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:

Отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;

Отношение “один ко многим” (1:М) возникает, когда одна запись взаимосвязана со многими другими;

Отношение “многие к одному” означает, что многие записи связаны с одной (М:1);

Отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

Одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

Одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

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

В курсовом проекте были использованы следующие типы связей (Таблица 3.1):

Таблица 3.1 - Классификация связей

Номер связи	Родительская таблица	Дочерняя таблица	Тип связи
1	driver	bus	1:M
2	bus	route	1:M
3	station	route	1:M
4	town	route	1:M

Таблица 3.1 показывает классификацию связей между таблицами. Связь под номером один, между таблицами «driver - bus» указывает на то, что в один водитель может работать на нескольких автобусах. Вторая связь «bus - route» имеет тип «1:M», так как на один автобус может работать на нескольких маршрутах. Третья связь «station - route» указывает на то, что c одной станции могут быть отправления по разным маршрутам. Четвертая связь «town - route» указывает на то, в один населенный пункт могут быть разные маршруты.

2.1.3 ER-Диаграмма

На рисунке 3.1 представлена ER-диаграмма базы данных.

Рисунок 3.1 - Инфологическая модель (ER-Диаграмма)

2.2 Даталогическая модель

Данные представляются в виде двумерных таблиц, над которыми допускаются традиционные теоретико-множественные операции (объединение, пересечение, разность и декартово произведение) и специальные реляционные операции (селекция, проекция, соединение и деление).

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

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

В разработанной базе данных «Автовокзал» существуют следующие функциональные зависимости между атрибутами:

Таблица 3.2 driver

Наименование атрибутов	Функциональные зависимости
driver_id driver_fio

Таблица 3.3 bus

Наименование атрибутов	Функциональные зависимости
bus_id bus_name driver_id gos_number

Таблица 3.4 station

Наименование атрибутов	Функциональные зависимости
station_id station_name

Таблица 3.5 town

Наименование атрибутов	Функциональные зависимости
town_id town_name

Таблица 3.6 route

Наименование атрибутов	Функциональные зависимости
route_id time_in time_out bus_id town_id station_id

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

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

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

Таблица 3.7 Ключи

Таблица	Ключ	Тип ключа
Drivers	Driver_id	primary
Station	Station_id	primary
Town	Town_id	primary
Bus	Bus_id	primary
Bus	Driver_id	regular
Route	Route_id	primary
Route	Town_id	regular
Route	Bus_id	regular
Route	Station_id	regular

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

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

Проведем нормализацию имеющихся сущностей.

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

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

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

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

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

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

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

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

Таблица 5.1.1 drivers

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Driver_id	Int	4	Not null
Driver_fio	Varchar	50	Not null

Таблица 5.1.2 bus

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Bus_id	Int	4	Not null
bus_name	Varchar	50	Not null
Gos_number	Varchar	10	Not null
Driver_id	Int	4	Not null

Таблица 5.1.3 station

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Station_id	Int	4	Not null
Station_name	Varchar	50	Not null

Таблица 5.1.4 town

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Town_id	Int	4	Not null
Town_name	Varchar	50	Not null

Таблица 5.1.5 route

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Route_id	Int	4	Not null
Time_in	Varchar	8	Not null
Time_out	Varchar	8	Not null
Bus_id	Int	4	Not null
Town_id	Int	4	Not null
Station_id	Int	4	Not null

3. ОРГАНИЗАЦИЯ ВЫБОРКИ ИНФОРМАЦИИ ИЗ БАЗЫ ДАННЫХ

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

В разработанной базе данных предусмотрены следующие запросы:

1. Простая выборка

SELECT *FROM drivers

SELECT *FROM town

SELECT *FROM station

SELECT *FROM bus

SELECT *FROM route

2. Выборка вычисляемых значений

SELECT town_name, COUNT(route_id) as count_ FROM route INNER JOIN town;

on route.town_id = town.town_id GROUP BY town_name

3. Выборка значений из определенного диапазона

SELECT * FROM route WHERE route.time_out BETWEEN '10-11' AND '14-00'

4. Выборка с использованием шаблонов

SELECT * FROM town WHERE town_name like 'М%'

5. Простой запрос с сортировкой

SELECT bus.bus_name,bus.gos_number FROM bus as bus ORDER BY bus.bus_Name

6. Выборка с упорядочением

SELECT * from town order by town_name

SELECT t.town_name FROM town as t;

WHERE t.town_id in (SELECT route.town_id FROM route HAVING COUNT(*) between min_

AND max_ group BY town_id ) ORDER BY town_name

7. Выборка с использованием оператора BETWEEN

SELECT t.town_name FROM town as t;

WHERE t.town_id in (SELECT route.town_id FROM route HAVING COUNT(*) between min_

AND max_ group BY town_id ) ORDER BY town_name

8. Выборка из связанных таблиц

SELECT town_name FROM town, route, bus

WHERE bus.driver_id = ident AND

route.bus_id = bus.bus_id AND

route.town_id = town.town_id

9. Использование группировки данных при организации запросов

SELECT driver_fio, coUNT(route_id) as count_ FROM route, bus, drivers

WHERE route.bus_id = bus.bus_id AND

bus.driver_id = drivers.driver_id GROUP BY driver_fio ORDER BY driver_fio

10. Выборка с использованием оператора естественного соединения

SELECT bus.bus_name, driver_fio FROM bus INNER JOIN

drivers ON

bus.driver_id = drivers.driver_id

Рисунок 4.1 Результат выполнение запроса - Простая выборка



Рисунок 4.2 Результат выполнение запроса - Выборка вычисляемых значений

Рисунок 4.3 Результат выполнение запроса - Выборка значений из определенного диапазона

Рисунок 4.4 Результат выполнение запроса - Выборка с использованием шаблонов



Рисунок 4.5 Результат выполнение запроса - Простой запрос с сортировкой

4. РАЗРАБОТКА ПРЕДСТАВЛЕНИЙ ДЛЯ ОТОБРАЖЕНИЯ РЕЗУЛЬТАТОВ ВЫБОРКИ

Информация находится в базе данных находится в структурированного виде. Для удобного представления данных пользователю в СУБД Microsoft SQL сервер имеется возможность создавать представления. Для их создания можно воспользоваться мастером создания представлений (рис 5.1).

Рисунок 5.1 Создание представления в MS SQL Server 2008

В данном курсовом проекте было создано представления для выборки расписания движения автобусов ROUTE VIEW.

Также для создания представления можно использовать язык Transact SQL - встроенный язык программирования Microsoft SQL Server. На рисунке 5.2 представлен код для создания представления на языке T-SQL.



Рисунок 5.2 - Представление ROUTE_VIEW

Рисунок 5.3 - Результат выполнения представление ROUTE_VIEW

5. ПРОЕКТИРОВАНИЕ ХРАНИМЫХ ПРОЦЕДУР

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

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

В данном курсовом проекте реализована хранимая процедура, возвращающая список рейсов в задаваемый населенный пункт. Хранимые процедуры в СУБД Microsoft SQL Server создаются на языке Transact SQL. На рисунке 6.1 представлен код реализованной процедуры.

Рисунок 6.1 - Исходный код хранимой процедуры с результатом выполнения

6. РАЗРАБОТКА МЕХАНИЗМОВ УПРАВЛЕНИЯ ДАННЫМИ В БАЗЕ ПРИ ПОМОЩИ ТРИГГЕРОВ

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

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

6.1 Триггер для добавления данных

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

Рисунок 7.1 - Триггер на вставку с результатом выполнения

6.2 Триггер для удаления данных

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

Рисунок 7.2 - Триггер на удаление с результатом выполнения

6.3 Триггер для обновления данных

Работа триггера для обновления данных аналогична работе триггера на вставку (рисунок 7.3).

Рисунок 7.1 - Триггер на обновление с результатом выполнения

7. РАЗРАБОТКА ТЕХНОЛОГИЙ ДОСТУПА К БАЗЕ ДАННЫХ

7.1 Выбор пользователей базы данных.

СУБД SQL Server обладает средствами ведения пользователей базы данных, контроля имен входа и администрирования доступа к данным.

Защита данных на уровне СУБД выполняется средствами идентификации пользователя с помощью политики паролей.

Для создания нового пользователя администратору Microsoft SQL Server необходимо создать имя входа в разделе «Безопасность» (рисунок 8.4).

Рисунок 8.1 - Создание имени входа

7.2 Разграничение полномочий пользователя

Для разграничения полномочий в базе данных созданы две роли: администратор и гость (рисунок 8.2). Для ролей установлены соответствующие ограничения и разрешения.



Рисунок 8.2 - Установка разрешений для ролей

Для разграничения полномочий пользователя достаточно соотнести его с одной из ролей (рисунок 8.3).

Рисунок 8.3 - Установка роли пользователя

8. ПРОЕКТИРОВАНИЕ КЛИЕНТСКОГО ПРИЛОЖЕНИЯ

Приложение разработано на платформе.Net Framework, язык программирования C#.

Пользовательский интерфейс программы выполнен в виде одно документного приложения (Single Document Interface). При запуске программа после идентификации (рисунок 9.1) выдает главное окно (рисунок 9.2).

Главным элементом главной формы является таблица, в которой содержится расписание движения автобусов.

Рисунок 9.1 - Идентификация пользователя

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

Рисунок 9.2 - Главное окно программы

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

В приложении реализованы справочники: Транспорт, Пункты назначения, Водители, Автостанции.

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

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

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

Записи вносятся в тот же компонент DataGridView, в который выводятся. На главной форме выбор данных из связанных таблиц осуществляется с помощью поля типа DataGridViewComboBoxColumn.

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

Поиск данных выполнен через компонент BindingSource, который связан с каждой таблицей. Найденные данные также можно выгрузить в приложение Microsoft Excel.

данные автоматизированный учет программный

9. ОРГАНИЗАЦИЯ ОБМЕНА ДАННЫМИ МЕЖДУ СЕРВЕРНОЙ ЧАСТЬЮ И КЛИЕНТСКИМ ПРИЛОЖЕНИЕМ

Приложение разработано c использованием технологии ADO.NET, поэтому подключение к базе данных выполнено с помощью объекта класса OleDBConnection.

Для подключения к базе данных и некоторых других функций разработан статический класс DB. Для выполнения любых операций с базой данных необходим вызов метода DB.DoConnection(). Этот метод производит подключение к базе данных и возвращает true, если подключение выполнено, и false в противном случае.

Для метода DB.DoConnection() необходима строка подключения. Для удобства администрирования программы был создан файл connect.udl - стандартный файл Windows для доступа к данным. Запустив его, администратор программы может выбрать базу данных (рисунок 10.1 - 10.2).

Рисунок 10.1 - Подключение к базе (выбор провайдера)



Рисунок 10.2 - Подключение к базе (выбор базы данных)

Описанные выше объекты и методы доступны для всех и используются практически во всех классах приложения

Для выполнения любых операций с базой данных в приложении используется компонент TableAdapter. В компоненте есть параметр Connection. Ему присваивается значение DataBase.MainConnect.

Для работы с объектами базы данными был разработан класс Data_Set. Данный класс полностью был создан с помощью мастера. Объекты типа TableAdapter были созданы автоматически при перетаскивании из источника данных (рисунок 10.3).

Рисунок 10.3 - Класс Data_Set

10. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РЕЗУЛЬТАТОВ ВНЕДРЕНИЯ ПРОГРАММНОГО ПРОДУКТА

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

Экономическая эффективность проекта складывается из двух составляющих:

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

- Прямого эффекта, который характеризуется снижением трудовых, стоимостных показателей.

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

- основная заработная плата персонала;

- дополнительная заработная плата;

- отчисления на социальные нужды;

- затраты на потребляемую электроэнергию;

- расходы на материалы и запасные части;

- затраты на техническое обслуживание и текущий ремонт вычислительной техники.

Часовая тарифная ставка программиста

руб. (11.1)

Часовая тарифная ставка оператора ЭВМ

руб. (11.2)

Фонд рабочего времени при создании информационной подсистемы

tВ = 1,15?(16 + 135,6 + 101) = 1,15?252,6 = 290,49 ч. (11.3)

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

ЗО = (16 + 135,6 + 101)*0,8*44,79 + (30,0 + 48,47 + 98,65)*0,8*31,29 = 9029,67+4433,66 = 13463,34 (11.4)

Дополнительная заработная плата

ЗД = 0,15?13463,34= 2019,5 руб. (11.5)

Отчисления на социальные нужды (35,6%)

руб. (11.6)

Таким образом, единый социальный налог составит 6481,1 руб.

Затраты на потребляемую электроэнергию

ЗЭ =0,3?1,74?722,44 = 377,49 руб. (11.7)

Данные для расчета затрат на материалы и запасные части занесенные в таблицу 11.1.

Таблица 11.1 - Затраты на материалы и покупные изделия

Материал, покупное изделие	Количество, единиц	Цена за единицу, руб.	Сумма, руб.
Справочно-техническая литература	3	165 ,00	495,00
СD-R, 700 Mb	2	15,00	30,00
Картридж для принтера	1	255,00	255,00
Упаковка бумаги, 500 листов	1	125,00	125,00
Итого			905,00

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

ЗМ = 905,00 руб.

Затраты на техническое обслуживание и текущий ремонт (стоимость вычислительной техники руб.)

руб. (11.8)

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

Таблица 11.2 - Величины затраты на создание программного продукта

Статья расхода	Сумма, руб.
Основная заработная плата	13463,34
Дополнительная заработная плата	2019,5
Отчисления на социальные нужды	6481,10
Затраты на потребляемую электроэнергию	377,49
Материальные затраты	905,00
Затраты на техническое обслуживание и текущий ремонт	356,19
Итого	23602,62

Таким образом, полные затраты на создание информационной подсистемы составляют

З = 23602,62 руб.

Капиталовложения при внедрении программного продукта равняются его себестоимости и в приведении к расчетному году не нуждаются, поэтому

К = З = 23602,62 руб.

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

Т = ТО + ТИ + ТА + ТП + ТОТЛ + ТД, (11.9)

где: ТО - затраты труда на описание задачи;

ТИ - затраты на исследование предметной области;

ТА - затраты на разработку алгоритма решения задачи;

ТП - затраты на создание таблиц, форм, отчётов, запросов и т.д.;

ТОТЛ - затраты на отладку;

ТД - затраты на подготовку документации.

Все составляющие определяем через условное число операторов D:

D = б ?c ? (1 + p), (11.10)

где: б = 85 - число операторов;

с = 1,5 - коэффициент сложности. Коэффициент сложности задачи с характеризует относительную сложность программы по отношению к так называемой типовой задаче, реализующей стандартные методы решения, сложность которой принята равной единице (величина коэффициента «с» лежит в пределах от 1,25 до 2). Для рассматриваемой информационной подсистемы, включающую в себя алгоритмы учета, отчетности, поиска - сложность задачи возьмем 1,5.

р = 0,9 - коэффициент коррекции программы в ходе разработки. Коэффициент коррекции программы - увеличение объема работ за счет внесения изменений в алгоритм или программу по результатам уточнения постановок. С учетом того, что в данном случае заказчик, хорошо представлял себе, что он хочет получить в результате разработки программного продукта коэффициент «p» примем равным 0,9.

В результате получим условное число операторов.

D = 85 ? 1,5 ?(1 + 0,9) = 242,25 ед.

Затраты труда на описание задачи принимаем: ТО = 30 чел./ч. Работу выполняет техник по учету продукции с окладом 5200 руб. в месяц и коэффициентом квалификации k = 1,35 (опыт работы по специальности 6 лет).

Затраты труда на изучение задачи ТИ с учетом уточнения описания и квалификации программиста могут быть определены по формуле:

ТИ = (D ? b) / ((75 85) ? k), (11.11)

где: D - условное число операторов,

b - коэффициент увеличения затрат труда, вследствие недостаточного описания задачи. Коэффициент увеличения затрат труда, вследствие недостаточного описания задачи, в зависимости от сложности задачи принимается от 1,2 до 1,5 в связи с тем, что данная задача, потребовала уточнения и больших доработок, примем коэффициент b= 1,5

ТИ = (242,25 ? 1,5) / (75 ? 1,35) = 3,59 чел./ч. (техник).

Затраты труда на разработку алгоритма решения задачи ТА рассчитывается по формуле:

ТА = D / ((20 25) ? k), (11.12)

ТА = 242,25 /(20 ? 1,35) = 8,97 чел./ч. (техник).

Затраты труда на составление программы по готовой блок-схеме ТП определяется по формуле:

ТП = D / ((20 25) ? k), (11.13)

ТП = 242,25 / (20 ? 1,45) = 8,35 чел./ч. (инженер-программист, с окладом 6000 руб. в месяц и коэффициентом квалификации k = 1,45).

Затраты труда на отладку программы на персональном компьютере ТОТЛ рассчитывается по следующей формуле:

ТОТЛ = D / ((4 5) ? k), (11.14)

ТОТЛ = 242,25 / (4 ? 1,45) = 41,77 чел./ч. (инженер-программист)

Затраты труда на подготовку документации по задаче ТД определяются по формуле:

ТД = ТДР + ТДО, (11.15)

где ТДР - затраты труда на подготовку материалов в рукописи;

ТДР = D / ((15 20) ? k), (11.16)

ТДР = 242,25 / (15 ? 1,45) = 11,14 чел./ч.

ТДО - затраты труда на редактирование, печать и оформление документации:

ТДО = 0,75 ? ТДР; (11.17)

ТДО = 0,75 ? 11,14 = 8,35 чел./ч.

ТД = 11,14 + 8,35 = 19,49 чел./ч. (инженер-программист)

Подставив все полученные данные в формулу (3.1), получим полную трудоемкость разработки:

Т = 30+3,59+8,97+8,35+41,77+19,49=112,17 чел./ч.

Данный программный продукт будет использоваться операторами автовокзала ООО «Транс Агентство 1». Оклад оператора -- 5100 руб., премиальный фонд -- 25% от оклада. Часовая ставка оператора составит:

руб. (11.18)

Тогда годовые затраты оператора при ручной обработке информации (затраты времени на ручную обработку информации составляют 89,11 ч в месяц) составят

ЗРУЧН = 89,11?12?39,11 = 41821,56 руб. (11.19)

При автоматизированной обработке информации (затраты времени 2,00 ч в месяц)

ЗАВТ = 2,00?12? 39,11 = 938,64 руб. (11.20)

Годовой эффект от внедрения программного продукта

Э = ЗРУЧН - ЗАВТ = 41821,56-938,64 = 40882,92 руб. (11.21)

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

Для персонального компьютера за 12 месяцев затраты на электроэнергию при потребляемой мощности компьютера PВ =0,3 кВт составят (стоимость электроэнергии ц_Э =1,74 руб./кВт-ч.)

З_Э = 0,3?2?12?1,74 = 14,09 руб. (11.22)

Затраты на техническое обслуживание и текущий ремонт

руб. (11.23)

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

З = З_Э + З_П = 14,09 + 19,28 = 33,37 руб. (11.24)

Прибыль рассчитаем по формуле

П = Э - З = 40882,92 - 33,37 = 40849,55 руб. (11.25)

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

капиталовложения - 24800,00 руб.;

1 год 40849,55 руб.;

2 год 40849,55 руб.;

3 год 40849,55 руб.

Чистый дисконтированный доход за 3 года использования информационной подсистемы (срок до морального старения данной разработки) при норме дисконта E=20% составит

(11.26)

Приходим к выводу, что ЧДД -- положителен, т.е. проект эффективен.

Рассчитаем срок окупаемости.

Величины приведенных (дисконтированных) годовых эффектов по годам расчетного периода равны:

руб.;

руб.;

руб.

Величина дохода за первый год составит

руб.,

что больше величины капиталовложений (24800 руб.).

Тогда срок окупаемости составит

года. (11.27)

Таблица 11.3 - Сводный анализ показателей экономической эффективности

Наименование показателя	Значение
Итоговая трудоемкость разработки информационной подсистемы, Т (чел./ч. )	112,17
Полные затраты на создание информационной подсистемы, З (руб.)	24800,00
Капиталовложения при внедрении информационной подсистемы, К (руб.)	24800,00
Годовой эффект от внедрения информационной подсистемы, П (руб)	40849,55
Чистый дисконтированный доход за 4 года использования информационной подсистемы, ЧДД (руб.)	61248,82
Срок окупаемости проекта, Ток (год)	1,27

Разработанная автоматизированная информационная подсистема «АВТОВОКЗАЛ» для отдела ООО «Транс Агентство 1» имеет как явный экономический эффект, так и неявный. Появляется возможность получать информацию намного быстрее, точнее и качественнее, чем при ручном вводе информации.

11. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ

Для успешной эксплуатации программного продукта необходим персональный компьютер со следующими характеристиками: процессор Intel Pentium с тактовой частотой 800 МГц и выше, оперативная память - не менее 256 Мбайт, свободное дисковое пространство - не менее 700 Мбайт, устройство для чтения компакт-дисков, монитор типа Super VGA (число цветов - 256) с диагональю не менее 15?, принтер. Программное обеспечение: операционная система WINDOWS 2000/XP и выше, Microsoft Office 2003 (с компонентом Excel) и выше, Microsoft Framework 3.5 и выше, Microsoft Visual Studio 2008, MS Microsoft SQL Server 2008.

12. ИНСТРУКЦИЯ ПО ЭКСПЛУАТАЦИИ БАЗЫ ДАННЫХ И ПОЛЬЗОВАТЕЛЬСКОГО ПРИЛОЖЕНИЯ

12.1 Инструкция пользователя

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

Программа имеет интуитивно понятный интерфейс.

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

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

Вводить и редактировать данные можно прямо в таблице.

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

Работа со всеми таблицами идентична.

Для печати главной таблицы нужно нажать кнопку «Печать таблицы».

12.2 Инструкция администратора

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

Перед установкой программы необходимо убедиться в соответствии требований к программному и аппаратному обеспечению.

Установка базы данных осуществляется с помощью мастера восстановления базы данных СУБД.

При установке программы необходимо переписать на жесткий диск папку с программой и открыть файл connect.udl. На второй вкладке необходимо указать путь к базе данных.

Установка пароля к базе данных и резервное копирование осуществляется с помощью интерфейса соответствующей версии Microsoft SQL Server (база данных будет работать и в более поздних версиях СУБД).

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Карпова Т.С. Базы данных. Модели, разработка, реализация/СПб.: Питер, 2002. - 304 с.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. Учебник для ВУЗов /под ред. проф.А.Д.Хомоненко // СПб.:КОРОНАпринт, 2000.- 416 с.

3. Корнеев В.В. и др. Базы данных. Интеллектуальная обработка информации // М.:Нолидж, 2000.- 352 с.

4. Бартеньев О.В. Microsoft Visual FoxPro:Учебно-справочное пособие/ М.:Диалог МИФИ, 2005-672 с.

5. Каратыгин С.А.,Тихонов А.Ф., Тихонова Л.Н. Visual FoxPro 6.0//М.: Бином, 1999-784С.

6. Ханcен Г., Ханcен Д. Базы данных. Разработка и управление/М.: Бином, 1999-704С.

7. Глушаков С.В., Ломотько Д.В. Базы данных. Учебный курс // Харьков: Фолио; Ростов н/Д: Феникс; Киев: Абрис, 2000. - 504 с.

8. Игорева, Е.Л., Основы алгоритмизации и программирования (3-е издание)./ И.И. Попов, О.Л. Игорева - М.: Инфа-М, 2006 - 432 с.

9. Петгольц, Ч. Программирование для Microsoft Windows на C#. В 3-х томах. Том 2. Пер. с англ./ Ч. Петгольц - М.: Издательско-торговый дом «Русская редакция», 2002. - 576 с.

10. Петгольц, Ч. Программирование для Microsoft Windows на C#. В 3-х томах. Том 3 Пер. с англ./ Ч. Петгольц - М.: Издательско-торговый дом «Русская редакция», 2002. - 624 с.

11. Гражданский кодекс РФ Части первая, вторая. М.: Норма. - 2000.

12. Закон РФ от 27 ноября 1992 г. N 4015-1 "Об организации страхового дела в Российской Федерации" // Российская газета. - 12 января 1993 г.

ПРИЛОЖЕНИЕ 1 -Программный код объектов базы данных

USE [master]

GO

/****** Object: Database [Auto] Script Date: 06/02/2011 23:59:36 ******/

CREATE DATABASE [Auto] ON PRIMARY

( NAME = N'Auto', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL\MSSQL\DATA\Auto.mdf', SIZE = 3072KB, MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )

LOG ON

( NAME = N'Auto_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL\MSSQL\DATA\Auto_log.ldf', SIZE = 1024KB, MAXSIZE = 2048GB, FILEGROWTH = 10%)

GO

ALTER DATABASE [Auto] SET COMPATIBILITY_LEVEL = 100

GO

IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))

begin

EXEC [Auto].[dbo].[sp_fulltext_database] @action = 'enable'

end

GO

ALTER DATABASE [Auto] SET ANSI_NULL_DEFAULT OFF

GO

ALTER DATABASE [Auto] SET ANSI_NULLS OFF

GO

ALTER DATABASE [Auto] SET ANSI_PADDING OFF

GO

ALTER DATABASE [Auto] SET ANSI_WARNINGS OFF

GO

ALTER DATABASE [Auto] SET ARITHABORT OFF

GO

ALTER DATABASE [Auto] SET AUTO_CLOSE OFF

GO

ALTER DATABASE [Auto] SET AUTO_CREATE_STATISTICS ON

GO

ALTER DATABASE [Auto] SET AUTO_SHRINK OFF

GO

ALTER DATABASE [Auto] SET AUTO_UPDATE_STATISTICS ON

GO

ALTER DATABASE [Auto] SET CURSOR_CLOSE_ON_COMMIT OFF

GO

ALTER DATABASE [Auto] SET CURSOR_DEFAULT GLOBAL

GO

ALTER DATABASE [Auto] SET CONCAT_NULL_YIELDS_NULL OFF

GO

ALTER DATABASE [Auto] SET NUMERIC_ROUNDABORT OFF

GO

ALTER DATABASE [Auto] SET QUOTED_IDENTIFIER OFF

GO

ALTER DATABASE [Auto] SET RECURSIVE_TRIGGERS OFF

GO

ALTER DATABASE [Auto] SET DISABLE_BROKER

GO

ALTER DATABASE [Auto] SET AUTO_UPDATE_STATISTICS_ASYNC OFF

GO

ALTER DATABASE [Auto] SET DATE_CORRELATION_OPTIMIZATION OFF

GO

ALTER DATABASE [Auto] SET TRUSTWORTHY OFF

GO

ALTER DATABASE [Auto] SET ALLOW_SNAPSHOT_ISOLATION OFF

GO

ALTER DATABASE [Auto] SET PARAMETERIZATION SIMPLE

GO

ALTER DATABASE [Auto] SET READ_COMMITTED_SNAPSHOT OFF

GO

ALTER DATABASE [Auto] SET HONOR_BROKER_PRIORITY OFF

GO

ALTER DATABASE [Auto] SET READ_WRITE

GO

ALTER DATABASE [Auto] SET RECOVERY SIMPLE

GO

ALTER DATABASE [Auto] SET MULTI_USER

GO

ALTER DATABASE [Auto] SET PAGE_VERIFY CHECKSUM

GO

ALTER DATABASE [Auto] SET DB_CHAINING OFF

GO

USE [Auto]

GO

/****** Object: Role [ADMIN] Script Date: 06/03/2011 00:02:59 ******/

CREATE ROLE [ADMIN] AUTHORIZATION [dbo]

GO

/****** Object: Role [GOST] Script Date: 06/03/2011 00:02:59 ******/

CREATE ROLE [GOST] AUTHORIZATION [dbo]

GO

/****** Object: Table [dbo].[town] Script Date: 06/03/2011 00:02:58 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[town](

[town_id] [int] IDENTITY(1,1) NOT NULL,

[town_name] [varchar](50) NULL,

CONSTRAINT [PK_town] PRIMARY KEY CLUSTERED

(

[town_id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

/****** Object: Table [dbo].[driver] Script Date: 06/03/2011 00:02:58 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[driver](

[driver_id] [int] IDENTITY(1,1) NOT NULL,

[driver_fio] [varchar](50) NULL,

CONSTRAINT [PK_driver] PRIMARY KEY CLUSTERED

(

[driver_id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

/****** Object: Table [dbo].[route] Script Date: 06/03/2011 00:02:58 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[route](

[route_id] [int] IDENTITY(1,1) NOT NULL,

[time_in] [varchar](10) NULL,

[time_out] [varchar](10) NULL,

[bus_id] [int] NULL,

[town_id] [int] NULL,

[station_id] [int] NULL,

CONSTRAINT [PK_route] PRIMARY KEY CLUSTERED

(

[route_id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

/****** Object: Table [dbo].[bus] Script Date: 06/03/2011 00:02:58 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[bus](

[bus_id] [int] IDENTITY(1,1) NOT NULL,

[gos_number] [varchar](10) NULL,

[bus_name] [varchar](50) NULL,

[driver_id] [int] NULL,

CONSTRAINT [PK_bus] PRIMARY KEY CLUSTERED

(

[bus_id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

/****** Object: Table [dbo].[station] Script Date: 06/03/2011 00:02:58 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[station](

[station_id] [int] IDENTITY(1,1) NOT NULL,

[station_name] [varchar](50) NULL,

CONSTRAINT [PK_station] PRIMARY KEY CLUSTERED

(

[station_id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

SET ANSI_PADDING OFF

GO

/****** Object: View [dbo].[ROUTE_VIEW] Script Date: 06/03/2011 00:02:59 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE VIEW [dbo].[ROUTE_VIEW]

AS

SELECT dbo.route.route_id, dbo.route.time_in, dbo.route.time_out, dbo.station.station_name, dbo.town.town_name, dbo.bus.gos_number, dbo.bus.bus_name,

dbo.route.bus_id, dbo.route.town_id, dbo.route.station_id

FROM dbo.route INNER JOIN

dbo.station ON dbo.route.station_id = dbo.station.station_id INNER JOIN

dbo.town ON dbo.route.town_id = dbo.town.town_id INNER JOIN

dbo.bus ON dbo.route.bus_id = dbo.bus.bus_id

GO

/****** Object: StoredProcedure [dbo].[GET_ROUTES_BY_TOWN] Script Date: 06/03/2011 00:02:54 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

-- =============================================

-- Author:<Author,,Name>

-- Create date: <Create Date,,>

-- Description:<Description,,>

-- =============================================

CREATE PROCEDURE [dbo].[GET_ROUTES_BY_TOWN]

@TOWN_ID int

AS

BEGIN

-- SET NOCOUNT ON added to prevent extra result sets from

-- interfering with SELECT statements.

SET NOCOUNT ON;

-- Insert statements for procedure here

SELECT time_in, time_out, station_name, gos_number, bus_name

from ROUTE_VIEW where town_id = @TOWN_ID

END

GO

/****** Object: ForeignKey [FK_bus_driver] Script Date: 06/03/2011 00:02:58 ******/

ALTER TABLE [dbo].[bus] WITH CHECK ADD CONSTRAINT [FK_bus_driver] FOREIGN KEY([driver_id])

REFERENCES [dbo].[driver] ([driver_id])

GO

ALTER TABLE [dbo].[bus] CHECK CONSTRAINT [FK_bus_driver]

GO

/****** Object: ForeignKey [FK_route_bus] Script Date: 06/03/2011 00:02:58 ******/

ALTER TABLE [dbo].[route] WITH CHECK ADD CONSTRAINT [FK_route_bus] FOREIGN KEY([bus_id])

REFERENCES [dbo].[bus] ([bus_id])

GO

ALTER TABLE [dbo].[route] CHECK CONSTRAINT [FK_route_bus]

GO

/****** Object: ForeignKey [FK_route_station] Script Date: 06/03/2011 00:02:58 ******/

ALTER TABLE [dbo].[route] WITH CHECK ADD CONSTRAINT [FK_route_station] FOREIGN KEY([station_id])

REFERENCES [dbo].[station] ([station_id])

GO

ALTER TABLE [dbo].[route] CHECK CONSTRAINT [FK_route_station]

GO

/****** Object: ForeignKey [FK_route_town] Script Date: 06/03/2011 00:02:58 ******/

ALTER TABLE [dbo].[route] WITH CHECK ADD CONSTRAINT [FK_route_town] FOREIGN KEY([town_id])

REFERENCES [dbo].[town] ([town_id])

GO

ALTER TABLE [dbo].[route] CHECK CONSTRAINT [FK_route_town]

GO

ПРИЛОЖЕНИЕ 2

Даталогическая модель

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