Walk away, people, walk away. No one will be convinced by the others, and no one else cares. Agree to accept that you each believe the other to be wrong, insulting, and insulted, and walk away.
There is no win for anyone to be had.
Awwwww, but I was sure that if I wrote the same argument in just 1,348,492,308,238,048,583 more ways, my opponent would finally see the light, stop disagreeing, and spend the rest of his life appending "What he said." to the end of every paragraph I write. Now what am I going to do with the rest of the afternoon? :)
In other words, you're right. Any objections if I delete this? I don't think anyone would miss it.
I'd be happy with my opponent just understanding that answering questions with the expectations that the other person already knows the field as well as oneself is rather silly. And I'd rather you let it cool for a few weeks before deleting it.
Tsk. Tsk. You're doing it again. I've had wives like you.
That comment invites too many potentially cruel replies. Must... resist...
Some people believe using the term "entity" to represent the general definition of things that belong to a particular kind of entity is wrong. They believe the word entity should only be used for "entity instances".
In other words -- in my experience, in entity relationship modeling, the word "entity" is used the way "class" is used in object-oriented modeling.
See FearOfAddingTables for context (BTW, in FearOfAddingTables I used Entity as class, not as instance.)
I really find it surprising that it could be interpreted as "a table with single row" or as "lets have a table for each instance of an entity class" this is the first time I see that interpretation for "one entity per table" (note that I originaly wrote "one entity concept per table" (no you didn't)), but apparently a discussion started on the particular intepretation of the word "entity" (Let the war begin ;) ):
- "There should be one, and only one, entity per table. You should know you've gone wrong when you try to shove two entities into the same table, without having to go through the process of normalization." - One entity per table? That's just downright foolish, at least in the broad swaths of domains where the number of entities is unbounded (even before dealing with mutable and non-monotonic sets of entities). You shouldn't need a database just to track your table namespace. If you must, use a database that supports tables or relations as element values and supports subqueries and joins on these tables. But, one table per entity? bleh. You should know you've gone wrong when you try to shove all of one entity into a table. DatabaseIsRepresenterOfFacts. A table should carry a set of facts, one per row, and 'entities' can have their facts distributed across many tables. Entities are represented in normalized schemas not by tables but, rather, by particular keys.
- I was simply using a common, informal mnemonic -- and a hint about beginning good modeling in general -- where "one entity per table" is shorthand for the well-known 'prayer' to remember 3rd normal form: "A non-key field must provide a fact about the key, the whole key, and nothing but the key, so help me Codd." In this case, "entity" has no more meaning than that collection of attributes determined by a candidate key. Broader meanings of "entity" need not apply, and anyone with experience in data modeling knows what is meant. The usage is also a casual reference to entity-relationship modeling, which is frequently used as a starting point for practical schema design, and where one entity per entity kind does indeed apply. E.g., use one table to represent the customer "entity", and another to represent the employee "entity", unless they are both determined by a common candidate key. Admittedly, it's a very loose and informal edict, but a handy one in practice. That said, when you wrote "the number of entities is unbounded", did you mean the number of entity kinds is unbounded, or did you mean the number of entity instances? If it's the former -- assuming we need to record facts about each entity kind, and they have distinctly different attributes -- then we're already outside the bounds of "normal" data modeling, and at the very least into using approaches like EntityAttributeValue or dynamic table generation, and quite possibly outside the practical scope of SQL or relational databases.
- Use one table to represent all customer "entities", each with their own unique key, and your statements will make some sense. The number of entities (same thing as entity-instances) is unbounded. Exactly one customer is exactly one 'entity'. The word 'entity' refers always to an entity-instance in the EntityRelationshipModel - a collection of attribute values, not a collection of attribute-types, and certainly not to an 'entity-kind' (which is a bit more artificial because there's nothing preventing one entity from being both customer and employee). An entity represents a discrete object. When you say "one entity per table", that means (to me and anyone else who interprets you literally): only one customer in this table, only one employee in that one. Which is, of course, quite insane. Apparently the phrase's use as a shorthand idiom isn't so well known that I remember ever hearing it. I agree on the latter... if the number of entity-kinds is unbounded, it requires a form of data-modeling (or KnowledgeRepresentation?) that is very, very different from that used in modern workhorse databases (e.g. various learning systems that must, essentially, grow their own ontologies).
- I take it you haven't worked professionally as a DBA, data modeller, database developer, or application developer in an enterprise setting, yes? My statements make perfect sense to anyone with even the slightest familiarity with those roles, as I've used standard terminology throughout. The notion of one instance per table is laughable; I'm surprised you'd even interpret it that way. "Entity" in such contexts almost invariably refers to an entity-kind, as in database design and implementation it is rare to speak in terms of single instances. In an EntityRelationshipModel, a box (or whatever symbol you use) represents an entity-kind (and possibly its associated attribute names, and occasionally their types), which in practice referred to just as an "entity". Beware of obsessively literal interpretation, especially when you're not familiar with the terminology of the field!
- {I didn't write the text you are replying to, but I find your response rude. It is a form of "if you were as experienced as me, then you would agree with me". AttackIdeasNotPeople.}
- Perhaps my response is a bit rude, and for that I apologise, but my points should have been obvious given the breadth of knowledge my correspondent has demonstrated elsewhere. I mean, how many people would really believe anyone would suggest one table per instance? I've never seen the like, even from students in their very first database class. I suspect his apparent naivete over common use of the term "entity" in the database field is artificial, and an attempt (at best) to "correct" me for not using his favoured terminology, whether it's the convention or not. At worst, it's just a quibble for the sake of quibbling.
- You said: "The notion of one instance per table is laughable; I'm surprised you'd even interpret it that way." - You do remember that you were answering a question, do you not? (Are normalization rules always able to tell us what to do in such cases?). And you answered with the extremely explicit: "There should be one, and only one, entity per table". Go look up the word 'entity' on most any site or in any book, and you'll find something like: "An entity represents a discrete object." (from Wikipedia), or "An entity is an object that exists and is distinguishable from other objects. For instance, John Harris with S.I.N. 890-12-3456 is an entity" (an SFU website). Perhaps you come from another school, where 'entity' is used where other schools use 'entity sets', but the English use of the word is in accordance ONLY with the schools that treat entities as individual objects. You should beware of exceptionally vague exposition, especially when answering questions about your field. Even for those familiar in the field, you shouldn't expect them to twist your words until they actually make sense and aren't "laughable". I prefer to laugh when you say something 'laughable'. I prefer precision to any sort of vague hand-waving-just-juggle-what-I-said-until-it-makes-sense-to-you approach. For example, when people speak of the 'box' being an entity in the traditional ER diagramming language, they aren't (as you imply) speaking of the entity-kind; they're speaking of an instance of that kind. I.e. 'A transaction': 'a customer' 'purchases/returns' 'an object' at some 'time'. This is evidenced quite clearly by the little lines you draw between those: one doesn't speak of one customer-kind being related to many transaction-kinds; rather, it is one customer to many (individual) transaction-instances.
- When people label the boxes in an ER diagram, they write "customer", "employee", or "invoice", not "Bigcorp Inc.", "Joe Blogs", or 389237. Thus, the ER diagram is referring to classes or kinds, not individuals. The little lines and crows-feet (or whatever) indicate that each instance of the class or kind may relate to one or many instances of a class or kind. An ER diagram facilitates cognition about properties shared by all instances of a kind, and hence we think about the kind as a whole, rather than about properties belonging to an individual. Obviously, we would refer to "Bigcorp Inc." as a single entity, or a single instance, were it appropriate to mention it. However, at a modeling level, the individuals are insignificant. Therefore, when talking about modeling issues we typically use the shorthand term "entity" to refer to the kind or class, just as has been done at the top of this page. We might say, "I think we should create a new table for this entity," or "We don't need to represent that entity in the database," where it is implicitly recognised that "entity" refers to the kind, not an individual. This may not be perfectly accurate, but as we both know, terminological laxity is pervasive. However, nothing pleasant comes from having a pedant in the room who haughtily retorts, "You mean an entity class, don't you???" every time the modeler says "We need a table for this entity."
- They label the 'box of entities' with the kind of entity found in that box, but people diagram relationships between entities. The 'entity', in this context, MUST be the entity-instance. And 'we' (including me and a number of schools) do NOT arbitrarily create confusing, shorthand terms for the 'kind' or 'class' of entities. We call those 'entity-kinds' or 'entity-classes' or 'entity-concepts' or (quite often) 'entity-sets'. Further, even where 'we' occasionally DO create arbitrary, confusing, shorthand terms (and foolishly overload them for two conceptually different uses that can be easily confused in the same context), we SHOULD at least recognize how STUPID we're being when using confusing, shorthand terms to ANSWER QUESTIONS to STUDENTS. When providing a clear answer: the box is not the entity. The box contains the entity. "Employee" is not 'an' entity unless one is discussing a database of ER diagrams. If I say, "I think we should create a new table for this entity", it's because 'this' refers a -specific entity- that doesn't fit into any of the classes-of-entities represented in the schema. I don't go about creating new classes-of-entities until there's something to put in them. I'll admit to being a 'pedant', but, as we both can determine without much effort, terminological laxity involving distance-units manages to crash multi-million dollar Mars landings... and terminological laxity involving politically weighted terms has resulted in multi-billion dollar wars. War, hunger, famine, crime, and apathy are all pervasive... but it doesn't make them good or excusable.
- Crashing Mars landers...? War, hunger, and famine? Now, really... Shorthand terms to answer questions to students??? When did students come into this? At least it's a nice rant.
- If your argument is unsound, it's unsound. Just because something is pervasive DOES NOT make it good or excusable. Terminological Laxity is a bad thing, bred from (in this case) the laziness and arrogance (or possibly confusion) of whomever decided to use the word 'entity' as shorthand for 'entity-class' when it already possesses a dictionary meaning AND a corresponding relational meaning associating it with specific (discrete) instances. Terminological Laxity is a bad thing whether it be for Mars Landers or answering the question of students. Wave your hands all you want; it won't change the fact that using the same word for two meanings because it is 'shorthand' for you is a recipe for confusing everyone else.
- What's with the students again? Did the original questioner mention being a student and I missed it? I think you've confused "everyone else" with none but yourself. You are the confused party -- I doubt anyone else is. And it's hardly my laziness or arrogance -- though I'm quite happy to perpetuate it, if that's what it is, for the sake of brevity -- as it's common usage and widely understood. Indeed, it would seem much more arrogant and pedantic if I carefully said "entity class" or some such in a context, e.g., database design & modeling, where everyone else happily uses "entity" and knows exactly what is meant. I go to work in a car, too -- shall I be careful to call it an automobile from now on, lest someone think I take the train?
- A student is a person who studies. A good example of a student: a person who asks a question with the purpose of seeking an answer from an expert. The person who asked IS a student... unless his or her question was wholly rhetorical. And use of the word 'entity' to mean 'entity-class' is NOT a common usage. The 'most common' usage for the word 'entity' is the one found in the Dictionary. When the word 'entity' is used in 'EntityRelationshipModel' or 'EntityAttributeValue', it usually remains consistent with the dictionary definition, referring to a specific instance. This is evidenced both in typical explanations of the EntityRelationshipModel (e.g. explaining relationships between entities: 'a singer' and 'a song', not the class 'singer' and the class 'song') and in traditional operational definitions of the word relative to the model (Entities and Entity-sets, for example). Your use of the word is colloquial not only TO the field but even WITHIN the field. And your weak excuse for perpetuating this confusing malapropism: brevity? right. You save one full syllable (and six keystrokes) moving from 'entity-class' to 'entity', and if you wished you could save three syllables (and seven keystrokes, AND potential for confusion) moving from 'entity-class' to 'class'. How wonderfully brilliant of you.
- It's not just me, because it is common usage (note that the person who started this thread uses it at the top of this page -- and I know it ain't just him and me), and you are the first person I've seen "confused" by it (yeah, right) in twenty years. And absolutely my usage is colloquial! I was speaking colloquially, as one does with an audience of professional colleagues, which is what this wiki generally presents. When I was developing database applications professionally, I heard and used "entity" used to refer to "entity class" on a daily basis, because babbling out "entity class" every single time is pointless and verbose when everyone in the room knows exactly what "entity" means in that context, and when "entity" is the preferred term in that context. You're trying to rearrange mountains and change the colour of the sky here! Surely you don't speak in rigorous, cautious, carefully disambiguated-in-case-someone-doesn't-know-better terms to your work colleagues, do you? If you do, watch carefully for eye-rolling next time you start expostulating on some aspect of terminological minutiae.
- I have taken courses on the subject along with whole classes of university-taught students in Database systems. I have professionally worked in an enterprise environment where I needed to write ER diagrams and create schema. However, I have NOT heard the term used in your favored, colloquial manner prior to hearing it from you. No matter what you believe, it is NOT as common as you think if it is not penetrating bread-and-butter university curriculum. Perhaps there are two schools of thought with this word, and I was educated in the other one... which is, at least now, the dominant one (as reflected by Wikipedia). However, even if this is the case, it just requires you be even more cautious: you should carefully, cautiously use entity-instance when you mean instance, and entity-class/set/concept/kind/type when talking of the abstraction of the instance, at least when you don't know from which school-of-thought the person you're discussing it with hails. And do I speak in "rigorous, cautions, carefully disambiguated" terms to my colleagues? That depends on five things: what I already understand of their knowledge in the particular subject matter being discussed, what I already understand of the communications context, how well I know the subject matter being discussed, their apparent motivation for asking, and my motivation for telling. With face-to-face, at least, I can watch for physical clues as to understanding, irritation, or uncomprehension. What I don't do is act the arrogant arse who starts using confusing shorthand when talking to -anonymous people- who are -asking questions because they want real answers- with my knowledge of their understanding being limited to -what I can derive from the question and the fact they reached that page-, especially with the -communications context being a page that titularly encourages the addition of large numbers of tables-. You keep saying you were answering 'an audience of professional colleagues'. While we're using colloquialisms and idioms, do you make this sort of 'preaching to the choir' a common practice? Perhaps THAT is why you've never seen someone 'confused'; you're too damn used to telling people what they already know in the way they're used to hearing it.
- And since you feel I'm being a prat for feeling some need to correct you, you should keep in your mind that the literal interpretation of your words was, truly, the first to enter my mind, despite my knowledge and experience in the field (which is far more extensive than you imply); if what you had said with your hand-waving imprecision was just a little less laughable, you could have dreadfully confused the person for whom you were attempting to provide a clear answer... or been rejected as apparently confused on the subject yourself. Further, what you're saying (only one entity-instance in a table) HAS been seen, even promoted, on this Wiki (mostly wrgt. representation of trees and some cases of object-relational mapping), so thoughts that you might be another promoter of this silly concept have far more plausibility than you probably care to think. (Hmmm... I need another tree. I know! That guy said "there should be one, and only one, entity per table" and seems to know what he's talking about, so let's add another table for another tree! Woohoo! it worked! Hmmm... I need another tree.)
- Even if that was the first thing to enter your mind, shouldn't the second thing to enter your mind be the knowledge and experience to recognise conventional usage and common advice? Unless, of course, YOU are the pedant in the room who haughtily retorts, "You mean an entity class, don't you???" every time the modeler says "We need a table for this entity."
- Nope. I already know the conventional usage of the terminology: an entity represents a discrete object, like a single employee. And, if I honestly needed the advice, I certainly wouldn't recognize it as common. Thus, these things SHOULDN'T be the second things to enter the mind of ANYONE to whom you were honestly offering advice. If your advice -relies upon- the other person already knowing it, why did you offer it in the first place?
- It was clear from the context that the individual who asked the question that spawned this thread was using "entity" in the "class" sense. Later, he explicitly stated so at the top of this page and on the one where this thread originated. The confusion, it appears, lies only with you. Actually, I suspect there was never any confusion at all -- you knew exactly what I meant, and simply saw a juicy opportunity to be self-righteously pedantic and seized it. C'mon, admit it. :)
- The context had the person use the word 'entity-concept' in the 'class' sense, which made it at least possible to stumble past his further use of 'conceptual entities' in the 'class' sense. You went straight to 'entity'. Of course, I did understand that you probably actually meant 'entity-concept' or 'entity-class', but the confusion was real enough - mostly because, as I stated above, I have seen people promoting the one-entity-instance-per-table idea regarding representation of trees and tree-structured objects. Add to that the immediate context of "FearOfAddingTables", and a person saying "yeah! one entity per table! one table per entity! that's so damn obvious!" and your intent becomes far more ambiguous than you imagined. Of course, I do fully reserve my right to be self-righteously pedantic, especially when the knocking opportunities are "juicy".
- So... If you knew what I probably meant, but have seen folks promoting questionable one-entity-instance-per-table and whatnot, wouldn't it have been more polite to simply ask whether or not I'm promoting the idea of one-entity-instance-per-table? Then I could have answered 'no' and we'd be spared all this... And as long as you fully reserve your right to be self-righteously pedantic, I shall exercise my right to be correspondingly indignant at your self-righteous pedantry. So there! :)
- More polite? possibly. Pedants aren't known for their politeness. Ever tell GCC to be pedantic? Anything but polite. Believe me.
From a modeling perspective, we generally classify noun classifications into one of these level "slots":
Entity is simply the highest grouping level on this hierarchy. It is not a hard category because there are multiple ways to view the same thing, all which may be "valid". It is a
UsefulLie to simplify communication and help make necessary partitioning decisions.
SeptemberZeroSeven
Entity Definition Discussion