Base 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.” 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. Todos los movimientos de las organizaciones son registrados en
la base de datos. Si hablamos de 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. Pueden tener tres tipos de
estructuras: Jerárquica, Red o Relacional (tablas bidimensionales relacionadas por un dato en
común). 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.

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). En cliente no puedo poner número de
factura porque puede haber muchas facturas para un mismo cliente.
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):

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. Busca los datos en la BD y los entrega a cada programa para que los procese.
Características de las Bases de Datos:
 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. 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 simple 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: Es una colección de herramientas conceptuales para describir los datos, las
relaciones que existen entre ellos, semántica asociada a los datos y restricciones de consistencia con
un diagrama de entidad relación. 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: 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.

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.

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 pueden 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:
1. Definir cuáles son las entidades intervinientes en un proceso.
2. Determinar las relaciones entre estas entidades.
3. Definir ordinalidades y cardinalidades.
4. Asignar atributos a cada entidad.
5. Definir las claves primarias y secundarias, generándose así el modelo de Base de Datos.
6. Mostrar entidades asociativas si las hubiere con sus atributos.
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. 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:
.

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

Redundancia:
 1- Sobra o demasiada abundancia de cualquier cosa o en cualquier línea.
2- Repetición o uso excesivo de una palabra o concepto.
3- Cierta repetición de la información contenida en un mensaje, que permite, a pesar de la
pérdida de una parte de este, reconstruir su contenido.
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.
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, útil para la obtención de información esporádica, no
prevista en el sistema transaccional, realizándose consultas en las tablas de las bases, muy útil para
el análisis de la información), 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): Colección de datos internos y externos a la
organización, integrados, no volátiles e históricos. 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 – online transactional processing) y de otras fuentes, tales como bases de
datos de proveedores, clientes, información de la competencia, etc.
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. 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.
Datamining: O minería de datos, es una tecnología que trabaja dentro del DW que permite la
búsqueda automática de relaciones, patrones, tendencias o reglas que expliquen el comportamiento
del sistema organizacional o de una área determinada. Basado en técnicas de inteligencia artificial.
SQL: El lenguaje de consulta estructurado o SQL (por sus siglas en inglés structured query
language) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar
diversos tipos de operaciones en éstas. Permite efectuar consultas con el fin de recuperar -de una
forma sencilla- información de interés de una base de datos. La forma básica de una consulta es:
 SELECT (lista de datos que se quieren conocer).
 FROM (Nombre de la tabla en la que se encuentran los datos).
 WHERE (Condiciones de búsqueda).
Ejemplo 1: A partir de una tabla de clientes con el siguiente formato:
CLIENTES
CodCli
NomCli
DomCli
CuitCli
CodPostal_Cli
Fecha_Ing_Cli
Se quiere obtener un listado de Nombres, Domicilio y CUIT
*SELECT – FROM: SELECT CodCli , NomCli, DomCli, CuitCli, FROM Clientes
Observación: No existe la cláusula WHERE porque no hay ninguna condición para la búsqueda. La
salida es un listado con todos los clientes de la tabla.
*WHERE: Luego de la cláusula WHERE: se especifican las condiciones que limitan la búsqueda a
sólo aquellos registros de datos en los cuales se está interesado. Es decir se establece una condición
de búsqueda, solo a través de comparaciones lógicas, tales como: >, <, =.
Importante: Sin esta comparación el uso de WHERE está mal. El orden de las cláusulas no debe
alterarse.
Ejemplo 2: Si se necesitan conocer los mismos datos de los clientes de Rosario, pero además
únicamente de aquellos que comenzaron a comprarle a la empresa en el año 2011:
 SELECT Nomcli, Domcli, CuitCli
  FROM Clientes
 WHERE CodPostal_Cli = 2000 AND Fecha Ing_Cli>31/12/2010
Ejemplo 3: Si quisiéramos los mismos datos de los clientes de Rosario y los de Funes
 SELECT Nomcli, Domcli, CuitCli
 FROM Clientes
 WHERE CodPostal_Cli = 2000 OR CodPostal_Cli=2132 AND Fecha Ing_Cli>31/12/2010
Ejemplo 4: Si de la misma tabla quisiera un listado de Nombres, Domicilio y Cuit clientes que
ingresaron entre el 01/01/2011 y el 30/06/2011.
 SELECT Nomcli, Domcli, CuitCli
 FROM Clientes
 WHERE Fecha Ing_Cli>31/12/2010 AND Fecha Ing_Cli< 01/07/2011
Otra alternativa a la solución anterior:
 SELECT Nomcli, Domcli, CuitCli
 FROM Clientes
 WHERE Fecha Ing_Cli BETWEEN(31/12/2010,01/07/2011)
*Utilización de la cláusula BETWEEN: Define un rango en la condición de búsqueda. Estos
Ejemplos corresponden a búsquedas de información en 1 sola tabla. Si la búsqueda de información
es en más de una tabla, el formato de la cláusula FROM, Cambia
Es importante aclarar que los atributos no van entre comillas y que cuando no es un numero se
utiliza comillas.