Data Definition Language (SQL DDL)

DDL (Data Definition Language) se refiere al grupo de instrucciones SQL dedicadas a crear, modi-
ficar y eliminar objetos de la base de datos. Mayormente estos objetos serán tablas.
Hay 2 tipos de tablas: las permanentes y las temporarias.

TABLAS TEMPORARIAS TABLAS PERMANENTES

Las temporarias solamente existen durante la Las permanentes son utilizadas
sesión de un usuario que se conectó con la ba- para largo plazo, nunca serán eli-
se de datos. Si estas tablas no son eliminadas minadas a menos que el usuario
explícitamente durante la sesión, las mismas ejecute las instrucciones SQL
serán eliminadas una vez finalizada la misma. pertinentes.

CREATE TABLE

La sentencia para crear una tabla es CREATE TABLE:

CREATE TABLE < nombre_tabla > (<lista de especificación de columnas y restricciones>);

Una especificación de columna incluye el nombre de la columna y el tipo de dato válido para la
columna. De forma adicional, ciertas restricciones (constraints) pueden definirse no sólo de forma
adicional mediante especificaciones extras, sino que en la definición de la columna en cuestión.

El ejemplo de esto son columnas que se definen como claves primarias y claves forá-
neas (primary y foreign key respectivamente).

Otro ejemplo son las columnas NOT NULL, es decir que siempre deben contener algún valor al-
macenado.

La tabla de productos de la base de datos de la firma Computadora, consiste en 3 columnas -Fa-

bricante, Modelo y Tipo-; todas de ellas serán de tipo string VARCHAR(N). Para crear esta tabla,
ejecutaremos la siguiente sentencia:

CREATE TABLE Producto (Fabricante varchar(10), Modelo varchar(50), Tipo varchar(50));

N es el máximo número de caracteres en la columna correspondiente que se puede almacenar.

VARCHAR es un largo variable, esto quiere decir, que si almacenamos un valor con menos de N
caracteres, ese largo será definido de forma dinámica para ese registro. En cambio si fuera de lar-
go fijo (CHAR) y almacenamos valores con largo menor que N, el valor será complementado con
espacios hacia la derecha, hasta llegar al largo N.

Si el largo N no es especificado, se asume el valor 1 (caracter único).

Apenas la tabla haya sido creado, podremos escribir datos utilizando la sentencia INSERT:

INSERT INTO Producto VALUES

('A', '1232', 'PC'),
('A', '1232', 'Printer'),
(NULL, NULL, NULL)

La data será escrita con éxito, pero parece no ser correcta. Primero, no está claro si el modelo
1232 es una impresora o una computadora. Luego, tenemos un modelo del cuál no sabemos nada
al respecto (el registro con 3 valores en NULL).

Acá debemos enfatizar que al crear tablas, establecemos un modelo relacional del área en estu-
dio. En este caso el área en estudio es la del manejo de stock para una compañía de computado-
ras. Para asegurarnos que el modelo es el adecuado para el área en estudio, las tablas deben es-
tar definidas de tal forma que los objetos en el mundo real, puedan ser simulados en el modelo,
mientras que las cosas que no son posibles que sucedan en el área de estudio, no deberían poder
pasar en el modelo relacional definido.

Por lo tanto en la realidad, un modelo no puede ser una impresora y una computadora al mismo
tiempo, cómo sucedió en nuestro modelo. Para encarar estas situaciones que no suceden en el
mundo real, debemos poder reflejarlas en el modelo relacional, es para esto que veremos el con-
cepto de integridad de datos a partir del uso de restricciones (constraints).

2.1.3. Integridad de entidades

Integridad de entidades

Integridad de entidades significa que cada objeto representado en una columna en la tabla, debe-
ría ser distinguido de cualquier otro objeto. En otras palabras, debería haber un conjunto de atribu-
tos de forma tal que su combinación, identificará un único objeto. Ese conjunto de atributos que
hace identificar a un único objeto, es candidato a ser llamado clave.

Para forjar una integridad de entidades, SQL te permite definir una clave primaria (PRIMARY KEY)
y especificación de unicidad (UNIQUE).

En nuestro caso qué nos puede servir cómo clave primaria?, dado que nuestro Fabricante puede
producir varios modelos y aparecer en la tabla Producto varias veces, la columna Fabricante no es
la adecuada para ser clave primaria. De forma similar, la columna Tipo tampoco necesariamente
deberá ser único.

El único atributo que no tendrá un duplicado, es el código del modelo, y este será nuestro candida-
to a ser clave primaria. No hay ningún otro candidatos a ser clave primaria en la tabla. Para probar
eso, podemos suponer cualquier otra combinación de columnas, y demostrar que no aseguran la
identificación única del objeto. En particular, el valor de la combinación de las 3 columnas en el
ejemplo visto, es único, aún así falla a la hora de identificar el modelo 1232.

Creemos entonces una clave primaria. SQL permite cambiar la estructura de una tabla existente,
haciendo uso de la sentencia ALTER TABLE. Sin embargo, para mantener las cosas simples por
ahora, simplemente re-crearemos la tabla, es decir que la eliminaremos (con la sentencia DROP)
y volveremos a crear agregando la restricción de clave primaria.

DROP TABLE Producto;

