Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Міністерство освіти та науки, молоді та спорту України
Національний університет «Львівська політехніка»
Кафедра АСУ
Звіт
про виконання лабораторної роботи № 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) у кожному записі можна розрізняти
клієнтів. Це дуже важливо, оскільки у таблиці можуть зустрічатися однакові
прізвища. Теоретично можна використовувати ім’я клієнта та його адресу, але не виключено, що у людей з однаковим прізвищем адреса одна й та ж (наприклад, батько й син можуть проживати за однією адресою і мати не тільки однакове прізвище але й ініціали). Мета встановлення первинних ключів у створені унікальних записів.
Як вибрати ключ
У більшості таблиць є поле або комбінація полів, які роблять запис уні-
кальним. Саме вони складають первинний ключ для таблиці. Часто поле ключа
може бути ідентифікаційним полем таблиці, яке зазвичай є текстовим.Його вміст задається при створенні. Можна визначити його як просту послідовністьзначень 0001, 0002, 0003 і т.д. або використовувати як перший символ літеру (наприклад першу літеру назви компанії) і додати порядковий номер (А001, А002, В001, В002 і т.д.). Спосіб нумерації може також бути отриманий у результаті деяких обчислень, що базуються на інформації з декількох полів таблиці. Дуже часто поле первинного ключа розташовують першим. Первинними ключами можна оголосити декілька полів. Для цього слід виділити необхідні поля у специфікації: утримуючи клавішу [Ctrl] натиснутою,слід клікнути мишкою у селекторній колонці навпроти кожного з потрібних полів.
Зв’язки між таблицями
У реляційних базах даних користувач може описати відношення між
декількома таблицями. Access враховує ці відношення при пошуку взаємопов’язаних даних під час обробки запитів, форм та звітів, що базуються на декількох таблицях. Щоб встановити зв’язки між кількома таблицями спершу треба створити первинний ключ для кожної таблиці. Для встановлення зв’язків у вікні бази даних слід вибрати команду Relationships (Зв’язки) з меню Tools (Інструменти). Після створення зв’язку між двома таблицями можна змінити його властивості, зокрема, властивість тип зв'язку (Join Type). Найбільш розповсюдженим типом зв’язку є One-To-Many (Один-до-багатьох). Додатково, при визначенні зв'язків можуть встановлюватись правила цілісності даних (Referential Integrity), які дозволяють опрацьовувати зв'язані таблиці як єдину структуру. Допускається встановлення таких правил:
- каскадна модифікація – визначає синхронну зміну значень полів зв'язку в
обох таблицях;
- каскадне знищення – одночасне знищення пов'язаних записів у головній і підпорядкованій таблицях.
Описання виконаної роботи
Об’єкт інформаційного моделювання
Предметна область - велика інформаційна система кінопрокат спрямована для збирання, обробки інформації та надання послуг кінопрокату у місті. Ця система є ланцюгом між постачальниками послуг – кінотеатрами та його споживачами - глядачами. Тому оптимальної взаємодії виділених сторін, є необхідність автоматизації інформаційних процесів, що веде до швидкодії.
Основне завдання, яке стоїть перед проектуванням даної БД, є складання розкладу роботи різних кінотеатрів міста, з урахуванням сеансів ,які проходять у них .
Завданням цієї лабораторної роботи є описання певної предметної області на підставі якого буде спроектовано реляційну базу даних.
Вибрано таку предметну область:
Об’єкт – кінопрокат. Кінопрокат (або кінодистриб'юція)(англ. Film distribution) — масовий показ фільмів в мережі кінотеатрів. Потрібно побудувати базу даних Кінопрокат у місті, тобто цілісну базу даних з списком кінотеатрів міста, зали для перегляду фільмів наявністю, вартістю квитків, фільми та інформацією про них.
Моя база даних спроектована і призначена для працівників довідкової служби кінотеатрів міста, що забезпечує взаємодію з нею в режимі діалогу.
Концептуальна модель бази даних
Характеристики предметної області, що підлягають відображенню у базі даних, описує така множина атрибутів: назва кінотеатру, його адреса і номер телефону, інформація про зали в певному кінотеатрі, сеанси, їх дата та час початку та вартість ,інформація про фільми.
Логічна схема бази даних
Всі перелічені вище характеристики кінопрокату можна подати такими інформаційними відношеннями, тобто таблицями MS Access:
- Кінотеатри- перелік кінотеатрів у місті(назва, район , адреса, телефон)
-Зали – перелік залів у певному кінотеатрі(назва залу, к-ть місць, ціна ,категорія)
-Сеанси- інформація про розклад фільми якій показують в кінотеатрі(в якому залі який фільм ,коли ( час і дата ) і скільки вільних місць залишилось на певний сеанс)
-Фільми – Інформація про фільми (назва, режисер , тривалість фільму ,рік виходу , режисер)
-Ролі – інформація про акторів ,які знімалися в певному фільмі
- Актори – прізвища та ім`я акторів.
Структура та вміст таблиць
Кінотеатри
|
Код кінотеатру |
Назва |
Адреса |
Район |
Телефон |
|
|
Тип поля |
счечик |
Текст |
Текст |
Текст |
Число |
|
Розмірність |
Довге ціле |
50 |
50 |
Long date |
Довге ціле |
Зали
|
Код залу |
Назва |
Кінотеатр |
Кількість місць |
Категорія |
Ціна |
- |
|
|
Тип поля |
Счечик |
Текст |
Текст |
Числовий |
Числовий |
Число |
|
|
Розмірність |
Довге ціле |
50 |
255 |
Довге ціле |
Довге ціле |
Довге ціле |
Сеанси
|
Код залу |
Зал |
Фільм |
Дата |
Час |
Вільно місць |
|
|
Тип поля |
Счечик |
Текст |
Текст |
Дата й час |
Дата й час |
Числовий |
|
Розмірність |
Довге ціле |
Довге ціле |
Короткий формат |
- |
- |
Довге ціле |
Фільми
|
Код фільму |
назва |
Режисер |
Оператор |
Прокатна вартість |
Наявність призів |
Жанр |
Рік виробництва |
Країна |
Тривалість |
|
|
Тип поля |
Счечик |
Короткий текст |
Короткий текст |
Короткий текст |
Текст |
Короткий текст |
Текст |
Число |
Короткий текст |
Число |
|
Розмірність |
Довге ціле |
50 |
50 |
50 |
Довге ціле |
50 |
255 |
Довге ціле |
50 |
Довге ціле |
Ролі
|
Код участі |
Фільм |
Актор |
|
|
Тип поля |
Счечик |
Числовий |
Числовий |
|
Розмірність |
Довге ціле |
Довге ціле |
Довге ціле |
Актори
|
Код актора |
Прізвище |
Ім’я |
|
|
Тип поля |
Счечик |
Короткий текст |
Короткий текст |
|
Розмірність |
Довге ціле |
50 |
50 |
Додаткові властивості та обмеження полів
Для деяких полів наших таблиць необхідно задати певні обмеження та додаткові властивості:
У таблиці Кінотеатри:
Код кінотеатру – ключове поле.
Телефон – використана маска (000)-0-00-00
У таблиці Зали:
Код залу – ключове поле.
Ціна- накладено обмеження >0
У таблиці Сеанси:
Код сеансу – ключове поле.
Кількість місць= використано обмеження >=0
У таблиці Фільми:
Код фільму – ключове поле.
Жанр- використана підстановка – поле із списком - "Бойовик";"Вестер";"Документалний";"Детектив";"Драма";"Историчний";"Комедія";"Мелодрама";"Мультфільм";"Триллер";"Жахи";"Фантастика";"Містика"
У таблиці Ролі:
Код Участі – ключове поле.
У таблиці Актори:
Код актора – ключову поле
Зв’язки
Між даними таблиць Кінотеатри і Зали, Зали і Сеанси, Сеанси і фільми, Фільми і Ролі, Ролі і Актори зв’язок один-до-багатьох.
Рис.1. Відображення зв’язків у БД Кінопрокат у місті
Практичне завдання
Рис.2. Створення нової бази даних у MS Acces
Рис. 3. Створення таблиці у MS Access.
Рис. 4. Приклад заповнення полів, та їхніх типів даних таблиці Кінотеатри.
Рис. 5. Список всіх таблиць бази даних Кінопрокат у місті.
Для того, щоб пов’язати між собою таблиці і створити цілісну базу даних, потрібно «протягнути» відповідні первинні ключі в таблицю Зали, з інших таблиць. Робимо це так, як показано на рисунку:
Рис. 6. Зв’язування таблиць у вікні Зв’язки
Висновок: в цій лабораторній роботі ми ознайомилися з послідовністю, методами та засобами інформаційного моделювання предметної області, створення таблиць бази даних, проектування логічної структури реляційної бази даних, нормалізації баз даних. Я розробив базу даних кінопрокату у місті. Я вважаю її зручною і зрозумілоб пересічному користувачеві. Використав 6 таблиць і створив зв’язки між цими таблицями.