Моделювання алгоритмів обчислення статистичних даних для спортивних змагань

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

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

Міністерство освіти і науки України

Харківський національний університет радіоелектроніки

Факультет прикладної математики та менеджменту

Кафедра інформатики

Спеціальність 6.08 0201 - «Інформатика»

ДИПЛОМНА РОБОТА БАКАЛАВРА

Пояснювальна записка

Моделювання алгоритмів обчислення статистичних даних для спортивних змагань

Студент гр. ІНФ-06-1

О.С. Подрєзова

Керівник дипломної роботи

О.А.Кобилін

Харків 2010 р.



КАЛЕНДАРНИЙ ПЛАН

№	Назва етапів дипломної роботи	Термін виконання етапів роботи	Примітка
1	Отримання завдання на дипломне проектування	2.02.2010	виконано
2	Аналіз поставленої задачі	3.02.2010-8.02.2010	виконано
3	Аналіз предметної області	9.02.2010-15.02.2010	виконано
4	Розробка алгоритму	16.02.2010-15.03.2010	виконано
5	Програмна реалізація	16.03.2010-20.04.2010	виконано
6	Підготовка пояснювальної записки	21.04.2010-20.05.2010	виконано
7	Підготовка презентації та доповіді	02.06.2010-04.06.2010	виконано



РЕФЕРАТ

Дипломная работа бакалавра: 66 с., 15 рис., 2 табл., 2 приложений, 7 источников.

Целью данного дипломного проекта является разработка информационной системы хранения для обработки и моделирования алгоритмов вычисления статистических данных для спортивых соревнований. Информационная система обеспечивает предоставлении информации о спортсменах, соревнованиях и предоставляет статистические данные по результатам соревнований.

В основе проектирования лежит метод, при котором первоначально строится информационно-логическая модель предметной области. Затем она отображается в даталогическую модель реляционной базы данных клиентской части. Данная бакалаврская работа реализована с использованием интерпретатора языка PHP и MySQL.

предметная область, объект, связь объектов, модель данных, реляционная модель данных, отношение, атрибут, кортеж, функциональная зависимость, первичный ключ, внешний ключ, нормализация, запрос



РЕФЕРАТ

Дипломна робота бакалавра: 66 с., 15 рис., 2 табл., 2 додатків, 7 джерел.

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

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

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

ABSTRACT

Bachelor degree work: 66 p., 15 fig., 2 tables, 2 applications, 7 notices.

The aim of this diploma project is the development of information storage, processing and modeling algorithms for computing statistics for athletic competition (in particular on swimming). The information system provides information about the swimmers, competitions, and provides statistical data on the results of the competition.

The basis of design is the method which originally built infological model domain. It appears in datalogical model of relational database client. This bachelor work done by the interpreter language PHP and MySQL.

application domain, object, relationship object, model data, relational model data, attitude, attribute, tuple, functional dependency, primary key, external key, normalization, request

ЗМІСТ

Вступ

1. Аналізпредметної області та постановка задачі бакалаврської роботи

1.1 Актуальність проблеми розробки баз даних

1.2 Архітектура бази даних

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

1.3.1 Система бізнес-правил

1.3.2 Глосарій проекту

1.4 Постановка задачі дипломної роботи бакалавра

2. Моделювання даних предметної області

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

2.1.1 Концептуальне проектування бази даних

2.1.2 Логічне проектування бази даних

2.1.3 Фізичне проектування бази даних

2.2 Моделювання алгоритмів обчислення статистичних даних для спортивних змагань

3. Результати використання розробленої програмної системи

3.1 Установка та запуск системи

3.2 Основні етапи роботи користувача

Висновки

Перелік посилань

Додаток А Зразки сторінок сайта

Додаток В Базові таблиці даних

• ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, СКОРОЧЕНЬ ТА ТЕРМІНІВ
• СУБД системи управління базами даних
• БД - база даних
• РБД - реляційна база даних
• UML - Unified Modeling Language
• ER- entity relationship
• НФ- нормальна форма
• FK- зовнішній ключ
• AK- альтернативний ключ
• ВСТУП
• В наш час життя людини насичене настільки великим обсягом інформації, що для її обробки потрібно створення величезної кількості сховищ інформації різного призначення.
• Сучасні інформаційні системи мають змогу зберігати дуже великі обсяги даних, вони складно організовані, можуть задовольняти найрізноманітніші вимоги численних користувачів.
• Основою інформаційних систем є бази даних. Метою будь-якої інформаційної системи є обробка даних про об'єкти реального світу. У широкому сенсі база даних - це сукупність відомостей про конкретні об'єкти реального світу в будь-якій предметній області. Крім того, база даних - це сховище даних для спільного використання [1-3].

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

Система управління базами даних поєднує відомості з різних джерел в одній реляційній базі даних. Створювані форми, запити і звіти дозволяють швидко й ефективно обновляти дані, отримувати відповіді на питання, здійснювати пошук потрібних даних, аналізувати дані, друкувати звіти, діаграми і поштові наклейки [4].

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

Реалізація бази даних здійснюється засобами MySQL, а створення клієнтського додатка в середовищі PHP (Personal Home Page Tools0), для здійснення взаємодії кінцевого користувача зі створеною базою даних.

1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ БАКАЛАВРСЬКОЇ РОБОТИ

1.1 Актуальність проблеми розробки баз даних

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

- фізичне розміщення даних та їх описів;

- пошук даних;

- підтримку баз даних в актуальному стані;

- захист даних від некоректних оновлень і несанкціонованого доступу;

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

Інакше кажучи, СУБД повинна включати в себе компонент мовного процесора для різних мов визначень даних. СУБД має також «розуміти» синтаксис мови визначення даних.

СУБД повинна вміти обробляти запити користувача на вибірку, зміну або видалення існуючих даних або на додавання нових даних в базу даних.

Іншими словами, СУБД повинна включати в себе компонент процесора мови обробки даних.

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

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

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

1.2 Архітектура бази даних

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

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

Існують такі різновиди архітектури БД:

а) локальні БД;

б) архітектура «файл - сервер»;

в) архітектура «клієнт - сервер»;

г) багаторівнева (N-tier або multi-tier) архітектура.

Вимоги до БД:

а) постійне розширення структури даних та вмісту даних;

б) пошук інформації;

в) знизити надмірність даних та підвищити їх надійність;

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

Для реалізації даної інформаційної системи була використана трирівнева (three-tier) архітектура.

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

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

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

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

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

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

У порівнянні з клієнт-серверною або файл-серверною архітектурою можна виділити наступні переваги трирівневої архітектури:

а) маштабованість;

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

в) висока безпека;

г) висока надійність;

д) низькі вимоги до швидкості каналу (мережі) між терміналами та сервером додатків;

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

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

а) більш висока складність у створенні додатків;

б) є складнішою в адмініструванні та розгортанні;

в) високі вимоги до продуктивності серверів додатків та сервера бази даних, що призводить до високої вартості серверного обладнання;

г) високі вимоги до швидкості каналу (мережі) між сервером бази даних та серверами додатків.

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

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

На сьогодні для моделювання предметної області існує широкий спектр CASE-засобів. Найпопулярніші CASE-засоби це Rational Rose, CA BPwin, Silverrun, Sybase та інші.

У даній бакалаврській роботі використане моделювання предметної області з використанням уніфікованої нотації, яка основується на використанні уніфікованої мови моделювання (Unified Modeling Language, UML).

Основними задачами при моделюванні предметної області є опис:

а) бізнес-процесів підприємства;

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

в) бізнес-сутностей;

г) сценаріїв виконання бізнес-функцій, що підлягають автоматизації;

д) стан бізнес-сутностей;

