Según el DRAE, un modelo es, entre otras definiciones, el esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja. Podemos decir que es la representación de cualquier aspecto o tema extraído del mundo real.

¿Qué sería entonces un modelo de datos? Aquél que nos permite describir los elementos que intervienen en una realidad o en un problema dado y la forma en que se relacionan dichos elementos entre sí.

Contextualizando, un modelo de datos es por tanto un conjunto de métodos y reglas que indican cómo se ha de almacenar la información y cómo se han de manipular los datos.

En informática, el modelo de datos se implementa con un lenguaje utilizado para la descripción de una base de datos. Con este lenguaje vamos a poder describir las estructuras de los datos (tipos de datos y relaciones entre ellos), las restricciones de integridad (condiciones que deben cumplir los datos, según las necesidades de nuestro modelo basado en la realidad) y las operaciones de manipulación de los datos (insertado, borrado, modificación de datos).

Ese lenguaje, por lo general, presenta dos sublenguajes:

• Lenguaje de Definición de Datos o DDL (Data Definition Language ) , cuya función es describir, de una forma abstracta, las estructuras de datos y las restricciones de integridad.
• Lenguaje de Manipulación de Datos o DML (Data Manipulation Language), que sirve para describir las operaciones de manipulación de los datos.

Existen tres fases de modelado en el diseño de una base de datos basadas en el nivel de abstracción, es decir, en lo alejado que esté del mundo real y que deben ser realizadas en orden:

1. Modelo de datos conceptual: Se utiliza en el diseño conceptual. Es una representación (normalmente gráfica) de la realidad no comprometida con ningún entorno informático. Describen las estructuras de datos y restricciones de integridad. Se utilizan durante la etapa de análisis de un problema dado, y están orientados a representar los elementos que intervienen y sus relaciones. Es una fase muy importante ya que cualquier error en esta fase es arrastrado a las siguientes.
   Ejemplo, Modelo Entidad-Relación.

2.  Modelo Lógico: Se utiliza en el diseño lógico. Determinan unos criterios de almacenamiento (formas de almacenar la información) y de operaciones de manipulación de datos dentro de un tipo de entorno informático. Los S.G.B.D. comerciales se basan en un modelo lógico concreto. Ejemplo, Modelo Relacional.

3. Modelo Físico: Se utiliza en el diseño físico. Es la implementación física del modelo anterior. Son estructuras de datos a bajo nivel, implementadas dentro de un sistema gestor de base de datos comercial, por ej. Oracle, mysql, etc,,

Los SGBD comerciales se basan en un modelo lógico concreto. Por ej. Oracle en el modelo relacional.

¿Sabes que el modelo relacional te va a permitir representar la información del mundo real de una manera intuitiva? Así es, pudiendo introducir conceptos cotidianos y fáciles de entender por cualquiera, aunque no sea experto en informática.

El modelo relacional fue propuesto por Edgar Frank Codd en los laboratorios de IBM en California. Como hemos visto, se trata de un modelo lógico que establece una estructura sobre los datos, independientemente del modo en que luego los almacenemos. Es como si guardamos nuestra colección de libros, dependiendo del número de habitaciones que tenga en casa, del tamaño y forma de nuestras estanterías, podremos disponer nuestros libros de un modo u otro para facilitarnos el acceso y consulta. Los libros serán los mismos pero puedo disponerlos de distinta forma.

Es importante recordar que el diseño de las tablas del modelo relacional es la segunda fase del diseño de la base de datos y previamente se ha realizado el diseño conceptual identificando, tras el análisis,  las tablas o relaciones resultantes, sus atributos, restricciones y relaciones. 

El nombre de modelo relacional viene de la estrecha relación entre el elemento básico de este modelo y el concepto matemático de relación. Si tenemos dos conjuntos A y B, una relación entre estos dos conjuntos sería un subconjunto del producto cartesiano AxB.

El producto cartesiano nos dará la relación de todos los elementos de un conjunto con todos los elementos de los otros conjuntos de ese producto. Al estar trabajando con conjuntos, no puede haber elementos repetidos.

Por ejemplo para los dos conjuntos que se presentan en la imagen, uno denominado Marcas que contiene marcas de coches y otro denominado Modelos que contiene diferentes modelos el resultado de la operación de producto cartesiano será la combinación de todos los elementos de un conjunto con los del otro.

A partir de ahora, nosotros veremos una relación como una tabla con filas y columnas. Podemos asociar atributos a columnas y tuplas a filas. 

• Atributos: es el nombre de cada dato que se almacena en la relación (tabla). En la tabla Alumnos, que se muestra a la derecha, los atributos o columnas serían  DNI, nombre y  apellidos..

  El nombre del atributo debe describir el significado de la información que representa. En la tabla Empleados, el atributo Sueldo almacenará el valor en euros del sueldo que recibe cada empleado. A veces es necesario añadir una pequeña descripción para aclarar un poco más el contenido. Por ejemplo, si el sueldo es neto o bruto.

• Tuplas: Se refiere a cada elemento de la relación o tabla. En la tabla alumnos hay 5 tuplas con los atributos  DNI, nombre y apellidos de cada uno de los alumnos..

  Cada una de las filas de la tabla se corresponde con la idea de registro y tiene que cumplir que:

  • Cada tupla se debe corresponder con un elemento del mundo real.
  • No puede haber dos tuplas iguales (con todos los valores iguales).

Está claro que un atributo en una tupla no puede tomar cualquier valor. No sería lógico que en un atributo Población se guarde "250€". Estaríamos cometiendo un error, para evitar este tipo de situaciones obligaremos a que cada atributo sólo pueda tomar los valores pertenecientes a un conjunto de valores previamente establecidos, es decir, un atributo tiene asociado un dominio de valores.

A menudo un dominio se define a través de la declaración de un tipo para el atributo (por ejemplo, diciendo que es un número entero entre 1 y 16), pero también se pueden definir dominios más complejos y precisos. Por ejemplo, para el atributo Sexo de los usuarios, podemos definir un dominio en el que los valores posibles sean "M" o "F" (masculino o femenino).

Una característica fundamental de los dominios es que sean atómicos, es decir, que los valores contenidos en los atributos no se pueden separar en valores de dominios más simples.

Un dominio debe tener: Nombre, Definición lógica, Tipo de datos y Formato.

Por ejemplo, si consideramos el Sueldo de un empleado, tendremos:

• Nombre: Sueldo.
• Definición lógica: Sueldo neto del empleado
• Tipo de datos: número entero.
• Formato: 9.999€.

Llamaremos grado al tamaño de una tabla en base a su número de atributos (columnas). Mientras mayor sea el grado, mayor será la complejidad para trabajar con ella.

¿Y cuántas tuplas (filas o registros) puede tener?

Llamaremos cardinalidad al número de tuplas o filas de una relación o tabla.

Vamos a verlo con un ejemplo. Dadas las relaciones

 A={Carlos, María}, B={Matemáticas, Lengua}, C={Aprobado, Suspenso}.

Las posibles relaciones que obtenemos al realizar el producto cartesiano AxBxC da como resultado una relación de grado 3, ya que tiene 3 columnas 

Si cogemos un subconjunto de ésta con 5 filas, tendríamos una relación de cardinalidad 5. Por ej.

Los términos vistos hasta ahora tienen distintos sinónimos según la nomenclatura utilizada. Trabajaremos con tres:

• En el modelo relacional: RELACIÓN - TUPLA - ATRIBUTO - GRADO - CARDINALIDAD.
• En tablas: TABLA - FILA - COLUMNAS - NÚMERO COLUMNAS - NÚMERO FILAS.
• En términos de registros: FICHEROS - REGISTROS - CAMPOS - NÚMERO CAMPOS - NÚMERO REGISTROS.

¿En un modelo relacional se puede utilizar cualquier relación? ¿Es válida cualquier tabla o se deben cumplir algunas propiedades?

