Материал: Мизніков Діплом Бакалавр

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

Firebird (FirebirdSQL) – компактна, кросплатформна, вільна система управління базами даних (СКБД), що працює на GNU / Linux, Microsoft Windows і різноманітних Unix платформах.

Переваги Firebird:

• багатоверсійності архітектура;

• компактність (дистрибутив 5Mb);

• висока ефективність;

• потужна мовна підтримка для збережених процедур і тригерів.

Недоліки:

• відсутність кеша результатів запитів;

• відсутність індексів fulltext для повнотекстового пошуку.

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

MySQL – це найпоширеніша повноцінна серверна СУБД. MySQL дуже функціональна, що вільно розповсюджується СУБД, яка успішно працює з різними сайтами і веб додатками. Навчитися використанню цієї СУБД досить просто, так як на просторах інтернету ви легко знайдете більшу кількість інформації [25].

Незважаючи на те, що в ній не реалізований весь SQL функціонал, MySQL пропонує досить багато інструментів для розробки додатків.

Переваги MySQL:

• простота в роботі;

• великий функціонал;

• безпека;

• масштабованість;

• швидкість.

PostgreSQL – найбільш продвинута СУБД.

PostgreSQL – це потужна об'єктно-реляційна система управління базами даних з відкритими вихідними текстами. Вона розробляється протягом більше 15 років і покращує архітектуру, завоювала репутацію надійної, інтегрованої і масштабованої СУБД [26].

Будучи СУБД класу підприємства, PostgreSQL надає такі особливості як Multi-Version Concurrency Control (MVCC).

Перерахуємо їх:

• відновлення по точці в часі;

• табличний простір;

• асинхронна реплікація;

• вкладені транзакції (точки збереження);

• гаряче резервування;

• планувальник / оптимізатор запитів;

• випереджаюче журнал на випадок поломки.

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

Є діючі PostgreSQL системи, які управляють більш ніж 4 терабайт даних. Реалізація SQL в PostgreSQL відповідає ANSI-SQL 92/99 стандартам. Підтримує майже всі конструкції SQL. Він має повну підтримку вкладених запитів (включаючи вибір з FROM), рівень читання тільки зафіксованих даних і транзакції.

PostgreSQL може виконувати збережені процедури, написані на різних мовах програмування, що було важливим при виборі даної СУБД.

Так само PostgreSQL має дуже велику кількість типів даних, що спрощує роботу з нею.

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

З огляду на широку поширеність, потужність і доступність, була обрана СУБД PostgreSQL.

3. Вибір архітектури системи

Архітектура програмного забезпечення – спосіб структурування програмної системи, тобто розділ системи на абстракції [27]. Залежно від потреб і технологій існують різні типи «Model-View-Controller (MVC)», «Сервіс-орієнтована архітектура (SOA)», «Трирівнева архітектура (Multitier architecture)», «Клієнт-серверна архітектура» [31]. Для розроблюваної програмної системи оптимальною є клієнт-серверна архітектура, схема якої зображена на рис. 3.2.

Рисунок 3.2 – Схема клієнт-серверної архітектури

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

4. Логічне та фізичне моделювання бази даних системи

Логічне та фізичне моделювання бази даних автоматизованої системи проводилося з використанням CASE-засобу «Allfusion ErWin Data Modeler». Даний засіб дозволяє змоделювати логічну і фізичну моделі даних системи, що б визначити набір сутностей, які беруть участь в роботі системи, і визначити структуру сховища даних [28].

Методика створення моделі реляційної бази даних з використанням CASE-засобу «Allfusion Erwin Data Modeler» складається з наступних етапів: складання логічної моделі даних, потім, на її основі, фізичної моделі даних.

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

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

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

Логічна модель бази даних інформаційної системи наведена на рис. 3.3.

Рис. 3.3 – Логічна модель бази даних системи

Сутності предметної області, які увійшли у модель, зображені в таблиці 3.1

Таблиця 3.1 – Сутності логічної моделі БД

На рисунку 3.4 приведена фізична модель бази даних

Рис. 3.4 – Фізична модель бази даних

Створення БД (серверної частини) системи здійснювалося за допомогою CASE-засобу Allfusion Erwin Data Modeler [30].

Сутність Users необхідна для збереження усіх даних про користувача, а також для прив’язки до нього аккаунтів із соціальних мереже таких як Twitter, Facebook.

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

Сутність Active_Storage_Blob необхідна для збереження всіх ресурсів оголошення на сторонньому сервісі Amazon Web Services (AWS) [33]. Таким чином, система зможе зберігати об’єкти типу Blob на сторонньому ресурсі та зменшити навантаження на основний сервер.

Сустності Favorite_template, Template_tag, Template_keyword, Tag та Keyword націлені на спрощення пошуку макету для оголошення, а також для SEO оптимізації сайту, що збільшує можливість потрапляння нових користувачів на сайт, за рахунок релевантних пошукових запитів.

Сутність Institution націлена на збереження інформації про існуючі установи, навчальні заклади, спортивні гуртки тощо.

Сутність Preset націлена на збереження інформації про попередні установки оголошення, які вносив користувач.

Сутність PictureBase64 націлення на збереження необхідних користувачеві ресурсів.

Сутність Folder націлена на створення стуктуризації ресурсів користувача, необхідних для створення оголошення.

4. Розробка алгоритму роботи системи

На рисунку 3.5 показаний алгоритм роботи функції створення оголошення.

Рис. 3.5 – Алгоритм системи для створення оголошення про спортивну подію

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

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

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

5. Розробка інтерфейсу клієнтської частини

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

Рис. 3.6 – Форма реєстрації користувача

Користувачеві, для того щоб зареєструватися необхідно ввести про себе наступні дані:

• електронна адреса;

• ім’я;

• фамілія;

• назва установи, в якій користувач працює чи навчається;

• пароль;

• підтвердження паролю;

Всі поля є обов’язковими для заповнення. Дана форма зв’язана із сутністю Users.

Після реєстрації у користувача з’являється можливість скористатися авторизацією. На рисунку 3.7 зображена форма авторизації.

Рис. 3.7 – Форма авторизації

Користувач, який має зареєстрований аккаунт може зайти у систему та попасти на головну сторінку веб сайту. Якщо користувач забув пароль, він може його відновити з допомогою кнопти «Forgot Password?». Для максимальної зручності, на головній сторінці можна знайти макети оголошень.

Лістинг 3.1 – Написання форми для авторизації користувача

<div class="registration_page registration_page--login_page">

<div class="registration_page--logo_container">

<img class="registration_page--logo_container--image" src="/assets/gipperLogo.svg">

</div>

<div class="registration_page--wrapper">

<div class="registration_page--wrapper--header">