Gestión de la información

Bases de datos para aplicaciones B2C

  • Óscar Alavedra i Martí

    Óscar Alavedra i Martí

    Ingeniero de Telecomunicaciones por la Universidad Politécnica de Cataluña (UPC). Ha desarrollado su experiencia profesional en la UPC, como programador y administrador de sistemas informáticos y como jefe de la Unidad de Apoyo Técnico para el Servicio de Gestión Académica. Es colaborador en varios proyectos de comercio electrónico.

  • M. Àngels Rius Gavidia

    M. Àngels Rius Gavidia

    Licenciada en Informática por la Universidad Politécnica de Cataluña. Profesora asociada adscrita a la Escuela Universitaria Politécnica de Vilanova i la Geltrú desde 1996. Su ámbito de investigación se enmarca dentro del campo de las bases de datos. Actualmente es profesora propia de los Estudios de Informática y Multimedia de la Universitat Oberta de Catalunya.

PID_00160585
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares de los derechos.

Introducción

En los últimos años, las empresas han visto cómo Internet ha cambiado la manera de actuar de muchos de sus procesos, haciéndolos mucho más eficientes y rentables y, al mismo tiempo, ha permitido mejorar la relación y comunicación con los clientes, empleados y proveedores.
Para una empresa actual, la adaptación a los cambios que Internet le representa se convierte más en una necesidad que en una elección. La empresa que no adopte o no sepa adoptar bien estos cambios perderá ventaja competitiva respecto a los competidores que sí los hayan integrado en sus procesos.
Para conseguir utilizar eficientemente todas las ventajas que Internet nos ofrece, habrá que integrar bien todos los sistemas de información de la empresa, lo que no es una tarea fácil, dado que aquí interviene un gran número de procesos gestionados por diferentes personas y departamentos, que muy a menudo trabajan aislados unos de otros.
En este módulo nos centraremos en dos partes del sistema de información global de la empresa: el subsistema responsable de permitir las operaciones de venta de los productos a través de la Red y el encargado de ofrecer apoyo a la toma de decisiones, desde un punto vista estratégico.
El primer subsistema lo soporta la llamada base de datos operativa. Se denomina así porque está orientada a operaciones cotidianas relacionadas con los procesos de venta, como la elaboración y presentación del catálogo de productos (según los diferentes criterios que cliente debe elegir) y el almacenamiento de toda la información relativa a los pedidos (productos que ha elegido un determinado cliente).
El segundo subsistema lo soporta una base de datos diseñada a propósito para apoyar la toma de decisiones estratégicas para la empresa. Estudiaremos la necesidad de un segundo depósito de información y veremos un modelo de datos para esta base de datos estratégica orientado al análisis de las ventas. En el último apartado veremos cómo se debe aplicar el concepto de CRM para orientar la estrategia de empresa hacia el cliente en lugar de hacia el producto.

Objetivos

En los materiales didácticos de este módulo el estudiante encontrará la información indispensable para lograr los objetivos siguientes:

  1. Conocer el marco de referencia sobre el que se deben concebir las aplicaciones de comercio electrónico entre consumidor y empresa.

  2. Saber identificar dos grandes tipos de información, la que hace referencia a las operaciones de ventas de la empresa y la que es útil para la toma de decisiones.

  3. Comprender la importancia de las bases de datos como depósito de toda la información que gestiona una empresa en el entorno del comercio electrónico.

  4. Entender los modelos de datos, que se presentarán como genéricos, y ser capaz de introducir las modificaciones necesarias para adaptarlos a modelos de empresa específicos.

  5. Saber aplicar los mecanismos de manipulación de datos para gestionar las ventas de la empresa de la manera más adecuada.

  6. Comprender la necesidad de un data warehouse para transformar la información en ideas y acciones que repercutan en la productividad del negocio.

  7. Ser capaz de recopilar toda la información de interés para el negocio, de manera que ésta sirva para apoyar la gestión de relaciones con sus clientes.

1.Bases de datos, el motor del comercio electrónico

Desde el punto de vista de la gestión de la información, vemos un proceso de comercio electrónico como un conjunto de operaciones asíncronas entre varios agentes que se ubican en diferentes puntos de la Red.
El hecho de que la compra se realice a partir de una serie de flujos de información, que provienen de ubicaciones y agentes diferentes, requiere un depósito de datos capaz de almacenar e identificar unívocamente cada una de las transacciones económicas que se producen en el entorno web.
El elemento ("motor") que posibilita la compraventa en el entorno web son las bases de datos.
Se desprende, pues, que las bases de datos son la tecnología de gestión de la información que necesitamos, puesto que nos permiten integrar los datos y a la vez compartirlos entre múltiples usuarios.
Una vez justificado el uso de la tecnología que se debe emplear, analizaremos en qué contexto se sitúan las aplicaciones B2C y la información que éstas deben gestionar.

1.1.Escenario de una aplicación de comercio electrónico B2C

Existen diferentes tipos de comercio electrónico. En este módulo didáctico nos centraremos en el comercio electrónico B2C, que fácilmente introducen los dos agentes principales: la empresa (B) y el cliente (C). Por lo tanto, podemos ver el comercio electrónico B2C como la relación que se establece entre el cliente y la empresa durante el proceso de compra.
Dado que esta relación se produce entre dos agentes, la analizaremos desde dos puntos de vista, en primer lugar, desde la perspectiva de la empresa y, en segundo lugar, desde el punto de vista del cliente.
1.1.1.B2C desde el punto de vista de la empresa
Uno de los objetivos principales de una empresa es la venta de sus productos.
Una aplicación para vender productos en entorno web ha de ser capaz de gestionar el catálogo de productos y facilitar su mantenimiento. Esto implica que deberá permitir dar de alta productos, modificar sus características (precio, descripciones), eliminarlos del catálogo y consultar la disponibilidad de existencias en todo momento.
Para poder vender el mayor número de productos, el vendedor también debe poder ofrecerlos al mayor número de clientes posible. La mejor manera de conseguirlo será que la web pueda mostrar toda la información relativa a los productos en varios países y, por lo tanto, en diferentes idiomas y expresando las cantidades monetarias con la moneda de cada país.
Además, un punto importante para el vendedor es la parte de la transacción en la que se efectúa el pago del producto. La importancia del sistema de pago en las aplicaciones de comercio electrónico obliga a un tratamiento más exhaustivo, que se estudia en el módulo didáctico "Sistemas de pago electrónico".
Otro requisito que debe satisfacer la aplicación B2C, para apoyar la venta de productos, es mantener el registro de los pedidos realizados por los clientes. Por lo tanto, debe ser posible almacenar los datos de envío y de pago para cada cliente al mismo tiempo que grabar las referencias de los productos solicitados, la cantidad pedida de cada uno de ellos y su precio.
Por otro lado, puede resultar interesante conocer otros datos relacionados con los pedidos, como la fecha en la que se ha confeccionado el pedido, el tiempo empleado en realizarlo, el tipo de navegador utilizado, etc.
Una vez que la aplicación cubre las necesidades de gestión de productos, pedidos y clientes, el empresario se puede plantear pedir apoyo a la aplicación para extraer información que lo ayude en la estrategia de la empresa.
Por ejemplo, puede ser útil disponer de información en lo referente a las preferencias de sus clientes y otros visitantes, dado que, así, el vendedor podrá adaptar la política de marketing de la empresa con más garantías de éxito.
Otro ejemplo podría ser que la empresa utilizara esta información para segmentar el mercado y, en consecuencia, poder ofrecer condiciones especiales para diferentes tipos de clientes (descuentos, promociones, etc.) y personalizar el trato con el cliente.
1.1.2.B2C desde el punto de vista del cliente
Respecto al cliente, el objetivo primordial es utilizar la Red para poder comprar de manera rápida, cómoda y segura.
El comercio electrónico debe permitir al cliente localizar rápidamente y de una manera sencilla el producto que más se ajusta a sus necesidades. Es la aplicación B2C la que ha de posibilitar suficiente flexibilidad en cuanto a criterios de búsqueda y, a la vez, facilitar la elección de productos, mostrando aquellas características que ayuden al consumidor en su elección.
Una vez decidido el producto o productos de interés, el cliente espera gestionar fácilmente su pedido. Por lo tanto, la aplicación B2C ha de permitir añadir productos, eliminarlos y modificar las cantidades que se desea comprar. Y no sólo esto, también debe obtener una referencia que identifique su pedido, bien por razones de seguimiento de la compra, bien para posibles reclamaciones.
Cuando se ha realizado el pedido, el comprador debe llevar a cabo el pago. Las propiedades de seguridad que ha de tener este pago están descritas en el módulo didáctico "Seguridad en el comercio electrónico" y la descripción cuidadosa de los diferentes sistemas de pago electrónico la encontraréis en el módulo didáctico "Sistemas de pago electrónico".
Si el cliente está satisfecho con sus compras anteriores, puede interesarle registrarse. El hecho de registrarse le permitirá hacer más sencillo el proceso de confección de pedidos posteriores y así evitará la necesidad de volver a introducir sus datos, que son comunes en todos los pedidos. El registro de un cliente puede reportarle todavía más ventajas, dado que la aplicación lo reconocerá a partir del momento en el que se haya registrado y, por lo tanto, le podrá presentar ofertas más adaptadas a sus preferencias.

1.2.Información operativa frente a información de ayuda a la toma de decisión

