Unidad II.

Lenguaje de Definición de Datos (DDL)

Objetivo: Crea una base de datos, y define su esquema en SQL.

2.1. Creación del esquema de la base de datos

El esquema de una base de datos (en inglés, Database Schema) describe la

estructura de una Base de datos, en un lenguaje formal soportado por un Sistema
administrador de Base de datos (DBMS). En una Base de datos Relacional, el
Esquema define sus tablas, sus campos en cada tabla y las relaciones entre cada
campo y cada tabla.

El esquema es generalmente almacenado en un Diccionario de Datos. Aunque

generalmente el esquema es definido en un lenguaje de Base de datos, el término
se usa a menudo para referirse a una representación gráfica de la estructura de
base de datos (Diseño de lógico de la base de datos).

Generalmente en la práctica el término esquema de la base de datos se refiere al

diseño físico de la base de datos.

Oracle generalmente asocia un 'username' como esquemas en este caso

SYSTEM y HR (Recursos humanos).

Por otro lado MySQL presenta dos esquemas information_schema y MySQL

ambos guardan información sobre privilegios y procedimientos del gestor y no
deben ser eliminados.

Sintaxis básica para crear una base de datos en Oracle (No aplica en Oracle
express)
CREATE DATABASE nombre_baseDatos

Sintaxis básica para crear una base de datos en MySQL

CREATE DATABASE IF NOT EXISTS nombre_baseDatos;

Para conocer las bases de datos creadas use

SHOW DATABASES;

2.2. Actualización, modificación y eliminación del esquema de

base de datos

Oracle

Una tabla es un sistema de elementos de datos (atributo - valores) que se

organizan que usando un modelo vertical - columnas (que son identificados por su
nombre)- y horizontal filas. Una tabla tiene un número específico de columnas,
pero puede tener cualquier número de filas. Cada fila es identificada por los
valores que aparecen en un subconjunto particular de la columna que se ha
identificado por una llave primaria.

Una tabla de una base de datos es similar en apariencia a una hoja de cálculo, en
cuanto a que los datos se almacenan en filas y columnas. Como consecuencia,
normalmente es bastante fácil importar una hoja de cálculo en una tabla de una
base de datos. La principal diferencia entre almacenar los datos en una hoja de
cálculo y hacerlo en una base de datos es la forma de organizarse los datos.
Por lo tanto, la creación de las tablas en el proceso de programación en Oracle
juegan un papel muy importante. En el momento de crear las tablas se definen
características a dos niveles: Tabla y Columna, como se muestra a continuación:

A nivel de tabla: Refieren a una o a varias columnas, donde cada columna se

define individualmente.

Nombre de la tabla puede ser de 1 a 30 caracteres. La tabla tiene

como propietario al usuario que las crea. Por ejemplo: EQUIPO.
Hay que tener en cuenta también ciertas restricciones con los
nombres de las tablas: longitud máxima de 30 caracteres, no
Nombre:
puede haber nombres de tabla duplicados, deben comenzar con
un carácter alfabético, permitir caracteres alfanuméricos y el
guión bajo '_', y Oracle no distingue entre mayúsculas y
minúsculas.

La tabla tiene como propietario al usuario que las crea En nuestro

caso somos el usuario ALUMNO. Otro usuario que desee usar
Propietario:
nuestras tablas debe tener autorización para ello y hacer
referencia a la tabla como ALUMNO.EQUIPO (propietario.tabla)

Cantidad de
Una tabla puede tener un máximo de 254 columnas.
Columnas:

A nivel de Columna el nombre de la columna puede tener un máximo de 30

caracteres.

En Oracle podemos implementar diversos tipos de tablas. A continuación se

presenta una recopilación no exhaustiva de ellas.

Tipo Tabla Descripción

Son el mecanismo de almacenamiento de los datos en una base
de datos Oracle. Contienen un conjunto fijo de columnas. Las
Regular columnas de una tabla describen los atributos de la entidad que
(heap) se representa con la tabla. Cada columna tiene un nombre y
características específicas: tipo de dato y longitud, restricciones,
etc.

Un cluster proporciona un método opcional de almacenar datos

Clustered de tabla. Un cluster está compuesto de un grupo de tablas que
comparten los mismos bloques de datos. Las tablas son
 Tipo Tabla Descripción
agrupadas mediante columnas comunes.

Aquí una tabla es almacenada en la estructura de un índice.

Esto impone orden físico a las filas por si mismas. A diferencia
Index de un heap, donde los datos son almacenados en donde caben,
en una tabla IOT (Tabla Organizada por Índices) los datos son
almacenados en el orden de la clave primaria.

Es un esquema de organización de los datos con el cual

podemos dividirla en múltiples objetos de almacenamientos
llamados particiones de datos o rangos, dependiendo los
Particionadas valores puede ser dividido en uno o más columnas de la tabla.
Cada particiones de datos es almacenado separadamente.
Estos objetos almacenados pueden estar en diferentes
tablespaces, en el mismo o en una combinación de ambos.

Son tablas cuyos datos permanecerán en el sistema sólo

durante el tiempo que dure la transacción o sesión involucrada.
Temporales No obstante, al igual que para las tablas permanentes, la
definición de las tablas temporales se almacena en las tablas
del sistema.

La sintaxis del comando que permite crear un tabla es la siguiente:

Del examen de la sintaxis de la sentencia Create Table se pueden concluir que

necesitamos conocer los distintos tipos de columna y las distintas restricciones
que se pueden imponer al contenido de las columnas.

Existen varios tipos de datos en SQL. De esta manera, cada columna puede
albergar una información de naturaleza distinta. Los tipos de datos más comunes y
sus características en Oracle Express (10 Y 11g) se resumen en la siguiente tabla.
Las versiones de Oracle comercial soportan una gama mucho más amplia de tipos
de datos.
 Tipo de Dato Descripción
Contiene datos binarios con un tamaño máximo de 4
gigabytes. Los datos binarios nos van a permitir guardar
en la base de datos archivos, imágenes, sonidos, etc ...
BLOB Casi siempre es preferible guardar la ruta del archivo en
la base de datos en lugar del propio archivo en modo
binario, pero existen ciertas circunstancias en las que no
nos queda otra solución.

BINARY_DOUBLE Precisión doble

BINARY_FLOAT Precisión simple

Un tipo de datos CLOB de Oracle contiene datos de

caracteres basados en el juego de caracteres
predeterminados del servidor. Su tamaño máximo es de
4 gigabytes. Se asigna a cadena.

CLOB Use la siguiente expresión para una consulta de un

campo CLOB

SELECT DBMS_LOB.substr(campo,
DBMS_LOB.getlength(campo), 1)
FROM tablaprueba;
Almacena datos de tipo carácter alfanumérico de longitud
CHAR
fija, con un tamaño máximo de 2000. caracteres

Almacena fechas desde el 1-Ene-4712 AC hasta el 31-

DATE
Dic-4712 DC.

Datos numéricos de n dígitos, de los cuales dec son

NUMBER(dig [, dec])
decimales. El tamaño máximo es de 38 dígitos.

Almacena un valor alfanumérico de longitud variable en

NVARCHAR2 caracteres Unicode con las mismas restricciones de
varchar.

Fecha y hora (incluidos los segundos), con un tamaño

TIMESTAMP
que abarca desde 7 a 11 bytes.

Guarda datos de tipo carácter alfanumérico de longitud

