Ideas para la auditoría de Sistemas

La auditoría de sistemas es un tema que puede llegar a ser complejo en la empresa, como todo tópico tiende a ser abordado desde distintos puntos de vista y no deja de ser válido el aspecto técnico contra el aspecto administrativo.

Desde el aspecto administrativo se esperan tener números que demuestren la efectividad de las reglas tomadas y de los ahorros conseguidos.

El aspecto técnico implica la rapidez de las tareas y los ahorros de tiempo para permitir el hacer otras tareas.

Los gerentes esperan de sus jefes técnicos la generación de simulaciones con lo que costaría en tiempo vs dinero invertido vs posible impacto para asegurar la necesidad de fondos para sus actividades, es parte de su set de conocimientos y necesidades.

Para los Jefes Técnicos es implícita esa necesidad y es difícil el concepto de generar aún mas trabajo para las actividades críticas del negocio.

Los dos lados de la moneda son difíciles de conciliar pero no imposible, varias instituciones han diseñado modelos de gobernabilidad de TI basados en las diferencias de conceptualización, convirtiendo tareas criticas en métricas medibles.

Para una persona técnica a veces es complicado el convertir las posibilidades de desastre en algo cuantificable, tan sólo la pérdida o corrupcion de datos parcial implica una investigación costosa y una posible pérdida monetaria y de confianza.

La comparación de cambios, el seguimiento, la responsabilidad documentada  y una adecuada política de proceso ayuda a reducir la posibilidad de factores impredecibles, por otro lado permite una rápida recuperación ante accidentes.

Es importante para todos los responsables en una empresa  el involucrarse y tratar tanto de comprender a sus colegas como el facilitar la comprensión de sus responsabilidades para mejorar la eficacia de los procesos en la empresa.

Programando para Móbiles

¿Porqué compilar en lenguaje nativo es mejor?

El compilar en lenguaje nativo contrario al ejecutar tecnologías híbridas como el html5 tiene muchas ventajas para el desarrollador serio:

La aplicación es más rápida tanto de instalar como de ejecutar

Las aplicaciones nativas no traen tanto bagaje de gráficos extras ni máquinas virtuales que provocan grandes pausas de latencia en los teléfonos que no son aparatos diseñados para tener capacidad de procesamiento.

En un tiempo donde la transmisión de datos sigue siendo un recurso premium no podemos darnos el lujo de obligar a nuestros clientes a bajar una gran cantidad de datos simplemente por una mala planificación y/o mala decisión a la hora de elegir una herramienta para trabajar.

La aplicación es más segura

Una aplicación compilada en lenguaje nativo está encapsulada, así que sus datos están protegidos, no se puede decir lo mismo de html5 por lo cual sus aplicaciones son muy reducidas.

El uso de herramientas personales esta restringido

Un desarrollador de aplicaciones móviles es obligado a utilizar las herramientas que vienen con el framework, y rara vez éste les permite crear sus componentes propios.

El soporte a gráficos es limitado

Los frameworks para desarrollo no nativo tienen un soporte de gráficos muy limitado debido a las diferencias tan marcadas de manejo entre las diferentes plataformas, y no permiten un buen uso de 3d

In-eficiencia del código

Los framework de programación móvil orientadas a Web dependen de librerias de traducción de código que no son eficientes lo que dificulta la correcta ejecución del diseño original de la app.

¿Como Optimizar SQL de manera visual?

Uno de los retos del día a día es optimizar los SQL que deben ejecutarse en nuestras bases de datos.

Muchos preguntarán el porqué de ésto, tomando en cuenta las capacidades procesales de las máquinas de hoy en día pero la respuesta es justamente que la capacidad de procesamiento es costosa, y debemos llegar a un punto de equilibrio muy por debajo del techo de la capacidad promedio de procesamiento si deseamos estar preparados para las "horas pico"

Los motores de bases de datos actuales nos permiten hacer búsquedas muy específicas y aunque nos parezcan ínfimas las velocidades de búsqueda, la cantidad de éstas es simplemente inmensa y una diferencia de 0.1 segundo entre una búsqueda y otra es una ventaja enorme.

Optimizar sentencias pequeñas no presenta problema, pero que tal una de ésta categoría?

SELECT C.Phone_Number, C.Honorific, C.First_Name, C.Last_Name,
C.Suffix, C.Address_ID, A.Address_ID, A.Street_Address_Line1,
A.Street_Address_Line2, A.City_Name, A.State_Abbreviation,
A.ZIP_Code, OD.Deferred_Shipment_Date, OD.Item_Count,
ODT.Text, OT.Text, P.Product_Description, S.Shipment_Date
FROM Orders O, Order_Details OD, Products P, Customers C, Shipments S,
Addresses A, Code_Translations ODT, Code_Translations OT
WHERE UPPER(C.Last_Name) LIKE :Last_Name||'%'
AND UPPER(C.First_Name) LIKE :First_Name||'%'
AND OD.Order_ID = O.Order_ID
AND O.Customer_ID = C.Customer_ID
AND OD.Product_ID = P.Product_ID(+)
AND OD.Shipment_ID = S.Shipment_ID(+)
AND S.Address_ID = A.Address_ID(+)
AND O.Status_Code = OT.Code
AND OT.Code_Type = 'ORDER_STATUS'
AND OD.Status_Code = ODT.Code
AND ODT.Code_Type = 'ORDER_DETAIL_STATUS'
AND O.Order_Date > :Now - 366
ORDER BY C.Customer_ID, O.Order_ID DESC, S.Shipment_ID, OD.Order_Detail_ID;

Por eso hoy voy a mostrar un método muy usado, VST

Para empezar vamos a clasificar las partes de la consulta de la siguiente manera, vamos a crear un diagrama de tipo autómata en la que:
Las tablas usadas en la consulta serán los nodos.
Los Joins serán las líneas de conexión entre los nodos
y los filtros nos guiarán con la ruta a seguir.

De ésta manera la consulta anterior se reclasificaría así:

Tablas
Orders O,
Order_Details OD,
Products P,
Customers C,
Shipments S,
Addresses A,
Code_Translations ODT,
Code_Translations OT

Joins
OD.Order_ID = O.Order_ID
O.Customer_ID = C.Customer_ID
OD.Product_ID = P.Product_ID(+)
OD.Shipment_ID = S.Shipment_ID(+)
S.Address_ID = A.Address_ID(+)
O.Status_Code = OT.Code
OD.Status_Code = ODT.Code

Filtros
WHERE UPPER(C.Last_Name) LIKE :Last_Name||'%'
AND UPPER(C.First_Name) LIKE :First_Name||'%'
AND OT.Code_Type = 'ORDER_STATUS'
AND O.Order_Date > :Now – 366
AND ODT.Code_Type = 'ORDER_DETAIL_STATUS'

y armamos el diagrama de la siguiente manera

Para que quede un diagrama como éste

El siguiente paso es ordenarlo para que nos permita determinar la ruta más discriminatoria y por lo tanto la que va a acelerar nuestra consulta:

Aquí podemos definir que la ruta mas restrictiva es ésta:

Por lo tanto nuestra consulta debe empezar por efectuar los joins a las tablas OD, O y C antes de continuar con las demás para considerarla optimizada.

 

Como ver el valor de una variable en una sentencia SQL ejecutándose en Oracle

Uno de los problemas generalizados en Oracle es el poder ver el valor de una variable incluida en una sentencia ejecutada.

¿a que me refiero con ésto?

En Oracle podemos usar una sentencia de éste tipo:

INSERT INTO emp VALUES
    (:empno, :ename, :job, :sal, :deptno)

donde los valores son incluidos por parámetro en variables, 
en éste caso es fácil de saber cuál valor es cuál cierto?

¿Que tal cuando las variables son incluidas ... así? 

INSERT INTO emp VALUES
    (:E1, :E2, :E3, :E4, :E5)

aunque no lo crea es un formato muy utilizado, 

¿cómo sabría usted cuál variable es cuál?

La manera difícil es generar un sql parecido a éste, por cada variable:

select sesion.sid,
       sesion.serial#,
       sesion.username,
       sesion.sql_id,
       sesion.sql_child_number,
       optimizer_mode,
       hash_value,
       address,
       sql_text
  from v$sqlarea sqlarea, v$session sesion
 where sesion.sql_hash_value = sqlarea.hash_value
   and sesion.sql_address    = sqlare

La manera fácil es con una herramienta de optimización como 
el DBOptimizer de Embarcadero:






Como ven aquí nos muestra todas las variables relacionadas al SQL 

con sólo un click