Unidad II.

Lenguaje de Definicin de Datos (DDL)

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

2.1. Creacin del esquema de la base de datos

El esquema de una base de datos (en ingls, 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 trmino
se usa a menudo para referirse a una representacin grfica de la estructura de
base de datos (Diseo de lgico de la base de datos).
Generalmente en la prctica el trmino esquema de la base de datos se refiere al
diseo fsico 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 informacin sobre privilegios y procedimientos del gestor y no
deben ser eliminados.
Sintaxis bsica para crear una base de datos en Oracle (No aplica en Oracle
express)
CREATE DATABASE nombre_baseDatos
Sintaxis bsica 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. Actualizacin, modificacin y eliminacin 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 nmero especfico de columnas,
pero puede tener cualquier nmero 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 clculo, en
cuanto a que los datos se almacenan en filas y columnas. Como consecuencia,
normalmente es bastante fcil importar una hoja de clculo en una tabla de una
base de datos. La principal diferencia entre almacenar los datos en una hoja de
clculo y hacerlo en una base de datos es la forma de organizarse los datos.

Por lo tanto, la creacin de las tablas en el proceso de programacin en Oracle

juegan un papel muy importante. En el momento de crear las tablas se definen
caractersticas a dos niveles: Tabla y Columna, como se muestra a continuacin:
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.

Nombre:

Propietario:

Hay que tener en cuenta tambin ciertas restricciones con los

nombres de las tablas: longitud mxima de 30 caracteres, no
puede haber nombres de tabla duplicados, deben comenzar con
un carcter alfabtico, permitir caracteres alfanumricos y el
guin bajo '_', y Oracle no distingue entre maysculas y
minsculas.
La tabla tiene como propietario al usuario que las crea En nuestro
caso somos el usuario ALUMNO. Otro usuario que desee usar
nuestras tablas debe tener autorizacin para ello y hacer
referencia a la tabla como ALUMNO.EQUIPO (propietario.tabla)

Cantidad de
Una tabla puede tener un mximo de 254 columnas.
Columnas:
A nivel de Columna el nombre de la columna puede tener un mximo de 30
caracteres.
En Oracle podemos implementar diversos tipos de tablas. A continuacin se
presenta una recopilacin no exhaustiva de ellas.
Tipo Tabla

Regular
(heap)

Clustered

Descripcin
Son el mecanismo de almacenamiento de los datos en una base
de datos Oracle. Contienen un conjunto fijo de columnas. Las
columnas de una tabla describen los atributos de la entidad que
se representa con la tabla. Cada columna tiene un nombre y
caractersticas especficas: tipo de dato y longitud, restricciones,
etc.
Un cluster proporciona un mtodo opcional de almacenar datos
de tabla. Un cluster est compuesto de un grupo de tablas que
comparten los mismos bloques de datos. Las tablas son

Tipo Tabla

Descripcin
agrupadas mediante columnas comunes.

Index

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

Esto impone orden fsico a las filas por si mismas. A diferencia
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 organizacin de los datos con el cual

podemos dividirla en mltiples objetos de almacenamientos
llamados particiones de datos o rangos, dependiendo los
Particionadas valores puede ser dividido en uno o ms 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 combinacin de ambos.

Temporales

Son tablas cuyos datos permanecern en el sistema slo

durante el tiempo que dure la transaccin o sesin involucrada.
No obstante, al igual que para las tablas permanentes, la
definicin 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 informacin de naturaleza distinta. Los tipos de datos ms comunes y
sus caractersticas en Oracle Express (10 Y 11g) se resumen en la siguiente tabla.
Las versiones de Oracle comercial soportan una gama mucho ms amplia de tipos
de datos.

Tipo de Dato

Descripcin
Contiene datos binarios con un tamao mximo de 4
gigabytes. Los datos binarios nos van a permitir guardar
en la base de datos archivos, imgenes, 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 solucin.

BINARY_DOUBLE

Precisin doble

BINARY_FLOAT

Precisin simple
Un tipo de datos CLOB de Oracle contiene datos de
caracteres basados en el juego de caracteres
predeterminados del servidor. Su tamao mximo es de
4 gigabytes. Se asigna a cadena.

CLOB

Use la siguiente expresin para una consulta de un

campo CLOB

SELECT
DBMS_LOB.substr(campo,
DBMS_LOB.getlength(campo), 1)
FROM tablaprueba;
CHAR

Almacena datos de tipo carcter alfanumrico de longitud

fija, con un tamao mximo de 2000. caracteres

DATE

Almacena fechas desde el 1-Ene-4712 AC hasta el 31Dic-4712 DC.

NUMBER(dig [, dec])

Datos numricos de n dgitos, de los cuales dec son

decimales. El tamao mximo es de 38 dgitos.

NVARCHAR2

Almacena un valor alfanumrico de longitud variable en

caracteres Unicode con las mismas restricciones de
varchar.

TIMESTAMP

Fecha y hora (incluidos los segundos), con un tamao

que abarca desde 7 a 11 bytes.

VARCHAR2(tamao)

Guarda datos de tipo carcter alfanumrico de longitud

variable, con un tamao mximo de 4,000 caracteres.

Ejemplo: Considere la siguiente tabla de datos correspondientes a los campeones

de Formula 1 (1950 - 2012) y sus escuderas. Y su traduccin a sentencias Oracle.
Ao

Campen

Escudera

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 poblacin y superficie de la Republica
Mexicana
CREATE TABLE
idEstado
nombreEstado
capital
densidad
poblacion
);