VARCHAR2(tamaño)
variable, con un tamaño máximo de 4,000 caracteres.
Ejemplo: Considere la siguiente tabla de datos correspondientes a los campeones
de Formula 1 (1950 - 2012) y sus escuderías. Y su traducción a sentencias Oracle.

Año Campeón Escudería

2012 - -

2011 Sebastian Vettel Red Bull Racing

2010 Sebastian Vettel Red Bull Racing

2009 Jenson Button Brawn GP

2008 Lewis Hamilton McLaren

2007 Kimi Raikkonen Ferrari

2006 Fernando Alonso Renault

2005 Fernando Alonso Renault

2004 Michael Schumacher Ferrari

2003 Michael Schumacher Ferrari

2002 Michael Schumacher Ferrari

2001 Michael Schumacher Ferrari

2000 Michael Schumacher Ferrari

CREATE TABLE f1 (
year INTEGER PRIMARY KEY,
campeon CHAR(30),
escuderia CHAR(20)
);

Ejemplo: Estados, capitales, densidad de población y superficie de la Republica

Mexicana

CREATE TABLE estados (

idEstado INTEGER PRIMARY KEY,
nombreEstado CHAR(25) NOT NULL,
capital CHAR(25) NOT NULL,
densidad INTEGER NOT NULL,
poblacion INTEGER NOT NULL
);
Tablas Temporales

Oracle permite la creación de tablas temporales para mantener datos propios y

exclusivos a una sesión Oracle determinada. Estos datos permanecerán en el
sistema sólo durante el tiempo que dure la transacción o sesión involucrada. No
obstante, al igual que para las tablas permanentes, la definición de las tablas
temporales se almacena en las tablas del sistema.

La siguiente sintaxis permite crear una tabla temporal personal para cada sesión.
Eso significa que los datos no se comparten entre sesiones y se eliminan al final
de la misma.

CREATE GLOBAL TEMPORARY TABLE [ schema. ]table (

nombreColumna tipoDato [DEFAULT expresión] [NOT NULL],
[,nombre_columna tipo_dato [DEFAULT expresión]
[restricción_columna] ...
|restricción_tabla];
ON COMMIT { DELETE | PRESERVE } ROWS ]
[ physical_properties ]

Con la opción ON COMMIT DELETE ROWS se borran los datos cada vez que se
hace COMMIT en la sesión.
Con la opción ON PRESERVE DELETE ROWS los datos no se borran hasta el
final de la sesión.

Sus ventajas son varias, la información contenida en ella esta solo disponible para
la sesión actual, cualquier inserción, borrado, actualización solo se refleja en la
sesión activa.

Muchas funcionalidades de cualquier tabla normal se mantienen en ella, como

triggers a nivel tabla, vistas, índices, exportar e importar (claro solo la definición de
la tabla).

No es posible declarar llaves foráneas en una tabla temporal.

(DROP) Eliminación

Cuando una tabla ya no es útil y no vamos a volver a necesitarla debe ser borrada.
Esta operación se puede realizar con el comando DROPTABLE.

DROP TABLE nombre_tabla [CASCADE CONSTRAINTS][PURGE]

Se borra la tabla de la base de datos, borrando toda la información contenida en la

tabla, es decir, todas las filas. También se borrará toda la información que sobre la
tabla existiera en el diccionario.

Si alguna columna de la tabla a borrar sirve como clave ajena de alguna tabla
detalle, impide la eliminación de la tabla, ya que existe una restricción que requiere
de la existencia de la tabla maestra. Esto se puede arreglar colocando la sentencia
CASCADE CONSTRAINTS.

Esto produce que las restricciones de la tabla detalle se borren antes de borrar la
tabla maestra. PURGE evita que los objetos borrados se vayan a la papelera

La siguiente sentencia produce la eliminación de la tabla BORRAME.

Modificación

Oracle permite modificar las restricciones definidas para una tabla. Esto puede
llevar a “inconsistencia” de los datos ya introducidos en la base de datos. Por
ello, Oracle tiene definidos mecanismos para modificación de los datos ya
existentes.

Esta operación se puede realizar con el comando ALTER TABLE.

ALTER TABLE [esquema.]tabla

clausula_constraint [,…]
[ENABLE clausula_activa | DISABLE clausula_disable]
[{ENABLE|DISABLE} TABLE LOCK]
[{ENABLE|DISABLE} ALL TRIGGERS];

Hay que tener en cuenta varios puntos:

 No es posible disminuir el tamaño de una columna, si esta contiene

datos.

 En las modificaciones, los tipos anterior y nuevo deben ser compatibles,

o la tabla debe estar vacía.

 La opción ADD ... NOT NULL sólo será posible si la tabla está vacía.

 La opción MODIFY ... NOT NULL sólo podrá realizarse cuando la tabla
no contenga ninguna fila con valor nulo en la columna en cuestión.

Considere el ejemplo Propietario - Automóvil, bajo el criterio de hacienda del

Gobierno del Estado de Veracruz, México. Modificaremos el ejemplo para añadir el
atributo color.
ALTER TABLE automovil
ADD(color CHAR(15) NOT NULL);

ARCHIVO CREATE TABLE AUTOMOVIL

Es factible modificar una tabla añadiendo o eliminando restricciones, en este caso

para el ejemplo anterior el comando a utilizar será

ALTER TABLE tabla {ADD | DROP} CONSTRAINT restricción;

ALTER TABLE automovil DROP CONSTRAINT FK_Propietario;

ALTER TABLE automovil ADD
CONSTRAINT FK_Propietario FOREIGN KEY (idPropietario)
REFERENCES propietario (idPropietario)
ON DELETE CASCADE;

El cual permitira el borrado en cascada.

MySQL

MySQL soporta varios motores de almacenamiento que tratan con distintos tipos
de tabla. Los motores de almacenamiento de MySQL incluyen algunos que tratan
con tablas transaccionales y otros que no lo hacen:
 MyISAM trata tablas no transaccionales. Proporciona almacenamiento y
recuperación de datos rápida, así como posibilidad de búsquedas
fulltext.MyISAM se soporta en todas las configuraciones MySQL, y es el
motor de almacenamiento por defecto a no ser que tenga una configuración distinta
a la que viene por defecto con MySQL.
El motor de almacenamiento MEMORY proporciona tablas en memoria. El motor
de almacenamiento MERGE permite una colección de tablas MyISAM idénticas
ser tratadas como una simple tabla. Como MyISAM, los motores de
almacenamiento MEMORY y MERGE tratan tablas no transaccionales y ambos se
incluyen en MySQL por defecto.
Nota: El motor de almacenamiento MEMORY anteriormente se conocía como
HEAP.
 Los motores de almacenamiento InnoDB y BDB proporcionan tablas
transaccionales. BDB se incluye en la distribución binaria MySQL-Max en aquellos
sistemas operativos que la soportan. InnoDB también se incluye por defecto en
todas las distribuciones binarias de MySQL 5.0 . En distribuciones fuente, puede
activar o desactivar estos motores de almacenamiento configurando MySQL a su
gusto.
 El motor de almacenamiento EXAMPLE es un motor de almacenamiento 'tonto'
que no hace nada. Puede crear tablas con este motor, pero no puede almacenar
datos ni recuperarlos. El objetivo es que sirva como ejemplo en el código MySQL
para ilustrar cómo escribir un motor de almacenamiento. Como tal, su interés
primario es para desarrolladores.
 NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para
