Showing posts with label Relational. Show all posts
Showing posts with label Relational. Show all posts

Monday, March 15, 2010

Formulating Expressions a Step at a Time: Lazy Evaluation

I am reading this book, and I found the section with the title “Formulating Expressions a Step at a Time” particularly interesting:

First, the book shows you this the query for the sentence "Get pairs of supplier numbers such that the suppliers concerned are collocated (i.e., are in the same city)" written in Tutorial D:

( ( ( S RENAME ( SNO AS SA ) ) { SA , CITY } JOIN
( S RENAME ( SNO AS SB ) ) { SB , CITY } )
WHERE SA < SB ) { SA , SB }

And then it proceeds to show you how to write this query in a more readable (step by step) way:

WITH ( S RENAME ( SNO AS SA ) ) { SA , CITY } AS R1 ,
( S RENAME ( SNO AS SB ) ) { SB , CITY } AS R2 ,
R1 JOIN R2 AS R3 ,
R3 WHERE SA < SB AS R4 :
R4 { SA, SB }

Finally, it shows you how to write this query in SQL:

WITH T1 AS ( SELECT SNO AS SA , CITY
FROM S ) ,
T2 AS ( SELECT SNO AS SB , CITY
FROM S ) ,
T3 AS ( SELECT *
FROM T1 NATURAL JOIN T2 ) ,
T4 AS ( SELECT *
FROM T3
WHERE SA < SB )
SELECT SA , SB
FROM T4

Thanks to the “with” keyword, both in SQL and in Tutorial D, it is possible to deal with this query in a “step by step” way, instead of having to deal with it a single hard to write and hard to read expression (note that this is not a recursive query, so the with keyword is not being used for that in this examples)

Sadly, so far I have been unable to find a equivalent for this syntax in Dataphor… While it is possible to write something like (I am not 100% confident the syntax is right, but I think it should give you the general idea):

var R1 := S {SNO SA}
var R2 := S {SNO SB}
var R3 := R2 JOIN R3
var R4 := R3 WHERE SA < SB
select R4 {SA, SB}

In Dataphor, the variables (R1, R2, etc) are not lazily evaluated, and therefore the performance is not as good, as in, for example, the SQL case (I ran a similar example in SqlServer, and the expressions were evaluated lazily, at the end, instead of one by one, resulting in far better performance). Maybe I am doing something wrong?

I wonder how hard would it be to make Dataphor generate SQL using the WITH keyword with those databases that support it (so far the latest versions of SQLServer (2008) and Oracle (10 & 11) seem to support this syntax)… I guess it is time to ask the Dataphor authors…

Thursday, March 04, 2010

Null versus None

None means Nothing, Nothing is a concept that describes the absence of anything at all. Nothing is sometimes confused with Null, but they are very different concepts because Nothing means absence of anything, while Null means unknown (you do not know if there is a thing or not).

