Utilización de herramientas CASE para el modelado e ingeniería inversa de bases de datos.
Mg. René
Arturo Angulo.
|
Utilización
para herramientas CASE para el modelado e ingeniería inversa de bases de
datos.
|
|
Facultad de
Ingeniería.
|
Índice.
1. Introducción............................................................................. 3
2. Antecedentes.......................................................................... 4
3. Investigación
Bibliográfica....................................................... 5
4. Herramienta
CASE: PowerDesigner........................................ 11
5. Desarrollo
de caso práctico de aplicación de conceptos........ 16
Introducción.
Las bases de datos, son un conjunto de registros, que relacionados entre sí, guardan en detalle toda la información organizacional, es importante entender como este concepto a lo largo de la historia ha venido fortaleciendo, y en dicho proceso ha venido complicando a las organizaciones. Este concepto que surgió en los años 60, se ha visto beneficiado en su inicio en el incremento y posterior abaratamiento, de los medios de almacenamiento, es en estos medios en donde residen finalmente los datos.
El desarrollo de la tecnología de las bases
de datos, se inicio con un articulo presentado por el científico informático
Ingles Edgar Frank Codd,(“Un
modelo relacional de datos para grandes bancos de datos compartidos" ("A RelationalModel of Data
forLargeShared Data Banks")) en el cual se presento los fundamentos
sobre los cuales se construyeron bases de datos como ORACLE. La teoría de Codd,
marcaba que la base de datos, podía entenderse más bien como un conjunto de
relaciones, en donde los datos se organizaban o estructuraban.
En la actualidad, este concepto ha evolucionado
grandemente, llegando a generar nuevas teorías, y sustentando nuevas hipótesis,
las cuales inciden directamente en el corazón de la toma de decisiones: los
datos. Al crecer las empresas, tanto en tiempo (sistemas que tienen más de 10
años en producción), físicamente (originalmente tenían dos tiendas o sucursales
y después de 10 años tiene más de treinta o cuarenta.), han generado que datos,
que presentan en actualidad, retos sobre el rendimiento, así como velocidades
en las transacciones I/O, empresas como ORACLE, ya están ofreciendo
alternativas de implementación de priorización de datos, la cual permite
segmentar la capa de datos para optimizar rendimientos y lecturas de
información.
Estos nuevos retos, nos hacen buscar
especialización en el diseño y modelado de la base de datos, así como también,
en la decisión sobre herramientas que nos ofrezcan ayuda, y que al menos en
alguna parte del proceso pueda de manera eficiente darnos retroalimentación de
la fase del modelado, y poder regresar de lo implementado, nuevamente a lo
modelado y viceversa.
Antecedentes.
Desarrollo de Sistemas.
Dentro del proceso de desarrollo de
aplicaciones, y considerando el Ciclo de vida clásico, RUP u otra estrategia de
desarrollo que utilicemos para eficientizar esta etapa, siempre existe una parte
que corresponde al modelado, ya sea del sistema o de la base de datos.
Convencionalmente en la parte de desarrollo y el modelado compete solamente al
programados, desarrollar la solución informática (software o sistema), no así
la parte del modelado de la base de datos, esta responsabilidad es pasada por
lo general (en empresas que lo poseen) a un DBA (Data Base Administrator), que
en conjunto con los usuarios y los programadores realiza un proceso que
mediante los requerimientos del sistema, desarrolla toda las estructura en
donde se sustentara la información que los sistemas transaccionales tendrán. Sin
embargo dentro de nuestra realidad Salvadoreña, y considerando elementos
formativos, de autoempleo etc. El modelado de la base de datos es también parte
integral delas funciones de una persona única que Recopila, Analiza, define,
modela, diseña, desarrolla. Implementa y da seguimientos. Aun cuando no sea
esta la situación, es importante que en función de comprender como se modela la
base de datos y que impactos puedan tener las decisiones tomadas en esta etapa,
se tengan claros los procesos que se realizar y herramientas que en función de
la tecnología, puedan abonar a reducir los tiempos de respuesta de los usuarios
finales.
Uso de Herramientas CASE.
Es importante comprendes que la fase de
requerimientos, es siempre la que da los insumos necesarios para poder modelar
la base de datos. El proceso de modelado, en el desarrollo de sistema,
constituye un reto muy grande, debido a que además del modelado lleva la
implementación en diferentes RDBMS ( por sus siglas en inglés RelationalDataBaseManagamentSystem),
y que sin el uso de Software Asistido, se tornaría una actividad titánica el
desarrollarla; es importante por tanto, comprender los alcances que estas
herramientas CASE (por sus siglas en
inglés:ComputerAided Software Engineer) tiene, para poder determinar lo que
tiene que hacerse en cada una de las opciones que dicha herramienta ofrezca
Comprensión de la teoría y su punto
intermedio con la práctica.
Es importante lograr comprender los elementos
que equilibran el concepto de teoría – práctica, ya que en función de cada uno
de ellos se podrá ser productivo en un mundo
globalizado y sistemáticamente exigente de resultados. Para ello, este
documento pretende ejemplificar algunos criterios sobre elementos en los cuales
la práctica se sobre pone a la teoría, en función de incorporar elementos de
valor agregado o eficientizar procesos o reportes.
Investigación Bibliográfica.
Conceptos.
De los conceptos
desarrollas a continuación, los cuales se basan en el algebra y el cálculo
relación comprenderemos otros concepto como tupla, relación y atributo que utilizaremos más adelante. Todo atributo
en una tabla tiene un dominio, el cual representa el conjunto de valores que este
puede tomar. Una instancia de una tabla puede verse entonces como un
subconjunto del producto cartesiano entre los dominios de los atributos. Sin
embargo algunos RDBMS permiten filas duplicadas, entre otras cosas.
Una tupla puede
razonarse matemáticamente como un elemento del producto cartesiano entre los
dominios. De lo cual, podemos concluir, que toda relación tiene Dependencias.
Dependencias.
·Aumentatividad: Si x !y, x' ! y "x' " x
Ejemplo: S# !NomS
S#, Ciudad !NomS
· Proyectividad: Si x ! y, x ! y' "y' " y
Ejemplo: S# !NomS, Estado, Ciudad
S# !NomS
S# ! Estado
S# ! Ciudad
·Adictividad: Si x !y, u !w ! xvu ! yuw
· Transitividad: Si x ! y, y ! z ! x ! z
Normalización.
Es el proceso mediante el cual el proceso de modelado de la base de
datos, garantiza que las estructuras implementadas tengan identificadores
únicos, no tengan redundancia de datos, se mejora el desempeño de las
transacciones, se garantiza la fiabilidad de los datos, etc. Es E. Codd quien propone este proceso y
posteriormente fue ampliado por los autores R. Fagin, C. Delobel y C. Zaniolo.
El proceso que comprende la normalización, está constituido por seis
etapas, llamadas formas normales (ver figura 1).
El proceso de normalización pretende garantizar que la estructura
diseñada para la minimización de los problemas relacionales que existen
inherentes a las bases de datos. Este proceso, permite además de los aspectos
técnicos antes mencionados, tener la claridad de una arquitectura, la
normalización si bien es cierto es un proceso matemático simple, permite
claramente sustenta los sistemas transaccionales, pilar fundamental de otros
tipos de bases de datos orientadas a la toma de decisiones. La normalización
basa sus formas normales,
Antes de definir el proceso de normalización, deberemos comprender
algunos elementos esencialmente básicos para poder continuar:
a) Tupla. En matemática, se define como la secuencia ordenada de objetos,
convencionalmente se le relaciona con el concepto de registro, sin embargo
diferenciaremos estos dos conceptos utilizando el primero (Tupla) como el
nombre conceptual y el segundo (registro) como la implementación informática
dentro de una base de datos.
b) Atributo. Es una propiedad que describe un hecho de la vida real, y que
pertenece a una entidad. Es el nombre lógico que se da a la implementación de
las columnas o campos.
c) Entidad.Es la agrupación de atributos, que por sus características se
agrupan en una entidad. Es el nombre lógico que se da alas tablas de las bases
de datos. Los nombres de las entidades no deben de asignarse en plural, ya que
ellos mismos representan conjuntos de datos.
d) Llave. Es un atributo o conjunto de
atributos especiales, que representan de forma única a la Entidad.
e) Integridad de los esquemas
relacionales.
a. Integridad de la clave: Ningún valor que forme parte de la clave (en el caso de existir
llaves primarias o llaves compuestas), podrá contener el valor nulo.
b. Integridad de referencia.Es la propiedad de las bases de datos relaciones que garantiza que
dos entidades relacionadas entre sí por medio de llaves foranes sostengan los
datos no nulos de una entidad con respecto a otra.
f) Teoría de las
dependencias. Las dependencias son propiedades o
muy características de los datos, dentro de las dependencias existen varios
tipos: las funcionales, las
multivaluadas las jerárquicas y las de combinación. Las más restrictivas de
todas son las dependencias funcionales, las cuales sustentan al proceso de
normalización.
g) Dependencias funcionales. Son la base que sustenta el proceso de normalización, dentro de las
teorías de las dependencias son las mas restrictivas. Las dependencias pueden
ser :
a. Reflexivas. Esta teoría considera que todo conjunto de atributos de una
relación funcionalmente dependiente de sí mismo y de cualquier de sus posibles
agregados.
b. Aumento.
c. Transitiva.
d. Unión.
e. Pseudo-transitiva.
f.
Descomposición.
Formas Normales.
Se le llama formas normales, al proceso en realidad de la
normalización de las estructuras de bases de datos. El proceso garantiza que la
estructura desarrollada sea eficiente desde el punto de vista transaccional y
de consumo de espacio en disco duro.
|
|
|
Primera forma normal
|
|
Tercera forma normal
|
|
Cuarta forma normal
|
|
Segunda forma normal
|
|
Tercera forma normal. Boyce-Codd
|
|
Quinta forma normal
|
Figura 1.Forma gráfica del
proceso de normalización.
Aplicación de las formas normales.
Primera forma normal. (1FN)
Una relación, se
dice que está en primera forma normal, si y solo si, el conjunto de atributos
son diferentes, y cada uno de los mismos son componentes atómicos.
Por ejemplo, la
siguiente tabla de control de pagos :
Se deben, por tanto establecer el conjunto de atributos que hacen
que las tuplas se repitan, para este ejemplo pago, Fecha de Pago 1, pago Fecha
de pago 2, etc.; atributos que corresponde al detalle de los pagos realizados a
los empleados. Al aplicarse la 1FN, la tabla quedaría de la siguiente forma:
Segunda forma normal. (2FN)
El primer requisito de la segunda forma normal, es que este aplicada
la primera forma normal. Luego de cumplido ese criterio, se debe determinar que
todos los atributos de la tabla deberán estar asociados a la llave primaria de
la misma. Continuando con el ejemplo, el campo departamento, es un campo que en
realidad esta referenciado y es un atributo de, posiblemente, por lo cual al
aplicar la 2FN, quedaría de la siguiente manera:
Tercera forma Normal.
(3FN)
Se dice que una relación esta en tercera forma normal, si y solo si
cumple estar en segunda forma normal y que cada atributo no depende
funcionalmente de forma transitiva de la
clave primaria de la relación. Es el caso del campo, fecha de cumpleaños, el
cual depende funcionalmente de la llave primaria de empleado, no así
directamente de la estructura de pagos, es decir, que dentro de la estructura
no deben existir dependencias entre los atributos que no forman parte de la
clave primaria de la relación.
Ingeniería Inversa.
Se definecomo ingeniería inversa, al proceso sobre el cual se obtiene
información o un diseño a partir de un producto terminado y funcional, con el
objetivo de poder establecer como fue concebido. Este concepto, se puede aplicar a múltiples
áreas programación, bases de datos, productos, componentes electrónicos, para
el presente estudio es importante poder definir que se prestara principal
atención a la ingeniería inversa que se le realiza a las bases de datos, la
cual permite extraer información de la estructura (diccionario de datos) de la
base en análisis. Es para ello, que se utilizan herramientas CASE, que son las
que ciertamente hacen la diferencia.
Herramientas CASE.
Las herramientas CASE, son programas de computadoras, con la
principal funcionalidad de servir como herramientas para el análisis de
programas, bases de datos, etc. de forma que por medio de un interfaz con
características amigables hacia el usuario (en este caso el usuario no es
considerado como un usuario final, sino mas bien como un usuario con solidos
conocimientos de la base de datos a realizarle la ingeniería inversa). Como
herramienta de análisis se ha seleccionado PowerDesigner, esto es en base a la
experiencia en su manejo por parte del investigador.
PowerDesigner.
Es una herramienta para realizar el modelamiento de los datos, esta
herramienta, al igual que otras, se utiliza para visualizar, analizar y
manipular los metadatos de la base de datos. En general esta herramienta no
solo modela bases de datos, trabaja también, con lenguajes de programación
(UML) como .NET, Java, powerbuilder,C++, c# entre otros. Como una de los
valores agregados, se va a desarrollar en un apartado especial, la funcionalidad
de esta herramienta.
Herramienta CASE: PowerDesigner.
Según el sitio web, definen los siguientes elementos importantes de
la herramienta:
Características Principales:
- Perfiles
de usuario que le ayudan a estandarizar la percepción de
sus modelos y el soporte de estándares en la organización.
- Matrices
de dependencia (disponibles en todos los módulos) que le
ayudan a visualizar y editar vínculos entre diferentes tipos de objetos,
aún si están en diferentes tipos de modelos.
- Preferencias
de visualización que le permiten
personalizar las preferencias de visualización para objetos extendidos y
para objetos del nuevo Modela de Arquitectura Empresarial (EAM). Usted
puede ver cualquiera de sus atributos o colecciones en el orden en que los
requiera.
Técnicas de Modelamiento
- Modelamiento
de Negocio – BPM con vínculos a simulación con soporte
BPMN.
- Modelamiento
de Datos – Modelamiento de datos multi-nivel
conceptual, lógico, físico y para bodegas de datos con soporte a técnicas
modernas como Java, XML y servicios Web en la base de datos con notación
IE y IDEF1/x.
- Modelamiento
XML – Un paradigma físico único con soporte a XML
DTD y artefactos de esquema.
- Modelamiento
de Objetos – Modelamiento UML 1.x y 2.0, altamente
extendible.
- Modelamiento
ETL, EII y de Replicación – Permite documentar todas
las etapas del movimiento de datos para cualquier estrategia implementada.
- Modelamiento
Empresarial – Poderosa tecnología “Link &Sync” para
un poderoso manejo de metadatos y un completo análisis de impacto a nivel
de proyecto y de empresa.
Repositorio Empresarial
- Solución
de Equipos – Permite que múltiples modeladores trabajen
sobre el mismo modelo, al mismo tiempo.
- Gestión
de Metadatos – Permite almacenar, manejar y versionar
modelos PowerDesigner y otros documentos en una única ubicación.
- Análisis
de Impacto entre Modelos – Permite almacenar y
mantener dependencias entre modelos para un completo análisis de impacto
en la empresa.
- Gestión
de Recursos de Software – Encuentre y reutilice
objetos entre todos los modelos y proyectos.
- Seguro –
Seguridad basada en roles con capacidades de trazabilidad y un completo
conjunto de permisos que limitan el acceso y la visibilidad a modelos y
sub-modelos.
- Open –
Tablas almacenadas en RDBMS, completamente documentadas para generación de
reportes basados en SQL.
Proyectos y Matrices de Infraestructura
- Proyectos –
Proveen un ambiente conveniente para trabajar con múltiples modelos
interconectados y otros archivos.
- Plantillas –
Pueden contener modelos, contenido, reglas y formatos predefinidos para
ser reutilizados. Las plantillas son usadas para soportar arquitectura
empresarial y otras infraestructuras que requieren una cierta combinación
de modelos. Comenzar con plantillas apropiadas le ayuda a iniciarse
rápidamente con el desarrollo basado en estándares.
- Matrices
de infraestructura – Le ayudan a dirigir su
proceso de modelamiento brindando una grilla en la que cada celda debe ser
completada de acuerdo a un conjunto predefinido de acciones. PowerDesigner
brinda una matriz de infraestructura predefinida para la infraestructura
FEAF, además de un ambiente de edición de infraestructuras fácil de usar
que le permite crear y personalizar las propias.
Plataformas Soportadas
- Ejecución
de Procesos – Soporte a BPMN, ebXML, BPEL4WS y SOA.
- RDBMS –
Reingeniería completa para más de 60 RDBMS, incluyendo las últimas
versiones de Oracle, IBM DB/2, Microsoft SQL Server, Sybase, MySQL, NCR
Teradata y muchas más.
- Lenguajes
de Objeto – Reingeniería completa para Java J2EE, C#,
VB.NET, PowerBuilder, XML, C++, Web Services y más.
- Integración
con el Desarrollo – Plug-ins para Eclipse,
PowerBuilder y Visual Studio, con sincronización entre modelo / código.
Otras Características y Beneficios
- Tecnología
“Link &Sync”, que crear mayor alineamiento entre el negocio y el área
de tecnología.
- Logre
mayor agilidad del negocio a través de los sistemas de tecnología de
información, con análisis de impacto y gestión de cambio.
- Visualice,
documente y reporte, de manera fácil y exacta, el impacto antes de hacer
cambios en producción.
- Describa
visualmente una Arquitectura Empresarial con el nuevo modelo de
Arquitectura Empresarial.
- Usando
el Diagrama de Análisis de Impacto, fácilmente visualice el impacto y las
dependencias.
- Soporte
altamente personalizable para estándares propios o infraestructuras EA
estándares (DoDaf, Zachman).
- A
través del “Repository Web Viewer”, comparta metadatos EA con todos los
“stakeholders”, independientemente de sus habilidades técnicas.
- Arquitectura
Orientada a Servicios – Orquestación de servicios a nivel de negocio y
técnico.
- Gestión
de requerimientos que provee análisis detallado, encadenando todos los
modelos, para trazabilidad. La importación y sincronización con MS Word
pone a los usuarios directamente en el ciclo de vida de análisis y diseño.
De lo anterior podemos concluir algunos elementos importantes:
1. En base a la evolución de la herramienta (desde que estaba integrada
con PowerBuilder) su campo de aplicación es extremadamente amplio.
2. Engloba varias áreas de trabajo dentro del que hacer del desarrollo,
gestión, y supervisión de las áreas de TI.
3.
El ámbito de estudio de este
documento será lo que al modelado de las bases de datos corresponde.
Proceso de creación de un Diagrama ER con PowerDeginer. (Video con otro ejemplo de uso de la herramienta CASE y aplicación practica de la normalización. PowerDesginer )
Figura 1. Opciones de inicio de PowerDesigner.
En el proceso de selección de la herramienta, es importante elegir
sobre que notación se va a trabajar, es por ello que esta herramienta permite
desarrollar las siguientes notaciones:
·
Barker.
·
Merise.
·
Entity/Relationship.
·
E/R + Merise.
·
IDEF1X.
Notaciones que
PowerDesigner ofrece.
Las notaciones, dentro de este contexto especifican la estructura
gráfica que se va a utilizar, es decir al conjunto de grafos y representaciones
visuales de cada símbolo. Este conjunto de símbolos no altera la
conceptualización de los diagramas ER, sino más bien pretenden enriquecer la
forma en como entendemos las estructuras y relaciones de las bases de datos con
una forma particular de entendimiento. Bajo este contexto, PowerDesigner tiene
las siguientes notaciones:
1. Notación Barker.
2. Notación Merise.
3. Notación Entity/Relationship.
4. Notación E/R + Merise.
5.
Notación IDEF1X.
Notación Barker.
Esta notación fue desarrollada por Richard Barker, Ian Palmer, Harry
Ellis et al. Mientras trabajaba en la firma consultora británica CACI en torno
a 1981. La notación fue adoptada por Barker cuando se unió a ORACLE. A esta
notación se le conoce como una variante de la "pata de cuervos”.
NotacionMerise.
En esta Notación se modela la vista de datos en tres etapas - desde
conceptual (en el cual se definen las relaciones sin considerar constraints) y
lógico (en donde los constraints son adicionados como parte de los modelos),
hasta la física (En donde se considera el modelo lógico y las partes semánticas
de los SQL (SQL Server, MySQL, ORACLE, etc.) y sus diferentes particularidades).
Similarly, the process-oriented view passes
through the three stages of conceptual, organizational and operational.
Notación
Entity/Relationship.
La notaciónEntity/Relationship,
es la forma abstracta para describir la estructura de una base de datos . En powerdesigner, es una
notación por si misma, y es diagramada o conocida como de “pata de cuervo”,
porque la figura que representa la notación en la relación de muchos asemeja
una pata de una ave.
Notación E/R + Merise.
Es la combinación de la
notaciónEntity/Relationship y la Notación Merise.
Notación IDEF1X.
En la notación IDEF1X,
las relaciones son asimétricas es decir que existen símbolos diferentes para opcionalidad y para
cada cardinalidad de la relación. Unlike the other
notations, symbols cannot be parsed in terms of optionality and cardinality
independently. A diferencia de las otras anotaciones, los símbolos no se
pueden analizar en términos de opcionalidad y cardinalidad de forma
independiente. Each set of symbols describes a combination
of the optionality and cardinality of the entity next to it. Cada
conjunto de símbolos describe una combinación de la opcionalidad y
cardinalidad de la entidad a su lado.
Cada una de las
notaciones, antes mencionadas reflejan una forma de expresar la estructura de
los datos, en el trasfondo de las
notaciones; lo importante es seleccionar una
notación, que, dentro de la empresa se pueda reflejar de forma clara como
se relacionan las estructuras de datos, y como, de forma sencilla se pueda
cambiar la notación que represente dichas realidades.
Cardinalidad:
La cardinalidad es un
concepto que se aplica a las relaciones entre las tablas, y una cardinalidad se
representa mediante una etiqueta en el exterior de una relación, en
PowerDesigner las cardinalidades son:
1.
One – One.
2.
One – Many.
3.
Many – One.
4.
Many – Many.
El “rol name” dentro de PowerDesigner se utiliza para establecer si
la cardinalidad es obligatoria en cualquiera de las dos vías de las tablas en
relacionarse.
Algunos ejemplos de
cardinalidad son los siguientes:
Una factura (entidad)
se emite (relación) a una persona (entidad) y sólo una, pero una persona puede
tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre
de alguien.
Un cliente (entidad)
puede comprar (relación) varios productos (entidad) y un producto puede ser
comprado por varios clientes distintos.
Desarrollo de caso práctico de aplicación de conceptos.
Caso de estudio: Sistema
de facturación.
Una organización de venta de artículos de retail, está desarrollando
un sistema de facturación, que permita poder realizar facturas de consumidor
final y créditos fiscales; dentro del sistema se requiere poder registrar
ingresos de inventarios, los ingresos de inventarios son en unidades de
facturación, y la existencia final se calcula sumando los ingresos a inventarios
y restando las facturas emitidas en un periodo de tiempo determinado. Las
facturas que se emiten dentro del sistema deberán de llevar un control de
usuarios que han modificado la factura y
sus respectivos detalles así como también un detalle de la última fecha en que
se ha registrado el inventario dentro del sistema. Dentro de los procesos, se
han definido que las facturas solamente serán emitidas desde la tienda y
solamente se emitirán facturas desde la tienda misma, lo que significa que una
tienda no podrá emitir facturas de otras tiendas. Para facilidad de análisis
cada una de las tiendas tiene una bodega asociada sobre la cual se generan las
facturas. Al final de un día de trabajo en el sistema, se deberá generar la
información de todos los productos facturados en un rango de fechas, con IVA y
sin IVA. Cada una de las facturas será emitida a un cliente, sobre los clientes
se solicita, llevar un registro de los nombres completos, direcciones, al menos
dos teléfonos de contacto, un nombre de una persona de contacto, numero de NIT
de la empresa (en caso de ser una persona natural se debe de guardar el numero
de DUI). En general cuando una factura es emitida, se le da al crédito al
cliente, de tal forma que cada uno de los clientes posee un saldo propio de
cuentas por pagar a la empresa emisora de la factura; los saldos de los
clientes se ven disminuidos cuando se liquida las facturas por medio de notas
de pagos(para el diseño original no se requiere el control de pagos, mas si
considerar el registro de saldos de los clientes y las facturas, ya que en el
momento de generar la factura, se pueden realizar abonos parciales siempre y
cuando estos abonos se realicen a una factura). En el sistema se pueden
registrar descuentos, ya sea a nivel porcentual o por un monto, y estos
descuentos se aplican o bien por productos o bien al total de la factura.
Dentro del sistema, otro elemento importante a considerar como parte de los
requisitos funcionales, es el hecho de controlar los precios de los artículos,
cada uno de los precios registrados en el sistema, debe estar registrado en una
lista de precios vigente, cada una de las listas vigentes tiene una fecha de
inicio, una fecha final en la que se especifica si la lista de precios esta o
no vigente, cada uno de los artículos en venta estará asociado a una lista de
precios. Dentro de todo el sistema de facturación se debe desarrollar otros
aspectos importantes que en las generalidades del sistema, deberá ser el
garante del mismo; por ejemplo, se tiene que tener un control de los límites de
crédito, anulación de las facturas, generación de devoluciones en base a una
factura previamente creada.
Caso de Estudio: Sistema de Facturación.
A continuación se presentan los campos que, en función de los
requerimientos se detectan:
6. Nombre del cliente
7. DUI del cliente.
8. NIT del cliente.
9. Dirección del cliente.
10. Números de teléfonos del cliente.
11. Fecha de la factura.
12. Usuario de creación de la factura
13. Fecha de creación de la factura.
14. Usuario que modifica la factura.
15. Fecha en que se modifica la factura.
16. Nombre de Bodega de facturación.
17. IVA.
18. Nombre del contacto del cliente.
19. Cliente NATURAL o EMPRESA.
20. Crédito fiscal o factura.
21. Saldo de cliente.
22. Saldo de la factura.
23. Producto facturado.
24. Cantidad de productos facturado.
25. Descuentos en dinero sobre los productos facturados.
26. Descuento en % sobre el producto facturados
27. Descuento en monto aplicado a la factura.
28. Descuento en % aplicado a la factura.
29. Descripción de la lista de precios.
30. Fecha de inicio del precio
31. Fecha de finalización del precio.
32. Estado de la lista de precios.
33. Limite de crédito del cliente.
34. Factura Anulada.
35.
Tipo de documento. (el tipo de
documento representa si es Factura o es una devolución).
Al detalle de requerimientos, en el listado anterior, le aplicamos el
proceso de normalización, de lo que, al verificar la 1FN, podemos observar que
están en 1FN. Al verificar la 2FN, tenemos el siguiente listado:
CLIENTE.
1. Nombre del cliente.
2. DUI del cliente.
3. NIT del cliente.
4. Dirección del cliente.
5. Tipo de Cliente (Natural o empresa).
6. Saldo del cliente.
7. Limite de Crédito.
8. Nombre del contacto del cliente.
FACTURA.
1. Fecha de factura.
2. Saldo de la factura.
3. Producto facturado.
4. Cantidad de productos facturados.
5. Descuento en dinero de los productos facturados.
6. Descuento en % de los productos facturados.
7. Descuento en monto aplicado a la factura.
8. Descuento en % aplicado a la factura.
9. IVA.
10. Nombre de Bodega de facturación.
11. Usuario de creación de la factura.
12. Usuario de modificación de la factura.
13. Fecha de creación de la factura.
14. Fecha de modificación de la factura.
15. Estado de la factura.
16. Tipo de documento.
17. Tipo de factura emitida factura o crédito fiscal.
PRECIOS.
1. Descripción de la lista de precios.
2. Fecha de inicio de la lista de precios.
3. Fecha de finalización de la lista de precios.
4. Estado de la lista de precios.
5. Detalle de productos asociados a la lista de precios.
Con este último detalle de nombre de campos a considerar, se debe de
realizar un nuevo análisis, ya que como
se puede ver en el ejercicio, existe la estructura FACTURA no se percibe la
1FN; esta conclusión se llega a tener, ya que producto factura no es atómico
para FACTURA, es decir, que dentro de una factura pueden generarse varios
productos que se facturen, así también Cantidad, descuento en monto aplicado al
producto, descuento en % aplicado al producto, por lo cual y al aplicar la 1FN,
el mismo criterio aplica para Bodegapor lo que dicha estructura queda de la
forma siguiente:
FACTURA.
18. Fecha de factura.
19. Estado de la factura.
20. Tipo de documento.
21. Saldo de la factura.
22. Descuento en monto aplicado a la factura.
23. Descuento en % aplicado a la factura.
24. IVA.
25. Nombre de Bodega de facturación.
26. Usuario de creación de la factura.
27. Usuario de modificación de la factura.
28. Fecha de creación de la factura.
29. Fecha de modificación de la factura.
30. Tipo de factura emitida factura o crédito fiscal.
FACTURA DETALLE.
31. Producto facturado.
32. Cantidad de productos facturados.
33. Descuento en dinero de los productos facturados.
34. Descuento en % de los productos facturados.
BODEGA.
1.
Nombre de la bodega de
facturación.
Otra tabla que debe ser parte de un análisis especial es la de
PRECIOS, la cual en conclusión lógica, cada PRECIO, contendrá asociado un
artículo y un precio para cada uno; por lo que, esta relación se convierte en
dos estructuras quedando de la siguiente forma:
PRECIO.
5. Descripción del precio.
6. Fecha de inicio.
7. Fecha de Finalización.
PRECIO DETALLE.
1. Producto.
2.
Precio unitario.
Para concluir con la aplicación de la 2FN, debe de considerarse que
todos los atributos deben estar relacionados a la llave primaria, por lo que hay que determinar que atributos
son llaves primarias de las estructuras:
ESTRUCTURA
|
LLAVE
|
RAZONAMIENTO
|
FACTURA
|
DOCUMENTO
|
El numero de la FACTURA, es un numero que en general puede
identificar de manera única a la
estructura FACTURA, sin embargo es importante leer que en los requerimientos
se ha considerado registrar también dentro de esta tabla (Una decisión que
afecta el diseño y que por tanto cambia la conceptualización del resultado, )
|
FACTURA DETALLE
|
LINEA DETALLE
|
En esta caso, no existe un campo e los listados que represente de
forma única a la estructura, por lo que se crea un llave temporal, se vera
mas adelante esta decisión ya que el concepto puede cambiar. A este tipo de
llave se le conoce como llaves artificiales.
|
CLIENTE
|
CODIGO CLIENTE
|
En este caso existen dos campos que pueden describir de forma
única a la tabla NIT y DUI, sin embargo pueden existir casos en los cuales no
exista el NIT o no exista el DUI o ambos
|
BODEGA
|
BODEGA
|
Se ha decidido crear el campo BODEGA, como llave primaria ya que,
hasta este punto de análisis.
|
PRECIOS
|
PRECIO
|
Se ha creado el campo PRECIO para identificar de forma única a la
tabla.
|
PRECIO DETALLE
|
LINEA PRECIO
|
El análisis es similar a la FACTURA DETALLE, este análisis será
retomado mas adelante en el documento.
|
PRODUCTO
|
PRODUCTO
|
Tabla que contiene los datos generales de los productos, en este
sentido no se pretende desarrollar conversiones de productos, se presume que
las unidades de ingreso son las mismas unidades de venta
|
Con estos análisis desarrollados, hemos aplicado la 3FN, con lo cual
los cambios en la tabla anterior, las estructuras quedan de la siguiente forma:
CLIENTE.
1. CODIGO CLIENTE
2. Nombre del cliente.
3. DUI del cliente.
4. NIT del cliente.
5. Dirección del cliente.
6. Tipo de Cliente (Natural o empresa).
7. Saldo del cliente.
8. Limite de Crédito.
9. Nombre del contacto del cliente.
10.
Tipo de factura emitida: factura
o crédito fiscal.
PRECIOS.
1. PRECIO.
2. Descripción de la lista de precios.
3. Fecha de inicio de la lista de precios.
4. Fecha de finalización de la lista de precios.
5. Estado de la lista de precios.
6. Detalle de productos asociados a la lista de precios.
FACTURA.
1.
DOCUMENTO
2.
Fecha de factura.
3.
Estado de la factura.
4.
Tipo de documento.
5.
Saldo de la factura.
6.
Descuento en monto aplicado a
la factura.
7.
Descuento en % aplicado a la
factura.
8.
IVA.
9.
Usuario de creación de la
factura.
10.
Usuario de modificación de la
factura.
11.
Fecha de creación de la
factura.
12.
Fecha de modificación de la
factura.
13.
Tipo de factura emitida factura
o crédito fiscal.
FACTURA DETALLE.
1.
LINEA DETALLE
2.
Producto facturado.
3.
Cantidad de productos
facturados.
4.
Descuento en dinero de los
productos facturados.
5.
Descuento en % de los productos
facturados.
BODEGA.
1. BODEGA.
2. Nombre de la bodega de facturación.
PRECIO.
1. PRECIO.
2. Descripción del precio.
3. Fecha de inicio.
4. Fecha de Finalización.
PRECIO DETALLE.
1. LINEA PRECIO
2. Producto.
3. Precio unitario.
PRODUCTO.
1. PRODUCTO.
2. Descripción producto.
En este punto, incluiremos ya el uso de la herramienta CASE, sin
embargo, es importante hacer ver que se tienen que considerar los siguientes
elementos:
1.
Tipos de datos de cada uno de
los campos.
2.
Relaciones que existan entre
las tablas.
3.
Cualquier cambio que por
requerimientos posteriores se tenga que incluir.
4.
Los elementos conclutorios, son
basados en la experiencia del autor de este estudio.
5.
La notación utilizada en el
diagrama es: Entity / RelationShip.
Aplicación de la herramienta CASE.
a) Análisis de la base
de datos.
Al comenzar a utilizar la herramienta CASE, tenemos que la tabla de
CLIENTE, queda de la siguiente forma:
Elementos importantes a
considerar en el uso de la herramienta:
1. El tipo de datos varchar solicita una longitud, la cual determina la
cantidad máxima de caracteres a ser aceptados en el atributo.
2. Existen dos columnas que aparentemente son iguales, Name
y Code,
la última se refiere a cómo quedará finalmente codificado el campo.
3. Las últimas columnas M P D, significan M: Mandatory[1],
P: Primary Key, D: Displayed. Vale la pena aclarar que una llave primaria debe
ser mandatorio, pero un campo mandatorio no necesariamente será una llave.
4. Los tipos de datos dentro de la definiciones de las columnas ayudan
a hacer predecible el crecimiento de la base de datos, esto es importante para
poder ya sea encontrar problemas de procesos o bien para poder dimensionar
crecimiento en espacio en disco duro o la administración de los espacios
reservados para la base de datos.
Conclusiones en la estructura:
3. Existen dos campos que no están incluidos en esta tabla: a) Tipo de
cliente si es empresa o persona natural y b) el tipo de documento que por
default se le va a emitir (Factura o crédito fiscal), no están consideradas
como una columna más en esta estructura, ya que a nivel Conceptual, estas son
el resultado de las relaciones. En este sentido podría considerarse que también
pueden ser campos verdaderos falsos, sin embargo si el sistema se aplicara en
otros países o existieran variantes; será complicado realizar el cambio
estructural, por lo que se ha decidido crear con estos campos dos tablas.
4. Aun cuando según los criterios de normalización los campos
calculados no deben ser parte de una estructura, es importante aclarar que en
las siguientes estructuras se incluirán varios de estos campos, en términos
generales, se considera la creación de estos campos, debido a que por efectos
prácticos resulta más fácil consumir recurso en disco duro, que consumir tiempo
de respuesta en una consulta; como ejemplo de esta aseveración es el valor del
IVA (0.13 actualmente). Aparentemente este valor será un valor repetitivo, y
que en función del tiempo consumirá espacio en disco duro innecesariamente, sin
embargo (y por considerarse este consumo relativamente insignificante en
función de los espacios en disco duro que existen en la actualidad), en el
momento de encontrar un valor histórico sobre el cálculo en caso de un cambio de valor, o cálculo del
mismo para efectos de reportes, este valor, generará demasiado consumo de
tiempo y esfuerzo de la base de datos si se pretende desarrollar una consulta o
series de consultas para calcularlo, es por ello que resulta práctico crear
mejor un campo en donde se pueda almacenar.
Luego de estas
conclusiones el diagrama va tomando la siguiente forma:
Al trabajar la
tabla de FACTURA, concluimos nuevamente que dos campos son tablas, una de ellas
ya existe y está relacionada con el cliente; la factura también tiene relación
con la tabla cliente, ya que una factura solamente será emitida a un cliente.
Al continuar con la
estructura de los datos y agregar las nuevas tablas tenemos la siguiente
estructura:
Podemos percatarnos en
este punto, que la estructura de la base de datos está complicándose, hay que
cuidarse de no crear tablas (innecesariamente), ya que podría volver ala base
de datos demasiado lento en el rendimiento que se desarrolla.
Continuamos entonces con
la tabla de FACTURA DETALLE.
Al trabajar esta tabla,
concluimos los siguientes elementos:
1. Existen muchos productos asociados a muchos precios.
2. La llave de la factura detalle, es una llave considerada como llave
compuesta, esta llave estará constituida de dos campos: LineaDetalle y Documento (que proviene de la FACTURA). Para representar
esta característica PowerDesigner utiliza un triangulo, lo cual representa que
la tabla posee una llave primaria que se convertirá en llave foránea y
compuesta dentro de la llave.
3. Existe una escenario, en el cual se complica aún más este tipo de
estructura, el cual consiste en la implementación del control de existencias
por bodega, este tipo de controles implica más criterios
dentro de la base de datos y no es por el momento parte de este estudio ya que esta en
relacióndirecta con el Control de Inventario.
4. Por requerimiento resulta importante clasificar a los clientes,
motivo por el cual se implementara una tabla que soporte dicha estructura.
5. Entre PRODUCTO y PRECIO, existe una relación de muchos a
muchos, al implementar esta estructura se creara una tabla intermedia para
romper este tipo de relación, sin embargo conceptualmente si existe.
Al implementar
estas consideraciones, la estructura queda de la siguiente forma:
Modelo
Conceptual del sistema de facturación requerido.
b) Implementación de
la base de datos utilizando Power Designer.
Al tener la
información en modo conceptual dentro de Power Desginer, para generar la
siguiente estructura se utilizan las siguientes opciones:
/Tools/Generate Logical Data Model , al usar esta opción se mostrara la
siguiente opción:
Opciones de generaciones de Logical Data Model (LDM).
Esta
pantalla, permite actualizar un modelo existente o crear desde cero uno, en
este caso utilizaremos la primera opción para evitar confusiones de combinaciones
de modelos. Al utilizarla el diagrama cambia de notación (pasa de Conceptual
Data Model (CDM) a Logical Data Model (LDM)), para evitar confusiones Power
Desginer utiliza esta nomenclatura para tipificar la extensión. Los cambios que
suceden al generar el CDM son los siguientes:
1.
Las llaves
primarias de una tabla, se convierten en llaves foráneas de la tabla con que se
relaciona.
2.
Se rompió la
relación de muchos a muchos creando automáticamente una estructura intermedia
para llevar este control.
3.
En la tabla
de FACTURADETALLE, se crea una llave compuesta constituida de la llave foránea
y la llave de la tabla.
El diagrama entonces queda de la siguiente forma:
Diagrama conceptual.
En
este punto es importante validar elementos de:
1.
Las
relaciones de las tablas.
2.
Congruencia
de las llaves primarias.
3.
Congruencia
de los tipos de datos.
4.
Congruencia
de los nombres de los campos.
Si existiera algún cambio a considerar, es
importante que los cambios se realicen en el modelo Lógico para poder llevar un
mejor control de los cambios estructurales.
El siguiente paso es la creación del Physical Data
Model (PDM), en este paso se selecciona ya la base de datos para poder crear
con las particularidades del SQL, la base de datos.
La opción que se muestra a continuación permite
seleccionar la base de datos sobre la cual Power Designer trabajara las
estrucuras SQL,
Opciones de generación de PDM.
Los PDM, tienen una semántica un poco diferente, las relaciones son las
flechas que se generan; la estructura que se generara es la siguiente:
Diagrama físico de la base de datos.
El último paso en Power Designer es la creación de
la base de datos, para ello existen dos opciones o bien, nos conectamos a la
base de datos directamente con un usuario con privilegios de creación de
estructuras o creamos un archivo sql que contiene el script de creación de la
base de datos y luego dentro de la base de datos ejecutamos el script. Para
generar la base de datos, se accesa a la opción Database y luego a Generate
Database (Esta opción se habilita solamente cuando estamos en el PDM).
Pantalla de generación de bases de datos. Luego de seleccionar el proveedor
de bases de datos (En este caso ORACLE Versión 11g)
A
continuación se muestra las sintaxis sql que se generan en base al Diagrama
Físico de la base de datos.
/*==============================================================*/
/*
DBMS name: ORACLE Version 11g */
/*
Created on: 17/01/2013 8:46:40
AM */
/*==============================================================*/
alter
table CLIENTE
drop constraint
FK_CLIENTE_TIPOCLIEN_TIPOCLIE;
alter
table CLIENTE
drop constraint
FK_CLIENTE_TIPOFACTU_TIPOFACT;
alter
table FACTURA
drop constraint FK_FACTURA_CLIENTE_F_CLIENTE;
alter
table FACTURA
drop constraint
FK_FACTURA_TIPODOCUM_TIPODOCU;
alter
table FACTURA
drop constraint
FK_FACTURA_TIPOFACTU_TIPOFACT;
alter
table FACTURA_DETALLE
drop constraint
FK_FACTURA__BODEGA_FA_BODEGA;
alter
table FACTURA_DETALLE
drop constraint
FK_FACTURA__FACTURA_F_FACTURA;
alter
table FACTURA_DETALLE
drop constraint
FK_FACTURA__PRECIO_FA_PRECIO;
alter
table FACTURA_DETALLE
drop constraint
FK_FACTURA__PRODUCTO__PRODUCTO;
alter
table PRECIO_PRODUCTO
drop constraint
FK_PRECIO_P_PRECIO_PR_PRODUCTO;
alter table PRECIO_PRODUCTO
drop constraint
FK_PRECIO_P_PRECIO_PR_PRECIO;
alter
table PRODUCTO
drop
constraint FK_PRODUCTO_BODEGA_PR_BODEGA;
drop
table BODEGA cascade constraints;
drop
table CLIENTE cascade constraints;
drop
table FACTURA cascade constraints;
drop
table FACTURA_DETALLE cascade constraints;
drop
table PRECIO cascade constraints;
drop
table PRECIO_PRODUCTO cascade constraints;
drop
table PRODUCTO cascade constraints;
drop
table TIPOCLIENTE cascade constraints;
drop
table TIPODOCUMENTO cascade constraints;
drop
table TIPOFACTURA cascade constraints;
/*==============================================================*/
/*
Table: BODEGA */
/*==============================================================*/
create
table BODEGA
(
BODEGAID INTEGER not null,
DESCRIPCIONBODEGA VARCHAR2(255),
constraint PK_BODEGA primary key (BODEGAID)
);
/*==============================================================*/
/*
Table: CLIENTE
*/
/*==============================================================*/
create
table CLIENTE
(
CODIGO_CLIENTE VARCHAR2(15) not null,
TIPOCLIENTEID INTEGER,
TIPOFACTURA INTEGER,
NOMBRECLIENTE VARCHAR2(250),
DUI VARCHAR2(12),
NIT VARCHAR2(12),
DIRECCIONCLIENTE VARCHAR2(250),
SALDOCLIENTE FLOAT,
LIMITECREDITO FLOAT,
NOMBRECONTACTO VARCHAR2(200),
constraint PK_CLIENTE primary key
(CODIGO_CLIENTE)
);
comment on table CLIENTE is
'Tabla que contiene la
información de los clientes. Esta tabla se utiliza para vincular las cuentas
por pagar, las cuentas por cobrar, etc.';
/*==============================================================*/
/*
Table: FACTURA
*/
/*==============================================================*/
create
table FACTURA
(
DOCUMENTO VARCHAR2(15) not null,
CODIGO_CLIENTE VARCHAR2(15),
TIPOFACTURA INTEGER,
TIPODOCUMENTOID INTEGER,
FECHAFACTURA DATE,
ESTADOFACTURA INTEGER,
SALDOFACTURA FLOAT,
DESCMONTO FLOAT,
DESCPORC FLOAT,
IVA FLOAT,
USR_CREACION VARCHAR2(25),
USR_MODIFICA VARCHAR2(25),
FCREACION DATE,
FEMISION DATE,
constraint PK_FACTURA
primary key (DOCUMENTO)
);
/*==============================================================*/
/*
Table: FACTURA_DETALLE */
/*==============================================================*/
create
table FACTURA_DETALLE
(
DOCUMENTO VARCHAR2(15) not null,
LINEADETALLE INTEGER not null,
PRODUCTOID INTEGER,
BODEGAID INTEGER,
PRECIOID INTEGER,
CANTIDAD FLOAT not null,
PRECIOUNITARIO FLOAT not null,
DECMONTOPROD FLOAT,
DESCPORCPROD FLOAT,
constraint PK_FACTURA_DETALLE primary key
(DOCUMENTO, LINEADETALLE)
);
comment
on column FACTURA_DETALLE.CANTIDAD is
'Cantidad de productos
facturados.';
comment on column
FACTURA_DETALLE.PRECIOUNITARIO is
'Precio unitario de los
productos, este valor viene asignado en función de la lista de precios vigente
en el momento.';
comment
on column FACTURA_DETALLE.DECMONTOPROD is
'Descuento en valor monetario
aplicado al producto.';
comment
on column FACTURA_DETALLE.DESCPORCPROD is
'Descuento en valor porcentual
aplicado al producto.';
/*==============================================================*/
/*
Table: PRECIO
*/
/*==============================================================*/
create
table PRECIO
(
PRECIOID INTEGER not null,
FECHADEINICIO DATE,
FECHADEFIN DATE,
ESTADODELISTA INTEGER default 0
constraint
CKC_ESTADODELISTA_PRECIO check (ESTADODELISTA is null or (ESTADODELISTA between
0 and 1 and ESTADODELISTA in (0,1))),
constraint PK_PRECIO primary key (PRECIOID)
);
/*==============================================================*/
/* Table: PRECIO_PRODUCTO */
/*==============================================================*/
create table PRECIO_PRODUCTO
(
PRODUCTOID INTEGER not null,
PRECIOID INTEGER not null,
constraint PK_PRECIO_PRODUCTO primary key
(PRODUCTOID, PRECIOID)
);
/*==============================================================*/
/*
Table: PRODUCTO
*/
/*==============================================================*/
create
table PRODUCTO
(
PRODUCTOID INTEGER not null,
BODEGAID INTEGER,
DESCRIPCIONPRODUCTO VARCHAR2(255),
constraint PK_PRODUCTO primary key
(PRODUCTOID)
);
comment on table PRODUCTO is
'Detalle de productos que se
venden en el punto de venta.';
/*==============================================================*/
/* Table: TIPOCLIENTE */
/*==============================================================*/
create table TIPOCLIENTE
(
TIPOCLIENTEID INTEGER not null,
DESCRIPCIONCLIENTE VARCHAR2(255),
constraint PK_TIPOCLIENTE primary key
(TIPOCLIENTEID)
);
comment on table TIPOCLIENTE is
'Contiene los diferentes tipos
de clientes que se registran dentro de la empresa.';
/*==============================================================*/
/* Table: TIPODOCUMENTO */
/*==============================================================*/
create table TIPODOCUMENTO
(
TIPODOCUMENTOID INTEGER not null,
TIPODOCUMENTODESCRIPCION VARCHAR2(255),
constraint PK_TIPODOCUMENTO primary key
(TIPODOCUMENTOID)
);
/*==============================================================*/
/* Table: TIPOFACTURA */
/*==============================================================*/
create table TIPOFACTURA
(
TIPOFACTURA INTEGER not null,
DESCRIPCIONTIPOFACTURA VARCHAR2(255),
constraint PK_TIPOFACTURA primary key
(TIPOFACTURA)
);
alter table CLIENTE
add constraint FK_CLIENTE_TIPOCLIEN_TIPOCLIE
foreign key (TIPOCLIENTEID)
references TIPOCLIENTE (TIPOCLIENTEID);
alter table CLIENTE
add constraint FK_CLIENTE_TIPOFACTU_TIPOFACT
foreign key (TIPOFACTURA)
references TIPOFACTURA (TIPOFACTURA);
alter table FACTURA
add constraint FK_FACTURA_CLIENTE_F_CLIENTE
foreign key (CODIGO_CLIENTE)
references CLIENTE (CODIGO_CLIENTE);
alter table FACTURA
add constraint FK_FACTURA_TIPODOCUM_TIPODOCU
foreign key (TIPODOCUMENTOID)
references TIPODOCUMENTO
(TIPODOCUMENTOID);
alter table FACTURA
add constraint
FK_FACTURA_TIPOFACTU_TIPOFACT foreign key (TIPOFACTURA)
references TIPOFACTURA
(TIPOFACTURA);
alter table FACTURA_DETALLE
add constraint
FK_FACTURA__BODEGA_FA_BODEGA foreign key (BODEGAID)
references BODEGA (BODEGAID);
alter
table FACTURA_DETALLE
add constraint FK_FACTURA__FACTURA_F_FACTURA
foreign key (DOCUMENTO)
references FACTURA (DOCUMENTO);
alter table FACTURA_DETALLE
add constraint
FK_FACTURA__PRECIO_FA_PRECIO foreign key (PRECIOID)
references PRECIO (PRECIOID);
alter table FACTURA_DETALLE
add constraint
FK_FACTURA__PRODUCTO__PRODUCTO foreign key (PRODUCTOID)
references PRODUCTO (PRODUCTOID);
alter table PRECIO_PRODUCTO
add constraint
FK_PRECIO_P_PRECIO_PR_PRODUCTO foreign key (PRODUCTOID)
references PRODUCTO
(PRODUCTOID);
alter table PRECIO_PRODUCTO
add constraint
FK_PRECIO_P_PRECIO_PR_PRECIO foreign key (PRECIOID)
references PRECIO (PRECIOID);
alter table PRODUCTO
add constraint
FK_PRODUCTO_BODEGA_PR_BODEGA foreign key (BODEGAID)
references BODEGA (BODEGAID);
Ingeniería Inversa.
El proceso de
Ingeniería Inversa, dentro de las bases de datos (se hace la aclaración ya que
para otras áreas de la informática puede cambiar el significado y la aplicación
del mismo), persigue que se pueda dentro del proceso partir de la estructura
física de la base de datos, ya sea esta de un desarrollo propio de las
organizaciones o uno externo poder de forma sencilla extraer la información de
todos los objetos dentro de la base, objetos tales como tablas, atributos,
constraints, comentarios en general desarrollados ya sea en campos o tablas,
validaciones estructurales etc. Es sin embargo importante, comprender de que
algunos diseños de bases de datos pueden ser de sistemas ya heredados, los
cuales, es posible no poseen más que algunos objetos de la base, es sobre esta
estructura recuperada que puede dar inicio al proceso de documentación de los
sistemas.
El proceso de
ingeniería inversa, es realmente sencillo en la mayoría de herramientas CASE,
(aunque algunas no poseen estas opciones, basadas en criterios de los derechos
reservados o porque esta opción es accesible desde las versiones pagadas);
basta tener el cliente de la base de datos y se puede accesar a toda la
metadata almacenada.
Dentro de
powerdesigner, la opción esta dentro de File/Reverse Engineer/DataBase, tal
como se muestra en la siguiente imagen:
Al utilizar esta
opción, se nos muestra el conjunto de bases de datos soportada en la
instalación del Sistema Operativo a las cuales PowerDesigner puede conectarse
para la extracción de la metadata, nos mostrará lo siguiente:
La siguiente
opción, determina como será la importación de la estructura, si es desde un
script o desde la base de datos directamente, y si el proceso de ingeniería
inversa será realizado con los privilegios del administrador. Luego, el proceso
está vinculado con las opciones de ODBC del sistema y los privilegios que tiene
el usuario actual; las opciones siguientes están en función de que tablas serán
importadas; si la estructura posee la información necesaria, será un proceso de
un asistente común y corriente para llegar a la estructura física, que a
discreción del analista llevarlo a las estructura Lógica y finalizar
información pendiente.
¿ En que casos
se requiere la ingeniería inversa?
1.
Sistemas heredados que
normalmente han evolucionado en función del tiempo y que no existe ninguna documentación.
2.
Cuando se está en el proceso de
ensayo de la estructura, y se realizan cambios en la base de datos
directamente, y se tiene que regresar a la estructura Lógica.
3.
Cuando un proveedor externo
desarrolla sistemas y se desea analizar funcionalidades especificas,
integraciones con DM (desarrollos a la medida), fallas en el rendimiento, o
procesos de auditorías en general.
Conclusión de la
generación de la base de datos.
1.
Cualquier
documentación creada en las tablas o campos, se convierten en Comment, como
parte de la documentación de la base de datos.
2.
El script de
la base borra la base de datos, con esto hay que tener cuidado ya que si los
datos existen estos se perderán.
3.
Cuando se
desarrollan los sistemas, siempre se considera como un elemento básico de la
arquitectura la base de datos, la cual deberá de ser pensada como un elemento
que pueda de cierta manera contestar a todas las preguntas que todas las áreas
de la organización se hagan, en este sentido poseer una herramienta que nos
permita ejercitar las estructuras y descubrir de forma rápida y sencilla
cualquier oportunidad de mejora se vuelve en el proceso de desarrollo de
sistemas un elemento crucial, mas aun en momento en los cuales las empresas
requieren soluciones casi mágicas.
4.
Las
herramientas CASE, dentro de las organizaciones no son un lujo, son más bien
una necesidad que abona directamente a la productividad de la empresa.
5.
Las
herramientas CASE, bien utilizadas son una de las herramientas que ayuda a los
ya engorrosos procesos de documentación de los sistemas.
6.
La ingeniería
inversa, es el elemento que nos permite regresar al modelo lógico de los
cambios ensayados y las correcciones realizadas a la estructura de la base de
datos.
7.
Algunos de
los modelos planteados como teóricos, son muy buenos e importante
desarrollarlos, sin embargo, es el elemento práctico el que puede garantizar la
productividad en la compresión, desarrollo y documentación de los sistemas.
Bibliografía.
Luque Ruiz Irene, Gomez-Nieto Miguel Angel, Enrique
Espinosa, Gonzalo Cerruela García, Bases de Datos, desde Chen hasta Codd con
ORACLE. Primera Edición 2004.
González
Alvarado, Carlos. Sistemas de Bases de Datos. Primera Edición 2009
Kevyn Loney, Marlene Theriault, ORACLE 9i, Manual Del Administrador. Técnicas de
Gestión de datos ORACLE robustas y de alto rendimiento.
William R. Vaugh, Programación de SQL Server 7.0 con Visual Basic 6.0
Teaching Soft Group, ORACLE 11g, Curso Práctico.
Catherine M. Ricardo, Bases de DATOS.
Referencias web.
[1]Mandatory: se convertirá en SQL (de cualquiera de las bases de
datos) como NOT NULL.
Dejo el link con el contenido solicitado en mi tarea para el postgrado de educación virtual de la Universidad Tecnológica de El Salvador. Documento Compartido
Dejo el link con el contenido solicitado en mi tarea para el postgrado de educación virtual de la Universidad Tecnológica de El Salvador. Documento Compartido
