Principle of Orthogonal Design

#41

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

Quote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# IsSalaried IsCommissioned
==== ---------- --------------
1 Y N
2 N Y
3 Y Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} PK(name)
ownership = {owner, dog} FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
<Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.

#42

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#43

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#44

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#45

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#46

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#47

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#48

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#49

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen

#50

On Jan 10, 5:32*am, DM Unseen <dm.uns... (AT) gmail (DOT) com> wrote:

Quote:

On 10 jan, 03:23, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Jan 9, 9:01 pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:

On Jan 8, 6:51 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

I was wondering what your current stances towards the principle of
current design is cdt - info about the POOD is actually pretty sparse
on google, which has not helped my own understanding. I gather that
Date has realigned his opinion - although what to I know not - and
that Darwen rejected the original POOD paper outright given that
McGovern posits that:

R1 { X INTEGER, Y INTEGER }
R2 { A INTEGER, B INTEGER }

violates the principle, whatever the relations' attribute names.
Instinctively it does seem rather odd that a predicates such as:

* on Day:X the shop had noCustomers:Y
* on Roll:A, the dice showed the Number:B

cannot share the same database. Have I interpreted the debate
correctly? Any insights or corrections are, as ever, appreciated -
POOD is certainly thought provoking, and the concept that an update
need not require specifcation of a table name is an interesting one.

I thought I'd work up an example that illustrates part of McGovern's
argument (as I understand it). Comments and corrections are most
welcome:

Assuming we want to represent employees and their status as either
salaried, commissioned, or both, we might come up with the following
design (assuming the most obvious interpretations):

Table: Emp
Emp# *IsSalaried *IsCommissioned
==== *---------- *--------------
1 * * Y * * * * * N
2 * * N * * * * * Y
3 * * Y * * * * * Y

Another possible design could be:
Table: Emp
Emp#
====
1
2
3

Table: SalariedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
1
3

Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
Emp#
====
2
3

Although we can derive the same information from each design, the
former is to be prefered because the latter violates POOD (two tables
with identical headers, even semantically speaking). Additionally, it
requires that we inspect the tables' names in order to gather the full
meaning of the propositions.

TroyK

I like this example Troy - It is both concise and clear. I was just
mulling and came up with a possible schema for a "kennel club", that
might help clarify some of the issues I'm seeing.

owners = {name, age, joined} PK(name)
dogs = {name, age, joined} *PK(name)
ownership = {owner, dog} *FK(owner, owners.name) FK(dog, dogs.name)

As it stand this is clearly not in POOD, and a proposition such as
Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
know in real life what a proposition refers to.

1) I know the context implicitly of <Bess, 18, 01/08/08> (from
previous conversation, who i'm talking to, etc)
2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
years old and joined the kennel club on 01/08/08"

I don't think we can deign to rely on a computer ever being able to
cope with implict context (leave that to the CYC people to bang there
heads against ad infintum), so that appears to leave me with option 2.
In turn, I see two ways of integrating this explicit surrounding
context.

1) Via role names so, the proposition becomes:
There is a dog with (dogsName:Bess) of (age:18) and who (joined:
01/08/08)

2) Via another attribute:
There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
01/08/08)

Which is preferable, and why that would be so I am uncertain. It would
be easy to say "this is all just a design decision", but I'm starting
to think there might be some sort of salient lesson in there.
Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Could be something like

joiners= {name, age, joined, type} PK(name,type)
where type in {'Owner','Dog'}

ownership = {owner, dog} *FK(owner, joiners.name AND
joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')

This could still be generalised further bit I think this would be in
POOD.

And yes POOD implies "semantical" types and not syntactical.
This could also imply that we are dropping too much information in the
conversion from semantical (conceptual) models like NIAM/ORM to
logical models like the relational models.

DM Unseen- Hide quoted text -

- Show quoted text -

You make a good point about the possible lossy conversion from
conceptual to logical (inasmuch as "encoding" information in the
relations' names implies this loss).

I'm wondering if we should consider this type of POOD violation a non-
issue, though. In SQL, we always need to specify which table we're
talking about (both for updates and data retrieval), so that forces
one to be specific about the propositions they're interested in. Even
in a more pure RM implementation, we would need to reference which
relvar in particular we're updating (or deriving from).

In practice, I use POOD more to inform my design decisions around
constraint-based table/view partitioning.

TroyK