Los Datos que generan la Información

Transcripción

1 Los Datos que generan la Información Introducción El objetivo de esta guía es mostrar las herramientas tecnológicas vigentes en la actualidad, para contener los datos que generan información. 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 características que todo profesional del conocimiento, que trabaja fundamentalmente generando y utilizando información no debe desconocer. Es necesario saber cómo se almacenan los datos para obtener la información para la toma de decisiones que, a su vez es la generadora de conocimiento. Se desarrollan aquí, los siguientes temas: una definición y caracterización de las Bases de Datos Relacionales, dos metodologías para su diseño y, por último, una breve reseña de la evolución tecnológica, en cuanto a almacenamientos, para procesos de análisis de información (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 formación sólida de profesionales que sugiero que los alumnos analicen cada proceso para la obtención de informes de su trabajo. Pueden utilizar las metodologías aquí expuestas para el diseño de las tablas de la base de datos necesaria para la producción 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 generación de los informes respectivos. Bases de Datos Según James Martin La base de datos puede definirse como una colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es la de servir a una aplicación o más, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean métodos 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 información de una organización. Es decir, es la herramienta de la se valen para administrar los datos, y en base a ellos, obtener información. 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 información transaccionales y las bases de datos con las que actúan se las conoce como bases de datos transaccionales u operacionales y permiten el Proceso de Transacciones en Línea (OLTP), dando apoyo a los procesos de las organizaciones. Las bases de datos fueron creadas con ese objetivo. Pueden tener tres tipos de estructuras: Jerárquica, Red o Relacional. Estas últimas son las utilizadas mayoritariamente en la actualidad por los sistemas. 1 Martin James Organización de las Bases de Datos, México 1977, pag. 19

2 Las bases de datos relacionales, desde el punto de vista de su diseño lógico, están 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. Tabla CLIENTES Las columnas representan los atributos Cod.Cli NomCli DomCli CodPostal A-121 Alvarez Ramón Sucre A-331 Alonso César Italia B-005 Benitez Juan Paraguay Las filas o tuples representan los individuos o sucesos de la tabla) Clave Principal La forma en que se implementa la relación de las tablas es a través de un atributo común. 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 foránea Tabla Facturas Nro.Fact FechaFact ImpFact B A-121 Clave secundaria o foránea Clave Principal Los datos de una base de datos tienen los siguientes componentes: Nombre (el que figura en la cabecera de cada columna) Tipo (numérico, alfanumérico, fecha, etc.) Valores o variables El conjunto de valores de una fila, es el registro lógico 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 repetirán, de forma tal que ese valor puede identificar a un tuple. La definición de un atributo como

3 clave la realiza quien diseña la base de datos. Las circunstancias con las que el o los diseñadores se pueden encontrar son las siguientes: Puede suceder que exista más de un atributo que cumpla con la característica requerida para ser clave. En ese caso se procederá a elegir uno. Otro suceso sería que no exista ninguno, lo que llevará a los diseñadores a buscar una combinación de dos o más atributos cuya concatenación de valores no se repitan (conviene que como máximo sean tres). Es el caso de las claves concatenadas. Una tercera ocurrencia sería que no exista posibilidad de concatenación de atributos, es decir, que definitivamente no exista la posibilidad de definir una clave. En esta circunstancia conviene generar un nuevo atributo cuya función sea exclusivamente la de clave. No constituiría un dato real y sus valores consistirían en una secuencia que comenzaría con 1, incrementándose de a uno (1,2,3,,n) Sistema gestor de base de datos (SGBD) Usuario 1 Programa de Aplicación 1 Usuariio 2 SISTEMA GESTOR DE BASE DE DATOS BASE DE DATOS Proframa de Aplicación 2 Usuario 3 Programa de Aplicación 3 Fig. 1 Conocido también por Sistema Administrador de Base de Datos (SABD), consiste en un conjunto de programas que permite la creación, modificación y consulta de la base de datos. De esta definición se extrae que para poder implementar una Base de Datos, es necesario tener un SGBD. Existen diversos SGBD, todos con la misma finalidad básica, que se diferencian por los servicios adicionales que pueden prestar.