Si nos fijamos en el escenario descrito en los subapartados anteriores, vemos que cualquier empresa que opera por medio de Internet gestiona un gran volumen de información. Por lo tanto, podemos distinguir dos grandes categorías: información para las operaciones de la empresa e información de ayuda a la toma de decisiones.
La información necesaria para la venta y catalogación de productos es la información operativa de la empresa.
Organizaremos la información operativa en una base de datos convencional, que denominaremos base de datos operativa. Esta base de datos se diseñará según el modelo entidad interrelación (1) (ER) y utilizando la tecnología que ofrecen las bases de datos relacionales.
La información útil para tomar decisiones estratégicas es la que denominaremos información de ayuda a la toma de decisiones o información estratégica.
Para este otro tipo de información, la organización de los datos será diferente a la de la base de datos operativa, ya que su finalidad también es otra. Estamos hablando de la base de datos estratégica o data warehouse.
El hecho de aprovechar datos generados durante el tiempo de vida del negocio y utilizarlos para temas más estratégicos y de personalización de trato con el cliente no es nuevo. En las aplicaciones B2C, la condición de no presencia de éstas implica que a los clientes se los conoce exclusivamente a partir de los datos históricos de sus compras, razón por la cual resulta fundamental tenerlas almacenados.
En resumen, las aplicaciones de comercio electrónico mantienen paralelamente dos bases de datos: la operativa y la estratégica (data warehouse).

2.Base de datos operativa

En este segundo apartado nos centraremos en el estudio de toda la información que interviene en el proceso de comercio electrónico desde el punto de vista del conjunto de operaciones de la empresa.
Inicialmente, estudiaremos un pequeño ejemplo de transacción económica vía web para comprender mejor cuál es la información que almacenará esta base de datos. Después, teniendo en cuenta el escenario de la aplicación B2C en su vertiente operativa, diseñaremos la base de datos y determinaremos qué operaciones son útiles para este entorno.

2.1.Agentes de una transacción económica

Empezaremos mostrando un posible proceso de compra a través de la web.
Este proceso de compra electrónica nos permitirá analizar una secuencia de pasos, entre cliente o comprador y vendedor (tienda o empresa), que debe conducir a la conclusión de la transacción económica.
La figura siguiente muestra la secuencia de una transacción económica de compraventa:
Figura 1
Figura 1
La descripción de los pasos de la compraventa es la siguiente:
1. El cliente accede a la tienda virtual.
2. El vendedor permite la visualización de su catálogo de productos según unos criterios de selección.
3. El cliente visualiza los productos de acuerdo con uno de los criterios de selección, el que más se ajuste a sus necesidades.
4. El cliente confecciona su pedido.
5. El vendedor presenta el desglose del pedido.
6. El cliente confirma los datos del pedido.
7. El vendedor solicita datos al cliente: de envío, contacto, etc.
8. El cliente complementa los formularios de datos.
9. El vendedor comprueba que los datos del cliente son válidos.
10. El cliente realiza el pago.
11. El vendedor envía el pedido al comprador.
La secuencia anterior ayudará a identificar todos los agentes que intervienen en ella y el modo como éstos interaccionan.
Fijaos en que, en principio, intervienen dos agentes (CLIENTE, VENDEDOR) y varios tipos y flujos de información (datos de productos, pedidos, pago, etc.).
En la figura 1, también resulta evidente que el desglose de la secuencia se ha realizado en función del agente que genera un nuevo flujo en cada paso. Encontramos la explicación en el hecho de que la transacción económica es soportada por un entorno cliente-servidor.
Tampoco es difícil ver que la base de datos tiene un papel fundamental en este escenario, dado que hay que almacenar los datos que se van generando a lo largo de todo el proceso y, a la vez, debe ser posible identificarlos, de manera que se pueda ver el proceso de compra como un ente único.

2.2.Diseño de la base de datos

