МОСКІВСЬКИЙ ДЕРЖАВНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ «МАМІ»

КУРСОВА РОБОТА

з дисципліни: Інформаційне забезпечення систем управління

на тему: «Розробка бази даних футбольного клубу»

Виконав: студент 642 групи

Плетньов Микола Вікторович

Перевірив: викладач

Семеніхін Геннадій Ілліч

Серпухів 2009

Зміст Завдання

Вступ

1.Опис діяльності організації

3. Розробка бази даних серед СУБД Access 2003

3.1 Створення таблиць

3.2 Створення схеми даних

3.3 Створення форм

3.4 Створення запитів на мові QBE та SQL

3.5 Створення звітів

4.Словник термінів

Висновок

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

Завдання

1. Провести опис діяльності футбольного клубу «Челсі», сформулювати основні завдання його інформаційно-керуючої системи та обґрунтувати вимоги до його бази даних.

2. Розробити модель «сутність-зв'язок» БД:

Розробити перелік сутностей та їх атрибутів

Виділити зв'язки між сутностями

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

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

Додати не ключові атрибути у відносини

За необхідності скоригувати діаграми ER-типу

3.Реалізувати розроблену реляційну БД інформаційно-керуючої системи футбольного клубу «Челсі» у середовищі СУБД Access 2003.

4. Розробити не менше 2-х звітів і не менше 5-7 запитів до БД, з використанням засобів СУБД та мов QBE та SQL з обґрунтуванням їх використання в Організації.

Вступ

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

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

За допомогою Microsoft Access можна створювати таблиці, форми та інші об'єкти, що становлять бази даних. Особливістю є створення запитів з допомогою запиту SQL.

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

Запит SQL - це запит, створюваний з допомогою різних операторів, наприклад:Select,UpDate чи DELETE. Прикладами запитів SQL можуть бути запити на об'єднання, запити до сервера, керуючі та підлеглі запити.

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

1. Опис діяльності футбольного клубу «Челсі»

інформаційний керуючий база access

Футбольний клуб "Челсі" (Chelsea Football Club) був заснований у 1905 році в Лондоні. Виступає цей клуб в Англійській прем'єр-лізі (Чемпіонат Англії). ФК Челсі має прізвисько серед уболівальників – Аристократи. Це прізвисько сталося через багатий район Лондона. Той самий район у якому живуть найзаможніші громадяни туманного Альбіону. Виступ ФК Челсі в 20 столітті вважалося не дуже яскравим, і тому їх вважали середнячком в Англії. У 1955 році вони вперше стали чемпіонами Англії. У європейських кубках ФК Челсі виступав рідко і успіх був не вражаючим. Однак у 1971 році їм вдалося виграти кубок кубків Європи після перемоги у кубку Англії, за рік раніше. Наприкінці 20-го століття аристократи виграли ще один кубок кубків, а потім і Суперкубок Європи. Це був найбільший титул історії клубу. Коли ФК Челсі купив російський мільярдер, губернатор Чукотки Роман Абрамович, клуб придбав безліч зіркових гравців, таких як Петро Чех, Рікард Карваль, Клод Макелеле, Жеремі і т.д. З такими гравцями клуб став одним із найсильніших у Європі. І 2005 року виграв свій другий чемпіонський титул в Англії. Останнім часом у клуб прийшли не менш знамениті гравці як Арьєн Роббен, Міхаель Баллак, Андрій Шевченко, Дідьє Дрогба. Ці гравці допомогли здобути третій титул чемпіона Англії. ФК Челсі за останні два роки виходив до півфіналу ліги чемпіонів.

Стадіон на якому грає Челсі – «Стемфорд Брідж» із місткістю 42 142 особи, включаючи VIP-крісла. Президентом клубу є Брюс Бак. Аристократи мають свій сайт в Інтернеті для вболівальників www.chelseafc.com.

Систему управління футбольним клубом «Челсі» можна розбити на кілька підсистем:

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

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

Робота з уболівальниками як основна частина підтримки в моральному плані. Саме кількість уболівальників визначає популярність клубу у світі.

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

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

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

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

2. Розробка моделі «сутність-зв'язок» бази даних

Для розробки моделі «Сутність-зв'язок» потрібно дотримання наступних етапів проектування:

1. Виділити сутності та зв'язки між ними.

2. Побудувати діаграми ER-типу.

3. Формування набору попередніх відносин із зазначенням їх первинних ключів.

4. Додавання не ключових атрибутів у відносини.

5. Приведення попередніх відносин до 3 посиленої нормальної форми.

Розробка моделі «Сутність-зв'язок» футбольного клубу «Челсі»:

1-ий етап: Статус (Код, Вид статусу)

