BENEMRITA UNIVERSIDAD AUTNOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LA COMPUTACIN

TESIS
SISTEMA DE FACTURACIN Y COBRANZA
DE RADIO LOCALIZADORES
QUE PARA OBTENER EL TITULO DE
LICENCIADO EN
CIENCIAS DE LA COMPUTACIN

PRESENTA:

JOS MIGUEL ANGEL OCHOA RODRGUEZ

ASESOR:
M.E. CARMEN CERN GARNICA
PUEBLA, PUE.

Julio 2004

CONTENIDO
INTRODUCCIN
CAPTULO I
MARCO TERICO
1.1 Conceptos de bases de datos ..........................................................................1
1.1.1 Caractersticas .............................................................................................2
1.1.2 Ventajas .......................................................................................................3
1.1.3 El sistema administrador de bases de datos (DBMS) .................................3
1.1.3.1 Funciones del DBMS ...................................................................................3
1.1.3.2 Modelo Entidad Relacin ..........................................................................4
1.1.3.3 Normalizacin ..............................................................................................5
1.2 Modelo Cliente Servidor ................................................................................6
1.2.1 Arquitectura Cliente Servidor ....................................................................7
1.3 Mecanismos de conectividad en las bases de datos........................................8
1.4 Lenguajes de programacin orientados a objetos............................................9
CAPTULO II
SISTEMA MANEJADOR DE BASES DE DATOS ORACLE
2.1 Arquitectura ....................................................................................................15
2.1.1 Bases de Datos..........................................................................................15
2.1.2 Espacios de Tablas....................................................................................15
2.1.3 Archivos de Datos......................................................................................16
2.1.4 Otros archivos............................................................................................16
2.1.5 Instancias...................................................................................................18
2.2 Caractersticas Administrativas de Oracle ......................................................19
2.2.1 Instalacin..................................................................................................19
2.2.2 Gestin del proceso de desarrollo .............................................................24
2.2.2.1 Procesos culturales...................................................................................24
2.2.2.2 Procesos de gestin .................................................................................25
2.2.2.3 Tecnologa ................................................................................................25
2.3 Herramientas de desarrollo Oracle.................................................................26
2.3.1 Arquitectura de datos de Developer Forms y Developer Reports .............28
2.4 Ventajas...........................................................................................................32
CAPTULO III
ANLISIS Y DISEO DEL SISTEMA
3.1 Planteamiento del problema ..........................................................................33
3.2 Anlisis del sistema .......................................................................................33
3.2.1 Especificacin de requerimientos ..............................................................34
3.2.2 Estrategia de solucin................................................................................35
3.3 Modelo funcional............................................................................................36
3.3.1 Narrativa de las funciones del sistema ......................................................36
3.3.2 Narrativa del flujo de datos del sistema (DFD) ..........................................40
3.4 Diseo de la base de datos ...........................................................................46
3.4.1 Entidad Relacin.....................................................................................46
3.4.2 Normalizacin ............................................................................................47
3.4.3 Diseo lgico de la base de datos .............................................................49
3.4.4 Diseo fsico de la base de datos ..............................................................52
3.4.5 Tablas del sistema .....................................................................................54

3.5 Diccionario de datos ......................................................................................56

CAPTULO IV
DESARROLLO DEL SISTEMA
4.1 Herramientas de desarrollo ............................................................................59
4.1.1 Mens ........................................................................................................59
4.1.2 Asistente para Formas...............................................................................60
4.1.3 Pasos para construir una forma.................................................................65
4.1.4 Llamando Reportes desde las Formas ......................................................69
4.2 Ambiente de las herramientas de desarrollo ..................................................70
4.2.1 Forms Builder.............................................................................................71
4.2.2 Forms Runtime ..........................................................................................72
4.2.3 Triggers......................................................................................................73
4.2.4 Reports Builder ..........................................................................................77
4.3 Recursos de hardware y software ..................................................................80
CAPITULO V
PRUEBAS DE DATOS DEL SISTEMA
5.1 A todos los mdulos ........................................................................................81
5.1.1 Sistema de Mens .....................................................................................81
5.1.2 Mdulos .....................................................................................................84
5.1.3 Reportes ....................................................................................................86
CONCLUSIN.......................................................................................................90
PERSPECTIVAS ...................................................................................................91
BIBLIOGRAFA.....................................................................................................92

ii

INDICE DE FIGURAS
CAPTULO I
MARCO TERICO
1.1 Representacin de una tabla, mostrando sus campos y registros ....................2
1.2 Ejemplo de un diagrama Entidad Relacin.....................................................5
1.3 Modelo Cliente Servidor .................................................................................7
CAPTULO II
SISTEMA MANEJADOR DE BASES DE DATOS ORACLE
2.1 Relaciones sobre bases de datos, tablespaces y archivos de datos...............15
2.2 Instancias y bases de datos en Oracle ............................................................19
2.3 Ventana de inicio del asistente de instalacin .................................................20
2.4 Configuracin para desinstalar productos .......................................................21
2.5 Productos disponibles......................................................................................22
2.6 Identificacin de Bases de Datos ....................................................................23
2.7 Fin de la instalacin .........................................................................................23
2.8 Estructura de Forms ........................................................................................27
2.9 Principales relaciones de los objetos de una pantalla .....................................28
2.10 Manejo de la herramienta Forms de Oracle ..................................................29
2.11 Ejemplo de diseo de un Reporte en Developer Reports..............................30
2.12 Funcionamiento de la herramienta Forms de Oracle ....................................31
2.13 Tipos de archivos para mdulos en Forms de Oracle ...................................32
CAPTULO III
ANLISIS Y DISEO DEL SISTEMA
3.1 Modelo Funcional General...............................................................................36
3.2 Modelo Funcional del verificacin de usuarios ................................................37
3.3 Modelo Funcional del catlogos principales ....................................................38
3.4 Modelo Funcional de Generacin y Aplicacin de cuentas x cobrar y facturas .......................... 39

3.5 Modelo Funcional de Generacin de Reportes y Consultas ...........................40

3.6 Diagrama DFD de Nivel 0...............................................................................41
3.7 Diagrama DFD de Nivel 1...............................................................................42
3.8 Diagrama DFD de Nivel 2 Captura General de Datos.................................43
3.9 Diagrama DFD de Nivel 2 Generacin de Cuentas por Cobrar...................44
3.10 Diagrama DFD de Nivel 2 Preparar Cuentas a Cobradores......................44
3.11 Diagrama DFD de Nivel 2 Aplicacin de pagos.........................................45
3.12 Diagrama DFD de Nivel 2 Generacin de Facturas ..................................45
3.13 Diagrama entidad Relacin ........................................................................46
3.14 Diseo lgico de la Base de Datos................................................................51
3.15 Esquema de la tabla Clientes ........................................................................54
3.16 Esquema de la tabla Cobradores ..................................................................54
3.17 Esquema de la tabla Contratos .....................................................................55
3.18 Esquema de la tabla Productos.....................................................................55
3.19 Esquema de la tabla Facturas .......................................................................56
CAPTULO IV
DESARROLLO DEL SISTEMA
4.1 Diseo de la barra de men ............................................................................59
4.2 Conexin a la Base de Datos a travs de Forms de Oracle............................60
4.3 Asistente para generar formas de tipo bloque.................................................61
4.4 Seleccionando la tabla y campos a manejar en la forma ................................61
4.5 Finalizando asistente de bloque de datos .......................................................62

iii

4.6 Seleccionando nombre y tipo de canvas del asistente de Layout ...................62

4.7 Seleccionando nombre y tipo de canvas del asistente de Layout ...................63
4.8 Personalizando propiedades de los Items.......................................................63
4.9 Seleccionando el modo de desplegar los datos ..............................................64
4.10 Propiedades de los elementos mostrados en la forma..................................64
4.11 Base de Datos y Formas ...............................................................................65
4.12 Construccin de un bloque de llaves primarias .............................................66
4.13 Construccin del bloque principal (bloque de trabajo)...................................66
4.14 Unin entre bloques.......................................................................................67
4.15 Cdigo del trigger forma WHEN-NEW-ITEM-INSTANCE .............................68
4.16 Diseo de la pantalla .....................................................................................69
4.17 Llamado de reportes a travs de forms .........................................................70
4.18 Componentes de Forms Builder ....................................................................71
4.19 Elementos de datos .......................................................................................72
4.20 Componentes de Runtime .............................................................................73
4.21 Ejecucin de un Trigger.................................................................................74
4.22 Ventana Object Naviator de Reports Oracle 6i..............................................77
4.23 Ventana Data Model de Reports Oracle 6i ....................................................78
4.24 Ventana Layout Model de Reports Oracle 6i.................................................78
4.25 Ventana Runtime Parameter Form de Reports Oracle 6i..............................79
4.26 Ventana Live Previewer de Reports Oracle 6i...............................................79
CAPITULO V
PRUEBAS DE DATOS DEL SISTEMA
5.1 Men Sistema..................................................................................................81
5.2 Men Catlogos...............................................................................................82
5.3a Men Cuentas por Cobrar con Cancelaciones..............................................82
5.3b Men Cuentas por Cobrar con Reportes.......................................................83
5.4 Barra de herramientas .....................................................................................83
5.5 Mdulo de Catlogo de Clientes .....................................................................84
5.6 Mdulo de Catlogo de Contratos ...................................................................84
5.7 Mdulo de Catlogo de Cobradores................................................................85
5.8 Mdulo de Catlogo de Productos y Servicios ................................................85
5.9 Forma de llamado al reporte de Clientes.........................................................85
5.10 Forma de Generacin de cuentas por cobrar................................................86
5.11 Reporte de General de Clientes ....................................................................87
5.12 Reporte de facturas pagadas ........................................................................87
5.13 Reporte de cartera vencida ...........................................................................88
5.14 Reporte de facturas cobradas por cobrador ..................................................88
5.15 Reporte general de facturas no pagadas por cliente.....................................89

iv

INTRODUCCIN
Con la siguiente tesis se pretende realizar un sistema de facturacin que permita el
manejo de clientes, facturas, cobradores, productos y servicios, el cual ser desarrollado a
travs de una metodologa basada en teora y prctica en bases de datos relacionales e
ingeniera de software. La siguiente accin es la de crear el diseo y la implementacin en
un manejador de bases de datos de Oracle y desarrollar las interfaces a travs del
desarrollador de aplicaciones Developer de Oracle que permite gran flexibilidad para
programar y que es adems compatible con la mayora de computadoras que existe en las
empresas, el lenguaje se eligi bajo previo estudio y evaluacin de otros productos que son
compatibles con bases de datos.
Una de las razones por la cual se decidi hacer un sistema que pueda llevar el
control de facturacin, es porque en la actualidad existe software comercializado que cubre
ciertos puntos de los que una empresa necesita pero en la mayora de los casos, el software
a la medida se adapta al 100% a las necesidades de una empresa y de esta manera cubrir al
mximo los objetivos de la empresa.
A continuacin se da una abreve introduccin de cada captulo
Captulo 1 Marco Terico: Aqu se dan definiciones bsicas para comprender el
inicio de la creacin de una base de datos, as como tambin los
elementos necesarios para poder desarrollar un programa conjuntamente
con una base de datos.
Captulo 2 Sistema manejador de bases de datos oracle: En este captulo se explican
diferentes caractersticas de la Base de Datos de Oracle, as como
tambin las estructuras de datos de las herramientas de desarrollo a
utilizar.
Captulo 3 Anlisis y diseo del sistema: Aqu se dan los detalles de cmo va a
generarse el sistema de facturacin a travs de diferentes herramientas de
diseo de bases de datos e ingeniera de software.
Captulo 4 Desarrollo del sistema: En este captulo se muestra el modo de
implementar las herramientas de desarrollo para generar los mens,
formas, reportes y el cdigo que los hace funcionar; As como tambin la
explicacin del ambiente de las herramientas de desarrollo.
Captulo 5 Pruebas de datos del sistema: Aqu se muestra el funcionamiento que
debe de tener el sistema ya implementado a travs de pantallas de todas
las formas y reportes que comprende el sistema de facturacin.
v

Captulo 1

Marco terico

Este captulo trata a cerca de los conceptos bsicos a cerca de las bases de datos, as
como sus fundamentos y trminos, con el propsito de empezar a entender mejor los
requerimientos necesarios para comenzar a crear el sistema de facturacin.

1.1 Conceptos de Bases de Datos

Definiciones
Un sistema de bases de datos no es ms que un sistema para archivar en una
computadora, es decir, es un lugar donde se almacena un conjunto de archivos de datos
computarizados [DaC01]. Al usuario del sistema se le brindarn recursos para realizar
diversas operaciones sobre estos archivos, incluidas entre otras las siguientes:
Agregar archivos nuevos (vacos) a la base de datos; insertar datos nuevos en archivos ya
existentes; obtener datos nuevos en archivos ya existentes; actualizar archivos ya
existentes; borrar datos en archivos ya existentes y eliminar archivos ya existentes.
Tablas, Campos y Registros
Las tablas son el ncleo de la informacin de una base de datos, en ella se almacena
todos los datos importantes del usuario que estarn disponibles para cualquier accin antes
definida. Las tablas tienen su manera de organizar dicha informacin a travs de los
Campos y Registros.
Los campos definen el tipo de informacin a ser almacenada, en trminos sencillos,
stos nos indican la clase de dato a ser insertado, como por ejemplo en el campo nombre
nicamente sern almacenados los datos de nombre, en el campo cdigo postal
nicamente sern almacenados los cdigos postales de dichas personas o empresas y no
ser almacenado ningn otro tipo de dato.
Los registros son un conjunto de campos que nos definen la informacin de un tipo
de dato, como por ejemplo el conjunto de campos: nombre, apellido, direccin y cdigo
postal nos pueden definir la informacin a cerca de un cliente, amigo, empleado, etc. A
continuacin se muestra una tabla de ejemplo, mostrando lo que es un campo y lo que es un
registro figura 1.1:

CAMPOS

REGISTROS

Nombre Apellidos
Direccin
Pancho Pantera Av. Del Chocolate No.3
Ral
Salinas
Cda. Almoloya 2
Antonio
Tigre
Av. Keloggs #33

Telfono
2569847
3115588
2336655

C. P.
72450
72365
72000

Figura 1.1 Representacin de una tabla, mostrando sus campos y registros

1.1.1 Caractersticas
Se muestran a continuacin los cuatro componentes principales de un sistema de bases
de datos: la informacin, el equipo, los programas y los usuarios [DaC01].
La informacin: Es el propsito y la razn existencial de todo sistema de bases de
datos, pueden ser de cualquier tipo e ndole, la cual puede ser mejor administrada gracias a
la computadora y sus sistemas. Dicha informacin define el tipo de sistema a utilizar,
pueden ser muy pequeos hasta grandes y complejos, dependiendo de la finalidad de la
aplicacin de esos datos. Los sistemas pequeos suelen servir para un solo usuario,
mientras que los sistemas grandes generalmente son multiusuario; en un sistema
multiusuario, varios usuarios pueden tener acceso a la base de datos mientras que en uno
pequeo, un solo usuario puede tener dicho acceso.
El equipo: Gracias al desarrollo rpido y creciente de la tecnologa podemos contar
en la actualidad con equipos suficientemente capaces de llevar a cabo la tarea de ejecutar
un sistema de bases de datos confiablemente, a un costo relativamente bajo a comparacin
de las dcadas anteriores. Las caractersticas del equipo de cmputo dependen de las
caractersticas necesarias que el sistema de bases de datos requiera en velocidad del
procesador, memoria RAM, velocidad de acceso a datos y capacidad en unidades de
almacenamiento como discos duros y si es necesario, una unidad de respaldo.
Los programas: Se entiende por programa todo aquel que pueda realizar alguna
tarea especfica dentro de la computadora, sirviendo como intermediario entre la
computadora y el usuario para realizar un propsito determinado. El sistema de bases de
datos en s es un programa, pero existen otros subprogramas que interactan entre dicho
sistema y la computadora, con la finalidad de distanciar un poco a los usuarios de detalles a
nivel equipo, es decir que esos subprogramas pueden encargarse de esas tareas a nivel
equipo.
El usuario: Se encargue bsicamente de actividades propias de la administracin o
manejo de un sistema de bases de datos. Un ejemplo de esos subprogramas es el Sistema
de Administracin de Base de Datos o tambin llamado DBMS (Database Management
system). El DBMS maneja todas las solicitudes de acceso a la base de datos hechas por los
usuarios, como se vio en el concepto de base de datos anterior, son las acciones de
agregar, consultar, modificar y eliminar archivos de un sistema de bases de datos.
2

1.1.2 Ventajas
Los sistemas de bases de datos nos permiten automatizar diferentes reas de trabajo
en donde se manejan grandes cantidades de productos o servicios y stos requieren de una
administracin adecuada, las bases de datos nos ayudan a encontrar las caractersticas de
dicho producto, hacer un control de inventario, hacer una lista de material faltante para
compras, generar listas de cuentas por cobrar, etc. (slo por nombrar algunas ventajas), de
hecho, la mayora de las empresas emplean ya el uso de una base de datos para mejorar su
desarrollo.

1.1.3 El Sistema de Administracin de Bases de Datos (DBMS)

El sistema de administracin de la base de datos es un conjunto de programas que
maneja todo acceso a la base de datos. Conceptualmente, lo que sucede es lo siguiente:
1. Un usuario solicita acceso, empleando algn sublenguaje de datos determinado (Por
ejemplo, SQL).
2. El DBMS interpreta esa solicitud y la analiza.
3. El DBMS inspecciona, en orden, el esquema externo de ese usuario, la
correspondencia externa / conceptual asociada, el esquema conceptual, la
correspondencia conceptual / interna y la definicin de la estructura de
almacenamiento.
4. El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada.

1.1.3.1 Funciones del DBMS[DaC01]

Definicin de datos: El DBMS debe de incluir componentes procesadores de
lenguajes para cada uno de los diversos lenguajes de definicin de datos (DDL). As
tambin el DBMS debe entender las definiciones DDL, es decir, que entiende que
un registro externo contiene un campo; y debe poder utilizar estos conocimientos para
interpretar y responder las solicitudes de los usuarios

Manipulacin de datos: El DBMS debe ser capaz de atender las solicitudes del
usuario para extraer, y quiz poner al da, datos que ya existen en la base de datos, o
para agregar en ella datos nuevos.

Seguridad e integridad de datos: El DBMS debe supervisar las solicitudes de los

usuarios y rechazar los intentos de violar las medidas de seguridad e integridad
definidas por el administrador de bases de datos

Recuperacin y concurrencia de datos: El DBMS -o algn software asociado con ldebe cuidar del cumplimiento de ciertos controles de recuperacin y concurrencia.

Diccionario de datos: El DBMS debe de incluir una funcin de diccionario de

datos. El contenido del diccionario puede considerarse como Datos a cerca de
datos, es decir, definiciones de otros objetos en el sistema y no slo datos en bruto.
Deber ser posible consultar el diccionario igual que cualquier otra base de datos de
modo que se pueda saber, por ejemplo, cules programas o usuarios podran verse
afectados por alguna modificacin propuesta para el sistema.
3

Desempeo: El DBMS deber ejecutar todas las funciones recin identificadas en la

forma ms eficiente posible

1.1.3.2

Modelo Entidad Relacin [KoH+94] / [HaI94]

Es un conjunto de tcnicas del tipo grfico que permite construir modelo de datos. Implica:
Identificar los asuntos de importancia dentro de una organizacin (Entidades).
Las propiedades de esos asuntos (Atributos).
Cmo se relacionan entre s? (Relacin).
Describiendo los puntos antes mencionados tenemos:
Entidad:
Es una cosa o un objeto con significado, real o imaginario, acerca de las necesidades de
informacin que se van a conocer o mantener.
El nombre de la entidad debe ser el que representa un tipo o clase de elementos. En
particular tenemos dos tipos de entidades:
Entidad particular: Algo del mundo real que tiene existencia independiente.
Entidad: Descripcin de un conjunto de entidades particulares que comparten la
misma estructura.
Atributo: Son caractersticas que califican, cualifican, clasifican o cuantifican
ocurrencias de una entidad.
Tipos de atributos:
o Simples: no se pueden descomponer, describen un solo valor.
o Compuestos: se descomponen en varios atributos.
o Monovaluados: para cada entidad solo hay un atributo.
o Multivaluados: para cada entidad hay varios atributos.
o Derivados: su valor se puede deducir de algun atributo almacenado.
o Clave: tienen un valor diferente para cada entidad particular.