Debes saber que:

• Cada tabla tiene un nombre distinto.

  

• Como hemos visto antes, cada atributo (columna) de la tabla toma un solo valor en cada tupla (fila).
• Cada atributo (columna) tiene un nombre distinto en cada tabla (pero puede ser el mismo en tablas distintas).
• No puede haber dos tuplas (filas) completamente iguales.

  

• El orden de las tuplas (filas) no importa.

  

• El orden de los atributos (columnas) no importa.

  

• Todos los datos de un atributo (columna) deben ser del mismo dominio.Si hemos definido que el dominio del atributo Nota sólo admite los valores Aprobado o Suspenso entonces el dato NOTABLE sería incorrecto ya que no pertenece al dominio.

  

Existen varios tipos de relaciones o tablas y las vamos a clasificar en:

• Persistentes: Sólo pueden ser borradas por los usuarios. 
  • Base: Independientes, se crean indicando su estructura y sus ejemplares (conjunto de tuplas o filas).

  • Vistas: son tablas que sólo almacenan una definición de consulta, resultado de la cual se obtiene datos que proceden de otras tablas base o de otras vistas e instantáneas. Si los datos de las tablas base cambian, los de la vista que utilizan esos datos también cambiarán ya que se obtienen a partir de ellas.

  • Instantáneas: son vistas (se crean de la misma forma) pero sí almacenan los datos que muestran, además de la consulta que la creó. Solo modifican su resultado cuando el sistema se refresca cada cierto tiempo. Es como una fotografía de la relación, que sólo es válida durante un periodo de tiempo concreto.

• Temporales: Son tablas que son eliminadas automáticamente por el sistema.

¿Qué es un DNI? ¿Con qué datos lo representamos? El DNI es una información que es susceptible de ser guardada. Normalmente el DNI está formado por dígitos y una letra al final. Si tuviéramos que clasificarlo diríamos que es un conjunto de caracteres alfanuméricos. ¿Y si pensamos en Sueldo? Aquí lo tenemos un poco más claro, evidentemente es un número entero o con decimales.

Hasta ahora hemos visto que vamos a guardar información relacionada en forma de filas y columnas. Las columnas son los atributos o información que nos interesa incluir del mundo real que estamos modelando.

Hemos visto que esos atributos se mueven dentro de un dominio, que formalmente es un conjunto de valores. Pues bien, en términos de sistemas de base de datos, se especifica indicando el tipo de dato (de forma general) y el conjunto de valores que puede tomar (de forma restringida). El conjunto de valores restringidos se le indicará en la definición de la tabla si el SGBD lo permite. 

Por ejemplo para un atributo que va a guardar el género (M masculino o F femenino), el tipo de datos será carácter o texto de longitud 1. Los valores posibles M o F se indicarán en la definición de la tabla.

Al crear la relación (tabla) decidimos qué conjunto de datos deberá ser almacenado en los atributos de las filas. Tenemos que asignar un tipo de dato a cada atributo.

Con la asignación de tipos de datos, también habremos seleccionado un dominio para cada atributo. 

Cada campo:

• debe poseer un Nombre (relacionado con los datos que va a contener) y
• debe tener asociado un Tipo de dato que determinará qué valores puede tomar y qué operaciones se pueden realizar con ellos.

Existen distintas formas de nombrar los tipos de datos dependiendo del lenguaje que utilicemos (C, Java, PHP, MySQL, SQL, Pascal, etc.).

Veamos cuales son los tipos de datos más comunes y habituales, existentes en la mayoría de los lenguajes, que posteriormente se definirán utilizando la sintaxis específica del  lenguaje elegido.

• Texto: almacena cadenas (conjunto) de caracteres: números con los que no vamos a realizar operaciones matemáticas, letras o símbolos.
• Numérico: almacena números. Si dudamos entre numérico o texto tendremos en cuenta si vamos a realizar operaciones matemáticas con ellos, en cuyo caso será numérico.
• Fecha/hora: almacena fechas y horas.
• Sí/No: almacena datos que solo tienen dos posibilidades (verdadero/falso).
• Autonumérico: se puede considerar un subtipo de Numérico ya que almacena valores numéricos secuenciales que el SGBD incrementa de modo automático al añadir un registro (fila).
• Memo: almacena texto largo (mayor que un tipo texto).
• Moneda:  pero con una característica especial, y es que los valores representan cantidades de dinero.
• Objeto OLE: almacena gráficos, imágenes o textos creados por otras aplicaciones.

Para determinar qué tipo de dato se asocia a cada atributo se tiene en cuenta el conjunto de valores que puede tomar y las operaciones que hay que realizar con él.

Un código postal, por ejemplo 06800, a pesar de estar formado por dígitos numéricos, es mejor definirlo como una cadena de 5 caracteres por dos motivos: porque no se va a realizar operaciones matemáticas con él y porque los ceros a la izquierda no deben ser obviados como si fuera numérico. El número de teléfono se encuentra en un caso similar.

Es fundamental determinar de forma correcta el tipo de dato y tamaño para cada atributo, ya que si se define mal, no permitirá almacenar la información deseada o puede que almacene información incompleta. Por ejemplo, si se define de un tamaño o longitud inferior al valor que va a contener. Supongamos que nos precipitamos y definimos el DNI como un campo de tipo cadena de 8 caracteres; si se quiere registrar el  DNI 89234432B que tiene 9 caracteres, es posible que el sistema lo almacene mal, dejando atrás el carácter sobrante. De ahí la importancia de este proceso. 

¿Cómo diferenciamos unos usuarios de otros? ¿Cómo sabemos que no estamos recogiendo la misma información? ¿Cómo vamos a distinguir unas tuplas de otras? Lo haremos mediante los valores de sus atributos. Para ello, buscaremos un atributo o un conjunto de atributos que identifiquen de modo único las tuplas (filas) de una relación (tabla). A ese atributo o conjunto de atributos lo llamaremos superclaves.

Hemos visto que una característica de las tablas era que no puede haber dos tuplas (filas) completamente iguales, con lo que podemos decir que toda la fila como conjunto sería una superclave.

Por ejemplo, en la tabla Usuarios tenemos las siguientes superclaves:

• {Nombre, Apellidos, login, e_mail, F_nacimiento}
• {Nombre, Apellidos, login, e_mail}
• {login, e_mail}
• {login}

Tendríamos que elegir alguna de las superclaves para diferenciar las tuplas. En el modelo relacional trabajamos con tres tipos de claves:

• Claves candidatas.
• Claves primarias.
• Claves alternativas.
• Claves ajenas.

A continuación veremos cada una de ellas.

Si puedo elegir entre tantas claves, ¿con cuál me quedo? Tendremos que elegir entre las claves "candidatas" la que mejor se adapte a mis necesidades. ¿Y cuáles son éstas? Las claves candidatas serán aquel conjunto de atributos que identifiquen de manera única cada tupla (fila) de la relación (tabla). Es decir, las columnas cuyos valores no se repiten en ninguna otra fila de la tabla. Por tanto, cada tabla debe tener al menos una clave candidata aunque puede haber más de una.

Siguiendo con nuestro ejemplo, podríamos considerar los atributos Login o E_mail como claves candidatas, ya que sabemos que el Login debe ser único para cada usuario, a E_mail le sucede lo mismo. Pero también cabe la posibilidad de tomar: Nombre, Apellidos y F_nacimiento, las tres juntas como clave candidata.

Las claves candidatas pueden estar formadas por más de un atributo, siempre y cuando éstos identifiquen de forma única a la fila. Cuando una clave candidata está formada por más de un atributo, se dice que es una clave compuesta.

Una clave candidata debe cumplir los siguientes requisitos:

• Unicidad: no puede haber dos tuplas (filas) con los mismos valores para esos atributos.
• Irreductibilidad: si se elimina alguno de los atributos deja de ser única.

