Главная > Информатика, программирование > База даних "Чемпіонат авто"

База даних "Чемпіонат авто"


25-01-2012, 11:04. Разместил: tester1

ЗМІСТ

Введення

1. Концептуальна модель бази даних В«Чемпіонат автоВ»

1.1 Основні поняття

1.2 Опис предметної області

1.3 Каталог завдань

1.4 Опис таблиць

1.5 Схема даних

1.6 ER-діаграма

2. Реляційна модель бази даних В«Спортивний комплексВ»

2.1 Вибір логічної моделі

2.2 Основні поняття

2.3 Проектування реляційної моделі

2.3.1 Нормалізація відносин

2.3.2 Опис ключів

2.3.3 Правила цілісності

3. Реалізація бази даних В«Чемпіонат авто В»

4. Результат роботи бази даних В«Чемпіонат автоВ»


ВСТУП

Вибір предметної області В«Чемпіонат автоВ» обумовлений особистим інтересом і можливістю поширення бази даних серед фахівців і цікавляться. При проектуванні програм з'ясовуються запити та побажання користувача, і визначається можливий підхід до вирішення завдання. Завдання аналізується. На основі цього аналізу реалізується конкретна модель в конкретній програмному середовищі. Результати кожного етапу проектування використовуються як вихідний матеріал наступного етапу. Аналізується поточна організація В«Чемпіонат автоВ», виділяються проблеми для вирішення, визначаються об'єкти відносини між ними, розробляється модель з урахуванням конкретних умов її функціонування. База даних орієнтована на певну предметну область і організована на основі деякого підмножини даних. Можливості баз даних корисні в областях, пов'язаних з довготривалим управлінням інформацією, таких як електронні бібліотеки та сховища даних. При проектуванні системи обробки даних найбільше нас цікавить організація даних. Вимоги окремих користувачів повинні бути представлені в єдиному "узагальненому представленні". Останнє називають концептуальною моделлю. У процесі проектування необхідно: Описати предметну область; визначити склад і зміст інформації, використовуваної в даної предметної області; виявити сутності; виявити зв'язки між сутностями; представити модель у вигляді схеми даних і ER-діаграми; проаналізувати модель з урахуванням інформаційних потреб користувачів; створити спроектовану БД в середовищі Delphi; розробити додатка реалізації запитів і вирішення завдань; реалізувати можливість сортування та пошуку; представити кілька звітів і діаграм.


1. КОНЦЕПТУАЛЬНА МОДЕЛЬ БАЗИ ДАНИХ В«ЧЕМПІОНАТ АВТОВ»

1.1 Основні поняття

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

Сутність - особистості, факти, об'єкти реального світу, що мають відношення до деякої проблемної області.

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

Примірник сутності - Це один набір значень його елементів даних.

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

Зв'язок - Це функціональна залежність між сутностями.

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

1.2 Опис предметної області

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

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

1.3 Каталог завдань

Грунтуючись на описі предметної області, визначимо коло запитів і завдань, які передбачається вирішувати з використанням бази даних В«Чемпіонат автоВ».

Завдання:

В· відомості про гонщиків;

В· відомості про автомобілях;

В· відомості про чемпіонатах;

В· відомості про працюючому персоналі;

В· відомості про спонсорів;

В· наявні терміни ремонті автомобілів;

В· інформація про місця проведення чемпіонатів;

В· список заїздів, час і місце учасників

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

1.4 Опис таблиць

1) Майстерня

* ID майстерні

idmaster + Автомобіль avtomast S Вартість Ремонту stoim I Дата закінчення ремонту daterem D Номер Боксу nbox I Прізвище Майстри familmast S

2) Працівники Майстерні

* ID майстра

idworker + Прізвище familwork S Ім'я namework S батькові fathwork S Дата Народження datework D Стаж stag I

3) Cписок Автомобілів

* Марка

CodeWork + Модель model S Рік Випуску yearvyp I Пробіг probeg I Колір color S ID майстерні idmast I

4) УчастнікіЧемпіоната

* ID учасника

iduch + Автомобіль avto I Гонщик racer S Результат result I ID гонщика idracer I

база даний реляційний модель

5) Гонщики

* ID гонщика

idracer + Прізвище familracer S Ім'я nameraser S батькові fathracer S Дата Народження dateracer D Кількість участь kolvo I Наявність Приз Місць priz B

6) Результати Заїзду

* ID результату

idresult + Чемпіонат champ I Час time I Місце mesto I

7) Чемпіонати

* ID чемпіонату

idchamp + Назва Чемпіонату nazchamp S Спонсор Чемпіонату sponschamp I Місце Проведення mestochamp I Рік Проведення yearchamp D

8) Спонсори

* ID спонсора

idspons + Спонсор sponsor S Винагорода Спонсора voznagr I ID чемпіонату idchamp I

9) Місце Проведення

* ID місця

idmesta + Назва Місця nazmesta S Тип Траси tiproad S ID чемпіонату idchamp I


1.5 Схема даних

1.6 ER- діаграма


2. Реляційна МОДЕЛЬ БАЗИ ДАНИХ В«ЧЕМПІОНАТ АВТОВ»

2.1 Вибір логічної моделі

Збережені в базі дані мають певну логічну структуру, тобто модель. Розрізняють такі основні моделі представлення даних в базі даних:

- ієрархічну

- мережеву

- реляційну

- об'єктно-орієнтовану

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

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

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

Реляційна модель отримала свою назву від англійського терміна relation (Відношення) і була запропонована в 1970-х роках співробітником фірми IBM Едгаром Коддом. Реляційна БД являє собою сукупність таблиць, пов'язаних відносинами. Різниця між таблицею в звичному сенсі і поняттям відносини полягає в тому, що у відношенні немає порядку - це невпорядковане безліч записів. Порядок визначається не ставленням, а конкретної вибіркою з відносини. Зв'язок між таблицями існує на логічному рівні і визначається предметною областю. Практично зв'язок між таблицями встановлюється шляхом використання логічно пов'язаних даних у різних таблицях.

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

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

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

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

...

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

В· уявлення даних у вигляді двовимірних таблиць простіше, ніж вигляді списків;

В· реляційна модель проста, володіє гнучкою структурою, зручна для реалізації на комп'ютері.

В· 2.2 Основні поняття

Реляційна модель даних - це подання даних у вигляді сукупності двовимірних таблиць:

1) кожний елемент таблиці являє собою один елемент даних, тобто список не може бути значенням;

2) всі стовпці в таблиці однорідні, тобто елементи стовпця однієї природи;

3) стовпцях однозначно присвоєні імена;

4) в таблиці немає двох однакових рядків;

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

Для математичного опису реляційної моделі нам знадобляться наступні поняття

Атомарні дані - це найменші одиниці даних нерозкладних з точки зору моделі.

Домен - Це безліч атомарних значень одного і того ж типу.

Атрибут - Це деякий підмножина домену, що має унікальне ім'я.

Ставлення на доменах D 1 , D 2 , .. D n складається із заголовка і тіла.

R (A 1 , A 2 , .. A n ) ГЌ D 1 'D 2 ' D 3

Заголовок складається з такого фіксованого безлічі атрибутів

А 1 , A 2, .. A n , Що існує відношення між атрибутами та їх доменами.

Тіло складається з мінливих в часі безлічі кортежів.

Кортеж складається із значень кожного атрибуту по одному значенню на атрибут.

Таблиця в реляційної теорії відповідає відношенню.

Строке відповідає кортеж.

стовпців - атрибут.

Введемо поняття ключа відносини.

Нехай А - безліч атрибутів відносини

А = {A 1 , A 2 , .. A n } і нехай k - це підмножина А

k ГЌ A

Можливим ключем відносини R є таке підмножина k, яке задовольняє наступній умові:

1) в довільний момент часу ніякі два різних картежа не мають одного і того ж значення для k

2) жоден з атрибутів не може бути виключений з k без порушення першої умови.

2.3 Проектування реляційної моделі

Існує два основні методи проектування реляційної моделі:

1. метод декомпозиції (використовується при кількості ключових атрибутів не більше 20);

2. на основі концептуальної моделі.

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

2.3.1 Нормалізація відносин

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

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

Відношення називається нормалізованим або приведеним до першій нормальній формі (1НФ) , якщо всі його атрибути прості або атомарні - далі неподільні. Розроблена база даних В«Чемпіонат автоВ» відповідає даній НФ, а саме виконані наступні вимоги:

В«у відношенні немає однакових кортежів;

В«кортежі не упорядковані;

В«атрибути не впорядковані і розрізняються за найменуваннями;

В«всі значення атрибутів атомарні.

Як видно з перерахованих властивостей, будь-яке відношення автоматично знаходиться в першій нормальній формі. Щоб розглянути питання приведення відносин до другої нормальній формі, необхідно дати пояснення поняттю функціональної Залежно . Нехай є відношення R. Безліч атрибутів Y функціонально залежно від безлічі атрибутів X, якщо для будь-якого стану відносини R для будь-яких кортежів r1, r2 Про R з того, що r1X = r2X випливає, що r1Y = r2Y, тобто у всіх кортежах, що мають однакові значення атрибутів X, значення атрибутів Y також збігаються в будь-якому стані відносини R.

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

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



3.

procedure

begin

end;

На форму

Подія для

procedure

begin

try

;

end;

end;

procedure

begin

end;

Подія для

procedure

begin

end;


procedure

begin

end;

procedure

begin

end;

міста. інформації.