Duda. Que tipo de dato debo elegir en PK (Tabla materias, tabla bloque...)

[usuarioxr]

¿Que tipo de dato debo elegir en la clave primaria


Tabla materias, esta hice su PK autonumerico (1,2,3...etc)

Tabla Bloques (FK = Id_materia), aqui no se si poner autonumerico su PK

Tabla Temas(FK = IdBloque), aqui los mismo no se si poner autonumerico su PK

¿Ustedes que opinan? ¿Deveria utilizar autonumerico o cambiar el tipo de dato
?

Son como 30 asignaturas, cada asignaturas tiene maximo 3 bloques, y los bloques
tienen varios temas, y los temas tienen varios subtemas

[sefirotxx]

Personalmente creo que toda tabla debe tener lo siguiente:
- clave primaria no compuesta (es decir que no lo componga mas de un campo)
- la clave primaria debe ser unica por lo que un id es lo mejor para este proposito (es mucho mejor que tratar de dejar el rut por ejemplo como clave primaria)
- y la clave primaria debiera ser siempre con autoincremento, de tal forma que en las inserciones no sea necesaria considerarla y asegura que entregara un valor unico.

Por lo cual me parece que el tipo de dato que ocupas en las claves primarias de tus tablas es el correcto, ahora que sea int, smallint bigint etc .. depende de los registros que calculas tendra tu tabla aproximadamente.

[usuarioxr]

Iniciado por sefirotxx

Personalmente creo que toda tabla debe tener lo siguiente:
- clave primaria no compuesta (es decir que no lo componga mas de un campo)
- la clave primaria debe ser unica por lo que un id es lo mejor para este proposito (es mucho mejor que tratar de dejar el rut por ejemplo como clave primaria)
- y la clave primaria debiera ser siempre con autoincremento, de tal forma que en las inserciones no sea necesaria considerarla y asegura que entregara un valor unico.

Por lo cual me parece que el tipo de dato que ocupas en las claves primarias de tus tablas es el correcto, ahora que sea int, smallint bigint etc .. depende de los registros que calculas tendra tu tabla aproximadamente.

¿Entonces sigo utilizando autoincremento en las demas tablas?

[gnzsoloyo]

En realidad, sefirotxx, eso es un tema completamente resuelto en el modelo E-R, y lo que planteas no es correcto desde ese punto de vista.
El tema es algo trillado, porque lo hemos tratado innumerables veces, pero veremos si puedo sintetizar.

- Por definición del modelo E-R, toda entidad (y tabla) debe tener una PK.

- También por definición de PK, una clave primaria es siempre única y no nula. Siempre.

- Una clave debería ser siempre un atributo propio de la entidad, es decir propio del objeto o relación representada, sea esta clave compuesta o no.

- Una clave no es conveniente que sea un autoincremental, a menos que llegados a la 3FN, no se haya encontrado un determinante (clave candidata). Los AI causan serios problemas a futuro, en integraciones de datos, consolidaciones de bases, backups, restauraciones, y un enorme etcétera. Están totalmente desaconsejados en la arquitectura de datos, pero como son lo único que parecen comprender bien los programadores, es muy habitual que se usen.

- Las PK deben respetar el esquema integridad referencial, por lo que una tabla puede no tener PK propia sino heredada, o bien heredada pero con un discriminante.

- Debes considerar que las relaciones N:N definen la existencia de tablas que no figuran en el DER lógico, pero que son consecuencia del modelo. Estas tablas no tienen una PK propia sino que la misma se crea con las dos FK de las tablas relacionadas. Esto no lo estás teniendo en cuenta.

- Otros (muchos, muchos) considerandos.

En definitiva, para poder definir las PK que necesitas, lo primero que tienes que hacer es modelar el DER lógico, donde establezcas las entidades que integran el sistema, y recién entonces podrás definir claramente cuáles son las claves adecuadas.
Lo que si puedo decirte es que si puedes evitar los AI, tu será escalable. si los usas... tarde o temprano necesitarás re ingeniería para sacarlos.

Hay capítulos enteros de los libros de fundamentos de base de datos que explican todo esto, que para mas o menos dominarlo tienes que haber estudiado un año entero, más un par adicionales de práctica.
Por lo pronto, mi consejo es lo que dije: Analiza el sistema, verifica las entidades y determina qué las identifica unívocamente. Esa será la mejor clave.

Tu DER físico sería mas o menos:


Lo de elegir como PK un AI o no, es un tema a discutir, pero yo no los recomiendo. Es preferible ver cómo se codificarán las identificaciones de esas cosas en el sistema, y partir de alli.
Los AI traen más complicaciones a futuro que beneficios, como ya te dije.

[sefirotxx]

Interesante... aunque carece de explicaciones, no soy un experto en el tema y talves aprenda aca un poco:

- Una clave no es conveniente que sea un autoincremental, a menos que llegados a la 3FN, no se haya encontrado un determinante (clave candidata). Los AI causan serios problemas a futuro, en integraciones de datos, consolidaciones de bases, backups, restauraciones, y un enorme etcétera. Están totalmente desaconsejados en la arquitectura de datos, pero como son lo único que parecen comprender bien los programadores, es muy habitual que se usen.

¿ No entiendo el porque no se deben usar aun ? Solo se explica lo que se tendria que hacer si sacaramos los auoincrementos pero no dice el porque, en que afectarian a futuro a la base de datos

- Debes considerar que las relaciones N:N definen la existencia de tablas que no figuran en el DER lógico, pero que son consecuencia del modelo. Estas tablas no tienen una PK propia sino que la misma se crea con las dos FK de las tablas relacionadas. Esto no lo estás teniendo en cuenta.

Eso es de libro exactamente, pero por que no poner a esa tabla una PK que sea un ID autoincrementado?? 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??

Agradeceria nos explicaras mejor por que asi tambien yo empezaria a evaluar no ocupar auoincrementos, pero tengo algunos sistemas hechos y hasta el momento no tienen ningun problema. Gracias gnzsoloyo

[gnzsoloyo]

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.

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.

[sefirotxx]

Ufff tremenda respuesta gnzsoloyo. Bueno debo decir que al final de cuenta la experiencia te va dando diferentes puntos de vista, pero es muy interesante lo que tratas. La mayoria de las cosas que explicas lo estudie mucho en la universidad y lamentablemente desde la universidad vengo con la idea que los autoincrementos son buenos y no me ha dado malos resultados.

Pero luego de ver tan bien explicadas las razones de por que no usar autoincremento indiscriminadamente por supuesto que tendre mas cuidado, al fin y al cabo lo dices por experiencia (lo cual es igual o mas valido que la universidad)

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

Esa es la parte principal de todo esto y para no perder el hilo del post creo que debieras considerar lo que te dice el colega en su buenisima explicación, pero personalmente con la experiencia que llevo puedo volver a decirte de que no he tenido problema con los autoincrementos y me han ayudado bastante, sobre todo si eres el analista y el programador a la vez.