I have two tables parent and child.
If I make a foreign key on child that points to the primary key of parent, and then make an entity diagram, the relationship is shown correctly.
If I make the foreign key point to a different column, the relationship is not shown.
I have tried adding indexes to the column, but it does not have an effect.
The database is sqlite, but I am not sure if that has an effect since its all hidden behind ADO.net.
How do I get the relationship to work correctly?
This is using Visual Studio 2010 in the Entity Framework (.edmx) diagram, having it automatically generate the diagram from the database.
A foreign key has to reference a candidate key in the parent table. The column(s) you are pointing to in the diagram must therefore be a candidate key. That doesn't have to be the "primary" key but it must be a set of columns that is guaranteed unique by the presence of a uniqueness constraint (usually a UNIQUE or PRIMARY KEY constraint).
Related
My predecessor built our database with some "overloaded" child tables that are shared by multiple parents, using a "tabletype" column that specifies which parent table is the parent of a particular child record. Also, the parents and child are often joined using multiple columns which are not keys, or a compound key, or unique in any way. Multiple parents records can be related to multiple child records this way. Usually, SELECT DISTINCT or GROUP BY are used to eliminate duplicates in the results, in reports or forms. Apparently this is the way our data really works, and users are fine with it. I am not mandated to change this structure.
In one example, the child table has a "tabletype" column with one of three possible values (and currently no constraint to enforce them). It has a foreign key column to relate to the ID of one parent table (call it ParentA). This column is blank for records related to the other two parents. It has an identifying number (not unique) column (we will call it "IdentiNum") and a "BatchID" column, and joins with either of the other two parents using those two columns.
As you'd expect, Referential Integrity is not enforced, and probably can't be enforced with simple RI triggers and constraints. I'm an Access programmer, new to Oracle and PL/SQL. I can write code to enforce RI in the Access interface using VBA. That'll do no good if we replace this interface with one using APEX or another tool, as we plan to do. I want RI in the database where it belongs.
Here's what I think I need for this case:
a constraint on tabletype allowing one of three values that specify which table contains a record's parent.
a constraint on the child's ForeignKey column requiring its value to exist in the ID column of ParentA, unless it is null, which it might be.
a delete trigger on ParentA which cascade-deletes related records in the child table, but still allows the child's ForeignKey to be nullable.
a constraint on the child's IdentiNum and BatchID columns, requiring the values to exist (together) in either ParentB or ParentC, depending on the value of TableType.
delete triggers on ParentB and ParentC which cascade-deletes related records in the child table, the relation determined by IdentiNum, BatchID, and TableType. However, when a ParentB or ParentC record is deleted, the procedure would have to check to make sure there were no other parent records with the same IdentiNum and BatchID values before deleting all related child records.
How can I define column to be unique when creating logical model? It's because I want to create relationship 1:N and both columns are not primary key. I tried to define surrogate keys when defining relationship and typed column names in field Name of source/target, but when creating relational model, I don't get what I want.
So basically I want define which columns from tables go into relationship and define unique constraint over column with multiplicity 1.
I found that I can set up Unique Constraints in the Relational Model in the Table Properties. There is an item in the list called "Unique Constraints" name the Constraint and then add the column. After that click the check box to generate the DDL for the constraint.
just use the UNIQUE constraint.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/clauses002.htm
BTW, why are you using a FK that does not reference the PK? You might need to do this, but you might also consider refining your conceptual model so that the reference can refer to the PK.
I am analyzing an Oracle database design and I am perplexed at seeing both unique keys and primary keys on the same fields. These unique-primary key pairs are consistently created on all tables. I see no reason to do this.
If I have a primary key anyway, is there a good reason to create an additional unique key on the same field?
For a table resolving a many-to-many it would be common to have a two part key (as indicated by Quassnoi). It is also quite likely to need indexes supporting access through either parent.
If you have, for example, PERSON, ADDRESS and PERSON_ADDRESS tables, your PERSON_ADDRESS table may have the primary key of (PERSON_ID, ADDRESS_ID) and a supporting index. You would also have another index on (ADDRESS_ID,PERSON_ID), and you would likely make this a UNIQUE index (as it is a unique combination of fields).
It is also possible that your DBA has some particular way of generating tables that starts with a UNIQUE index on the primary key fields followed by the creation of the PRIMARY KEY constraint. That may show up in some GUI tools in the way you suggest.
No, there is no reason to have it also as unique; when you set a column as PK you are sure that:
No NULL will be accepted for that column on INSERT or UPDATE;
Values in the whole table for that column are always UNIQUE;
so just PK is enough. Since there is a UNIQUE index for the PK column, by definition, there is no need to add any other index on that column only because queries will use the PK index whenever only that column is affected.
I believe it's impossible (PK and unique constraint on the same column[s])...
You cannot designate the same column or combination of columns as both a primary key and a unique key.
(from here, section "Restrictions on Primary Key Constraints"). Isn't it?
Oracle won't let you create multiple UNIQUE and PRIMARY KEY constraints on the same field set in the same order and will fail with ORA-02261.
If you have composite keys, you can create PRIMARY KEY on the column set in one order (PRIMARY KEY (a, b)) and a unique constraint on another (UNIQUE (b, a)).
This will parse and execute, however a single index will be used to police both constraints so it makes no sense.
Could you please post the table scripts?
Just a little theoretical background here... When modeling your table, you identify a set of keys. These keys are logically equivalent, but for practical purposes you pick one of them and call it "primary" while the rest of them become "alternate".
(In DDL SQL, a primary key is called "PRIMARY KEY", while "alternate key" is called "UNIQUE constraint".)
So, in light of that, your question is equivalent to: "is there a good reason to have two identical keys", and the answer is: "no".
That being said, you may have overlapping keys (i.e. keys that share some fields but not all), but this is usually a sign of a bad design... and the answer is: "probably not".
OTOH, if by "unique key", you actually mean "unique index", then yes, you need both of them.
Index is not a logical constraint - it is there just to allow a logical constraint such as PRIMARY KEY to perform well (and for querying, but that's a different topic).
I have a 1:1 relationship between table 'A' and 'B' in my .DBML. The FK in the database is in place and the .DBML diagram shows an association line between 'A' and 'B'. However, I cannot get the code generator to create a child property in the 'A' entity. All I have is the FK column. In the Association properties, I have ChildProperty set to true. However, the code generator will not create the child property. I have dropped and added the two tables several times.
Anyone have any ideas?
The O/R designer will refuse to create an association property if a primary key is missing on one of the associated tables. Make sure all of your associated tables have a primary key.
Not sure, but I think what you call 1:1 is actually seen by the DBML as 1:* because the list can "have" many of your fk-table, e.g. one empley oyee can have one city, but each city can "have" many employees.
AFAIK a primary key in each table is a prerequisite without which the DBML will not "work". An error is issued when saving it. Your project will compile, but you'll see the errors later. HTH
I have to add some security for a C#/.NET WinForms/Desktop application. I am using Oracle DB back-end.
The tables are simple: User (ID,Name), Role(ID,Role), UserRole(UserID,RoleID).
I am using the windows account name to populate User table. Role table will for now just be simply 'Admin','SuperUser','BasicUser'...
Since no two people could ever possible have the same windows account name... even when I do not control these name management (netops does, hence why I want to use windows accounts so I don't have to manage it ;)). For Role table, I should again never have dupe value - I control the input, there will only be 3 (tactical app going away within year). UserRole is a join table to represent the Many-To-Many relationships of users and roles, so no surragate key is justified.
Simple question - Why bother with 'ID' (int) in the User and Role table? Any point or advantage here? Is this one of those 'I've always done it this way' type things? Or have I just not done this in awhile and forget the reason?
Names change - primary key values must not. Abigail Smith becomes Abigail Jones and the username changes but a surrogate key protects against having to cascade those changes everywhere.
If you are using a surrogate key but there is a column or combination of columns which should be unique, then enforce that using a unique index. There's a good chance you'll want indexes on your user.name and role.role columns anyway, and a unique index is more space efficient and supplies useful metadata to the optimizer. If you have a surrogate key but don't have another combination of columns that uniquely identify a row then think again whether you have your entity definition right.
One caution. Especially for very narrow tables with few access paths, you may use an index-organized table. Oracle will only allow an index organized table on the primary key, but does allow foreign keys against a unique set of columns (if it is enforced by a unique constraint, not simply a unique index).
It is possible that you'll end up with a table where a unique ID is enforced through a unique index and treated as PK by an ORM and used as the parent for foreign key relationships, but the primary key (as defined in the DB) is the rolename/username/whatever because you want that as the driver for an index-organised table.
A surrogate key is not required on intersection tables, but here are a few reasons to do so:
Consistency: If every table has a single artificial key, you always know the key name when you know the table name.
Ease Of Use: Less typing — one key means ON and WHERE clauses are shorter and thus less error-prone.
Interoperability: Some ORMs only work well with tables with a single primary key column.