Rewriting SPARQL query with a join statement

404 views
Skip to first unread message

Motaz Lubbad

unread,
Apr 21, 2018, 7:50:28 AM4/21/18
to ontop4obda

Hi there, 
Thank you for your effort to develop this platform, and I would like to ask a question.

for this SPARQL query :

Select  ?Di ?Dn ?Fn ?Ln ?id ?ro where{
?x a :Department . ?x :DepartmentName ?Dn . ?x :DepartmentId ?Di 
;  :HasWorker ?b. ?b :FirstName ?Fn ; :LastName ?Ln ; :EmployeeId ?id ; :Hasrole ?r .
?r :Title ?ro .
}

the platform rewrites the SQL query like this  :

SELECT 
   7 AS `LnQuestType`, NULL AS `LnLang`, CAST(`Qemployees_employeesVIEW1`.`last_name` AS CHAR(8000) CHARACTER SET utf8) AS `Ln`, 
   7 AS `DiQuestType`, NULL AS `DiLang`, CAST(`Qemployees_departmentsVIEW0`.`dept_no` AS CHAR(8000) CHARACTER SET utf8) AS `Di`, 
   7 AS `FnQuestType`, NULL AS `FnLang`, CAST(`Qemployees_employeesVIEW1`.`first_name` AS CHAR(8000) CHARACTER SET utf8) AS `Fn`, 
   7 AS `DnQuestType`, NULL AS `DnLang`, CAST(`Qemployees_departmentsVIEW0`.`dept_name` AS CHAR(8000) CHARACTER SET utf8) AS `Dn`, 
   4 AS `idQuestType`, NULL AS `idLang`, CAST(`Qemployees_employeesVIEW1`.`emp_no` AS SIGNED) AS `id`, 
   7 AS `roQuestType`, NULL AS `roLang`, CAST(`Qemployees_titlesVIEW4`.`title` AS CHAR(8000) CHARACTER SET utf8) AS `ro`
FROM 
    `employees`.`departments` `Qemployees_departmentsVIEW0`,
    `employees`.`employees` `Qemployees_employeesVIEW1`,
    `employees`.`titles` `Qemployees_titlesVIEW2`,
    `employees`.`dept_emp` `Qemployees_dept_empVIEW3`,
    `employees`.`titles` `Qemployees_titlesVIEW4`
WHERE 
    (`Qemployees_departmentsVIEW0`.`dept_no` = `Qemployees_dept_empVIEW3`.`dept_no`) AND
    (`Qemployees_employeesVIEW1`.`emp_no` = `Qemployees_titlesVIEW2`.`emp_no`) AND
    (`Qemployees_employeesVIEW1`.`emp_no` = `Qemployees_dept_empVIEW3`.`emp_no`) AND
    (`Qemployees_employeesVIEW1`.`emp_no` = `Qemployees_titlesVIEW4`.`emp_no`)


but I think it should be something using JOIN like this :

SELECT E.first_name , E.last_name , 
       E.emp_no , D.dept_name  , D.dept_no ,T.title
        FROM dept_emp DE 
         JOIN employees E
          ON DE.emp_no = E.emp_no 
          join departments D
          ON D.dept_no = DE.dept_no
          join titles T
          on E.emp_no =T.emp_no



My question is there any problem with my SPARQL query or my mapping or is it a normal situation?



Guohui Xiao

unread,
Apr 21, 2018, 9:23:04 AM4/21/18
to Motaz Lubbad, ontop4obda
Dear Motaz,

Are you wondering why Ontop produces SQL queries not using the "JOIN" and "ON", but using only "FROM" and "WHERE"?

If this was your question, it is a very normal situation. In fact, these two ways of writing SQLs are equivalent.

Best,

Guohui

--
Please follow our guidlines on how to report a bug https://github.com/ontop/ontop/wiki/BugReport
---
You received this message because you are subscribed to the Google Groups "ontop4obda" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontop4obda+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Guohui Xiao, PhD
Assistant Professor with a fixed-term contract
KRDB - Faculty of Computer Science        
Free University of Bozen-Bolzano
Piazza Domenicani, 3                
I-39100 Bolzano, Italy    

http://www.ghxiao.org

Guohui Xiao

unread,
Apr 21, 2018, 9:50:59 AM4/21/18
to Motaz Lubbad, ontop4obda, Guohui Xiao
Dear Motaz,

Indeed, sometimes we translate SPARQL queries to SQL with LEFT JOIN. When SPARQL queries are with OPTIONAL, we may have to generate LEFT JOINs. 

In terms of performance, our experience is that INNTER joins in general performs better than LEFT/RIGHT joins. Therefore, whenever possible, we generate INNER joins.

Best,

On 21 April 2018 at 15:37, Motaz Lubbad <motazl...@gmail.com> wrote:
Daer Guohui 

Thank you for your answer, you are right. but I'm wondering if there any possibility to rewrite the SPARQL queries with the different type of  JOIN "INNER, LEFT, RIGHT", with the different type of join I think we can get higher performance.

Regards,

Reply all
Reply to author
Forward
0 new messages