In this ERD:
Certificate Entity is an Associative Entity and it has a unique identifier - Certificate Number. Since an Associative Entity inherits its primary key from other entities. The key field of associated entity are primary key of each end entity is a foreign key on the associated entity, and both foreign keys combined together become a primary key(Concepts from Textbook).
Is the primary key of the Certificate Entity should be a composite key which contains three parts: CertificateNumber, EmployeeID, CourseID ?
Or its primary key is CertificateNumber, and takes EmployeeID, CourseID as attributes of this entity??
I'm confused on this question because normally an associated entity doesn't have its own identifier(Certificate Number). It just take primary keys from other entities combined as composite key(EmployeeID, CourseID), then use that composite key as its identifier.
Thank you
Alex
Associative entities don't have a primary key based on their own attributes. In your first diagram, you created an associative entity with the functional dependency (Employee_ID, Course_ID) -> Date_Completed. Note that while Employee_ID and Course_ID are columns in the table, they're not attributes. An attribute in the ER model is a mapping from an entity set to a value set. Foreign keys are components of a relationship and don't map to a value set.
In your second diagram, by adding a surrogate key, your associative entity becomes a regular entity which is in relationships with Employee and Course. Your primary key is just Certificate_Number, but a unique constraint on (Employee_ID, Course_ID) is probably a good idea. The relationships are represented by the functional dependencies Certificate_Number -> Employee_ID and Certificate_Number -> Course_ID recorded in the Certificate table.
You could also keep it an associative entity and use (Employee_ID, Course_ID) as the primary key and make Certificate_Number a regular attribute, though uniquely constrained (and probably auto-incremented). In this case, the diagram would look like your first one but with an extra attribute on the relationship.
Related
I have the following model:
I created every table in an Oracle database but I don't know how implement the relations between tables. Can you help ?
There are plenty of possibilities, but here some selected suggestions:
A one-to-many association (or aggregation or composition) is often implemented by having the primary key of the "one" appearing as foreign key in the "many". This technique is sometimes called Foreign key mapping. Example: the primary key of Address table would be an additional foreign key column it the Fire table.
A many-to-many association is generally implemented with an association table, having two foreign keys that correspond to the primary keys of the associated classes. This is sometimes called association table mapping.Example: You'd have an additional association table PostFire having two foreign key columns, one corresponding to the primary key of Post and the other to the primary key of Fire.
An association class is implemented with an association table (see above).Example: To the table implementing Scale, you'd add two foreign key columns, one with the primary key of Client and the other with the primary key of Fire.
Inheritance has many many ways of doing it. If you already created 4 tables, then the trick would be to have the primary key of the "parent" appear as foreign key of the "children", with a unique constraint on this value. Another simpler variant could be to reuse the primary key of the parent as primary key of the children. Both of these techniques are called class table inheritance because each class corresponds to a table.Example: add a foreign key column to Fireman that corresponds the primary key of User.
P.S: Several points, not directly related to your issue:
There is an UML inconsistency between the association-class name Scale and the association name confirm. An association class is at the same time the association and the class and cave only have one name.
NEVER EVER STORE A PASSWORD IN DATABASE TABLE. Storing a hash code of the password is a much safer approach.
I have the following model:
I created every table in an Oracle database but I don't know how implement the relations between tables. Can you help ?
There are plenty of possibilities, but here some selected suggestions:
A one-to-many association (or aggregation or composition) is often implemented by having the primary key of the "one" appearing as foreign key in the "many". This technique is sometimes called Foreign key mapping. Example: the primary key of Address table would be an additional foreign key column it the Fire table.
A many-to-many association is generally implemented with an association table, having two foreign keys that correspond to the primary keys of the associated classes. This is sometimes called association table mapping.Example: You'd have an additional association table PostFire having two foreign key columns, one corresponding to the primary key of Post and the other to the primary key of Fire.
An association class is implemented with an association table (see above).Example: To the table implementing Scale, you'd add two foreign key columns, one with the primary key of Client and the other with the primary key of Fire.
Inheritance has many many ways of doing it. If you already created 4 tables, then the trick would be to have the primary key of the "parent" appear as foreign key of the "children", with a unique constraint on this value. Another simpler variant could be to reuse the primary key of the parent as primary key of the children. Both of these techniques are called class table inheritance because each class corresponds to a table.Example: add a foreign key column to Fireman that corresponds the primary key of User.
P.S: Several points, not directly related to your issue:
There is an UML inconsistency between the association-class name Scale and the association name confirm. An association class is at the same time the association and the class and cave only have one name.
NEVER EVER STORE A PASSWORD IN DATABASE TABLE. Storing a hash code of the password is a much safer approach.
If I have a weak entity with no attributes and has a four weak relationship with the owner entities and I want to design the relational schema for this weak entity, Can I take all primary keys of the strong entities that have relations with the weak entity and make them as primary keys for the weak entity?
I add an example below, my question is about the "Recon" entity.
ER diagram(Recon entity)
Migrate the primary keys of the related strong entities into the primary key of the weak entity. The result is one (composite) primary key, not multiple primary keys1.
The resulting table would look something like this:
CREATE TABLE Recon (
sin int REFERENCES Person,
method int REFERENCES Method,
name int REFERENCES Place,
time REFERENCES TimeSlot,
PRIMARY KEY (sin, method, name, time)
-- Other fields and constraints...
);
NOTE: I'd consider introducing surrogate keys into the parent/strong entities, simply to make the weak entity's key leaner (e.g. introduce PlaceId and reference it from Recon instead of the natural key name).
1 In fact, there can be only one primary key per entity, although you could in theory have multiple alternate keys.
What if the table does not have a primary key ?
Or Does does the table need to enforce Entity Integrity to be called as a relation?
One of the Relation properties states that :
Each row(tuple) must be distinct. (does this means that the table must have a primary key)
A relation does not have duplicate tuples. A relational table therefore has to have that property as well. If tuple uniqueness is enforced in a table that means the table has at least one candidate key, even if the key is the entire set of attributes in the table.
In the relational model there are really no "primary" keys as such because all keys are effectively equal in form, function and status. Since a primary key is just any arbitrarily selected one of the keys in a table, we can say that any table with at least one key has by definition satisfied the primary key requirement.
In the conversion of an Entity Relationship Model to a Relational Data Model:
When mapping a 1:N Binary Relationship, should we include (as a foreign key) the composite key (partial key + foreign key from the owner entity) of the entity on the 1 side of the relationship to the relation corresponding to the entity type on the N side of the relationship, or just the partial key?
Background:-
While transforming an Entity-Relationship Model into a Relational Data Model, the following steps are followed:
Map regular entity types into relations, including their single valued attributes.
Map week entity types into relations. Include in the relation the Primary Key attribute of its Identifying (i.e. Owner) Entity Type as a Foreign Key. The key of this relation is a combination of its Partial Key and the Foreign Key from its Identifying Entity Type.
Map Binary 1:1 Relationship Types by including the Primary Key of one entity type (which is not showing a Total Participation, if only one of the two participating entity types is showing a total participation in the relationship) as a Foreign Key in the relation corresponding to the other entity type (the one showing the total participation in the relationship.
Map Binary 1:N Relationship Types by including the Primary Key of the participating entity type towards to 1 side, as a Foreign Key in the relation corresponding to the entity type towards to N side of the relationship.
Map the Binary Relationship M:N by making a new relation for the Relationship Type and making its Composite Key by including Primary Keys of both the participating entity types as Foreign Keys.
Make a new relation for each multivalued attribute and make its Key by including Primary Key from its entity type as a Foreign Key.
Reference: ERM to RDM
Question explained:-
My first question is from step 3.
If, in step 2, a week entity type's patial key had been combined with a foreign key from its owner relationship to form a composite key in the corresponding relation for the week entity type,
and the same week entity type is showing a total participation in a 1:1 binary relationship,
and then in step 3, when we are required to add a foreign key from the (although owner) entity type which is not the one showing the total participation to the relation corresponding to the (although week) entity type which is showing total participation, BUT we have already done that in the previous step as a requirement of that step, what will we do? Nothing, just move on?
My next question is from step 4, if the entity type towards the 1 side of the relationship is actually a week entity, and thus its primary key is (now, after following the previous step 2) a combination of its own partial key and the foreign key from its identifying relationship, shall we add this composite key as a foreign key in the entity type towards the N side of the relationship, or just its partial key?
this rule is only for binary relationships that have strong entities on both side i.e. both of the entities have primary key.
if their is weak entity then it will defenitly be on many (N) side of this relationship in that case we again follow the same rule but the primary key of the relation you built w. r. t. weak enity will be combination of partial key (if any) and primary key of owner (strong) entity.