Re: Weak entity types

On Aug 17, 7:23 am, paul c <toledobythe..._at_oohay.ac> wrote:
> Hugo Kornelis wrote:
> > On Sat, 11 Aug 2007 15:55:29 -0700, beginner16 wrote:
>
> >> hello
>
> >> a)
> >> Weak entity type cannot be uniquely identified by its own attributes
> >> alone and thus needs another entity to be uniquely identified.
> >> So in relational model, every relation which has primary key made of
> >> foreign key and perhaps some other attribute, is weak entity type?
>
> > Hi beginner16,
>
> > Choose your words with care. There are no entities, either weak or
> > strong, in the relational model.
>
> > Entitiy types (from an ER model) can be REPRESENTED in the relational
> > model. This is done in the form of tables.
>
> > You are correct that a table that represents a weak entity type will
> > always have a primary key that consists of at least one foreign key and
> > usually at least one other column - except if the "other" entity type
> > (there's a name for it, but it has slipped my mind) is, for whatever
> > reason, not represented as a table. The reverse also holds true - a
> > table with a primary key that consists of at least one foreign key plus
> > some other column can be represented in the ER model as a weak entity
> > type, except when the table referenced by the foreign key is not
> > represented by an entity type.
>
> >> Ok, but I could instead of creating a foreign key create another
> >> attribute which could uniquely identify rows in a table.
>
> > If you add a new identifying attribute to a weak entity type in the ER
> > model, it does indeed cease to be weak. You will of course have to get
> > the business to sign off on your idea. "Hey, I have an idea, let's get
> > rid of this complicated stuff of having a mail name that has to be
> > unique within the domain, let's replace email adress with a single
> > 128-character string - that way, email address can be a strong entity
> > type rather than a weak one!" Good luck on getting management to sign
> > off on that one! <g>
>
> >> By
> >> definition the relation would no longer be weak entity type --> there
> >> has to be more to this --> perhaps it's more of a subjective thing?!
> >> Meaning two tables can both have compound primary key, but one table
> >> could be considered weak and other strong entity type, based on how
> >> the person creating the two tables would perceive the world?! Can you
> >> show me an example?
>
> > It is subjective indeed - in that an ER model has to depict the
> > conceptual model, IOW you model how the users of the data view the
> > world, not how it is (or will be) implemented.
>
> >> If so, aren't there some regulations that would in more objective way
> >> define when an entity is weak and when strong ( assuming entity has
> >> compound primary key in both cases )
>
> >> b)
> >> Looking at few E-R diagrams I noticed that attributes being drawn for
> >> particular entity type ( entity type is drawn as rectangle ) often
> >> don't include an attribute acting as foreign key ?
> >> I'd understand if this entity type was weak entity type and thus would
> >> include foreign key attribute only when E-R model was converted into,
> >> say, relational model, but in the examples I saw the entity type
> >> wasn't represented as a weak type. So when do we also draw foreign key
> >> attributes and when not?!
>
> > Again, there are as many variations in how ER models have to be drawn as
> > there are publications on ER ;->
>
> > Some don't depict attributes at all (eg Yourdon ER), some use a special
> > symbol for weak entity types so that you "know" that the key of the
> > "other" entity type will also aid in identifying occurences of the weak
> > entity type (eg Method Manager ER), and some do draw the identifying
> > attributes from the "other" entity type at the weak entity type as well,
> > usually using a special symbol (eg Chen ER).
>
> > Hmmm, rereading your question, I'm not sure if I have answered it. If I
> > didn't, then I don't understand the question.
>
> > Best, Hugo
>
> Maybe I'm making the above exchange into more than it is but speaking of
> word choices and not to question my betters but I wish Codd had never
> used the term "model". It has so many connotations that are prey to
> willful twisting, such as "simulation" or even "emulation" that confuse
> the literalists, mystics as well as OO fans who dwell among minority
> rest of us into thinking that they can re-create reality in a machine.
> Also encourages the weak-minded to dream that just because there are
> mechanical ways that relations can be manipulated that there must be
> equally mechanical ways to define useful relations. The mathematical
> parallels that people come up with are useful but they remain
> abstractions by definition. Plus they are extremely partial, for
> instance there doesn't seem to be an algebra that embodies persistence
> without resorting to using the word "persistence" and I suspect there
> couldn't be one. Sometimes I wish Codd had called his invention the
> relational abstraction, then it might have been more clear that there
> remains an irreducible element of Picasso's clever madness in all of
> this, especially when it comes to cutting out the crap.
>
> p

I've actually written a reasonable amount about this now for the "Data Model" part of the db-resource I'm knocking together - I'll post some of it if anyone's interested. The etymology of the term is actually quite engaging, and I've pretty much come to the conclusion that the term 'model' does make sense in our context. But as with most paronyms, the term has ended up with subtly different meanings in maths, engineering and hard science - we just have to be really careful to recognize that there is a formal definition that applies to our field. After all a database is little more than a 'Model of Data' (its primary players being facts, and its operators acting on their manipulation) in the scientific sense. Received on Fri Aug 17 2007 - 13:19:36 CEST