Prolog to SQL Converter

prolog to SQL converter

Recommending:

https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/prolog/code/io/pl2sql/0.html

my advice- use Eclipse prolog (http://www.eclipseclp.org/) (not (here) to be confused with prolog in the eclipse IDE).

I spent hours trying to get the code to compile in 4 other prologs(!) and 4 minutes to compile in eclipse.

When it works, it's a thing of beauty.

Credit to Herr Draxler of course

Comparing SQL and Prolog

Most of the (earlier) answers here are a reflection of the fact that most people do not know what SQL is (its an implementation of Relational Calculus) or what that means (that it's a form of Predicate Logic). The following statements are true of both Prolog and SQL:

• they are both logic-driven
• they can both store, express and use relations (logical relationships in Prolog)
• they can both store and express complex logical conditions
• they both have facts(data in SQL) and can derive conclusions from those facts
• they both have queries, that do in fact mean the same thing
• they both have data(facts in Prolog) and use them similarly
• they are both programming languages
• they are both turing-complete (though it is somewhat difficult to access this in both of them)
• etc, etc..

Generally, people are not aware of these equivalences between them:

1. "Facts" and "Data" are the same thing. This is straight out of Codd's original paper.
2. A "Relation" in Relational Theory is the same thing as a "Table" in SQL, is the same thing as a Relation or relational function in Predicate Logic and is the same thing as a tuple-set in Set Theory
3. An aliased table-expression (i.e., a View, etc.) in SQL is the same thing as a Rule in Prolog.

So what are their differences? Although they operate across the same conceptual domains, their focuses are in completely different directions. In Prolog terms, SQL is primarily a Fact and Relation(set) engine, whereas Prolog is primarily a Rules and Inferencing engine. Each can do the other, to a limited extent, but it becomes increasingly difficult with even small increases in complexity. For instance, you can do inferencing in SQL, but it is almost entirely manual in nature and not at all like the automatic forward-inferencing of Prolog. And yes, you can store data(facts) in Prolog, but it is not at all designed for the "storage, retrieval, projection and reduction of Trillions of rows with thousands of simultaneous users" that SQL is.

Plus, SQL is primarily a Server-language paradigm, whereas Prolog is primarily a Client-language paradigm.

How to add an XML declaration prolog with encoding to XML in SQL Server 2016?

SQL Server holds XML data type internally as UTF-16. And because of it, it strips any XML prolog.

That's why if you need an XML declaration prolog, you need to use NVARCHAR() data type.

Please see below.

SQL

-- DDL and sample data population, start
DECLARE @ENTETE TABLE (CIB_DECLARANT INT, Type_Fischier VARCHAR(30), date_declaration DATE);
INSERT INTO @ENTETE (CIB_DECLARANT, Type_Fischier,  date_declaration) 
VALUES (10057, 'DECLARATION_TCN', '2019-12-03');
-- DDL and sample data population, end

-- just to see
SELECT
(
    SELECT *
    FROM @ENTETE
    FOR XML PATH('ENTETE'), TYPE
).query('<TCN  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
{
    for $x in /ENTETE
    return $x
}

</TCN>');

DECLARE @prolog NVARCHAR(100) = N'<?xml version="1.0" encoding="utf-8" standalone="no"?>'
   , @xml NVARCHAR(MAX);

-- real deal
SET @xml = @prolog + TRY_CAST((SELECT
(
    SELECT *
    FROM @ENTETE
    FOR XML PATH('ENTETE'), TYPE
).query('<TCN  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
{
    for $x in /ENTETE
    return $x
}

</TCN>')) AS NVARCHAR(MAX));

-- final XML with the prolog as NVARCHAR() data type
SELECT @xml;

Output (indented for the human eyes only)

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<TCN xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <ENTETE>
      <CIB_DECLARANT>10057</CIB_DECLARANT>
      <Type_Fischier>DECLARATION_TCN</Type_Fischier>
      <date_declaration>2019-12-03</date_declaration>
   </ENTETE>
</TCN>

Any specific rules for converting MySQL data to Prolog rules for exploratory mining?

You could maybe use nth1/1 and the "univ" operator, doing something like this:

fieldnames(t, [id,this,that]).
get_field(Field, Tuple, Value) :- 
    Tuple =.. [Table|Fields],
    fieldnames(Table, Names),
    nth1(Idx, Names, Field),
    nth1(Idx, Fields, Value).

You'd need to create fieldnames/2 records for each table structure, and you'd have to pass the table structure along to this query. It wouldn't be terrifically efficient, but it would work.

?- get_field(this, t(testId, testThis, testThat), Value)
Value = testThis

You could then build your accessors on top of this pretty easily:

findThisById(X, This) :- get_field(this, X, This).

Edit: Boris points out rightly that arg/3 will do this with even less work:

get_field(Field, Tuple, Value) :-
    functor(Tuple, Table, _),
    fieldnames(Table, Names),
    nth1(Idx, Names, Field),
    arg(Idx, Tuple, Value).

Prolog is so awesome.

Using Prolog to make a prediction based on the data in a Relational Database

Yes- you can train a classifier using a machine learning algorithm.
Algorithms which work well in prolog are ones that make rule models.

For example a decision tree or a rule learner such as ripper.

http://www.amazon.co.uk/Programming-Artificial-Intelligence-International-Computer/dp/0321417461 chapter 18 is a good start. There is a LOT of literature on the subject ;)

---

Related Topics