機能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つ発表します 機能、入力として 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 年に製品 No. 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 年に購入者が最も多くのお金を費やした XNUMX つの商品 (名前) を見つけます。

前の例からドメイン ロジックを拡張します。

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 で自分で解決することをお勧めします。友達の数は好きな人よりはるかに少ないと想定されます。したがって、それらは別のテーブルにあります。成功すると星XNUMXつのタスクもあります。その中で、友情は対称的ではありません。機能データベースでは次のようになります。

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: 最初と XNUMX 番目のアスタリスクの問題の解決策 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 

まとめ

指定された言語構文は、指定された概念を実装するためのオプションの XNUMX つにすぎないことに注意してください。 SQL が基礎として採用され、目標は 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 のみ) を「仮想マシン」として使用します。 RDBMS クエリ オプティマイザーは、FDBMS が知っている特定の統計を知らないため、この変換で問題が発生することがあります。理論的には、機能ロジックに特化した特定の構造をストレージとして使用するデータベース管理システムを実装することが可能です。

出所： habr.com