е) бізнес-правила.

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

Розробка діаграми варіантів використання переслідує цілі: а) визначити загальні кордони та контекст модельованої предметної області на початкових етапах проектування системи;

б) сформулювати загальні вимоги до функціональної поведінки проектованої системи;

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

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

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

Діаграми варіантів використання (use case diagram) для даної предметної області представлені на рисунку 1.1.

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

Повний проект програмної системи являє собою сукупність моделей логічного та фізичного рівнів, які повинні бути узгоджені між собою. У мові UML для фізичного представлення моделей систем використовуються діаграми реалізації (implementation diagrams), які включають в себе діаграму компонентів і діаграму розгортання [3].



Рисунок 1.1 - Діаграма варіантів використання

Рисунок 1.2 - Діаграма розгортання

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

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

а) візуалізації загальної структури вихідного коду програмної системи;

б) специфікації для використаного варіанту програмної системи;

в) забезпечення багаторазового використання окремих фрагментів програмного коду;

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

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

1.3.1 Система бізнес-правил

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

В загальному випадку існує три типи бізнес правил.

До першого типу належать правила виводу. Правила виводу (derivation rule) перетворюють вхідну інформацію в значення, що повертаються. Правила цього типу припускають зміни, тому перш ніж з ними працювати, необхідно визначити ці правила.

Рисунок 1.3 - Діаграма компонентів (component diagram)

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

Третій тип правил - інваріантні правила. Інваріантні правила (invariant rules) перевіряють множинні зміни та забезпечують несуперечливість кінцевого результату.

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

Система бізнес правил для предметної області моделювання алгоритмів статистичних даних для спортивних змагань (плавання).

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

б) користувач має змогу отримувати інформацію стосовно спортсменів, змагань та може переглянути статистичні дані;

в) рефері має пройти авторизацію, заповнивши поля «логін» та «пароль»;

г) після проходження авторизації рефері може реєструвати нові змагання;

д) тренер має пройти авторизацію, заповнивши поля «логін» та «пароль»;

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

ж) в одній команді може бути будь яка кількість спортсменів;

з) один спортсмен може бути лише в одній команді;

и) під час одного змагання спортсмен має змогу приймати участь у декількох видах змагань;

к) змагання характеризується датою, та назвою;

л) кожна окрема участь плавця у змаганні характеризується днем змагання, видом, заявкою та результатом, запливом, доріжкою, категорією, розрядом та ін.;

м) спортсмен характеризується фамілією, ім`ям, по батькові, роком народження, статтю;

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

1.3.2 Глосарій проекту

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

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

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

а) користувач - особа, що користується системою (без особливих можливостей);

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

в) тренер - тренер команди, має спеціальні можливості. При проході авторизації має змогу реєструвати свою команду у змаганні;

г) учасник - плавець, спортсмен. Головний об`єкт у системі. Вся інформація у системі стосується учасника, характеризує його успіхи в змаганнях;

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

е) види змагань - заданий перелік існуючих видів змагань;

ж) команда - спортсмени одного колективу, мають спільного тренера або тренерів.

1.4 Постановка задачі дипломної роботи бакалавра

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

Таким чином система повинна реалізувати наступні можливості:

а) реєстрування в системі нових команд;

б) реєстрування в системі нових спортсменів;

в) додавання особових даних спортсменів;

г) додавання нових змагань;

д) додавання повної інформації щодо змагань(назва, дата і так далі);

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

ж) обчислення рейтингу плавця;

з) обчислення рейтингу команди;

и) обчислення рейтингів тренерів.

база даний змагання плавання



2. МОДЕЛЮВАННЯ ДАННИХ ПРЕДМЕТНОЇ ОБЛАСТІ

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

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

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

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

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

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

2.1.1 Концептуальне проектування бази даних

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

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

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