El objetivo de este segundo apartado es diseñar la base de datos operativa del vendedor. Tal como hemos visto en el apartado anterior, los tres agentes que nos interesan son el vendedor, para quien hacemos el modelo de datos, el cliente, que es la pieza clave del modelo, y las entidades bancarias, agentes intermediarios que intervienen puntualmente en el proceso de pago y de las que no pretendemos hacer ningún modelo de datos.
Para diseñar la base de datos operativa utilizaremos los principios de diseño de una base de datos, el modelo ER y su transformación en relacional.
Si bien estas metodologías son necesarias e imprescindibles para abordar con éxito un buen modelo de datos, no debemos olvidar que, en aplicaciones de envergadura como las B2C, un buen diseño va precedido de un buen análisis de requisitos. Este análisis nos ayudará a identificar todos aquellos aspectos que se deben modelar y tener en cuenta en el momento de elegir las estructuras de datos capaces de soportar todos los requisitos.
Es un hecho que todas las empresas comparten gran parte del modelo de datos, aproximadamente un 50%, dado que la manera de operar de todas éstas es muy común. En el supuesto que nos ocupa, empresas que venden sus productos a través de Internet (B2C), esta similitud puede llegar a ser superior al 75%, lo que nos deja un margen muy reducido para variar el modelo de datos y hacerlo exclusivo para una empresa en concreto.
2.2.1.Diseño conceptual
El objetivo de la etapa de diseño conceptual es obtener una estructuración de la información independientemente de la tecnología que hay que emplear.
Para ello, modelaremos los datos que intervienen en el escenario de las aplicaciones B2C usando el modelo ER. El diagrama ER nos ayudará a entender el porqué de ciertas relaciones y atributos, dado que la razón de ser de alguno de éstos se dará por la misma manera de operar empresarial.
De manera general, hemos visto que, en el tipo de aplicaciones que estamos considerando, los clientes, por medio de la web, compran productos, y que el mecanismo habitual para solicitar los productos es mediante la confección de un pedido. Por lo tanto, resulta fácil entender que intervengan en el modelo conceptual las entidades siguientes: PRODUCTOS, CLIENTES y PEDIDOS. Dado que el escenario descrito en el apartado anterior es mucho más complejo, desarrollaremos el diagrama ER a partir de estas entidades señaladas como relevantes.
Figura 2. Modelo conceptual de datos de la base de datos operativa
Observad en el diagrama ER que la entidad IDIOMA es la que se interrelaciona con un mayor número de entidades.
Ampliación
Observad en el diagrama ER que la entidad IDIOMA es la que se interrelaciona con un mayor número de entidades.
Si nos fijamos en el diagrama ER de la figura 2, a primera vista se desprende que la entidad IDIOMA tiene un papel tan destacado, o más, como las otras tres entidades antes mencionadas.
Las aplicaciones B2C deben permitir la venta de productos a diferentes países y, por lo tanto, todos aquellos atributos que contienen un valor textual que se haya de mostrar en la web se deberán almacenar en diferentes idiomas.
Dado que la base de datos ha de guardar cada descripción en más de un idioma y uno de los principios del buen diseño de las bases de datos consiste en evitar la redundancia de datos, se ha hecho necesario considerar nuevas entidades para guardar sólo una vez cada descripción en cada idioma.
Tal como se ha comentado antes, el diagrama ER es la representación de un modelo conceptual de datos genérico para el escenario en el que nos encontramos. Lo estudiaremos centrándonos en cada una de las entidades principales identificadas (CLIENTE, PRODUCTO, PEDIDO e IDIOMA) y sus interrelaciones con el resto de entidades.
Cliente
Para conseguir uno de los objetivos de la aplicación B2C, que es ofrecer la máxima facilidad de compra a los clientes, se les permite confeccionar su pedido sin pedirles ningún tipo de información hasta el momento de confirmarlo. Para permitir este funcionamiento se debe distinguir entre clientes registrados y no registrados.
Los clientes no registrados compran sin que la aplicación los reconozca; por lo tanto, a pesar de que compren varias veces, se consideran como si fueran clientes diferentes.
Los clientes registrados son aquellos de los que la base de datos contiene la información siguiente: datos personales, datos sobre su historial de compras y datos adicionales para identificarlos en el caso de que alguno olvide su código secreto.
La ventaja para el usuario registrado es que podrá ahorrarse el hecho de cumplimentar los formularios correspondientes a los datos personales y de envío en el proceso de compra y que el sistema, al identificarlo, le puede ofrecer ofertas en función de sus preferencias.
Dado que los clientes pueden ser uno de estos dos tipos, registrados y no registrados, parece lógico que conceptualmente se representen mediante una jerarquía de especialización-generalización diferenciada y completa a la vez.
Respecto a los clientes registrados, es interesante que la aplicación pueda tener en cuenta sus preferencias. Esta información, por el hecho de ser estratégica, también se almacenará en la base de datos estratégica. En la base de datos operacional normalmente guardaremos una información sobre clientes que servirá para establecer una clasificación de clientes por tipos y, de ese modo, ofrecerles descuentos para grupos o colectivos. Si la manera de operar de la empresa tiene en cuenta esta clasificación y queremos evitar la redundancia de datos, deberemos separar en el módulo conceptual de datos el atributo tipo de cliente del resto de atributos del cliente, que son específicos de cada uno. De aquí la necesidad de la entidad TIPO CLIENTE que contiene los atributos que comparten todos los clientes de un mismo tipo.
La interrelación ASOCIACIÓN representa el hecho de que los clientes están clasificados por tipos. Fijaos en que se trata de una interrelación M-N; esto significa que es posible que un cliente pertenezca a varios tipos de cliente a la vez y, dado que el número de clientes que debe permitir la base de datos no ha de ser restrictivo, más bien al contrario, es necesario tener en cuenta la posibilidad de que varios clientes puedan ser de un mismo tipo.
Por otro lado, teniendo en cuenta que la base de datos debe contener información en varios idiomas y las descripciones de los diferentes tipos de clientes han de estar en diferentes idiomas, es normal que la entidad TIPO CLIENTE se relacione con la entidad IDIOMA. En un mismo idioma tendremos la descripción de cada uno de los tipos de cliente posible y se podrá describir un mismo tipo de cliente en diferentes idiomas. Vemos, pues, que por este motivo existe la interrelación DESC_TIP_CLI entre IDIOMA y TIPO CLIENTE, que es M-N.
Figura 3
Figura 3
PRODUCTO
La entidad PRODUCTO representa los diferentes productos que forman parte de un catálogo de productos y, por lo tanto, que la empresa vende. Esta entidad almacenará los atributos que describen las características de cada producto con independencia del idioma.
Asimismo, dado que la aplicación debe ofrecer la máxima flexibilidad a los clientes para localizar el producto que desean, los productos, del mismo modo que se ha operado con los clientes, han de poder clasificarse en función de características comunes. En la entidad TIPO PRODUCTO se guardan todos los datos comunes a todos los productos de un mismo tipo y esta entidad se interrelaciona con PRODUCTO mediante la interrelación PERTENECER.
La interrelación PERTENECER asocia los productos con los tipos de productos y es M-N, ya que de un tipo de producto existen varios productos de este tipo, y un producto específico se puede catalogar en varios tipos de producto. A la vez, teniendo en cuenta que el cliente debe poder localizar los datos de un producto según varios criterios de búsqueda, hay que posibilitar diferentes maneras de acceso. Por esta razón, es necesario que los diferentes tipos de producto se puedan relacionar unos con otros, lo que posibilitará establecer relaciones, de producto más genérico o más especializado. De aquí la interrelación reflexiva CLASIFICACIÓN, que también es M-N, y con opcionalidad para ambos lados, ya que para cada pareja de tipo de producto puede haber relación o no con otras instancias de tipos de producto.
Ejemplo de clasificación por tipo de producto
Si el producto que hay que vender fuera un libro que viniera identificado por su International Standard Book Number (ISBN), también se podría clasificar por ámbito temático. De más general a más específico, podríamos catalogarlo como libro técnico; dentro de los libros técnicos se localizaría en el ámbito de la informática y más concretamente en una área de conocimiento dentro de la informática, por ejemplo, las bases de datos.
Dado que los datos referentes a productos deberán aparecer tanto en el catálogo que se presenta al cliente como en el pedido, será necesario que todos aquellos atributos de producto que sean de tipo texto y se deban presentar en diferentes idiomas se separen de la entidad PRODUCTO, evitando así la redundancia de datos.
Por este motivo, en el diagrama ER existe la interrelación DESC_PROD con grado M-N, ya que permite modelar el hecho que un producto se pueda describir en varios idiomas y que en un idioma se pueda describir más de un producto. Si queremos almacenar varias descripciones de un producto, pongamos por caso, una descripción resumida, una detallada y otra cara a la publicidad, estos atributos serían atributos de la interrelación DESC_PROD.
Análogamente a lo que hemos comentado para los tipos de cliente, los tipos de producto también tienen una descripción que interesa almacenar en los diferentes idiomas. Por lo tanto, la interrelación DESC_TIP_PROD establece la interrelación entre TIPO PRODUCTO e IDIOMA. Precisamente, como atributo de interrelación tendríamos la descripción del tipo de producto en el idioma que corresponda, y los atributos comunes a todos los productos del mismo tipo que no fuera necesario traducir irían a la entidad TIPO PRODUCTO.
Figura 4
Figura 4
PEDIDO
El pedido es precisamente el nexo entre CLIENTE y PRODUCTO, ya que, una vez que el cliente ha seleccionado los productos que desea, los pide formulando el pedido. Del pedido se han de almacenar muchos datos, por lo que parece lógico representarlo como entidad en lugar de hacerlo como interrelación entre CLIENTE y PRODUCTO.
Un pedido tendrá, además de los datos de los productos seleccionados, los datos de facturación (a quién enviar la factura) y de envío (a quién se envían los productos del pedido). Estos datos los guardaremos en la entidad FACTURA_ENVIO, que se interrelacionará con PEDIDO en grado 1-N.
Si consideramos que el PEDIDO lo CONFECCIONA un cliente y que un cliente puede hacer muchos pedidos o ninguno (en el supuesto de que se registre, pero no compre), tenemos una interrelación 1-N con opcionalidad en la parte N.
Tal como hemos mencionado antes, el pedido contiene mucha información y, como es habitual, distinguimos entre cabecera del pedido y línea de pedido.
Los datos del pedido se almacenan en varias entidades: PEDIDO, FACTURACION_ENVIO y LINEA_PEDIDO.
La información que se almacena en la entidad FACTURACION_ENVIO contiene datos sobre el destinatario de los productos pedidos (no debe coincidir necesariamente con el cliente, imaginemos que se trata de un regalo) y también sobre facturación (a quién se le envía la factura del pedido). La cabecera del pedido almacena datos sobre el pago, opción de envío, etc. El pedido SE-COMPONE de muchas líneas de pedido. Cada línea es la petición de un producto en un pedido, por lo tanto, la podíamos haber representado como interrelación entre pedido y producto. Pero si consideramos que la existencia de una línea de pedido está condicionada por la existencia del pedido, podemos representarla como entidad débil.
La entidad LINEA_PEDIDO se relaciona con PRODUCTO por la interrelación REFERIR_SE, puesto que una línea de pedido siempre se refiere a un producto (referencia, precio unitario, número de unidades, etc.) y un producto puede figurar en varias líneas de pedido o en ninguna; por lo tanto, se trata de una interrelación 1-N con opcionalidad en la parte N. De este modo, se refleja la relación que existe entre PRODUCTO y PEDIDO.
Dentro del argot que se utiliza en el mundo web, el pedido correspondería al "carro, bolsa o cesta de la compra" que todos estamos acostumbrados a ver en las tiendas virtuales, mientras que cada producto dentro de la "cesta" correspondería a una línea de pedido.
De nuevo, debemos considerar el efecto que tiene la diversidad de idiomas sobre los datos del pedido que poseen valores textuales diferentes para cada idioma.
Habrá que mostrar la información sobre el estado del pedido en el idioma del cliente y, por lo tanto, conviene tenerlo separado de la cabecera del pedido. Dado que puede haber muchos pedidos en un mismo estado y un pedido en todo momento tiene un único estado, la interrelación entre PEDIDO y ESTADO_PEDIDO es 1-N. La misma consideración sirve para los datos referentes al modo de envío (FORMA_ENVIO) y al de pago (FORMA_PAGO). Todas estas entidades que contienen información descriptiva del pedido según el idioma se relacionarían con la entidad IDIOMA con grado N-M, tal como hemos visto previamente al describir el entorno de las entidades CLIENTE y PRODUCTO.
Figura 5
Figura 5
IDIOMA
En la entidad idioma se almacenará el código de idioma con su descripción en un idioma de referencia.
Cualquier entidad que esté relacionada con idioma mediante una interrelación M-N contendrá los atributos de interrelación que son la descripción del atributo en cualquier idioma.
Codificación de idiomas
Supongamos la entidad ESTADO_PEDIDO, que puede tener tres estados posibles –pendiente, en proceso y retenido, codificados respectivamente por los códigos 10, 20 y 30–. En ese caso, la interrelación DESC_ESTADO contendría para cada idioma la traducción de cada uno de los valores posibles del atributo que describe el estado. Para el estado 10 en el idioma 0 (catalán), el valor del atributo sería "pendent", para el idioma 1 (castellano), "pendiente" y para el idioma 2 (inglés) "pending"; para el estado 20 en el idioma 0 el valor asociado sería "en procés", en el idioma 1 "en proceso" y en el idioma 2 "processing", etc.
2.2.2.Diseño lógico
Para obtener el diseño lógico de la base de datos operativa, partiremos del modelo conceptual genérico presentado y lo transformaremos para que se adapte a la tecnología que se deba emplear.
En nuestro caso, usaremos las bases de datos relacionales; por lo tanto, en esta etapa obtendremos un conjunto de relaciones con sus atributos, claves primarias y foráneas.
Traduciremos el modelo conceptual por partes, considerando el entorno en las entidades destacadas (CLIENTES, PRODUCTO, PEDIDO e IDIOMA).
CLIENTE
Las relaciones obtenidas a partir de la transformación relativas a clientes son las siguientes:
CLIENTE (id_cliente)
CLIENTE_REGISTRADO (id_cliente, nif, nombre, apellidos, e-mail,
contraseña, pregunta, respuesta, fecha_nacimiento,
estado_civil, fecha_primera_compra, fecha_ultima_compra
importe_acumulado_compras , numero_compras, baja_logica)
donde {email} es clave alternativa
donde {id_cliente} referencia CLIENTE
CLIENTE_NO_REGISTRADO (id_cliente)
donde {id_cliente} referencia CLIENTE
TIPO_CLIENTE (id_tipo_cliente, dto)
DESC_TIP_CLI (id_tipo_cliente, id_idioma,
descripcion_tipo_cliente)
donde {id_tipo_cliente} referencia TIPO_CLIENTE y
{id_idioma} referencia IDIOMA
ASOCIACION (id_cliente, id_tipo_cliente)
donde {id_cliente} referencia CLIENTE y
{id_tipo_cliente} referencia TIPO_CLIENTE
Observamos que la relación CLIENTE NO REGISTRADO no aporta más información adicional de la que aporta la relación CLIENTE y, por lo tanto, en el nivel lógico podemos prescindir de ella. Si en algún momento fuera necesario almacenar algún dato que no contiene la entidad CLIENTE_REGISTRADO, entonces tendría sentido considerarla.
Observad que la relación CLIENTE, a pesar de tener un único atributo, no la eliminamos porque los clientes no registrados también pueden comprar y, por lo tanto, pueden hacer pedidos.
También es interesante destacar que, en la relación TIPO_CLIENTE, no tenemos la descripción del tipo de cliente, ya que para un mismo código de cliente tendríamos varias descripciones, una por cada idioma. La descripción del tipo de cliente está en la interrelación DESC_TIP_CLI, de manera que aseguramos que haya una única descripción para cada tipo de cliente e idioma.
Gráficamente podemos ver esta parte del diseño lógico tal como se muestra a continuación:
Figura 6
Figura 6
PRODUCTO
Las relaciones obtenidas a partir de la transformación relativas a productos son las siguientes:
PRODUCTO (id_producto, precio_actual, es_oferta,
precio_oferta, reserva_inicial, reserva_actual, reserva_notificacion)
TIPO_PRODUCTO (id_tipo_producto, dto)
DESC_TIP_PROD (id_tipo_producto, descripción, id_idioma)
donde {id_tipo_prod} referencia TIPO_PRODUCTO y
{id_idioma} referencia IDIOMA
CLASIFICACION (id_classid, id_tipo_generico, id_tipo_especifico)
donde {id_tipo_prod_generico} referencia TIPO_PRODUCTO y {id_tipo_prod_especifico}
referencia TIPO_PRODUCTO
DESC_PROD (id_producto, id_idioma, descripcion_corta,
descripcion_larga)
donde {id_producto} referencia PRODUCTO y
r{id_idioma} eferencia IDIOMA
PERTENECER (id_producto, id_tipo_producto)
donde {id_producto} referencia PRODUCTO y
{id_tipo_producto} referencia TIPO_PRODUCTO
Observad que, tal como sucedía con la descripción tipo de cliente, la diversidad de idiomas hace que se deban relacionar los productos (PRODUCTO) o tipo de productos (TIPO_PRODUCTO) con las descripciones para cada idioma, lo que da lugar a las respectivas DESC_PROD y DESC_TIP_PROD.
Podéis ver la representación gráfica de esta parte del diseño lógico a continuación:
Figura 7
Figura 7
Ampliación
PEDIDO
Las relaciones obtenidas a partir de la transformación relativa a pedido son las siguientes:
FACTURA_ENVIO (id_fact_env, nif, nombre, apellidos,
dirección, población, codigo_postal, país, teléfono, fax
e-mail, nombreenv, apellidosenv, direccionenv,
poblacionenv, codigo_postalenv, paisenv)
ESTADO_PEDIDO (id_estado)
FORMA_ENVIO (id_envio)
FORMA_PAGO (id_pago)
PEDIDO (id_pedido, id_cliente, id_fact_env, total_pedido,
fecha_pedido, hora_inicio_compra,
hora_final_compra, direc_ip_compra,
id_estado,num_transaccion, fecha_transaccion,
id_resultado_tansaccion, id_pago, id_envio,
fecha_entrega, hora_entrega)
donde {id_estado} referencia ESTADO_PEDIDO,
{id_envio} referencia FORMA_ENVIO,
{id_pago} referencia FORMA_PAGO
LINEA_PEDIDO (id_linea, id_pedido, id_producto, descripcio,
unidades, precio_unitario_bruto, dto, precio_neto)
donde {id_producto} referencia PRODUCTO,
{id_pedido} referencia PEDIDO.
DESC_ENV (id_envio, id_idioma, descripcion)
donde {id_idioma} referencia IDIOMA
DESC_ESTADO (id_estado, id_idioma, descripcion)
donde {id_idioma} referencia IDIOMA
DESC_PAG (id_pago, id_idioma, descripcion)
donde {id_idioma} referencia IDIOMA
Análogamente a lo que hemos observado para las descripciones referentes a clientes y productos, sucede con otros atributos de pedido, como el estado, el modo de envío y el de pago, que se separan de los datos del pedido para que las descripciones consten en la base de datos una sola vez por idioma.
Observad que, en la relación PEDIDO, guardamos la id_cliente, que puede referirse tanto a un cliente anónimo no registrado (CLIENTE) como a un cliente registrado.
A continuación mostramos la representación gráfica del diseño lógico en lo referente a los pedidos.
Figura 8
Figura 8
Ampliación
IDIOMA
Las transformaciones referentes a la entidad IDIOMA han ido apareciendo al hacer las transformaciones del diseño conceptual, considerando el entorno de CLIENTE, PRODUCTO y PEDIDO. Por lo tanto, nos queda únicamente la relación IDIOMA, que constará de los atributos id_idioma y descripcion (expresados en el idioma de referencia).
IDIOMA (id_idioma, descripcion)
2.2.3.Diseño físico
La etapa de diseño físico tiene como objetivo el buen rendimiento de la base de datos. Para ello se debe transformar el diseño lógico para obtener más eficiencia y tener en cuenta ciertos aspectos de implementación física que dependen del sistema de gestión de la base de datos (SGBD).
Teniendo en cuenta que nosotros no fijamos ningún SGBD, sino que damos orientaciones generales, esta etapa no la desarrollaremos. Únicamente, después de haber detallado los procesos que consultan y actualizan los datos, y a sabiendas de los caminos de acceso que se utilizarán, así como las frecuencias de ejecución, podremos desarrollar esta etapa para un marco de referencia concreto.

