DBMS פונקציונלי

עולם מסדי הנתונים נשלט זה מכבר על ידי DBMSs יחסי, המשתמשים בשפת SQL. עד כדי כך שגרסאות מתפתחות נקראות NoSQL. הם הצליחו למצוא לעצמם מקום מסוים בשוק הזה, אבל DBMSs יחסי לא הולכים למות, וממשיכים לשמש באופן פעיל למטרותיהם.

במאמר זה אני רוצה לתאר את הרעיון של מסד נתונים פונקציונלי. להבנה טובה יותר, אעשה זאת על ידי השוואתו למודל ההתייחסותי הקלאסי. בעיות מבדיקות 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), בתוך הקבוצות שצוינו (כאן Customer ו- Year, אבל יכול להיות כל ביטוי), מיון בתוך הקבוצות לפי הביטויים שצוינו ב-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 בונה וליישם פולימורפיזם מרובה. אני כנראה אכתוב איך בדיוק במאמרים הבאים.

למרות שזה רק מושג, כבר יש לנו יישום כלשהו בג'אווה שמתרגם את כל ההיגיון הפונקציונלי ללוגיקה יחסית. בנוסף, ההיגיון של הייצוגים והרבה דברים אחרים מחוברים אליו יפה, שבזכותם אנו מקבלים שלם פּלַטפוֹרמָה. בעיקרו של דבר, אנו משתמשים ב-RDBMS (רק PostgreSQL לעת עתה) כ"מכונה וירטואלית". לפעמים מתעוררות בעיות עם תרגום זה מכיוון שמאופטימיזציית השאילתות של RDBMS אינו יודע סטטיסטיקות מסוימות שה-FDBMS יודע. בתיאוריה, ניתן ליישם מערכת ניהול מסד נתונים שתשתמש במבנה מסוים כאחסון, המותאם במיוחד ללוגיקה פונקציונלית.

מקור: www.habr.com