Облік діяльності автотранспортного підприємства

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

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

Завдання

Виконати специфікацію вимог до кожного з двох користувачів у тому числі: розробити вимоги до даних; розробити вимоги до транзакцій

1. Специфікація вимог для кожного з двох користувачів

Специфікація вимог до даних для користувача «Диспетчер»:

Збір та аналіз вимог користувача «Диспетчер» здійснювався в офісі відділення автотранспортного підприємства (АТП). Було проведено опитування співробітників, які працюють на посадах диспетчерів. Також була проаналізована вся документація, яка використовувалася даною групою співробітників. На основі цього аналізу була підготовлена специфікація вимог до інформації, що буде вміщена в створювану базу даних, а також були визначені всі трансакції, необхідні диспетчерам для успішного виконання їхніх службових обов'язків.

Вимоги до даних для користувача «Диспетчер»:

1. У кожному відділенні АТП є персонал, що відповідає за розподіл вантажних перевезень, тобто за оформлення та видачу подорожніх листів (ПЛ) водіям, що оформлюються на основі товарно-транспортної накладної (ТТН), яку попередньо оформив клієнт.

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

3. Дані про авторейси (майбутні, та вже здійснені) можна отримати у будь-якому відділенні АТП. Дані про авторейс мають бути наступні: унікальний номер авторейсу, напрям перевезення, час та дата відправлення та час і дата прибуття.

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

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

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

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

8. До обов'язків персоналу, що займається оформлення ПЛ та видачею їх водіям входять наступні:

- Оформлення документів ПЛ на основі ТТН.

- Видача документів ПЛ та ТТН водіям.

Вимоги до транзакцій для користувача «Диспетчер»:

1) Складання списку клієнтів, вантаж яких був перевезений у певному напрямі.

2) Надання інформації клієнтам про напрями та строки вантажних та кур'єрських перевезень.

Вимоги до даних для користувача «Головний інженер підприємства»:

1. У кожному відділенні АТП є персонал, що здійснює налагодження та ремонт наявних на підприємстві автомобілів - механіки, що знаходяться під керівництвом головного інженера-механіка підприємства.

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

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

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

Вимоги до транзакцій для користувача «Головний інженер підприємства»:

1) Контроль всіх співробітників компанії та перегляд даних про них;

2) Перегляд всіх механіків, що здійснювали ремонтно-технічні роботи в розрізі кожного автомобіля;

3) Перегляд списку автомобілів, що транспортували вантаж у певному напрямі.

2. Концептуальне проектування бази даних (кроки 1.1 - 1.7)

Етап 1.1. Визначити типи сутностей

Основними типами сутностей, що згадуються у специфікаціях користувачів є наступні:

1. Відділення

2. Працівник

3. Диспетчер

4. Водій

5. Механік

6. Головний інженер підприємства

7. Автомобіль

8. Товарно-транспортна накладна (ТТН)

9. Подорожній лист (ПЛ)

10. Клієнт - фізична особа

11. Клієнт - юридична особа

12. Рейс

13. Напрям

Документування виділених типів сутностей

Зведення про виділені атрибути і їх приналежність відповідним сутностям та зв'язкам наведені в табл. 1.2.

Таблиця 1.2. Атрибути, які належать сутностям

Документування виділених атрибутів

У документацію необхідно помістити докладні зведення про атрибути, перераховані у табл.1..2. Для кожного атрибута варто вказати загальний опис, тип даних і довжину значення, наявні обмеження, значення за замовчуванням (якщо таке є), псевдоніми (якщо такі існують), а також є атрибут складеним або похідним і чи припустиме для нього значення NULL. Фрагмент подібного документа наведений у кінці цього розділу (Додаток В).

Етап 1.4. Визначення доменів атрибутів

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

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

Етап 1.5. Визначити атрибути, що є потенційними і первинними ключами

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

Таблиця 1.3. Сутності і їх первинні й альтернативні ключі

Сутність	Первинний ключ	Альтернативний ключ
Відділення	Номер	Телефон
Працівник	Табельний Номер
Клієнт - фіз. особа	Номер
Клієнт - юр. особа	Номер	Телефон
Автомобіль	Номер	Номер двигуна
ТТН	Номер
ПЛ	Номер
Рейс	Номер
Напрям	Номер

Етап 1.6. Спеціалізація/генералізація типів сутностей

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

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

Рис. 13. Суперклас Працівник