For Nothing, the normal Two valued logic applies (Nothing=Nothing : true, Nothing = Something : false), for Null, Three valued logic is necessary(Null=Null:unknown, Null=Something:unknown). Unfortunately, this 2 concepts have been used interchangeably without much thought, to point where the most common use for Null in relational databases is to mean Nothing (even when Null was designed to represent unknown by Codd). This confusion is aggravated by the fact that many mainstream application languages (Java, C#, C, etc) use the null keyword to mean uninitialized variable which easily maps to the interpretation that null means the variable is pointing to "nothing" (no object).

But for databases, Null was not invented to represent nothingness, was invented to represent that the value of something was not known (maybe be something, maybe nothing, we just do not know).

Now that Chris Date wants Null to be removed from Relational Databases, so that the incongruence and confusion brought in by Three valued logic is eliminated, the developers, accustomed to use Null to represent Nothing, resist to the idea asking: How am I going to represent the fact that a Person is not married? I use to do that by marking the Marriage Date? as a nullable Date. Now what? I need to split the table into 2 tables just to represent the fact that the Marriage Date? is not mandatory? That of course seems like the obvious, elegant (if extremely cumbersome answer). But the practical developer refuses to get into that trouble, it is just too much effort, it is simple easier to continue using Null. But... what about Nothing? why not just simply add "Nothing" as a possible value for to the Date domain? That way it is possible to say that the Person has no Marriage Date?, and still stay inside the realm of two valued logic.

Is this solution, in any way in conflict with The Third Manifesto? I really would like to know… I wonder what will be the opinion of the community in the  C2 Wiki

Tuesday, January 26, 2010

Pagination in Dataphor

First I created this operator:

create operator GetNext(var AID :Integer) : System.Integer 
begin
AID:= AID+1;
result:=AID;
end ;


and then I used it:



var id := 0; 
select SomeTable add {GetNext(id) rowid};


It is nice, but it would be better if there were a way to do this without having to create an operator myself (it should already include one that does this)

Now If I want to do pagination, all I have to do is write:



var id := 0; 
select SomeTable add {GetNext(id) rowid} where rowid between 2 and 5;


That will return rows between 2 and 5 from the “SomeTable” table.



Now one of the most interesting feaures about Dataphor, are relvars (relational variables), that make it possible to do this:



var SomeComplexQuery := SomeTable where …...
var id := 0;
select SomeComplexQuery add {GetNext(id) rowid} where rowid between 2 and 5;


That way, pagination can be added to a query of arbitrary complexity with minimum effort.

Sunday, April 20, 2008

The Two Laws Of Dimensional Ontology

The Two Laws Of Dimensional Ontology

  • Law I
    • "One and the same phenomenon projected out of its own dimension into dimensions lower than its own is depicted in such a way that the individual pictures contradict one another."
  • Law II
    • "Different phenomena projected out of their own dimension into one dimension lower than their own are depicted in such a manner that the pictures are ambiguous."
I think this is two laws somehow explain what happens when we try to use a model to describe stuff in the real world, we end up representing things inaccurately and incompletely... the funny things that sometimes we seem to somehow change our angle of perspective, and then we realize that the our model is wrong... and try to fix it, and after that we believe that now it is right, but we will never have it right because the map is not the territory. Perhaps a similar problem arises when we try to use ObjectRelationalMapping, we simply lose some of the information because of the perspective we choose to use... Object Orientation forces a particular structure it may not exists... and Relational... trying to see things from a neutral point of view end up not being helpful enough: it seems that humans tend to need to see things from a particular hierarchical perspective at a time, and find it hard to grasp things from all points of view at the same time.

I started to think about this, because as a software engineer I am sometimes asked to create documentation about the software I am building (you know, the typical use cases stuff), and when you have to write a document of the kind a lot of times, the company where you work typically already have some document templates... now, typical document templates have a hierarchical (object oriented?) structure:
  • UseCases
    • UseCase1
      • Scenario 1
      • Scenario 2
      • Actors that participate in the use case
      • Classes (sterotyped as boundary in RobustnessAnalysis) that participate in the use case
      • Classes (sterotyped as control in RobustnessAnalysis) that participate in the use case
      • Classes (sterotyped as entities in RobustnessAnalysis) that participate in the use case
      • ActivityDiagram?
But then, they realize that some times, (for example to decide what uses cases will be affected by the modification of an entity class) they also need a document like this:
  • Classes
      • Classes (stereotyped as boundary in RobustnessAnalysis) that participate in the use case
        • Class 1
          • Use case 1
          • Use case 2
          • Actors interacting with the class
        • Class 2
          • etc,etc.
Both documents have kind of the same internal model, but represent (view it?) form a different perspective, now, the strange thing, is that I do not know of a commecially successful desktop publishing and/or word processing application that allows you to specify such a model so that you can describe your system once and only once and produce documents with several perspectives (I know products like Adobe FrameMaker are supposed to help you with this kind of semantical document structure, but, since they are (AFAIK) internally based on hierarchies, and not relational theory, they do not really allow the user to use all the power of the relational manipulation of data) I think that the problem might be that humans usually organize their ideas following some kind of hierarchical structure... or at least thats the way we are thought to do it at school, perhaps because of the limitations of printed material (a book made of paper can not be queried and reshaped relationally). But, now that we have all this electronic power to help us, we still try to organize stuff in hierarchies (or in messy graphs) and not relationally (internet is a messy graph, no a relational database... am I wrong? XHTML/XML are hierarchical, nobody would accuse them of being relational). We simply find it easier to organize stuff in that way... is it really because that is the natural way in which we think? or is it because we still do not have good enough relational tools to deal with knowledge? is relationally actually about creating a model that is valid from any perspective? or it is more about easily changing the perspective? (But if we build those model from particular perspective, how can we expect relational to produce a model that is valid for more than one perspective?) And finally, why we do not have any Relational Word Processor/ Relational Document Standard

Sunday, March 30, 2008

Alphora Dataphor is OpenSource!

Now that AlphoraDataphor is opensource, I believe a relational reborn could come in the near future... I have been reading the manuals and, while I am an object weenie let me tell you all that I think Dataphor is a very exciting technology I hope it finds the way to make True relational database a buzz word like Ruby and that finally forces big companies like Oracle to make databases truly relational.

Requirements Analysis: Negative Space

A while ago, I was part of a team working on a crucial project. We were confident, relying heavily on our detailed plans and clear-cut requi...