Arquitectura de Datos - Administración de Seguridad en Sybase ASE

Algunas estadísticas interesantes sobre seguridad en Sybase:

• Sybase ASE 15 ha obtenido el nivel más alto posible de certificación de seguridad con  reconocimiento internacional para un producto de software general (Common Criteria EAL4+) en más plataformas que ningún otro proveedor de bases de datos.
• ASE 15 ha presentado la menor cantidad de vulnerabilidades de bases de datos del mercado en un período de 12 meses, según el Equipo de Respuesta a Emergencias Informáticas de Estados Unidos (US-CERT).
• El 61 por ciento de la pérdida de datos es responsabilidad de miembros de la compañía. El cifrado en reposo, único de ASE, es una protección contra amenazas internas.

ASE 15 responde a los retos de seguridad mejorando un producto que ya es reconocido por su confiabilidad y su reducido riesgo operativo y que ha sido la elección para aplicaciones de misión crítica en el 90% de las compañías de seguridad en el mundo y 60% de los bancos, así como procesando más del 50% de las transacciones financieras de Wall Street.

La seguridad de la información personal es un área en donde ASE 15 ha agregado una habilidad única. Después de analizar más a fondo el tema de la protección de datos personales, Sybase identificó dos falencias importantes en la seguridad. Una es la necesidad de encripción a nivel de disco, que es esencial para proteger los datos personales cuando los discos, computadores portátiles, cintas o computadores personales son hurtados o violentados. Las pérdidas aquí pueden ser substanciales. Por ejemplo, un grupo médico recientemente perdió los datos personales de 185 mil pacientes al ser hurtados dos sistemas, y una institución académica reportó el robo de un computador portátil que contenía los datos personales de más de 98 mil aspirantes a graduación. Para brindar encripción a nivel de disco, ASE 15 utiliza un sistema de encripción único que no requiere modificaciones a la aplicación. Esto mantiene bajo el costo de la implementación y evita la aparición de nuevos problemas de seguridad generados por la interacción entre la aplicación y el software de seguridad.

La falta de protección para las llaves de encripción es otra omisión seria en otros sistemas. ASE 15 brinda esta protección integrando el acceso a las llaves a través de un sistema de permisos, el cual provee llaves sólo a usuarios designados. Con este manejo intrínseco de las llaves, las llaves de encripción están protegidas y son más fáciles de manejar, particularmente cuando se está lidiando con un gran número de usuarios. ASE 15 también hace que la implementación de las llaves de encripción sea muy fácil, a través de una sintaxis simple y directa.

En adición a éstas características únicas, ASE 15 también ofrece la certificación de criterio común, soporta para SSL y se acoge a FIPS 140-2.

Al responder al problema del tiempo no planeado fuera de línea, ASE 15 comienza con un producto ya reconocido por su confiabilidad y uso eficiente de los recursos del sistema, y luego agrega sustanciales nuevas características para mejorar la disponibilidad del sistema y los procedimientos de recuperación ante desastres.

El nuevo motor de almacenamiento de ASE 15 permite cuatro tipos de particionamiento de datos, el cual permite la ubicación sobre varios dispositivos físicos. Si un dispositivo falla, las particiones restantes quedan disponibles para su uso.

Adicionalmente, para potenciar la disponibilidad y facilitar la recuperación ante desastres, Sybase ASE 15 puede ser usado en conjunto con las tecnologías de replicación de Sybase, tales como Replication Server y Mirror Activator, para ofrecer un arquitectura altamente escalable con la habilidad de mezclar y unir componentes que brinden un amplio rango de soluciones, desde una sencilla replicación de base de datos a base de datos, hasta replicación heterogénea compleja y bidireccional entre ubicaciones geográficamente separadas. Esto permite a los DBAs configurar rápidamente sitios redundantes para recuperación ante desastres y sincronizar datos entre plataformas heterogéneas de datos. ASE 15 también continúa soportando la solución de cluster de dos nodos (activo/activo o activo/pasivo) para alta disponibilidad.

Otra característica nueva de seguridad seria el sistema único de cifrado de ASE, de patente en trámite, que ofrece notables ventajas con respecto a otros productos:

• Se puede implementar sin modificaciones de las aplicaciones.
• Ofrece un sistema basado en permisos para controlar el acceso, lo que brinda una mejor protección y facilita la administración.
• Protege contra el fraude interno mediante el uso de claves seguras a las que incluso el administrador de bases de datos no tiene acceso.
•  Minimiza el impacto de funcionamiento ya que sólo cifra las columnas que contienen datos personales confidenciales.

Componentes principales de Seguridad para Sybase:

ASE Security & Directory Services Package:

Garantiza la privacidad de los datos mediante controles de acceso basados en filas, la encriptación de datos en tránsito y compatibilidad con los servicios LDAP, Active Directory y Pluggable Authentication Modules (PAM).

Opción Columna encriptada de ASE:

Permite que los datos se encripten en forma nativa y selectiva, y que se almacenen con ASE.

Opción ASE Advanced Backup Services - Tivoli™ Storage Manager:

Compatible con la integración de Adaptive Server Backup Server con Tivoli Storage Manager.

Sybase Adaptive Server Enterprise (ASE) Cluster Edition:

Está diseñado para satisfacer demandas extremas de los más altos niveles de servicio de aplicaciones y garantías de tiempo de funcionamiento del sistema. La nueva tecnología Virtualized Resource Management™ y la arquitectura de cluster de disco compartido protege los niveles de servicio, permite la consolidación de servidores y ayuda a disminuir los costos de infraestructura. Adaptive Server Enterprise Cluster Edition está fundamentado en la fiabilidad y los bajos costos operativos de ASE, y ofrece una infraestructura de base de datos que permite al departamento de TI mejorar los niveles de servicios de aplicación, reducir los costos de los centros de datos y crear una infraestructura de datos para el crecimiento futuro del negocio.

Replication Server

El software de replicación de base de datos mueve y sincroniza los datos en la empresa distribuida. Con los siguientes beneficios:

·         Brinda operación continua sin importar las fallas de hardware/software y durante procesos de mantenimiento, al mismo tiempo que provee soporte a toma de decisiones en tiempo real sin afectar los sistemas de producción—Replication Server hace parte de nuestros productos para la Continuidad del Negocio.

·         Permite la integración y sincronización de operaciones a lo largo de ubicaciones remotas.

·         Construido para plataformas heterogéneas de base de datos—Sybase ASE, Oracle, IBM DB2 y Microsoft SQL Server.

Mirror Activator

Mirror Activator es una solución innovadora y fácil de implementar que trabaja en conjunto con productos de replicación a nivel de dispositivo, garantiza la integridad transaccional y protege ante corrupción de discos.

Con Mirror Activator, los clientes de Adaptive Server Enterprise pueden ahora:

·         Reducir el costo total de propiedad. Mirror Activator corta el ancho de banda requerido por los sistemas de replicación de dispositivos basados en hardware hasta en un 50%.

·         Minimizar el riesgo operativo. Reduce dramáticamente el tiempo de failover para aplicaciones basadas en Adaptive Server Enterprise, reduciendo los costos asociados con la pérdida de continuidad de los sistemas.

·         Brindar completa integridad de datos. Garantiza la integridad de datos y protege contra corrupciones en disco.

·         Convertir costoso hardware inactivo en un recurso productivo. Los sistemas de bases de datos standby pueden ahora ser utilizados para operaciones de sólo lectura, tales como consultas y generación de reportes, mejorando el retorno de inversión. 

OpenSwitch

Garantiza una disponibilidad continua al dirigir los usuarios finales del sistema principal al sistema de respaldo.

Algunos escenarios de OpenSwitch:

Tolerancia a Fallos.

Balanceo de Cargas.

En Línea, Fuera de Línea.

Opción de Alta Disponibilidad:

Sybase Adaptive Server Enterprise (ASE) está diseñado para soportar los exigentes requerimientos de aplicaciones de misión crítica con procesamiento intensivo de transacciones y de aplicaciones para el soporte a toma de decisiones. La eficaz optimización de consultas de ASE brinda niveles sin precedentes de rendimiento, escalabilidad y bajo costo. Sus características de administración hacen que Adaptive Server sea más fácil de poner en marcha y mantener; su escalabilidad operativa mejorada soporta mayores cargas de trabajo, con menos recursos. Sybase Adaptive Server Asegura la más alta eficiencia operativa sobre un amplio rango de plataformas.

La Opción de Alta Disponibilidad para Adaptive Server Enterprise brinda casi continuo acceso a la base de datos, con protección a fallas en sitio. Las aplicaciones críticas del negocio y las transacciones más sensitivas son mantenidas en el evento de fallas inesperadas del sistema, u operaciones programadas de mantenimiento.

10 Preguntas y Respuestas sobre Administración de Proyectos

1. Define el concepto de Alineación Estratégica de la T.I. con el negocio y explica su importancia: Es parte del proceso de planeación estratégica que se enfoca en garantizar el vínculo entre los planes de las Entidades de Gobierno Empresarial y los planes del Área de TI. Su importancia se deriva que esta alineación estratégica es el proceso continuo para definir, mantener y validar la Propuesta de Valor de TI, y su segundo objetivo es enfocar las operaciones de TI con las operaciones de la organización.
2. Explica cuál puede ser el impacto económico de una a) adecuada e b) inadecuada alineación de la T.I. con el negocio: a) Principalmente se tendrá el patrocinio adecuado para el portafolio de proyectos y estrategias de TI para generar valor de negocio a la organización. Y se demostrara el valor de TI mediante el proceso de Gobierno y Control del área. b) Esta organización mostraría que el presupuesto de TI se dedicaría a “Apagar Fuegos” y seria “Reactivo” para cubrir las necesidades inmediatas de soporte de TI para la Organización. No existiría un patrocinio adecuado para grandes proyectos de implementación de Arquitectura Empresarial.
3. ¿De qué manera puede el área de T.I. dirigir proyectos alineados a los objetivos organizacionales? Se deberá implementar un proceso ágil de administración de proyectos con una correcta justificación del valor de negocio de los proyectos (Caso de Negocio, Administración de Requerimientos, Administración de Riesgos, Arquitectura Empresarial y Métricas de Gobierno de TI).
4. Describe un ejemplo de proyecto de T.I. que tenga una clara alineación con objetivos estratégicos del negocio (Rentabilidad, Productividad, Competitividad, etc.) Ejemplo Caso de Negocio de BPM: Evaluar el desempeño de los procesos y la madurez de la gestión de administración de procesos en términos de Alineación Estratégica, Gobierno, Métodos, Tecnologías de Información, Personas y Cultura. Desarrollar la solución de BPM y su plan de implementación. Identificar los indicadores clave sobre los beneficios y elaborar su retorno de inversión. Estos indicadores se deben plantear en términos de la Eficiencia, Visibilidad y Agilidad. (ROI del BPM),
5. Señala los aspectos principales a tomar en cuenta para que la T.I. habilite un proceso clave del negocio. El primer paso para alinear los proyectos de TI con los objetivos estratégicos de la empresa, seria la definición adecuada de los objetivos, priorización y clasificación utilizando terminología SMART (Específicos, Medibles, Alcanzables, Reales y Temporales). Una vez definidos, se puede modelar con BPM la Estructura de Metas, y se definen los procesos clave para su realización. Y al final se desglosa en un portafolio de proyectos de TI con su correcta alienación a los objetivos estratégicos organizacionales para la automatización de los proyectos clave (que apliquen), y se define presupuesto en relación de esta clasificación y priorización.
6. Describe la relación entre los tres principales aspectos de la administración de un proyecto (tiempo, costo, alcance) y su impacto en la calidad del mismo. Esta relación se conoce como la triple restricción, y se refiere a dependencia directa que existe entre el tiempo asignado para realizar un proyecto dado cierto alcance en un costo definido, y si se modifica alguna de las variables del proyecto, esto afecta a las dos variables dependientes (por eso se representa con un triangulo), y comúnmente la cuarta variable que se representa como un vector que surge del triangulo es la calidad, de igual forma dependiente de las demás variables del proyecto.
7. Explica por qué la administración de proyectos puede/debe apoyarse en un marco de referencia como el propuesto por el PMI. El marco de referencia de PMI o PRINCE2 debe implementarse y configurarse en organizaciones que busquen la alineación estratégica para obtener los siguientes beneficios: Mayor cumplimiento de expectativas de todos los involucrados y patrocinadores, mejor predicción de resultados y mejor manejo de riesgos, mejores relaciones entre los involucrados, información veraz y oportuna, estandarización de procedimientos, capitalización de aprendizajes, agilidad en tiempos de respuesta, agilidad en inducción para los nuevos miembros del equipo, mejoras en la calidad y su aseguramiento, menor burocracia, mayor integración dentro de y entre los equipos, agilidad en tiempo de ejecución, ahorros en costos, mayor compromiso con los resultados, y gobierno de los proyectos.
8. El artículo “Effective Project Management Efforts Have Business Goals Attached” menciona que se debe tener un “Business Case”.  ¿A qué se refiere y cuál es la importancia de este aspecto? El autor refiere al acrónimo BASIC (Caso de Negocio, Asignación de Responsabilidades, Métricas de Éxito, Impacto en otros Proyectos y Comunicación) como elementos que debe contar un CIO para la administración mínima de proyectos. El principal elemento de la Administración de Proyectos es el Caso de Negocio, en el se define el enunciado de alcance del proyecto (objetivo principal) y se constituye los participantes, recursos y patrocinadores del proyecto.
9. Menciona las etapas en el ciclo de vida o “grupos de proceso” que sugiere el PMBoK y explica la importancia de gestionarlas adecuadamente. Los grupos de proceso son: Inicio, Planeación, Ejecución, Monitoreo – Control y Cierre. Las aéreas de conocimiento son: Integración, Alcance, Tiempo, Costo, Calidad, Recursos Humanos, Comunicación, Riesgos y Adquisiciones. La gestión adecuada, indica cuales son los entregables y actividades principales para realizarlos por cada fase (critico identificar cuáles son los entregables hitos por fase), y asignando la responsabilidad por área de conocimiento. Esta relación en conjunto se conoce como el marco de trabajo del PMI.
10. De acuerdo con lo visto hasta ahora en la materia, ¿cómo puede la administración de proyectos apoyar para que un proyecto específico de T.I. esté verdaderamente alineado con el negocio? Las herramientas que prefiero para verificar la alineación estratégica de los proyectos de TI, seria COBIT, en particular ValIT y RiskIT, las cuales permiten evaluar sistemáticamente los proyectos de TI, y gobernar los Riesgos de estos proyectos. Factores que son críticos para el éxito de los proyectos de TI.

Habilidades de un Administrador de Proyectos.

Un administrador de proyectos debe reforzar las siguientes habilidades:

• Planeación. La habilidad para planear significa ser capaz de identificar tareas que necesitan realizarse, incluyendo las diferentes dependencias incluidas en la tarea, y desarrollar estimados de tiempo y recursos necesarios para completar un proyecto.
• Evaluación del estado del proyecto. Cada  PM debe saber cómo determinar el estatus de un proyecto en desarrollo comparado con los detalles de su plan.. Las metodologías y técnicas concernientes—earned value analysis (EVA), Índice de agenda, performance index (SPI) analysis, y cost performance index (CPI) indicators — son algunas herramientas útiles.
• Manejo de Riesgos. A los PMs  se les puede enseñar a identificar riesgos mediante el uso de un contrato que aclare los objetivos, alcance, recursos y tiempos para el— y luego a usar técnicas de administración de proyectos para manejar estos riesgos. Las organizaciones deberán estar preparadas para proporcionar cursos de certificación, entrenamiento en sitio ó algún tipo de entrenamiento de alta calidad en habilidades requeridas por nuevos o posibles PMs.
• Anticipación. Algunas personas son buenas para concentrarse en la tarea actual y no se preocupan por lo que vendrá más adelante. En cambio, un administrador de proyectos necesita anticipar lo que encontrará a la vuelta de la esquina. Aun con la planeación mas exhaustiva, los problemas pueden surgir  durante la ejecución de un proyecto que podría descarrilarse si estos problemas no son anticipados y atendidos. Un PM debe pensar en el futuro y estar listo para cualquier contingencia.
• Atención a los detalles. La mayoría de los proyectos se conforman de varias piezas que se tienen que acoplar, requieren que mucha gente trabaje en conjunto y parten de varios requerimientos que tienen que ser cumplidos. El PM debe poder ver no solo el bosque, sino también los detalles (los árboles del bosque), y como estos encajan unos con otros. La persona que solo piensa en la perspectiva general no puede ser un PM eficaz, puesto que la administración de proyectos requiere la habilidad de pensar a diferentes niveles de detalle sin descuidar la fotografía completa.
• Habilidad para Influenciar. Sin importar que tanta planeación se lleve a cabo para un proyecto, la habilidad de un PM para dar buenos resultados depende en su habilidad para influenciar a la gente. Los miembros del equipo deben entender sus tareas y saber por qué son importantes, y a los “stakeholders” del proyecto, se les debe de mantener informados del progreso para que las decisiones que tomen se alineen con las metas del proyecto. Un PM de poder comunicarse con todos los interesados y manejar las expectativas durante el camino de la culminación exitosa del proyecto.

Arquitectura de Datos - Modelo Entidad/Relación

Modelo Entidad/Relación

El modelado de datos entidad/relación (también conocido como entidad/vínculo, E/R) es un modelo conceptual basado en una percepción del mundo real por medio de objetos básicos llamados entidades y de las relaciones que existen entre éstos.

El modelo E/R fue creado por Peter Pin-Shan Chen en 1976, sin embargo ha sido modificado y refinado a través del tiempo. Se desarrolló para facilitar el diseño de las bases de datos por medio de la representación de la estructura lógica de una base de datos.

En el modelo E/R existen 3 conceptos básicos principales:

1) Entidades (sustantivo)

Una entidad es una cosa u objeto del mundo real que se puede identificar en forma distintiva. Es algo que existe y puede ser descrito.

Las entidades se pueden clasificar como entidades normales (o fuertes) y entidades débiles. Una entidad débil es aquella cuya existencia depende de otra entidad, es decir, no puede existir si la otra entidad no existe. Por el contrario, una entidad normal puede existir pos sí misma.

2) Atributos o propiedades (adjetivo)

Es una característica distintiva de las entidades. Los atributos pueden identificar, relacionar o describir entidades. Para cada atributo hay un conjunto de valores permitidos que son el dominio del atributo.

Además, un atributo se puede caracterizar por pertenecer a alguno de los siguientes tipos:

* Simples o compuestos: el atributo puede ser un todo (p.ej. país) o puede estar compuesto de otros atributos simples (p.ej. dirección).

* Clave: Único dentro de algún contexto (p. ej. CURP).

* Monovaluado o multivaluado: Si el atributo especificado hace referencia a un único valor se considera monovaluado (p.ej. talla), pero si por el contrario puede tener un conjunto de valores es multivaluado. (p.ej. teléfono).

* Faltante: En caso de que la entidad no tenga un valor para el atributo, que el atributo no exista para la entidad, o que simplemente se desconozca su valor. (p.ej. último_acceso en caso de que no se hayan realizado accesos)

* Base o derivados: Un atributo derivado es el que obtiene su valor de otros atributos o entidades relacionados (p.ej. total_venta), un atributo base es el opuesto al derivado.

3) Relaciones  o vínculos (verbo)

Una relación es una asociación entre entidades. Las entidades involucradas en una relación son participantes en esa relación, mientras que al número de participantes en la relación se le llama grado del vínculo o relación.

Una relación es total cuando todo ejemplar de una entidad A se relaciona con al menos un ejemplar de una entidad B, en caso contrario decimos que es una relación parcial.

En base al número de instancias participantes en una relación, pueden existir tres tipos de cardinalidades  uno a uno, uno a muchos/muchos a uno o muchos a muchos.

Modelo E/R extendido

Con el paso del tiempo se agregaron algunos conceptos a modelo original propuesto por Chen. Algunos de estos nuevos conceptos son especialización y generalización

El concepto especialización se refiere a diferenciar un subgrupo (subclase) de una entidad (superclase) (p.ej. empleado es una especialización de persona). Un subgrupo de entidades puede tener atributos que no son compartidos con otros subgrupos. Cada atributo del subconjunto generado posee los atributos del atributo del que se derivó y adicionalmente cuenta con atributos propios (herencia de atributos).

Por otro lado, el proceso de integración de subgrupos para obtener un nivel más alto se llama generalización.

Diagramas E/R

Los diagramas son una forma práctica y visual de representar la estructura lógica de una base de datos.  La notación para realizar diagramas E/R es la siguiente:

Otras notaciones

Con el tiempo se han desarrollado otras notaciones que representan los mismos conceptos por medio de diferentes simbologías, algunas son:

1) Notación de Ross

2) Notación de Bachmann

3) Notación de Martin

4) Notación de Chen

5) Notación de Rumbaugh

Diagramas de Ejemplo

Arquitectura de Datos - Modelado de Datos

Modelado de datos

Un modelo es un conjunto de herramientas conceptuales que permite describir la estructura de los datos (tipos de datos y forma en la que se relacionan) y sus restricciones de integridad. El modelado hace la pregunta ¿Qué?.

También se puede decir que un modelo de datos permite describir los elementos de la realidad que intervienen en un cierto problema y la forma en la que éstos se relacionan entre sí.

Los modelos de datos se pueden clasificar en 3 tipos:

1. Modelos conceptuales: También llamados modelos de datos semánticos. Están orientados a dar una visión general del negocio, representando los elementos que intervienen en el problema a resolver y sus relaciones. Se basan en objetos.

o Modelo Entidad Relación

2. Modelos lógicos: También llamados modelos de datos clásicos. En estos modelos se incluyen todos los detalles de los datos. Se basan en registros.

o Modelo Relacional, modelo de redes, modelo jerárquico

3. Modelos físicos: También llamados modelos de datos primitivos. Son un esquema de datos de bajo nivel que se implementa dentro del manejador de base datos.

o Administración de ficheros (p.ej. CA-DATACOMB de Computer Associates International)

Para diseñar una base de datos se deben usar primero los modelos conceptuales para lograr una descripción de alto nivel de la realidad, y luego se transforma el esquema conceptual en un esquema lógico.

Los modelos conceptuales, para poder representar correctamente la realidad, deben poseer las siguientes cualidades:

* Expresividad: Deben tener suficientes conceptos para expresar perfectamente la realidad.

* Simplicidad: Deben ser simples para que los esquemas sean fáciles de entender.

*  Minimalidad: Cada concepto debe tener un significado distinto.

*  Formalidad: Todos los conceptos deben tener una interpretación única, precisa y bien definida.

El resultado de un modelado de datos es una representación que tiene dos componentes:

1) Las propiedades estáticas: Que se definen en un esquema.

* Objeto: Cualquier entidad con existencia independiente sobre el que almacenan datos. Puede ser simple o compuesto.

* Relación: Asociación entre objetos.

* Restricción estática: Propiedad estática del mundo real que no puede expresarse con los anteriores, ya que sólo se da en la base de datos; suele corresponder a valores u ocurrencias, y puede ser sobre atributos, entidades y relaciones.

* Objeto compuesto: definidos como nuevos objetos dentro de la base de datos, tomando como punto de partida otros existentes, mediante mecanismos de agregación y asociación.

* Generalización: se trata de relaciones de subclase entre objetos, es decir, parte de las características de diferentes entidades pueden resultar comunes entre ellas.

2) Las propiedades dinámicas: Que se definen como especificaciones de transacciones, consultas e informes.

* Operación: Acción básica sobre objetos o relaciones (crear, modificar, eliminar...).

* Transacción: Conjunto de operaciones que deben ejecutarse en su conjunto obligatoriamente.

* Restricción dinámica: Propiedades del mundo real que restringen la evolución en el tiempo de la base de datos. 1

Proceso de Modelado de Datos.

El modelado de datos es uno de los elementos más importantes a la hora de iniciar el desarrollo de cualquier proyecto. Esta es la estructura, sobre la que realmente reside la verdadera esencia de la aplicación. Incluso determina si el proyecto va a cumplir con su verdadero objetivo. Esta fase es crítica en el diseño de la arquitectura de software, y soporta directamente la implementación de los requerimientos aplicativos en esta arquitectura. Esta actividad es independiente de la implementación del manejador de base de datos a utilizar y las herramientas para explotarlo. Existen algunas metodologías informales que indican cómo realizar este modelado, en general serian las siguientes:

* Identificar requerimientos generales de la arquitectura de datos. Validar los requerimientos generales de la arquitectura de datos (desempeño, concurrencia, integridad, seguridad, etc.)

* Análisis de Fuentes de Información Actuales. Estas fuentes incluyen la documentación en papel o digital que ya exista (archivos, reportes, formatos, recibos, listados, etc.).

* Identificación de Entidades Principales. En esta fase se enlistan los campos identificados y se asignan a sus correspondientes entidades. También se identifican los campos llave.

* Elaborar diagrama E-R preliminar. Se identifican las relaciones entre entidades.

* Verificar Modelo E-R. Se cargan algunos datos de prueba, y se normalizan las tablas. Y se actualiza el modelo E-R.

* Implementar el Modelo E-R final. Se implementa en el manejador específico el Modelo E-R final.

El modelado de datos debe verificarse para asegurarse de que cumpla los requerimientos específicos de calidad de la arquitectura de datos. A continuación se enumeran los factores generales que deben ser validados sobre el modelado:

* Información incorrecta. Anomalía de modificación: Si la información es repetida en más de un lugar en la base de datos, es común que sea inconsistente (sensible a mayúsculas, abreviaciones, captura incorrecta, etc.)

* Inhabilidad para ingresar información necesaria. Anomalía de inserción: Si no se cuenta con los campos y relaciones correctas, no va a ser posible ingresar datos que el negocio necesita (orden de la inserción de información).

* Perdida de información necesaria. Anomalía de eliminación: Cuando se elimina información en base de datos mal diseñados, comúnmente también se elimina información necesaria.

* Dificultad para implementar cambios. Una base de datos correctamente diseñada permite el crecimiento y cambios de su información.

Arquitectura de Datos - Conceptos Generales

Conceptos generales

Base de Datos: Es un sistema que almacena datos que están relacionados.

Se pueden clasificar según su función o según su estructura. La clasificación en base a su función comprende una gama muy alta que no se incluirá en este trabajo. La segunda clasificación según su estructura o modelo de base de datos, se describe a continuación:

- Base de datos jerárquicos: En este modelo la información se almacena en una estructura jerárquica. En este modelo los datos se organizan en una forma similar a un árbol invertido, en donde un nodo padre de información puede tener varios hijos. La gran desventaja de este modelo es la incapacidad de representar eficientemente la redundancia de la información relacionada.

- Base de datos de red: Este modelo es muy similar al anterior, con la gran diferencia que un nodo pueda tener varios padres.

- Bases de datos transaccionales: Su fin único es el envió y recepción de datos a grandes velocidades.

- Bases de datos relacionales: Su concepto principal es el uso de “relaciones”. Estas mismas podrían considerarse en forma lógica como conjuntos de datos llamados “tuplas”.  También surge el concepto de tabla, compuesta de registros (filas en una tabla), que representan las tuplas, y campos (las columnas de una tabla). Otra característica muy importante de este modelo, es la independencia del modelo lógico contra el modelo físico, lo cual significa que el lugar y forma en que se almacenen los datos no tiene relevancia.

Sistema Administrador de Base de Datos  (DBMS-Data Managment System ) son un tipo de software muy específico, dedicado a servir de interfaz entre las bases de datos y las aplicaciones que la utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta.

Arquitectura de bases de datos

La arquitectura de los sistemas de bases de datos utilizada en la actualidad fue propuesta por el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) en 1975 y consiste en 3 niveles distintos de abstracción de los datos almacenados.

Los niveles propuestos son:

* Nivel interno o físico: Describe los datos de forma física, es decir, todos los detalles de su almacenamiento, configuraciones a bajo nivel y rutas de acceso.

* Nivel conceptual o lógico: Es el siguiente nivel más alto en abstracción. Describe los datos mediante un esquema conceptual, el cual describe las entidades, atributos, relaciones entre los datos y las restricciones de integridad.

* Nivel externo o vistas: Es el nivel más alto en abstracción. Describe las vistas al usuario de los datos, es decir, muestra sólo un conjunto de datos específico a ciertos usuarios y oculta el resto.

Es importante mencionar que para una base de datos existe un nivel único interno y un nivel único conceptual, pero pueden existir varios niveles externos según se requiera.

La arquitectura de 3 capas permite la independencia de datos que se puede definir como la capacidad para modificar el esquema en un nivel del sistema sin tener que modificar el esquema del nivel inmediato superior 1. Los dos tipos de independencia de datos que existen son:

* Independencia Física: Es la capacidad para modificar el esquema interno (físico) sin alterar los niveles superiores.

* Independencia Lógica: Es la capacidad para modificar el esquema conceptual sin la necesidad de rehacer las aplicaciones.

Sistemas de bases de datos

Un sistema de base de datos es un sistema informático que sirve como interfaz entre la base de datos y el usuario por medio de peticiones. Está integrado por  un conjunto de componentes que permiten:

* Definir los tipos de datos, estructuras y restricciones de los datos que se almacenarán en la base de datos.

* Almacenar los datos.

* Manipular los datos almacenados.

Los sistemas de base de datos tienen 4 componentes principales:

* Datos

* Equipo (Hardware)

* Programas (Software)

* Gente

Los sistemas de bases de datos se pueden clasificar de varias formas:

1. De acuerdo al modelo de datos en el que está basado.

o Relacional

o Orientado a Objetos

o Objeto-relacional o relacional extendido.

o Jerárquico

o De red

2. De acuerdo al número de usuarios que la pueden usar.

o Monousuario

o Multiusuario

3. De acuerdo al número de sitios en el que se encuentra distribuida la base de datos.

o Centralizado

o Distribuido

Existen 8 servicios principales que los sistemas de bases de datos deben proporcionar:

1. La capacidad a los usuarios de almacenar, acceder y actualizar datos en la base de datos

2. Un catálogo (diccionario de datos) en el que se almacenen las descripciones de los datos y que sea accesible por los usuarios. Este diccionario de datos  contiene información que describe los datos de la base de datos (metadatos).

3. Un mecanismo que garantice que todas las actualizaciones correspondientes a un conjunto de acciones (transacción) se realicen por completo  o que no se realice ninguna.

4. Un mecanismo que asegure que la base de datos se actualice correctamente cuando varios usuarios la actualizan a la vez.

5. Un mecanismo capaz de recuperar la base de datos en caso de que ocurra algún suceso que la dañe llevándola a un estado consistente.

6. Un mecanismo que garantice que sólo los usuarios autorizados pueden acceder a la base de datos.

7. Integración con algún software de comunicación que permita a los usuarios acceder a la base de datos a través de una red.

8. Los medios necesarios para garantizar que tanto los datos de la base de datos, como los cambios que se realicen sobre ellos, sigan ciertas reglas de integridad garantizando su calidad.

Los sistemas de base de datos tienen la característica de utilizar lenguajes basados en relaciones de información para utilizarse, programarse, explotarse y administrarse. Y las instrucciones relacionadas en estos lenguajes se clasifican dependiendo su función en el SDB:

- Data Control Language (DCL): es utilizado para tener control del acceso a la base de datos.

- Data Definition Language (DDL): utilizado para configurar, definir, modificar y borrar tablas y vistas.

- Data Manipulation Language (DML): utilizado para extraer y modificar información.

Frontend vs Backend

En los sistemas de bases de datos existen componentes servidor (backend) y componentes de explotación, consumo y presentación de la información (frontend). Aunque actualmente no es tan común utilizar los mismos frontends que provee el fabricante, un caso muy claro seria Access, ya que es una BD que tiene sus elementos de presentación y explotación integrados. Aunque también los aplicativos que se desarrollan para consumir la información de una BD se considerarían como Frontend. Por ejemplo una aplicación web, que explota los servicios de una BD de SQL Server u Oracle. O incluso un Servicio XML Web que consume información de una base de datos diversa.

Lenguajes de explotación

Se le denomina de esta forma a los lenguajes que permiten manipular los datos contenidos en las bases de datos, es decir, realizar consultas, insertar, borrar y modificar datos. En ingles Data Manipulation Language (DML).

Existen 2 tipos de lenguajes de explotación o manipulación:

* Lenguajes procedurales: En este tipo de lenguaje el usuario debe especificar que datos necesita y las operaciones relacionadas para obtenerlos. Las sentencias de los lenguajes procedurales deben estar embebidas en un lenguaje de alto nivel, ya que se necesitan sus estructuras (bucles, condicionales, etc.) para obtener y procesar cada registro individual. A este lenguaje se le denomina lenguaje anfitrión2. Son usados por bases de datos del tipo jerárquicas y de red

* Lenguajes no procedurales (o declarativos): Permiten al usuario especificar el tipo de manipulación de datos que desee por medio de una sentencia sencilla sin especificar cómo se debe acceder a ellos. La traducción de la sentencia es realizada por el Sistema Gestor de Base de Datos. Son usados por las bases de datos relacionales.

Algunos de los lenguajes más usados son:

* SQL (Structured Query Language): Fue creado por IBM en los años 70’s, está basado en el álgebra relacional y cuenta con algunas facilidades del cálculo relacional. Se creó para System R.

* QUEL (Query Language): Fue desarrollado en 1976 por M. Stonebraker para el Sistema de Base de Datos Ingres. Está basado en el cálculo relacional orientado a tuplas.

* QBE (Query by example): Se desarrolló por IBM en los años 70’s. Está basado en cálculo relacional orientado al dominio. Consiste en dar un ejemplo del tipo de tupla que se quiere.

Lenguajes de 4ta generación

Se les llama así a los lenguajes de programación que utilizan una sintaxis muy parecida al idioma inglés. Los lenguajes de 4ta generación son del tipo no procedural, es decir, el usuario define lo que se debe hacer y no el cómo.

Es interesante que a partir de la creación de estos lenguajes de programación, se cambie la manera en la que se compilan o interpretan estos lenguajes. Este proceso básicamente significa traducir de un lenguaje específico a otro lenguaje, en este caso de un lenguaje que entiende fácilmente un usuario programador, a un lenguaje comprendido por la computadora. Sin embargo, era común que la interpretación dependiera específicamente de la computadora a utilizar, en particular la arquitectura del procesador, y con el auge en evolución de procesadores y el dinamismo en el que surgían nuevos procesadores, la industria tuvo que partir de estándares y se crearon las maquinas virtuales. Así entonces cuando un programador compilaba su programa, lo hacía en una maquina virtual, la cual a su vez traducía al lenguaje propio de la computadora donde estuviera ejecutándose, independiente de la arquitectura del procesador. Y el programador solo se tenía que preocupar con algunas características básicas del procesador, como si su arquitectura es 32 bits o 64 bits. Independiente del fabricante. En la industria surgieron dos maquinas virtuales principales, .NET CLR la desarrollada por Microsoft para arquitectura Windows principalmente, y Java Virtual Machine desarrollada por SUN y otros para ejecutarse abiertamente en diferentes arquitecturas, incluso en arquitectura abierta o libre.

Otra característica interesante de los manejadores actuales de bases de datos es que pueden utilizar y compilar subconjuntos de instrucciones para estas maquinas virtuales, como es el caso del lenguaje Java en el mismo manejador Oracle, o CLR (common language runtime) del .NET para SQL Server, para ejecutar instrucciones C# o VB en el manejador de BD de Microsoft.

Y por último, en la arquitectura de aplicaciones actualmente se incluye una capa de abstracción para manipular y explotar la información de una base de datos, independiente de la aplicación y su arquitectura. Esta capa se conoce como capa de Acceso a Datos, en ella se definen instrucciones en los lenguajes actuales de programación propios del aplicativo a utilizar, y permite integrar instrucciones o elementos del modelo relacional para su manipulación directa en la base de datos. Esta capa ha evolucionado en base a los nuevos lenguajes, anteriormente se utilizaban RPC (llamadas remotas a procedimientos), luego se utilizaron lenguajes orientados a objetos (ODBC’s, JDBC, ADO.NET), luego se utilizaron sentencias que pudieran manipular información estructura en XML, incluso algunos manejadores como Oracle o SQL Server permiten exponer funciones para explotar su información en formato XML, y accesarla vía Servicios XML Web. Actualmente en esta evolución de capas de acceso a datos, se están utilizando modelos de datos directamente integrados en las aplicaciones, utilizando componentes que generan el código a utilizar de manera automatizada, lo cual permite a los programadores basarse en el modelo relacional para integrarlo en su aplicación directamente, algunos ejemplos (Java Hibernate o  ADO.NET Entity Framework).

Como identificar un proyecto con riesgo de fracaso

Las estadísticas del artículo son muy interesantes y bastante reales sobre los proyectos de TI. Y es muy importante contar con la información al día sobre la salud del proyecto. En lo personal encuentro 3 elementos críticos para el éxito o fracaso de un proyecto:

• Comunicaciones inadecuadas: Si importar que metodología o proceso se esté utilizando para controlar y administrar el proyecto, es necesario contar con un eficiente y ágil proceso de comunicaciones, con evidencia real de su realización, que genere entregables que den visibilidad del proyecto. Como mínimo contar con reuniones sino diarias, semanales de avance del proyecto, con documentación clara y concisa (minutas y reportes). Y de ser posible (dependiendo el tamaño y formalidad de la empresa) implementar un proceso automatizado con métricas reales sobre la salud del proyecto.
• Falta de Compromiso: Desde el adecuado patrocinio y financiamiento del proyecto, como el proceso de liderazgo para el continuo enfoque del equipo en los objetivos y resultados del proyecto día con día. Esto derivado de la correcta definición del alcance del proyecto y su detalle a través de la ingeniería de requerimiento.
• Riesgos desatendidos: Comúnmente en los proyectos siempre hay buenas intenciones de que estos se lleven a cabo y se concluyan exitosamente. Sin embargo, la falta de planeación y atención de los riesgos, deriva en falta de asignación temprana en los proyectos para su prevención, corrección, transferencia o eliminación. En particular con los proyectos de TI, implementar un proceso de definición, validación y actualización de arquitectura empresarial (o arquitectura de software/tecnológica, según aplique el alcance del proyecto). Permitirá la planeación e identificación de riesgos derivados de la complejidad de esta arquitectura, de esa manera se podrán asignar recursos y tomar decisiones desde el inicio del proyecto, para controlar estos riesgos.

También es importante aclarar que es posible obtener ciertos beneficios alternativos de los fracasos de los proyectos:

• Catalizador de cambios. Es posible que del fracaso, surjan elementos que indiquen aéreas de oportunidad. Lo cual pueda derivar en una implementación de procesos que permitir mejorar estas aéreas.
• Base de Conocimiento y mejores prácticas aprendidas. Este nuevo conocimiento surge de situaciones negativas, pero apoya la continua mejora y próximas implementación (tanto de proyectos como de procesos).
• Soluciones alternativas o cumplir con algunos requerimientos esperados del proyecto. Es importante medir el valor sobre aquellos requerimientos obtenidos.
• Análisis Holístico. Se recomienda realizar un análisis integral para identificar lo sucedido con el proyecto cubriendo las aéreas de TI y aéreas del Negocio, tanto las afectadas, involucradas, dependientes y participantes en el proyecto.

Como identificar un proyecto con riesgo de fracaso

Las estadísticas del artículo son muy interesantes y bastante reales sobre los proyectos de TI. Y es muy importante contar con la información al día sobre la salud del proyecto. En lo personal encuentro 3 elementos críticos para el éxito o fracaso de un proyecto:

• Comunicaciones inadecuadas: Si importar que metodología o proceso se esté utilizando para controlar y administrar el proyecto, es necesario contar con un eficiente y ágil proceso de comunicaciones, con evidencia real de su realización, que genere entregables que den visibilidad del proyecto. Como mínimo contar con reuniones sino diarias, semanales de avance del proyecto, con documentación clara y concisa (minutas y reportes). Y de ser posible (dependiendo el tamaño y formalidad de la empresa) implementar un proceso automatizado con métricas reales sobre la salud del proyecto.
• Falta de Compromiso: Desde el adecuado patrocinio y financiamiento del proyecto, como el proceso de liderazgo para el continuo enfoque del equipo en los objetivos y resultados del proyecto día con día. Esto derivado de la correcta definición del alcance del proyecto y su detalle a través de la ingeniería de requerimiento.
• Riesgos desatendidos: Comúnmente en los proyectos siempre hay buenas intenciones de que estos se lleven a cabo y se concluyan exitosamente. Sin embargo, la falta de planeación y atención de los riesgos, deriva en falta de asignación temprana en los proyectos para su prevención, corrección, transferencia o eliminación. En particular con los proyectos de TI, implementar un proceso de definición, validación y actualización de arquitectura empresarial (o arquitectura de software/tecnológica, según aplique el alcance del proyecto). Permitirá la planeación e identificación de riesgos derivados de la complejidad de esta arquitectura, de esa manera se podrán asignar recursos y tomar decisiones desde el inicio del proyecto, para controlar estos riesgos.

También es importante aclarar que es posible obtener ciertos beneficios alternativos de los fracasos de los proyectos:

• Catalizador de cambios. Es posible que del fracaso, surjan elementos que indiquen aéreas de oportunidad. Lo cual pueda derivar en una implementación de procesos que permitir mejorar estas aéreas.
• Base de Conocimiento y mejores prácticas aprendidas. Este nuevo conocimiento surge de situaciones negativas, pero apoya la continua mejora y próximas implementación (tanto de proyectos como de procesos).
• Soluciones alternativas o cumplir con algunos requerimientos esperados del proyecto. Es importante medir el valor sobre aquellos requerimientos obtenidos.
• Análisis Holístico. Se recomienda realizar un análisis integral para identificar lo sucedido con el proyecto cubriendo las aéreas de TI y aéreas del Negocio, tanto las afectadas, involucradas, dependientes y participantes en el proyecto.

Discusiones sobre la Alineación Estratégica y TI

Muy interesante el artículo al identificar uno de los principales factores por el cual la alineación entre los objetivos del negocio y las aéreas de tecnologías de información es deficiente. Este factor se refiere a la estructura organizacional aislada. Donde los esfuerzos para cumplir los objetivos de negocio directos o indirectos se realizan aislados y en algunos casos incluso se genera re-trabajo. Otro indicador interesante de este aislamiento, seria que las iniciativas de automatización de procesos únicamente son esfuerzos del área de TI, y no tienen patrocinio adecuado, y por lo tanto el impacto es limitado de estas iniciativas es limitado, y comúnmente desperdiciado, incluyendo esfuerzos robustos como la implementación de BPM o SOA en la organización.

El éxito para la alineación empresarial y las aéreas de TI, se basa en la integración del negocio, eliminando así el aislamiento empresarial. A manera que las iniciativas de automatización de procesos y generación de la arquitectura empresarial se permeen en toda la organización, integrando a los patrocinadores clave desde la concepción de las iniciativas, y controlando el avance de estas iniciativas como se vayan ejecutando. Para lo cual existe ya practicas bastante robustas y completas como COBIT (ValIT y RiskIT), y TOGAF para diseñar, implementar y medir la ejecución de la arquitectura empresarial.

Introducción a COBIT, ValIT y RiskIT

Definición: 

Objetivos de Control para la información y Tecnologías relacionadas (COBIT- Control Objectives for Information and related Technology) es un conjunto de mejores prácticas para el manejo de información creado por la Asociación para la Auditoría y Control de Sistemas de Información,(ISACA - Information Systems Audit and Control Association), y el Instituto de Administración de las Tecnologías de la Información (ITGI - IT Governance Institute) en 1992.

Objetivo:

"Investigar, desarrollar, publicar y promocionar un conjunto de objetivos de control generalmente aceptados para las tecnologías de la información que sean autorizados (dados por alguien con autoridad), actualizados, e internacionales para el uso del día a día de los gestores de negocios (también directivos) y auditores." Gestores, auditores, y usuarios se benefician del desarrollo de COBIT porque les ayuda a entender sus Sistemas de Información (o tecnologías de la información) y decidir el nivel de seguridad y control que es necesario para proteger los activos de sus compañías mediante el desarrollo de un modelo de administración de las tecnologías de la información.

ValIT:

Es un conjunto de documentos que proveen un marco de trabajo para el gobierno de las inversiones en TI, creado por ITGI. Es una declaración formal de los principios y procesos para la administración del portafolio de TI.

Las organizaciones siguen haciendo importantes inversiones en negocios posibilitados por TI: Inversiones en el mantenimiento, crecimiento o transformación del negocio que tienen un componente crítico de TI. La experiencia y un creciente volumen de investigaciones empíricas demuestran que dichas inversiones, cuando se gestionan bien dentro de un marco de gobierno efectivo, generan oportunidades importantes en las organizaciones para la creación de valor.

Muchas organizaciones han creado valor mediante la selección de las inversiones oportunas y la gestión efectiva de las mismas desde la concepción, pasando por la implementación, hasta la realización del valor esperado. Entre los ejemplos se encuentran IBM, que ha podido ahorrar más de 12 mil millones de USD en dos años uniendo las diversas partes de su cadena de suministro, reduciendo así los niveles de inventario, y Southwest Airlines, que ha podido reducir los costes de aprovisionamiento y aumentar los niveles de servicio mediante su proyecto de transformación de la cadena de suministro.

Sin embargo, sin un gobierno efectivo y una buena gestión, estas inversiones generan una oportunidad igualmente significativa para erosionar o destruir valor. De hecho, según una publicación de Gartner de 2002, 2 se desperdicia el 20 por ciento de todos los gastos en TI, representando, a nivel global, una destrucción anual de valor de 600 mil millones de USD.

Una lección fundamental es que la inversión en TI ya no trata solamente de implementar soluciones de TI, sino que cada vez más trata de implementar el cambio posibilitado por TI. Esto implica mayor complejidad y mayor riesgo que en el pasado. Las prácticas de gestión que tradicionalmente se han aplicado ya no son suficientes. El mensaje es claro: las inversiones de negocio posibilitadas por TI pueden dar enormes beneficios, pero solo con los procesos de gobierno y gestión apropiados y el pleno compromiso e implicación de todos los niveles de dirección. Hasta ahora, sin embargo, la dirección no ha tenido un procedimiento claro que indique la forma de considerar las inversiones en TI o de informar sobre o monitorizar el posible éxito o fracaso de dichas inversiones.

Al considerar que existía una falta de guías de inversión y gestión de TI, el IT Governance Institute, trabajando conjuntamente con otros profesionales líderes en la comunidad de negocio y TI, ha lanzado la iniciativa Val IT.

Esta iniciativa, en la que se incluyen investigaciones, publicaciones y servicios de soporte, tiene como objetivo ayudar a la gerencia a abordar este reto, así como garantizar que las organizaciones logren un valor óptimo de las inversiones de negocio posibilitadas por TI, a un coste económico, y con un nivel conocido y aceptable de riesgo. Val IT constituye una extensión y complemento de COBIT, que proporciona un marco de control global para el gobierno de TI.

En concreto, Val IT se centra en la decisión de invertir (¿estamos haciendo lo correcto?) y la realización de beneficios (¿estamos obteniendo beneficios?), mientras que COBIT está enfocado en la ejecución (¿lo estamos haciendo correctamente, y lo estamos logrando bien?).

El gobierno efectivo parte del liderazgo, compromiso y respaldo desde arriba. Sin embargo, dicho liderazgo, aunque es crítico, no es suficiente. En Val IT, se da soporte al liderazgo estableciendo un marco global, con un complemento completo de procesos de soporte y otros materiales de orientación desarrollados para ayudar al consejo / directorio y a la dirección ejecutiva a comprender y desempeñar sus papeles relacionados con las inversiones de negocio posibilitadas por TI.

En Val IT, soportado en el marco de control en COBIT, se proporciona una fuente única, creíble y codificada para dar soporte a la creación de un valor de negocio real a partir de las inversiones posibilitadas por TI. Val IT es relevante para todos los niveles de dirección a todo lo ancho tanto del negocio como de TI, desde el Director General y el consejo / directorio hasta todos aquellos involucrados directamente en los procesos de selección, aprovisionamiento, desarrollo, implementación, despliegue y realización de beneficios. Val IT contiene guías esenciales para todos.

RiskIT



El marco de los riesgos de TI, RISK IT, se complementa con COBIT,  que proporciona un marco integral para el control y la gestión de las organizaciones de soluciones y servicios de TI. Aunque COBIT establece las mejores prácticas para la gestión de riesgos proporcionando un conjunto de controles para mitigar los riesgos de TI, RISK IT establece las  mejores prácticas con el fin de establecer un  marco para las organizaciones para identificar, gobernar y administrar los riesgos asociados a su negocio.


El marco de riesgos de TI es utilizado para ayudar a implementar el gobierno de TI, y las organizaciones que han adoptado (o  están planeando adoptar) COBIT como marco de su gobierno de TI pueden utilizar RISK IT para mejorar la gestión de sus riesgos.

Referencia: Portal ISACA.
Presentación ValIT