Гравець (Код, Прізвище, Ім'я, Амплуа, Вік, …)

Досягнення (Прізвище, Ім'я, Число матчів...)

Контракт (Номер контракту, Прізвище...)

Персонал (Код, Прізвище, Ім'я)

2-ий етап: Виділимо зв'язки та визначимо клас власності:

Гравець має статус

Гравець має Досягнення

Персонал має статус

Гравцю відповідає Контракт

Персоналу відповідає Контракт

За отриманими даними будуємо діаграму ER-типу:

Гравець

Статус

1 1

Контракт

Гравцю

1 1 1 1

Гравець

Досягнення

М 1 1 1

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

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

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

Правило 3: Якщо ступінь зв'язку 1:1 і клас належності обох сутностей необов'язковий, необхідно використовувати три відносини з первинними ключами, два відносини пов'язані співвідношеннями.

Правило 4: Якщо ступінь зв'язку 1: М і клас належності КП обов'язковий, достатньо формувати два відносини по одному на кожну сутність.

Правило 5:Якщо ступінь зв'язку 1:М і клас приналежності М-зв'язної сутності необов'язковий, необхідно формування 3х відносин, 2 відносини відповідні пов'язані сутності, ключі яких є первинними у цьому плані.

Правило 6: Якщо ступінь зв'язку М: М і клас власності сутності обов'язковий, то незалежний від класу власності сутності.

За правилом 1: 1. Статус (Код, Вид статусу .....)

За правилом 5: 1.Статус (Код, Вид статусу……)

2.Гравець (Код, Прізвище ……)

3.Контракт (Номер контракту, Прізвище …..)

За правилом 1: 1.Досягнення (Прізвище, ...)

За правилом 2: 1. Персонал (Код, Прізвище ….)

2.Контракт (Номер контракту, Прізвище ….)

3. Розробка бази даних серед СУБД Access 2003

3.1 Створення таблиць

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

У базі даних футбольного клубу «Челсі» міститься 5 таблиць, створених за допомогою майстра таблиць.

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

Має подію Сlick. Обробники подій Click для кнопок представлені в Додатку А. Висновок Під час виконання курсової роботи було досягнуто мети роботи – проектування бази даних господарського обліку футбольного клубу. Для досягнення мети було вирішено низку завдань: складання опису предметної галузі; складання словника понять та термінів; побудова вихідної моделі (ER- ...

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

... "Трактор", "Динамо", "Торпедо", "Камвольник", "Локомотив", будівництво футбольного комплексу "Сквіч", що включає манеж, стадіон зі стандартним футбольним полем. 2. Мінськ – ресурс соціально-економічного розвитку Білорусі Мінськ, якому нещодавно виповнилося 940 років, у всі часи був великою адміністративною одиницею – столицею удільного князівства, воєводським центром у Великому...

У матеріалі пропонуються поурочні розробки на тему "База даних - основа інформаційної системи" для 11 класу базового рівня навчання. Розробки дано для 6 навчальних годин. Уроки спрямовані на проектну діяльність учнів, мається на увазі самостійна домашня робота учнів над проектами. Безперечно, як і будь-яка проектна діяльність учнів, від викладача вимагається досконале знання матеріалу цієї галузі, для правильної допомоги учням під час роботи над проектами. Матеріал підготовлений на основі підручника для 10-11 класу Семакін (домашні завдання посилаються на нього).

Завантажити:

Попередній перегляд:

Поурочні розробки на тему:

"База даних - основа інформаційної системи".

Інформатика та ІКТ

11 клас

Вчитель інформатики та ІКТ

МБОУ ЗОШ №10

Алексєєва Оксана Юріївна

2012-2013 навчальний рік

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

Інформаційно-пошукова система (БД та СУБД); поняття інформаційних структур даних: реляційна (таблиця), ієрархічна (дерева) та мережева; об'єкти бази даних: поле, за лист, ключове поле; формати типів даних СУБД «MS Access» та її тан терфейс.

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

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

Концепція структури бази даних.

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

Цілі вивчення теми:

1. Освітні:

1. познайомити учнів із поняттями: інформаційно-пошукова система, база даних, системний аналіз та інфологічна модель, із класифікацією БД;
2. показати практичне застосування теоретичного матеріалу;
3. дати початкові вміння працювати з системою управління базою даних Microsoft Access.

1. Розвиваючі:

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

1. Виховні:

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

Урок №1 База даних Microsoft Access

Елементи змісту:призначення БД, види моделей даних, структура реляційної моделі, СУБД. Практична робота №1 «Знайомство із СУБД Microsoft Access».

Тип уроку: урок вивчення нового матеріалу

Вигляд уроку: комбінований.

Форми роботи:

Обладнання:

1. Схема №1;
2. Схема №2;
3. Схема №3;
4. Таблиця №1;
5. Аркуші із послідовністю побудови структури бази даних (за кількістю учнів);
6. Список класів школи;

ХІД УРОКУ

I. Організаційний момент.Привітання учнів.

Уявіть себе у ролі директора нашої школи. Змогли б ви згадати всі відомості про успішність учнів, громадську роботу, поведінку учнів. А домашня адреса, місце роботи батьків, стан здоров'я кожного учня тощо. Така рутинна робота переслідує кожного керівника великого колективу.
Хто з вас знає, а як раніше зберігалися дані про співробітників певного колективу?(У картотеках: як висувних ящиків, де у алфавітному порядку стояли особисті справи співробітників).
З появою комп'ютерів люди почали замислюватися, а як би занести на згадку про комп'ютер дані і потім з ними працювати (здійснювати пошук, доповнювати і змінювати відомості). Так було створено спеціальні програми, які дозволяли здійснити всі ці операції. Вони отримали назву – інформаційно-пошукові системи. Нині вони застосовуються у всіх галузях людської діяльності: у банках, магазинах, бібліотеках тощо. На уроці розглянемо поняття інформаційно-пошукової системи, бази даних, основні елементи та види баз даних, познайомимося з однією із систем управління базами даних – Microsoft Access.
ІІ. Теоретична частина.

Розглянемо з вами ситуацію із керівником великого колективу. Кожен із вас, хто відвідує бібліотеку, знає, як доводиться часом довго шукати в каталозі необхідну книгу, особливо, якщо точно не знаєш назву книги та автора.
Наведені мною ситуації мають багато спільного: у великій кількості даних ми шукаємо інформацію, яка необхідна в даний момент. В обох ситуаціях йдеться фактично про безліч однотипних об'єктів. Для кожного з цих об'єктів суттєвими є лише деякі ознаки.
Що ви вважаєте для учнів ознаками?(Зростання, прізвище, ім'я, по батькові, адреса місця проживання, рік народження тощо)
Для кожного учня ми можемо конкретизувати наші ознаки та отримуватимемо значення ознак.
Отже, пошук інформації можна доручити комп'ютеру. Для цього було створено програми – інформаційно-пошукові системи.

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

1. велика, спеціально організована сукупність даних (вона називається базою даних);
2. програма, що дозволяє оперувати цими даними (СУБД – система управління базою даних)(Записати до зошита).

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

Розглянемо схему №1

Схема №1.

компоненти

організація

Ієрархічні Мережеві Реляційні

DBIG,

IDS RUC, SQL/DS, DB2,

IMS, OKA Банк, Сетор, DBASE, KAPAT,

Мережа, FOXBASE, RBASE,

Сіод PARADOX, Clarion

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

Завдання. На дошці наведено деяку сукупність даних. Яку корисну інформацію ви можете витягти з неї?

1, 3, 5; ТУ-154; Тюмень; 4, 7; Москва; 8-40; АН-24; Іжевськ; 16-20; ТУ-134; 320; 308; 3107; 17-35; 1, 3, 5, 7.

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

Розглядаємо таблицю №1

Таблиця №1.

Аеропорт призначення	Номер рейсу	Тип літака	Дні відправлення	Час Відправлення
Москва		ТУ-154	1,3,5	16-20
Іжевськ		АН-24		17-35
Тюмень	3107	Ту-134	1,3,5,7	8-40

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

Схема №2.

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

– Третій різновид структури даних називаєтьсямережею.

Схема №3.

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

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

1. за характером інформації, що зберігається

1. фактографічні (коротка інформація в одному форматі: картотека)
2. документальна (різні документи – тексти, графіка, відео, звук тощо: архів)

1. за способом зберігання даних

1. централізовані (вся інформація зберігається одному комп'ютері – на сервері)
2. розподілені (інформація зберігається у локальній чи глобальній мережі)

1. за структурою організації даних

1. реляційна – таблична (використовується найчастіше і є універсальним)
2. ієрархічна
3. мережева.

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

Принципи, що у основі розробки структури БД:

1. Правильність розробленої структури (поля унікальні, тип, розмір, формат):

1. кожен елемент таблиці є одним елементом даних, повторювані елементи відсутні;
2. всі поля у таблиці однорідні;
3. поля мають унікальні ідентифікатори.

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

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

ІІІ. Практична робота №1

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

На партах у учнів лежить аркуш зі списком класів у нашій школі.

– Будувати ми будемо у наступній послідовності (на партах розкладено аркуші із послідовністю побудови).

Побудова структури даних за наступною послідовністю:

1. Визначаються об'єкти опису;
2. Визначаються ознаки цих об'єктів;
3. Вибирається тип структури, що відображає зв'язок між об'єктами (таблиці, дерева, мережі);
4. Будується конкретний екземпляр структури.

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

1. Після того, як завантажилася програма, комп'ютер пропонуєСтворити базу даних, Відкрити вже раніше створені бази даних. Ми вибираємо Створити нову.
2. Далі комп'ютер пропонує дати назву вашій базі даних (назвемосвоїм прізвищем та ім'ям), після цього клавішаСтворити.
3. У діалоговому вікні пропонуються варіанти побудови:Побудова таблиці як конструктора, Побудова таблиці за допомогою майстра, Побудова таблиці шляхом введення даних(Про кожний варіант вчитель повідомляє його суть). Ми вибираємоПобудова таблиці за допомогою конструктора.
4. У діалоговому вікніНова таблиця вибираємо підменюКонструктор . З'являється вікно, в якому заносяться ознаки наших об'єктів та типи даних, тобто будуємо макет таблиці.
5. Далі зберігаємо цю таблицю під назвоюКласи і закриваємо її натисканням на хрестик у верхньому правому куті вікна.
6. У діалоговому вікні бази даних з'явиться назва таблиці, подвійним клацанням відкриваємо цю таблицю. Пропонується макет таблиці і тут ви можете вносити значення визначених нами ознак запропонованого набору об'єктів.

Учні створюють базу даних, хто виконав всю роботу, сідають за свої місця.

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

1. Лікарня (стаціонар)
2. Лікарня (поліклініка)
3. Розклад уроків свого класу
4. Бібліотека (книги, читачі)
5. ДТП (учасники, машини, обставини ДТП)
6. Футбольний чемпіонат (команди, графік ігор, результати ігор, футболісти)
7. Міська телефонна мережа (наприклад, телефони всіх моїх друзів)
8. Авіарейси (літаки, пілоти, рейси, пасажири)
9. Відділ кадрів нашої школи (співробітники, посади, стаж роботи, …)
10. Магазин (відділи, товари, продавці, постачальники)
11. Вступні іспити до ВУЗу (факультети, спеціальності, абітурієнти, іспити, оцінки)
12. Каталог музики (диски, виконавці, назви пісень)

§31 підручника, вміти відповідати питання після §.

VI. Підбиття підсумків уроку

1. Інформаційно-пошукова система.
2. База даних, система керування базою даних.
3. Банк даних.
4. Реляційна база даних
5. Запис.
6. Поле записи.
7. Ієрархічна база даних.
8. Мережа бази даних.

Виставлення оцінок.

Урок №2. Проектування багатотабличної бази даних

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

Предметна область- РОЗКЛАД УРОКІВ

Ціль використання інформаційної системи- Навчальна.

Тип уроку : урок вивчення нового матеріалу

Вигляд уроку : комбінований.

Форми роботи:

1. Пояснення нового матеріалу – фронтальна робота
2. Практична робота – індивідуальна робота.

Обладнання: Програмне забезпечення: Microsoft Word.

ХІД УРОКУ

I. Організаційний момент.Привітання учнів.Перевірка д/з та виставлення оцінок.

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

ІІ. Фронтальне опитування:

Що називається моделлю?(Новий об'єкт, що замінює вихідний з будь-якою метою).

Від чого залежить властивості моделі?(Властивості моделі залежить від її призначення).

Які види інформаційних моделей ми знаємо?(Таблічні та графи)

Які види табличних моделей ми знаємо?(ОС, ТОВ, ООН, ВЗГ)

ІІІ. Теоретична частина.

Записати у зошит:

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

Властивості інфологічної моделі теж залежить від її призначення.

Визначимо призначення нашої майбутньої інформаційної системи. З неї ми повинні дізнатися:

1. В які дні тижня вчимося
2. Для яких класів складено розклад
3. Початок і кінець кожного уроку
4. В якому кабінеті та в якого вчителя проходить урок

Побудуємо граф нашінформаційної системи(на дошці). Основні об'єкти та зв'язки між ними:

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

Які ще зв'язки ми тут бачимо? Розклад «складено для» дня тижня, розклад «складено для» класів, розклад «складено для» кабінетів – тип «один до багатьох». Уроки "проходять в" кабінетах - зв'язок "один до одного". Уроки «проходять в» класах, класи «вчаться в» кабінетах – зв'язок «багато хто до багатьох».

IV. Практична робота №2.

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

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

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

VI. Постановка домашнього завдання

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

§ 32 підручника, вміти відповідати на запитання після §

VII. Підбиття підсумків уроку

На дошці виписані нові поняття, вивчені на уроці, і повторення матеріалу з учнями ведеться з них.

1. Системний аналіз.
2. Інфологічна модель.

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

Виставлення оцінок.

Урок №3 Створення БД

Мета уроку: створення БД, створення зв'язків у багатотабличній БД

Тип уроку: Урок закріплення матеріалу, що вивчається

Вигляд уроку: комбінований.

Форми роботи:

1. Перевірка д/з та виставлення оцінок
2. Опитування із закріплення нового матеріалу – фронтальне опитування
3. Практична робота – індивідуальна робота.

Обладнання:

1. Аркуші з тестовими питаннями на тему «Бази даних» (за кількістю учнів);
2. Програмне забезпечення: СУБД Microsoft Access.

ХІД УРОКУ

I. Організаційний момент. Вітання учнів

ІІ. Фронтальне опитування:

Що таке системний аналіз?(процес створення інфологічної (інформаційно-логічної моделі)

Що називається інфологічною моделлю?(структурна модель реальної системи, що відображає її основні складові та зв'язки між ними)

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

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

Як класифікуються БД? (за характером інформації, що зберігається, за способом зберігання даних, за структурою організації даних)

Що таке структура?(Вигляд організації даних)

Які види структур БД ми знаємо?(Реляційна - таблиці, ієрархічна - дерево, мережева)

Що таке поле? (Стовпець таблиці БД)

Назвіть основні характеристики поля

Що таке записування?(Рядок таблиці БД)

(її призначення)

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

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

Перша нормальна форма – кожне поле щодо неподільне.

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

Третя нормальна форма – щодо має бути транзитивних залежностей.

ІІІ. Практична робота №3.

База даних «Розклад уроків»

Відносини, що становлять цю базу:

Тиждень (День , День тижня)

Розклад (День, Клас, Урок , Кабінет, Предмет)

Класи (Клас , Число уч, Клас_рук)

Уроки (Урок , Початок уроку, Кінець уроку)

Кабінети (Кабінет , Поверх, Предмет, Вчитель)

У базі даних Access можна використовуватитри типи ключових полів: лічильник, простий ключ та складовий ключ.

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

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

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

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

Для зв'язування таблиць потрібно виконати команди

Сервіс  Схема даних. Відкриється вікно Додавання таблиці.

Виділити назву таблиці, виконати командуДодати. Закрити.

В результаті на полі вікнаСхема даних з'являться образи 5 таблиць. Натиснувши ліву клавішу миші, перетягніть ключове полеКлас таблиці Розклад на поліКлас з таблиці Моя підгрупа. Відкриється вікноЗв'язки. Послідовно активізувати прапорці "Забезпечити цілісність даних", "Каскадне оновлення пов'язаних полів", "Каскадне видалення пов'язаних записів". Тип зв'язку «Один до багатьох» буде вибрано автоматично.

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

V. Постановка домашнього завдання

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

§ 33 підручника, вміти відповідати на запитання після §

VI. Підбиття підсумків уроку

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

1. Системний аналіз.
2. Інфологічна модель.
3. Зв'язки між об'єктами («один до одного», «один до багатьох», «багато до багатьох»)
4. Команди для зв'язування таблиць (Сервіс Схема даних  Додавання таблиці)
5. Три нормальні форми
6. Первинний ключ - види (лічильник, простий, складовий)
7. Навіщо використовується первинний ключ (для зв'язування однієї таблиці з іншого).

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

Урок №4. Створення БД «Розклад уроків».

Цілі уроку: заповнити даними багатотабличну БД

Тип уроку : Урок закріплення матеріалу, що вивчається.

Вигляд уроку: комбінований.

Форми роботи:

1. Перевірка д/з та виставлення оцінок
2. Опитування із закріплення нового матеріалу – фронтальна робота
3. Практична робота – індивідуальна робота.

Устаткування : Програмне забезпечення: СУБД Microsoft Access.

ХІД УРОКУ

I. Організаційний момент:Привітання учнів.

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

ІІ. Фронтальне опитування:

Що таке поле? (Стовпець таблиці БД)

Основні характеристики поля(Поля унікальні, мають тип, розмір, формат)

Що таке записування?(Рядок таблиці БД)

Що впливає формування структури БД?(її призначення)

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

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

Які команди потрібно виконати для зв'язування таблиць(Сервіс  Схема даних  Додавання таблиці)

ІІІ. Практична робота №4.

Таблиці даних:

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

V. Постановка домашнього завдання

Будинки учням необхідно заповнити таблиці в індивідуальній БД.

VI. Підбиття підсумків уроку

Повторимо поняття, вивчені на минулих уроках:

1. Системний аналіз.
2. Інфологічна модель.
3. Зв'язки між об'єктами («один до одного», «один до багатьох», «багато до багатьох»)
4. Три нормальні форми

Елементи змісту: Запити програми ІС, засоби формування запитів, структура запиту на вибірку: список полів, умова вибору записів, ключі та порядок сортування.

Мета уроку: створити запити у багатотабличній БД

Тип уроку: Урок вивчення нового матеріалу

Вигляд уроку: комбінований.

Форми роботи:

1. Перевірка д/з та виставлення оцінок
2. Вступна лекція з демонстрацією на мультимедіа-проекторі
3. Практична робота – індивідуальна робота.

Обладнання: Програмне забезпечення: СУБД Microsoft Access, мультимедіа-проектор, картки із завданнями для виконання запитів (за кількістю учнів).

ХІД УРОКУ

1. Організаційний момент:Привітання учнів.
2. Теоретична частина.

Якщо потрібно здійснити пошук у одній таблиці БД, то використовують пункт меню – “Пошук”, якщо потрібно шукати у кількох таблицях, використовують Запит.

Запит – це бланк для пошуку інформації у багатотабличній БД.

Для створення запиту необхідно відкрити основне вікно бази даних та вибрати пункт "Запити" - Створити запит у режимі конструктора. З'явиться вікно діалогу “Додавання таблиці”, в якому необхідно вибрати таблиці, які будуть використовуватись для запиту (у нашому випадку – таблиці Тиждень, Розклад, Класи, Уроки, Кабінети). Меню – Вид – Об'єкти БД.

Відкривається вікно “Запит1: запит на вибірку”, де у верхній частині представлені таблиці, які використовуються запиту (ключові поля виділені жирним шрифтом), а нижньої – конструктор запиту.

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

Перегляд таблиці: Меню – Запит – Запуск.

Зміни у запиті: (наприклад, якщо потрібно створити запит із умовою)

Меню – Вид – Режим конструктора.

Конструктор запитів дозволяє також:

А) сортувати вибрані дані у запиті за певним полем;
Б) створювати запит із умовами.

1. Практична робота №5.

Виконати завдання, отримані на картці:

1. Показати всі уроки інформатики за тиждень
2. Скільки уроків інформатики за кожен день тижня

Прості та складні логічні вирази в умовах вибірки:

1. Чи є за розкладом урок інформатики у вівторок після 3-го уроку у 101 кабінеті?

2. Показати всі уроки інформатики за тиждень:

3. Скільки уроків інформатики за кожен із днів тижня:

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

V. Постановка домашнього завдання

Придумати та виконати запити (не менше 2-х) в індивідуальній БД.

§ 34 підручника, вміти відповідати на запитання після §

Приклади запитів у індивідуальних завданнях.

1 . БД із 2-х таблиць:

1) Книга (Автор, назва, короткий опис (казка, роман, публіцистика, детектив ...), Тираж).
2) Склад (назва книги, кількість, ціна).

2 . БД із 2-х таблиць:

1) Одяг (Назва моделі одягу, назва тканини для її пошиття, розмір).
2) Склад (Назва одягу, кількість примірників, ціна).

Знайти:

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

3 . БД із 2-х таблиць:

1) Товар (Найменування, ціни, продана кількість).
2) Склад (Найменування, залишок на складі, чи потрібно ще замовити (так/ні)).

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

4. БД із 2-х таблиць:

1) Країна (Назва, столиця, назва материка, на якому розташована країна).
2) Відомості (Назва, кількості населення, держ. лад, основна спеціалізація).