4 Características de las Bases de Datos Si se analiza la definición de James Martin, algunas de las características de las bases de datos serían: 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 característica brinda flexibilidad al sistema ya que se pueden crear o modificar programas sin tener en cuenta la administración 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 están en la base de datos al igual que lo hacen los programas que procesan cobranzas. Esto permite la consistencia de la información ya que todos los subsistemas acceden a los mismos datos y, por lo tanto, la información será concordante entre los sistemas. El SGBD no controla la redundancia de los datos. La base de datos puede contener datos redundantes, lo que podría implicar inconsistencia, en el caso de que los valores de un mismo dato repetido difieran. Para evitarla es necesario un buen diseño de la BD. Consultas no programadas: Los sistemas, para brindar información, contienen programas que la elaboran. Quien utiliza el sistema, obtiene esa información siempre que la necesita, pero puede suceder que se necesite información que no esté prevista en el sistema, generalmente para la toma de decisiones en niveles jerárquicos. Los SGBD, brindan la posibilidad de que, a partir de un sencillo lenguaje de programación, un lenguaje de consulta estructurado (SQL) se pueda obtener fácilmente, información que no está prevista en el sistema, y que es necesaria en un determinado momento. Modelo de Datos A fin de poder diseñar una base de datos, es necesario planificar los datos en función de los requerimientos de la organización. Teniendo en cuenta las necesidades de información de los usuarios finales, se puede elaborar el modelo de datos con un diagrama de entidad relación. En este diagrama se representan las relaciones entre las entidades que intervienen en los procesos de la organización, necesarios para el cumplimiento de sus objetivos (procesos de negocios). Los modelos de datos aportan la base conceptual para diseñar aplicaciones. De acuerdo a los requerimientos de información y los procesos del sistema de información, se construye una representación de la aplicación que muestra las propiedades requeridas para dar soporte a los procesos, por ejemplo,

5 transacciones y consultas. Además de capturar las necesidades definidas en el momento de la etapa de diseño, la representación debe ser capaz de dar cabida a eventuales futuros requerimientos. Diagrama de Entidad Relación y Modelo de Base de Datos El diagrama de Entidad-Relación 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: Código de Cliente, Domicilio de Cliente, Nombre de Cliente, Código Postal. Estarían definiendo la entidad Cliente. Los atributos que intervienen en un determinado proceso son relevados por quienes están diseñando el modelo de datos. En un proceso de facturación, los clientes originan facturas. Factura es otra entidad del modelo, cuyos atributos podrían ser Número de Factura, Fecha de Factura e Importe de Factura. Ambas entidades deben estar relacionadas. Cliente 1:1 origina Factura fig. 2 Este diagrama muestra la relación entre las dos entidades. Puede leerse, de izquierda a derecha: Un cliente origina, como mínimo una factura y como máximo muchas (). En sentido inverso, de derecha a izquierda: Una factura es originada sólo por un cliente (1:1). La notación utilizada no es única, existen variantes tales como: Cliente Factura fig. 3 en la que los extremos de la línea de relación indican la cardinalidad de la misma, 1:1 o. 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 estaría representando el modelo de base de datos. Clientes Facturas PK PK NomCli DomCli FK1 FechaFact ImpFact Fig. 4

6 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 más de una: FK2, FK3, etc.). Es esta clave secundaria la que implementa el atributo común que relaciona las dos tablas, según la definición. 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 facturación, porque la factura contiene más 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 Código del Producto, la Descripción del mismo, la Cantidad en Stock que tiene la empresa de ese producto, su Precio de Venta. Cliente 1:1 origina Factura contiene Producto fig. 5 En esta nueva relación: 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 común 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 situación, la relación se implementa a partir de una nueva entidad llamada entidad asociativa, que es definida, en este caso, por los muchos artículos que puede contener una factura y la cantidad de cada uno de ellos. Cliente 1:1 origina Factura contiene Producto Factura-Producto fig. 6 El respectivo modelo de base de datos sería: Clientes Facturas Factura-Producto Productos PK PK PK CodProd NomCli DomCli FK1 FechaFact ImpFact FK1 FK2 Cant_Prod CodProd DescrProd CantStock PrecioVta fig. 7

