Normalización BD

[[Delphius]]

Empezado por Caral

Hola
Si amigo, se que es una manera de hacer las cosas y me imagino que debe ser la mejor.
Solo que aveces como buen alumno trato de que ampliéis las dudas.
Si no planteo una posibilidad es difícil que aprenda.
Yo estoy de acuerdo con lo que dices, solo que me gusta exprimiros el conocimiento, como puedo aprender si no es asi.
Gracias amigo por la paciencia.
Saludos

Ha... ya veo, tu lo que quieres es que redacte mis típicos testamentos y que me explote la cabeza
Pues ahorita no puedo amigo. Desde el ajuste de tornillos que siento que se me hace más difícil realizar esas largas exposiciones.

Como tu ya sabes amiguito: habrá que acostumbrarse a que de a poquito la pandilla New se vaya despidiendo. Va a ser un tantito más aburrido, pero bueno hacía falta eso y a mis amigos ya no le estaba gustando que se colasen cada vez que nos juntábamos... reconozco que en ocasiones eran una mala influencia.

Saludos,

[rastafarey]

La relacion entre tablas de una base de datos depende de su cardinalidad.
Si es de 1 a 1 se usa una clave foranea en una de las tablas
Si es de 1 a n se usa una clave foranea en la tabla n
Si es de n a n se crea una nueva tabla con ambas claves foraneas.

Y como siempre recomiendo no hay mejor normalizacion que la que sale de un buen diagrama de entidad relacion. Ya que muchas veces las formas normales se rompen en algunos casos por eso no normalizo usando dichas formas normales(ese es mi criterio y eso me dice la practica). Cada quien en libre de eleigir como normalozar su bd.

[lbuelvas]

Hola amigos foristas, la pregunta planteada por el compañero mjjj es bastante interesante y ha sido tema de mutiples discusiones.

Quiero comentar sobre las tres primeras tablas. Ambas aproximaciones son válidas, sin embargo quiero replantear el modelo del negocio de la siguiente manera: Imaginemos que necesitamos registrar informacion sobre usuarios o clientes y tambien registrar la informacion de empresas; en cada empresa pueden laborar uno o mas usuarios y cada usuarios pueden trabajar en una o mas empresas.

Caso 1:
Tablas:
usuarios (id, nombre, apellido) PK: id
empresas (id, nombre) PK: id
empresa_usuario (id_usuario, id_empresa) PK: id_usuario, id_empresa

Caso 2:
Tablas:
usuarios (id, nombre, apellido) PK: id
empresas (id, nombre) PK: id
empresa_usuario (id, id_usuario, id_empresa) PK: id

Hay algo que normalmente no se enseña en cursos básicos de bases de datos y es la dinámica del tiempo. Cuando diseñemos bases de datos debemos pensar que el sistema se va a utilizar no por un año sino por un periodo de al menos 5 años. Los 2 modelos nos permite indicar el usuario para que empresa trabaja, pero preguntemonos: El usuario puede renunciar a una de las empresas y un tiempo despues puede volver a trabajar en esa misma empresa, en esta situación y solo con tres tablas el caso 1 no nos sirve, el caso 2 es mas flexible en cuanto a diseño.

Esto nos lleva a que cuando nos encontremos con una relación m:n (eviten escribir m:m porque se estaría diciendo que existe igual numero de elementos en cada una de las entidades) pensemos en que no solo se resuelve con una tabla de asociación sino que esa tabla de asociación puede ayudarnos a "enriquecer" el modelo.

Entonces esa tabla empresa_usuario podria quedar asi:

empresa_usuario
(
id not null,
id_usuario not null,
id_empresa not null,
estado not null
fecha_ingreso not null,
fecha_egreso
) PK: id

El campo estado puede decirnos si esta vinculado, suspendido, contrato cancelado,etc.

Fecha de ingreso como su nombre lo indicanos dira cuando se establecio esa relación y fecha de egreso tendrá un valor null hasta que haya finalizado la relación del usuario con la empresa.

Sobre si es mejor las tablas identificarlas con un identificador único entero (ID) es algo que defienden los puristas defensores del modelo orientado a objetos, es muy flexible pero la construcción de aplicaciones y elaboración de consultas es mas compleja y no tan eficiente como con la creación de llaves "relacionales" (mas de un atributo). Ambas aproximaciones (relacional y de objetos) tienen sus ventajas y desventajas, por eso utilizo una u otra o una mezcla de ambas dependiendo de la situación que deba resolver de forma que mantenga un equilibrio entre simplicidad y efciencia.

[rastafarey]

empresas

n
|
posee
|
n

usuarios

hay una relacion n a n
lo cual da nacimiento a una tercera tabla la tabla de relaion entre epresas y cliente.

solo hay que hacer un buen diagrama de entidad relecion poner la cardinalidad y el resultado sera la mejor base de datos que se pueda disenar.