2.3.Manipulación de datos

En este apartado nos centraremos en las operaciones básicas de manipulación de datos que permitirán, de manera cómoda y eficaz, el funcionamiento de esta base de datos. Por lo tanto, estudiaremos las operaciones que hay que realizar sobre una base de datos operativa y lo haremos fijándonos en los agentes que intervienen (tal como hicimos en la etapa de diseño) y en los parámetros de entrada y salida de estas operaciones.
Las diferentes operaciones que se mostrarán se indicarán mediante el nombre de la operación seguida de la lista de parámetros de entrada entre paréntesis y los parámetros de salida o acciones que realice la operación se explicarán a continuación, pero no aparecerán en la firma de la operación, para que sean adaptables a diferentes implementaciones.
Distinguiremos dos tipos de operaciones según el entorno en el que se ejecuten: las operaciones que se realizan por medio de la red pública, es decir, aquellas que se realizarán a petición del cliente desde Internet, y las operaciones que se llevan a cabo a través de la red interna (intranet) por parte de la propia empresa, es decir, aquellas operaciones restringidas a usuarios con privilegios.
De los diferentes mecanismos de los que dispone una base de datos para gestionar la información (vistas, procedimientos almacenados y disparadores), básicamente utilizaremos los procedimientos y, en algunos casos, los disparadores. Las vistas no se utilizan porque la mayoría de las operaciones requieren parámetros de entrada.
También debemos tener en cuenta que ciertas operaciones se han de tomar como unidad básica de trabajo a efectos de concurrencia e integridad. Por ejemplo, un alta de producto implica su inserción en dos tablas, la tabla PRODUCTOS y la tabla DESC_PROD, y, en consecuencia, habrá que definir una transacción que contenga ambas operaciones y asegure la consistencia de la base de datos.
2.3.1.Catálogo de productos
El catálogo es la exteriorización en formato web de los productos que el vendedor ofrece a sus clientes por medio de operaciones de consulta.
El vendedor se encargará del mantenimiento del catálogo de productos, por lo tanto, deberá disponer de operaciones que lo mantengan actualizado.
Mantenimiento del catálogo de productos
Todas las operaciones de mantenimiento (altas/bajas/modificaciones) se realizarán, por parte de la empresa, desde el entorno restringido (intranet).
1) Altas
alta_producto_desc (id_producto, id_idioma, descripcion_corta,
descripcion_larga)
alta_producto_atributo (precio_actual, es_oferta, precio_oferta,
reserva_inicial, reserva_actual, reserva_notificación)
Estas dos operaciones permiten insertar los datos de un producto (características y descripciones) en el catálogo. La primera operación hace una inserción en la tabla DESC_PROD añadiendo las descripciones referentes al producto en un idioma.
La segunda operación añade, a la tabla PRODUCTO, los datos que son independientes del idioma. Observad que son necesarias ambas operaciones para hacer efectiva el alta de un producto y que se deberán ejecutar en una única transacción.
A continuación, veremos operaciones que permitirán jerarquizar los diferentes tipos de productos entre más genéricos y más específicos.
alta_tipo_producto_desc (id_tipo_producto,id_idioma,descripcion,dto)
alta_clasifica_producto (id_tipo_generico, id_tipo_especifico)
La operación alta_tipo_producto_desc permite dar de alta el tipo de productos en el idioma correspondiente. Esta operación tendrá doble funcionalidad: alta de tipo de productos nuevos con su descuento y alta de una nueva descripción por un tipo de producto dado.
Ejemplo de altas
alta_tipo_producto_desc (101, 0, ‘informática')
alta_tipo_producto_desc (102, 0, ‘biología')
alta_tipo_producto_desc (103, 0, ‘sistemas operativos'))
alta_tipo_producto_desc (104, 0, ‘sistemas gestores de bases de datos')
Supongamos que el sistema les asigna los id_tipos_producto 101, 102 y 103 y 104 respectivamente
alta_clasifica_producto (NULL,101)
alta_clasifica_producto (NULL,102)
alta_clasifica_producto (101,103)
alta_clasifica_producto (101,104)
Estas operaciones añadirán dos tipos de productos (informática y biología) al nivel superior de la jerarquía (que se indica con el id_tipo_generico igual a 0). Después se han dado de alta dos tipos de producto: sistemas operativos (id_tipos_producto 103) y sistemas gestores de bases de datos (id_tipos_producto 104) que tienen como grupo genérico informática.
2) Bajas
baja_producto (id_producto)
La operación baja_producto permitirá eliminar el producto del catálogo. Por un lado, suprimirá el registro de la tabla PRODUCTO correspondiente al id_producto especificado y, por otro, suprimirá las descripciones asociadas al producto en los diferentes idiomas.
3) Modificaciones
modifica_producto_desc (id_producto, id_idioma descripcion_corta,
descripcion_larga)
modifica_producto_atributo (id_producto, precio_actual, es_oferta,
precio_oferta,reserva_inicial, reserva_actual,
reserva_notificación)
Del mismo modo que en el caso de las altas, necesitaremos dos operaciones para modificar la información relativa a un producto.
Fijaos en que en las operaciones de modificación se deberán pasar por parámetro todos los atributos, cambien o no de valor.
alta_producto_tipo (id_producto, id_tipo)
baja_producto_tipo (id_producto, id_tipo_producto)
Estas dos operaciones permitirán gestionar la clasificación del producto, de manera que el producto se pueda catalogar dentro de un agrupamiento u otro, según convenga.
Dado que todas las operaciones de mantenimiento requieren parámetros de entrada, se implementarán mediante procedimientos almacenados.
Consultas del catálogo de productos
Todas las operaciones de consulta sobre el catálogo se realizarán en el entorno de la red pública.
productos_tipos (id_tipos_producto, id_idioma)
Esta operación permitirá obtener los datos de los productos a partir de alguno de sus agrupamientos y del idioma correspondiente. Por lo tanto, el resultado de esta operación devuelve un conjunto de registros (recordset).
Para poder solicitar los productos de un determinado tipo, el cliente debe poder saber qué agrupamientos de productos tiene el catálogo. Por lo tanto, será necesaria una operación que muestre la clasificación de los productos.
muestra_tipo_producto (id_tipo_producto, id_idioma)
Esta operación devolverá el conjunto de tipos de productos que dependen de un tipo más genérico, que es el indicado por el parámetro de entrada.
El usuario también querrá consultar los datos de productos según otras características diferentes del tipo de producto. Algunas posibles operaciones serían:
productos_precios (precio_inferior, precio_superior, id_idioma)
productos_palabra (palabra_clave, id_idioma)
Estas operaciones buscan los productos que cumplen unos requisitos específicos: con precio entre un intervalo de valores, con descripción que contiene una palabra clave, etc. Por lo tanto, también se obtendrá como resultado el conjunto de registros correspondientes a los productos que cumplan los criterios de búsqueda.
De nuevo, las operaciones descritas requieren parámetros de entrada y, por ello, se implementarán mediante procedimientos almacenados.
Actualización de reservas
Habrá operaciones sobre el catálogo de productos que provocarán la ejecución automática de otras operaciones relacionadas. El caso más típico es el control de reservas, ya que, cada vez que se produzca la venta de un producto, se deberá modificar el número de unidades disponibles en reserva de este producto.
modifica_reserva (id_producto, unidades_vendidas)
Para implementar esta operación, utilizaremos un disparador que se activaría como consecuencia de una actualización de la tabla PEDIDO y un valor concreto de id_estado que indicaría que el pedido es aceptado por la empresa.
2.3.2.Bolsa o cesta de la compra (pedidos)
La bolsa la compra representa, en cada momento y para cada cliente, el desglose de los artículos seleccionados para ser comprados. Requiere, pues, el detalle de datos para cada producto de la cesta: la referencia, descripción, unidades pedidas, subtotales por concepto, impuestos, importe del transporte, totales, etc.
El cliente se encargará de la confección del pedido y la empresa gestionará el estado de aquél.
Confección y gestión de pedidos
Un pedido se corresponde con un registro en la tabla PEDIDO y varios registros de la tabla LINEA_PEDIDO (uno para cada producto comprado).
Para confeccionar un pedido, necesitaremos realizar las operaciones siguientes:
1) Añadir un producto al pedido.
Para añadir un producto al pedido, deberemos comprobar si existe la cabecera del pedido o no. En caso de existir, únicamente habrá que añadir los datos correspondientes en la tabla LINEA_PEDIDO; de lo contrario, será necesario crear el pedido, haciendo una inserción en la tabla PEDIDO, lo que dará lugar a la cabecera, e insertar igualmente los datos del producto en la tabla LINEA_PEDIDO.
crea_pedido (fecha_inicio, direccion ip)
añade_pedido (id_producto, unidades, id_pedido)
Estas operaciones dan de alta un pedido y no devuelven ningún conjunto de registros.
2) Modificar una línea de pedido.
El cliente puede, en cualquier momento, modificar las unidades de los productos que hay que comprar:
modifica_pedido (id_linea, id_pedido, unidades)
Esta operación permitirá que el cliente pueda cambiar las unidades de cada uno de los productos de dentro de la bolsa, de manera que se deberán pasar como parámetro el código de línea y la id_pedido, que identifica unívocamente cada línea de la bolsa.
3) Eliminar una línea de pedido.
También se ha de ofrecer la posibilidad de suprimir algún producto del pedido:
elimina_pedido (id_linea, id_pedido)
Esta operación elimina el registro asociado a la tabla LINEA_PEDIDO.
4) Modificar información de un pedido.
Los datos del pedido se actualizan varias veces. Una actualización se produce cuando el cliente acaba de confeccionar el pedido e introduce los datos del destinatario, de envío y de modo de pago.
datos_pedido (nif, nombre, apellidos, dirección, población, codigo_postal,
país, teléfono, fax, e-mail, nombreenv, apellidosenv,
direccionenv, poblacionenv, codigo_postalenv, paisenv,
id_cliente, total_pedido ,
fecha_pedido, hora_inicio_compra,
hora_fin_compra, direcc_ip_compra,id_pago,
id_envio, fecha_entrega, hora_entrega)
Otra posible modificación de los datos del pedido se da cuando se conoce el resultado de la transacción económica de pago.
resultado_economico_pedido (id_pedido, num_transaccion,
fecha_transaccion, id_resultado_transaccion
Cuando cambia el estado del pedido también hay que actualizar el campo id_estado_pedido. La operación correspondiente sería la siguiente:
estado_pedido (id_pedido, id_estado)
Observad que el vendedor realizará esta última operación a través de la red privada (intranet).
5) Presentación de los datos del pedido.
Necesitaremos operaciones para mostrar los datos relativos a un pedido a partir del código de pedido (id_pedido):
datos_pedido (id_pedido)
Esta operación extrae todos los datos relativos al pedido. Por lo tanto, devolverá un conjunto de registros.
Observamos que las operaciones que manipulan el pedido se hacen desde la red pública, a excepción del cambio de estado del pedido. Todas requieren parámetros de entrada y, por lo tanto, se implementarán mediante procedimientos almacenados.
2.3.3.Clientes
Las operaciones relacionadas con los clientes serán operaciones de mantenimiento de sus datos personales, de gestión de su contraseña, de reconocimiento del cliente por parte de la aplicación y de seguimiento de las compras efectuadas.
Mantenimiento de los datos personales
Este mantenimiento se puede realizar tanto desde la red pública, en la que cada usuario podrá gestionar sus datos, como desde la red privada, en la que el vendedor podrá realizar modificaciones sobre los datos de cualquier cliente.
1) Alta de un nuevo cliente.
alta_cliente (nif, nombre, apellidos, e-mail, contraseña, pregunta, respuesta,
fecha_nacimiento, estado_civil)
Esta operación insertará un nuevo registro en la tabla CLIENTES.
2) Modificación de los datos de un cliente.
modifica_cliente (idclient, nif, nombre, apellidos, e-mail, contraseña,
pregunta, respuesta, fecha_nacimiento, estado_civil)
Un cliente, desde la red pública, podrá modificar sus datos personales. Esta operación actualizará el registro correspondiente al cliente con los nuevos datos.
3) Baja de un cliente.
baja_cliente (idcliente)
Esta operación actualizará un campo del registro de cliente indicando que es baja; físicamente no se borrará.
Todas las operaciones de este subapartado se implementarán como procedimientos almacenados.
Gestión de las contraseñas
Para restringir el acceso a la base de datos por medio de la red pública, se puede utilizar un proceso de autenticación vía usuario y contraseña. En este caso, la aplicación ofrecerá a los clientes la posibilidad de cambiar la contraseña personal y de recordarla en caso de olvido.
1) Cambio de la contraseña.
cambio_contraseña (id_cliente, contraseña)
Esta operación actualizará la contraseña del cliente. En el caso de hacerse desde la red pública, sólo se permitirá el cambio al cliente que lo solicite. En el supuesto de que la modificación se lleve a cabo desde la red privada, el vendedor podrá elegir el cliente cuya contraseña se quiere cambiar.
2) Recordatorio de la contraseña.
Es habitual tener que resolver la situación en la que un cliente olvida su contraseña. Por esta razón, en el formulario de alta se pide una pregunta y la correspondiente respuesta al usuario. La pregunta elegida por el cliente y la respuesta asociada deben servir para autenticarlo.
muestra_pregunta (e-mail)
verifica_respuesta (e-mail, respuesta)
La primera operación devuelve la pregunta asociada a la dirección de correo electrónico que se le pasa como parámetro de entrada. Fijaos en que en este caso particular tomamos la dirección de correo electrónico como login.
La segunda operación verifica si la respuesta de un determinado cliente (identificado por su correo electrónico) es correcta o no. La operación devolverá un booleano indicando el resultado de la comprobación.
Autenticación del cliente
Cuando un cliente entra en la red pública dentro del área clientes, se debe comprobar que la dirección de correo electrónico (2) y la contraseña corresponden a un cliente válido de la tabla CLIENTES.
user_login (e-mail, contraseña)
Esta operación debe comprobar que la combinación de correo electrónico y la contraseña corresponden a uno de los clientes registrados. Devolverá una variable booleana con el resultado de la comprobación, y el código de cliente en caso de cliente válido; entonces el código de cliente se almacenará en una variable global para usarlo posteriormente.
Una vez reconocido el cliente, se han de determinar los descuentos que le corresponden.
descuento_cliente (idcliente)
La operación descuento_cliente calcula el descuento más favorable para el cliente, dependiendo del tipo de cliente que sea. Devolverá el valor del descuento que se almacenará en una variable global para acceder a ella posteriormente.
Las dos operaciones se implementarán como procedimientos almacenados.
Seguimiento de las compras
Dentro de la tabla CLIENTE_REGISTRADO tenemos campos como la fecha de la primera compra, la de la última compra, el importe acumulado de las compras y el número de compras realizadas.
Toda esta información nos será útil para poder ofrecer condiciones particulares, dependiendo de los valores de estos campos; así, por ejemplo, podríamos ofrecer un descuento especial a los clientes que nos han comprado más de un cierto importe, a los que hace más de dos meses que no nos han comprado nada, a los que nos han comprado más de una vez dentro de la misma semana, etc.
Consideramos este tipo de información como operativa, dado que nos sirve para las operaciones diarias de la empresa. Para actualizar estos campos del registro de clientes, se hará uso de los disparadores.
fecha_primera_compra (idcliente)
fecha_ultima_compra (idcliente, fecha)
importe_acumulado_compras (idcliente, importe)
numero_compras (idcliente)
Todas estas operaciones actualizan un registro de la tabla CLIENTE y se implementarán con un disparador que se activa al actualizar la tabla PEDIDO, siempre que el resultado de la transacción haya sido correcto (id_resultado_tansacción=0 por ejemplo).
La operación fecha_primera_compra inserta la fecha actual del sistema si el valor del campo fecha_primer_pedido de la tabla CLIENTE tiene valor nulo. Análogamente, la operación fecha_ultima_compra inserta la fecha actual del sistema en el campo fecha_ultimo_pedido de la tabla CLIENTE.
La operación importe_acumulado_compras actualiza el campo importe_acumulado_compras incrementando el importe de la compra según la cantidad acumulada, campo total_pedido de la tabla PEDIDO, antes de producirse la compra.
La operación numero_compras actualiza el campo número de compras del cliente asociado incrementando el valor en una unidad.

3.Data warehouse: base de datos estratégica

Ahora que ya conocemos la parte operativa de una aplicación B2C, nos centraremos en la parte de apoyo en la toma de decisiones. Veremos que la base de datos estratégica ha de servir a los responsables de la empresa para tomar decisiones. El objetivo de esta base de datos es transformar información en acciones e ideas útiles para incrementar la productividad del negocio.
Iniciaremos el apartado viendo la necesidad de una base de datos estratégica que denominaremos data warehouse, detallaremos los rasgos más relevantes de este almacén de datos y, a continuación, veremos un ejemplo de modelo de datos orientado al análisis de las ventas. Una vez hecho el diseño, explicaremos cómo se realiza la alimentación del data warehouse y después veremos cómo explotarlo, extrayendo el conocimiento que nos sirva para mejorar las relaciones con los clientes.

3.1.Necesidad de un entorno estratégico

Recordad que en el primer apartado hablamos de dos tipos de información y de la necesidad de dos tipos de bases de datos. Hasta ahora sólo hemos tratado la información operativa.
¿Os imagináis que la base de datos que conocemos pueda dar respuesta a preguntas como las siguientes?

  • ¿Cuáles han sido los productos más vendidos durante los diferentes trimestres del año pasado?

  • ¿Qué efecto ha tenido una determinada campaña publicitaria sobre las ventas?

  • ¿Cómo podemos segmentar el mercado en función de las compras realizadas por los clientes de cada área, zona o país?

