Lamento mucho escuchar que has tenido tan malas experiencias con los profesores en cuyas manos ha quedado la enseñanza de un tema tan crítico como el de las bases de datos. Y no es una exageración decir "crítico", si consideras que más allá de las aplicaciones de diseño, multimedia, juegos y un largo etcétera, donde más se usa la informática es precisamente para procesar... datos.
Todos son datos en este mundo, y todo dato implica base de datos. Y si las mismas están mal diseñadas, parafraseando a un profesor mío, solamente consigues basura.
Bueno, las preguntas que tienes son muchas, por lo que tendremos que empezar por las básicas:
Cita: por ejemplo se que la Primary Key debe ser un valor UNICO e Irrepetible para cada registro de la tabla, que otros trucos hay?
No hay truco, el modelo establece cierta reglas a cumplir:
1) Toda entidad y tabla tienen una única PK.
2) No puede ser nula.
3) Es irrepetible.
4) Identifica unívocamente un registro en una tabla (o tupla en la relación/entidad).
Fuera de eso, en la definición del paradigma se enseña que una PK
debe ser un atributo de la entidad, o un
subconjunto de atributos considerados como unidad, tal que pueda identificar a esa tupla en todo el universo de tuplas posibles. Y por universo se enseña que se habla de todos los casos, aún los que no existen aún en esa base de datos.
Esto significa que una PK debería definirse
preferentemente con alguno de los atributos de la entidad que le sean propios, y no crear uno
ad hoc.
Pero cuando se extiende un poco el tema, se reconoce que no en todos los casos es posible encontrar un atributo o subgrupo que pueda cumplir con ese papel, en esos caso (y sólo como excepción) el modelo expresa que se puede crear un atributo para ser usado como PK en tanto cumpla con las reglas.
Este es el caso muy usado de los ID numéricos incrementales. No son obligatorios, son soluciones fáciles para no realizar buenos análisis, muy comunes especialmente entre programadores (lamento si alguien se ofende, pero es verdad).
Si el modelo lo permite, siempre es mejor usar un atributo propio de la entidad como PK. Si no se puede, y
luego de la pertinente normalización de las tablas hasta la 3FN, se puede usar otra cosa.
Cita: pero por ejemplo como identifico las relaciones si son N:N o 1:N o 1:1...... es lo mismo N:1 que 1:N?...
La identificación de las cardinalidades se hace en dos momentos:
1) En el análisis previo, cuando se está modelando el sistema, y jamás cuando se crea el modelo físico.
2) Durante la normalización, ya que allí se generan tablas que no existen en el modelo lógico.
En el análisis previo surgen no sólo casi todas las cardinalidades, sino que además surge si esas relaciones son mandatorias u opcionales, estableciendo si se trata de entidades débiles o fuertes.
En cualquier caso, la cardinalidad se analiza "parándose" desde la óptica de cada entidad y expresando la regla que define esa relación.
Por ejemplo:
Cita: "Cada A tiene una única relación con un sólo B."
Cardinalidad 1:1 mandatoria.
Cita: "B puede tener cero o más de A relcionados."
Cardinalidad 1:N opcional.
Cita: "B tiene uno o más de A relcionados."
Cardinalidad 1:N mandatoria
Cita: "A se relaciona con cero o más de C."
"C se relaciona con cero o más de A."
Cardinalidad N:N opcional.
Cita: "A se debe relacionar con uno o más de C."
"C se debe relacionar con uno o más de A."
Cardinalidad N:N mandatoria.
Nota: Toda relación N:N
obligatoriamente genera una tabla física para administrarla, que no existe en el modelo lógico, y cuya PK está formada por las PK de cada una de las tablas relacionadas en ella.
Sólo se agrega un atributo discriminador como parte de la PK si y sólo si además de ser N:N, en la relación el mismo par de PKs puedan aparecer N veces también.
¿Se entiende eso?
En cuanto a 1:N y N:1, por reflexividad, son equivalentes. Sólo explicitan la diferencia en el diagrama acerca de cuál de las dos entidades es 1 y cuál N.