Знайти:

Усі країни, розташовані в Африці з населенням понад 100 тис.,
- країну з монархією

VI. Підбиття підсумків уроку.

Виставлення оцінок.

Урок №6. Технологія формування форм, звітів у СУБД.

Мета уроку: створити форми та звіти у багатотабличній БД

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

Вигляд уроку: комбінований.

Форми роботи:

1. Перевірка д/з та виставлення оцінок
2. Вступні визначення
3. Практична робота – індивідуальна робота.

Обладнання: Програмне забезпечення: СУБД Microsoft Access.

ХІД УРОКУ

I. Організаційний момент.

ІІ. Теоретична частина.

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

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

ІІІ. Практична робота №6.

Минулого уроку ми створювали запити. А сьогодні займемося формами та звітами.

Підготуйте звіт «Уроки інформатики» для друку.

Порядок роботи:

1. Відкрийте закладку Звіти, якщо ви перебуваєте в іншому вікні.
2. Натисніть кнопку Створити за допомогою майстра
3. За допомогою серії діалогових панелей задайте параметри зовнішнього вигляду звіту, клацнувши на кнопці Далі
4. Збережіть звіт під назвою «Уроки інформатики». Закрийте звіт
5. У вікні БД натисніть кнопку Перегляд (або відкрийте звіт). З'явиться документ у тому вигляді, в якому він може бути надрукований.