a las

Relacin: Son asociaciones entre dos entidades. Los tipos de relacin se da por una
caracterstica: La Cardinalidad
Cardinalidad
La cardinalidad expresa el nmero de ocurrencias asociadas o implicadas en una
relacin.
o RELACION UNO A VARIOS. Este Tipo de relacin es la ms frecuente en
las bases de datos relacionales.
En una relacin de este tipo, un registro de la tabla A puede tener ms de un
registro coincidente en la tabla B, pero un registro de la tabla B no puede tener
ms de un registro coincidente en la tabla A. Por ejemplo, en una empresa un
proveedor puede suministrar ms de un producto, pero un producto slo tiene
un proveedor.
o RELACION UNO A UNO.- En una relacin uno a uno, un registro de la tabla
A no puede tener ms de un registro coincidente en la tabla B, y un registro de la
tabla B no puede tener ms de un registro coincidente en la tabla A.
4

o RELACION VARIOS A VARIOS.

En una relacin varios a varios, un registro de la tabla A puede tener varios
registros coincidentes en la tabla B, y a su vez un registro de la tabla B ouede
tener varios registros coincidentes en la tabla A
En la figura 1.2 se muestra la aplicacin del modelo Entidad - Relaci

Figura 1.2 Ejemplo de un diagrama Entidad - Relacin

1.1.3.3

Normalizacin

Uno de los pasos ms importantes en el diseo de una base de datos consiste en

asegurarse de que los datos se distribuyan correctamente entre las tablas. Si las estructuras
de datos son correctas, el resto de la aplicacin (las consultas, los formularios, los informes,
el cdigo, etc.) se ver simplificada en gran medida. El nombre formal que recibe el diseo
apropiado de una tabla es del de normalizacin de bases de datos; las reglas de
Normalizacin estn encaminadas a eliminar redundancias e inconsistencias de
dependencia en el diseo de las tablas [BrM+84].
La normalizacin es un proceso que pone las cosas en su sitio, hacindolas
normales. El origen de esta palabra viene del latn norma, que era una "escuadra de
carpintero" para conseguir el ngulo correcto. En geometra, cuando una lnea est en
ngulo recto con otra se dice que estn en un ngulo "normal". En una base de datos, el
trmino tambin tiene un significado matemtico especfico, realizando una separacin de
elementos de datos (tales como nombres, direcciones u oficios) en grupos afines y
definiendo las relaciones normales o "correctas" entre ellos.
5

La normalizacin es una tcnica eficaz para el diseo de bases de datos que puede aplicarse
tanto a sistemas relacinales como a otros modelos. Con la tcnica de la normalizacin se
trata de evitar la dependencia entre inserciones, actualizaciones y borrado de elementos de
las tablas de la base de datos. Tambin se reducen las operaciones de reorganizacin
cuando hay que incorporar nuevos datos [PeC03].
Se tienen como referencia cinco pasos para lograr la normalizacin:
Nivel 0: Cuando ninguna de las reglas de normalizacin se ha aplicado a nuestras
tablas
Nivel 1: Comprende de los siguientes pasos:
1. Eliminar los grupos repetitivos de la tablas individuales.
2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.
Nivel 2: Comprende de los siguientes pasos:
1. Crear tablas separadas para aquellos grupos de datos que se aplican a varios
registros.
2. Relacionar estas tablas mediante una clave externa..
Nivel 3: Eliminar aquellos campos que no dependan de la clave.
Nivel 4: En las relaciones varios-con-varios, entidades independientes no pueden ser
almacenadas en la misma tabla.
Existe otro nivel de normalizacin que se aplica a veces, pero es de hecho
algo esotrico y en la mayora de los casos no es necesario para obtener la
mejor funcionalidad de nuestra estructura de datos o aplicacin. Su
principio sugiere:
Nivel 5: La tabla original debe ser reconstruida desde las tablas resultantes en las
cuales a sido troceada.

1.2 El modelo cliente - servidor.[ DaC91] / [OrR98]

La arquitectura cliente-servidor permite al usuario en una mquina, llamado el
cliente, requerir algn tipo de servicio de una mquina a la que est unido, llamado el
servidor, mediante una red como una LAN (Red de Area Local) o una WAN (Red de Area
Mundial). Estos servicios pueden ser peticiones de datos de una base de datos, de
informacin contenida en archivos o los archivos en s mismos o peticiones de imprimir
datos en una impresora asociada. Aunque clientes y servidores suelen verse como mquinas
separadas, pueden, de hecho, ser dos reas separadas en la misma mquina. Por tanto, una
nica mquina Unix puede ser al mismo tiempo cliente y servidor. Adems una mquina
cliente unida a un servidor puede ser a su vez servidor de otro cliente y el servidor puede
ser un cliente de otro servidor en la red. Tambin es posible tener el cliente corriendo en un
sistema operativo y el servidor en otro distinto.
Hay varios tipos comunes de mquinas clientes en entornos cliente-servidor. Uno de
los clientes ms populares es una computadora personal basada en Intel que ejecuta
aplicaciones de DOS en un entorno Windows. Otra cliente popular es una terminal X; de
6

hecho, el sistema X Windows es un modelo cliente-servidor clsico. Hay tambin clientes

Unix que ejecutan sistemas operativos como UnixWare. Un servidor que pide cosas a otro
servidor es un cliente de la mquina a la que est pidiendo. Sin considerar el tipo de cliente
que se est usando en una red cliente-servidor, se realizando al menos una de las funciones
bsicas descritas aqu como funciones del cliente. En la figura 1.3 se muestra a detalle el
Modelo Cliente Servidor

Figura 1.3 Modelo Cliente - Servidor

1.2.1 Arquitectura cliente servidor.

Funciones del cliente: Los clientes en una red cliente-servidor son las mquinas o
procesos que piden informacin, recursos y servicios a un servidor unido. Estas peticiones
pueden ser cosas como proporcionar datos de una base de datos, aplicaciones, partes de
archivos o archivos completos a la mquina cliente. Los datos, aplicaciones o archivos
pueden residir en un servidor y ser simplemente accedidos por el cliente o pueden ser
copiados o movidos fsicamente a la mquina cliente. Esta disposicin permite a la mquina
cliente ser relativamente pequea. Para cada tipo de entorno de cliente, hay habitualmente
software especfico (y a veces hardware) en el cliente, con algn software y hardware
anlogo en el servidor.
Funciones generales de un servidor: Los servidores en una red cliente-servidor
son los procesos que proporcionan informacin recursos y servicios a los clientes de la red.
Cuando un cliente pide un recurso como, por ejemplo, un archivo, datos de una base de
datos, acceso a aplicaciones remotas o impresin centralizada, el servidor proporciona estos
recursos al cliente. Los procesos del servidor pueden residir en una mquina que tambin
acta como cliente de otro servidor. Adems de proporcionar este tipo de recursos, un
7

servidor puede dar acceso a otras redes, actuando como un servidor de comunicaciones que
conecta a otros servidores o mainframes o minicomputadoras que actuan como hosts de la
red [MoP96].
En el entorno de los mainframes, todas las solicitudes de informacin y las tareas de
programacin pasan a travs del departamento de informtica. Ellos determinan si la
informacin est disponible, cmo extraerla de la base de datos, y darle un formato para el
ejecutivo o vendedor. Cuando se solicita un cambio de programacin o una nueva
aplicacin, ha de realizarse un anlisis costo/beneficio antes de aprobar o rechazar la
peticin. Mientras tanto, el usuario que solicit la informacin o el cambio puede haberse
jubilado o cambiado de trabajo. Con la capacidad de consultar una base de datos SQL
Server usando conexiones ODBC el usuario puede obtener rpidamente la informacin que
necesita para su trabajo, siempre que se tengan los permisos de acceso necesarios.
Con la llegada de la PC (Personal Computer, Computadora Personal) y poco
despus de la LAN (Local Area Network, Red de rea Local), un usuario puede trabajar
con la informacin en bruto como nunca antes. En lugar de esperar un informe
trascendental durante una semana, el usuario puede realizar un anlisis en su propio equipo.
Hasta ahora, los sistemas cliente-servidor han sido el mtodo empleado para saltar
gran parte del vaco entre la computadora central y los sistemas basados en PC/LAN. sta
ha sido una forma efectiva de distribuir la potencia de procesamiento necesaria entre el
usuario y el personal de departamento de informtica. El personal del departamento de
informtica puede mantener la base de datos en su propio servidor, con la adecuada copia
de seguridad. Los usuarios tienen acceso a la informacin necesaria contenida en la base de
datos y pueden procesar sus propias consultas e informes. Este modelo tambin permite la
aplicacin de reglas de negocio a la base de datos, asegurando que la informacin
introducida en la misma cumpla las restricciones de coherencia necesarias, antes de
permitir que se le apliquen cambios o aadidos [ByJ01].

1.3 Mecanismos de conectividad en las Bases de Datos

Cuando una aplicacin es desarrollada y se requiera que interacte con una base de
datos, es necesario utilizar un programa intermediario que realice las transacciones de
informacin entre la aplicacin y la base de datos, slo hablaremos de dos tipos de
conectividades comunes, una es desarrollada para aplicaciones Microsoft llanada ODBC y
otra para el lenguaje multiplataforma Java llama JDBC
ODBC (Open Database Connectivity) es un programa de interface de aplicaciones
(API) para acceder a datos en sistemas manejadores de bases de datos tanto relacionales
como no relacional, utilizando para ello SQL (lenguaje de consulta estructurado).

JDBC (Java Database Connection) crea un interfaz a nivel de programacin para

comunicarnos con las bases de datos en una forma uniforme similar al concepto ODBC de
Microsoft, el cual es un estndar para computadoras personales y LAN's.

1.4 Lenguajes de programacin orientados a objetos

Existen muchos lenguajes diferentes que pueden ser usados para programar una
computadora. El ms elemental de ellos es el lenguaje mquina, coleccin de instrucciones
muy detalladas y crpticas que controlan la circuitera interna de la computadora. Este es el
dialecto natural de la computadora. No obstante, muy pocos programas se escriben
realmente en lenguaje mquina, y ello por dos significativas razones: primero, porque el
lenguaje mquina es muy incmodo de usar y, segundo, porque la mayora de las
computadoras tienen sus propios repertorios de instrucciones, y ello hace que un programa
escrito en lenguaje mquina para un tipo de computadora no pueda ser ejecutado en otro
tipo de computadora sin alteraciones sustanciales[ByS98].
Generalmente, un programa se escribe en algn lenguaje de alto nivel, cuyo
repertorio de instrucciones es ms compatible con los lenguajes humanos y los procesos
humanos de pensamiento. Casi todos los lenguajes de alto nivel son lenguajes de propsito
general, como el Pascal. (Otros lenguajes de propsito general ordinariamente empleados
son Pascal, C, C++, Java. Etc.) Existen tambin algunos lenguajes de alto nivel y de
propsito especial, cuyos repertorios de instrucciones han sido diseados especficamente
para algn tipo particular de aplicacin.
Por regla general, una sola instruccin en un lenguaje de alto nivel ser equivalente
a varias instrucciones en lenguaje mquina. Adems, un programa escrito en lenguaje de
alto nivel puede ejecutarse generalmente en muchas computadoras diferentes con poca o
ninguna modificacin. Por ello el uso de un lenguaje de alto nivel nos ofrece ventajas muy
significativas frente al uso del lenguaje mquina, principalmente simplicidad, uniformidad
y portabilidad (es decir, independencia de la mquina) [ByS98].
Dentro de los lenguajes de alto nivel se cuenta con los lenguajes de programacin
visual, su caracterstica primordial radica en que, utilizan herramientas adicionales propias
de un sistema operativo visual, como por ejemplo, se cuenta con la utilizacin de ventanas,
cuadros de texto, botones, etc. que son programados previamente por los desarrolladores
del lenguaje visual, el programador nicamente debe preocuparse por la manipulacin y
programacin de dichos controles.
Por otro lado, existen lenguajes de programacin que su finalidad est enfocada en
la Web, existen diversos lenguajes de alto nivel de este tipo, entre ellos estn Java, Java
Script, CGI, Perl, entre otros. Estos lenguajes pertenecen a diferentes tendencias de
programacin como se explicar mas adelante.

Para la interfaz del sistema de facturacin se pretende utilizar el lenguaje de

programacin visual llamado Visual Basic, que tiene la facilidad de crear aplicaciones
rpidamente y facilidad de interactuar con bases de datos de SQL Server.
Existen dos paradigmas dentro de los lenguajes de programacin y son las
siguientes:

Estructurados
Orientado a objetos

Para tener una idea fundamental de lo que es la tecnologa orientada a objetos

comenzaremos a definir lo que es un objeto: El termino objeto surgi casi
independientemente en varios campos de la informtica, simultneamente a principios de
los sesenta, para referirse a nociones que eran diferentes en su apariencia, pero relacionados
entre s. Todas estas nociones se inventaron para manejar la complejidad de sistemas
software de tal forma que los objetos representaban componentes de un sistema
descompuesto modularmente o bien unidades modulares de representacin del
conocimiento; Un objeto puede estar compuesto por otros objetos, estos ltimos a su vez,
pueden estar compuestos de objetos, del mismo modo que una maquina esta formada por
partes y estas, tambin, estn formadas por otras partes. Esta estructura intrincada de los
objetos permite definir objetos muy complejos.
Las tcnicas orientadas objetos permiten que el software se construya a partir de
objetos de comportamiento especfico. En el modelo de objetos es necesario estudiar los
principios fundamentales en los que se basa el anlisis orientado a objetos [JaM97] /
[BrE91]:

Objeto
Polimorfismo
Clase
Herencia
Mensaje
Mtodo
Identidad
Reutilizacin
Abstraccin
Encapsulacin
Modularidad
Jerarqua
Concurrencia

Haremos un anlisis individual relativo a la teora de los objetos:

OBJETO: El objeto es un concepto, una abstraccin o una cosa con unos limites
definidos y que es relevante para el tema en cuestin, podemos decir adems que estos
poseen identidad y son distinguibles, aunque dos objetos tengan los mismos valores para
10

todos, sus atributos son diferentes. Para finalizar diremos que se llamara objeto a cualquier
cosa real o abstracta, en la cual podemos almacenar datos y los mtodos para controlar
dichos datos.
POLIMORFISMO: El polimorfismo se define como la posibilidad de asumir varias
formas. El polimorfismo permite que una misma operacin pueda llevarse a cabo de varias
formas, en clases diferentes. Desde este punto de vista, representa un concepto de teora de
tipos en el que un solo nombre puede denotar objetos de muchas clases diferentes que se
relacionan por alguna superclase comn. Cualquier objeto denotado por este nombre es, por
lo tanto, capas de responder a algn conjunto comn de operaciones. Una operacin es una
accin o transformacin que realiza o padece un objeto. La implementacin especfica de
una operacin determinada a una clase determinada se denomina mtodo. Aunque los
mtodos sean distintos, llevan a cabo el mismo propsito operativo, y as estaramos
hablando tambin, de polimorfismo.
Una operacin es una abstraccin de un comportamiento similar (pero no idntico)
en diferentes clases de objetos. La semntica de la operacin debe ser la misma para todas
las clases. Sin embargo, cada mtodo concreto seguir unos pasos especficos. Existe el
polimorfismo cuando interactan las caractersticas de la herencia y el enlace dinmico.
Esta es quizs la caracterstica ms importante de los lenguajes orientados a objetos
despus de su capacidad para soportar la abstraccin y es lo que distingue la programacin
orientada a objetos de otra programacin ms tradicional con tipos abstractos de datos. El
polimorfismo es tambin un concepto central en el diseo orientado a objetos. Una de las
ventajas del polimorfismo es que se puede hacer una solicitud de una operacin sin conocer
el mtodo que debe ser llamado.
CLASE: El termino clase se refiere a la implantacin en software de un tipo de
objeto. Especifica una estructura de datos y los mtodos operativos permisibles que se
aplican a cada uno de los objetos. Una clase puede tener sus propios mtodos y estructura
de datos, as como tambin heredarlos de su superclase. La superclase es la clase de la cual
hereda otra clase, llamada esta ultima subclase inmediata.
Una clase es una abstraccin de un conjunto posiblemente infinito de objetos
individuales. Cada uno de estos objetos se dice que es una instancia o ejemplar de dicha
clase. Cada instancia de una clase posee sus propios valores para sus atributos, pero
comparte el nombre de estos atributos y las operaciones con el resto de instancias de su
clase. La eleccin de clases es arbitraria, y depende del dominio del problema.
La industria utiliza el trmino clase para hacer referencia a las implantaciones de los
tipos de objetos. Se construyen clases a partir de otras clases, las cuales a su vez se integran
mediante clases. As, como los bienes manufacturados se fabrican a partir de una serie de
materiales de partes y subpartes ya existentes, tambin el software se crea mediante una
serie de materiales de clases ya existentes y probadas.
HERENCIA: El concepto de herencia se refiere a la comparicin de atributos y
operaciones basadas en una relacin jerrquica entre varias clases. Una clase pude
definirse de forma general y luego redefinirse en sucesivas subclases. Cada clase hereda
11

todas las propiedades de sus superclases y aade sus propiedades particulares. La herencia
es el medio por el cual los objetos de una clase pueden acceder a variables y funciones
miembro contenidas en una clase previamente definida, sin tener que volver a realizar esas
definiciones.
HERENCIA SIMPLE: La herencia simple es aquella en la que una clase puede
heredar la estructura de datos y operaciones de una superclase. Es una relacin entre clases
en la que una clase comparte la estructura y/o el comportamiento definido en una.
HERENCIA MLTIPLE: La herencia mltiple se da cuando una clase puede
heredar la estructura de datos y operaciones de ms de una superclase. Es la relacin entre
clases en la que una clase comparte la estructura dems de una clase base. La herencia
mltiple presenta una gran dificultad y es el hecho que puede heredar dos operaciones con
el mismo nombre. Esto hace que las colisiones pueden introducir ambigedad en el
comportamiento de la subclase que hereda en forma mltiple.
MENSAJE: Para que el objeto haga algo enviamos, una solicitud. Esta ha ce que se
produzca una operacin. La operacin ejecuta el mtodo apropiado y, de, manera opcional,
produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del
objeto, el nombre de una operacin, a veces, un grupo de parmetros. Un mensaje es una
solicitud para que se lleve a cabo la operacin indicada y se produzca el resultado. En pocas
palabras los mensajes son solicitudes, que invocan operaciones especficas, con uno o ms
objetos como parmetros. La respuesta a estas rdenes ser la informacin requerida,
siempre que el objeto considere que quien enva el mensaje esta autorizado para obtenerla
MTODO: El mtodo es la especificacin de un proceso de una operacin, es un
proceso disciplinado para generar un conjunto de modelo que describen varios aspectos de
un sistema de software en desarrollo, utilizando alguna notacin bien definida. Los mtodos
especifican la forma en que se controlan los datos de un objeto. Los mtodos en un tipo de
objeto solo hacen referencia a las estructuras de datos de ese tipo de objeto. No deben tener
acceso directo a las estructuras de datos de otros de objeto. Para utilizar la estructura de
datos de otro objeto, debe enviar un mensaje a este. El tipo de objeto empaca junto los tipos
de datos y los mtodos.
IDENTIDAD: La identidad es aquella propiedad de un objeto que los distingue de
todos los dems objetos. La identidad nica (pero no necesariamente el nombre) de cada
objeto se preserva durante el tiempo de vida del mismo, incluso cuando su estado cambia.
La identidad es la naturaleza de un objeto que lo distingue de todos los dems.
REUTILIZACIN: Es volver a generar una clase, teniendo en cuenta que puede ser
til para varios sistemas, sin tener que volver a generarlos, ahorrando con esto tiempo para
programacin, etc. Las clases estn definidas para que se reutilicen en muchos sistemas.
Para que esta sea efectiva, las clases se deben construir a partir de un modo que puedan ser
adaptables y reutilizables indefinidamente. Un objetivo de las tcnicas orientadas a objetos
es lograr la reutilizacin masiva al construir un software. Los sistemas suelen ser
construidos a travs de objetos ya existentes, que se lleva a un alto grado de reutilizacin,
esto conlleva a un ahorro de dinero, un menor tiempo de desarrollo y una mayor
12

confiabilidad de sistemas. Por lo tanto si ya es puesto a prueba una clase en un sistema,

