SQL (Structured Query Language) es una programación orientada a leer (read), manejar (update y delete) y construir (create) bases de datos relacionales. Las palabras en inglés marcadas en negro corresponden a las siglas CRUD. Estas son las acciones que se pueden hacer con las bases de datos ¡Recuérdelas!.
Por otro lado, al referirse a bases de datos relacionales se indica que existe una relación entre ellos. Para explicar esto imagínese usted tiene una empresa que diseño un sitio web donde sus clientes navegan. Cada cliente tiene que registrarse en su sitio web antes de navegar por él. Esto lo realiza así, primero para que cada interacción que tienen por su sitio quede registrada sabiendo quien hizo qué. Y segundo porque usted cobra por un servicio que ofrece dentro de su sitio web y una parte es solo para sus clientes que pagan. Otra parte es para todo público que se registra sin pagar. Por lo tanto, usted con esto debería tener como mínimo 3 tablas “macro” en este respecto, señaladas abajo:
Tabla cliente: Aquí están todos los clientes registrados en su plataforma.
| id_cliente | nombre | fecha_de_creación | |
| 1 | Pedro ko | pko@algo.cl | 10/11/2019 11:20:32 |
| 2 | Juan Ta | jta@algo.cl | 11/11/2019 11:22:42 |
| 3 | Valeria Fuentes | Vfuentes@algo.com | 10/03/2020 11:20:00 |
| 4 | Johan Renco | jrenco@@algo.com | 11/11/2020 11:20:32 |
Está y las demás tablas están cortadas, ya que pueden tener muchos más registros (filas). Y estás tablas son solo explicativas de lo que vendrá a continuación.
Podría esta tabla clientes tener otra columna que indique si el cliente ha pagado por tener todos los servicios que ofrece su empresa.
Tabla acciones_plataforma: Tabla donde cada fila o registro indica una posible acción en su plataforma.
| id_accion | nombre_accion |
| 1 | log-in |
| 2 | ver producto |
Tabla registro_acciones: Tabla que muestra efectivamente cada acción realizada por sus usuarios.
| id_registro | id_cliente | id_accion | Fecha_acción |
| 100 | 1 | 1 | 10/03/2020 11:20:01 |
| 101 | 2 | 1 | 10/03/2020 11:20:02 |
| 102 | 1 | 2 | 10/03/2020 11:20:03 |
Cabe destacar tres cosas:
- Cada registro es como una “oración” que causa “sentido” por su cuenta. Ejemplo:
- El primer cliente pedro de mail pko@algo.cl se registró el 10/11/2019 11:20:32. (primera tabla).
- La acción 100 registrada en el sitio web realizada el 10/03/2020 11:20:01 fue por Pedro realizando un log-in.
- Existe una relación o vinculación entre una o más tablas por medio de algunas de sus columnas (por medio de las id_cliente y id_acción). Estas son llamadas “foreign key”.
- Las tablas están normalizadas (esto se explicará más abajo).
Normalización
La normalización son una serie de reglas que permiten tener las bases de datos lo más “limpias posible”. Es decir, evitando inconsistencia. Las reglas son:
Primera Regla
Todas las filas de una tabla tienen la misma cantidad de columnas. Pueden existir columnas sin valor. Pero aun así, tienen la misma cantidad de columnas registro a registro.
Segunda Regla
Todas las tablas tienen una llave. La llave representa el registro y es única. Está llave puede ser una columna o más de una. Todo el resto de columnas que no son parte de la llave dicen algo de ella.
Tercera Regla
Si hay una columna que no se relaciona con la llave. Se debe sacar, a pesar, de poder estar relacionada con otra columna (que está a su vez sí se relaciona con la llave). Un ejemplo sería si usted tiene una empresa B2B (es decir, sus clientes son otras empresas que tienen por su parte empleados u otros clientes que usan su plataforma) y tiene una tabla usuario. Si en ella está la dirección del trabajo de ellos. ¡No estaría normalizada la bases de datos! Esto es porque la dirección de trabajo es de la empresa que emplea al sujeto y no del sujeto.
Aquí lo que debería hacer es crear otra tabla de empresas y a cada empresa asociarle una o más direcciones (si tiene sucursales). En caso de tener varias direcciones por empresas ¡Tenga especial cuidado a la primera regla de normalización!
Probablemente se esté preguntando ¿Por qué esto ayuda a tener las tablas “limpias”? Para responder esto por su cuenta trate de descifrar que pasaría si ocurriera lo de abajo. Específicamente, trate de responder ¿Cómo se actualizarían las bases de datos si pasará qué…?:
- Se quiere cambiar una dirección mal escrita de una sola sucursal (de una de las empresas cliente). En esta sucursal existen 10.000 usuarios activos en la base de datos.
- Una empresa con todas sus sucursales y/o filiales dejo de ser clientes de usted(y por ende todos sus usuarios).
- Un usuario de una de sus empresas se cambia a otra empresa. Y por suerte esa empresa también es su cliente.
- El mismo caso anterior pero la nueva empresa no está en base de datos. Y ese usuario era el único usuario inscrito hasta el momento de esta empresa.
- Se agrega una nueva filial de una de las empresas a la base de datos.
Cuarta Regla
Las tablas no deben implicar una relación que no existe. Aquí las tablas probablemente deban separarse en más tablas para eliminar está falsa relación. Por ejemplo, si se sabe más información de los clientes que navegan por la página. Como es su área de trabajo, el idioma que habla y su conocimiento en software. Al ver la tabla, se puede erróneamente pensar que existe una relación entre sus columnas que no existe. Mire el siguiente ejemplo:
| Cliente | Habilidades Técnicas | Idiomas_hablados | Área de Trabajo | |
| Pedro Ko | Python | Español | Gerente de Marketing | |
| Pedro Ko | Excel | Inglés | Gerente de Marketing |
Por ejemplo, se puede concluir al ver las tablas (erróneamente) que hablar español impacta positivamente para ser gerente de marketing y saber Python. Lo que se debe hacer aquí es separar las tablas. En este caso sería una tabla con competencias técnicas por persona. Esto es porque una persona puede tener varias competencias técnicas y por ende varios registros o filas en ellas. Lo mismo se hacen con las otras tablas que se crean. Es decir, se crea también otra tabla de idiomas que habla el cliente. Y la última con el área que trabaja. Si todos los usuarios trabajan solo en una sola área de trabajo se puede mantener está columna en la tabla cliente. Cómo se muestra abajo:
| Cliente | Idiomas_hablados |
| Pedro Ko | Español |
| Pedro Ko | Inglés |
| Cliente | Habilidades Técnicas |
| Pedro Ko | Python |
| Pedro Ko | Excel |
Generalizando este punto un poco más. Lo que dice esta regla es que no pueden haber dos o más registros que dentro de una llave (este caso un cliente) puedan tomar dos o más valores. Por ejemplo un trabajador puede saber uno o más idiomas. Y por otro lado puede tener más de una competencia técnica. Por ende estos dos atributos no pueden estar juntos dentro de una misma tabla. Ya que son independiente entre ellos y no debe implicarse una relación que no existe.
Adicionalmente tener las bases de datos normalizadas ayuda mucho para actualizarlas. Imagínese que, por ejemplo, Pedro aprende una nueva habilidad, Word. Note lo fácil que es actualizar los datos con las tablas separadas y lo difícil que resulta cuando no lo están (que pondría, por ejemplo, en Habilidades Técnicas para rellenar la fila).
Nota Respecto a normalización
Si se cumple la primera regla de normalización se dice que la base de datos está en su primera forma normal. Para estar en la segunda forma normal tiene que estar en la primera forma normal y en la segunda. Y así para las siguientes formas normales.
Existe una quinta forma normal. Que básicamente toca casos no tratados por las cuatro reglas anteriores. Está forma normal se dejará fuera. Pero para el curioso se deja la siguiente esta fuente para que pueda seguir leyendo. Pero en resumen, trata de encapsular la mayor cantidad de información con la menor cantidad de registros. Y así ayuda a que no crezcan las bases de datos de forma tan exponencial.
Casos Prácticos que se Puede Lograr Con Consultas a Bases de Datos
Probablemente si llego a este artículo le interese, la parte posterior a la creación de las bases de datos. Vale decir, una vez que ya están las bases de datos creadas, ¿Cómo puedo extraer el mayor potencial de ellas para mi negocio?, ¿Cómo puedo hacer consultas que me entreguen información relevante? Partiendo de un punto más básico que se puede consultar con las 3 tablas de arriba.
- Se podría saber cuantas acciones promedio hace cada cliente.
- A que horas navegan.
- Cuántas sesiones realizan en un mes.
- Cuántas acciones hacen en una sesión.
- Cuánto tiempo están en una sesión normal.
- Cual es el viaje del cliente por la plataforma. Con esto se podría saber cuales son las páginas más visitadas y cómo llegan a ellas.
Incluso podría ir más lejos y usando algoritmos de Machine Learning más algunos supuestos podría preguntarse. Qué sesiones probablemente existió una frustración en la navegación.
En los siguientes artículos se irá trabajando estos puntos entregando en cada uno de ellos las correspondientes consultas en mysql.