implementar tablas que se particionan en varias máquinas. Está disponible en
distribuciones binarias MySQL-Max 5.0. Este motor de almacenamiento está
disponible para linux, Solaris, y Mac OS X. Los autores mencionan que se añadirá
soporte para este motor de almacenamiento en otras plataformas, incluyendo
Windows en próximas versiones.
 El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades
de datos sin índices con una huella muy pequeña.
 El motor de almacenamiento CSV guarda datos en archivos de texto usando
formato de valores separados por comas.
 El motor de almacenamiento FEDERATED se añadió en MySQL 5.0.3. Este motor
guarda datos en una base de datos remota. En esta versión sólo funciona con
MySQL a través de la API MySQL C Client. En futuras versiones, será capaz de
conectar con otras fuentes de datos usando otros drivers o métodos de conexión
clientes.
La versión 5 de MySQL crea por defecto tablas innoDB que permiten el manejo
de integridad referencial, transacciones. Al igual que las tablas regulares de
oracle. Para saber si el gestor de base de datos de MySQL que tenemos las
soporta es necesario ejecutar la siguiente sentencia.

SHOW VARIABLES liKE '%innodb%';

Si nuestro gestor soporta por defecto las tablas innodb las sentencias para crear
las tablas previamente mostradas serán exactamente igual a las de oracle. En
caso contrario se muestra la sintaxis correspondiente

CREATE TABLE f1 (
year INTEGER PRIMARY KEY,
campeon CHAR(30),
escuderia CHAR(20)
) ENGINE = InnoDB;

Ejemplo: Estados, capitales, densidad de población y superficie de la Republica

Mexicana

CREATE TABLE estados (

idEstado INTEGER PRIMARY KEY,
nombreEstado CHAR(25) NOT NULL,
capital CHAR(25) NOT NULL,
densidad INTEGER NOT NULL,
poblacion INTEGER NOT NULL
) ENGINE = InnoDB;

Comando Describe

MySQL proporciona este comando que resulta útil para conocer la estructura de
una tabla, las columnas que la forman y su tipo y restricciones. La sintaxis es la
siguiente DESCRIBE nombreTabla.

DESCRIBE estados;

Comando SHOW TABLES y SHOW CREATE TABLE

 El comando SHOW TABLES muestra las tablas dentro de una base de datos y
SHOW CREATE TABLES muestra la estructura de creación de la tabla.

Tablas temporales

Las tablas temporales solo existen mientras la sesión está viva . Si se

corre este código en un script de PHP ( Cualquier otro lenguaje), la tabla temporal
se destruirá automáticamente al termino de la ejecución de la página. Si no
específica MEMORY, la tabla se guardará por defecto en el disco.

CREATE TEMPORARY TABLE temporal (

ife INTEGER(13) PRIMARY KEY,
nombre CHAR(30) NOT NULL UNIQUE
);

 Este tipo de tabla solo puede ser usada por el usuario que la crea.
 Si creamos una tabla que tiene el mismo nombre que una existente en la base de
datos, la que existe quedará oculta y trabajaremos sobre la temporal.

Tablas Memory ( Head )

 Se almacenan en memoria
 Una tabla head no puede tener más de 1600 campos
 Las tablas MEMORY usan una longitud de registro fija.
 MEMORY no soporta columnas BLOB o TEXT.
 MEMORY en MySQL 5.0 incluye soporte para columnas AUTO_INCREMENT e
índices en columnas que contengan valores NULL.
 Las tablas MEMORY se comparten entre todos los clientes (como cualquier otra
tabla no-TEMPORARY).

CREATE TEMPORARY TABLE temporal (

ife INTEGER(13) PRIMARY KEY,
nombre CHAR(30) NOT NULL UNIQUE
) ENGINE = MEMORY;
Modificación

Esta operación se puede realizar con el comando ALTER TABLE. Para usar
ALTER TABLE, necesita permisos ALTER, INSERT y CREATE para la tabla.
La sintaxis para MySQL es:

ALTER [IGNORE] TABLE tbl_name

alter_specification [, alter_specification] ...;

alter_specification:
ADD [COLUMN] column_definition [FIRST | AFTER col_name
]
| ADD [COLUMN] (column_definition,...)
| ADD INDEX [index_name] [index_type] (index_col_name,...)
| ADD [CONSTRAINT [symbol]]
PRIMARY KEY [index_type] (index_col_name,...)
| ADD [CONSTRAINT [symbol]]
UNIQUE [index_name] [index_type]
(index_col_name,...)
| ADD [FULLTEXT|SPATIAL] [index_name]
(index_col_name,...)
| ADD [CONSTRAINT [symbol]]
FOREIGN KEY [index_name] (index_col_name,...)
[reference_definition]
| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP
DEFAULT}
| CHANGE [COLUMN] old_col_name column_definition
[FIRST|AFTER col_name]
| MODIFY [COLUMN] column_definition [FIRST | AFTER
col_name]
| DROP [COLUMN] col_name
| DROP PRIMARY KEY
| DROP INDEX index_name
| DROP FOREIGN KEY fk_symbol
| DISABLE KEYS
| ENABLE KEYS
| RENAME [TO] new_tbl_name
| ORDER BY col_name
| CONVERT TO CHARACTER SET charset_name [COLLATE
collation_name]
| [DEFAULT] CHARACTER SET charset_name [COLLATE
collation_name]
| DISCARD TABLESPACE
| IMPORT TABLESPACE
 | table_options

Considere el ejemplo Propietario - Automóvil, bajo el criterio de hacienda del

Gobierno del Estado de Veracruz, México. Modificaremos el ejemplo para añadir el
atributo color según la sintaxis MySQL

ALTER TABLE automovil

ADD(color CHAR(15) NOT NULL);
CREATE TABLE propietario (
idPropietario INTEGER NOT NULL AUTO_INCREMENT,
nombre CHAR(35) NOT NULL,
direccion CHAR(50) NOT NULL,
colonia CHAR(40) NOT NULL,
localidad CHAR(25) NOT NULL,
rfc CHAR(14),
telefono CHAR(14),
CONSTRAINT PK_propietario PRIMARY KEY (idPropietario)
) ENGINE = InnoDB;

CREATE TABLE automovil (

idAutomovil INTEGER NOT NULL AUTO_INCREMENT,
idPropietario INTEGER,
placa CHAR(12) NOT NULL,
marca CHAR(18) NOT NULL,
cveVehicular INTEGER(3) NOT NULL,
linea CHAR(18) NOT NULL,
numeroSerie CHAR(25) NOT NULL,
subLinea CHAR(18) NOT NULL,
origen CHAR(20) NOT NULL,
clase CHAR(14) NOT NULL,
modelo CHAR(18) NOT NULL,
fechaAlta CHAR(18) NOT NULL,
 CONSTRAINT PK_Automovil PRIMARY KEY (idAutomovil),
CONSTRAINT FK_Propietario FOREIGN KEY (idPropietario)
REFERENCES propietario (idPropietario)
)ENGINE = InnoDB;

Ejemplo: Eliminar una llave foránea

ALTER TABLE automovil DROP FOREIGN KEY FK_Propietario;

Ejemplo: Agregar una llave foranea con borrado en cascada

ALTER TABLE automovil ADD

CONSTRAINT FK_Propietario
FOREIGN KEY (idPropietario)
REFERENCES propietario (idPropietario)
ON DELETE CASCADE;