Як показано в таблиці 1.2, всі атрибути сутності Працівник, уключаючи і первинний ключ, присутні також у сутностях Головний інженер, Диспетчер, Водій та Механік. Однак кожна з цих сутностей бере участь у різних зв'язках, наприклад у таких, як Головний інженер керує Механіками і Механіки ремонтують автомобілі. На підставі цих зведень ми приймаємо рішення провести генералізацію сутностей Головний інженер, Диспетчер, Механік і Водій. Вони будуть представлені як підкласи суперкласу Працівник. Зв'язки, що суперклас "підтримує" зі своїми під класами, є частковими і непересічними,

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

Рис.14. Суперклас „Клієнт” і його підкласи „Фізична особа” і „Юридична особа”

Також розглянемо взаємини між сутностями, що представляють клієнтів АТП. У специфікаціях визначено два типи подібних сутностей - Клієнт-фізична особа і Клієнт-юридична особа. Як видно з таблиць 1.1 і 1.2, ці сутності розділяють кілька загальних атрибутів (Номер, Адреса, Телефон), а також підтримують той самий зв'язок (Оформлюють ТТН), як показано на рисунку 6. Однак є й атрибути, специфічні для сутностей Клієнт - фізична особа (Ім'я і Прізвище) і Клієнт - юридична особа (Назва, Тип і Ім'я для контактів). З усього цього випливає, що дані сутності представляють різні типи клієнтів, що оформлюють ТТН.

Етап 1.6. Створення діаграми сутність-зв'язок

Із метою одержання наочного представлення основних сутностей і зв'язків, визначених у специфікаціях, ми побудували вихідну ER-діаграму, яка має вигляд, показаний на рисунку 15 (для представлення користувача Головний інженер підприємства) та на рисунку 16 (Диспетчер). Ці ER-діаграми являють собою локальну концептуальну модель даних.

Рис. 15. Локальна концептуальна модель даних для представлення користувача Головний інженер підприємства

Рис. 16. Локальна концептуальна модель даних для представлення користувача Диспетчер

3. Логічне проектування бази даних (кроки 2.1 - 2.6, 3.1 - 3.4)

Етап 2. Побудувати і перевірити локальну логічну модель даних на основі представлення про предметну область кожного з типів користувачів

Етап 2.1. Перетворити локальну концептуальну модель даних у локальну логічну модель

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

1. Видалення зв'язків типу M:N.

2. Видалення складних зв'язків.

3. Видалення рекурсивних зв'язків.

4. Видалення зв'язків, що мають атрибути.

5. Видалення множинних атрибутів.

6. Повторний огляд зв'язків типу 1:1.

7. Видалення надлишкових зв'язків.

Видалення зв'язків типу M:N

Рис. 17. Видалення зв'язку типу M : N “Механік ремонтує автомобілі”

Як видно з рисунка локальної концептуальної моделі з представлення користувача Головний інженер підприємства, зв`язок «Механік Ремонтує Автомобілі» має кардинальність «багато до багатьох» (M : N). Тому необхідно перетворити зв`язок Ремонтує у два зв`язки типу 1:М (Назвемо їх Здійснює та Підлягає), як показано на рис. 17, для чого буде потрібно ввести слабку сутність Ремонт. Оскільки знову створена сутність є слабкою, первинний ключ сутності Ремонт буде цілком або частково визначатися сутностями-власниками, тобто сутностями Механік і Автомобіль.

Видалення складних зв'язків

На ER-діаграмі відсутні будь які складні (не бінарні зв'язки). Усі зв'язки в концептуальній моделі є бінарними, тобто будь-який зв'язок існує тільки між двома сутностями.

Видалення рекурсивних зв'язків

Рекурсивних зв'язків у концептуальній моделі не було виявлено.

Видалення зв'язків, що мають атрибути

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

Видалення множинних атрибутів

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

Повторний огляд зв'язків типу 1:1

У деяких випадках сутності, що беруть участь у зв'язку 1:1, можуть фактично представляти різні аспекти того самого об`єкта. З цієї причини рекомендується знову проаналізувати зміст усіх зв'язків типу 1:1, що існують у моделі даних. У нашому прикладі є зв'язки цього типу, наприклад Водій Має Авто, однак зовсім очевидно, що сутності, що беруть участь у ньому, представляють різні об`єкти реального світу.

Видалення надлишкових зв'язків

У ER-діаграмі надлишкових зв'язків не виявлено.

Етап 2.2. Визначити набір відношень, вихочи зі структури локальної логічної моделі даних

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

Відношення для представлення користувача Головний інженер підприємства:

ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).

Первинний ключ - Номер_Відділення.

ПРАЦІВНИК (Номер_Працівника, Ім'я, Прізвище, По-батькові, Адреса, Телефон, Стать, Посада).

Первинний ключ - Номер_Працівника.

Зовнішній ключ - Номер_Відділення посилання Відділення(Номер_Відділення).

АВТОМОБІЛЬ (Номер_Автомобіля, Номер_Двигуна, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність)

Первинний ключ - Номер_Автомобіля.

Зовнішній ключ - Номер_Водія посилання Працівник(Номер_Працівника).

ПЛ (Номер_Документу, Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж)

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер_Автомобіля посилання Автомобіль (Номер_Автомобіля).

Зовнішній ключ - Номер_Рейсу посилання Рейс(Номер_Рейсу).

РЕМОНТ (Номер_Працівника, Номер_Автомобіля)

Первинний ключ - Номер_Працівника, Номер_Автомобіля.

Зовнішній ключ - Номер_Працівника посилання Працівник(Номер_Працівника).

Зовнішній ключ - Номер_ Автомобіля посилання Автомобіль (Номер_ Автомобіля).

НАПРЯМ (Номер_Напряму, Пункт_Відправлення, Пункт_Прибуття)

Первинний ключ - Номер_Напряму.

РЕЙС (Номер_Рейсу, Час_Відправлення, Час_Прибуття)

Первинний ключ - Номер_Рейсу.

Відношення для представлення користувача Диспетчер:

ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).

Первинний ключ - Номер_Відділення.

ПРАЦІВНИК (Номер_Працівника, Ім'я, Прізвище, По-батькові, Адреса, Телефон, Стать, Посада).

Первинний ключ - Номер_Працівника.

Зовнішній ключ - Номер_Відділення посилання Відділення(Номер_Відділення).

КЛІЄНТ-фізична особа (Номер_Клієнта, Прізвище, Ім'я, По-батькові, Стать, Телефон, Адреса).

Первинний ключ - Номер_Клієнта.

КЛІЄНТ-юридична особа (Номер_Клієнта, Тип_Компанії, Найменування, Телефон, Адреса, Ім'я_Представника).

Первинний ключ - Номер_Клієнта.

АВТОМОБІЛЬ (Номер_Автомобіля, Номер_Водія, Номер_Двигуна, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність)

Первинний ключ - Номер_Автомобіля.

Зовнішній ключ - Номер_Водія посилання Працівник(Номер_Працівника).

ТТН (Номер_Документу, Номер_Клієнта, Вантаж, Вага_Вантажу)

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер Клієнта посилання Клієнт (Номер_Клієнта).

ПЛ (Номер_Документу, Номер_ТТН, Номер_Диспетчера, Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж).

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер_ТТН посилання ТТН(Номер_Документу).

Зовнішній ключ - Номер_Диспетчера посилання Працівник(Номер_Працівника).

Зовнішній ключ - Номер_Автомобіля посилання Автомобіль (Номер_Автомобіля).

Зовнішній ключ - Номер_Рейсу посилання Рейс(Номер_Рейсу).

НАПРЯМ (Номер_Напряму, Пункт_Відправлення, Пункт_Прибуття)

Первинний ключ - Номер_Напряму.

РЕЙС (Номер_Рейсу, Час_Відправлення, Час_Прибуття)

Первинний ключ - Номер_Рейсу.

Рис. 18. Локальна логічна модель даних для представлення користувача

Рис. 19. Локальна логічна модель даних для представлення користувача Диспетчер

Етап 2.3 Перевірка моделі за допомогою правил нормалізації

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

· приведення до першої нормальної форми (1НФ), що дозволяє видалити з відношень повторювані групи атрибутів;

· приведення до другої нормальної форми (2НФ), що дозволяє усунути часткову залежність атрибутів від первинного ключа;

· приведення до третьої нормальної форми (ЗНФ), що дозволяє усунути транзитивну залежність атрибутів від первинного ключа;

· приведення до нормальної форми Бойса-Кодда (НФБК), що дозволяє видалити з функціональних залежностей аномалії, що залишилися.

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

Перевірка відношень для користувача Головний інженер підприємства:

ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).

Первинний ключ - Номер_Відділення.

Номер_Відділення Телефон, Факс, Поштовий_Код, E-mail.

ПРАЦІВНИК (Номер_Працівника, Ім'я, Прізвище, По-батькові, Адреса, Телефон, Стать, Посада).

Первинний ключ - Номер_Працівника.

Зовнішній ключ - Номер_Відділення.

Номер_Працівника Ім'я, Прізвище, По-батькові, Адреса, Телефон, Стать, Посада.

АВТОМОБІЛЬ (Номер_Автомобіля, Номер_Двигуна, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність)

Первинний ключ - Номер_Автомобіля.

Зовнішній ключ - Номер_Водія.

Альтернативний ключ - Номер_Двигуна.

Номер_Автомобіля Номер_Двигуна, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність.

Номер_Двигуна Номер_Автомобіля, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність.

ПЛ (Номер_Документу, Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж)

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер_Автомобіля посилання Автомобіль (Номер_Автомобіля).

Зовнішній ключ - Номер_Рейсу посилання Рейс(Номер_Рейсу).

Номер_Документу.

Номер_Документу Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж.

РЕМОНТ (Номер_Працівника, Номер_Автомобіля)

Первинний ключ - Номер_Працівника, Номер_Автомобіля

Зовнішній ключ - Номер_Працівника посилання Працівник(Номер_Працівника)

Зовнішній ключ - Номер_ Автомобіля посилання Автомобіль (Номер_ Автомобіля)

Номер_Працівника Номер_Автомобіля.

Номер_ Автомобіля Номер_ Працівника.

НАПРЯМ (Номер_Напряму, Пункт_Відправлення, Пункт_Прибуття)

Первинний ключ - Номер_Напряму.

Номер_Напряму Пункт_Відправлення, Пункт_Прибуття.

РЕЙС (Номер_Рейсу, Номер_Напряму, Час_Відправлення, Час_Прибуття)

Первинний ключ - Номер_Рейсу.

Номер_Рейсу Номер_Напряму, Час_Відправлення, Час_Прибуття.

Перевірка відношень для користувача Дисптчер:

ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).

Первинний ключ - Номер_Відділення.

Номер_Відділення Телефон, Факс, Поштовий_Код, E-mail.

ПРАЦІВНИК (Номер_Працівника, Ім'я, Прізвище, По-батькові, Адреса, Телефон, Стать, Посада).

Первинний ключ - Номер_Працівника.

Зовнішній ключ - Номер_Відділення посилання Відділення(Номер_Відділення).

Номер_Працівника Ім'я, Прізвище, По-батькові, Адреса, Телефон, Стать, Посада.

КЛІЄНТ-фізична особа (Номер_Клієнта, Прізвище, Ім'я, По-батькові, Стать, Телефон, Адреса).

Первинний ключ - Номер_Клієнта.

Номер_Клієнта Прізвище, Ім'я, По-батькові, Стать, Телефон, Адреса.

КЛІЄНТ-юридична особа (Номер_Клієнта, Тип_Компанії, Найменування, Телефон, Адреса, Ім'я_Представника).

Первинний ключ - Номер_Клієнта.

Альтернативний ключ - Телефон.

Номер_Клієнта Тип_Компанії, Найменування, Телефон, Адреса, Ім'я_Представника.

Телефон Тип_Компанії, Найменування, Адреса, Ім'я_Представника.

АВТОМОБІЛЬ (Номер_Автомобіля, Номер_Водія, Номер_Двигуна, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність)

Первинний ключ - Номер_Автомобіля.

Зовнішній ключ - Номер_Водія.

Альтернативний ключ - Номер_Двигуна.

Номер_Автомобіля Номер_Двигуна, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність.

Номер_Двигуна Номер_Автомобіля, Номер_Кузова, Марка_Авто, Маркування_Моделі, Вантажопідйомність.

ТТН (Номер_Документу, Номер_Клієнта, Вантаж, Вага_Вантажу)

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер Клієнта.

Номер_Документу Номер_Клієнта, Вантаж, Вага_Вантажу.

ПЛ (Номер_Документу, Номер_ТТН, Номер_Диспетчера, Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж).

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер_ТТН посилання ТТН(Номер_Документу).

Зовнішній ключ - Номер_Диспетчера посилання Працівник(Номер_Працівника).

Зовнішній ключ - Номер_Автомобіля посилання Автомобіль (Номер_Автомобіля).

Зовнішній ключ - Номер_Рейсу посилання Рейс(Номер_Рейсу).

Номер_Документу Номер_ТТН, Номер_Диспетчера, Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж.

НАПРЯМ (Номер_Напряму, Пункт_Відправлення, Пункт_Прибуття)

Первинний ключ - Номер_Напряму.

Номер_Напряму Пункт_Відправлення, Пункт_Прибуття.

РЕЙС (Номер_Рейсу, Час_Відправлення, Час_Прибуття)

Первинний ключ - Номер_Рейсу.

Номер_Рейсу Номер_Напряму, Час_Відправлення, Час_Прибуття.

Після виконання процедури перевірки моделі за допомогою правил нормалізації для всіх відношень ми переконалися у тому, що всі відношення відповідають вимогам НФБК.

Етап 2.4. Перевірити модель у відношенні транзакцій користувачів

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

Етап 2.5. Створити діаграму сутність-зв'язок

Остаточний варіант ER-діаграм логічної моделі даних для користувачів Головний інженер підприємства та Диспетчер після виконання усіх перевірок показаний на рисунках 19 та 20 відповідно.



Рис. 19. Локальна логічна модель даних для представлення користувача Головний інженер підприємства (остаточний варіант)

Рис. 20. Локальна логічна модель даних для представлення користувача Диспетчер (остаточний варіант

Етап 2.6 Визначити вимоги підтримки цілісності даних

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

· обов'язкові дані;

· обмеження для доменів атрибутів;

· цілісність сутностей;

· посилальна цілісність;

· вимоги даного підприємства.

Обов'язкові дані

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

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

Обмеження для доменів атрибутів

Домен атрибута встановлює набір припустимих значень, що можуть привласнюватися цьому атрибутові. Наприклад, набір припустимих значень для атрибута Номер сутності Працівник являє собою всі можливі рядки довжиною до 4 символів, що мають значення від 1 до 9999. Приклади доменів атрибутів логічної моделі даних користувача Диспетчер були наведені при виконанні етапу 1.4 і представлені в додатку Г.

Цілісність сутностей

Атрибут первинного ключа сутності не може мати значення NULL. Наприклад, кожен екземпляр сутності Відділення обов'язково повинен мати конкретне значення атрибута його первинного ключа Номер_Відділення. Атрибути, що входять у значення первинного ключа кожної сутності, були визначені при виконанні попередніх етапів Докладні зведення про ключі сутностей представлені в додатку.

Посилальна цілісність

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

Підтримка посилальної цілісності організується за допомогою завдання необхідних обмежень для значень первинних і зовнішніх ключів. Ці обмеження визначають умови, яких слід дотримуватися при відновленні або видаленні значень первинного ключа, а також при вставці або відновленні значень зовнішнього ключа. Відзначимо, що вставка нового значення первинного ключа або видалення значення зовнішнього ключа не викликає яких-небудь проблем з посилальною цілісністю. Для кожного зовнішнього ключа відношення варто вказати умови, що повинні виконуватися при відновленні або видаленні відповідного значення первинного ключа. У цьому випадку можна застосувати одну з пропонованих стратегій - NO ACTION, CASCADE, SET NULL, SET DEFAULT або NO CHECK.

Вимоги даного підприємства

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

Етап 3. Створити і перевірити глобальну логічну модель даних

Етап 3.1. Злити локальну логічну модель даних у єдину глобальну модель даних

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

Аналіз імен сутностей і їхніх первинних ключів

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

Таблиця 3.1. Порівняння імен сутностей і їхніх первинних ключів у представленнях користувачів Головний інженер підприємства і Диспетчер.

Тип сутності (представлення Головний інженер підприємства)	Первинний ключ	Тип сутності (представлення Диспетчер)	Первинний ключ
Відділення	Номер_Відділення	Відділення	Номер_Відділення
Працівник	Номер_Працівника	Працівник	Номер_Працівника
		Клієнт - фізична особа	Номер_Клієнта
		Клієнт - юридична особа	Номер_Клієнта
Автомобіль	Номер_Автомобіля	Автомобіль	Номер_Автомобіля
		ТТН	Номер_Документу
ПЛ	Номер_Документу	ПЛ	Номер_Документу
Напрям	Номер_Напряму	Напрям	Номер_Напряму
Рейс	Номер_Рейсу	Рейс	Номер_Рейсу

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

Аналіз імен зв'язків

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

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

Сутності (представлення Головний інженер підприємства)	Тип зв'язку	Тип сутності (представлення Головний інженер підприємства)	Сутності (представлення Диспетчер)	Тип зв'язку	Тип сутності (представлення Диспетчер)
Відділення	Має	Працівник	Відділення	Має	Працівник
Головний інженер підприємства	Керує	Механік
			Диспетчер	Фіксується у Фіксується у	ТТН ПЛ
			Клієнт - фіз. особа	Оформлює	ТТН
			Клієнт - юр. особа	Оформлює	ТТН
Водій	Має у розпорядженні	Автомобіль	Водій	Має у розпорядженні	Автомобіль
Рейс	Приписаний	ПЛ	Рейс	Приписаний	ПЛ
Напрям	Визначає	Рейс	Напрям	Визначає	Рейс
Механік	Здійснює	Ремонт
Автомобіль	Підлягає	Ремонт
Працівник	Належить до	Відділення	Працівник	Належить до	Відділення
Механік	Знаходиться під керівництвом	Головний інженер підприємства
			ТТН	Містить дані про Містить дані про Фіксується у	Диспетчер Клієнт ПЛ
			ПЛ	Містить дані про Містить дані про Містить дані про Містить дані про	Диспетчер Рейс ТТН Автомобіль
			Автомобіль	Знаходиться у розпорядженні	Водій
Рейс	Здійснюється у	Напрям	Рейс	Здійснюється у	Напрям

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

Злиття загальних сутностей з окремих локальних моделей

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

· злиття сутностей з однаковими іменами й однаковими первинними ключами;

· злиття сутностей з однаковими іменами, що мають різні первинні ключі;

· злиття сутностей з різними іменами, що мають однакові або різні первинні ключі.

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

Такі сутності відсутні

Злиття сутностей з різними іменами, що мають однакові або різні первинні ключі .

Такі сутності відсутні.

Включення (без злиття) сутностей, унікальних для кожного локального представлення.

Глобальне представлення

КЛІЄНТ-фізична особа (Номер_Клієнта, Прізвище, Ім'я, По-батькові, Стать, Телефон, Адреса).

Первинний ключ - Номер_Клієнта.

КЛІЄНТ-юридична особа (Номер_Клієнта, Тип_Компанії, Найменування, Телефон, Адреса, Ім'я_Представника).

Первинний ключ - Номер_Клієнта.

Альтернативний ключ - Телефон.

ТТН (Номер_Документу, Номер_Клієнта, Вантаж, Вага_Вантажу)

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер Клієнта посилання Клієнт (Номер_Клієнта).

ПЛ (Номер_Документу, Номер_ТТН, Номер_Диспетчера, Номер_Автомобіля, Номер_Рейсу, Марка_Пального, Початковий_Об'єм_Пального, Кінцевий_Об'єм_Пального, Кілометраж).

Первинний ключ - Номер_Документу.

Зовнішній ключ - Номер_ТТН посилання ТТН(Номер_Документу).

Зовнішній ключ - Номер_Диспетчера посилання Працівник(Номер_Працівника).

Зовнішній ключ - Номер_Автомобіля посилання Автомобіль (Номер_Автомобіля).

Зовнішній ключ - Номер_Рейсу посилання Рейс(Номер_Рейсу).

Злиття загальних зв'язків з окремих локальних моделей

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

Включення (без злиття) зв'язків, унікальних для кожного локального представлення У таблиці можна виділити зв'язки, що є унікальними для кожного з представлень. Для представлення користувача Головний інженер підприємства виявлені унікальні зв'язки: Механік здійснює Ремонт, Автомобіль підлягає Ремонту, Головний інженер керує Механіками. Для представлення користувача Диспетчер характерні наступні унікальні зв'язки: Диспетчер фіксується у ТТН, Диспетчер фіксується у ПЛ, Клієнт зазначений у ТТН

.

Етап 3.2. Перевірити глобальну логічну модель

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

Перевірка на наявність пропущених сутностей і зв'язків

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

Перевірка коректності зовнішніх ключів

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

Перевірка дотримання обмежень цілісності

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

Етап 3.3. Перевірити можливості розширення моделі в майбутньому

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

Етап 3.4. Створити остаточний варіант діаграми сутність-зв'язок.

Остаточна версія логічного глобального представлення показана на рис. 21.

Рис. 21. Глобальна логічна модель даних

Висновок

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

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

Список літературних джерел

1. Дейт К.Дж. Введение в системы баз данных. 6-е издание. Диалектика. Киев - Москва. 1998 г. 784 с.

2. Хансен Г., Хансен Дж. Базы данных: разработка и управление. Бином. Москва. 1999 г. Пер. с англ. 700 с.

3. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 2-е издание. Вильямс. Москва-Санкт-Петербург-Киев. 2000 г. 1111 с.

4. Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. Санкт-Петербургский Государственный институт точной механики и оптики (технический университет). Кафедра вычислительной техники. - http://www.cs.ifmo.ru

5. С.Д. Кузнецов Основы современных баз данных. Информационно-аналитические материалы. - http://www.citmgu.ru/

Додаток А

Відомості про типи сутностей

Ім'я сутності	Опис	Особливості використання
Відділення	Місце роботи	Одне і більше відділень АТП
Працівник	Загальний термін. Описує весь персонал, який працює у АТП.	Кожен із працівників належить до певного відділення.
Головний інженер	Керуючий	Здійснює контроль над всіма механіками АТП
Диспетчер	Персонал, що відповідає за розподіл вантажних перевезень	Оформлює документи на перевезення, визначає водіїв та автомобілі, що виконають перевезення.
Механік	Персонал, що здійснює ремонтно-технічні роботи на підприємстві	Обслуговує та ремонтує автотранспортні засоби
Клієнт - фіз. особа	Фізична особа, що оформила документ на перевезення	Оформлює документ товарно-транспортна накладна (ТТН)
Клієнт - юр. особа	Юридична особа, організація, що зробила замовлення на перевезення та оформила документ	Оформлює документ товарно-транспортна накладна (ТТН)
Рейс	Певне перевезення	Використовується для ідентифікації перевезення та визначення часу відправлення та часу прибуття
Напрям	Певний маршрут автомобіля	Використовується для відображення пунктів відправлення та прибуття автомобіля
Автомобіль	Автотранспортний засіб	Використовується безпосередньо для здійснення перевезення вантажу
Товарно-транспортна накладна (ТТН)	Документ, в якому виражена домовленість АТП та клієнта про перевезення	Використовується основою для путівного листа.
Путівний лист	Документ, в якому вказані особливості перевезення вантажу	Використовується для визначення особливостей перевезення вантажу

Додаток Б

Зведення про типи зв'язків

Тип сутності	Тип зв'язку	Тип сутності	Кардинальність
Відділення	Має	Працівник	1: М
Головний інженер підприємства	Керує	Механік	1: М
Диспетчер	Фіксується у Фіксується у	ТТН ПЛ	1 : М 1: М
Клієнт - фіз. особа	Оформлює	ТТН	1: М
Клієнт - юр. особа	Оформлює	ТТН	1 : М
Водій	Має у розпорядженні	Автомобіль	1 : 1
Рейс	Приписаний	ПЛ	1 : 1
Напрям	Визначає	Рейс	1: М
Механік	Ремонтує	Автомобіль	М : N
Працівник	Належить до	Відділення	М : 1
Механік	Знаходиться під керівництвом	Головний інженер підприємства	М : 1
ТТН	Містить дані про Містить дані про Фіксується у	Диспетчер Клієнт ПЛ	М : 1 М : 1 1 : 1
ПЛ	Містить дані про Містить дані про Містить дані про Містить дані про	Диспетчер Рейс ТТН Автомобіль	М : 1 1 : 1 1 : 1 М : 1
Автомобіль	Підлягає ремонту з боку Знаходиться у розпорядженні Фіксується у	Механік Водій ПЛ	N:М 1 : 1 1 : 1
Рейс	Здійснюється у	Напрям	M : 1

Додаток В

Зведення про атрибути

Тип сутності	Атрибут	Опис	Тип даних, довжина	Обмеження	Значення за замовчуванням	Псевдонім	Допустимість Null	Похідний
Відділення	Номер	Унікальний ідентифікатор відділення	Символьний, до 3 символів	Первинний ключ			Ні	Ні
	Телефон	Номер телефону відділення	Символьний, фіксований, 13 символів	Альтернативний ключ			Ні	Ні
	Факс	Номер факсу відділення	Символьний, фіксований, 13 символів	Альтернативний ключ			Ні	Ні
	Поштовий код	Поштовий код відділення	Символьний, фіксований, 13 символів	Альтернативний ключ			Ні	Ні
	E-mail	Електронна адреса відділення	Символьний, фіксований, 25 символів	Альтернативний ключ			Так	Ні
Працівник	Номер	Унікальний ідентифікатор співробітника	Символьний, до 5 символів	Первинний ключ			Ні	Ні
	Номер відділення	Унікальний ідентифікатор відділення	Символьний, до 3 символів				Так	Ні
	Повне ім'я	Ім'я працівника (складений атрибут, включає атрибути Прізвище, Ім'я і По-Батькові)
	Ім'я	Ім'я працівника	Символьний, до 15 символів				Ні	Ні
	Прізвище	Прізвище працівника	Символьний, до 15 символів				Ні	Ні
	По-батькові	По-батькові працівника	Символьний, до 20 символів				Ні	Ні
	Адреса	Адреса працівника	Символьний, до 70 символів				Ні	Ні
	Телефон	Номер телефону працівника	Символьний, фіксований, 13 символів				Так	Ні
	Стать	Стать працівника	Символьний, фіксований, 1 символ				Ні	Ні
	Посада	Посада, займана працівником	Символьний до 20 символів				Ні	Ні
Диспетчер	Ті самі, що для сутності Працівник	Визначає працівника, що працює на посаді диспетчера
Механік	Ті самі, що для сутності Працівник	Визначає працівника, що працює на посаді механіка
Водій	Ті самі, що для сутності Працівник	Визначає працівника, що працює на посаді водія
Головний інженер підприємства	Ті самі, що для сутності Працівник	Визначає працівника, що працює на посаді головного інженера
Клієнт - фізична особа	Номер	Унікальний ідентифікатор клієнта	Символьний, до 5 символів	Первинний ключ			Ні	Ні
	Повне ім'я	Повне ім'я клієнта (складений атрибут, включає атрибути Прізвище, Ім'я і По-Батькові)
	Ім'я	Ім'я клієнта	Символьний, до 15 символів				Ні	Ні
	Прізвище	Прізвище клієнта	Символьний, до 15 символів				Ні	Ні
	По-батькові	По-батькові клієнта	Символьний, до 20 символів				Ні	Ні
	Телефон	Телефон клієнта	Символьний, до 13 символів				Ні	Ні
	Адреса	Адреса клієнта	Символьний, фіксований, 70 символів				Ні	Ні
	Стать	Стать клієнта	Символьний, фіксований, 1 символ				Ні	Ні
Клієнт - юридична особа	Номер	Унікальний ідентифікатор клієнта	Символьний, до 5 символів	Первинний ключ			Ні	Ні
	Тип компанії	Тип компанії клієнта	Символьний, 20 символів				Ні	Ні
	Найменування компанії	Найменування компанії клієнта	Символьний, 70 символів				Ні	Ні
	Адреса компанії	Адреса компанії клієнта	Символьний, 70 символів				Ні	Ні
	Контактний телефон	Контактний телефон компанії клієнта	Символьний, 13 символів	Альтернативний ключ			Ні	Ні
	Ім'я представника	Ім'я представника компанії клієнта	Символьний, 70 символів				Ні	Ні
Рейс	Номер	Унікальний ідентифікатор рейсу	Символьний, до 3 символів	Первинний ключ			Ні	Ні
	Номер напряму	Унікальний ідентифікатор напряму

Страница:

•  1 
•  2 

курсовая работа "Облік діяльності автотранспортного підприємства" скачать

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

• Розробка бази даних

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

• Облік перельотів пасажирів авіакомпанії

  Специфікація вимог для кожного з двох користувачів. Концептуальне та логічне проектування баз даних. Історія досліджень баз даних (програмного забезпечення). Система упрваління базами даних. Фази проектування баз даних: концептуальна, логічна, фізична.
  
  дипломная работа [105,8 K], добавлен 20.02.2010
  

• Розробка бази даних "Автосалон" в середовищі MSAccess

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

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

  Проектування і реалізація реляційної бази даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів готельного комплексу. Розробка сценаріїв для створення бази даних і базових таблиць проекту.
  
  курсовая работа [147,2 K], добавлен 02.06.2019
  

• Автоматизація ведення бази даних індивідуальних програм реабілітації інвалідів

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

• Концепція автоматизованого програмування

  Розробка бази даних для обробки інформації про діяльність туристичного агентства. Визначення предметної області, вхідних та вихідних даних, їх організації. Генерація схеми бази даних. Реалізація функціональних вимог. Інструкція з експлуатації системи.
  
  курсовая работа [5,3 M], добавлен 12.05.2015
  

• Проектування та розробка баз даних реєстру повітряних суден (на прикладі реєстру цивільних повітряних суден України)

  Етапи проектування баз даних. Декларація вимог до проектованої системи баз даних, до інформаційного, математичного, програмного, технічного, організаційного забезпечення. Опис заходів, необхідних для контролю даних у базі даних, їх резервного копіювання.
  
  курсовая работа [65,1 K], добавлен 09.12.2012
  

• База даних "Магазин тенісного устаткування"

  Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.
  
  курсовая работа [8,8 M], добавлен 16.12.2015
  

• Проектування бази даних для аналізу користувачів пластикових карток в комерційних банках

  Схема взаємодії учасників платіжної системи з використанням пластикових карток. Вхідні та вихідні повідомлення для проектування бази даних для автоматизації аналізу користувачів пластикових карток. Проектування та реалізація бази даних у MS Access.
  
  курсовая работа [3,0 M], добавлен 27.12.2013
  

• Проектування бази даних відділу кадрів

  Фізичне проектування бази даних відділу кадрів. Форма бази "Табель обліку робочого часу". Діалогове вікно для введення параметру "Період", звіт. Охорона праці при роботі на персональному комп'ютері: перелік вимог до робочого місця, пожежна безпека.
  
  курсовая работа [1,6 M], добавлен 25.03.2013
  

Другие документы, подобные "Облік діяльності автотранспортного підприємства"

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