Recent content by dportas

That depends on the database schema. The fact that you are calculating and storing a balance at some point in time doesn't necessarily violate Boyce-Codd or 5th Normal Form for example. A relation is in BCNF if every non-trivial determinant is a superkey. A relation is in 5NF if all of its...

I don't think I misquoted you at all, I merely commented on the table structure you sketched earlier. Seriously though, if you are denying the possibility that a table can have more than one key then I don't think this discussion is going to go anywhere. As Galaxiom says, you have backed...

Every DBMS that I know of allows you to implement multiple keys per table as you have already demonstrated in your example. A primary key is no different from any other candidate key (unless you choose to make it so). As I hope you know, in the relational model every table has at least one key...

To rephrase in more conventional database design terms: this is a table with two keys, one simple key and one composite key. The purpose of the keys is data integrity. This is a point that I think Gemma, Pat and I have already made in different ways. Referring to client and invoice as a "unique...

Can't make any sense of that. I can only repeat that the composite key means uniqueness of more than one attribute whereas a simple key does not. That is an advantage whenever data integrity requires that a set of attributes should be unique. "Autonumbers" have nothing to do with it - a simple...

But uniqueness in relational database terms is a property of a set of attributes, not of a table. Uniqueness of just one attribute clearly does not guarantee uniqueness of some others. A row may be identified by multiple keys, not just one key and any of those keys might be either simple or...

Well I certainly disagreed with your claim that keys are not about data integrity! Keys are absolutely central to data integrity as I thought I had explained - but obviously not well enough. Obviously there is something a simple key does not do. A composite key means that the data in a...

That's an extremely partial over-simplification. A database is a set of propositions (facts) about some universe of discourse. A table is a set of propositions of one particular fact type. In order to use the information in a table and to stand any chance of interpreting and updating it...

The reason for composite keys is the same as for simple ones. Keys are about data integrity and are not just invented magic numbers for things. Composite keys prevent some combination of attributes from being duplicated on multiple rows and thus implement relevant business rules. They help to...

You mean avoiding the recalculation of values by having those values pre-calculated in the database? It's not normalization/denormalization that makes the difference. What matters isn't whether those calculations are attributes in the logical schema but whether they are physically persisted in...

Hopefully no sensible and knowledgeable professional will "blindly" follow anything without question. If he knows the fundamentals of data management then the database practitioner will properly understand concepts such as: normalization, dependency theory and the relational model. He'll be able...

It may be more efficient or maybe not. But what you said was that normalization required it and I thought that point was worth correcting.

Normalization does not require a "unique numerical ID". Normalization requires that every table have at least one key and normalization theory specifies certain rules about dependencies on those keys. It says nothing about what type of data the keys should contain. Of course it's a good thing...

Let's be clear what we are talking about here. A "relationship" (in Access terms) means at least three quite different and mostly unrelated things: 1) A line drawn on a diagram; 2) A default method for joining tables in queries; 3) A foreign key constraint. Gizmo is correct in that none of...

SELECT IDNum FROM MasterTable EXCEPT SELECT IDNum FROM LinkedTable WHERE Info1=100;