Manual del curso de sql fundamentos y práctica

Curso de SQL
Fundamentos y Práctica

Por Byron Quisquinay.

Contenido
Bases de Datos Relacionales ................................................................................................................... 5
Sistema de Administración de Base de Datos (DMBS) ............................................................................ 5
Modelo Relacional ................................................................................................................................... 6
Sistema de Administración de Base de Datos Relacional (RDBMS) ........................................................ 6
Esquema .................................................................................................................................................. 7
Tablas ...................................................................................................................................................... 7
Índices ..................................................................................................................................................... 8
Acceso a la Información .......................................................................................................................... 8
Lenguaje Estructurado de Consulta (Estructured Query Language [SQL]).......................................... 8
Administración de las Transacciones ...................................................................................................... 9
Concurrencia ....................................................................................................................................... 9
Consistencia de la Información ......................................................................................................... 10
Arquitectura de la Base de Datos Oracle .............................................................................................. 10
Base de Datos e instancia .................................................................................................................. 11
Estructuras de Almacenamiento de la Base de Datos....................................................................... 12
Estructuras físicas de almacenamiento ............................................................................................. 12
Estructuras lógicas de almacenamiento............................................................................................ 12
Estructura de una Instancia de Base de Datos ...................................................................................... 13
Procesos de la Base de Datos Oracle................................................................................................. 13
Estructuras de Memoria de la Instancia............................................................................................ 14
Arquitectura de Aplicación y de Red ..................................................................................................... 14
Arquitectura de Aplicación ................................................................................................................ 14
Arquitectura de Red .......................................................................................................................... 15
Diseño de la Base de Datos ................................................................................................................... 15
¿Qué es un usuario de Base de Datos? ................................................................................................. 16
Diseño conceptual ................................................................................................................................. 16
Sentencias SQL tipo DDL........................................................................................................................ 17
CREATE .............................................................................................................................................. 18
CREATE TABLE ............................................................................................................................... 18
Sintaxis de Create Table ................................................................................................................ 19
Global Temporary Tables .............................................................................................................. 22

Teoría de la normalización ............................................................................................................ 22
Comentarios ...................................................................................................................................... 24
Comentarios de documentación ................................................................................................... 24
Hints .............................................................................................................................................. 25
COMMENT ON ............................................................................................................................... 25
Agregando comentarios ................................................................................................................ 26
Comentarios sobre Tabla .............................................................................................................. 26
Comentarios sobre Campos .......................................................................................................... 26
¿Qué es un índice? ............................................................................................................................ 30
CREATE INDEX ................................................................................................................................... 31
Sintaxis de CREATE INDEX ............................................................................................................. 31
Semántica ...................................................................................................................................... 32
Creando Índices ................................................................................................................................. 33
CREATE SEQUECE........................................................................................................................... 33
DROP.................................................................................................................................................. 40
DROP TABLE................................................................................................................................... 41
DROP SEQUENCE ........................................................................................................................... 43
DROP INDEX................................................................................................................................... 44
TRUNCATE TABLE .............................................................................................................................. 45
Sintaxis de TRUNCATE TABLE ........................................................................................................ 46
Semántica de la Sintaxis ................................................................................................................ 46
Sentencias SQL tipo DML....................................................................................................................... 48
Sentencia Insert ................................................................................................................................. 48
Sintaxis de la sentencia Insert ....................................................................................................... 49
Insertando información ................................................................................................................. 50
Sentencia Select ................................................................................................................................ 56
Sintaxis de Select ........................................................................................................................... 56
Semántica de la Sintaxis ................................................................................................................ 57
Seleccionando información ........................................................................................................... 57
Consultas con Relaciones .................................................................................................................. 61
EQUIJOINS ..................................................................................................................................... 61
SELF JOINS ..................................................................................................................................... 61

PRODUCTOS CARTESIANOS ........................................................................................................... 62
INNER JOINS .................................................................................................................................. 62
OUTER JOINS ................................................................................................................................. 62
Realizando consultas con relación .................................................................................................... 64
EXPLAIN PLAN.................................................................................................................................... 65
Sintaxis de EXPLAIN PLAN.............................................................................................................. 66
Creando un Plan de Ejecución ....................................................................................................... 67
Consultas jerárquicas ........................................................................................................................ 68
Sintaxis........................................................................................................................................... 68
Semántica de la sintaxis ................................................................................................................ 68
Proceso de una consulta jerárquica .............................................................................................. 69
Operadores de consultas jerárquicas ............................................................................................ 70
PRIOR ............................................................................................................................................. 70
CONNECT_BY_ROOT ..................................................................................................................... 71
Seudo columnas ................................................................................................................................ 71
Seudo columnas de queries jerárquicos ....................................................................................... 71
UPDATE.............................................................................................................................................. 72
Sintaxis de UPDATE ....................................................................................................................... 72
Modificando la Información .......................................................................................................... 73
DELETE ............................................................................................................................................... 74
Sintaxis de DELETE ......................................................................................................................... 74
Eliminando información ................................................................................................................ 74
Procesamiento de las sentencias SQL ................................................................................................... 75
Transacciones ........................................................................................................................................ 75
Sentencias de Control de Transacción .................................................................................................. 75
COMMIT ............................................................................................................................................ 76
ROLLBACK .......................................................................................................................................... 76
Estado de los datos durante la transacción ...................................................................................... 76

Bases de Datos Relacionales1
Cada organización empresarial necesita información que deberá almacenar y manejar para
cumplir con sus requerimientos de operación y administración. Por ejemplo, una empresa deberá
recolectar y mantener la información de su Capital Humano, ello conlleva la necesidad de registros
para sus colaboradores. Esta información deberá estar disponible para aquellos que la necesiten.
Todo ello conlleva a la necesidad de contar con procesos y procedimientos para recolectar y
administrar esa información. Entonces, un Sistema de información es un Sistema formal para
almacenar y procesar la información.
Un Sistema de Información podría ser el conjunto de mobiliario que contiene carpetas y
habrán reglas que rijan el almacenamiento y extracción de estas carpetas. Más sin embargo en la
actualidad muchas empresas emplean las Bases de Datos para automatizar sus Sistemas de
Información. Una Base de Datos es una colección organizada de información que es tratada como
una unidad. El propósito de una Base de Datos es recolectar, almacenar y retraer información
relacionada para ser usada a través de aplicaciones de Base de Datos.

Sistema de Administración de Base de Datos (DMBS)
Un Sistema de Administración de Base de Datos (DMBS) es software que controla el
almacenamiento, organización y recuperación de la información. Típicamente un DBMS tiene los
siguientes elementos:
Código Kernel.
Repositorio de metadata. Usualmente llamado Diccionario de Datos.
Lenguaje de Consulta. Este lenguaje le permite a las aplicaciones acceder a la
información.
Una Aplicación de Base de Datos es software que interactúa con la base de datos para
acceder y manipular la información.
La primera generación de Sistemas de Administración de Base de Datos incluyen los
siguientes tipos:
Jerárquico: Una Base de Datos jerárquica organiza la información en una estructura de árbol.
Cada registro padre tiene uno o más registros hijos, similar a un Sistema de Archivos.
Red: Una Base de Datos de Red es similar a una Base de Datos jerárquica, con la excepción de
que los registros tienen una relación de muchos a muchos en lugar de uno a muchos.

1

Tomado de: Oracle® Database - Concepts - 12c Release 1 (12.1) - E17633-21.

Las bases de Datos anteriores almacenaban la información en una relación rígida
predeterminada. Dado que no existía un lenguaje de definición de datos, cambiar la estructura de la
información era difícil. También estos Sistemas adolecían de un lenguaje simple de consulta, lo que
significaba un desarrollo de aplicaciones.

Modelo Relacional
En su trabajo de seminario de 1970 titulado: "Un Modelo Relacional de Información para
Grandes Bancos de Información Compartida", E. F. Codd definió el modelo relacional basado en
teoría matemática. Hoy en día es modelo de Bases de Datos más aceptados es el Modelo Relacional.
Una Base de Datos Relacional es una Base de Datos que adopta el modelo relacional. El
modelo relacional tiene estos aspectos definidos a grandes razgos:
Estructuras: Objetos bien definidos de almacenamiento o acceso a la información de la Base
de Datos.
Operaciones: Acciones claramente definidas que permitan a las aplicaciones manipular la
información y sus estructuras de la Base de Datos.
Reglas de Integridad: Reglas de integridad que gobiernen las operaciones sobre la
información y las estructuras de la Base de Datos.
Una Base de Datos Relacional almacena la información en un conjunto simple de relaciones.
Una relación es un conjunto de tuplas. Una tupla es un conjunto ordenado de valores de un atributo.
Una tabla es una representación de dos dimensiones de la relación en forma de registros
(tuplas) y columnas (atributos). Cada registro en una tabla tiene el mismo conjunto de columnas.
Una Base de Datos Relacional es una Base de Datos que almacena la información en relación (tablas).
Por ejemplo, una Base de Datos Relacional puede almacenar información de sus colaboradores una
tabla colaboradores, una tabla de departamento y en una tabla de salarios.

Sistema de Administración de Base de Datos Relacional (RDBMS)
El modelo relacional es la base para un Sistema de Administración de Base de Datos
Relacional. Esencialmente un RDBMS mueve la información a la Base de Datos, almacena la
información y la extrae de manera que las aplicaciones puedan manipularla. Un RDBMS realiza una
distinción entre los siguientes tipos de operaciones:

Operaciones lógicas: En ese caso una aplicación especifica qué contenido es requerido por
ella. Por ejemplo una aplicación solicita el nombre de un Colaborador o el agregado de un
registro de un Colaborador a una Tabla.
Operaciones físicas: En este caso el RDBMS determina que se deberá realizar para llevar a
cabo la operación. Por ejemplo, cuando una aplicación consulta una tabla, la Base de Datos
quizá emplee un índice para encontrar los registros solicitados, leer la data en la memoria y
ejecutar otros pasos antes de retornar el resultado al usuario. El RDBMS almacena y
recupera la información de manera tal que las operaciones físicas sean transparentes para la
aplicación.
Oracle es un RDBMS que implementa funcionalidades Orientadas a Objetos, tales como tipos
definidos por el usuario, herencia y polimorfismo, por ello es llamada Sistema de Administración de
Base de Datos Objeto - Relacional (ORDBMS). La Base de Datos Oracle ha extendido el modelo
relacional a un modelo objeto – relacional, haciendo posible almacenar modelos complejos de
negocios en una Base de Datos Relacional.

Esquema
Una característica de un RDBMS es la independencia del almacenamiento físico de la
información de la estructura lógica de ella misma. En la Base de Datos Oracle, un Esquema (Schema)
de Base de Datos es una colección de estructuras lógicas de información u Objetos del Esquema. Un
usuario de Base de Datos posee su propio Esquema de Base de Datos, que tiene el mismo nombre
que el usuario.
Los Objetos del Esquema son estructuras creadas por el usuario, estas estructuras se refieren
de forma directa a la información en la Base de Datos. La Base de Datos soporta varios tipos de
Objetos de los cuales los más importantes son las Tablas y los Índices.
Un Esquema en sí mismo en un Objeto de la Base de Datos. Algunos objetos de la Base de
Datos, como los perfiles y roles no residen en los Esquemas.

Tablas
Una Tabla describe una entidad tal como Colaboradores. Usted define una Tabla con un
Nombre de Tabla, así como colaboradores y un conjunto de columnas. En general usted define a
cada columna un nombre, un tipo de dato y un acho cuando la crea.

Una Tabla es un conjunto de registros. Una columna identifica un atributo de una entidad
descrita por la Tabla. Mientras que un registro identifica una instancia de la entidad. Por ejemplo,
los atributos de la entidad Colaborador corresponden a columnas para el ID de Colaborador y su
apellido. Un registro identifica a un Colaborador en específico.
Usted puede opcionalmente especificar reglas para cada columna o una Tabla. Esas reglas
son llamadas Restricciones de Integridad (Integrity Constraints). Un ejemplo la restricción de
integridad “No Nulo”, esta restricción obliga a que la columna tenga valores para cada registro.

Índices
Un índice es una estructura de información opcional, usted puede crear uno o más índices
sobre una o más columnas de una tabla. Los índices pueden incrementar la eficiencia en la
recuperación de la información. Cuando se procesa una petición, la Base de Datos puede utilizar los
índices disponibles para localizar de forma eficiente los registros solicitados. Los índices son útiles
cuando las aplicaciones a menudo consultan un registro o un conjunto de ellos.
Los índices son lógica y físicamente independientes de la información. De esa manera usted
puede eliminar y crear índices sin sobre las tablas u otros índices. Todas las aplicaciones siguen
funcionando aún si usted elimina un índice.

Acceso a la Información
Un requerimiento general para un DBMS es adherirse a los estándares aceptados por la
Industria para un Lenguaje de Acceso a la Información.

Lenguaje Estructurado de Consulta (Estructured Query Language [SQL])
SQL es un lenguaje declarativo basado en un conjunto de sentencias que provee una interfaz
para el RDBMS tal como Oracle. En contraste con lenguajes por procedimientos, tales como el
Lenguaje C; que describe “cómo” las cosas deben ser realizadas, SQL no es de procedimientos, más
bien describe “qué” se debe hacer. Los usuarios especifican el resultado que ellos desean (por
ejemplo: el nombre de un colaborador) y no cómo obtenerlo. SQL es lenguaje estándar ANSI para
Bases de Datos Relacionales.
Todas las operaciones en la Base de Datos Oracle son ejecutadas empleando sentencias SQL.
Por ejemplo usted emplea SQL para crear tablas, consultar o modificar la información. Una sentencia
SQL puede ser pensada como muy simple, pero un poderosa programa de computadora o
instrucción.

Con las Sentencias SQL usted puede ejecutar estas tareas:
Consultar la información.
Insertar (agregar), modificar (actualizar) o eliminar (borrar) registros de una tabla.
Crear, reemplazar, alterar y eliminar objetos.
Controlar el acceso a la Base de Datos y sus objetos.
Garantizar la consistencia e integridad de la Base de Datos.

Administración de las Transacciones
Un RDBMS debería ser capaz de agrupar las Sentencias SQL, de manera que todas ellas
puedan ser confirmadas (COMMIT) en la Base de Datos o bien desechadas (ROLLBACK). Una
transacción es una unidad lógica y atómica de trabajo que contiene una o más sentencias SQL.
Una ilustración que contiene la necesidad de una transacción, es el de una transferencia de
fondos de una cuenta de ahorros a una de monetarios. La transferencia consiste en las siguientes
operaciones separadas:
1. Disminuir el saldo de la cuenta de ahorros.
2. Aumentar el saldo de la cuenta de monetarios.
3. Registrar la transacción en el diario de transacciones.
La Base de Datos Oracle, garantiza que esas tres operaciones se realizan con éxito o fallan todas
como una unidad. Por ejemplo: si una falla de hardware impide que se realice una de las sentencias,
entonces las otras deberán ser desechadas.
Las transacciones son una de las características que la Base de Datos Oracle asigna aparte del
Sistema de Archivos. Si usted ejecuta una operación atómica que actualiza varios archivos, y el
Sistema de Archivos falla en medio de la actualización, entonces los archivos no serán consistentes.
En contraste una transacción se realiza en una Base de Datos de un estado consistente a otro. El
principio básico de una transacción es: “todo o nada”: una operación atómica es exitosa del todo o
nada.

Concurrencia
Un requerimiento de un RDBMS multiusuario es el control de la concurrencia sobre la
información, que consiste en el acceso simultaneo por varios usuarios, a la misma información. Sin
controles de concurrencia, los usuarios podrían actualizar la información de manera inadecuada,
comprometiendo la integridad de la información. Por ejemplo: un usuario puede actualizar un
registro cuando un usuario diferente de forma simultánea también actualiza el mismo registro.

Si múltiples usuarios acceden a la misma información, entonces una manera de administrar
dicha concurrencia es hacer que los usuarios esperen. Sin embargo, el objetivo de un DBMS es
reducir el tiempo de espera de manera tal que este no sea inexistente o negligente. Todas las
sentencias SQL que modifican información deberán proceder con la menor interferencia posible.
Interacciones destructivas, que son interacciones que modifican información o estructuras
subyacentes, de forma incorrecta, deberán ser evitadas.
La Base de Datos Oracle emplea bloqueos (locks) para controlar el acceso concurrente a la
información. Un bloqueo es un mecanismo que previene interacciones destructivas entre
transacciones que acceden a recursos compartidos. Los bloqueos se aseguran la integridad de la
información mientras que permite el máximo de accesos a la información.

Consistencia de la Información
En la Base de Datos Oracle, cada usuario deberá tener una visualización consistente de la
información, incluyendo los cambios visibles realizados por el mismo y aquellos cambios confirmados
por otros usuarios. Por ejemplo, la Base de Datos previene las “lecturas sucias”, las cuales ocurren
cuando una transacción visualiza cambios que no han sido confirmados por otra transacción
concurrente.
La Base de Datos Oracle hace cumplir siempre lecturas consistentes en el nivel de la
transacción, lo que garantiza que la información que una consulta simple retorna es confirmada y
consistente para un periodo de tiempo determinado. Dependiendo del nivel de aislamiento de la
transacción, ese período de tiempo en que la sentencia fue abierta o en el tiempo en que la
transacción inicia. La característica Flashback Query le permite especificar este período de tiempo en
específico.
La Base de Datos también puede proveer consistencia en las lecturas a todas las consultas en
una transacción, esto es conocido como consistencia de la lectura a nivel de transacción. En este
caso, cada sentencia en una transacción puede visualizar la información en el mismo período de
tiempo, que es el tiempo en el que la transacción inicia.

Arquitectura de la Base de Datos Oracle
El servidor de la Base de Datos es la llave de la administración de la información. En general,
un servidor administra una gran cantidad de información de manera fiable en un ambiente multi
usuario, de manera que puedan acceder de forma concurrente a la misma información. Un servidor
de Base de Datos también previene accesos no autorizados y provee soluciones eficientes para la
recuperación ante fallas.

Base de Datos e instancia
Un servidor de Base de Datos Oracle consiste en una Base de Datos y al menos una instancia
de Base de Datos (común mente referida solo como instancia). Dado que una Instancia y una Base
de Datos están tan estrechamente conectadas, el término Base de Datos Oracle es muchas veces
usado para referirse a ambos. En el estricto sentido de los términos, éstos tienen el siguiente
significado:
Base de Datos: una base de datos es un conjunto de archivos, alojados en el disco que
almacena la información. Esos archivos pueden existir de forma independiente de una
Instancia de Base de Datos.
Instancia de Base de Datos: Una Instancia es un conjunto de estructuras en memoria que
administran los archivos de la Base de Datos. La Instancia consiste en un área de memoria
compartida, llamada Area Global del Sistema (SGA) y un conjunto de procesos de fondo
(background). Una instancia puede existir de forma independiente con respecto de la Base
de Datos.
Por cada conexión de usuario a la instancia, un proceso cliente ejecuta la aplicación. Cada cliente
es asociado a su propio proceso servidor. El proceso servidor tiene su memoria privada de sesión,
conocida como el Área Global de Programa (PGA).

Una Base de Datos puede ser considerada tanto desde una perspectiva física, así como de
una perspectiva lógica. La información física es visible a nivel del Sistema Operativo. Por ejemplo,
las herramientas tales como el “ls” de Linux y el “ps” pueden listar los archivos y procesos de la Base

de Datos. La información lógica tal como una tabla es únicamente significativa para la Base de Datos.
Una sentencia SQL puede listar las tablas en una Base de Datos Oracle, pero una herramienta del
Sistema Operativo no.
La Base de Datos tiene estructuras físicas y lógicas. Debido a que las estructuras físicas y
lógicas son separadas. El almacenamiento físico de la información puede ser administrado sin
afectar el acceso a las estructuras lógicas de almacenamiento. Por ejemplo: al renombrar un archivo
físico de la Base de Datos no renombra las tablas cuya información está almacenada en ese archivo.

Estructuras de Almacenamiento de la Base de Datos
Una tarea especial de una Base de Datos Relacional es el almacenamiento de la información.
Para ello necesita estructuras que le permitan el almacenamiento de dicha información.

Estructuras físicas de almacenamiento
Las estructuras físicas de almacenamiento de la Base de Datos son los archivos que almacenan la
información. Cuando usted ejecuta el comando SQL CREATE DATABASE los siguientes archivos son
creados:
Data Files: Cada Base de Datos Oracle tiene uno o más archivos físicos de Data Files, mismos
que contienen toda la información de la Base de Datos. La información de las estructuras
lógicas de información, tales como las tablas e índices son almacenados físicamente en los
Data Files.
Control Files: Cada Base de Datos Oracle tiene un Control Files. Un Control Files contiene
metadata especificando la estructura física de la Base de Datos, incluyendo el nombre de la
Base de Datos el nombre y ubicación de los archivos de la Base de Datos.
Online redo log Files: Cada Base de Datos Oracle tiene un Online redo log, que es un
conjunto de dos o más Online redo log Files. Un redo log está constituido de entradas redo
(también llamados redo records), este archivo registra todos los cambios realizados a la
información.
Muchos otros archivos son importantes para el funcionamiento de un Servidor de Base de Datos
Oracle. Estos son offline files importantes para los respaldos y la recuperación.

Estructuras lógicas de almacenamiento
Las siguientes estructuras lógicas de almacenamiento le permiten a la Base de Datos Oracle tener
un control de granularidad fina sobre el espacio de disco utilizado:
Data Blocks: Al más fino nivel de granularidad, la información de la Base de Datos Oracle es
almacenada en Data Blocks. Un Data Block corresponde a un número específico de bytes en
el disco.