7 La entidad asociativa Factura-Producto es una entidad débil, que surge por la imposibilidad de relacionar directamente dos entidades por un atributo común. Por ese motivo, algunas herramientas de diseño, como la empleada en este artículo (Microsoft Office Visio 2003), generan tablas sin una clave principal y con las claves primarias de las dos tablas que relacionan, como claves secundarias. También puede considerarse que esos atributos conformen una clave primaria concatenada de la tabla. Estas entidades asociativas, además de la función 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 artículos que puede contener una factura y la cantidad vendida de cada uno de ellos. La tabla correspondiente contendrá más de un tuple por cada factura (uno por cada artículo que en ella se vendió). Resumiendo, para construir un modelo de entidad-relación es necesario: definir en primer lugar cuáles son las entidades interviniente en un proceso Luego, determinar las relaciones entre estas entidades Por último, se definen las claves primarias y secundarias, generándose así el modelo de Base de Datos Siguiendo estos pasos, es posible realizar el modelo de datos de cualquier proceso. Normalización de Datos Es una técnica para lograr el Modelo de Base de Datos Relacional, alternativa al diagrama de Entidad-Relación. 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 gestión 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 facturación. Los datos necesarios para el mismo son: FechaFact ImpFact CodProd DescProd CantProd PrecVta NomCli DomCli (Número de Factura) (Fecha de Factura) (Importe de la Factura) (Código del Producto vendido) (Descripción del Producto) (Cantidad del Producto vendido) (Precio de Venta del Producto) (Código del Cliente) (Nombre del Cliente) (Domicilio del Cliente) (Código Postal)

8 Se puede considerar a estos datos como una relación cuya clave principal es el Número de Factura. 1FN (primera forma normal). Consiste en analizar la relación que tiene cada dato con la clave principal. Aquellos que tienen una relación de (para una ocurrencia del dato clave, pueden existir más de una ocurrencia del dato analizado), se deben poner en una nueva relación, arrastrando con ellos la clave principal. Los datos que cumplen con esta condición se los conoce como grupos repetitivos FechaFact ImpFact NomCli DomCli CodProd DescProd CantProd PrecVta Se genera aquí una nueva relación con los datos relativos a los productos de la factura. Esta nueva relación tiene una clave, que siempre es la concatenación del valor de la clave de la nueva relación, con el valor de la clave de la relación original: CodProd +. 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 relación biunívoca 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 Código de Producto toma el valor A25, la Descripción del Producto siempre va a tener el valor lata de arvejas XX y viceversa. Estos datos se deben poner en una nueva relación, arrastrando el dato clave del que dependen. Esta situación se la denomina Dependencias parciales con la clave. En el ejemplo, DescProd y PrecVta tienen relación biunívoca con CodProd, luego: CodProd FechaFact CodProd DescProd ImpFact CantProd PrecVta NomCli DomCli 3FN (tercera forma normal). Aquí se analizan también las relaciones biunívocas pero entre datos no claves. Se las denomina dependencias transitivas. Se colocan en una nueva relación y, al igual que en la 2FN, arrastran el dato del que dependen, que será la nueva clave.

