Re: Modeling Data for XML instead of SQL-DBMS

mAsterdam wrote:
> dawn wrote:
> > mAsterdam wrote:
> >> dawn wrote:
> >>> mAsterdam wrote:
> >>>> dawn wrote:
> >>>>> mAsterdam wrote:
> >>>>>> dawn wrote:
> >>>>>>> mAsterdam wrote:
> > <snip>
> >> In the logical model there is strictly no
> >> more need for implementation specifics than in the conceptual
> >> model. However, the team is closer to cut-over day, so
> >> implementation is more on their mind. So in real logical model
> >> documents you will see some implementation stuff, but that
> >> is noise, not signal.
> >
> > OK. Restating this, I think that here you are saying that a designer
> > could create a logical data model without knowing whether the
> > implementation will use a SQL-DBMS, a MUMPs product, a Nelson-Pick
> > product, or XML. Additionally I think you are saying that when the
> > design does know the target, this often influences the logical data
> ^team<
> > model, but that is not a good thing.

>

>


> >>> there we go to "design."  I think of the conceptual model as analysis


> >>> and the logical model as design.  I don't really think about any other

> >>> models, with iterations of the logical model until it becomes the

> >>> version of the logical model that gets implemented.  I used to think of

> >>> the logical model as the one at the start of that process, but after

> >>> reading a bit, I started to think of it as the one at the end of the

>


> >> If these different models are defined, they are


> >> defined as deliverables in some 'formal' (handbook/official/case-tool)

> >> software development process. There is no generally accepted

> >> reference process, AFAIK, so I have to rely on those I dealt with.

> >> In one official process the requirements for these deliverables

> >> (or artifacts if you prefer) were such that the conceptual models

> >> allowed for many to many relationships, while in the (integrated)

> >> logical model they were forbidden.

> >

>

I'll just take this point for now and see if I can understand what you are saying.

What I am trying to make clear is that we can use tools where we can indicate a Books and an Authors entity, without adding a third relation into the mix. We might have a Books relation that includes an attribute whose value is a list (or set) of Authors and an Authors relation with an attribute that is a list of Books. If there are no attributes in the relationship between book and author that are relevant to our system, there is no need to introduce any relationship entity.

Am I missing the mark on what you are saying? Thanks. --dawn Received on Fri Oct 27 2006 - 23:02:24 CEST