SQL: Formas Normales

Recuperados ya del fin de semana de rock and roll vamos a volver al código con algo de SQL teórico: la normalización de datos. El diseño lógico de las tablas y sus relaciones es fundamental para la optimización de una base de datos. Existen cinco reglas de normalización que debemos cumplir para aseverar que nuestra base de datos SQL está normalizada, aunque es cierto que hay quien considera que la cuarta y la quinta son rizar el rizo y que con cumplir la tres primeras generalmente ya tenemos una base de datos normalizada. Estas son las cinco formas normales:

  1. Primera Forma Normal: La primera forma requiere la eliminación de todas las columnas duplicadas de una tabla, la separación en otras tablas de esos datos que se duplicarían y la identificación de cada tabla con una atributo de clave primaria. Por ejemplo, si tenemos una tabla donde registramos ventas no guardamos el nombre y el precio del producto vendido en ella varias veces, sino que tendremos una tabla de productos con esos datos separado de la tabla de ventas, y ambas tendrían claves primarias que identifican a cada fila.
  2. Segunda forma Normal: Implica que se cumpla lo dicho en la primera forma normal y que, además, se creen relaciones entre tablas a través de claves externas. Es decir, la tabla Ventas del ejemplo anterior incluye como Clave Externa un valor único que lo relaciona con la tabla Productos, generalmente su clave primaria.
  3. Tercera Forma Normal: Esta norma implica que se cumplan las dos anteriores y que, además, todas las columnas de un registro deben hacer referencia únicamente a la clave primaria, y además elimina todos los atributos derivados. Volvemos al ejemplo: la tabla Productos nos dará el nombre del producto, su precio, en qué almacén se guarda y su fecha de caducidad. No tendremos, por ejemplo, un registro para decir en qué piso del almacén se guarda, ya que ese dato sería de la tabla Almacén. Tampoco tendríamos una columna con los días que faltan hasta que caduque, ya que ese sería un atributo derivado que podemos calcular con la fecha de caducidad.
  4. Cuarta Forma Normal: Agrega un requisito adicional, que es la eliminación de cualquier dependencia multivaluada en las relaciones. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia.
  5. Quinta Forma Normal: Rizando el rizo, vendría a decir que sólo se podrían realizar relaciones entre tablas utilizando claves candidatas, con la idea de reducir la redundancia de datos entre múltiples tablas.

A la hora de normalizar bases de datos hay una frase en inglés que lo resume todo: «The key, the whole key, and nothing but the key.» En la propia web de Microsoft la primera recomendación que dan para mejorar el rendimiento de SQL-Server y tener un diseño eficiente de la base de datos es usar un índice autonumérico como clave primaria de cada tabla, identificando así de forma unívoca cada registro y facilitando la relación entre ellos.

PostgreSQL: Obtener todas las fechas que existen entre dos fechas dadas

El otro día veíamos cómo crear en SQL-Server una tabla con todas las fechas entre dos fechas dadas. Hoy vamos a ver cómo hacer un simple select valiéndonos de la función generate_series() para obtener todas las fechas comprendidas entre dos fechas dadas con PostgreSQL

select i::date from generate_series('2017-06-01', 
  '2017-07-31', '1 day'::interval) i

Abrir SQL-Server Management Studio desde el intérprete de comandos

¿Cómo abro el Management Studio de SQL-Server desde el terminal de comandos? Pues si es el de SQL-Server 2005 ejecutando sqlwb.exe

sqlwb.exe

Acepta varios parámetros:

  • -S: La instancia a la que nos conectamos
  • -d: La base de datos a la que nos conectamos
  • -E: Usar autenticación de Windows
  • -U: Usuario de SQL-Server
  • -P: Contraseña del usuario
  • [file_name[, file_name]]: Ficheros a cargar

Para SQL-Server 2008 o SQL-Server 2012 se usa SSMS.exe

SSMS.exe

La lista de parámetros que acepta es la misma que en el 2005, podéis verla arriba.

SQL-Server: Crear una tabla auxiliar con Fechas comprendidas entre dos fechas dadas

A veces necesitamos una tabla calendario. De hecho muchas veces la necesitamos. ¿Cómo podemos crear una tabla ad-hoc con todas las fechas comprendidas entre dos fechas dadas en SQL-Server? Pues de la siguiente forma:

DECLARE @FechaInicio date
DECLARE @FechaFin date

--En este punto le doy valor a las fechas

Select @FechaInicio = '01/01/2017'
Select @FechaFin = '01/07/2017'

--Aquí creamos la variable tabla con los valores
DECLARE @dim TABLE ([Fecha] DATE)

	INSERT @dim([Fecha])
	SELECT d
	FROM
	(
	  SELECT
		  d = DATEADD(DAY, rn - 1, @FechaInicio)
	  FROM 
	  (
		  SELECT TOP (DATEDIFF(DAY, @FechaInicio, @FechaFin)) 
			  rn = ROW_NUMBER() OVER (ORDER BY s1.[object_id])
		  FROM
			  sys.all_objects AS s1
		  CROSS JOIN
			  sys.all_objects AS s2
		  ORDER BY
			  s1.[object_id]
	  ) AS x
	) AS y;

