Normalización 01 - Primera Forma Normal 

En una clave primaria compuesta lo que debe hacerse es no repetir todos y cada uno de los campos que la componen. Si la clave de compone de dos campos, y se repiten ambos, da igual que haya más campos que no se repitan si estos no forman parte de la clave primaria. Esa tabla no cumpliría con la 1FN. Cuando quieras recuperar un registro la clave sirve para recuperarlo de forma que sea imposible confundirlo con otro. Si los dos campos que la componen están repetidos, no podrías recuperarla solo con ellos y no cumplirías la forma normal. Espero haberme podido explicar.

Utilizaba Filmora, una aplicación de pago relativamente barata, que permite grabar y editar. Creo que pagué 30€ por tenerla para siempre. No obstante me ha dado muchos problemas de compatibilidad (se me cerraba durante el renderizado y perdía los videos grabados) y tuve que pagarla dos veces por quedarse obsoleta, necesitar actualizarla y carecer ya de soporte. Sin embargo es la que mantengo por no tener nada mejor a ese precio.

Me gusta tu propuesta de solución, queda más elegante y limpia. No obstante se reproduciría el problema al escalar. Si tienes una tabla TELÉFONOS FIJOS en la que la clave primaria es el código del usuario y tienes un campo para el teléfono en cuestión; y otra tabla TELÉFONOS MÓVILES, en la que la clave primaria es el código del usuario y tienes un campo para el teléfono móvil en cuestión, vuelves a necesitar de una clave compleja que reúna ambos campos cuando un alumno te presenta 2 teléfonos móviles o más, o dos fijos o más. (Salvo que sólo permitas registrar un teléfono de cada tipo por persona). Este problema, o el mío original, podría solucionarse generando una tabla de relaciones alumnos y teléfonos en la que la clave sea una inventada por nosotros, por ejemplo, un campo de valor autoincremental, pero en este video únicamente se está tratando de explicar lo que es la primera forma normal y las tres condiciones que deben cumplirse para lograrla.

@@programadordenivel1 Si claro entiendo, de hecho ya me vi los otros videos porque empecé a estudiar eso esta semana y la verdad es que me resulto muy útil tu explicación. Si uno de los problemas que noto es que si uno tiene una cantidad indeterminada de datos del mismo tipo que se pueden agregar entra en un conflicto. Ejemplo, guardar todos los domicilios históricos de una persona. Si o si necesitas una clave compleja para acceder a todos ellos, porque solo con la clave de la persona no podes saber a cual de sus domicilios estas accediendo. Pero si uso la clave compleja puedo recuperarlos todos en una lista o el que busco si conozco el segundo valor de la clave que estoy buscando. Gracias por tu respuesta y espero sigas subiendo videos como ese que me encantan.

La verdad es que es un asunto feo. Es como cuando quieres poner Dirección y separar Calle, Número, CP, Ciudad, etc. Normalmente esto se evita haciendo 2 campos: combreCompleto y Apellidos. En inglés se suele ver con name y last_name. Si requieres esos 4 sí o sí, una opción sería tener una tabla personas con nombre y apellido1. Y 2 tablas más. Una tabla nombresCompuestos los campos id, id_persona, nombre2. Y otra tabla ApellidosCompuestos con los campos id, id_persona y apellido2. De forma que esas tablas sólo se rellenan cuando el apellido o el nombre es compuesto. Los campos id_persona serían clave foránea del id de la primera tabla. Espero que se me entienda. Si alguien tiene una idea alternativa puede proponerla. No obstante me parece mucha ingeniería para algo que se debería prevenir con los campos name y lastname, pudiendo incluir en ellos tanto nombres como apellidos compuestos. Espero haberte sido de ayuda.

@@programadordenivel1 muy claro muchas gracias

Muy buenas. En este vídeo únicamente estamos tratando de explicar de forma teórica el concepto de "normalización" aplicado a bases de datos. De hecho para ilustrarlo ni siquiera estamos usando una base de datos como Oracle o mysql, sino un Excel, por simplicidad. Si entendí bien tu pregunta, quieres saber cómo introducir datos en una base de datos mediante formulario. Para ello me temo que tendrás que ver un tutorial diferente y tener conocimientos de sql. La estructura tipo, no obstante, suele ser algo así : insert into nombreTabla values ('valor1', 'valor 2'...) ; Los valores van entre comillas simples salvo que sean números, que entonces van sin ellas. Espero haberte sido de utilidad

@@programadordenivel1 Entonces Excel no es para base de datos ,tengo información y está todo metido en una tabla los datos en otra por eso normalizar me parece interesante (tener los datos estructurados) ,tengo poco conocimiento de SQL lo instale una vez .

@@raisaro8979 efectivamente. Excel es una hoja de cálculo. La base de datos de Microsoft es access. No obstante lo que creo que quieres hacer podrás encontrarlo en tutoriales de Excel sobre "macros", que te permiten automatizar varias tareas como por ejemplo juntar las información de dos hojas diferentes, y tutoriales de "userform", que te permiten crear un formulario de usuario con el que rellenar una tabla Excel.