Extents: Un Extent es un número específico de Data Blocks contiguos, obtenido en una
misma ubicación, empleado para almacenar un tipo específico de información.
Segment: un segmento es un conjunto de Extents ubicados para un objeto de usuario (por
ejemplo: Una tabla o un índice), o bien para un Undo Data o un Temporary Data.
Tablespaces: una Base de Datos es dividida en unidades de almacenamiento lógico llamada
Tablespace. Un Tablespace es el contenedor lógico para un segmento. Cada Tablespace
consiste en al menos un Data File.

Estructura de una Instancia de Base de Datos
Una Base de Datos Oracle utiliza estructuras de memoria y procesos para administrar y
acceder a la Base de Datos. Todas las estructuras de memoria existen en la memoria principal de la
computadora que constituye el RDBMS.
Cuando las aplicaciones se conectan a una Base de Datos Oracle, ellas se conectan a la
Instancia de Base de Datos. Y los servicios de instancia de aplicación al alojarse en otras áreas de
memoria distintos al SGA e iniciar otros procesos distintos a los background processes (procesos de
fondo o segundo plano) de la Base de Datos.

Procesos de la Base de Datos Oracle
Un proceso es un mecanismo en un Sistema Operativo que puede ejecutar una serie de
pasos. Algunos Sistemas Operativos usan el término job, task o thread. Para el propósito de esta
discusión un thread es equivalente a un proceso. Una Instancia de Base de Datos Oracle tiene los
siguientes tipos de procedimientos:
Proceso Cliente: Estos procesos son creados y mantenidos para ejecutar software de un
programa de aplicación o una herramienta de Oracle. Muchos ambientes tienen
computadoras separadas para los procesos cliente.
Procesos de fondo: Estos procesos consolidan funciones que de otra manera serían
manejados por múltiples programas de la Base de Datos Oracle ejecutándose para cada
proceso cliente. Los procesos de fondo de forma asíncrona realizan I/O y monitorean otros
procesos de la Base de Datos Oracle para proveer paralelismo para brindar un mejor
rendimiento y confiabilidad.
Procesos servidor: Estos procesos se comunican con los procesos cliente e interactúan con la
Base de Datos Oracle para cumplir con las solicitudes.
Los procesos de Oracle incluyen procesos servidores y procesos de fondo. En la mayoría de
ambientes, los procesos de Oracle y los procesos cliente se ejecutan en computadoras separadas.

Estructuras de Memoria de la Instancia
La Base de Datos Oracle crea y utiliza estructuras de memoria para programas de software,
información compartida entre los usuarios y áreas privadas de información para cada usuario
conectado. Las siguientes estructuras de memoria están asociadas a una Instancia:
System Global Area (SGA): La SGA es un grupo de estructuras de memoria compartida que
contienen información e información de control para una Instancia de Base de Datos. Un
ejemplo de los componentes del SGA incluyen los buffers de la Base de Datos, el cache y las
áreas compartidas de SQL.
Program Global Area (PGA): Una PGA es una región de memoria que contiene información e
información de control para un proceso servidor o de fondo. El acceso a la PGA es exclusivo
para el proceso. Cada proceso servidor o de fondo tiene so propio PGA.

Arquitectura de Aplicación y de Red
Para el aprovechamiento de un Sistema de Computadora o de Red, la Base de Datos Oracle
permite dividir el procesamiento entre el servidor y los programas cliente. La computadora que
ejecuta el RDBMS manipula la interpretación y despliegue de la información.

Arquitectura de Aplicación
La arquitectura de aplicación se refiere al ambiente computacional en el cual una Aplicación
de Base de Datos se conecta con una Base de Datos Oracle. Las dos arquitecturas de Base de Datos
más comunes son cliente/servidor y multiusuario.
En una estructura cliente/servidor, la aplicación cliente inicia la solicitud para una operación
para que sea ejecutada en el servidor de la Base de Datos. El servidor ejecuta software de la Base de
Datos Oracle y maneja las funciones requeridas para un acceso compartido y concurrente. El
Servidor recibe y procesa las peticiones que origina cada cliente.
En una arquitectura tradicional de varios niveles (o capas), uno o más servidores de
aplicación ejecutan parte de la operación. Un servidor de aplicación contiene una gran parte de la
lógica de la aplicación, provee acceso a la información para el cliente y ejecuta algún procesamiento
de consultas, disminuyendo así la carga de la Base de Datos. El servidor de aplicación puede servir
como interface entre clientes y múltiples Bases de Datos y proveer un nivel adicional de seguridad.
Una arquitectura orientada a los servicios (SOA) es una arquitectura de varios niveles (o
capas) en donde la funcionalidad de la aplicación se encuentra encapsulada en servicios. Los
servicios SOA usualmente son implementados como Web Services. Los Web Services son accesibles
a través de un protocolo HTTP y están basados en estándares XML, tales como el Web Services
Description Language (WSDL) y SOAP.

Oracle puede actuar como un proveedor de Web Services en un ambiente tradicional de
varias capas o un ambiente SOA.

Arquitectura de Red
Oracle Net Services es la interface entre la Base de Datos y los protocolos de comunicación
de la Red que facilitan el procesamiento distribuido y Bases de Datos Distribuidas. Los protocolos de
comunicación definen la manera en que la información es transmitida y recibida en la red. Oracle
Net Services soporta las comunicaciones en la mayor parte de protocolos de red, incluyendo: TCP/IP,
HTTP, FTP y WebDAV.
Oracle Net, que es un componente de Oracle Net Services, entabla y mantiene una sesión
desde un cliente de aplicación hacia la Base de Datos. Después de que una sesión es establecida,
Oracle Net actúa como con transportador de información entre el cliente de aplicación y el servidor
de la Base de Datos, intercambiando mensajes entre ellos. Oracle puede realizar esto debido a que
está localizado en cada computadora en la red.
Un componente importante de Net Services es el Oracle Net Listener (llamado el listener),
que es un proceso que se ejecuta en la Base de Datos o en cualquier parte de la red. El cliente de
aplicación envía una solicitud de conexión al listener, que se encarga de manejar el tráfico de esas
solicitudes hacia la Base de Datos. Cuando una conexión es establecida, el cliente y la Base de Datos
se comunican directamente.
La forma más común de configurar una Base de Datos Oracle a solicitudes del cliente servidor
son:
Arquitectura de servidor dedicado: Cada proceso cliente se conecta a un proceso servidor
dedicado. El proceso servidor no es compartido por otro cliente durante la sesión del cliente.
Cada nueva sesión es asignada a un proceso servidor dedicado.
Arquitectura de servidor compartido: La Base de Datos utiliza un pool de procesos
servidores para múltiples sesiones. Un proceso cliente se comunica con un despachador,
que es un proceso que permite a muchos clientes conectarse a la misma Instancia de Base de
Datos sin la necesidad de un proceso de servidor dedicado para cada cliente.

Diseño de la Base de Datos
Las dificultades inherentes al diseño de una base de datos han de afrontarse con procedimientos
ordenados y metódicos. En el proceso de diseño de una base de datos hemos de distinguir tres
grandes fases:

• Diseño conceptual: Cuyo objetivo es obtener una representación de la información
con independencia de usuarios y aplicaciones en particular y fuera de consideraciones sobre
la eficiencia del ordenador.
• Diseño lógico: Cuyo objetivo es transformar el diseño conceptual obtenido y adaptarlo al
modelo de datos en el que se apoya el RDBMS que se va a utilizar. En nuestro caso, el RDBMS
es relacional, por lo cual nos referiremos a este modelo de datos.
• Diseño físico: Cuyo objetivo es conseguir una instrumentación lo más eficiente posible del
diseño lógico.

¿Qué es un usuario de Base de Datos?
Un usuario de Base de Datos, no es más que un conjunto de permisos que se
aplican a una conexión de base de datos.
De igual manera, el usuario también tiene otras funciones:
· Ser el propietario de ciertos objetos.
· Definición del tablespace por defecto para los objetos de un usuario.
· Copias de seguridad.
· Cuotas de almacenamiento.
El usuario que posee privilegios está en la posibilidad de de realizar dos operaciones:
· Operación de sistema: necesita el permiso de sistema correspondiente.
· Operación sobre objeto: necesita el permiso sobre el objeto en cuestión.
El rol en una base de datos es una agrupación de permisos de sistema y de objeto.

Diseño conceptual
El diseño conceptual, brevemente expresado, consiste en extraer del trabajo de la empresa
aquellas entidades y acciones que son de uso habitual en la misma y que van a formar parte de la
Base de Datos.

Para ello, la forma habitual de diseño es mediante la consulta con los empleados de la empresa,
pues a partir de la misma se ha de obtener el conjunto de entidades que van a formar parte de la
base de datos, así como las acciones relevantes que pueden afectar al diseño de la base de datos.

La cardinalidad es obtenida en base a las posibilidades de relación entre las entidades,
existiendo tres tipos de cardinalidad:
• Cardinalidad 1:1: Que es cuando una entidad A se relaciona solo con otra entidad B y
viceversa. Por ejemplo, el identificador de un vehículo (número de chasis) se corresponde
con una matrícula (placa) y esa matrícula con ese identificador del vehículo.
• Cardinalidad 1:N: que es cuando una entidad A se puede relacionar con N entidades B
pero no al revés. Por ejemplo un libro puede tener N ejemplares, pero un ejemplar es solo de
un libro.
• Cardinalidad N:M: Que es cuando una entidad A se relaciona con N entidades B y
viceversa. Por ejemplo, un libro puede ser escrito por varios autores distintos y un autor
puede escribir varios libros distintos.

Sentencias SQL tipo DDL
Las sentencias de SQL que son un conjunto de expresiones (normadas) que permiten la
interacción de las personas o programas con el Sistema de Administración de Base de Datos
Relacionales (RDBMS) de manera tal que se pueda acceder, crear, modificar o eliminar elementos de
la Base de Datos con la que se establece una conexión, consta de dos grandes grupos, uno de ellos lo
constituye el Lenguaje de Definición de Datos (DDL).
El Lenguaje de Definición de Datos le permite usted las siguientes tareas:
Crear, alterar y eliminar objetos de un Schema.

Conceder y revocar privilegios y roles.
Analizar información en una tabla, índice o cluster.
Establecer opciones de auditoría.
Agregar comentarios al Diccionario de Datos.
Para la ejecución de estas sentencias el usuario que usted o sus programas utilizan para la
conexión a la Base de Datos deberá poseer los permisos necesarios para realizar las tareas definidas
para dichas sentencia.
Las sentencias del grupo de DDL son:
ALTER
SYSTEM
ANALYZE
ASSOCIATE STATISTICS
AUDIT
COMMENT
CREATE
DISASSOCIATE STATISTICS
DROP
FLASHBACK
GRANT
NOAUDIT
PURGE
RENAME
REVOKE
TRUNCATE
Este grupo de Sentencias no requieren de su confirmación con la sentencia COMMIT. Con
ello usted debe de estar plenamente seguro de su utilización.

CREATE
La sentencia CREATE de SQL permite solicitar la creación de un objeto [o elemento] en la
base de datos.

CREATE TABLE
Emplee la sentencia CREATE TABLE para crear estos tipos de tablas:
Una Tabla Relacional, que es la estructura básica para albergar información.

