Re: Declaring super types

From: Tegiri Nenashi <tegirinenashi_at_gmail.com>
Date: Mon, 26 Apr 2010 11:02:35 -0700 (PDT)
Message-ID: <8347e95c-224b-4e05-94de-749953339f27_at_o15g2000pra.googlegroups.com>


On Apr 25, 5:57 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
> On Apr 25, 3:02 pm, r..._at_raampje.lan (Reinier Post) wrote:
>
> > Tegiri Nenashi wrote:
> > >Second, why would I add redundant attributes to a Circle? If the idea
> > >is to make both relations to have the same set of attributes, then we
> > >go back to the previous paragraph: I'm interested to see a convincing
> > >example of two relations with different sets of attributes that fits
> > >your definition.
>
> >   Person: first name, last name, date of birth
> >   Citizen: first name, last name, date of birth, country of citizenship
>
> > I've done some student instructions with that textbook and I still
> > use the same ER modelling technique for myself; I've noticed that
> > this is-a comes up pretty often, and that it is helpful, i.e. many
>
> Does "is-a" come up because it follows naturally from the design
> process? Or does it come up the same way that Object Oriented comes
> up these days in programming discussions ie being shoe-horned into
> the conversation whether needed or not?
>
> How is this is-a concept "helpful" as you claim? For example, I
> can't imagine myself every creating a database with the separate
> Person and Citizen tables above.
>
> > modelling errors I see can be explained in terms of "is-a being overlooked"
> > or "is-a being modeled incorrectly".  It is also fairly common in tools.
>
> And what happens if we simply banish "is-a" from our thinking and
> vocabulary entirely? Are those modelling errors eliminated? What
> do we lose by sacrificing this hierarchical notion?

Perhaps both Person and Citizen don't have to be physical tables (as you implied)? They are relations. Let me borrow a better example from wiki.postgresql.org/images/9/91/Pguswest2008hnd.pdf , page 12. Ignoring all the modeling nonsense on the preceding and follow up pages, this example is quite insightful. I would design this schema as the two physical tables: Carnivores and Herbivores. The Animals relation is generalized union of Carnivores and Herbivores and would be better physically represented as a view, while Omnivores is natural join, which is another view. Received on Mon Apr 26 2010 - 20:02:35 CEST

Original text of this message