Re: Modeling Data for XML instead of SQL-DBMS

mAsterdam wrote:
> dawn wrote:
> > mAsterdam wrote:
> >> dawn wrote:
> <snip>
> >>> Why should they be forbidden when they are quite viable logically and
> >>> can be implemented in some DBMS tools?
> >> [m:n]
> >> No 'should', really. Whatever the implementation will be,
> >> at some point in the process the many to many relationships
> >> will have to be transformed into named things
> >> (SQL: tables with at least two foreign keys, Codasyl: records
> >> in at least two sets, etcetera).
> >
> > 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.

>

>

>

Happy, happy, joy, joy. It sounds like we reached one point of understanding. Progress. I repeat this question in my next response, so you can ignore there.

Thanks. I now understand that you think the logical data model should not assume any particular target DBMS tools. Additionally, we have covered the m:n question, with both of us having a current understanding that deciding to remove such relationships from an LDM would not be implementation-dependent.

Then we have that nasty null thing, which we can ignore for now, with you recognizing that when I'm modeling for a non-SQL-DBMS implementation, I have no problem including attributes that are permitted to have null values (yes, values, not to be confused with SQL NULLs). It would not at all be considered a "best practice" to avoid null values for use with 2VL.

Given that it is called a logical data model, it works for me to think that the one component from the target environment that people opt to pull into their LDM is what logic system they are working with. If you do not have enough information to make an educated guess about your target platform data model (product family), then I would think the LDM should assume 2VL, as is used thoughout most software, which also happens to make for a simpler model. Add the complexity in for 3VL and the SQL NULL only when you know that is your target.

Does that work for you? --dawn Received on Sat Oct 28 2006 - 00:41:30 CEST