Система управління базою даних

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Зміст

Введення

1. Інфологічне проектування

1.1 Аналіз предметної області

1.2 Аналіз інформаційних завдань і кола користувачів системи

1.3 інфологічне проектування

2. Визначення вимог до операційної обстановці

2.1 Вибір ПЗ та ЕОМ

2.2 Обсяг зовнішньої пам'яті займаний модулями СУБД

2.3 Обсяг пам'яті, що відводиться під дані

2.4 Уявлення про характер і інтенсивності запиту

3. Вибір СУБД

4 Логічне проектування БД

4.1 Обмеження цілісності

5. Фізичне проектування БД

6. Висновок

Список літератури

Введення

У сучасному світі роль бази даних достатня висока. Багато підприємств, фірми використовують такий метод зберігання інформації в комп'ютері, будь то дані про співробітників, про різних комерційних угодах (купівлі, продажу і т.д.). За будь-яких банківських операціях (оплата комунальних послуг, за газ, за світло і т.д.) дані заносяться в базу даних.

База даних - це організована структура, в якому в спеціальному форматі зберігається інформація, тобто дані. Система управління базою даних (СКБД) - це програма, за допомогою якої в комп'ютер вводиться інформація, проглядається, сортується, фільтрується, розшукується, експортується (перекладається у формати інших СУБД) або, навпаки, імпортується. СУБД це програма, яка здійснює ще й найбільш швидке звернення до зберігаються в ній даних.

Сьогодні більшість систем управління базами даних (СКБД) дозволяють розміщувати у своїх структурах не лише дані, але і методи (тобто програмний код), за допомогою яких відбувається взаємодія зі споживачем або з іншими програмно-апаратними комплексами.

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

1. Інфологічне проектування

1.1 Аналіз предметної області

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

1.2 Аналіз інформаційних завдань і кола користувачів системи

Проектована база даних (БД) призначена для інформаційної системи (ІС) диспетчерів автовокзалу та обслуговуючого персоналу, для управління та обліку виїздів всіх автобусів. БД повинна вирішувати досить вузьке коло завдань, пов'язаний зіставленням розкладу та фактичних виїздів автобусів по різних маршрутах.

Основним завданням стоїть перед проектованої БД є складання розкладу виїздів автобусів різних автокомпаній під управлінням відповідних екіпажів, з урахуванням дальності маршруту.

Різні автокомпанії надають автобуси різного класу (марки). Для дотримання правових норм і контролю диспетчерам автовокзалу необхідна наявність реквізитів всіх автокомпаній надають послуги з перевезення пасажирів. Наявність реквізитів забезпечує також функціональний зв'язок автовокзалу і компаній в разі позапланових та надзвичайних ситуацій. Реквізити повинні включати в себе: назву автокомпанії, номер ліцензії, адреса головного офісу і телефон головного менеджера компанії. Даний список реквізитів є достатнім і не створює надмірності інформації для роботи зазначеної служби автовокзалу.

Для служби забезпечення важливим є наявність наступних даних: кількість посадкових місць, марка палива, об'єм паливного бака, і марка автобуса.

У залежності від марки автобуса підбирається відповідний екіпаж, що має відповідну групу допуску управління.

Кожен екіпаж складається з однієї особи, кожен з яких має такі атрибути як прізвище, ім'я, по батькові, посада (Шофер).

На певний термін диспетчерами складається планове розклад поїздки автобусів. Дані складеного розкладу поширюються не тільки серед диспетчерських служб автовокзалу, а й для інформаційного забезпечення потенційних пасажирів. Щоб володіти достатньою інформативністю для її користувачів, розклад повинне мати такі атрибути: номер рейсу, місце відправлення, місце призначення, час в дорозі, відстань, проміжні зупинки.

Для послуг з боку бази даних необхідно вміст у ній відносини - «Маршрути», що володіє наступними атрибутами: код маршруту, код рейсу, дата відправлення, час відправлення, автобус, екіпаж, кількість проданих квитків.

У результаті аналізу предметної області були виділені наступні завдання:

- Введення даних;

- Зберігання даних;

- Оновлення даних;

- Вибірка даних;

- Надання звітів.

Для забезпечення комфорту керування та вводу даних існує необхідність створення в БД форм.

