Re: Lessons (was Re: Objects and Relations)

JOG wrote:

> On Feb 12, 6:27 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>

>>Bob Badour wrote:
>>
>>>What lessons have you learned that you might want to relay? (Please
>>>enumerate.)

Very interesting. I generally ascribe that result to navigation. Can you elaborate on how encapsulation causes it too?

> 7. Query neutrality is important for good management of shared data.
> 8. Do not confuse conceptual/physical/logical layers.
> 9. Purely Navigational Databases are inferior to Declarative
> Databases.

Two points: First, #9 extends far beyond data management. Second, it's not really the database that is navigational or declarative, is it? Isn't it the formalism.

> 10. Nulls are both nonsensical and generate logical errors.
> 11. There are two types of updates masquerading as one - domain
> redefinitions/proposition replacement,

Interesting. Can you elaborate?

> 12. RM redefines some mathematical concepts - tuple/relation/cross-
> product.
> 13. Semi-structured data has no definition.
> 14. Keys are not entity identifiers, nor vice versa. Keys are the
> antecedents of material implication.

Very well put.

> 15. Surrogates are still attributes, just unobserved ones.
> 16. Combining XML with xlink and xpath to create a data model is like
> grafting arms and legs on to a hamburger.

LOL Well said!

Of the 16 lessons above, which three cause you the most frustration?

>>>What audiences do you try to reach with these lessons?

Are the colleagues other teachers? What level of student do you teach? (Approximate age range and some indication of their scholastic background.)

One must tread very carefully when trying to reach colleagues. Some of them will be so entrenched in some fad or technology that all one can do is wait for them to become disenfranchised in due course. The best one can do is drop a few hints or leading questions and let them mull until it becomes their own idea.

>>>What approaches have you used?

Seeing that you did not fill in this section, I suggest you perhaps have to examine your approach more closely.

>>>What other approaches are you aware of?

Again, perhaps your approach frustrates you.

>>>What other audiences might exist?

I asked this in case your choice of audience leads to frustration. If so, you might consider choosing a different audience.

>>>What big questions remain unanswered in your mind?

In what ways might a fully relational language prove intractable?

> 2. Is it possible to generalize Codd's insights without relations.

Other than the insight that one can use relations for data management, what insights do see?

> 3. Is an MV system (ignoring current suggestions and implementations)
> ever justifiable.
> 4. View updatability.

This one hinges on what one considers 'theoretically updatable'. In the past, I think people have interpreted that to mean any view where an appropriate theory can determine what updates to make. I now interpret 'theoretically updatable' to mean 'updatable unless theory proves no consistent update can exist'.

Sometimes a dbms will be able to determine only one consistent update exists, in which case, the dbms can just perform the update. In other cases such as the union view discussed here a few days ago, several consistent updates might exist and the dbms should allow the designer to specify which of them to use.

Just as project/join normalization minimizes the use of general wff's for integrity, the _Principle of Orthogonal Design_ minimizes the situations requiring the designer to choose among consistent updates.

> 5. Is it a valid approach to consider a stuctural layer between
> logical and physical.

One can divide the physical layer into as many layers as one wants. The conceptual/logical/physical distinction serves to describe the place and the role of the logical or formal. I would expect any implementation to further divide the physical into multiple layers. In fact, I would expect any implementation to divide various components within the physical implementation into multiple layers. Transport layers don't really apply to the storage components and block allocation doesn't really apply to the network.

> 6. Is it possible to provide a mechanism to prevent the same mistakes
> continually occurring in IT.

That will happen with time as the industry matures. Think of how many people died of sepsis (especially post-operative) before the medical industry matured.

It will take our industry much longer to mature because the disposal costs are so low.

>>>How do you measure success?

The first and third strike me as very important. When you gain insight into the capabilities of your students, you will gain the acceptance necessary for serenity.

Take Neo for example. Years ago, I concluded he cannot think in the abstract. He understands everything in concrete terms only. Hence, his focus on syntax to exclusion of all else. I also concluded he has severe comprehension problems with written english.

I expected he would never learn or improve. Recently, I have seen one or two excerpts of his writing that show some improvement. Not much improvement and it has taken several years, but enough of a qualitative improvement that I noticed at least a little more polish.

I cannot take any credit for his minor improvement, but I count that as a success because it makes me feel good to see it. He exceeded my expectations. Received on Tue Feb 13 2007 - 16:11:07 CET