Самостійно створіть форму для запиту Розклад за пн, вт, ср для 11 класу.

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

V. Постановка домашнього завдання

Придумати та виконати звіти та форми (не менше 2-х) в індивідуальній БД.

§ 35 підручника, вміти відповідати на запитання після §

VI. Підбиття підсумків уроку. Виставлення оцінок.

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

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

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

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

Чернігівський державний технологічний університет

Кафедра інформаційних та комп'ютерних систем

Програмна система "Футбольний чемпіонат"

Курсова робота з дисципліни "Організація баз даних"

Виконали

студенти гр. КІ-104А.Г. Войцехівський

А.Г. Райська

Керівник

Помічник М.В. Харченко

Чернігів 2013

Реферат

Курсова робота, 86 с., рис.21, 9 джерел, 2 додатки.

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

Основним методом проектування модулів програми – використання UML – діаграм. Таким чином, за наявності ліцензійного програмного забезпечення можна експортувати розроблені класи в середу Eclipse EE.

У процесі написання програми було розроблено та створено дві фабрики DAOTourFirma та ServiceTourFirma для роботи з сутностями. За допомогою ServiceTourFirma було додатково реалізовано бізнес-логіку.

Також була використана технологія Servlet- та JSP-контейнера. Так як сервлети та jsp-сторінки викликаються через HTTP-протокол, то Servlet-контейнер і JSP-контейнер часто супроводжує ще один компонент - web-сервер, який також може бути написаний на Java.

Як сервер був використаний сервер Tomcat 6.0. Програма була розроблена з використанням комплекту JDK версії 1.7.

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

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

Для своєї роботи корпоративний додаток вимагає мінімально: 1024 Мб оперативної пам'яті, процесор не нижче за Atom 1100 МГц і будь-який браузер. Вимоги до операційної системи – Windows, Unix.

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

Реферат

Курсова робота, 86 с., 21 рис., 9 джерел, 2 додатки.

Об'єктом розробки є корпоративна програма, яка дозволяє працювати з БД як за допомогою тонкого клієнта, так і за допомогою веб сервісів.

Основним методом проектування модулів програми – використання UML – діаграм. Таким чином, за наявності ліцензійного програмного забезпечення можна було експортувати розлоблені класи в Eclipse EE.

У процесі написання програми були розроблені та створені дві фабрики DAOTourFirma та ServiceTourFirma для роботи із сутностями. За допомогою ServiceTourFirma було додатково реалізовано бізнес-логіку.

Також була використана технологія Servlet- та JSP-контейнера. Так як сервлеті та jsp-сторінки викликаються через HTTP-протокол, то Servlet-контейнер та JSP-контейнер часто супроводжує ще один компонент - web-сервер, який також може бути написаний на Java.

Як сервер був використаний сервер Tomcat 6.0. Програма була розроблена за допомогою комплекту JDK версії 1.7.

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

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

Для своєї роботи корпоративна програма вимагає мінімально: 1024 Мб оперативної пам'яті, процесор не нижче за Atom 1100 МГц і будь-який браузер. Вимоги до операційної системи – Windows, Unix.

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

Java, C#, ORM, JSP, JPA, SQL, Servlet, HTML, TAG, JS

The Abstract

Course project, 86 p., Pic.21, 9 sources, 2 of the annex.

Об'єкт є розробкою application, що задовольняє вас для роботи з 데이터베이스, як через thin client або через application desktop.

Основний метод designing application modules - use UML - diagrams. Тому, якщо програма може бути розроблена для експорту екземплярів в екологічному середовищі EE.

Під час написання applications мав бути розроблений і налаштований на дві factories DAOTourFirma and ServiceTourFirma для роботи з ними. З ServiceTourFirma буде been further implemented business logic.

У тренажерному залі курсу роботи для операційної системи з використанням DBMS PostgerSQL 9.0. На базі даних, які складаються з 9 таблиць. У кожному table unique primary key is external. Це є опційним сервісним полем, підключеним до всіх існуючих повідомлень повідомлень tables, тільки purpose of which - to serve as primary key. Значення цієї сфери не формуються на основі будь-якого іншого data від database, і створені матеріалом. Головним розв'язанням зовнішньої кнопки є те, що вона не змінює, тому що вона є інформаційним table field.

Also, технологія буде been used, і Servlet-JSP-container. Тому що servlets і jsp-pages invoked via HTTP-protocol, Servlet-JSP-container і container є доступним до іншого компонента - веб-сервер, який може бути написаний в Java.

Під час розвитку applications enterprise have been received Football championat brought to the level of beta. Результат результату розвитку форми проектного проекту, розташований в annexe до курсу роботи.

Для її корпоративного застосування потребує мінімум: 1024 Мб RAM, CPU не є атомом нижче 1100 МГц і браузер. Вимоги до операційної системи - Windows, Unix.

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

Java, C#, ORM, JSP, JPA, SQL, Servlet, HTML, TAG, JS

Вступ

1. Аналіз розв'язуваної задачі

1.1 Аналіз предметної галузі

1.2 Цілі та завдання системи

1.3 Призначення системи

1.4 Вимоги до системи

2. Проектування

2.1 Вибір інструментальних засобів розробки системи

2.1.1 Сервер бази даних

2.1.2 Технології реалізації системи

2.2 Проектування архітектури системи

2.2.1 Проектування шару бізнес логіки та бізнес правил

2.2.2 Проектування шару доступу до даних

2.2.3 Проектування шару відображення

3. Розробка

3.1 Розробка бази даних системи

3.1.1 Розробка схеми бази даних

3.1.2 Забезпечення цілісності даних

3.1.3 Розробка базових запитів

3.1.4 Створення ролей, вибір індексів та уявлень

3.1.5 Розробка збережених процедур та тригерів

3.1.6 Організація захисту даних

3.1.7 Об'єктно-реляційне відображення

3.2 Розробка модулів системи

3.2.1 Розробка модулів шару бізнес-логіки та бізнес-правил

3.2.2 Розробка модулів шару доступу до даних

3.2.3 Розробка модулів шару сервісу

3.2.4 Розробка модулів шару відображення

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

Вступ

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

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

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

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

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

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

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

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

1. Аналіз розв'язуваної задачі

1.1 Аналіз предметної галузі

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

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

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

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

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

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

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

1.2 Цілі та завдання системи

Метою системи "Футбольний чемпіонат" є автоматизація процесу проведення чемпіонатів. Даний додаток несе інформативний характер: дозволяє автоматизувати підрахунок кількості виграшів, програшів та нічиєї, а також нарахування очок командам відповідно до результатів проведення матчу (3 очки – виграш, 2 – нічия, 1 – програш). Додаток дозволяє за допомогою форм введення-виводу додавати нові, видаляти та змінювати дані турнірної таблиці. Є можливість перегляду даних про працівників та про команди, а також перегляд 10 найкращих команд та результати матчем, які були проведені у поточний день.

1.3 Призначення системи

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

На малюнку 1.1 представлена ​​діаграма варіантів використання ролі Президент чемпіонату

Малюнок 1.1 – Діаграма варіантів використання для ролі Президент чемпіонату

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

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

На малюнку 1.2 представлена ​​діаграма варіантів використання ролі Адміністратор

Малюнок 1.2 - Діаграма варіантів використання ролі Адміністратор

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

Варіант використання «Керувати обліковими записами» має наступний сценарій: Якщо це додавання нового користувача, заповнити відповідну формулу і зберегти зміни; якщо це зміна або видалення користувача, то потрібно його спочатку знайти в базі, при видаленні – знищити дані про користувача, при зміні – скоригувати їх та зберегти.

На малюнку 1.3 представлена ​​діаграма варіантів використання ролі Менеджер.

Рисунок 1.3 - Діаграма варіантів використання ролі Менеджер

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

На малюнку 1.4 представлена ​​діаграма варіантів використання ролі Гость.

Рисунок 1.4 - Діаграма варіантів використання ролі Гість

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

1.4 Вимоги до системи

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

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

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

2. Проектування

2.1 Вибір інструментальних засобів розробки системи

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

2.1.1 Сервер бази даних

На даний момент існує безліч серверів баз даних таких як: MySQL, PostgreSQL, Microsoft Access та інші.

PostgreSQL – це об'єктно-реляційна система управління базами даних, що працює як клієнт-серверна система. Грунтуючись на базових поняттях реляційних БД, PostgreSQL підтримує і ряд "об'єктних" операцій, наприклад, успадкування. PostgreSQL відповідає базовій специфікації SQL99 та підтримує велику кількість можливостей, описаних стандартом SQL92.

Oracle дещо перевершує PostgreSQL у таких питаннях як використання індексів, реплікація та відновлення даних, та й взагалі інструменти адміністрування. Oracle більш розвинені (але водночас і складніші). З іншого боку, PostgreSQL надає можливість використовувати як процедурну мову крім PL/pgSQL (дуже схожого з PL/SQL, що використовується в Oralce), а також PL/Perl, PL/Python, PL/Tcl, що дозволяє розробнику вибрати більш звичний інструмент.

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

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

