Assume I have the following tables (**bold** - primary key, *italics* - foreign key):
patient(**patient_id**, name)
disease(**disease_id**, name)
patient_disease(**p_d_id**, *patient_id*, *disease,_id* )
I want to draw the ER diagram for this. My idea is to make two entities, one for patient and one for disease, then make a n-to-n relation between them, with p_d_id as its attribute. Is that how it's supposed to be?
Yep, that's correct. In ER diagrams we model the logical relationship, not the eventual physical relationship with a "join" table for many-to-many relationships.
The logical relationship in this case is that multiple patients can have multiple diseases and vice-versa.
Your entities and n2n relationship are ok, but the p_d_id key is not needed, if that 3 are the only fields of patient_disease, then (patient_id, disease_id) is enough as its primary key.
Having p_d_id as primary key would let you have many rows with the same patient_id and disease_id, and what would that mean? for stating that a patient had a disease, it's enough with one just one row.
If, in change, you had another field, for example date, to signify the date in which a patient had a disease, then it would make sense to have an id of its own, because a patient could have the same disease twice, at different dates, but again, in that case, the date could be part of the primary id.
note: In relational theory, 'relation' and 'relationship' are different concepts, in your question, you wrote 'relation' but that's really a 'relationship'. A 'relation' is just a tuple, an instance of an entity, what in the DB would be a row.