1. 4Обґрунтування вибору сховища даних 15



Сторінка6/8
Дата конвертації15.06.2017
Розмір0.54 Mb.
1   2   3   4   5   6   7   8

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


Bootstrap – це фреймворк, що реалізує підхід семплування даних вихідної вибірки для розширення кількості її елементів штучним шляхом генерування ймовірнісних змінних. Найчастіше застосовується тоді, коли необхідно поділити вхідну множину з доволі малим обсягом елементів. Наприклад, необхідно отримати m множин, кожна з яких складається з n елементів, де в розпорядженні лиш n-елементна множина. В результаті потрібно згенерувати ще m-1 множину на основі даної n-мірної. Це відбувається вибором шляхом дискретного рівномірного розподілу n елементів, з яких генерується вибірка з повторенням.

Також слід зазначити, що Bootstrap це набір інструментів від Twitter (відноситься до класу інструментів: CSS-фреймворк), створений для полегшення розробки web застосунків та сайтів. Він включає CSS та HTML для типографії, форм, кнопок, таблиць, сіток, навігації тощо, а також додаткові розширення JavaScript.

Такод пропонується використовувати AngularJS, який представляє собою JavaScript-фреймворк з відкритим програмним кодом, що розробляє Google. Призначений для розробки односторінкових застосунків, що складаються з одної HTML сторінки з CSS і JavaScript. Його мета — розширення браузерних застосунків на основі шаблону Модель-вид-контролер (MVC), а також спрощення їх тестування та розробки.

Фреймворк працює зі сторінкою HTML, що містить додаткові атрибути і пов'язує області вводу або виводу сторінки з моделлю, яка являє собою звичайні змінні JavaScript. Значення цих змінних задаються вручну або отримуються зі статичних або динамічних JSON-даних.

Використання підходу модель-вид-контролер (MVC) суттєво розширює функціонування та гнучкість проекту, так як використовується під час проектування та розробки програмного забезпечення.

Цей шаблон поділяє систему на три частини: модель даних, вигляд даних та керування. Застосовується для відокремлення даних (модель) від інтерфейсу користувача (вигляду) так, щоб зміни інтерфейсу користувача мінімально впливали на роботу з даними, а зміни в моделі даних могли здійснюватися без змін інтерфейсу користувача.

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

Архітектурний шаблон Модель-Вид-Контролер (MVC) поділяє програму на три частини. У тріаді до обов'язків компоненту Модель (Model) входить зберігання даних і забезпечення інтерфейсу до них. Вигляд (View) відповідальний за представлення цих даних користувачеві. Контролер (Controller) керує компонентами, отримує сигнали у вигляді реакції на дії користувача, і повідомляє про зміни компоненту Модель. Така внутрішня структура в цілому поділяє систему на самостійні частини і розподіляє відповідальність між різними компонентами.



https://upload.wikimedia.org/wikipedia/commons/0/09/mvp_1_2.jpg

Рисунок 2.3.1.1 - Загальна структура MVC

MVC поділяє цю частину системи на три самостійні частини: введення даних, компонент обробки даних і виведення інформації. Модель, як вже було відмічено, інкапсулює ядро даних і основний функціонал з їх обробки. Також компонент Модель не залежить від процесу введення або виведення даних. Компонент виводу Вигляд може мати декілька взаємопов'язаних областей, наприклад, різні таблиці і поля форм, в яких відображається інформація. У функції Контролера входить моніторинг за подіями, що виникають в результаті дій користувача (зміна положення курсора миші, натиснення кнопки або введення даних в текстове поле).

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


2.4Розробка структури бази даних


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

До основного функціоналу веб ресурсу можна віднести:

реєстр перевізників та замовників;

розділення прав доступу

населені пункти відправлення та призначення

відомості про автомобілі

особливості вантажу

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

Відповідно до вище описаних зауважень, щодо розробки бази даних пропонується створити наступу структуру таблиць.

користувачі;

ролі

права доступу



оголошення

автомобілі

міста

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



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

[Id] [nvarchar](128) NOT NULL,

[AccountType] [int] NOT NULL,

[Email] [nvarchar](256) NULL,

[EmailConfirmed] [bit] NOT NULL,

