озволяє швидко і наочно спроектувати модель у вигляді діаграм В«сутність-зв'язокВ», а потім згенерувати SQL код бази даних. Так як ERwin 7.3 не підтримує PostgreSQL, в якості СУБД була обрана MySql 5.x, тому що SQL синтаксис і основні типи даних в PostgreSQL та MySql збігаються. br/>
4.1 Логічний рівень моделі даних
У ERwin результат проектування на концептуальному рівні представляється логічною моделлю даних (малюнок 4.1).
У логічної моделі даних відображаються сутності й атрибути, ключові атрибути в моделі представлені в сутності, над рисою. Зовнішні ключі (мігруючі атрибути з батьківської сутності) позначаються як (FK - Foreign Key) [2]. Логічний рівень означає пряме відображення фактів з реального життя. Вони іменуються на природній мові, з будь-якими роздільниками слів (пробіли, коми і т.д.). На логічному рівні не розглядається використання конкретної СУБД, не визначаються типи даних (наприклад, ціле або дійсне число) і не визначаються індекси для таблиць [2]. p align="justify"> Сурогатний ключ - це додаткове службове поле, додане до вже наявних інформаційних полях таблиці, єдине призначення якого - служити первинним ключем [4].
Головне достоїнство сурогатного ключа полягає в тому, що він ніколи не змінюється, оскільки не є інформативним полем таблиці (не несе ніякої інформації про описуваному записом об'єкті) [4].
При використанні сурогатних ключів не слід спантеличувати користувача введенням значень, які не несуть для нього ніякої інформації. Вони генеруються автоматично незалежно від користувача [1]. p align="justify"> Введемо сурогатні ключі для сутностей В«ПокупціВ», В«ПрацівникиВ», В«ПостачальникиВ» і В«ТоварВ», крім того, атрибути В«ПІБ покупцяВ» і В«ПІБ співробітникаВ» розділимо на три атрибути (В«прізвищеВ» , В«ім'яВ», В«батьковіВ») кожен і згрупуємо їх у складові альтернативні ключі. Так само альтернативними ключами зробимо атрибути В«назва постачальникаВ» і В«назва гриВ». Альтернативні ключі (AK - Alternative Key) служать для прискорення пошуку по базі даних. br/>В
Малюнок 4.1 - Модель даних на логічному рівні в нотації IDEF1x
4.2 Фізичний рівень моделі даних
Модель даних на фізичному рівні відрізняється від моделі даних на логічному рівні тим, що вона повністю орієнтована на обрану СУБД, тобто на відміну від логічної моделі, в якій не має значення, який конкретно тип даних має атрибут, у фізичній моделі даних важливо описати інформацію про конкретних фізичних об'єктах - таблицях, полях, індексах, процедурах і т.д [2]. Для СУБД PostgreSQL характерно те, що всі об'єкти бази даних, повинні мати англомовне найменування. p align="justify"> У ході проектування фізичного рівня була отримана модель, представлена ​​на малюнку 4.2.
В
Малю...
