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

Анотація

Тема проекту ?Розробка бази даних спортивного клубу?. Проект складається з пояснювальної записки і бази даних розробленої в середовищі Microsoft SQL Server, Пояснювальна записка містить описи, таблиці, рисунки, результати роботи.

Об`єктом дослідження є спортивний клуб.

Мета розробки - створення бази даних клубу призначеної для ведення даних по обліку спортсменів, тренерів, участі в змаганнях.

Метод вирішення проблеми - використання технології баз даних на основі клієнт-серверної архітектури.

Використані засоби - Microsoft SQL Server.

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

Вступ

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

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

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

У наші дні активно розвиваються web-додатки баз даних, а також бази даних з використанням Internet -технологій. Web -додатки баз даних роблять дані доступними через оглядач користувача , в той час як бази даних з використанням Internet - технологій просто використовують клієнтські оглядачі і технології типу XML і DHTML для роботи з базою даних.

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

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

В даній роботі приведено опис проектування бази даних призначеної для інформатизації роботи спортивного клубу. Система реалізована засобами Microsoft SQL Server. Приведена фізична реалізація бази даних і запити до бази даних на реалізацію функцій користувача.

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

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

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

Спортклуб призначений для забезпечення загальної фізичної підготовки спортсменів в період зборів і змагань.

Спортсмени об`єднуються у певні команди, або тренуються і виступають індивідуально.

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

Кожен спортсмен має свого індивідуального тренера.

Всі виступи спортсменів фіксуються і аналізуються для подальшої роботи.

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

В Україні присвоюються такі спортивні звання: 

? заслужений тренер України; 

? заслужений майстер спорту України;

? майстер спорту України міжнародного класу;

? гросмейстер України; 

? майстер спорту України. 

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

Спортсмени, яким присвоєні спортивні звання, є спортсменами вищої категорії. 

В Україні присвоюються такі спортивні розряди:

? кандидат у майстри спорту України; 

? перший розряд;

? другий розряд; 

? третій розряд; 

? перший юнацький розряд;

? другий юнацький розряд; 

? третій юнацький розряд. 

Спортсменам, які виконали спортивні розряди, передбачені Єдиною спортивною класифікацією України, видається посвідчення про присвоєння відповідного спортивного розряду в порядку, визначеному центральним органом виконавчої влади у сфері фізичної культури і спорту. 

1.2 Вимоги до бази даних

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

Вимоги можна поділити на функціональні і не функціональні.

Перелік не функціональних вимог:

1.2.1 Багаторазове використання даних. Користувачі, які по-різному розуміють одні й ті ж дані, можуть використовувати їх різним чином.

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

1.2.3 Легкість використання. Користувачі мають простий доступ до даних; складний доступ до даних здійснює СУБД.

1.2.4 Гнучкість використання. Звернення до даних або їх пошук здійснюється за допомогою різних методів доступу.

1.2.5 Простота внесення змін. База даних може збільшуватися і змінюватися без порушення наявних способів використання даних.

1.2.6 Зменшення надмірності даних. Вимоги нових додатків задовольняються за рахунок існуючих даних, а не шляхом створення нових файлів.

1.2.7 Продуктивність. Запити на дані задовольняються з такою швидкістю, яка потрібна для використання даних.

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

1.2.9 Секретність. Несанкціонований доступ до даних неможливий. Обмеження доступу до одних і тих же даних для різного їх використання може здійснюватися різними способами.

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

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

Перелік функціональних вимог:

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

1.2.13 Формування і перегляд переліку спортсменів, що є членами клубу.

1.2.14 Формування і перегляд переліку тренерів, що здійснюють керівництво спортсменами.

1.2.15 Формування і перегляд переліку даних про змагання, в яких приймали участь спортсмени клубу..

1.2.16 Формування і перегляд даних про участь спортсменів у змаганнях.

1.2.17 Формування і перегляд даних по по можливих травмах і облік травм, отриманих спортсменами на змаганнях.