Para responder a la primera pregunta, es necesario disponer de información histórica. Nuestra base de datos operativa guardará información de las ventas durante los últimos sesenta o noventa días, un margen de tiempo insuficiente para extrapolar el comportamiento de las ventas y planificar el aprovisionamiento futuro.
La segunda pregunta se formularía para analizar los resultados obtenidos como consecuencia de una determinada acción hacia el mercado, para ver el efecto producido y plantearse llevar a cabo más campañas publicitarias o no o, cuando menos, para mejorar futuras promociones. Observad que deberíamos determinar el periodo de tiempo sobre el que analizaríamos las ventas y que necesitaríamos información del departamento de ventas que no tenemos en la base de datos operativa.
La tercera pregunta responde a un análisis de los clientes de la empresa por zona, área o país. Este análisis nos permitirá llegar a conocer las preferencias de compra de nuestros clientes según la zona geográfica y así poder ofrecer promociones por área o zona.
Preguntas del estilo de las formuladas responden a cuestiones estratégicas cuyas respuestas a partir de la base de datos operativa requieren la construcción de consultas SQL que resultarían muy poco eficientes, debido a la gran cantidad de tablas que hay que combinar y a la carencia de información histórica en este entorno.
El análisis de datos se debe realizar a partir de información estable, no cambiante, como es el caso de la información que contiene la base de datos operativa. Por esta razón, nos planteamos la necesidad de considerar dos entornos: el entorno OLTP (3) , soportado por la base de datos operativa y el entorno OLAP (4) soportado por la base de datos estratégica. Ambos depósitos tienen finalidades diferentes y, por lo tanto, se estructuran de manera diferente.
En el apartado anterior, hemos visto que el diseño de la base de datos operativa responde a la necesidad de hacer posible las transacciones del día a día. Ahora estudiaremos cómo debe ser el almacén de datos de la base de datos estratégica, que integrará datos que provienen de fuentes distintas y heterogéneas: base de datos operativa, información y datos de otras aplicaciones que son controladas por otras áreas de negocio de la empresa (RH, marketing, ERP, etc.).

3.2.¿Qué es el data warehouse?

La base de datos estratégica también se denomina data warehouse.
El data warehouse se caracteriza por ser un almacén de datos orientado a las áreas de interés de la empresa, que integra información de varias fuentes con información no volátil e información histórica y que tiene, como último objetivo, dar apoyo en la toma de decisiones.
Veamos con algo más de detenimiento estos rasgos característicos del data warehouse.
Orientado a las áreas de interés de la empresa
La organización de los datos se efectúa a partir de los hechos que se desea analizar (ventas, clientes, envíos, etc.), no a partir de los procesos que realizan las aplicaciones. Esto provoca que el diseño y la representación de los datos se oriente a los hechos o áreas de negocio que se quieren estudiar, almacenando sólo aquellos datos que nos son útiles para tomar decisiones.
Integración de datos
La información que almacena el data warehouse proviene de diferentes fuentes de datos, entre las que destaca la base de datos operativa y los datos de otras aplicaciones de la empresa, que a menudo gestionan otros departamentos. Toda la información que formará parte del data warehouse debe pasar previamente por un proceso de integración a varios niveles (nombres, medidas de campos, implementación de estructuras de datos, etc.).
De tiempo variable
Todo dato almacenado en el data warehouse tiene el correspondiente estampillado de tiempo, dado que forma parte del historial de datos. Los datos que almacena suelen ser de cinco a diez años atrás y, a nivel lógico, debemos verlos como una colección de instantáneas sobre los temas de interés de la empresa que nos ayudarán a detectar evoluciones y tendencias de los hechos que hay que analizar.
No volatilidad
Para tomar decisiones hay que basarse en datos estables. El data warehouse sólo admite dos tipos de operaciones: la carga de datos y la obtención de datos. No existe la operación de actualización; si algún dato de resumen cambia, se añade la nueva información con el correspondiente estampillado de tiempo para disponer del historial.
Figura 9
Fijaos en que el data warehouse se alimenta a partir de la base de datos operativa, información histórica y datos de otros departamentos o aplicaciones de la empresa y que, a partir de ésta, se extrae información para los diferentes departamentos, para aplicaciones de comercio electrónico, CRM, ERP, para hacer análisis estadístico, etc.
Fijaos en que el data warehouse se alimenta a partir de la base de datos operativa, información histórica y datos de otros departamentos o aplicaciones de la empresa y que, a partir de ésta, se extrae información para los diferentes departamentos, para aplicaciones de comercio electrónico, CRM, ERP, para hacer análisis estadístico, etc.
Otra manera de entender el data warehouse es compararlo con la base de datos operacional. El cuadro siguiente resume las diferencias más importantes:

BD operacional

Data warehouse

Datos operacionales

Datos informativos de negocio

Diseño orientado a la aplicación

Diseño orientado a las áreas de interés del negocio

Datos actuales (60-90 días)

Datos históricos + actuales

Datos detallados

Datos detallados + datos resumen

Información cambiante

Información estable

Muchos usuarios concurrentes

Pocos usuarios concurrentes

Consultas predefinidas

Consultas imprevistas

Volumen de datos pequeño

Volumen de datos grande

Tiempo de respuesta inmediata

Tiempo de respuesta no crítico
A partir de ahora, cuando hagamos referencia al data warehouse, nos referiremos a aquella parte de la base de datos estratégica que se alimenta de la base de datos operacional. Concretamente, nos referiremos a los datos de la base de datos operacional útiles para analizar las ventas, las tendencias de los clientes, etc.

3.3.Modelo de datos para el análisis de las ventas