tendr la garanta y la confiabilidad que podr volver a ser reutilizada.
ABSTRACCIN: Una abstraccin denota las caractersticas esenciales de un objeto
que lo distinguen de todos los dems tipos de objetos, y proporciona as fronteras
conceptuales definidas con nitidez, desde la perspectiva del observador. Todo objeto es
nico. Sin embrago, la abstraccin elimina algunas distinciones para que podamos ver los
aspectos comunes entre los objetos. La abstraccin es una de las vas fundamentales por la
que los humanos podamos combatir la complejidad. Una abstraccin se centra en la visin
externa de un objeto, y por lo tanto, sirve para separar el comportamiento esencial de un
objeto de su implantacin.
Sin la abstraccin solo sabramos que cada objeto es diferente de los dems, con ella
se omiten de manera selectiva varias caractersticas distintivas de uno o ms objetos, lo que
permite concentrarnos en las caractersticas que comparten. Para hacerlo ms entendible,
diremos que la abstraccin es el acto o resultado de eliminar diferencias entre los objetos,
de modo que podamos ver los aspectos ms comunes.
ENCAPSULAIN: El encapsulamiento es el proceso de compartimentar los
elementos de una abstraccin que constituyen su estructura y su compartimiento. Sirve para
separar el interfaz contractual de una abstraccin y su implantacin. Como hemos visto,
cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos
relacionados entre s, como si estuvieran encerrados conjuntamente en una cpsula. Esta
propiedad se denomina encapsulamiento y es una de las caractersticas fundamentales en la
programacin orientada a objetos, y la podemos definir como el proceso de almacenar en
un mismo compartimiento los elementos de una abstraccin que constituyen su estructura y
su comportamiento; sirve para separar la interfaz contractual de una abstraccin y su
implantacin. El hecho de cada objeto sea una cpsula facilita enormemente que un objeto
determinado pueda ser transportado a otro punto de la organizacin, o incluso a otra
organizacin totalmente diferente que precise de el. Si el objeto ha sido bien construido, sus
mtodos seguirn funcionando en el nuevo entorno sin problemas. Esta cualidad hace que
la programacin orientada a objetos sea muy apta para la reutilizacin de programas.
El encapsulamiento es importante porque separa el comportamiento del objeto de su
implantacin. Esto permite la modificacin de la implantacin del objeto sin que se tengan
que modificar las aplicaciones que lo utilizan.
MODULARIDAD: La modularidad es la propiedad que posee un sistema que ha
sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados. Para esto
se debe hacer lo posible por construir mdulos cohesivos (agrupando abstracciones que
guarden cierta relacin lgica) y dbilmente acoplados (minimizando las dependencias
entre mdulos). Segn Liskov, un especialista en la materia, la modularizacin consiste en
dividir un programa en mdulos que pueden compilarse separadamente, pero que tiene
conexiones con otros mdulos. As los principios de abstraccin, encapsulamiento y
modularidad son sinrgicos. Si bien es cierto la abstraccin es algo bueno, pero excepto en
las aplicaciones ms triviales, puede haber muchas ms abstracciones diferentes de las que
se pueden comprender simultneamente. El encapsulamiento ayuda a manejar esta
13

complejidad ocultando la visin interna de las abstracciones. La modularidad tambin

ayuda, ofreciendo una va para agrupar abstracciones relacionadas lgicamente. Esto sigue
sin ser suficiente, frecuentemente un conjunto de abstracciones forma una jerarqua, y la
identificacin de esas jerarquas en el diseo simplifica en gran medida la comprensin del
problema.
JERARQUA: La jerarqua es una clasificacin u ordenacin de abstracciones. Las
dos jerarquas ms importantes en un sistema complejo son su estructura de clases y su
estructura de objetos, jerarqua de clase y jerarqua de partes correspondientemente. La
herencia es el ejemplo mas claro de una jerarqua de clases, esta define una relacin entre
clases, en la que una clase comparte la estructura de comportamiento definida en una o ms
clases (herencia simple o herencia mltiple, respectivamente).
Los sistemas jerrquicos estn compuestos usualmente de solo unas pocas clases
diferentes de subsistemas en varias combinaciones y disposiciones.
CONCURRENCIA: La concurrencia es la propiedad que distingue a un objeto
activo de uno que no esta activo. Para cierto tipo de problemas, un sistema automatizado
puede tener que manejar muchos eventos diferentes simultneamente, en otro problema
pueden implicar tantos clculos que excedan la capacidad de cualquier procesador
individual. En ambos casos es natural considerar el uso de un conjunto distribuido de
computadores para la implantacin que se persigue o utilizar procesadores capaces de
realizar multitareas, a travs de un hilo de control, mediante la cual se producen acciones
dinmicas independientes dentro del sistema. La concurrencia permite a diferentes objetos
actuar al mismo tiempo

14

Captulo 2

Sistema Manejador de Bases de Datos ORACLE

El servidor de Oracle es un sistema manejador de bases de datos relacional que

ofrece una integracin aproximada al manejo de informacin. Un servidor Oracle consiste
de una base de datos Oracle y un servidor de instancias Oracle.

2.1 Arquitectura
Para entender la arquitectura de oracle es necesario entender y considerar dos
conceptos: Bases de Datos e Instancias.

2.1.1 Bases de Datos

Oracle tiene la habilidad de almacenar y acceder informacin de una manera
coherente con un modelo definido y conocido como el modelo relacional. Por ello, oralce
es refererido como un sistema manejador de base de datos relacional (RDBMS, siglas en
ingls Relational DataBase Management System). Cuando hablamos de una base de
datos no slo nos estamos refiriendo a los datos fsicos, sino tambin a la combinacin de
objetos fsicos, de memoria y de proceso [LoK02].
La informacin en una base de datos es almacenada en tablas. Las tablas
relacionales se definen por sus columnas y se les asigna un nombre. Los datos se almacenan
como filas en la tabla. Las tablas pueden relacionarse entre s y la base de datos puede
utilizarse para hacer que se apliquen esas relaciones.
Adems de almacenar datos en formato relacional , oracle (a partir de la versin 8)
soporta estructuras orientadas a objetos, como tipos de datos abstractos y mtodos. Los
objetos pueden relacionar a otros objetos, y contener otros objetos. De cualquier estructura
utilizada, ya sea relacional u orientada a objetos, oracle almacena la informacin en
archivos. Internamente, existen estructuras de bases de datos que se encargan de la
correspondencia lgica entre la informacin y los archivos, alojando diferentes tipos de
datos para ser almacenados separadamente. Estas divisiones lgicas son llamadas Espacios
de Tablas (en ingls llamadas: Tablespaces).

2.1.2 Espacios de tablas

Un espacio de tabla es una divisin lgica de una base de datos. Cada base de datos
tiene por lo menos un espacio de tabla (llamado espacio de tabla SYSTEM). Se pueden
utilizar otros espacios de tablas para agrupar a los usuarios o aplicaciones con el fin de
facilitar el mantenimiento y mejorar el rendimiento. Ejemplos de estos tipos de espacios
tabla seran USERS, de propsito general y UNDO para segmentos para deshacer
cambios (que ser descrito ms adelante). Un espacio de tabla puede pertenecer nicamente
a una base de datos[LoK02].
15

2.1.3 Archivos de datos

Cada espacio de tablas esta constituido por uno o mas archivos, llamados archivos
de datos, que se almacenan en disco. Un archivo de datos puede pertenecer a uno y
nicamente a un espacio de tabla. El tamao de los archivos de datos se puede modificar
despus de su creacin. Crear un nuevo espacio de tabla conlleva a crear un nuevo archivo
de datos. Una vez que el archivo de datos ha sido agregado a un espacio de tablas, dicho
archivo no puede eliminarse del espacio de tablas, ni puede ser asociado con algn otro
espacio de tablas [LoK02].
Si se almacenan objetos de bases de datos en mltiples espacios de tablas, entonces
se deben separar fsicamente colocando sus respectivos archivos de datos en discos
distintos. Esta separacin de datos es una herramienta importante en la planeacin y
optimizacin de la forma en que la base de datos maneja las solicitudes de entrada / salida
que recibe. La relacione entre bases de datos, espacios de tabla y archivos de datos se
muestran en la sig. Figura 2.1:

Tablespaces

SISTEMA
Espacio de tablas

Segundo
Espacio de tablas

Tercer
Espacio de tablas

Archivos de
Datos
Figura 2.1

Relaciones sobre bases de datos, tablespaces y archivos de datos

2.1.4 Otros archivos

Los archivos de datos de la base de datos, proporcionan el almacenamiento fsico de
los datos de la base de datos. Por tanto, son estructuras tanto internas, por estar ligadas
directamente a los espacios de tablas, como externas, por tratarse de archivos fsicos.
Los siguientes tipos de archivos, aunque estn relacionados con la base de datos,
estn separados de los archivos de datos. Entre estos archivos se incluyen los siguientes:
Los registros de reconstruccin.
Los archivos de control.
Los archivos de traza y el registro de alertas.

Los registros de reconstruccin

Oracle conserva registros de todas las transacciones realizadas en la base de datos.
Estas transacciones se registran en archivos denominados archivos de registro de
reconstruccin en lnea. Estos archivos de registro de reconstruccin se utilizan para
16

recuperar las transacciones de la base de datos en el orden adecuado, en caso de que se

produzca un fallo en la base de datos. La informacin del registro de reconstruccin se
almacena de forma independiente de los archivos de datos de la base de datos.
Los archivos de registro de reconstruccin tambin permiten que Oracle coordine la
forma en que se escriben los datos en el disco. Cuando se produce una transaccin en la
base de datos, sta se introduce en los buffers del registro de reconstruccin, mientras
que los bloques de datos afectados por la transaccin no se escriben de manera
inmediata en el disco.
Todas las bases de datos Oracle tienen tres o ms archivos de registro de reconstruccin en lnea. Oracle escribe en ellos de manera cclica: despus de llenar el primer
archivo de registro, escribe en el segundo, hasta llenarlo. Cuando se han llenado todos
los archivos de registro de reconstruccin en lnea, vuelve al primero y empieza a
sobrescribir su contenido con nuevos datos de transacciones. Si la base de datos se est
ejecutando en modo ARCHIVELOG, har una copia de los archivos de registro de
reconstruccin en lnea antes de sobrescribirlos. Estos archivos de registros de
reconstruccin salvaguardados pueden utilizarse para devolver a cualquier parte de la
base de datos al estado en que se encontrara en un determinado momento
La base de datos puede duplicar en espejo los archivos de registro de reconstruccin. Esta operacin permite al DBA duplicar los archivos de registro de reconstruccin
sin depender del sistema operativo o de la funcionalidad que ofrezca el hardware del
entorno de funcionamiento [LoK02].
Archivos de Control
La arquitectura fsica global de una base de datos se mantiene por medio de sus
archivos de control, en los que se registra la informacin de control referente a todos los
archivos de la base de datos. Se utilizan para conservar la coherencia interna y guiar las
operaciones de recuperacin.
Como los archivos de control son fundamentales para la base de datos, se almacenan varias copias en lnea. Estos archivos suelen almacenarse en discos separados,
con el fin de minimizar el dao potencial derivado de posibles fallos de los discos. La
base de datos crear y mantendr los archivos de control que se hubieran especificado
en el momento de la creacin de la base de datos.
Los nombres de los archivos de control de la base de datos se especifican a travs
del parmetro de inicializacin CONTROL_FILES. Si se tiene que aadir un nuevo
archivo de control a la base de datos, se puede cerrar la instancia, copiar uno de los
archivos de control existentes en una nueva ubicacin, aadir la nueva ubicacin a la
configuracin del parmetro CONTROL_FILES y reiniciar la instancia.
Los archivos de traza y el registro de alertas
Todos los procesos asociados a una instancia que se ejecutan en segundo plano
tienen a su vez un archivo de traza asociado. El archivo de traza contiene informacin
relativa a los sucesos significativos con los que se encuentran dichos procesos. Adems
17

de estos archivos, Oracle conserva un archivo llamado registro de alertas. Este registro
almacena los comandos y los resultados de los comandos correspondientes a los
sucesos ms importantes que ocurren en la vida de la base de datos. Por ejemplo, la
creacin de espacios de tablas, el paso de un registro de reconstruccin a otro, las operaciones de recuperacin y los inicios de la base de datos se graban en el registro de
alertas. El registro de alertas es una fuente de informacin fundamental para la gestin
cotidiana de una base de datos. Los archivos de traza son muy tiles para tratar de descubrir la causa de un fallo importante [LoK02].
Las entradas de este registro de alertas informan sobre cualquier problema que haya
surgido durante las operaciones de la base de datos, como, por ejemplo, cualquier error
interno de tipo ORA-0600 que se haya producido. Con el fin de que el registro de
alertas resulte ms fcil de usar.

2.1.5 Instancias
Para acceder a la informacin a la base de datos, oracle utiliza un conjunto de
procesos en segundo plano que son compartidos por todos los usuarios. Adems, existen
estructuras de memoria (Conocidas por todos como SGA) que son utilizadas para
almacenar las ltimas consultas hechas a la base de datos. Las secciones ms grandes de la
SGA (System Global Area o rea global del sistema), la cach de buffers de bloques de
datos, el rea compartida SQL, el rea de bloques de gran tamao y el rea Java,
constituyen generalmente ms del 95 por 100 de la memoria asignada a la SGA. Estas reas
de memoria ayudan a mejorar el rendimiento de la base de datos, ya que reducen la
cantidad de operaciones de entrada /salida sobre los archivos de datos.
Una instancia de base de datos (conocida tambin como servidor) es un conjunto de
estructuras de memoria y procesos en segundo plano que acceden a un conjunto de archivos
de bases de datos. Es posible que mltiples instancias accedan a una nica base de datos
(sta es la opcin conocida como Real Application Cluster). La relacin entre instancias y
bases de datos se muestran en la figura 2.2 [LoK02].
Los parmetros que determinan el tamao y composicin de una instancia son
almacenados en un archivo llamado init.ora o, bien, residen dentro de la base de datos,
en un archivo de parmetros de servidor, conocido como SPFILE, el cual est almacenado
en spfile.ora.. Este archivo es ledo durante el inicio de la instancia y puede ser
modificado por el DBA (Administrador de Bases de Datos, DataBase Administrator).
Cualquier modificacin hecha a este archivo no tendr efecto hasta que el siguiente inicio
de la instancia. El nombre de un archivo de inicializacin de una instancia usualmente
incluye el nombre de la instancia; si la instancia es llamada ORCL, entonces el archivo
init.ora usualmente ser llamado initorcl. Oracle crea cada vez ms y ms parmetros
dentro de la base de datos que se pueden ajustar dinmicamente. Los cambios de los
parmetros pueden continuar en efecto despus de las operaciones sucesivas de apagado e
inicio, independientemente del contenido del archivo de parmetros de inicializacin. En
Oracle9i, el DBA puede utilizar SPFILE, en lugar del archivo init.ora e introducir
cambios, temporales o definitivos, en los parmetros de inicializacin [LoK02].

18

Ins t an cia
SGA

User
process

Shared pool
Library
Cache

Server
process

Data Dictionary
Cache

Database
Buffer Cache

Redo Log
Buffer

Java Pool

Large Pool

PGA
PMON

Trace
Files

SMON

Datafiles

DBWR

LGWR

Control
Files

CKPT

Redo Log
Files

Otros

Parameter
File

Base de Datos
Figura 2.2

Instancias y bases de datos en Oracle

2.2 Caractersticas Administrativas de Oracle

2.2.1 Instalacin [PeC03]
Oracle cuenta con una gama de productos entre ellos diferentes versiones de Bases
de Datos como: Enterprise, Estndar, Estndar Edicin uno y versiones Personal
Edicin Enterprise: Ofrece escalabilidad y confiabilidad tanto en configuraciones de
cluster como en las de sistema nico. Proporciona caractersticas ms extensas para
entornos de procesamiento de transacciones en lnea (OLTP) y business intelligence a un
precio ms accesible.
Edicin Estndar: Es una alternativa de bajo costo para la mediana y pequea
empresa o aplicaciones departamentales que necesitan de las utilidades de Oracle pero no
requieren las opciones high end de la versin Enterprise
Edicin Personal: Una versin de Bases de Datos Oracle con caractersticas
completas que cumple las necesidades de individuos que requieren de compatibilidad con
toda la familia de bases de datos Oracle
Para este sistema que se desarrollar se ocupar la versin Personal de Oracle ya
que se cumple con los requerimientos a apropiados, en adelante se hablar de los detalles de
la instalacin de la Base de Datos:
19

La instalacin fue echa sobre el sistema operativo XP utilizando la base de datos

Oracle 9i que consta de 3 CDs de instalacin, cuando es insertado el primer CD se ejecuta
el asistente de instalacin Oracle Universal Installer que permite instalar y configurar la
base de datos, inicialmente se obtiene la pgina de bienvenida de este asistente, como lo
muestra la imagen 2.3.

Imagen 2.3

Ventana de inicio del asistente de instalacin

Una vez iniciado el asistente de instalacin, se procede a desinstalar alguna base de

datos de Oracle de versin anterior si es que existe, de lo contrario se prosigue con la
instalacin, para desinstalar una versin anterior de base de datos Oracle hay que oprimir el
botn desinstalar productos o tambin utilizar este botn en caso de modificar puntos en
una instalacin de esta versin hecha previamente como lo muestra la imagen 2.4.
Despus de este paso se configura el lugar donde sern almacenados fsicamente la
base de datos en el disco duro tomando en cuenta tambin el directorio de donde se estn
tomando los archivos de instalacin. Para el destino de los archivos se da un nombre de la
variable de entorno ORACLE_HOME y su directorio raz.
El paso siguiente consiste en seleccionar uno de tres posibles productos que son :

20

Base de datos Oracle 9i, que instala una base de datos inicial opcional ya
preconfigurada, las herramientas de gestin, servicios de red, utilidades y
software bsico de cliente para un servidor de base de datos Oracle.
Administrador e integrador Oracle 9i, que instala el servidor de
administracin, las herramientas de administracin, el directorio de Internet de
Oracle, el servidor de integracin Oracle, servicios de red, utilidades y
software bsico del cliente.
Cliente Oracle 9i, instala las herramientas de administracin Enterprise, los
servicios de red, utilidades, herramientas de desarrollo, los precompiladotes y
el software bsico del cliente

Para el desarrollo del sistema de facturacin se requiere de la primera opcin

como lo muestra la imagen 2.5.

Imagen 2.4

Configuracin para desinstalar productos

En el siguiente paso se selecciona el tipo de instalacin que se pueden elegir las

siguientes opciones:
Enterprse Edition, que proporciona gestin de datos para aplicaciones de
nivel superior como, por ejemplo, entornos de procesamiento de transacciones
en lnea (OLTP) de alto volumen, almacenes de datos de numerosas consultas
y aplicaciones de Internet exigentes. Ofrece herramientas y funcionalidad para
satisfacer las necesidades de disponibilidad y escalabilidad de aplicaciones
crticas.
Edicin Estndar, destinada para aplicaciones de grupo de trabajo o a nivel de
departamento. Incluye un juego integrado de herramientas de gestin,
distribucin completa, replicacin y funciones Web para crear aplicaciones
crticas.
Personal Edition, que instala el mismo software que el tipo Enterprise Edition,
pero que soporta slo un usuario, siendo compatible con Enterprise Edition y
Standard Edition. Este tipo de instalacin es el nico de Oracle 9i soportado
por Windows 98.
Personalizada, que permite instalar de forma selectiva componentes de los
tipos de instalacin anteriores. Tenga en cuenta que algunos componentes
adicionales slo estn disponibles para la instalacin personalizada.

21

Imagen 2.5

Productos disponibles

Despus de haber seleccionado la opcin Enterprise, se procede a seleccionar el tipo

de configuracin de Base de Datos, ya sea de uso general que instala una base de datos
configurada previamente para uso general, de procesamiento de transacciones que instala
una base de datos configurada previamente optimizada para los almacenes de datos, de
almacenes de datos, personalizada o slo software. En este caso se utiliz la primera
opcin que fue de uso general.
En seguida se configura la identificacin de la base de datos que se crear de
manera simplificada, dando como datos: el nombre de la base de datos global y el SID
identificador del sistema de Oracle, se recomienda que el nombre en ambas partes sea corto
y el mismo como lo muestra la imagen 2.6; Para despus configurar la ubicacin de
archivos de las Bases de Datos ya sea escribiendo la ruta directamente o seleccionndola a
travs del botn Examinar del cuadro de dilogo del asistente de instalacin.
Por ltimo se muestra el resumen que muestra todos los componentes que fueron
indicados y sern instalados, en este punto se puede retroceder en alguna fase de instalacin
para su modificacin; En caso contrario se oprime el botn instalar, cambiar de ventana
el asistente mostrando una barra de progreso indicando el porcentaje de estado de la
instalacin.

