VIDEO 16. ¿Cuestionario 2? ¿Examen para la sección de MySQL?
1. El Primary Key es igual a una Unique Key:
Falso, solo son iguales en el aspecto de que su valor será único en la tabla, pero hay otros
aspectos como el AUTOINCREMENT que solo aplica a las Primary Keys.
2. Los campos con Indices de tipo KEY no pueden tener valores duplicados:
Indica puede tener valores duplicados.
VIDEO 17 ¿La Primera Forma Normal?
Bueno, llegó ya el turno de meternos de lleno en las optimizaciones y en las mejoras.
Lo que tenemos que tener en cuenta a la hora de diseñar tablas en bases de datos.
Atención, porque esto que vamos a ver no fue creado por mí, no fue inventado por Pablo Pilota.
Es algo que ha sido creado y macerado luego de muchísimos años, de muchos expertos alrededor
del mundo y lo han llamado las 3 formas normales de diseño de bases de datos.
Entonces, lo que vamos a ver en este capítulo es vamos a empezar con la primera forma normal,
que consta de 4 principios, no 4 principios que tenemos que seguir a la hora de diseñar nuestra
base de datos.
Vamos a ver el primero.
Cada tabla de la base de datos debe tener una clave primaria única y más o menos lo hemos
visto con las bases, con la base de cursos, las tablas de clientes, productos, todo tiene su clave
principal. (ABRIR ARCHIVO CursoBD).
Vamos a ver, aquí todo tiene su ID cliente, todo producto, ID, proveedores, ID. Todo es clave
principal sí o sí.
Cuando creen tablas tienen que tener una primary key siempre.
Entonces esta estamos cumpliendo ya con la primera premisa de la primera forma normal.
¿Por qué es así? ¿Por qué nos obliga esto?
Porque eso hace de que cada tabla pueda ser accedida por su clave principal y esto genera una
respuesta en milisegundos automáticamente al tener el ID de cliente como una clave principal.
Cuando yo busque el cliente número 10, lo que va a ser el motor, como va a tener indexado por
su clave principal, ese campo va a acceder automáticamente a los datos.
Segunda regla de la primera forma normal:
No se permiten grupos repetitivos de datos.
Esto es muy importante. ¿A qué se refiere?
Se refiere a que, si yo voy a hacer que mi cliente tenga varios teléfonos, la posibilidad de cargar
varios teléfonos, no voy a crear el campo.
Teléfono uno y otro campo. Teléfono dos y otro campo. Teléfono tres.
Eso es una mala práctica.
Entonces lo que nos dice es que si necesitamos llegar a eso, que nos creemos una tabla aparte
llamada clientes, teléfonos, por ejemplo, y que cada registro sea un teléfono propio de cada
cliente, Se entiende?
Vamos a hacer el ejemplo aquí vamos a crear, vamos a crear una nueva tabla, la vamos a llamar
“clientes_telefonos“ vamos a tener, vamos a crearle (AGREGAR) un prefijo que es “CliT_id” para
que sea único.
No vamos a tener tantos datos así puede ser un medio int “Sin signo”.
Aquí vamos “Agregar” un cliente cli id (CliT_ClilD) que apunte a mi tabla de clientes. El tipo de
dato que elijamos acá tiene que ser exactamente el mismo que tenemos en la tabla Clientes y
en la tabla Clientes.
La clave principal es un MEDIUMINT, tenemos que colocar MEDIUMINT, si es un un INT tenemos
que colocar INT ok.
Ahora vamos a crear todos los índices de esto y aquí vamos a crear “Agregar” una columna que
va a ser teléfono (CliT_Telefono). ¿Fíjense que no es teléfono uno, teléfono dos va a ser de tipo
obviamente VARCHAR y aquí vamos a decirle que es 20 más no?
Ok, entonces esto va a ser mi Primary key.
Esto va a ser una clave que se puede duplicar porque por un mismo cliente puedo tener n
teléfonos. Lo bueno de esto es que no me limita.
Si yo quiero que un cliente cargue 20 teléfonos disponibles lo puede hacer porque va a haber un
registro por cada teléfono “sin valor predeterminado”.
Lo dejamos y aquí podemos permitirnos un NULL.
Ok, sin valor predeterminado. Me está obligando a que cuando yo inserte un registro en esta
tabla tengo que colocar el cliente y aquí no puede ser nulo, sino que va a tener que ser lo mismo.
No puedo colocar un valor predeterminado nulo en una primary key.
Ok, perfecto, ya tengo mi tabla “cliente_teléfonos”, entonces aquí yo en mi ficha de clientes voy
a.
No voy a colocarle un campo teléfono porque eso ya hace que los teléfonos van a ir en una tabla
aparte. Vamos a ver otro ejemplo.
Supongamos que tenemos que tenemos usuarios en lugar de clientes y por cada usuario de
nuestro sistema le damos la posibilidad de cargar sus redes sociales.
Entonces, ¿qué tendríamos que hacer en mi base de usuarios?
¿Crear un campo que diga Facebook, crear un campo que diga Twitter?
No, esa sería una práctica, una práctica terriblemente mala.
Tengo que tener una tabla que sea usuarios, redes sociales y ahí por cada registro con el ID de
usuario voy a poder grabar distintas redes sociales.
Entonces un usuario va a poder tener 20 redes sociales, otro no tener ninguna, no va a haber
ningún registro en esa tabla, otro puede tener dos, puede tener Twitter y Facebook.
Entonces esto es lo que nos dice la primera forma normal de que no hay que repetir grupos, no
se permiten grupos repetitivos de datos. Es una mala práctica.
Entonces cuando tenemos que repetir tenemos que ir a una tabla auxiliar.
Vamos a ver al tercer, a la tercera consigna de la primera forma normal.
(COLUMNAS CON VALORES ATÓMICOS) Cada columna en una tabla debe contener valores
atómicos y con esto se refiere a que, por ejemplo, en conviene que no haya un campo nombre.
Aquí tengo razón social, pero puede haber un campo nombre y dentro tener el nombre y el
apellido.
O sea, dentro de cada campo tendría que haber un valor inequívoco y único de que nos está
diciendo que no tengamos valores compuestos.
Entonces, en los sistemas generalmente puede haber nombre y otro campo que sea apellidos o
apellido y los vamos a estar separando y atomizando lo máximo posible.
(COLUMNAS CON UN SOLO VALOR POR FILA) Cada columna en una fila debe tener un solo valor
para esa fila.
Tiene mucha relación con lo que dijimos en la tercera consigna.
Esta cuarta consigna medios como que lo está reafirmando.
Por ejemplo, si tenemos un campo llamado hijos, que dentro de ese campo no estén los hijos
separados por comas y los nombres de todos los hijos, esa es una mala práctica, como como
decimos lo mismo, si vamos a permitir que carguen los nombres de todos sus hijos, vamos a
tener que tener una tabla aparte que sea usuarios o clientes hijos.
Ahí por cada registro el cliente va a poder tener un hijo en cada campo, no separados por comas.
Bueno, eso tiene que ver con la primera forma normal y ahí ya nos va dando un panorama y nos
va alineando de acuerdo a lo que nosotros tenemos que tener en cuenta a la hora de diseñar
tablas.
Vamos a ver qué nos dice la segunda forma normal.