Проектування бази даних Ліги Чемпіонів

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

Рубрика Программирование, компьютеры и кибернетика
Вид контрольная работа
Язык украинский
Дата добавления 27.08.2012
Размер файла 3,2 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

Проектування бази даних Ліги Чемпіонів

ліга турнір база даний

Завдання: автоматизувати процес формування та опрацювання бази даних Ліги Чемпіонів.

Таблиця. Зміст завдання та календарний план його виконання

з/п

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

Дата

1.

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

25.02.2012

2.

Визначення та опис предметної області.

10.03.2012

3.

Побудувати моделі типу «сутність-зв'язок».

18.03.2012

4.

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

22.03.2012

5.

Побудова обмежень відношень бази даних. Нормалізація відношень бази даних.

25.03.2012

6.

Виконання над відношеннями операцій реляційної алгебри.

27.03.2012

7.

Оформити записку до курсової роботи згідно з вимогами Міжнародних стандартів, дотримуючись такого змісту:

· Вступ;

· Визначення та опис предметної області;

· Концептуальна модель «сутність- зв'язок»;

· Логічна структура бази даних;

· Розроблення обмежень відношень бази даних;

· Нормалізація бази даних;

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

· Висновки;

· Література;

· Додатки.

3.04.2012

Завдання прийнято до виконання: _______________ р.

Керівник роботи _____________

Вступ

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

Ліга чемпіонів УЄФА (англ. UEFA Champions League) -- щорічний футбольний турнір, що проводиться поміж європейськими клубами, які найбільш успішно виступили у національних чемпіонатах попереднього сезону. Турнір запроваджено УЄФА.

Раніше (з сезону 1955/56 до сезону 1991/92) турнір мав назву Кубок Європейських чемпіонів. Починаючи з сезону 1992/93 турнір отримав нинішню назву та змінив формат.

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

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

Для розробки бази даних вибрав досить зручний в проектуванні і простий у використанні MS Access 2003.

Визначення та опис предметної області «Ліга Чемпіонів»

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

До об'єктів та сутностей предметної області Ліга Чемпіонів можна віднести:

До інформації про ігри, які відбуватимуться в Лізі чемпіонів можна віднести:

1) матч;

2) господар;

3) гість;

4) голи господарів;

5) голи гостей;

6) етап.

До інформації, що описують команди:

1) назва;

2) країна;

3) місто;

4) дата заснування;

5) головний тренер;

6) президент.

До інформації, що описують склади команд:

1) номер;

2) гравець;

3) амплуа;

4) матчі;

5) голи;

6) команда.

До інформації про стадіон:

1) стадіон;

2) назва;

3) країна;

4) місто;

5) місткість.

До інформації, що відображає дані про суддівські бригади:

1) бригада;

2) головний;

3) боковий1

4) боковий2;

5) боковий3;

6) боковий4;

7) резервний;

8) країна.

Побудова ЕR-моделi бази даних "Ліга Чемпіонів"

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

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

ІГРИ (Матч, Дата, Час, Господар, Голи господарів, Голи гостей, Гість, Стадіон, Суддівська бригада, Етап).

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

КОМАНДИ (Команда, Назва, Країна, Місто, Дата заснування, Головний тренер, Президент).

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

СУДДІВСЬКА БРИГАДА (Головний, Боковий1, Боковий2, Боковий3, Боковий4, Резервний, Країна)

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

Сутності, пов'язанi мiж собою асоцiацiями або зв'язками.

Зв'язки(1:N) видаються між сутностями КОМАНДИ і ІГРИ.

Вони характеризують команди господарів і гостей.

Зв'язок(1:N) видається ? мiж сутністю СУДДІВСЬКА БРИГАДА і ІГРИ.

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

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

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

Даталог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 Таблиця «Суддівська бригада»

Нормалізація відношень бази даних «Ліга Чемпіонів»

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

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

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

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

Сутності ІГРИ, КОМАНДИ, СКЛАДИ КОМАНД, СТАДІОНИ, СУДДІВСЬКА БРИГАДА, є нормалізованими, що складаються з простого ключа. Отже, база даних «Ліга Чемпіонів» приведена до третьої нормальної форми. Тобто всі не ключові поля кожної таблиці функціонально не залежать від інших не ключових полів таблиці. Залежать лише від ключових.

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

Рис.

Виконання операцій реляційної алгебри. Теоретико-множинні операції

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

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

Рис.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). Результуючі відношення варіантів різниці не співпадають.

Запити:

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

FROM Команди

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

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

FROM Команди_1

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

Операція декартового добутку відношень

