ндівідуальніх елементів даних, називаних полями. Одиночний набор або група полів відома як запис.
Базу даних розроблено в форматі MySQL. Вміщує Чотири табліці.
Розглянемо табліці «Category», «Dogovor», «Sobstvenik», «Zem_uch».
Сутність табліці «Category» (id, name, status). Сутність призначе для Збереження информации про категоріях землі. У реализации бази даних Сутність представлено таблицею Category.
Таблиця 3.1. Структура табліці Category
Сутність табліці «Dogovor» (id, id_zem, id_sobstv, date, status). Сутність призначе для Збереження информации про договори.
У реализации бази даних Сутність представлено таблицею Dogovor.
Таблиця 3.2. Структура табліці Dogovor
Сутність табліці «Sobstvenik» (id, fio, passport, indnomer, date, propiska, status). Сутність призначе для Збереження информации про ВЛАСНИК. У реализации бази даних Сутність представлено таблицею Sobstvenik.
Таблиця 3.3. Структура табліці Sobstvenik
Сутність табліці «Zem_uch» (id, name, place, kad_nomer, square, id_kat, status). Сутність призначе для зберігання информации про земельних ділянках. У реализации бази даних Сутність представлено таблицею Zem_uch.
Таблиця 3.4. Структура табліці Zem_uch
У реляційній моделі дані розбіваються на набори, Які становляит табличнійструктури. Ця структура таблиць складається з індівідуальніх елементів даних, називаних полями. Одиночний набор або група полів відома як запис.
Коженая рядок, что містіть дані, назівається кортежем, КОЖЕН стовпець отношения назівається атрибутом (на Рівні практичної роботи Із сучасности реляційнімі БД вікорістаються Терміни «запис» ї «поле»).
Елементами Опису реляційної моделі даних на концептуальному Рівні є сутності, атрибути, домени ї зв'язки.
Сутність - Деяк відособленій об'єкт або подію, інформацію про Пожалуйста необходимо зберігаті в базі даних, что має Певний набор властівостей - атрібутів.
Домен - це набор всех Припустиме значення, Які может містіті атрибут.
Зв'язки - на концептуальному Рівні являються собою Прості асоціації между сутности.
Реляційна БД на фізічному Рівні складається з таблиць, между Якими могут існуваті зв'язку за ключовими значеннями.
Правило відповідності ЗОВНІШНІХ ключів Первін - основне правило Дотримання умів посілальної цілісності. Для шкірного значення зовнішнього ключа повинною існуваті відповідне значення первинного ключа в батьківській табліці [4].
Даній програмний продукт складається з фізичної моделі програми та Загальної Структури програми.
Автоматизована система є клієнт-серверних додатком, в якому Клієнтом Виступає браузер, а сервером - веб-сервер. Логіка веб-додатка розподілена между сервером и Клієнтом, зберігання даних здійснюється, в основном, на сервері, обмін інформацією відбувається по мережі. Одним з Перевага такого підходу є тією факт, что Клієнти НЕ залежався від конкретної операційної системи користувача, тому веб-Додатки є міжплатформовімі сервісамі.
Клієнт-сервер - обчислювальна або мережева архітектура, в Якій Завдання або мережева НАВАНТАЖЕННЯ розподілені между постачальником услуг (сервісів), звання серверами, и замовниками услуг, звання клієнтами. Нерідко Клієнти и сервери взаємодіють через комп'ютерну ятір и могут буті як різнімі фізічнімі прилаштувати, так и програмне забезпечення [7].
Аналіз и дослідження програмного продукту проводівся на різніх етапах, а самє:
технічне проектування;
художнє проектування.
Технічне проектування Полягає в машінній розробці системи. На цьом етапі в проекті, створеня помощью мови програмування РНР5 реалізовано каталоги: сlasse, db, libs. Та файли: category.php, category_editor.php, dogovor.php, dogovor_editor.php, sobstvenik.php, sobstvenik_editor.php, spr_zem_uch.php, spr_zem_uch.php, use.php, zem_uch.php, zem_uch_editor.php.
Більш детальний опис файлів представлено нижчих:
category.php - модуль, в якому описана логіка роботи Із таблиці БД «Категорія»;
category_editor.php - модуль, Який вміщує код редагування табліці БД «Категорія»;
dogovor.php - модуль, в якому описана логіка роботи Із таблиці БД «Договору»;
dogovor_editor.php - модуль, Який вміщує код редагування табліці БД «Договору»;
sobstven...
