Проектування та розробка бази даних маршрутів міського транспорту

Розробка бази даних "Автовокзал". Функціональні залежності між атрибутами. Ідентифікація атрибутів, які в реляційної моделі даних використовуються в якості первинних ключів реляційних відносин. Організація вибірки інформації з бази за допомогою запиту.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 19.08.2012
Размер файла 35,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на 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


Подобные документы

  • Розробка структури бази даних. ER-моделі предметної області. Проектування нормалізованих відношень. Розробка форм, запитів, звітів бази даних "Автосалон". Тестування роботи бази даних. Демонстрація коректної роботи форми "Додавання даних про покупців".

    курсовая работа [4,0 M], добавлен 02.12.2014

  • Реляційна модель баз даних. Цілісність бази даних. Нормалізація, нормальні форми та функціональні залежності. Нормальна форма Бойса-Кодда. Запити та форми Access. Процес нормалізації при побудові бази даних "Музей" та система запитів над даними.

    курсовая работа [2,9 M], добавлен 06.11.2013

  • Проектування бази даних та інтерфейсу програми. Розробка бази даних за допомогою Firebird 2.5. Контроль коректності вхідних та вихідних даних. Додавання та редагування інформації. Вплив електронно-обчислювальних машин на стан здоров'я користувачів.

    дипломная работа [4,7 M], добавлен 12.10.2015

  • Системний аналіз бази даних за вхідною та вихідною документацією, визначення сутностей, атрибутів, зв’язків. Створення логічної моделі бази даних із застосуванням нормалізації, алгоритм її роботи. Розробка програмного забезпечення та інтерфейсу СУБД.

    курсовая работа [946,8 K], добавлен 02.07.2015

  • Проектування інформаційної системи для супроводу баз даних. Моделі запиту даних співробітником автоінспекції та обробки запиту про машини та їх власників. База даних за допомогою SQL-сервер. Реалізація запитів, процедур, тригерів і представлення.

    курсовая работа [1,7 M], добавлен 18.06.2012

  • Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.

    курсовая работа [3,5 M], добавлен 28.11.2011

  • Використання баз даних та інформаційних систем. Поняття реляційної моделі даних. Ключові особливості мови SQL. Агрегатні функції і угрупування даних. Загальний опис бази даних. Застосування технології систем управління базами даних в мережі Інтернет.

    курсовая работа [633,3 K], добавлен 11.07.2015

  • Розробка бази даних для меблевої фірми. Обстеження і аналіз предметної області та побудова концептуальної, логічної та фізичної моделі цієї бази даних. Використання мови програмування Visual Basic при написанні програмного коду, що обслуговує базу даних.

    курсовая работа [1,4 M], добавлен 24.10.2010

  • Проектування бази даних реєстрації та ведення обліку автомобілів в ДАІ на прикладі київського МРЕВ ДАІ за допомогою SQL Oracle. Опис інформаційної структури ПО з використанням діючих бізнес-правил та визначенням сутностей, їх атрибутів та зв'язків.

    курсовая работа [159,3 K], добавлен 05.12.2012

  • Специфікація вимог для кожного з двох користувачів. Концептуальне проектування бази даних. Визначення типів сутностей та зв’язків, доменів. Перетворення концептуальної моделі даних у логічну, визначення набору відношень, підтримки цілісності даних.

    курсовая работа [55,1 K], добавлен 15.03.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.