Re: Modeling Data for XML instead of SQL-DBMS

"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. 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 - 00:11:40 CEST