ні: 10 таблиця, з яких 5 є довідковими, 5 основними. Усі зв'язки між таблицями - один до багатьох.
Малюнок 2.4 - Даталогіческая модель бази даних
У міру накопичення бази даних може виникнути надмірність і аномалії. Розрізняють аномалії вставки і видалення. Щоб уникнути цього, необхідно схему відносин привести до нормальної форми. Достатньою умовою є приведення схеми відносин до третьої нормальної форми.
Схема відносин знаходиться в 1НФ тоді і тільки тоді, якщо всі атрибути схеми мають атомарну значення і в схемі відносин відсутні повторювані групи. Схема відносин знаходиться у 2НФ, якщо вона знаходиться в 1НФ, і все не ключові атрибути функціонально повно залежать від складеного первинного ключа. Якщо схема відносин у 1НФ і первинний ключ це 1 атрибут, то схема відносин автоматично знаходиться у 2НФ. Схема відносин знаходиться в 3НФ, якщо вона знаходиться у 2НФ, і відсутні транзитивні залежності між не ключова атрибутами. Мінімальною вважається вимоги 3НФ.
При аналізі полученной схеми відносин був зроблений висновок, що отримана схема відносин знаходиться в 3НФ і НФБК.
2.3.4 Фізична модель бази даних
Етап фізичного проектування полягає в ув'язці логічної структури БД та фізичної середовища зберігання з метою найбільш ефективного розміщення даних, тобто відображенні логічної структури БД в структуру зберігання. Вирішується питання розміщення збережених даних в просторі пам'яті, вибору ефективних методів доступу до різних компонентів «фізичної» БД. Фізична модель БД представлена ??на мові опису даних СУБД InterBase. Результати цього етапу документуються у формі схеми зберігання на мові визначення збережених даних. Прийняті на цьому етапі рішення роблять визначальний вплив на продуктивність системи. Розглянемо кожен з класів об'єктів у вигляді таблиць 2.3 - 2.12:
Таблиця 2.3 - Поверх
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.NumberIntegern.n.
Таблиця 2.4 - Приміщення
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.NameString, 50n.n.PloIntegern.n.Id_itazhFKIntegern.n.
Таблиця 2.5 - Датчик
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.NameString, 80n.n.
Таблиця 2.6 - Виробник
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.NameString, 50n.n.
Таблиця 2.7 - Тип датчика
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.NameString, 50n.n.
Таблиця 2.8 - Статус
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.NameString, 50n.n.
Таблиця 2.9 - Список встановлених датчиків
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.Sr_numberString, 10n.n.Data_usDaten.n.Data_spDateId_pomFK1Integern.nId_datchikFK2Integern.nId_statFK3Integern.n
Таблиця 2.10 - Показання
НазваніеКлючТіп, длинаОпциональностьIdPKIntegern.n.VrDaten.n.ZnachIntegern.nId_list_ustFKIntegern.n.
Таблиця 2.11 - Перевірка
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.DataDaten.n.OpisString, 100n.n.Id_list_ustFK1Integern.n.Id_sotrFK2Integern.n.
Таблиця 2.12 - Співробітник
НазваніеКлючТіп, длінаОпціональностьIdPKIntegern.n.fioString, 100n.n.PostString, 50n.n
2.4 Розробка алгоритмів програми
Укрупненная схема алгоритму програми, представлена ??на малюнку 2.5.
Малюнок 2.5- Укрупненная схема алгоритму програмного засобу
2.5 Захист даних
Цілісність і безпеку бази даних розглядається в трьох аспектах:
Цілісність таблиці, має підтримуватися:
- відсутність повторюваних рядків, тобто таблиця повинна містити первинний ключ і він повинен бути визначений (NN);
- підтримка унікальних ключів.
Посилальна цілісність.
Правило: Значення зовнішнього ключа повинно відповідати значенню потенційного ключа зв'язаної таблиці, або значення зовнішнього ключа може бути не визначено.
Організація підтримки посилальної цілісності. Реалізація здійснюється за допомогою завдання обмеження існування певної умови, при якому може вставлятися, оновлюватися або віддалятися кожне значення потенційного або зовнішнього ключа.
Існує 6 способів обмеження існування:
1 Вставка нового рядк...
