Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
2 лаба бд.docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
418.97 Кб
Скачать

Міністерство освіти та науки, молоді та спорту України

Національний університет «Львівська політехніка»

Кафедра АСУ

Звіт

про виконання лабораторної роботи № 2

з дисципліни:

Організація баз даних та знань

Виконав:

студент групи КН-22

Олекса Володимир

Перевірив:

старший викладач Рішняк І.В.

Львів 2013

Тема

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

Мета

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

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

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

Концептуальна модель передбачає два етапи реалізації: інфологічний та

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

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

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

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

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

концепутальної інфологічної моделі предметної області у даталогічну модель,

що визначається як множина схем відношень. У процесі такого відображення

виконуються такі перетвореня:

- кожному атрибутові сутності ставиться у відповідність атрибут

відношення;

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

своїх властивостей, ставиться у відповідність кортеж;

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

- зв'язок між класами сутностей відображається як зв'язок між відношеннями;

- множині взаємопов'язаних сутностей предметної області ставиться у

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

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

- один атрибут сутності може відображатися одним або кількома

атрибутами відношення;

- одному класові сутностей може відповідати одне, або декілька

відношень;

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

- зв'язки між відношеннями в реляційних базах даних не є самостійними

об'єктами, а реалізуються через значення атрибутів;

- зв'язки між атрибутами визначаються через відповідність їх значень відношень;

- зв'язки між відношеннями задаються через встановлення відповідності

між атрибутами цих відношень;

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

атрибутів сутностей;

- кількість відношень та зв'язків у базі даних може не відповідати

кількості сутностей та зв'язків у концептуальній моделі предметної

області.

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

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

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

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

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

Для кожного поля встановлюється тип даних, що визначає вигляд інформації, яка буде вноситись у це поле. Тип даних вноситься в колонку Data Type (Тип даних). Access розрізняє такі типи даних: число, текст, примітка, дата й час, грошова одиниця, автонумерація, так/ні, об’єкт OLE, гіперпосилання, майстер підстановок.

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

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

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

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

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

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

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

Нормалізація - це розбиття таблиці на дві або більше, що володіють

кращими властивостями при додаванні, зміні і видаленні даних. Остаточна мета

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

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

інформації. Це робиться не стільки з метою економії пам'яті, скільки для

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

реляційній БД задовольняє умові, відповідно до якої у позиції на перетині

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

і ніколи не може бути множини таких значень. Будь-яка таблиця, що

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

таблиці, тобто таблиці, які містять групи, що повторюються, навіть не

релізуються у реляційній БД.

База даних Microsoft Access

База даних складається з однієї або декількох таблиць, а також з інших

об’єктів, наприклад запитів, форм та звітів. Таблиці – це логічно згруповані дані. Вони складаються із лінійок (записів, rows, records) та стовпців (полів, columns, fields). Таблиці є основною формою представлення даних в реляційній базі даних. В Access без таблиці не можна спроектувати форму, на базі таблиць будуються запити і звіти. Багатотабличність дозволяє спростити ввід даних та зменшити кількість дубльованих та неправильно введених даних. Крім того часом дані в таблиці застарівають.

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

У Microsoft Access перед тим, як створювати таблиці, форми та інші

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

У Microsoft Access існує чотири засоби створення порожньої таблиці:

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

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

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

- Визначення всіх параметрів макету таблиці у режимі конструктора.

Додавання та видалення полів

У готову специфікацію можна вносити зміни. Зокрема можна змінювати

параметри окремих полів, додавати поля та видаляти зайві. Але при цьому слід

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

Первинний ключ

Кожна таблиця може мати первинний ключ. Він ідентифікує записи і

дозволяє відрізнити один запис від іншого. Первинний ключ складається з

одного або декількох полів. Наприклад, поле вставлене у таблицю КЛІЄНТІВ, дозволить відрізнити одного клієнта від іншого. Воно може бути названо полем

НОМЕРА КЛІЄНТА, може бути текстовим і задаватися користувачем при

створенні запису. Це поле може бути й числовим; значення у ньому будуть

створюватись автоматично при внесенні кожного нового запису. Маючи

унікальний первинний ключ (Primary Key) у кожному записі можна розрізняти

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

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