 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / April 2004Date's First Great Blunder
C. J. Date has written about what he calls "The First Great Blunder" related to this question: What concept is it in the relational world that is the counterpart to the concept of object class in the object world? He suggests that there are two answers given: domain = object class or relvar = object class. He then says that the first equation is obviously right and the second wrong. Classes are types and domains are types, but relvars are variables and, therefore, not types, so QED. The idea, it seems, is to rid Java programmers of the notion of using classes to define "relations" or records. I'm guessing I'm not the only one who doesn't buy Mr. Date's argument. I'll toss out one of the way-too-many-thoughts buzzing in my head on this topic. How about this equation: Class = Metadata A class is a spec/template -- not a variable nor an object. There can be metadata for a type and metadata for a relation/record and classes corresponding to either. Do many folks agree with Date on this point or is this one of his lone-ranger attempts to push against the OO folks? --dawn et al: Do people respond to Dawn because they don't know any better? Maybe they think they will get laid, Timothy J. Bruce uniblab@hotmail.com </RANT> > et al: > [quoted text clipped - 4 lines] > uniblab@hotmail.com > </RANT> Ah, so THAT'S why you responded is it? > et al: > [quoted text clipped - 4 lines] > uniblab@hotmail.com > </RANT> Nice. With a great deal of luck on our part, that will have been your final post. > Nice. With a great deal of luck on our part, that will have been your final > post. She napped the line while I was reeling her in, so I'm done with her for good. She just entered Ye Olde Kill File, Timothy J. Bruce uniblab@hotmail.com </RANT> Being the champion at topic-raising comes with a responsability. I don't like the title. While I don't like object bashing, person-bashing is no improvement. So for the next thread: Your content deserves better subject lines. Please. > C. J. Date has written about what he calls "The First Great Blunder" related > to this question: What concept is it in the relational world that is the > counterpart to the concept of object class in the object world? The complementing question would be: What concept is it in the object world that is the counterpart to the concept of relation in the relational world? That is, *if* these two worlds are separable. Are they? If they are, are they the only ones or are there more worlds? Hm... the subject line bothers me more than I thought. But I won't s/te/wn/ So only 2 Eurocents for now. Later. :-/ Being the champion at topic-raising comes with a responsability. I don't like the title. While I don't like object bashing, person-bashing is no improvement. So for the next thread: Your content deserves better subject lines. Please? > C. J. Date has written about what he calls "The First Great Blunder" related > to this question: What concept is it in the relational world that is the > counterpart to the concept of object class in the object world? The complementing question would be: What concept is it in the object world that is the counterpart to the concept of relation in the relational world? That is, *if* these two worlds are separable. Are they? If they are, are they the only ones or are there more worlds? Hm... the subject line bothers me more than I thought. But I won't s/te/wn/ So only 2 Eurocents for now. Later. :-/ If I put Date's terminology of "First Great Blunder" in quotes is that better? I've read his treatment and name of this opinion of his in multiple places, so I thought it might be recognizable. Keeping the quotes off just made me smile, so I thought it might make others smile too. Cheers! --dawn > Being the champion at topic-raising comes with a responsability. > [quoted text clipped - 18 lines] > So only 2 Eurocents for now. > Later. :-/ > If I put Date's terminology of "First Great Blunder" in quotes is that > better? I've read his treatment and name of this opinion of his in multiple > places, so I thought it might be recognizable. Keeping the quotes off just > made me smile, so I thought it might make others smile too. Cheers! --dawn I must have been really grumpy this morning. Sorry :-) > I don't like the title. IMO it is only a little joke. > While I don't like object bashing, But there are many things to fix in the OO world. > The complementing question would be: What concept is it in the object > world that is the counterpart to the concept of relation in the > relational world? Good question. The counterpart of both relation and relvar is "collection object", but they are not directly supported by the languages and they don't have an algebra or calculus. > That is, *if* these two worlds are separable. Are they? The problem is that the OO world is extremely fuzzy. There are literally millions of OO worlds. Regards Alfredo > C. J. Date has written about what he calls "The First Great Blunder" related > to this question: What concept is it in the relational world that is the [quoted text clipped - 8 lines] > classes to define "relations" or records. I'm guessing I'm not the only one > who doesn't buy Mr. Date's argument. You'd be right, it goes against the grain for many OO folks. > I'll toss out one of the way-too-many-thoughts buzzing in my head on this > topic. How about this equation: [quoted text clipped - 7 lines] > Do many folks agree with Date on this point or is this one of his > lone-ranger attempts to push against the OO folks? --dawn I agree with Date - when I first saw him present this at a seminar back in 1997 it struck me as a obviously true, once pointed out. But it isn't really an attack on the OO folks, rather it is a defence of the relational model AGAINST attacks by the OO (or OR) folks, who have said that the relational model is at fault and should be fixed by the "relvar = object class" approach. However, it is true that in the process of doing that, Date has pointed out flaws in the thinking behind OO - flaws which he very much wants to keep out of the relational model! > C. J. Date has written about what he calls "The First Great Blunder" related > to this question: What concept is it in the relational world that is the [quoted text clipped - 20 lines] > Do many folks agree with Date on this point or is this one of his > lone-ranger attempts to push against the OO folks? --dawn I do agree with him, although his use of the term "counterpart" isn't exactly right. Part of his agenda is pointing out the overloading in the use of some OO terms, and the vagueness in others (not necessarily a disjoint set). Using terms like "spec", "metadata", and "template" requires some definition as well. What is metadata for a type, other than the type itself? Relations have types, as do tuples (simply and not very precisely, the relation has a heading which has the same type as its allowable tuples). In any event, the crux of his argument is that types are to relations what nouns are to sentences, separating the values we can talk about from what we're saying about them. OO allows excessive and unnecessary leniency, in that an object is a variable, or rather a record with both variables and functions, and the values of its variables can be other variables, etc. etc. This is confused in ways that force the use of patterns and conventions such as immutability / "value classes", enumerations, factories and factory methods, and many other techniques enforcable not via automation, but purely via human obedience and review. Aliasing is a major problem in OO applications, and has spawned research which, interestingly enough, has many different solutions. This suggests, although the field is young, intractability. So if you suggest that classes can correspond both to types and to relations/records, in what way do we prevent the varying needs of each from overlapping in destructive ways? In the OO community there are patterns galore to govern how you build your classes, some corresponding more to types and some more to relations/records (and then more to helpers, utilities, managers, DAOs, ad nauseum). Unfortunately, there's also the opportunity to spawn bastard hybrids - more invitation than opportunity, really. In what way does the concept of class then help, if we have to take measures to coral our classes back into the appropriate camp? And if we work best with classes classified as either collection variable or as type, then why fuse the two together? So far we've spoken only of types, both "basic" (domains) and tuple types (records). A relation (specifically a relvar) has not only a type but a value. Does a class correspond to the "type of the relvar" (e.g. the "metadata"), or to its current value, the tuples currently stored in it? I'll close with one of my favorite quotes. Oh, I can't pick just one, so here are a bunch of related ones from Dijkstra: "... all unmastered complexity is of our own making; there is no one else to blame and so we had better learn how not to introduce the complexity in the first place." "The sore truth is that complexity sells better. (It is not only the computer industry that has discovered that.) And it is even more diabolical in that we even use the complexity of our own constructs to impress ourselves." "It is a genuine sacrifice to part from one's ingenuities, no matter how contorted. Also, many a programmer derives a major part of his professional excitement from not quite understanding what he is doing, from the daring risks he takes and from the struggle to find the bugs he should not have introduced in the first place." "... pay the greatest possible care to the choice of concepts in terms of which we have built up our theories: we know we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making." "The moral is clear: prevention is better than cure, in particular if the illness is unmastered complexity, for which no cure exists." - erk P.S. I'll add, to avoid the stamp of anti-object bigot, that I've been programming nearly exclusively in Java/J2EE for the past 4 years, so while I will never claim to be an expert, I am at least well-versed in the practice and the literature. >What is metadata for a type, other than the type itself? I disagree. A type is a set of values and a set of operators but the metadata of a type are things like the name of the type, the name of the possreps, the name of the possrep's components and their types, etc. Regards Alfredo > >What is metadata for a type, other than the type itself? > > I disagree. A type is a set of values and a set of operators but the > metadata of a type are things like the name of the type, the name of > the possreps, the name of the possrep's components and their types, > etc. OK, I can buy that. I think for purposes of this discussion that we can ignore those other things - though come to think of it, POSSREP will probably creep into the discussion. I was trying to start simply. >> >What is metadata for a type, other than the type itself? >> [quoted text clipped - 6 lines] >ignore those other things - though come to think of it, POSSREP will >probably creep into the discussion. I was trying to start simply. Now I understand you. The metadata of a type can be extracted from the type definition. Regards Alfredo > He suggests that there are two answers given: domain = object class or > relvar = object class. He then says that the first equation is obviously > right and the second wrong. Classes are types and domains are types, but > relvars are variables and, therefore, not types, so QED. It's all very obvious. > The idea, it seems, is to rid Java programmers of the notion of using > classes to define "relations" or records. The idea is to rid programmers of making great blunders. > I'm guessing I'm not the only one > who doesn't buy Mr. Date's argument. The vast majority of the OO coders reject the evident when it is against the dogma. > I'll toss out one of the way-too-many-thoughts buzzing in my head on this > topic. How about this equation: [quoted text clipped - 4 lines] > metadata for a type and metadata for a relation/record and classes > corresponding to either. A class is a type and "object" is the mix and confusion of the "variable" and "value" concepts. Metadata is data like any other data, and it should be represented in the form of relations. > Do many folks agree with Date on this point or is this one of his > lone-ranger attempts to push against the OO folks? This is an attempt to educate the misleaded and misinformed practicioners. Regards Alfredo > > He suggests that there are two answers given: domain = object class or > > relvar = object class. He then says that the first equation is obviously [quoted text clipped - 13 lines] > The vast majority of the OO coders reject the evident when it is > against the dogma. OO, like relational database theory, does have religious followers, but I'm guessing that most practitioners of each are more pragmatic than dogmatic, working to develop and maintain information systems. It "works" to specify a "record" by way of an OO class and include persistence methods in the class -- and that is what's "evident" to "the vast majority of the OO coders", I suspect. > > I'll toss out one of the way-too-many-thoughts buzzing in my head on this > > topic. How about this equation: [quoted text clipped - 7 lines] > A class is a type and "object" is the mix and confusion of the > "variable" and "value" concepts. Is a class a type or a definition of a type? A type, being a domain, is a set. A class is a specification where the set of all objects that can be instantiated using that specification constitute the domain (or the set that actually ARE instantiated, depending on your definition of domain). > Metadata is data like any other data, and it should be represented in > the form of relations. Or in the same for as other data, agreed. Code is metadata.. > > Do many folks agree with Date on this point or is this one of his > > lone-ranger attempts to push against the OO folks? > > This is an attempt to educate the misleaded and misinformed > practicioners. Your post is? Date's opinion is? What is? smiles. --dawn >> The vast majority of the OO coders reject the evident when it is >> against the dogma. > >OO, like relational database theory, does have religious followers I disagree. Relational database theory is a branch of maths and OO is a set of fuzzy and contradictory guidelines that lacks any consensus. It is clear that the second is a lot more religious followers prone. >, but I'm >guessing that most practitioners of each are more pragmatic than dogmatic, Many practicioners does not have knowledge enough to be pragmatic and they are forced to be dogmatic. >working to develop and maintain information systems. It "works" to specify >a "record" by way of an OO class and include persistence methods in the >class -- and that is what's "evident" to "the vast majority of the OO >coders", I suspect. What is evident is that the equation: type = variable does not work. >> A class is a type and "object" is the mix and confusion of the >> "variable" and "value" concepts. > >Is a class a type or a definition of a type? A class is a type and a class definition is a type definition. Many people confuse a class with its definition. > A type, being a domain, is a >set. A class is a specification where the set of all objects that can be >instantiated using that specification constitute the domain (or the set that >actually ARE instantiated, depending on your definition of domain). A class being a type is a set (among other things). >> Metadata is data like any other data, and it should be represented in >> the form of relations. > >Or in the same for as other data, agreed. Code is metadata.. No, code does not have any relationship with metadata. The metadata of a type is the name of the type, the number of the possible representations and their names, the name of the representation's components, their types, etc. >Your post is? Date's opinion is? What is? smiles. --dawn My post is my post :) Regards Alfredo > >> The vast majority of the OO coders reject the evident when it is > >> against the dogma. [quoted text clipped - 4 lines] > a set of fuzzy and contradictory guidelines that lacks any consensus. > It is clear that the second is a lot more religious followers prone. Not to me, it isn't. Mathematical models are simply models/metaphores. The discipline of "doing" relational theory could be seen as mathematics, but the application of this mathematics to the discipline of application software development has to do with a belief that this mathematical model has something to do with the engineering effort underway. > >, but I'm > >guessing that most practitioners of each are more pragmatic than dogmatic, > > Many practicioners does not have knowledge enough to be pragmatic and > they are forced to be dogmatic. Yes, it is a shame that those fresh out of higher ed do seem dogmatic about both relational databases as being the best databases and OO as the best programming languages, based not on practice, but the sermons they have heard in the classroom and read in their text books. The advocates in both of these areas have a pitch that resonates with professors and/or text book writers & publishers. I think both OO and relational theory ought to be taught side by side with alternatives and pros & cons of each. There is not one correct mathematical model for data, metadata, nor functions (by whatever names). > >working to develop and maintain information systems. It "works" to specify > >a "record" by way of an OO class and include persistence methods in the > >class -- and that is what's "evident" to "the vast majority of the OO > >coders", I suspect. > > What is evident is that the equation: type = variable does not work. I agree. > >> A class is a type and "object" is the mix and confusion of the > >> "variable" and "value" concepts. [quoted text clipped - 4 lines] > > Many people confuse a class with its definition. Me, for exampe. The term is used both ways. I prefer to think of a class as a specification for (that is, metadata regarding) a domain/type. What we can "see" of the class is a specification "in writing" (e.g. MyType.java) and a compiled version of that spec (e.g. MyType.class). The set of objects that could be instantiated by way of this specification of the type is more abstract. So, I prefer using the term "class" as a definition/spec of a type and the term "type" as the more abstract (invisible) set. I think this helps avoid some of the confusion in terms, perhaps, maybe, a little bit. > > A type, being a domain, is a > >set. A class is a specification where the set of all objects that can be > >instantiated using that specification constitute the domain (or the set that > >actually ARE instantiated, depending on your definition of domain). > > A class being a type is a set (among other things). See how confusing that terminology is? > >> Metadata is data like any other data, and it should be represented in > >> the form of relations. > > > >Or in the same for as other data, agreed. Code is metadata.. > > No, code does not have any relationship with metadata. really? What about the declarative code that specifies constraints on the data -- is that metadata? If the same information is in a procedural language, does it cease to be metadata at that point? > The metadata of > a type is the name of the type, the number of the possible > representations and their names, the name of the representation's > components, their types, etc. maybe that's the meta-metadata? --dawn > There is not > one correct mathematical model for data, metadata, nor functions (by > whatever names). "Correct"? Is that even possible? > > Many people confuse a class with its definition. > [quoted text clipped - 6 lines] > type and the term "type" as the more abstract (invisible) set. I think this > helps avoid some of the confusion in terms, perhaps, maybe, a little bit. So a class is simply an implementation of a type? That seems to be what you're getting at. > > No, code does not have any relationship with metadata. > > really? What about the declarative code that specifies constraints on the > data -- is that metadata? If the same information is in a procedural > language, does it cease to be metadata at that point? Yes, I'd say so. The line between "procedural" and "declarative" may be somewhat hard to define (at least I haven't seen a formal definition), though most of us would know either to see it. - erk > > There is not > > one correct mathematical model for data, metadata, nor functions (by > > whatever names). > > "Correct"? Is that even possible? Nope, unless you think it is possible to have a correct metaphor. > > > Many people confuse a class with its definition. > > [quoted text clipped - 13 lines] > So a class is simply an implementation of a type? That seems to be what > you're getting at. "Type" is not my favorite word, but if, indeed, it is the very same word as "domain" then it seems to me that a class is the specification of a domain. The class itself is not the domain "set" but, rather, an object of software that specifies the domain. I suppose that one could equate a specification with a set and surely there is a mapping (a function) from the spec to the domain. > > > No, code does not have any relationship with metadata. > > [quoted text clipped - 5 lines] > somewhat hard to define (at least I haven't seen a formal definition), > though most of us would know either to see it. What gives "declarative" a description of metadata that OO or functional or procedural or whatever other languages would not be able to claim? --dawn >"Type" is not my favorite word, but if, indeed, it is the very same word as >"domain" then it seems to me that a class is the specification of a domain. Type is a word with a long pedigree and a lot more precise than class. By the way, strictly speaking, domain is not exactly the same as type. A domain is a type minus the operators. Regards Alfredo > Type is a word with a long pedigree and a lot more precise than class. > By the way, strictly speaking, domain is not exactly the same as type. > A domain is a type minus the operators. I would suggest that operators are not necessarily part of the type definition. At least there are operators that could belong to many types, such as speed(distance, time). regards, Lauri Pietarinen >> Type is a word with a long pedigree and a lot more precise than class. >> By the way, strictly speaking, domain is not exactly the same as type. >> A domain is a type minus the operators. > >I would suggest that operators are not necessarily part of the type >definition. Then they are part of what? > At least there are operators that could belong to many >types, such as >speed(distance, time). Agreed, but what is the problem? An operator could be part of several type definitions. IMHO Tutorial D type definitions are actually domain definitions because they don't include the operators (and it is a good thing). Regards Alfredo > > > There is not > > > one correct mathematical model for data, metadata, nor functions (by [quoted text clipped - 3 lines] > > Nope, unless you think it is possible to have a correct metaphor. Nope, not me. > > > > Many people confuse a class with its definition. > > > [quoted text clipped - 20 lines] > "Type" is not my favorite word, but if, indeed, it is the very same word as > "domain" then it seems to me that a class is the specification of a domain. I think Alfredo suggested that domain was type without the operators. Could well be the case, but I'll just stick with type and only mention the operators when they're important. I'd say a class CAN BE an implementation of a domain. But classes must also be other things, because not every bit of functionality and data in a system is a domain. Specifically, relations, which speak of values (of their attribute types), but are not in and of themselves types. (strong caveat here - it strikes me that I don't have the precise language to differentiate attribute types from relation heading types, since Date does agree, of course, that relations have types. I'll have to think about this more. Tuples are values of a type, and so are relations, so there are TUPLE and RELATION type generators, and they have operators as well - the operators on relations are the algebra. Or am I oversimplifying? Sorry, just mumbling to myself...) > The class itself is not the domain "set" but, rather, an object of software > that specifies the domain. I suppose that one could equate a specification > with a set and surely there is a mapping (a function) from the spec to the > domain. Yes, although most developers use them strictly as variables, and abuse them horribly. I like the line that relational theory draws between types and relations. > What gives "declarative" a description of metadata that OO or functional or > procedural or whatever other languages would not be able to claim? --dawn With OO and procedural, the metadata must be separately maintained or laboriously derived from the code - not an easy process. Functional is a different matter I lack the expertise to discuss much, but it's also declarative in that lazy vs. strict implementations can decide on the order of evaluation of expressions (unlike procedural). With "declarative" (correctly placed in quotes), what you declare is the "metadata" (although we're not really talking about data here). It's just executable (e.g. a higher level of abstraction). Keep in mind that OO is simply procedural with some packaging (although I don't know about the inclusion of objects in Lisp and other non-procedural languages). And, as a final caveat, you can induce "proceduralism" to some degree in many functional and logic languages. They just don't mandate it, and make it awkward. Anyone proficient in those languages, feel free to correct me... - erk <snip> > > What gives "declarative" a description of metadata that OO or functional > or > > procedural or whatever other languages would not be able to laim? --dawn > With OO and procedural, the metadata must be separately maintained or > laboriously derived from the code - not an easy process. Functional is a [quoted text clipped - 8 lines] > don't know about the inclusion of objects in Lisp and other non-procedural > languages). And isn't declarative just specifying the parms for some proprietary database's procedural code to apply? I do think that different languages have different advantages and disadvantages, so I'm not language-agnostic, but I don't see anything decidedly different whether I spec constraints in one language or another. If one is metadata, so is the other. And for software developers who are writing database-independent code, the constraints often need to be pushed to the underlying databases from some other repository with some other language (often proprietary to the software developer). So a rules database for all constraints makes sense. Then if a "service" is able to maintain the data and apply these rules, then using the DBMS for storing and managing such constraints seems like unnecessary double work (sorry for going off on this tangent) cheers! --dawn > <snip> > And isn't declarative just specifying the parms for some proprietary > database's procedural code to apply? Assuming that statement is right, that's still a big difference. The runtime executes one machine-code processor-specific instruction at a time (basically), which is what CPUs do. But that looks nothing like the source code (though today they tend to have more in common than they should), and the source code looks nothing like the specification, which looks nothing like the user manual. Think about it this way: the user manual, if accurate and detailed, "looks like" the external appearance of the system at runtime. But the machine code being executed looks nothing like that. A true specification describes, abstractly but accurately and precisely, the effects of the system. "Declarative code" describes the result, not how to get there. The procedural part is in the engine that processes the declarations, not in the declarations themselves. Among other things, this allows the engine to optimize (much as compilers these days can apply more optimizations better than most assembly programmers), and even to optimize based on runtime characteristics (e.g. how the system is being used), like Oracle can optimize its access paths based on stats generated from the actual queries run. Little of that is possible with procedural code, where the programmer has to specify not only what to do but how to do it. > I do think that different languages > have different advantages and disadvantages, so I'm not language-agnostic, > but I don't see anything decidedly different whether I spec constraints in > one language or another. I'd be surprised if you spec constraints at all - you code, like most of us, but where is the spec? The code is not the spec. The spec is probably in your head as you're coding, but not making it explicit means it's easy to forget about it and violate it in your code. > If one is metadata, so is the other. Not true. Think of a SQL query vs. a COBOL program accessing ISAM data. > And for software developers who are writing database-independent code, the > constraints often need to be pushed to the underlying databases from some [quoted text clipped - 3 lines] > DBMS for storing and managing such constraints seems like unnecessary double > work (sorry for going off on this tangent) I think it's a useful and related one. Yes, I agree, a "rules database" is what's needed. Why you've separated that from the DBMS I don't know... I wish I could use the relations defined in my DBMS directly in my code! Or rather, specify the constraints somewhere and have them published everywhere they're relevant. I think the problem is that languages aren't relational enough - I can imagine a lot of cloying for/while/if tests that are basically to select objects matching some criteria, and that an in-memory SELECT would accomplish it much more simply. - erk Quotes from my screensaver, relevant to this discussion: "Progress is possible only if we train ourselves to think about programs without thinking of them as pieces of executable code." - Edsger W. Dijkstra and "We have to let the symbols do the work, for that is the only known technique that scales up." - Edsger W. Dijkstra >Not to me, it isn't. Mathematical models are simply models/metaphores. They are formal representations. > The >discipline of "doing" relational theory could be seen as mathematics, but >the application of this mathematics to the discipline of application >software development has to do with a belief that this mathematical model >has something to do with the engineering effort underway. It should not have relationship with beliefs. It is proven that it is simpler than the known alternatives. >Yes, it is a shame that those fresh out of higher ed do seem dogmatic about >both relational databases as being the best databases and OO as the best >programming languages, based not on practice, but the sermons they have >heard in the classroom and read in their text books. Most if not all of the advocates of the network and hierarchical approaches never tried The Relational Model, thus their experience has little value. It is hard to practice with something never implemented. > The advocates in both >of these areas have a pitch that resonates with professors and/or text book >writers & publishers. I think both OO and relational theory ought to be >taught side by side with alternatives and pros & cons of each. I agree, although they are independent. Relational theory is for data management and OO is for coding. > There is not >one correct mathematical model for data, metadata, nor functions (by >whatever names). But there is one best approach for data management. >> What is evident is that the equation: type = variable does not work. > >I agree. Then it is obvious that you disagree with class = type >> A class is a type and a class definition is a type definition. >> >> Many people confuse a class with its definition. > >Me, for exampe. The term is used both ways. Indeed, it is the typical fuzzyness of OO. OO terms have many meanings and communication and precise thinking is very difficult. > I prefer to think of a class >as a specification for (that is, metadata regarding) a domain/type. It does not change the things a lot. The equation: type specification = relvar is as blunderous as type = relvar. >> A class being a type is a set (among other things). > >See how confusing that terminology is? Yes, that's why I tend to avoid the "class" term and to use "type", "type definition" and "type implementation" instead. Bad terminology leads to bad thinking. >> No, code does not have any relationship with metadata. > >really? What about the declarative code that specifies constraints on the >data -- is that metadata? No, it is a way to represent metadata. You should not confuse the "thing" with one possible representation of the "thing". Regards Alfredo > >Not to me, it isn't. Mathematical models are simply models/metaphores. > > They are formal representations. Yes, formal representations of a metaphore for whatever in the "real world" they are applied to > > The > >discipline of "doing" relational theory could be seen as mathematics, but [quoted text clipped - 4 lines] > It should not have relationship with beliefs. It is proven that it is > simpler than the known alternatives. Simpler to human beings? Simpler to computers? Simpler to work with mathematically? This is a RELIGIOUS BELIEF that if you take the simplest mathematical model (aka metaphor) for something, then that is the best. I could use a point as a mathematical model for God or use a more complicated model of a triangle. I prefer the triangle metaphor because it is helpful for describing a trinitarian view of God. A point is surely simpler than a triangle, however. That doesn't mean it is the best metaphor to choose. > >Yes, it is a shame that those fresh out of higher ed do seem dogmatic about > >both relational databases as being the best databases and OO as the best [quoted text clipped - 4 lines] > approaches never tried The Relational Model, thus their experience has > little value. It is hard to practice with something never implemented. The terms "Network" and "Hierarchical" were coined by relational theorists to disparage other approaches -- in other words, they are marketing terms. There are many people who persist data in trees (see your average file system, LDAP, DNS and many other repositories) or di-graphs (see the www). I am an example of someone who has used Oracle, SQL Server, My SQL, and PostgreSQL and much prefer the data model of the U2 databases (UniVerse and UniData). Why? Because I care about the cost of ownership for the overall software solutions over time. I am not alone in knowing and using relational databases and prefering not to. > > The advocates in both > >of these areas have a pitch that resonates with professors and/or text book [quoted text clipped - 3 lines] > I agree, although they are independent. Relational theory is for data > management and OO is for coding. Yes, but both are for developing software applications that meet the needs of people and organizations. > > There is not > >one correct mathematical model for data, metadata, nor functions (by > >whatever names). > > But there is one best approach for data management. Ah, there is that religion again -- I suppose the one best approach is to use the relational model? Yes that is king of the hill still in 2004, but it might be wise to keep your eye on the rear view mirror (to mix metaphors). > >> What is evident is that the equation: type = variable does not work. > > > >I agree. > > Then it is obvious that you disagree with class = type That's really a matter of defining terms. I do think that "the code is the spec" for software and by my definitions, the software class is a spec for a type. I think Eric had some more industry-standard terms for a difference between a specification for a set and the enumeration of the set. If I were to specify in a class that a set S = {all women over 60} then that class would have the specification for the type S but would not BE the type if, indeed, type and domain are the same set. My mother would be IN that set, but would not be part of the class, nor perhaps even within a 100 miles of the set. The objects that can be instantiated by a class are NOT "in" the class, while they are in the domain specified by the class. But again, this is a definition of terms. I someone wants to define class=type then I can play that game but I'd rather say that a class is a type definition or specification. > >> A class is a type and a class definition is a type definition. > >> [quoted text clipped - 4 lines] > Indeed, it is the typical fuzzyness of OO. OO terms have many meanings > and communication and precise thinking is very difficult. But if all those OO folks have that same problem, then perhaps there is more precision than we think? > > I prefer to think of a class > >as a specification for (that is, metadata regarding) a domain/type. > > It does not change the things a lot. The equation: type specification > = relvar is as blunderous as type = relvar. Is there such a thing as a relation as a type of attribute (as in "relational-valued attribute")? If so, then why couldn't a class be a type of relation? > >> A class being a type is a set (among other things). > > > >See how confusing that terminology is? > > Yes, that's why I tend to avoid the "class" term and to use "type", > "type definition" and "type implementation" instead. OK, I can work with that. > Bad terminology leads to bad thinking. Agreed. "Bad terminology" is not just imprecise terminology but terminology that does not properly communicate. It seems to me that when I talk about classes with OO folks there is better understanding about what we are talking about than if I talk about types with relational database folks, however, the relational theorists have done a better job of making the definitions precise (each variation on them). > >> No, code does not have any relationship with metadata. > > [quoted text clipped - 3 lines] > No, it is a way to represent metadata. You should not confuse the > "thing" with one possible representation of the "thing". then we are back to a class not actually BEING a type, but being a possible representation of a type. Even though we have had a similar discussion on these terms many times in this forum, I'm not getting any wiser about them and I really want to. It is not just that there are so many possible definitions, but there seems to be different term-tuples that are being described. The question of "for what concepts do we need a term" are different in different worlds, so we have overloaded and contradictory terms. Some of that is understandable, but as soon as someone says that "OOclass=RELATIONALtype" it seems like things get muddier (in my head) and not clearer. I'll keep studying. --dawn > Alfredo Novoa wrote: >> [quoted text clipped - 19 lines] > for describing a trinitarian view of God. A point is surely simpler than a > triangle, however. That doesn't mean it is the best metaphor to choose. Yup. Unfortunately some of these religions are so secretive that even the believers don't all know that they are. I am sure I have some (a lot - who knows?) of those beliefs. One of my unfounded beliefs I *am* aware of is that if people try to understand and respect eachother, they will. [snipalot] > That's really a matter of defining terms. ... How about a c.d.theory glossary ? >> >Not to me, it isn't. Mathematical models are simply models/metaphores. >> >> They are formal representations. > >Yes, formal representations of a metaphore for whatever in the "real world" >they are applied to Mathematical models are not limited to the real world. >> It should not have relationship with beliefs. It is proven that it is >> simpler than the known alternatives. > >Simpler to human beings? Simpler to computers? Simpler to humans of course. > Simpler to work with >mathematically? This is a RELIGIOUS BELIEF that if you take the simplest >mathematical model (aka metaphor) for something, then that is the best. Simplest leads to cheapest and money has nothing to do with religion (although the contrary is false :). >> Most if not all of the advocates of the network and hierarchical >> approaches never tried The Relational Model, thus their experience has [quoted text clipped - 4 lines] >There are many people who persist data in trees (see your average file >system, LDAP, DNS and many other repositories) or di-graphs (see the www). If you don't like the terms I could say that it was proven that the logic based approach is superior to the graph based approaches. >I am an example of someone who has used Oracle, SQL Server, My SQL, and >PostgreSQL and much prefer the data model of the U2 databases (UniVerse and >UniData). Why? Because I care about the cost of ownership for the overall >software solutions over time. I am not alone in knowing and using >relational databases and prefering not to. None of the above is a RDBMS and My SQL is not a DBMS at all. To use Oracle does not mean that you know how to take andvantage on The Relational Model. I used navigational procedural approaches and the relational approach, and the differences in code size are in orders of magnitude. The differences in productivity between assembler and Java is very little compared to this. >> I agree, although they are independent. Relational theory is for data >> management and OO is for coding. > >Yes, but both are for developing software applications that meet the needs >of people and organizations. You can use The Relational Model to manage data and to use OO when you code the applications. >> But there is one best approach for data management. > >Ah, there is that religion again No, it is well stablished science teached at any university. > -- I suppose the one best approach is to >use the relational model? Yes that is king of the hill still in 2004, but >it might be wise to keep your eye on the rear view mirror (to mix >metaphors). I would be delighted to find something even better, but there is not any sign in the horizon. >The objects that can be instantiated by a class are NOT "in" the class, If class is definition this is evident. If class is type then it is evident that objects (values) of a class are part of the class. >while they are in the domain specified by the class. But again, this is a >definition of terms. I someone wants to define class=type then I can play >that game but I'd rather say that a class is a type definition or >specification. That's the magic of OO. Everything might be anything. The best definition of object is: an object is something. Everything is something, thus everything is an object. >> > I prefer to think of a class >> >as a specification for (that is, metadata regarding) a domain/type. [quoted text clipped - 5 lines] >"relational-valued attribute")? If so, then why couldn't a class be a type >of relation? Relations have type, you could call class to the type of a relation, but OO languages (still) don't support anything similar. OO types are scalar and relation types are not. BTW you can not declare relation types in Tutorial D or table types in SQL. Regards Alfredo > >> >Not to me, it isn't. Mathematical models are simply models/metaphores. > >> [quoted text clipped - 18 lines] > Simplest leads to cheapest and money has nothing to do with religion > (although the contrary is false :). Bingo! So, we ought to be able to get some emperical data. If such a study is done fairly, what will it show about the cost of ownership of an RDBMS compared to a PICK implementation? > >> Most if not all of the advocates of the network and hierarchical > >> approaches never tried The Relational Model, thus their experience has [quoted text clipped - 7 lines] > If you don't like the terms I could say that it was proven that the > logic based approach is superior to the graph based approaches. Now we are getting somewhere -- I have heard relational theorists make this claim often -- is there emperical data to "prove" this claim or is this one of those "I made the rules of the game and then I won the game" statements? I have honestly searched for such proof and cannot find it. > >I am an example of someone who has used Oracle, SQL Server, My SQL, and > >PostgreSQL and much prefer the data model of the U2 databases (UniVerse and [quoted text clipped - 3 lines] > > None of the above is a RDBMS and My SQL is not a DBMS at all. So, we have a theory and no implementations so it is impossible for us to know whether the theory is useful or not? I won't hold my breath for an actual consumer product that is deemed good enough for us to test the theory. And, by the way, since Codd's first relational theory paper was published by ACM in 1970, what is keeping us from having an implementation these many years later? I'll admit there are no perfect PICK implementations by a long stretch, but the first implementation of it was, indeed, an implementation. > To use Oracle does not mean that you know how to take andvantage on > The Relational Model. I will completely agree that I am no expert on the relational model, but I am here as a student. > I used navigational procedural approaches and the relational approach, > and the differences in code size are in orders of magnitude. The > differences in productivity between assembler and Java is very little > compared to this. I care naught for code size. In the 80's when I had COBOL programmers working for me (and was one myself), the anecdotal evidence I saw that the really excellent programmers often produced many fewer lines of code than their average-programmer counterparts was overwhelming. Additionally, I find "lines of code per function point" comparisons of computer languages to tell us nothing about productivity in the language. It is good to see our profession attempt to get some solid metrics, but what a silly metric that one is! > >> I agree, although they are independent. Relational theory is for data > >> management and OO is for coding. [quoted text clipped - 4 lines] > You can use The Relational Model to manage data and to use OO when you > code the applications. But I only work with applications whose purpose is to manage data ;-) [don't respond to that one IYKWGFY] > >> But there is one best approach for data management. > > > >Ah, there is that religion again > > No, it is well stablished science teached at any university. I have yet to find proof that the relational model is better for a company to use than any other data model. My anecdotal evidence tells me otherwise. Where is the emperical data? > > -- I suppose the one best approach is to > >use the relational model? Yes that is king of the hill still in 2004, but [quoted text clipped - 3 lines] > I would be delighted to find something even better, but there is not > any sign in the horizon. I suspect this has to do with what we are trying to do with the model. I'm after the best total cost of ownership for software applications. > >The objects that can be instantiated by a class are NOT "in" the class, > > If class is definition this is evident. > > If class is type then it is evident that objects (values) of a class > are part of the class. Yup, agreeds. > >while they are in the domain specified by the class. But again, this is a > >definition of terms. I someone wants to define class=type then I can play [quoted text clipped - 20 lines] > but OO languages (still) don't support anything similar. OO types are > scalar and relation types are not. In what way are they scalar? I suspect this is a def thing too. It seems to me that one could have an array as an object (loose terminology), right? > BTW you can not declare relation types in Tutorial D or table types in > SQL. I know -- what a shame, eh? smiles. --dawn >> Simplest leads to cheapest and money has nothing to do with religion >> (although the contrary is false :). > >Bingo! So, we ought to be able to get some emperical data. If such a study >is done fairly, what will it show about the cost of ownership of an RDBMS >compared to a PICK implementation? I am sure about it will show that an RDBMS is a lot cheaper. The problem is that we don't have RDBMSs to do the study. >> If you don't like the terms I could say that it was proven that the >> logic based approach is superior to the graph based approaches. > >Now we are getting somewhere -- I have heard relational theorists make this >claim often -- is there emperical data to "prove" this claim or is this one >of those "I made the rules of the game and then I won the game" statements? Anecdotal evidence is not necessary and it does not prove anything in maths. >I have honestly searched for such proof and cannot find it. See the Relational Database Writings series. And also this for instance: http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.jhtml >> None of the above is a RDBMS and My SQL is not a DBMS at all. > >So, we have a theory and no implementations so it is impossible for us to >know whether the theory is useful or not? Even the bastardized implementations are very useful at practice and they replaced the alternatives in most scenaries. > I won't hold my breath for an >actual consumer product that is deemed good enough for us to test the >theory. And, by the way, since Codd's first relational theory paper was >published by ACM in 1970, what is keeping us from having an implementation >these many years later? IMO the major component is ignorance. The model was never understood by the masses. The first dirty, flawed and incomplete prototypes were so successful that a correct implementation was forgotten. When the flaws and limitations arised they were attributed to the model instead of the flaws of the implementations and some people returned to the primitive approaches. Sad, but true. >> I used navigational procedural approaches and the relational approach, >> and the differences in code size are in orders of magnitude. The [quoted text clipped - 5 lines] >really excellent programmers often produced many fewer lines of code than >their average-programmer counterparts was overwhelming. I am talking about the same programmer and differences of more than a 90% > Additionally, I >find "lines of code per function point" comparisons of computer languages to >tell us nothing about productivity in the language. It is good to see our >profession attempt to get some solid metrics, but what a silly metric that >one is! It is silly to apply it blindly but it might says many things. I am sure about I prefer to mantain 2000 lines of high level code instead of 50000 lines of assembler code. >> Relations have type, you could call class to the type of a relation, >> but OO languages (still) don't support anything similar. OO types are >> scalar and relation types are not. > >In what way are they scalar? They have visible components. > I suspect this is a def thing too. It seems >to me that one could have an array as an object (loose terminology), right? Yes, an array type is a good example of non scalar type. IMO all OO languages should implement relational variables besides array variables. It would be the end of the called "impedance mismatch". >> BTW you can not declare relation types in Tutorial D or table types in >> SQL. > >I know -- what a shame, eh? No, I don't think they are very useful and it would be very easy to implement that. Regards Alfredo > The problem is that we don't have RDBMSs to do the study. So let's work with what we have, namely Oracle, DB2, SQL Server, etc. until we get the first "genuine" RDBMS. Regardless of whether these products correctly implement the relational concept or not, they can still be evaluated for usefulness. > we don't have RDBMSs to do the study. We do. Alphora Dataphor.  SignatureLeandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SP BRASIL http://br.geocities.com./lgcdutra/ "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > > we don't have RDBMSs to do the study. > > We do. Alphora Dataphor. Great -- so what advantages can you see in a real relational database management system that are not present in the not-exacxtly-relational implementations that are out there? In other words, in what way is a pure relational implementation more useful than one that is not-so-pure? Thanks in advance. --dawn >> Alphora Dataphor. > > Great -- so what advantages can you see in a real relational database > management system that are not present in the not-exacxtly-relational > implementations that are out there? In other words, in what way is a pure > relational implementation more useful than one that is not-so-pure? User defined types as first class citizens, including special values to get us rid of NULLs. Updateable derived relations (updateable views). All the system defined on the database, including UI. And so on... get it for yourself on http://alphora.com./ -- unfortunately it needs MS .Net. SignatureLeandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SP BRASIL http://br.geocities.com./lgcdutra/ "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > >> Alphora Dataphor. > > [quoted text clipped - 5 lines] > User defined types as first class citizens, including special > values to get us rid of NULLs. Good deal. > Updateable derived relations (updateable views). Wonderful! > All the system defined on the database, including UI. I'll withhold judgment until I take a look > And so on... get it for yourself on http://alphora.com./ -- OK > unfortunately it needs MS .Net. nevermind ;-( smiles. --dawn >>> Alphora Dataphor. >> [quoted text clipped - 5 lines] > User defined types as first class citizens, including special >values to get us rid of NULLs. Amen to that ... > Updateable derived relations (updateable views). > > All the system defined on the database, including UI. I think we might have trouble here ... I'm beginning to get inconvenient ideas about data/metadata ... :-) > And so on... get it for yourself on http://alphora.com./ -- >unfortunately it needs MS .Net. Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 >> All the system defined on the database, including UI. > > I think we might have trouble here ... I'm beginning to get inconvenient > ideas about data/metadata ... :-) What's wrong about metadata being data? SignatureLeandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SP BRASIL http://br.geocities.com./lgcdutra/ >>> Alphora Dataphor. >> [quoted text clipped - 5 lines] > User defined types as first class citizens, including special >values to get us rid of NULLs. As I said in another post - great! But I've been thinking ... Does relational draw a distinction between data and metadata? Does it also require a separation between the database (that acts on metadata) and applications (that act on data)? Because if the answer to both questions is yes, then we are trying to square a circle. "Nature opposes any change". Apply a voltage across a wire, current starts to flow, which causes a voltage in the opposite direction, which resists the flow of the current ... - the normal behaviour of the physical world ... Analysis of a real-world object to obtain data to put into a database involves considerable transformation. In particular, it involves the destruction of a large amount of metadata. As others have noted, analysis is not a closed system and the metadata can be replaced by the equivalent data (the metadata that two "order details" are physically on the same piece of paper called an invoice is replaced by the data that both order detail rows in the database share the same invoice-no as a foreign key). The only way to make this information available to the DBMS again is to put application logic INSIDE the DBMS - indeed - to make user-defined types "equal citizens" with pre-defined types we need to be able to allow the user to modify the DBMS, and not just the database. To me this flies in the face of all the claims by the current "relational" databases to be able to protect the data from the programmer - how can it if the programmer has the ability to write code to convert data into metadata? This seems to me to be even more evidence in favour of the Pick approach, which is to separate data integrity from data storage, and to store metadata as "just more data". In other words, data integrity should be enforced by a mechanism similar to the current relational trigger, and not by metadata in the datastore itself. The application layer sits on top of a data integrity layer which sits on top of a datastore layer. Current "relational" databases muddle the integrity layer into both the datastore and the application layer. Pick just shoves the whole lot into the application layer ... (although it's added a trigger layer which could do it.) Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 >>we don't have RDBMSs to do the study. > > We do. Alphora Dataphor. Does it already have its own storage engine? -- Jan Hidders >> Alphora Dataphor. > > Does it already have its own storage engine? Only the beginnings of it, and probably it will be redone. For now it is still best to use IBM DB2 (or some lesser SQL DBMS) as its storage engine. SignatureLeandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SP BRASIL http://br.geocities.com./lgcdutra/ > I care naught for code size. In the 80's when I had COBOL programmers > working for me (and was one myself), Dawn, If you managed COBOL programmers in the 1980s, but never heard of the hierarchical or network data models, except as "marketing for the relational model", then you have led a sheltered existence, indeed. Ever hear of IMS? It was built on the hierarchical model of data. Ever hear of IDMS (not IDMS/R)? It was built on the network model of data. These are just two examples. Any COBOL shop that had some exposure to the prerelational COBOL/DBMS world had some exposure to one of these models of data. As far as comparisons between data models go, Codd's work in the early 1970's was proposing a new data model. To propose a new data model, without comparing it to existing data models, would have been irresponsible. Codd made the comparison. If you want to dismiss Codd's work as "marketing hype", well, who am I to argue? As far as "an RDBMS has never been built", I agree with you. That's not a useful position to take. No one has ever built a triangle either. But my kindergarten teacher had an approximate triangle that she held up in class, and said "This is a triangle". Close enough. > > I care naught for code size. In the 80's when I had COBOL programmers > > working for me (and was one myself), [quoted text clipped - 10 lines] > prerelational COBOL/DBMS world had some exposure to one of these models of > data. Perhaps you misunderstood me. I have worked with IMS extensively and have touched IDMS. I don't think that there was anyone in the building of IMS that called IMS a "hierarchical" database, but I could be wrong. It is my impression that the terms "network database" and "hierarchical database" were prepared by relational database theorists in describing how their database implementations differed from those that were out there already. If the IDMS folks, for example, set out to create something they called a "network database" then I'm interested in any historical information on that. I read a bunch of database history a few months ago and it was my impression that these terms were coined by the relational database "industry" somewhere along the line. > As far as comparisons between data models go, Codd's work in the early > 1970's was proposing a new data model. To propose a new data model, without > comparing it to existing data models, would have been irresponsible. Codd > made the comparison. If you want to dismiss Codd's work as "marketing > hype", well, who am I to argue? I most certain do not do that! However, when I read in textbook after textbook something that could be summarized as "there are three possibilities -- network, hierarchical, and relational and relational is obviously better" then I know there is some thread of marketing going on. Of course now they add that there are also OO databases, perhaps XML dbs and they might mention a few others ("semantic web" etc). But the entire wealth of knowledge related to persisting data in 1950-1990 outside of RDBMS's is typically narrowed down to IMS as hierarchical and IDMS as network databases, prior to being dismissed entirely by the text book. > As far as "an RDBMS has never been built", I agree with you. That's not a > useful position to take. No one has ever built a triangle either. But my > kindergarten teacher had an approximate triangle that she held up in class, > and said "This is a triangle". Close enough. Great analogy! --dawn Dawn, I'd like to suggest that you go back to two original sources. The first is Codd's original work, proposing the relational model. A Google search on "Codd Data Model" brings up a reprint of the classic paper, among lots of others. The second is James Martin, "Computer Database Organization". I haven't looked at Martin in almost twenty years, so I don't know what you'll find there. But I would expect that you would find his treatment more convincing than I find most of the stuff I associate with the word "marketing." Was Galileo's comparison of the Copernican and the Ptolemaic systems, "marketing"? > Dawn, > [quoted text clipped - 3 lines] > search on "Codd Data Model" brings up a reprint of the classic paper, among > lots of others. Within the past year I have read it, re-read it, made sure I understood it and filed I've got it right here. What do you think it says that I'm missing? > The second is James Martin, "Computer Database Organization". I haven't > looked at Martin in almost twenty years, so I don't know what you'll find > there. But I would expect that you would find his treatment more convincing > than I find most of the stuff I associate with the word "marketing." I last read Martin about 20 years ago too (common grade school text?) Again, what do you think I'll find there? > Was Galileo's comparison of the Copernican and the Ptolemaic systems, > "marketing"? No -- again, I'm not judging the original users of such terms, but the fact that they became the norm so that instead of using the very common term "tree" to describe IMS (it might not exactly be a tree, but wlog we can consider it such), we perpetuate the relational folks' terminology not just for relational theory, but for products that are not in their camp. From a global standpoint, that is a common marketing strategy -- classify competitor products and your own and then attact the super-classes. It has worked so well for the relational database industry in grabbing mindshare that almost every product, including PICK, has called itself a relational database. It makes sense for Oracle and other RDBMS vendors to use this trick, but perhaps the textbooks could be a little less slanted in their use of terms. For example, if you say that there are hierarchical databases and then list IMS and PICK (I know it is never listed, except as "and others") in that category, you would have readers thinking that there is anything similar between IMS and PICK (nothing I can see other than the ability to display the structure of each as a di-graph). I'm rambling and this isn't an important enough point. But if you DO KNOW of any reason to believe that prior to Codd's publications in 1970 (or his work to get there) any of the existing database implementations classified themselves as hierarchical or network, please point me to the sources. I'm VERY interested in that. Thanks. --dawn I expect that, if you dig deep enough, you'll find that the terms "hierarchical data model" and "network data model" predate the relational data model. These are just two places to start the search. > I expect that, if you dig deep enough, you'll find that the terms > "hierarchical data model" and "network data model" predate the relational > data model. > > These are just two places to start the search. I've searched -- I haven't found them. My assessment is that there certainly could have been a person who uttered the words "hierarchical database" when talking about IMS prior to 1970, but so far I have not found anything in writing referring to hierarchical or network database prior to Codd's 1970 ACM paper. I suspect it is historically accurate that relational theorists coined these terms or at least standardized on them for discussions of why relational was a better strategy. If someone has evidence to the contrary, I'm very interested. --dawn Conspiracy theories can be extraordinarily hard to debunk. If you are determined to believe that the term "hierachical database" was popularised as part of an Orwellian agenda by the "relational camp", I'm just not going to argue that point with you. Do your own investigating, and draw your own conclusions. A five minute search with Google turned up the following article in 1974. But that's after 1970. http://portal.acm.org/citation.cfm?id=811508&dl=ACM&coll=GUIDE > Conspiracy theories can be extraordinarily hard to debunk. > > If you are determined to believe that the term "hierachical database" was > popularised as part of an Orwellian agenda by the "relational camp", I'm > just not going to argue that point with you. You are missing my point and my motivation for it -- I don't see it as a pre-meditated conspiracy at the outset. I don't think the original players, other than perhaps that guy at the company-later-known-as-Oracle, were marketing-savvy enough to know or care about the choice of terms for marketing purposes. But if you address the question of what were some of the helping factors outside of the technology itself that promoted the relational database structure to the king of the hill position, one thing you might look at is the language used when discussing it. Relational database folks and their marketing counterparts have impressed upon our minds so heavily that everything was once either a hierarchical, network, or relational database (before declaring that relational is obviously superior). So now those writing text books have adopted this terminology too and promoted a somewhat scewed version of the history of databases, using post-IMS terminology to describe IMS, for example. It is like when I called the "M card approach" a design pattern -- not the terminology we used in "data processing" in the 70's, to be sure. > Do your own investigating, and draw your own conclusions. > > A five minute search with Google turned up the following article in 1974. > But that's after 1970. Yup -- even post the time of the next paper(s) on the subject. Don't get me wrong -- I don't think this language is bad -- it just has a marketing spin to it that most people fail to recognize. People riding horses who started driving cars DID recognize they were riding horses prior to the car coming along. The spin was that now they could have a horseless carriage. In the case of relational databases, the proponents defined what they were replacing in a way so as to pick up on one aspect of their competition (the tree or di-graph structure) and then once they defined for us what we were doing using this metaphor of hierarchical, network or relational was set out, it was hard to make a case for either of the first two. Anyway, we have beat this one to death, but if anyone DOES find evidence that the terms "network database" or "hierarchical database" came from anywhere other than the "relational camp" please let me know. Cheers! --dawn > http://portal.acm.org/citation.cfm?id=811508&dl=ACM&coll=GUIDE > > I expect that, if you dig deep enough, you'll find that the terms > > "hierarchical data model" and "network data model" predate the [quoted text clipped - 11 lines] > discussions of why relational was a better strategy. If someone has > evidence to the contrary, I'm very interested. I don't have any evidence either way, but I would imagine the relationalists could have found better rhetorical and disparaging terms than "hierarchical" and "network". Neither of those terms suggests anything on its own, nor is either one inaccurate in any significant way (as far as I know). - erk >> I've searched -- I haven't found them. My assessment is that there >> certainly could have been a person who uttered the words "hierarchical [quoted text clipped - 11 lines] >and "network". Neither of those terms suggests anything on its own, nor is >either one inaccurate in any significant way (as far as I know). It is a *standard* rhetorical technique to highlight what you perceive as weakness in the opposition, and compare it to your strengths. One of the strengths of relational is that "all queries are equal" - the database is optimised so that you can ask any question with equal ease. By their very nature, hierarchical databases are best with queries whose structure matches the structure of the database. So the terms are not "disparaging", as you put it, but are designed by the relational camp to emphasise those features that the relational camp WISH to emphasise - those features that the relational camp see as placing hierarchical databases at a disadvantage. ALL descriptions are loaded - that's the nature of language. Dawn is simply trying to place the words in their historical context and comprehend the impact they had then - a very difficult task when your vision is obscured by hindsight ... Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 >> I expect that, if you dig deep enough, you'll find that the terms >> "hierarchical data model" and "network data model" predate the [quoted text clipped - 11 lines] >discussions of why relational was a better strategy. If someone has >evidence to the contrary, I'm very interested. Hi Dawn, Even if someone could find hard proof that the terms hierarchical and network database were never used prior to 1970, that would still not proof that these are marketing terms, nor that they stem from the "relational camp". When the first computers were built, nobody called them "mainframe". That term was only introduces when mini computers started to appear. Is the term "mainframe" a marketing term, invented by the producers of minicomputers? Or is it just a term that was needed to be able to distinguish a new type of computers from an old type? I've had a personal computer for years without ever referring to it as a "desktop". That word was introduced when the first laptop computers were introduced? A marketing term, introduced by the producers of laptop computers? Or just a word that turend out to be helpful in distinguishing the differend sizes of computers? The introduction of the relational model meant the introduction of a completely different kind of database. So, there had to be a way to distinguish between the "old" database structure and the "new" database structure. And I must admit that the terms "hierarchic" and "network" describe the storage model of those databases quite accurately. A real marketeer would probably not have invented these words. (S)he would have referred to the relational databases as "new" and to all others as "old". Groetjes, Hugo SignatureSorry, vandaag geen grappige sig lines meer. > >> I expect that, if you dig deep enough, you'll find that the terms > >> "hierarchical data model" and "network data model" predate the [quoted text clipped - 43 lines] > > Groetjes, Hugo Thanks for piping up 'cause I'm clearly not being crisp in my point (I know, I know, I've had the problem before). I complete agree that this was not anything dreamed up by marketing folks. But in doing my own mini-research to identify anything other than the data model that has made relational databases take the king-of-the-hill position, the classification of all of the competition and then subsequent claims that such were clearly "wrong" turned out to be one of the things that contributes to compacting all of the history of databases into a couple of terms -- hierarchical and network -- for efforts prior to 1970. Do you |
Enable EMail Alerts
Start New Thread
Reply to this Message