Introducción

En este nuevo artículo voy a explicar con un lenguaje no técnico que son las bases de datos relacionales y porque los profesionales que trabajan con datos deben conocer sus fundamentos.

Una Base de Datos relacional es un “programa” que su función es la de ir guardando datos de una página web, de una aplicación móvil, de facebook, de netflix… para después poder consultar los datos. ¿Dónde creéis que se guardan los datos que publicamos en Facebook o cada vez que compramos en Amazon?

Las bases de datos relacionales necesitan para funcionar lo siguiente:

• Tablas y columnas
• Datos
• Lenguaje de consultas SQL ( Lenguaje Estructurado de Consultas )

Ahora que he realizado una breve introducción a las bases de datos voy a entrar más en profundidad a explicar cada apartado.

Tablas y Columnas

Las bases de datos necesitan una estructura para poder almacenar datos y esta estructura es una tabla con columnas. Podemos verlo como sí fuera una hoja de Excel donde cada fila es un registro ( tupla ) y cada columna es una columna.

Esta hoja de excel es el ejemplo perfecto de una tabla de BBDD.

• La tabla se llama ficha_cliente
• Tiene 4 columnas: id, nombre, apellidos, telefono
• Tiene 5 registros 

Esquemas de entidad relación

Cuando se diseña una base de datos relacional la forma correcta es diseñar un esquema de Entidad – Relación o ER.

Este esquema es el esquema lógico donde se representa el mundo real y como se va a guardar los datos en una base de datos

La explicación de este esquema es la de tener una base de datos que almacene los datos de los clientes de una biblioteca, estos clientes deben poder alquilar libros de la biblioteca y cuando los alquilen se debe quedar registrada la fecha de alquiler y cuando lo devuelvan se debe registrar la fecha de entrega.

En la base de datos se debe almacenar los datos de los libros como puede ser el género, la sinopsis y el autor. 

Como un autor puede escribir varios libros es conveniente tener almacenados los datos de autor en la base de datos.

Una vez se ha diseñado el modelo lógico de entidad relación es hora de pasar este modelo a tablas físicas a la base de datos.

Paso a tablas

A partir de un modelo entidad relación se va a crear el modelo físico de tablas y sus relaciones.

Para convertir el modelo de entidad relación hay que tener claro lo siguiente:

• En todas las relaciones N:N se tiene que crear una nueva tabla que una las tablas relacionadas. La clave primaria de esta tabla va a ser una clave compuesta de las claves primaria de las tablas origen. Además, cada campo tiene que estar relacionado con su clave ajena o Forgeign Key

• Las relaciones 1:N se tiene que llevar la clave primaria de la relación 1 a la tabla de la relación N. Esto significa que la relación 1 puede estar en muchas N

• Las relaciones 1:1: Para este tipo de relaciones hay 2 formas:

• Creación de una nueva tabla como la N:N pero aparte de crear la clave primaria compuesta se debe crear un índice único por cada campo de la clave primaria. Esta restricción sirve para evitar que por ejemplo la clave 1 se repita y la clave 2 también se repita.

• Llevar la clave primaria de una tabla a la otra realizando un cruce de claves. Para mi gusto este tipo de unión me gusta más que el de crear una tabla.

Una vez explicado cómo se debe crear las tablas a partir del modelo lógico, este es el resultado.

Una vez obtenido el modelo de tablas ( diferente al modelo lógico ) es necesario escribir la definición de las tablas si esta información se quisiera utilizar para un análisis. 

• autor ( id_autor, nombre, apellidos, fecha_nacimiento )
  • primary key: id_autor
  • Tipos de datos:
    • id_autor: integer
    • nombre: varchar(100)
    • apellidos: varchar(100)
    • fecha_nacimiento: datetime
• libro ( id_libro, titulo, tematica, id_autor, sinopsis )
  • primary key: id_libro
  • foreign key: id_autor -> autor( id_autor )
  • tipos de datos: 
    • id_libro: integer
    • titulo: varchar(100)
    • tematica: varchar(100)
    • id_autor: integer
    • sinopsis: varchar(1000)
• cliente ( id_cliente, nombre, apellidos, ano_nacimiento, direccion, sexo, telefono, email )
  • primary key: id_cliente
  • tipos de datos:
    •  id_cliente: integer
    • nombre: varchar(100)
    • apellidos: varchar(100)
    • ano_nacimiento: integer
    • direccion: varchar(500)
    • sexo: char(1) (valores H o M)
    • telefono: varchar(20)
    • email: varchar(100)
• cliente_libro_alquila( id_libro, id_cliente, fecha_alquilar, fecha_entrega )
  • primary key: id_libro, id_cliente, fecha_alquilar
  • foreign key:
    • id_libro -> libro (id_libro)
    • id_cliente -> cliente (id_cliente)
  • tipos de datos:
    • id_libro: integer
    • id_cliente: integer
    • fecha_alquilar: datetime
    • fecha_entrega: datetime

Conclusión

Siempre me gusta terminar los artículos dando mi opinión personal o realizando una pequeña conclusión.

Voy a ir escribiendo artículos sobre bases de datos porque estoy viendo que en Linkedin cada vez hay más profesionales que se dedican al tratamiento de datos pero carecen de los conocimientos básicos de las bases de datos.

Estoy viendo ofertas de trabajo en las que se valora mucho los años de experiencia que tienes en ciertas herramientas pero obvian si tienes una buena base que al fin y al cabo es lo importante para hacer un trabajo de calidad o un trabajo mediocre.

Además, hay muchos profesionales haciendo procesos ETL y construyendo Datawarehouse que les preguntas si han hecho un modelo dimensional, sí han hecho tablas desnormalizadas o si simplemente tienen un esquema de Entidad Relación y no saben de lo que hablas. 

En este artículo que escribí hace meses explico qué es un modelo dimensional en estrella

• El modelo de estrella. El pilar fundamental del Business Intelligence: https://datamanagement.es/2019/06/27/business-intelligence-modelo-estrella/