Київський національний університет імені Тараса Шевченка

Звіт
до лабораторного практикуму

"Фрагментарна реалізація систем управління табличними базами

даних"

з курсу «Інформаційні технології»

Виконали студенти 4-го курсу

групи ТТП-41

Беденко Аліна

Бурлака Владислав

Дволінська Вікторія

Прохорчук Дмитро

Київ-2023
 Зміст

Постановка задачі 3
Етап 3. Клієнт-серверна версія СУБД 3
Етап 4. Web-service версія СУБД 6
Етап 5. REST 7
Етап 6. GraphQL APІ 11
Етап 7. gRPC 14
Етап 8. Вибірковий блок 17
 Постановка задачі

Етап 3. Клієнт-серверна версія СУБД

Система сервера баз даних, побудована на технології

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

Реалізація сервера:

1. Завантаження чи створення бази даних.

Використовуючи бібліотеку System.IO.Abstractions, сервер
перевіряє наявність файлу бази даних за певним шляхом.
Якщо файл існує, база даних завантажується; в іншому
випадку, створюється нова база даних.

2. Створення та реєстрація сервісу.

Створюється об'єкт DbService, який надає функціональність
для взаємодії з базою даних. Цей сервіс реєструється в
роутері (DefaultTargetSelector), що визначає спосіб обробки
запитів на сервері.

3. Створення та запуск сервера.

Створюється обробник запитів (engine) на основі роутера.
Після чого створюється серверний хост через іменовані
канали (NamedPipeHost), який слухає на іменованому каналі
"DbPipe". Сервер виводить повідомлення про успішний
запуск та очікує команди користувача для виходу.
 Реалізація клієнта:

1. Підключення до сервера через транспорт.

Клієнтська сторона створює об'єкт
NamedPipeClientTransport з ідентифікатором каналу
"DbPipe" для забезпечення з'єднання з сервером через
іменовані канали.

2. Створення проксі-об'єкта для викликів на сервері.

Створюється проксі-об'єкт для інтерфейсу IDbService. Цей
проксі використовує транспорт для взаємодії з сервером, а
саме для виклику методів, доступних на сервері.

3. Виклик методів сервера та обробка результатів.

Клієнт викликає метод GetTables на сервері через проксі та
обробляє отримані дані. Це дозволяє клієнтській стороні
отримувати та використовувати інформацію, надану
сервером.
Етап 4. Web-service версія СУБД

Постановка задачі: Реалізація СУБД на основі

сервіс-орієнтованої технології (сервер і клієнт), у т.ч. SOAP-,
SOAP/WSDL-, SOAP/XML-сервіси, веб-сервісів.

Реалізація: Вебсервіс реалізовано з використанням

EntityFramework.
<?xml version="1.0" encoding="utf-8"?>

<packages>

<package id="EntityFramework" version="6.2.0"

targetFramework="net472" />

<package
id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform"
version="2.0.1" targetFramework="net472" />

</packages>

Конфігураційний файл для налаштування:

using System.Reflection;

using System.Runtime.CompilerServices;

using System.Runtime.InteropServices;

[assembly: AssemblyTitle("WSDB")]

[assembly: AssemblyDescription("")]

[assembly: AssemblyConfiguration("")]

[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("WSDB")]

[assembly: AssemblyCopyright("Copyright © 2021")]

[assembly: AssemblyTrademark("")]

[assembly: AssemblyCulture("")]

[assembly: ComVisible(false)]

[assembly: Guid("c22165c8-c3bc-40fc-b2c5-cdc78d6d4cc7")]

[assembly: AssemblyVersion("1.0.0.0")]

[assembly: AssemblyFileVersion("1.0.0.0")]

Деталі сервісу:

До методу ObtenerLibros застосований атрибут [WebMethod], що

дозволяє йому бути доступним як операції веб-сервісу.

Усередині методу створюється новий екземпляр LibrosDBEntities

для взаємодії з базою даних.

Використовується LINQ для отримання всіх записів з таблиці

Libros, після чого результат перетворюється в список перед
поверненням.
 Етап 5. REST

Постановка задачі включає в себе:

● Реалізація операцій над даними, орієнтуючись на їх ієрархічну

структуру: база -> таблиця -> … та на використання HTTP-запитів (як
мінімум GET, POST та DELETE). Потрібно розробити REST API сервер та
продемонструвати його роботу на відповідних тестових HTTP-запитах
(Postman, cURL тощо)

● Реалізація на вибір:

- REST web-сервіси + HATEOAS.

- REST web-сервіси. Розробка OpenAPI Specification для

взаємодії з ієрархічними даними (база, таблиця, ...).

- REST web-сервіси. Реалізація серверного проєкту,

використовуючи кодогенерацію стабу за OpenAPI Specification.

- REST web-сервіси. Реалізація клієнтського проєкту за OpenAPI

Specification

Теорія

REST API (Representational State Transfer Application Programming

Interface) - це архітектурний стиль розробки мережевих програм, який
використовує HTTP протокол для взаємодії між системами. REST
використовує стандартні HTTP-методи, такі як GET, POST, PUT, DELETE
для взаємодії з ресурсами, представленими у вигляді URL.

У C# REST API можна реалізувати використовуючи ASP.NET Core,

яка надає вбудовані можливості для створення веб-служб. ASP.NET Core
використовує контролери для обробки запитів, а дані зазвичай
передаються у форматі JSON.
 Для реалізації REST API важливо визначити моделі даних і створити
контролери, які будуть обробляти HTTP запити та відповідати на них.
Інтеграція з базою даних часто здійснюється через Entity Framework, який
дозволяє працювати з даними на високому рівні абстракції.

Основні Компоненти

- Entity Framework: Використовується для взаємодії з базою

даних. Entity Framework дозволяє працювати з даними у вигляді об'єктів та
сутностей, не звертаючись безпосередньо до SQL-запитів.

- Міграції: Використовуються для управління змінами в

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

- Репозиторії (Repositories): Репозиторії в MusicWebAPI

відповідають за взаємодію з контекстом Entity Framework. Це ізолює логіку
доступу до даних від бізнес-логіки контролерів.

- AutoMapper: Використовується для мапінгу даних між DTO

(Data Transfer Objects) та моделями домену. Це дозволяє автоматизувати
процес перетворення об'єктів одного типу в інший.

- DTOs (Data Transfer Objects): Використовуються для передачі

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

1. Моделі та Контекст Даних

Створюємо моделі даних (наприклад, Artist, Song), які

представлятимуть структуру наших даних.

Використовуємо Entity Framework для створення контексту даних,

який забезпечує з'єднання між нашими моделями та базою даних.

2. Контролери

Створюємо контролери (наприклад, ArtistsController,

SongsController), які наслідуються від класу ControllerBase.

Кожен контролер містить методи для обробки HTTP запитів (GET,

POST, PUT, DELETE), які взаємодіють з репозиторіями для доступу до
даних.

3. Репозиторії

Створюємо репозиторії (наприклад, ArtistRepository,

SongRepository), які відповідають за взаємодію з базою даних через Entity
Framework.
 Репозиторії ізолюють логіку доступу до даних від бізнес-логіки, що
реалізована в контролерах.

4. AutoMapper

Використовуємо AutoMapper для мапінгу даних між моделями Entity

Framework та DTO (Data Transfer Objects).

5. Валідація та Обробка Помилок

Додаємо логіку для валідації вхідних даних та обробки помилок,

щоб забезпечити коректність даних та стабільність API.

6. Міграції

Використовуємо міграції Entity Framework для управління змінами в

структурі бази даних.

REST API Реалізація

API розділене на два основні контролери: ArtistsController та

SongsController. Кожен з них виконує наступні функції:

GET запити:
Get(): Повертає список усіх артистів або пісень.
GetById(int id): Повертає артиста або пісню за їх ідентифікатором.

POST запити:
Дозволяють додавати нових артистів або пісні до бази даних.

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

PUT запити:
Оновлюють дані існуючих артистів або пісень.
 Етап 6. GraphQL APІ

Постановка задачі

Потрібно розробити GraphQL API сервер для забезпечення, як

