"Andreas Ntaflos" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Friday 05 September 2008 23:59:25 Igor Tandetnik wrote: >> Define "weak entity". Precisely what properties does it have that are >> not represented in the model? > > A weak entity has no possible combination of attributes that would > uniquely identify it in the relational model. It's existence depends > on another entity. The building-room-example illustrates this nicely. > There's nothing to hinder two separate, uniquely identifiable > buildings to have the same room number scheme, so to identify a > single room the key of the building is needed in combination with the > room's numer.
Well, in this case you've violated your "conceptual model" the moment you decided to assign unique auto-generated numbers to your rooms, in a way completely divorced from how numbers would be assigned to real rooms in real buildings. As the room is no longer a "weak entity" by your definition, of course you have difficulty modeling it as one. Why again are you surprised? > The property the desired model has that are not represented in this > model we discuss is that a room's primary key does not contain a > reference to the primary key of the owning entity. It is globally and > uniquely identifiable without ever looking at the building. And that is bad because...? > This is a practical consequence and thus the model you propose is > possible and probably even feasible, but it is no longer the model I > wanted to implement. Plus I don't really see why it would be wrong to > use an auto-incrementing key for the roomID while keeping the tuple > (roomID, buildingID) as a primary key. What's the point? What's so special about PRIMARY KEY that you absolutely must have one? All it does is guarantee uniqueness - but you already have that. You are getting hung up on the syntax of your CREATE TABLE statement, rather than on the properties of the underlying relation. Let's put it this way: are there any queries that you can't run against the current model, but would be able to run against your hypothetical ideal model? And if there are no such queries, what's the difference between the two? > It seems that there are two choices available: go with your model, > which is simpler and certainly more efficient, but loses an aspect of > the desired model (namely that rooms are by themselves not uniquely > identifiable). Again, it's not the model that loses the property - it's your initial decision of using unique room numbers. After that, you just insist on a syntactical game of make-believe, for no other reason that to make yourself feel better, as far as I can tell. You say: I want to assign unique numbers to rooms, but I want to pretend the rooms are not uniquely identifiable by those unique numbers. Does this really make sense to you? Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