Si elegimos como clave candidata Nombre, Apellidos y F_nacimiento, cumple con la unicidad puesto que es muy difícil encontrarnos con dos personas que tengan el mismo nombre, apellidos y fecha de nacimiento iguales. Es irreductible puesto que sería posible encontrar dos personas con el mismo nombre y apellidos o con el mismo nombre y fecha de nacimiento, por lo que son necesarios los tres atributos (campos) para formar la clave.

Para identificar las claves candidatas de una relación no nos fijaremos en un momento concreto en el que vemos una base de datos. Puede ocurrir que en ese momento no haya duplicados para un atributo o conjunto de atributos, pero esto no garantiza que se puedan producir. El único modo de identificar las claves candidatas es conociendo el significado real de los atributos (campos), ya que así podremos saber si es posible que aparezcan duplicados. Es posible desechar claves como candidatas fijándonos en los posibles valores que podemos llegar a tener. Por ejemplo, podríamos pensar que Nombre y Apellidos podrían ser una clave candidata, pero ya sabemos que cabe la posibilidad de que dos personas puedan tener el mismo Nombre y Apellidos, así que lo descartamos.

Hasta ahora, seguimos teniendo varias claves con la que identificamos de modo único nuestra relación. De ahí el nombre de candidatas. Hemos de quedarnos con una.

La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave primaria estará formada por todos los atributos de la relación, pero normalmente habrá un pequeño subconjunto de los atributos que haga esta función. En otros casos, podemos crear un campo único que identifique las tuplas, por ejemplo un código de usuario, que podrían estar constituidos por valores autonuméricos.

Las claves candidatas que no son escogidas como clave primaria son denominadas claves alternativas.

Si en nuestra tabla Usuarios escogemos Login como clave primaria, el E_mail o {Nombre, Apellidos, F_Nacimiento} serán nuestras claves alternativas.

Hasta ahora no nos hemos planteado cómo se relacionan unas tablas con otras dentro de una base de datos. Si tenemos las tablas Usuarios y Partidas, necesariamente habrá una "relación" entre ellas. Deben compartir algún dato en común que las relacione. Una partida es jugada por un jugador (Usuarios), por lo que en la tabla Partida deberíamos guardar algún dato del usuario-jugador, pero ¿cuál?

Una clave ajena, también llamada externa, foránea o secundaria, es un atributo o conjunto de atributos de una relación cuyos valores coinciden con los valores de la clave primaria de alguna otra relación (o de la misma). Las claves ajenas representan relaciones entre datos. Dicho de otra manera, son los datos de atributos de una tabla cuyos valores están relacionados con atributos de otra tabla.

En la tabla Partidas, se recogen datos como Cod_partida, Fecha y Hora de creación, Nombre de la partida, etc. ¿Qué campo utilizaremos para relacionarla con la tabla Usuarios? Si nos basamos en la definición, deberíamos utilizar la clave primaria de la tabla Usuarios. Por tanto, el atributo Login que es la clave principal en su tabla aparecerá en la tabla Partidas como clave ajena, externa o secundaria. El Login en Partidas hace referencia a cada jugador que juega esa partida. En lugar de guardar todos los datos de ese jugador en la misma tabla, lo hacemos en otra y lo "referenciamos" por su clave primaria tomándola como ajena.

Es lógico que las claves ajenas no tengan las mismas propiedades y restricciones que tienen como clave primaria en su tabla, por tanto, sí que pueden repetirse en la tabla. En nuestro ejemplo, un mismo jugador puede jugar varias partidas.

Las claves ajenas tienen por objetivo establecer una conexión con la clave primaria que referencian. Por lo tanto, los valores de una clave ajena deben estar presentes como clave primaria  en la tabla a la que hacen referencia , o bien deben ser valores nulos. En caso contrario, la clave ajena representaría una referencia o conexión incorrecta, lo que supondría que la información almacenada es inconsistente (no fiable). Imagina un código de jugador en la tabla Partidas que no se corresponde con ningún jugador de la tabla Usuarios.

No podemos tener una partida de un jugador que previamente no se ha registrado y no existe en la tabla Usuarios. Pero sí podemos tener los datos de una partida y desconocer el jugador de ésta, es decir  la columna jugador puede tener el valor nulo (sin valor).

Imagina que estás creando un diccionario de términos informáticos. Podrías elegir la opción de escribirlo en una única hoja muy larga (estilo pergamino) o bien distribuirlo por hojas. Está claro que lo mejor sería distribuirlo por páginas. Y si buscamos el término "informática" en nuestro diccionario, podríamos comenzar a buscar en la primera página y continuar una por una hasta llegar a la palabra correspondiente. O bien crear un índice al principio, de manera que podamos consultar a partir de qué página podemos localizar las palabras que comienzan por "i". Esta última opción parece la más lógica.

Pues bien, en las bases de datos, cada tabla se divide internamente en páginas de datos, y se define el índice a través de un campo (o campos) y es a partir de este campo desde donde se busca.

Un índice es una estructura de datos que permite acceder a diferentes filas de una misma tabla a través de un campo o campos . Esto permite un acceso mucho más rápido a los datos.

Los índices son útiles cuando se realizan consultas frecuentes a un rango de filas o una fila de una tabla. Por ejemplo, si consultamos los usuarios cuya fecha de ingreso es anterior a una fecha concreta.

Los cambios en los datos de las tablas (agregar, actualizar o borrar filas) son incorporados automáticamente a los índices con transparencia total.

Debes saber que los índices son independientes, lógica y físicamente de los datos, es por eso que pueden ser creados y eliminados en cualquier momento, sin afectar a las tablas ni a otros índices.

¿Cuándo indexamos? No hay un límite de columnas a indexar, si quisiéramos podríamos crear un índice para cada columna, pero no sería operativo. Normalmente tiene sentido crear índices para ciertas columnas ya que agilizan las operaciones de búsqueda de base de datos grandes. Por ejemplo, si la información de nuestra tabla Usuarios se desea consultar por apellidos a menudo y se necesita agilidad en los accesos,  tiene sentido indexar por esa columna. No conviene indexar por columnas de gran tamaño porque puede resultar contraproducente.

Al crear índices, las operaciones de modificar o agregar datos se ralentizan, ya que al realizarlas es necesario actualizar tanto la tabla como el índice. Por tanto hay que pensar bien cuándo interesa definir o no un índice.

Si se elimina un índice, el acceso a datos puede ser más lento a partir de ese momento.

El SGBD utiliza índices para la gestión de las claves ajenas y de las claves primarias. En el caso de las claves primarias serán índices únicos (no admiten valores repetidos).

¿Qué sucede si al guardar los datos de los Usuarios hay algún dato que no tengo o no necesito guardarlo porque no corresponde?

Independientemente del dominio al que pertenezca un campo, éste puede tomar un valor especial denominado NULO (NULL en inglés) que designará la ausencia de dato.

Cuando por cualquier motivo se desconoce el valor de un campo, por ejemplo, desconocemos el teléfono del usuario, o bien ese campo carece de sentido (siguiendo con el mismo ejemplo, puede que el usuario no tenga teléfono), podemos asignar a ese campo el valor especial NULO.

Cuando trabajamos con claves secundarias el valor nulo indica que la tupla o fila no está relacionada con ninguna otra tupla o fila. Este valor NULO es común a cualquier dominio.

Un ordenador tomará un espacio en blanco como un carácter como otro cualquiera. Por tanto, si introducimos el carácter "espacio en blanco" estaríamos introduciendo un valor que pertenecería al dominio texto y sería distinto al concepto "ausencia de valor" que sería no incluir nada (nulo).

Este valor se va a utilizar con frecuencia en las bases de datos y es imprescindible saber cómo actúa cuando se emplean operaciones lógicas sobre ese valor. En la lógica booleana tenemos los valores VERDADERO y FALSO, pero un valor NULO no es ni verdadero ni falso.

