Data Definition Language (SQL DDL

Data Definition Language (SQL DDL)
DDL (Data Definition Language) se refiere al grupo de instrucciones SQL dedicadas a crear,
modificar 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 para largo plazo, nunca serán
base de datos. Si estas tablas no son eliminadas a menos que el
eliminadas explícitamente durante la sesión, usuario ejecute las instrucciones
las mismas serán eliminadas una vez SQL pertinentes.
finalizada la misma.
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
almacenado.
La tabla de productos de la base de datos de la firma Computadora, consiste en 3 columnas

-Fabricante, 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
largo 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
estudio. En este caso el área en estudio es la del manejo de stock para una compañía de
computadoras. Para asegurarnos que el modelo es el adecuado para el área en estudio, las tablas
deben estar 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
concepto 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,
debería ser distinguido de cualquier otro objeto. En otras palabras, debería haber un conjunto de
atributos 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
candidato 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

embargo, 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
primaria no tenga duplicado alguno cuando escribamos en la table. Entonces si volvemos a
intentar ejecutar la sentencia ejecutada al inicio:

('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:

('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.
INSERT fails.
Finalmente si ejecutamos:

('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,
volviendo 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

restricciones.
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
modelo 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,
mientras 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 matriculado 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
Modelo 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
referenciando también a la columna Modelo de la tabla Producto.

Data Definition Language (SQL DDL

Cargado por

Copyright:

Formatos disponibles

Data Definition Language (SQL DDL

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Data Definition Language (SQL DDL

Cargado por

Copyright:

Formatos disponibles

Data Definition Language (SQL DDL)

TABLAS TEMPORARIAS TABLAS PERMANENTES

La sentencia para crear una tabla es CREATE TABLE:

Una especificación de columna incluye el nombre de la columna y el tipo de dato válido para la

El ejemplo de esto son columnas que se definen como claves primarias y claves

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

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.

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

INSERT INTO Producto VALUES

2.1.3. Integridad de entidades

DROP TABLE Producto;

Hemos incluido la especificación de la clave primaria en la definición de una columna. Sin

CONSTRAINT PRIMARY KEY ()

Finalmente entonces, tendremos las siguientes sentencias:

DROP TABLE Producto;

INSERT INTO Producto VALUES

Si ahora corregimos ese error, ingresando un modelo distinto:

INSERT INTO Producto VALUES

INSERT INTO Producto VALUES

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:

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

La sentencia ALTER TABLE permite agregar/quitar columnas, valores por defectos y

ALTER TABLE ADD CONSTRAINT ;

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

ALTER TABLE Producto

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

Deberíamos recibir un mensajes cómo este:

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

También podría gustarte