Apache Derby - це реляційна СУБД, написана на Java, призначена для вбудовування в Java-додатки або обробки транзакцій у реальному часі. Займає 2 Мб на диску. Apache Derby розробляється як open source та поширюється на умовах ліцензії Apache 2.0. Дербі був раніше відомий як IBM Cloudscape. Sun поширює самі бінарні файли під ім'ям Java DB.

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

2.1.2 Технології реалізації системи

JSP (JavaServer Pages) – технологія, що дозволяє веб-розробникам легко створювати вміст, який має як статичні, так і динамічні компоненти. По суті, сторінка JSP є текстовим документом, який містить текст двох типів: статичні вихідні дані, які можуть бути оформлені в одному з текстових форматів HTML, SVG, WML або XML, та JSP елементи, які конструюють динамічний вміст. Крім цього, можуть використовуватися бібліотеки JSP тегів, а також EL (Expression Language), для впровадження Java-коду в статичний вміст JSP-сторінок.

JSP - одна з високопродуктивних технологій, тому що весь код сторінки транслюється в java-код сервлета за допомогою компілятора JSP сторінок Jasper, а потім компілюється в байт-код віртуальної машини java (JVM). Контейнери сервлетів, здатні виконувати JSP сторінки, написані мовою Java, яка може працювати різних платформах. JSP сторінки завантажуються на сервері і управляються зі структури спеціального Java server packet, який називається Java EE Web Application, здебільшого упаковані у файлові архіви.war і.ear.

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

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

- Expression Language (EL) - мова виразів, що дозволяє серед іншого створювати розробникам шаблони в стилі Velocity;

- Простіший і швидший спосіб створювати нові теги за допомогою файлів.tag, тепер для створення нових тегів не обов'язково знати Java;

- Зручний спосіб управління вкладеними бінами (JavaBeans);

– більш швидкий та легкий спосіб відображення параметрів змінних.

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

Хоча сервлети можуть обслуговувати будь-які запити, вони зазвичай використовуються для розширення веб-серверів. Для таких програм технологія Java Servlet визначає HTTP-специфічні сервлет класи.

JSTL (JavaServer Pages Standard Tag Library) - у перекладі з англійської "стандартна бібліотека тегів JSP". Вона розширює специфікацію JSP, додаючи бібліотеку JSP тегів для спільних потреб, таких як аналіз XML даних, умовна обробка, створення циклів і підтримка інтернаціоналізації. JSTL - кінцевий результат JSR 52, розробленого в рамках JCP (процесу Java спільноти).

JSTL є альтернативою такому виду вбудованої в JSP логіки, як скриплети, тобто прямі вставки Java коду. Використання стандартизованого безлічі тегів краще, оскільки отримуваний код легше підтримувати і простіше відокремлювати бізнес-логіку від логіки відображення.

Java Persistence API (JPA) - API, що входить з версії Java 5 до складу платформ Java SE і Java EE, надає можливість зберігати у зручному вигляді Java-об'єкти в базі даних.

Існує кілька реалізацій цього інтерфейсу, одна з найпопулярніших використовує Hibernate.

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

– безпосередньо API, заданий у пакеті javax.persistence;

– платформо-незалежна об'єктно-орієнтована мова запитів Java Persistence Query Language;

- Метаінформація, що описує зв'язки між об'єктами;

генерація DDL для сутностей.

2.2 Проектування архітектури системи

шар база даних модуль servlet

Архітектура системи буде такою, яка наведена в аналізі (рисунок 1.1) та методах розв'язання задачі.

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

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

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

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

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

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

Об'єктно-реляційне відображення (JPA). JPA не є новою технологією, а, швидше, це зібрання ідей найкращих з наявних технологій, таких як Hibernate, TopLink та JDO. Як результат JPA є стандартизованою специфікацією, що входить до J2EE5, що дозволяє будувати шар збереження даних незалежно від будь-яких конкретних провайдерів. Тобто. реалізацій специфікації JPA може бути багато, однією з таких, наприклад, є фреймворк OpenJPA або той же Hibernate.

Об'єктні бази даних. Об'єктні бази даних спеціально розроблені для зберігання об'єктів і повністю вписуються в концепцію об'єктно-орієнтованого програмування. Object Database Management Group (ODMG) була створена для створення єдиного API для роботи з такими базами. Однак, багато постачальників баз даних все ще не наважуються перейти з реляційної системи, що добре себе зарекомендувала, на об'єктно - орієнтовану. Так само менша кількість засобів аналізу даних доступна для об'єктних баз і дуже багато даних вже збережено в реляційних базах. З цих причин, а так само з багатьох інших, об'єктні бази даних не знайшли такого широкого застосування, на яке сподівалися їх творці;

Enterprise Java Beans (EJBs). EJB є компонентами, які зберігають свій стан в реляційній базі даних і забезпечують об'єктно-орієнтоване відображення постійних даних. На відміну від продуктів об'єктно-реляційного відображення, EJB мають жорстку специфікацію, що уможливлює використання продуктів від різних постачальників. На жаль, стандарт EJB обмежений в об'єктно-орієнтованому відношенні. Вони не підтримують успадкування, поліморфізм тощо. Також EJB компоненти вимагають великих витрат для їх написання і часто спеціального програмного забезпечення для їх роботи.

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

Hibernate, iBATIS, Java Data Objects (JDO), JPOX, Cayenne, TopLink, JPA.

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

2.2.1 Проектування шару бізнес логіки та бізнес правил

Принцип роботи цієї системи:

Адміністратор заносить дані про працівників, чемпіонатів, команди;

Користувачі переглядають турнірну таблицю та інформацію про чемпіонати;

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

Була створена додаткова таблиця для реалізації зв'язку багатьом. zakaz_dop_uslugi (пов'язує замовлення із додатковими послугами).

Отже, можна спроектувати такі класи домену (рис. 2.4).

Малюнок 2.4 - Класи домену

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

2.2.2 Проектування шару доступу до даних

Для доступу до даних, що зберігаються у зовнішньому сховищі, найзручніше визначити окремі інтерфейси з методами для маніпуляції даними. Реалізація цих інтерфейсів може бути будь-яка, наприклад, що використовує JDBC або JPA, JAXB або навіть прості колекції Java. Як спрощення даного курсового проекту було обрано JPA. Для того, щоб можна було використовувати різні реалізації інтерфейсів доступу до даних, зручно застосувати шаблон проектування "Абстрактна фабрика" або "Фабричний метод". У цьому випадку такою фабрикою виступає абстрактний клас DAOFactory, який містить визначення абстрактних методів, що повертають реалізації інтерфейсів (рисунок 2.4).

Серед усіх операцій доступу до даних можна чітко виділити базові CRUD (create, read, update, delete) опреації - створення об'єкта, видалення об'єкта, оновлення об'єкта, отримання об'єкта за ідентифікатором та отримання всіх об'єктів. Винесення таких операцій в окремий супер клас дозволить уникнути дублювання коду. Такі базові операції також були винесені в окремий базовий інтерфейс IGenericDao , який використовує Java Generics, дозволяє вказати клас об'єктів, з якими проходитиме робота.

Малюнок 2.4 – Діаграма класів DAO

2.2.3 Проектування шару відображення

Цей шар є тонким клієнтом.

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

3. Розробка

3.1 Розробка бази даних системи

3.1.1 Розробка схеми бази даних

Виходячи з аналізу, проектування шару бізнес-логіки та правил, структуру БД можна зробити наступною (рисунок 3.1)

Рисунок 3.1 – Логічна схема БД

Фізична схема БД показана малюнку 3.2

Малюнок 3.2 – Фізична схема БД

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

Турнірна таблиця;

Команди;

Користувач;

Працівник;

Зарплата;

Чемпіонат Світу

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

3.1.2 Забезпечення цілісності даних

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

Таблиця 3.1 - Опис таблиць БД