Una Tabla Objeto, que es una tabla que utiliza un Tipo Objeto para la definición de
una columna. Una Tabla Objeto es explícitamente definida para contener instancias de un
Tipo en particular.
Usted puede crear un Tipo Objeto y luego utilizarlo como definición de una columna cuando
crea una Tabla Relacional.
Sintaxis de Create Table:
CREATE [Global | Temporary]
TABLE [Schema.] Nombre de Tabla [Relational_table | Object_table]
(<Columnas [nombre] y su definición [tipo de dato]>)
ON COMMIT [Delete | Preserve] [Rows]
<Listado de Propiedades físicas>
<Listado de Propiedades de la tabla>;

Creando Tablas Relacionales:
Tal como hemos explorado, necesitaremos emplear la Sentencia CREATE TABLE para indicarle
al RDBMS que deseamos Crear una Tabla, entonces iniciemos:

create
table tbl_catalogo_genero
(
genero_no
genero
descripcion_genero
fecha_creacion
fecha_activo
fecha_inactivo
);
create
table tbl_catalogo_pais
(
pais_no
pais
descripcion_pais
fecha_creacion
fecha_activo
fecha_inactivo
);

number(10)
constraint
varchar2(80)
constraint
varchar2(200),
date
default sysdate constraint
date
date

pk_genero_no_tcg
cnn_genero_tcge

primary key,
not null,

ccn_fecha_creacion_tcg
ccn_fecha_activo_tcg

not null,
not null,

number(10)
constraint
varchar2(80)
constraint
varchar2(200),
date
date
date

pk_pais_no_tcp
cnn_pais_tcp

primary key,
not null,

ccn_fecha_creacion_tcp
ccn_fecha_activo_tcp

not null,
not null,

create
table tbl_catalogo_departamento
(
departamento_no
departamento
descripcion_departamento
fecha_creacion
fecha_activo
fecha_inactivo
);
create
table tbl_catalogo_municipio
(
municipio_no

number(10)
constraint
varchar2(80)
constraint
varchar2(200),
date
date
date

number(10)

pk_departamento_no_tcd
cnn_pais_tcd

primary key,
not null,

ccn_fecha_creacion_tcd
ccn_fecha_activo_tcd

not null,
not null,

constraint pk_municipio_no_tcm

primary key,

municipio
descripcion_municipio
fecha_creacion
fecha_activo
fecha_inactivo
);

varchar2(80)
constraint cnn_municipio_tcm
varchar2(200),
date
default sysdate constraint ccn_fecha_creacion_tcm
date
default sysdate constraint ccn_fecha_activo_tcm
date

create
table tbl_catalogo_estatus_cliente
(
estatus_cliente_no number(10)
constraint
estatus_cliente
varchar2(80)
constraint
descripcion_tipo
varchar2(200),
fecha_creacion
date
fecha_activo
date
fecha_inactivo
date
);
create
table tbl_catalogo_tipo_cliente
(
tipo_cliente_no number(10)
constraint
tipo_cliente
varchar2(80)
constraint
descripcion_tipo varchar2(200),
fecha_creacion
date
fecha_activo
date
fecha_inactivo
date
);
create
table tbl_clasificacion_cliente
(
clasificacion_no
clasificacion
descripcion_clasificacion
fecha_creacion
fecha_activo
fecha_inactivo
);

not null,
not null,

pk_estatus_cliente_no_tcec primary key,
cnn_estatus_cliente_tcec
not null,
ccn_fecha_creacion_tcec
ccn_fecha_activo_tcec

pk_cliente_no_tctc
ccn_tipo_cliente_tctc

not null,
not null,

primary key,
not null,

ccn_fecha_creacion_tctc not null,
ccn_fecha_activo_tctc
not null,

number(10)
constraint
varchar2(80)
constraint
varchar2(200),
date
date
date

create
table tbl_catalogo_ciclos
(
ciclo_no
number(10)
constraint
leyenda_ciclo
varchar2(80)
constraint
descripcion_ciclo varchar2(200),
fecha_creacion
date
fecha_activo
date
fecha_inactivo
date
);

not null,

pk_cliente_no_tcc
ccn_clasificacion_tcc

primary key,
not null,

ccn_fecha_creacion_tcc
ccn_fecha_activo_tcc

not null,
not null,

pk_ciclo_no_tccf
ccn_leyenda_ciclo_tccf

primary key,
not null,

ccn_fecha_creacion_tccf
ccn_fecha_activo_tccf

not null,
not null,

create
table tbl_catalogo_serie_factura
(
serie_no
number(10)
constraint pk_serie_no_tcsf
primary key,
serie_factura
varchar2(80) constraint cnn_serie_factura_tcsf not null,
descripcion_serie varchar2(200),
fecha_creacion
date
default sysdate constraint ccn_fecha_creacion_tcsf not null,
fecha_activo
date
default sysdate constraint ccn_fecha_activo_tcsf
not null,
fecha_inactivo
date
);

create
table tbl_maestra_cliente
(
cliente_no
genero_no
primer_nombre
segundo_nombre
tercer_nombre
primer_apellido
segundo_apellido
apellido_casada
fecha_nacimiento
nit
dpi
pasaporte
direccion1
direccion2
direccion3
pais_no
departamento_no
municipio_no

number(10)
constraint pk_cliente_no_tmc
primary key,
constraint fk_genero_no_tmc
references tbl_catalogo_genero(genero_no),
varchar2(80)
constraint cnn_primer_nombre_tmc
not null,
varchar2(80),
varchar2(80),
varchar2(80)
constraint cnn_primer_apellido_tmc not null,
varchar2(80),
varchar2(80),
date,
varchar2(80),
varchar2(80),
varchar2(80),
varchar2(80),
varchar2(80),
varchar2(80),
constraint fk_pais_no_tmc
references tbl_catalogo_pais(pais_no),
constraint fk_departamento_no_tmc
references tbl_catalogo_departamento(departamento_no),
constraint fk_municipio_no_tmc
references tbl_catalogo_municipio(municipio_no),

estatus_cliente_no
tipo_cliene_no
clasificacion_no
ciclo_no
serie_no
ultima_factura_no
fecha_inicia_ciclo
fecha_finaliza_ciclo
fecha_emision
fecha_vence
proxima_fecha_inicia
proxima_fecha_finaliza
proxima_fecha_emision
proxima_fecha_vence
fecha_creacion
fecha_activo
fecha_inactivo
);

constraint
constraint
constraint
constraint
constraint
number(10),
date,
date,
date,
date,
date,
date,
date,
date,
date
date
date

fk_estatus_cliente_no_tmc
fk_tipo_cliente_no_tmc
fk_clasificacion_no_tmc
fk_ciclo_no_tmc
fk_serie_no_tmc

references
references
references
references
references

tbl_catalogo_estatus_cliente(estatus_cliente_no),
tbl_catalogo_tipo_cliente(tipo_cliente_no),
tbl_clasificacion_cliente(clasificacion_no),
tbl_catalogo_ciclos(ciclo_no),
tbl_catalogo_serie_factura(serie_no),

default sysdate constraint ccn_fecha_creacion_tmc not null,
default sysdate constraint ccn_fecha_activo_tmc not null,

Existe alguna regla para la redacción
No, en realidad no existe una regla que se deba seguir con respecto de la redacción de las
sentencias SQL, usted puede incluir espacios en blanco a su criterio, carácter TAB, retorno de línea
(enter), pero si usted recorre cuidadosamente la sección de CREATE TABLE de este manual, notará
cierto patrón:
Una sangría uniforme.
Nombres descriptivos por sí mismos.
Orden en general.
Estas son consideradas buenas prácticas y su empleo beneficia tanto a desarrolladores, analistas
y demás participantes en el proceso de desarrollo y explotación del Software. Entonces usted debe
de tener en mente al momento del diseño y construcción de sentencias, estas buenas prácticas.
Además usted puede observar el empleo de un estándar en la definición del nombre de los
objetos o elementos de estos, puede pues apreciar el uso de:
TBL_ para iniciar el nombre de una tabla.
Cnn para la definición de un Constraint Not Null.
_????? Para finalizar el nombre de una tabla o constraint y estos valores son la inicial del
nombre al que pertenecen, si es cuidadoso, verá que los Constraint NOT NULL para
fecha_creado podrían colisionar por ya existir un objeto con un nombre igual, por ello se
emplea esa consideración o norma para evitar dicho problema.
Con respecto de estos últimos detalles, usted debe tener noción de los estándares que se aplican
según el sistema del cual usted forma parte del grupo de desarrolladores, analistas o técnicos
informáticos, deberá respetarlos en la construcción de objetos en la Base de Datos. Los que usted
puede apreciar en el presente manual son una mera referencia o sugerencia para un correcto
proceso de desarrollo de soluciones informáticas.

Global Temporary Tables2
Crea una tabla temporal personal para cada sesión. Eso significa que los datos no se
comparten entre sesiones y se eliminan al final de la misma.
CREATE GLOBAL TEMPORARY TABLE tbt_tabla_temp (
columna datatype [DEFAULT expr] [column_constraint(s)]
[,columna datatype [,...]]
) {ON COMMIT DELETE ROWS | ON COMMIT PRESERVE ROWS};

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

Teoría de la normalización3
En el desarrollo del diseño lógico obtenemos una serie de tablas finales que son las
candidatas a formar nuestra base de datos. Sin embargo, dichas tablas han sido obtenidas a partir de
un diseño conceptual elaborado sin ningún tipo de reglas, por lo que podemos obtener un diseño de
tablas más o menos heterogéneo.
La teoría de la normalización consiste en un conjunto de reglas formales que nos permiten
asegurar que un diseño lógico cumple una serie de propiedades, corrigiendo la estructura de los
datos de las tablas y evitando una serie de problemas como:
·
·
·
·
·

Incapacidad de almacenar ciertos hechos.
Redundancias y por tanto, posibilidad de inconsistencias.
Ambigüedades.
Pérdida de información.
Aparición en la base de datos de estados no válidos en el mundo real, es lo que se llama
anomalías de inserción, borrado y modificación.

Las reglas formales de la teoría de la normalización son conocidas con el nombre de formas
normales. Existen seis formas normales, de forma que cuando la base de datos cumple las reglas de
la primera forma normal se considera que está en primera forma normal (1FN), cuando pasan la
segunda, que está en segunda forma normal (2FN), etc. Además, una base de datos de la que se
afirme que está en 2FN, está también en 1FN, pues las formas normales se aplican de forma sucesiva.

2
3

Tomado de: http://ora.u440.com/ddl/create%20global%20temporary%20table.html
Tomado de: Adquisición y tratamiento de datos - Diseño de bases de datos relacionales.

De las seis formas normales, generalmente solo se aplican sobre las bases de datos las tres
primeras, considerando que una base de datos que está en 3FN es una base de datos correctamente
diseñada. Por ello, expondremos a continuación estás tres primeras formas normales.

Primera forma normal (1FN)
Una base de datos se considera que está en 1FN si cada atributo (campo) de una tabla
contiene un solo valor atómico (simple). Un atributo que contiene varios valores puede derivar en
una pérdida de datos.

