Gestión de datos

Conociendo el DMBOK

sg — Fri, 16 Mar 2018 06:06:50 +0000

Conociendo el DMBOK

sg Fri, 03/16/2018 - 00:06

Publicado en

SG #56

Gestión de datos

Autor

Oswaldo Baez

Los avances tecnológicos contribuyen a aumentar la competitividad en distintos sectores y llevan a las empresas a buscar nuevas opciones de diferenciación. En el siglo pasado, ese diferenciador se manifestaba principalmente en los productos y capacidad de producción o administración de las empresas. Hoy en día, ese diferenciador es la información; es decir, cada vez hay más y más organizaciones públicas y privadas que buscan mantenerse competitivas (eficientes y eficaces) mediante el aprovechamiento de sus datos e información.

Para conseguir el objetivo de mejorar su negocio por medio del aprovechamiento de datos, es común que las organizaciones se vuelquen en iniciativas de análisis de información (actualmente llamada “ciencia de datos”), con el propósito de obtener cualquier tipo de beneficio que sea factible de estos recursos. Desafortunadamente, quienes buscan seguir este “atajo” sin sustentarlo con una estrategia adecuada terminan obteniendo resultados de poco valor al negocio. Para lograr el éxito, las organizaciones deben considerar cómo gestionar su información de forma holística y efectiva, asegurando en todo momento que se cumpla con la calidad esperada, a fin de que esto impacte positivamente a todos niveles de su operación.

Afortunadamente, desarrollar o mejorar una cultura de gestión de datos e información, no tiene que convertirse en un reto que se inicie desde una hoja en blanco; es decir, no hay necesidad de “reinventar la rueda”. De hecho, literalmente, la “rueda de la gestión de datos” ya está definida, y se puede apreciar en la figura 1.

Figura 1. Rueda de gestión de datos. DAMA, 2013.

Estas prácticas, definidas por la Data Management Association (DAMA), han sido documentadas en la guía conocida como DAMA-DMBOK (Data Management Body of Knowledge), la cual al paso del tiempo se ha convertido en una importante referencia en esta materia.

Actualmente, dicha guía se encuentra en su segunda edición, publicada en julio del 2017, proponiendo las diferentes áreas funcionales que componen la gestión de datos e información. La guía es un compendio de mejores prácticas y terminología, sin detallar métodos y técnicas específicas, manteniéndose agnóstica a tecnologías y marcas. Su contenido es un apoyo para organizaciones interesadas en, por ejemplo, implantar y/o robustecer su marco de gobernanza de datos e información, mejorar la calidad de su información, hacer transparente la existencia de la información y como está se relaciona, adoptar esquemas para la gestión de sus metadatos, desarrollar una capacidad analítica (data science), entre otras.

Figura 2. DAMA-DMBOK, 2da edición

Algunos de los aspectos importantes de la nueva edición son los siguientes:

El capítulo de “Ética en la Gestión de Datos” propone un tema central y neurálgico: la conducción que debe regir a todo el personal involucrado en el manejo de la información.
El capítulo de “Big Data y Data Science” se refiere a la relación del gobierno de datos con éstos temas fundamentales. Para ello, establece una línea base para identificar un plan de acción encaminado a la implementación de proyectos y actividades de análisis de información (data science), en conjunto con la viabilidad de contar con una estrategia de gestión de datos de distintas fuentes disponibles dentro de las organizaciones considerando amplitud, velocidad de emisión y variedad de formatos (big data).
También, aborda el tema de evaluar y evolucionar la Madurez de la gestión de datos dentro de la organización a través del capítulo “Data Management Maturity Assessment” .
Expone los roles ideales y necesarios para favorecer un enfoque orientado a los datos de una organización en el capítulo “Data Management Organization and Role Expectation”.
En el capítulo “Data Management and Organizational Change Management” analiza dos enfoques de gestión del cambio considerando la propuesta de hacer un enfoque hacia la gestión de datos e información dentro de una organización tomando la propuesta del DMBOK.

Conclusión

Esta Guía de DAMA presenta una estrategia completa para llevar a las organizaciones a un enfoque y orientación a la información o los datos.

Es importante mencionar que en México ya existe una representación de DAMA desde mayo del 2016. Es una Asociación, con el nombre de DAMA Capítulo México, cuya misión, acciones y objetivos están encaminados a promover y facilitar el desarrollo de la Cultura de Gestión de Datos e Información en el país. Los interesados deberán dirigirse a http://www.dama.org.mx/ para obtener mayor información del DAMA-DMBOK y involucrarse en el desarrollo de la Comunidad de los Profesionales de los Datos o la Información en México.

Bio

El Dr. Oswaldo Baez se desempeña como Arquitecto de Información Financiera en Banco de México, y es miembro del capítulo México de DAMA. Es egresado del Instituto Politécnico Nacional y cuenta con un Doctorado en Ciencias Computacionales por la Universidad de York.

Exportando Sistemas Relacionales a Sistemas Columnares Distribuidos

sg — Mon, 21 Aug 2017 20:31:18 +0000

Exportando Sistemas Relacionales a Sistemas Columnares Distribuidos

sg Mon, 08/21/2017 - 15:31

Publicado en

SG #55

Gestión de datos

Autor

Hugo de la Mora

El manejo de información masiva se ha hecho cotidiano, y una estrategia común para analizar grandes cantidades de datos es moverla de las bases de datos relacionales tradicionales (RDBMS) hacia bases de datos columnares distribuidas.

En el presente artículo muestro los pasos necesarios para migrar información relacional a una infraestructura de Hive en Hadoop. La idea básica es importar grandes datos de un origen relacional como Microsoft SQL Server a un almacenamiento en Hadoop como Hive o HDFS, teniendo la posibilidad de analizar esa información a través de Hue.

Panorama

Para esta labor utilizaremos Apache Sqoop [1], una herramienta precisamente creada para mover datos entre bases de datos estructuradas y Hadoop. Sqoop trabaja con tablas individuales, cada fila de una tabla se trata como un registro en HDFS. Todos los registros se almacenan como datos de texto en archivos de texto, en Hive o HBase (ver figura 1).

Figura 1. Flujo de Sqoop

Prerrequisitos

Para el propósito de este tutorial voy a suponer que ya se tiene instalado y funcionando tanto un ambiente de SQL Server como otro de Hadoop. Si no tienes el de Hadoop, para propósito de aprendizaje puedes utilizar una máquina virtual de Cloudera Quickstart [2]. En tu ambiente de Hadoop necesitas tener instalado Sqoop. Checa si ya tienes, invocando el comando “sqoop” desde la línea de comandos. Si no lo tienes, lo más conveniente es instalarlo por medio del manejador de paquetes de tu sistema operativo (en el caso de OSX está disponible para Homebrew).

