[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Designing XML to Support Information Evolution

• To: "Hunsberger Peter" <Peter.Hunsberger@S...>
• Subject: Re: Designing XML to Support Information Evolution
• From: "Chiusano Joseph" <chiusano_joseph@b...>
• Date: Mon, 17 May 2004 15:58:00 -0400
• Cc: "Roger L. Costello" <costello@m...>, xml-dev@l...
• Organization: Booz Allen Hamilton
• References: <1E0CC447E59C974CA5C7160D2A2854EC097E0E@S...>

As long as we're on the subject of XML and normalization, I'm reminded
of the following 2 XML.com articles on this subject from late 2002:

http://www.xml.com/pub/a/2002/11/13/normalizing.html
http://www.xml.com/pub/a/2002/12/04/normalizing.html

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World

"Hunsberger, Peter" wrote:
> 
> Chiusano Joseph <chiusano_joseph@b...> writes:
> 
> <snip/>
> 
> > > >
> > > > Of course, in some cases this can violate second and/or
> > third normal
> > > > form (I forget which - it might be both...it's been a long time
> > > > since I studied this in my undergrad, and it's now become
> > > > instinct;). Using Roger's original example, let's say
> > that we have a
> > > > business rule that allows a picker to belong to multiple lots -
> > > > perhaps we're short on pickers and need to share them
> > among multiple
> > > > lots in alternating shifts. Let's also say that we need
> > to represent
> > > > properties of a picker
> > > > - I'm a city boy so I'll take my best guess...manufacturer, size,
> > > > etc. Repeating the properties of a picker over and over
> > for each lot
> > > > to which it is assigned violates one or both of those
> > normal forms.
> > > >
> > >
> > > Umm, yes, but I'm not sure what the issue is?  Store the data
> > > relationally, fully normalized, represent it hierarchically.
> >
> > The biggest issue right out of the gate, of course, is file
> > size - with XML files already being larger in size than
> > data-only files, this approach would take up inordinate
> > amounts of file size and bandwidth to transmit. That's a
> > complete show-stopper in many instances.
> 
> Ok, I see where you're going...  XML normalization can be a lot harder
> than DB normalization, but yes, you need to be sensible.  That's why in
> our case we separate the hierarchical metadata model from the actual
> data.  The model is small, the data is large, but flat.  The exception,
> is our data relationship model which is sort of half way in between:
> it's only the data relationships and not all the data, but it can be a
> big hierarchy.
> 
> As long as you're using conventional computer systems you can't avoid
> this, sooner or later you have to make the space time complexity trade
> offs.  So, if you've got lots of time, go ahead build the hierarchy from
> scratch, but be aware that a pre-assembled hierarchy can cut a couple of
> orders of magnitude out of the processing time...

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton

• References:
  • RE: Designing XML to Support Information Evolution
    • From: "Hunsberger, Peter" <Peter.Hunsberger@S...>

• Prev by Date: RE: Designing XML to Support Information Evolution
• Next by Date: Re: Designing XML to Support Information Evolution
• Previous by thread: RE: Designing XML to Support Information Evolution
• Next by thread: RE: Designing XML to Support Information Evolution
• Index(es):
  • Date
  • Thread