Для поєднання відомостей про стадіони та команди виконуємо операцію декартового добутку. Для цього використаємо проекцію відношень СТАДІОН та КОМАНДИ, ці відношення (рис.5.1.4.1.,5.1.4.2.) не мають однакових атрибутів, результат виконання операції подано на рис 5.1.1.4.

Вираз: СТАДІОН x КОМАНДИ

Рис.5.1.4.1 Початковий стан проекції відношення Стадіон.

Рис.5.1.4.2 Початковий стан проекції відношення Команди.

Рис.5.1.4.3. Операція декартового добутку відношень Стадіон та Команди

Запит:

SELECT Стадіон.*, Команди.*

FROM Стадіон, Команди;

Спеціальні реляційні операції. Операція проекції відношення

Потрібно визначити міста команд учасників. Для цього виконаємо операцію проекції відношення КОМАНДИ на підмножини атрибутів А'={Команда, Назва, Місто, Країна}, результат виконання операції подано на рис 5.2.1. Вираз: КОМАНДИ(Команда, Назва, Місто, Країна)

Рис 5.2.1. Операція проекції відношення КОМАНДИ

Запит:

SELECT Команди.[Команда], Команди.[Назва], Команди.Місто, Команди.Країна

FROM Команди

Операція селекції відношення

З відношення СКЛАДИ КОМАНД виберемо інформацію про гравців амплуа, яких «Нападник». Для цього виконуємо операцію селекції відношення СКЛАДИ КОМАНД з критерієм відбору ш=(Амплуа = Нападник).

Вираз: СКЛАДИ КОМАНД(Амплуа="Нападник")

Рис. 5.2.2. Операція селекції відношення СКЛАДИ КОМАНД

Запит:

SELECT Команди.[Назва], Команди.Країна, Команди.Місто, Команди.[Дата заснування], Команди.[Головний тренер], Команди.[Президент], Склади.[Номер], Склади.[Гравець], Склади.[Амплуа]FROM Команди INNER JOIN Склади ON Команди.[Команда] = Склади.[Команда]

WHERE (((Склади.[Амплуа])="Нападник"))

ORDER BY Команди.[Команда];

Операція натурального з'єднання відношень

Необхідно отримати інформацію про стадіон у відношені ІГРИ. Для цього виконуємо операцію натурального з'єднання відношень СТАДІОН та ІГРИ.

Вираз: СТАДІОН * ІГРИ

Рис .5.2.3.Початковий стан відношення СТАДІОН

У відношеннях СТАДІОН та ІГРИ спільним атрибутом є стадіон, що дозволяє виконати їх натуральне з'єднання. Результат виконання операції подано на рис 5.2.3.

Рис. 5.2.3 Операція натурального з'єднання відношень .

Запит:

SELECT Ігри.[Матч], Ігри.[Дата], Ігри.[Час], Стадіон.[Назва], Стадіон.[Країна], Стадіон.[Місто], Стадіон.[Місткість]

FROM Стадіон, Ігри

WHERE Стадіон.[Стадіон]=Ігри.[Стадіон]

Операція умовного з'єднання відношень

Потрібно визначити, коли і на якому матчі працювала бригада арбітрів за номером 10. Для цього виконаємо операцію над відношенням ІГРИ та проекцією відношення СУДДІВСЬКА БРИГАДА і задамо критерій ш=(Суддівська бригада=10^Матч>5).

Вираз: ІГРИ *?СУДДІВСЬКА БРИГАДА

Рис. 5.2.4. проекція відношення СУДДІВСЬКА БРИГАДА

Рис. 5.2.4 Операція умовного з'єднання відношень

Обчислюємо значення критерію для кожного з кортежів відношень ІГРИ та СУДДІВСЬКА БРИГАДА шляхом порівняння відповідних атрибутів.

Як видно з рисунку результатом виконання операції є нове відношення, множина атрибутів якого є об'єднанням множини атрибутів відношень ІГРИ та СУДДІВСЬКА БРИГАДА. Кожен кортеж інформаційного наповнення результуючого відношення утворений шляхом об'єднання тих кортежів відношень ІГРИ та СУДДІВСЬКА БРИГАДА, у яких значення атрибутів задовольняють критерієві з'єднання.

Запит:

SELECT Ігри.[Матч], Ігри.Дата, Ігри.Час, Ігри.[Етап], Ігри.[Суддівська бригада], Судді.[Головний], Судді.[Боковий1], Судді.[Боковий2], Судді.[Боковий3], Судді.[Боковий4], Судді.[Резервний], Судді.[Країна]

FROM Ігри, Судді

WHERE (((Ігри.[Матч])>5) AND ((Судді.[Бригада])=10));

Операція додавання кортежу до відношення

