Re: Modeling Data for XML instead of SQL-DBMS
Date: Sat, 28 Oct 2006 00:32:59 GMT
Message-ID: <%yx0h.19384$Cq3.18089_at_tornado.ohiordc.rr.com>
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.
>
> Note that tablespaces and table maps are transparent to the programmers, but
> NOT to the database builder. I'm not sure what you meant by your "not
> dealing with this as a developer". Did you mean as a programmer?
>
>
> There are layers below that that are striclty internal to the DBMS, and
> that we can treat as even transparent to the database builder.
>
>
> Note that *in addition* to the data models I'm discussing here, a system
> also has models that describe the processing to be done. There is, for
> instance, the functional model, which describes the tranformations used to
> generate outputs from inputs. If you are treating database design as
> subsystem design, then reconciling the logical data model with the process
> model can be important, even if rather involved.
>
>
>
>
Received on Sat Oct 28 2006 - 02:32:59 CEST