Normalización BD

[lbuelvas]

Resp, consideraría que por la dinámica del tiempo, es posible que una persona trabaje para la misma empresa mas de una vez, por ejemplo, se vincula del año 2000 al 2005, se retira y vuelve a vincularse desde el 2010 en adelante.

Podriá considerarse como sugiere JoAnCa identificar la tabla con el "Numero del Contrato", siempre y cuando cada empresa tenga numeraciones diferentes; como estoes dificllograr, puede usarse una llave artificial como por ejemplo un numero consecutivo.

[rastafarey]

Para ese caso seria otro diagrama. Por digo que todo depende de la naturaleza del problema.

Si plantean un problema con anbiguedad generaremos muchas controversias y muchas respuestas y todo esto se deve a que cada quien tien un punto de vista.

Ahora si aclaramos todos los criterios que debes usarse no creo que se genere ambiguedad.

Les voy a plantear una situacion. Hace un tiempo estaba realizando un sistema donde debia realizar una tabla de parestesco entre personas y como todo progrmador que no nos gusta escribir en papel si hacerlo a vuelo pajaro siempre se llegaba a un punto que las tablas no funcionanban como debian, saben como lo sulucione un simple diagrama y a la final el diagrama me dijo que habia que hacer una sola tabla. Si no escribimos en papel y ahcemos el diagrama la mente nos va jugar muchas bromas que a la larga las vamos a pagar con perdida de tiempo y dinero. Y para emendar el capote vamos aterminar haciendo una chapuzada.

[lbuelvas]

Resp, encuentro ambiguedad en tu ultimo post, quede con la incertidumbre si estas dirigiendo el comentario a todo el mundo o a mi especificamente. Llevo el suficiente tiempo desarrollando sistemas de gestión e impartiendo catedra universitaria en diseño de bases de datos y me considero con autoridad para tratar el tema de este post.

Lo que he querido aportar es simplemente ampliar la visión de lo que pasa cuando diseñamos bases de datos y no las proyectamos a que su uso puede perdurar durante varios años para una organización y las "chapuzadas" pasan cuando siguiendo el planteamiento que propongo te dicen que el empleado volvió a trabajar en la empresa, me explico, en un momentum del tiempo, es decir si detienes el tiempo, una persona no puede trabajar mas de una vez en la misma empresa, pero si miras a lo largo de los años una persona si puede trabajar varias veces en diferentes temporadas en la misma empresa; ese pequeño detalle puede obligar a un cambio en el diseño de la base de datos y del aplicativo mismo.

Por las razones expuestas, me demoro un poco mas en el diseño tratando de preveer cambios a futuro, dejando flexible el modelo para responder rápidamente ante los cambios que se presenten en requerimientos por parte del cliente.

Y comento que cuando me enfrento a diseñar una base de datos utilizo como tu comentas lápiz y papel, además los modelos los documento con herramientas disponibles para ello, los imprimo y cunado estoy programando los tengo pegados a la pared para tener la visión global y detallada del proyecto.

[rastafarey]

Bueno segun veo no estamos siendo controdictorios. No se si me considere con autoridad para tratar el tema, pero ya tengo casi 18 años desarrolando bases de datos. Y como todos sabemos siempre hay algo que nos falto y cierto caso que no tomamos en cuenta. Por eso digo que todo se basa el la naturaleza del problema. Aunque por mas expertos y mas experiencia que tengamos el algun momento se nos va a pasar cierto casoo regla que no tomamos en cuentas. Lo que siempre querido expresar en este post en que si tomamos todos los casos con un buen diagrama de entidad relacion nos va dar la bd que necesitamos. Bueno eso lo digo en mi caso. No es mi intencion molestar ni contradecir a nadie.