22

Imagen 2.6

Identificacin de Bases de Datos

Al finalizar la instalacin el asistente nos mostrar un mensaje de Fin de la

instalacin como lo muestra la imagen 2.7, si se desean instalar algunos otros componentes
se oprime el botn Siguiente instalacin, de lo contrario oprimir el botn Salir.

Imagen 2.7

Fin de la instalacin

23

2.2.2 Gestin del proceso de desarrollo

Gestionar el desarrollo de aplicaciones puede ser una tarea complicada. Desde la
perspectiva de un administrador de bases de datos (DBA), la mejor forma de llevar a cabo
este proceso es convertirse en parte integrante de los equipos participantes en l [LoK02].
La implementacin de una aplicacin en una base de datos mediante la simple
ejecucin de una serie de comandos crear tabla (create table en el lenguaje SQL) no
asegura la integracin del proceso de creacin con las otras reas principales (planificacin,
control y ajuste). El administrador de bases de datos debe participar en los procesos de
desarrollo de la aplicacin para disear correctamente la base de datos que dar soporte al
producto final.
El ciclo de vida de una base de datos se define por las cuatro acciones:
planificacin, creacin, control y ajuste. Los elementos de la implementacin adecuada de
este ciclo pueden identificarse como pertenecientes a tres categoras principales: procesos
culturales, procesos de gestin y tecnologa. Gestionar los esfuerzos de implementacin
por parte de los desarrolladores de la base de datos requiere llevar a cabo acciones en las
tres categoras:
Cultural: La cultura corporativa y el equipo de desarrollo deben dar soporte
a la participacin del administrador de la base de datos en el proceso de
desarrollo.
Gestin: Se debe exigir a los desarrolladores que sigan lo ms estrictamente
posible una metodologa de ciclo de vida
Tecnologa: Los desarrolladores y administradores de bases de datos deben
definir una serie de mecanismos que aseguren que existe el nivel adecuado
de participacin y atencin a los detalles.

2.2.2.1

Procesos culturales

Los administradores de bases de datos y los desarrolladores que trabajen

formando parte del mismo equipo pueden mejorar considerablemente el proceso de
desarrollo. Un equipo conjunto de administradores y desarrolladores proporcionan
valor aadido creando aplicaciones de mantenimiento ms sencillo, creando
aplicaciones con un tamao y una configuracin adecuados, lo que requiere por
tanto menos tiempo de mantenimiento, creando ndices adecuados para maximizar
el rendimiento de las consultas, Identificando las tablas y los ndices que utilizar la
aplicacin con ms frecuencia, entre otros ms[LoK02].
El valor que el administrador de la base de datos aade a estos esfuerzos
adquiere an mayor alcance cuando el DBA entiende completamente la aplicacin y
las necesidades comerciales que satisface. Si comprende las necesidades
comerciales, podr entender mejor los objetivos que persiguen los desarrolladores
en su proceso de desarrollo de aplicaciones.

24

2.2.2.2

Procesos de gestin

Para gestionar adecuadamente los esfuerzos de desarrollo, la metodologa de

be definir las relaciones entre las distintas reas funcionales y los documentos
entregables necesarios en cada fase de desarrollo de la aplicacin. Si los
documentos entregables de la seccin de desarrollo estn terminados, revisados y
aprobados, entonces la aplicacin puede pasar al entorno de prueba, bajo cuyas
restricciones debern entonces trabajar los desarrolladores [LoK02].
Para saber si se est siguiendo una metodologa es necesario el
establecimiento de una lista de elementos llamados documentos entregables que
deben cumplimentarse durante el desarrollo de la aplicacin. La metodologa debe
definir claramente, tanto en formato como en nivel detalle, los documentos
entregables necesarios para cada etapa del ciclo de vida que, adems, deben incluir
especificaciones para cada uno de los siguientes elementos:
Diagrama de relaciones entre entidades
Modelo fsico de la base de datos
Requisitos de espacio
Objetivos de optimizacin para consultas y el proceso de
transacciones
Requisitos de seguridad
Requisitos de los datos
Planes de ejecucin de consultas
Procedimientos de las pruebas de aceptacin

2.2.2.3

Tecnologa

Los documentos entregables internos al proceso deben estar disponibles

mientras el desarrollo est teniendo lugar. Como la mayora de los equipos de
desarrollo incluyen varios desarrolladores (a al menos un DBA), se debe establecer
un medio de comunicacin. Los canales de comunicacin permitirn mantener la
coherencia en la planificacin y la ejecucin. Se necesitan cuatro soluciones
tecnolgicas para la metodologa funcione: herramientas CASE, directorios
compartidos, bases de datos de administracin del proyecto y bases de datos de
discusin.
Herramientas CASE
Se puede utilizar una herramienta CASE para generar el diagrama de
relaciones entre entidades y el modelo fsico de la base de datos. Las herramientas
CASE pueden crear el diagrama de relaciones entre entidades y suelen tener un
diccionario de datos integrado. Las herramientas CASE pueden permitir la
comparticin de entidades entre varias aplicaciones y pueden almacenar
informacin sobre volmenes de tablas y tamaos de fila. Las herramientas CASE
permiten mantener o congelar distintas versiones de un modelo de datos, dando
soporte a la gestin de versiones y a la creacin de prototipos.

25

Los comandos SQL que crean los objetos de base de datos para la aplicacin
deben generarse directamente desde la herramienta CASE. Se puede tambin
utilizar la herramienta CASE para crear versiones genricas de aplicaciones
basndose en los objetos de base de datos definidos.
Directorios compartidos
Varios de los documentos entregables, como los requisitos de copia de
seguridad, no tienen una herramienta especfica con la que deban ser creados. Estos
documentos deben crearse con cualquier herramienta que sea adecuada y que est
disponible en dicha organizacin. Los archivos resultantes deberan almacenarse en
directorios de proyecto compartidos de forma que todos los miembros del equipo
implicados puedan acceder a ellos. Los formatos y los convenios de nomenclatura
para estos archivos deben especificarse en las primeras etapas de proceso de
desarrollo.
Bases de datos de administracin del proyecto
Para comunicar el estado de la aplicacin y sus documentos entregables a las
personas que no formen parte del equipo de desarrollo, debe mantenerse una base de
datos de administracin de proyecto. Esta base de datos debe ofrecer a estas
personas una perspectiva del proyecto y de su estado. Esta informacin permitir a
las personas que no estn implicadas directamente en el proyecto (como el personal
de administracin de sistemas) anticiparse a los futuros requisitos. La base de datos
de administracin del proyecto permite adems realizar el anlisis del impacto que
pueden tener cambios o retrasos producidos en la programacin, lo que dara lugar
posiblemente a modificaciones en los niveles de recursos asignados a las tareas del
proyecto [LoK02].

2.3 Herramientas de desarrollo Oracle

Oracle ofrece herramientas para desarrollar aplicaciones de procesamiento de
transacciones como las herramientas Oracle Business Intelliegence que incluyen: Oracle
Discover, para anlisis y consultas ad hoc; Oracle Reports, para la publicacin de bases de
datos de alta fidelidad; y las herramientas Express, para el desarrollo de aplicaciones
analticas. Entre las herramientas de desarrollo de Oracle se incluyen Designer y Developer,
productivas herramientas de desarrollo basado en modelos, y JDeveloper, herramienta de
desarrollo de Java basada en componentes. Las herramientas de Oracle automatizan el
desarrollo de aplicaciones y reducen el trabajo y el tiempo necesarios para completar
aplicaciones de bases de datos, y reduciendo el proceso de codificacin manual, que resulta
propenso a errores [PKo+00].
Oracle Developer es una herramienta de desarrollo lder en el mercado para la
creacin de aplicaciones de base de datos. Proporciona las utilidades y herramientas de
productividad para crear aplicaciones de base de datos de primera que automaticen
funciones y procesos de negocio, dentro y fuera de la empresa. En la actualidad, Oracle
Developer es la herramienta que eligen muchas empresas de todo el mundo para desarrollar
aplicaciones personalizadas de carcter empresarial.
26

Los autores Meter y Paul muestran en su libro varios recursos para el desarrollo en
Oracle Developer como: una referencia de prctias recomendadas usando las caractersticas
orientadas a objetos de Oracle Developer, un anlisis de los estndares para Oracle
Developer que ayuden a garantizar el xito de los proyectos que se presenten.
Forms es el componente principal de Developer 6i. Forms permite desarrollar
aplicaciones para presentar y manipular datos de muchas maneras. Las aplicaciones de
Forms le permiten a los usuarios:
Insertar, actualizar, borrar y consultar datos utilizando una variedad de items de
interfaz.
Presentar los datos utilizando controles de texto, imgenes y VBX.
Control de formas a travs de varias ventanas.
Acceso de fcil comprensin, utilizando mens integrados.
Mdulos en Forms
En Forms se tienen tres tipos de mdulos (archivos):
Forma. Una forma presenta los objetos y datos con los que el usuario puede
interactuar. Los elementos de datos en una forma son agrupados en registros.
Men. Un mdulo men puede comprimir una jerarqua de mens. Usualmente los
mdulos mens son ligados a mdulos forma.
Librera. Es una coleccin de unidades de programa en PL/SQL. Estas unidades de
programa pueden ser utilizadas en formas y mens.
La imagen 2.8 muestra la estructura de forms y su interaccin con la base de datos Oracle,
otros productos de Developer y otros objetos.

Forms

PL/
PL/ SQL
SQL
Mens

Formas

Libreras
Transacciones
VBX
VBX
OLE2
OLE2
DDE
DDE

Otros
Otros
Productos
Productos de
de
Developer
Developer 6i
6i
Fuentes de Datos
Imagen 2.8

Base de Datos

Estructura de Forms

27

2.3.1 Arquitectura de datos de Developer Forms y Developer Reports

Una pantalla Form es un mdulo de Form Builder que almacena un conjunto de
objetos en un solo archivo. La pantalla acta como una especie de interfaz de usuario que
permite al usuario visualizar o manipular la informacin de la base de datos. La ventaja de
Oracle Developer Forms radica en su estrecha relacin con la base de datos Oracle. El
principal vnculo que lo une a dicha base de datos es un bloque, que est asociado con un
objeto de la base de datos, como puede ser una tabla o un procedimiento.
Cada pantalla contiene uno o ms bloques. Los datos se pueden consultar, insertar,
actualizar y borrar mediante elementos que se corresponden en las columnas de una tabla o
con los elementos de un registro en una variable de cursor o tabla PL/SQL. Generalmente,
los elementos aparecen en una pantalla para que el usuario pueda interactuar con ellos.
Cada bloque puede contener uno o ms elementos. Se utilizan controles de interfaz grfica
de usuario estndar, como elementos de texto, elementos de visualizacin, casillas de
verificacin y grupos de botones e opcin para representar en la interfaz los elementos de
datos. En la imagen 2.9 se muestra los objetos de pantalla ms importantes, los vnculos
con una tabla y cmo los objetos se relacionan entre s con un nivel obligatorio de tipo uno
a muchos [PKo+00].
Tabla

Pantalla de
Forms
Imagen 2.9 Principales relaciones de los objetos de una pantalla

28

Forms
Forma

Men

Forma

Procedimiento
Procedimiento
Funcin
Funcin
Paquete
Paquete
Imagen 2.10 Manejo de la herramienta Forms de Oracle

Mediante Forms se pueden crear diferentes tipos de mdulos: Forma, Men y

Librera. Forms permite relacionar los tres tipos de mdulos.
Se puede atar un mdulo Men a un Mdulo Forma, haciendo las opciones del
men disponibles desde la forma en tiempo de ejecucin.
Se puede atar uno o ms mdulos Librera a un mdulo Forma o a un mdulo
Men, para hacer disponibles las unidades de programa de la librera dentro de
cada mdulo.
Un mdulo Forma puede invocar a otro mdulo Forma
Lo anterior puede ser mostrado en la imagen 2.10.
Una forma puede tener muchos tipos de objetos; no todos son visibles al usuario en
tiempo de ejecucin. Los tres objetos principales en una forma son:
Items. Son objetos que presentan valores al usuario y le permiten interactuar con la
forma, dependiendo del tipo de item. Los items son agrupados lgicamente en
bloques y distribuidos fsicamente sobre canvas.
Canvas. Un canvas es una superficie donde se colocan objetos visuales. Una forma
puede tener varios canvas (como las pginas de un libro). Por default, todos los
canvas en una forma aparecen en la misma ventana, pero se pueden asignar
ventanas separadas para cada canvas.
Bloques. Un bloque es una agrupacin lgica de items. Los items en un bloque
deben estar relacionados lgicamente; por ejemplo, pueden corresponder a
columnas de una tabla en la base de datos.
No es necesario que los items de un bloque estn fsicamente agrupados, ya que
pueden estar distribuidos en varios canvas.
29

Un bloque con tabla base, es un bloque que est asociado con una tabla o vista de la
base de datos. Muchos de los bloques en una forma, son con tabla base. Un bloque slo
puede tener una tabla base. Para un bloque con tabla base, Forms automticamente:
Crea items que correspondan a columnas de la tabla.
Produce cdigo en la forma para emplear las reglas de los constraints de la tabla.
Genera en tiempo de ejecucin sentencias SQL para insertar, actualizar, borrar y
consultar renglones en la tabla base, dependiendo de las acciones del usuario.
Se pueden crear bloques con una relacin maestro-detalle para permitir que valores
de llave primaria y llave fornea sean ligados a travs de bloques y sincronizar los datos
que sern desplegados. Forms automticamente genera los objetos y el cdigo necesario
para soportar la relacin maestro-detalle. Se pueden crear bloques que slo muestren un
registro o que muestren varios registros a la vez (bloque multi-registro).
Los componentes Forms y Reports de Oracle Developer poseen arquitecturas de
datos diferentes. En Reports hay un objeto, que se denomina columna, que representa un
elemento de datos (normalmente, un valor de columna de una fila de una tabla) en una
consulta del modelo de datos. Reports emplea un objeto independiente en el modelo de
diseo (Layaout Model), el campo, para mostrar los datos de la columna. Puede haber
columnas sin campos y puede haber columnas con ms de un campo. El modelo de datos y
el modelo de diseo contienen representaciones independientes. En el componente Forms
slo hay un objeto, el elemento que hace referencia al valor de la columna en la base de
datos y muestra los datos correspondientes. La Imagen 2.11 muestra un ejemplo de cmo es
el diseo final de un reporte el cual plasma en impresin o diferentes formatos de
documentos la salida de la informacin requerida, de la base de datos.

Figura 2.11 Ejemplo de diseo de un Reporte en Developer Reports

30

Forms crea automticamente instrucciones DML e instrucciones SQL de consulta

(INSERT, UPDATE, DELETE y SELECT), a partir del bloque y elementos contenidos
en la pantalla. Estas instrucciones SQL no necesitan ninguna codificacin, gracias a la
funcionalidad ya incluida en el bloque. Otra de las utilidades de Forms es la funcin de
consulta por ejemplo (QBE, Query By Example). El usuario puede poner la pantalla en
el modo Enter Query (Introducir Consola), introducir los valores de correspondencia en los
elementos del bloque y ejecutar la consulta. La pantalla crear una clusula WHERE que se
aadir a la instruccin SELECT generada para recuperar los datos. Otra de las funciones
de esta herramienta radica en su capacidad de gestionar automticamente el bloqueo de
filas y la concurrencia, sin necesidad de ninguna codificacin adicional [PKo+00].
Las definiciones de los mdulos de Forms se pueden almacenar en el sistema de
archivos o en la base de datos. Si se guarda un mdulo forma al sistema de archivos, se crea
un archivo Form Module Binary (.fmb). Este archivo no es ejecutable; se debe generar un
archivo .fmx para ejecutar la forma. Un archivo ejecutable de Developer, necesita una
herramienta del mismo Developer para ejecutarlo. Esto puede ser visto en la imagen 2.12

Fuentes y Ejecutables
Memoria
Memoria de
de
Forms
Forms
Builder
Builder
Definicin
Definicin
de
de la
la Forma
Forma

Preferencias

Archivos
Archivos oo

OPEN Base
Base de
de Datos?
Datos?
SAVE

COMPILE
Runtime
Runtime de
de
Forms
Forms

Tablas
Tablas

RUN

Base de Datos

.fmx

.fmb

Sistema de
Archivos

Figura 2.12 Funcionamiento de la herramienta Forms de Oracle

31

Archivos Binarios
Definicin Binaria Portable

Ejecutable NoNo-Portable

.fmb

Forma
Forma

.fmx

.mmb

Men
Men

.mmx

.pll

Librera
Librera

.plx

Figura 2.13 Tipos de archivos para mdulos en Forms de Oracle

Adems de los mdulos forma (.fmb) tambin se puede salvar los mdulos mens y
los mdulos librera al sistema de archivos. Arriba se ilustra en la figura 2.13, que extensin
tienen los archivos donde se guardan los mdulos forma, men y librera; tambin la
extensin de los archivos ejecutables.
Los archivos fuente tienen la caracterstica de que son portables a diferentes
plataformas, mientras que los archivos ejecutables no son portables

2.4 Ventajas
Oracle es el mayor proveedor de software de comercio electrnico del mundo. 65 de
las 100 mayores empresas, segn la clasificacin de la revista Fortune, usan Oracle para el
negocio electrnico. Esto se debe a que Oracle ofrece una completa plataforma de Internet,
incluyendo la base de datos 9i, servidores de aplicacin y herramientas.
Entre las herramientas de Oracle se incluye una serie integrada de herramientas para
labores de inteligencia empresarial Business Intelligence, para satisfacer fcilmente a
cualquier pregunta sobre negocios.
Si un equipo de desarrollo utiliza Oracle Developer Forms y Reports para crear una
aplicacin que acceda a una base de datos Oracle, pueden crear rpidamente un sistema
sofisticado y fcil de utilizar que pueda satisfacer incluso los requisitos ms complejos.
Developer posee la capacidad de satisfacer la mayora de los requisitos de interfaz de
usuario ms habituales. Adems, Developer ofrece la suficiente flexibilidad para ajustar las
aplicaciones con el fin de que proporcione el mximo rendimiento [PKo+00].

32

Captulo 3

Anlisis y diseo del sistema

Este captulo se enfatiza con los planteamientos, anlisis y estrategias de cmo se

pretende desarrollar el sistema, aqu se centran las bases de la aplicacin de la ingeniera de
software.

3.1 Planteamiento del problema

Una empresa ofrece servicios de seal a aparatos radio localizadores, como
cualquier empresa, requiere que sus servicios sean facturados para propsitos fiscales, al
inicio se contaban con pocos clientes y el manejo de dichas facturas se poda hacer de
manera manual y rpida. Pero a medida que la empresa crece el manejo de la informacin
se vuelve lento.

3.2 Anlisis del sistema

El sistema debe de analizarse a travs una estructura modular, la cual permita
identificar cada elemento, como los mdulos clientes, cobradores, facturacin, productos y
servicios y reportes.
Primero se debe de contar con un catlogo de Clientes, Productos y servicios,
cobradores. Hay que considerar que un cliente puede ser una empresa y usuario a la vez,
pero se puede dar el caso de que una empresa pueda tener varios usuarios. Los cobradores
pueden tener asignados varios clientes pero un cliente nicamente puede ser asignado a un
cobrador.
Cuando un cliente es dado de alta es necesario asignarle un servicio producto, as
como tambin una forma de pago ya sea a travs de un cobrador, cuenta bancaria o
directamente en la empresa. Una vez realizado lo anterior se prosigue a llevarle un
seguimiento mensual a cada cliente con respecto a sus pagos, para ello se genera la factura
a pagar de manera mensual que pasa a ser una cuenta por pagar, dicha generacin
comprende a todos los clientes que se encuentren activos al momento de crearlas, por ello,
se requiere que se generen de manera individual o en grupo. Previniendo cualquier
situacin se requiere que se pueda cancelar una determinada factura teniendo en cuenta su
motivo.
Los clientes pueden hacer mensuales sus pagos o hacer anticipos, esto significa que
el cliente debe tener un saldo a favor o a pagar. El pago que realizar el cliente (con los
medios antes mencionados) har una aplicacin de pago o tambin llamada liquidacin de
factura. Cuando el pago es realizado a travs de una cuenta bancaria se debe leer la
informacin a travs de un documento de texto dado por la entidad bancaria, si el pago es
realizado a travs de un cheque se debe de tomar los datos del banco, nmero de cheque y
denominacin. La empresa puede hacer al cliente la asignacin de una nota de crdito por
un determinado motivo y monto, el cual deber tambin ser considerado. Previniendo
33

