Los Datos que generan la Informacin Introduccin El objetivo de esta gua es mostrar las herramientas tecnolgicas vigentes en la actualidad,

para contener los datos que generan informacin. Es importante tener en cuenta que sin ellos, sin datos, es imposible obtenerla. Los sistemas los almacenan en Bases de Datos Relacionales. Esta herramienta tiene caractersticas que todo profesional del conocimiento, que trabaja fundamentalmente generando y utilizando informacin no debe desconocer. Es necesario saber cmo se almacenan los datos para obtener la informacin para la toma de decisiones que, a su vez es la generadora de conocimiento. Se desarrollan aqu, los siguientes temas: una definicin y caracterizacin de las Bases de Datos Relacionales, dos metodologas para su diseo y, por ltimo, una breve resea de la evolucin tecnolgica, en cuanto a almacenamientos, para procesos de anlisis de informacin (Datawarehouse). Cabe aclarar que estos ltimos, los DW, tienen su origen en las Bases de Datos, es decir, stas son la fuente generadora e indispensable para los mismos. Por lo tanto, es por la importancia que tiene este tema, en la formacin slida de profesionales que sugiero que los alumnos analicen cada proceso para la obtencin de informes de su trabajo. Pueden utilizar las metodologas aqu expuestas para el diseo de las tablas de la base de datos necesaria para la produccin de dichos informes, o cualquier otra que pueda ser alternativa. Lo importante es que se represente, claramente, el modelo de base de datos que soporta la generacin de los informes respectivos. Bases de Datos Segn James Martin La base de datos puede definirse como una coleccin de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es la de servir a una aplicacin o ms, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean mtodos bien determinados para incluir datos nuevos y para modificar o extraer los datos almacenados.1 Se puede considerar a una base de datos como al conjunto de datos que son utilizados por los sistemas de informacin de una organizacin. Es decir, es la herramienta de la se valen para administrar los datos, y en base a ellos, obtener informacin. Todos los movimientos de las organizaciones son registrados en la base de datos. Si hablamos empresas comerciales, todos los datos de las compras, los pagos, las ventas, los cobros, etc. conforman los registros de la base de datos. Estos sistemas son conocidos como sistemas de informacin transaccionales y las bases de datos con las que actan se las conoce como bases de datos transaccionales u operacionales y permiten el Proceso de Transacciones en Lnea (OLTP), dando apoyo a los procesos de las organizaciones. Las bases de datos fueron creadas con ese objetivo. Pueden tener tres tipos de estructuras: Jerrquica, Red o Relacional. Estas ltimas son las utilizadas mayoritariamente en la actualidad por los sistemas.
1

Martin James Organizacin de las Bases de Datos , Mxico 1977, pag. 19

Las bases de datos relacionales, desde el punto de vista de su diseo lgico, estn conformadas por tablas bidimensionales en las que cada columna corresponde a un atributo de la tabla y cada fila o tuple, al conjunto de valores de esos atributos, correspondientes a un individuo o suceso de la tabla. Las columnas representan los atributos Tabla CLIENTES Cod.Cli A-121 A-331 B-005 NomCli Alvarez Ramn Alonso Csar Benitez Juan DomCli Sucre 1950 Italia 3334 Paraguay 555 CodPostal 2000 2000 2000

Las filas o tuples representan los individuos o sucesos de la tabla)

Clave Principal

La forma en que se implementa la relacin de las tablas es a travs de un atributo comn. En general, el atributo clave principal de una tabla, es el que se repite en otra con la que necesita relacionarse y en esta ltima toma el nombre de clave secundaria o clave fornea Tabla Facturas Nro.Fact FechaFact ImpFact CodCli 1566 29-10-2008 1000 B-005 1567 29-10-2008 500 A-121 Clave secundaria o fornea

Clave Principal Los datos de una base de datos tienen los siguientes componentes: Nombre (el que figura en la cabecera de cada columna) Tipo (numrico, alfanumrico, fecha, etc.) Valores o variables El conjunto de valores de una fila, es el registro lgico o tuple y corresponde a los valores de los datos de una ocurrencia de la tabla (un cliente, una factura) Clave Principal Es el atributo o atributos de una tabla cuyos valores no se repetirn, de forma tal que ese valor puede identificar a un tuple. La definicin de un atributo como

