Normalización BD

[[Caral]]

Empezado por Delphius

......
De otro modo sólo podría esperarse un caso de (1:M).

Amigo, esto no es cierto, Depende de como se haga la tabla y campos.

Empezado por Delphius

.......
Algo fundamental para para poder establecer el diseño de las tablas y sus relaciones.

Amigo, igual que lo anterior; depende.

Empezado por Delphius

La teoría del álgebra relacional y de las reglas normales que ha mencionado rgstuamigo así lo indican: Una relación (M:M) debe "romperse" añadiendo una tabla intermedia para establecer dos vínculos (1:M). Luego se normalizan estas tablas.

Sigo igual; depende.

Empezado por Delphius

No entiendo lo que comentas y el objetivo que planteas. Disculpa.

Entiendo tu punto.
No pretendo ningun objetivo, solo digo que no es necesario crear una tabla adicional para que un usuario pueda acceder a mas de una empresa.
La relacion la puedo hacer de muchas maneras sin necesidad de crear una tabla.
Estoy seguro que tu tambien podrias hacerlo sin nigun problema.
Saludos

[[Delphius]]

Puede ser Carlos, puede ser que pueda... aunque seguramente si siguiera ese enfoque muy posiblemente esté rompiendo algunas reglas normales y no conseguiría una buena normalización.

Admito que en ocasiones es deseable cierto grado de desnormalización, pero creo que para este caso, se perderían algunas virtudes y ventajas que ofrece unas buenas tablas bien estructuradas, índices y claves primarias y foráneas para agilizar las cosas.

Una de las maravillas del álgebra relacional y las reglas normales es la de eliminar la redundancia y de establecer vínculos fuertes que luego dan mayores capacidades.
Y creeme, no por añadir una tabla se hace las cosas más complejas. Si fueran 15 o más allí creo que si se podría aceptar tu planteo amigo.

Se pone mucho énfasis en la normalización porque con una buena estructuración se aprovecha mejor las capacidades del motor, las consultas tienden a ser más sencillas, rápidas y estables... Y si mjjj está llevando esto para algun trabajo de la universidad con más razón debe verse que se han aplicado las reglas normales... Son muy exigentes los profesores en esto.

Ya nos dirá mjjj.

Saludos,

[[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

[[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.