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

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK

On Mar 11, 4:55*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Short comment/question on the syntax:

PRESENT2D - does the name imply that there will be other n-dimensional
presentations available (PRESENT3D, e.g.)?

Why not:
[MAKE RICH_EMPLOYEE = {EMPLOYEE WITH SALARY > 100000}]
(with curly braces around the derivation expression)? It seems a
little "off" to use them only sometimes.

Regarding derived relation definitions, what would the expected
behavior be for VIP_MEMBER if the derivation for RICH_EMPLOYEE were to
change after VIP_MEMBER was declared, e.g.:
[MAKE RICH_EMPLOYEE = EMPLOYEE WITH SALARY > 150000]

My assumption is that the VIP_MEMBER relation would "dynamically"
derive from the new definition. Is this correct?

TroyK