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

Вступ

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

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

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

Висновки

Ціллю курсової роботи було проектування бази даних автовокзалу.

Для виконання курсової роботи були проведені всі необхідні дослідження, що стосуються розробки стратегії автоматизації, в результаті яких була надана відповідь на принципові запитання, що стосуються автоматизації перевезень.

Після цього була побудована концептуальна модель. Для цього була використана мова ER-опису ПО, яка базується на концепції, що інформаційна модель будь-якої ПО може бути описана із застосування таких понять, Як сутність, атрибут, зв'язок. Крім того, ця мова є суттєво графічною, що дає можливість наочно представляти концептуальну модель ПО. При побудові концептуальної моделі неявно використовувалися результати теорії нормалізації, у зв'язку з цим побудована модель представлена у третій нормальній формі. Необхідності використання більш високих нормальних форм не було, так як у предметній області не були виявлені складні види транзитивних функціональних залежностей, а також багатозначні залежності.

Логічне та фізичне проектування БД складалося з конвертації концептуальної моделі ПО у реляційну модель даних. При цьому був використаний алгоритм конвертування схеми ПО у мові ER в схему реляційної бази даних. Після цього реляційна база даних була представлена у вигляді команд створення таблиць бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі інформаційно-пошукові запити.

Додаток

Програмний код об'єктів бази даних

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: 22/11/2011 00:02:59 ******/

CREATE ROLE [ADMIN] AUTHORIZATION [dbo]

GO

/****** Object: Role [GOST] Script Date: 22/11/2011 00:02:59 ******/

CREATE ROLE [GOST] AUTHORIZATION [dbo]

GO

/****** Object: Table [dbo]. [town] Script Date: 22/11/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: 22/11/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: 22/11/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: 22/11/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: 22/11/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: 22/11/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: 22/11/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 Размещено на Allbest.ru