Операція включення нового кортежу у відношення. У відношення СТАДІОН додам новий кортеж.

Insert(СТАДІОН, (12, 'Львів-Арена', 'Україна', 'Львів', 32000)

Рис. 5.2.5 Операція додавання кортежу до відношеня

Запит:

INSERT INTO Стадіон

VALUES (11, 'Львів-Арена', 'Україна', 'Львів',32000);

Операція вилучення кортежу з відношення

Видалю кортеж який добав у попередньому пункті у відношенні СТАДІОН.

Delete(СТАДІОН,( Стадіон =11)

Рис. 5.2.6 Операція видалення кортежу з відношеня

Запит:

DELETE *

FROM Стадіон

WHERE [Стадіон]=11;

Операція зміни значень атрибутів у кортежі відношень

Модифікую значення атрибуту у кортежу з відношення СТАДІОН.

Update(СТАДІОН,( Стадіон =1),(Місткість=50000))

Рис. 5.2.7 Операція зміни значень атрибутів у кортежі відношень

Запит:

UPDATE Стадіон SET [Місткість] = 50000

WHERE [Стадіон] =1;

Операція визначення нового атрибута у відношення

Для відношення СТАДІОН визначу новий атрибут.

Add(Стадіон,Відкриття)

Рис. 5.2.8 Операція визначення нового атрибута у відношення

Запит:

ALTER TABLE Стадіон

ADD Відкриття varchar (10) NOT NULL;

Операція вилучення атрибута з відношення

З відношення СТАДІОН видалю атрибут Відкриття, який був доданий у попередньому пункті.

Drop(Стадіон,Відкриття)

Рис. 5.2.9 Операція вилучення атрибута з відношення

Запит:

ALTER TABLE Стадіон

DROP COLUMN Відкриття;

Операція зміни параметрів атрибута у відношенні:

Зміна області визначення атрибута

Alter(Стадіон,Dмісткість,Dмісткість*1.1) додаєм до місткості 10%

Таблиця Місткість до змін:

Рис. 5.2.10.1 Зміна області визначення атрибута

Таблиця після змін:

Рис. 5.2.10.2 Зміна області визначення атрибута

Запит:

UPDATE Стадіон SET Стадіон.[Місткість] = [Стадіон]![Місткість]*1.1;

Висновок

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

Створена база даних є достатньо ефективною та зручною у застосуванні. Також не містить надлишкової інформації.

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

1.Берко А. Ю., Верeс О. М., Пасічник В.В. Організація баз даних та знань: Навч. Посібник.-Львів: «Магнолія 2006», 2011.-456 с.

2.http://datasql.ru/basesql/5.htm

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


Подобные документы

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

    курсовая работа [147,2 K], добавлен 02.06.2019

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

    курсовая работа [3,5 M], добавлен 28.11.2011

  • Відомості про бази даних, їх історія становлення та загальна інформація про Microsoft Visual FoxPro. Установка Visual FoxPro, створення проекту, таблиць, запитів. Аналіз реляційної бази даних. Прийоми проектування і реалізації реляційної бази даних.

    курсовая работа [1,6 M], добавлен 22.04.2019

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

    курсовая работа [35,6 K], добавлен 19.08.2012

  • Використання баз даних та інформаційних систем. Поняття реляційної моделі даних. Ключові особливості мови SQL. Агрегатні функції і угрупування даних. Загальний опис бази даних. Застосування технології систем управління базами даних в мережі Інтернет.

    курсовая работа [633,3 K], добавлен 11.07.2015

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

    курсовая работа [4,0 M], добавлен 02.12.2014

  • Бізнес процеси й елементи даних. Специфікація елементів даних. Діаграма класів проектування. Створення та використання об'єктів бази даних. Таблиці, обмеження цілісності, тригери, типові вибірки, представлення, індекси. Типові оператори модифікації даних.

    курсовая работа [255,3 K], добавлен 01.06.2019

  • Поняття та переваги реляційної бази, автоматизація аналізу даних. Опис основних компонентів сховища даних AS/400. Процес перетворення оперативних даних в інформаційні. Багатовимірні бази даних (MDD). Опис даних і створення файлів в інтеграційних базах.

    реферат [36,8 K], добавлен 14.01.2012

  • Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.

    курсовая работа [8,8 M], добавлен 16.12.2015

  • Реляційна модель баз даних. Цілісність бази даних. Нормалізація, нормальні форми та функціональні залежності. Нормальна форма Бойса-Кодда. Запити та форми Access. Процес нормалізації при побудові бази даних "Музей" та система запитів над даними.

    курсовая работа [2,9 M], добавлен 06.11.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.