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

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

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

• загальна сума щомісячної зарплати всіх співробітників;

• кількість об'єктів нерухомості, що знаходяться під управлінням певного співробітника компанії.

Інколи похідні атрибути не включають в логічну модель даних, а описують в словнику даних. А якщо похідний атрибут включений в модель, для вказівки на те, що він є похідним, перед його ім'ям ставиться коса межа (/), як описано в розділі 11.1.2. На першому етапі проектування вивчається логічна модель даних і словника даних, а також готується список всіх похідних атрибутів. На етапі фізичного проектування бази даних необхідно визначити, чи повинен похідний атрибут зберігатися в базі даних або обчислюватися кожного разу, коли в нім виникає необхідність. Проектувальник повинен розрахувати наступне:

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

• витрати на обчислення похідних даних, якщо їх обчислення виконується в міру необхідності.

З цих двох варіантів вибирається найменш дорогий з врахуванням вимог до продуктивності. У останньому з перерахованих вище прикладів може бути прийняте рішення про зберігання відносно staff додаткового атрибуту, що позначає кількість об'єктів нерухомості, якими управляє в даний час кожен співробітник компанії. У таблиці. 16.1 приведено відношення PropertyForRent, а в таблиці. 16.2 — спрощене відношення Staff з новим похідним атрибутом NoOfProperties, сформоване на основі екземпляра учбового проекту бази даних Dreamhome, показаного в таблиці. 3.3-3.9.

Таблиця 16.1. Відношення PropertyForRent

proper tyNo	street	city	postcode	type	rooms	rent	owner No	staff No	branch No
PA14	16 Holhead	Aberdeen	AB7 5SU	House	6	650	C046	SA9	B007
PL94	6 Argyll St	London	NW2	Flat	4	400	C087	SL41	B005
PG4	6 Lawrence St	Glasgow	Gil 9QX	Flat	3	350	C040		B003
PG36	2 Manor Rd	Glasgow	G32 4QX	Flat	3	375	C093	SG37	B003
PG21	18 Dale Rd	Glasgow	G12	House	5	600	C087	SG37	B003
PG16	SNovarDr	Glasgow	G129AX	Flat	4	450	C093	SG14	B003

Таблиця 16.2. Спрощене відношення Staff з новим похідним атрибутом noOfProperties

staffNo	fName	Iname	branch No	noOfProperties
SL21	John	White	BOO5	0
SG37	Ann	Beech	BOO3	2
SG14	David	Ford	BOO3	1
SA9	Mary	Howe	BOO7	1
SG5	Susan	Brand	BOO3	0
SL41	Julie	Lee	BOO5	1

Додаткові витрати пам'яті для цього нового похідного атрибуту не дуже великі. Значення атрибуту оновлюється кожного разу, коли під управління співробітника компанії передається об'єкт нерухомості або відміняється його призначення для управління якимсь об'єктом; такі зміни відбуваються також при видаленні об'єкту нерухомості із списку доступних об'єктів. Але в любому з цих випадків значення атрибуту noofproperties для відповідного співробітника компанії має бути збільшене або зменшено на 1. У процесі проектування необхідно забезпечити, щоб ці зміни відбувалися в кожному з вказаних випадків і кількість об'єктів, що враховувалися, залишалася правильним, оскільки це гарантує цілісність бази даних. При зверненні до цьому атрибуту за допомогою будь-якого запиту його значення є безпосередньо доступним і не вимагає обчислення. З іншого боку, якщо цей атрибут не зберігався б безпосередньо відносно Staff, то його значення доводилося б обчислювати кожного разу, коли його буде потрібно. Для цього необхідно виконати об’єднання відношень Staff і Propertyforrent. Таким чином, якщо запит вказаного типа виконується часто або вважається дуже важливим з точки зору продуктивності, похідний атрибут доцільніше зберігати в базі даних, а не обчислювати при кожному зверненні до його значення. Рішення, що передбачає зберігання похідних атрибутів, є прийнятним і в тому разі, якщо мова запитів цільової СУБД не дозволяє легко реалізувати алгоритм обчислення похідних атрибутів. Наприклад, в мові SQL є лише обмежений набір функцій агрегації, який не дозволяє легко реалізувати рекурсивні запити, як було описано в главі 5.

Документальне оформлення проекту здобуття похідних даних

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