Назва таблиці		Опис	Тип даних	Обмеження
		ідентифікаційний код працівника		Первинний ключ
		Адреса працівника	рядок, 20 символів	обов'язкове для введення
		дата народження	рядок, 20 символів	обов'язкове для введення
		Прізвище ім'я. По батькові працівника	рядок, 60 символів	обов'язкове для введення;
		Телефонний номер працівника	Рядок 20 символів	обов'язкове для введення
		Зовнішній ключ користувача	ціле число
		Зовнішній ключ чемпіонату	ціле число	для введення; унікальних значень
		ідентифікаційний код матчу		Первинний ключ
		Дата проведення матчу	рядок, 20 символів	обов'язкове для введення
		Команда, що грає в гостях	рядок, 20 символів	обов'язкове для введення
		Команда, що приймає	рядок, 20 символів	обов'язкове для введення
		Рахунок гри	рядок, 20 символів
		Номер туру	ціле число	обов'язкове для введення
		Зовнішній ключ команди	ціле число	для введення; унікальних значень
		ідентифікаційний код користувача		Первинний ключ
		Логін для входу на сай	рядок, 20 символів	обов'язкове для введення
		Пароль для входу на сай	рядок, 20 символів	обов'язкове для введення
		Зовнішній ключ ролі	ціле число	для введення; унікальних значень
		ідентифікаційний код таблиці		Первинний ключ
		Кількість матчів, зіграних у нічию	ціле число	обов'язкове для введення
		Кількість очок за матч	ціле число	обов'язкове для введення
		Кількість програних матчів	ціле число	обов'язкове для введення
		Кількість виграних матчів	ціле число	обов'язкове для введення
		ідентифікаційний код зарплати		Первинний ключ
		Кількість вироблених годинників	ціле число	обов'язкове для введення
		Розмір премії	Речовий тип даних
		Розмір штрафу	Речовий тип даних
		Зовнішній ключ працівника	ціле число	для введення; унікальних значень
		ідентифікаційний код права		Первинний ключ
		Зовнішній ключ ролі	ціле число	для введення; унікальних значень
		Дія, яка може виконувати вказану роль	рядок, 30 символів	для введення; унікальних значень
		ідентифікаційний код ролі		Первинний ключ
			рядок, 30 символів	обов'язкове для введення
		ідентифікаційний код команди		Первинний ключ
		Назва міста	рядок, 20 символів	обов'язкове для введення
		Назва команди	рядок, 20 символів	обов'язкове для введення
		ПІБ тренера	рядок, 60 символів	обов'язкове для введення
		Зовнішній ключ таблиці	ціле число	обов'язкове для введення
		ідентифікаційний код чемпіонату		Первинний ключ
		Дата проведення чемпіонату		обов'язкове для введення
		Назва країни	рядок, 40 символів	обов'язкове для введення
		Зовнішній ключ таблиці	ціле число	обов'язкове для введення

3.1.3 Розробка базових запитів

При розробці базових запитів JPQL був обраний мовою розробки.

Нижче наведено опис основних запитів, їх реалізація наведена у додатку А.

getKomandasByTablicaId – запит на вибірку значень з таблиці «Команда», де id таблиці – параметр для отримання команди.

findKomandaByName- запит на вибірку команди, де name таблиці - параметр для отримання команди.

getTablicaByChempionatId – запит на вибірку значень з таблиці «Таблиця», де id чемпіонату – параметр для отримання таблиці.

getKomandasByTablicaId – запит на вибірку значень з таблиці «Команда», де id таблиці – параметр для отримання таблиці.

findUserByNameAndPassword- запит на вибірку значень з таблиці «Користувач», де login користувача дорівнює першому параметру, а password другому.

getWorkerByChempionatId- запит на вибірку значень з таблиці «Робітник», де id чемпіонату – параметр для отримання працівника.

getZarplatasByWorkerId – запит на вибірку значень із таблиці «Зарплата», де id працівника – параметр для отримання зарплати.

3.1.4 Створення ролей, вибір індексів та уявлень

Ролі:

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

Create role "admin" LOGIN UNENCRYPTED PASSWORD "qwerty"

Create role "manager" LOGIN UNENCRYPTED PASSWORD "qwerty1"

Create role "director" LOGIN UNENCRYPTED PASSWORD "qwerty2"

Права доступу до відносин chempionat, komanda, matchi, prava, "role", tablica, users, worker, zarplata можуть бути описані наступним чином:

grant select, delete, insert, update on chempionat, komanda, matchi, prava, "role", tablica, users, worker, zarplata to admin

grant select, delete, insert, update on tablica, matchi, komanda to manager

Індекси:

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

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

create index i_worker on worker(id);

create index i_komanda на komanda(id);

create index i_matchi on matchi(id);

create index i_zarplata on zarplata(id)

Уявлення:

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

create view w_guest (kolnichiyih,kolocheck,kolproigrashey,kolviigrashey,idchampionata) as

select kolnichiyih, kolocheck, kolproigrashey, kolviigrashey, idchampionata від tablica;

create role guest LOGIN UNENCRYPTED PASSWORD "qwerty3"

grant select on w_guest to guest

3.1.5 Розробка збережених процедур та тригерів

Тригери:

1) Тригер, який вносить значення в полі premiya при додаванні запису до таблиці Zarplata. Якщо значення поля колЧасов перевищує певне значення.

CREATE OR REPLACE FUNCTION ins()

RETURNS trigger AS

UPDATE "zarplata"

SET "premiya" =("kolchasov" - 176) * 100

Від "zarplata", "worker"

where ("kolchasov"> 8);

LANGUAGE "plpgsql";

CREATE TRIGGER trig_11 AFTER INSERT ON "Zarplata"

FOR EACH ROW EXECUTE PROCEDURE ins();

2) Тригер, який додає запис у полі сума таблиці зарплата, при додаванні чи оновленні запису у таблиці. Значення цього поля визначається значенням полів ставка, штраф та премія.

create or replace function addSumInZarplata()returns trigger as

declare shtr float:=(select shtraf from zarplata where id=new.id);

declare prem float:=(select premiya from zarplata where id=new.id);

declare s float:= (select summa from zarplata where id=new.id);

update zarplata set

summa = s+prem-shtr where id=new.id;

language plpgsql;

create trigger trigAddSumZarplat

on zarplata for each row

execute procedure addSumInZarplata();

Збереженіпроцедури:

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

CREATE OR REPLACE FUNCTION func_1()

RETURNS TABLE(id integer, gost character varying(30), hozain character varying(30),

schet character varying(10), tur integer, idkomandy integer, data date) AS $$

SELECT * FROM "matchi" WHERE "data" = timenow()::date; $$

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

CREATE OR REPLACE FUNCTION func_2(strana character varying(40))

SELECT "name" FROM "komanda", "tablica", "chempionat" WHERE "komanda". "idtablici" = "tablica". AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE "strana" = $1); $$

3) Розробити збережену процедуру, яка повертатиме top-10 команд турнірної таблиці. Вхідні параметри – назва країни. Вихідним параметром буде таблиця, що складається з назв 10 кращих команд та їх кількості очок.

CREATE OR REPLACE FUNCTION func_3(strana character varying(40))

RETURNS TABLE(_name character varying(20), kolocheck integer) AS $$

WITH subquery AS (SELECT "name", "kolocheck" FROM "komanda", "tablica", "chempionat" WHERE "komanda"."idtablici" = "tablica"."id" AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE "strana" = $1) GROUP BY 1, 2 ORDER BY "kolocheck" DESC)

SELECT * FROM "subquery" GROUP BY 1, 2 HAVING COUNT("name")<= 10; $$

4) Розробити процедуру, що зберігається, яка повертатиме назву команди лідера турнірної таблиці певного чемпіонату. Вхідні параметри – назва країни. Вихідним параметром буде назва лідера.

CREATE OR REPLACE FUNCTION func_5(strana character varying(40))

RETURNS character varying(20) AS $$

SELECT "name" FROM "komanda", "tablica", "chempionat"

WHERE "komanda"."idtablici" = "tablica"."id" AND "kolocheck" IN (SELECT MAX("kolocheck") FROM "tablica") AND "idchampionata" IN (SELECT "id" FROM "chempionat" WHERE " сторiнка" = $1); $$

3.1.6 Організація захисту даних

У розробленій системі є кілька ролей і для кожної з них у програмній системі «Футбольний чемпіонат» різний функціонал. Можливості кожного з видів користувачів у цій програмній системі наведені у таблиці 3.2

Таблиця 3.2 Захист даних

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

3.1.7 Об'єктно-реляційне відображення

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

Об'єктно-реляційне відображення (ORM) – це техніка програмування, яка пов'язує реляційну базу даних з концепціями об'єктно-орієнтованого програмування та створює «віртуальну базу даних об'єктів».

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

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

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

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

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

Для її вирішення було обрано JPA (Java Persistence API).

На наведеній нижче діаграмі показано взаємозв'язок між основними компонентами JPA архітектури.

Малюнок 3.3 - Архітектура JPA

Persistence - клас містить допоміжні статичні методи отримання EntityManagerFactory незалежним від постачальника способом.

EntityManagerFactory – інтерфейс, реалізація якого є фабрикою для створення об'єктів EntityManager.

EntityManager - є основним JPA інтерфейсом, що використовується в додатках. Кожен EntityManager керує набором об'єктів, що зберігаються, і містить API для вставки нових об'єктів і видалення існуючих. З кожним EntityManager пов'язаний свій EntityTransaction і, також, EntityManager виступає фабрикою для об'єктів Query.

Entity - сутність, що є об'єктом, що зберігається.

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

Query - інтерфейс для виконання запитів щодо знаходження об'єктів, що зберігаються, які задовольняють заданим критеріям. JPA підтримує запити об'єктною мовою Java Persistence Query Language (JPQL) та стандартною структурованою мовою Structured Query Language (SQL). Отримати екземпляри Query можна з об'єкта EntityManager.

3.2 Розробка модулів системи

3.2.1 Розробка модулів шару бізнес-логіки та бізнес-правил

Даний модуль є описом всіх сутностей нашої БД. Він включає одинадцять класів, а саме:

Matchi.java – клас, який описує матчі. Містить таку інформацію: дата проведення матчу, гість, господар, рахунок матчу, номер туру. Він містить методи отримання та запису полів.