clave la realiza quien disea la base de datos. Las circunstancias con las que el o los diseadores se pueden encontrar son las siguientes: Puede suceder que exista ms de un atributo que cumpla con la caracterstica requerida para ser clave. En ese caso se proceder a elegir uno. Otro suceso sera que no exista ninguno, lo que llevar a los diseadores a buscar una combinacin de dos o ms atributos cuya concatenacin de valores no se repitan (conviene que como mximo sean tres). Es el caso de las claves concatenadas. Una tercera ocurrencia sera que no exista posibilidad de concatenacin de atributos, es decir, que definitivamente no exista la posibilidad de definir una clave. En esta circunstancia conviene generar un nuevo atributo cuya funcin sea exclusivamente la de clave. No constituira un dato real y sus valores consistiran en una secuencia que comenzara con 1, incrementndose de a uno (1,2,3, ,n) Sistema gestor de base de datos (SGBD)

Usuario 1
Programa de Aplicacin 1

Usuariio 2
Proframa de Aplicacin 2

SISTEMA GESTOR DE BASE DE DATOS

BASE DE DATOS

Usuario 3
Programa de Aplicacin 3

Fig. 1

Conocido tambin por Sistema Administrador de Base de Datos (SABD), consiste en un conjunto de programas que permite la creacin, modificacin y consulta de la base de datos. De esta definicin se extrae que para poder implementar una Base de Datos, es necesario tener un SGBD. Existen diversos SGBD, todos con la misma finalidad bsica, que se diferencian por los servicios adicionales que pueden prestar.

Caractersticas de las Bases de Datos Si se analiza la definicin de James Martin, algunas de las caractersticas de las bases de datos seran: Independencia de los datos con respecto a los programas que los utilizan. El SGBD, tal como lo muestra la fig. 1, es el intermediario entre los programas y los datos. Los programas no necesitan incluir instrucciones para el acceso a los datos que necesitan. Solo los enuncian por sus respectivos nombres. Es el SGBD el que los busca en la base de datos y los entrega a cada programa para que ste los procese. Esta caracterstica brinda flexibilidad al sistema ya que se pueden crear o modificar programas sin tener en cuenta la administracin de los datos y viceversa, se pueden agregar nuevos datos a la base sin afectar los programas que ya la usan. Posibilidad de no redundancia de datos: Al estar todos los datos del sistema en la base de datos, todos los programas pueden acceder a ellos. Un programa que procesa ventas, no necesita tener su propio archivo de clientes, utiliza los datos de los clientes que estn en la base de datos al igual que lo hacen los programas que procesan cobranzas. Esto permite la consistencia de la informacin ya que todos los subsistemas acceden a los mismos datos y, por lo tanto, la informacin ser concordante entre los sistemas. El SGBD no controla la redundancia de los datos. La base de datos puede contener datos redundantes, lo que podra implicar inconsistencia, en el caso de que los valores de un mismo dato repetido difieran. Para evitarla es necesario un buen diseo de la BD. Consultas no programadas: Los sistemas, para brindar informacin, contienen programas que la elaboran. Quien utiliza el sistema, obtiene esa informacin siempre que la necesita, pero puede suceder que se necesite informacin que no est prevista en el sistema, generalmente para la toma de decisiones en niveles jerrquicos. Los SGBD, brindan la posibilidad de que, a partir de un sencillo lenguaje de programacin, un lenguaje de consulta estructurado (SQL) se pueda obtener fcilmente, informacin que no est prevista en el sistema, y que es necesaria en un determinado momento. Modelo de Datos A fin de poder disear una base de datos, es necesario planificar los datos en funcin de los requerimientos de la organizacin. Teniendo en cuenta las necesidades de informacin de los usuarios finales, se puede elaborar el modelo de datos con un diagrama de entidad relacin. En este diagrama se representan las relaciones entre las entidades que intervienen en los procesos de la organizacin, necesarios para el cumplimiento de sus objetivos (procesos de negocios). Los modelos de datos aportan la base conceptual para disear aplicaciones. De acuerdo a los requerimientos de informacin y los procesos del sistema de informacin, se construye una representacin de la aplicacin que muestra las propiedades requeridas para dar soporte a los procesos, por ejemplo,