Preparando la conexión

Nos conectaremos a SQL Server por medio de JDBC. Para que esto funcione primero necesitamos habilitar TCP/IP en nuestra instancia. Esto se hace desde el SQL Server Configuration Manager.

Posteriormente vamos a descargar el driver de JDBC de SQL Server en nuestro ambiente Hadoop. Este se obtiene del sitio web de Microsoft y al momento de escribir este artículo la versión más reciente se obtiene en http://swgu.ru/t3 . Dentro del paquete encontraremos una carpeta jre7 y otra jre8 y dentro de cada una hay un archivo .jar que corresponde al driver. Así que seleccionaremos el archivo que corresponda a la versión de java que estemos usando y lo copiaremos en /var/lib/sqoop . Si esta carpeta no existe, la creamos y le asignamos los permisos necesarios como se ve a continuación.

$ mkdir -p /var/lib/sqoop
$ chown sqoop:sqoop /var/lib/sqoop
$ chmod 755 /var/lib/sqoop
$ sudo cp sqljdbc_6.0/enu/jre8/sqljdbc42.jar /var/lib/sqoop/

Importando datos

Para verificar que podemos conectarnos de nuestro ambiente Hadoop a SQL Server vamos a comenzar listando las bases de datos. Para ello utilizamos sqoop list-databases con los argumentos de conexión requeridos (en este ejemplo nuestro SQL Server está disponible en la ip 192.168.56.1 y exponiendo el puerto 1444, y tiene un usuario hadoopUser con contraseña hadoop… ).

$ sqoop list-databases --connect jdbc:sqlserver://192.168.56.1:1444 --username hadoopUser --password hadoop...

Con lo anterior obtendremos una lista de las bases de datos.

A continuación importamos la base de datos y tablas que queremos (en este caso la tabla employee de la base de datos sqoopDB).

$ sqoop import --connect "jdbc:sqlserver://192.168.56.1:1444;username=hadoopUser; password=hadoop...; database=sqoopDB" --table employee --hive-import

Por cierto, si quisieramos importar todas las tablas de la BD sin necesidad de especificarlas una por una utilizaríamos sqoop import-all-tables –connect “jdbc://sqlserver….” --hive-import

Si quieres revisar lo que se importó a Hadoop, puedes hacerlo por medio Hue, una interfaz gráfica web para navegar Hadoop.

Hagámoslo repetible

Si quisieramos estar realizando esta tarea frecuentemente, lo más conveniente es crear un “job” en sqoop que simplemente podemos invocar. Para ello usamos sqoop job con el argumento --create y el resto de la información para conectarse a SQL Server.

$ sqoop job --create jobImpEmpl -- import --connect "jdbc:sqlserver://192.168.56.1:1444;username=hadoopUser;password=hadoop...;database=sqoopDB" --table employee --hive-import

Lo más probable es que no querramos importar todos los datos cada vez que ejecutamos la tarea, sino que solo querramos importar los datos nuevos o modificados. Para lograr esto usamos la opción --incremental e indicamos la columna con el timestamp a verificar.

$ sqoop job --create jobImpEmplInc -- import --connect "jdbc:sqlserver://192.168.56.1:1444;username=hadoopUser;password=hadoop...;database=sqoopDB" --table employee --incremental lastmodified -check-column creationdate --hive-import

Ya creamos los jobs, pero todavía no los ejecutamos. Para ejecutar un job utilizamos sqoop job --execute <nombre-del-job>. Para ver los jobs que tenemos definidos podemos usar sqoop job --list. Y si queremos consultar los detalles de algún job usamos sqoop job --show <nombre-del-job>.

Ejecución periódica automatizada

Si deseamos estar importando datos de manera periódica y automatizada, lo más conveniente es programar la tarea por medio de Oozie, que es una herramienta del ecosistema Hadoop que permite gestionar workflows desde una interfaz web.

Oozie tiene un editor en el cual defines el workflow. Si ya tienes el comando de sqoop que deseas ejecutar simplemente puedes “pegarlo” en un campo de texto al crear tu workflow. Después de eso podemos crear “coordinadores” para calendarizar el envío de información al sistema HDFS (ver figura 2).

Figura 2. Coordinar workflows en Oozie

Conclusión

Se ha mostrado de una forma sencilla la extracción de datos desde un popular ambiente de bases de datos relacionales hasta un sistema columnar como Hive.

Referencias

Bio

El MSC Hugo Enrique De La Mora Carrillo (@hugodelamora) es Chief Information Security Officer en CONTPAQi. Anteriormente ha trabajado con sistemas distribuidos, big data, desarrollo para cloud y móvil.

Resolviendo Dilemas en un Pipeline de Data Science

sg — Fri, 04 Mar 2016 23:01:49 +0000

Resolviendo Dilemas en un Pipeline de Data Science

sg Fri, 03/04/2016 - 17:01

Publicado en

SG #50

Gestión de datos

Autor

Al iniciar un proyecto de Data Science se tienen que tomar diversas decisiones para que cada etapa del flujo de trabajo o pipeline cumpla con las metas especificadas. El pipeline que definamos depende de factores tales como la experiencia que se tiene con las plataformas, herramientas, lenguajes o algoritmos específicos así como de la investigación previa y referencias externas. Lo ideal es lograr un equilibrio entre la rapidez que nos brinda el uso de los elementos conocidos y la incorporación de herramientas y conocimiento nuevo que permita lograr resultados de forma más rápida y eficiente. En este artículo abordaremos algunos dilemas a los que generalmente nos enfrentamos en la definición de un pipeline y en nuestra experiencia, qué aspectos debemos considerar para tomar la mejor decisión.

Aunque las etapas de un pipeline están muy definidas, todas están ligadas a un objetivo. Y es precisamente la ausencia de un objetivo claro una de las principales causas de los problemas. Para definir ese objetivo debemos cuestionarnos aspectos como: ¿cuál es el resultado tangible esperado del proyecto?, ¿cuáles son los beneficios que generaría el proyecto en caso de ser exitoso?, ¿a quién van dirigidos los resultados? La claridad con la que podamos responder a estas preguntas es fundamental para reducir los contratiempos que invariablemente surgirán.

A lo largo del proyecto nos encontraremos con diversas disyuntivas que nos obligarán a tomar decisiones. Es conveniente reflexionar antes de tomar una decisión impulsiva que haga que ese proyecto fascinante, divertido y retador se transforme en nuestra peor némesis. A continuación se describen algunos dilemas comunes a los que nos hemos enfrentado y que se asocian a las diversas etapas de un pipeline.