2. Проектування бази даних

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

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

- визначення бізнес-планів та цілей організації з наступним виділенням її потреб в інформаційних технологіях;

- оцінка показників уже існуючих інформаційних систем з метою виявлення їх сильних і слабких сторін;

- оцінка можливостей використання інформаційних технологій для досягнення переваг перед конкурентами.

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

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

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

концептуальне проектування

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

фізичне проектування

2.1 Концептуальна модель предметної області

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

Концептуальне моделювання предметної області включає:

– Створення локальної концептуальної моделі даних виходячи з представле?нь предметної області кожного з типів користувачів.

– Визначення типів сутностей.

– Визначення типів зв'язків.

– Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків.

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

Для концептуального моделювання використаємо модель “сутність-зв'язок”, (ER-модель).

2.1.1 Визначення типів сутностей

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

Основні сутності предметної області описані в табл.2.1.

Таблиця 2.1 - Опис типів сутностей

Ім`я типу сутності	Опис
Вид спорту	Назва виду спорту
Тренер	Характеризує тренерів, що тренують спортсменів
Спортсмен	Характеризує спортсменів, які є членами клубу
Спортивний розряд	Містить перелік всіх розрядів і звань для тренерів і спортсменів
Змагання	Характеризує місце і час проведення змагання
Участь в змаганні	Характеризує сукупність участі в змаганнях конкретних спортсменів
Партнери	Визначає спортсменів, які є партнерами спортсменів-членів клубу у змаганнях
Вид травм	Містить перелік можливих травм
Травми	Містить перелік спортсменів, які отримали травми і характеристику травм

2.1.2 Визначення атрибутів сутностей

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

Атрибути сутностей предметної області описані в табл.2.2.

Таблиця 2.2 - Опис атрибутів сутностей

Ім`я сутності	Атрибути	Опис атрибута	Тип	Обмеження
Вид спорту	Назва	Назва виду спорту	Рядок
Тренер	ПІБ	Повне ім`я тренера	Рядок
	Розряд	Спортивний розряд	Рядок
	Вид спорту	Спеціалізація тренера	Рядок
	Телефон	Номер телефону	Рядок
Спортсмен	ПІБ	Повне ім`я спортсмена	Рядок
	Тренер	Тренер, що тренує спортсмена	Рядок
	Дата	Дата народження	Дата
	Розряд	Спортивний розряд	Рядок
Спортивний розряд	Назва	Назва розряду	Рядок
Змагання	Назва	Назва змагання	Рядок
	Країна	Країна в якій проводяться змагання	Рядок
	Місто	Місто в якому проводяться змагання	Рядок
	Дата початку	Початок змагань	Дата
	Дата завершення	Завершення змагань	Дата
Участь в змаганні	Спортсмен	Повне ім`я спортсмена	Рядок
	Партнер	Повне ім`я партнера	Рядок
	Змагання	Назва змагання	Рядок
	Дата	Дата зустрічі	Дата
	Бал спортсмена	Бал набраний спортсменом	Цілий
	Бал партнера	Бал набраний партнером	Цілий
	Перемога	Вказує чи досяг спортсмен перемоги	Цілий
Партнер	ПІБ	Повне ім`я	Рядок
	Розряд	Спортивний розряд	Рядок
	Дата	Дата народження	Дата
	Країна	Країна яку представляє	Рядок
Вид травм	Назва	Назва травми	Рядок
Травми	Змагання	Назва змагання де отримана травма	Рядок
	Вид травми	Назва травми	Рядок
	Дата	Дата отримання	Дата
	Спортсмен	Повне ім`я спортсмена	Рядок

2.1.3 Визначення зв`язків між сутностями

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

Сутності, охоплені деяким зв'язком, називаються учасниками цього зв'язку.

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

З кожного боку бінарний зв`язок має такі характеристики:

- ім`я,

- множинність або потужність,

- обов`язковість.