Construir un modelo de datos para diseñar un data warehouse va más allá de los propósitos de esta asignatura, pero podemos centrarnos en una única área de interés de la empresa y hacer un primer diseño que nos servirá de ejemplo ilustrativo.
Elegiremos como área de interés las ventas y, por lo tanto, diseñaremos un data warehouse que permita analizar las ventas desde diferentes dimensiones.
Hemos visto que, al definir el data warehouse, uno de sus rasgos característicos es que se orienta hacia un área de interés o hecho; en nuestro caso hemos elegido las ventas. También hemos visto que incorpora el componente temporal en toda la información que almacena, hecho que facilita el análisis de ventas por periodos de tiempos que ayudará a descubrir evoluciones y tendencias en las ventas. Pero un análisis completo de un hecho implica tener en cuenta más dimensiones. En nuestro caso, es fácil darse cuenta de que es necesario considerar otras dimensiones como el producto y el cliente.
Tenemos, por lo tanto, tres dimensiones que hay que estudiar en las ventas: cliente, producto y tiempo.
Si tomamos un eje tridimensional y en el centro ubicamos las ventas, cada uno de los ejes correspondería a las tres dimensiones elegidas para el análisis y, en consecuencia, obtendríamos un cubo como el siguiente:
Figura 10
Observamos que cada elemento del cubo (minicubo) contiene un valor de las ventas para un cliente particular, un producto concreto y un punto de tiempo concreto.
Observamos que cada elemento del cubo (minicubo) contiene un valor de las ventas para un cliente particular, un producto concreto y un punto de tiempo concreto.
Si quisiéramos añadir una dimensión más al hecho ventas, por ejemplo, el área o zona, el cubo ya no nos serviría como representación. Entonces podríamos usar un dibujo como el siguiente:
Figura 11. Modelo de datos de estrella
Figura 11. Modelo de datos de estrella
Este modelo multidimensional recuerda una estrella: el hecho central (ventas) y las dimensiones que lo rodean (cliente, producto, área, tiempo). Por este motivo, se denomina modelo de estrella y es el diagrama más utilizado para hacer el diseño de un data warehouse, dado que permite responder consultas formuladas en lenguaje empresarial, como qué productos son estacionales, qué líneas de producto incrementan su popularidad y cuáles la disminuyen, etc.
El modelo de estrella es un diagrama que permite mostrar las relaciones entre hechos y tablas. Las tablas son las dimensiones y se relacionan con el hecho mediante interrelaciones 1-N. También se denomina modelo multidimensional.
Si nos fijamos, algunas dimensiones corresponden a tablas de nuestra base de datos operacional y las ventas están claramente relacionadas con la tabla PEDIDO. La tecnología que mejor soporta un modelo de datos basado en tablas relacionadas es la tecnología de bases de datos relacionales, pero con un enfoque diferente al de la base de datos operativa. Esta base de datos sólo debe contener información útil para que los responsables del área en cuestión puedan tomar decisiones estratégicas sobre el área o el hecho de interés que quieran estudiar.
El modelo conceptual descrito en la figura 11 se transformaría en un modelo lógico formado por cinco relaciones:
Ventas (id_cliente, id_producto, id_tiempo, id_area,
cantidad, importe)
Cliente (id_cliente, nombre_completo, dirección)
Producto (id_producto, nombre_producto, precio_unitario)
Área (id_area, descripcion_area)
Tiempo (id_tiempo, fecha, num_semestre, num_trimestre, año)
Hay algunas cosas de este diseño lógico que se deben comentar:
1) Es importante que quede claro que sólo se almacena información útil para la toma de decisiones y, por lo tanto, se omitirán datos como la mayoría de las descripciones.
2) El modelo de estrella sólo permite representar interrelaciones de grado 1-N. No hay tablas que representen interrelaciones como la LINEA_PEDIDO (interrelación entre PRODUCTO y PEDIDO). Se trata de tener toda la información necesaria para el análisis de ventas, de modo que las consultas sean lo más eficiente posible y no impliquen la combinación de múltiples tablas relacionadas.
3) La tabla tiempo contiene información detallada sobre los periodos de tiempos en los que es interesante analizar las ventas. De hecho, a partir de una fecha podríamos derivar otros intervalos de tiempos. Además, el hecho de tener otras divisiones de tiempos como atributos agiliza las consultas . Por otro lado, lo que importa del pedido, aparte del producto, la cantidad y el precio, es el instante en el que la dirección considera el pedido como venta. Hemos supuesto que sería cuando se envía al destinatario, de aquí que el id_tiempo en el hecho ventas corresponda a la fecha de envío del pedido.
4) La clave primaria del hecho es una clave compuesta por todas las claves primarias de cada una de las dimensiones. Esta tabla es la más consultada, dado que contiene todos los hechos reales que se quieren analizar, del mismo modo que las claves foráneas de otras tablas que forman parte de la clave primaria suelen ser útiles para hacer agrupaciones según las dimensiones.

3.4.Alimentación del data warehouse

Una vez construido un dat warehouse, tenemos identificados los hechos que hay que analizar y las dimensiones desde las que lo queremos estudiar. El paso siguiente consiste en determinar el mecanismo de alimentación del data warehouse.
Seguimos con el ejemplo de nuestro data warehouse orientado a las ventas. En este caso, tenemos toda la información que necesitamos para alimentarlo en la base de datos operativa.
Uno de los problemas iniciales que se presenta es la unificación de criterios en el entorno de la definición de los hechos. Nos encontramos con que no existe ninguna tabla denominada VENTAS ni ningún atributo con este nombre, pero sabemos que las ventas se producen después de haberse confeccionado un pedido que pasa por varios estados hasta considerarse servido. Desde el punto de vista estratégico, hay que determinar qué se entiende por venta y, una vez aclarado este punto, podremos determinar qué datos de la base de datos operativa serán considerados ventas y, por lo tanto, podrán pasar a formar parte de las filas de la tabla de hechos.
Lo que resulta evidente es que las ventas están estrechamente relacionadas con los pedidos, y sabemos que todo pedido tiene un estado que indica en qué punto se encuentra (pendiente, en proceso, enviado, pagado, etc.). El valor del campo estado_pedido nos ayudará a determinar cuándo un pedido se considera venta desde el punto de vista estratégico.
El mecanismo de alimentación del data warehouse se basa en el traspaso de información hacia tablas temporales, que se realiza mediante disparadores que se activan cada vez que se produce un hecho, volcando toda la información útil para el análisis en las tablas temporales.
La carga del data warehouse no se realiza cada vez que se produce un hecho en el entorno operacional, sino que se lleva a cabo cuando se dispone de suficientes datos significativos que ayudarán a tomar mejor las decisiones. Éste es el motivo por el que las tablas temporales van almacenando información, que, en el momento en el que se determine, pasarán a formar parte del data warehouse.
En nuestro caso, sólo hemos considerado una única fuente de datos, la base de datos operativa, pero se podría dar el caso en el que fuera necesaria información de otras fuentes, por ejemplo, los datos de otro departamento. Por lo tanto, existen otras consideraciones que se deben tener en cuenta, como la integración de datos, desde el punto de vista del formato, semántico, etc. Por ende, la información recogida de varias fuentes a medida que se producen hechos se ha de integrar para poder pasar a formar parte del data warehouse.
Figura 12. Extracción, integración, carga
Figura 12. Extracción, integración, carga

3.5.CRM (customer relationship management)

La gestión de las relaciones con los clientes no es un concepto nuevo. Un ejemplo claro de esto sería el caso de un pequeño comercio de barrio en el que el tendero (empresario) conoce bien las preferencias de sus clientes. Dado que existe una estrecha relación entre ambas partes, el tendero utiliza esta información para proveerse de productos que puedan interesar a sus clientes. A posteriori, éste los ofrecerá a determinados clientes y actuará de manera estratégica en cuanto a ventas y aprovisionamiento.
El CRM (customer relationship management) es una estrategia de empresa que permite entender el comportamiento de los clientes mediante una estrecha y significativa comunicación, y tiene como objetivo conseguir su fidelidad y lealtad.
En otras palabras, el CRM es un proceso interactivo cuyo objetivo principal es obtener información de los clientes dentro de un entorno basado en la relación empresa-cliente.
Para el CRM, el cliente es el centro del negocio. Pretende un trato personalizado para cada cliente y esto hace que el CRM también se denomine relación one to one. Las empresas actuales tienen la necesidad de evolucionar hacia este modelo para ampliar su mercado, por ello, el CRM se impone cada vez más como estrategia de empresa, sobre todo en entornos como el del comercio electrónico, en el que los clientes están distribuidos en diferentes zonas geográficas.
El último objetivo del CRM es analizar el comportamiento de los clientes, hacer segmentaciones, identificar tendencias, tipologías y consumos y, a partir de aquí, elaborar la oferta de productos y desarrollar toda la estrategia de aproximación al mercado.
Como consecuencia de todo esto, vemos que el CRM no es un software, sino una estrategia de empresa apoyada por una plataforma tecnológica que se basa en el historial de datos de cada uno de los clientes que forman parte de la cartera de la empresa. Todos estos datos se extraen del gran almacén de datos estratégico, el data warehouse.
Hay que ser consciente de que implantar una estrategia CRM implica realizar cambios dentro de la estructura de la empresa. Una de las primeras tareas consiste en cambiar la visión del negocio, revisar los procesos de la empresa para adaptarlos a este nuevo enfoque.
Para resumir, el CRM provoca que aumente el valor de una organización, pero para ello es necesaria la motivación y el incentivo de las personas, la atención y el servicio al cliente, así como la capacidad de una empresa para convertir datos e información de clientes en ideas y acciones.

Resumen