Adquisición

Cuando inicia un proyecto, uno de los primeros puntos a tratar es, ¿qué información necesitamos para lograr los mejores resultados? En las reuniones iniciales generalmente se hacen acuerdos sobre la información a utilizar y sus respectivas fuentes. Sin embargo, a medida que transcurren los días no es raro que se presenten las siguientes situaciones:

• Nos damos cuenta de que no tenemos toda la información que se definió en un principio.

• Necesitamos información adicional.

• No tenemos acceso a todas las fuentes.

Es recomendable resolver estas cuestiones lo antes posible. Aunque sabemos que nos encontramos en un proceso iterativo en el cual es posible que hagamos pruebas con datos diferentes a los originales, es mejor tener un conjunto de datos base.

Una situación común es que cuando el proyecto ya se encuentra avanzado se descubren nuevos datos que podrían ser útiles al modelo. Incorporar nuevos datos podría mejorar el resultado pero retrasaría el tiempo de entrega, ¿qué hacer? Esta es una decisión de gestión de proyecto más que nada y podrá variar dependiendo del contexto particular. Sin embargo, nuestra recomendación es guiarse por los lineamientos del desarrollo iterativo, terminando la iteración actual con los datos que se tenían contemplados al inicio de dicha iteración, y evaluar si tiene sentido incorporar los nuevos datos en iteraciones posteriores. Siempre debemos tener en cuenta que al final del proyecto es preferible tener un modelo útil aunque lleve más tiempo, que terminar a tiempo con un modelo inútil.

No tengamos falsas expectativas, el caso ideal en el cual tenemos desde el inicio todos los datos perfectos y completos es solamente una ilusión.

Exploración y entendimiento

Cuando existen tiempos reducidos podemos tener la tentación de omitir pasos, especialmente en la fase de exploración. A fin de cuentas, confiamos en las fuentes, ¿qué podría pasar? Aun cuando tengamos datos muy limpios, es necesario asegurarse de que no contienen información que nos pueda llevar a resultados erróneos. Por ejemplo, podemos encontrar rangos de edades irreales y ciudades que no existen, entre otros posibles hallazgos que si no los notamos a tiempo nos harán padecer en fases posteriores. Llevar a cabo la exploración no debe ser un dilema, debe ser un paso riguroso antes de seguir con el proyecto.

Pero explorar los datos no lo es todo. Debemos estar seguros de que entendemos cada variable o atributo. Si contamos con un diccionario de datos la labor se facilita pero si no contamos con él, vale la pena no suponer nada e investigar con el administrador de base de datos de su preferencia sobre el significado de los datos. No hacerlo puede tener un costo elevado.

Pre-proceso, transformación, manipulación

Esta fase requiere que tomemos decisiones con respecto a las transformaciones que nos convienen para obtener los mejores resultados. Es necesario conocer bien los datos: ¿de qué tipo son?, ¿qué efecto tienen estos tipos en las transformaciones? Existen detalles sutiles que no deben dejarse para después. No es lo mismo una variable tipo fecha que una variable numérica; no es lo mismo una variable tipo factor que una tipo texto. Aunque visualmente se vean iguales, si no damos a las variables el formato adecuado podemos consumir tiempo valioso.

En cuanto a los valores atípicos (outliers), también nos enfrentamos a dilemas: ¿los quitamos?, ¿los dejamos?, ¿cuáles son las consecuencias de estas decisiones? Como consideraciones generales podemos decir que si los valores atípicos tienen significado, no se deben eliminar. Si por el contrario, valores atípicos distorsionan la realidad entonces deben eliminarse. Imaginemos que estamos obteniendo perfiles de usuario para ciertos productos. Si introducimos edades negativas o mayores de 200 años los modelos resultantes mostrarán patrones de usuarios inexistentes. Por supuesto, hay diversas situaciones y tratamientos que pueden darse a valores atípicos. El punto clave es que no debe restarse importancia a las decisiones sobre estos valores.

Análisis y modelado

Ya que nuestros datos están preparados y listos, la pregunta es ¿qué tipo de análisis necesito? Esto depende fundamentalmente del objetivo del análisis. Existen infinidad de técnicas y algoritmos que pueden ser útiles ya sea como base o bien podemos diseñar un nuevo algoritmo ad-hoc a nuestro problema. En cualquier caso, la decisión de la técnica o algoritmo a aplicar tiene su origen en el objetivo. Y si no tenemos claro el objetivo es muy difícil esperar tener buenos resultados.

Un problema frecuente es que podemos caer en la tentación de querer aplicar algoritmos o técnicas emergentes y creer que si no lo hacemos no somos competitivos. Por ejemplo, ¿de verdad Deep Learning es la solución a nuestro problema? Tenemos que encontrar argumentos sólidos para tomar decisiones de este tipo. Una estrategia útil es empezar por la solución más simple e ir incrementando el nivel de sofisticación de la solución en la medida que lo requiera el proyecto, no en la medida de nuestro ego.

Comunicación y operación

Y llegamos a la fase en la que ya tenemos resultados buenos. ¡Si, lo logramos! Después de varias iteraciones en las fases anteriores hemos llegado a la parte de presentar los resultados. La interrogante es: ¿cómo presentarlos?, la respuesta depende de diversos factores: ¿el resultado es un reporte?, ¿es un producto?, ¿es un servicio?, ¿es un dashboard?, ¿es un resultado final o una iteración?, ¿para quién son?

Aunque estemos muy felices con nuestros resultados, una presentación inadecuada puede ser desastrosa si no mostramos los aspectos de interés para cada público. Es conveniente elaborar dos presentaciones base:

• Presentación técnica: debe incluir detalles de análisis e implementación para que sea reproducible. Debe incluir referencias a los repositorios donde se ubica el proyecto para que los interesados puedan repetir los experimentos y análisis. En este tipo de presentación es importante contestar la pregunta: ¿cómo se obtuvieron los resultados?

• Presentación no técnica: debe omitir detalles de análisis e implementación e incluir resultados duros y cómo aplicar esos resultados para lograr el objetivo del negocio. Este objetivo puede traducirse en beneficios económicos, incremento en ventas, campañas de marketing, incremento en número de usuarios, entre otros. La pregunta a responder es: ¿qué beneficio se obtiene con esos resultados?. En este tipo de presentación se debe ser cuidadoso en no utilizar tecnicismos a menos que sea estrictamente necesario. Es nuestra responsabilidad describir las cosas de modo que esté al alcance de profesionales de diversas áreas. Y eso no es una tarea trivial.

Dilemas técnicos