Множинність може бути один і багато. Якщо зв`язок між сутностями А і В з боку сутності А має множинність один, то це означає, що кожен екземпляр В асоціюється не більше ніж з одним екземпляром А. Якщо зв`язок з боку В є множинним, це означає, що екземпляр А асоціюється з довільною кількістю екземплярів В.

Спортивний клуб охоплює тренування з декількох видів спорту. Кожен тренер здійснює тренування тільки з одного виду спорту, тому зв`язок між сутностями Вид спорту і Тренер один до багатьох.

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

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

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

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

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

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

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

Опис зв`язків приведено в табл.2.3.

Таблиця 2.3 - Опис зв`язків

Ім`я сутності	Зв`язок	Ім`я сутності	Тип зв`язку
Травма	Має	Вид травми	m : 1
Травма	Отримується	Змагання	m : 1
Спортсмен	Отримує	травму	1 : m
Спортсмен	Має	Спортивний розряд	m : 1
Участь у змаганні	Приймає	Спортсмен	m : 1
Тренер	Спеціалізується	Вид спорту	m : 1
Тренер	Має	Спортивний розряд	m : 1
Партнер	Має	Спортивний розряд	m : 1
Партнер	Представляє	Країну	m : 1
Участь у змаганні	Приймає	Партнер	m : 1
Участь у змаганні	Відноситься	Змагання	m : 1
Змагання	Проходять	Країна	m : 1

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

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

Рисунок 2.1- Концептуальна схема

2.2 Логічна модель даних

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

- вибір певної моделі даних,

- приведення ER-діаграми до виду, сумісного з реляційною моделлю,

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

- перевірки відносин за допомогою правил нормалізації на відповідність першим трьом формам нормалізації.

Переважна більшість сучасних СКБД - реляційні. Якщо обрано реляційну систему, то концептуальну схему бази даних треба буде відображати на реляційну модель. Для реалізації задачі обрано СКБД Microsoft SQL Server, що підтримує реляційну модель даних.

ER-діаграма не має зв`язків ?багато-до-багатьох?, не має багатозначних атрибутів, складних зв`язків тому вона сумісна з реляційною моделлю.

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

Відношення необхідно нормалізувати. Достатньо привести базу даних до третьої форми нормалізації.

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

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

Рисунок 2.2- Логічна схема бази даних

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

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

Є п'ять класів обмежень цілісності, що розрізняються по функціональності і області застосування:

Обмеження цілісності NULL. Діє для стовпця або користувацького типу даних.

Обмеження цілісності CHECK (перевірка). Це обмеження цілісності визначається для стовпця і обмежує діапазон значень, які можуть бути збережені в цьому стовпці. При визначенні обмеження цілісності СНЕСК вказується логічне умова для введених даних. При введенні або зміні даних вводиться значення підставляється в умова. Якщо в результаті перевірки повертається значення «істина» (TRUE), то зміни даних приймаються. Якщо ж перевірка повертає «не істина» (FALSE), то зміни даних відкидаються і генерується повідомлення про помилку. Для одного і того ж стовпця можна створити кілька обмежень цілісності CHECK.

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

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

Обмеження цілісності FOREIGN KEY (зовнішній ключ). Це обмеження цілісності призначено для організації посилальної цілісності даних. Зовнішній ключ зв'язується з одним з кандидатів на первинний ключ в іншій таблиці (з потенційним ключем).

Використані обмеження цілісності PRIMARY KEY, FOREIGN KEY, NULL.

2.3 Фізична модель даних

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

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

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

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

create database Спортивний_клуб

go

use Спортивний_клуб

go

CREATE TABLE Vid_sport

(kod_vid_sport int IDENTITY primary key,

name_vid_sport varchar(50) NOT NULL

)

CREATE TABLE Sport_rozrayd

(kod_sport_rozrayd int IDENTITY primary key,

name_sport_rozrayd varchar(50) NOT NULL

)

go

CREATE TABLE Trener

(kod_trener int IDENTITY primary key,

name_trener varchar(50) NOT NULL,

sport_rozrayd int FOREIGN KEY REFERENCES Sport_rozrayd (kod_sport_rozrayd) NOT NULL, vid_sport int FOREIGN KEY REFERENCES Vid_sport (kod_vid_sport) NOT NULL, phone varchar(30)

)

go

CREATE TABLE Sportsman

(kod_sportsman int IDENTITY primary key,

name_sportsman varchar(50) NOT NULL,

trener int FOREIGN KEY REFERENCES Trener (kod_trener) NOT NULL,

data_narodgenny datetime NOT NULL,

sport_rozrayd int FOREIGN KEY REFERENCES Sport_rozrayd (kod_sport_rozrayd) NOT NULL

)

go

CREATE TABLE Vid_travma

(kod_vid_travma int IDENTITY primary key,

name_vid_travma varchar(50) NOT NULL

)

CREATE TABLE Country

(kod_country int IDENTITY primary key,

name_country varchar(50) NOT NULL

)

go

CREATE TABLE Zmagannay

(kod_zmagannay int IDENTITY primary key,

name varchar(50 NOT NULL,country int FOREIGN KEY REFERENCES Country (kod_country) NOT NULL, town varchar(30)NOT NULL,

data_begin datetime NOT NULL, data_end datetime NOT NULL

)

go

CREATE TABLE Travma

(kod_travma int IDENTITY primary key,

zmagannay int FOREIGN KEY REFERENCES Zmagannay (kod_zmagannay) NOT NULL,vid_travma int FOREIGN KEY REFERENCES Vid_travma (kod_vid_travma) NOT NULL,data datetime NOT NULL, sportsman int FOREIGN KEY REFERENCES Sportsman (kod_sportsman) NOT NULL

)

go

CREATE TABLE Partner

(kod_partner int IDENTITY primary key,

name_partner varchar(50) NOT NULL,

sport_rozrayd int FOREIGN KEY REFERENCES Sport_rozrayd (kod_sport_rozrayd) NOT NULL, data_narodgenny datetime NOT NULL,

country int FOREIGN KEY REFERENCES Country (kod_country) NOT NULL

)

go

CREATE TABLE Uchast_zmagannay

(kod_Uchast_zmagannay int IDENTITY primary key, sportsman int FOREIGN KEY REFERENCES Sportsman (kod_sportsman) NOT NULL, partner int FOREIGN KEY REFERENCES Partner (kod_partner) NOT NULL,

zmagannay int FOREIGN KEY REFERENCES Zmagannay (kod_zmagannay) NOT NULL, data datetime NOT NULL, ball_sportsman int NOT NULL,

ball_partner int NOT NULL, victory int NOT NULL

)

go

Після виконання інструкцій таблиці бази даних мають структуру приведену на рис. 2.3 - рис.2.12.

Рисунок 2.3 - Структура таблиці Vid_sport

Рисунок 2.4 - Структура таблиці Trener

Рисунок 2.5 - Структура таблиці Cportsman

Рисунок 2.6 - Структура таблиці Sport_rozrayd

Рисунок 2.7 - Структура таблиці Partner

Рисунок 2.8 - Структура таблиці Country

Рисунок 2.9 - Структура таблиці Zmagannay

Рисунок 2.10 - Структура таблиці Travma

Рисунок 2.11 - Структура таблицi Vid_travma

Рисунок 2.12 - Структура таблицi Uchast_zmagannay

3. Запити до бази даних

3.1 Заповнення бази даних

Для заповнення таблиць використані інструкції:

SET DATEFORMAT dmy

INSERT Vid_sport VALUES ('Бадмінтон')

INSERT Vid_sport VALUES ('Бокс')

INSERT Vid_sport VALUES ('Боротьба вільна')

INSERT Vid_sport VALUES ('Боротьба греко-римська')

INSERT Vid_sport VALUES ('Дзюдо')

INSERT Vid_sport VALUES ('Теніс')

INSERT Vid_sport VALUES ('Теніс настільний')

INSERT Vid_sport VALUES ('Тхеквондо')

INSERT Vid_sport VALUES ('Фехтування')

INSERT Sport_rozrayd VALUES ('заслужений тренер України')

INSERT Sport_rozrayd VALUES ('заслужений майстер спорту України')

INSERT Sport_rozrayd VALUES ('майстер спорту України міжнародного класу')

INSERT Sport_rozrayd VALUES ('гросмейстер України')

INSERT Sport_rozrayd VALUES ('майстер спорту України')

INSERT Sport_rozrayd VALUES ('кандидат у майстри спорту України')

INSERT Sport_rozrayd VALUES ('перший розряд')

INSERT Sport_rozrayd VALUES ('другий розряд')

INSERT Sport_rozrayd VALUES ('третій розряд')

INSERT Sport_rozrayd VALUES ('перший юнацький розряд')

INSERT Sport_rozrayd VALUES ('другий юнацький розряд')

INSERT Sport_rozrayd VALUES ('третій юнацький розряд')

INSERT Trener VALUES ('Іваненко П.С.',1,1,'0931234654')

INSERT Trener VALUES ('Степаненко О.В.',2,3,'0937609176')

INSERT Trener VALUES ('Фурсенко А.І.',3,6,'0974567923')

INSERT Trener VALUES ('Марчук М.В.',1,7,'0965673623')

INSERT Trener VALUES ('Савсюк К.Ф.',2,9,'0937451234')

INSERT Sportsman VALUES ('Іваненко І.І.',5,'12.05.1996',1)

INSERT Sportsman VALUES ('Петренко В.О.',6,'06.11.1997',2)

INSERT Sportsman VALUES ('Савченко О.І.',7,'09.07.1998',3)

INSERT Sportsman VALUES ('Семенюк Д.М.',7,'15.04.1998',3)

INSERT Sportsman VALUES ('Король К.П.',8,'06.03.1999',4)

INSERT Sportsman VALUES ('Степанчук О.М.',8,'21.02.1998',5)

INSERT Vid_travma VALUES ('Розтягування або розрив ахіллового сухожилля')

INSERT Vid_travma VALUES ('Розтягнення щиколотки')

INSERT Vid_travma VALUES ('Перелом щиколотки')

INSERT Vid_travma VALUES ('Стресовий перелом кісток стопи')

INSERT Vid_travma VALUES ('Розтягування або розрив м"язів гомілки')

INSERT Vid_travma VALUES ('Тендиніт надколінка')

INSERT Vid_travma VALUES ('Розрив хряща меніска')

INSERT Vid_travma VALUES ('Зсув колінної чашечки')

INSERT Vid_travma VALUES ('Розрив передньої хрестоподібної зв"язки')

INSERT Vid_travma VALUES ('Стресовий перелом стегнової кістки')

INSERT Vid_travma VALUES ('Бурсит стегнового суглоба')

INSERT Vid_travma VALUES ('Розтягування чотириголового м"яза')

INSERT Vid_travma VALUES ('Стресовий перелом хребців поперекового відділу')

INSERT Vid_travma VALUES ('Грижа міжхребцевого диска')

INSERT Vid_travma VALUES ('травм хлистів')

INSERT Vid_travma VALUES ('Розтягування м"язів середньої частини спини')

INSERT Vid_travma VALUES ('Розтягування нервових стовбурів')

INSERT Vid_travma VALUES ('Вивих плечового суста')

INSERT Vid_travma VALUES ('Перелом ключиці')

INSERT Vid_travma VALUES ('Травма обертальної манжети плеча')

INSERT Vid_travma VALUES ('«лікоть тенісиста»')

INSERT Vid_travma VALUES ('Ліктьова невропатія')

INSERT Vid_travma VALUES ('Перелом ліктя')

INSERT Vid_travma VALUES ('Синдром зап"ястного каналу')

INSERT Vid_travma VALUES ('Розтягування суглоба пальця')

INSERT Vid_travma VALUES ('Розтягнення зап"ястя')

INSERT Country VALUES ('Україна')

INSERT Country VALUES ('Польща')

INSERT Country VALUES ('Литва')

INSERT Country VALUES ('Германія')

INSERT Country VALUES ('Чехія')

INSERT Country VALUES ('Словенія')

INSERT Zmagannay VALUES ('Змагання з бадмінтону',1,'Київ','12.05.2013','17.05.2013')

INSERT Zmagannay VALUES ('Змагання з боксу',4,'Берлін','20.07.2013','30.07.2013')

INSERT Zmagannay VALUES ('Вільна боротьба',2,'Варна','10.10.2013','15.10.2013')

INSERT Zmagannay VALUES ('Турнір з великого тенісу',5,'Прага','12.01.2014','17.01.2014')

INSERT Zmagannay VALUES ('Турнір з настільного тенісу',1,'Харків','20.02.2014','25.02.2014')

INSERT Zmagannay VALUES ('Турнір фехтувальників',1,'Київ','15.04.2014','20.04.2014')

INSERT Travma VALUES (1,24,'14.05.2013',1)

INSERT Travma VALUES (2,5,'14.10.2013',3)

INSERT Travma VALUES (2,8,'15.10.2013',3)

INSERT Travma VALUES (3,22,'14.01.2014',4)

INSERT Travma VALUES (3,1,'16.01.2014',4)

INSERT Travma VALUES (4,24,'17.01.2014',5)

INSERT Travma VALUES (5,25,'23.02.2014',6)

INSERT Travma VALUES (5,26,'25.02.2014',6)

INSERT Partner VALUES ('Литовченко О.А.',1,'12.05.1996',1)

INSERT Partner VALUES ('Савченко А.В.',6,'06.11.1997',1)

INSERT Partner VALUES ('Ісавічус І.',7,'09.07.1998',3)

INSERT Partner VALUES ('Лімавіс М.',7,'15.04.1998',3)

INSERT Partner VALUES ('Брут Г.',9,'06.03.1999',4)

INSERT Partner VALUES ('Степанчік О.М.',9,'21.02.1998',5)

INSERT Uchast_zmagannay VALUES (1,1,1,'12.05.2013',25,15,1)

INSERT Uchast_zmagannay VALUES (3,2,3,'11.10.2013',32,35,0)

INSERT Uchast_zmagannay VALUES (4,3,5,'20.02.2014',32,35,0)

INSERT Uchast_zmagannay VALUES (4,4,5,'22.02.2014',125,10,1)

INSERT Uchast_zmagannay VALUES (5,1,1,'12.05.2013',5,15,0)

INSERT Uchast_zmagannay VALUES (5,5,6,'15.04.2014',28,19,1)

INSERT Uchast_zmagannay VALUES (1,6,6,'17.04.2014',35,25,1)

Після виконання інструкцій таблиці бази даних мають вміст приведений на рис. 3.1 - рис.3.10.

Рисунок 3.1 - Вміст таблицi Vid_sport

Рисунок 3.2 - Вміст таблицi Trener

Рисунок 3.3 - Вміст таблицi Sportsman

Рисунок 3.4 - Вміст таблицi Partner

Рисунок 3.5 - Вміст таблицi Country

Рисунок 3.6 - Вміст таблицi Uchast_zmagannay

Рисунок 3.7 - Вміст таблицi Vid_travma

Рисунок 3.8 - Вміст таблицi Travma

Рисунок 3.9 - Вміст таблицi Sport_rozryad

Рисунок 3.10 - Вміст таблицi Zmagannay

3.2 Вибірка даних

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

/*перелік тренерів і їх спортсменів за видами спорту*/

SELECT dbo.Trener.name_trener Тренер, dbo.Vid_sport.name_vid_sport [Вид спорту],

dbo.Sportsman.name_sportsman спортсмен

FROM dbo.Vid_sport INNER JOIN dbo.Trener ON dbo.Vid_sport.kod_vid_sport = dbo.Trener.vid_sport INNER JOIN

dbo.Sportsman ON dbo.Trener.kod_trener = dbo.Sportsman.trener

Результат вибірки приведено на рис.3.10.

Рисунок 3.10 - Меню на 11.12.2013

/*Змагання в яких приймали участь спортсмени*/

SELECT dbo.Country.name_country Країна, dbo.Zmagannay.town Місто,

CONVERT(DATETIME,dbo.Zmagannay.data_begin,102) as[Дата початку],

CONVERT(DATETIME,dbo.Zmagannay.data_end,102) as[Дата завершення],

dbo.Zmagannay.name AS [Назва турніру]

FROM dbo.Zmagannay INNER JOIN dbo.Country ON dbo.Zmagannay.country = dbo.Country.kod_country

Результат вибірки приведено на рис.3.10.

Рисунок 3.10 - Меню на 11.12.2013

/*Облік травм, отриманих спортсменами*/

SELECT dbo.Sportsman.name_sportsman Спортсмен, dbo.Vid_travma.name_vid_travma Травма, CONVERT(DATETIME,dbo.Travma.data, 102) Дата

FROM dbo.Vid_travma INNER JOIN dbo.Travma ON dbo.Vid_travma.kod_vid_travma = dbo.Travma.vid_travma INNER JOIN

dbo.Sportsman ON dbo.Travma.sportsman = dbo.Sportsman.kod_sportsman

Результат вибірки приведено на рис.3.10.

Рисунок 3.10 - Меню на 11.12.2013

/*Кількість перемог спортсменів за вказаний проміжок часу*/

SELECT dbo.Sportsman.name_sportsman Спортсмен, dbo.Vid_sport.name_vid_sport [Вид спорту],

COUNT(dbo.Uchast_zmagannay.victory) AS [Кількість перемог]

FROM dbo.Sportsman INNER JOIN dbo.Uchast_zmagannay ON dbo.Sportsman.kod_sportsman = dbo.Uchast_zmagannay.sportsman INNER JOIN

dbo.Trener ON dbo.Sportsman.trener = dbo.Trener.kod_trener INNER JOIN dbo.Vid_sport ON dbo.Trener.vid_sport = dbo.Vid_sport.kod_vid_sport

WHERE (dbo.Uchast_zmagannay.data BETWEEN CONVERT(DATETIME, '2013-01-01 00:00:00', 102) AND CONVERT(DATETIME, '2015-01-01 00:00:00', 102))

GROUP BY dbo.Sportsman.name_sportsman, dbo.Vid_sport.name_vid_sport

Результат вибірки приведено на рис.3.10.

Рисунок 3.10 - Меню на 11.12.2013

/*Участь в змаганнях спортсменів вказаного тренера за вказаний проміжок часу*/

SELECT dbo.Trener.name_trener Тренер, dbo.Sportsman.name_sportsman Спортсмен, dbo.Country.name_country [Місце змагання], CONVERT(DATETIME,dbo.Uchast_zmagannay.data, 102) Дата

FROM dbo.Sportsman INNER JOIN dbo.Uchast_zmagannay ON dbo.Sportsman.kod_sportsman = dbo.Uchast_zmagannay.sportsman INNER JOIN

dbo.Trener ON dbo.Sportsman.trener = dbo.Trener.kod_trener INNER JOIN dbo.Zmagannay ON dbo.Uchast_zmagannay.zmagannay = dbo.Zmagannay.kod_zmagannay INNER JOIN

dbo.Country ON dbo.Zmagannay.country = dbo.Country.kod_country

WHERE (dbo.Trener.name_trener = 'Фурсенко А.І.') AND (dbo.Uchast_zmagannay.data BETWEEN CONVERT(DATETIME, '2013-01-01 00:00:00', 102) AND CONVERT(DATETIME, '2015-01-01 00:00:00', 102))

Результат вибірки приведено на рис.3.10.

Рисунок 3.10 - Меню на 11.12.2013

/*Партнери в змаганнях спортсменів клубу за вказаний проміжок часу*/

SELECT dbo.Sportsman.name_sportsman AS Спортсмен, dbo.Partner.name_partner AS Партнер, dbo.Vid_sport.name_vid_sport AS [Вид спорту], CONVERT(DATETIME, dbo.Uchast_zmagannay.data, 102) AS Дата, dbo.Uchast_zmagannay.ball_sportsman AS [Бали спортсмена],

dbo.Uchast_zmagannay.ball_partner AS [Бали партнера]

FROM dbo.Partner INNER JOIN dbo.Uchast_zmagannay ON dbo.Partner.kod_partner = dbo.Uchast_zmagannay.partner INNER JOIN dbo.Sportsman ON dbo.Uchast_zmagannay.sportsman = dbo.Sportsman.kod_sportsman INNER JOIN dbo.Zmagannay ON dbo.Uchast_zmagannay.zmagannay = dbo.Zmagannay.kod_zmagannay INNER JOIN dbo.Trener ON dbo.Sportsman.trener = dbo.Trener.kod_trener INNER JOINdbo.Vid_sport ON dbo.Trener.vid_sport = dbo.Vid_sport.kod_vid_sport

WHERE (dbo.Uchast_zmagannay.data BETWEEN CONVERT(DATETIME, '2013-01-01 00:00:00', 102) AND CONVERT(DATETIME, '2015-01-01 00:00:00', 102))

Результат вибірки приведено на рис.3.10.

Рисунок 3.10 - Меню на 11.12.2013

4. Захист бази даних

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

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

Захист бази даних починається з розмежування прав доступу.

Всі користувачі SQL Server об'єднуються в робочі групи. Члени однієї робочої групи мають рівні права на спільне використання ресурсів. Формування робочих груп і визначення їхніх прав на ресурси бази даних здійснює адміністратор системи. Кожному членові робочої групи надається обліковий запис і запис користувача.

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

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

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

Заключення

В даній роботі приведено опис проектування бази даних для інформатизації роботи спортивного клубу.

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

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

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

Для реалізації бази даних обрано СКБД SQL Server і побудована фізична модель даних. Для формування таблиць бази даних використані відповідні інструкції мови запитів, які приведені в документі, і на рисунках приведена структура таблиць бази даних.

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

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

Перелік використаної літератури

1. Конноли, Томас Бази даних. Проектирование, реализация и сопровождение. Теория и практика, 3-е издание:Пер. с англ /Томас Конноли, Каролін Бег .-М.:Издательский дом ?Вильямс?, 2003.- 1440 с.: ил. .- ISBN 5-8459-0527-3 (рус)

2. Мамаев, Евгений. Microsoft SQL Server для профессионалов/ Евгений Мамаев, Лилия Шкарина.- СПб.: Питер, 2001.- 1088 с. ил.? ISBN 5-272-00339-Х

3. Пасічник, В.В. Організація баз даних та знань/ В.В.Пасічник, В.А.Резніченко.-К.: Видавнича група BHV, 2006.- 384 сю:іл.- ISBN966-552-156-Х

4. Хансен, Гэри Базы данных: Разработка и управление : Пер. С англ/ Гэри Хансен, Вжеймс Хансен. - М.:ЗАО Издательство «Бином», 2000 .- 704 с.: ил. .- ISBN 5-7989-0015-0 (рус)

5. Шкарина, А. Язык SQL. Учебный курс/ Шкарина, А.. - СПб.: Питер, 2001(9)

6. Боггс, Уэнди UML и Rational Rose 2002 / Уэнди Боггс, Майкл Боггс .?Лори, 2001.? 582 с.? ISBN: 5-85582-091-2

Размещено на Allbest.ru