Re: Relational vs network vs hierarchic databases
Date: Fri, 12 Nov 2004 17:37:08 GMT
Message-ID: <8x6ld.14$m36.6_at_trnddc02>
"Dan" <guntermann_at_verizon.com> wrote in message
news:7a6ld.253$h15.215_at_trnddc07...
> >
>>>What does orthogonal mean? Does it mean that the intersecting vectors of
>>>relational and performance never ever really intersect? No.
>>
>> It means that they are mutually independent.
>>
>> It is a rather frequent term in computing science. See this:
>>
>> http://dictionary.reference.com/search?q=orthogonal%20instruction%20set
>>
> Alfredo,
>
What the heck.
Here is something I wrote about this subject a while back... apologies for its length.
- RE: Orthogonality and its definition **
Steven provided an example definition that I found somewhat misleading with
"mutually independent; well separated; sometimes irrevalent to...". The
example that follows the definition offsets the confusion to some degree,
yet I still crave a deeper sense of precision. In mathematics, orthogonal
does imply a large degree of independence, but not total independence.
Rather, orthogonal can be conceptualized as two totally independent lines
that intersect at a single point, or as the point where a tangential line
meets the circumference of a circle. The implication here is that, when two
things are orthogonal in theory, they are totally independent in terms of
model and implementation except at the point where the two should meet, a
relatively miniscule area in comparison to the modelling space of either
line.
For example, to fall back on previous exposure to the term, some
theoreticians claim that the relational model of data should be orthogonal
to data types (domains, classes, etc). This became especially relevant at
the advent of object-oriented and object-relational databases over ten years
ago. This principle means in an informal sense that a data type designer
should be able to implement a type system as arbitrarily complex as he or
she wants, whether it be using strong or weak typing, user-defined types,
hierarchies or lattices, inheritance and multiple inheritance, nested
tables, etc., and the relational model will view and operate on those types
in exactly the same way -- by treating instance values of types as "values".
Thus, an value attribute might be a complex value that is a representation
of an entire computer system or commercial corporation, and the relational
model only sees it as a "value", distinguishable from other values of the
same type, and treat it in the exact same way as it would a "simple" type,
such as a character string or integer.
As a result of this orthogonality, the efficacy and consistency of the relational model itself is totally isolated from the whims and fancies of type systems (i.e. relational algebra and relational calculus are still relevant). A change in how types are defined, modelled or implemented will have absolutely no effect on the logical model itself in terms of logical structures, logical manipulation, and integrity aspects, except for where the relational model must interpret type representations in distinct values (the point of intersection).
When contrasting my previous exposure to the word, orthogonality, with the use of the word in the context of Tanenbaum's discussion of ISA instructions, I think some profound and fundamental concepts can be extracted:
a.. The distinction between value and representation. b.. The distinction between model and implementation. c.. The value in reserving optimization activities to the lowest level ofimplementation possible.
The problem with introducing this ideal in its purest sense at this level is that representation and value are so closely aligned, as are model and implementation. So really, I think that relative degrees of orthogonality are at issue, rather than absolute terms. Designers simply don't have the same luxury of ignoring spatial representations of a value like a theoretician would. In SCO, Tanenbaum gives a pretty succinct (in contrast to me) definition of what he means by orthogonality when he writes, "from a software point of view, instructions and addressing should have a regular structure, with a minimum number of instruction formats" (p. 332), and "all opcodes should permit all addressing modes where it makes sense" (p.332). Upon my first read of the texbook, my impression of achieving better orthogonality in the context of ISA instructions is that a level of generality should be the goal where opcodes (operations) should be specified with as little embedded knowledge of addressing modes and format as possible, and that address and address modes should be designed and implemented with as little consideration for specific opcodes as possible.
An example might be that the ISA design team be divided into two people, person A for opcodes, and person B for address modes. Before they start, person A says to person B, "I'll be designing about 256 operations for three, two, and one operands. I expect to use operands that address up to 64GB of memory, all 64 registers, and using any combination of modes (direct, indirect, offset), but never mind what the opcodes are right now." Person B responds with "I'll be providing an addressing scheme that allows you to access any value held in the memory hierarchy no matter what the operation you give is, you merely have to specify the address and mode. Don't worry about what the scheme is now, just be rest assured that you I'll give them to you after we are done."
The two go off and model their two respective areas of responsibility and then come back and say, "Here is the list of operations," or "Here is the addressing scheme. You can access any memory using any mode, and you can treat all registers the same."
In the strictest sense, this type of orthogonality cannot happen. Indeed, the opposite can happen. Tanenbaum writes in SCO, "a large portion [of opcode] bits in aprogram are used to specify where operands come from rather than what operations are being performed on them." In such cases, it seems orthogonality is thrown out the window because special intelligence about the memory structure and addressing scheme is pre-encoded into the opcode.
Later in the discussion, Steven asked: "Is orthogonality the opposite of instructions which have expanded opcodes? This seems true, what may be an address for one instruction may be part of an opcode for another instruction."
I think Steven was very insightful with this statement. With expanding opcodes, we encode not only the meaning of the operation in the opcode, but also the format of address and mode in the instruction itself. Thus, there is a dependency on information in the opcode to correctly interpret the addressing scheme that belies a lack of independence and flexibilty.
Dr. Porto recently added, "If we apply the concept of orthogonality in the overall sense throughout the entire ISA, we would have to conclude that ALL instructions would have the same field, the same size in bits. This could be an enormous limitation...."
Yes, I agree, but this scenario is taking orthogonality to an extreme. We might still be able to achieve some orthogonality to a lesser degree without sacrificing too much.
In any case, if one weighs achieving ultimate performance enhancement by introducing complexity and dependencies in the instruction to the long term benefits of a clean interface and clearer decoupling, we might be able to assume the long term view could possibly provide a great difference in cost savings. Evidence of this might be possibly demonstrated with the transition of Intel from IA-32 to IA-64 architectures.
There is tension between the the need to squeeze out the last ounce of performance and efficiency using ad-hoc work arounds and a "more" orthogonal design, and I think the desire for a strong income sheet in the next quarter versus over the next decade wins out. The stronger pull of survival for today in the industry is well-expressed by Tanenbaum when we writes, "of course, even far-sigthed designers may not be able to make all the right chioices. And even if they could, they have to deal with the short term, too. If this elegant ISA is a little more expensive than its current ugly competitors, the company may not survive long enough for the world to appreciate the elegance of the ISA." I would translate this to mean that true orthogonality for an ISA instruction set is the face of a baby that only a true academic could love. :-)
- Dan