Segunda forma normal (2FN)
La segunda forma normal, como la tercera que veremos a continuación, se relaciona con el
concepto de dependencia funcional. Entendemos como dependencia funcional a la relación que
tienen los atributos (campos) de una tabla con otros atributos de la propia tabla. Un campo tiene
dependencia funcional si necesita información de otro/s campo/s para poder obtener un valor.
Una tabla se dice que está en segunda forma normal (2FN) si sucede que:
Está en 1FN
Cada atributo (campo) no clave depende de la clave completa, no de parte de ella.
Por supuesto, una base de datos estará en 2FN si todas sus tablas lo están.
La idea intuitiva de la 2FN es identificar todas las tablas con una clave compuesta, pues
todas las tablas con clave simple están por defecto en 2FN si están en 1FN, y comprobar
que cada uno de los campos de esta tabla depende de la clave completa.
Tercera forma normal (3FN)
Una tabla se dice que está en tercera forma normal (3FN) si:
Está en 2FN.
Todos los atributos que no son claves deben ser mutuamente independientes, es
decir, un atributo no debe depender de otro atributo no clave de su tabla.
Si un atributo que no es clave depende de otro atributo que no es clave, la tabla
posiblemente contiene datos acerca de más de una entidad, contradiciendo el principio de
que cada tabla almacene información de una entidad.
Problemas de la Normalización

Mientras la normalización resuelve los problemas relacionados con la estructuración de los
datos en tablas, crea problemas añadidos a su propio concepto, como son la duplicación de datos y la
ineficacia en la recuperación de información.
Así, el proceso de normalización envuelve la descomposición de una tabla en tablas más
pequeñas, lo cual requiere que la clave primaria de la tabla original se incluya, como una clave
foránea, en la tabla/s que se forman. Esto significa que a medida que se van creando estas claves
foráneas se va incrementando las probabilidades de poner en peligro la integridad de la base de
datos.
Otro efecto adicional del número creciente de tablas en la base de datos, es que se ve
disminuido el rendimiento del sistema en la recuperación de la información contenida. Esta
disminución del rendimiento puede ser particularmente importante. Por tanto, en ciertas ocasiones
es necesario llegar a un compromiso entre el nivel de normalización de la base de datos y el
rendimiento del sistema.

Comentarios
Usted puede crear dos tipos de comentarios:
Comentarios sobre (documentando) las sentencias que usted crea. Existen dos
forma de realizar un comentario:
o Entre /*<comentario>*/, ejemplo: /*Este query permite obtener los
clientes con estatus válido*/
o O empleando --, ejemplo –Este query permite obtener los clientes con
estatus válido.
Comentarios asociados a objetos de Schemas u objetos que no son de un
esquema, este tipo de comentarios son almacenados en el Diccionario de Datos
con la Metadada sobre los objetos en sí mismos. Para crear comentarios
asociados a Objetos de la Base de Datos emplee la sentencia COMMENT ON.

Comentarios de documentación
No le tema a realizar documentación entre sus desarrollos, esta buena práctica le ayudará a
usted y al resto del equipo al que usted pertenece o aquel equipo que tendrá relación con sus
desarrollos. Ayuda que consiste en acelerar el proceso de administración y desarrollo al no tener qué
descifrar el porqué de una sentencia o construcción. Los comentarios no tienen efecto sobre la
sentencia a menos que sea un HINT.

Hints
Los Hints son comentarios que pasan instrucciones al Optimizador de Oracle. El Optimizer
usa esos hints para escoger un Plan de Ejecución asociado a la Sentencia SQL, siempre y cuando no
exista alguna razón por la que el Optimizer tenga que ignorar la instrucción.
La utilización de los hints debe ser algo de lo que usted está muy seguro, luego de analizar el
Plan de Ejecución sin ellos y basado en el conocimiento que usted tiene de la Data.

COMMENT ON
Con esta Sentencia usted indica al RDBMS que a continuación agregará al Diccionario de
Datos, comentarios asociados a una Tabla o bien a una Columna de una tabla.

Sintaxis de COMMENT ON
COMMENT ON [TABLE | COLUMN] [Schema.][Tabla.][Campo] IS ‘<Comentario>’;

Semántica de la sintaxis
COMMENT ON
Sentencia que indica que se agregará un comentario a al Diccionario de Datos,
comentarios asociados a una Tabla o bien a una Columna de una tabla.

SCHEMA
De ser necesario escriba el nombre del Schema al que pertenece la Tabla a la cual
estará asociado el comentario, o el nombre de la Tabla a la que pertenece el campo al cual se
asociará el comentario.

TABLA
Escriba el nombre de la Tabla a la cual estará asociado el comentario, o el nombre de
la Tabla a la que pertenece el campo al cual se asociará el comentario.

CAMPO
Indique el campo al cual será asociado el comentario.

IS
Esta cláusula indica que a continuación escribiremos el texto del comentario a asociar.

COMENTARIO
Escriba entre apóstrofes el texto que describa de forma clara el objetivo de la Tabla o
Campo, este comentario deberá ser una ayuda a los usuarios y técnicos que tengan relación
con el objeto al que se asocia el comentario.

Agregando comentarios
Teniendo en cuenta las Tablas que hemos creado con el presente manual, ahora
agregaremos comentarios tanto a Tablas como a los Campos o Columnas de la Tabla:

Comentarios sobre Tabla

COMMENT ON TABLE tbl_catalogo_genero
para identificar el género de un cliente.';

IS 'Tabla tipo Catálogo que contiene los valores posibles

COMMENT ON TABLE tbl_catalogo_pais
definen la ubicación de la dirección del cliente';

IS 'Tabla tipo Catálogo que contendrá los Países que

COMMENT ON TABLE tbl_catalogo_departamento
IS 'Tabla tipo Catálogo que contendrá los Departamentos
que definen la ubicación de la dirección del cliente';
COMMENT ON TABLE tbl_catalogo_municipio
IS 'Tabla tipo Catálogo que contendrá los Municipios que
definen la ubicación de la dirección del cliente';
COMMENT ON TABLE tbl_catalogo_estatus_cliente
asociados a un cliente.';

IS 'Tabla tipo Catálogo que contendrá los posibles estatus

COMMENT ON TABLE tbl_catalogo_tipo_cliente
IS 'Tabla tipo Catálogo que contendrá los posibles valores
que definen el Tipo de Cliente según su naturaleza legal.';
COMMENT ON TABLE tbl_clasificacion_cliente
que definen la claisificación del Cliente.';


COMMENT ON TABLE tbl_catalogo_ciclos
IS 'Tabla tipo Catálogo que contendrá los Ciclos de
Facturación a los que puede ser asignado un cliente para su periodicidad de facturación.';
COMMENT ON TABLE tbl_catalogo_serie_factura
de Serie de Factura que se asocian a un Cliente y su Factura.';
COMMENT ON TABLE tbl_maestra_cliente
Clientes que administra el Sistema.';

Comentarios sobre Campos

IS 'Tabla Maestra que contiene la información de los

COMMENT ON COLUMN tbl_catalogo_genero.genero_no
IS 'Campo cuyos valores son el identificador único
del genero del cliente, su función es permitir la relación entre aquellas tablas que requieren la
definición de un género de persona.';
COMMENT ON COLUMN tbl_catalogo_genero.genero
IS 'Descriptivo corto que define el genero de una
persona.';
COMMENT ON COLUMN tbl_catalogo_genero.descripcion_genero IS 'Descripción larga del genero de una persona.';
COMMENT ON COLUMN tbl_catalogo_genero.fecha_creacion
IS 'Campo cuyo valor indica la fecha en que se
creó el registro.';
COMMENT ON COLUMN tbl_catalogo_genero.fecha_activo
encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_catalogo_genero.fecha_inactivo
IS 'Campo cuyo valor indica la fecha en que ya no
se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_catalogo_pais.pais_no
del Pais, su función es permitir la relación entre aquellas tablas que requieren la definición de un
País.';
COMMENT ON COLUMN tbl_catalogo_pais.pais
IS 'Campo cuyo valor define el nombre del País';
COMMENT ON COLUMN tbl_catalogo_pais.descripcion_pais
IS 'Descripción del País.';
COMMENT ON COLUMN tbl_catalogo_pais.fecha_creacion
IS 'Campo cuyo valor indica la fecha en que se creó
el registro.';
COMMENT ON COLUMN tbl_catalogo_pais.fecha_activo
COMMENT ON COLUMN tbl_catalogo_pais.fecha_inactivo
IS 'Campo cuyo valor indica la fecha en que ya no se
COMMENT ON COLUMN tbl_catalogo_departamento.departamento_no
IS 'Campo cuyos valores son el
identificador único del Departamento, su función es permitir la relación entre aquellas tablas que
requieren la definición de un Departamento.';
COMMENT ON COLUMN tbl_catalogo_departamento.departamento
IS 'Nombre del Departamento.';
COMMENT ON COLUMN tbl_catalogo_departamento.descripcion_departamento
IS 'Descripción del Departamento.';
COMMENT ON COLUMN tbl_catalogo_departamento.fecha_creacion
IS 'Campo cuyo valor indica la fecha
en que se creó el registro.';
COMMENT ON COLUMN tbl_catalogo_departamento.fecha_activo
en que se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_catalogo_departamento.fecha_inactivo
en que ya no se encuentra disponible en el sistema le registro de la tabla, empleado para definir
vigencias.';
COMMENT ON COLUMN tbl_catalogo_municipio.municipio_no
identificador único del Municipio, su función es permitir la relación entre aquellas tablas que requieren
la definición de un País.';
COMMENT ON COLUMN tbl_catalogo_municipio.municipio
IS 'Nombre del Municipio.';
COMMENT ON COLUMN tbl_catalogo_municipio.descripcion_municipio
IS 'Descripción del Municipio.';
COMMENT ON COLUMN tbl_catalogo_municipio.fecha_creacion
IS 'Campo cuyo valor indica la fecha en
que se creó el registro.';
COMMENT ON COLUMN tbl_catalogo_municipio.fecha_activo
que se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_catalogo_municipio.fecha_inactivo
que ya no se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_catalogo_estatus_cliente.estatus_cliente_no IS 'Campo cuyos valores son el
identificador único del Estatus del Cliente, su función es permitir la relación entre aquellas tablas que
requieren la definición de un estatus de Cliente.';
COMMENT ON COLUMN tbl_catalogo_estatus_cliente.estatus_cliente
IS 'Texto que define el estatus del
Cliente.';
COMMENT ON COLUMN tbl_catalogo_estatus_cliente.descripcion_tipo
IS 'Descripción del Estatus del
Cliente.';
COMMENT ON COLUMN tbl_catalogo_estatus_cliente.fecha_creacion
que se creó el registro.';
COMMENT ON COLUMN tbl_catalogo_estatus_cliente.fecha_activo
que se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_catalogo_estatus_cliente.fecha_inactivo
que ya no se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';

