align="justify"> У загальному випадку, якщо у великій кількості запитів потрібно об'єднувати більше п'яти або шести таблиць, слід розглянути варіант денормалізації бази даних.
В· денормалізації шляхом введення додаткового поля в одну з таблиць. При цьому з'являється надмірність даних, потрібні додаткові дії для збереження цілісності БД.
Оскільки масштаб розроблюваної мною бази даних відносно малий, то істотного підвищення швидкодії шляхом значної зміни структури даних домагатися не має сенсу. Тим не менш, в рамках денормалізації даних мого проекту необхідно створити зручну систему вибірки співробітників університету із загального списку по датах народження. p align="justify"> При аналізі предметної області та формулюванні основних завдань відділу кадрів університету, була означена обов'язок організації заходів з формування корпоративної культури. Ці заходи можуть бути різноплановими, але основну частину їх складає нагородження ювілярів, привітання з днем ​​народження і т.д. Значить, що розробляється база даних повинна забезпечувати можливість моніторингу дат народження всіх співробітників в зручній формі запиту. У моїй базі даних присутній атрибут Birth, що описує дату народження працівників ВУЗу, але, оскільки типом даних цього атрибуту є тип дата/час, використовувати його у вищеописаних цілях незручно. p align="justify"> Для вирішення даної проблеми потрібно створити ще одну сутність "День народження", зв'язавши його ідентифікуючої зв'язком з ключовою сутністю "Працівник". Після створення сутності я вніс до неї атрибути BirthDay, BirthMounth і BirthYear, що описують день, місяць і го д народження відповідно.
Таким чином, за рахунок надмірності даних про дні народження співробітників, я створив структуру, що дозволяє за допомогою запитів найбільш швидко визначити, наприклад, всіх співробітників, народжених в один місяць, з наступним визначенням чисел їх народження. На рис.13 показана денормалізованная фізична модель моєї бази даних. br/>В
Рис.13 Денормалізованная фізична модель бази даних
4.3 Коригування типів і розмірів полів
На етапі логічного проектування я вказував тільки типи доменів для кожного атрибута. Але в ERwin підтримується ще й точне визначення типів полів для конкретної обраної СУБД. Зараз в отриманій фізичної моделі необхідно скорегувати типи і розміри полів для заданої СУБД Access відповідно до табл.5. br/>
Таблиця 5
Типи даних і розміри колонок таблиць фізичної моделі
ТабліцаКолонкаТіп даннихОпит работиWorkBeginDate/TimeWorkText (20) WorkEndDate/TimeReasonText (30) PenaltyMemoRewardsMemoНаучние достіженіяDegreeYesYes NoRankIntegerDegreeIntegerУченая степеньDegreeNameText (40) Вчене званіеRankNameText (20) ОбразованіеEd...