Puede ejecutar múltiples cláusulas ADD, ALTER, DROP, y CHANGE en un único

comando ALTER TABLE. Esta es una extensión MySQL al estándar SQL, que
permite sólo una de cada cláusula por comando ALTER TABLE.

2.3. Integridad referencial

Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar
las reglas de integridad, es decir que los datos almacenados en dicha estructura
deben cumplir ciertas características para garantizar que son correctos. Al definir
cada atributo sobre un dominio se impone una restricción sobre el conjunto de
valores permitidos para cada atributo.

A este tipo de restricciones se les denomina restricciones de dominios. Hay

además dos reglas de integridad muy importantes que se deben cumplir en todas
las bases de datos relacionales y en todos sus estados o instancias (las reglas se
deben cumplir todo el tiempo). Estas reglas son la regla de integridad de
entidades y la regla de integridad referencial. Antes de definirlas, es preciso
conocer el concepto de nulo.
 Restricciones de dominios

Imponen una limitación al conjunto de valores permitidos para los atributos en las
relaciones. Permitiendo restringir los valores que puede tomar un atributo respecto
a su dominio, por ejemplo EDAD >= 18.

Nulos

Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no

representa el valor cero ni la cadena vacía, éstos son valores que tienen
significado. El nulo implica ausencia de información, bien porque al insertar la
tupla se desconocía el valor del atributo, o bien porque para dicha tupla el atributo
no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa
problemas de implementación en los SGBD relacionales.

NULL|NOT NULL. Determina si se permiten valores NULL en la columna.

 ORACLE: El optimizador necesita saber que una columna no es NOT NULL, y

sin este conocimiento, se limita a elegir un plan de ejecución inferior al óptimo.
 SQL SERVER: NULL no es estrictamente una restricción, pero se puede
especificar de la misma forma que NOT NULL. La restricción se puede usar para
las columnas calculadas sólo si se especifica también PERSISTED.
 MySQL 5.02 Si la columna puede tener NULL como valor, la columna se define
con una cláusula DEFAULT NULL explícita. En caso contrario no define DEFAULT
explícito.

Restricción UNIQUE

En un índice UNIQUE todos los valores en el índice deben ser distintos. Ocurre un
error si intenta añadir un nuevo registro con una clave que coincida con un registro
existente. La excepción es que una columna en el índice puede contener valores
NULL múltiples
 Cláusula check

Un constraint check específica una condición en cada renglón de la tabla.

 Un constraint check no puede ser definida en una vista.

 Un constraint check puede usar solamente columnas en las misma tabla.
 Un constraint check no puede ser incluida en una subconsulta.

Ejemplo: Se presentan 4 reglas de integridad de dominio.

 En el primer caso la no nulidad del campo nombreProveedor

 La no nulidad de forma ímplícíta del campo idProveedor al ser declarado llave
primaria (pkProveedor)
 La tercera regla obliga que el idProveedor este en el rango de 1,000 a 9,999
(check_id)
 El constraint dom_nombreProveedor obliga a que el nombre del proveedor se
escriba en mayúscula

CREATE TABLE proveedores (

idProveedor INTEGER(4),
nombreProveedor CHAR(50) NOT NULL,
CONSTRAINT pkProveedores PRIMARY KEY (idProveedor),
CONSTRAINT check_id CHECK (idProveedor BETWEEN 1000
AND 9999),
CONSTRAINT dom_nombreProveedor CHECK (nombreProveedor =
UPPER(nombreProveedor))
) ENGINE = InnoDB;

CREATE TABLE proveedores (

idProveedor NUMBER(4),
nombreProveedor CHAR(50) NOT NULL,
CONSTRAINT pkProveedores PRIMARY KEY (idProveedor),
CONSTRAINT check_id CHECK (idProveedor BETWEEN 1000
AND 9999)
 CONSTRAINT dom_nombreProveedor CHECK (nombreProveedor =
UPPER(nombreProveedor))
);
-- MySQL
CREATE TABLE proveedores (
idProveedor INTEGER(4),
nombreProveedor CHAR(50),
CONSTRAINT pkProveedores PRIMARY KEY (idProveedor),
CONSTRAINT dom_idProveedor
CHECK (idProveedor BETWEEN 100 AND 9999),
CONSTRAINT dom_nombreProveedor
CHECK (nombreProveedor = UPPER(nombreProveedor))
) ENGINE = InnoDB;
-- Oracle
CREATE TABLE proveedores (
idProveedor NUMBER(4),
nombreProveedor CHAR(50),
CONSTRAINT pkProveedores PRIMARY KEY (idProveedor),
CONSTRAINT dom_idProveedor
CHECK (idProveedor BETWEEN 100 AND 9999),
CONSTRAINT dom_nombreProveedor
CHECK (nombreProveedor = UPPER(nombreProveedor))
);

-- MySQL y Oracle

ALTER TABLE proveedores

ADD CONSTRAINT dom_nombreProveedor
CHECK (nombreProveedor IN ('HP','IBM', 'Microsoft', 'SONY'));

Ejemplo: ALTER TABLE

Mediante esté constraint se restrige el nombre de los proveedores validos

ALTER TABLE proveedores

ADD CONSTRAINT dom_nombreProveedor
CHECK (nombreProveedor
IN ('DELL', 'HP','IBM', 'MICROSOFT', 'SONY'));

Regla de integridad de entidades

Una PRIMARY KEY es una llave única donde todas las columnas de la clave
deben definirse como NOT NULL. Si no se declaran explícitamentecomo NOT
NULL, el gestor las declara implícitamente. Una tabla puede tener sólo una
PRIMARY KEY
 La primera regla de integridad se aplica a las claves primarias de las relaciones
base: ninguno de los atributos que componen la clave primaria puede ser nulo.
 Por definición, una clave primaria es un identificador irreducible que se utiliza para
identificar de modo único las tuplas. Irreducible significa que ningún subconjunto
de la clave primaria sirve para identificar otra tupla. Los campos que conforman
una llave primaria son por defecto no nulas.

Nótese que esta regla sólo se aplica a las relaciones base y a las claves primarias,
no a las claves alternativas.

Regla de integridad referencial

La segunda regla de integridad se aplica a las claves ajenas o foraneas: si en una

relación hay alguna clave ajena, sus valores deben coincidir con valores de la
clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base

de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La
cuestión es ¿qué hacer si estando en un estado legal, llega una petición para
realizar una operación que conduce a un estado ilegal? Existen dos opciones:
rechazar la operación, o bien aceptar la operación y realizar operaciones
adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres
preguntas:

 Regla de los nulos: Los campos involucrados en llaves primarias son por definición
no nulos.
 Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la
clave ajena?
o Restringir: no se permite borrar la tupla referenciada.
o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la
referencian mediante la clave ajena - borrado en cascada-.
o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la
clave ajena (sólo si acepta nulos) - SET NULL-.
 Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave
primaria de la tupla referenciada por la clave ajena?
o Restringir: no se permite modificar el valor de la clave primaria de la tupla
referenciada.
o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se
propaga la modificación a las tuplas que la referencian mediante la clave ajena. Oracle
no permite la modificación en cascada.
o Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo
la clave ajena (sólo si acepta nulos).

En Oracle y MySQL la clausula ON DELETE dice como comportarse si se borra el

registro “padre”:

1. Si no se especifica nada, por defecto saltará un error

2. CASCADE. Borrará los registros hijos.

Ejemplo: Considere la relación departamentos y empleados. Es posible

modificar el CONSTRAINT para que acepte el borrado en cascada.
DROP TABLE IF EXISTS empleado, departamento

CREATE TABLE departamento (

idDepartamento INTEGER(3),
nombre CHAR(15) NOT NULL,
ciudad CHAR(10) NOT NULL,
CONSTRAINT DOM_Ciudad
CHECK (ciudad IN ('Veracruz', 'Xalapa', 'Orizaba',
'Regional')),
CONSTRAINT PK_Departamento PRIMARY KEY (idDepartamento)
) ENGINE = InnoDB;

CREATE TABLE empleado(

idEmpleado INTEGER,
rfc CHAR(14),
nombreEmpleado CHAR(40) NOT NULL,
oficio CHAR(11) NOT NULL,
cargo CHAR( 9) NOT NULL,
jefe INTEGER,
ingreso DATE NOT NULL,
salario DECIMAL(10,2),
comision DECIMAL(10,2),
idDepartamento INTEGER(3) NOT NULL,
CONSTRAINT PK_Empleado PRIMARY KEY (idEmpleado),
CONSTRAINT AK_Empleado UNIQUE (rfc),
CONSTRAINT FK_EmpJefe FOREIGN KEY (jefe) REFERENCES
empleado (idEmpleado),
CONSTRAINT FK_Empleado FOREIGN KEY (idDepartamento)
REFERENCES departamento (idDepartamento),
CONSTRAINT D_Salario CHECK ( salario > 0 ),
CONSTRAINT D_NombreEmpleado CHECK (nombreEmpleado =
UPPER(nombreEmpleado))
) ENGINE = InnoDB;

ejemplo:

DROP TABLE IF EXISTS empleado, departamento;

CREATE TABLE departamento (

idDepartamento INTEGER(3),
nombre CHAR(15) NOT NULL,
ciudad CHAR(10) NOT NULL,
CONSTRAINT DOM_Ciudad CHECK (ciudad IN ('Veracruz', 'Xalapa', 'Orizaba', 'Regional')),
CONSTRAINT PK_Departamento PRIMARY KEY (idDepartamento)
) ENGINE = InnoDB;
CREATE TABLE empleado(
idEmpleado INTEGER,
rfc CHAR(14),
nombreEmpleado CHAR(40) NOT NULL,
oficio CHAR(11) NOT NULL,
cargo CHAR( 9) NOT NULL,
jefe INTEGER,
ingreso DATE NOT NULL,
salario DECIMAL(10,2),
comision DECIMAL(10,2),
idDepartamento INTEGER(3) NOT NULL,
CONSTRAINT PK_Empleado PRIMARY KEY (idEmpleado),
CONSTRAINT AK_Empleado UNIQUE (rfc),
CONSTRAINT FK_EmpJefe FOREIGN KEY (jefe) REFERENCES empleado(idEmpleado),
CONSTRAINT FK_Depto FOREIGN KEY (idDepartamento) REFERENCES
departamento (idDepartamento),
CONSTRAINT D_Salario CHECK ( salario > 0 ),
CONSTRAINT D_NombreEmpleado CHECK (nombreEmpleado =
UPPER(nombreEmpleado))
) ENGINE = InnoDB;

CREATE GLOBAL TEMPORARY TABLE detalle (

rfc CHAR(14) PRIMARY KEY,
nombreEmpleado CHAR(40) NOT NULL,
salarioNeto NUMBER(10,2)
) ON COMMIT PRESERVE ROWS;

INSERT INTO detalle

SELECT rfc, nombreEmpleado, salario + salario*comision
FROM empleado
WHERE comision > 0;

El código para implementar el borrado es cascada si borramos un departamento

borrar los empleados que laboran en él es:

ALTER TABLE empleado

DROP CONSTRAINT FK_Empleado;
ALTER TABLE empleado ADD CONSTRAINT FK_Empleado
FOREIGN KEY (idDepartamento)
REFERENCES departamento (idDepartamento)
ON DELETE CASCADE;

Versión Oracle
DROP TABLE empleado CASCADE CONSTRAINTS;
DROP TABLE departamento CASCADE CONSTRAINTS;

CREATE TABLE departamento (

idDepartamento NUMBER(3),
nombre CHAR(15) NOT NULL,
ciudad CHAR(10) NOT NULL,
CONSTRAINT DOM_Ciudad
CHECK (ciudad IN ('Veracruz', 'Xalapa', 'Orizaba',
'Regional')),
CONSTRAINT PK_Departamento PRIMARY KEY (idDepartamento)
);

CREATE TABLE empleado(

idEmpleado NUMBER(3),
rfc CHAR(14),
nombreEmpleado CHAR(40) NOT NULL,
oficio CHAR(11) NOT NULL,
cargo CHAR(9) NOT NULL,
jefe NUMBER(3),
ingreso DATE NOT NULL,
salario NUMBER(10,2),
comision NUMBER(10,2),
idDepartamento NUMBER(3) NOT NULL,
CONSTRAINT PK_Empleado PRIMARY KEY (idEmpleado),
CONSTRAINT AK_Empleado UNIQUE (rfc),
CONSTRAINT FK_Empleado_Jefe FOREIGN KEY (jefe)
REFERENCES Empleado,
CONSTRAINT FK_Empleado FOREIGN KEY (idDepartamento)
REFERENCES Departamento,
CONSTRAINT D_Empleado_Salario CHECK ( salario > 0 ),
CONSTRAINT D_Empleado_NombreEmpleado CHECK
(nombreEmpleado = UPPER(nombreEmpleado))
);

3. SET NULL. Pondrá los campos del registro hijo a null. Note que la clave ajena
debe permitir el valor nulo.

Sintaxis

CONSTRAINT FK_columna
FOREIGN KEY (columna1, columna2, ... columna_n)
REFERENCES TablaReferenciada (columna1, columna2, ...
columna_n)
ON DELETE SET NULL

Ejemplo: Proveedor - Producto

CREATE TABLE IF NOT EXISTS proveedor (

idProveedor INTEGER,
nombreProveedor CHAR(50) NOT NULL,
contacto CHAR(50),
CONSTRAINT PK_Proveedor PRIMARY KEY (idProveedor)
) ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS productos (

idProducto INTEGER,
idProveedor INTEGER,
nombreProducto CHAR(50),
precioProducto DECIMAL(8,2),
CONSTRAINT PK_Productos PRIMARY KEY (idProducto),
CONSTRAINT FK_Proveedor
FOREIGN KEY (idProveedor)
REFERENCES proveedor(idProveedor)
ON DELETE SET NULL
) ENGINE = InnoDB;

DROP TABLE productos CASCADE CONSTRAINT;

DROP TABLE proveedor CASCADE CONSTRAINT;
 CREATE TABLE proveedor (
idProveedor NUMBER(3),
nombreProveedor CHAR(50) NOT NULL,
contacto CHAR(50),
CONSTRAINT PK_Proveedor PRIMARY KEY (idProveedor)
);

CREATE TABLE productos (

idProducto NUMBER(5),
idProveedor NUMBER(3),
nombreProducto CHAR(50),
precioProducto NUMBER(8,2),
CONSTRAINT PK_Productos PRIMARY KEY (idProducto),
CONSTRAINT FK_Proveedor
FOREIGN KEY (idProveedor)
REFERENCES proveedor (idProveedor)
ON DELETE SET NULL
);

Reglas de negocio

Toda aplicación trata de reflejar parte del funcionamiento del mundo real, para
automatizar tareas que de otro modo serían llevadas a cabo de modo más
ineficiente, o bien no podrían realizarse. Para ello, es necesario que cada
aplicación refleje las restricciones que existen en el negocio dado, de modo que
nunca sea posible llevar a cabo acciones no válidas. A las reglas que debe seguir
la aplicación para garantizar se les denomina reglas de negocio.

Ejemplos de tales reglas son:

 No permitir crear facturas pertenecientes a clientes inexistentes

 Controlar que el saldo negativo de un cliente nunca sobrepase cierta cantidad,
 No emitir facturas sin RFC (Registro Federal de Causante)
 Limitar o cancelar los números de celular no registrados
 Limitar el servicio telefónico por falta de pago

En realidad, la información puede ser manipulada por muchos programas distintos:

así, una empresa puede tener un departamento de contabilidad que controle todo
lo relacionado con compras, cobros, etc., y otro departamento técnico, que esté
interesado en relacionar diversos parámetros de producción con los costes.
La visión que ambos departamentos tendrán de la información y sus necesidades
serán distintas, pero en cualquier caso siempre se deberán respetar las reglas de
negocio. El hecho de que la información sea manipulada por diversos programas
hace más difícil garantizar que todos respetan las reglas, especialmente si las
aplicaciones corren en diversas máquinas, bajo distintos sistemas operativos, y
están desarrolladas con distintos lenguajes y herramientas.

Ejemplo: Considere el diagrama entidad relación que a continuación se expone y

su correspondiente traducción a sentencias MySQL y Oracle. El cual involucra
artistas, sus discos y las canciones que contiene dicho disco.

CREATE TABLE artista (

idArtista INTEGER,
nombreArtista CHAR(35) NOT NULL,
CONSTRAINT pk_Artista PRIMARY KEY (idArtista),
CONSTRAINT ak_nombreArtista UNIQUE ( nombreArtista )
) ENGINE = InnoDB;

CREATE TABLE disco (

asin CHAR(12),
idArtista INTEGER NOT NULL,
nombreAlbum CHAR(20) NOT NULL,
yearLanzamiento INTEGER(4),
marca CHAR(20),
CONSTRAINT pk_disco PRIMARY KEY (asin),
CONSTRAINT fk_artistaDisco FOREIGN KEY (idArtista)
REFERENCES artista (idArtista)
) ENGINE = InnoDB;

CREATE TABLE canciones (

idCancion INTEGER,
asin CHAR(12) NOT NULL,
nombreCancion CHAR(30) NOT NULL,
duracion CHAR(6),
estilo CHAR(15),
CONSTRAINT pk_canciones PRIMARY KEY (idCancion),
CONSTRAINT fk_DiscoCanciones FOREIGN KEY (asin)
REFERENCES disco (asin)
) ENGINE = InnoDB;

CREATE TABLE artista (

idArtista NUMBER,
nombreArtista CHAR(35) NOT NULL,
CONSTRAINT pk_Artista PRIMARY KEY (idArtista),
CONSTRAINT ak_nombreArtista UNIQUE ( nombreArtista )
);

CREATE TABLE disco (

asin CHAR(12),
idArtista NUMBER NOT NULL,
nombreAlbum CHAR(20) NOT NULL,
yearLanzamiento NUMBER(4),
marca CHAR(20),
CONSTRAINT pk_disco PRIMARY KEY (asin),
CONSTRAINT fk_artistaDisco FOREIGN KEY (idArtista)
REFERENCES artista (idArtista)
);

CREATE TABLE canciones (

idCancion NUMBER,
asin CHAR(12) NOT NULL,
nombreCancion CHAR(30) NOT NULL,
duracion CHAR(6),
estilo CHAR(15),
CONSTRAINT pk_canciones PRIMARY KEY (idCancion),
CONSTRAINT fk_DiscoCanciones FOREIGN KEY (asin)
REFERENCES disco (asin)
);
 Integridad referencial declativa

La integridad de los datos es la propiedad que asegura que información dada es

correcta, al cumplir ciertas aserciones.

Las restricciones de integridad aseguran que la información contenida en una

base de datos es correcta.

Las restricciones de integridad son propiedades de la base de datos que se deben

satisfacer en cualquier momento.

Tanto Oracle y MySql son sistemas de gestión de base de datos (SGBD)

relacional que permite la definición de restricciones de integridad dentro del diseño
de su base de datos al ser creada.

Las restricciones de integridad aseguran que la información contenida en la base

de datos cumple ciertas normas o reglas para los diferentes estados.

Existen dos tipos de restricciones:

 Estáticas: limitan los estados permitidos de la Base de Datos.

 Dinámicas: restringen las posibles transiciones de estados de la base datos.

Para incorporar el tratamiento de las restricciones de integridad en el sistema

pueden realizarse:

 Añadiendo código adicional para verificar y asegurar que se cumplen las