@@programadordenivel1 Etoy haciendo en accsess la estructura está buen, borré las referencias y estoy volviendo a pasar ,pero me quedado en el formulario quiero un formulario y vincular con las demás tablas ej. campo teléfono hay personas que tienen 2 y en la caja de texto solo aparece uno .

Buenos días, y muchas gracias por tu comentario. Aclarar que las tres tablas de la zona superior son distintas formas de errores comunes que existen. La primera es un error de valores no atómicos (El Al_002 tiene dos valores en el campo 'Teléfono'). La segunda es un doble error, por un lado porque tiene redundancia (Se repite el campo 'Nombre' del AL_002) y por otro y más grave, repite la clave primaria de (AL_002), y recordemos que las claves primarias deben ser únicas. Las claves primarias de cada tabla están pintadas en amarillo. La tercera tabla incluye valores nulos, y eso no es compatible con la primera forma normal. Las dos tablas de abajo son una propuesta válida de solución. Dicho esto, creo entender que comentas que en la segunda tabla de abajo hay valores duplicados o repetidos, y supongo que te refieres a que se repite el valor 'Al_002' en el campo Cod_Alumno. Sin embargo eso no se considera un valor repetido, dado que como puedes observar, ambos campos de esa tabla están pintados de amarillo (con lo que indico que ambos son clave primaria, formando una clave primaria compuesta). Al ser una clave primaria compuesta, para que se considere que está repetida o duplicada, deben repetirse los dos valores que la componen, no solamente uno de ellos. Esta misma solución que propongo para la primera forma normal está basada en la que propone Arturo Mora Rioja en su libro 'Bases de datos. Diseño y gestión' (2014) en la página 55. No obstante, si has encontrado una solución más óptima te agradecería que la publicaras en los comentarios, tengo interés en cómo podría resolverse de otras maneras. Nuevamente muchas gracias por tu aporte, un saludo.

Buena pregunta. Hasta donde yo sé (que me puedo equivocar), si quieres respetar la 1ª forma normal tienes que rellenar todos los campos. No puedes dejar uno sin valor o nulo. Si prevés introducción de datos que sólo van a tener un apellido, quizá en vez de los campos Apellido1 y Apellido2 podrías poner un sólo campo Apellidos. Es lo mismo que con las direcciones. En vez de poner un campo Calle, Numero, Piso, Puerta, Escalera, etc, que muchas veces se puede quedar alguno o varios en blanco, se suele poner un solo campo Dirección y en él todo el contenido. La otra opción es no respetar la 1ª forma normal y tener campos en blanco. No obstante si das con una solución alternativa agradeceríamos que la compartieras. Un saludo

@@danielmarcosmunoz6574 Otra alternativa sería, tener un valor absurdo para rellenar campos vacíos, este valor por supuesto debería tener el mismo tipo de dato del que suplanta, por ejemplo si tenemos un valor por defecto para algún apellido nulo que valga "Noaplica", en nuestro código interpretaremos esa lectura como campo apellido 2 nulo, lo mismo en el caso de celular, bastaría un valor como "111111111", de esa manera evitamos campos con valor null.

@@andresmoreno4040 Efectivamente. Sería una alternativa que funcionar, funcionaría, pero no sería elegante. Sería eficaz, pero no eficiente. A la hora de diseñar una base de datos de forma seria deben encontrar la solución óptima e idónea, y si bien lo que propones puede permitirte 'salvar la situación' si no sabes hacerlo de otra forma, en realidad estarías llenando una base de datos (que puede tener decenas de miles de registros) de 'datos basura', que estarían ocupando un espacio en la memoria y consumiendo unos recursos de tu sistema. Además el desarrollador que tuviera que hacer el mantenimiento de esa base de datos debería estar al corriente de ello para tenerlo en cuenta a la hora de realizar consultas y trabajar con ella. Si bien en una base de datos pequeña para pruebas te puede funcionar, la solución que propones no es escalable y tampoco se consideraría una buena práctica. Gracias por tu aporte.

En principio toda tabla debe tener su clave primaria, compuesta de uno o más campos. Si en una tabla un campo se compone de la clave primaria de otro campo, tendrás que indicar esa relación. Si un alumno está inscrito en varios cursos una posible solución sería seguir la siguiente estructura: Una tabla ALUMNOS que contiene los datos de los alumnos (CODIGO_ALUMNO, NOMBRE, APELLIDO, ETC.) siendo el código de alumno la clave primaria e irrepetible. Una tabla CURSOS que contenga los datos de los cursos (CODIGO_CURSO, NOMBRE_CURSO, DURACION_HORAS, ETC.) siendo el código del curso la clave primaria. Una tabla ALUMNOS_MATRICULADOS_EN_CURSOS con sólo 2 campos (CÓDIGO_ALUMO, CÓDIGO_CURSO) en donde la clave primaria es compuesta, y la conforman ambos campos código_alumno y código_curso. De esta forma un alumno puede estar registrado en varios cursos y la clave primaria no se repetiría (porque aunque se duplique el código_alumno tantas veces como en cursos esté matriculado, la otra parte de la clave, la del código_curso, no se está repitiendo) Espero haber resuelto tus dudas.