cualquier situacin se requiere que se pueda cancelar una determinada aplicacin de pago
teniendo en cuenta su motivo.
Dentro de la informacin que se imprimir se cuenta con saldos de clientes,
facturas, clientes, clientes activos / suspendidos.
Los saldos de clientes a consultar debern mostrar los datos generales del cliente
como sus cargos y abonos, as como sus clculos correspondientes.
Los datos de las facturas a imprimir deben reflejar la siguiente informacin:
Facturas pagadas en una fecha determinada, Facturas no pagadas en un determinado rango
de fechas, general de facturas, facturas cobradas por cobrador, facturas de clientes
suspendidos, facturas clientes activos, facturas canceladas, notas de crdito, facturas
pagadas en una determinada fecha y facturas no pagadas en una determinada fecha.
Con respecto a los clientes se debe imprimir la siguiente informacin: Cartera
vencida, facturas no pagadas, consumo anual, datos generales, clientes activos o clientes
suspendidos y clientes suspendidos por un mes determinado.

3.2.1 Especificacin de requerimientos

El sistema es requerido por una empresa que brinda los servicios de renta y venta de
aparatos radio localizadores.
La empresa requiere de un sistema que permita llevar a cabo la facturacin de cada
mes para los clientes, tambin deber permitir el registro de los clientes, productos y
servicios.
Los clientes podrn consultar su saldo a travs de la Web. Tambin se requiere el
control sobre el personal de cobro el cual tiene a su cargo diferentes clientes, los cuales
visitan al cliente en el domicilio indicado.
Se deben de generar las facturas por mes de servicio las cuales irn a cuentas por
cobrar, las facturas pueden generarse ya sea por grupo o individualmente, se debe
considerar la cancelacin de dichas facturas.
La aplicacin de pagos de las facturas se hace a travs del banco, directamente en la
empresa a travs del manejo de anticipos y se debe de contemplar la cancelacin de
determinados pagos.
Se debe considerar informacin impresa requerida por la empresa como saldos, los
diferentes estados de las facturas, datos generales de los Clientes as como su actividad
dentro de la empresa (activos o suspendidos).

34

Por ltimo se deben manejar los diferentes productos y servicios dentro del sistema
para su mejor manejo.

3.2.2 Estrategia de solucin

Previamente se ha hecho el anlisis del sistema y la especificacin de
requerimientos, ahora se debe de enfatizar en tomar una estrategia de solucin con forme
una ingeniera de software.
Se utilizar el ciclo de vida clsico de software (tambin llamado en cascada) el cual
tiene un enfoque sistemtico y secuencial del desarrollo del software, que segn pressman
[PrR93], indica que comienza en un nivel de sistema y progresa a travs del anlisis,
diseo, codificacin, prueba y mantenimiento. Modelizado a partir del ciclo convencional
de una ingeniera, este paradigma abarca las siguientes actividades:
Ingeniera y anlisis del sistema: Aqu el trabajo comienza estableciendo los
requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos
requisitos al software. La ingeniera y el anlisis del sistema abarcan los requisitos globales
a nivel del sistema con una pequea cantidad de anlisis y de diseo a un nivel superior.
Dentro del sistema de facturacin ste punto ya ha sido completado en los primeros puntos
de este captulo, en donde se hace el anlisis de dicho sistema as como tambin los
requerimientos solicitados por el cliente.
Anlisis de los requisitos del software. Para comprender la naturaleza de los
programas que hay que construir, el analista debe de comprender el mbito de la
informacin del software, as como la funcin, el rendimiento y las interfaces requeridas.
Los requisitos, tanto del sistema como del software, se documentan y revisan con el cliente.
Aplicando este punto al diseo del sistema de facturacin se toman en cuenta las
caractersticas, tanto del software como del hardware, para poder llevar acabo el diseo al
software, se plantea el uso del sistema manejador de Bases de Datos Oracle como medio de
almacenamiento y para el desarrollo se utilizar una herramienta de Oracle llamada
Developer que consiste por una parte en Forms que permite la creacin de interfaces en
un entorno Windows y para los reportes requeridos se utilizar la herramienta Reports
que permite la comunicacin entre la base de datos Oracle, forms y reports.
Diseo. ste es un proceso multipaso que se enfoca sobre cuatro atributos distintos
del programa: La estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos
en una representacin del software que pueda ser establecida de forma que obtenga la
calidad requerida antes de que comience la codificacin. Este paso en el diseo en cascada
se aplica al sistema de facturacin como este captulo, en el cual se modelan diferentes
aspectos del sistema, permitiendo as su mejor entendimiento antes de hacer dicha
codificacin.
Codificacin. El diseo debe traducirse en una forma legible para la mquina. Si el
diseo se realiza de una manera detallada, la codificacin puede realizarse mecnicamente.
35

Despus de haber hecho el anlisis y verificado en que se desarrollar dicho sistema, se

pasa a la codificacin, como se eligi el entorno de Developer de Oracle como
herramienta de desarrollo se utilizar el lenguaje SQL ya que es el lenguaje de
programacin bsico de las bases de datos relacionales y PL/SQL que es el lenguaje
flexible con el cual se interacta con las herramientas de Oracle hacindolo ms fcil de
manejar dentro del medio de las bases de datos.
Prueba. Una vez que se ha generado el cdigo, comienza la prueba del programa. La
prueba se centra en la lgica interna del software, realizando pruebas que aseguren que la
entrada definida produce los resultados que realmente se requieren. Esta fase permitir al
sistema de facturacin quedar libre de errores comunes de programacin sin embargo
requerir de su etapa de mantenimiento para verificar otro tipo de errores que se puedan
llegar a encontrar.
Mantenimiento. El software sufrir cambios despus que se entregue al cliente. Los
cambios ocurrirn debido a que se hayan encontrado errores, a que el software deba
adaptarse a cambios en los procesos que vena haciendo el cliente manualmente. El sistema
de facturacin debe de pasar esta prueba por el cliente, ya que es el nico que puede evaluar
finalmente el sistema tanto como el pueda aplicarlo a sus necesidades.

3.3 Modelo funcional

3.3.1 Narrativa de las funciones del sistema
El mdulo general se compone de los mdulos de verificacin de usuario, Catlogos
principales, Generacin de cuentas por cobrar, facturacin y Generacin de reportes y
consultas la Figura 3.1 muestra la estructura general de los mdulos.
Sistema de
Facturacin

Cobranza

Verificacin
de usuario

Catlogos
Principales

Figura 3.1

Generar,
asignar, aplicar
Cuentas X Cobrar
y Facturas

Generar
re porte s

y consultas

Modelo Funcional General

1. El primer mdulo es de seguridad donde los usuarios deben de identificarse para poder
acceder al sistema a travs de un nombre de usuario y contrasea

36

1.1. Se cuenta con un submdulo que permite otorgar atributos a usuarios como Cliente,
Usuario supervisor, en caso que el usuario halla accedido como supervisor con su
pasaporte correspondiente
La funcin de verificacin de usuarios es la que permite asignar privilegios
a los usuarios que sern utilizados despus para el acceso al sistema mediante la
asignacin de un nombre de usuario y contrasea, la figura 3.2 muestra la
estructura del mdulo.

Verificar
Usuario

Comprobar nombre
y pasaporte de
usuario

Asignar
permisos

Supervisor

Capturista

Cliente

Figura 3.2

Modelo Funcional del verificacin de usuarios

2. Almacenar y manipular datos de clientes, contratos, cobradores, productos y servicios

El mdulo de catlogos principales es el encargado de generar los datos con los
que el sistema deber de tener primeramente para poder funcionar, ste a su vez se
divide en tres, que son los de Clientes, cobradores y productos y servicios, que cada uno
permite hacer una alta, baja o modificacin de los datos, la figura 3.3 muestra dicha
estructura.
2.1. Guardar, agregar y eliminar Clientes; En este mdulo se pueden hacer las
modificaciones correspondientes al catlogo de Clientes en el caso de que el
usuario halla accedido al sistema como supervisor o usuario con privilegios.
2.2. Guardar, agregar y eliminar Contratos; En este mdulo se pueden hacer las
modificaciones correspondientes al catlogo de Contratos en el caso de que el
usuario halla accedido al sistema como supervisor o usuario con privilegios.

37

2.3. Guardar, agregar y eliminar Cobradores; En este mdulo se pueden hacer las
modificaciones correspondientes al catlogo de Cobradores en el caso de que el
usuario halla accedido al sistema como supervisor o usuario con privilegios.
2.4. Guardar, agregar y eliminar Productos y servicios; En este mdulo se pueden hacer
las modificaciones correspondientes al catlogo de Productos y servicios en el caso
de que el usuario halla accedido al sistema como supervisor o usuario con
privilegios.

Catlogos
Principales

Clientes

Cobradores

Productos y
Servicios

Altas

Altas

Altas

Bajas

Bajas

Bajas

Modificaciones

Figura 3.3

Modificaciones

Modificaciones

Modelo Funcional del catlogos principales

3. Generar, asignar, cancelar, aplicacin de Facturas y Cuentas por Cobrar

El mdulo de generacin de cuentas por cobrar permite primeramente generar
dichas cuentas por cobrar para despus ser capturados a la base, en seguida se aplica el
mdulo de asignacin de cuentas a cobradores para que despus realizados los pagos se
apliquen y despus se efecte la generacin de facturas as como tambin su captura en
el sistema, la figura 3.4 indica la estructura de este mdulo.
3.1. Genera Cuentas x cobrar individuales, en este mdulo se tiene el nmero de
contrato, datos del cliente, fecha, descripcin de cobro, periodo de servicio que se
le cobrar al cliente
3.2. Genera Cuentas x cobrar en grupo, este mdulo se tiene la informacin de los
nmeros de contrato los cuales estn agrupados dependiendo de un determinado
cliente para su cobro de servicio.

38

3.3. Aplicacin de pago de una Cuenta x Cobrar, este es un mdulo en el cual una
cuenta x cobrar ya pagada se aplica a una factura para efectos fiscales del cliente, la
aplicacin del pago a una factura se aplica por grupo o individual, tambin aqu se
considera la aplicacin de una nota de crdito.
3.4. Cancelacin de una Cuenta x Cobrar, este mdulo solo requiere del nmero de
Cuenta x Cobrar, la causa de la cancelacin y fecha.
3.5. Cancelacin de una Factura, este mdulo solo requiere del nmero de folio de la
Factura, la causa de la cancelacin y fecha.
3.6. Asignacin de Cuentas x Cobrar a Cobradores, este mdulo se encarga de asignar a
los cobradores sus Cuentas que sern cobradas a los clientes, solo hay que tener
como referencia el nombre del cobrador y el nmero de Cuenta x Cobrar

Generar, asignar,
aplicar Cuentas X
Cobrar y Facturas

Captura de
Cuentas x Cobrar

Genera

Asignacin de

Cuentas X
Cobrar

Cuentas a
Cobradores

Aplicacin de
Pagos

Captura de
Facturas

Generacin de
Facturas

Figura 3.4 Modelo Funcional de Generacin y

Aplicacin de cuentas x cobrar y facturas

4. Generar Reportes y consultas

4.1. Saldos de clientes, este mdulo genera los reportes de los clientes y muestra sus
datos generales as como su saldo actual, para poder generar el reporte es necesario
dar el rango de nmeros de contrato que se desea imprimir, y ya sea que se desee
consultar por cargo, abono o ambos y dependiendo de ello se hace un clculo.
4.2. Reporte de facturas, aqu se especifican diferentes rangos como: facturas pagadas,
facturas no pagadas, general de facturas, facturas cobradas por determinado
cobrador, facturas de clientes suspendidos, facturas de clientes activos, facturas
canceladas, notas de crdito, facturas pagadas durante un rango de fechas, y
facturas no pagadas en un determinado periodo de fechas.
39

4.3. Clientes, este mdulo puede dar a conocer la informacin general de los clientes
dependiendo de la cartera vencida, facturas no pagadas y consumo anual.
4.4. Clientes Activos / suspendidos, este mdulo permite obtener los datos de los
clientes que su estado se encuentra suspendido o activo a partir de una determinada
fecha, rango de fechas o por mes.

Generacin de
Reportes y
Consultas

Clientes

Figura 3.5

Facturas

Saldos

Pagadas /
No Pagadas

Generales

Por
Cobrador

Activos /
Suspendidos

Canceladas

Modelo Funcional de Generacin de Reportes y Consultas

3.3.2 Narrativa del flujo de datos del sistema (DFD)

En la fase analtica del sistema se han generado los siguientes diagramas que nos
permiten una presentacin grfica de las interrelaciones mostrando el flujo de entrada y
salida de datos.
En el DFD de nivel 0 se muestra solo las entidades externas que permitirn
interactuar con el sistema y las entidades externas a donde llega la informacin finalmente.

40

Factura
Datos personales

Cliente

Capturista
Datos personales

Supervisor

Sistema de
Facturacin y
cobranza de
servicios y
productos de
radiolocalizacin

Cuentas x
Cobrar
Cobrador

Saldos
Cliente

Datos personales

Reportes

Cliente

Capturista
Figura 3.6

Diagrama DFD de Nivel 0

El sistema estar manejado por tres diferentes tipos de usuario: Capturista,

Supervisor y Cliente. El usuario capturista tiene acceso restringido a ciertas reas donde
solo es vlida la captura, manipulacin e impresin de informacin, el usuario supervisor es
aquel que tiene acceso a todo el sistema el cual puede modificar cualquier tipo de
informacin, as como tambin asignar privilegios a usuarios y por ltimo el usuario cliente
el cual solo tiene el derecho de saber el saldo de su cuenta actual en el sistema, se le
considera cliente a la persona la cual tiene un contrato en este sistema y se le considera
capturista a la persona la cual utiliza este sistema como herramienta de trabajo para
manipular informacin de la base de datos con fines que la empresa le requiera.
En el diagrama de flujo de datos en nivel 1 los usuarios que acceden al sistema
debern iniciar con un proceso de validacin el cual identificar los privilegios de cada
usuario, dependiendo de ello es como se tiene acceso solo a consultas que es el caso del
usuario tipo cliente, siendo supervisor o capturista se procede a manejar los dems mdulos
pero con ciertas restricciones que los diferencia entre usuarios.

41

Usuarios
Datos personales
Capturista
Datos personales
Supervisor
Datos personales
Cliente

Factura, cuentas x Cob.

Usuario vlido
Cliente / supervisor / Capturista

Verifica
Privilegios

Datos de
captura

Captura
general
de datos

Usuario vlido
Supervisor / Capturista

P
Info.

Genera
Cuentas
x Cobrar

Saldos, reportes

Consultas

ro d .

Facturas
grneradas

Genera
Factura

os
Dat t e
n
e
i
Cl

Datos
Notas

Datos
Cobrador
Datos
Cliente

Datos clientes/
Prod. & Serv.

Figura 3.7

Prepara
Cuentas a
Cobradores

Cuentas
asignadas

Pagos
liberados

Aplicar
Pagos

Diagrama DFD de Nivel 1

Analizaremos ahora el caso de ser un usuario capturista o supervisor, ste primero

debe de generar las cuentas por cobrar que es el medio por el cual la empresa puede cobrar
por los servicios prestados al cliente, stas se generan tomando en cuenta los datos del
cliente y los de los servicios solicitados por el cliente a travs de un contrato, esta
informacin generada es almacenada en una tabla llamada Cuentas por cobrar. Una vez
generadas las cuentas por cobrar se procede a asignar dichas cuentas a los cobradores
mediante un mdulo de asignacin que requiere solo de las cuentas generadas
anteriormente y los datos de los cobradores que se les asignar.
Cuando los cobradores hayan realizado sus cobros, las Cuentas por Cobrar se
aplican a las facturas las cuales deben de amortizar su valor con el de la cuenta cobrada,
esta informacin est acompaada por los datos del cliente y generar as la factura impresa.
Las facturas generadas son almacenadas como comprobante de venta en la Base de
Datos, teniendo as un control detallado de dicho movimiento contable.
Se cuenta tambin con un mdulo de captura general de datos, en la es alimentada la
Base de Datos con la informacin de Clientes, Cobradores, Productos y Servicios, Notas de

42

Crdito, Facturas, Cuentas por Cobrar y Usuarios. La figura 3.7 seala con detenimiento lo
antes mencionado.
El mdulo de captura general de datos, permite al usuario capturista o administrador
a introducir y modificar los diferentes datos de clientes, cobradores, productos y servicios,
ya que es necesario tener esta informacin antes de que sea utilizado el sistema, el diagrama
de flujo de datos de nivel 2 detalla este mdulo

Datos de
captura

Aplica
Clientes

Datos
Cliente

Figura 3.8

Aplica
Cobradores

Datos
Cobrador

Aplica
Productos
y servicios

Info. Prod.

Diagrama DFD de Nivel 2 Captura General de Datos

Tal como lo muestra la figura 3.8 se detalla la manera en que es procesada la

informacin para ser almacenada a la base de datos, en cada uno de sus mdulos interviene
un proceso de validacin de datos para que la informacin sea la adecuada, as como
tambin se tiene un proceso de captura y modificacin.
El mdulo de consultas consiste en un conjunto de mdulos encargados de generar
los diferentes tipos de reportes para los cuales se toman como base la informacin recabada
de la Base de Datos y la aplicacin de clculos y filtros a cada uno de ellos.
La generacin de cuentas por pagar verifica primero los clientes activos a los cuales
se les calcular los montos a pagar por el servicio dado, los clculos consisten en
multiplicar la cantidad de servicios adquiridos por el monto asignado a dicho servicio de
determinado periodo. La figura 3.9 indica dicho flujo.
El procedimiento de preparar cuentas a cobradores consiste en hacer la seleccin de
los cobradores que se les asignarn determinadas cuentas dependiendo de la solicitud de
cliente y por zona geogrfica, estas asignaciones pueden ser impresas en el mdulo de
43

consulta e impresin de reportes. En la figura 3.10 se muestra el seguimiento de este

proceso

Datos de usuario
vlido

Clientes

Verifica
clientes
activos
Productos y
servicios

Datos de las
Cuentas
Clientes
activos

Monto del
servicio

Figura 3.9

Datos del
cliente

Calcula
montos

Cuentas x
Cobrar
Datos de la
Cta. x Cob

Diagrama DFD de Nivel 2 Generacin de Cuentas por Cobrar

Datos de Cuentas
x Pagar Generadas

Cobradores

Seleccin
de
cobradores

Cuentas x
Cobrar

Figura 3.10

Datos
cobrador
Datos
cobrador
seleccionado

Datos generales
de Cuentas

Asignacin
Cobrador Cuenta
Datos de las
Cuentas
asignadas

Diagrama DFD de Nivel 2 Preparar Cuentas a Cobradores

En el proceso de aplicacin de pagos se selecciona primero a los clientes que han

pagado sus cuentas por pagar, despus se verifica si al cliente se le ha asignado alguna nota
de crdito para ser tomada en cuenta en los clculos de aplicacin, ya que dependiendo del
pago realizado por el cliente y la nota de crdito se puede tener un monto a favor del cliente
o una deuda, despus hecho el clculo se cambia el estado de la cuenta por cobrar a ya
pagada para ser tomada en cuenta para la facturacin, en caso de que el monto no llegue a
44

ser el suficiente para tomar la cuenta por cobrar como liberada, su estado seguir siendo
como no pagada pero con diferente monto. Al finalizar este proceso se seleccionan las
cuentas por cobrar ya pagadas para ser enviadas al proceso de generacin de facturas. En la
figura 3.11 se ilustra el seguimiento de los datos de este proceso.
Notas de
crdito

Clientes

Datos de Cuentas
x Pagar Generadas

Datos
cliente

Seleccin
de Clientes
con cuenta
pagada

Monto de
la nota

Datos del
cliente

Datos de
la nota
Calcular
monto total
de la cuenta
por cobrar

Datos de
la Cuenta

Pagos
Liberados

Datos de la
Cuenta liberada

Cuentas x cobrar

Figura 3.11

Asignacin
de notas de
crdito

Datos de
Cuentas
pagadas

Seleccin
de Cuentas
pagadas

Diagrama DFD de Nivel 2 Aplicacin de pagos

El proceso de generacin de facturas consiste en seleccionar aquellas cuentas por

cobrar ya pagadas, tomar los datos de los clientes que liquidaron dichos pagos y guardar esa
informacin para el momento de imprimir las facturas. En la figura 3.12 muestra dicho
flujo de informacin.

Pagos
liberados

Cuentas x
Cobrar

Clientes

Datos
de la cuenta
Seleccin
de Cuentas
liberadas

Datos de
clientes a
facturar

Datos de
facturas
generadas

Datos de cuentas
seleccionadas
Asignar datos
de cliente cuenta a
factura

Facturas

Datos de la
factura

Figura 3.12

Diagrama DFD de Nivel 2 Generacin de Facturas

45

3.4 Diseo de la base de datos

3.4.1 Entidad relacin

Figura 3.13

Diagrama entidad - Relacin

En este diseo del diagrama Entidad - Relacin se colocaron las entidades como
elementos independientes dentro del problema, sus relaciones expresadas como lneas
continuas y punteadas indican de qu manera interactan dichas entidades. Gracias a este
46

diagrama se puede comprender mejor la manera en que ser almacenada la informacin, ya

que a partir de esto se podr ya implementar los datos en la base de datos como tablas del
sistema. La figura 3.13 es la representacin de dicho diagrama Entidad Relacin.

3.4.2 Normalizacin
Normalizacin es un proceso que clasifica relaciones, objetos, formas de relacin y
dems elementos en grupos, en base a las caractersticas que cada uno posee. Si se
identifican ciertas reglas, se aplica una categora; si se definen otras reglas, se aplicar otra
categora.
La forma de clasificar las relaciones de las bases de datos relacionales es a travs de
los tipos de dependencias que podemos determinar dentro de la relacin. Cuando las reglas
de clasificacin sean ms y ms restrictivas, diremos que la relacin est en una forma
normal ms elevada. La relacin que est en la forma normal ms elevada posible es que
mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de
importancia: La cantidad de espacio requerido para almacenar los datos es la menor posible
y la facilidad para actualizar la relacin es la mayor posible
Para este sistema de facturacin se han implementado dichos niveles de
normalizacin como a continuacin se muestra:
Primera Forma Normal
1) Eliminar los grupos repetitivos de las tablas individuales
Este punto se dio cuando se intenta identificar a cada una de las entidades que
intervienen en el problema tal como se vio en el esquema de entidad relacin, ya
que, como por ejemplo, puede repetirse en una sola entidad nombre de cliente y
factura ya que el cliente va a estar facturando cada mes, la repeticin sera el
cliente que es por cada factura que realice, por tanto es separada en dos
entidades cliente y factura. Esto con todas las entidades vistas en dicho esquema
entidad relacin.
2) Crear una tabla separada por cada grupo de datos relacionados
Esto es similarmente visto como el punto anterior utilizando cada entidad como
tabla, en el esquema de entidad relacin, tal como se observa en la figura 3.9.
3) Identificar cada grupo de datos relacionados con una clave primaria
Aqu se identifica a cada tabla con un elemento de ella como el que marcar la
unicidad de cada elemento almacenado en ella, esto es por ejemplo, que cuando
se almacene un dato de una factura, aunque el mismo cliente halla comprado los
mismos productos en la misma cantidad en la misma fecha, deber de existir un
dato que las haga diferentes, en este caso estamos hablando del folio de la
factura. As del mismo modo con todas las tablas. Esto es visible en el diseo
fsico de la base de datos el cual nos muestra en letras tipo negrita las llaves
primarias de cada tabla.

47

Segunda Forma Normal

Para aplicar la segunda forma normal es necesario que:

La relacin de los datos est en la primera forma normal

Crear tablas separadas para aquellos grupos de datos que se aplican a varios
registros y por ltimo relacionar dichas tablas mediante una clave externa.

Para esto hemos concluido el primer punto como se explico anteriormente, para
aplicar el segundo punto nos basamos en el modelo entidad relacin y se generaron las
tablas junto con su llave primaria respectiva, pero para relacionar la informacin entre las
tablas es necesaria la presencia de otra llave que es conocida como fornea que sirve para
hacer referencia de datos de una tabla hacia otra, es decir, liga la informacin de tal manera
que puedan unirse dos o mas tablas para obtener informacin conjunta entre todas las tablas
que se relacionen.
En este caso se aplicaron las siguientes llaves forneas:
Tablas: Clientes, Contratos
Llave Fornea: Contratos hace referencia a la tabla clientes a travs de la llave:
ClienteNum
Tablas: Productos, Contratos
Llave Fornea: Contratos hace referencia a la tabla productos a travs de la llave:
ProductNum
Tablas: Cobradores, Contratos
Llave Fornea: Contratos hace referencia a la tabla cobradores a travs de la llave:
CobNum
Tablas: DetContrato, Contratos, Facturas
Llave Fornea: Contratos hace referencia a las tablas
DetContrato a travs de la llave: ContratoNum
DetContrato a travs de la llave: FolioFactura
Tablas: NotaCredito, Contratos
Llave Fornea: Contratos hace referencia a la tabla NotaCredito a travs de la llave:
NumNota
Tablas: NotaCredito, CuentasXCobrar
Llave Fornea: CuentasXCobrar hace referencia a la tabla NotaCredito a travs de la
llave: NumNota

48

Tablas: Facturas, CuentasXCobrar, Productos, DetFactura

Llave Fornea: DetFactura hace referencia a las tablas:
Facturas a travs de la llave: FolioFactura
CuentasXCobrar a travs de la llave: CuentaNum
Productos a travs de la llave: ProductNum
Con el uso de las llaves forneas y con informacin almacenada podemos por
ejemplo saber el nmero de contrato de un cliente y que mercanca adquiri, as como
tambin los productos y notas de crdito que intervinieron en una factura entre otras
muchas combinaciones para recuperar informacin.
Tercera Forma Normal
Este nivel trata de traspasar a otra tabla aquellos campos que no dependen del
campo clave, este es un punto de refinamiento el cual pretende eliminar la repeticin
innecesaria d e informacin.
En la aplicacin al sistema de facturacin se separ la tabla de contratos de la de
clientes, ya que anteriormente se repeta la informacin de cada cliente las veces que
tuviese un contrato, es decir, si el cliente deseaba tener 10 productos, diez veces se
almacenaba sus datos personales como nombre, direccin y RFC, pero al llegar a este punto
los datos antes mencionados no dependen del nmero de contrato si no de una clave de
cliente.

3.4.3 Diseo lgico de la base de datos

El diseo lgico cosiste en la transformacin del esquema conceptual previamente
hecho y mostrar las entidades y relaciones vistas anteriormente, como un diseo que
permita identificar las entidades como tablas y sus atributos como llaves primarias, llaves
ajenas y campos de dichas tablas
CLIENTES (Cliente Num, Nombre, Domicilio, C.P., Poblacin, Telfono, RFC)
CONTRATOS (No. Contrato, Nmero de Cliente, Nmero Cobrador, Cdigo
Producto, Nota Nmero, Fecha Inicio, Saldo, Observaciones, Dgito,
Nmero Serie, Clave Radio, Usuario Radio, Status)
COBRADORES (Nmero Cobrador, Nombre, Direccin, Telfono)
PRODUCTOS (Cdigo Producto, Descripcin, Precio)
FACTURAS (Folio, Status, Motivo Cancelacin, Importe Cancelacin)
NOTAS DE CRDITO (Nota Nmero, Monto)

49

CUENTAS POR COBRAR (Cuenta Nmero, Contrato Num, Fecha Pago)

DETALLE CONTRATO FACTURA (No. Contrato, Folio Factura, Fecha)
DETALLE CONTRATO CUENTA X COBRAR (No. Contrato, Cuenta Num,
Fecha)
DETALLE FACTURA (Folio Factura, Cuenta Num, Cdigo Producto, Fecha
Aplicacin de Cuenta, Cantidad Producto, Monto Factura)
USUARIOS (Clave, Nombre, Contrasea)
TABLA
CLIENTES

CONTRATOS

CAMPO
ClienteNum
Nombre
Domicilio
CP
Poblacin
Telfono
RFC

TIPO
Nmero
Texto
Texto
Nmero
Texto
Texto
Texto

TAMAO LLAVE REFERENCIA

5
Principal
100
100
5
50
25
15

ConmtratoNum
ClienteNum
CobNum
ProductNum
NumNota
FechaIni
Saldo
Observaciones
Digito
SerieNum
ClaveRadio
UsuarioRadio
Status

Nmero
Nmero
Nmero
Nmero
Nmero
Fecha
Nmero
Texto
Nmero
Texto
Nmero
Texto
Texto

5
5
3
5
5
9,2
3000
1
15
9
100
1

Nmero
Texto
Texto
Texto

3
100
100
25

Principal

Nombre
Direccin
Telfono
ProductNum
Descripcin
Precio
MostrarMasivo

Nmero
Texto
Nmero
Nmero

5
3000
9,2
1

Principal

COBRADORES CobNum

PRODUCTOS

50

Principal

TABLA
FACTURAS

CAMPO
FolioFactura
Status
MotivoCan
ImporteCan

NOTAS CRED. NumNota

TIPO
Nmero
Texto
Texto
Nmero

TAMAO LLAVE REFERENCIA

9
Principal
1
100
9

Nmero 5
Nmero 9,2

Principal

Monto
CuentaNum
NumNota
FechaPago
Monto
MontoEnvio
ChequeNum
Banco
MontoEfectivo
MontoCheque
MontoBanco
Status
MotivoCan
FechaCancel
IVA

Nmero
Nmero
Fecha
Nmero
Nmero
Nmero
Texto
Nmero
Nmero
Nmero
Texto
Texto
Fecha
Nmero

Principal
Fornea NOTAS CRED.

DET CONTRATO

FolioFactura
ContratoNum
FechaFact

Nmero 9
Nmero 5
Fecha

Principal FACTURAS
Principal CONTRATOS
Principal

DET CTASXCOB

CuentaNum
ContratoNum
FechaElab

Nmero 5
Nmero 5
Fecha

Principal CTAS X COB.

Principal CONTRATOS
Principal

CTAS X COB.

DETFACTURA FolioFactura

Nmero
CuentaNum
Nmero
ProductNum
Nmero
FechaAplicacion Fecha
CantidadProduct Nmero
MontoFactura
Nmero

USUARIOS

Clave
Nombre
Contrasea

5
5
9,2
6
5
100
9
9
9
1
100
2

9
5
5

Principal FACTURAS
Principal CTAS X COB.
Principal PRODUCTOS
Principal

4
9,2

Nmero 3
Texto
50
Texto
10

Principal

Tabla 3.14 Diseo lgico de la Base de Datos

51

3.4.4 Diseo fsico de la base de datos

El diseo fsico esta construido sobre las bases del modelo lgico y describe como
los datos son almacenados. Este es el nivel mas bajo de abstraccin.
CLIENTES
CREATE TABLE CLIENTES
(
CLIENTENUM NUMBER(5)
NOMBRE
VARCHAR2(100 BYTE)
DOMICILIO
VARCHAR2(100 BYTE)
CP
NUMBER(5),
POBLACION
VARCHAR2(50 BYTE),
TELEFONO
VARCHAR2(25 BYTE),
RFC
VARCHAR2(15 BYTE)
)

NOT NULL,
NOT NULL,
NOT NULL,

CONTRATOS
CREATE TABLE CONTRATOS
(
CONTRATONUM
NUMBER(5)
CLIENTENUM
NUMBER(5)
COBNUM
NUMBER(3)
PRODUCTNUM
NUMBER(5)
NUMNOTA
NUMBER(5),
FECHAINI
DATE
SALDO
NUMBER(9)
OBSERVACIONES VARCHAR2(3000 BYTE),
DIGITO
NUMBER(1),
SERIENUM
VARCHAR2(15 BYTE)
CLAVERADIO
NUMBER(9)
USUARIORADIO
VARCHAR2(100 BYTE),
STATUS
VARCHAR2(1 BYTE)
)

NOT
NOT
NOT
NOT

NULL,
NULL,
NULL,
NULL,

NOT NULL,
DEFAULT 0

NOT NULL,

DEFAULT 'S/N' NOT NULL,

DEFAULT 0
NOT NULL,
NOT NULL

COBRADORES
CREATE TABLE
(
COBNUM
NOMBRE
DIRECCION
TELEFONO
)

COBRADORES
NUMBER(3)
VARCHAR2(100 BYTE)
VARCHAR2(100 BYTE),
VARCHAR2(25 BYTE)

NOT NULL,
NOT NULL,

PRODUCTOS
CREATE TABLE PRODUCTOS
(
PRODUCTNUM
NUMBER(5)
DESCRIPCION VARCHAR2(3000 BYTE),
PRECIO
NUMBER(9,2)
)

52

NOT NULL,
NOT NULL

FACTURAS
CREATE TABLE FACTURAS
(
FOLIOFACTURA NUMBER(9)
STATUS
VARCHAR2(1 BYTE)
MOTIVOCAN
VARCHAR2(100 BYTE),
IMPORTECAN
NUMBER(9)
)

NOT NULL,
NOT NULL,

NOTAS DE CRDITO
CREATE TABLE NOTACREDITO
(
NUMNOTA NUMBER(5)
MONTO
NUMBER(9,2)
)

NOT NULL,
NOT NULL

CUENTAS POR COBRAR

CREATE TABLE CUENTASXCOBRAR
(
CUENTANUM
NUMBER(5)
NUMNOTA
NUMBER(5),
FECHAPAGO
DATE,
MONTO
NUMBER(9)
MONTOENVIO
NUMBER(6),
CHEQUENUM
NUMBER(5),
BANCO
VARCHAR2(100 BYTE),
MONTOEFECTIVO NUMBER(9),
MONTOCHEQUE
NUMBER(9),
MONTOBANCO
NUMBER(9),
STATUS
VARCHAR2(1 BYTE)
MOTIVOCAN
VARCHAR2(100 BYTE)
)

NOT NULL,
NOT NULL,

NOT NULL,

DETALLE CONTRATO_FACTURA
CREATE TABLE DETCONTRATO
(
FOLIOFACTURA NUMBER(9)
CONTRATONUM
NUMBER(5)
FECHAFACT
DATE
)

NOT NULL,
NOT NULL,
NOT NULL

DETALLE CONTRATO_CUENTAXCOBRAR
CREATE TABLE DETCUENTAXCOBRAR
(
CUENTANUM
NUMBER(5)
CONTRATONUM NUMBER(5)
FECHAELAB
DATE
)

NOT NULL,
NOT NULL,
NOT NULL

DETALLE FACTURA
CREATE TABLE DETFACTURA
(
FOLIOFACTURA
NUMBER(9)
CUENTANUM
NUMBER(5)
PRODUCTNUM
NUMBER(5)
FECHAAPLICACION
DATE
CANTIDADPRODUCTO NUMBER(4),
MONTOFACTURA
NUMBER(9)
)

NOT
NOT
NOT
NOT

NULL,
NULL,
NULL,
NULL,

53

3.4.5 Tablas del sistema

CLIENTES

Figura 3.15

Esquema de la tabla Clientes

COBRADORES

Figura 3.16

CONTRATOS

54

Esquema de la tabla Cobradores

Figura 3.17

Esquema de la tabla Contratos

Figura 3.18

Esquema de la tabla Productos

PRODUCTOS

FACTURAS
55

Figura 3.19

Esquema de la tabla Facturas

3.5 Diccionario de datos

CLIENTES
CLIENTENUM
NOMBRE
DOMICILIO
CP
POBLACION
TELEFONO
RFC

Nmero que identificar como cliente nico en el sistema

Nombre de la persona Fsica o Moral a la que se le facturar
Direccin fiscal que se va a facturar
Cdigo Postal correspondiente a la direccin
Nombre de la entidad federativa
Telfono del cliente, usando caracteres (,),Nmero de Registro Federal de Contribuyentes

CONTRATOS
CONTRATONUM
CLIENTENUM
COBNUM
PRODUCTNUM
NUMNOTA
FECHAINI
SALDO
OBSERVACIONES
DIGITO
SERIENUM
CLAVERADIO
USUARIORADIO
STATUS

56

Nmero de contrato nico que se le asigna al cliente

Nmero de cliente asignado
Nmero de cobrador asignado
Nmero de producto (radio) que se prestar el servicio
Nmero de nota de crdito, en caso de asignacin
Fecha de Inicio del contrato
Saldo a la fecha del contrato, Saldo a Favor, Saldo deudor
Texto que permite detallar el estado del contrato
Nmero que permite identificar clave del servicio del radio localizador
Nmero de Serie que tiene el aparato Radio Localizador
Clave del radio la cual permite tener contacto con el usuario
Nombre del usuario del Radio Localizador
Estado del Servicio, (A)ctivo (S)uspendido

COBRADORES
COBNUM
NOMBRE
DIRECCION
TELEFONO

Clave nica que identifica al cobrador

Nombre completo del cobrador
Domicilio fsico del cobrador
Telfono donde se puede localizar al cobrador

PRODUCTOS
PRODUCTNUM
DESCRIPCION
PRECIO

Clave nica con la que se identifica al producto o servicio

Texto que detalla la descripcin del producto o servicio
Indica el precio del producto o servicio en pesos Mexicanos

FACTURAS
FOLIOFACTURA
STATUS
MOTIVOCAN
IMPORTECAN

Nmero de Folio fsico de la factura fiscal

Estado de la factura, (P)agada, (N)o pagada, (C)ancelada
En caso de cancelacin explicar su motivo
Monto en Pesos Mexicanos por motivo de Cancelacin

NOTAS DE CRDITO
NUMNOTA
MONTO

Nmero consecutivo de nota de crdito generada

Monto en Pesos Mexicanos de la Nota de Crdito

CUENTAS POR COBRAR

CUENTANUM
NUMNOTA
FECHAPAGO
MONTO
MONTOENVIO
CHEQUENUM
BANCO
MONTOEFECTIVO
MONTOCHEQUE
MONTOBANCO
STATUS
MOTIVOCAN

Nmero consecutivo de Cuenta por Cobrar

Nmero de nota de crdito asociada a la cuenta por cobrar
Fecha de Pago de la Nota de Crdito
Cantidad en Pesos Mexicanos cobrada por concepto de cuenta x cobrar
Cantidad en Pesos Mexicanos por concepto de envo
Nmero de folio de cheque dado como pago
Nombre de la institucin bancaria donde proviene el cheque
Cantidad en Pesos Mexicanos por concepto de pago en efectivo
Cantidad en Pesos Mexicanos por concepto de pago con cheque
Cantidad en Pesos Mexicanos por concepto de pago con depsito
Estado de la cuenta, (P)agada, (N)o pagada, (C)ancelada
En caso de cancelacin explicar su motivo

DETALLE CONTRATO_FACTURA
FOLIOFACTURA
CONTRATONUM
FECHAFACT

Nmero de Folio fsico de la factura fiscal asignado al contrato

Nmero de contrato asignado a la factura
Fecha de aplicacin de la factura

DETALLE CONTRATO_CUENTAXCOBRAR
CUENTANUM
CONTRATONUM
FECHAELAB

Nmero consecutivo de Cuenta por Cobrar asignado a una factura

Nmero de contrato asignado a la cuenta por cobrar
Fecha de elaboracin de la cuenta x cobrar

DETALLE FACTURA
FOLIOFACTURA
CUENTANUM

Nmero de Folio fsico de la factura fiscal

Nmero consecutivo de Cuenta por Cobrar

57

PRODUCTNUM
FECHAAPLICACION
CANTIDADPRODUCTO
MONTOFACTURA

Clave nica con la que se identifica al producto o servicio

Fecha de aplicacin de la factura
Cantidad en unidades enteras del producto adquirido
Monto en Pesos Mexicanos del monto total de la factura

USUARIOS
CLAVE
NOMBRE
PASSWORD

58

Nmero nico de identificacin de usuario

Nombre del usuario que accede al sistema
Contrasea que usa el usuario para poder ingresar al sistema

Captulo 4

Desarrollo del sistema

En este captulo se muestra el desarrollo del sistema a nivel software donde es

utilizada la herramienta de Oracle Developer para generar formas y reportes que permitirn
al usuario acceder a la base de datos.

4.1 Herramientas de desarrollo

En esta etapa se implementan las herramientas que nos permitirn desarrollar los
elementos grficos del sistema de facturacin. Se inicia con el diseo de la estructura de
men que contendr el acceso a cada mdulo del sistema, se modelaron varias estructuras
pensando en la organizacin ms frecuente que el usuario puede manejar.

4.1.1 Mens
La implementacin de la herramienta de Forms para poder desarrollar un men luce
como lo muestra la figura 4.1.

Figura 4.1

Diseo de la barra de men

El diseo del men fue pensado en la frecuencia de uso que tendr el usuario con
cada uno de los mdulos, cada uno fue agrupado por secciones: Catlogos y Cuentas por
Cobrar en donde a cada uno se le asocia un sub men de reportes. A cada elemento del
men se le asigna la instruccin de llamado a los dems mdulos, estas instrucciones en
Forms se le llaman Triggers, que son cdigo PL/SQL SQL que permiten la manipulacin
de todo el entorno grfico. El cdigo para el llamado de otras formas a travs del men es:
open_form('CatClientes');
Esta instruccin se lee:
59

open_form(''); - Instruccin que manda a ejecutar una forma a travs del

nombre de la forma a abrir dado como parmetro entre
parntesis y apstrofes, finalizando la instruccin con
punto y coma.
Esta instruccin se repite por cada mdulo que se ejecutar; Los reportes no se
manejan de manera directa por el men, si no son llamados a travs de otros mdulos
forma. Al igual que otro componente de Forms, los mens deben de ser compilados y
generar su archivo ejecutable. En este caso los tipos de archivos manejados para el men
son:
menu.mmb Archivo fuente de un men, contiene cdigo modificable.
menu.mmx Archivo ejecutable, su contenido no puede ser modificado.
El men dentro del sistema final, ser llamado a travs de su archivo menu.mmx por
medio de una forma principal encargada de contenerlo junto con una barra de herramientas.
La barra de herramientas contiene el acceso slo a los mdulos que se utilizan con
ms frecuencia, y las instrucciones para llamar a los mdulos son las mismas que se
ocuparon para los mens.
Para generar cualquier elemento de Forms, ya sea una Forma, Men o mdulo es
necesario conectarse con la base de datos con el fin de que lo que se este manipulando
concuerde con los tipos, nombres y caractersticas de los elementos de la base de datos con
los que se va a trabajar. Esto se hace a travs de la instruccin connect del men File, en
esta ventana se especifica el nombre de usuario, contrasea y nombre de la base de datos a
la que se desea conectar tal y como lo muestra la imagen 4.2.

Figura 4.2

Conexin a la Base de Datos a travs de Forms de Oracle

4.1.2 Asistente para formas

Una vez hecha la conexin a la base de datos se puede disear compilar y ejecutar
los elementos que se generan en Forms. Una de las formas de generar las formas del
sistema es a travs del asistente de bloques, en la figura 4.3 muestra cmo se crea una
forma con un bloque.

60

Figura 4.3

Asistente para generar formas de tipo bloque

Despus de seleccionar que los datos que deseamos mostrar los obtendremos de una
tabla o vista, se procede a oprimir el botn next para elegir la tabla o vista, para luego
seleccionar las columnas disponibles de las tablas, ya sea de manera individual o todas,
como lo muestra la imagen 4.4.

Figura 4.4

Seleccionando la tabla y campos a manejar en la forma

Cuando se halla terminado de seleccionar los campos de una determinada tabla, nos
mostrar una ventana que se ha terminado de dar las configuraciones para generar un
bloque de datos y se preguntar si se desea terminar el asistente o continuar con el asistente
de Layout, como lo muestra la figura 4.5.

61

Figura 4.5

Finalizando asistente de bloque de datos

Si se elige continuar con el asistente de Layout, aparecer la ventana que muestra la

figura 4.6, en donde se le indica en qu canvas se va a colocar los elementos del bloque de
datos generados con el asistente anterior, as como el tipo de canvas.

Figura 4.6

Seleccionando nombre y tipo de canvas del asistente de Layout

Despus de seleccionar el nombre y tipo de canvas, se seleccionan los elementos del

bloque de datos que se van a desplegar en el canvas, ntese que slo se podrn elegir los
campos seleccionados de la tabla del bloque de datos generado.

62

Figura 4.7

Seleccionando nombre y tipo de canvas del asistente de Layout

En la ventana de la imagen 4.7, ya que se seleccionaron los elementos a desplegar se

les puede cambiar el tipo de Item as como al grupo que pertenecern dentro de la forma.
Despus de esto, se personalizan los nombres y tamaos que tendrn los elementos.
Aunque despus se podrn manipular ms propiedades de los Items.

Figura 4.8

Personalizando propiedades de los Items.

En seguida se elige el modo de desplegar los datos de la tabla o vista seleccionada,

se puede decidir entre un registro a la vez si se elige Form, y se pueden desplegar 2 o ms
registros a la vez si se elige el modo tabular, como lo muestra la imagen 4.9.

63

Figura 4.9

Seleccionando el modo de desplegar los datos.

Cuando se ha seleccionado el modo de desplegar los datos, se da el nombre del

recuadro que contendr los elementos a desplegar, el nmero de registros a mostrar, la
distancia entre los campos y si se mostrar la barra de desplazamiento, estos tres ltimos si
se eligi la opcin de mostrar los datos de manera tabular, como lo muestra la imagen 4.10.

Figura 4.10

Propiedades de los elementos mostrados en la forma.

Todo esto genera ya una interfaz grfica que hace posible la interaccin del usuario
con la base de datos Oracle como lo muestra la imagen 4.11, donde para llevar a cabo el
llamado de los datos a la forma requiere de cdigo PL/SQL, entre otros elementos que a
continuacin se indicar.

64

Figura 4.11

Base de Datos y Formas

Al crear una forma, no se deben de utilizar sentencias SELECT y DML explcitas

para manipular los datos que se estn capturando o desplegando en la forma.
Slo se deben utilizar sentencias SQL explcitas cuando se manipulen datos de
tablas que no se estn manejando directamente en la forma, por ejemplo, insertar registros
en una bitcora.

4.1.3 Pasos para construir una forma

Para algunos items que forman una llave fornea, es necesario desplegar datos
relacionados (descripcin). Por ejemplo, si tenemos un bloque de Ordenes, se requiere que
a la derecha del item clientenum (llave fornea hacia Clientes) se despliegue el nombre del
cliente. En estos casos se debe de crear un nuevo bloque por cada llave fornea. A estos
bloques los denominamos bloques de descripcin.
Para construir una forma que manipule los datos de una TABLA, se siguieron los
siguientes pasos:
1) Crear un bloque que contenga slo las llaves primarias de TABLA.
Ligar la property class Frame al frame del bloque.
Cambiar el nombre del bloque a TABLA_PK.
Ligar a este bloque la property class BLOCK.
Cambiar la propiedad Database Data Block a No.
Ligar al ltimo item del bloque la property class ITEM_PK.
La figura 4.12 muestra este punto.
2) Crear un bloque basado en TABLA.
Esta vez se incluyeron todas las columnas necesarias. Las columnas que
forman la llave primaria de la tabla tambin deben de ser incluidos en el
bloque, pero no deben de ser visibles.
65

Eliminar el frame asociado al bloque y acomodar los items dentro del frame del
bloque PK.
En los items que forman la llave primaria de TABLA, se debe de copiar el
valor del item correspondiente que est en el bloque TABLA_PK.
Si se van a desplegar descripciones relacionadas con llaves forneas del bloque,
hay que ligarle la property class BLOCK_MAIN, de lo contrario ligar la
property class BLOCK
La figura 4.13 muestra este punto.

Propiedad Database
Data Block = no

Property Class
BLOCK

Ligar la Property Class

FRAME al frame del bloque

Property Class
ITEM_PK
Figura 4.12

Construccin de un bloque de llaves primarias

Property Class
BLOCK_MAIN
BLOCK

Eliminar el frame del

bloque y acomodar los
items dentro del frame
del bloque PK

Figura 4.13

Propiedad Copy Value from

Item = TABLA_PK.ITEM_PKx
No visibles

Construccin del bloque principal (bloque de trabajo)

3) Por cada bloque de descripcin que se necesite, se necesita:

Crear un bloque basado en la tabla a la que se hace referencia en una llave
fornea.
66

Incluir las columnas que forman la llave primaria y la columna que desea poner
como descripcin.
Crear una relacin maestro-detalle, siendo el bloque maestro, el bloque que
tiene la llave fornea (el bloque TABLA) y el detalle, el que tiene la llave
primaria (el bloque que estamos creando).
Los items que forman la llave primaria no se deben desplegar.
Eliminar el frame asociado al bloque y acomode los items dentro del frame del
bloque PK.
Ligar a este boque el property class BLOCK_QUERY.
Ligar la property class ITEM_DESCRIPCION a los items que forman la
descripcin
La figura 4.14 explica esta unin entre bloques.
4) Modificar el nombre del canvas, para que sea ms representativo
BLOQUE PK

BLOQUE
DESCRIPCIN
Property Class
BLOCK_QUERY

No visible
Property Class
ITEM_DESCRIPCION

Crear
relacin

Eliminar el frame del

bloque y acomodar los
items dentro del frame
del bloque PK
Figura 4.14

Unin entre bloques

5) En el trigger WHEN-NEW-ITEM-INSTANCE que se encuentra a nivel

forma, se colocan los valores apropiados en las instrucciones:
sys_constraints.validaItemsNotNull(<NOMBRE_CANVAS>, vItem,
<LISTA DE ITEMS DEL BLOQUE PK>);
go_block(<BLOQUE_PRINCIPAL>);

La figura 4.15 muestra el cdigo ya implementado.

6) En el trigger WHEN-VALIDATE-ITEM a nivel de bloque principal , se
escribe la lista de items que forman parte de una llave fornea:
:system.trigger_item IN ('<LISTA DE ITEMS>')

7) En la unidad de programa queryFkRecord, se ponen los valores apropiados en la

instruccin:
67

sys_constraints.consultaFK(pTriggerItem, '<BLOQUE>',
<LLAVE FORANEA>)

donde <BLOQUE> es un bloque de descripcin y <LLAVE FORANEA> es una lista

de items que forman la llave fornea hacia el bloque de descripcin.
Debe haber tantas instrucciones de este tipo como bloques de descripcin haya
en la forma.
8) Crear un bloque de control para botones. Se toman los botones de la librera de
objetos. Si se requiere un botn que no se encuentra en la librera, se crea un
botn y se liga la property class Button
Para el ejemplo del catlogo de clientes el cdigo del trigger WHEN-NEW-ITEMINSTANCE queda de la siguiente manera:
DECLARE
vItemActual VARCHAR2(60);
vItem
VARCHAR2(80);
BEGIN
IF (:parameter.query = 'Y') THEN
:parameter.query := 'N';
vItemActual := :system.cursor_item;
--- VALIDA SI LOS CAMPOS DEL BLOQUE PK SON NO NULOS Y ENTONCES CONSULTA EL REGISTRO
-IF (lGNValid.validaItemsNotNull('PRINCIPAL', vItem,
'CLIENTES_PK.CLIENTENUM')) THEN
go_block ('CLIENTES');
--- LIMPIAR EL BLOQUE SLO SI TIENE DATOS
-IF :system.block_status <> lGNConst.cEdoNew THEN
clear_block(no_validate);
--- LIMPIAR EL BLOQUE DE DESCRIPCIONES
-END IF;
execute_query;
ELSE
go_block ('CLIENTES');
clear_block(no_validate);
--- LIMPIAR EL BLOQUE DE DESCRIPCIONES
-END IF;
go_item(vItemActual);
--- SI El ITEM NO ESTA HABILITADO, AVANZAR AL ITEM SIGUIENTE
-IF (get_item_property(vItemActual, enabled) = 'FALSE') THEN
next_item;
END IF;
END IF;
END;

Figura 4.15

Cdigo del trigger forma WHEN-NEW-ITEM-INSTANCE

En este cdigo se muestra cmo se han colocado los nombres de los bloques y Items
de la forma que se est realizando. La funcionalidad de este cdigo es de que si se
68

habilita el parmetro Query limpiar los items que contengan informacin y

mostrar los nuevos datos a travs de la instruccin execute_query; la cual hace el
llamado a la base de datos y regresa con ellos a la forma, mostrndolos en el bloque
donde est situado: go_block ('CLIENTES');
El diseo de la ventana es hecho sobre un rea de trabajo llamada canvas, la cual
puede contener uno o varios bloques de datos. El diseo de la ventana del catlogo de
clientes luce como lo muestra la imagen 4.16. en donde se muestran los controles que
servirn para mostrar la informacin de la base de datos.

Figura 4.16

Diseo de la pantalla

4.1.4 Llamando reportes desde las formas

Para mandar a llamar a un reporte, puede ser utilizado el built-in run_product el cual
funciona bien cuando se trabaja en un ambiente cliente-servidor, pero cuando la aplicacin
se sube al WEB, el reporte que se llama no se muestra en el cliente sino en el servidor.
En Forms se puede crear un objeto Report, el cual representa un mdulo reporte, y
para ejecutarlo se utiliza el built-in run_report_object en lugar de run_product. En un
ambiente cliente-servidor no hay ninguna diferencia entre ejecutar un reporte con
run_product o run_report_object; pero en un ambiente WEB, el segundo no presenta
ningn problema. Por lo tanto, en esta aplicacin utilizaremos run_report_object.
Para utilizar run_report_object, primero se tiene que crear un objeto Report:
1.
2.
3.

En el Navegador, seleccione el nodo Reports, y haga clic en el icono Create.

Se desplegar la caja de dilogo Nombre_modulo: New Report.
Seleccione Use Existing Report File y escriba el nombre del reporte.
En el nuevo objeto, configure sus propiedades:
Name. Nombre del objeto Report (del objeto, no del mdulo).
Filename. Nombre del reporte (no se debe de especificar la ruta).
Execution Mode. Se debe de configurar a Runtime.
Report Destination Type. Configurarlo a Screen
69

Figura 4.17

Llamado de reportes a travs de forms

El cdigo para el llamado de reportes es el siguiente:

run_report_object( {nombre_reporte VARCHAR |
id_reporte report_object }
[, lista_param { VARCHAR2 | paramlist } ] )

En el trigger en donde va a llamar al reporte, cree la lista de parmetros que le va a

pasar al reporte. No hay ninguna restriccin con respecto a esta lista de parmetros. A
run_report_object se le puede pasar como parmetro, el nombre o el apuntador de un objeto
report. El apuntador se obtiene mediante find_report_object.
La sintaxis de estos built-ins se muestra arriba, donde:
nombre_reporte
id_reporte
lista_param

Especifica el nombre de un objeto Report.

Especifica el apuntador a un objeto Report.
Especifica una lista de parmetros.

4.2 Ambiente de las herramientas de desarrollo

Forms incluye tres componentes que usted puede acceder como diseador de
aplicaciones:
Forms Builder. Este componente permite disear y guardar las definiciones de
mdulos forma, men y librera. Tambin permite invocar a los otros dos
componentes. El archivo ejecutable es IFBLD60.EXE.
Forms Compiler. Lee la definicin de un mdulo y crea un archivo ejecutable. El
archivo ejecutable es IFCMP60.EXE.
Forms Runtime. Es un programa que corre una aplicacin ejecutable de Forms. El
archivo ejecutable es IFRUN60.EXE.
70

4.2.1 Forms Builder

Este es un entorno grfico en donde se trabajar la mayor parte para generar las
formas, se compone de los siguientes elementos:
1) Navegador de Objetos: Esta ventana nos muestra de manera jerrquica los
elementos que componen una forma, stos son: Triggers de forma, Alertas,
Libreras Adjuntas, Bloques de datos, Canvas, Listas de valores (LOVs), Grupos de
objetos, Parmetros, Unidades de programa, Propiedades de clases, Record groups,
Reportes, Atributos visuales y Ventanas.
2) rea de trabajo de Canvas: sta es una ventana en la cual se manipulan los objetos
que se mostrarn al usuario a travs de un canvas, aqu se le da la apariencia y
posicin a los Items.
3) Paleta de propiedades: Aqu se muestran y modifican las propiedades de todos los
elementos que pueden existir en forms, ya sea que sea un elemento de la ventana de
Navegador de Objetos (1) del rea de trabajo de Canvas (2).

Figura 4.18

Componentes de Forms Builder

Dentro de forms builder se puede manejar diferentes tipos de Items dependiendo de

la finalidad que se le de. Una aplicacin tpica en Forms utiliza una variedad de objetos y
tipos de items, como lo muestra la figura :
1. Objetos boilerplate (texto, imgenes, dibujos)
2. Text items
71

3.
4.
5.
6.

Display items
List items
Botones
Radio buttons (que forman radio groups)

Figura 4.19

Elementos de datos.

4.2.2 Forms Runtime

Una sesin Runtime consiste de una o ms formas y mens ligados, todos bajo el
control de un usuario. Los componentes principales de una sesin Runtime son:
Multiple-Document Interface (MDI) Parent Window. Es una ventana contenedora,
en la cual, una aplicacin puede desplegar mltiples formas.
Nota: El concepto de MDI slo es aplicable a Microsoft Windows.
Men Default. Es el men que Forms liga automticamente a todas las
aplicaciones. ste se puede reemplazar o personalizar.
Consola. En la consola se proporciona informacin til al usuario en tiempo de
ejecucin. Tiene dos partes.
La lnea de mensajes: Despliega mensajes especficos de Forms y de la aplicacin.
La lnea de estatus: Despliega una variedad de indicadores que reflejan el estado
actual de la forma
La Figura 4.17 muestra los componentes de Runtime.

72

Men
Default
MDI Parent
Window

Consola: Lnea de
Estatus y de Mensajes

Figura 4.20

Componentes de Runtime

4.2.3 Triggers
Un trigger es una unidad de programa que es ejecutada (disparada) debido a un
evento. Forms le permite construir elementos poderosos en una aplicacin, sin escribir una
sola lnea de cdigo. Los triggers le permiten agregar o modificar funcionalidad a la
aplicacin mediante cdigo PL/SQL.
Todos los triggers que usted defina son asociados con un evento especfico. Forms
define una amplia gama de eventos que pueden disparar un trigger. Estos incluyen: eventos
relacionados con consultas, validacin, navegacin, interaccin del usuario con los items de
la forma, eventos internos de la forma, errores y mensajes.
En Developer/2000, los triggers son escritos en PL/SQL. Hay tres componentes
principales a considerar cuando se disea un trigger:
Tipo de Trigger. Define el evento especifico que causar que se dispare el trigger.
Cdigo del Trigger. Cdigo en PL/SQL que define las acciones del trigger.
Alcance del trigger. El nivel en la forma, donde el trigger es definido. Esto
determina el alcance sobre el cual los eventos sern detectados por el trigger.

73

PL/
PL/ SQL
SQL
Queries
Validacin
Movimiento del Cursor/Mouse
Cursor/Mouse
Interaccin con el Usuario
Evento interno
Errores y Mensajes
Otros

Evento

Dispara

PL/
PL/ SQL
SQL

PL/
PL/ SQL
SQL
Tipos de
Triggers
Figura 4.21

Ejecucin de un Trigger

A continuacin se muestran los Triggers de forma que se utilizaron para el catlogo

de clientes, que son similares a los que se utilizaron para los otros mdulos
El Trigger WHEN-NEW-FORM-INSTANCE es el primero que se dispara cuando
la forma es ejecutada, aqu se escribe el cdigo PL/SQL de inicializacin de los Items. He
aqu el cdigo:
/*****************************************************************************/
/* Modulo:
CatClientes.fmb
/* Autor:
Miguel Angel Ochoa Rodrguez
/* Sistema
Factura
/* Fecha:
15-Feb-2004
/* Descripcion: Catlogo que permite manejar la informacion de los clientes que
/*
servir despus para la facturacin
/*****************************************************************************/
DECLARE
BEGIN
--- ELIMINA AVISOS DE OPERACIN
-:system.message_level := 5;
--- ESTABLECE LA BARRA DE ESPECIFICACION DE TECLAS. SI DESEA QUE UNA
-- TECLA NO SE MUESTRE, PONGA COMO COMENTARIO LA INSTRUCCION CORRESPONDIENTE
-:generico.esc := 'ESC-Salir';
:generico.f1 := 'F1-Ayuda';
:generico.f2 := 'F2-Grabar';
:generico.f3 := 'F3-Borrar';
:generico.f9 := 'F9-Buscar';
set_item_property('GENERICO.ESC', visible, property_true);
set_item_property('GENERICO.F1', visible, property_true);
set_item_property('GENERICO.F2', visible, property_true);
--- RECUPERA EL AVISO DEL DIA
-:generico.aviso := 'Datos del cliente que sern utilizados en la factura';
--- CARGA EL LOGOTIPO DE LA EMPRESA
--

74

read_image_file('elite.gif', 'GIF', 'GENERICO.LOGO');

-- Codigo
go_item('listaclientes.clientenum');
execute_query;
END;

El cdigo anterior habilita las teclas que estarn disponibles durante la ejecucin de
la forma, desplegar los datos seleccionados de la tabla clientes en el bloque de lista
inferior de la forma, esto a travs de la instruccin:
go_item('listaclientes.clientenum');
execute_query;

go_item (); permite llevar el control hacia el bloque indicado como parmetro y la
instruccin execute_query; manda a llamar los datos de la tabla asociados del bloque.
El siguiente cdigo muestra cmo se insertarn los datos a la tabla de clientes que
son especificados en la forma. Este cdigo est contenido en una unidad de programa
llamada grabar y que a su vez es llamado por el Trigger WHEN-BUTTON-PRESSED del
botn grabar.
PROCEDURE grabar IS
BEGIN
IF :system.form_status <> lGNCOnst.cEdoChanged THEN
RAISE form_trigger_failure;
END IF;
--- VALIDACION DE DATOS CAPTURADOS
-IF :clientes_pk.clientenum IS NULL THEN
mensaje('Falta de captuar el nmero de cliente',1);
go_item('clientes_pk.clientenum');
raise Form_Trigger_Failure;
END IF;
IF :clientes.nombre IS NULL THEN
mensaje('Falta de captuar el nombre de cliente',1);
go_item('clientes.nombre');
raise Form_Trigger_Failure;
END IF;
IF :clientes.domicilio IS NULL THEN
mensaje('Falta de captuar el domicilio de cliente',1);
go_item('clientes.domicilio');
raise Form_Trigger_Failure;
END IF;
IF :clientes.poblacion IS NULL THEN
mensaje('Falta de captuar la poblacin de cliente',1);
go_item('clientes.poblacion');
raise Form_Trigger_Failure;
END IF;
--- INICIA LA TRANSACCIN
-BEGIN
--- DML A LOS BLOQUES DE LA VENTANA
-post;
IF :system.form_status <> lGNCOnst.cEdoQuery THEN
RAISE form_trigger_failure;
END IF;

75

--- SALVA LAS OPERACIONES DML

-commit_form;
IF :system.form_status <> lGNCOnst.cEdoQuery THEN
RAISE form_trigger_failure;
END IF;
clear_message;
message('Los datos se grabaron satisfactoriamente');
EXCEPTION
WHEN OTHERS THEN
lGNValid.execRollback;
RAISE form_trigger_failure;
END;
END;

El cdigo de la unidad de programa Borrar, es llamado por el Trigger de WHENBUTTON-PRESSED del mismo nombre que contiene el siguiente cdigo:
PROCEDURE borrar(pBloque VARCHAR2) IS
BEGIN
IF :system.form_status = lGNCOnst.cEdoNew THEN
RAISE form_trigger_failure;
END IF;
--- VALIDACION DE DATOS CAPTURADOS
-DECLARE
vClienteNum contratos.clienteNum%Type;
vcontratoNum contratos.contratoNum%Type;
BEGIN
SELECT
INTO
FROM
WHERE

contratonum, clientenum
vContratoNum, vClienteNum
contratos
clientenum = :clientes_pk.clientenum;

set_alert_property('ALERT_STOP',alert_message_text,'No puede Borrar al cliente '||vClienteNum

||', Tiene el contrato: '||vContratoNum||' asignado');
IF SHOW_ALERT('ALERT_STOP') = alert_button1 THEN
--:clientes_PK.clienteNum := NULL;
RAISE form_trigger_failure;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND THEN
:system.message_level := 5;
WHEN TOO_MANY_ROWS THEN
set_alert_property('ALERT_STOP',alert_message_text,'No puede Borrar al cliente '||vClienteNum
||', Tiene varios contratos asignados');
IF SHOW_ALERT('ALERT_STOP') = alert_button1 THEN
--:clientes_PK.clienteNum := NULL;
RAISE form_trigger_failure;
END IF;
END;
--- INICIA LA TRANSACCIN
-BEGIN
go_block(pBloque);
delete_record;
--- DML A LOS BLOQUES DE LA VENTANA
-post;
IF :system.form_status <> lGNCOnst.cEdoQuery THEN
RAISE form_trigger_failure;
END IF;
--- SALVA LAS OPERACIONES DML
-commit_form;
IF :system.form_status <> lGNCOnst.cEdoQuery THEN
RAISE form_trigger_failure;
END IF;
clear_message;
message('Los datos fueron borrados satisfactoriamente');
EXCEPTION
WHEN OTHERS THEN
lGNValid.execRollback;
RAISE form_trigger_failure;
END;

76

--- INICIALIZA LA VENTANA

-go_item('listaclientes.clientenum');
execute_query;
END;

4.2.4 Reports Builder

Antes de construir un reporte, se deben entender los conceptos bsicos de
navegacin en la interfaz de Reports Builder. Tambin se deben apreciar las reas donde se
definen los datos y la presentacin del reporte. Un reporte consiste de uno o ms queries. Se
puede codificar los queries directamente dentro del reporte o incluir un query externo. Para
construir un reporte usando Reports, se deben seguir algunos pasos bsicos:
1. Crear la definicin de un reporte.
2. Definir el Data Model para especificar que datos son requeridos.
3. Definir el Layout para especificar como aparecern los datos en el reporte.
4. Ejecutar el Previewer para probar el reporte.
5. Ampliar el reporte, modificando el layout y agregando objetos, cdigo PL/SQL,
color, etc.
6. Guardar el reporte.
En Reports se manejan diferentes ventanas para poder generar reportes como a
continuacin se describen:
Object Navigator. El Object Navigator se despliega cuando se inicia Reports y
permanece disponible durante toda la sesin de diseo. Se muestra como una vista
jerrquica de los mdulos abiertos en la sesin actual, permitiendo localizar, inspeccionar y
modificar mdulos.

Figura 4.22

Ventana Object Naviator de Reports Oracle 6i

77

Data Model. Se hace doble clic en el nodo Data Model en el Object Navigator para
abrir la ventana Data Model. Esta ventana se utiliza para crear el query (o los queries) para
el reporte, definir columnas adicionales, agregar data links y filtros. En esta ventana se
define que datos contiene el reporte.

Figura 4.23

Ventana Data Model de Reports Oracle 6i

Layout Editor. Se hace doble clic en el nodo Layout Model en el Object Navigator
para abrir la ventana Layout Model. Esta ventana se utiliza para desplegar el layout del
reporte, el cual se puede crear por default, y ampliarlo como sea requerido. Contiene
muchos objetos, como fields, frames y boilerplates. En esta ventana se define como se
presentan los datos.

Figura 4.24

78

Ventana Layout Model de Reports Oracle 6i

Runtime Parameter Form. Esta ventana se despliega cuando se ejecuta un reporte.

En esta ventana se pueden escribir valores para parmetros, ya sea del sistema o del
usuario. Por default esta ventana no se despliega, a menos que se especifique lo contrario.

Figura 4.25

Ventana Runtime Parameter Form de Reports Oracle 6i

Live Previewer. En esta ventana se despliegan los datos del reporte. Esta ventana es
muy parecida al Layout Editor (de Forms o de Reports) y se puede modificar la apariencia
del reporte: color, fuentes, mscaras de formato, etc.

Figura 4.26

Ventana Live Previewer de Reports Oracle 6i

79

4.3 Recursos de Hardware y Software

Los requerimientos de Hardware y Software para instalar la base de datos y los
componentes de Developer 6i de Oracle, dependen de los elementos que se elijan al
instalar.
Para la instalacin de Oracle Developer 6i se tienen los siguientes requerimientos:
En la parte del Cliente:
Procesador Pentium 166 MHz superior
128 Mb en RAM*
1 Gb En Disco Duro
Entre 298 and 587 Mb disponibles en disco duro, dependiendo de las opciones

a elegir.
Sistema Operativo: Windows NT 4.0 con Service Pack 5 o 6, Windows 2000
con Service Pack 1, Windows98 or Windows95
* Requiere 256 Mb RAM si se usan utilidades de Java
Para trabajar bajo Windows es necesario manejar una cuenta de tipo
administrador en la parte de Base de Datos.
En la parte del Servidor:
Como mnimo 64 Mb en RAM, de donde 32 Mb deben de estar disponibles para

el rea de sistema Global (SGA)

Por cada repositorio:
o Aproximadamente 140 Mb en el SYSTEM tablespace para los paquetes
repositorio, procedimientos y vistas
o Entre 20 and 325 Mb en otros tablespaces, para los datos repositorios
Oracle8i Enterprise Edition Standard Edition, release 8.1.7*
Versin de SQL*Plus compatible con la Base de Datos
Versin of TNS Listener compatible con la Base de Datos
* En este caso se instal la base de datos Oracle 9i por lo cual no existen
inconvenientes a este punto.

80

Captulo 5

Pruebas de datos del Sistema

En este ltimo captulo se realizan las pruebas a cada uno de los mdulos, ya sea
insertando datos, eliminando, consultando e imprimiendo.

5.1 A todos los mdulos

En esta etapa se implementan las herramientas que nos permitirn desarrollar los
elementos grficos del sistema de facturacin.

5.1.1 Sistema de Mens

Se inicia con el diseo de la estructura de men que contendr el acceso a cada
mdulo del sistema, se modelaron varias estructuras pensando en la organizacin ms
frecuente que el usuario puede manejar. Este men quedo de la siguiente manera:

Figura 5.1

Men Sistema

En men sistema comprende de mdulos que permiten manejar de manera global al

sistema los cuales son los de configuracin y usuarios, la figura 5.1 muestra dicho acceso.

81

Figura 5.2

Men Catlogos

En el men catlogos se inician los mdulos que permiten ingresar los primeros
datos con los cuales el sistema podr trabajar ms adelante, estos mdulos son: Clientes,
Contratos, Cobradores, Productos y Servicios; As como tambin los accesos a los mdulos
que generarn los reportes de Clientes, Cobradores, Productos y Servicios, la figura 5.2
muestra el contenido del men.

Figura 5.3 a

82

Men Cuentas por Cobrar con Cancelaciones

Figura 5.3 b

Men Cuentas por Cobrar con Reportes

El men Cuentas por Cobrar contiene la mayor parte de los mdulos principales del
sistema, los cuales le dan la funcionalidad deseada en los anlisis de requerimientos, los
cuales son: Generacin de Cuentas por Cobrar ya sea de manera individual o por grupo de
contratos, asignacin de Cuentas por Cobrar a Cobradores, Aplicacin de pagos, Facturas,
Anticipos, Notas de Crdito. Incluye el acceso a los mdulos de cancelacin de Factura,
Cuenta por Cobrar, Aplicacin de Pagos, Nota de Crdito y Anticipo. As como tambin
sus respectivos reportes de Facturas, Cuentas por Cobrar y Notas de Crdito, la Figura 5.3a
muestra el contenido del men junto con la seccin de cancelaciones y la figura 5.3b
muestra dicho men y su anexo de reportes de Cuentas por Cobrar.
El siguiente paso es generar la barra de botones que dar acceso al usuario a los
mdulos que son utilizados con ms frecuencia, esta barra es una ventana que contiene
botones de accin como los comnmente utilizados para la accin de Aceptar o Cancelar,
solo que en este casos se les activ la propiedad de mostrar un icono sobre ellos, Forms de
Developer Oracle, no incluye la utilidad de barra de herramientas como usualmente se hace
con otros desarrolladores de software como son el Visual Basic de Microsoft entre otros. La
prioridad que tiene Developer es la de manipular grandes cantidades de informacin y por
ello no se especializa en la parte grfica hacia el usuario.
La barra de herramientas generada luce como muestra la siguiente figura 5.4:

Figura 5.4

Barra de herramientas

83

5.1.2 Mdulos
En seguida se generan cada uno de los mdulos que comprendern el sistema de
facturacin, primeramente se hace una consulta de los datos que se van a manejar en cada
uno de dichos mdulos, esto es, se hace un anlisis de requerimientos de cada mdulo
llamado especificacin de mdulo.
En cada especificacin de mdulo se indica la funcionalidad, componentes y diseo
que ser visible al usuario as como las restricciones de datos de cada uno.

Figura 5.5

Mdulo de Catlogo de Clientes

Figura 5.6

84

Mdulo de Catlogo de Contratos

Para utilizar el catlogo de contratos, es necesario que primero se capturen los datos
de los clientes as como un producto por el cual se prestar un servicio. En la figura 5.6 se
muestra dicho catlogo.

Figura 5.7

Mdulo de Catlogo de Cobradores

El catlogo de cobradores se utiliza un sencillo modelo de Maestro detalle.

Figura 5.8

Mdulo de Catlogo de Productos y Servicios

Este catlogo es muy similar en el funcionamiento y diseo que el catlogo de

cobradores.

Figura 5.9

Forma de llamado al reporte de Clientes

85

El reporte de Clientes es llamado a travs de la forma que lleva el mismo nombre, la

funcionalidad de sta es la de capturar los rangos de los clientes que se desean imprimir as
como la de validar dichos rangos de datos, cuando es llamado el reporte se utiliza el
programa Run Reports.

Figura 5.10

Forma de Generacin de cuentas por cobrar

La generacin de las cuentas por cobrar involucra tanto a los contratos, clientes,
productos y clculos que realiza esta forma para almacenar los datos en la tabla de cuentas
por cobrar, detalle de cuentas por cobrar y detalle de contratos, para despus asignarle a los
cobradores dichas cuentas por cobrar.

86

5.1.3 Reportes

Figura 5.11

Reporte de General de Clientes

El reporte general de clientes nos muestra la informacin que se utilizar para la

facturacin del cliente. La figura 5.11 muestra dicho formato.
La figura 5.12 Muestra el formato del reporte de facturas pagadas, ste se puede
imprimir a travs de un rango de facturas, contratos o fecha.

Figura 5.12

Reporte de facturas pagadas

87

En la figura 5.13 se muestra el diseo del reporte de cartera vencida a una

determinada fecha y cliente.

Figura 5.13

Reporte de cartera vencida

En la figura 5.14, muestra el diseo del reporte de facturas cobradas por cobrador,
para mostrar este reporte es necesario dar un rango de fecha y cobrador

Figura 5.14

88

Reporte de facturas cobradas por cobrador

La figura 5.15 muestra el reporte general de facturas no pagadas, para ejecutar este
reporte es necesario indicar la fecha lmite a la cual se desea saber que personas deben
dicho servicio.

Figura 5.15

Reporte general de facturas no pagadas por cliente

89

CONCLUSIN
Actualmente el sistema cumple con diferentes funciones propuestas al inicio, se
pueden ingresar todos los datos solicitados con sus respectivas validaciones, puede tambin
mostrar diferentes reportes y por supuesto generar todo el proceso de facturacin que va
desde la generacin de cuentas por cobrar, asignacin de notas de crdito y generacin de
facturas, estos son los puntos ms importantes que debe de realizar el sistema y actualmente
los lleva a cabo.
Para la implementacin del sistema en el equipo del cliente es necesario realizar una
migracin de datos que parte del sistema de Access a Oracle. Para ello es necesario anexar
diferentes columnas a las que se tienen, se debe de dividir informacin que se tena en una
sola tabla en diferentes debido al nuevo anlisis que se present para el proyecto. Una vez
hecha la estructuracin de los datos en tablas de Excel, se procede a generar los Scripts para
que en la ventana de Oracle PL/SQL sean ingresados a la base de datos.
El anlisis hecho en este trabajo fue implementado con xito, dando como respuesta
que el sistema realiza adecuadamente el proceso de facturacin as como el buen
funcionamiento de los mdulos.
El anlisis y diseo de Base de Datos tiene la estructura adecuada para soportar los
datos que la empresa solicita, adems de poder almacenar gran cantidad de informacin
para darle larga durabilidad y soporte al sistema.
El utilizar el manejador de Base de Datos Oracle me ayud a entender y manejar
diversas herramientas que me son muy tiles para el medio en el que me desarrollo, el
manejo de las herramientas de desarrollo Oracle me da una perspectiva mas amplia de lo
que es el concepto del manejo de las Bases de Datos, que tienen infinidad de aplicaciones y
que el manejo de informacin, con la ayuda de Oracle, es a grandes escalas tanto en el rea
privada como de investigacin.

90

PERSPECTIVAS
El sistema se encuentra en la posibilidad de podrsele agregar otras funciones o
aplicar nuevos requerimientos, el sistema fue diseado para implementarse solo en un
equipo, sin embargo se puede implementar en una red de tipo LAN sin ninguna
modificacin al sistema o a la Base de Datos.
El realizar que la informacin del sistema de facturacin sea consultada a travs
de Internet no es un requerimiento que necesite demasiado anlisis y modificacin de los
mdulos actuales, la herramienta de desarrollo Developer de Oracle tiene una
herramienta para migrar la estructura de las formas y reportes hechos en Developer 6i a
otra ms actual que es la versin 9i-AS que trabaja sobre la plataforma Java que es muy
portable a cualquier sistema operativo a travs de los navegadores WEB. Para hacer
dicha migracin no existira la necesidad de hacer cambios en la estructura de la Base de
Datos.
El sistema actual puede ser utilizado para cualquier otra empresa que se dedique
a dar cualquier tipo de servicio o venta de productos, de hecho, se puede aplicar en una
empresa que de el servicio de vender sus productos servicios a crdito, esto es debido
a que el sistema maneja mdulos de cuentas por cobrar que se puede acoplar con
facilidad.

91

BIBLIOGRAFA

[PrR93]

Roger S. Pressman, Ingeniera del Software, Mc. Graw Hill, Tercera

Edicin, 1993

[HaI94]

I. T. Hawryszkiewycz, Anlisis y diseo de bases de datos, Megabyte

Noriega editores, Primera edicin, 1994

[ByS98]

Byron S. Gottfried, Programacin en Pascal serie Schaum, Mc Graw

Hill, 1998

[OrR98]

Orfali Robert Harkey Dan y Edwards Jeri, Cliente/Servidor Gua de

Supervivencia, McGraw Hill Mxico, 1998

[KaK+97]

Karlapalem K., Ng Moon Pun, Query-Driven Data Allocation

Algorithms for Distributed Database Systems DEXA 1997

[KoH+94]

Henry F. Korth / Abraham Silberschatz, Fundamentos de Base de

Datos, Mc Graw-Hill, 1994

[DaC01]

C.J Date, Introduccin a los Sistemas de Base de Datos, Prentice Hall,

Sptima edicin, 2001

[BrM+84]

M. L. Brodie, J. Mylopoulos & J. W. Schmidt, "On the Development of

Data Models", 1984

[DaC91]

C. J. Date, "Dont Encode Information into Primary Keys!", en

Relational Database Writings, Reading, Mass: Addison-Wesley
Publishing, 1991

[MoP96]

Piroz Mohseni, Web Database Primer Plus, Waite Group Press, 1996

[JaM97]

James Martin, James J. Odell, Object-Oriented Methods A

Foundation, Prentice Hall, 1997

[BrE91]

Bruce Eckel, Aplique C++, Mc Graw Hill, 1991

[PuL97]

Lee Purcell, Mary Jane Mara, The ABCs of Java Script, Sybex, 1997

[LoK02]

Kevin Loney, Marlene Theriault, Oracle 9i Manual del administrador,

tcnicas de gestin de bases de datos Oracle robustas y de alto
rendimiento, Oracle Press - Mc Graw Hill Osborne, 2002

92

[PeC03]
[PKo+00]

Csar Prez, Oracle 9i Administracin y anlisis de Bases de Datos,

Alfaomega Ra-Ma, 2003
Peter Koletzke, Dr. Paul Dorsey, Oracle Developer, Manual avanzado
de Forms y Reports, Oracle Press Osborne Mc Graw Hill, 2000

http://www.oracle.com
http://otn.oracle.com

93