En este módulo hemos presentado los conceptos relacionados con la gestión de la información en el comercio electrónico.
En primer lugar, hemos justificado la necesidad de la tecnología de bases de datos como pieza clave para la venta a través de la web.
La parte central del módulo se dedica al estudio de la base de datos operativa, que es la que posibilita que se lleven a cabo las transacciones económicas que equivalen a la venta tradicional. Se ha estudiado el diseño de una base de datos genérica y se han enumerado las operaciones básicas que requiere un entorno de venta electrónico. Todos estos conocimientos se pondrán en práctica en la última parte de la asignatura mediante la construcción de una tienda virtual.
El último apartado pretende ampliar la visión del comercio electrónico, para no quedarnos sólo con la parte operativa, y muestra la perspectiva más estratégica de todo este ámbito.

Actividades

1. Visitad La Virtual y comparadla con la librería que se describe en el apartado de la base de datos operativa. Observad qué productos se venden, cómo se muestra el catálogo de productos, cómo se visualiza un pedido, qué operaciones permite realizar, etc.
2. Utilizando la bibliografía recomendada del módulo, haced una lista de objetivos y beneficios del data warehouse.

Ejercicios de autoevaluación

1. Indicad en qué tipo de base de datos encontraríais las informaciones que se detallan a continuación:
a) Ventas del último trimestre cerrado.
b) Clientes que han dejado de comprar desde hace un año.
c) Clientes de tipo preferente.
d) Productos en oferta.
e) Productos catalogados por tipos.
f) Tendencias de las ventas por trimestres de los últimos dos años.
g) Tipo de productos que se venden principalmente por Navidad.
2. ¿Cómo modificaríais el modelo de datos conceptual de la base de datos operacional para que...
a) incluya el idioma preferido por cada cliente?
b) grave descuentos que hay que aplicar a los clientes por tipos de producto?
c) tenga en cuenta márgenes de precio diferentes por producto?
3. Suponiendo que el hecho que hay que analizar en la base de datos estratégica son los clientes, ¿qué modelo de datos propondríais, teniendo en cuenta que interesa tener las preferencias de los clientes por zona, producto, tipo de cliente y nivel social?
4. Según una base de datos estratégica orientada a ventas, formulad las consultas SQL que darían respuesta a las consultas siguientes en lenguaje empresarial:
a) ¿Hay productos que fueron más populares en unas zonas que en otras durante el año pasado?
b) ¿Qué productos son estacionales? Consideraremos los datos de los últimos cinco años.

Solucionario

Ejercicios de autoevaluación
1. La información que hace referencia a datos históricos y de carácter estratégico iría en la columna de la base de datos estratégica, mientras que la información referida al día a día iría en la base de datos operacional.
BD estratégica: a, b, g, h.
BD operacional: c, d, e, f.
2. A partir del modelo conceptual de datos presentado en el módulo...
a) el idioma preferido por el cliente sería un dato personal del cliente con un valor atómico; por lo tanto, lo incluiría como atributo en la entidad CLIENTE.
b) los descuentos que se deben aplicar por tipos de cliente y tipos de producto requerirán una nueva interrelación entre las entidades TIPOS_CLIENTE y TIPOS_PRODUCTO con grado N-M, ya que, dado un tipo de cliente, se deberían almacenar varios descuentos, uno para cada tipo de producto, mientras que otro tipo de producto podría tener diferentes descuentos según el tipo de cliente.
c) considerar un precio mínimo y máximo por producto implicaría tener unas limitaciones que habría que considerar una vez determinado el descuento que aplicar al cliente. Podrían añadirse como dos atributos en la entidad PRODUCTO.
3. El cliente es el hecho central y las dimensiones sobre las que se debe hacer el estudio son zona, producto, tipo de cliente y nivel social.
81034_m3_15.gif
4. Las consultas SQL serían las siguientes:
a) Se trata de ver qué productos son más populares en unas zonas respecta a otras. Para ello, buscaremos, para cada producto y área, el número de ventas y la cantidad de productos vendidos.
SELECT p.nombre_producto, , a.descripcion_area, count(*) "Total ventas",
sum(cantidad) as "Total productos"
FROM ventas v, productos p, area a, tiempo t
WHERE v.id_producto =p.id_producto AND v.id_area=t.id_area
AND v.id_tiempo = t.id_tiempo AND an=YEAR(fecha) -1
GROUP BY p.nombre_producto, a.descripcion_area
ORDER BY p.nombre_producto, a.descripcion_area;
b) Para determinar los productos estacionales, se deben analizar las cantidades de productos vendidos durante cada trimestre. Podemos hacer el estudio a partir de una consulta que obtenga una lista ordenada por nombre de producto y número de semestre que muestre la cantidad de productos que se han vendido durante los diferentes trimestres de los cinco últimos años. A partir de esta información, se puede hacer una gráfica, de manera que se visualice claramente el aumento y la disminución de popularidad de los diferentes productos.
SELECT p.nombre_producto, t.num_trimestre, sum(cantidad)
FROM ventas as v, productos as p, tiempo as t
WHERE v.id_producto =p.id_producto AND v.id_tiempo=t.id_tiempo
AND p.num_trimestre between 1 and 4
AND t.an between YEAR(date)-5 AND YEAR(date)
GROUP BY p.nombre_producto, t.num_trimestre
ORDER BY p.nombre_producto, t.num_trimestre;

Glosario

cliente/servidor m
Entorno en el que establecen comunicaciones entre diferentes agentes a través de una red de transmisión de datos, de manera que los agentes clientes reclaman servicios ofrecidos por agentes servidores.
CRM m
Ved Gestión de relación con el cliente
customer relationship management m
Ved Gestión de relación con el cliente
data warehouse m
Almacén de datos orientado a las áreas de interés de la empresa, que integra información de varias fuentes con información no volátil e información histórica y que tiene, como último objetivo, dar apoyo en la toma de decisiones.
disparador m
Procedimiento almacenado en la base de datos que se ejecuta automáticamente (se dispara) cuando se hace una operación INSERT, DELETE o UPDATE sobre alguna tabla en concreto. Esta ejecución, a la vez, puede provocar que se ejecuten sentencias como INSERT, DELETE, UPDATE o EXECUTE PROCEDURE.
diseño conceptual m
Etapa del diseño de una base de datos que obtiene una estructura de la información de la futura base de datos independientemente de la tecnología que se quiere emplear.
diseño físico m
Etapa del diseño de una base de datos que transforma la estructura obtenida en la etapa del diseño lógico con el objetivo de conseguir una eficiencia mayor y que, además, la completa con aspectos de implementación física que dependerán de la SGBD que se debe utilizar.
diseño lógico m
Etapa del diseño de una base de datos que parte del resultado del diseño conceptual y lo transforma de manera que se adapte al modelo del SGBD con el que se desea implementar la base de datos.
enterprise resources planning m
Ved software de gestión integrada
ERP m
Ved software de gestión integrada
gestión de relación con el cliente f
en customer relationship management
Estrategia de empresa que permite entender el comportamiento de los clientes por medio de una estrecha y significativa comunicación para conseguir su fidelidad y lealtad. En otras palabras, es un proceso interactivo cuyo principal objetivo es obtener información de los clientes dentro de un entorno basado en la relación empresa-cliente.
sigla: CRN
información estratégica f
Información útil relacionada con la planificación y estrategia de la empresa.
información operacional f
Información del "día a día" de la empresa.
marketing m
Medios y técnicas utilizadas para conquistar nuevos mercados.
OLAP m
Ved proceso de análisis en línea
OLTP m
Ved proceso de transacción en línea
on-line analysis process m
Ved proceso de análisis en línea
on-line transaction process m
Ved proceso de transacción en línea
procedimiento m
Programa definido por el usuario que se almacena en la base de datos. Una vez que el procedimiento ha sido creado, se almacena en formato ejecutable en la base de datos como cualquier objeto de ésta.
proceso de análisis en línea m
en on-line analysis process
Método de análisis de datos que se caracteriza por que redefine de manera continua y flexible el tipo de información que hay que extraer, analizar y sintetizar.
sigla: OLAP
proceso de transacción en línea m
en on-line transaction process
Sistemas de procesamiento de transacciones en línea (OLTP) que tienen como objetivo guardar la integridad de los datos necesarios para administrar una organización de manera eficiente.
sigla: OLTP
software de gestión integrada m
en enterprise resources planning
Sistema de gestión de la información para satisfacer la demanda de soluciones de gestión empresarial basado en el ofrecimiento de una solución completa que permita a las empresas evaluar, implementar y gestionar más fácilmente su negocio.
sigla: ERP
transacción f
Conjunto de operaciones de lectura y/o actualización de la base de datos que acaba confirmando o cancelando los cambios que se han llevado a cabo.
vista f
Tabla ficticia que se construye a partir de tablas reales almacenadas en la base de datos. La no existencia real de las vistas provoca que puedan ser actualizables o no.

Bibliografía

Franco, J. M.; EDS-Instituto Prométhéus. (1997). El Data Warehouse – El Data Mining. Barcelona: Gestión 2000.
Gill Harjinder, S.; Rao Prakash, C. (1996) Cliente/Servidor. Data Warehousing. México: Prentice Hall.
Inmon W. H.; Imhoff, C.; Sousa, R. (2001). Corporate Information Factory. Estados Unidos: Wiley.
Sakhr Youness. (2000). Data Warehousing with SQL Server 7.0 and OLAP Servicies. Wrox.
Silverston, L. (2001). The Data Model Resource Book (vol. 1). Estados Unidos: Wiley.
Simon Alan, R.; Shaffer Steven, L. (2001). Data Warehousing and Business Intelligence for E-Commerce. Estados Unidos: Morgan Kaufmann Publishers.
Todman, C. (2001). Designing a Data Warehouse. Estados Unidos: Hewlett-Packard Profesional Books.
Swift, R. S. (2000) ACCELERATING Customer Relationships. Prentice Hall.