COMMENT ON COLUMN tbl_catalogo_tipo_cliente.tipo_cliente_no
IS 'Campo cuyos valores son el identificador
único del Tipo del Cliente, su función es permitir la relación entre aquellas tablas que requieren la
definición de un Tipo de Cliente.';
COMMENT ON COLUMN tbl_catalogo_tipo_cliente.tipo_cliente
IS 'Texto que define el Tipo del Cliente.';
COMMENT ON COLUMN tbl_catalogo_tipo_cliente.descripcion_tipo IS 'Descripción del Tipo de Cliente.';
COMMENT ON COLUMN tbl_catalogo_tipo_cliente.fecha_creacion
creó el registro.';
COMMENT ON COLUMN tbl_catalogo_tipo_cliente.fecha_activo
COMMENT ON COLUMN tbl_catalogo_tipo_cliente.fecha_inactivo
IS 'Campo cuyo valor indica la fecha en que ya
no se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_clasificacion_cliente.clasificacion_no
identificador único de la Clasificación del Cliente, su función es permitir la relación entre aquellas
tablas que requieren la definición de una Clasificación de Cliente.';
COMMENT ON COLUMN tbl_clasificacion_cliente.clasificacion
IS 'Texto que define la Clasificación
del Cliente.';
COMMENT ON COLUMN tbl_clasificacion_cliente.descripcion_clasificacion IS 'Descripción de la Clasificación
del Cliente.';
COMMENT ON COLUMN tbl_clasificacion_cliente.fecha_creacion
en que se creó el registro.';
COMMENT ON COLUMN tbl_clasificacion_cliente.fecha_activo
en que se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_clasificacion_cliente.fecha_inactivo
en que ya no se encuentra disponible en el sistema le registro de la tabla, empleado para def inir
vigencias.';
COMMENT ON COLUMN tbl_catalogo_ciclos.ciclo_no
del Ciclo de Facturación, su función es permitir la relación entre aquellas tablas que requieren la
definición de un Ciclo de Facturación.';
COMMENT ON COLUMN tbl_catalogo_ciclos.leyenda_ciclo
IS 'Texto que define el Ciclo de Facturación.';
COMMENT ON COLUMN tbl_catalogo_ciclos.descripcion_ciclo IS 'Descripción del Ciclo de Facturación.';
COMMENT ON COLUMN tbl_catalogo_ciclos.fecha_creacion
IS 'Campo cuyo valor indica la fecha en que se creó
el registro.';
COMMENT ON COLUMN tbl_catalogo_ciclos.fecha_activo
COMMENT ON COLUMN tbl_catalogo_ciclos.fecha_inactivo
IS 'Campo cuyo valor indica la fecha en que ya no
COMMENT ON COLUMN tbl_catalogo_serie_factura.serie_no
IS 'Campo cuyos valores son el identificador
único de la Serie de Factura, su función es permitir la relación entre aquellas tablas que requieren la
definición de una Serie de Factura.';
COMMENT ON COLUMN tbl_catalogo_serie_factura.serie_factura
IS 'Texto que define la Serie de Factura.';
COMMENT ON COLUMN tbl_catalogo_serie_factura.descripcion_serie IS 'Descripción de la Serie de Factura.';
COMMENT ON COLUMN tbl_catalogo_serie_factura.fecha_creacion
IS 'Campo cuyo valor indica la fecha en que
se creó el registro.';
COMMENT ON COLUMN tbl_catalogo_serie_factura.fecha_activo
COMMENT ON COLUMN tbl_catalogo_serie_factura.fecha_inactivo
ya no se encuentra disponible en el sistema le registro de la tabla, empleado para definir vigencias.';
COMMENT ON COLUMN tbl_maestra_cliente.cliente_no
IS 'Campo cuyo valor es el identificador
único del Cliente y cuyo fin es permitir la relación entre este y los demás objetos o registros que
ameriten estár referenciados a él.';
COMMENT ON COLUMN tbl_maestra_cliente.genero_no
IS 'Llave foránea que permite la relación del
Cliente con respecto de su género esta relación es hacia la tabla/campo tbl_catalogo_genero.genero_no.';
COMMENT ON COLUMN tbl_maestra_cliente.primer_nombre
IS 'Campo que contendrá el Primer Nombre del
Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.segundo_nombre
IS 'Campo que contendrá el Segundo Nombre del
Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.tercer_nombre
IS 'Campo que contendrá de poseerlo el Tercer
Nombre del Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.primer_apellido
IS 'Campo que contendrá el Primer Apellido
del Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.segundo_apellido
IS 'Campo que contendrá el Primer Apellido
del Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.apellido_casada
IS 'dCampo que contendrá el Apellido del
Casada de un Cliente Mujer.';
COMMENT ON COLUMN tbl_maestra_cliente.fecha_nacimiento
IS 'Campo que contendrá la fecha de
nacimiento del Cliente.';

COMMENT ON COLUMN tbl_maestra_cliente.nit
IS 'Campo que contendrá el número de
Tributación del Cliente ante la SAT.';
COMMENT ON COLUMN tbl_maestra_cliente.dpi
Identificación único de un individuo expresado en su DPI.';
COMMENT ON COLUMN tbl_maestra_cliente.pasaporte
Pasaporte del Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.direccion1
IS 'Campo que contendrá un Texto que Describa
la Dirección de Residencia y Notificaciones del Cliente, de necesitar más espacio para expresar la
Dirección se cuenta con otros dos campos.';
IS 'Campo que contendrá un Texto complemento
que Describa la Dirección de Residencia y Notificaciones del Cliente, de necesitar más espacio para
expresar la Dirección se cuenta con otro campo más para dicho efecto.';
IS 'Campo que contendrá un Texto complemento
que Describa la Dirección de Residencia y Notificaciones del Cliente, no existen más espacios para este
efecto.';
COMMENT ON COLUMN tbl_maestra_cliente.pais_no
IS 'Campo que permite la relación del Cliente
con respecto del País en donde reside.';
COMMENT ON COLUMN tbl_maestra_cliente.departamento_no
con respecto del Departamento en donde reside.';
COMMENT ON COLUMN tbl_maestra_cliente.municipio_no
con respecto del Municipio en donde reside.';
COMMENT ON COLUMN tbl_maestra_cliente.estatus_cliente_no
con respecto de su Estatus';
COMMENT ON COLUMN tbl_maestra_cliente.tipo_cliene_no
IS 'Campo que permite definir el Tipo de
Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.clasificacion_no
IS 'Campo que permite definir el la
Clasificación del Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.ciclo_no
IS 'Campo que permite definir el Ciclo de
Facturación al cual pertenece el Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.serie_no
IS 'Campo que permite definir la Serie de
Facturas que corresponde a un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.ultima_factura_no
IS 'Campo que contiene el identificador de la
última factura válida que forma parte de la Cuenta Corriente de un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.fecha_inicia_ciclo
IS 'Campo que contiene la fecha inicial de la
COMMENT ON COLUMN tbl_maestra_cliente.fecha_finaliza_ciclo
IS 'Campo que contiene la fecha final de la
COMMENT ON COLUMN tbl_maestra_cliente.fecha_emision
IS 'Campo que contiene la fecha de emisión de
la última factura válida que forma parte de la Cuenta Corriente de un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.fecha_vence
IS 'Campo que contiene la fecha en que vence
de la última factura válida que forma parte de la Cuenta Corriente de un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.proxima_fecha_inicia
IS 'Campo que contiene la fecha inicial de la
próxima factura a emitirse para un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.proxima_fecha_finaliza IS 'Campo que contiene la fecha final de la
próxima factura a emitirse para un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.proxima_fecha_emision
IS 'Campo que contiene la fecha de emisión de
la próxima factura a emitirse para un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.proxima_fecha_vence
IS 'Campo que contiene la fecha en que vence
la próxima factura a emitirse para un Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.fecha_creacion
se creó el Cliente.';
COMMENT ON COLUMN tbl_maestra_cliente.fecha_activo
se encuentra activo el Cliente dentro del Sistema.';
COMMENT ON COLUMN tbl_maestra_cliente.fecha_inactivo
ya no se encuentra activo el Cliente dentro del Sistema.';

Documentar es una buena práctica
Es importante que usted adopte buenas prácticas al desempeñarse en la labor del Desarrollo
y Mantenimiento de Sistemas, tal como usted ve, Oracle le provee una forma de documentar y está
constituida por los comentarios, tanto como parte de las Sentencias que usted elabora, así como
parte del Diccionario de Datos o Metadata. Estas prácticas harán más fácil y eficiente las tareas de
Desarrollo y Mantenimiento de un Sistema basado en data perdurable alojada en una Base de Datos
y gestionada por un Sistema de Administración de Base de Datos Relacionales. Pierda pues el miedo
de documentar y genere soluciones que sean fáciles y amigables de administrar.

¿Qué es un índice?
Un índice es un objeto de la Base de Datos, cuya finalidad es crear un acceso directo a la
información de manera tal que su obtención sea rápida.
Oracle accede a los datos de dos maneras:
1. Recorriendo las tablas; comenzando el principio y extrayendo los registros que
cumplen las condiciones de la consulta; lo cual implica posicionar las cabezas
lectoras, leer el dato, controlar si coincide con lo que se busca (como si pasáramos
una a una las páginas de un libro buscando un tema específico).
2. Empleando índices; recorriendo la estructura de árbol del índice para localizar los
registros y extrayendo los que cumplen las condiciones de la consulta (comparando
con un libro, diremos que es como leer el índice y luego de encontrar el tema
buscado, ir directamente a la página indicada).
Un índice posibilita el acceso directo y rápido haciendo más eficiente las búsquedas. Sin
índice, Oracle debe recorrer secuencialmente toda la tabla para encontrar un registro.
Los índices son estructuras asociadas a tablas, una tabla que almacena los campos indexados
y se crean para acelerar las consultas.
La desventaja es que consume espacio en el disco en disco y genera costo de mantenimiento
(tiempo y recursos).
Es importante identificar el o los campos por los que sería útil crear un índice, aquellos
campos por los cuales se realizan búsquedas con frecuencia: claves primarias, claves externas o
campos que combinan tablas.
No se recomienda crear índices sobre campos que no se usan con frecuencia en consultas o
en tablas muy pequeñas.
Los cambios sobre la tabla, como inserción, actualización o eliminación de registros, son
incorporados automáticamente.
Cuando creamos una restricción "primary key" o "unique" a una tabla, Oracle
automáticamente crea un índice sobre el campo (o los campos) de la restricción y le da el mismo
nombre que la restricción. En caso que la tabla ya tenga un índice, Oracle lo usa, no crea otro.

Oracle permite crear distintos tipos de índices. "Normal" es el estándar de Oracle, son índices
tipo árbol binario; contiene una entrada por cada valor de clave que almacena la dirección donde se
encuentra el dato. Es el tipo predeterminado y el más común.

