Освітній портал MyReferatik

Зміст

ВСТУП 5
1 АНАЛІЗ СУЧАСНОГО РОЗВИТКУ СУБД 6
2 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ 8
3 РОЗРОБКА УНІВЕРСАЛЬНОГО ВІДНОШЕННЯ 9
4 РОЗРОБКА ER-МОДЕЛІ ПРЕДМЕТНОЇ ОБЛАСТІ 11
5 ПРОЕКТУВАННЯ НОРМАЛІЗОВАНИХ ВІДНОШЕНЬ 15
5.1 Одержання початкових відношень за методом “суть – зв'язок” 16
5.2 Нормалізація відношень методом декомпозиції 18
5.3 Оцінка спроектованих НФБК відношень 19
6 РЕАЛІЗАЦІЯ ЗАПИТІВ І ВИХІДНИХ ФОРМ 21
6.1 Аналіз запитів, що реалізуються СКБД 21
6.2 Розробка вихідних форм 21
ВИСНОВКИ 23
ПЕРЕЛІК ПОСИЛАНЬ 24
Додаток Б. Таблиці 29
Додаток В. Запити 31
Додаток Г. Звіти 32
Додаток Д. Схема даних 34

Уривки

Ищешь качественные сапоги для ребенка? В интернет магазине yokoko ты сможешь детские сапоги купить от известного японского производителя обуви. Твой малыш заслуживает лучшего.
5.3 Оцінка спроектованих НФБК відношень
Перевірка НФБК - відношень, які розглядаються в якості кінцевого проекту на предмет наявності невиявлених проблем, включає такі основні кроки :
1. Складаються списки функціональних залежностей дня кожного від-ношення. Ці списки перевіряються на двох направленнях:
- одна і таж функціональна залежність не повинна з'являтися більш, чим в одному відношенні;
- набір функціональних залежностей, отриманих в результаті проекту-вання, повинен в точності співпадати з набором, присутнім в мінімальному покритті, отриманому перед початком проектування. Іншими словами, потрібно буде довести можливість отримання підсумкового набору функціональних залежностей з мінімального покриття за допомогою правил виведення. Якщо хоча б одна з перевірок виявиться недостовірною (невірогідною), прийдеться аналізувати процес проектування для виявлення помилок і/або розглянути інші варіанти проектування.
2. Здійснюється перевірка на присутність надлишкових відношень. Відношення являється надлишковим якщо :
- всі його атрибути можуть бути знайдені в одному або другому відно-шенні набору, що проектується;
- всі його атрибути можуть бути знайдені в відношенні, котре може бути отримане з інших відношень запропонованого проектного набору за допомогою серії JOIN - операцій над цими відношеннями. Якщо встановлена надлишковість відношення, його потрібно видалити з проектного набору.
3. Розгляд відношень з практичної точки зору. Вивчається характер використання відношень в базі даних, що проектується і визначаться чи будуть вони підтримувати ті типи операцій відновлення та занити, котрі передбачається використовувати.
В загальному випадку, в процесі проектування атрибути можуть згрупуватися нелогічно. Це вказує на можливу помилку, викликає в подальшому складності у реалізації запитів. Досвідчений проектувальник обов'язково слідкує за атрибутами в процесі проектування відношень і намагається осмислити, наскільки розумно вони групуються одне з одним.
Розглядаючи отримані при проектуванні бази даних "Ремонт ПК" відношення, можна помітити, що:
- ні одна ФЗ не повторюється більше одного разу;
- цей набір ФЗ являється мінімальним.
Аналіз відношень показує, що не можна вказати серед них жодного, всі атрибути якого були би підмножиною атрибутів іншого відношення. Крім того, неможливо об’єднати будь-які два відношення так, щоб у результаті були отримані всі атрибути третього відношення. Тобто, жодне з відношень не є надлишковим, що свідчить про правельність проведення проектування.
Кінцеві відношень приймуть наступний вигляд:
R2 (, Кількість, Ціна, Сума),
R3(, ПІБ, Статус, Примітка),
R5(, НазваЗамов, Дата, КодВарт, №КредитКартки),
R6(, НазваДеталі, Виробник),
R7().
6 РЕАЛІЗАЦІЯ ЗАПИТІВ І ВИХІДНИХ ФОРМ

6.1 Аналіз запитів, що реалізуються СКБД
Для користувача є приємним той факт, що розроблена автоматизована система обслуговування бази даних могла б у зручній формі представляти відповіді на запити користувача. Працюючи з даною АСУБД, користувач може:
- «Пошук замовлення». За допомогою даного запиту можна отримати список замовлень, які зробив клієнт. Сюди включають № кредитної картки клієнта, ПІБ клієнта, код замовлення, назва замовлення, вартість замовлення.
- «Пошук клієнта». За допомогою даного запиту можна знайти інформацію про клієнта (ПІБ, статус, примітки) за № кредитної картки.
- «Пошук деталі». За допомогою даного запиту можна отримати назву, шуканої за кодом, деталі і супутню інформацію до неї.
При виконанні даних запитів інформація видається в зручній для користувача формі.
Механізм пошуку даних реалізується вибором користувачем по-трібної бази даних і поля в ній – задається область пошуку, і потім введенням користувачем ключа, за яким буде відбуватися пошук потрібних даних в таблиці.

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