Відображення на реляційну модель даних

Реляційна модель даних складається з ряду відносин (таблиць). При відображенні концептуальної моделі, приведеної на мал. 5.8 (концепт. модель), на логічну модель необхідно визначити відносини і їх атрибути. Окремі атрибути цих відносин є їх первинними ключами.

Кожен прямокутник на мал. 5.8 представляє відношення і містить властиві йому атрибути. Всього показано п'ять відносин: СТУДЕНТ, КУРС, СЕМЕСТР, СЕМЕСТР+КУРС і СЕМЕСТР+КУРС+СТУДЕНТ.

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

Відображення на ієрархічну модель даних

Ієрархічну модель даних підтримує цілий ряд СУБД. Одна з них - система IMS, що поставляється IBM. Ця система підтримує і деякі мережеві структури. Використовування системи IMS накладає наступні обмеження на модель даних:

1. Можливе існування .не більше 255 типів вузлів, які в системі IMS називаються «типами сегментів».

2. Допускається не більш 15 рівнів ієрархії.

3. Породжений сегмент може мати максимум два початкові сегменти. Один з початкових сегментів, в ієрархії якого знаходиться породжений, називається «фізично початковим». Інший початковий називається «логічно початковим». На логічно породжені сегменти накладається наступне обмеження.

4. Логічно породжений не може мати логічно породженого.

Відображення на мережну модель даних

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

1. Формування узагальненої мережної моделі даних, в якій не враховуються обмеження, що накладаються використовуваній СУБД.

2. Трансформація узагальненої мережної моделі з урахуванням обмежень, що накладаються конкретній СУБД.

3. Модифікація трансформованої моделі з урахуванням «очевидних» міркувань, що впливають на продуктивність.

4. Спрощення імен ключів.

5. Реалізація взаємозв'язків, не відображених в логічній моделі, але насправді існуючих.

У мережній моделі даних на відміну від більшості інших моделей АБД повинен указувати способи розміщення записів. Вибір способу розміщення істотно впливає на експлуатаційні характеристики бази даних. Наприклад, екземпляри типу запису СЕМЕСТР + КУРС + СТУДЕНТ можуть розміщуватися або через набір ЗАЛІКИ-СТУДЕНТА, або через набір ЗАЛІКИ-ПО-КУРСУ-В-СЕМЕСТРІ. Вибір може визначатися тим, по якому шляху доступ здійснюється швидше. (Незалежно від того, через який набір розміщуються записи, доступ до них може вироблятися через будь-який з двох наборів.)

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

• Не слід ускладнювати структуру.

Самостійна робота №9

Тема: Запити з параметрами. Обчислення по полям.

Мета: ознайомитися з особливостями створення запитів та виконання обчислень.

Форма роботи: вивчення теоретичного матеріалу.

План:

1. Порядок введення формул в запит.

2. Призначення підсумкових запитів.

3. Порядок створення підсумкового запиту.

4. Види статистичних функцій.

Основна література: