Функционален DBMS

Во светот на базите на податоци долго време доминираат релациони DBMS, кои го користат јазикот SQL. Толку многу што новите варијанти се нарекуваат NoSQL. Тие успеаја да одвојат одредено место за себе на овој пазар, но релационите DBMS нема да умрат и ќе продолжат активно да се користат за нивните цели.

Во оваа статија сакам да го опишам концептот на функционална база на податоци. За подобро разбирање, ќе го направам ова споредувајќи го со класичниот релациски модел. Како примери ќе се користат проблеми од различни SQL тестови пронајдени на Интернет.

Вовед

Релационите бази на податоци работат на табели и полиња. Во функционална база на податоци, наместо тоа ќе се користат класи и функции. Поле во табела со N копчиња ќе биде претставено како функција од N параметри. Наместо врски помеѓу табелите, ќе се користат функции кои враќаат објекти од класата на која е направена врската. Наместо JOIN ќе се користи функцискиот состав.

Пред да преминам директно на задачите, ќе ја опишам задачата на логиката на доменот. За DDL ќе користам синтакса PostgreSQL. За функционална има своја синтакса.

Табели и полиња

Едноставен Sku објект со полиња за име и цена:

Релациски

CREATE TABLE Sku
(
    id bigint NOT NULL,
    name character varying(100),
    price numeric(10,5),
    CONSTRAINT id_pkey PRIMARY KEY (id)
)

функционални

CLASS Sku;
name = DATA STRING[100] (Sku);
price = DATA NUMERIC[10,5] (Sku);


Ви објавуваме два функции, кои земаат еден параметар Sku како влез и враќаат примитивен тип.

Се претпоставува дека во функционален DBMS секој објект ќе има внатрешен код кој автоматски се генерира и може да се пристапи доколку е потребно.

Ајде да ја поставиме цената за производот/продавницата/добавувачот. Може да се промени со текот на времето, па ајде да додадеме временско поле на табелата. Ќе прескокнам декларирање табели за директориуми во релациона база на податоци за да го скратам кодот:

Релациски

CREATE TABLE prices
(
    skuId bigint NOT NULL,
    storeId bigint NOT NULL,
    supplierId bigint NOT NULL,
    dateTime timestamp without time zone,
    price numeric(10,5),
    CONSTRAINT prices_pkey PRIMARY KEY (skuId, storeId, supplierId)
)

функционални

CLASS Sku;
CLASS Store;
CLASS Supplier;
dateTime = DATA DATETIME (Sku, Store, Supplier);
price = DATA NUMERIC[10,5] (Sku, Store, Supplier);


Индекси

За последниот пример, ќе изградиме индекс на сите клучеви и датумот за да можеме брзо да ја најдеме цената за одредено време.

Релациски

CREATE INDEX prices_date
    ON prices
    (skuId, storeId, supplierId, dateTime)

функционални

INDEX Sku sk, Store st, Supplier sp, dateTime(sk, st, sp);


задачи

Да почнеме со релативно едноставни проблеми земени од соодветните Член на Хабр.

Прво, да ја декларираме логиката на доменот (за релациската база на податоци ова е направено директно во горната статија).

CLASS Department;
name = DATA STRING[100] (Department);

CLASS Employee;
department = DATA Department (Employee);
chief = DATA Employee (Employee);
name = DATA STRING[100] (Employee);
salary = DATA NUMERIC[14,2] (Employee);


Проблем 1.1

Прикажете список на вработени кои примаат плата поголема од онаа на нивниот непосреден претпоставен.

Релациски

select a.*
from   employee a, employee b
where  b.id = a.chief_id
and    a.salary > b.salary

функционални

SELECT name(Employee a) WHERE salary(a) > salary(chief(a));


Проблем 1.2

Наведете ги вработените кои примаат максимална плата во нивниот оддел

Релациски

select a.*
from   employee a
where  a.salary = ( select max(salary) from employee b
                    where  b.department_id = a.department_id )

функционални

maxSalary 'Максимальная зарплата' (Department s) = 
    GROUP MAX salary(Employee e) IF department(e) = s;
SELECT name(Employee a) WHERE salary(a) = maxSalary(department(a));

// или если "заинлайнить"
SELECT name(Employee a) WHERE 
    salary(a) = maxSalary(GROUP MAX salary(Employee e) IF department(e) = department(a));