мінімум, доступу до вхідних та результуючих даних варіантної операції,
надаючи можливість обирати той чи інший рівень деталізації цих даних.
Для демонстрації роботи сервера на тестових клієнтських HTTP-запитах,
окрім традиційних засобів (Postman, cURL тощо), можна скористатись
Graphіql.

Основні компоненти

Моделі:

Визначені як класи з використанням `TypeORM` та `TypeGraphQL`

анотацій.

Клас `Artist` містить поля `id`, `fullName`, `pseudoName`, `country` та

відношення один до багатьох з `Song`.

Клас `Song` включає поля `id`, `title`, `year`, `duration` та зворотнє

відношення до `Artist`.

Схеми GraphQL
 Використовуються для визначення структури даних, які будуть
відправлені клієнту через GraphQL запити.

Резолвери

`SongResolver` містить GraphQL запити (`Query`) та мутації

(`Mutation`), які дозволяють переглядати, додавати та взаємодіяти з даними
артистів та пісень.

Запити включають отримання списків пісень та артистів, а також

детальний перегляд окремих елементів за ідентифікатором.

Мутації дозволяють створювати нові записи для артистів та пісень.

Тестові Дані

Визначені відповідні об'єкти для артистів (`weeknd`, `lana`,

`maneskin`) та пісень (`song1`, `song2`, `song3`, `song4`), які
використовуються для демонстрації функціональності API.

Функціональність

- GET Запити (Через GraphQL Query):

● `viewArtistSongs`: Повертає пісні конкретного артиста.

● `viewSongs`: Повертає усі пісні.

● `viewArtists`: Повертає усіх артистів.

● `viewArtist`: Повертає конкретного артиста за його ID.

- POST Запити (Через GraphQL Mutation):

● `createSong`: Дозволяє створити нову пісню з вказаними

даними.

● `createArtist`: Дозволяє додати нового артиста.

 Застосування

Програма може використовуватися для створення та управління

музичною базою даних, надаючи можливості для додавання, перегляду та
взаємодії з даними про артистів та пісні. Використання GraphQL дозволяє
ефективно керувати запитами та відповідями, забезпечуючи гнучкість та
ефективність у взаємодії з API.
 Етап 7. gRPC

І. Теорія

gRPC (Google Remote Procedure Call) - це відкритий протокол для

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

У C# реалізація gRPC використовує бібліотеку grpc-dotnet. Для

створення gRPC служби в C# потрібно визначити сервіс у файлі з
розширенням ".proto", описати його методи та структури даних за
допомогою Protocol Buffers. Після цього можна використовувати
інструменти gRPC для автоматичної генерації коду для сервера та клієнта.

Серверна частина написана в C# може використовувати

згенерований код для реалізації методів, визначених у файлі ".proto".
Клієнтська частина також може використовувати згенерований код для
зручного взаємодії з віддаленим сервером, викликаючи методи, які
відповідають описаним у ".proto" файлі.

gRPC в C# забезпечує високопродуктивний та ефективний механізм

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

1. Створили proto-файл, який описує контракти на інтерфейс

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

2. Так як ми реалізовуємо це для серверної сторони, то маємо

також прописати конкретну реалізацію кожного методу. Для
цього створили файл DbService, який наслідується від
генерованого Generated.DB.DBBase.
3. Також для клієнт-сторони матимемо авто-генеровані класи
типів, що значно спрощує розробку клієнт-серверних додатків.
Наприклад, клас Cell:
 Етап 8. Вибірковий блок

Постановка задачі

Варіант проєкту із використанням реляційної СУБД (замість використання

серіалізації об'єктів для збереження даних).

Реалізація

У 5 етапі при реалізації REST API сервера було застосовано Entity

Framework та Міграції для роботи з базою даних, а саме SQL Server.

Основи Entity Framework та Його Роль

Entity Framework є об'єктно-орієнтованим відображенням (ORM), що

дозволяє розробникам взаємодіяти з базами даних, використовуючи .NET
об'єкти, замість прямих SQL запитів. Це спрощує процес розробки та
підтримки, оскільки вносить абстракцію та зменшує залежність від
конкретного SQL діалекту бази даних.

Міграції в Entity Framework

Міграції в EF дозволяють розробникам вести версіювання схеми бази

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

У результаті отримали наступну базу даних: