"Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." EwDijkstraQuotes
I was in Munich a few years ago, speaking at something (OOP or something, I can't really remember). BruceAnderson was there, and we sat together listening to David Taylor go on about something. I wasn't getting it, but Bruce did. He said that David was being vague (it was a fairly superficial coverage of the material David was working on). I asked if he was being abstract, and Bruce then explained the difference (I'm paraphrasing; Bruce can correct this if I've blown it):
I worked with David Taylor for a few months. He's a very visual thinker, and communicates best at a large whiteboard. Not to say that he can't be vague at times, but I can imagine him sitting on a panel squirming with the desire to grab a marker and start drawing. --DaveSmith
I'm not commenting on Taylor's talk, rather the distinction between two general forms of high-level discussion. --RonCrocker
How does one tell the difference? If one can turn an idea into a mathematical notation, then it's not "vague" within that notation. But sometimes applying such to something more explicit, such as a software implementation, requires making assumptions or interpretations. If my math model says all foos added to gogs are nibbles, then we have a clear rule in that notation. But determining what is the foo and a gog in an explicit implementation may be subject to non-unique interpretation. Being clear in a WalledGarden notation system (math) is easy; applying it to the real world and still being clear or non-arbitrary can be tricky. -t
Mathematical notations are orthogonal to abstraction. Abstraction is about dealing with relevant generalities instead of irrelevant specifics. For example, if we're talking about "road vehicles" as an abstraction for modelling traffic flow, it doesn't matter what colour the cars are or what sort of doohickey they've got hanging from the rear view mirror.
{"How does one tell the difference?" Something is abstract if some irrelevant details are ignored. Something is vague if there are things to which it both applies and doesn't apply. The two concepts are logically independent so we can have things that are one, the other, both, or neither. Everything after your question appears to be comparing abstract to concrete, so I'm not sure what it has to do with your question.}
First-Name Last-Name Internal-ID ----------------------------------- Bob........Jones.....3cfe84a7c // note how we have 2 Bob Jones' Bob........Jones.....7a389cb8f Martha.....Stewart...e68b89bfcIf that Internal-ID isn't visible to the user, then the two rows are not unique.
"The user" is relative. It could be a DBA, app developer, power user writing SQL, or an end-user, for example. We can talk about viewpoints (access rights etc.), but that's still relative.
The only relevant viewpoint here is whether Internal-ID is visible to the user or not. As soon as Internal-ID isn't visible, if duplicates are visible, the user isn't dealing with the RelationalModel.
So "relational" is a viewpoint then, not a system architecture?
The RelationalModel is a DataModel consisting of relations and the RelationalAlgebra. If a system delivers a tabular structure to you with duplicate rows, it is by definition not a relation, and therefore at least that part of it is outside the RelationalModel.
Then claiming that existing RDBMS are not "true relational" is misleading because discarding the key from "output" is a user choice just as it is in RelProject. I will agree that the degree that a given DB system "makes it easy" to discard a key from output varies widely, but that's not a Boolean classification between "relational" versus "non-relational". Saying that System A "facilitates" relational (uniqueness) more so than System B is certainly acceptable, but "more so" is not Boolean. And if you import a bag, all RDBMS give the rows an internal key at some level such that technically each row is unique (although "is" is perhaps Relative to viewpoint). It may not map to something unique in the domain world, but (formal) auto-keys have that "problem" anyhow. RelProject allows auto-keys, no? Either we pick a specific reference point (viewpoint) or "pretend" something is a bag by not considering internal keys/addresses in our head as a hopefully UsefulLie. In short, TrueBagsCannotExist.