До основних сутностей, які присутні у специфікаціях відносяться: distancii (дистанції), komanda (команда), osnovnaya (основна), referi (рефері), sorevnovaniya (змагання), trener (тренер), vid_sorevnovaniya (вид змагання), ychastniki (учасники).

Таблиця 2.1.1

Основні типи зв'язків

Тип сутності	Тип зв'язку	Тип сутності	Кардинальність
Дистанції	Містяться	Змагання	М:1
	Пов`язана	Вид змагання	М:1
Основна	Містить	Дистанції	М:N
	Містить	Учасники	М:1
	Містить	Команда	М:1
Команда	Характеризується	Тренер	М:1

Для більш наглядного уявлення про зв'язок між сутностями використовують модель даних «сутність-зв'язок», або ER-модель (від англійських entity - сутність та relationship - зв'язок), яка була запропонована в 1976 П. Ченом.

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

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

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

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

- потрібно вивести безліч формальних правил цілісності для роботи з такими формальними об'єктами;

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

Формально структурна специфікація ER-моделі задається наступним чином. Перш за все, вводиться множина E={E₁,...,E_m} типів сутностей, де E_i={e_i1,..., e_iMi} - множина сутностей. Введемо тепер множену R={R₁,..., R_p} типів зв'язків. Нехай (E₁,..., E_n) - сукупність сутностей (не обов'язково різних), що агрегуються в n-арний зв'язок Rj, L_j={l_j1,...,l_jn} - множина ролей кожного типу сутності E_k в типі зв'язку Rj. Тоді R_j={(l_j1/e_1,..., l_jn/e_n) | e₁E_1,..., e_nE_n}, де l_jk/e_k означає іменну роль l_jk сутністі e_k. Оскільки сутності в зв'язку супроводжуються своєю роллю, порядок їх розташування не важливий. Безлічі Е і R вважаються кінцевими, але не фіксованими.

Нехай тепер V_1,..., V_n - множина скалярних значень. Багатозначні агрегатне властивість можна визначити як відображення _i:E_i(V₁...V_K)^q, або _j: R_j(V₁...V_K)^q, де К - кількість агрегованих простих властивостей, показник декартового ступеня q - число повторень агрегату. При К = 1 отримуємо просту властивість. При q = 1 властивість є однозначною.

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

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

Об'єкти (і відносини) володіють деякими властивостями. Всі об'єкти одного типу володіють деякими загальними властивостями. Види властивостей та їх особливості:

а) проста або складова властивість;

б) ключова властивість (унікальна в певному контексті);

в) однозначна або багатозначна властивість;

г) немає властивості («невідома» або «не застосовується»);

д) базова або похідна властивість.

2.1.2 Логічне проектування бази даних

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

Для того щоб досягти необхідного результату необхідно:

а) видалити зв'язки M:N;

б) видалити складних зв'язків;

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

г) видалити зв'язків, які мають атрибути;

д) видалити надлишкових зв'язків.

У таблиці 2.2 наведений опис даних бази даних по обчисленню статистичних даних змагань.

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

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

Рисунок 2.1 - Діаграма «сутність-зв'язок»

Таблиця 2.2

Опис даних

Елемент даних	Опис	Об'єкт	Тип даних	Умова призначення
1	2	3	4	5
Kod_Sorevnovaniya	Ідентифікаційний код змагання	distancii	int	NOT NULL
Poryadok_Sortirovki	Порядок сортування	distancii	int	NOT NULL
Den_Provedeniya	Дата народження	distancii	int	NOT NULL
Vid_Sorevnovaniya	Вид змагання	distancii	int	NOT NULL
Kod_Komandi	Код команди	komanda	int	NOT NULL
Komanda	Назва команди	komanda	text	NOT NULL
Trener	Ідентифікаційний номер	komanda	int	NOT NULL
Kod	Код	osnovnaya	int	NOT NULL
Kod_Sorevnovaniya	Код змагання	osnovnaya	int	NOT NULL
Poryadok_Sortirovki	Порядок сортування	osnovnaya	int	NOT NULL
Den_Provedeniya	День проведення змагання	osnovnaya	int	NOT NULL
Vid_Sorevnovaniya	Вид змагання	osnovnaya	int	NOT NULL
Kod_Ychastnika	Ідентифікаційний номер учасника	osnovnaya	int	NOT NULL
Kod_Komandi	Ідентифікаційний номер команди	osnovnaya	int	NOT NULL
Zayavka	Подана заявка (на результат запливу)	osnovnaya	varchar	DEFAULT NULL
Rezultat	Результат запливу (час)	osnovnaya	varchar	DEFAULT NULL
Zapliv	Номер запливу	osnovnaya	int	DEFAULT '0'
Dorogka	Номер доріжки на якій пливе/плистиме даний спортсмен	osnovnaya	int	DEFAULT '0'
PU	Першість України	osnovnaya	tinyint	DEFAULT '0'
KU	Кубок України МУЖ/ЮН, Ж/Д	osnovnaya	varchar	DEFAULT NULL
KU_L	Кубок України Логічні	osnovnaya	tinyint	DEFAULT '0'
LP	Особиста першість	osnovnaya	tinyint	DEFAULT '0'
VK	Поза конкурсом	osnovnaya	tinyint	NOT NULL DEFAULT '0'
KB	Командна боротьба	osnovnaya	tinyint	NOT NULL DEFAULT '0'
Ochki	Набрані очки за заплив	osnovnaya	float	NOT NULL DEFAULT '0'
Kategoriya	Категорія спортсмена	osnovnaya	char	DEFAULT NULL
Razryad	Разряд спортсмена	osnovnaya	varchar	DEFAULT NULL
Kopirovanie	Копіюваня	osnovnaya	tinyint	NOT NULL DEFAULT '0'
id	Ідентифікаційний код рефері	referi	int	NOT NULL
login	Логін рефері для авторизації	referi	varchar	NOT NULL
pasword	Пароль рефері для авторизації	referi	varchar	NOT NULL
Kod_Sorevnovaniya	Ідентифікаційний код змагань	sorevnova-niya	int	NOT NULL
Sorevnovaniya	Назва змагань	sorevnova-niya	varchar	NOT NULL
Data_Sorevnovaniya	Дата змагання	sorevnova-niya	date	NOT NULL
Memo	Закриття змагання	sorevnova-niya	tinyint	NOT NULL
Kod_Trenera	Ідентифікаційний код тренера	trener	int	NOT NULL
Trener	Фамілія тренера	trener	varchar	NOT NULL
Login	Логін тренера для авторизації	trener	varchar	NOT NULL
Parol	Пароль тренера для авторизації	trener	varchar	NOT NULL
Kod	Ідентифікаційний код змагання	vid_sorevnovaniya	int	NOT NULL
Vid_sorevnovaniya	Вид змагання	vid_sorevnovaniya	varchar	DEFAULT NULL
ZMSM	Заслужений майстер спорту (чоловіки)	vid_sorevnovaniya	varchar	DEFAULT NULL
MSMKM	Майстер спорту міжнародного класу (чоловіки)	vid_sorevnovaniya	varchar	DEFAULT NULL
MSM	Майстер спорту (чоловіки)	vid_sorevnovaniya	varchar	DEFAULT NULL
KMSM	Кандидат в майстри спорту (чоловіки)	vid_sorevnovaniya	varchar	DEFAULT NULL
M1	1 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
M2	2 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
M3	3 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
M4	4 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
ZMSG	Заслужений майстер спорту (жінки)	vid_sorevnovaniya	varchar	DEFAULT NULL
MSMKG	Майстер спорту міжнародного класу (жінки)	vid_sorevnovaniya	varchar	DEFAULT NULL
MSG	Майстер спорту (жінки)	vid_sorevnovaniya	varchar	DEFAULT NULL
KMSG	Кандидат в майстри спорту (жінки)	vid_sorevnovaniya	varchar	DEFAULT NULL
G1	1 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
G2	2 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
G3	3 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
G4	4 розряд	vid_sorevnovaniya	varchar	DEFAULT NULL
Kod_Ychastnika	Ідентифікаційний код	ychastniki	int	NOT NULL
Familiya	Прізвище	ychastniki	varchar	NOT NULL
Imya	Ім`я	ychastniki	varchar	NOT NULL
Otchestvo	По-батькові	ychastniki	varchar	NOT NULL
God_Rogdeniya	Рік народження	ychastniki	int	NOT NULL
Pol	Стать	ychastniki	varchar	NOT NULL

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

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