estados (
INTEGER PRIMARY KEY,
CHAR(25) NOT NULL,
CHAR(25) NOT NULL,
INTEGER NOT NULL,
INTEGER NOT NULL

Tablas Temporales
Oracle permite la creacin de tablas temporales para mantener datos propios y
exclusivos a una sesin Oracle determinada. Estos datos permanecern en el
sistema slo durante el tiempo que dure la transaccin o sesin involucrada. No
obstante, al igual que para las tablas permanentes, la definicin de las tablas
temporales se almacena en las tablas del sistema.
La siguiente sintaxis permite crear una tabla temporal personal para cada sesin.
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 expresin] [NOT NULL],
[,nombre_columna
tipo_dato [DEFAULT expresin]
[restriccin_columna] ...
|restriccin_tabla];
ON COMMIT { DELETE | PRESERVE } ROWS ]
[ physical_properties ]
Con la opcin ON COMMIT DELETE ROWS se borran los datos cada vez que se
hace COMMIT en la sesin.
Con la opcin ON PRESERVE DELETE ROWS los datos no se borran hasta el
final de la sesin.
Sus ventajas son varias, la informacin contenida en ella esta solo disponible para
la sesin actual, cualquier insercin, borrado, actualizacin solo se refleja en la
sesin activa.
Muchas funcionalidades de cualquier tabla normal se mantienen en ella, como
triggers a nivel tabla, vistas, ndices, exportar e importar (claro solo la definicin de
la tabla).

No es posible declarar llaves forneas en una tabla temporal.

(DROP) Eliminacin
Cuando una tabla ya no es til y no vamos a volver a necesitarla debe ser borrada.
Esta operacin 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 informacin contenida en la
tabla, es decir, todas las filas. Tambin se borrar toda la informacin 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 eliminacin de la tabla, ya que existe una restriccin 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 eliminacin de la tabla BORRAME.

Modificacin
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 modificacin de los datos ya
existentes.
Esta operacin 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 tamao de una columna, si esta contiene

datos.

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

o la tabla debe estar vaca.

La opcin ADD ... NOT NULL slo ser posible si la tabla est vaca.

La opcin MODIFY ... NOT NULL slo podr realizarse cuando la tabla
no contenga ninguna fila con valor nulo en la columna en cuestin.

Considere el ejemplo Propietario - Automvil, bajo el criterio de hacienda del

Gobierno del Estado de Veracruz, Mxico. Modificaremos el ejemplo para aadir el
atributo color.

ALTER TABLE automovil

ADD(color CHAR(15) NOT NULL);
ARCHIVO CREATE TABLE AUTOMOVIL

Es factible modificar una tabla aadiendo o eliminando restricciones, en este caso

para el ejemplo anterior el comando a utilizar ser

ALTER TABLE tabla {ADD | DROP} CONSTRAINT restriccin;

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

recuperacin de datos rpida, as como posibilidad de bsquedas

fulltext.MyISAM se soporta en todas las configuraciones MySQL, y es el
motor de almacenamiento por defecto a no ser que tenga una configuracin 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 coleccin de tablas MyISAM idnticas
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 conoca como
HEAP.
Los motores de almacenamiento InnoDB
y BDB proporcionan tablas
transaccionales. BDB se incluye en la distribucin binaria MySQL-Max en aquellos
sistemas operativos que la soportan. InnoDB tambin 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 cdigo MySQL
para ilustrar cmo escribir un motor de almacenamiento. Como tal, su inters
primario es para desarrolladores.
NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para

implementar tablas que se particionan en varias mquinas. 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 aadir
soporte para este motor de almacenamiento en otras plataformas, incluyendo
Windows en prximas versiones.
El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades

de datos sin ndices con una huella muy pequea.

El motor de almacenamiento CSV guarda datos en archivos de texto usando

formato de valores separados por comas.

