[SGBD] Sentencias DDL – Restricciones al crear tablas

Cuando creamos una tabla que forma parte de una base de datos, esta debe cumplir una serie de normas o restricciones para su existencia (claves primarias, ajenas, obligatoriedad de valores en campos, valores por defecto, etc.), las cuales se definen en la sentencia explicada en el anterior punto, la orden CREATE. Podemos englobar dichas restricciones en dos grupos:

  • Restricciones de atributo: que son las propias de cada columna (o atributo) y que se especificaran una a una (por ejemplo, si un campo no puede tener valores nulos llevará la restricción NOT NULL).
  • Restricciones de tablas: aquellas que afectan o pueden afectar a más de un atributo y que se especificaran al final de la tabla (claves primarias, ajenas, etc.), aunque bien es cierto que podrían especificarse a nivel de atributo. Esto ya será a elección del programador.

Pongamos un ejemplo: supongamos que tenemos que crear la tabla EMPLEADO con los campos NOMBRE (clave primaria), EDAD (que debe cumplir la restricción de ser menor de 60) y CODPROV (que es código de provincia, clave ajena de la tabla PROVINCIA). La orden sería:

Expliquemos ahora dicha sentencia:

  • A pesar de ponerlo, en el campo NOMBRE no es necesario implementar la sentencia NOT NULL, ya que una clave primaria jamás puede contener valores nulos. Aún así, no pasa nada por especificarlo.
  • La palabra clave CONSTRAINT se utiliza para indicar las posibles restricciones de la tabla.
  • Tanto PK_EMPLEADO como FK_EMPLEADO es el nombre que nosotros le asignamos a las restricciones para que en caso de error, cuando ORACLE nos avise del mismo sepamos donde se ha producido. Si no especificamos nombre no pasa nada, ya que el sistema le otorgará uno de tipo “ORA-02437“. Obviamente, aprenderse estos códigos resulta más tedioso que asignarles nosotros un nombre. Yo, a nivel personal, suelo especificar si se trata de una PRIMARY KEY (PK) FOREIGN KEY (FK), seguido de un guión bajo y el nombre de la tabla. Después se especifica si es clave primaria o ajena y el campo al que está afectando.
  • En el caso de las claves ajenas, debemos especificar también a que tabla y campo hace referencia dicha clave. Hay que tener en cuenta que en este caso, podemos optar por poner el atributo de la tabla origen solo si difiere del nombre en la actual tabla. Por ejemplo, si en la tabla PROVINCIA el campo es CODPROV pero en la tabla EMPLEADO se llama CD_PROV habría que especificar tabla y campo. En caso de tener el mismo nombre no es necesario, aunque a título personal prefiero ponerlo siempre.

 Otra forma válida de escribir la sentencia anterior sería:

Como vemos, las restricciones de clave primaria o ajena pueden establecerse tanto a nivel a nivel de atributo como a nivel de tabla. Ya es cuestión del programador.

Veamos ahora los distintos tipos de restricciones que podemos encontrar en SQL:

  1. Restricción de clave primaria (PRIMARY KEY) – Solo puede definirse una clave primaria por tabla, la cual puede estar formada por uno o varios atributos (lo que llamamos, clave compuesta). Cuando se crea una clave primaria, se genera un índice para acceder a la tabla de manera más sencilla.
  2. Restricción de clave ajena (FOREIGN KEY) – Una clave ajena está formada por uno o varios atributos asociados a una clave primaria de otra tabla (o incluso de la misma, en el caso de las relaciones reflexivas). En una tabla pueden aparecer varias claves ajenas, si dicha tabla hace referencia a varias tablas (es el caso de las relaciones N:M, donde la clave primaria de ambas tablas se propagan hacia una nueva tabla de la propia relación).
  3. Restricción NOT NULL. Esta restricción se asocia o no a nivel de atributo; su significado es simple: controla si dicho atributo puede contener campos vacíos o debe tener obligatoriamente un valor.
  4. Restricción valores por defecto (DEFAULT) – En el momento de crear una tabla, podemos asignarles valores por defecto a sus atributos (por ejemplo, si queremos que un atributo de la tabla PROFESOR llamado CARGO siempre tenga por defecto el valor ‘Tutor’.
  5. Restricción de valores no repetidos (UNIQUE) – Esta restricción evita valores repetidos en un atributo. Por ejemplo, supongamos que tenemos la tabla PROFESOR, cuya clave primaria es CÓDIGOPROFESOR; además, queremos guardar el DNI de todos los profesores. Este campo debe ser único, ya que no puede haber dos personas con el mismo DNI.
  6. Restricción de verificación de condiciones (CHECK) – Algunos atributos necesitan valores limitados dentro de un rango o el cumplimiento de ciertas condiciones. Para ello, se utiliza la palabra reservada CHECK seguida de la condición que debe cumplir entre paréntesis. Para esta restricción, son muy útiles los operadores BETWEEN e IN visto en entradas anteriores.

Podríamos reunir todas estas opciones vistas en una sola tabla:

Donde:

  • CODPROFESOR – Es el código del profeso y es de tipo número.
  • NOMBRE – Es el nombre del profesor y es de tipo Varchar2; no puede contener valores nulos.
  • EDAD – Es la edad del profesor y es de tipo numérico. Debe estar comprendida entre 18 y 65.
  • INGLES – Se refiere a si el profesor sabe inglés. Solo admite como valor ‘Si’ o ‘No’.
  • DNI – Es el DNI del profesor; debe ser único.
  • CARGO – El cargo que desempeña el profesor ese curso. Por defecto, será tutor.
  • FECHAALTA – Es de tipo fecha (date) y por defecto introducirá la fecha del día actual.
  • CODCLASE – Es el código que identifica la clase.
  • PK_PROFESOR – Es una restricción que declara que la clave primaria de dicha tabla es el atributo CODPROFESOR.
  • FK_PROFESOR – Es una restricción que declara que la clave ajena de dicha tabla es el atributo CODCLASE, el cual hace referencia a la tabla CLASE, cuyo atributo que actúa como clave primaria se llama igual.

28 años | Entrenador de fútbol | Informático&Web Design | Linuxero | Componente de @chirigotaninos | Creador de http://todobytes.es & http://sudosu.es | Apasionado de la historia

Facebook Twitter Google+ YouTube 

Related posts

One Thought to “[SGBD] Sentencias DDL – Restricciones al crear tablas”

  1. […] ya vimos en un capítulo anterior, es posible que nuestras tablas creadas tengan una serie de restricciones que contribuyan a una […]

Leave a Comment