CREATE TABLE Producto (
Fabricante varchar(10),
Modelo varchar(50) PRIMARY KEY,
Tipo varchar(50)
);

Hemos incluido la especificación de la clave primaria en la definición de una columna. Sin embar-
go, podemos lograr el mismo efecto creando una restricción por separado:

CONSTRAINT PRIMARY KEY ()

Finalmente entonces, tendremos las siguientes sentencias:

DROP TABLE Producto;

CREATE TABLE Producto (
Fabricante varchar(10),
Modelo varchar(50),
Tipo varchar(50),
CONSTRAINT product_PK PRIMARY KEY (Modelo)
);
Ahora, nuestro gestor de base de datos (SQL Server por ejemplo) se asegurará que la clave pri-
maria no tenga duplicado alguno cuando escribamos en la table. Entonces si volvemos a intentar
ejecutar la sentencia ejecutada al inicio:

INSERT INTO Producto VALUES

('A', '1232', 'PC'),
('A', '1232', 'Printer'),
(NULL, NULL, NULL);

En este caso, el gestor de base de datos nos lanzará el siguiente error (o similar según el gestor):

Violation of PRIMARY KEY constraint 'product_PK'. Cannot insert duplicate key in object 'Product'.
The duplicate key value is (1232).

Si ahora corregimos ese error, ingresando un modelo distinto:

INSERT INTO Producto VALUES

('A', '1232', 'PC'),
('A', '3001', 'Printer'),
(NULL, NULL, NULL);

Obtendremos otro error, debido a que la clave primaria no puede ser NULL:

Cannot insert the value NULL into column 'model', table 'Product'; column does not allow nulls. IN-
SERT fails.

Finalmente si ejecutamos:

INSERT INTO Producto VALUES

('A', '1232', 'PC'),
('A', '3001', 'Printer'),
(NULL, '2000', NULL);

Se ejecutará con éxito.

2.1.4. Modificación de tablas: Sentencia ALTER

Sentencia ALTER TABLE

Los siguientes niveles para restricciones se pueden diferenciar entre:

Atributos: a nivel de columnas.
Tupla: a nivel de filas.
Relación: a nivel de columnas.

Una restricción a nivel de atributo (columna) se aplica a una única columna. Por ejemplo, volvien-
do al ejemplo de la base de datos de computadores, la columna Tipo de la tabla Producto, puede
contener uno de 3 valores. Podemos restringir con la siguiente sentencia:

CHECK (Tipo IN('Impresora', 'PC', 'Laptop'))

Asumiendo que ya tenemos creada la base de datos y la tabla Producto, para aplicar un cambio a
la tabla que deseemos, debemos hacer uso de la sentencia ALTER TABLE.

La sentencia ALTER TABLE permite agregar/quitar columnas, valores por defectos y restriccio-
nes.
Estamos interesados en aplicar restricción a la columna Tipo; por eso examinemos la sintaxis:
ALTER TABLE ADD CONSTRAINT ;

Aplicando la sintaxis para modificar la tabla agregando la restricción mencionada:

ALTER TABLE Producto

ADD CONSTRAINT chk_type CHECK (Tipo IN('PC', 'Laptop', 'Impresora'));

Para asegurarnos que la restricción se encuentra activa, probemos escribir un registro con un mo-
delo que no se encuentra en la restricción:

INSERT INTO Producto VALUES ('A', 1122, 'Notebook');

Deberíamos recibir un mensajes cómo este:

The INSERT statement conflicted with the CHECK constraint "chk_type". The conflict occurred in
database "learn", table "dbo.product", column 'type'. The statement has been terminated.

2.1.5. Integridad referencial: Clave Foránea (FK)

Una clave foránea (foreign key) en una base de datos relacional es una clave que se usa en una
tabla secundaria y que coincide con la clave primaria en una tabla primaria relacionada.

Las claves foráneas pueden tener valores duplicados (multiplicidad) en la tabla secundaria, mien-
tras que para las claves primarias eso no es posible. El uso apropiado de claves foráneas permite
exigir la integridad referencial.

La regla de la integridad referencial establece que cualquier valor de clave foránea no nulo en una
tabla secundaria debe hacer referencia a un valor de clave primaria de su tabla primaria en la base
de datos. En el ejemplo del Paso 1 no tendría sentido en la base de datos tener un estudiante ma-
triculado en un curso cuando no haya información acerca del estudiante en la tabla "Student". Esta
regla hace cumplir la consistencia en una base de datos.

Las claves foráneas se agregan a partir de la modificación de la tabla con la sentencia ALTER:
FOREIGN KEY (REFERENCES TABLE> ()

Por ejemplo
ALTER TABLE PC
ADD CONSTRAINT fk_pc_product
FOREIGN KEY(Modelo) REFERENCES Producto(Modelo);

Aquí estaremos haciendo referencia entre la columna Modelo de la tabla PC, con la columna Mo-
delo de la tabla Producto. El nombre de la clave foránea es fk_pc_product.

La idea de la tabla PC, es que contenga todos los productos de tipo PC, donde su identificación
del modelo (columna Modelo) hará referencia al valor que se encuentra en la columna Modelo de
la tabla Producto. De esta forma es que se forma la relación. De misma forma se podría hacer
creando las tablas Impresora y Laptop, donde también se deberán crear las claves foráneas refe-
renciando también a la columna Modelo de la tabla Producto.