лієнти: дає опис всіх клієнтів даної фірми.
У таблиці вказується ПІБ, адреса і телефон клієнта.
Таблиця Замовлення: складається з чотирьох полів:
Код замовлення - код поточного замовлення (тип поля - лічильник)
Фірма - замовники (представники фірм). Дані беруться з таблиці Клієнти.
Дата замовлення - дата надходження замовлення, дане поле заповнюється автоматично.
Виконано - Так/Ні. Якщо в цьому полі стоїть «галочка», то дане замовлення вже виконано (значення true).
Таблиця Заказанние_товари: містить три поля:
Номер - код замовлення.
КодТовара - код даного товару. Береться з таблиці Товар і вводиться автоматично.
Кількість - кількість замовленого товару, який не повинен перевищувати кількість товарів даного типу в таблиці Товар.
Таблиця Виконані замовлення: містить шість полів, заповнюється за допомогою запиту і дає інформацію про виконані товари.
Код - код виконаного замовлення
Фірма - назва фірми-замовника.
Дата замовлення - дата надходження замовлення.
Дата виконання - дата виконання замовлення.
Кількість - загальна кількість замовлених товарів будь-якого типу.
Сума замовлення - вартість усіх товарів в замовленні.
. 2 Нормалізація
Нормалізація - процес зменшення надмірності інформації в таблицях реляційної БД і, як наслідок, побудови оптимальної структури таблиць і зв'язків.
Можна виділити 4 основних правила, якими слід керуватися при проектуванні і подальшої нормалізації таблиць бази даних:
1. Кожне поле будь-якої таблиці повинно бути унікальним.
2. Кожна таблиця повинна мати унікальний первинний ключ, який може складатися з одного або декількох полів таблиці.
. Для кожного значення первинного ключа має бути одне і тільки одне значення будь-якого з шпальт даних, і це значення має ставитися до об'єкта таблиці.
. Повинна бути можливість змінювати значення будь-якого поля (що не входить в первинний ключ), і це не повинно спричинити за собою зміну іншого поля.
Створена мною таблиця задовольняє вищевикладеним вимогам:
1 НФ (Нормальна Форма):
Назва табліциКлючевое полеТовар Проізводітель_товара Опісаніе_товара Клієнти Замовлення Заказанние_товари Виконані заказиНомер, Виробник, Характеристика Виробник Тип Фірма Код замовлення Id Код замовлення
НФ:
виконуються обмеження 1НФ, і кожен не ключовий атрибут функціонально повно залежить від складеного первинного ключа.
НФ:
всі неключові атрибути відносини взаємно незалежні і повністю залежать від первинного ключа.
Таким чином, база даних задовольняє всім вимогам нормалізації таблиць і Третя нормальна форма - остаточний результат нормалізації моєї Бази даних.
. 3 Схема даних
Відносини - це правила, підтримувані на рівні механізму реалізації СУБД. Розрізняють три типи відносин:
Ставлення «один-до-одного»: для кожного рядка в одній таблиці існує не більше одного рядка зв'язаної таблиці.
Ставлення «один-до-багатьох»: одна таблиця не містить взагалі або має набір пов'язаних «дочірніх» записів з іншої таблиці.
Ставлення «багато-до-багатьох»: для кожного рядка першої таблиці може існувати набір рядків в іншій таблиці і навпаки. Такий зв'язок організовується, як правило, за допомогою третьої, сполучною таблиці, яка містить значення первинних ключів обох таблиць в якості зовнішніх ключів.
При розробці БД необхідно брати до уваги правила забезпечення цілісності даних (забезпечує каскадне оновлення
записів у зв'язаних таблицях)
У моїй схемі даних таблиці пов'язані наступним чином. При додаванні нового товару, продавець вибирає тип (товару), який за допомогою майстра підстановки береться з таблиці Опісаніе_товара.
Також продавець вибирає виробника (з табл...
