ь підтримки цілісності при внесенні змін. У процесі проектування до відносин висувають такі вимоги:
- інформаційний об'єкт повинен містити унікальний ідентифікатор (ключ);
- всі описові реквізити повинні бути взаємонезалежні, тобто між ними не може бути функціональних залежностей;
- всі реквізити, що входять в складений ключ, повинні бути також взаємонезалежні;
- кожен описовий реквізит повинен функціонально повно залежати від ключа, тобто кожному значенню ключа відповідає тільки одне значення описового реквізиту;
- при складеному ключі описові реквізити повинні залежати цілком від всієї сукупності реквізитів, що утворюють ключ;
- кожен описовий реквізит не може залежати від ключа транзитивно, тобто через інший проміжний реквізит.
Виходячи з аналізу опису предметної області, виявлених бізнес-правил, а також правил побудови відносин, виходячи з ER-діаграм була отримана наступна схема бази даних:
. Товари ( код_товара , Найменування, Додаткова інформація)
. Постачальники ( код_поставщіка , Ім'я, код_города, код_товара )
. Міста ( код_города , Ім'я, Додаткова інформація)
. Склади ( код_склада , Адреса, код_города, телефон )
. Зберігається ( код_товара, код_склада , кількість, обмеження )
. Заявки ( код_заявкі
1.4 Обмеження цілісності
При реалізації отриманої схеми слід враховувати, що предметна область накладає деякі обмеження на значення атрибутів. Також слід враховувати, що при реалізації на атрибути будуть накладені обмеження, пов'язані з обраним типом даних. Таблиця 1демонстрірует обмеження цілісності та відповідності типів атрибутам відносин. br/>
Таблиця 1 - Обмеження
ОтношениеАтрибутОписаниеТип атрибутаОграничениеТоварыКод_товараУникальный номер товару, первинний ключЦелое чіслоУнікальное поле, генерується автоматическиНаименованиеУникальное найменування товараСтрока (40 символів) Унікальне поле, обов'язково для заполненияИнформацияДополни...