Cuando necesitemos comparar dos campos, si ambos son nulos no podremos obtener ni verdadero ni falso. Necesitaremos definir la lógica con este valor. Veamos los operadores lógicos más comunes y sus resultados utilizando el valor nulo:

• VERDADERO Y (AND) NULO daría como resultado NULO.
• FALSO Y (AND) NULO daría como resultado FALSO.
• VERDADERO O (OR) NULO daría como resultado VERDADERO.
• FALSO O NULO daría como resultado NULO.
• NO (NOT) NULO daría como resultado NULO.

En todas las bases de datos relacionales se utiliza un operador llamado  IS NULL (ES NULO) que devuelve VERDADERO si el valor con el que se compara es NULO.

Cuando vimos los distintos tipos de relaciones, aprendimos que, entre otros, estaban las vistas. Ahora ya tenemos más conocimientos para comprender mejor este concepto.

Una vista es una tabla "virtual" cuyas filas y columnas se obtienen a partir de una o de varias tablas que constituyen nuestro modelo. Lo que se almacena no es la tabla en sí, sino su definición, por eso decimos que es "virtual". Una vista actúa como filtro de las tablas a las que hace referencia en ella.

La consulta que define la vista puede provenir de una o de varias tablas, o bien de otras vistas de la base de datos actual u otras bases de datos.

No existe ninguna restricción a la hora de consultar vistas pero sí hay algunas restricciones a la hora de modificar los datos de éstas establecidas para mantener la integridad y consistencia de los datos.

Podemos dar dos razones por las que queramos crear vistas:

• Seguridad, nos puede interesar que los usuarios tengan acceso a una parte de la información que hay en una tabla, pero no a toda la tabla.
• Comodidad, como veremos al pasar nuestras tablas/relaciones a un lenguaje de base de datos, puede que tengamos que escribir sentencias bastante complejas, las vistas no son tan complejas.

Las vistas no tienen una copia física de los datos, son sentencias de consultas a los datos que hay en las tablas, por lo que si actualizamos los datos de una vista, estamos actualizando realmente la tabla, y si actualizamos la tabla estos cambios serán visibles desde la vista.

Aunque no siempre podremos actualizar los datos de una vista, dependerá de la complejidad de la misma y del gestor de base de datos. No todos los gestores de bases de datos permiten actualizar vistas, Oracle, por ejemplo, no lo permite, mientras que SQL Server sí.

A la hora de conectarnos a la base de datos es necesario que utilicemos un modo de acceso, de manera que queden descritos los permisos de que dispondremos durante nuestra conexión. En función del nombre de usuario tendremos unos permisos u otros.

Un usuario es un conjunto de permisos que se aplican a una conexión de base de datos. 

Tiene además otras características: 

• Es el propietario de ciertos objetos (tablas, vistas, etc.).
• Realiza las copias de seguridad.
• Tiene asignada una cuota de almacenamiento.
• TIene asignado un tablespace por defecto para los objetos en Oracle.

Pero no todos los usuarios deberían poder hacer lo mismo cuando acceden a la base de datos. Por ejemplo, un administrador debería tener más privilegios que un usuario que quiere realizar una simple consulta.

¿Qué es un privilegio? No es más que un permiso dado a un usuario para que realice ciertas operaciones, que pueden ser de dos tipos:

• De sistema: necesitará el permiso de sistema correspondiente.
• Sobre objeto: necesitará el permiso sobre el objeto en cuestión.

¿Y no sería interesante poder agrupar esos permisos para darlos juntos? Para eso tenemos el rol.

Un rol de base de datos no es más que una agrupación de permisos de sistema y de objeto.

Podemos tener a un grupo determinado de usuarios que tengan permiso para consultar los datos de una tabla concreta y no tener permiso para actualizarlos. Luego un rol permite asignar un grupo de permisos a un usuario. De este modo, si asignamos un rol con 5 permisos a 200 usuarios y luego queremos añadir un permiso nuevo al rol, no tendremos que ir añadiendo este nuevo permiso a los 200 usuarios, ya que el rol se encarga de propagarlo automáticamente.

SQL (Structured Query Language ) es un lenguaje de dominio específico utilizado en programación, diseñado para administrar, y recuperar información de sistemas de gestión de bases de datos relacionales.es el lenguaje fundamental de los SGBD relacionales. Es uno de los lenguajes más utilizados en informática en todos los tiempos. Es un lenguaje declarativo y por tanto, lo más importante es definir qué se desea hacer, y no cómo hacerlo. De esto último ya se encarga el SGBD.

Hablamos por tanto de un lenguaje normalizado que nos permite trabajar con cualquier tipo de lenguaje (ASP o PHP) en combinación con cualquier tipo de base de datos (Access, SQL Server, MySQL, MariaDB, Oracle, etc.).

El hecho de que sea estándar no quiere decir que sea idéntico para cada base de datos. Así es, determinadas bases de datos implementan funciones específicas que no tienen necesariamente que funcionar en otras.

Aunque SQL está estandarizado, siempre es recomendable revisar la documentación del SGBD con el que estemos trabajando para conocer su sintaxis concreta, ya que algún comando, tipo de dato, etc., puede no seguir el estándar.

SQL posee dos características muy apreciadas, potencia y versatilidad, que contrastan con su facilidad para el aprendizaje, ya que utiliza un lenguaje bastante natural. Es por esto que las instrucciones son muy parecidas a órdenes humanas. Por esta característica se le considera un Lenguaje de Cuarta Generación.

Aunque frecuentemente oigas que SQL es un "lenguaje de consulta", ten en cuenta que no es exactamente solo eso ya que contiene muchas otras capacidades además de la de consultar la base de datos:

• la definición de la propia estructura de los datos (DDL)
• su manipulación (DML)
• y la especificación de conexiones seguras (DCL)

Por tanto, el lenguaje estructurado de consultas SQL es un lenguaje que permite operar con los datos almacenados en las bases de datos relacionales.

Se puede trabajar de dos formas con SQL:

• SQL embebido: las sentencias se escriben dentro de un programa escrito en otro lenguaje como Java, PHP,etc..
• SQL interpretado: Podemos usar un entorno gráfico para escribir y ejecutar las sentencias (nosotros utilizaremos SQLDeveloper) o bien desde SQL*Plus que es el programa de línea de comandos de Oracle que permite ejecutar  comandos SQL y  PL/SQL de forma interactiva. 

En la unidad 1 utilizaste SQLPlus para conectarte a la base de datos y crear tu usuario. Es importante que tengas soltura en su uso, aunque manejes de forma más habitual el interface gráfico SQLDeveloper,  ya que permite hacer más operaciones.

En el Anexo III de esta unidad y en el siguiente enlace tienes los pasos a seguir para descargarte e instalarte SQLDeveloper y dar los primeros pasos:

SQLDeveloper: Instalación y primeros pasos (pdf - 964 KB)

Imagínate que cada programador utilizara sus propias reglas para escribir. Esto sería un caos. Es muy importante establecer los elementos con los que vamos a trabajar y unas normas que seguir.

El lenguaje SQL está compuesto por comandos, cláusulas, operadores, funciones y literales . Todos estos elementos se combinan en las instrucciones o setencias y se utilizan para crear, actualizar y manipular bases de datos. Estos conceptos son bastante amplios por eso será mejor que vayamos por partes.

• COMANDOS: Van a ser las instrucciones que se pueden crear en SQL. Se pueden distinguir en tres grupos que veremos con más detenimiento a lo largo de las siguientes unidades:
  • De definición de datos (DDL, Data Definition Language), que permiten crear y definir nuevas bases de datos, tablas, campos, etc.
  • De manipulación de datos (DML, Data Manipulation Language), que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.
  • De control y seguridad de datos (DCL, Data Control Language), que administran los derechos y restricciones de los usuarios.
