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...

1) 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}]
[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

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
use the verb MAKE.  I am hoping the above example wil draw some
constructive comments..

Regards...