Re: Modeling Data for XML instead of SQL-DBMS
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 28 Oct 2006 00:54:47 GMT
Message-ID: <rTx0h.11361$cz.179653_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> I think something's missing...
>
> A *conceptual model* is a description of entities and events
> as the users of the system to be delivered "see things." The
> more "user-friendly" it is, the more useful it is.
>
> It may, sometimes, be helpful to develop a more formal -
> possibly "computerizable" - conceptual design, but most often
> it makes sense to move to...
>
> ...a *logical design,* which should be a fully normal, orthogonal
> representation of the entities of interest, definitions of
> operations to be performed upon those entities, and declarations
> of all constraints needed to ensure integrity.
>
> A logical design might directly transliterate into dbms model
> language - "data definition language," in some dialects - but
> feature-deprived implementations and performance requirements
> often dictate...
>
> ...a *physical design* which includes artifacts that have nothing
> to do with the data the users want managed and don't closely
> resemble the conceptual design.
>
> When this occurs, I feel that a *presentation design* is necessary
> so that users can "see things" the way they expect to see them.
>
> Examples? Sure. The many-to-many relationships that might seem
> completely natural in the conceptual model will probably be
> "associated away" in the logical model. Any MVDs - which users
> might discount with, "Well, /everyone/ knows better than to try
> to do *that!*" - must be projected into "extra" tables [Excuse me
> for speaking SQL, here.] with appropriate constraints so that the
> dbms won't allow /someone/ to mistakenly do *that.* For similar
> reasons, the tables which form fragments of cyclic JDs must be
> opaque to the end user -- so that no one will conclude, for instance,
> that Bob sells Chevy motorcycles simply because they can see that Bob
> sells Chevys and Bob sells motorcycles.
>
> Strictly speaking, our work as data craft folk ends with a good
> logical design. Practically speaking, there are lots of other features
> that have to be added in in order to ensure success. Knowing where
> those features belong and how they should be provided requires good
> knowledge of relational theory.
>
Date: Sat, 28 Oct 2006 00:54:47 GMT
Message-ID: <rTx0h.11361$cz.179653_at_ursa-nb00s0.nbnet.nb.ca>
> David Cressey wrote:
>
>> "dawn" <dawnwolthuis_at_gmail.com> wrote in message >> news:1161897452.953712.279360_at_i3g2000cwc.googlegroups.com... >> >>> David Cressey wrote: >>> >>>> "dawn" <dawnwolthuis_at_gmail.com> wrote in message >>>> news:1161893884.428842.156110_at_m7g2000cwm.googlegroups.com... >>>> >>>>> OK, I'll review all the feedback and come back with a revised question >>>>> (once I have proper definitions for the logical data model and know >>>>> precisely for which model we need to know whether persistence will be >>>>> handled with UniData or DB2, for example). >>>> >>>> >>>> I'm going to suggest that there are at least two conflicting >>>> definitions >> >> >> of >> >>>> "logical data model" in use in the newsgroup, regardless of what the >>>> glossary says. >>> >>> >>> I think it is mum on this matter. >>> >>> >>>> One of the definitions might be called "preliminary design". >>>> The other might be called "programmer visible implementation." >>> >>> >>> Yes, yes, very good summary. I was using the former and after reading, >>> I switched to the latter. However, that is being contested here. >>> >>> >>>> Note that, >>>> in the case of design choices that are invisible to the programmer, it >>>> doesn't matter why they are invisible. >>>> >>>> >>>> >>>>> Only because I need to rephrase the question and am apparently using >>>>> the term Logical Data Model incorrectly, yet I'm not certain whether >> >> >> if >> >>>>> you and I are both given the same conceptual data model and you are >>>>> implementing it in Oracle and I in UniData, whether we might have the >>>>> same logical data model, although different implementation data >> >> >> models, >> >>>>> or whether our logical data models would differ. Mine would include >>>>> multi-valued attributes, for example. Thanks for any clarification. >>>>> --dawn >>>>> >>>> >>>> Here's the way I learned the terms, back in 1984 (no pun intended). >>>> >>>> conceptual data model (CDM): Driven by requirements. results from >>>> data >>>> anlysis. |data model independent. Example: er modeling. >>> >>> >>> agreed. >>> >>> >>>> logical data model (LDM): design model, cannot be changed without (in >> >> >> some >> >>>> situations) requiring (some) application code rewrite. >>>> result of preliminary design, driven by conceptual model, plus >> >> >> some >> >>>> indication of how the data is to be used. Data model dependent, DBMS >>>> independent, with a class of DBMSes that are all based on the same >>>> data >>>> model. Exapmple: relational data model. >>> >>> >>> Yes, that is how I was using the term, as a model that is data model >>> dependent. So, if I am going to implement in SQL Server or DB2, my >>> logical data model will be different than if I am going to implement in >>> UniData or OpenQM. Perhaps the confusion in the terminology is that if >>> one has blinders on and see only one class of DBMS tools, then they >>> think of the logical data model as actually being DBMS-independent, >>> rather than DBMS-independent for a particular class of DBMS's (or for a >>> particular "data model"). >>> >>> >>>> physical data model (PDM): late design model, driven by logical data >>>> model, but also by data volume, resources, load, and speed >> >> >> priorities. >> >>>> DBMS product (and perhaps version) dependent. Example: p.d.m. for >>>> implementation on Oracle. >>> >>> >>> I have used physical data model for the model used by a DBMS tool. So >>> the physical data model was "hidden" from me as a developer, until >>> addressing a performance problem, for example. >>> >> >> >> The usage of PDM that I use agrees more or less with the usage of PDM in >> Data Architect. >> Note that DA itself goes directly from CDM to PDM. >> >> Using Oracle strictly for the sake of example, such things as tables >> design >> are part of the PDM, but derived from what I would call the LDM. >> However, >> such things as tablespace design and the mapping of tables onto >> tablespaces >> would be part of the PDM but not part of the LDM. While DA does not >> have a >> separate LDM, it does classify the objects in the PDM as "schema >> objects" >> (domains, columns, tables, and indexes), and "database objects" >> (tablespaces, maps, etc.) This pretty well aligns with the distinction I >> make between "logical" and "physical" design, and therefore between >> LDM and >> PDM.
>
>
> I think something's missing...
>
> A *conceptual model* is a description of entities and events
> as the users of the system to be delivered "see things." The
> more "user-friendly" it is, the more useful it is.
>
> It may, sometimes, be helpful to develop a more formal -
> possibly "computerizable" - conceptual design, but most often
> it makes sense to move to...
>
> ...a *logical design,* which should be a fully normal, orthogonal
> representation of the entities of interest, definitions of
> operations to be performed upon those entities, and declarations
> of all constraints needed to ensure integrity.
>
> A logical design might directly transliterate into dbms model
> language - "data definition language," in some dialects - but
> feature-deprived implementations and performance requirements
> often dictate...
>
> ...a *physical design* which includes artifacts that have nothing
> to do with the data the users want managed and don't closely
> resemble the conceptual design.
>
> When this occurs, I feel that a *presentation design* is necessary
> so that users can "see things" the way they expect to see them.
>
> Examples? Sure. The many-to-many relationships that might seem
> completely natural in the conceptual model will probably be
> "associated away" in the logical model. Any MVDs - which users
> might discount with, "Well, /everyone/ knows better than to try
> to do *that!*" - must be projected into "extra" tables [Excuse me
> for speaking SQL, here.] with appropriate constraints so that the
> dbms won't allow /someone/ to mistakenly do *that.* For similar
> reasons, the tables which form fragments of cyclic JDs must be
> opaque to the end user -- so that no one will conclude, for instance,
> that Bob sells Chevy motorcycles simply because they can see that Bob
> sells Chevys and Bob sells motorcycles.
>
> Strictly speaking, our work as data craft folk ends with a good
> logical design. Practically speaking, there are lots of other features
> that have to be added in in order to ensure success. Knowing where
> those features belong and how they should be provided requires good
> knowledge of relational theory.
>
>> Some in this NG object to lumping indexes in with the tables. These >> people >> point out, correctly, that an index influences the preformance of a >> query, >> but not its logical result. While that's a strong argument, I prefer >> to go >> along with DA on this, and involve programmers (somewhat) in the >> question >> of whether the queries will run fast or slow.
What a self-congratulating idiot. Do you really have to inflict this stuff on us? If you just cannot stop yourself from replying to her nonsense, can you not at least snip out the self-congratulatory bullshit? Received on Sat Oct 28 2006 - 02:54:47 CEST