ფუნქციური 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 ერთეულზე მეტი No30 პროდუქტი 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