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 (DW). 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.

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. 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.

1
Martin James “Organización de las Bases de Datos” , México 1977, pag. 19
 Las columnas representan
los atributos
Tabla CLIENTES

Cod.Cli NomCli DomCli CodPostal

A-121 Alvarez Ramón Sucre 1950 2000
A-331 Alonso César Italia 3334 2000
Las filas o tuples
B-005 Benitez Juan Paraguay 555 2000 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 CodCli Clave secundaria

1566 29-10-2008 1000 B-005 o foránea
1567 29-10-2008 500 A-121

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
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

SISTEMA GESTOR DE BASE DE

Usuariio 2 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.

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,
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.

1:1 1:M
Cliente 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 (1:M)”. 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 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 estaría representando el modelo de base de datos.

Clientes Facturas

PK CodCli PK NroFact

NomCli FechaFact
DomCli ImpFact
CP FK1 CodCli

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 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.

1:1
1:M 1:M 1:M
Cliente 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.

1:1
1:M 1:M 1:M
Cliente origina Factura contiene Producto

Factura-Producto

fig. 6

El respectivo modelo de base de datos sería:

Clientes Facturas Factura-Producto Productos

PK CodCli PK NroFact PK CodProd

NomCli FechaFact Cant_Prod DescrProd

DomCli ImpFact FK1 NroFact CantStock
CP FK1 CodCli FK2 CodProd PrecioVta

fig. 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:

NroFact (Número de Factura)

FechaFact (Fecha de Factura)
ImpFact (Importe de la Factura)
CodProd (Código del Producto vendido)
DescProd (Descripción del Producto)
CantProd (Cantidad del Producto vendido)
PrecVta (Precio de Venta del Producto)
CodCli (Código del Cliente)
NomCli (Nombre del Cliente)
DomCli (Domicilio del Cliente)
CP (Código Postal)

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 1:M (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”

NroFact NroFact
FechaFact CodProd
ImpFact DescProd
CodCli CantProd
NomCli PrecVta
DomCli
CP

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 + 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
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:

NroFact NroFact CodProd

FechaFact CodProd DescProd
ImpFact CantProd PrecVta
CodCli
NomCli
DomCli
CP

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.

Facturas Factura-Producto Productos Clientes

NroFact NroFact CodProd CodCli
FechaFact CodProd DescProd NomCli
ImpFact CantProd PrecVta DomCli
CodCli CP
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 2003

.
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
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.
Bussines Intelligence
OLAP
100
Datawarehouse Dataminig 80
ERP de Datos
Base 60
Es te
Fuentes
Transaccional 40 Oe ste
Externas
Fuentes Externas 20 Norte
Otrosdatos
Otros datosfuera 0
fuera
del del ERP
OLTP 1er 2do 3e r 4to
trim . trim . trim . trim .

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 también 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.
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 Organización de las Bases de Datos. Ed Prentice
Hall Hispanoamericana, México 1989. 1ra edición
Date, C.J. Introducción a los Sistemas de Bases de Datos.
Ed.Pearson Educación, México 2001, 7ma. Edición
Hernández Orallo, José Curso sobre Datawarehouse y Datamining,
Chihuahua, México - octubre 2003