[PasswordHash] [nvarchar](max) NULL,

[SecurityStamp] [nvarchar](max) NULL,

[PhoneNumber] [nvarchar](max) NULL,

[PhoneNumberConfirmed] [bit] NOT NULL,

[TwoFactorEnabled] [bit] NOT NULL,

[LockoutEndDateUtc] [datetime] NULL,

[LockoutEnabled] [bit] NOT NULL,

[AccessFailedCount] [int] NOT NULL,

[UserName] [nvarchar](256) NOT NULL.

Відповідно до постановленої задачі також необхідно створити таблицю для розподілення доступу між користувачами.

[Id] [nvarchar](128) NOT NULL,

[Name] [nvarchar](256) NOT NULL,

Також необхідно створити таблицю, я ка буде пов’язувати ролі користувачів з самим користувачами, така таблиця на практиці реалізує зв'язок типу n-n.

[UserId] [nvarchar](128) NOT NULL,

[RoleId] [nvarchar](128) NOT NULL,

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

[BookingId] [int] IDENTITY(1,1) NOT NULL,

[Weight] [int] NOT NULL,

[Size] [int] NOT NULL,

[CityFromId] [int] NOT NULL,

[CityToId] [int] NOT NULL,

[AccountId] [nvarchar](128) NOT NULL,

[CustomerName] [nvarchar](max) NULL,

Останнім етапом опису бази даних є створення таблиць що дозволяють зберігати інформацію про запити на перевезення вантажу.

[DeliveryId] [int] IDENTITY(1,1) NOT NULL,

[CarInfo] [nvarchar](max) NULL,

[Weight] [int] NOT NULL,

[Size] [int] NOT NULL,

[CityId] [int] NOT NULL,

[PriceKm] [decimal](18, 2) NOT NULL,

[AccountId] [nvarchar](128) NOT NULL,

[DriverName] [nvarchar](max) NULL,

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

Для кожного бінарного зв’язку отримуються попередні відношення за такими правилами:

1) Якщо ступінь бінарного зв’язку дорівнює 1:1 і клас належності обох сутностей є обов’язковим, то потрібно лише одне відношення, первинним ключем якого може бути ключ будь-якого з двох відношень.

2) Якщо ступінь бінарного зв’язку дорівнює 1:1 і клас належності однієї сутності є обов’язковим («О»), а другої не обов’язковим («НО»), то необхідно побудувати два відношення. На кожну сутність потрібно виділити одне відношення, при цьому ключ сутності повинен слугувати первинним ключем для відповідного відношення. Крім того ключ сутності, для якої клас належності є «НО», додається в якості атрибуту у відношення, що виділене для сутності з обов’язковим класом належності.

3) Якщо ступінь бінарного зв’язку дорівнює 1:1 і клас належності обох сутностей є «НО», то необхідно використовувати три відношення, по одному для кожної сутності, ключі яких слугуватимуть в якості первинних у відповідних відношеннях та одного відношення для зв’язку серед своїх атрибутів. Відношення, що виділяється для зв’язку буде мати по одному ключу сутності від кожної сутності.

4) Якщо ступінь бінарного зв’язку дорівнює 1:N та клас належності однозв`язної сутності є «О», то достатнім є використання двох відношень по одному на кожну сутність за умови, що ключ кожної сутності слугує в якості первинного ключа для відповідного відношення. Додатково ключ N- зв'язної сутності повинен бути добавлений, як атрибут у відношення, що відводиться для однозв`язної сутності.

5) Якщо ступінь бінарного зв’язку дорівнює 1:N та клас належності однозв`язної сутності є «НО», то необхідно формувати три відношення: по одному для кожної сутності, при чому ключ кожної сутності слугує первинним ключем відповідної сутності та одного відношення для зв’язку. Зв'язок повинен мати серед своїх атрибутів ключ сутності кожної з сутностей.

6) Якщо ступінь бінарного зв’язку дорівнює N:N, то для зберігання даних необхідно три відношення: по одному для кожної сутності, використовуючи в якості первинного ключа ключ відповідного відношення та одного відношення для зв'язку. Останнє повинно серед числа своїх атрибутів мати ключ кожної сутності.

Визначення ступеню зв`язку та класу належності сутностей «Bookings» та «Cities» (рис. 2.1).