CREATE INDEX
La sentencia tipo DDL: CREATE INDEX le indica al RDBMS que solicitamos la creación de un
índice. Los índices pueden ser creados sobre:
Uno o más campos de una Tabla, una Tabla Particionada, una Tabla index-organized o un
Cluster.
Uno más atributos Tipo Objeto escalar de una Tabla o Cluster.
Una Tabla anidada para indexar una columna de una Tabla anidada.
Entonces, un siendo un objeto el índice este contiene una entrada por cada valor que aparece en
los campos indexados de una Tabla o Cluster. La Base de Datos Oracle soporta varios tipos de índices
y esto son:
Índices normales. Por defecto, Oracle crea índice B-tree.
Índices Bitmap, que almacenan los rowid asociados con el valor llave como un bitmap.
Índices particionados, que consiste en particiones conteniendo una entrada por cada
valor que reside en el campo o campos indexados de la Tabla.
Índices basados en funciones, que están basados en expresiones. Ellos le permiten a
usted construir consultas que evalúan el valor retornado basado en una expresión, que
quizá inclua ye Funciones nativas de Oracle.
Índices de Dominio, que son instancias de un índice de una Aplicación en específico del
tipo indextype.

Sintaxis de CREATE INDEX
CREATE [UNIQUE | BITMAP] INDEX [Schema.]<Nombre del índice> ON [Schema.]<Nombre
Tabla> (<lista de campos a indexar>);

Semántica
CREATE INDEX
Que solicita al RDBMS la creación de un índice.

UNIQUE
Especifique esta cláusula para indicar que el valor de la columna o columnas bajo los
cuales está creado el índice deberán ser únicos. Usted no puede crear índices únicos para
índices de Dominio.

BITMAP
Especifique esta cláusula para indicar que el índice será creado con un bitmap para
cada llave, en lugar de indexar cada fila o registro por separado. Los índices bitmap
almacenan el rowid asociado al valor de la llave como un bitmap. Cada bit en el bitmap
corresponde a un posible rowid. Si el Bit es asignado, entonces significa que el registro con
su correspondiente rowid contiene el valor llave. La representación de bitmaps es la mejor
opción para aplicaciones con bajos niveles de transacciones concurrentes, tales como un
Data Ware House. Los índices de tipo Bitmap tienen las siguientes restricciones:
Usted no puede especificar la cláusula BITMAP cuando crea un índice global
particionado.
No se puede crear un índice secundario BITMAP sobre una tabla index-organized
a menos que dicha tabla tenga una Tabla mapping asociada a ella.
No se puede especificar esta cláusula para índices de Dominio.
Un índice BITMAP únicamente pude tener hasta 30 columnas.

SCHEMA
De ser necesario especifique con el nombre del Schema al que pertenecerá el índice.
Si usted no lo especifica será creado bajo el Schema del usuario que crea el índice.

ON
Seguido de esta cláusula usted indicará al RDBMS la Tabla sobre la cual usted creará
el índice.

SCHEMA
De ser necesario especifique el esquema al que pertenece la tabla sobre la cual
creará el índice. Si se omite, por defecto será sobre el Schema del usuario que lo crea.

Tabla
Especifique el nombre de la Tabla sobre la cual será creado el índice.

Lista de Campos
Escriba el nombre de los campos que serán indexados.

Creando Índices
Siguiendo con las Tablas que hemos creado a través de este manual, ahora crearemos índices
para algunos de los campos de esas tablas:

CREATE INDEX idx_on_tipo_cliene_no_tmc

on tbl_maestra_cliente(tipo_cliene_no);

CREATE INDEX idx_on_clasificacion_no_tmc on tbl_maestra_cliente(clasificacion_no);

CREATE SEQUECE4
Emplee la sentencia CREATE SEQUENCE para crear una Secuencia, que es un objeto de Base
de Datos que es empleado por muchos usuarios para la generación de enteros únicos. Usted puede
usar las secuencias para generar automáticamente los valores para los Primary Key.
Cuando un número de la secuencia es generado, la secuencia se incrementa,
independientemente si la transacción es confirmada o deshecha (commit o rollaback). Si dos
usuarios incrementan la misma secuencia, los números que ellos usan de la secuencia tendrán una
diferencia de correlación, dada la generación de distintos números según se solicitó el incremento de
la secuencia por cada usuario.
Los números de las Secuencias son creados sin dependencia de las Tablas, de esta suerte los
números de las Secuencias pueden ser utilizados para diferentes tablas. Es posible pues, que los
números de las Secuencias parecieran no ser correlativos y que alguno de ellos han sido salteados,
esto es debido a que en las transacciones que incrementan la secuencia, alguna de dichas
transacciones hayan sido deshechas (rollback).
Después de que una secuencia es creada, usted puede acceder a sus valores, empleando
sentencias SQL con la seudo columnas:
4

Tomado de: Oracle® Database - SQL Language Reference - 12c Release 1 (12.1) - E17209-14.

CURRVAL: Que retorna el valor actual de la Secuencia.
NEXTVAL: Que incrementa la Secuencia y retorna el nuevo valor
incrementado.

Sintaxis de CREATE SEQUENCE
Usted puede crear una secuencia obedeciendo esta sintaxis:
Create Secuence [schema.] [nombre de la secuencia]
Increment by [integer]
Start whit [integer]
Maxvalue [integer]
Nomaxvalue
Minvalue [integer]
Nominvalue
Cycle
Nocycle
Cache
Nocache
Order
Noorder
Keep
Nokeep
Session
Global

Semántica de la Sintaxis
Data la sintaxis para la Creación de una secuencia, tenemos que el significado o función de
las cláusulas son:

Create Secuence
Solicita al RDBMS la creación de una secuencia.

Schema
Indica a qué esquema pertenecerá la secuencia. Si un esquema no es especificado,
Oracle lo asignará al Schema del usuario que solicita su creación.

Nombre de la Secuencia
Definirá el nombre de la Secuencia, recuerde el empleo de un estándar válido que
obedezca buenas prácticas y que se apegue a los estándares del Sistema del cual formará
parte.

Increment By
Con esta cláusula usted puede especificar el intervalo entre los número de la
Secuencia. Este valor entero puede ser bien sea positivo o negativo, pero no puede ser cero
(0). Este valor puede tener hasta 28 dígitos para una secuencia ascendente y 27 para una
secuencia descendente. El valor absoluto de la secuencia debe ser menor que la diferencia
entre Maxvalue y Minvalue. Si este valor es negativo, entonces la secuencia es descendente.
Si es positivo entonces la secuencia es ascendente. Si usted omite esta cláusula, el intervalo
adquiere un valor por defecto de 1.

Start with
Especifica el valor de inicio de la secuencia, usted debe emplear esta cláusula para
iniciar una secuencia ascendente en el valor más grande que su valor mínimo o una
descendente en su valor menor que su máximo.
Para secuencias ascendentes, el valor
por defecto es el valor mínimo de la secuencia. Para secuencias descendentes el valor por
defecto de esta cláusula es su valor máximo. Este valor entero puede tener hasta 28 o
menos dígitos para valores positivos y 27 o menos para valores negativos.
Maxvalue
Especifica el valor máximo que puede generar la secuencia. Este valor puede ser un
entero de hasta 28 o menos dígitos para valores positivos y 27 o menos dígitos para valores
negativos. Maxvalue deberá ser igual o mayor a el valor de la cláusula Start With y deberá
ser mayor que el valor de la cláusula Minvalue.

Nomaxvalue
Definir esta cláusula en la creación de la Secuencia indicará que el valor máximo de la
misma será 10 elevado a la 28 potencia menos 1 para secuencias ascendentes o -1 para
secuencias descendentes.

Minvalue
Con el valor de esta cláusula se especifica el valor mínimo de la Secuencia. Este
puede tener un valor entero de 28 o menos dígitos para valores positivos o 27 o menos para
valores negativos. Minvalue debe ser igual o menor a el valor de la cláusula Start With y
deberá ser menor que el valor de la cláusula Maxvalue.

Nominvalue
Indica un valor mínimo de 1 para Secuencias ascendentes o -10 elevado a la 27
potencia -1, para Secuencias descendentes.

Cycle
Especifica que la Secuencia continuará generando valores luego de alcanzar su valor
máximo o mínimo. Después que una Secuencia ascendente alcance su valor máximo, esta
generará su valor mínimo. En el caso de una Secuencia descendente generará su valor
máximo.

Nocycle
Específica que la Secuencia no deberá generar más valores una vez haya alcanzado su
valor mínimo o máximo.

Cache
Con esta cláusula usted puede especificar cuántos valores de la Secuencia debe la
Base de Datos mantener en memoria para su acceso inmediato. Este valor entero puede
tener 28 o menos dígitos. El valor mínimo de esta cláusula es 2. Para Secuencias que son
Cíclicas, este valor debe ser menor que los valore del ciclo. No se pueden almacenar en
Cache más valores que pueden ser empleados en un ciclo de la Secuencia. En consecuencia,
el valor máximo permitido para esta cláusula [Cache] deberá ser menor que el resultado de
la siguiente fórmula: (CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT). Si existe un fallo en el
Sistema, todos los valores alojados en memoria para la Secuencia y que no han sido usados
en una transacción asegurada (commit), serán perdidos.

Nocache
Especifica que no se desean valores almacenados en memoria. Si usted omite las
cláusulas Cache, Nocache, entonces la Base de Datos almacena en Cache 20 números de la
Secuencia por defecto.

Order
Con esta cláusula usted exige que se garantice que los números de la Secuencia son
generados en el orden en que son solicitados. Esta cláusula es útil si usted está empleando
secuencias tipo Timestamp. Garantizar el orden de Secuencias cuyo objetivo son la
generación de llaves primarias, generalmente no es necesario. Esta cláusula es pues
necesaria para garantizar el orden de generación si usted emplea Oracle Real Application
Clusters. Si usted está empleando el Exclusive Mode, entonces las Secuencias siempre
generarán los valores de ella en orden.

Noorder
Emplee esta cláusula si usted no desea que se generen los valores en el órden de
requisición de incremento de la Secuencia. Si usted omite esta cláusula, Oracle la incluye por
defecto.

Keep
Especifique esta cláusula si usted desea que Nextval retenga su valor original durante
el replay para Application Continuity. Este comportamiento ocurrirá solo si el usuario que
ejecuta la aplicación es el propietario del Schema que contiene a la Secuencia. Esta cláusula
es útil para proveer Variables de Entorno (de aplicación y ejecución de aplicación) en la
continuidad de la aplicación luego de restaurarse la misma durante un error.

Nokeep
Con esta cláusula usted especifica que no desea que Nextval retenga su valor original
durante la recuperación de la continuidad de la Aplicación. Oracle define por defecto este
valor para la creación de una Secuencia si usted no la especifica.

Session
Con esta cláusula usted indica que se creará una Secuencia de Sesión. Que es una
tipo especial de Secuencia, destinada a ser empleada con las tablas Global Tempoary Table,
que tienen visibilidad de Sesión. A diferencia de las Secuencias regulares (Globales), una
Secuencia de Sesión retorna un rango único de números únicamente con la Sesión en donde
son empleadas, pero no con relación a otras Sesiones. Otra diferencia consiste en que las
Secuencias de Sesión no son persistentes. Si una sesión finaliza, así mismo lo hace el estado
de las Secuencias de Sesión que son empleadas durante dicha Sesión.
Las cláusulas, Cache, Nocache, order y Noorder son ignoradas cuando se crea una
Secuencia de Sesión.

