Функционална СУБД

Светът на базите данни отдавна е превзет от релационни СУБД, които използват езика SQL. Толкова много, че нововъзникващите разновидности се наричат ​​NoSQL. Те успяха да спечелят определено място за себе си на този пазар, но релационните СУБД няма да умрат и продължават да се използват активно за собствените си цели.

В тази статия искам да опиша концепцията за функционална база данни. За по-добро разбиране ще направя това, като сравня с класическия релационен модел. Като примери ще бъдат използвани задачи от различни 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 параметър като вход и връщат примитивен тип.

Предполага се, че във функционална СУБД всеки обект ще има някакъв вътрешен код, който се генерира автоматично и може да бъде достъпен, ако е необходимо.

Нека да определим цената за продукта / магазина / доставчика. Може да се промени с времето, така че нека добавим поле за време към таблицата. Ще пропусна декларацията на таблици за директории в релационна база данни, за да съкратя кода:

Релационна

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);


Необходимо е да се намерят възможни кандидати за приятелство. По-формално, трябва да намерите всички хора A, B, C, така че A да е приятел с B, а B да е приятел с C, A да харесва C, но A да не е приятел с C.
От гледна точка на функционална база данни, заявката ще изглежда така:

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 и да приложите множествен полиморфизъм. Как точно, може би ще пиша в следващите статии.

Въпреки че това е само концепция, вече имаме някаква реализация в Java, която превежда цялата функционална логика в релационна логика. Освен това логиката на представянията и много други неща са красиво завинтени към него, благодарение на което получаваме цяло платформа. По същество ние използваме RDBMS (засега само PostgreSQL) като "виртуална машина". Този превод понякога създава проблеми, тъй като оптимизаторът на заявки за RDBMS не знае определени статистики, които FDBMS знае. На теория е възможно да се приложи система за управление на база данни, която ще използва определена структура като съхранение, адаптирана специално за функционална логика.

Източник: www.habr.com