Komanda.java – клас, який описує команди. Містить таку інформацію: назва команди, ПІБ тренера, місто команди. Він містить методи отримання та запису полів.

Tablica.java – клас, який описує турнірну таблицю. У ньому містяться поля: кількість очок команди, кількість програшів, виграшів та нічиїх. Він містить методи отримання та запису полів.

Chempionat.java – клас, який описує чемпіонат. Він містить таку інформацію: дата початку дата закінчення мемпіонату, назва країни, в якій він проводиться. Він містить методи отримання та запису полів.

Worker.java – клас, який описує працівника. У ньому містяться така інформація: ПІБ працівника, дата народження, телефон, адреса. Він містить методи отримання та запису полів.

User.java – клас, який описує користувача. Він містить таку інформацію: логін і пароль для входу в систему. Він містить методи отримання та запису полів.

Role.java – клас, який описує роль користувача. Він містить таку інформацію: ім'я користувача. Він містить методи отримання та запису полів.

Prava.java – клас, який описує права користувача. У ньому містяться така інформація: права, під якими він входить у систему

3.2.2 Розробка модулів шару доступу до даних

Доступ до даних здійснюється за допомогою DAO. Цей модуль представлений двома пакетами з інтерфейсами та їх реалізаціями. У ньому містяться такі інтерфейси:

– ITablicaDao.java - інтерфейс, який містить опис методів, для роботи з таблицею. У ньому описано наступні методи:

public Collection getTablicasByChempionatId(Integer chId) throws PersistenceException метод отримання всіх таблиць для заданого чемпіонату.

Реалізація методів знаходиться у класі TablicaDaoJpa.

- IKomandaDao.java - інтерфейс, який містить опис методів, для роботи зі списком команд. У ньому описані такі методи:

a)public Collection getKomandasByTablicaId(Integer chId) throws PersistenceException метод отримання всіх команд певної турнірної таблиці;

b)public Komanda findKomandaByName(String name) throws PersistenceException метод для отримання команди на ім'я.

c) getTheWorstKomandaByChampId(String name) throws PersistenceException метод для отримання найгіршої команди в чемпіонаті;

d)public String getTheBestKomandaByChampId(String name) throws PersistenceException метод для отримання найкращої команди в чемпіонаті;

e)public Collection getTopTenKomandasByChampId(String name) throws PersistenceException метод для отримання 10 найкращих команд у чемпіонаті;

...

Подібні документи

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

курсова робота , доданий 03.11.2012


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

курсова робота , доданий 29.11.2015


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

дипломна робота , доданий 10.07.2017


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

курсова робота , доданий 17.06.2014


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

курсова робота , доданий 22.02.2011


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

дипломна робота , доданий 03.07.2011


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

курсова робота , доданий 20.02.2015


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

лабораторна робота , доданий 13.02.2013


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

курсова робота , доданий 21.05.2013


Концепція бази даних. Розробка таблиць, форм введення та виведення інформації, основних запитів, процедур, що зберігаються, і тригерів бази "Дошка оголошень". Підготовка для виведення на друк. Аналіз потреби адміністрування, засобів захисту інформації.

Федеральне Агентство Залізничного Транспорту

Кафедра «Зв'язок»

Курсова робота.

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

Роботу виконав:

студент гр. ІТ-314

Медведєв Н.В.

Роботу перевірив:

викладач

Пащенко М.О.

Єкатеринбург,

Вступ 3

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

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

1.2. Опис інформаційних потреб користувачів 5

1.3. Побудова інфологічної моделі 6

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

2.1. Вибір та характеристика СУБД 7

2.2. Побудова даталогічної моделі 9

2.3. Створення бази даних 11

2.4. Заповнення БД 12

Висновок 17

Список використаної литературы 18

Вступ.

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

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

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

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

· Яким чином відобразити об'єкти предметної області в абстрактні об'єкти моделі даних, щоб це відображення не суперечило семантиці предметної області, і було якомога кращим (ефективним, зручним і т.д.)? Часто цю проблему називають проблемою логічного проектування бази даних.

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

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

Рис.1 Етапи проектування БД

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

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

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

Властивість

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

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

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

1.2. Опис інформаційних потреб користувачів

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

Основними поняттями ER-моделі є сутність, зв'язок та атрибут:

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

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

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

Зв'язок представляється як лінії. При цьому над місцем "стикування" зв'язку з сутністю ставиться знак «∞» або літера «M», якщо для цієї сутності у зв'язку можуть використовуватися багато примірників сутності, і цифра «1», якщо у зв'язку може брати участь тільки один примірник сутності.

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

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

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

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

Побудова інфологічної моделі

Інфологічна модель для бази даних «Результати ігор футбольної команди» проектувалась як модель «Сутність-зв'язок».

Сутність – це клас однотипних об'єктів. Процес діяльності фірми ідентифікує такі сутності : Команда, Тренер, Члени команди, Матчі, Чемпіонат.

Кожна із сутностей має свій набір атрибутів.

Малюнок 1. Діаграма ER – типів.

Опис сутностей:

Команда, Тренер, Члени команди, Матчі, Чемпіонат.

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

2.1. Вибір та характеристика СУБД

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

До основних функцій СУБД прийнято відносити такі:

1. Безпосереднє керування даними у зовнішній пам'яті.

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

2. Управління буферами оперативної пам'яті.

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

3. Управління транзакціями.

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

4. Журналізація.

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

5. Підтримка мов БД.

p align="justify"> Для роботи з БД використовуються спеціальні мови баз даних. Найчастіше виділяються 2 мови – мова визначення даних (DDL) та мова маніпулювання даними (DML). DDL служить, головним чином, визначення логічної структури БД, а DML, містить набір операторів маніпулювання даними. Багато СУБД зазвичай підтримується єдиний інтегрований мову, що містить усі необхідні засоби для роботи з БД. Стандартною мовою реляційних СУБД є мова SQL. Мова SQL поєднує кошти DDL і DML, тобто. дозволяє визначати схему реляційної БД та маніпулювати даними.

У SQL використовуються такі основні типи даних, формати яких можуть дещо відрізнятися для різних СУБД:

INTEGER- ціле число (зазвичай до 10 значущих цифр та знак);

SMALLINT- "коротке ціле" (зазвичай до 5 значущих цифр та знак);

