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

ТЕХНОЛОГІЙ

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

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

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

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

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

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

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

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

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

Інструкція

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

Створення фізичної моделі

бази даних

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

Дмитрів Г.Р.

Львів – 2011

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

Мета роботи – перенос логічної моделі даних в середовище цільової СУБД

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

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

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

• способи створення основних відношень;

• чи підтримує система визначення первинних, зовнішніх і альтернативних ключів;

• чи підтримує система визначення обов'язкових даних (тобто чи допускає система вказувати у визначенні атрибуту, що для нього заборонено використання значення NULL);

• чи підтримує система визначення доменів;

• чи підтримує система реляційні обмеження цілісності;

• чи підтримує система визначення обмежень наочної області.

Процедури розробки баз даних виконуються наступні дії.

1. Проектування основних відношень.

2. Розробка способів здобуття похідних даних.

3. Реалізація обмежень наочної області.

1.1 Проектування основних відношень

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

• ім'я відношення;

• список простих атрибутів, ув'язнений в круглі дужки;

• визначення первинного ключа і (якщо такі існують) альтернативних (АК) і зовнішніх (FK) ключів;

• список похідних атрибутів і опис способів їх обчислення;

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

Для кожного атрибуту в словнику даних має бути присутньою наступна інформація:

• визначення його домена, що включає вказівку типа даних, розмірність внутрішнього представлення атрибуту і будь-які необхідні обмеження на допустимі значення;

• значення атрибуту, що набуває за умовчанням (необов'язково);

• допустимість значення NULL для даного атрибуту.

При створенні проекту основних відношень використовується розширений формат виразів мови DBDL, що дозволяє вказувати домени, значень, що набувають за умовчанням, і індикатори допустимості значення NULL. Як приклад в лістингу 16.1 приведено визначення відношення PropertyForRent з учбового проекту Dreamhome.

Опис відношення PropertyForRent на мові DBDL

Domain PropertyNumber: variable length character string, length 5

Domain Street: variable length character string, length 25

Domain City: variable length character string, length 15

Domain Postcode: variable length character string, length 8

Domain PropertyType: single character, must be one of 'В', 'С, 'D’ ,' E ', 'F’, 'H’, 'M', 'S'

Domain PropertyRooms: integer, in the range 1-15

Domain PropertyRent: monetary value, in the range 0.00-9999.99

Domain OwnerNumber: variable length character string, length 5

Domain StaffNumber: variable length character string, length 5

Domain BranchNuraber: fixed length character string, length 4

PropertyForRent(

propertyNo PropertyNumber NOT NULL,

street Street NOT NULL,

city City NOT NULL,

postcode Postcode,

type PropertyType NOT NULL DEFAULT 'P',

rooms PropertyRooms NOT NULL DEFAULT 4,

rent PropertyRent NOT NULL DEFAULT 600,

ownerNo OwnerNumber NOT NULL,

staffNo StafrNumber,

branchNo BranchNumber NOT NULL,

PRIMARY KEY (propertyNo),

FOREIGN KEY (staffNo) REFERENCES Staff(staffNo) ON UPDATE CASCADEON DELETE SET NULL,

FOREIGN KEY {ownerNo) REFERENCES PrivateOwner(ownerNo) and

BusinessOwner(ownerNo) ON UPDATE CASCADE ON DELETE NO ACTION,

FOREIGN KEY (branchNo) REFERENCES Branch{branchNo) ON UPDATE

CASCADE ON DELETE NO ACTION);

Реалізація основних відношень

Тепер необхідно прийняти рішення про спосіб реалізації основних відношень. Це рішення залежить від типу вибраної цільової СУБД — при визначенні основних відношень деякі системи надають більше можливостей, чим інші. У попередніх розділах були продемонстровані три способи реалізації основних відношень: з використанням стандарту ISO SQL (розділ 6.1), Microsoft Access (розділ 8.1.3) і Oracle (розділ 8.2.3).

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

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