• CLÁUSULAS: Llamadas también condiciones o criterios, son palabras especiales que permiten modificar el funcionamiento de un comando.
• OPERADORES: Permiten crear expresiones complejas. Pueden ser aritméticos (+, -, *, /, ...) o lógicos (< , >, , < >, And, Or, etc.).
• FUNCIONES: Para conseguir valores complejos. Por ejemplo, la función promedio para obtener la media de un salario.
• LITERALES: Les podemos llamar también constantes y serán valores concretos, como por ejemplo un número, una fecha, un conjunto de caracteres, etc.

Y tendremos que seguir unas normas sencillas pero primordiales:

• Todas las instrucciones terminan con un signo de punto y coma.
• No se distingue entre mayúsculas y minúsculas.
• Cualquier comando puede ser partido con saltos de línea o espacios para facilitar su lectura y comprensión.
• Los comentarios comienzan por /* y terminan con */ (excepto en algunos SGBD).

Juan le ha dicho a Ana que es hora de ponerse a trabajar con la aplicación. Para aprender mejor le ha pedido permiso a Juan para instalar Oracle en su ordenador y así ir probando todo sobre la marcha para no cometer errores. El SQL estándar y el SQL de Oracle son bastante parecidos, pero con algunas diferencias.

La primera fase del trabajo con cualquier base de datos comienza con sentencias DDL, puesto que antes de poder almacenar y recuperar información debemos definir las estructuras donde almacenar la información. Las estructuras básicas con las que trabaja SQL son las tablas.

Conocer el Lenguaje de Definición de Datos (DDL) es imprescindible para crear, modificar y eliminar objetos de la base de datos (es decir, los metadatos). En el mercado hay suficientes aplicaciones y asistentes que nos facilitan esta labor, a través de una interfaz visual que nos oculta el lenguaje SQL y en los cuales nos limitamos a poner nombres a los campos, elegir el tipo de datos y activar una serie de propiedades.

Es cierto que estas herramientas nos facilitan el trabajo, pero resulta imprescindible comprender y conocer en profundidad el lenguaje, ya que nos veremos en muchas situaciones donde necesitaremos crear un objeto, modificarlo o eliminarlo sin depender de esas herramientas visuales.

En Oracle, cada usuario de una base de datos tiene un esquema, que tendrá el mismo nombre que el usuario con el que se ha accedido y sirve para almacenar los objetos que posea ese usuario.

¿De qué objetos estamos hablando? Éstos podrán ser tablas, vistas, índices u otros objetos relacionados con la definición de la base de datos. ¿Y quién puede crear y manipularlos? En principio el usuario propietario (el que los creó) y los administradores de la base de datos. Más adelante veremos que podemos modificar los privilegios de los objetos para permitir el acceso a otros usuarios.

Básicamente, la creación de la base de datos consiste en crear las tablas que la componen. Aunque antes de ésto tendríamos que definir un espacio de nombres separado para cada conjunto de tablas. Es lo que antes hemos llamado esquemas o usuarios.

Crear una base de datos implica indicar los archivos y ubicaciones que se van a utilizar además de otras indicaciones técnicas y administrativas. Es obvio que todo esto sólo lo puede realizar si se tiene privilegio de Administrador.

Con el estándar de SQL la instrucción a usar sería Create Database, pero cada SGBD tiene un procedimiento para crear las bases de datos. Crearíamos una base de datos con el nombre que se indique a continuación.

CREATE DATABASE NombredemiBasedeDatos;

Por ejemplo, a la base de datos que están creando Juan y Ana se le va a llamar RyMjuegos, entonces nos quedaría:

CREATE DATABASE RyMjuegos;

Hemos estado hablando de objetos de la base de datos, ahora veremos a qué nos referimos.

Según los estándares, una base de datos es un conjunto de objetos que nos servirán para gestionar los datos. Estos objetos están contenidos en esquemas y éstos a su vez suelen estar asociados a un usuario. De ahí que antes dijéramos que cada base de datos tiene un esquema que está asociado a un usuario. 

En oracle la sentencia "create database" tiene un sentido distinto a otros SGBD como Mysql.

Nosotros trabajaremos en oracle creando las tablas en el esquema del usuario creado previamente, es decir, no utilizaremos la sentencia "create database"

¿Qué necesitamos para poder guardar los datos? Lo primero será definir los objetos donde vamos a agrupar esos datos. Los objetos básicos con los que trabaja SQL son las tablas, que como ya sabemos es un conjunto de filas y columnas cuya intersección se llama celda. Es ahí donde se almacenarán los elementos de información, los datos que queremos recoger.

Antes de crear la tabla es conveniente tener a mano la siguiente información que se obtiene en la fase de diseño lógico de la BD

• Qué nombre le vamos a dar a la tabla.
• Qué nombre le vamos a dar a cada una de las columnas.
• Qué tipo y tamaño de datos vamos a almacenar en cada columna.
• Qué restricciones tenemos sobre los datos.
• Alguna otra información adicional que necesitemos.

Y debemos tener en cuenta otras reglas que se deben cumplir para los nombres de las tablas:

• No podemos tener nombres de tablas duplicados en un mismo esquema (usuario).
• Deben comenzar por un carácter alfabético.
• Su longitud máxima es de 30 caracteres.
• Solo se permiten letras del alfabeto inglés, dígitos o el signo de guión bajo.
• No puede coincidir con las palabras reservadas de SQL (por ejemplo, no podemos llamar a una tabla WHERE).
• No se distingue entre mayúsculas y minúsculas.
• En el caso de que el nombre tenga espacios en blanco o caracteres nacionales (permitido sólo en algunas bases de datos), entonces se suele entrecomillar con comillas dobles. En el estándar SQL99 (respetado por Oracle) se pueden utilizar comillas dobles al poner el nombre de la tabla a fin de hacerla sensible a las mayúsculas (se diferenciará entre "USUARIOS"y "Usuarios").

La sintaxis básica del comando que permite crear una tabla es la siguiente:

CREATE TABLE [esquema.] nombredeTabla ( 
columna1 Tipo_Dato,
columna2 Tipo_Dato, ...  
columnaN Tipo_Dato );

donde:

• columna1, columna2, ..., columnaN son los nombres de las columna que contendrá la tabla.
• Tipo_Dato indica el tipo de dato de cada columna.

Ana va a crear la primera tabla llamada USUARIOS con un solo campo de tipo VARCHAR:

CREATE TABLE USUARIOS (Nombre VARCHAR(25));

Recuerda que solo podrás crear tablas si posees los permisos necesarios para ello.

Hay veces que necesitamos que un dato se incluya en una tabla de manera obligatoria, otras veces necesitaremos definir uno de los campos como llave primaria o ajena. Todo esto podremos hacerlo cuando definamos la tabla, además de otras opciones.

Una restricción es una condición que una o varias columnas deben cumplir obligatoriamente.

Cada restricción que creemos llevará un nombre, si no se lo ponemos nosotros lo hará Oracle o el SGBD que estemos utilizando. Es conveniente que le pongamos un nombre que nos ayude a identificarla y que sea único para cada esquema (usuario). Es buena idea incluir de algún modo el nombre de la tabla, los campos involucrados y el tipo de restricción en el nombre de la misma. La sintaxis en SQL estándar es la siguiente: 

CREATE TABLE NOMBRETABLA (
     Columna1 Tipo_Dato
          [CONSTRAINT nombredelarestricción]
          [NOT NULL]
          [UNIQUE]
          [PRIMARY KEY]
          [FOREIGN KEY]
          [DEFAULT valor]
          [REFERENCES nombreTabla [(columna [, columna ])]
          [ON DELETE CASCADE]]
          [CHECK condición],
     Columna2 Tipo_Dato
          [CONSTRAINT nombredelarestricción]
          [NOT NULL]
          [UNIQUE]
          [PRIMARY KEY]
          [FOREIGN KEY]
          [DEFAULT valor]
          [REFERENCES nombreTabla [(columna [, columna ])]
          [ON DELETE CASCADE]]
          [CHECK condición],...);