restricciones (Mecanismos declarativos: Procedure o Trigger
 Declarando las restricciones como parte del esquema de la base de datos.

La definición en la fase de diseño de las restricciones de integridad proporciona

mayor número de ventajas, ya que:
 Reduce el costo de desarrollo de software.
 Es más confiable al ser centralizado y uniforme.
 Mantenimiento más fácil.

De acuerdo con la forma de especificación del comando CREATE TABLE dada

anteriormente, la cláusula CONSTRAINT puede entonces tener las siguientes
formas:

 CONSTRAINT <constraint_name> PRIMARY KEY (<column_name

>[,<column_name>])
 CONSTRAINT <constraint_name> UNIQUE (<column_name>[,<column_name>])
 CONSTRAINT <constraint_name> FOREIGN KEY
(<column_name>[,<column_name>])
REFERENCES <table_name>
 CONSTRAINT <constraint_name> CHECK (<condición>)

Donde:

 <constraint_name> es el nombre con el que se designará al CONSTRAINT en el

esquema donde se crea la tabla que lo incluye.
 <column_name> es el nombre de una columna de la tabla en la que se define el
CONSTRAINT
 <table_name> es el nombre de una tabla definida en el esquema donde existe la
tabla que incluye el CONSTRAINT .
 <condición> es una expresión lógica en SQL.

En el manual de referencia de SQL usted podrá encontrar información sobre las

reglas de formación de expresiones lógicas de SQL.

Un punto importantísimo a destacar es el de garantizar que los nombres de los

CONSTRAINT sean nemónicos. Toda vez que un CONSTRAINTsea violado, el
SGBD generará un mensaje de error indicando el CONSTRAINT que ha fallado.
Asignar nombres nemónicos permitirá hacer la depuración de programas y la
carga de datos mucho más sencilla, además de garantizar una perfecta cohesión
entre el esquema de implantación y la documentación del esquema lógico.
 Es así como se sugiere utilizar el siguiente estándar de nomenclatura:

 Para restricciones de no-nulidad se recomienda no crear CONSTRAINT sino

declarar la no-nulidad al momento de crear la tabla y para cada columna.
 Para asociar un CONSTRAINT de clave primaria a una tabla <table_name> se
recomienda designar el “constraint" con el nombre PK_<table_name>.
 Para asociar un CONSTRAINT de unicidad relacionado con una clave alterna de la
tabla<table_name>, se recomienda designar el CONSTRAINT con el nombre
AK_<table_name>
 Para asociar un CONSTRAINT de clave foránea a una tabla <table_name1> que
referencia a una tabla <table_name2> designe el CONSTRAINT con el nombre
FK_<table_name1>_<table_name2>.
 Asociar un CONSTRAINT que represente una restricción de dominio sobre una
columna <column_name> de una tabla <table_name>, se sugiere utilizar
D_<table_name>__<column_name> como nombre del CONSTRAINT
 Para asociar un CONSTRAINT que represente una restricción explícita, descrita a
través de una restricciôn de tipo CHECK, de una tabla <table_name> use
EXP_<table_name>__R<constraint_number> como nombre del “constraint
constraint_number> representará el número de restricción explícita asociado en la
documentación del esquema relacional que se implanta.

Los CONSTRAINT pueden ser agregados a una tabla previamente creada, o

eliminados de una tabla existente. Para tal fin se pueden utilizar dos variaciones
del comando ALTER TABLE, cuya sintaxis a continuación se indica:

ALTER TABLE <table_name> ADD (<table_constraint> [,<table_constraint>]);

Permitirá agregar una o más CONSTRAINT a la tabla existente en la base de

datos. Cada uno de los CONSTRAINT que se añaden a la tabla seguirán las
convenciones sintácticas de la cláusula <table_constraint>.

ALTER TABLE <table_name> DROP CONSTRAINT <constraint_name>

[CASCADE];

Eliminará de la tabla la restricción <constraint_name>.

 Si se utiliza la cláusula CASCADE, la eliminación del CONSTRAINT tendrá como
efecto eliminar cualquier otro CONSTRAINT relacionado con elCONSTRAINT que
se elimina.

Por ejemplo, si se elimina un CONSTRAINT de clave primaria de una tabla A bajo

modalidad CONSTRAINT entonces se eliminarán losCONSTRAINT de clave
foránea que referencien a A.

SOBRE LÍMITES

ORACLE impone los siguientes límites en lo que respecta a los objetos descritos
en esta sección:

 La longitud de cualquier identificador (nombre de tabla, nombre de columna,

nombre de "constraints", entre otros) se limita a un máximo de 30 caracteres.

 El número máximo de columnas que puede tener una tabla es de 1000.

 El número máximo de columnas que pueden constituir una clave primaria, una
clave alterna o una clave foránea es de 16.

Ejemplo: Torneo Primera División Federación Mexicana de Futbol

CREATE TABLE posicion (
idPosicion NUMBER(1),
nombrePosicion CHAR(20) NOT NULL,
CONSTRAINT PK_Posicion PRIMARY KEY (idPosicion)
);

CREATE TABLE nacionalidad (

idNacionalidad NUMBER(3),
nombreNacionalidad CHAR(20) NOT NULL,
CONSTRAINT PK_Nacionalidad PRIMARY KEY
(idNacionalidad)
);

CREATE TABLE estadio (

idEstadio NUMBER(3),
nombreEstadio CHAR(25) NOT NULL,
direccion CHAR(35) NOT NULL,
codigoPostal NUMBER(5),
ciudad CHAR(30) NOT NULL,
fechaInaguracion DATE,
capacidad NUMBER NOT NULL,
foto CHAR(30),
CONSTRAINT PK_Estadio PRIMARY KEY (idEstadio)
);

CREATE TABLE equipo (

idEquipo NUMBER,
nombreEquipo CHAR(25) NOT NULL,
seudonimo CHAR(25) NOT NULL,
nombre_oficial CHAR(60) NOT NULL,
direccion CHAR(35) NOT NULL,
codigoPostal NUMBER(5),
ciudad CHAR(30) NOT NULL,
escudo CHAR(50),
fechaFundacion DATE,
paginaWeb CHAR(50) NOT NULL,
CONSTRAINT PK_Equipo PRIMARY KEY (idEquipo)
);

CREATE TABLE jugador (

idJugador NUMBER,
nombreJugador CHAR(40),
idEquipo NUMBER,
idPosicion NUMBER NOT NULL,
jj NUMBER DEFAULT 0,
jc NUMBER DEFAULT 0,
jt NUMBER DEFAULT 0,
ec NUMBER DEFAULT 0,
sc NUMBER DEFAULT 0,
minutos NUMBER DEFAULT 0,
goles NUMBER DEFAULT 0,
ta NUMBER DEFAULT 0,
tr NUMBER DEFAULT 0,
numero NUMBER NOT NULL,
fechaNacimiento DATE NOT NULL,
estatura NUMBER,
peso NUMBER,
idNacionalidad NUMBER DEFAULT 1,
CONSTRAINT PK_Jugador PRIMARY KEY (idJugador),
CONSTRAINT FK_Juega_En FOREIGN KEY (idEquipo)
REFERENCES equipo (idEquipo),
CONSTRAINT FK_Juega_Como FOREIGN KEY (idPosicion)
REFERENCES posicion (idPosicion),
CONSTRAINT FK_Origen FOREIGN KEY (idNacionalidad)
REFERENCES nacionalidad
(idNacionalidad)
);

CREATE TABLE partido (

idPartido NUMBER,
jornada NUMBER(2) NOT NULL,
 fecha DATE NOT NULL,
hora CHAR(5) NOT NULL,
idLocal NUMBER(3) NOT NULL,
golLocal NUMBER(2) DEFAULT 0,
idVisitante NUMBER(3) NOT NULL,
golVisitante NUMBER(3) DEFAULT 0,
idEstadio NUMBER(3) NOT NULL,
arbitro CHAR(50) NOT NULL,
asistente1 CHAR(50) NOT NULL,
asistentente2 CHAR(50) NOT NULL,
cJuez CHAR(50),
idEquipoLocal NUMBER(3) NOT NULL,
idEquipoVisitante NUMBER(3) NOT NULL,
CONSTRAINT PK_Partido PRIMARY KEY (idPartido),
CONSTRAINT FK_Partidos_En FOREIGN KEY (idEstadio)
REFERENCES estadio (idEstadio),
CONSTRAINT FK_Local FOREIGN KEY (idLocal)
REFERENCES equipo (idEquipo),
CONSTRAINT FK_Visitante FOREIGN KEY (idVisitante)
REFERENCES equipo (idEquipo)
);

CREATE TABLE posicion (

idPosicion INTEGER(1),
nombrePosicion CHAR(20) NOT NULL,
CONSTRAINT PK_Posicion PRIMARY KEY (idPosicion)
);

CREATE TABLE nacionalidad (

idNacionalidad INTEGER(3),
nombreNacionalidad CHAR(20) NOT NULL,
CONSTRAINT PK_Nacionalidad PRIMARY KEY
(idNacionalidad)
);

CREATE TABLE estadio (

idEstadio INTEGER(3),
nombreEstadio CHAR(25) NOT NULL,
direccion CHAR(35) NOT NULL,
codigoPostal INTEGER(5),
ciudad CHAR(30) NOT NULL,
fechaInaguracion DATE,
capacidad INTEGER NOT NULL,
foto CHAR(30),
CONSTRAINT PK_Estadio PRIMARY KEY (idEstadio)
);
CREATE TABLE equipo (
idEquipo INTEGER,
nombreEquipo CHAR(25) NOT NULL,
seudonimo CHAR(25) NOT NULL,
nombre_oficial CHAR(60) NOT NULL,
direccion CHAR(35) NOT NULL,
codigoPostal INTEGER(5),
ciudad CHAR(30) NOTNULL,
escudo CHAR(50),
fechaFundacion DATE,
paginaWeb CHAR(50) NOT NULL,
CONSTRAINT PK_Equipo PRIMARY KEY (idEquipo)
);

CREATE TABLE jugador (

idJugador INTEGER,
nombreJugador CHAR(40),
idEquipo INTEGER,
idPosicion INTEGER NOT NULL,
jj INTEGER DEFAULT 0,
jc INTEGER DEFAULT 0,
jt INTEGER DEFAULT 0,
ec INTEGER DEFAULT 0,
sc INTEGER DEFAULT 0,
minutos INTEGER DEFAULT 0,
goles INTEGER DEFAULT 0,
ta INTEGER DEFAULT 0,
tr INTEGER DEFAULT 0,
numero INTEGER NOT NULL,
fechaNacimiento DATE NOT NULL,
estatura INTEGER,
peso INTEGER,
idNacionalidad INTEGER,
CONSTRAINT PK_Jugador PRIMARY KEY (idJugador),
CONSTRAINT FK_Juega_En FOREIGN KEY (idEquipo)
REFERENCES equipo (idEquipo),
CONSTRAINT FK_Juega_Como FOREIGN KEY (idPosicion)
REFERENCES posicion (idPosicion),
CONSTRAINT FK_Origen FOREIGN KEY (idNacionalidad)
REFERENCES nacionalidad
(idNacionalidad)
);
CREATE TABLE partido (
idPartido INTEGER(5) NOT NULL,
jornada INTEGER(2) NOT NULL,
fecha DATE NOT NULL,
hora CHAR(5) NOT NULL,
idLocal INTEGER(3) NOT NULL,
golLocal INTEGER(2) DEFAULT 0,
idVisitante INTEGER(3) NOT NULL,
golVisitante INTEGER(3) DEFAULT 0,
idEstadio INTEGER(3) NOT NULL,
arbitro CHAR(50) NOT NULL,
asistente1 CHAR(50) NOT NULL,
asistente2 CHAR(50) NOT NULL,
cJuez CHAR(50),
idEquipoLocal INTEGER(3) NOT NULL,
idEquipoVisitante INTEGER(3) NOT NULL,
CONSTRAINT PK_Partido PRIMARY KEY (idPartido),
CONSTRAINT FK_Partidos_En FOREIGN KEY (idEstadio)
REFERENCES estadio (idEstadio),
CONSTRAINT FK_Local FOREIGN KEY (idLocal)
REFERENCES equipo (idEquipo),
CONSTRAINT FK_Visitante FOREIGN KEY (idVisitante)
REFERENCES equipo (idEquipo)
);

Ejemplo: El departamento de Postgrado e investigación del Tecnológico Virtual ha

diseñado una base de datos (BD) para la gestión de los proyectos de investigación
en los que participan sus investigadores.

Se presenta a continuación el diagrama Entidad Relación propuesto mismo que es

perfectible. Si lo hace justique sus cambios.
DROP TABLE asignado CASCADE CONSTRAINTS;
DROP TABLE proyecto CASCADE CONSTRAINTS;
DROP TABLE linea CASCADE CONSTRAINTS;
DROP TABLE investigador CASCADE CONSTRAINTS;
DROP TABLE depAcademico CASCADE CONSTRAINTS;
CREATE TABLE linea
(
idLinea CHAR(20),
nombreLinea CHAR(100) NOT NULL,
financiadoPor CHAR(30) NOT NULL,
CONSTRAINT PK_Linea PRIMARY KEY (idLinea)
);

CREATE TABLE proyecto (

idProyecto CHAR(20),
idLinea CHAR(20) NOT NULL,
nombreProyecto CHAR(100) NOT NULL,
F_Inicio DATE NOT NULL,
F_Terminacion DATE NOT NULL,
Presupuesto NUMBER(10,0) NOT NULL,
CONSTRAINT PK_Proyecto PRIMARY KEY (idProyecto),
 CONSTRAINT FK_Linea FOREIGN KEY (idLinea)
REFERENCES linea (idLinea)
);

CREATE TABLE depAcademico (

idDepartamento NUMBER,
Departamento CHAR(30) NOT NULL,
CONSTRAINT PK_DepAcademico PRIMARY KEY (idDepartamento)
);

CREATE TABLE investigador (

ife CHAR(13),
nombreInvestigador CHAR(50) NOT NULL,
telefono CHAR(10) NOT NULL,
email CHAR(50) NOT NULL,
idDepartamento NUMBER NOT NULL,
CONSTRAINT PK_Investigador PRIMARY KEY (ife),
CONSTRAINT FK_DepAcademico FOREIGN KEY (idDepartamento)
REFERENCES depAcademico
(idDepartamento)
);

CREATE TABLE asignado (

ife CHAR(13) NOT NULL,
idProyecto CHAR(20) NOT NULL,
F_Inicio DATE NOT NULL,
F_Termino DATE,
tipoParticipacion CHAR(20) NOT NULL,
CONSTRAINT FK_Investigador FOREIGN KEY (ife) REFERENCES
investigador (ife),
CONSTRAINT FK_Proyecto FOREIGN KEY (idProyecto)
REFERENCES proyecto (idProyecto)
);

DROP TABLE IF EXISTS asignado, proyecto, linea,

investigador, depAcademico;

CREATE TABLE linea (

idLinea CHAR(20),
nombreLinea CHAR(100) NOT NULL,
financiadoPor CHAR(30) NOT NULL,
CONSTRAINT PK_Linea PRIMARY KEY (idLinea)
);

CREATE TABLE proyecto (

idProyecto CHAR(20),
idLinea CHAR(20) NOT NULL,
nombreProyecto CHAR(100) NOT NULL,
F_Inicio DATE NOT NULL,
F_Terminacion DATE NOT NULL,
Presupuesto DECIMAL(10,0) NOT NULL,
CONSTRAINT PK_Proyecto PRIMARY KEY (idProyecto),
CONSTRAINT FK_Linea FOREIGN KEY (idLinea)
REFERENCES LINEA (idLinea)
);

CREATE TABLE depAcademico (

idDepartamento INTEGER,
Departamento CHAR(30) NOT NULL,
CONSTRAINT PK_DepAcademico PRIMARY KEY (idDepartamento)
);

CREATE TABLE investigador (

ife CHAR(13),
nombreInvestigador CHAR(50) NOT NULL,
telefono CHAR(10) NOT NULL,
email CHAR(50) NOT NULL,
idDepartamento INTEGER NOT NULL,
CONSTRAINT PK_Investigador PRIMARY KEY (ife),
CONSTRAINT FK_DepAcademico FOREIGN KEY (idDepartamento)
REFERENCES depAcademico
(idDepartamento)
);

CREATE TABLE asignado (

ife CHAR(13) NOT NULL,
idProyecto CHAR(20) NOT NULL,
F_Inicio DATE NOT NULL,
F_Termino DATE,
tipoParticipacion CHAR(20) NOT NULL,
CONSTRAINT FK_Investigador FOREIGN KEY (ife) REFERENCES
investigador (ife),
CONSTRAINT FK_Proyecto FOREIGN KEY (idProyecto)
REFERENCES proyecto (idProyecto));