El motor de almacenamiento FEDERATED se aadi en MySQL 5.0.3. Este motor
guarda datos en una base de datos remota. En esta versin slo funciona con
MySQL a travs de la API MySQL C Client. En futuras versiones, ser capaz de
conectar con otras fuentes de datos usando otros drivers o mtodos de conexin
clientes.

La versin 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 sern 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 poblacin 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 creacin de la tabla.

Tablas temporales

Las tablas temporales solo existen mientras la sesin est viva . Si se

corre este cdigo en un script de PHP ( Cualquier otro lenguaje), la tabla temporal
se destruir automticamente al termino de la ejecucin de la pgina. Si no
especfica 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 ms 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;

Modificacin
Esta operacin 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 - Automvil, bajo el criterio de hacienda del

Gobierno del Estado de Veracruz, Mxico. Modificaremos el ejemplo para aadir el
atributo color segn 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 fornea

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 mltiples clusulas ADD, ALTER, DROP, y CHANGE en un nico
comando ALTER TABLE. Esta es una extensin MySQL al estndar SQL, que
permite slo una de cada clusula 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 caractersticas para garantizar que son correctos. Al definir
cada atributo sobre un dominio se impone una restriccin sobre el conjunto de
valores permitidos para cada atributo.
A este tipo de restricciones se les denomina restricciones de dominios. Hay
adems 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 limitacin 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 vaca, stos son valores que tienen
significado. El nulo implica ausencia de informacin, bien porque al insertar la
tupla se desconoca 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 implementacin 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 ejecucin inferior al ptimo.

SQL SERVER: NULL no es estrictamente una restriccin, pero se puede

especificar de la misma forma que NOT NULL. La restriccin se puede usar para
las columnas calculadas slo si se especifica tambin PERSISTED.
MySQL 5.02 Si la columna puede tener NULL como valor, la columna se define
con una clusula DEFAULT NULL explcita. En caso contrario no define DEFAULT
explcito.
Restriccin UNIQUE

En un ndice UNIQUE todos los valores en el ndice deben ser distintos. Ocurre un
error si intenta aadir un nuevo registro con una clave que coincida con un registro
existente. La excepcin es que una columna en el ndice puede contener valores
NULL mltiples

Clusula check

Un constraint check especfica una condicin en cada rengln 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 mplcta 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 mayscula

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 explcitamentecomo NOT
NULL, el gestor las declara implcitamente. Una tabla puede tener slo 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 definicin, una clave primaria es un identificador irreducible que se utiliza para
identificar de modo nico las tuplas. Irreducible significa que ningn subconjunto
de la clave primaria sirve para identificar otra tupla. Los campos que conforman
una llave primaria son por defecto no nulas.

Ntese que esta regla slo 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

relacin 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 trminos de estados de la base
de datos: indica lo que es un estado ilegal, pero no dice cmo puede evitarse. La
cuestin es qu hacer si estando en un estado legal, llega una peticin para
realizar una operacin que conduce a un estado ilegal? Existen dos opciones:
rechazar la operacin, o bien aceptar la operacin 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 definicin

no nulos.

Regla de borrado: Qu ocurre si se intenta borrar la tupla referenciada por la

clave ajena?
o
o
o

Restringir: no se permite borrar la tupla referenciada.

Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la
referencian mediante la clave ajena - borrado en cascada-.
Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la
clave ajena (slo si acepta nulos) - SET NULL-.

Regla de modificacin: 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.

Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se

