기능성 DBMS

데이터베이스 세계는 오랫동안 SQL 언어를 사용하는 관계형 DBMS가 지배해 왔습니다. 그래서 새로운 변종을 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);


XNUMX개를 발표합니다 기능, 하나의 매개변수 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 작업

부서 ID, 직원 수가 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 작업

최대 총 직원 급여가 포함된 부서 ID 목록을 찾습니다.

관계형

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 연산자는 다음 원칙에 따라 작동합니다. 지정된 그룹(여기서는 Customer 및 Year, 그러나 임의의 표현식일 수 있음) 내에서 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와 친구이고, B는 C와 친구이고, A는 C를 좋아하지만 A는 C와 친구가 아닌 모든 A, B, 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을 모두 유사한 구문으로 만들 수 있습니다.

제 생각에는 설명된 데이터베이스 개념에는 다음과 같은 장점이 있습니다.

• 편함. 이는 단순한 경우에는 명확하지 않은 상대적으로 주관적인 지표입니다. 그러나 더 복잡한 사례(예: 별표 관련 문제)를 살펴보면 이러한 쿼리를 작성하는 것이 훨씬 쉽다고 생각합니다.
• Инкапсуляция. 일부 예에서는 중간 함수를 선언했습니다(예: 판매, 구입 등), 이를 바탕으로 후속 기능이 구축되었습니다. 이를 통해 필요한 경우 해당 기능에 의존하는 기능의 논리를 변경하지 않고도 특정 기능의 논리를 변경할 수 있습니다. 예를 들어 판매를 할 수 있습니다. 판매 완전히 다른 개체에서 계산되었지만 나머지 논리는 변경되지 않습니다. 예, CREATE VIEW를 사용하여 RDBMS에서 구현할 수 있습니다. 그러나 모든 논리가 이런 방식으로 작성되면 읽기가 쉽지 않을 것입니다.
• 의미상의 공백 없음. 이러한 데이터베이스는 테이블과 필드 대신 함수와 클래스에서 작동합니다. 고전 프로그래밍과 같습니다(메서드가 해당 클래스의 형태로 첫 번째 매개변수를 갖는 함수라고 가정하는 경우). 따라서 범용 프로그래밍 언어와 "친구를 사귀는" 것이 훨씬 쉬워집니다. 또한 이 개념을 사용하면 훨씬 더 복잡한 기능을 구현할 수 있습니다. 예를 들어 다음과 같은 연산자를 포함할 수 있습니다.

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


• 상속과 다형성. 기능적 데이터베이스에서는 CLASS ClassP: Class1, Class2 구성을 통해 다중 상속을 도입하고 다중 다형성을 구현할 수 있습니다. 나는 아마도 향후 기사에서 정확히 어떻게 쓰는지 쓸 것입니다.

이것은 단지 개념일 뿐이지만 모든 기능적 논리를 관계형 논리로 변환하는 Java 구현이 이미 있습니다. 또한 표현의 논리와 기타 많은 것들이 아름답게 연결되어 있습니다. 덕분에 우리는 전체를 얻습니다. 플랫폼. 기본적으로 우리는 RDBMS(현재는 PostgreSQL만)를 "가상 머신"으로 사용합니다. FDBMS가 알고 있는 특정 통계를 RDBMS 쿼리 최적화 프로그램이 알지 못하기 때문에 이 변환에 문제가 발생하는 경우가 있습니다. 이론적으로는 기능적 논리에 맞게 특별히 조정된 특정 구조를 저장소로 사용하는 데이터베이스 관리 시스템을 구현하는 것이 가능합니다.

출처 : habr.com