Cual es normalizacion aplicarian

[jairx_x1]

Que normalizacion de estas es mejor:

1. Se tiene que hacer una base de datos en mysql de hojas de vida y lo que se quiere es que al final se filtren personas por estudios y cargos.

La primera solución sería crear 7 tablas ya que en los datos personales hay un identificador unico que es un id o cedula, entonces esta sería la tabla maestra y las otras dos dependeran de esta en una relacion de 1:n y de 1:n es decir una persona puede tener muchos estudios y una persona puede tener muchos trabajos cierto?, 3 tablas para los datos personales, estudios y cargos ademas otras 3 tablas que contendran las llaves primarias de estas principales, y las que conectan con estudios y experiencas que se conecten a la secundaria de datos_personales asi se crearia toda una relacion.

2. la segunda opcion y mas viables pero no estoy seguro si es normalizar es crear 4 tablas la de datos personales, estudios y experiencias y una que contenga 3 llaves primarias y 3 llaves foraneas que lleven a cada tabla su respectiva relacion.
me parece mas facil pero no se a la hora de las relaciones funciones bien ? Muchas gracias y pues si se le van unos ejemplos de bases de datos o saben donde encontrar ejemplos de bases de datos relacionales pero hechas en mysql para examinar el codigo haber como podria construirse sería muy bueno.

[gnzsoloyo]

Estás empezando por las tablas, cuando en realidad deberías comenzar analizando el sistema, las entidades y las relaciones. De allí sale todo.
Comenzar creando tablas, es lo mismo que levanta paredes sin cimientos, o agregar puertas de habitaciones a una construcción sin un plano: simplemente terminarás haciendo cualquier cosa.

¿Por qué no empiezas haciendo un buen DER lógico? El 99% de tus respuestas saldrán de allí solas.

[jairx_x1]

gnzsoloyo aqui un prospecto de lo que hice :
[URL="http://s2.subirimagenes.com/otros/previo/thump_8368518norma.jpg"]http://s2.subirimagenes.com/otros/previo/thump_8368518norma.jpg[/URL]

Y pues sobre esto quiero que me digan si es viable o como lo harían ustedes?. Gracias.

[gnzsoloyo]

Eso es un thumbnail, es decir, una miniatura de una imagen... no se ve lo suficiente para reconocer nada.

En cuanto a lo que yo haría.. ya te lo dije: Primero comenzaría haciendo un buen DER, a fin de no olvidarme de nada y por sobre todo, no perderme en la definición de las tablas.
Diseñar una base directamente por las tablas sólo lo puedes hacer bien cuando tienes experiencia en el diseño de datos. Y hablo de MUCHA experiencia.

[gnzsoloyo]

Vamos a ver si te puedo acercar un poco a la logica que se aplica en este caso:
1) Todas las relaciones nacen sobre la persona, esto es: una entidad Persona es la raiz de todo el diagrama.
2) Una persona debe tener diferentes datos que le son propios, y son completamente inseparables: Nombre, apellido, fecha de nacimiento, estado civil, dirección, etc.
3) Puede tener más direcciones, pero sólo una es la real.
4) Debe tener estudios de cierto grado, y puede tener más estudios de otros niveles. Todo estudio fue en una institución, con un titulo recibido, en un año definido, y es de cierto nivel
5) Puede haber hecho cursos de posgrado o especialización. cada curso debe tener nombre, institución, periodo de duración, y fecha de realizacion.
6) Puede haber trabajado. Todo trabajo debe ser en una empresa u organización, con periodo de ingreso, pudiendo haber o no terminado, en un puesto y debe tener algun tipo de tareas o responsabilidades, así como referentes de consulta.
7) Puede tener hobbies o aficiones (no discriminables)
Con este esquema, una hoja de vida (o curriculum vitae) requiere al menos de seis (6) tablas, las de las cuales hay una sola mandatoria, y en todos los casos hay una relación 1:N, por lo que la PK de la entidad persona es FK no mandatoria en cinco (5) de las tablas y mandatoria en una (1).
El modelo se puede expandir si y sólo si se requieren almacenar por separado los nombres de las empresas, de las instituciones educativas, o cosas así, pero ni aún en ese caso son relaciones N:N.

[jairx_x1]

Gracias por responder , pero una pregunta, a que te refieres con lo de Fk no mandatoria en cinco?, yo entiendo que esa Fk la tendra tambien la Pk de la entidad persona, cierto? no se pero no es necesario expandirla, Muchas gracias.

[gnzsoloyo]

Una FK mandatoria es cuando el campo FK se declara NOT NULL.
Mandatorio es un sinónimo de "obligatorio", en este caso.
Por deducción, una FK no mandatoria es nulable y como tal la única condición es que si se ingresa un valor, ese valor exista en la tabla referida.
Obviamente me refiero a la tabla donde el campo es FK apuntando a otra tabla. En la tabla origen toda PK es NOT NULL.
Puntualmente, en tu caso, la tabla Persona puede o no tener, significa que puede que no existan cursos, estudios o trabajos desarrollados por la persona. Pero por otro lado una persona debe tener estudios, pero como la tabla estudios depende de persona y no al revés, esa restricción sólo se puede controlar a nivel programático, y no en la base de datos.

Vamos a ver si se entiende mejor:
Una FK es obligatoria sí y sólo si el campo donde se define es NOT NULL, y esto pasa en dos circunstancias:
1) La FK es parte de la PK de la tabla.
2) La FK es NOT NULL por requerimiento de negocio.

El primer caso es el de las entidades débiles, cuya existencia obligatoriamente depende de otra entidad. Sería el caso, por ejemplo, de los estudios de una persona: Una entrada por cada estudio, con el ID de la persona a que pertenece esa instancia.
El segundo caso es el de las relaciones obligatorias por integridad de datos: Una dirección alternativa de una persona debe forzosamente existir en una ciudad, aunque la ciudad sea sólo un código.En ese caso el Código de la ciudad es obligatorio, y no debe omitirse.

Las FK no mandatorias (no obligatorias), representan siempre información adicional no relevante. Un ejemplo de eso podría ser, tal vez, algún dato de jurisdicción (barrio, departamento de la provincia), que no sea necesario para mayor precisión.