La implementación de un producto basado en análisis de datos masivos provoca retos interesantes a resolver dado que los sistemas productivos generalmente no están diseñados para el tipo de carga que implica. Por ejemplo, una base de datos que soporta una aplicación web de alta escalabilidad puede responder adecuadamente cuando se tienen millones de peticiones concurrentes pero cuando se necesita consultar para análisis de datos o para un producto basado en Big Data puede poner en riesgo los sistemas productivos. ¿Qué hacer entonces?, ¿Implementar una solución batch/offline sacrificando posible utilidad de una solución en tiempo real para el usuario?, ¿replicar la base de datos a otra de sólo lectura o con fines exclusivos para el producto de data science?, ¿pagar una nueva instancia en caso de bases de datos comerciales o escoger una alternativa abierta? ¿exportar simplemente a archivos de texto y dejar que los scripts hagan el trabajo pesado? ¿utilizar cómputo en la nube para el procesamiento, y si es así, cómo hacer segura la información privada que saldrá de nuestros servidores?

Durante la fase de diseño del sistema, uno de los primeros dilemas que se pueden encontrar en las implementaciones es el tipo de arquitectura en la que va a correr. En mayor parte se cuenta con dos opciones: utilizar la infraestructura local o utilizar las diferentes servicios que ofrecen procesamiento en la nube. En este caso es muy importante conocer las ventajas y desventajas que cada una de estas implementaciones ofrece, además de las necesidades propias del sistema a implementar y que pueden afectar en menor o mayor medida a la decisión que vamos a tomar.

Lo primero que tenemos que tomar en cuenta es la capacidad de procesamiento necesaria para la implementación de nuestra solución de data science, de esta manera podemos estimar si los servidores propios son lo suficientemente capaces para soportar la carga extra que vamos a agregar al nivel de trabajo diario. En caso de que el procesamiento no sea factor, se debe de tomar en cuenta la cuestión monetaria ya que las soluciones en la nube involucran un gasto que comienza siendo moderado pero rápidamente puede llegar a cifras altas dependiendo de las instancias que necesitemos crear y el tiempo que las tengamos operando.

Además de las barreras económicas y de procesamiento, existen requerimientos específicos del sistema. En este caso si se elige una implementación de cloud, es necesario prever la integración necesaria con el sistema que tenemos local. Necesitamos saber si es necesaria la replicación de información almacenada en bases de datos locales y que se tendrá que estar replicando de manera constante a la solución en la nube, además de otros aspectos como la cantidad de información que será transferida desde el ambiente local a la nube y viceversa.

Si por otra parte se opta por una implementación local, es necesario prever desde un principio la necesidad futura ya que si es necesario escalar la implementación y no se cuenta con la infraestructura necesaria para hacerlo es posible que se requiera una reimplementación del sistema. Esta decisión puede llevar al consumo de tiempo y recursos que se pudieran haber invertido en otro tipo de solución.

Conclusión

Un proyecto de data science representa un reto en distintos niveles y los cuestionamientos son inevitables en el transcurso de las diversas etapas del mismo. Sin embargo, por sobre cualquier aspecto técnico está el factor humano. La colaboración, capacidad, motivación y buena disposición de los miembros del equipo son los factores clave que determinarán si el proyecto tendrá éxito o no.

Bio

Blanca Vargas, Andrés Arteaga y Eduardo Flores forman parte del equipo de Innovación y Desarrollo en OCC Mundial. Blanca se desempeña como Data Scientist, Andrés como Data Engineer y Eduardo como Gerente de Desarrollo e Innovación.

Análisis de datos: Cuando los hechos no son la realidad

hmcuesta — Mon, 07 Jul 2014 23:17:45 +0000

Análisis de datos: Cuando los hechos no son la realidad hmcuesta Mon, 07/07/2014 - 18:17

Publicado en

SG #44

Gestión de datos

Autor

Héctor Cuesta

Hace ya varios años que se me dio la oportunidad de publicar mi primer artículo, en la revista Software Guru número 28 y el gusto por escribir no me ha dejado desde esa época.

El año pasado tuve la oportunidad de ser autor de un libro[1] para la editorial Packt Publishing, acerca de una de mis grandes pasiones, el Análisis de Datos. En el libro exploro una gran cantidad de algoritmos y ejemplos concretos, siempre tratando de que los capítulos sean auto-contenidos. Debido a mi naturaleza de Ingeniero de Software siempre trato de expresarme con código así que encontraran una gran cantidad de código en cada capítulo. Para el libro, utilizo el lenguaje Python, aprovechando librerías para el análisis de datos y machine learning como Pandas, SciPy, NumPy, matplotlib y mlpy. Para el procesamiento de datos utilizo MongoDB por su flexibilidad y su soporte al paradigma MapReduce y para visualización presento múltiples ejemplos con D3js. En la sección de Biblioteca de la presente edición encontrarán más sobre mi libro “Practical Data Analysis”.

Análisis de Datos

El análisis de datos es el proceso en donde datos crudos son ordenados, limpiados y transformados, con la finalidad de ser usados en métodos que ayuden a explicar el pasado y a predecir el futuro. Sin embargo el análisis de datos no tiene que ver con simplemente procesar números, más bien tiene que ver con hacer preguntas y encontrar respuesta de valor a partir de los datos.

El uso que se le da de forma general al análisis de datos es: el de explicar un fenómeno a través de extraer proporciones, distribuciones y patrones. Cualquier tipo
de fenómeno, ya sea natural, artificial o social, estos fenómenos pueden ser medidos y persistidos en un “dataset”. El entender tus datos generalmente requiere una
combinación de habilidades analíticas, conocimiento del dominio y esfuerzo. El cómputo nos provee de herramientas que facilitan la extracción, limpieza, procesamiento e interpretación de dichos datasets. Herramientas como SQL, R, MongoDB y Hadoop nos permiten manipular datos con diferentes naturalezas y a diferentes escalas. Sin embargo el análisis de datos no es algo nuevo y como vemos en la figura 1 se puede de forma clásica decir que: Si buscamos las causas en los datos estamos usando métodos estadísticos y si queremos extrapolar los datos desde las causas estamos frente a modelos probabilísticos.

Figura 1. Forma clásica del análisis de datos.

El análisis de datos se puede dividir en 3 áreas generales: descriptivo, prescriptivo y predictivo.

El análisis descriptivo es el primer paso que debemos realizar para poder darnos una idea general de la distribución de nuestros datos y de aparentes patrones, para esto podemos ayudarnos de la visualización.

En contraste el análisis prescriptivo nos puede guiar a crear mejores modelos de datos este tipo de análisis no se utiliza directamente, más bien nos sirve para confirmar nuestra intuición acerca de un problema particular, técnicas de reducción de datos como PCA (Análisis de Componente Principal) nos permiten reducir la complejidad del problema y sirven en sí mismos como una forma de clasificación.