--Aquí hacemos un select sobre dim para ver el resultado
Select Fecha from @dim

SQL Server: Obtener la primera o la última palabra de una cadena.

El caso: tenemos una cadena de caracteres en SQL-Server (2008 R2 para más señas), donde las palabras están separadas por un caracter concreto. ¿Cómo obtenemos la primera palabra mediante una consulta? ¿Y la última?

La primera es fácil, sólo tenemos que hacer un SUBSTRING() que llegue hasta la primera aparición del caracter separador, que en este caso es un espacio:

DECLARE @test NVARCHAR(255)
SET @test = 'Esto es una frase'
Select SUBSTRING(@test, 1, CHARINDEX(' ', @test, 1) - 1)

¿Y la última? La cosa se torna compleja en SQL-Server 2008 (no se si en versiones posteriores es más sencillo). Y es que tenemos CHARINDEX(), que nos localiza la primera aparición del caracter empezando a contar desde una posición fija, pero no algo similar a LASTINDEX que nos diga la última posición. Entonces ¿cómo vamos a sacar esta última palabra? Pues sirviéndonos de la función REVERSE() para poder encontrar la última aparición del espacio a base de darle la vuelta a la cadena:

DECLARE @test NVARCHAR(255)
SET @test = 'Esto es una frase'
SELECT REVERSE(LEFT(REVERSE(@test), CHARINDEX(' ', REVERSE(@test))-1 ))

PostgreSQL: Consulta para saber en qué tabla está una columna

Lo hicimos en Oracle, en SQL-Server y en MySQL. No podíamos dejarnos PostgreSQL ¿cómo podemos saber en qué tabla está una columna sabiendo sólo el nombre de dicha columna?

Pues con una consulta sobre la vista columns, que contiene información sobre las columnas de todas las tablas y vistas. Veamos cómo sabríamos en qué tabla está la columna «NombrePaciente» (por poner un ejemplo práctico):

Select table_name
from columns
where column_name like 'NombrePaciente'

En vuestro caso cambiáis NombrePaciente por el nombre de columna que corresponda.

MySQL y MariaDB: Consulta para saber en qué tabla está una columna

El otro día lo vimos en SQL-Server, ayer en Oracle, vamos hoy con MySQL y su fork MariaDB, seguramente los gestores de bases de datos SQL libres más populares de la actualidad ¿Cómo puedo saber a qué tabla pertenece una columna sabiendo sólo el nombre de columna? Como en los casos anteriores, basta una consulta:

SELECT DISTINCT TABLE_NAME
    FROM INFORMATION_SCHEMA.COLUMNS
    WHERE COLUMN_NAME = 'Nombre_Columna'
        AND TABLE_SCHEMA='Nombre_BaseDatos';

Ya sabéis, os toca cambiar el nombre de columna y el nombre del esquema por los que correspondan en vuestro caso.

SQL-Server: Consulta para saber en qué tabla está una columna

Vamos con un tip rápido de SQL-Server, y seguramente útil en muchas ocasiones. Me acaba de pasar que ejecutaba un script para pasar datos de una base de datos vieja a una nueva (donde las tablas tienen algunas diferencias, al ser un versión posterior de la aplicación) y me devolvía como error que el tipo de datos no era válido para la columna Envases. Y me asalta la duda y la necesidad ¿en qué tabla está esa columna? Pues podemos saberlo con una consulta:

SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME = 'Envases'
ORDER BY DATA_TYPE

En vuestro caso debéis cambiar Envases por el nombre de columna que corresponda. Próximamente lo veremos en Oracle.

MySQL: Calcular una edad a partir de una fecha.

En fin, seguimos con el cálculo de edades a partir de fechas en diferentes SGBD. Ya hablamos de SQL-Server y de PostgreSQL, vamos ahora a ver cómo iría la cosa en MySQL/MariaDB.

Vamos a asumir que los datos están bien guardados, en una columna del tipo DATETIME. Como en el caso de Postgres, en MySQL dispones de una función que nos ayudará a hacer esto directamente, llamada TIMESTAMPDIFF(). Esta función recibe como argumentos la unidad de tiempo en la que queremos recibir la respuesta y las dos fechas entre las que queremos obtener la diferencia. Veamos el ejemplo para obtener la edad de alguien con esta función, sirviéndonos de una tabla de ejemplo llamada clientes que contendrá una columna FechaNac con la fecha de nacimiento de los mismos:

SELECT TIMESTAMPDIFF(YEAR,FechaNac,CURDATE()) AS edad
     FROM clientes;