Bueno, básicamente estás necesitando que explique lo que en la universidad requiere dos cuatrimestres completos sólo llegar a ver. No hablemos de comprender completamente, pero si es necesario...
Por empezar, hay que tener algo claro algunos conceptos, que te recomiendo revisar en documentación buena y no en tutoriales: entidad, atributo, relación, cardinalidad, por ejemplo. No me explayaré sobre ellos, y en todo caso te sugiero comenzar con Wikipedia, que está bastante bien escrito en este tema.
- El paradigma relacional sólo indica que una entidad debe poder identificar unívocamente a cada instancia de esa entidad por un único identificador. Pero no especifica qué es ese identificador (numero, cadena de caracteres, fecha/hora, otros). La decisión de usar uno u otro se deja al analista.
- Cuando te enseñan análisis de sistemas, te enseñan a "descubrir" las
claves candidatas en los propios atributos que la entidad tiene. En ese momento se hace hincapié que el objetivo es que esa clave sea capaz de identificar unívocamente a una instancia de la entidad
en todo el universo de entidades posibles, y esto implica que esa instancia pueda identificarse sin importar que la vayas migrando de base en base.
- Obviamente, eso descarta desde el inicio el uso de autoincrementales para hacer esas claves, porque los AI son dependientes estrictamente de la base donde se generan.... y allí comienza el problema. Cualquier migración posterior de ese dato a otras estructuras y bases (por la razón que fuere) invalida cualquier AI que se use.
- Una de las ventajas de usar como PK atributos propios de la entidad es que cualquier consulta que hagas siempre traerá
datos útiles (la clave), mientras que usar un ID numérico no relacionado con el objeto es un dato esencialmente inútil (sólo se usa a los efectos de busqueda), ya que no representa información
de la instancia.
- A nivel de performance, las búsquedas basadas en claves numéricas son siempre más rápidas que con datos no numéricos, pero eso
no quiere decir que se usen AI, sino que las PK son más eficientes si son numéricas. En este sentido, usar un campo numerico no AI basado en atributo propio de la entidad es mejor opción.
- Entre las consecuencias procedimentales del uso de los AI es que si se realiza una integración de datos de diferentes bases (supongamos una empresa con varias sucursales que pretende consolidar los datos en una base central), los mismos identificadores pueden (y seguramente sucederá) estar siendo usados por diferentes instancias de la misma entidad en diferentes bases.
Sea el caso de clientes: Un mismo cliente lo puede ser en diferentes sucursales (no existe un impedimento válido para eso), y con eso el mimo cliente puede aparecer en las diferentes sucursales con el diferentes ID... porque son AI.
- Además de esa posibilidad, cuando se realizan backups sin reserva de continuidad histórica (las tablas se truncan luego del backup), si se pretende luego realizar una restauración de datos por la razon que fuere, esta se generará con conflictos, ya que los nuevos registros existentes en la base luego del backup estaría en muchos casos usando los ID que antes pertenecían a otro.
- Como puedes imaginar, los AI son conflictivos para crear datamarts y datawarehouses, ya que se trata de consolidación de datos históricos, y si se han generado reinicios de numeración, las consecuencias para BI y DM, serían catastróficas.
Ahora bien, con todo esto, ¿por qué se usan? Buenos, algunas razones simples
- Son sencillos.
- Se requieren en ciertos casos puntuales.
- Evitan tener que realizar consultas más complejas.
- No requieren niveles avanzados de normalización de tablas.
- Los programadores los entienden (la mayoría no comprende el modelo E-R).
- Se parecen demasiado a estructuras de arrays, diccionarios y colecciones diversas.
Pero todas estas cosas se pagan luego con eficiencia y optimización. claro que para cuando se presenta el problema, la cosa ya suele ser demasiado tarde.
Cita: solo imaginate dos tablas persona y avion. Una persona puede viajar en varios aviones y un avion puede transportar varias personas. De N:N, por lo que hacemos una tercera tabla vuelo con claves foraneas de las otras dos tablas que seran su clave compuesta... que pasaria si la persona vuelve a viajar en el mismo avion otra vez??
En realidad la solución que respete el modelo E-R es tan sencilla que casi se cae de cajón. Es parte de los primeros ejercicios de Base de Datos I en cualquier facultad:
Una relación N:N que permita más de una instancia de ambas tablas requiere que exista un tercer atributo discriminante, y
es la representación de una relación con atributos, o bien una ternaria.
Es decir: Eso ya fue considerado por los autores del modelo.
Simplemente, si una persona viaja N veces en el mismo avión, en primer lugar la persona no se relaciona con el avión, sino con la lista de pasajeros de un vuelo, de una empresa, que se da en una única fecha, desde un aeropuerto, etc.
¿Se alcanza a ver?
Ese tipo de "problemas" suele mostrar que el modelo de datos está incompleto o mal definido, porque cuando el sistema se especifica bien se empiezan a ver relaciones y entidades que a simple vista son invisibles.
Pero eso se adquiere con la experiencia. No hay manuales que te sirvan, sólo la guía de quienes dominan el tema (no, yo no soy uno, sólo tengo experiencia) te ayuda a ver mejor los sistemas.
De todos modos, la clave para el caso es lo que te dije: Si tienes una relación N:N que puede repetirse, entonces la clave está compuesta por las dos FK
más un atributo propio de la relación N:N como discriminante de la instancia.
¿Se entiende la idea.
Espero no haber perdido el hilo del tema.
Saludos.