Los corchetes, caracteres [ y ],  se utilizan en informática en  los formatos de la sintaxis de los lenguajes para especificar opcionalidad, es decir, está indicando que lo contiene se puede utilizar o no. 

Veamos un ejemplo: 

CREATE TABLE USUARIOS (
    Login VARCHAR(15) CONSTRAINT usu_log_PK PRIMARY KEY,
    Password VARCHAR (8) NOT NULL,
    Fecha_Ingreso DATE DEFAULT SYSDATE);

Otra opción es definir las columnas de la tabla y después especificar las restricciones, de este modo podrás referir varias columnas en una única restricción.

En los siguientes apartados veremos cada una de las restricciones, su significado y su uso.

Con esta restricción obligaremos a que esa columna tenga un valor o lo que es lo mismo, prohíbe los valores nulos para una columna en una determinada tabla.

Podremos ponerlo cuando creamos o modificamos el campo añadiendo la palabra NOT NULL después de poner el tipo de dato.

Si en la tabla USUARIOS queremos que el campo "F_Nacimiento" sea obligatorio ponerlo, nos quedaría así:

CREATE TABLE USUARIOS (
    F_Nacimiento DATE
    CONSTRAINT Usu_Fnac_NN NOT NULL);

o bien, de esta otra forma:

CREATE TABLE USUARIOS (
    F_Nacimiento DATE NOT NULL);

Habrá ocasiones en la que nos interese que no se puedan repetir valores en la columna, en estos casos utilizaremos la restricción UNIQUE. Oracle crea un índice automáticamente cuando se habilita esta restricción y lo borra al deshabilitarla.

También para esta restricción tenemos dos posibles formas de ponerla, veámoslo con un ejemplo. Supongamos que el campo Login de nuestra tabla va a ser único. Lo incluiremos en la tabla que estamos creando. Nos quedaría así:

CREATE TABLE USUARIOS (
    Login VARCHAR2 (25)
    CONSTRAINT Usu_Log_UK UNIQUE);

 Veamos otra forma:

CREATE TABLE USUARIOS (
    Login VARCHAR2 (25) UNIQUE);

 También podemos poner esta restricción a varios campos a la vez, por ejemplo, si queremos que Login y correo electrónico sean únicos podemos ponerlo así:

CREATE TABLE USUARIOS (
    Login VARCHAR2 (25),
    Correo VARCHAR2 (25),
    CONSTRAINT Usuario_UK UNIQUE (Login, Correo));

Si te fijas, detrás del tipo de datos de Correo hay una coma, eso es así porque la restricción es independiente de ese campo y común a varios. Por eso después de UNIQUE hemos puesto entre paréntesis los nombres de los campos a los que afecta la restricción.

En el modelo relacional las tablas deben tener una clave primaria. Es evidente que cuando creamos la tabla tendremos que indicar a quién corresponde.

Sólo puede haber una clave primaria por tabla pero ésta puede estar formada por varios campos. Dicha clave podrá ser referenciada como clave ajena en otras tablas.

La clave primaria hace que los campos que forman sean NOT NULL y que los valores de los campos sean de tipo UNIQUE.

Veamos como quedaría si la clave fuese el campo Login:

• Si la clave la forma un único campo:

CREATE TABLE USUARIOS (
	Login VARCHAR2 (25) PRIMARY KEY);

• O bien poniendo un nombre a la restricción:

CREATE TABLE USUARIOS (
     Login VARCHAR2 (25)
          CONSTRAINT Usu_log_PK PRIMARY KEY);

• Si la clave está formada por más de un campo, por ejemplo Nombre, Apellidos y Fecha de Nacimiento, entonces hay que utilizar este formato, después de la definición de todos los campos y antes del paréntesis de cierre de la sentencia:

CREATE TABLE USUARIOS (
	Nombre VARCHAR2 (25),
	Apellidos VARCHAR2 (30),
	F_Nacimiento DATE,
	CONSTRAINT Usu_PK PRIMARY KEY(Nombre, Apellidos, F_Nacimiento));

Ya vimos que las claves ajenas, secundarias o foráneas eran campos de una tabla que se relacionaban con la clave primaria (o incluso con la clave candidata) de otra tabla.

Cuando creemos la tabla tendremos que indicar de alguna forma quién es clave ajena. Lo haremos "haciendo referencia" a la tabla y los campos de donde procede.

En nuestra tabla vamos a tener una clave ajena procedente de la tabla PARTIDAS que será su Cod_Partida, por tanto tendremos que hacer referencia a éste:

 CREATE TABLE USUARIOS (
    Cod_Partida NUMBER(8)
        CONSTRAINT Cod_Part_FK
        REFERENCES PARTIDAS(Cod_Partida));

Si el campo al que hace referencia es clave principal en su tabla no es necesario indicar el nombre del campo:

CREATE TABLE USUARIOS (
    Cod_Partida NUMBER(8)
        CONSTRAINT Cod_Part_FK
        REFERENCES PARTIDAS);

Si la definición de la clave ajena se pone al final, tendremos que colocar el texto FOREIGN KEY para especificar a qué campo se está refiriendo.

Vamos a verlo en el caso en que la clave ajena estuviera formada por Cod_Partida y Fecha de la partida de la tabla PARTIDAS:

CREATE TABLE USUARIOS (
    Cod_Partida NUMBER(8),
    F_Partida DATE,
    CONSTRAINT Partida_Cod_F_FK FOREIGN KEY (Cod_Partida, F_Partida)
    REFERENCES PARTIDAS);

Al relacionar campos necesitamos que el dato del campo que es clave ajena en una tabla (que llamaremos secundaria) previamente haya sido incluido en su tabla de procedencia donde es clave primaria o candidata. En nuestro ejemplo, cualquier código de partida que incluyamos en la tabla USUARIO, debería estar previamente en la tabla de la que procede, es decir, en la tabla PARTIDAS. A esto se le llama Integridad Referencial.

Esto puede crear algunos errores, pues puede ocurrir lo siguiente:

• Si hacemos referencia a una tabla que no está creada: Oracle buscará la tabla referenciada y al no encontrarla dará fallo. Esto se soluciona creando en primer lugar las tablas que no tengan claves ajenas.
• Si queremos borrar las tablas tendremos que proceder al contrario, borraremos las tablas que tengan claves ajenas antes.

Tenemos otras soluciones y es añadir tras la cláusula REFERENCE:

• ON DELETE CASCADE: te permitirá borrar todos los registros cuya clave ajena sea igual a la clave del registro borrado.
• ON DELETE SET NULL: colocará el valor NULL en todas las claves ajenas relacionadas con la borrada.
• ON DELETE DEFAULT xxxx: colocará el valor  xxxx  en todas las claves ajenas relacionadas con la borrada.

esas opciones son válidas también para la operación de modificación especificando ON UPDATE en lugar de ON DELETE.

A veces es muy tedioso insertar siempre lo mismo en un campo. Imagínate que casi todos los jugadores fuesen de España y tenemos un campo País. ¿No sería cómodo asignarle un valor por defecto? Eso es lo que hace la restricción DEFAULT.

En nuestro ejemplo vamos a añadir a la tabla USUARIOS el campo País y le daremos por defecto el valor "España".

CREATE TABLE USUARIOS (
    Pais VARCHAR2(20) DEFAULT ' España ' );

En las especificaciones de DEFAULT vamos a poder añadir distintas expresiones: constantes, funciones SQL y variables.

Si queremos incluir en un campo la fecha actual, independientemente del día en el que estemos, podremos utilizar la función SYSDATE como valor por defecto:

CREATE TABLE USUARIOS (
      Fecha_ingreso DATE DEFAULT SYSDATE);

También vamos a necesitar que se compruebe que los valores que se introducen son adecuados para ese campo. Para ello utilizaremos CHECK.