1.3 інфологічне проектування

Метою інформаційно-логічного (інфологічне) моделювання є забезпечення найбільш природних для людини способів збору та подання інформації яку можна зберігати в створюваній базі даних.

Процес проектування ІС починається з побудови инфологической моделі предметної області. Инфологическая модель предметної області (ПО) являє собою опис структури та динаміки ПЗ, характеру інформаційної потреби користувачів в термінах, зрозумілих користувачеві і не залежать від реалізації БД. Цей опис виражається в термінах не окремих об'єктів ВО та зв'язків між ними, а їх типів, пов'язаних з ними обмежень цілісності і тих процесів, які призводять до переходу предметної області з одного стану в інший.

Аналіз предметної області дозволяє виділити сутності.

Стрижневі сутності; Автобуси, Рейси, Екіпажі.

Позначають сутності: Автокомпанії, Марка автобусів.

Асоціативні сутності: Маршрути.

Характеризують сутності: Склад екіпажу.

Використовуючи міфологічний мова моделювання (ЯІМ) базу даних можна описати таким чином

Рейси (Номер рейсу. Місце відправлення, Місце призначення, Час в дорозі. Відстань, Проміжні посадки);

Автобуси (Реєстраційний знак. Марка автобуса. Автокомпанія);

Екіпажі (№ екіпажу. Група допуску, Медичний висновок);

Маршрути [Автобуси М, Рейси N, Екіпажі Р] (Код Маршруту, № рейсу, Дата відправлення, Час відправлення, Реєстраційний знак, № екіпажу, Кількість проданих квитків);