transacciones y consultas. Adems de capturar las necesidades definidas en el momento de la etapa de diseo, la representacin debe ser capaz de dar cabida a eventuales futuros requerimientos. Diagrama de EntidadRelacin y Modelo de Base de Datos El diagrama de Entidad-Relacin define las relaciones que existen entre las entidades que intervienen en un determinado proceso. Se puede considerar una entidad a todo sujeto, objeto o hecho susceptible de contener atributos. Son estos atributos, abstracciones de los datos, los que definen a una entidad. Como ejemplo podemos tomar los siguientes atributos: Cdigo de Cliente, Domicilio de Cliente, Nombre de Cliente, Cdigo Postal. Estaran definiendo la entidad Cliente. Los atributos que intervienen en un determinado proceso son relevados por quienes estn diseando el modelo de datos. En un proceso de facturacin, los clientes originan facturas. Factura es otra entidad del modelo, cuyos atributos podran ser Nmero de Factura, Fecha de Factura e Importe de Factura. Ambas entidades deben estar relacionadas.

1:1 Cliente origina

1:M

Factura

fig. 2 Este diagrama muestra la relacin entre las dos entidades. Puede leerse, de izquierda a derecha: Un cliente origina, como mnimo una factura y como mximo muchas (1:M). En sentido inverso, de derecha a izquierda: Una factura es originada slo por un cliente (1:1). La notacin utilizada no es nica, existen variantes tales como:

Cliente

Factura

fig. 3 en la que los extremos de la lnea de relacin indican la cardinalidad de la misma, 1:1 o 1:M. Cada entidad puede llegar a ser una tabla de la base de datos. Si se agregan los atributos de cada una de ellas indicando las respectivas claves primarias y secundarias, se estara representando el modelo de base de datos.
Clientes PK CodCli NomCli DomCli CP PK Facturas NroFact FechaFact ImpFact CodCli

FK1

Fig. 4

En este modelo PK indica la clave primaria y FK, la secundaria (FK1, porque en este caso hay una sola clave secundaria, pero pueden existir ms de una: FK2, FK3, etc.). Es esta clave secundaria la que implementa el atributo comn que relaciona las dos tablas, segn la definicin. En este caso, es posible porque cada factura corresponde a un solo cliente, y por lo tanto puede guardar el valor de ese solo dato. Es claro que estos modelos no representan totalmente el proceso de facturacin, porque la factura contiene ms atributos, tales como los productos que se han vendido y la cantidad de ellos. Surge aqu una nueva entidad: Producto, que contiene y es definida por el Cdigo del Producto, la Descripcin del mismo, la Cantidad en Stock que tiene la empresa de ese producto, su Precio de Venta.
1:1 Cliente origina 1:M Factura 1:M contiene 1:M Producto

fig. 5 En esta nueva relacin: una factura contiene muchos productos y un producto es contenido en muchas facturas (porque se supone que un tipo de producto, no una unidad en particular, va a ser vendido muchas veces). Se observa la particularidad de que su cardinalidad es muchos (1: M) en ambos sentidos. Esto trae una dificultad al momento de definir el atributo comn que las va a relacionar porque no existe un solo valor de producto para una factura, se puede vender varios productos a un cliente y todos ellos deben registrarse en la factura. En este caso, y en todos en los que se de esta situacin, la relacin se implementa a partir de una nueva entidad llamada entidad asociativa, que es definida, en este caso, por los muchos artculos que puede contener una factura y la cantidad de cada uno de ellos.
1:1 Cliente origina 1:M Factura 1:M contiene 1:M Producto

Factura-Producto

fig. 6 El respectivo modelo de base de datos sera:

Clientes PK CodCli NomCli DomCli CP PK Facturas NroFact FechaFact ImpFact CodCli FK1 FK2 Cant_Prod NroFact CodProd Factura-Producto PK Productos CodProd DescrProd CantStock PrecioVta

FK1

fig. 7

