I am little confused in understanding Candidate Keys. Do we check Candidate Keys in 1st Normal Form tables only?
As we know, a Candidate Key simply consists of a column or group of columns which can take the place of a Primary Key. If there are more than one then any one can stand as a Primary Key.
So, in 1st Normal Form there can be one table also i.e. we can make one big table and fill the whole table with values to remove repeating groups so we make Candidate Keys relating to one big table in 1st Normal Form.
Then what about 2nd Normal Form? or Third Normald Form. Do we find Candidate Keys for tables in these forms or only once, in 1st Normal Form?
If yes, then what does it mean if previous Candidate Keys are not removed which were found in the 1st Normalized Form table before new Candidate Keys are added in 2nd and 3rd Normal Form?
As we normalize to a higher normal form we replace a relation by other relations that join back to that relation. Each new relation has fewer attributes than the one it came from. And each may satisfy fewer functional dependencies, which are how we determine its candidate keys. Since each relation has its own attributes and satisfied functional dependencies, it may have different candidate keys.
The candidate keys of a relation that we decomposed just don't matter any more because we aren't using it any more. We don't "remove" candidate keys. The candidate keys of a relation depend on its attributes and the functional dependencies it satisfies.
PS Sometimes a non-relational table "normalizes" to multiple 1NF relations. Sometimes "normalizing" a relation to 1NF by replacing attributes by those deemed in some sense "simpler" produces multiple relations.
PPS Normalization does not necessarily involve moving through multiple normal forms.
Related
I'm trying to model the following relationships between entities, mainly consisting of a partial, disjoint generalization.
original EERD
'mapped' to relational
Since I didn't need the subclasses to have any particular attributes I decided to use the "single table inheritance" approach, added the "type" field and moved the relationships towards the parent.
After that I had two choices to make:
1- type for the "business type" attribute
2- way to constraint participation to at most one of the 4 relationships based on the type attribute
For the sake of portability and extensibility I decided to implement no.1 as a lookup table (rather than enum or a hardcoded check).
About no.2 I figured the best way to enforce participation and exclusivity constraints on the four relationships would be a trigger.
The problem is that now I'm not really sure how to write a trigger function; for instance it would have to reference values inserted into business type, so I'd have to make sure those can't be changed or deleted in the future.
I feel like I'm doing something wrong so I wanted to ask for feedback before going further; is this a suitable approach in your opinion?
I found an interesting article describing a possible solution: it feels a bit like an 'hack' but it should be working
(it's intended for SQL Server, but it can be easily applied in postgres too).
EDIT:
It consists in adding a type field to the parent table, and then have every child table reference said field along with the parent's id by using a foreign key constraint (a UNIQUE constraint on this pair of fields has to be added beforehand, since FKs must be unique).
Now in order to force the type field to match the table it belongs to, one adds a check constraint/always generated value ensuring that the type column always has the same value
(eg: CHECK(Business_type_id = 1) in the Husbandry table, where 1 represents 'husbandry' in the type lookup table).
The only issue is that it requires a whole column in every subclass, each containing the same generated value repeated over and over (waste of space?), and it may fall apart as soon as the IDs in the lookup table are modified
For an assessment task I'm doing, an entity album has the attribute also_bought, which is a self-referential attribute. However, this one attribute has multiple entries for any one album - as the also_bought recommendations are rarely only one recommendation - and thus, is a bit of a question mark when it comes to normalisation. I'm not sure whether it passes 1NF or not.
To be clear, the entire entity's set is
Album(album_id, title, playtime, genre, release_date, price, also_bought)
"Also bought" items should be stored in a separate table, something like.
AlsoBought (table)
album_id
also_bought_album_id
Then configure foreign keys from both columns to reference Album.album_id.
You mean that Album is a "self-referencing table" because it has a FK (foreign key) from one column list to another in the same table? (A FK constraint holds when subrow values for a column list must appear elsewhere.) If you mean that the type of also_bought is a list of album_ids, there is no FK from the former to the latter, because values for the former (lists of ids) are not values for the latter (ids). There's a constraint that is reminding you of a FK.
Anyway, normalization is done to one table, and doesn't depend on FKs.
But any time you are "normalizing to 1NF" eliminating "non-atomic columns" you have to start by deciding what your "table" "columns" contain. If you decide a cell for a column in a row contains "many values" then you don't have a relational table and you have to come up with one. The easiest way is to assume a set-valued column to get a relation and then follow the standard rules for elimination of too-complex column types.
I have a query with EF which looks like this:
var x = _db.qMetaDataLookups.ToList();
if I execute, direct on the SQL server SELECT * FROM qMetaDataLookup, 2155 distinct rows are returned. After executing the above, x ALSO contains 2155 elements.
The problem is that the data is wrong. I'm not getting the same data back from the EF as I do from the SQL Query.
In particular, theres a particular element that exists on the SQL output, call it "WXYZ", which makes no appearance at all in the EF version of the query (against the exact same database).
Instead, what I find are numerous repeats. If I call x.Distinct() the list filters down from 2155 elements, to a mere 143.
I'm flummoxed. I have never seen my EF and SQL results differ on a query this simple. There must be a very simple [face-palm] explanation, but I'm missing it.
Thanks.
EDIT qMetaDataLookup (a view) are contains information about our database. In essence, its a listing of all tables and views, and each of their columns, with other information about the datatype, length, precision, scale, etc. The 'key' in this table ought to be the column that matches "tableName.columnName" but instead EF chose for it all the datatype properties. This is why the query fails to perform as desired.
Make sure the entity key is set correctly for qMetaDataLookup in the Entity Data Model. Sometimes the entity keys are messed up...
The issue might have been that your model was using a key with duplicate values where the Entity Framework was expecting unique values. This would happen if, for example, your data model used a composite primary key composed of foreign keys from other tables. It seems EF doesn't like composite primary keys very much, and so returned results from queries will generate what appear to be duplicated rows.
The fix seems to be to add a surrogate primary key column to your table which is guaranteed to be unique. If you still need to reference the foreign columns that's fine, so long as they aren't being used as a composite primary key for the table.
I can't claim any credit for the solution, but here's the link that helped me solve my issue:
http://jepsonsblog.blogspot.ca/2011/11/enitity-framework-duplicate-rows-in.html
I'm using entity framework 4.3 model first and can't figure out why I'm not allowed to have a one to zero-to-one association along with a referential constraint.
I have two main problems. I can't force referential integrity (without manual intervention) and my lazy loading doesn't seem to work... all my 1 to many associations are fine.
I basically have two tables, Loans and Contracts. The Contracts table has a scalar field for LoanId.
Until a loan is submitted, it does not have contract data and I chose not to place everything in the same table due to the size of the contract data. Ie. I don't want contract data retrieved from the database unless it is actually required.
I've searched around and can't seem to find any model first information that clearly answers my questions. Any information that may help me understand and clarify my problem would be greatly appreciated.
Regards
Craig
I guess LoanId field is not a primary key in Contracts table. In such case you cannot have such one-to-one relation because EF doesn't support it. When you create LoanId field in Contracts table the only way to force one-to-one relation is to add unique constraint on that field. EF currently doesn't support unique keys (except primary keys) so the only way to create one-to-one relation is to create relation between primary keys (Loan.Id <-> Contract.Id). If you don't follow this you will get error in designer.
I have an Entity Framework model using Table per Type Inheritance, but when I use a VS Data Generation Plan it produces duplicate keys in the child tables, which is a problem for EF. Does anyone know of a way to get this to work, so that the child tables do not have overlapping keys?
For anyone else trying to do this, I found a solution. You can change the generation type of foreign keys to interger, and then assign ranges. So for example, my parent table generates 40 records. Then each of my 4 child tables generates 10 records by setting a 1:4 ratio on each. Then, I set the ID value for the first table to 1-10, for the second 11-20, etc. This works perfectly.