ДЕРЖАВНИЙ УНІВЕРСИТЕТ ІНФОРМАЦІЙНО – КОМУНІКАЦІЙНИХ

ТЕХНОЛОГІЙ

ЛЬВІВСЬКИЙ КОЛЕДЖ ДЕРЖАВНОГО УНІВЕРСИТЕТУ

ІНФОРМАЦІЙНО – КОМУНІКАЦІЙНИХ ТЕХНОЛОГІЙ

Навчальна дисципліна: Бази даних

Лабораторія: Комп’ютерних технологій

Розглянуто Затверджую

на засіданні циклової комісії Заступник директора з НВР

Обслуговування комп’ютерної техніки

Протокол №___від «___»_________20__р.

Голова комісії ______________Кужій Л.І. ___________Плешівський Я.М.

Інструкція

до практичної роботи №2

Створення локальної логічної моделі

бази даних

Склала викладач:

Дмитрів Г.Р.

Львів – 2011

1. Мета роботи

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

2. Короткі теоретичнi вiдомостi

1. Створення і перевірка локальної логічної моделі даних для окремих призначених для користувача представлень

На цьому етапі кожна локальна концептуальна модель даних, створена на етапі 1, перетвориться в локальну логічну модель даних, що складається з er-діаграмі реляційної схеми і супровідної документації. Для спрощення цього процесу передбачений необов'язковий перший етап, на якому відбувається усунення особливостей, які не можуть бути представлені безпосередньо в реляційній моделі (таких як зв'язки "багато до багатьох").Отримана реляційна схема перевіряється з використанням правил нормалізації для визначення того, чи є її структура правильної. Перевіряється також логічна модель, що дозволяє переконатися в тому, що вона підтримує всі транзакції, вказані в специфікації вимог користувача. Перевірена локальна логічна модель даних може застосовуватися як основа для розробки прототипів, якщо в цьому є необхідність. Нарешті, в модель вводяться обмеження цілісності.

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

На цій стадії виконуються наступні етапи.

1. Виключення особливостей, не сумісних з реляційною моделлю (необов'язковий етап).

2. Формування відношень на основі локальної логічної моделі даних.

3. Перевірка відношень з використанням засобів нормалізації.

4. Перевірка застосовності відношень для виконання призначених для користувача транзакцій.

5. Визначення обмежень цілісності. 6. Узгодження локальної логічної моделі даних з користувачем.

При виконанні справжнього етапу застосовується концептуальна модель даних, створена в попередній главі для представлення Staff учбового проекту Dreamhome. На рис. 15.1 приведена повна версія цієї локальної концептуальної моделі даних, де показані всі атрибути. Крім того, для ілюстрації певних понять, які не знайшли віддзеркалення в представленні Staff, використовуються приклади з представлення Branch учбового проекту Dreamhome.

1.1 Виключення особливостей, несумісних з реляційною моделлю (необов'язковий етап)

Призначення даного етапу полягає в наступному.

1. Видалення двосторонніх зв'язків "багато до багатьох" (*:*).

2. Видалення рекурсивних зв'язків "багато до багатьох" (*:*).

3. Видалення складних зв'язків.

4. Видалення багатозначних атрибутів.

1. Видалення двосторонніх зв'язків "багато до багатьох" (*:*)

Якщо в концептуальній моделі даних присутній зв'язок "багато до багатьох" (*:*), може бути виконана декомпозиція цього зв'язку для виявлення проміжної сутності (див. розділ 11.6.3). Зв'язок *:* замінюється двома зв'язками "один до багатьох" (1:*), в яких бере участь знов виявлена сутність.

Наприклад, розглянемо зв'язок Client Views Propertyforrent (Клієнт оглядає об'єкт нерухомості, що орендується) типу *:*, показаний на рис. 15.2, а. В результаті декомпозиції зв'язку Views (Оглядає) визначені сутність Viewing і два нові зв'язки 1:* (Requests (Вимагає проведення) і Takes (Піддається)). Тепер зв'язок Views типу *:* перетворений в два зв'язки — Client Requests Viewing (Клієнт вимагає проведення огляду) і Propertyforrent Takes Viewing (Об'єкт нерухомості піддається огляду), як показано на рис. 15.2, б. Слід зазначити, що сутність Viewing показана як слабка (жоден з її атрибутів не позначений як первинний ключ), оскільки її існування залежить від іншої сутності (Client і Propertyforrent).