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

3. Зв’язок (1:N) видається між сутностями СТАДІОНИ і ІГРИ.

Він характеризує стадіони, на котрих проводяться матчі.

 

 

3. Даталогiчна модель бази даних ”Ліга Чемпіонів”

Побудуємо логiчну схему бази даних "Ліга Чемпіонів", яка складається iз схем не менше нiж трьох взаємопов'язаних таблиць, таким чином, щоб вона мicтила поля вcix типiв, що пiдтримуються СУБД MS Access - символьнi, числовi, логiчнi, дата/ час, текст (mеmо), об'єкт, гiперпосилання.

У вiдповiдностi з процедурою проектування кожна з сутностей ПО подається базовою таблицею. Перший варіант цих таблиць описується так:

 

ТАБЛИЦЯ Ігри *(Звичайна сутність)

ПЕРВИННИЙ КЛЮЧ (Матч)

ПОЛЯ (Дата Дата/час, Час Дата/час, Господар Числовий(байт), Голи господарів Числовий(байт), Голи гостей Числовий(байт), Гість Числовий(байт), Стадіон Числовий (байт), Суддівська бригада Числовий (байт), Етап Текстовий(10));

 

ОБМЕЖЕННЯ На поля Дата і Час накладено маски: «00.00.0000» і «00.00» відповідно.

 

ТАБЛИЦЯ Команди *(Звичайна сутність)

ПЕРВИННИЙ КЛЮЧ (Команда)

ПОЛЯ (Назва Текстовий(15), Країна Текстовий(20), Місто Текстовий(20), Дата заснування Дата/час, Головний тренер Текстовий(25), Президент Текстовий(25));

 

ОБМЕЖЕННЯ На поле Дата заснування накладено маску: «00.00.0000.

 

ТАБЛИЦЯ Склади команд *(Слабка сутність)

ПЕРВИННИЙ КЛЮЧ (Номер)

ПОЛЯ (Гравець Текстовий(30), Амплуа Текстовий(15), Матчі Числовий (Ціле), Голи Числовий (Ціле), Команда Числовий(байт));

 

ОБМЕЖЕННЯ На поле Амплуа накладено підстановку «Поле зі списком» з можливими значеннями: "Захисник";"Нападник";"Півзахисник";"Воротар"

 

ТАБЛИЦЯ Стадіони *(Слабка сутність)

ПЕРВИННИЙ КЛЮЧ (Стадіон)

ПОЛЯ (Назва Текстовий(25), Країна Текстовий(20), Місто Текстовий(20), Місткість Числовий(довге ціле));

 

ТАБЛИЦЯ Суддівська бригада *(Звичайна сутність)

ПЕРВИННИЙ КЛЮЧ (Бригада)

ПОЛЯ (Головний Текстовий(30), Боковий1 Текстовий(30), Боковий2 Текстовий(30), Боковий3 Текстовий(30), Боковий4 Текстовий(30), Резервний Текстовий(30), Країна Текстовий(20));

 

Структура сутностей що використовуються в проектованій базі даних «Ліга Чемпіонів»

Рис. 2.1 Таблиця «Ігри»

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

Рис. 2.3 Таблиця «Склади команд»

Рис. 2.4 Таблиця «Стадіон»

Рис. 2.5 Таблиця «Суддівська бригада»

 

4. Нормалізація відношень бази даних “Ліга Чемпіонів”

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

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

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

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

1. функціонально залежить від повного первинного ключа, а не від його частини (якщо ключ складений);

2. не має функціональної залежності від іншого не ключового поля.

Сутності ІГРИ, КОМАНДИ, СКЛАДИ КОМАНД, СТАДІОНИ, СУДДІВСЬКА БРИГАДА, є нормалізованими, що складаються з простого ключа.

Отже, база даних ”Ліга Чемпіонів” приведена до третьої нормальної форми. Тобто всі не ключові поля кожної таблиці функціонально не залежать від інших не ключових полів таблиці. Залежать лише від ключових.

 

Структура зв’язків між сутностями що використовуються в нашій базі даних

 

5. Виконання операцій реляційної алгебри

Теоретико-множинні операції

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

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

Рис.5.1 Початковий стан відношення Команди

 

Рис.5.2 Початковий стан відношення Команди_1

Операція об’єднання

Необхідно утворити відношення у якому будуть відображені відомості про всіх дилерів. Для цього виконуємо об’єднання відношень КОМАНДИ та КОМАНДИ_1. Результат виконання операції подано на рис 5.1.1.

Вираз: КОМАНДИ КОМАНДИ_1

рис 5.1.1. Об’єднання відношень Команди та Команди_1.

Запит:

SELECT Команди_1.[Команда], Команди_1.[Назва], Команди_1.Країна, Команди_1.Місто, Команди_1.[Дата заснування], Команди_1.[Головний тренер], Команди_1.[Президент]

FROM Команди_1

UNION SELECT Команди.[Команда], Команди.[Назва], Команди.Країна, Команди.Місто, Команди.[Дата заснування], Команди.[Головний тренер], Команди.[Президент]

FROM Команди;

 

Операція перетину

Операція перетину відображає інформацію про тих дилерів,що є в обох відношеннях КОМАНДИ та КОМАНДИ_1 одночасно. Множина атрибутів відношень КОМАНДИ та КОМАНДИ_1 однакові. Результат виконання операції подано на рис 5.1.2.

 

Вираз: КОМАНДИ ∩ КОМАНДИ_1

Рис.5.1.2 Операція перетину Команди та Команди_1

Запит:

SELECT Команди_1.[Команда], Команди_1.[Назва], Команди_1.Країна, Команди_1.Місто, Команди_1.[Дата заснування], Команди_1.[Головний тренер], Команди_1.[Президент]

FROM Команди_1

WHERE Команди_1.[Команда] IN(SELECT Команди.[Команда] FROM Команди);

 

Операція різниці відношень

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

 

1. Вираз: КОМАНДИ \ КОМАНДИ_1

2. Вираз: КОМАНДИ_1 \ КОМАНДИ

рис 5.1.3. Операція різниці відношень

Інформаційне наповнення результату різниці між відношеннями КОМАНДИ та КОМАНДИ_1, складається з кортежів відношення КОМАНДИ, які не є кортежами відношення КОМАНДИ_1 (рис.1.). Кортежі відношення КОМАНДИ_1, що не є елементами інформаційного наповнення НАЗВА, формують результат різниці між відношеннями КОМАНДИ_1 та КОМАНДИ (рис.2). Результуючі відношення варіантів різниці не співпадають.

Запити:

1.

SELECT Команди.[Команда], Команди.[Назва], Команди.Країна, Команди.Місто, Команди.[Дата заснування], Команди.[Головний тренер], Команди.[Президент]

FROM Команди

WHERE Команди.[Назва] NOT IN(SELECT Команди_1.[Назва] FROM Команди_1);

 

2.

SELECT Команди_1.[Команда], Команди_1.[Назва], Команди_1.Країна, Команди_1.Місто, Команди_1.[Дата заснування], Команди_1.[Головний тренер], Команди_1.[Президент]

FROM Команди_1

WHERE Команди_1.[Назва] NOT IN(SELECT Команди.[Назва] FROM Команди);