Esta restricción comprueba que se cumpla una condición determinada al rellenar una columna. Dicha condición se puede construir con columnas de esa misma tabla.

Si en la tabla USUARIOS tenemos el campo Crédito y éste sólo puede estar entre 0 y 2000, lo especificaríamos así:

CREATE TABLE USUARIOS (
    Credito NUMBER(4) CHECK (Crédito BETWEEN 0 AND 2000));

Una misma columna puede tener varios CHECK asociados a ella, para ello ponemos varios CONSTRAINT seguidos y separados por comas.

Cuando una tabla ya no es útil y no la necesitamos es mejor borrarla, de este modo no ocupará espacio y podremos utilizar su nombre en otra ocasión.

Para eliminar una tabla utilizaremos el comando DROP TABLE.

DROP TABLE NombreTabla [CASCADE CONSTRAINTS];

Esta instrucción borrará la tabla de la base de datos incluido sus datos (filas). También se borrará toda la información que existiera de esa tabla en el Diccionario de Datos.

La opción CASCADE CONSTRAINTS se puede incluir para los casos en que alguna de las columnas sea clave ajena en otra tabla secundaria, lo que impediría su borrado. Al colocar esta opción las restricciones donde es clave ajena se borrarán antes y a continuación se eliminará la tabla en cuestión.

Vamos a eliminar la tabla con la que hemos estado trabajando:

DROP TABLE USUARIOS ;

Ten cuidado al utilizar este comando, el borrado de una tabla es irreversible y no hay una petición de confirmación antes de ejecutarse.

Es posible que después de crear una tabla nos demos cuenta que se nos ha olvidado añadir algún campo o restricción, quizás alguna de las restricciones que añadimos ya no es necesaria o tal vez queramos cambiar el nombre de alguno de los campos. ¿Es posible esto? Ahora veremos que sí y en casi todos los casos utilizaremos el comando ALTER TABLE.

• Si queremos cambiar el nombre de una tabla:

RENAME NombreViejo TO NombreNuevo;

• Si queremos añadir columnas a una tabla: las columnas se añadirán al final de la tabla.

ALTER TABLE NombreTabla ADD
( ColumnaNueva1 Tipo_Datos [Propiedades]
[, ColumnaNueva2 Tipo_Datos [Propiedades]
... );

• Si queremos eliminar columnas de una tabla: se eliminará la columna indicada sin poder deshacer esta acción. Además de la definición de la columna, se eliminarán todos los datos que contuviera. No se puede eliminar una columna si es la única que forma la tabla, para ello tendremos que borrar la tabla directamente.

ALTER TABLE NombreTabla DROP COLUMN (Columna1 [, Columna2, ...]);

• Si queremos modificar columnas de una tabla: podemos modificar el tipo de datos y las propiedades de una columna. Todos los cambios son posibles si la tabla no contiene datos. En general, si la tabla no está vacía podremos aumentar la longitud de una columna, aumentar o disminuir en número de posiciones decimales en un tipo NUMBER, reducir la anchura siempre que los datos no ocupen todo el espacio reservado para ellos.

ALTER TABLE NombreTabla MODIFY
(Columna1 TipoDatos [propiedades] [, columna2 TipoDatos [propiedades] ...] );

• Si queremos renombrar columnas de una tabla:

ALTER TABLE NombreTabla RENAME COLUMN NombreAntiguo TO NombreNuevo;

Tenemos la siguiente tabla creada:

 CREATE TABLE USUARIOS (
    Credito NUMBER(4) CHECK (Crédito BETWEEN 0 AND 2000));

Nos gustaría incluir una nueva columna llamada User que será tipo texto y clave primaria:

ALTER TABLE USUARIO ADD
    (User VARCHAR(10) PRIMARY KEY);

Nos damos cuenta que ese campo se llamaba Login y no User, vamos a cambiarlo:

ALTER TABLE USUARIO RENAME COLUMN User TO Login;

Utilizando el comando ALTER TABLE, podemos modificar las restricciones o bien eliminarlas:

• Si queremos borrar restricciones:

  ALTER TABLA NombreTabla DROP CONSTRAINT NombreRestriccion;

• Si queremos modificar el nombre de las restricciones:

  ALTER TABLE NombreTabla RENAME CONSTRAINT NombreViejo TO NombreNuevo;

• Si queremos activar o desactivar restricciones:

  A veces es conveniente desactivar temporalmente una restricción para hacer pruebas o porque necesitemos saltarnos esa regla. Para ello usaremos esta sintaxis:

  ALTER TABLE NombreTabla DISABLE CONSTRAINT NombreRestriccion [CASCADE];

  La opción CASCADE desactiva las restricciones que dependan de ésta.

  Para activar de nuevo la restricción:

  ALTER TABLE NombreTabla ENABLE CONSTRAINT NombreRestriccion [CASCADE];

Sabemos que crear índices ayuda a la localización más rápida de la información contenida en las tablas. Ahora aprenderemos a crearlos y eliminarlos:

CREATE INDEX NombreIndice ON NombreTabla (Columna1 [, Columna2 ...]);

No es aconsejable que utilices índices sobre campos de tablas pequeñas o que se actualicen con mucha frecuencia. Tampoco es conveniente si esos campos no se usan en consultas de manera frecuente o en expresiones.

El diseño de indices es un tema bastante complejo para los Administradores de Bases de Datos, ya que una mala elección ocasiona ineficiencia y tiempos de espera elevados. Un uso excesivo de ellos puede dejar a la Base de Datos colgada simplemente con insertar alguna fila.

Para eliminar un índice es suficiente con poner la instrucción:

DROP INDEX NombreIndice;

Ya hemos visto que necesitamos una cuenta de usuario para acceder a los datos de una base de datos. Las claves de acceso se establecen cuando se crea el usuario y pueden ser modificados por el Administrador o por el propietario de dicha clave. La Base de Datos almacena encriptadas las claves en una tabla del diccionario llamada DBA_USERS.

¿Cómo se crean los usuarios? La sintaxis es:

CREATE USER NombreUsuario
IDENTIFIED BY ClaveAcceso
[DEFAULT TABLESPACE tablespace ]
[TEMPORARY TABLESPACE tablespace]
[QUOTA int {K | M} ON tablespace]
[QUOTA UNLIMITED ON tablespace]
[PROFILE perfil];

donde:

• CREATE USER: crea un nombre de usuario que será identificado por el sistema.
• IDENTIFIED BY: permite dar una clave de acceso al usuario creado.
• DEFAULT TABLESPACE: asigna a un usuario el Tablespace por defecto para almacenar los objetos que cree. Si no se asigna ninguna, será SYSTEM.
• TEMPORARY TABLESPACE: especifica el nombre del Tablespace para trabajos temporales. Por defecto será SYSTEM.
• QUOTA: asigna un espacio en Megabytes o Kilobytes en el Tablespace asignado. Si no se especifica el usuario no tendrá espacio y no podrá crear objetos.
• PROFILE: asigna un perfil al usuario. Si no se especifica se asigna el perfil por defecto.

Practiquemos un poco con este comando. Creemos una cuenta de usuario limitado, que no tenga derecho ni a guardar datos ni a crear objetos, más tarde le daremos permisos:

CREATE USER UsuarioLimitado IDENTIFIED BY passworddemiusuariolimitado ;

Podemos modificar usuarios mediante el comando ALTER USER, cuya sintaxis es la siguiente:

ALTER USER NombreUsuario
IDENTIFIED BY clave_acceso
[DEFAULT TABLESPACE tablespace ]
[TEMPORARY TABLESPACE tablespace]
[QUOTA int {K | M} ON tablespace]
[QUOTA UNLIMITED ON tablespace]
[PROFILE perfil];

Un usuario sin privilegios de Administrador únicamente podrá cambiar su clave de acceso.

Para eliminar o borrar un usuario utilizamos el comando DROP USER con la siguiente sintaxis:

DROP USER NombreUsuario [CASCADE];

La opción CASCADE borra todos los objetos del usuario antes de borrarlo. Sin esta opción no nos dejaría eliminar al usuario si éste tuviera tablas creadas.

Ningún usuario puede llevar a cabo una operación si antes no se le ha concedido el permiso para ello. En el apartado anterior hemos creado un usuario para iniciar sesión, pero si con él intentáramos crear una tabla veríamos que no tenemos permisos suficientes para ello.

Para poder acceder a los objetos de una base de datos necesitas tener privilegios (permisos). Éstos se pueden agrupar formando roles, lo que simplificará la administración. Los roles pueden activarse, desactivarse o protegerse con una clave. Mediante los roles podemos gestionar los comandos que pueden utilizar los usuarios. Un permiso se puede asignar a un usuario o a un rol.

Un privilegio o permiso se concede con el comando GRANT (conceder).

Si se dan privilegios sobre los objetos:

GRANT {privilegio_objeto [, privilegio_objeto]...|ALL|[PRIVILEGES]}
ON [usuario.]objeto
FROM {usuario1|rol1|PUBLIC} [,{usuario2|rol2|PUBLIC] ...
[WITH GRANT OPTION];

donde:

• ON especifica el objeto sobre el que se conceden los privilegios.
• TO señala a los usuarios o roles a los que se conceden privilegios.
• ALL concede todos los privilegios sobre el objeto especificado.
• [WITH GRANT OPTION] permite que el receptor del privilegio se lo pueda conceder a otros.
• PUBLIC hace que un privilegio esté disponible para todos los usuarios.

En el siguiente ejemplo Juan ha accedido a la base de datos y ejecuta los siguientes comandos:

• GRANT INSERT TO Usuarios TO Ana; (permitirá a Ana insertar datos en la tabla Usuarios)
• GRANT ALL ON Partidas TO Ana; (Juan concede todos los privilegios sobre la tabla Partidas a Ana)

Los privilegios de sistema son los que dan derecho a ejecutar comandos SQL o acciones sobre objetos de un tipo especificado. Existen gran cantidad de privilegios distintos.

La sintaxis para dar este tipo de privilegios la tienes aquí:

GRANT {Privilegio1 | rol1 } [, privilegio2 | rol2}, ...]
TO {usuario1 | rol1| PUBLIC} [, usuario2 | rol2 | PUBLIC} ... ]
[WITH ADMIN OPTION];