La entidad asociativa Factura-Producto es una entidad dbil, que surge por la imposibilidad de relacionar directamente dos entidades por un atributo comn. Por ese motivo, algunas herramientas de diseo, como la empleada en este artculo (Microsoft Office Visio 2003), generan tablas sin una clave principal y con las claves primarias de las dos tablas que relacionan, como claves secundarias. Tambin puede considerarse que esos atributos conformen una clave primaria concatenada de la tabla. Estas entidades asociativas, adems de la funcin de relacionar otras dos entidades fuertes, pueden contener atributos que les son propios y que las definen. En este caso la entidad representa los varios artculos que puede contener una factura y la cantidad vendida de cada uno de ellos. La tabla correspondiente contendr ms de un tuple por cada factura (uno por cada artculo que en ella se vendi). Resumiendo, para construir un modelo de entidad-relacin es necesario: definir en primer lugar cules son las entidades interviniente en un proceso Luego, determinar las relaciones entre estas entidades Por ltimo, se definen las claves primarias y secundarias, generndose as el modelo de Base de Datos Siguiendo estos pasos, es posible realizar el modelo de datos de cualquier proceso. Normalizacin de Datos Es una tcnica para lograr el Modelo de Base de Datos Relacional, alternativa al diagrama de Entidad-Relacin. Consiste en varios pasos llamados formas normales, para lograr tablas relacionadas que no contengan datos redundantes. No tiene en cuenta los procesos de negocios a los que las tablas van a dar soporte. Para sistemas de gestin administrativa, se considera que con tres formas normales es suficiente para conseguir una base de datos eficiente. Se parte del relevamiento de datos de un determinado sistema, en este caso, seguiremos con el ejemplo del proceso de facturacin. Los datos necesarios para el mismo son: NroFact FechaFact ImpFact CodProd DescProd CantProd PrecVta CodCli NomCli DomCli CP (Nmero de Factura) (Fecha de Factura) (Importe de la Factura) (Cdigo del Producto vendido) (Descripcin del Producto) (Cantidad del Producto vendido) (Precio de Venta del Producto) (Cdigo del Cliente) (Nombre del Cliente) (Domicilio del Cliente) (Cdigo Postal)

Se puede considerar a estos datos como una relacin cuya clave principal es el Nmero de Factura. 1FN (primera forma normal). Consiste en analizar la relacin que tiene cada dato con la clave principal. Aquellos que tienen una relacin de 1:M (para una ocurrencia del dato clave, pueden existir ms de una ocurrencia del dato analizado), se deben poner en una nueva relacin, arrastrando con ellos la clave principal. Los datos que cumplen con esta condicin se los conoce como grupos repetitivos NroFact FechaFact ImpFact CodCli NomCli DomCli CP NroFact CodProd DescProd CantProd PrecVta

Se genera aqu una nueva relacin con los datos relativos a los productos de la factura. Esta nueva relacin tiene una clave, que siempre es la concatenacin del valor de la clave de la nueva relacin, con el valor de la clave de la relacin original: CodProd + NroFact. 2FN (segunda forma normal): Este paso se realiza nicamente con relaciones cuya clave es concatenada y consiste en analizar qu datos de ella tienen una relacin biunvoca con alguno de los datos no claves. Se puede pensar en que cuando un dato de la clave toma un determinado valor, el dato analizado siempre muestra el mismo valor y viceversa. Ejemplo: cuando el Cdigo de Producto toma el valor A25, la Descripcin del Producto siempre va a tener el valor lata de arvejas XX y viceversa. Estos datos se deben poner en una nueva relacin, arrastrando el dato clave del que dependen. Esta situacin se la denomina Dependencias parciales con la clave. En el ejemplo, DescProd y PrecVta tienen relacin biunvoca con CodProd, luego: NroFact FechaFact ImpFact CodCli NomCli DomCli CP NroFact CodProd CantProd CodProd DescProd PrecVta

3FN (tercera forma normal). Aqu se analizan tambin las relaciones biunvocas pero entre datos no claves. Se las denomina dependencias transitivas. Se colocan en una nueva relacin y, al igual que en la 2FN, arrastran el dato del que dependen, que ser la nueva clave.

Facturas NroFact FechaFact ImpFact CodCli

Factura-Producto NroFact CodProd CantProd

Productos CodProd DescProd PrecVta

Clientes CodCli NomCli DomCli CP

