Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] PIW Relationships Modelling

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] PIW Relationships Modelling
  • Date: Wed, 20 Jul 2005 09:36:03 -0500

Richard Morris writes:
> Chad Knepp wrote:
> > My use of denormalization was talking over my head. I didn't even
> > know someone had created theories behind it. Looks like I have some
> > reading to do.
>
> For the PFAF dataset. I'd say normilisation issues are a real headache
> from a database admin point of view. Theres some terible problems with
> the same data being represented in two or more tables and only one of
> which is updated.

Yup, the Eden dataset has the same data, but is much closer to being
fully normalized. I did have Relational Database Systems (CS 420
IIRC) about 7 years ago, but at the time I was more interested in
Linux/UNIX administration (and rooting campus boxes) to want to pay
much attention. I think Sean's talk of denormalization and star
schema is something different than this or else I really was asleep
then...

> > > > IIRC, Bear suggested a two/three column schema with a primary key
> > > > and then an attribute and followe by data of the attribute.
> > > > Something like:
> > > >
> > > > id | attribute | data
> > > > ---------------------
> > > > 34 height/feet 20
> > > >
> > > > As I said earlier this doesn't scale well in an RDBMS.
>
> This system would fit well with and RDF style triples. Basically
> you have
> source | atribute | object
> where atribute could be any sort of relationship.
>
> It could lead to a simple database structure, most everything could be
> encoded in three tables.
>
> > >
> > > This represents data entry optimized designing. It scales very
> > > well with RDMS tools, but not if you don't use the data that way.
> > > This is a schema discussion, not about the tool to implement it.
> >
> > Not sure I follow this. Bear was suggesting this because we were
> > having trouble deciding what [plant] attributes where important and
> > which weren't (a schema discussion correct?). His suggestion would
> > disolve most of the need to figure out what was important ahead of
> > time and essentially make a row out of each column of several tables.
> > I love the idea from an ease of implementation standpoint, but I'm not
> > sold on the extra select to reassemble the plant row and lack of
> > contraints (anything could be NULL). OTOH, this is really close to
> > the loose tagging way of data organization I'm currently in love
> > with.
> >
> > Waddya think? I would really love to be convinced that this is a good
> > idea. I'm going to read some ralphkimball.com stuff -n- relax.
>
> I'm very much in favor of loose tagging and keeping the type of
> atributes open. This could future proof the system so that if someone
> wants to come along and add some new atribute it would be possible.

I'm not sure this is as much of a benefit as would seem at first.
Adding new types of data attributes will likely require some changes
in the client in order to display it intelligently. Allowing an
uncontrolled vocabulary will also allow things like *height* and
*hieght* to slip in on the same and different plants.

The big benefit IMO is that our schema choices now we don't confine
our user contributions later. For example root habit is currently
missing from the dataset. Maybe it didn't seem important to Ken or
maybe he didn't have access to that information, but by allowing tagging
a plant with *very deep tap root* or *root depth/meters | 5, root
width/meters | .1* we don't limit user contributions to our initial
choice of schema. Note: the problem with the later example is that it
requires some knowledge intelligence somewhere to understand whether 5
meters is shallow, medium, or deep.

> <tangent>
> I've been pondering the whole tagging concept. Basically its a move to a
> set theoretic concept. Rather than have trees or anything like that you
> can define things purely in terms of sets.
>
> In principal it would be posible to create a file system based around a
> set/tagging concept. Rather that define a directory structure it would
> be posible to allow each file to be a member of a number of sets.
> To locate a file you just type in the the names of the different sets it
> belongs to and it would dispaly the intersection of the sets.
>
> So rather than have a directory
> /work/projects/pcplantdb/datastructures
> I have a number of sets: work, projects, pcplantdb, datastructures.
> A file in the above directory would be a member of each set.
>
> To find files I could just enter "pcplantdb" or "datastructures".
> If thats too many I could enter "pcplantdb datastructures" which
> displays files in both sets.
>
> Conceptually you can view a tree structure as a specific type of set
> structure where there is strict inclusion. I.e. all elements in
> projects are also elements of work.
> </tangent>
>
> So thats confused everybody. Time for bed.

I actually think that's a pretty good example of how tagging can work
for us. If a plant has 4 tags and the user selects all of them, it
will be pushed to the top of the results.


Cheers,
Chad

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page