Relations in Designer ERD

Question

Dears,
i was creating ERD in oracle designer and i faced this issue:
i have 4 tables a,b,c,d
primary key in a is com_no which is a foreign key in b,c
so primary key in b is b_seq, com_no
and primary key in c is c_seq , com_no
both b and c primary keys are referenced from a foriegn key in d so i suppose the primary key in d
is d_seq, b_seq,c_seq, com_no
but when generating ERD i will have the primary key like this
d_seq, b_seq,c_seq, b_com_no,c_com_no
is this correct? if no how to manage?
thanks.

Answer 1

First of all, are you really working in the Entity/Relationship Diagrammer (ERD)? Or are you really creating database diagrams in the Design Editor? The reason I ask is that ERD doesn't create "Foreign Keys", it creates "Relationships". True, when you run the Database Design Transformer (DDT), the relationships will be transformed into foreign keys, but while you can create and designate key columns yourself, you normally don't - you let DDT create them.
Actually, what DDT wants to do, unless you set preferences to tell it not to, is create surrogate primary keys from an Oracle Sequence. Then the foreign keys are JUST foreign keys, they are NOT part of the primary key. So table A gets a primary key, A_ID, which is generated from A_SEQ. B gets a primary key, B_ID, and a foreign key, A_ID. C gets a primary key C_ID, and a foreign key, A_ID.
Now you are saying that D has a relationship to BOTH B and C. This is why it is good to use the ERD and define entities, attributes and relationships, and not jump directly to design tables, columns and foreign keys. Exactly what is the relationship between D and B, and D and C? And how does D relate to A? ERD would let you name your relationships and more clearly define them, and ask if this correctly describes the data your system must collect.
For instance, I get the feeling that D is an intersection table, and that it is defining a many to many relationship between different rows in A, via their related rows in B and C. In this case, D will have its own primary key, D_ID, and foreign keys to B, B_ID, and to C, C_ID. Notice that with this arrangement, you don't need any instances of A_ID in the D table. You can get to the right two rows of A through the foreign keys in B and C.