About grammar and syntax on a possible relational language
Date: Tue, 11 Mar 2008 03:55:27 -0700 (PDT)
Message-ID: <3d731fed-1364-48db-9ee8-e22f98017961_at_e60g2000hsh.googlegroups.com>
2 weeks ago, I have posted a sample of the semantics am using for the db core that I am building...I was hoping some comments that would help me sharpen it and make it more effective. Here are a few examples of what the language can do.
Considering the relation EMPLOYEE {EMP#, LNAME, DOB, SALARY}
I write...
- for basic manipulation and definition to define the EMPLOYEE RELATION, I write
[MAKE EMPLOYEE = {EMP# INT, LNAME CHAR, DOB DATE, SALARY INT}]
to extract basic information, I write
PRESENT2D [EMPLOYEE WITH LNAME='SMITH']
which brings a tabular representation of all EMPLOYEES with LNAME
'SMITH'
I can also write...
2) About relation definirion through derivation
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 100000]
to derive a relation RICH_EMPLOYEE from relation EMPLOYEE by adding a
constraint over the salary
then...
PRESENT2D [RICH_EMPLOYEE] to present all EMPLOYEES that have a salary higher than 100000
3) About defining new relations and foreign keys through subtyping. Supposing I want to define a relation VIP_MEMBER {EMPLOYEE} wich are all employees that make more than 100000...I can write
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 100000]
[MAKE VIP_MEMBER = {RICH_EMPLOYEE}] with RICH_EMPLOYEE being *de
facto* a foreign key to RICH_EMPLOYEE and RICH_EMPLOYEE being *de
facto* a foreign key to EMPLOYEE. This makes it easier to decompose
relations for normalization purposes.
I can then write
PRESENT2D [VIP_MEMBER WITH SALARY > 200000] which would have the
system actually benefit from all parent relation attributes. and would
present information in tabular format...
SUMMARY
By running the following at definition time
[MAKE EMPLOYEE = {EMP# INT, LNAME CHAR, DOB DATE, SALARY INT}]
PRESENT2D [VIP_MEMBER WITH SALARY > 200000] --> 2 implicit JOINS.
What do you guys think. I initially thought about using SET instead
but I want to keep the idea of relation as a construct which is why I
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 100000]
[MAKE VIP_MEMBER = {RICH_EMPLOYEE}]
I am defining 3 relations differently and applying operators while
establishing a de facto foreign key between VIP_MEMBER and
RICH_EMPLOYEE as well as RICH_EMPLOYEE and EMPLOYEE. I use this de
facto references to be able to write
Regards... Received on Tue Mar 11 2008 - 11:55:27 CET