DECIMAL ( p , q ) - десяткове число, що має p цифр (0

FLOAT- дійсне число з 15 значущими цифрами та цілочисловим порядком, що визначається типом СУБД;

CHAR ( n ) - символьний рядок фіксованої довжини із n символів (0

VARCHAR ( n ) - символьний рядок змінної довжини, що не перевищує n символів (n>0 і різне в різних СУБД, але не менше 4096);

DATE- дата у форматі, що визначається спеціальною командою (за замовчуванням mm/dd/yy); поля дати можуть містити лише реальні дати, що починаються за кілька тисячоліть до н. та обмежені п'ятим-десятим тисячоліттям н.е.;

DOUBLE PRECISION– для наукових обчислень 15 цифр точності.

NUMERIC ( p . s ) - чисельні значення містять цифри від 0 до 9 та необов'язкові знак та десяткову точку.

Тому при проектуванні БД вибір зупинився на СУБД InterBase 6.0, як СУБД, що підтримує всі основні вище перелічені функції. Крім цього InterBase 6.0 має такі характеристики:

1. Підвищена продуктивність за рахунок розвиненої архітектури

Сервер InterBase реалізує архітектуру множинних поколінь записів ( MGA- Multi-Generational Architecture). MGAзабезпечує унікальні можливості використання версій, що веде до високого ступеня доступності даних як для користувачів, що працюють з транзакціями, так і для користувачів, які використовують програми підтримки прийняття рішень. Механізм MGA в InterBase добре працює при оперативній обробці коротких транзакцій ( OLTP- On-Line Transaction Processing) і є унікальним для великомасштабних реальних додатків, перевершуючи інші бази даних у галузі паралельного виконання тривалих транзакцій для підтримки прийняття рішень. Механізм версій усуває необхідність блокування записів, до яких здійснюється доступ до читання під час транзакції, роблячи їх вільними від конфліктів доступу – доступ до читання ніколи не блокує доступу до запису. На відміну від інших баз даних InterBase забезпечує своєчасні, стійко відтворювані результати для кожного запиту без спеціального програмування. В результаті досягається максимальна пропускна здатність для всіх транзакцій користувача.

2. Багатопотокова архітектура

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

3. Потужна підтримка різних типів даних

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

4. Сигналізатори подій

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

5. Ефективність використання ресурсів

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

6. Суворе дотримання індустріальних стандартів

InterBase дотримується суворої відповідності індустріальним стандартам для клієнт-серверних обчислювальних середовищ, таких як ANSI/SQL, Java, UNICODE та XDR (External Data Representation – зовнішнє представлення даних). Наша прихильність до критично важливих технологічних стандартів означає, що ви можете скоротити час, необхідний для розробки, впровадження та супроводу ваших додатків на безлічі платформ з гарантією негайного досягнення найвищої продуктивності.

2.2. Побудова даталогічної моделі

На цьому етапі необхідно встановити відповідність між сутностями та характеристиками предметної галузі та відносинами та атрибутами в InterBase 6.0. Для цього потрібно кожній сутності та характеристикам поставити у відповідність набір відносин (таблиць) та їх атрибутів (полів).

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

Таблиця відповідності назв сутностей.

Таблиця відповідності назв полів.

Атрибути	Відповідність
Прізвище	Famil
Ім'я	Imya
По-батькові	Отчество
Телефон	Tel
Команда 1	Команда_1
Команда 2	Команда_2
Окуляри 1	ochki_1
Окуляри 2	ochki_2
Час	Vremya
Вид чемпіонату	Vid_chemp
Рік основи	God_osn
Місто	Gorod
Країна	Strana
Тренерувальні бази	Basi
Адреса	Adres
Назва	Названня
дата початку	Data_nachala
Дата_кінця	Data_konza

Малюнок 2. Даталогічна модель.

2.3. Створення бази даних .

Створення таблиць:

Таблиця «Чемпіонат »:

CREATE TABLE "CHEMP" ("KOD_CHEMP" INTEGER NOT NULL, "VID_CHEMP" VARCHAR(20), "VREMYA" DATE, PRIMARY KEY ("KOD_CHEMP"));

Таблиця «Члени команди »:

CREATE TABLE "LUDI" ("KOD_CHEL" INTEGER NOT NULL, "FAMIL" VARCHAR(20), "IMYA" VARCHAR(20), "OTCHESTVO" VARCHAR(20), "TEL" VARCHAR(20), "KOD_KOMANDI" INTEGER NOT NULL, "NOMER" INTEGER NOT NULL);

ALTER TABLE "LUDI" ADD FOREIGN KEY ("KOD_KOMANDI") REFERENCES TEAM ("KOD_KOMANDI");

Таблиця "Матчі":

CREATE TABLE "MATCHI" ("KOD_K1" INTEGER NOT NULL, "KOD_K2" INTEGER, "OCHKI_1" INTEGER, "OCHKI_2" INTEGER, "KOMANDA_1" VARCHAR (20), "KOMANDA_2" VARCHAR (20), " , "VREMYA" DATE, "KOD_CHEMP" INTEGER NOT NULL, PRIMARY KEY ("KOD_KOMANDI", "KOD_CHEMP"));

ALTER TABLE "MATCHI" ADD FOREIGN KEY ("KOD_CHEMP") REFERENCES CHEMP ("KOD_CHEMP");

ALTER TABLE "MATCHI" ADD FOREIGN KEY ("KOD_K1") REFERENCES TEAM ("KOD_KOMANDI");

ALTER TABLE "MATCHI" ADD FOREIGN KEY ("KOD_K2") REFERENCES TEAM ("KOD_KOMANDI");

Таблиця "Work1":

CREATE TABLE "WORK1" ("KOD_KOMANDI" INTEGER NOT NULL, "KOD_TRENERA" INTEGER NOT NULL, PRIMARY KEY ("KOD_KOMANDI", "KOD_TRENERA"));

Таблиця «Команда ».

CREATE TABLE "TEAM" ("KOD_KOMANDI" INTEGER NOT NULL, "STRANA" VARCHAR(20), "GOROD" VARCHAR(20), "GOD_OSN" DATE, "NAZVANIE" VARCHAR(20), PRIMARY KEY ("KOD_KOMANDI") ;

Таблиця «Тренери ».

CREATE TABLE "TRENER" ("KOD_TRENERA" INTEGER NOT NULL, "FAMIL" VARCHAR(20), "IMYA" VARCHAR(20), "OTCHESTVO" VARCHAR(20), "TEL" VARCHAR(20), "ADRES" VARCHAR( 20), PRIMARY KEY ("KOD_TRENERA"));

Таблиця «Позиція ».

CREATE TABLE "POZITZIYA" ("KOD_POZITZII" INTEGER NOT NULL,

"POZITZIYA" VARCHAR(20), PRIMARY KEY ("KOD_POZITZII"));

2.4. Заповнення БД

Таблиця "Чемпіонат".

Таблиця "Члени команд".

Таблиця "Матчі".

Таблиця "Команда".

Таблиця "Тренер".

Таблиця "Work1".

I. Однотабличні запити:

1. Виводить усіх футболістів, у кого перша літера прізвища знаходиться в проміжку від "А" до "Г":

select famil from ludi where famil >="А" and famil< "Г";

2. Виводить усіх тренерів у кого перша буква прізвища знаходиться в проміжку від "А" до "Р":

select famil from trener where famil >="А" and famil< "Р";

3. Видає всіх гравців команди Локомотив:

select famil, imya, отчество from ludi where kod_komandi=1;

ІІ. Багатотабличні запити:

1. Виводить тренерів кожної команди:

select nazvanie, знайомий з team, trener, work1 where team.kod_komandi=work1.kod_komandi and work1.kod_trenera=trener.kod_trenera;

2. Виводить таблицю ігор усіх чемпіонатів:

select vid_chemp, komanda_1,komanda_2,ochki_1,ochki_1 від chemp, matchi where chemp.kod_chemp=matchi.kod_chemp;

3. Виводить футболістів, хто грає в якомусь клубі:

select famil, nazvanie from ludi, team where team.kod_komandi=ludi.kod_komandi;

………………………………………….

…………………………………………..

ІІІ. З використанням функцій та обчислюваних значень:

1. Обчислює кількість грачів команди Локомотв:

select count(*) kod_chel from ludi where kod_komandi=1;

2. Виводить команду засновану раніше за всіх:

select min(god_osn) from team;

3. Виводить яку кількість матчів зіграла команда Локомотив:

select count(*) from matchi where kod_k1=1 or kod_k2=1;

IV. З груповими операціями

1. Виводить кількість граків кожної команди:

selectnazvanie, count(famil) fromludi, teamwhereteam.kod_komandi=ludi.kod_komandigroupbynazvanie;

2. Виводить скільки ігор зіграно у кожному чемпіонаті:

select vid_chemp, count(kod_chemp) від chemp, matchi where matchi.kod_chemp=chemp.kod_chemp group by vid_chemp;

Висновок

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

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

2. Е.К. Лецький «Інформаційні технології на залізничному транспорті», М: УМК МПС Росії, 2000.

Цілі уроку: створити умови для сприйняття та закріплення навчального матеріалу на тему “Моделювання в текстовому процесорі”

1. Продовжити знайомити учнів із можливостями моделювання у текстовому процесорі Word;
2. Ознайомити учнів із поняттям та видами структурних моделей;
3. Навчити загальний підхід до створення образно-знакових моделей у текстовому процесорі;
4. Забезпечити виконання завдань із моделювання у середовищі текстового процесора.

Розвиваюча:

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

Виховна:

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

Тип уроку: комбінований.

Обладнання уроку: комп'ютер, проектор, презентація ( Додаток 1), картки із завданням для практичної роботи ( Додаток 2).

Хід уроку:

I. Орг. момент.

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

ІІ. Актуалізація опорних знань учнів.

• Фронтальна робота із класом:

(додаток 1 слайд 2),

– Які моделі називаю знаковими?

- Назвіть відомі вам види знакових моделей?

– Яку знакову модель називають словесною?

– Який текстовий документ називається складовим?

– Наведіть приклади оформлювальних завдань, які вирішуються за допомогою створення складених документів у текстовому редакторі.

ІІІ. Вивчення нового матеріалу.

Структурою називається взаємне розташування складових частин чогось.

Структура даних – сукупність елементів інформації що у певної, заздалегідь заданої взаємозв'язку, і навіть спосіб опису такого взаємозв'язку. ( Додаток 1 слайд 3),

Структурна модель даних – модель даних, представлена ​​як структури – безлічі типів даних та зв'язків з-поміж них.

Найбільш поширеними у текстових документах є такі види інформаційних структур: ( додаток 1 слайд 4)

• Таблиця
• Схема – відбиває зовнішній вигляд класифікації об'єктів
(додаток 1 слайд 5)

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

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

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

Молодята нормально володіють правою рукою. У сім'ї жінки було ще дві сестри, які нормально володіли правою рукою, і три брати шульги. Мати жінки – правша, батько – шульга. У батька є сестра та 2 брати правші. Дід по лінії батька – правша, бабця – шульга. У матері жінки є два брати і сестра – всі правши. Мати чоловіка – правша, батько – шульга. ( Додаток 1 слайд 6)

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

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

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

Вам, звичайно, доводилося складати протокол ведення класних зборів.

– Що таке протокол? ( Протокол – документ, який фіксує хід обговорення питань та прийняття рішення на зборах, нарадах тощо)

– Яка обов'язкова інформація на ваш погляд має бути відображена у протоколі? (дата засідання; кількість присутніх; порядок денний; хід обговорення; рішення зборів)(Додаток 1 слайд 9)

на слайд 10 додатка 1наведено зразок оформлення протоколу класних зборів.

IV. Закріплення дослідженого матеріалу.

Виконання практичної роботи "Створення знакової структурної моделі" на комп'ютері ( Додаток 2)

V. Підсумок уроку.

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

- що вийшло?
- Що не вийшло?
- Які труднощі відчували під час виконання завдань?

2. Виставлення відміток виконання практичної роботи.

VI. Домашнє завдання.

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