Даталогічна проста мережна модель даних.

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

Відношення мають такий вигляд:

ТЕНДЕРНИЙ КОМІТЕТ (Номер тендеру, Адреса ТК, Назва ТК, Розрахунковий рахунок, Голова ТК, Склад ТК);

ТОВАР (Код товару, Найменування товару, Найменування товарів (родовий відмінок));

ЗАМОВЛЕННЯ (Номер протоколу, Номер тендеру, Дата проведення тендеру, Дата відправки замовлень, Дата первісного засідання, Дата звіту, Код товару, Сума очікуваної закупівлі, Очікувана сума прописом, Кількість товару);

ПРОПОЗИЦІЯ (Номер пропозиції, Номер протоколу, Код постачальника, Дата реєстрації пропозиції, Сума тендерної пропозиції, Сума пропозиції прописом, Код примітки, Переможець);

ПРИМІТКИ (Код примітки, Примітки);

ПОСТАЧАЛЬНИК (Код постачальника, Тип постачальника, Найменування постачальника, Розрахунковий рахунок, Телефон, Вулиця будинок, Місто, Індекс, ОКПО, Посада керівника, ПІБ керівника, E-mail);

Рисунок 5.1 - Даталогічна проста мережна модель даних

У прийнятих у словнику даних позначеннях зазначені відношення мають такий вигляд:

ТЕНДЕРНИЙКОМІТЕТ (№тендеру, Адреса, НазваТК, Розрахрах, Голова, Склад ТК);

ТОВАР (КодТовару, НаймТовару, РодВід);

ЗАМОВЛЕННЯ (№Протоколу, №тенгдеру, ДатаПровТендеру, ДатаВідпрЗам, ДатаПротФорми, ДатаЗвіту, КодТовару, ОчікСумаЗакуп, сума проп, Кількість Товару);

ПРОПОЗИЦІЯ (№Пропозиції, №Протоколу, КодПостач, ДатаРеєстрПроп, СумаТендПроп, СумаТендПропТекст, кодПримітки, Переможець);

ПРИМІТКА (КодПримітки, Примітки);

ПОСТАЧАЛЬНИК (КодПостач, ТипПідпр, НаймПост, РозрахРахПост, ТелефонПост, Вулиця,Будинок, Місто, Індекс, ОКПО, ПосадаКерівника, ПІБ_Керівника, E-mail);

Нормалізація даних

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

Відношення „Тендерний комітет” (ТендернийКомітет) має первинний ключ „Номер тендеру” (№тендеру) й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: "Назва ТК", "Адреса ТК". Обидві ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв'язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення "Товар" (Товар) має первинний ключ "Код товару" (КодТовару) й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: „Найменування товару”, „Найменування товарів (родовий відмінок)”. Обидві ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв'язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення "Замовлення" (Замовлення) має первинний ключ „Номер протоколу” (№Протоколу) й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: „Дата проведення тендеру”, „Дата відправки замовлень”, „Дата первісного засідання”, „Дата звіту”. Всі ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв'язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення "Пропозиція" (Пропозиція) має первинний ключ „Номер пропозиції” (№Пропозиції) й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: „Дата реєстрації пропозиції”, „Переможець”. Всі ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв'язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення "Примітка" (Примітка) має первинний ключ „Код примітки” (КодПримітки) й описовий атрибут, який функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано атрибуту: „Примітки”. Ця ключова детермінанта є можливим ключем, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв'язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.

Відношення "Постачальник" (Постачальник) має первинний ключ „Код постачальника” (№КодПостач) й описові атрибути, які функціонально повно і нетранзитивно залежать від ключа. Тому це відношення знаходиться у третій нормальній формі. Другу ключову детермінанту репрезентовано сукупністю атрибутів: „Тип постачальника”, „Найменування постачальника”, „Розрахунковий рахунок”, „Телефон”, „Вулиця будинок”, „Місто”, „Індекс”, „ОКПО”, „Посада керівника”, „ПІБ керівника”, „E-mail”. Всі ключові детермінанти є можливими ключами, інші ключові детермінанти відсутні; тому відношення знаходиться у третій посиленій нормальній формі. Множинні зв'язки між атрибутами відсутні. Відношення є таким, що не зводиться, і вільним від аномалій включення, вилучення та коректування даних.