а) нормалізація проекту дозволяє організувати розміщення даних згідно з їх функціональною залежністю. Тому дана процедура повинна виконуватися між етапами концептуального та фізичного проектування;

б) нормалізація проекту дозволяє підвищити його стійкість та позбавитись від аномалій оновлення;

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

Процес нормалізації включає наступні чотири основних етапи:

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

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

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

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

Отже, алгоритм нормалізації (тобто алгоритм приведення відносин до 3НФ) описується наступним чином.

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

Приведення до 2НФ. Якщо в деяких відносинах виявлена залежність атрибутів від частини складного ключа, то проводимо декомпозиція цих відносин на кілька відносин наступним чином: ті атрибути, які залежать від частини складного ключа виносяться в окрему відносину разом з цією частиною ключа. У вихідному відношенні залишаються всі ключові атрибути:

Вихідне відношення:..

Ключ: - складний.

Функціональні залежності:

- залежність всіх атрибутів від ключа відносини. - залежність деяких атрибутів від частини складного ключа.

Декомпозиція відносини:

- залишок від вихідного відносини. Ключ .

- атрибути, винесені з вихідного відносини разом з частиною складного ключа. Ключ .

Приведення до 3НФ. Якщо в деяких відносинах виявлена залежність деяких не ключових атрибутів до інших не ключових атрибутів, то проводимо декомпозицію цих відносин наступним чином: тобто не ключові атрибути, які залежать від інших не ключових атрибутів виносяться в окрему відносину. У новому відношенні ключем стає детермінант функціональної залежності:

Вихідне відношення:.

Ключ: .

Функціональні залежності:

- залежність всіх атрибутів від ключа відносини.

- залежність деяких не ключових атрибутів інших не ключових атрибутів.

Декомпозиція відносини:

- Залишок від вихідного відносини. Ключ..

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

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

Для того щоб привести модель «сутність-зв'язок», отриману на етапі концептуального проектування до логічної моделі вилучимо зв'язки типу M:N шляхом введення нової проміжної сутності. Зв'язок типу M:N замінюється на два зв'язки типу 1:М, встановлюваними зі створеною сутністю.

Розглянемо зв'язок типу M:N «Вид змагання - Дистанція». З метою його вилучення створимо нову сутність «Змагання» в яку винесемо поля «Код змагання», «Змагання», «Дата змагання», «Мемо». Тепер сутність «Змагання» має зв'язок 1:М з сутністю «Дистанція», також зв'язок 1:М між сутностями «Вид змагання» та «Дистанція»

Зв'язок типу M:N «Основна - Учасники» вилучаємо за допомогою створення двох сутностей «Команда» та «Тренер». У сутність «Команда» виносимо поля «Код команда», «Команда», «Тренер», а у сутність «Тренер» - поля «Код тренера», «Тренер», «Логін», «Пароль». Між сутностями «Основна» та «Команда» тепер зв'язок М:1, такий самий зв'язок між сутностями «Команда» та «Тренер»

Отримана модель зображена на рисунку 2.2:

Рисунок 2.2 - Отримана діаграма

2.1.3 Фізичне проектування бази даних

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

Логічна модель на рисунку 2.3:

Рисунок 2.3 - Логічна модель даних

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

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

а) ім'я відношення;

б) список простих атрибутів;

в) визначення первинного ключа та (якщо такі існують) альтернативних (АК) та зовнішніх (FK) ключів;

г) визначення вимог цілісності зв'язків для будь-яких зовнішніх ключів.

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

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

б) значення, яке атрибут приймає за замовчуванням (не обов'язково);

в) допустимість значення NULL для даного атрибуту;

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

Для даної предметної області фізичне проектування має вигляд як на рисунку 2.4:

2.2 Моделювання алгоритмів обчислення статистичних даних для спортивних змагань

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

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

Рисунок 2.4 - Фізична модель даних



Нехай є n об'єктів, для яких виміряна деяка характеристика, і отримані значення . Середнє арифметичне цих n значень позначають через і визначають як:

, (2.1)

або

.(2.2)

Символом зі змінним індексом i позначають наступну суму:

.(2.3)

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

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

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

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

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

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

а) обсяг сукупності непарних;

б) обсяг сукупності парних.

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

(2.4)

то

.(2.5)

Якщо ж кількість елементів парне, і Один , то немає Способи, яка б ділила сукупність на дві рівні за обсягом частини:

(2.6)

Тому як медіана умовно береться півсума варіант, що знаходяться в середині варіаційного ряду:

(2.7)

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

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

Введемо позначення:

- початок медіанного інтервалу;

- ширина медіанного інтервалу;

- частота медіанного інтервалу;

- сума частот інтервалів, що передують медіа;

- обсяг сукупності;

- накопичена частота до значення медіани;

- частота інтеравала від до , ширина якого дорівнює - .

Абсолютна щільність розподілу на медіанному інтервалі дорівнює .

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

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

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

(2.8)

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

- довжина модального інтервалу;

- частота модального інтервалу;

- частота інтервалу, що передує модальною;

- частота інтервалу, наступного за модальним.

Мінімум - наіменшее значення вибірки.

Максимум - найбільше значення вибірки.

Діапазон (максимальна відстань) - різниця між найбільшим і наіменшім значеннями вибірки.

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

(2.9)

Для більш наочної уяви про вариації ознакиа використовується коэфіцієнт варіації:

(2.10)

Коэфіцієнт варіації показує міру змінності ознаки в процентах [5-7].

Реалізовуємо статистичні обчислення за допомогою SQL запитів.

SQL (Structured Query Language) - це стандартна мова реляційних баз даних. SQL є мовою для роботи з таблицями з метою перетворення вхідних даних до потрібного вихідного вигляду. Мова SQL має два основних компоненти:

- мова DDL (Data Definition Language) призначена для визначення структур баз даних;

- мова DML (Data Manipulation Language) призначена для вибірки та визначення даних.

SQL оперує термінами, що відрізняються від термінів реляційної теорії: замість "відносин" використовуються "таблиці", замість "кортежів" - "строки", замість "атрибутів" - "колонки" або "стовпчики".

Стандарт мови SQL заснований на реляційної теорії, але в багатьох місцях відрізняється від неї.

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

Основні переваги мови SQL полягають в наступному:

а) стандартність - використання мови SQL в програмах, які стандартизовані міжнародними організаціями;

б) незалежність від конкретних СУБД - всі розповсюджені СУБД використовують SQL, тому що реляційну базу даних можна перенести з однієї СУБД на іншу з мінімальними доробками;

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

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

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

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

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

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

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

Будь-яка мова роботи з базами даних повинна надавати користувачеві наступні можливості:

- створювати бази даних і таблиці з повним описом їх структури;

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

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

Створювання таблиць виконується за допомогою оператора CREATE TABLE.

Синтаксис оператора виглядає так:

CREATE [ TEMPORARY ] TABLE таблиця (поле _1 тип [(розмір)] [ NOT NULL ]

[індекс_1] [, поле_2 тип [(розмір)] [ NOT NULL ] [індекс_2] [,...]]

[,составний_індекс [,...]])