9 Facturas Factura-Producto Productos Clientes CodProd FechaFact CodProd DescProd NomCli ImpFact CantProd PrecVta DomCli Cada una de estas relaciones contienen los datos de una tabla. En el ejemplo, se obtienen el diseño del modelo la base de datos necesaria para el proceso de facturación de esta organización. Como se podrá observar, no difiere con el definido con el diagrama de entidad-relación (excepto por el dato Cantidad en Stock, que en este caso no fue relevado, pero que en caso de serlo se agregaría a la tabla Productos). Se dijo al comienzo de este tema, que esta técnica es alternativa al diagrama de entidad-relación. 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. Evolución Tecnológica para obtener Información para la toma de Decisiones. Las tecnologías de la información fueron evolucionando en cuanto a las herramientas para brindar información no estructurada a las organizaciones, que permita tomar decisiones sobre una base cierta, minimizando la incertidumbre. Según José Hernández Orallo la evolución podría sintetizarse de la siguiente manera: 60 s: Informes batch: la información es difícil de encontrar y analizar, poco flexible, se necesita reprogramar cada petición. 70 s: Primeros DSS (Decision Support Systems) y EIS (Executive Information Systems): basados en terminal, no integrados con el resto de herramientas. 80 s: Acceso a datos y herramientas de análisis integradas (conocidas como intelligent business tools): Herramientas de consultas e informes, hojas de cálculo, interfaces gráficos e integrados, fáciles de usar. Acceden a las bases de datos operacionales ( killer queries ). 90 s: Almacenes de Datos y herramientas OLAP. 00 s: Herramientas de Minería de Datos y Simulación. José Hernández Orallo, cruso sobre Datawarehouse y Datamining, Chihuahua - octubre De acuerdo a esta cronología, la característica de consultas no programadas que se definió en el punto Bases de Datos, pertenece a la década de los 80 s 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 tenía su propio lenguaje de consulta (query). Esto hacía que quienes los usaban, debían conocer las palabras y la sintaxis del lenguaje específico de la

10 base de datos que se estaba utilizando. Si cambiaba la base de datos por una decisión de cambio en el sistema de información o quizás por un cambio de trabajo del gerente, debía aprender un nuevo lenguaje. En la actualidad el lenguaje de consulta estructurado (SQL), es un estándar en todos los SGBD y su uso fue intensivo. Este uso tuvo un efecto colateral no deseado: la lentificación del sistema transaccional. Muchos usuarios consultando las bases de datos para analizar información hace que las transacciones sean más lentas. Hay que tener en cuenta que las bases de datos fueron pensadas para las transacciones y no para el análisis. La tecnología dio una respuesta a este problema creando herramientas específicas para el análisis de información (OLAP) Almacenes de Datos (Datawarehouse DW) Son bases de datos orientadas a soportar el proceso de decisión (decisiones no programadas). Su diseño es generalmente multidimensional (cubos y no tablas). Se alimenta en forma automática 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, información de la competencia, etc. ERP Base de Datos Fuentes Transaccional Externas Fuentes Externas Otros datos fuera fuera del OLTP del ERP Datawarehouse Bussines Intelligence OLAP Dataminig er trim. 2do trim. 3er trim. 4to trim. Este Oeste Norte DECISIÓN Los DW deben ser también diseñados en función de las necesidades de información para la toma de decisiones de una organización. De esta forma, se sistematiza y automatiza la obtención de la misma. Este diseño utiliza los datos de la BD transaccional y además pueden incorporar datos externos que se consideren necesarios. Además, para cumplir con su función, estos almacenes, deben ser actualizados periódicamente, precisamente, con los datos de la base de datos transaccional y con aquellos datos externos con los que fueron diseñados. Los almacenes de datos y las técnicas OLAP son formas efectivas y tecnológicamente avanzadas para integrar, transformar y combinar los datos para facilitar al usuario o a otros sistemas el análisis de la información.

11 La tecnología 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 técnicas OLAP para bases de datos tradicionales y otras tecnologías para extraer información de los almacenes de datos. Prof. Diana Cecilia Navarro Bibliografía: Martin, James Date, C.J. Hernández Orallo, José Organización de las Bases de Datos. Ed Prentice Hall Hispanoamericana, México ra edición Introducción a los Sistemas de Bases de Datos. Ed.Pearson Educación, México 2001, 7ma. Edición Curso sobre Datawarehouse y Datamining, Chihuahua, México - octubre 2003