NBLUG Library ?

[dugan at passwall.com]

On Thu, Oct 24, 2002 at 10:17:09PM -0600, hanksdc at plug.org wrote:
> On Thu, 24 Oct 2002, Eric Eisenhart wrote:
> 
> > On Thu, Oct 24, 2002 at 03:42:06PM -0700, Ron Wickersham wrote:
> > > this is not something i understand very well, but the problem shows up in
> > > the structure and rules for the MARC records, which fit multi-valued
> > > database model (like pick).
> > >
> > > a search in the koha archives didn't yield the pages i read, but i did
> > > find this link that sounds similar to the issues raised on the koha list:
> > > http://sunsite.berkeley.edu/XML4Lib/archive/0112/0010.html
> >
> > That page talks about the proper relational method for creating
> > "multi-valued fields" being complicated enough that it's a hassle.
> >
> > Example:
> > DB with multi-valued fields where you give up on proper relational stuff:
> >
> > Foos
> > ----------
> > id  |int
> > name|varchar
> > bar |multi-value [one, two, three]
> 
> While I'd need to look at the MARC format a little more to fully
> understand this, a design much like this could still adhere to the
> relational model (and yes, still be 'proper'). Essentially you would have
> to design a user-defined type (let's call it multi-value-triple), along
> with the appropriate operators to manipulate that type, as well as
> means to enforce the allowable domain of values possible for that type.
> Postgres allows you to do this. But despite the apparent lack of atomicity,
> such a design would still be in 1st normal form, and hence, faithfully
> adhere to the relational model, which prescribes that each table be at
> least in 1NF.
> 
> Extending this idea, lots of complex data could be considered atomic, as
> long as the internal representation of the data type is invisible to the
> user, and as long as an 'object' of the data type can be manipulated only
> by operators defined for that type. In that sense, is it atomic.
> 
> To quote C.J. Date on the subject (he explains it better anyway):
> 
> "Thus we can have domains of audio recordings, domains of maps, domains of
> video recordings, domains of engineering drawings, domains of legal
> documents . . . The only requirement is that . . . the values in the
> domain must be manipulable <i>solely</i> by means of the operators defined
> for the domain in question; the internal representation must be hidden."
> [1]
> 
> More on this can be found in the first chapter of Fabian Pascal's
> excellent book, 'Practical Issues in Database Management'. (Also see
> www.dbdebunk.com for more of this type of discussion).
> 
> A lot of argument today against the relational model is its perceived lack
> of support for complex data, but in this light I don't think that
> argument holds water.
> 
> Now I'd need to look more at the MARC format, but I'd venture to guess it
> wouldn't be as difficult as it might appear at first glance to design a
> relational database to comfortably hold it, given the utility of
> the appropriate user-defined data types to accomodate the data.

FWIW, I beliebe that CPAN has a MARC record perl module. If you have
issue with MARC record and storage, Perl may be a good tool and exceed
PHP in functional web based application.

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ PGP++
t at -(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html