Cada una de estas relaciones contienen los datos de una tabla. En el ejemplo, se obtienen el diseo del modelo la base de datos necesaria para el proceso de facturacin de esta organizacin. Como se podr observar, no difiere con el definido con el diagrama de entidad-relacin (excepto por el dato Cantidad en Stock, que en este caso no fue relevado, pero que en caso de serlo se agregara a la tabla Productos). Se dijo al comienzo de este tema, que esta tcnica es alternativa al diagrama de entidad-relacin. No obstante pueden ser complementarias si se aplica el razonamiento de las formas normales, fundamentalmente la 3FN, a los datos de las tablas del modelo, para detectar errores al definir las entidades. En caso de encontrar una dependencia transitiva, seguramente falta definir una entidad. Evolucin Tecnolgica para obtener Informacin para la toma de Decisiones. Las tecnologas de la informacin fueron evolucionando en cuanto a las herramientas para brindar informacin no estructurada a las organizaciones, que permita tomar decisiones sobre una base cierta, minimizando la incertidumbre. Segn Jos Hernndez Orallo la evolucin podra sintetizarse de la siguiente manera: 60s: Informes batch: la informacin es difcil de encontrar y analizar, poco flexible, se necesita reprogramar cada peticin. 70s: Primeros DSS (Decision Support Systems) y EIS (Executive Information Systems): basados en terminal, no integrados con el resto de herramientas. 80s: Acceso a datos y herramientas de anlisis integradas (conocidas como intelligent business tools): Herramientas de consultas e informes, hojas de clculo, interfaces grficos e integrados, fciles de usar. Acceden a las bases de datos operacionales (killer queries). 90s: Almacenes de Datos y herramientas OLAP. 00s: Herramientas de Minera de Datos y Simulacin.

Jos Hernndez Orallo, cruso sobre Datawarehouse y Datamining, Chihuahua octubre 2003 . De acuerdo a esta cronologa, la caracterstica de consultas no programadas que se defini en el punto Bases de Datos, pertenece a la dcada de los 80s y tuvo un gran uso por parte de gerentes y directivos de organizaciones para avalar sus decisiones. Originalmente, cada Sistema Gestor de Base de Datos tena su propio lenguaje de consulta (query). Esto haca que quienes los usaban, deban conocer las palabras y la sintaxis del lenguaje especfico de la

base de datos que se estaba utilizando. Si cambiaba la base de datos por una decisin de cambio en el sistema de informacin o quizs por un cambio de trabajo del gerente, deba aprender un nuevo lenguaje. En la actualidad el lenguaje de consulta estructurado (SQL), es un estndar en todos los SGBD y su uso fue intensivo. Este uso tuvo un efecto colateral no deseado: la lentificacin del sistema transaccional. Muchos usuarios consultando las bases de datos para analizar informacin hace que las transacciones sean ms lentas. Hay que tener en cuenta que las bases de datos fueron pensadas para las transacciones y no para el anlisis. La tecnologa dio una respuesta a este problema creando herramientas especficas para el anlisis de informacin (OLAP) Almacenes de Datos (Datawarehouse DW) Son bases de datos orientadas a soportar el proceso de decisin (decisiones no programadas). Su diseo es generalmente multidimensional (cubos y no tablas). Se alimenta en forma automtica desde las bases de datos de los sistemas transaccionales (OLTP on line transactional processing) y de otras fuentes, tales como bases de datos de proveedores, clientes, informacin de la competencia, etc. Bussines Intelligence OLAP 100 Dataminig 80
60 40 20 0 1er 2do 3e r 4to trim . trim . trim . trim . Es te Oe ste Norte

Base ERP de Datos Transaccional Fuentes Fuentes Externas Externas Otros datos fuera Otros datos fuera del ERP del OLTP

Datawarehouse

DECISIN

Los DW deben ser tambin diseados en funcin de las necesidades de informacin para la toma de decisiones de una organizacin. De esta forma, se sistematiza y automatiza la obtencin de la misma. Este diseo utiliza los datos de la BD transaccional y adems pueden incorporar datos externos que se consideren necesarios. Adems, para cumplir con su funcin, estos almacenes, deben ser actualizados peridicamente, precisamente, con los datos de la base de datos transaccional y con aquellos datos externos con los que fueron diseados. Los almacenes de datos y las tcnicas OLAP son formas efectivas y tecnolgicamente avanzadas para integrar, transformar y combinar los datos para facilitar al usuario o a otros sistemas el anlisis de la informacin.

La tecnologa OLAP generalmente se asocia a los almacenes de datos, aunque podemos tener Almacenes de Datos sin OLAP y viceversa. Es decir que se pueden aplicar tcnicas OLAP para bases de datos tradicionales y otras tecnologas para extraer informacin de los almacenes de datos. Prof. Diana Cecilia Navarro Bibliografa: Martin, James Date, C.J. Hernndez Orallo, Jos Organizacin de las Bases de Datos. Ed Prentice Hall Hispanoamericana, Mxico 1989. 1ra edicin Introduccin a los Sistemas de Bases de Datos. Ed.Pearson Educacin, Mxico 2001, 7ma. Edicin Curso sobre Datawarehouse y Datamining, Chihuahua, Mxico - octubre 2003