style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Modelo E-R MySQL Workbench

Modelo EER En MySQL Worbench

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de AlexSnake

.... y luego????

ya nos mostraste tu diagrama entidad relación, pero... hasta ahi queda?
Ni un porque, para que....

Creo que quizo hacer algo

Creo que quizo hacer algo como un borrador.

Una interpretación

"Hay un registro de RPG o COBOL que está en un filesystem. Cada registro tiene un y sólo un primo instructor (podría ser tío o amigo, pero me gustó primo). Cada primo instructor puede recibir varias golpizas en su vida (les llaman eufemísticamente "lecciones"). Las palizas las puede recibir en diferentes lugares del cuerpo: cabeza, rodilla, estómago, etc. Para cada lugar del cuerpo donde se reciba una golpiza, hay un "cliente" que no podría ser un primo instructor porque son ligeramente diferentes."

Mi interpretación apesta, pero a falta de una explicación, tuve que imaginarme de qué se trataba el modelo. Y sí, tengo muy mala imaginación. ;-)

¿Por qué no se usan llaves primarias reales, y en cambio se emplean esos esperpentos conocidos como "ID"? Son utilizados por gente que hace programación orientada a objetos y que no sabe casi nada de bases de datos. (ANSI SQL 92 define el comportamiento de la actualización en cascada de una PK a todas las columnas afectadas).

Interesante que se usen mayúsculas y minúsculas: SQL no es sensitivo a mayúsculas ni minúsculas, pero su uso definitivamente facilita la lectura. Sin embargo, los espacios en los nombres de las columnas seguro van a dar mucha lata.

¿Por qué la edad es un varchar 45? ¿para poder escribir "tengo diecisiete años de edad"? Misma situación con todos las demás columnas. SQL tiene tipos para fecha, enteros, flotantes, etc. usar varchar y todos del mismo tamaño refleja falta de análisis y/o de comprensión del sistema de tipos SQL.

Por último, por favor, no llamar registro a una fila ni campo a una columna. Registros y campos son reliquias de hace muchísimos años cuando no había bases de datos relacionales, y se accedía físicamente a archivos de datos. Hay que acostumbrarse a pensar en tuplas de datos cuando se modelan bases de datos relacionales. Aquí en ejemplo de definición de registros y campos:

http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-2...

Podrían servirte este par de libros:

1. Joe Celko, Joe Celko’s Data and Databases: Concepts in Practice, 1st ed. (Morgan Kaufmann, 1998).
2. Joe Celko, Joe Celko’s SQL Programming Style (Morgan Kaufmann, 2005).

(hablan de "bases de datos", cuando en realidad deberían referirse a "sistemas de bases de datos relacionales", también conocidos como RDBMS. No todas las bases de datos son relacionales.

Saludos

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">