propaga la modificacin a las tuplas que la referencian mediante la clave ajena. Oracle
no permite la modificacin en cascada.
Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo
la clave ajena (slo 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 relacin 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 cdigo 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;
Versin 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 aplicacin trata de reflejar parte del funcionamiento del mundo real, para
automatizar tareas que de otro modo seran llevadas a cabo de modo ms
ineficiente, o bien no podran realizarse. Para ello, es necesario que cada
aplicacin refleje las restricciones que existen en el negocio dado, de modo que
nunca sea posible llevar a cabo acciones no vlidas. A las reglas que debe seguir
la aplicacin 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 nmeros de celular no registrados

Limitar el servicio telefnico por falta de pago

En realidad, la informacin 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 tcnico, que est
interesado en relacionar diversos parmetros de produccin con los costes.

La visin que ambos departamentos tendrn de la informacin y sus necesidades

sern distintas, pero en cualquier caso siempre se debern respetar las reglas de
negocio. El hecho de que la informacin sea manipulada por diversos programas
hace ms difcil garantizar que todos respetan las reglas, especialmente si las
aplicaciones corren en diversas mquinas, bajo distintos sistemas operativos, y
estn desarrolladas con distintos lenguajes y herramientas.

Ejemplo: Considere el diagrama entidad relacin que a continuacin se expone y

su correspondiente traduccin 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 informacin dada es

correcta, al cumplir ciertas aserciones.

Las restricciones de integridad aseguran que la informacin 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 gestin de base de datos (SGBD)

relacional que permite la definicin de restricciones de integridad dentro del diseo
de su base de datos al ser creada.

Las restricciones de integridad aseguran que la informacin contenida en la base

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

Existen dos tipos de restricciones:

Estticas: limitan los estados permitidos de la Base de Datos.

Dinmicas: restringen las posibles transiciones de estados de la base datos.

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

pueden realizarse:

Aadiendo cdigo 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 definicin en la fase de diseo de las restricciones de integridad proporciona

mayor nmero de ventajas, ya que:

Reduce el costo de desarrollo de software.

Es ms confiable al ser centralizado y uniforme.

Mantenimiento ms fcil.

De acuerdo con la forma de especificacin del comando CREATE TABLE dada

anteriormente, la clusula CONSTRAINT puede entonces tener las siguientes
formas:

<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 (<condicin>)
CONSTRAINT

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 .
<condicin> es una expresin lgica en SQL.

En el manual de referencia de SQL usted podr encontrar informacin sobre las

reglas de formacin de expresiones lgicas de SQL.

Un punto importantsimo a destacar es el de garantizar que los nombres de los

CONSTRAINT sean nemnicos. Toda vez que un CONSTRAINTsea violado, el
SGBD generar un mensaje de error indicando el CONSTRAINT que ha fallado.
Asignar nombres nemnicos permitir hacer la depuracin de programas y la
carga de datos mucho ms sencilla, adems de garantizar una perfecta cohesin
entre el esquema de implantacin y la documentacin del esquema lgico.

Es as como se sugiere utilizar el siguiente estndar 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 fornea 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 restriccin 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 restriccin explcita, descrita a
travs de una restriccin de tipo CHECK, de una tabla <table_name> use
EXP_<table_name>__R<constraint_number> como nombre del constraint
constraint_number> representar el nmero de restriccin explcita asociado en la
documentacin 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 continuacin se indica:
ALTER TABLE <table_name> ADD (<table_constraint> [,<table_constraint>]);
Permitir agregar una o ms CONSTRAINT a la tabla existente en la base de
datos. Cada uno de los CONSTRAINT que se aaden a la tabla seguirn las
convenciones sintcticas de la clusula <table_constraint>.
ALTER TABLE <table_name> DROP CONSTRAINT <constraint_name>
[CASCADE];
Eliminar de la tabla la restriccin <constraint_name>.

Si se utiliza la clusula CASCADE, la eliminacin 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 eliminarn losCONSTRAINT de clave
fornea que referencien a A.
SOBRE LMITES

ORACLE impone los siguientes lmites en lo que respecta a los objetos descritos
en esta seccin:

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

nombre de "constraints", entre otros) se limita a un mximo de 30 caracteres.

El nmero mximo de columnas que puede tener una tabla es de 1000.

El nmero mximo de columnas que pueden constituir una clave primaria, una
clave alterna o una clave fornea es de 16.

Ejemplo: Torneo Primera Divisin Federacin 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
nombreEstadio
direccion
codigoPostal
ciudad
fechaInaguracion
capacidad
foto

CONSTRAINT
);

INTEGER(3),
CHAR(25) NOT NULL,
CHAR(35) NOT NULL,
INTEGER(5),
CHAR(30) NOT NULL,
DATE,
INTEGER NOT NULL,
CHAR(30),
PK_Estadio PRIMARY KEY (idEstadio)

CREATE TABLE equipo (

idEquipo INTEGER,
nombreEquipo
CHAR(25) NOT
seudonimo
CHAR(25) NOT
nombre_oficial CHAR(60) NOT
direccion
CHAR(35) NOT
codigoPostal
INTEGER(5),
ciudad
CHAR(30) NOT

NULL,
NULL,
NULL,
NULL,

NULL,
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 investigacin del Tecnolgico Virtual ha
diseado una base de datos (BD) para la gestin de los proyectos de investigacin
en los que participan sus investigadores.
Se presenta a continuacin el diagrama Entidad Relacin propuesto mismo que es
perfectible. Si lo hace justique sus cambios.

DROP
DROP
DROP
DROP
DROP

TABLE
TABLE
TABLE
TABLE
TABLE

asignado
proyecto
linea
investigador
depAcademico

CREATE TABLE

CASCADE
CASCADE
CASCADE
CASCADE
CASCADE

CONSTRAINTS;
CONSTRAINTS;
CONSTRAINTS;
CONSTRAINTS;
CONSTRAINTS;

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

CREATE TABLE

linea

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
REFERENCES linea (idLinea)

FOREIGN KEY (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));