Re: Modeling Data for XML instead of SQL-DBMS
Date: Sat, 28 Oct 2006 02:22:42 +0200
Message-ID: <4542a213$0$320$e4fe514c_at_news.xs4all.nl>
dawn wrote:
> 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. >> I did not know that products with anonymous m:n relationships exist. >> >>> Am I missing the mark on what you are saying? >> No, I think you get it. >> This makes the requirement for having to get rid of >> m:n relations an implementation dependent one.
>
> 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.
I am not so sure, here. In the example you gave in the other post I am sure your NULL was not in the facts but in the (silent) implementation.
> 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?
2VL assumption, yes. Not so sure about those NULLs (whether as 3VL non-value or as 2VL value (- what? - I just don't know how that works). I got rid of a lot of nasty NULLs - every time I tried I could eventually find which implementation consideration introduced it. I think they just aren't needed in logical models. Received on Sat Oct 28 2006 - 02:22:42 CEST