Аргументи інструкції CREATE TABLE:

таблиця - ім'я створюваної таблиці;

поле_1, поле_2 - імена одного чи декількох полей, створюваних в новій таблиці. Таблиця повинна мати хоча б одно поле;

тип - тип данних поля в новій таблиці;

розмір - розмір поля у знаках (тільки для текстових та двоїчних полей);

індекс_1, індекс_2 - предложение CONSTRAINT, предназначенное для создания простого индекса;

составной_индекс - предложение CONSTRAINT, предназначенное для создания составного индекса.

Если для поля добавлено ограничение NOT NULL, то при добавлении новых записей это поле должно содержать допустимые данные.

Наприклад запит для створення таблиці «Основна» виглядає як у лістингу 3.1.

Лістинг 3.1 - Створення таблиці «Основна»

CREATE TABLE IF NOT EXISTS `osnovnaya` (

`Kod` int(11) NOT NULL AUTO_INCREMENT,

`Kod_Sorevnovaniya` int(10) unsigned NOT NULL DEFAULT '0',

`Poryadok_Sortirovki` int(10) unsigned NOT NULL DEFAULT '0',

`Den_Provedeniya` int(10) unsigned NOT NULL DEFAULT '0',

`Vid_Sorevnovaniya` int(10) unsigned NOT NULL DEFAULT '0',

`Kod_Ychastnika` int(10) unsigned NOT NULL DEFAULT '0',

`Kod_Komandi` int(10) unsigned NOT NULL DEFAULT '0',

`Zayavka` varchar(10) CHARACTER SET cp1251 DEFAULT NULL,

`Rezultat` varchar(10) CHARACTER SET cp1251 DEFAULT NULL,

`Zapliv` int(3) unsigned DEFAULT '0',

`Dorogka` int(1) unsigned DEFAULT '0',

`PU` tinyint(1) unsigned DEFAULT '0',

`KU` varchar(30) CHARACTER SET cp1251 DEFAULT NULL,

`KU_L` tinyint(1) unsigned DEFAULT '0',

`LP` tinyint(1) unsigned DEFAULT '0',

`VK` tinyint(1) unsigned NOT NULL DEFAULT '0',

`KB` tinyint(1) unsigned NOT NULL DEFAULT '0',

`Ochki` float NOT NULL DEFAULT '0',

`Kategoriya` char(3) CHARACTER SET cp1251 DEFAULT NULL,

`Razryad` varchar(4) CHARACTER SET cp1251 DEFAULT NULL,

`Kopirovanie` tinyint(1) unsigned NOT NULL DEFAULT '0',

PRIMARY KEY (`Kod`))

До основних операторів мови SQL DML відносять

а) SELECT - вибір даних з бази;

б) INSERT - вставка даних у таблицю;

в) UPDATE - оновлення (зміна) даних у таблиці;

г) DELETE - видалення даних з таблиці.

Формування запитів - основна операція мови SQL, що називається відображенням. Синтаксично це блок - SELECT-FROM-WHERE.

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

Формат команди вибірки з однієї таблиці:

SELECT [DISTINCT | ALL] <цільової список> FROM <ім'я таблиці>, WHERE <предиката>, де цільової список - список імен стовпців і / або виразів над стовпцями, елементи списку вказуються через кому (порядок елементів даних у цільовому списку визначає порядок вибірки даних);

ім'я таблиці - ім'я таблиці, з якої вибираються дані;

предиката - умова вибірки.

Наприклад при додаванні тренером нової заявки тренером використовуємо запит, показаний у лістингу 3.2.

Лістинг 3.2 - Додавання нової заявки

$query = "select Den_Provedeniya,Poryadok_Sortirovki

from distancii

where Vid_Sorevnovaniya = 1 and Kod_Sorevnovaniya =