Global
Especifica que la Secuencia será Global o regular. Para Oracle este valor es por
defecto si usted no lo especifica.

Creando Secuencias
Entonces, siguiendo nuestro modelo de datos a emplear para este Manual, crearemos las
Secuencias Globales necesarias para la generación de Llaves Primarias (PK) de cada tabla que
trabajaremos en adelante.

--Secuencia para el PK de la tabla tbl_catalogo_genero
create
sequence seq_genero_no_tcg
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_pais
create
sequence seq_pais_no_tcp
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_departamento
create
sequence seq_departamento_no_tcd
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_municipio
create
sequence seq_municipio_no_tcm
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_estatus_cliente
create
sequence seq_estatus_cliente_no_tcec

increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_tipo_cliente
create
sequence seq_tipo_cliente_no_tctc
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_clasificacion_cliente
create
sequence seq_clasificacion_no_tcc
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_ciclos
create
sequence seq_ciclo_no_tccf
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_catalogo_serie_factura
create
sequence seq_serie_no_tcsf
increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;
--Secuencia para el PK de la tabla tbl_maestra_cliente
create
sequence seq_cliente_no_tmc

increment by 1
start with 1
minvalue 1
maxvalue 9999999999
nocycle
nocache;

Convención de escritura
No existe una reglamentación definitiva para la redacción o escritura de las Sentencias
SQL, pero tal como lo hemos abordado en otros apartados de Creación, usted puede notar
en las sentencias que anteceden a este apartado, que existe un patrón en la redacción de
las mismas:
Una tabulación identificable, lo que permite a usted y resto del equipo ganar tiempo
en la lectura y análisis de las mismas, lo que se traduce en una buena práctica.
Además, también en estas creaciones usted nota el empleo de SEQ_ como estándar
para la creación de Secuencias, buena práctica que permitirá la rápida identificación
del Objeto Secuencia dentro de la Base de datos. Recuerde que esta es una
sugerencia y usted deberá apegarse a los estándares que rigen el desarrollo y
administración del Sistema en el cual usted se desenvuelve.
Además aquí se aborda el empleo de Comentarios, mismos que se anteceden de
guiones mayores, con lo cual el RDBMS sabe que esa línea es un comentario.
También pueden ser establecidos con /* y */, es decir: /*Esto es un comentario*/.
Son una buena práctica que permitirá al equipo y a usted mismo contar con
referencias prácticas que le permitirán desenvolverse de mejor manera en el
mantenimiento o desarrollo de Soluciones Informáticas.

DROP
La eliminación de Objetos de la Base de Datos se puede realizar con el empleo de la
Sentencia DROP. Las sentencias DROP que usted puede emplear son:
DROP AUDIT POLICY (Unified Auditing)
DROP CLUSTER
DROP CONTEXT
DROP DATABASE
DROP DATABASE LINK
DROP DIMENSION
DROP DIRECTORY
DROP DISKGROUP
DROP EDITION
DROP FLASHBACK ARCHIVE

DROP FUNCTION
DROP INDEX
DROP INDEXTYPE
DROP JAVA
DROP LIBRARY
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
DROP OPERATOR
DROP OUTLINE
DROP PACKAGE
DROP SEQUENCE
DROP SYNONYM
DROP TABLE
DROP TABLESPACE
DROP TRIGGER
DROP TYPE
DROP TYPE BODY
DROP USER
DROP VIEW
DROP TABLE
Emplee esta Sentencia para mover una Tabla o una Tabla Objeto a la papelera de reciclaje o
para removerla de la Base de Datos completamente. Para una Tabla externa, este comando
únicamente remueve la entrada de este objeto del Diccionario de Datos, no tiene pues efecto sobre
la información de la misma, puesto que ella reside fuera de la Base de Datos.
Al solicitar la eliminación de una tabla a través de la Sentencia DROP TABLE, invalida los
objetos dependientes de ella y se eliminan los privilegios sobre dicha Tabla. Si usted desea recrear la
tabla, entonces deberá volver a conceder los permisos que se necesitan sobre ella, así mismo deberá
recrear los índices, los constraints de integridad y los triggers asociados a ella. Si lo que usted
necesita es eliminar la información de la tabla sería una mejor opción la Sentencia DDL TRUNCATE.

Sintaxis de DROP TABLE
DROP TABLE [Schema.][Tabla] [CASCADE CONSTRAINTS] [PURGE];

DROP TABLE
Especifica al RDBMS que estamos solicitando la eliminación de una Tabla.

SCHEMA
De ser necesario especifique el esquema al que pertenece la tabla que desea
eliminar. Si se omite, por defecto será aquella tabla con el nombre especificado que exista
dentro de los objetos del Schema del usuario que ejecuta esta sentencia.

Tabla
Especifique el nombre de la Tabla que desea eliminar.
CASCADE CONSTRAINTS
Con esta cláusula usted indica al RDBMS que se eliminen todos los constraints de
integridad que se asocian tanto a la Llave Primaria, así como a las llaves foráneas que figuran
en la definición de la Tabla que está eliminando. Si usted omite esta cláusula y existen
constraints de integridad asociados a la tabla, entonces la Base de Datos retornará un error.

PURGE
La cláusula PURGE se emplea para indicar que usted al borrar la Tabla y liberar el
espacio asociado a ella. Si usted emplea esta cláusula tanto la Tabla y sus objetos
dependientes no será enviados a la palera de reciclaje. Tenga en cuenta que el empleo de
esta cláusula imposibilita el deshacer la eliminación de la misma.

Operaciones implícitas de DROP TABLE
Cuando usted emplea DROP TABLE, se ejecutan de forma implícita las siguientes
operaciones:
Todos los registros de la Tabla son eliminados.
Todos los índices e índices de Dominio y triggers asociados a la tabla son eliminados. Sin
importar quién los haya creado o el Schema al que pertenezcan. Si la Tabla es particionada,
así mismo los índices locales de partición son eliminados.
Todas las Storage Tables de Tablas anidadas y los LOBs de la Tabla son eliminados.
Cuando usted elimina una Tabla: range, hash, o list-partitioned, la Base de Datos elimina
todas las particiones de la Tabla. Si usted elimina una Tabla composite-partitioned, entonces
tanto las particiones y sub particiones son eliminadas.
Para una Tabla index-organized todas las mapping tables definidas en el index-organized son
eliminadas.
Si la Tabla a eliminar es base de una Vista, el contenedor de una Tabla Maestra o una Vista
Materializada o dicha tabla es referenciada en un Stored Procedure, función o paquete ,
entonces la Base de Datos invalida esos objetos dependientes pero no los elimina. Usted ya
no podrá utilizar esos objetos a menos que recree la Tabla o modifique los objetos de tal
suerte que ya no dependan de ella.

Eliminando Tablas
Teniendo en mente las Tablas que hemos creado con el presente manual, ahora
procederemos a eliminarlas:

drop table tbl_catalogo_genero

cascade constraints purge;

drop table tbl_catalogo_pais


drop table tbl_catalogo_departamento


drop table tbl_catalogo_municipio


drop table tbl_catalogo_estatus_cliente cascade constraints purge;
drop table tbl_catalogo_tipo_cliente


drop table tbl_clasificacion_cliente


drop table tbl_catalogo_ciclos


drop table tbl_catalogo_serie_factura


drop table tbl_maestra_cliente


DROP SEQUENCE
Con esta sentencia usted puede remover una Secuencia de la Base de Datos. También puede
emplear esta Sentencia para reiniciar una Secuencia al eliminarla y luego recrearla.

Sintaxis de DROP SEQUENCE
DROP SEQUENCE [Schema.] [Secuencia];

DROP SEQUENCE
Especifica al RDBMS que estamos solicitando la eliminación de una Secuencia.
SCHEMA
De ser necesario especifique el esquema al que pertenece la secuencia que desea
eliminar. Si se omite, por defecto será aquella secuencia con el nombre especificado que
exista dentro de los objetos del Schema del usuario que ejecuta la sentencia.

Secuencia
Es el nombre de la Secuencia que se desea eliminar.

Eliminando Secuencias
Ahora teniendo como objetivo las Secuencias creadas con este manual, procederemos a
eliminarlas:

DROP SEQUENCE seq_genero_no_tcg;
DROP SEQUENCE seq_pais_no_tcp;
DROP SEQUENCE seq_departamento_no_tcd;
DROP SEQUENCE seq_municipio_no_tcm;
DROP SEQUENCE seq_estatus_cliente_no_tcec;
DROP SEQUENCE seq_tipo_cliente_no_tctc;
DROP SEQUENCE seq_clasificacion_no_tcc;
DROP SEQUENCE seq_ciclo_no_tccf;
DROP SEQUENCE seq_serie_no_tcsf;
DROP SEQUENCE seq_cliente_no_tmc;

DROP INDEX
Con esta sentencia usted puede remover un Índice o un Índice de Domino de la Base de
Datos. Cuando usted elimina un global partitioned index, un range-partitioned index o un hashpartitioned index, todas las particiones del índice también son eliminadas. Si lo que está borrando es
un compoiste-partitioned index, entonces tanto sus particiones como sub particiones también son
eliminadas. Cuando se elimina un índice las estadísticas del mismo también son eliminadas.

Sintaxis de DROP INDEX
DROP INDEX [Schema.] [Índice] [ON LINE] [FORCE];

DROP INDEX
Especifica al RDBMS que estamos solicitando la eliminación de un índice.
SCHEMA
De ser necesario especifique el esquema al que pertenece el índice que desea
eliminar. Si se omite, por defecto será aquel índice con el nombre especificado y que exista
dentro de los objetos del Schema del usuario que ejecuta la sentencia.

Índice
Es el nombre del Índice que se desea eliminar.

ON LINE
Con esta sentencia usted indica que todas las operaciones DML sobre la tabla o
partición serán permitidas durante el proceso de eliminación del índice.

FORCE
Esta cláusula aplica únicamente cuando usted desea eliminar Índices de Dominio.
Con esta cláusula usted elimina el índice de Dominio aún que la rutina indextype retorne un
error o que el índice esté marcado como en PROGRESO.

Eliminando índices
Procederemos pues a eliminar los índices que hemos creado con el presente manual:

DROP INDEX idx_on_tipo_cliene_no_tmc;
DROP INDEX idx_on_clasificacion_no_tmc;

TRUNCATE TABLE
Su función es el eliminar todos los registros de una Tabla. Tenga muy en cuenta que usted no
puede deshacer los resultados del empleo de esta sentencia, pues usted no podrá utilizar la
Sentencia FLASHBACK para retornar los registros que se han eliminado de la Tabla, por ello el empleo

Manual del curso de sql fundamentos y práctica

Manual del curso de sql fundamentos y práctica

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Similar a Manual del curso de sql fundamentos y práctica

Similar a Manual del curso de sql fundamentos y práctica (20)

Más de Byron Quisquinay

Más de Byron Quisquinay (14)

Último

Último (20)

Manual del curso de sql fundamentos y práctica