Двете имплементации се еквивалентни. За првиот случај, во релациона база на податоци можете да користите CREATE VIEW, кој на ист начин прво ќе ја пресмета максималната плата за одреден оддел во него. Во продолжение, за јасност, ќе го искористам првиот случај, бидејќи тој подобро го одразува решението.

Проблем 1.3

Прикажете список со идентификатори на одделот, чиј број на вработени не надминува 3 лица.

Релациски

select department_id
from   employee
group  by department_id
having count(*) <= 3

функционални

countEmployees 'Количество сотрудников' (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
SELECT Department d WHERE countEmployees(d) <= 3;


Проблем 1.4

Прикажете список на вработени кои немаат одреден менаџер кој работи во истиот оддел.

Релациски

select a.*
from   employee a
left   join employee b on (b.id = a.chief_id and b.department_id = a.department_id)
where  b.id is null

функционални

SELECT name(Employee a) WHERE NOT (department(chief(a)) = department(a));


Проблем 1.5

Најдете список на лични карти на одделот со максимална вкупна плата на вработените.

Релациски

with sum_salary as
  ( select department_id, sum(salary) salary
    from   employee
    group  by department_id )
select department_id
from   sum_salary a       
where  a.salary = ( select max(salary) from sum_salary )

функционални

salarySum 'Максимальная зарплата' (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;
maxSalarySum 'Максимальная зарплата отделов' () = 
    GROUP MAX salarySum(Department d);
SELECT Department d WHERE salarySum(d) = maxSalarySum();


Ајде да преминеме на посложени задачи од друга Член. Содржи детална анализа за тоа како да се имплементира оваа задача во MS SQL.

Проблем 2.1

Кои продавачи продадоа повеќе од 1997 единици производ бр. 30 во 1 година?

Логика на доменот (како и претходно на RDBMS ја прескокнуваме декларацијата):

CLASS Employee 'Продавец';
lastName 'Фамилия' = DATA STRING[100] (Employee);

CLASS Product 'Продукт';
id = DATA INTEGER (Product);
name = DATA STRING[100] (Product);

CLASS Order 'Заказ';
date = DATA DATE (Order);
employee = DATA Employee (Order);

CLASS Detail 'Строка заказа';

order = DATA Order (Detail);
product = DATA Product (Detail);
quantity = DATA NUMERIC[10,5] (Detail);


Релациски

select LastName
from Employees as e
where (
  select sum(od.Quantity)
  from [Order Details] as od
  where od.ProductID = 1 and od.OrderID in (
    select o.OrderID
    from Orders as o
    where year(o.OrderDate) = 1997 and e.EmployeeID = o.EmployeeID)
) > 30

функционални

sold (Employee e, INTEGER productId, INTEGER year) = 
    GROUP SUM quantity(OrderDetail d) IF 
        employee(order(d)) = e AND 
        id(product(d)) = productId AND 
        extractYear(date(order(d))) = year;
SELECT lastName(Employee e) WHERE sold(e, 1, 1997) > 30;


Проблем 2.2

За секој купувач (име, презиме) најдете ги двете стоки (име) на кои купувачот потрошил најмногу пари во 1997 година.

Ја прошируваме логиката на доменот од претходниот пример:

CLASS Customer 'Клиент';
contactName 'ФИО' = DATA STRING[100] (Customer);

customer = DATA Customer (Order);

unitPrice = DATA NUMERIC[14,2] (Detail);
discount = DATA NUMERIC[6,2] (Detail);


Релациски

SELECT ContactName, ProductName FROM (
SELECT c.ContactName, p.ProductName
, ROW_NUMBER() OVER (
    PARTITION BY c.ContactName
    ORDER BY SUM(od.Quantity * od.UnitPrice * (1 - od.Discount)) DESC
) AS RatingByAmt
FROM Customers c
JOIN Orders o ON o.CustomerID = c.CustomerID
JOIN [Order Details] od ON od.OrderID = o.OrderID
JOIN Products p ON p.ProductID = od.ProductID
WHERE YEAR(o.OrderDate) = 1997
GROUP BY c.ContactName, p.ProductName
) t
WHERE RatingByAmt < 3

функционални

sum (Detail d) = quantity(d) * unitPrice(d) * (1 - discount(d));
bought 'Купил' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y;
rating 'Рейтинг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;


Операторот PARTITION работи на следниов принцип: го сумира изразот наведен по SUM (тука 1), во рамките на наведените групи (тука Клиент и Година, но може да биде кој било израз), сортирање во рамките на групите според изразите наведени во ORDER ( овде купено, и ако е еднакво, тогаш според внатрешната шифра на производот).

Проблем 2.3

Колку стоки треба да се нарачаат од добавувачите за да се исполнат тековните нарачки.

Ајде повторно да ја прошириме логиката на доменот:

CLASS Supplier 'Поставщик';
companyName = DATA STRING[100] (Supplier);

supplier = DATA Supplier (Product);

unitsInStock 'Остаток на складе' = DATA NUMERIC[10,3] (Product);
reorderLevel 'Норма продажи' = DATA NUMERIC[10,3] (Product);


Релациски

select s.CompanyName, p.ProductName, sum(od.Quantity) + p.ReorderLevel — p.UnitsInStock as ToOrder
from Orders o
join [Order Details] od on o.OrderID = od.OrderID
join Products p on od.ProductID = p.ProductID
join Suppliers s on p.SupplierID = s.SupplierID
where o.ShippedDate is null
group by s.CompanyName, p.ProductName, p.UnitsInStock, p.ReorderLevel
having p.UnitsInStock < sum(od.Quantity) + p.ReorderLevel

функционални

orderedNotShipped 'Заказано, но не отгружено' (Product p) = 
    GROUP SUM quantity(OrderDetail d) IF product(d) = p;
toOrder 'К заказу' (Product p) = orderedNotShipped(p) + reorderLevel(p) - unitsInStock(p);
SELECT companyName(supplier(Product p)), name(p), toOrder(p) WHERE toOrder(p) > 0;


Проблем со ѕвездичка

И последниот пример е од мене лично. Има логика на социјална мрежа. Луѓето можат да бидат пријатели едни со други и да се допаѓаат. Од перспектива на функционална база на податоци, тоа би изгледало вака:

CLASS Person;
likes = DATA BOOLEAN (Person, Person);
friends = DATA BOOLEAN (Person, Person);


Неопходно е да се најдат можни кандидати за пријателство. Поформално, треба да ги најдете сите луѓе А, Б, Ц така што А е пријател со Б, а Б е пријател со Ц, А сака Ц, но А не е пријател со В.
Од перспектива на функционална база на податоци, барањето би изгледало вака:

SELECT Person a, Person b, Person c WHERE 
    likes(a, c) AND NOT friends(a, c) AND 
    friends(a, b) AND friends(b, c);


Читателот е охрабрен сам да го реши овој проблем во SQL. Се претпоставува дека има многу помалку пријатели од луѓето што ви се допаѓаат. Затоа тие се во посебни табели. Доколку е успешна, има и задача со две ѕвезди. Во него пријателството не е симетрично. На функционална база на податоци тоа би изгледало вака:

SELECT Person a, Person b, Person c WHERE 
    likes(a, c) AND NOT friends(a, c) AND 
    (friends(a, b) OR friends(b, a)) AND 
    (friends(b, c) OR friends(c, b));


UPD: решение за проблемот со првата и втората ѕвездичка од dss_kalika:

SELECT 
   pl.PersonAID
  ,pf.PersonAID
  ,pff.PersonAID
FROM Persons                 AS p
--Лайки                      
JOIN PersonRelationShip      AS pl ON pl.PersonAID = p.PersonID
                                  AND pl.Relation  = 'Like'
--Друзья                     
JOIN PersonRelationShip      AS pf ON pf.PersonAID = p.PersonID 
                                  AND pf.Relation = 'Friend'
--Друзья Друзей              
JOIN PersonRelationShip      AS pff ON pff.PersonAID = pf.PersonBID
                                   AND pff.PersonBID = pl.PersonBID
                                   AND pff.Relation = 'Friend'
--Ещё не дружат         
LEFT JOIN PersonRelationShip AS pnf ON pnf.PersonAID = p.PersonID
                                   AND pnf.PersonBID = pff.PersonBID
                                   AND pnf.Relation = 'Friend'
WHERE pnf.PersonAID IS NULL 

;WITH PersonRelationShipCollapsed AS (
  SELECT pl.PersonAID
        ,pl.PersonBID
        ,pl.Relation 
  FROM #PersonRelationShip      AS pl 
  
  UNION 

  SELECT pl.PersonBID AS PersonAID
        ,pl.PersonAID AS PersonBID
        ,pl.Relation
  FROM #PersonRelationShip      AS pl 
)
SELECT 
   pl.PersonAID
  ,pf.PersonBID
  ,pff.PersonBID
FROM #Persons                      AS p
--Лайки                      
JOIN PersonRelationShipCollapsed  AS pl ON pl.PersonAID = p.PersonID
                                 AND pl.Relation  = 'Like'                                  
--Друзья                          
JOIN PersonRelationShipCollapsed  AS pf ON pf.PersonAID = p.PersonID 
                                 AND pf.Relation = 'Friend'
--Друзья Друзей                   
JOIN PersonRelationShipCollapsed  AS pff ON pff.PersonAID = pf.PersonBID
                                 AND pff.PersonBID = pl.PersonBID
                                 AND pff.Relation = 'Friend'
--Ещё не дружат                   
LEFT JOIN PersonRelationShipCollapsed AS pnf ON pnf.PersonAID = p.PersonID
                                   AND pnf.PersonBID = pff.PersonBID
                                   AND pnf.Relation = 'Friend'
WHERE pnf.[PersonAID] IS NULL 

Заклучок

Треба да се напомене дека дадената јазична синтакса е само една од опциите за имплементација на дадениот концепт. Како основа беше земен SQL, а целта беше тој да биде што е можно повеќе сличен на него. Се разбира, на некои можеби не им се допаѓаат имињата на клучни зборови, регистри на зборови итн. Главната работа овде е самиот концепт. Ако сакате, можете да направите и C++ и Python слична синтакса.

Опишаниот концепт на база на податоци, според мое мислење, ги има следните предности:

• олеснување. Ова е релативно субјективен индикатор кој не е очигледен во едноставни случаи. Но, ако погледнете посложени случаи (на пример, проблеми со ѕвездички), тогаш, според мое мислење, пишувањето такви прашања е многу полесно.
• Инкапсуляция. Во некои примери декларирав средни функции (на пример, продаваат, купи итн.), од кои беа изградени следните функции. Ова ви овозможува да ја промените логиката на одредени функции, доколку е потребно, без да ја менувате логиката на оние што зависат од нив. На пример, можете да направите продажба продаваат беа пресметани од сосема различни објекти, додека остатокот од логиката нема да се промени. Да, ова може да се имплементира во RDBMS користејќи CREATE VIEW. Но, ако целата логика е напишана на овој начин, нема да изгледа многу читливо.
• Нема семантички јаз. Таквата база на податоци работи на функции и класи (наместо табели и полиња). Исто како и во класичното програмирање (ако претпоставиме дека методот е функција со првиот параметар во форма на класата на која припаѓа). Според тоа, би требало да биде многу полесно да се „дружите“ со универзалните програмски јазици. Дополнително, овој концепт овозможува имплементација на многу посложени функционалности. На пример, можете да вградите оператори како што се:

  CONSTRAINT sold(Employee e, 1, 2019) > 100 IF name(e) = 'Петя' MESSAGE  'Что-то Петя продает слишком много одного товара в 2019 году';


• Наследување и полиморфизам. Во функционална база на податоци, можете да воведете повеќекратно наследување преку CLASS ClassP: Class1, Class2 конструира и имплементира повеќекратен полиморфизам. Веројатно ќе напишам како точно во идните статии.

Иако ова е само концепт, ние веќе имаме одредена имплементација во Јава која ја преведува целата функционална логика во релациона логика. Плус, логиката на репрезентации и многу други работи се прекрасно врзани за неа, благодарение на што добиваме една целина платформа. Во суштина, ние го користиме RDBMS (засега само PostgreSQL) како „виртуелна машина“. Понекогаш се појавуваат проблеми со овој превод затоа што оптимизатор на прашања RDBMS не знае одредени статистички податоци што ги знае FDBMS. Теоретски, можно е да се имплементира систем за управување со бази на податоци кој ќе користи одредена структура како складирање, адаптирана специјално за функционална логика.

Извор: www.habr.com