Por último el análisis predictivo nos ayuda a desarrollar modelos a través de entender los datos y las circunstancias en las que estos son creados.

Visualización

La visualización es una forma rápida de adentrarnos en datasets (pequeños o grandes) para describir, resumir y explorar de forma directa listas de datos que de otra forma sería muy difícil ver. Algunas de las ventajas de la visualización de datos son:

La detección de errores.
Encontrar patrones como tendencias.
Ayudarnos a seleccionar un tipo de modelo apropiado.
Determinar relaciones entre variables.

Sin embargo la visualización es sólo una herramienta del análisis y no un substituto de las habilidades analíticas, o substituto para la estadística o para los modelos predictivos. El Capítulo 3 del libro se dedica enteramente a la Visualización de múltiples tipos de datos con D3js que es una librería de javascript que facilita la visualización vía web que de paso es muy atractiva estéticamente hablando.

Análisis Predictivo

Hay una colección de algoritmos que intentan derivar información predictiva directamente de los datos. La construcción de modelos predictivos tiene por objetivo asistir en las decisiones del mundo real. En el libro me enfoco principalmente en estas familias de algoritmos proveyendo de ejemplos claros implementados en Python o MongoDB, pueden encontrar los códigos de todo el libro disponibles a través de GitHub[2].

Clasificación (Aprendizaje Supervisado)

En la clasificación el algoritmo asigna cada registro a una categoría previamente definida. Hay cuatro tipos de algoritmos para los diferentes problemas enfrentados por el análisis predictivo. Se considera aprendizaje supervisado debido a que las clases son conocidas de antemano, por ejemplo: Spam o No-Spam, Transacción Válida o Transacción Fraudulenta.

En el Capítulo 4 desarrollo un ejemplo de clasificación de Spam a través del algoritmo Naive Bayes y el Capítulo 11 desarrolla un modelo para determinar el sentimiento
(Sentiment Analysis) de mensajes de Twitter usando NLTK que es una librería para procesamiento de lenguaje natural.

Por último en el Capitulo 8 doy una breve introducción a las Máquinas de Soporte Vectorial (SVM) que son uno de los algoritmos más utilizados para clasificación ya que ofrecen excelentes resultados globales. Las SVM utilizan una frontera de decisión (como se muestra en la figura 2) y se apoya de puntos geométricos (Kernels) para crear vectores que se encuentren cerca de la frontera, esto para poder trazar de forma clara donde se dividen las clases de datos (define dónde se separan los puntos rellenados de los vacíos). Ver Figura 2.

Figura 2. Puntos geométricos (Kemeis)

Agrupación (Aprendizaje No-Supervisado)

En los algoritmos de agrupación los datos son organizados en clústeres, por número de categorías, forma y tamaño. Se le llama no supervisados debido a que los datos de los clústeres no son conocidos de antemano. El Capítulo 10 aborda como extraer información de Facebook en forma de un Grafo Social, para después utilizar algoritmos de agrupamiento para poder encontrar subcomunidades como “compañeros de escuela” o “familiares cercanos” sin saber de antemano el número de grupos.

Recomendaciones

Los sistemas de recomendación pueden ser vistos como una forma de agrupamiento donde podemos empezar desde un epicentro (un producto o una persona) y buscamos registros similares o relacionados con el epicentro. Las recomendaciones pueden ser explícitas del comportamiento humano. ¿Quiénes son mis amigos más cercanos?, ¿qué producto me conviene mas de acuerdo a mis preferencias?, ¿qué película me gustaría ver mañana?

El Capítulo 5 muestra paso a paso como crear un Motor de Búsqueda de imágenes sin usar metadatos y recomienda las imágenes más parecidas a la que buscamos.

Predicción de Series de Tiempo

Aquí aplicamos técnicas estadísticas para predecir el siguiente valor de una serie de mediciones con una periodicidad establecida.

En el Capítulo 7 presento un modelo basado en la serie de tiempo de todos los cambios en el precio del oro de los últimos
20 años y propongo una forma de predecir el valor para el siguiente mes.

Me gustaría terminar con palabras del famoso estadista George E. P. Box “todos los modelos están mal, pero algunos son útiles”.

Referencias

[1] Libro Practical Data Analysis http://bit.ly/1co6hOZ
[2] https://github.com/hmcuesta/PDA_Book

Bio

Hector Cuesta-Arvizu (@hmcuesta) es autor del libro “Practical Data Analysis” de la Editorial Packt Publishing. Provee servicios de consultoría en Ingeniería de Software y Análisis de Datos, adicionalmente se desempeña como instructor para NYCE en certificaciones de Desarrollo e Ingeniería de Software. Cuenta con maestría en ciencias de la computación y ha sido Revisor Técnico en los libros “Raspberry Pi Networking Cookbook”, “Raspberry Pi Robotic Projects” y “Hadoop Operations and Cluster Management” para Packt Publishing.

Data Grids: La clave para manejar gran cantidad de información móvil

sg — Mon, 23 Sep 2013 02:00:44 +0000

Data Grids: La clave para manejar gran cantidad de información móvil sg Sun, 09/22/2013 - 21:00

Publicado en

SG #41

Gestión de datos

En el año 2012, las empresas en general contaban con la suficiente capacidad de base de datos para manejar y procesar la actividad diaria de sus clientes; sin embargo, analistas de IDC han pronosticado un incremento masivo en el uso de Internet móvil en los teléfonos inteligentes y tabletas. Esta tendencia y el aumento de datos móviles, se incrementa aún más por los sistemas interconectados y distribuidos como los que se encuentran en los automóviles, en los electrodomésticos y en los sensores de servicios. Este continuo crecimiento de los volúmenes transaccionales combinados en la llamada “Internet de las cosas”, implicará que los sistemas de base de datos tradicionales se vean limitados en un futuro cercano. Hoy, las empresas buscan escalar los sistemas sin perder rendimiento y aprovechar la ventaja y oportunidad comercial que ofrece Internet móvil. Como los niveles de datos tradicionales son demasiado rígidos, complejos y costosos para enfrentar el desafío de los datos móviles, las grillas de datos en memoria (in-memory data grids) están diseñadas para ofrecer los niveles necesarios de rendimiento y flexibilidad a escala.

Como resultado, las grillas de datos en memoria se están convirtiendo en una tendencia que sirve para modernizar el software y adaptarse a las complejas exigencias en términos de rendimiento. A continuación, se exponen diversas razones por las cuales esta tecnología está creciendo en adopción por el mercado:

Brinda información precisa en tiempo real: contar con acceso en tiempo real a la información precisa, marca la diferencia entre las decisiones acertadas y las erróneas. Los data grid acercan los datos a la aplicación, proveen tolerancia ante fallos y permiten un acceso rápido y de baja latencia a la información crucial para el negocio.

Alcanza altas expectativas en tiempo de actividad y capacidad de respuesta: para que los clientes permanezcan fieles y comprometidos, las aplicaciones deben funcionar con coherencia y prestar un servicio ininterrumpido; incluso durante los momentos de máxima actividad y de picos de tráfico imprevistos. Un data grid puede acelerarse y desacelerarse en forma elástica en los nodos distribuidos ayudando a cumplir con los tiempos de respuesta requeridos.

Procesa grandes volúmenes de transacciones: cada vez más negocios se realizan mediante aplicaciones en línea, lo cual aumenta la actividad web y obliga a las aplicaciones a manejar volúmenes de transacción sin precedentes y siempre en aumento. A medida que la cantidad de datos crece, las actividades de lectura y escritura en los
depósitos tradicionales de back-end pueden convertirse en cuellos de botella para el rendimiento de las aplicaciones. Los data grids actúan como capas intermedias entre los depósitos relacionales y los frontends para cumplir con los requerimientos de conservación de datos e impulsar un rendimiento sumamente rápido y escalable.

Se integra eficientemente con un nivel de datos complejo y rígido: la implementación de nuevas aplicaciones o actualizaciones debería ser un proceso ágil y simple. Data grids disminuyen los costos fijos y los dolores de cabeza asociados a la integración de niveles de datos, permitiendo a las empresas una rápida salida al mercado.

Interopera en entornos informáticos mixtos: las empresas de hoy en día poseen entornos informáticos diversos. Las aplicaciones y la infraestructura pueden encontrarse en el lugar, en la nube, ser heredados o contemporáneos. Los data grids pueden actuar como capa de abstracción de datos y ofrecer la flexibilidad de trabajar en una variedad de entornos, aplicaciones, plataformas y bases de datos.

Una grilla de datos en memoria es una solución de almacenamiento que permite a las aplicaciones cumplir con los exigentes requerimientos de rendimiento, disponibilidad, confiabilidad y escalamiento flexible. Puede actuar como capa intermedia entre la base de datos relacionales (RDBMS) y la aplicación, manteniendo datos que son intrínsecamente transitorios o temporales, o que son necesarios para el acceso veloz, el acceso frecuente o el acceso entre múltiples geografías. El RDBMS luego puede liberarse para almacenar datos a los que rara vez se accede o son modificados.

¿En dónde se puede utilizar?

En pocas palabras, el data grid puede actuar como “supercargador” de una aplicación. Aumenta el rendimiento de la aplicación para adaptarse a grandes volúmenes de transacciones y a picos de actividad con velocidades
en memoria. Y debido a su naturaleza distribuida y tolerante ante fallos, las grillas de datos son ideales para dar soporte a los negocios globales descentralizados de hoy en día.

En la actualidad, data grid puede utilizarse en una gran variedad de industrias, como por ejemplo al brindarle al cliente una experiencia sin contratiempos en diferentes aplicaciones móviles y de la Web, al lograr un rendimiento y un escalamiento confiable frente a las fluctuaciones estacionales del negocio, o al reducir la carga de las bases de datos relacionales tradicionales a fin de ofrecerles a los usuarios servicios donde el factor tiempo es crucial. Las tecnologías de data grid también son utilizadas cada vez más en compañías internacionales para administrar y distribuir recursos entre múltiples centros de datos en tiempo real.

En un espectro amplio de industrias, las organizaciones de hoy enfrentan desafíos que el escalamiento tradicional de datos no puede resolver con facilidad, ya sea que se trate de brindar acceso a información en tiempo real, manejar grandes volúmenes de transacciones, cumplir con la exigencia de largos tiempos productivos o integrarse con un entorno informático diverso y dinámico.

Las tecnologías in-memory data grid permiten que las empresas alcancen un alto grado de flexibilidad y rendimiento para sus aplicaciones y agilicen las interacciones con el nivel de datos, brindándoles una ventaja para aprovechar las oportunidades comerciales y salir más rápidamente al mercado.

Bio

Christina Wong es Gerente Senior de Comercialización de Productos de Red Hat y está a cargo de Red Hat JBoss Data Grid y Red Hat JBoss Portal Platform. Obtuvo una Maestría en Administración de Empresas en la Universidad de Babson en EU y posee una década de experiencia empresarial y en ingeniería en alta tecnología.

Trabajando con stored procedures en SQL Server

Anonymous — Sat, 21 Aug 2010 18:22:40 +0000

Trabajando con stored procedures en SQL Server Anonymous Sat, 08/21/2010 - 13:22

Publicado en

SG #29

Gestión de datos

Autor

Ricardo Rangel

El procesamiento de datos es una de las actividades más arduas a la que nos enfrentamos al desarrollar sistemas transaccionales, especialmente cuando se afectan grandes cantidades de datos. Por medio de procedimientos almacenados, o stored procedures (SP), el sistema de base de datos es capaz de ejecutar un conjunto de instrucciones bien coordinadas entre sí que afectan la información con el fin de lograr un objetivo dentro del sistema.

A continuación comparto algunas técnicas que pueden ser útiles para crear stored procedures confiables con una gran cantidad de instrucciones y gestionar los grandes bloques de información que se ven afectados por estos. Vale la pena mencionar que aunque este artículo utiliza como referencia las capacidades disponibles en SQL Server, la teoría básica y la mayoría de la sintáxis es aplicable a otros manejadores de base de datos.

Catálogo de procedimientos
La primera recomendación es tener un catálogo de stored procedures que nos ayude a tener un listado de los procedimientos con los que contamos. En su forma mínima, esta tabla simplemente tendría Id y nombre del proceso, pero puede extenderse para incluir otra información relevante, tal como desarrollador o fecha de actualización.

IdProceso	Proceso
1	Registro de Comisiones
2	Pago de Comisiones a Vendedores
3	Traspasos de cuentas entre Vendedores

Bitácora de operaciones
Para llevar un registro de qué información es afectada por un procedimiento, podemos crear una tabla de auditoria, en donde se escribirá el Id del Proceso que tuvo que ver con la entrada, eliminación o actualización del registro. Por ejemplo, supongamos que en el cuerpo de nuestro procedimiento para registro de comisiones contiene la instrucción:

INSERT INTO COMISION (IdEmpleado, Comision)
VALUES (@IdEmpleado, @Comision)

Inmediatamente después (y dentro de la misma transacción) podríamos colocar la siguiente instrucción, haciendo referencia a nuestro catalogo de procesos:

INSERT INTO BITACORA_OPERACION (IdProceso, DescProceso, FechaAlta)
VALUES (@IdProceso, @DescProceso, @Getdate)

En donde @IdProceso tiene el valor de 1, y @DescProceso contiene el texto ingresado por el usuario para justificar esta comisión. Esto es muy útil para el seguimiento a información e incluso puede ser un requerimiento de seguridad o cumplimiento de normas en un corporativo.

Evitar la ejecución duplicada
Imaginemos que ejecutamos nuestro procedimiento de calcular comisiones de vendedores y éste introduce la información en una tabla. ¿Qué sucedería si volviéramos a ejecutar el mismo proceso por error? Bueno, no es difícil de imaginar, tendríamos información duplicada. Para evitar esto, podemos apoyarnos en nuestra tabla de bitácora, consultando si nuestra operación ha sido ejecutada recientemente, antes de ejecutarla. A nivel de interfaz, podríamos mostrarle al usuario un mensaje más descriptivo.

Depuración de variables
En caso de no contar con herramientas con capacidades de depuración para stored procedures, se puede usar la instrucción Select para conocer los valores que van tomando las variables al ejecutar el proceso, por ejemplo:

SELECT @Variable AS Variable

Por otro lado, cuando hay una falla en la ejecución del procedimiento, es muy probable que el valor de la variable nos aparezca vacío, por lo que esta instrucción no es muy útil para depurar fallas. En ese caso, la recomendación sería basarnos en el mensaje de error que arroje el servidor de base de datos donde indica la línea de código donde se está dando el error, y entonces utilizar cerca de esa línea la instrucción PRINT para que nos de un valor que permita ejecutar esa instrucción fuera del procedimiento y poder observar lo que está sucediendo.

Por ejemplo si el mensaje de error indica que el Subquery asignado a una variable está regresando más de un valor, podemos hacer un print para conocer los valores que se están usando para armar el query, y detectar el problema.

PRINT @IdEmpleado
SET @VarIdComision =
(SELECT IdComision FROM Comision where IdEmpleado = @IdEmpleado)

Monitoreo de la información
No porque nuestros procedimientos no marquen errores significa que funcionan correctamente. Por ejemplo, si en un procedimiento tenemos la instrucción IF @Variable > 1 y el proceso nunca entra en el IF (cuando se supone que debió haber entrado), entonces hay algo mal. Una herramienta de análisis de código nos ayudaría a conocer nuestra cobertura de código, pero dado que éstas herramientas no son comunes para stored procedures, lo más seguro es que debamos recurrir a monitorear esto manualmente revisando nuestros datos y la bitácora de operaciones.

Bitácora de incidencias
Cuando ocurre algún error en nuestro proceso es bueno anotar en una bitácora por qué se dio el error y cómo se solucionó. En ocasiones, los errores se dan no porque esté mal nuestro proceso sino porque hay una inconsistencia en los datos. Por ejemplo si el proceso busca el Id de un registro con una fecha, pero existen dos registros con la misma fecha, SQL no sabrá cual tomar y el proceso fallará. Así que se toma la acción correctiva correspondiente y se anota en la bitácora para posibles futuras excepciones.

Separación en funciones
Cuando manejamos grandes cantidades de información, es normal que los procesos que desarrollemos tengan una gran cantidad de instrucciones dando como resultado código muy largo. El uso de funciones en SQL permite simplificar el código en ciertas secciones donde necesitemos obtener un valor. Las funciones las podremos invocar una y otra vez desde nuestros procedimientos.

DECLARE @SaldoActualCta Smallmoney
SET @SaldoActualCta = (SELECT dbo.fnc_ObtenerSaldoActualCuentaXIdCta(@IdCtaLote))

Manejo de cursores
Hay quienes argumentan que no es bueno el uso de cursores porque son supuestamente “lentos”, pero considero que hay ocasiones en que es inevitable, e inclusive muy útiles, ya que el uso de cursores nos permitirá avanzar registro por registro y especificar una o varias instrucciones en cada vuelta. Cuando se opte por usar cursores hay que tener cuidado de cerrarlos correctamente, principalmente cuando utilizamos cursores anidados (cursor dentro de otro cursor). Otra cosa a tomar en cuenta es que si se produce un error dentro del cursor, supongamos en un INSERT, cuando manejemos la excepción, también debemos cerrar el o los cursores involucrados. Por otro lado, para avanzar registro por registro no solamente se cuenta con la opción de cursores sino también con la instrucción WHILE, pero seria cuestión de revisar cual de estas opciones se adecua más a nuestras necesidades.

Tablas temporales
Esta es otra arma que tenemos a nuestra disposición al manejar grandes cantidades de información. Las tablas temporales permiten almacenar información temporalmente, de tal manera que podemos hacer uso de ella durante la ejecución de nuestro stored procedure. Recordemos también que existen las llamadas variables de tabla que son similares a las tablas temporales pero utilizan menos recursos y son ideales para almacenar poco volumen de datos. Se recomienda investigar a fondo las diferencias entre ambas opciones ya que su explicación excede el alcance de este artículo.

Disparadores y reglas
Los disparadores (también conocidos como triggers) son objetos de la base de datos que ejecutan acciones cuando se producen ciertos eventos. Por ejemplo imaginemos que a un vendedor inactivo no se le puede asignar una cuenta. Mediante un disparador podremos prevenir esta situación.

Si al ejecutar el procedimiento se da esta situación, entonces aparecerá un mensaje que impedirá que se termine de ejecutar el SP correctamente. Esto es bueno para nosotros, porque es una advertencia de que algo anda mal en nuestro procedimiento. Por otro lado, las reglas (rules) nos permiten establecer ciertos limites a la información. Por ejemplo, imaginemos que el saldo de un vendedor no puede ser menor a 1,000 pesos. Para esto podemos crear una regla.

El uso de disparadores y reglas en la construcción de procedimientos es fundamental. De hecho, se recomienda que antes de programar el procedimiento, se programen todos los disparadores y reglas necesarias. Esto nos obligará a programar el proceso respetando siempre las reglas de negocio preestablecidas. El uso de disparadores y reglas nos garantizara que la información que resulte de nuestros procesos será confiable.

Conclusión
Los stored procedures son fundamentales para el desempeño óptimo de un sistema de información. A los desarrolladores de sistemas de información nos corresponde implementar todo tipo de estrategias y técnicas que nos permitan tener el control de la información y garantizar que ésta sea confiable y precisa. Espero que los tips compartidos en este artículo los ayuden a lograr esta tarea.

Referencias
[1] Solid Quality Learning. Microsoft SQL Server 2005: Técnicas Aplicadas, Microsoft Press.

Bio

Ricardo Rangel Ramírez es Licenciado en Informática egresado de la Universidad de Ecatepec. Ha desarrollado software en plataforma .Net para diferentes empresas. Actualmente labora en el Departamento de Sistemas de Stanhome de México y en proyectos independientes. Sus principales habilidades son la gestión y explotación de información, así como el análisis, diseño y desarrollo de sistemas de información. riccardorangel@hotmail.com

Diseño de Base de Datos: La importancia de los catálogos

Anonymous — Wed, 03 Dec 2008 19:57:49 +0000

Diseño de Base de Datos: La importancia de los catálogos Anonymous Wed, 12/03/2008 - 13:57

Publicado en

SG #22

Gestión de datos

Autor

Víctor Hugo García

Los catálogos, en una base de datos, son indispensables para un buen diseño de la misma. Es por eso la importancia de conocer las ventajas y desventajas de su uso. Comencemos definiendo “catálogo” en una base de datos. Un catálogo es una tabla de datos que contiene información relevante sobre las opciones finales de un usuario en una aplicación. A continuación menciono las ventajas y desventajas de los catálogos en el diseño de base de datos:

Ventajas

Permite una rápida obtención de los datos requeridos al momento de realizar una consulta.
Permite una reducción de tiempo en programación.
Permite al usuario final la posibilidad de realizar una modificación de manera dinámica a las opciones del software, fácil y rápidamente desde una administración.
Permite crear una base de datos normalizada.

Desventajas

El uso de memoria en el servidor SQL puede verse afectado.
La desventaja puede ser solucionada con el uso correcto de las consultas SQL, tal es el caso de evitar productos cartesianos al momento de dicha consulta y en su reemplazo utilizar INNER JOIN, LEFT JOIN, RIGHT JOIN según se requiera.
Ciertos desarrolladores necesitan ver un proceso de normalización de una base datos, sin embargo, si comienzas a diseñarla utilizando catálogos, dicho proceso puede llegar a ser innecesario.

Ejemplo 1

“Un sistema requiere que almacene el país de origen de un cliente” pero este dato puede cambiar y/o aumentar en base a las necesidades del usuario final. El desarrollador puede elegir entre varias opciones:

Agregar un campo de tipo cadena de caracteres, permitiéndole al usuario escribir el dato en un campo de texto.
Añadir un campo de tipo entero y colocando un campo de selección obteniendo la información desde el código de manera estática.

Los problemas que se generan cuando se utiliza un campo de tipo cadena de caracteres, radica en la integridad de los datos, pues en esta se pierde completamente. Los errores humanos siempre hay que tenerlos presentes y por tanto, alguien como usuario final puede llegar a escribir el nombre de un país de la manera incorrecta. Además la normalización no está presente en este caso.

Cuando se obtienen los datos de manera estática en el código, se presenta el problema en el tiempo invertido que se requiere en la programación de los elementos, así como el mantenimiento de ciertos módulos.

Enseguida muestro una solución utilizando los catálogos: Se diseña la tabla –Cliente- y la tabla –Pais-, La tabla Pais almacena los datos que necesitamos con dos simples campos: “idPais y nomPais”, dicha tabla siendo relacionada 1:N con la tabla clientes, de esta manera es posible obtener la información necesaria del cliente con una simple consulta SQL, además de que el proceso de normalización e integridad de los datos se está dando de manera automática.

Si el usuario final desea que su sistema sea capaz de aumentar los datos de los países, el administrador del catálogo Pais podrá agregarlo fácil y rápidamente. Inclusive, los reportes que se hayan programado no requerirán de inversión de tiempo, puesto que la información que se pida será obtenida mediante una consulta SQL.

En la siguiente figura muestro un diagrama de clases de lo que sería una relación de la tabla cliente con la tabla país (1:N).

Ejemplo 2

“Un sistema requiere que se almacene la especialidad de un médico” este dato se puede aumentar, actualizar y/o eliminar.

La solución fácil y rápida pero errónea, sería crear un campo en la tabla médico llamado “especialidadMedico” y que este sea de tipo cadena de caracteres. Como he venido platicado, esta solución pierde completamente la integridad de los datos y por consiguiente la normalización de la base de datos no existe. Por tanto si se elige la solución por catálogos como se muestra en la figura siguiente:

Realizar búsquedas, generar reportes, obtener información para desplegar en alguna lista, etc., todo esto puede llevarse a cabo de manera rápida y eficiente. En todos los sistemas una búsqueda es básica e indispensable, por lo tanto imaginemos esto: El cliente desea una lista desplegable con las especialidades que se tienen para realizar un mejor filtrado de la información. Ahora, imagina esto en más de 10 páginas. Por ultimo imagina que el usuario final te comenta que se requiere agregar una nueva especialidad.

Considerar la creación de un catálogo para un mejor control e integridad de la información sería ideal para solucionar varios problemas como el que se describe en el párrafo anterior. Si se requiere un reporte de todos los médicos de cierta especialidad, esto sería muy sencillo de obtener mediante una consulta SQL. Permitirle al usuario modificar las opciones de un sistema es siempre ideal, pues el usuario verá lo sencillo que es hacerlo desde un ambiente grafico.

Cuando se necesita cotizar una aplicación, se debe dejar en claro al cliente, que el administrador del sistema será capaz de modificar opciones del sistema de manera fácil y rápida; tu cliente verá esto como un buen desarrollo.

Cuando me encuentro en reuniones con clientes para hablar sobre las opciones que se desean en el sistema, siempre hay un punto en el que se comenta “Este módulo debe ser así, porque CASI NO se eligen esas opciones” es entonces cuando se tiene que realizar un análisis de ese caso, puesto que si eliges una opción errónea, al momento de entregar tu software se te diga que SIEMPRE SI se usarán dichas opciones, para solucionarlo te podrías ver en la necesidad de reprogramar uno o varios módulos; sin embargo, al elegir la opción de catálogos, simplemente se agrega el dato a la base de datos y listo.

Finalmente podemos concluir que si los desarrolladores ven la importancia del uso de catálogos, esto puede significar auténticos ahorros en tiempo de programación, proceso de normalización y mejorar la integridad de los datos en la aplicación.

Bio

Víctor Hugo García es Líder de Desarrollo Web en C-Technologies. Es egresado del Instituto Tecnológico de Ciudad Guzmán. Cuenta con experiencia en el diseño de base de datos y programación con tecnologías .NET y PHP. Actualmente se encuentra desarrollando software en diversas verticales de negocio para clientes en Estados Unidos. Durante el 2007 colaboró con proyectos en el Gobierno del estado de Guanajuato.