Склад екіпажу (Код складу екіпажу. Прізвище., Ім'я, По батькові, № екіпажу) (Екіпажі);

Автокомпанії (Автокомпанії, номер ліцензії, Адреса офісу, Телефон головного менеджера) [Автобуси].

Марка автобусів (Марка автобуса, код автобусів, Кількість місць, Марка палива, Об'єм паливного бака) [Автобуси].

На підставі аналізу можна побудувати ER-діаграму додаток А.

2. Визначення вимог до операційної обстановці

2.1 Вибір ПЗ та ЕОМ

База даних автовокзал повинна працювати в многопользовательском режимі, що вимагає підключення її до мережі. Накладаються умови дозволяють зробити вибір типу та конфігурації конкретної ЕОМ, типу і версії операційної системи.

У зв'язку з подальшим збільшенням обсягу оброблюваної інформації, у зв'язку з швидким розвитком прикладних програмних продуктів надають додаткові послуги з обробки даних та їх експорту, імпорту, доцільно вибрати, незважаючи на високу ціну даного програмного продукту, Microsoft Access 2002, під керуванням багатокористувацької операційної системи Microsoft Windows 98.

Від обраного програмного забезпечення вибираються параметри самої ЕОМ.

Процесор Pentium III або швидший, пам'ять 128 МБ ОЗУ. Вимоги до обсягу вільного місця на жорсткому диску залежать від конфігурації. При вибірковій установці може потрібно більше або менше місця на диску. При стандартній установці потрібно 170 МБ вільного місця на жорсткому диску і додатково 115 МБ на диску, де встановлена ​​операційна система; користувачам, у яких не встановлені продукти Windows 2000, Windows Me або Office 2000 Service Release 1 (SR-1), потрібно додатково 50 МБ для оновлення системних файлів. Необхідними є також пристрій для читання компакт-дисків, монітор Super VGA (800x600) або з більш високою роздільною здатністю з підтримкою 256 кольорів, миша Microsoft Mouse, Microsoft IntelliMouse або сумісний вказівний пристрій. При роботі з мультимедіа та звуком для покращеного відображення графіки потрібно відеоплата, підтримуюча прискорення графіки, або процесор, що підтримує набір команд MMX [1].

2.2 Обсяг зовнішньої пам'яті займаний модулями СУБД

Обсяг зовнішньої пам'яті займаний модулями СУБД визначається практично по створеній базі даних. Розмір проектованої бази даних «Автовокзал» становить 1478656 байт.

2.3 Обсяг пам'яті, що відводиться під дані

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

Розглянемо відношення «Автокомпанії».

Число атрибутів відносини а = 4. Число автокомпаній знаходяться в БД автовокзалу вибираємо імовірно рівним десяти одиницям, тобто потужність відносини m = 10. Дані зведені в таблицю 3.1

Таблиця 3.1 - Автокомпанії

Автокомпанія

Номер ліцензії

Адреса офісу

Телефон головного менеджера

30 байт

4 байти

50 байт

20

Тоді розмір під дані таблиці становить

D Автокомпанія = (30 +4 +50 +20) * 10 = 1040 байт.

Розглянемо відношення «Маршрутів».

Число атрибутів відносини а = 7. Число маршрутів на місяць приймаємо рівним 600, тобто потужність відносини m = 600. Дані зведені в таблицю 3.2

Таблиця 3.2 - Маршрути

Код маршруту

рейсу

Дата відправлення

Час відправлення

Реєстраційний знак

екіпажу

Кількість проданих квитків

4 байти

4 байти

8 байт

8 байт

4 байти

4 байти

4 байти

Тоді розмір під дані таблиці становить

D Маршрути = (4 +4 +8 +8 +4 +4 +4) * 600 = 21600 байт

Розглянемо відношення «Марки автобуса».

Число автобусів відносини а = 6. Число марок автобусів вибирається рівним 15, тобто потужність відносини m = 15. Дані зведені в таблицю 3.3

Таблиця 3.3 - Марки автобусів

Марка автобусів

Код автобуса

Кількість місць

Марка палива

Обсяг паливного бака

Група допуску

20 байт

4 байти

4 байти

10 байт

4 байти

4 байти

Тоді розмір під дані таблиці становить

D Марки автобусів = (20 +4 +4 +10 +4 +4) * 15 = 690 байт

Розглянемо відношення «Рейси».

Число атрибутів відносини а = 6. Число рейсів приймаємо рівним 100, тобто потужність відносини m = 100. Дані зведені в таблицю 3.4

Таблиця 3.4-Рейси

рейсу

Місце відправлення

Місце призначення

Час в дорозі

Відстань

Проміжні зупинки

4 байти

20 байт

20 байт

8 байт

4 байти

20 байт

Тоді розмір під дані таблиці становить

D Рейси = (4 +20 +20 +8 +4 +20) * 100 = 7600 байт

Розглянемо відношення «Автобуси».

Число атрибутів відносини а = 3. Число повітряних засобів з присвоєним реєстраційним знаком приймаємо рівним 50, тобто потужність відносини m = 50. Дані зведені в таблицю 3.5

Таблиця 3.5-Автобуси

Реєстраційний знак

Марка автобуса

Автокомпанія

4 байти

20 байт

30 байт

Тоді розмір під дані таблиці становить

D Автобуси = (4 +20 +30) * 50 = 2700 байт

Розглянемо відношення «Склад екіпажу».

Число атрибутів відносини а = 6. Потужність відносини приймаємо рівним 70, тобто m = 70. Дані зведені в таблицю 3.6

Таблиця 3.6-Склад екіпажу

Код складу екіпажу

Прізвище

Ім'я

По батькові

екіпажу

4 байти

20 байт

20 байт

20 байт

4 байти

Тоді розмір під дані таблиці становить

D Склад екіпажу = (4 +20 +20 +20 +20 +4) * 70 = 6160 байт

Розглянемо відношення «Екіпажі».

Число атрибутів відносини а = 3. Потужність відносини приймаємо рівним 55, тобто m = 55. Дані зведені в таблицю 3.7

Таблиця 3.7-Екіпажі

екіпажу

Група допуску

Медичний висновок

4 байти

4 байти

10 байт

Тоді розмір під дані таблиці становить

D Екіпажі = (4 +4 +10) * 55 = 990 байт

Тоді сумарний обсяг пам'яті відводиться під дані

D = D Автокомпанія + D Маршрути + D Марки автобусів + D Рейси + D автобуси + D Склад екіпажу + D Екіпажі = 1040 +21600 +690 +7600 +2700 +6160 +990 = 40780 байт = 40,78 Кбайт

2.4 Уявлення про характер і інтенсивності запиту

Диспетчерська служба для кожного маршруту за певним рейсу повинна підібрати таку марку автобуса, яка задовольняє таким вимогам:

- Дальність маршруту автобуса повинна бути більше або дорівнює відстані між пунктами відправлення та призначення відповідного рейсу;

- Необхідно підібрати екіпаж група допуску, якого повинна бути рівна або вище відповідної групи допуску самого автобуса,

- Кількість пасажирських місць в автобусі повинно бути більше або дорівнює проданим квиткам для відповідного рейсу.

Операція по вибірці автобуса, екіпажу для маршруту, за відповідними умовами виконується диспетчерами приблизно від 20 разів за добу. Для забезпечення операції по вибірці реалізований запит на вибірку - «Вибірка автобуса-екіпажу для маршруту».

Диспетчер з отриманих результатів запиту аналізує ситуацію і в таблицю маршрутів заносить дані.

За даними таблиці маршрутів обслуговуючий персонал автовокзалу повинен підготувати вибраний автобус до маршруту. Для цього за запитом - «Технічне обслуговування».

У зв'язку з потенційними проблемами і надзвичайними ситуаціями з автобусами існує необхідність оповіщення відповідних автокомпаній про позаштатних ситуаціях. Для такого роду інформаційної підтримки існує запит на вибірку - «відповідність Автобуси-Автокомпанії».

3. Вибір СУБД

Система управління базами даних призначена для централізованого управління базою даних в інтересах всіх працюючих в цій системі. Використовувані в даний час СУБД володіють засобами забезпечення цілісності даних і надійної безпеки, що дає можливість розробникам гарантувати більшу безпеку даних при менших витратах сил на низькорівневе програмування. Програмні продукти для БД функціонують у середовищі Windows вигідно відрізняються зручністю для користувача інтерфейсу і вбудованими засобами підвищення продуктивності. Порівняємо основні характеристики деяких СУБД - лідерів на ринку програмного забезпечення для БД. До числа таких відносяться: dBase, Microsoft Access, Microsoft FoxPro, Paradox [1].

Спочатку проектування реляційної бази даних накладає обмеження на вибір СУБД. Одним з можливих засобів створення реляційної бази даних на фізичному рівні є Access.

Коло користувачів створюваної бази даних для автовокзал складається, як раніше наголошувалося з диспетчерського персоналу та персоналу здійснює технічне обслуговування автобусів. Для задоволення потреб виділених користувачів СУБД повинна містити в собі інструменти необхідні для забезпечення безпеки, тому що технічний персонал не повинен мати можливість зміни даних про маршрути, рейсах, автокомпаніях, а дані про автобусах повинні бути надані у користування технічному персоналу. Добрими характеристиками безпеки відрізняється Access. Ця СУБД передбачає призначення паролів для індивідуальних користувачів або груп користувачів, і присвоєння різних прав доступу до окремих таблиць, запитам, звітам, макрокоманд і новим об'єктам на рівні користувача або груп.

Необхідність використання бази даних для відносно великого числа користувачів накладає додаткові вимоги на вибір СУБД і системно програмного забезпечення, зокрема обрана СУБД повинна працювати в многопользовательских середовищах. Кращими можливостями для роботи в многопользовательских середовищах мають Paradox і Access [2]. Зазначені СУБД мають наприклад наступними можливостями:

- Блокування БД, файлу, записи;

- Ідентифікація станції, що встановила блокування;

- Оновлення інформації після блокування;

- Контроль за часом і повторенням обігу;

- Обробка транзакцій (послідовність операцій користувача над БД, яка зберігає свою логічну цілісність).

Однією з основних завдань яку повинні вирішувати СУБД полягає в забезпеченні цілісності даних. Ця характеристика має на увазі наявність засобів, що дозволяють упевниться, що інформація в БД завжди залишається коректною і повною. Повинні бути встановлені правила цілісності дотримуються на глобальному рівні. До засобів забезпечення цілісності даних на рівні СУБД відносять:

- Вбудовані засоби для призначення первинного ключа;

- Засіб підтримки посилальної цілісності, які забезпечують запис інформації про зв'язки таблиць і автоматично припиняють будь-яку операцію приводить до порушення цілісності.

Деякі СУБД мають добре розроблений процесор для реалізації таких можливостей як унікальність первинних ключів, обмеження операцій, каскадне оновлення та видалення інформації. СУБД Access і Paradox набагато ближче інших СУБД відповідають реляційної моделі по надійності збереження цілісності данних.на рівні БД; правила зберігаються в БД і автоматично оновлюються [1].

СУБД володіють доступом даних за допомогою мови запитів SQL (Structured Query Language - мова структурованих запитів). Мова SQL в силу свого широкого застосування є міжнародним стандартом мов запитів. Мова надає розвинені можливості як кінцевим користувачам, так і фахівцям в обробці даних. Працює з SQL системами відіграє велику роль коли передбачається проведення робіт з корпоративними даними. СУБД мають доступ до даних SQL якщо бази даних сумісні з ODBC (Open Database Connectivity - відкрите з'єднання баз даних). За допомогою Access можна безпосередньо керувати базами даних за допомогою SQL і передавати наскрізні SQL-запити спільними зі специфікацією ODBC SQL-базами даних. Так що Access здатна служити засобом розробки масштабованих систем клієнт-сервер [3].

Крім того СУБД Access входить в пакет програм Microsoft Office, і має добре організовані зв'язки з такими програмами як Excel, Word. Дана взаємодія забезпечує потенційну можливість збільшення функціональних здібностей Access. Наявність у складі Access мови програмування високого рівня Visual Basic дозволяє створювати макрокоманди і процедури для більш гнучкого поводження з даними.

В даний час Access є визнаним стандартом для створення і ведення порівняно малих БД. Access дозволяє імпортувати в свій формат більшість файлів БД реляційного типу і експортувати їх далі. Володіє зручним для користувача - непрограмістів інтерфейсом і веде розгорнутий діалог з коментарями. Access володіє високими характеристиками продуктивності, надає своїм користувачам досить широкі функціональні можливості для реалізації потреб і подальшого розвитку ІС.

Виходячи з проведеного аналізу для реалізації проектованої реляційної БД автовокзалу вибирається Access.

4. Логічне проектування БД

Логічне проектування починається з побудови універсальної таблиці (реляційного відносини), яка задовольняє вимогу першої нормальної форми (1НФ), тобто в універсальній таблиці є закономірне «один факт в одному місці». Побудова універсальної таблиці ведеться виходячи з проведеного аналізу предметної області. Універсальна таблиця для проектованої бази даних автовокзалу наведена у додатку Б.

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

Для приведення універсальної таблиці до другої нормальної форми (2НФ) необхідно щоб усі поля кожного реляційного відношення не входять в первинний ключ відповідного ставлення, були пов'язані повної функціональної залежністю з первинним ключем. Для цього проведемо додатковий аналіз, виділивши складовою первинний ключ універсальної таблиці.

Припустимо, що кожен рейс має унікальний номер, що відноситься до єдиного місця відправлення і єдиному місця призначення, часу в дорозі, відстані, проміжним зупинок. Отже, номер рейсу однозначно визначає вказані атрибути.

Автокомпанії мають унікальні назви. Автокомпанія має єдину адресу, телефон головного менеджера і номер ліцензії.

Марка автобуса однозначно описує його технічні характеристики код автобуса, такі як кількість місць, дальність шляху, марка палива, об'єм паливного бака.

Номер екіпажу унікальний для групи допуску, медичного висновку про здоров'я всього екіпажу перед виїздом.

У базі даних існує нумерований список екіпажу, що має такі атрибути як прізвище, ім'я, по батькові.

Код маршруту унікальний для дати відправлення, часу відправлення, кількість проданих квитків. Маршрут робить нумерований реєстраційний знак (автобус) який є унікальним для марки автобуса і назви автокомпанії.

Тоді в якості первинного ключа універсальної таблиці можна використовувати наступний набір атрибутів.

Код маршруту, № рейсу, № екіпажу, Код складу екіпажу, Реєстраційний знак, Марка автобуса, Назва автокомпанії.

Виділимо в окремі таблиці відомості про маршрути, рейсах, автобусах, марках автобусах, автокомпаній, екіпажах та склад екіпажів. Дані відносини представлені в додатку В.

До другої нормальної формі наведені всі таблиці додатка В, а оскільки в них немає неключових полів, функціонально залежать один від одного, то всі вони знаходяться в третій нормальній формі (ЗНФ).

Отримані в додатку В таблиці є повною декомпозицією універсальної таблиці. У кожній з отриманих таблиць відсутні нетривіальні багатозначні залежності, а отже всі відносини додатка В знаходяться і в четвертій нормальній формі (4НФ).

Перетворимо ER-діаграму в схему бази даних. Дане перетворення представлено в додатку Г.

4.1 Обмеження цілісності

Опишемо проектовану базу даних на мові ЯІМ із зазначенням ключів та інших обмежень цілісності.

ТАБЛИЦЯ Автокомпанії (позначаються сутність, позначає Автобуси)

ПЕРВИННИЙ КЛЮЧ (Автокомпанія)

ПОЛЯ (Автокомпанія - Текст 50, Номер ліцензії - довгі ціле, Адреса офісу - Текст 50, Тел. Гол менеджера - Текст 50)

ОБМЕЖЕННЯ (Значення поля Автокомпанія повинні бути унікальні, при порушенні висновок повідомлення «Така автокомпанія вже є»)

ТАБЛИЦЯ Марки автобусів (позначаються сутність, позначає автобуси)

ПЕРВИННИЙ КЛЮЧ (Марка автобусів)

ПОЛЯ (Марка автобусів - Текст 50, Кількість місць - довгі ціле, Дальність маршруту - Текст 50, Марка палива - Текст 50, Об'єм паливного бака - довгі ціле, Група допуску - довгі ціле)

ОБМЕЖЕННЯ (Значення поля Марка автобуса повинні бути унікальні, при порушенні висновок повідомлення «Така марка автобуса вже є»)

ТАБЛИЦЯ Автобуси (Стрижнева сутність)

ПЕРВИННИЙ КЛЮЧ (Реєстраційний знак)

ЗОВНІШНІЙ КЛЮЧ (Марка автобусів З Марки автобусів

NULL - значення Не допустимо

ВИДАЛЕННЯ З Марки автобусів КАСКАДІРУЮТСЯ

ОНОВЛЕННЯ Марки автобусів. Марка автобуса КАСКАДІРУЮТСЯ

ЗОВНІШНІЙ КЛЮЧ (Автокомпанія З Автокомпанії

NULL - значення Не допустимо

ВИДАЛЕННЯ З Автокомпанії КАСКАДІРУЕТСЯ

ОНОВЛЕННЯ Автокомпанії. Автокомпанія КАСКАДІРУЮТСЯ

ПОЛЯ (Реєстраційний знак - довгі ціле, Марка автобуса - Текст 50, Автокомпанія - Текст 50)

ОБМЕЖЕННЯ (1.Значення поля Реєстраційного знака повинні бути унікальні, при порушенні висновок повідомлення «Такий реєстраційний номер вже є»

2. Значення полів Марка автобуса і Автокомпанія повинні належати набору значень з відповідних полів таблиць Марки автобусів і Автокомпанії)

ТАБЛИЦЯ Екіпажі (Стрижнева сутність)

ПЕРВИННИЙ КЛЮЧ (№ екіпажу)

ПОЛЯ (№ екіпажу - довгі ціле, Група допуску - довгі ціле, Медичний висновок - Текст 50)

ОБМЕЖЕННЯ (Значення поля № екіпажу повинні бути унікальні, при порушенні висновок повідомлення «Такий № екіпажу вже є»)

ТАБЛИЦЯ Склад екіпажу (характеризуються сутність, характеризує Екіпажі)

ПЕРВИННИЙ КЛЮЧ (Код складу екіпажу)

ЗОВНІШНІЙ КЛЮЧ (№ екіпажу ІЗ Екіпажі

NULL - значення Не допустимо

ВИДАЛЕННЯ З Екіпажі КАСКАДІРУЕТСЯ

ОНОВЛЕННЯ Екіпажі. № екіпажу КАСКАДІРУЕТСЯ

ПОЛЯ (Код складу екіпажу - Лічильник, Прізвище - Текст 50, Ім'я - Текст 50, По батькові - Текст 50, № екіпажу - довгі ціле)

ОБМЕЖЕННЯ (Значення поля № екіпажу повинні належати набору значень з відповідного поля таблиці Екіпажі)

ТАБЛИЦЯ Рейси (Стрижнева сутність)

ПЕРВИННИЙ КЛЮЧ (№ рейсу)

ПОЛЯ (№ рейсу - довгі ціле, Місце відправлення - Текст 50, Місце призначення - Текст -50, Час у дорозі - Час, Відстань - Довге ціле, Проміжні зупинки - Текст -50)

ОБМЕЖЕННЯ (Значення поля № рейсу повинні бути унікальні, при порушенні висновок повідомлення «Такий № рейсу вже є»)

ТАБЛИЦЯ Вильоти (Асоціативна сутність, пов'язує Рейси, Автобуси, Екіпажі)

ПЕРВИННИЙ КЛЮЧ (Код Маршруту)

ЗОВНІШНІЙ КЛЮЧ (№ рейсу З Рейси

NULL - значення Не допустимо

ВИДАЛЕННЯ З Рейси КАСКАДІРУЕТСЯ

ОНОВЛЕННЯ Рейси. № рейсу КАСКАДІРУЕТСЯ

ЗОВНІШНІЙ КЛЮЧ (Реєстраційний знак ІЗ Автобуси

NULL - значення Не допустимо

ВИДАЛЕННЯ З Автобуси КАСКАДІРУЕТСЯ

ОНОВЛЕННЯ Автобуси. Реєстраційний знак КАСКАДІРУЕТСЯ

ЗОВНІШНІЙ КЛЮЧ (№ екіпажу ІЗ Екіпажі

NULL - значення Не допустимо

ВИДАЛЕННЯ З Екіпажі КАСКАДІРУЕТСЯ

ОНОВЛЕННЯ Екіпажі. № екіпажу КАСКАДІРУЕТСЯ

ПОЛЯ (Код вильоту - Лічильник, № рейсу - довгі ціле, Дата відправлення - Дата, Час відправлення - Час, № екіпажу - довгі ціле, Кількість проданих квитків - довгі ціле)

ОБМЕЖЕННЯ (Значення полів № рейсу, Реєстраційний номер, № екіпажу повинні належати набору значень з відповідних полів таблиць Рейси, Автобуси, Екіпажі).

5. Фізичне проектування БД

Фізичне проектування бази даних автовокзалу проходить в СУБД Microsoft Access.

Створюються таблиці.

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

Автокомпанія

Номер ліцензії

Адреса офісу

Телефон гол. менеджера

Депо № 1

1587456

Саратов Перн 23-5

(882) -45-564-45

Депо № 2

1587455

Саратов Перн 23-5

(882) -45-564-45

Депо № 3

1587454

Саратов Перн 23-5

(882) -45-564-45

Депо № 4

1584444

Балаково вул. Новосельцева 256-45 / Г

(092) -8-78-78

...

...

...

...

Таблиця «Маршрути» містить фактичні маршрути по заданих рейсам

Код маршруту

рейсу

Дата відправлення

Час відправлення

Реєстраційний знак

екіпажу

Кількість проданих квитків

1

1

26.03.99

14:53

Н775КУ 64 rus

1

89

2

2

1,04.00

16:22

Н776КУ 64 rus

2

144

3

3

25.05.02

1:30

Н777КУ 64 rus

3

44

4

4

10.12.03

21:40

Н74КУ 64 rus

4

38

5

4

10.11.03

21:40

Н77КУ 64 rus

4

38

5

4

10.10.03

21:40

Н75КУ 64 rus

4

38

Таблиця «Марки автобусів» містить технічні характеристики автобусів

Марка автобуса

Код автобуса

Кількість місць

Марка палива

Обсяг паливного бака

Ікарус

1

150

ДП

150


...

...

...

...

ЛІАЗ

2

50

АІ-80

100

ПАЗ

3

60

АІ-80

90

ПАЗ

4

70

АІ-80

90

Таблиця «Рейси»

рейсу

Місце відправлення

Місце призначення

Час в дорозі

Відстань

Проміжні зупинки

1

Саратов

Москва

25

2000


2

Саратов

Петербург

30

2500

Москва

3

Саратов

Тамбов

22

1800


4

Саратов

Уфа

12

1000


...

...

...

...

...

...

Таблиця «Автобуси» містить відомості про номер реєстраційного знака кошти належить тій чи іншій автокомпанії.

Реєстраційний знак

Марка автобуса

Автокомпанія

Н775КУ 64 rus

Ікарус

Депо № 1

Н776КУ 64 rus

Ікарус

Депо № 2

Н777КУ 64 rus

Ікарус

Депо № 3

Н74КУ 64 rus

ЛІАЗ

Депо № 4

Н77КУ 64 rus

ПАЗ

Депо № 4

Н75КУ 64 rus

ПАЗ

Депо № 4

Таблиця «Склад екіпажу» містить відомості про шоферах що входять в той чи інший екіпаж

Код складу екіпажу

Прізвище

Ім'я

По батькові

екіпажу

1

Кучеров

Володимир

Петрович

4

2

Михайло

Сергій

Павлович

4

3

Кудрявцев

Петро

Ілліч

4

4

Кудряшов

Михайло

Васильович

3

5

Твордской

Олексій

Михайлович

2

6

Ларін

Сергій

Петрович

1

Таблиця «Екіпажі»

екіпажу

Група допуску

Медичне висновків

1

Е

придатний

2

Е

придатний

3

Е

придатний

4

Е

придатний

5

Е

придатний

6

Е

придатний

Створюються форми.

Форма «Автокомпанії»

Форма «Маршрути»

Форма «Марки автобусів»

Форма «Склад екіпажів»

Створюються запити.

Запит на вибірку «Вибір автобуса-екіпажу для маршруту» за задається рейсу.

рейсу

Марка автобуса

Дальність маршруту

Екіпажу

Кількість місць

4

Ікарус

1000

1

150

4

Ікарус

1000

2

150

4

Ікарус

1000

2

150

4

ЛІАЗ

1000

2

50

4

ПАЗ

1000

4

60

4

ПАЗ

1000

4

70

Запит «На вибірку по маршрутах».

рейсу

Дата відправлення

Час відправлення

1

26.09.99

14:53

2

01.04.00

16:22

3

25.05.02

1:30

4

10.12.03

21:40

4

10.11.03

21:40

4

10.10.03

21:40

Запит «відповідність автобуси-Автокомпанії».

Реєстраційний знак

Марка автобуса

Автокомпанія

Телефон гол. менеджера

Н775КУ 64 rus

Ікарус

Депо № 1

(882) -45-564-45

Н776КУ 64 rus

Ікарус

Депо № 2

(882) -45-564-45

Н777КУ 64 rus

Ікарус

Депо № 3

(882) -45-564-45

Н74КУ 64 rus

ЛІАЗ

Депо № 4

(092) -8-78-78

Н77КУ 64 rus

ПАЗ

Депо № 4

(092) -8-78-78

Н75КУ 64 rus

ПАЗ

Депо № 4

(092) -8-78-78

Створюються звіти.

Звіт «Автокомпанії» у додатку Д.

Звіт «Маршрути» у додаток Є.

Звіт «Існуючі рейси» у додатку Ж.

6. Висновок

У процесі проектування реляційної БД автовокзалу були вивчені матеріали дозволяють описувати предметну інформаційну систему з допомогою ЯІМ, ER-діаграм, вивчені принципи побудови инфологической моделі і реляційних відносин задовольняють 1НФ, 2НФ, 3НФ, 4НФ, а також опис відносин і БД у цілому з обмеженням цілісності .

Список літератури

1 Макарова Н.В. Інформатика. - 2-е вид. -М.: Фінанси і статистика, 1998 .- 768с.

2 Карпов Б.В Microsoft Access 2000 Довідник.-1-е вид. -М.: Пітер, 2000.-416 с.

3 Синьова Н.Ф. Створення реляційних баз даних в MS Access. -1-е вид. -Саратов: Копіпрінтер СГТУ, 1996.-40 с.

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
142.9кб. | скачати


Схожі роботи:
Проектування системи управління базою даних
Розробка систем управління базою даних MySQL
Розробка системи управління базою даних будівельної фірми
Проектування створення і управління базою даних Палітурна майстерня в пакеті MS Access
Робота з базою даних в MS Access
Система управління базами даних 2
Система управління базами даних Access
Система управління базами даних FoxPro
Реляційна модель даних у системах управління базами даних
© Усі права захищені
написати до нас