Основні рішення щодо реалізації компонентів системи

Для розробки даного програмного продукту використано реляційну модель.

У реляційній моделі дані розбиваються на набори, які становлять табличну структуру. Ця структура таблиць складається з індивідуальних елементів даних, називаних полями. Одиночний набір або група полів відома як запис.

Базу даних розроблено в форматі 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 - модуль, який вміщує код редагування таблиці БД «Договора»;

–  sobstvenik.php - модуль, в якому описана логіка роботи із таблицею БД «Собственники»;

–  sobstvenik_editor.php - модуль, який вміщує код редагування таблиці БД «Собственники»;

–  spr_zem_uch.php - довідник про земельні ділянки;

–  zem_uch.php - зберігає інформацію про земельні ділянки;

–  zem_uch_editor.php - модуль, який вміщує код редагування таблиці БД «Земельные участки».

Текст програми «Створення автоматизованої системи введення реєстру власників землі» надано в додатку А.

Художнє проектування необхідно для забезпечення необхідних споживчих властивостей системи. Метою художнього проектування є відображення властивостей емоційно-мотиваційної сфери людини, створення у нього певного естетичного ставлення до проектованої системі. Ергономічність є важливою складовою якості програмного продукту.

При розробці користувальницького інтерфейсу автоматизованої системи приділялася увага вимогам ергономіки і питань художнього сприйняття програмного продукту.

Система забезпечена різними поясненнями та повідомленнями користувачеві.

При спробі введення даних неприпустимого формату система їх не сприйме. Після цього користувачеві буде надана можливість знову ввести інформацію. При виконанні багатьох дій користувача система запитує їх підтвердження, виключаючи таким чином помилки. Вищевикладені чинники значно полегшують роботу користувача, підвищуючи тим самим продуктивність його праці.