Bookings належить Cities

_ Bookings > _ Cities>
1 1

2

3 2

«N, НО» «1, НО»

Рисунок 2.1 – Аналіз зв’язку сутностей «Bookings» та «Cities»

Отже, ступінь зв’язку між сутностями N:1, клас належності «НО»:«НО».

За правилом 5 : якщо ступінь бінарного зв’язку дорівнює 1:N та клас належності однозв`язної сутності є «НО», то необхідно формувати три відношення: по одному для кожної сутності, при чому ключ кожної сутності слугує первинним ключем відповідної сутності та одного відношення для зв’язку. Зв'язок повинен мати серед своїх атрибутів ключ сутності кожної з сутностей.

Отже, отримаємо такі відношення:


  • Bookings ();

  • Cities ().

Визначення ступеню зв`язку та класу належності сутностей «Bookings» та «Deliveries» (рис. 2.2).

Bookings відноситься Deliveries



_ Bookings > _ Deliveries>

1 1

2

3 2

«N, НО» «1, О»

Рисунок 2.2 – Аналіз зв’язку сутностей «Bookings» та «Deliveries»

Отже, ступінь зв’язку між сутностями N:1, клас належності «НО»:«О».

За правилом 5 : якщо ступінь бінарного зв’язку дорівнює 1:N та клас належності однозв`язної сутності є «НО», то необхідно формувати три відношення: по одному для кожної сутності, при чому ключ кожної сутності слугує первинним ключем відповідної сутності та одного відношення для зв’язку. Зв'язок повинен мати серед своїх атрибутів ключ сутності кожної з сутностей.

Отже, отримаємо такі відношення:


  • Bookings ();

  • Deliveries ().

Визначення ступеню зв`язку та класу належності сутностей «Bookings» та «Deliveries» (рис. 2.3).

Deliveries обслуговує Cities



_ Deliveries > _ Cities >

1 1

2

2 3

«1, НО» «N, О»

Рисунок 2.3 – Аналіз зв’язку сутностей «Deliveries» та «Cities»

Отже, ступінь зв’язку між сутностями N: N, клас належності «НО»:«О».

За правилом : 6 якщо ступінь бінарного зв’язку дорівнює N:N, то для зберігання даних необхідно три відношення: по одному для кожної сутності, використовуючи в якості первинного ключа ключ відповідного відношення та одного відношення для зв'язку. Останнє повинно серед числа своїх атрибутів мати ключ кожної сутності.

Визначення ступеню зв`язку та класу належності сутностей «Deliveries» та «Cities» (рис. 2.4).

AspNetRoles реєструє Deliveries



_ AspNetRoles > _ Deliveries >

1 1

2

3 2

«N, О» «1, О»

Рисунок 2.4 – Аналіз зв’язку сутностей «AspNetRoles» та «Deliveries»

Отже, ступінь зв’язку між сутностями N: 1, клас належності «О»:«О».

За правилом : 4 Якщо ступінь бінарного зв’язку дорівнює 1:N та клас належності однозв`язної сутності є «О», то достатнім є використання двох відношень по одному на кожну сутність за умови, що ключ кожної сутності слугує в якості первинного ключа для відповідного відношення. Додатково ключ N- зв'язної сутності повинен бути добавлений, як атрибут у відношення, що відводиться для однозв`язної сутності.

Отже, ступінь зв’язку між сутностями N: 1, клас належності «О»:«НО».

За правилом : 4 Якщо ступінь бінарного зв’язку дорівнює 1:N та клас належності однозв`язної сутності є «О», то достатнім є використання двох відношень по одному на кожну сутність за умови, що ключ кожної сутності слугує в якості первинного ключа для відповідного відношення. Додатково ключ N- зв'язної сутності повинен бути добавлений, як атрибут у відношення, що відводиться для однозв`язної сутності.




Поділіться з Вашими друзьями:
1   2   3   4   5   6   7   8


База даних захищена авторським правом ©divovo.in.ua 2017
звернутися до адміністрації

войти | регистрация
    Головна сторінка


загрузить материал