[AccessD] Normalization discussion

But you're talking in broader terms. In this database, I'd not be tracking
species without the animals. I would have no reason whatsoever to track
species.

I'm listening because you make sense -- but I'm not certain what you've
said actually applies to what I'm doing. The animals are the parent table
-- everything in the database applies to an individual animal.

Susan H.


On Fri, Aug 29, 2014 at 12:38 PM, James Button <jamesbutton at blueyonder.co.uk
> wrote:

> Child table is one where an entry cannot exist without the parent entry
>
> As in you can define the species in a table without specifying the animals
> in
> the species
> So Species would be the PARENT of animals because
> An animal has to be within a species, but a species can have several
> animals in
> it
>
> Delete (exterminate) a species and you lose lots of animals
> Delete (exterminate) an animal and you still have others of the same
> species
>
> JimB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Friday, August 29, 2014 4:39 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Normalization discussion
>
> Right now, most of my foreign keys in the parent table are simple lookups.
> For instance, species -- each individual has a species and those are in a
> child table. We'll update that table infrequently -- only if we add a new
> species. We have several individuals of each species. Another is gender --
> female and male, but the parent table has a foreign key to the gender
> table. (Gender's probably overkill, but I'm on autopilot I think). I'm also
> tracking acquisition method -- there are only three, so again, it's a
> lookup table and not a true child table.
>
> Susan H.
>
>
>
>
>
>
>
>
> On Fri, Aug 29, 2014 at 10:18 AM, Charlotte Foust <
> charlotte.foust at gmail.com
> > wrote:
>
> > A foreign key is a key that points to the PK in another table.  You're
> > mixing keys with parent child relationships, which are defined through
> > keys.  In a data warehouse, you put a bunch of keys in the central table,
> > but in a regular database you put the parent PK into the child tables so
> > they know their mommy,  The idea is to put the keys where they are
> needed.
> >
> > Charlotte
> >
> >
> > On Fri, Aug 29, 2014 at 6:07 AM, Susan Harkins <ssharkins at gmail.com>
> > wrote:
> >
> > > I'll spend the morning rereading the book Martin and I wrote, brushing
> up
> > > on the normalization part. I've forgotten a lot of the basics. I'm
> > writing
> > > an animal tracing database in Access and I'm trying to remember if it
> > > matters where the fk goes. Now, I remember its purpose and all that,
> but
> > it
> > > would be so much simpler if I could just drop them all into the main
> > table
> > > instead of adding a fk to all the child tables to the main table -- I
> > think
> > > anyway.
> > >
> > > So, I've got a main table of animals and all of the remaining tables
> are
> > > child tables of a sort and a few lookup tables. Is it reasonable to
> just
> > > add a fk to all those child tables in my parent table?
> > >
> > > I just don't remember. I haven't built a database in... seriously... 10
> > > years? It's been long enough that I'm really struggling.
> > >
> > > Susan H.
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>