• TO señala a los usuarios o roles a los que se conceden privilegios.
• WITH ADMIN OPTION es una opción que permite al receptor de esos privilegios que pueda conceder esos mismos privilegios a otros usuarios o roles.
• PUBLIC hace que un privilegio esté disponible para todos los usuarios.

Veamos algunos ejemplos:

GRANT CONNECT TO Ana;

Concede a Ana el rol de CONNECT con todos los privilegios que éste tiene asociados.

GRANT DROP USER TO Ana WITH ADMIN OPTION;

Concede a Ana el privilegio de borrar usuarios y que ésta puede conceder el mismo privilegio de borrar usuarios a otros.

Hasta ahora hemos aprendido a conceder permisos o privilegios. Será importante aprender a retirarlos:

Con el comando REVOKE se retiran los privilegios:

• Sobre objetos:

REVOKE {privilegio_objeto [, privilegio_objeto]...|ALL|[PRIVILEGES]}
ON [usuario.]objeto
FROM {usuario|rol|PUBLIC} [,{usuario|rol|PUBLIC] ...;

• Del sistema o roles a usuarios:

REVOKE {privilegio_stma | rol} [, {privilegio_stma | rol}]...|ALL|[PRIVILEGES]}
ON [usuario.]objeto
FROM {usuario|rol|PUBLIC} [,{usuario|rol|PUBLIC] ...;

Juan va a quitar el permiso de seleccionar y de actualizar sobre la tabla Usuarios a Ana:

REVOKE SELECT, UPDATE ON Usuarios FROM Ana;

y va a quitarle el permiso de eliminar usuarios:

REVOKE DROP USER FROM Ana;

El lenguaje SQL está compuesto por comandos, cláusulas, operadores, funciones y literales . Todos estos elementos se combinan en las instrucciones y se utilizan para crear, actualizar y manipular bases de datos.

• COMANDOS:

  Comandos DDL. Lenguaje de Definición de Datos:

  Comandos DDL. Lenguaje de Definición de Datos.

  Comando:	Descripción:
  CREATE	Se utiliza para crear nuevas tablas, campos e índices.
  DROP	Se utiliza para eliminar tablas e índices.
  ALTER	Se utiliza para modificar tablas.

  Comandos DML. Languaje de Manipulación de Datos:

  Comandos DML. Lenguaje de Manipulación de Datos.

  Comando:	Descripción:
  SELECT	Se utiliza para consultar filas que satisfagan un criterio determinado.
  INSERT	Se utiliza para cargar datos en una única operación.
  UPDATE	Se utiliza para modificar valores de campos y filas específicos.
  DELETE	Se utiliza para eliminar filas de una tabla.

  Comandos DCL. Lenguaje de Control de Datos:

  Comandos DCL. Lenguaje de Control de Datos.

  Comando:	Descripción:
  GRANT	Permite dar permisos a uno o varios usuarios o roles para realizar tareas determinadas.
  REVOKE	Permite eliminar permisos que previamente se han concedido con GRANT.

• CLÁUSULAS:

  Llamadas también condiciones o criterios, son palabras especiales que permiten modificar el funcionamiento de un comando.

  Cláusulas

  Cláusulas:	Descripción:
  FROM	Se utiliza para especificar la tabla de la que se van a seleccionar las filas.
  WHERE	Se utiliza para especificar las condiciones que deben reunir las filas que se van a seleccionar.
  GROUP BY	Se utiliza para separar las filas seleccionadas en grupos específicos.
  HAVING	Se utiliza para expresar la condición que debe satisfacer cada grupo.
  ORDER BY	Se utiliza para ordenar las filas seleccionadas de acuerdo a un orden específico.

• OPERADORES:

  Permiten crear expresiones complejas. Pueden ser aritméticos (+, -, *, /, ...) o lógicos (< , >, , < >, And, Or, …).

  Operadores lógicos

  Operadores lógicos.

  Operadores:	Descripción:
  AND	Evalúa dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas.
  OR	Evalúa dos condiciones y devuelve un valor de verdad si alguna de las dos es cierta.
  NOT	Devuelve el valor contrario de la expresión.

  Operadores de comparación

  Operadores de comparación.

  Operadores:	Descripción:
  <	Menor que.
  >	Mayor que.
  < >	Distinto de.
  < =	Menor o igual.
  > =	Mayor o igual.
  =	Igual.
  BETWEEN	Se utiliza para especificar un intervalo de valores.
  LIKE	Se utiliza para comparar.
  IN	Se utiliza para especificar filas de una base de datos.

• FUNCIONES:

  Para conseguir valores complejos. Por ejemplo, la función promedio para obtener la media de un salario. Existen muchas funciones, aquí tienes la descripción de algunas.

  Funciones de agregado:

  Funciones de agregado.

  Función:	Descripción:
  AVG	Calcula el promedio de los valores de un campo determinado.
  COUNT	Devuelve el número de filas de la selección.
  SUM	Devuelve la suma de todos los valores de un campo determinado.
  MAX	Devuelve el valor más alto de un campo determinado.
  MIN	Devuelve el valor mínimo de un campo determinado.

• LITERALES:

  Les podemos llamar también constantes y serán valores concretos, como por ejemplo un número, una fecha, un conjunto de caracteres, etc.

  Literales

  Literales:	Descripción:
  23/03/97	Literal fecha.
  María	Literal caracteres.
  5	Literal número.

En este archivo tienes los pasos para instalar Oracle18c XE 

Instalacion de Oracle Database 18c XE