 |
 | 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 / June 2004Peter Chen and Charles Bachman
If you are interested in the history of data modeling, whether it's called by that name or not, you really need to look into Peter Chen and Charles Bachman. Peter Chen introduced the E-R model in 1976 in an article in <i>Communications of the ACM</i>. AFAIK this is the first place where the E-R model was presented as such. Charles Bachman was the principal proponent of the "navigational" data models. In a 1974 debate between the proponents of the relational model and its opponents, Bachman led the opponents. Hey Dawn, if you really want to find out whether the term "hierarchical data model" was coined by its opponents, Bachman is the trail to follow. His "Data Structure Diagrams" precede Ed Codd's 1970 article. Here's a link that contains references for both Chen and Bachman. http://www.fairview-industries.com/standardmodule/section2.htm#Links > Hey Dawn, if you really want to find out whether the term "hierarchical > data model" was coined by its opponents, Bachman is the trail to follow. > His "Data Structure Diagrams" precede Ed Codd's 1970 article. Diagrams aren't models...  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 > > Hey Dawn, if you really want to find out whether the term "hierarchical > > data model" was coined by its opponents, Bachman is the trail to follow. > > His "Data Structure Diagrams" precede Ed Codd's 1970 article. > > Diagrams aren't models... I'll accept that diagrams, in themselves, are not full mathematical theories, but models they often are, it seems to me. What is your definition of "model" (as a noun)? >> Diagrams aren't models... > > I'll accept that diagrams, in themselves, are not full mathematical > theories, but models they often are, it seems to me. What is your > definition of "model" (as a noun)? A model must include all aspects of the database, or it will be only a draft. A diagram can hardly be expected to represent, say, all constraints in a database. Not to mention their maintenance tends to become counterproductive as the database grows in complexity and size. They are nice as drafts in the early stages of modelling and for presentation. 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 in message > A model must include all aspects of the database, or it will > be only a draft. That's precisely what a model is NOT! A model highlights certain features of the thing modeled precisely because it omits some of the detail. If you were building a 12 foot model of the titanic, you wouldn't expect all the toilets to flush! And it's the smae way in modeling SW or databases, or anything. The model isn't the thing itself, and it doesn't model everything about it. Otherwise the model would be a s hard to build as the thing it modeled. > A model highlights certain features > of the thing modeled precisely because it omits some of the detail. So a model omits data itself, and the DBMS, and the physical model. Otherwise, it's a draft. You can't make much of analogies with the physical world. 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/ >>A model highlights certain features >>of the thing modeled precisely because it omits some of the detail. > > So a model omits data itself, and the DBMS, and the physical model. Yes, yes and yes, as far as ER-models are concerned. However, naive use of them starts with higher expectations. Children who get to learn how to use city-maps have to learn how to use them. It's not immediately appearent which aspects from the map they can trust, and which ones they can't. Learning how to make use of ER-models goes the same way. Expectation management is important. > Otherwise, it's a draft. > > You can't make much of analogies with the physical world. Analogies make models useful for design, teaching and planning purposes. They don't need to be physical. "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > You can't make much of analogies with the physical world. What is this in reference to? "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > >> Diagrams aren't models... > > [quoted text clipped - 4 lines] > A model must include all aspects of the database, or it will > be only a draft. With the number of dialogs we have that include information relevant to databases, but "orthogonal" to relational theory, my conclusion is that by your definition relational theory is not a model -- is that correct? > A diagram can hardly be expected to represent, say, all > constraints in a database. [quoted text clipped - 4 lines] > They are nice as drafts in the early stages of modelling and > for presentation. > With the number of dialogs we have that include information relevant to > databases I don't know what you are talking about specifically. > but "orthogonal" to relational theory, my conclusion is that by > your definition relational theory is not a model There are actually three things that go by the name of model: a general theory of data, where relational is alone; a general way of managing data, where you have relational, hierarchical etc; and the specific conceptual or logical representation of a particular database. C'mon, you are not *that* ignorant after being in this forum for so long. 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 > > [quoted text clipped - 6 lines] > > A model must include all aspects of the database, or it will > > be only a draft. Wouldn't a model that includes all aspects of the database be an implementation? Perhaps the word "all" is a little strong. > With the number of dialogs we have that include information relevant to > databases, but "orthogonal" to relational theory, my conclusion is that by > your definition relational theory is not a model -- is that correct? I don't want to put words in his mouth, but I think he is arguing just the opposite. I'm sure many in this group have already seen the article, but the following by Chris Date gives rise to what I agree are some of the issues and distinctions that are relevent to what we call and how we use models. See "Models, models, everywhere, nor any time to think." (http://www.pgro.uk7.net/cjd3a.htm). - Dan > > A diagram can hardly be expected to represent, say, all > > constraints in a database. [quoted text clipped - 4 lines] > > They are nice as drafts in the early stages of modelling and > > for presentation. >> > A model must include all aspects of the database, or it will be only a >> > draft. > > Wouldn't a model that includes all aspects of the database be an > implementation? Perhaps the word "all" is a little strong. Indeed. That should be qualified by 'all logical or conceptual aspects, that is apart of actual data and physical details; perhaps what is commonly called the "structure" of the database'. Is that better? 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/ > That should be qualified by 'all logical or conceptual > aspects, that is apart of actual data and physical details; perhaps > what is commonly called the "structure" of the database'. Now we're getting somewhere. I can accept this. In this context. let me say this: an ER model is a "data model" but it is not a "database model". That is to say, all the relationships in the data that are inherent in the composition of the data, whether it's adjacency, navigational, or by common key data, are omitted from this model. To me, that's precisely what makes it valuable. A discussion between SMEs and DB designers concening an ER model will focus on whether the data values "make sense" in terms of the entities, relationships and attributes presented in that model. Questions about whether to model relationships using key data, CODASYL style networks, trees, or PICK structures can be left out of the discussion, because these things are not in the model. That means that once you have an ER model that is satisfactory to both the SMEs and the designers, you are still free to choose an implementation, without having to "undo" decisions made in the ER model. As has been said before in this forum, it's the difference between analysis and design. > > That should be qualified by 'all logical or conceptual > > aspects, that is apart of actual data and physical details; perhaps [quoted text clipped - 5 lines] > composition of the data, whether it's adjacency, navigational, or by common > key data, are omitted from this model. agreed. > To me, that's precisely what makes it valuable. A discussion between SMEs > and DB designers concening an ER model will focus on whether the data values > "make sense" in terms of the entities, relationships and attributes > presented in that model. Questions about whether to model relationships > using key data, CODASYL style networks, trees, or PICK structures can be > left out of the discussion, because these things are not in the model. Yes, an ERD can help communication among participants before any discussion of implementation. A relational model really targets a relational implementation, even though others will disagree. A COMPLETE relational model with all constraints and recognition of where there are parent-child relationships, in particular, could be implemented in many different databases (even those that are not relational) but it is not a good starting point for a discussion of the high level entities being discussed during the analysis phase of a project. > That means that once you have an ER model that is satisfactory to both the > SMEs and the designers, you are still free to choose an implementation, > without having to "undo" decisions made in the ER model. As has been said > before in this forum, it's the difference between analysis and design. Yup exactly! UML diagrams can do similarly, but tend to be more directed to OO design so I find using simple ER diagrams to "model" the data at a high level is one of the best ways of facilitating understanding of a subject area. But I'll admit that I honestly don't know what the relational model has to offer during the analysis phase of a project. Is there any reason why such topics as normalization would be needed or even useful during the analysis phase of a software project? What do those who don't like ERDs do instead in the early analysis phase? --dawn "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in > Yes, an ERD can help communication among participants before any discussion > of implementation. A relational model really targets a relational [quoted text clipped - 4 lines] > point for a discussion of the high level entities being discussed during the > analysis phase of a project. Agreed. In particular, a correctly expressed relational model will be in 1NF. If I've read your description of PICK correctly, this would be at best "orthogonal" and at worst counterproductive in terms of the later PICK implementation. Although some ER proponents argue for normalizing data in an ER model, many others do not. I tend to argue against normalizing data in the ER model. In particular an entity, an order, can contain line item data that is multivalued, or in 1NF parlance a "repeating group". If you implement in CODASYL you'll do one thing with it, if you implement in relational (or "tabular") you'll normalize by decomposition, and if you implement in PICK you'll do yet a third thing with it. > Yup exactly! UML diagrams can do similarly, but tend to be more directed to > OO design so I find using simple ER diagrams to "model" the data at a high [quoted text clipped - 4 lines] > analysis phase of a software project? What do those who don't like ERDs do > instead in the early analysis phase? As I said above, I'm against normalizing during analysis. Normalization belong in the solution domain, not the problem domain, IMO. The reason, IMO, that UML tends to be directed more towards OO design is that the OO community has not put enough attention into the difference between OOA and OOD. I don't know what people who don't like ERD's do for analysis. When I first joined this forum, there was a lively debate between the OO enthusiasts and the regulars about the subject of subject matter expertise. The prevailing opinion among the OO enthusiasts seemed to be that there wasn't time for the implementors to learn the subject matter, so the best thing to do was to design data structures that were subject matter independent. That's even farther from my way of thinking than your way of thinking is. >"Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in [snip] >Although some ER proponents argue for normalizing data in an ER model, many >others do not. I tend to argue against normalizing data in the ER model. [quoted text clipped - 3 lines] >"tabular") you'll normalize by decomposition, and if you implement in PICK >you'll do yet a third thing with it. <EG> You may really have to implement the Fourth Lie: "Of course I'll respect you in the morning.", "I'm here from the government and I'm here to help you.", "The cheque is in the mail.", and "I denormalised for performance." I thought PICK was based on the CODASYL way. If not, what is the differentiation please? [snip] >I don't know what people who don't like ERD's do for analysis. When I first >joined this forum, there was a lively debate between the OO enthusiasts and >the regulars about the subject of subject matter expertise. The prevailing >opinion among the OO enthusiasts seemed to be that there wasn't time for the >implementors to learn the subject matter, so the best thing to do was to >design data structures that were subject matter independent. An old saying: "There's never time to do it right, but there's always time to do it over." OOP is great, but so is cheddar cheese. I use each as appropriate. >That's even farther from my way of thinking than your way of thinking is. Having just gotten back to this group, I have reading the last month or so in the last few days. Given the current iteration in the neverending battle between Good and Evil (relational/SQL vs. PICK (or the reverse if that suits your biases), I have an overdose of PICKism. Thank goodness that Dawn finds "post-relational" being as stupid a term for PICK as most of us do. (If the first thing that someone tells me about Their Way is a lie, it does something for their credibility, something very bad.) Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. > >"Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in > [quoted text clipped - 15 lines] > I thought PICK was based on the CODASYL way. If not, what is the > differentiation please? I am unaware of any connection between the CODASYL designs and PICK, either historically or in looks, although both could likely be "modeled" with di-graphs. A CODASYL enthusiast would likely not consider PICK a DBMS. I have more experience with IMS than IDMS, but if I recall, IDMS also uses (used?) the concept of a schema (as a view) -- I could be wrong about that -- and typically includes DBA's in the mix, where the PICK approach does not. CODASYL was more strongly typed (lengths in particular) than PICK. PICK started out as an OS (then competed with UNIX and DOS and transitioned to residing on top of them). PICK runs within a virtual machine stemming from Wirth's P-machine (which is also the grandfather of the JVM). Writing software applications in COBOL and using IDMS as a DBMS really doesn't bear a lot of resemblence to software development in PICK (using DataBASIC, for example, along with Java or VB or whatever). It is conceivable, however, that the data modeling for each is similar. > [snip] > [quoted text clipped - 8 lines] > always time to do it over." OOP is great, but so is cheddar cheese. > I use each as appropriate. But only sharp cheddar -- life is too short to eat mild cheddar or milk chocolate, but that would (also) be a matter of taste ;-) > >That's even farther from my way of thinking than your way of thinking is. > [quoted text clipped - 6 lines] > tells me about Their Way is a lie, it does something for their > credibility, something very bad.) Sorry for the overdoes of PICKishness, Gene (and glad I didn't ruin my credibility by using clearly-errant terms like "post-relational"). The comments about PICK are more about "NOT RELATIONAL" or "not only relational", but I have found that using PICK as the example is better than using an even more emotion-inducing example such as "XML" or worse yet "XML Database." I might sound like an old lady stuck in some old technology, but I dont' think that's the whole of it -- I'm just trying to figure out why in the world we still teach relational theory (as it relates todata) as if it were TRUTH and don't teach other approaches that yield high productivity for companies (such as, you guessed it, PICK). Once my book learning and experience align better, I'll be at peace (well, only after the industry starts moving faster in directions I think more effective). smiles. --dawn <snip> >"Gene Wirchenko" <genew@mail.ocis.net> wrote in message [snip] >> I thought PICK was based on the CODASYL way. If not, what is the >> differentiation please? [snipped explanation] Thank you. >> >I don't know what people who don't like ERD's do for analysis. When I >first [quoted text clipped - 31 lines] >using an even more emotion-inducing example such as "XML" or worse yet "XML >Database." I am just graduating from a computing diploma program--I get my final course grade tomorrow--and in one of my courses, XML was inflicted on me. XML databases were mentioned. Why is it that every new thing has to be applied to everything else even when it does not fit? Presentation does not equal storage. >I might sound like an old lady stuck in some old technology, but I dont' >think that's the whole of it -- I'm just trying to figure out why in the [quoted text clipped - 3 lines] >experience align better, I'll be at peace (well, only after the industry >starts moving faster in directions I think more effective). smiles. --dawn I think that relational is more sophisticated than PICK, but I recognise that that comes at a cost which might not be necessary in some cases. My suspicion is that PICK does well in an environment where the database schema is fairly stable, but this is a guess. If it works, it works. This is from my sig collection: 'legacy (adj) - A pejorative term used in the computer industry meaning "it works."' Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. "Gene Wirchenko" <genew@mail.ocis.net> wrote in message > Why is it that every > new thing has to be applied to everything else even when it does not > fit? Presentation does not equal storage. Excellent point! > >"Gene Wirchenko" <genew@mail.ocis.net> wrote in message > [quoted text clipped - 3 lines] > some cases. My suspicion is that PICK does well in an environment > where the database schema is fairly stable, but this is a guess. Relational theory is much more sophisticated than PICK theory (which is largely in the minds of the practitioners, or not), but PICK seems to yield a better bang for the buck (an unproven observation from me and others who have seen both worlds). > If it works, it works. This is from my sig collection: 'legacy > (adj) - A pejorative term used in the computer industry meaning "it > works."' Excellent! I don't know how "legacy" got to be a bad word in our industry. I tell people that PICK is a legacy database, but that it is an earned legacy. --dawn > relational is more sophisticated than PICK, but I > recognise that that comes at a cost which might not be necessary in > some cases. I venture that two paradigms where one suffice is bad. 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 Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> wrote: >> relational is more sophisticated than PICK, but I >> recognise that that comes at a cost which might not be necessary in >> some cases. > > I venture that two paradigms where one suffice is bad. Having more than one approach is more robust. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. >> I venture that two paradigms where one suffice is bad. > > Having more than one approach is more robust. That begs proof. Specially because it hinders optimisation and increases complexity. 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 Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> wrote: >>> I venture that two paradigms where one suffice is bad. >> >> Having more than one approach is more robust. > > That begs proof. Specially because it hinders optimisation >and increases complexity. I am not a one-trick pony. Systems analysis includes selecting from possible choices. Note plural "choices". I see no advantage to being stuck with having to do something one way only. Sometimes, a different approach works better. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. > I see no advantage to > being stuck with having to do something one way only. Have you ever grokked _GOTO considered harmful_, or Codd's rules? 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 Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> wrote: >> I see no advantage to >> being stuck with having to do something one way only. > > Have you ever grokked _GOTO considered harmful_, or Codd's >rules? The former most definitely; the latter, not yet. There are times when a well-placed goto will aid program clarity. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. > Leandro Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> > wrote: [quoted text clipped - 7 lines] > The former most definitely; the latter, not yet. There are times > when a well-placed goto will aid program clarity. Only if the language is poor. 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 Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> wrote: >> Leandro Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> >> wrote: [quoted text clipped - 9 lines] > > Only if the language is poor. You are too doctrinaire for me. One of the fast sorts has a structure whose symmetry wrt to two variables is obvious with a couple of gotos, but which is lost with structured code. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. >Leandro Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> >wrote: [quoted text clipped - 18 lines] >variables is obvious with a couple of gotos, but which is lost with >structured code. Are you perhaps referring to the quicksort partitioning step? If solution symmetry is lost in "structured" code, blame the programmer's poorly structured thinking, and not the poorly structured code. Some intuitively grok structure, some find structure in the spaghetti, and many have structure thrust upon them. Most CS students are probably in the latter camp; they've been told: don't use GOTO, it's bad, which is a useful first order approximate model. Students probably haven't read Bohm and Jacopini, or Dijkstra, Dahl, and Hoare, to find out why the GOTO should be unnecessary for writing portable code in a well designed and implemented language; how well structured designs can lead to better implementations; and why it's okay to break the rules when language design or implementation fall short of the ideal. Exercises in restructuring (aka refactoring) real life examples of spaghetti code (and data) should be mandatory to teach students why well structured code is better than poorly "structured" code or unstructured spaghetti code. You can learn a lot about structure by studying code with GOTOs and poorly "structured" code to find where the implementation breaks the structure of the solution, and how to structure a better design and/or implementation. SignatureThanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca) fake address use address above to reply >>Leandro Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> >>wrote: [quoted text clipped - 23 lines] >programmer's poorly structured thinking, and not the poorly structured >code. When the code is structured the symmetry is not in the code. The two variables appear quite different in use. Do you have a version that retains the symmetry IN THE CODE? >Some intuitively grok structure, some find structure in the spaghetti, >and many have structure thrust upon them. I am in the first category, have had to deal with the second, and shudder at looking at code from someone in the third category. >Most CS students are probably in the latter camp; they've been told: >don't use GOTO, it's bad, which is a useful first order approximate >model. An excellent one, but after a year or so, they should be told about goto. >Students probably haven't read Bohm and Jacopini, or Dijkstra, Dahl, >and Hoare, to find out why the GOTO should be unnecessary for writing >portable code in a well designed and implemented language; how well >structured designs can lead to better implementations; and why it's >okay to break the rules when language design or implementation fall >short of the ideal. That is why I would wait a year. They would have a body of code that did not need goto. >Exercises in restructuring (aka refactoring) real life examples of >spaghetti code (and data) should be mandatory to teach students why >well structured code is better than poorly "structured" code or >unstructured spaghetti code. After the year, when they can appreciate it. >You can learn a lot about structure by studying code with GOTOs and >poorly "structured" code to find where the implementation breaks the >structure of the solution, and how to structure a better design and/or >implementation. Quite. If you have to maintain such code, you can go [|not so] quietly crazy, too. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. >>>Leandro Guimaraens Faria Corsetti Dutra <leandro@dutra.fastmail.fm> >>>wrote: [quoted text clipped - 27 lines] >two variables appear quite different in use. Do you have a version >that retains the symmetry IN THE CODE? The only asymmetry below seems to be the optimization that requires a specific order of operations to replace element swaps by moves. Opinion? [setup code elided] /* get median value and empty left slot */ move( temp, median, no_bytes); move( median, left, no_bytes); /* while partitions do not meet */ while (left < right) { /* scan from right to left while values >= median */ while (left < right && compare( item_cmp, right, temp) >= 0) right -= gap; /* if not partitioned, move out of order value to left */ if (left < right) { move( left, right, no_bytes); left += gap; /* scan from left to right while values <= median */ while (left < right && compare( item_cmp, left, temp) <= 0) left += gap; /* if not partitioned, move out of order value to right */ if (left < right) { move( right, left, no_bytes); right -= gap; } } /* if not partitioned */ } /* while not partitioned */ /* replace saved item in empty slot */ move( left, temp, no_bytes); print_sort_trace( list, no_items, no_bytes); /* sort smaller partition first in case bad median chosen */ lsize = left - list; litems = lsize/no_bytes; left -= gap; right += gap; rsize = end_list - right; ritems = rsize/no_bytes; if (++depth > max_nest_depth) max_nest_depth = depth; /* sort left partition first if smaller */ if (lsize < rsize) { if (litems > skip_threshold) quick_sort( list, litems, no_bytes, item_cmp); else if (litems > 1) (*skip_sort)( list, litems, no_bytes, item_cmp); if (ritems > skip_threshold) quick_sort( right, ritems, no_bytes, item_cmp); else if (ritems > 1) (*skip_sort)( right, ritems, no_bytes, item_cmp); } else /* right partition smaller so sort first */ { if (ritems > skip_threshold) quick_sort( right, ritems, no_bytes, item_cmp); else if (ritems > 1) (*skip_sort)( right, ritems, no_bytes, item_cmp); if (litems > skip_threshold) quick_sort( list, litems, no_bytes, item_cmp); else if (litems > 1) (*skip_sort)( list, litems, no_bytes, item_cmp); } SignatureThanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca) fake address use address above to reply [snip] >>>> One of the fast sorts has a structure whose symmetry wrt to two >>>>variables is obvious with a couple of gotos, but which is lost with [quoted text clipped - 12 lines] >a specific order of operations to replace element swaps by moves. >Opinion? [snipped code] It has been over 20 years, it was an instructor's example, and I do not recall exactly which fast sort it was. Your code is way longer than I remember. I grant your code has good symmetry. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. >[snip] > [quoted text clipped - 20 lines] >do not recall exactly which fast sort it was. Your code is way longer >than I remember. I grant your code has good symmetry. It was originally written to look similar and use similar structures and variables to other types of sort routines, for an algorithms and data structures course I taught: students probably learned more than they ever wanted about sorting. It's not as simple minded, straightforward, and problematic, as most academic examples tend to be: it's pretty close to production code. It also has useful comments, parameters for analysis and tuning, and instrumentation to allow analysis with a testbed and data generator. The elided code is almost the same volume again, to define and allow external parameter setting of static variables, and "skip_sort" routine for small partitions before a test run, tests to minimize worst case behaviour, and pick a median pivot. SignatureThanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca) fake address use address above to reply > an ER model is a "data model" but it is not a "database > model". Hair splitting. An ERD is a diagram. A draft. For presentation. Nothing more. > That is to say, all the relationships in the data that are > inherent in the composition of the data, whether it's adjacency, > navigational, or by common key data, are omitted from this model. 'Common key' is referential integrity, not 'relationships'. > That means that once you have an ER model that is satisfactory to both the > SMEs and the designers, you are still free to choose an implementation, > without having to "undo" decisions made in the ER model. As has been > said before in this forum, it's the difference between analysis and > design. So it is not a logical model. At most a conceptual one, and incomplete at that. 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" > > an ER model is a "data model" but it is not a "database > > model". > > Hair splitting. No, no, a thousand times NO! Data analysis is much more pervasive than database design. Data can be tied back to a conceptual model regardless of whether it is in one database or another, or even different kinds of databases, whether it's in exchange in the form of XML, CSV, of the responses to SQL SELECT, or in forms or reports or wherever. In particular, an enterprise could commit itself to a single conceptual model, for all data other than encapsulated data. And it could adhere to this model even if it continued to use products that don't talk to each other. > An ERD is a diagram. A draft. For presentation. Nothing > more. And ERD is a diagram that represents an ER model. The ER model can be more than the diagram. But even if it's only the diagram, so what? > 'Common key' is referential integrity, not 'relationships'. The use of foreign keys to represent relationships is one way to represent relationships. There are other ways. For example, in CODASYL, you define a set that defines a relationship between the set owner and the set members. Referential integrity is merely a mechanism for keeping foreign keys from getting orphaned. > So it is not a logical model. At most a conceptual one, and > incomplete at that. Incomplete for what? > Data analysis is much more pervasive than database design. Data can be > tied back to a conceptual model regardless of whether it is in one > database or another, or even different kinds of databases, whether it's > in exchange in the form of XML, CSV, of the responses to SQL SELECT, > or in forms or reports or wherever. Useless talk, since none of these gives you a data model as the RM does. >> An ERD is a diagram. A draft. For presentation. Nothing more. > > And ERD is a diagram that represents an ER model. The ER model can be > more than the diagram. > But even if it's only the diagram, so what? It is not a model. It is a draft. >> 'Common key' is referential integrity, not 'relationships'. > [quoted text clipped - 3 lines] > members. Referential integrity is merely a mechanism for keeping foreign > keys from getting orphaned. Hey, go back to your textbooks. Relationships aren't defined in the RM. >> So it is not a logical model. At most a conceptual one, and incomplete >> at that. > > Incomplete for what? For representing even the most basic constraints. 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 > > Data analysis is much more pervasive than database design. Data can be > > tied back to a conceptual model regardless of whether it is in one [quoted text clipped - 4 lines] > Useless talk, since none of these gives you a data model as > the RM does. If models are metaphors, can't a diagram provide such a metaphor? Sure some metaphors correspond to more components of what they are modeling than others, but that doesn't mean that a metaphor that is useful is not a model. It might make sense to use one metaphor when doing data analysis and another when doing database design, might it not? > >> An ERD is a diagram. A draft. For presentation. Nothing more. > > [quoted text clipped - 3 lines] > > It is not a model. It is a draft. A draft of a model? If I say that "trees are like people" then you can tell me that there is no good mapping from the consciousness of a person to something in a tree. Does that mean that my metaphor is a draft of a metaphor? NO. > >> 'Common key' is referential integrity, not 'relationships'. > > [quoted text clipped - 5 lines] > > Hey, go back to your textbooks. Relationships aren't defined in the RM. Well, the definition is often there, but it is incorrectly mapped to the word "relation" instead. It is a relationship (in mathematics) that is unordered, as someone else recently pointed out in the glossary discussions. > >> So it is not a logical model. At most a conceptual one, and incomplete > >> at that. > > > > Incomplete for what? > > For representing even the most basic constraints. Yes, you are correct that there is no map from the consciousness of a person to something in a tree in my metaphor. Cheers! --dawn >> Useless talk, since none of these gives you a data model as the RM does. > > If models are metaphors, can't a diagram provide such a metaphor? A database isn't a simple metaphor. It is a representation of a database. Speaking about metaphors will only confuse things now. >> Hey, go back to your textbooks. Relationships aren't defined in the RM. > > Well, the definition is often there, but it is incorrectly mapped to the > word "relation" instead. It is a relationship (in mathematics) that is > unordered, as someone else recently pointed out in the glossary > discussions. Hm, I see you don't want to learn, only to win the discussion... I won't play this game. 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 > >> Useless talk, since none of these gives you a data model as the RM does. > > > > If models are metaphors, can't a diagram provide such a metaphor? > > A database isn't a simple metaphor. It is a representation of > a database. So it's a complex metaphor. > Speaking about metaphors will only confuse things now. It seemed to be a word that would promote understanding in this discussion more than the word "model". > >> Hey, go back to your textbooks. Relationships aren't defined in the RM. > > [quoted text clipped - 5 lines] > Hm, I see you don't want to learn, only to win the > discussion... I won't play this game. I'm very open to learning and have learned quite a bit from this list (thank you's all around), but I do have a bee-up-my-uh-dress related to the misuse of the term "relation" in the field of relational theory. So, I did take the opportunity in this case not just to learn, but also to teach. If that was ill-advised, I apologize and will return to my dunce cap. ;-) --dawn "Leandro Guimar?es Faria Corsetti Dutra" > Hey, go back to your textbooks. Relationships aren't defined in the RM. Hey, go back to Codd's paper. He explicitly mentions relationships. > "Leandro Guimar?es Faria Corsetti Dutra" > > > Hey, go back to your textbooks. Relationships aren't defined in the RM. > > Hey, go back to Codd's paper. He explicitly mentions relationships. Good point ;-) --dawn "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > > Incomplete for what? > > For representing even the most basic constraints. Nonsense. I can see you've never worked with an ER model. Every ER model I've seen models relationships as either mandatory or optional, and as many-many many-one or one-one. Those are constraints. Most ER models classify attributes as single valued or multivalued. Some go further to list some attributes as optional. You would do well to learn more about a tool before dismissing it. > I can see you've never worked with an ER model. You are wrong. 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 > > I can see you've never worked with an ER model. > > You are wrong. In that case, I'm at a total loss to explain how you can make a ridiculous statement like the one you made earlier about ER not being able to express even the most basic constraints. How can you get something like that wrong, and do any successful work at all with the model? > I'm at a total loss to explain how you can make a ridiculous > statement like the one you made earlier about ER not being able to express > even the most basic constraints. Do you know the classes of constraints there are? 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 >> > Incomplete for what? >> >> For representing even the most basic constraints. > >Nonsense. I can see you've never worked with an ER model. The ER model can not represent many of the most basic constraints, although it can represent some basic constraints. Regards Alfredo > "Leandro Guimar?es Faria Corsetti Dutra" > > an ER model is a "data model" > but it is not a "database [quoted text clipped - 5 lines] > > Data analysis is much more pervasive than database design. I agree. > Data can be tied > back to a conceptual model regardless of whether it is in one database or > another, or even different kinds of databases, whether it's in exchange in > the form of XML, CSV, of the responses to SQL SELECT, or in forms or > reports or wherever. There is truth in that statement, but I would submit that logical data elements and structures, particularly in the relational model, can be tied back to a reconciliation and harmonization of one or more conceptual models (note: plural). Semantics inherently reflect one's view of the world and that one view doesn't necessarily correspond to another's view of the world. In some cases, we can accept a single view of the world, but with enterprise data management mechanisms, we must at least have the capability to accomodate all views of the world (different conceptual models) that are pertinent. Moreover, semantics are not necessarily time-independent, leading to another dimension of change in terms of conceptual definition. > In particular, an enterprise could commit itself to a single conceptual > model, for all data other than encapsulated data. And it could adhere to [quoted text clipped - 15 lines] > Referential integrity is merely a mechanism for keeping foreign keys from > getting orphaned. Relying on referential integrity artifacts, even when properly enforced in a DBMS, would seem to be insufficient in determining a true representation of relationships in my view. Any common attribute domain or sets of common attribute domains across relations will indicate potential relationships that might not be necessarily explicit or intuitively obvious. Moreover, trying to list and make sense of them in a conceptually coherent sense (i.e. business termonology) might be more work than its worth if not done in advance. It's even harder today with current implmentations because SQL domains do not give us a robust logical domain unification from a mechanized standpoint. - Dan > > So it is not a logical model. At most a conceptual one, and > > incomplete at that. > > Incomplete for what? > There is truth in that statement, but I would submit that logical data > elements and structures, particularly in the relational model, can be tied [quoted text clipped - 5 lines] > accomodate all views of the world (different conceptual models) that are > pertinent. Very good point. But reconciling two conceptual models that are independent of each other is much harder, IMO, than reformatting data to work with a different tool. In other words, it's the unified concpetual model that has to be acheived if you are going to integrate systems. > > There is truth in that statement, but I would submit that logical data > > elements and structures, particularly in the relational model, can be tied [quoted text clipped - 13 lines] > different tool. In other words, it's the unified concpetual model that has > to be acheived if you are going to integrate systems. Well, neither approach is necessarily easy. I would actually counter with my own opinion that it is the formal unified logical definition of data (domains) and sets of mappings between logical definitions that is the sufficient condition for integration. Concepts are far from logically cohesive or consistent across subject areas, domains, and universes of discourse. I get the sense that you might be deeply involved with data warehousing and ETL processes. In your experience, have you had successes enforcing and standardizing a unified grand conceptual model? Regards, - Dan > I get the sense that you might be deeply involved with data warehousing and > ETL processes. In your experience, have you had successes enforcing and > standardizing a unified grand conceptual model? Well, I've been involved with a few warehousing projects, but none of them were the grandiose "conquer the world" style of project. These were projects lasting about 13 weeks, after which the whole project was to be turned back over to the permanent employees of the client. Sucess was critically dependent on ETL. Real data sells the project better than test data. I've not been directly involved in the grand unified conceptual schema with clients, so I can't comment either favorably or unfavorably. What I will say, from experience, is that when integration happens, the driving force comes not for the technologists, but from the substantive users of the data. These are the people who have something to gain. And these people can understand a conceptual model much better than a technical model. Leandro Guimarães Faria Corsetti Dutra <leandro@dutra.fastmail.fm> wrote: >> an ER model is a "data model" but it is not a "database >> model". [quoted text clipped - 3 lines] > An ERD is a diagram. A draft. For presentation. Nothing >more. Bah! You think I am going to go to the trouble of drawing something useless? If I have an ERD, I use it to develop the database schema. [snip] >> That means that once you have an ER model that is satisfactory to both the >> SMEs and the designers, you are still free to choose an implementation, [quoted text clipped - 4 lines] > So it is not a logical model. At most a conceptual one, and >incomplete at that. Nope. It can be a logical model, if done to a RW amount of detail. It is not the physical model though. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. >> An ERD is a diagram. A draft. For presentation. Nothing >>more. > > Bah! You think I am going to go to the trouble of drawing > something useless? If I have an ERD, I use it to develop the database > schema. Yet it is just a draft. Incomplete and misleading. >> So it is not a logical model. At most a conceptual one, and >>incomplete at that. > > Nope. It can be a logical model, if done to a RW amount of > detail. It is not the physical model though. Physical is totally another story. ERDs can't represent the constraints of the logical model. 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 Guimaraes Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > >> So it is not a logical model. At most a conceptual one, and > >>incomplete at that. [quoted text clipped - 5 lines] > > ERDs can't represent the constraints of the logical model. What constraints ? :-) > Bah! You think I am going to go to the trouble of drawing > something useless? If I have an ERD, I use it to develop the database > schema. Good point. In one project, I used Data Architect to develop the ER model (DA calls it a CDM) and let DA generate the PDM automatically. The resulting PDM needed a few fixups, but only a few, and the project was ready to start testing the DB the next day. "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > >> > A model must include all aspects of the database, or it will be only a > >> > draft. [quoted text clipped - 9 lines] > > Is that better? Why yes it is, thank-you. Actually, how about manipulation (behavior) and integrity aspects....those fit into the properties in addition to structure. - Dan > how about manipulation (behavior) and integrity aspects....those > fit into the properties in addition to structure. Integrity certainly but manipulation? Well yes, if by manipulation you mean the operators associated with the user-defined types. 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 > > how about manipulation (behavior) and integrity aspects....those > > fit into the properties in addition to structure. [quoted text clipped - 3 lines] > Well yes, if by manipulation you mean the operators associated > with the user-defined types. Well no, relational operators don't fit that mold, but are manipulative aspects of the relational model. - Dan >> > how about manipulation (behavior) and integrity aspects....those fit >> > into the properties in addition to structure. [quoted text clipped - 6 lines] > Well no, relational operators don't fit that mold, but are manipulative > aspects of the relational model. Yes, but we were talking here specific logical models, not the general model of 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/ > > "Leandro Guimar?es Faria Corsetti Dutra" <leandro@dutra.fastmail.fm> wrote > > > [quoted text clipped - 16 lines] > I don't want to put words in his mouth, but I think he is arguing just the > opposite. I omitted the implied wink -- sorry ;-) --dawn > I'll accept that diagrams, in themselves, are not full mathematical > theories, but models they often are, it seems to me. What is your > definition of "model" (as a noun)? I'm getting tired of reading extraordinary and novel definitions of the meanings of words in this forum. Beyond a certain point, it's pointless. There's no question at all that the E-R model is a model. I don't care what Leandro says. It was introduced as a "data model" in 1976, and I have yet to see convincing evidence that it's not. Interestingly, some of Peter Chen's more recent publications refer to E-R in the context of "information modeling." The difference between "data modeling" and "information modeling" could turn out to be trivial, or it could be of the essence in your search for what you are searching for. I know that the difference between "data" and "information" has been central to my use of databases for 20 years. As far as whether Bachman diagrams do or do not represent one of the origins of the "hierarchical model of data" , I have yet to reach a conclusion on that. There's no question in my mind that Bachman diagrams (which he called "Data Structure Diagrams") were used to illustrate models of data well back into the 1960s. The word "hierarchy" occurs repeatedly in Bachman's writing. BTW, for reference, the term "data model" didn't start creeping into my vocabulary until sometime in the 1980s. And I'm hazy on how I got exposed to it. But as soon as a saw a diagram of the models, I "got the picture", so to speak. > As far as whether Bachman diagrams do or do not represent one of the origins > of the "hierarchical model of data" , I have yet to reach a conclusion on > that. There's no question in my mind that Bachman diagrams (which he > called "Data Structure Diagrams") were used to illustrate models of data > well back into the 1960s. The word "hierarchy" occurs repeatedly in > Bachman's writing. Slightly off topic -- We recently released a video interview with Clive Finkelstein, the father of information engineering. In the first 35 seconds, there is a tribute to 16 pioneers in our field. When we released the video recently, I asked several industry veterans how many of the 16 they recognized. Peter was the only person who replied he recognized all 16. You need Real Player or Windows Media Player to watch it: http://www.sqlsummit.com/CFinkelstein.htm |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.