Pid 00221682-4 PDF

Almacenamiento
y explotación
de datos en
el comercio
electrónico
Jordi Casas Roma
PID_00223058
© FUOC • PID_00223058 Almacenamiento y explotación de datos en el comercio electrónico
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 éste eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares del copyright.
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 7
1. Sistemas de almacenamiento en el comercio electrónico........ 9

1.1. El proceso de diseño de una base de datos ................................. 10
1.1.1. Recopilación y análisis de requisitos ............................. 12
1.1.2. Diseño conceptual ......................................................... 12
1.1.3. Diseño lógico ................................................................. 12
1.1.4. Diseño físico .................................................................. 13
1.1.5. Implementación y optimización ................................... 13
1.2. Diseño conceptual ....................................................................... 13
1.3. Diseño lógico .............................................................................. 16
2. Bases de datos operativas................................................................ 19

2.1. Datos relativos al catálogo de productos .................................... 20
2.2. Datos relativos a los clientes ...................................................... 22
2.3. Datos relativos a los pedidos ...................................................... 25
2.4. Datos relativos a los contenidos ................................................. 27
2.4.1. Noticias, agenda, novedades, foros, anuncios y FAQ .... 28
2.4.2. Información ampliada de los productos ....................... 29
2.5. Diseño de la base de datos de BricoTodo ................................... 29
2.5.1. El modelo ER de BricoTodo ........................................... 29
2.5.2. El modelo relacional de BricoTodo ............................... 31
3. Personalización y monitorización de los usuarios.................... 33

3.1. Personalización y preferencias de los usuarios ........................... 33
3.2. Estadísticas de acceso de los usuarios ......................................... 35
3.3. Herramientas de analítica social ................................................. 38
3.3.1. Datos volumétricos ........................................................ 38
3.3.2. Datos cuantitativos ........................................................ 39
3.3.3. Datos cualitativos .......................................................... 39
4. Bases de datos analíticas................................................................. 40

4.1. El almacén de datos o data warehouse.......................................... 40
4.1.1. ¿Qué es el data warehouse? ............................................ 41
4.1.2. El modelo de datos ........................................................ 42
4.1.3. Los usuarios ................................................................... 44
4.1.4. Las fuentes de información ........................................... 44
4.2. Técnicas de explotación de datos ............................................... 46
4.2.1. Consultas y listas ........................................................... 47
4.2.2. Análisis multidimensional ............................................. 48

4.2.3. Minería de datos ............................................................ 51
4.2.4. Bases de datos NoSQL ................................................... 52
4.2.5. Big data............................................................................ 53
Resumen....................................................................................................... 57
Ejercicios de autoevaluación.................................................................. 59
Solucionario................................................................................................ 60
Glosario........................................................................................................ 62
Bibliografía................................................................................................. 63
© FUOC • PID_00223058 5 Almacenamiento y explotación de datos en el comercio electrónico
Introducción
En este módulo didáctico trataremos el papel fundamental que tienen las ba-
ses de datos en el funcionamiento de una aplicación de comercio electrónico.
Estas serán las responsables de guardar las operaciones que se vayan produ-
ciendo, lo cual permite las interacciones entre el cliente y el vendedor y, por
lo tanto, el intercambio comercial.
El establecimiento electrónico, con la ayuda de la tecnología, debe ofrecer to-

das las funcionalidades propias de un comercio teniendo en cuenta, además,
los condicionantes que supone el entorno virtual. En un establecimiento tra-
dicional, el cliente se tiene que sentir a gusto dentro del espacio físico de la
sala de ventas, debe encontrar con facilidad aquello que busca, debe acceder
de una manera sencilla a productos similares o complementarios de aquellos
en los que está interesado, se le tiene que presentar el surtido de una manera
atractiva y que fomente la compra, etc.
En el ámbito del comercio electrónico, el cliente suele acceder al estableci-

miento a través de una página web o una app. Esta interfaz permite muchas
funcionalidades para hacer búsquedas y ordenaciones de los productos, pero
limita el modo en que se puede mostrar el surtido. Para salvar este inconve-
niente, es necesario que la información sobre los productos esté almacenada y
organizada de tal manera que el cliente pueda ordenar, clasificar y buscar los
artículos de acuerdo con sus preferencias, que se le puedan ofrecer productos
y promociones relacionados con aquellos que ya ha elegido, etc.
Además, no hay que recurrir a técnicas específicas de investigación (como la

observación en vídeo de los movimientos de los clientes en sus desplazamien-
tos dentro del establecimiento, entrevistas al personal de ventas, etc.), sino que
se puede obtener de manera sistemática y automatizada toda la información
relacionada con la operativa de compra de los usuarios, los productos que han
adquirido, las secciones que han visitado, los productos vistos, etc. Esto facilita
considerablemente el análisis del comportamiento de los consumidores.
Dedicaremos este módulo didáctico a estudiar el nivel de datos de las aplica-

ciones de comercio electrónico. Iniciaremos nuestro trabajo con una introduc-
ción a las bases de datos, definiendo el ciclo de diseño de una base de datos
y centrándonos brevemente en el modelo conceptual del diseño y el modelo
lógico de las bases de datos relacionales. Continuaremos estudiando la base
de datos operativa, y aprenderemos a evaluar la calidad de la información, a
depurarla y normalizarla para que pueda ser objeto de análisis y explotación.
También estudiaremos cómo debe ser la base de datos necesaria para efectuar
análisis sobre los datos y veremos los requisitos que debe tener la base de datos
operativa para que los datos sean útiles en la toma de decisiones del negocio. A
continuación, veremos cómo podemos personalizar la experiencia del usuario

y monitorizar sus acciones para poder adaptar nuestra plataforma a los usua-
rios, aumentando su grado de satisfacción. Finalmente, conoceremos varias
técnicas de explotación de los almacenes de datos, con diferentes utilidades
y enfoques de los análisis.
Objetivos
En los materiales didácticos de este módulo encontraremos las herramientas

indispensables para lograr los objetivos siguientes:
1. Comprender las funciones, los objetivos y las diferencias principales entre

la base de datos operacional y la base de datos analítica de un sistema de
comercio electrónico.
2. Conocer el ciclo de diseño de una base de datos, especialmente las etapas

de diseño conceptual y lógico de la base de datos, que nos permitirán en-
tender su estructura y funcionamiento.
3. Conocer la estructura de datos que da apoyo a una aplicación de comercio

electrónico, los atributos necesarios que hay que guardar y las relaciones
existentes entre los datos.
4. Comprender cómo se han de gestionar los datos para que tengan suficiente
calidad en posteriores tratamientos y análisis.
5. Entender los objetivos y el funcionamiento de un data warehouse, identi-

ficar los hechos que hay que analizar y las dimensiones necesarias impli-
cadas.
6. Comprender cómo y de qué datos se alimentará el data warehouse.
7. Estudiar diferentes técnicas de explotación de los almacenes de datos en

función del modo de utilización (verificación o descubrimiento) y del en-
foque de estos.
1. Sistemas de almacenamiento en el comercio

electrónico
En las aplicaciones de comercio electrónico, y en general en cualquier aplica-

ción informática, podemos distinguir hasta tres niveles o partes diferentes, en
función de las actividades que permiten desarrollar:
1)� Nivel� de� presentación: es la parte responsable de presentar el estableci-

miento al usuario final. Permite que este interactúe con el establecimiento, le
muestra el surtido de una manera clara e intuitiva, le informa de lo que hay
que hacer para efectuar un pedido, etc.
2)�Nivel�lógico: es la parte que se encarga de realizar las operaciones con los

datos. Por lo tanto, aporta todos los datos que hacen posible las funcionali-
dades del establecimiento, como mostrar los productos, presentar los precios,
recoger los pedidos, ofrecer opciones de pago, etc.
3)�Nivel�de�datos: es la parte responsable de almacenar todos los datos que

intervienen en los procesos de la aplicación de comercio electrónico.
A su vez, en el nivel de datos podemos distinguir dos entornos diferenciados:
• el entorno� operativo, orientado a almacenar los datos necesarios para

desarrollar las actividades comerciales habituales en el establecimiento
(consultas al catálogo de productos, gestión de los pedidos, consultas de
los datos de los clientes, etc.) y
• un entorno�analítico, donde se llevan a cabo análisis de los datos para

extraer conclusiones que ayuden a detectar oportunidades de negocio y
tomar decisiones tácticas y estratégicas.
A continuación, veremos brevemente el proceso de diseño de una base de da-

tos. Pondremos énfasis en las etapas del diseño conceptual y diseño lógico, y
tendremos en cuenta un tipo de bases de datos que son muy utilizadas y que
se conocen como bases de datos relacionales. El hecho de conocer el proceso
de diseño de una base de datos nos ayudará a entender la estructura de las
bases de datos, el porqué de muchas decisiones que se han de tomar durante
el proceso de diseño, qué datos se almacenan, cómo están relacionados entre
ellos y cómo pueden ser explotados para extraer información útil para el co-
mercio electrónico.
1.1. El proceso de diseño de una base de datos
El diseño de bases de datos es el proceso de diseñar la estructura conceptual,

lógica y física de una o más bases de datos para dar respuesta a las necesidades
de información de los usuarios y aplicaciones que usarán estas bases de datos.
Tareas del proceso diseño
Mediante un proceso de diseño de bases de datos se identifica qué datos son relevantes
para el problema que se va a tratar y, por lo tanto, qué datos habrá que almacenar en la
base de datos. El siguiente paso es identificar qué tablas y relaciones debe tener la base
de datos, qué atributos han de tener las diferentes tablas, qué claves primarias y claves
foráneas se tienen que declarar en cada tabla, etc. Todas estas tareas forman parte de este
proceso de diseño que a continuación estudiaremos con más detenimiento. Para poder
entender la estructura de una base de datos y el porqué de algunas de sus características,
conviene conocer este proceso y comprender cómo se va perfilando la estructura de la
base de datos a través de las diferentes etapas que conforman el proceso de diseño.
El proceso de diseño de una base de datos es el proceso en el que se

definen los datos relevantes y la estructura que debe tener la base de
datos de un determinado sistema de información.
Los distintos requisitos que ha de cumplir un sistema de información y la Dividir para vencer
complejidad de la información que se presenta en ellos hacen que el diseño
La estrategia de dividir para
de una base de datos sea un proceso complejo. Para simplificarlo, es muy re- vencer (en inglés, divide & con-
comendable utilizar la estrategia de dividir para vencer. quer) es una estrategia que
propone resolver un problema
complejo a partir de dividirlo
en un conjunto de problemas
Aplicando este concepto obtenemos las diferentes etapas del diseño de bases más sencillos, donde la resolu-
ción de los diferentes subpro-
de datos. Estas etapas son secuenciales, y el resultado de cada una de ellas blemas acabará llevando a la
sirve de punto de partida de la siguiente. El resultado de la última etapa será resolución del problema inicial.
el diseño final de nuestra base de datos. De este modo, se descompone un

proceso de cierta complejidad en varios procesos de complejidad menor. La
figura siguiente muestra las diferentes etapas del diseño de bases de datos:
recopilación y análisis de requisitos, diseño conceptual, diseño lógico, diseño
físico, e implementación y optimización.
Etapas del diseño de bases de datos
Antes de presentar cada etapa del proceso de diseño de una base de datos, lo Sistema gestor de bases
que haremos a continuación, hay que explicitar que en este texto denominare- de datos
mos sistema�gestor�de�bases�de�datos (SGBD) al software específico dedicado En inglés se conocen como da-
a servir de interfaz entre los datos, el usuario y las aplicaciones que la utilizan. tabase management system o
DBMS.
El conjunto de sistemas gestores de bases de datos con características similares
recibe el nombre de tipo�de�bases�de�datos o tipos�de�sistemas�gestores�de
bases�de�datos. Por ejemplo, podemos hablar de bases�de�datos�relacionales
como el tipo de sistema gestor de bases de datos que agrupa todas las bases de
datos que se basan en tablas con filas y columnas, y relaciones entre tablas.
Tipos de sistemas gestores de bases de datos
Existen varios tipos de bases de datos, cada uno con un conjunto de características propias
que lo hacen adecuado para un problema o conjunto de problemas concretos. Veamos
algunos de los más empleados:
• Bases�de�datos�relacionales: son los tipos de bases de datos más utilizadas actual-

mente, sobre todo en los entornos operacionales. Se basan en tablas, que contienen
filas y columnas, y las relaciones entre las tablas.
• Bases�de�datos�orientadas�a�objetos: permiten almacenar y recuperar colecciones de

objetos, donde un objeto se define por un conjunto de atributos y valores que deter-
minan su estado, y un conjunto de métodos que determinan su comportamiento.
• Bases�de�datos�geográficas: permiten la representación digital de entidades, objetos

o fenómenos que se producen en la superficie de la Tierra o cerca de esta. Por ejemplo,
para la representación de una casa, podríamos representar la geometría con una figura
rectangular; la posición, con la latitud y la longitud de cada uno de los vértices del
rectángulo, y los datos alfanuméricos (año de fabricación, calle, color, etc.), utilizando
atributos y relaciones.
• Bases�de�datos�documentales: permiten almacenar y recuperar documentos de toda

clase.
1.1.1. Recopilación y análisis de requisitos
La primera etapa del proceso de diseño es la de recopilación y análisis de re- Usuarios de una base de
quisitos. Esta etapa debe permitir obtener los requerimientos y restricciones datos
de los datos del problema. Para obtener esta información, será necesario man- Los usuarios de una base de
tener conversaciones con los diferentes usuarios de la futura base de datos y datos son todas aquellas per-
sonas que interactúan con sus
de las aplicaciones relacionadas con esta (como por ejemplo el comercio elec- datos: desde el personal de la
empresa que gestiona los da-
trónico y el sistema de gestión de la información interno de la empresa). Solo tos a través del formulario de
una aplicación o extrae lista-
a partir de cruzar los requerimientos de los diferentes perfiles de usuarios será dos y exportaciones de datos,
posible establecer un marco completo de los requerimientos y restricciones de hasta los administradores o
usuarios avanzados que ejecu-
los datos relacionados con la futura base de datos. tan los análisis de datos.
El caso de la empresa BricoTodo
El personal de almacén de la empresa BricoTodo necesita acceder a una aplicación que

le muestre los pedidos hechos a través de la plataforma de comercio electrónico. Esto les
permite seleccionar los productos adquiridos y preparar los pedidos para su expedición.
En la fase inicial del proceso de diseño de bases de datos, el personal de almacén de Bri-
coTodo puede pedir poder ver el código interno de cada producto, y no solo el código de
venta. Este código interno guardará relación con la manera como se ordenan y clasifican
los artículos en el almacén.
1.1.2. Diseño conceptual
A continuación se inicia la etapa de diseño conceptual. En ella se crea un es- Ved también
quema conceptual a partir de las especificaciones y requerimientos obtenidos
Trataremos con más detalle el
en la etapa anterior. Aquí hay que extraer las necesidades y los requerimientos tema del esquema conceptual
de la problemática y sintetizarlos en un modelo visual que permita representar en el subapartado 1.2 de este
módulo.
los datos y las restricciones de los conceptos que se quieren modelar en el sis-
tema de información. Este modelo visual se denomina esquema�conceptual.
Profundizaremos en esta etapa más adelante, cuando expliquemos con más Nota
detalle y ejemplifiquemos el desarrollo de un esquema conceptual. Observad que hasta esta eta-
pa del diseño de bases de da-
tos todavía no ha sido nece-
1.1.3. Diseño lógico sario elegir qué tipo de bases
de datos se utilizará ni tampo-
co se tiene en cuenta qué sis-
tema gestor de bases de da-
En la tercera etapa del proceso de diseño, el diseño lógico, se convierte el es-
tos (SGBD) se utilizará o con
quema conceptual en un�esquema�lógico, que permitirá definir y estructurar qué lenguaje concreto se im-
plementará la base de datos.
los datos y restricciones en un esquema adecuado al tipo de bases de datos que
se pretende utilizar. En el desarrollo de esta etapa, por lo tanto, es necesario
determinar qué tipo de bases de datos se utilizará, a pesar de que todavía no Ved también
es necesario elegir un SGBD concreto.
Trataremos con más detalle el
tema del esquema lógico en el
subapartado 1.3 de este mó-
En este punto, una vez finalizada la etapa del diseño lógico y antes de iniciar dulo.
la etapa de diseño físico, habrá que elegir un SGBD concreto sobre el que se
pretende implementar la base de datos.
1.1.4. Diseño físico
La etapa de diseño físico adapta el esquema lógico a las necesidades específicas

de un SGBD concreto y, posteriormente, ajusta algunos parámetros para el
correcto funcionamiento de la base de datos. Por ejemplo, habrá que definir
la longitud de los textos y números que debe almacenar la base de datos.
1.1.5. Implementación y optimización
La última de las etapas es la de implementación y optimización de la base de

datos. Esta etapa permite la implementación de la base de datos, la carga de los
datos y, posteriormente, permite ajustar algunos parámetros de la base de datos
para optimizar su rendimiento. Por ejemplo, podemos definir los principales
atributos que se utilizarán en las consultas a la base de datos para acelerar su
tiempo de ejecución.
Estas etapas del diseño no tienen que seguirse en estricta secuencia, y en mu-
chos casos es habitual rehacer el diseño de la etapa anterior a partir de necesi-
dades detectadas en fases posteriores. Estos bucles�de�retroalimentación son
habituales y permiten afinar los diseños de las diferentes etapas de manera
iterativa.
1.2. Diseño conceptual
Tal y como hemos comentado anteriormente, el objetivo de esta fase es crear

un esquema�conceptual a partir de las especificaciones y los requerimientos
obtenidos en la recopilación y análisis de requisitos. Existen varios esquemas
conceptuales que permiten representar los datos y las restricciones de los con-
ceptos que se quieren modelar en el sistema de información, pero en este texto
nos centraremos en el�modelo�ER.
El modelo ER (modelo entidad-interrelación) es un esquema conceptual de Modelo ER

datos independiente de la tecnología. Este modelo y sus variaciones constitu-
El nombre original proviene de
yen los modelos más utilizados por el diseño conceptual de las aplicaciones la lengua inglesa, donde ER se
de bases de datos. Esto se debe, principalmente, a su simplicidad y facilidad refiere a entity-relationship. En
lengua castellana encontramos
de uso. Como enseguida veremos, los principales elementos que incluye el autores que lo traducen como
modelo entidad-relación y otros
modelo son las entidades, los atributos y las relaciones entre entidades. El ob- que lo traducen como modelo
entidad-interrelación. Ambos se
jetivo principal del modelo ER es permitir a los diseñadores reflejar en un es- refieren al mismo modelo.
quema conceptual los requisitos del mundo real que sean de interés para la
problemática que hay que resolver.
Este modelo facilita el diseño conceptual de una base de datos y es aplicable al

diseño de cualquier tipo de bases de datos (relacionales, orientadas al objeto,
etc.), puesto que en la etapa del diseño conceptual no se tiene en cuenta toda-
vía la tecnología concreta que se empleará para implementar la base de datos.
El proceso de diseño conceptual de una base de datos se puede enfocar como

un proceso iterativo de refinamiento, donde se crea un primer diseño inicial y,
de manera iterativa, se va refinando hasta conseguir el nivel de diseño deseado.
Los principales elementos del modelo ER son las entidades, los atributos, las Lectura complementaria
claves y las relaciones entre entidades. A continuación se identifican y descri-
Jordi�Casas�Roma;�Jordi�Co-
ben estos elementos: nesa�i�Caralt (2013). Diseño
conceptual de bases de datos
en UML. Barcelona: Editorial
1) La entidad es un objeto o persona del mundo real, que tiene identidad UOC.
propia y que es distinguible del resto de los objetos o personas. Las entidades
pueden ser tangibles (por ejemplo, un destornillador a la venta en el estable-
Ejemplo de entidades y
cimiento electrónico o un cliente que vive en Dinamarca) o intangibles (por tipos de entidades
ejemplo, un servicio o una idea). Las entidades con características comunes y/
El tipo de entidad herramien-
o semántica común se agrupan en tipos�de�entidades. tas puede contener entidades
como, por ejemplo, un destor-
nillador o un martillo de mo-
2) Un atributo es una propiedad que tienen en común todas las entidades delos y marcas concretos. Por
otra parte, el tipo de entidad
consideradas en un tipo de entidad y que permite representar sus característi- clientes puede incluir como en-
cas. El conjunto de posibles valores que puede tomar un atributo se denomina tidades el cliente danés y los
demás clientes del estableci-
dominio del atributo. miento.
Ejemplo de tipo de entidad y atributos
La figura siguiente presenta un ejemplo básico del tipo de entidad productos y cinco atri-
butos que pertenecen a ella: el código, que hace referencia al código de barras del produc-
to; la referencia, que podría ser aquella combinación de letras y números que utiliza el
proveedor o fabricante para identificar el modelo concreto de producto; el nombre del
producto; una breve descripción del producto, y finalmente su precio.
Ejemplo de entidad y atributos
El tipo de entidad producto puede contener, por ejemplo, el destornillador con código
“202828609”, referencia “9780671023232”, nombre “Black & Decker 2.6 Volt. Cordless”,
descripción “destornillador eléctrico que funciona sin cables” y precio “15 euros”.
3) Una clave� candidata es un conjunto de atributos mínimo que permite

identificar de manera única a todas y cada una de las entidades de un determi-
nado tipo de entidad. Una entidad puede tener una o más claves candidatas.
No obstante, es necesario que tenga al menos una clave candidata que permita
identificar de forma unívoca a todas las entidades.
Una clave candidata puede estar formada por uno o más atributos. En el caso
de estar formada por varios atributos recibe el nombre de clave� candidata
compuesta. En este caso, la combinación de los diferentes valores de los atri-
butos debe ser única para identificar de forma unívoca a todas las entidades
de un mismo tipo de entidad.
Cuando haya más de una clave candidata posible, el diseñador de la base de

datos elegirá una de las claves candidatas para ser la clave�primaria. Esta se
usará para identificar de manera unívoca a las entidades. Como clave candi-
data, la clave primaria no podrá contener valores duplicados.
Ejemplo de entidad con las claves
Continuando con el ejemplo anterior, tenemos dos claves candidatas en la entidad pro-
ductos. La primera es el código, que se refiere al código de barras del producto. Nos permite
referirnos de forma única a cada una de las entidades de productos, y seguramente será
la que mostraremos a los clientes del establecimiento electrónico como identificador del
producto. La segunda clave candidata es la referencia, indicativa del modelo de producto
y su proveedor o fabricante, y también permite identificar de manera inequívoca cada
producto del catálogo.
En la figura siguiente podemos ver que hemos definido como clave primaria el atributo
código, puesto que es la que queremos emplear en el proceso de ventas, de tal modo que
los usuarios del establecimiento puedan ver este código en el catálogo de productos y
en su cesta de compra, y lo puedan usar para cualquier reclamación relacionada con un
producto concreto. No obstante, cabe señalar que, desde el punto de vista de diseño de la
base de datos, podíamos haber elegido el atributo referencia sin ningún tipo de perjuicio
en el funcionamiento de la base de datos. Este atributo quedará definido como clave
candidata, puesto que a pesar de ser un valor único para cada entidad finalmente no ha
sido elegido como clave primaria.
Ejemplo de entidad y claves primaria y candidata
4) Las relaciones son las asociaciones entre entidades. Las relaciones, casi
siempre, tienen una etiqueta�de�relación que indica la acción o el significado
de la asociación entre las dos entidades, y generalmente suele ser un verbo. Al
igual que las entidades, las relaciones pueden agruparse en tipos�de�relaciones
según su semántica y restricciones.
Se define el grado�de�una�relación como el número de entidades que partici-

pan en la asociación. Hablaremos de relaciones de grado 2, o binarias, cuan-
do en la relación intervienen dos entidades; de grado 3, o ternarias, cuando
intervienen tres entidades, y de relaciones de grado n, o n-arias, cuando inter-

vienen más de tres entidades en la relación. Las relaciones más habituales en
una base de datos son de grado 2 y 3.
La conectividad�de�un�tipo�de�relación expresa el tipo de correspondencia

que hay entre los tipos de entidades que participan en un tipo de relación.
En el caso de los tipos de relación binarios, expresa el número de ocurrencias
de un tipo de entidad con las cuales una ocurrencia del otro tipo de entidad
puede estar asociada según el tipo de relación.
Ejemplo de relación entre entidades
La figura que se recoge a continuación presenta el tipo de relación pertenece entre las
entidades productos y categorías de productos, donde definimos que un producto pertenece
a una única categoría y una categoría puede tener múltiples productos asociados (relación
1:N). En el diagrama leemos que “un producto pertenece a una categoría”, y en sentido
inverso que “a una categoría le pertenecen N productos”, donde N se refiere a 0 o más
productos.
Ejemplo de relación entre entidades
1.3. Diseño lógico
La etapa del diseño lógico convierte el esquema conceptual, fruto de la etapa de

diseño conceptual, en un�esquema�lógico que permitirá definir y estructurar
los datos y restricciones en un esquema adecuado al tipo de bases de datos
que se pretende utilizar. Será, por lo tanto, necesario determinar qué tipo de
bases de datos se utilizará.
Actualmente, la gran mayoría de las bases de datos operativas son relacionales.

Tal y como hemos comentado anteriormente, el modelo ER permite definir
de manera conceptual, independiente del tipo de base de datos, una parte del
mundo real. Cuando queremos trasladar esta representación a una base de
datos relacional utilizamos el modelo�relacional.
El modelo relacional es el esquema lógico específico para bases de datos

relacionales.
En esta etapa nos concentramos en las cuestiones tecnológicas relacionadas Lectura complementaria
con el modelo de la base de datos, asumiendo que en la etapa anterior ya
Xavier�Burgués�Isla (2012).
hemos dejado resuelta la problemática de la estructuración de la información Disseny lògic de bases de dades.
en un ámbito conceptual. El resultado de esta etapa será un modelo relacional Barcelona: Edicions UOC.
de la estructura de la información.
En las bases de datos relacionales la información se estructura de la siguiente

manera:
• Las tablas son los elementos principales en el modelo relacional. Cada

entidad del modelo ER se representa mediante una tabla en el modelo
relacional. Además, algunas relaciones y atributos también se transforman
en tablas para ser representadas en el modelo relacional.
• Los atributos de las entidades se representan mediante los campos de las

tablas. Por ejemplo, la tabla que representa la entidad clientes probable-
mente contendrá los campos que hacen referencia al nombre y apellidos
del cliente, a su lugar de residencia, a su fecha de nacimiento, etc.
• El registro o tupla de una tabla agrupa toda la información de una misma

entidad, dando valores concretos para cada atributo de la tabla. Así, un re-
gistro contiene toda la información de una entidad (por ejemplo, un clien-
te) y un campo incorpora los valores de los atributos (como, por ejemplo,
el lugar de residencia del cliente, el número de su tarjeta de fidelidad, etc.).
• Las diferentes tablas de una base de datos relacional están relacionadas

entre ellas por medio de campos que son comunes a diferentes tablas, y
que denominamos claves�foráneas. De este modo representamos las rela-
ciones entre las diferentes entidades del modelo ER.
Ejemplo de modelo relacional
A continuación se recoge la traslación al modelo relacional del modelo ER expuesto ante-

riormente. Este modelo relacional presenta dos tablas: productos y categorías de productos.
La tabla productos contiene los mismos campos que se recogían en el modelo relacional,
más un nuevo campo, código de categoría, que es una clave foránea y nos permite vincular
cada producto con su categoría. Así, este campo contendrá en cada registro el código de
la categoría de producto asociado.
Ejemplo de modelo relacional

Por ejemplo, la tabla productos podría contener los siguientes registros o tuplas:
<2423, “M3564”, “Martillo PBH”, “Martillo perforador PBH 2100 550w”, “109,95”, 1> y
<3590, “Z52890-S”, “Sierra PKS”, “Sierra circular PKS 16 MULTO”, “134,95”, 2>
Donde cada uno de los valores separados por una coma corresponden a un campo de
la tabla.
En este caso, la tabla categorías de productos debería contener, como mínimo, dos registros
con los códigos de categoría relacionados, tal y como mostramos a continuación:
<1, “Martillos neumáticos”> y

<2, “Sierras eléctricas”>
Y por lo tanto, mediante el campo código de categoría indicamos que el “martillo PBH”
pertenece a la categoría de productos “martillos neumáticos” y la “sierra PKS” pertenece
a “sierras eléctricas”.
2. Bases de datos operativas
A lo largo del proceso de compra a través de una plataforma de comercio elec-

trónico se producen una serie de intercambios entre el sistema y el cliente que
efectúa la compra. Este flujo de información entre las dos partes tiene que ser
almacenado para hacer efectivo el intercambio comercial. La base de datos del
sistema de comercio electrónico almacenará esta información. Concretamen-
te, la base de datos que almacena esta información recibe el nombre de base
de�datos�operativa, puesto que asegura la operatividad del establecimiento.
La información básica para el correcto funcionamiento de una aplica-

ción de comercio electrónico (catálogo de productos, información de
los clientes y detalles de los pedidos, entre otros) se almacena en la base
de datos operativa del establecimiento.
El pedido en el caso de BricoTodo
Consideremos un caso típico de proceso de pedido en la tienda virtual de BricoTodo, que

nos permitirá ver las diferentes informaciones que requiere el cliente en cada etapa del
proceso:
1) El cliente potencial accede al establecimiento y se hace una idea de lo que se le ofrece

observando los diferentes apartados del sitio web. Este último debe dejar muy clara la
diferencia entre la información sobre el surtido (tipologías de productos, características
de los productos, promociones) de la información complementaria del establecimiento
(información corporativa, noticias del sector, etc.). En cuanto al surtido, es muy impor-
tante organizarlo de acuerdo con criterios que tengan en cuenta el proceso de decisión
de compra del consumidor, y no con criterios internos de la empresa.
2) El cliente, que tiene una idea aproximada de lo que busca, elige una sección del catá-
logo de productos, observa cómo se le presenta esta sección del surtido y comprueba si
hay posibilidades de interactuar mediante buscadores o directorios para poder afinar la
búsqueda y encontrar el producto que se adapte mejor a sus necesidades. En esta fase, la
base de datos ha de ofrecer diferentes posibilidades de mostrar los productos del surtido.
3) Una vez que el cliente selecciona uno de los productos, averigua si hay información
adicional sobre este para acabar de decidirse. En caso afirmativo, actúa para incorporar
el producto a la cesta de la compra, donde visualiza el producto elegido y se le permite
cambiar las unidades de compra y consultar los costes de transporte y entrega.
4) Cuando el cliente quiere formalizar el pedido, el sistema le solicita los datos personales,
de envío y de pago. Una vez introducidos, el cliente finaliza el pedido y se le envía un
comprobante de este, con una referencia para hacer el seguimiento y, si se tercia, formular
alguna reclamación posterior.
En general, la base de datos operativa debe tener dos características que son
indispensables para el buen funcionamiento de un entorno de comercio elec-
trónico: por un lado, ha de ser robusta y asegurar la consistencia de los datos; y,
por otro lado, tiene que ser bastante rápida para efectuar las diferentes opera-
ciones que se le ordenan en un tiempo razonable. Entre los procesos habituales
que debe realizar la base de datos operativa podemos encontrar el alta de un
usuario registrado, la modificación de precios, la consulta de la información

sobre un producto por parte del cliente, la incorporación de un artículo a la
cesta de la compra, etc.
Estos requerimientos provocan que el modelo de datos operativo sea muy

complejo. Para estructurar correctamente la información y permitir que el sis-
tema sea rápido, eficiente y consistente, la base de datos debe tener la infor-
mación estructurada en diferentes tablas y muy bien relacionada entre sí, a
través de múltiples vínculos entre las tablas. De este modo, cada operación
que se hace en la base de datos solo afectará a un número reducido del total
de tablas que componen la base de datos.
En general, también es importante procurar que la base de datos no

contenga datos redundantes, puesto que la redundancia de datos puede
producir estados de inconsistencia en los datos, además de ocupar un
mayor volumen de espacio físico.
2.1. Datos relativos al catálogo de productos
El catálogo de productos es una parte importante de la base de datos operativa.

Esta será la responsable de hacer posible que se puedan mostrar los productos
según diferentes criterios de ordenación y búsqueda, ayudando al cliente a
encontrar de manera rápida y eficiente el producto que está buscando en cada
momento.
Normalmente, cada establecimiento dispone de un sistema informático don-

de se guarda información de sus productos y del stock disponible de cada uno
de ellos. Es importante que la base de datos operativa de la aplicación de co-
mercio electrónico se nutra de este sistema, puesto que de este modo las ope-
raciones de mantenimiento del catálogo de productos habrá que hacerlas so-
lo una vez. Sin embargo, a menudo la base de datos del establecimiento elec-
trónico se encuentra situada fuera de las instalaciones de la empresa, alojada
en un proveedor de servicios de internet. Así, la empresa se puede olvidar del
mantenimiento del servidor web, que suele ser crítico en temas de seguridad y
requiere el trabajo de expertos en seguridad para su mantenimiento. En estos
casos, es muy conveniente definir mecanismos que permitan la sincronización
entre las dos bases de datos de manera automática y periódica. De este modo,
el establecimiento virtual mostrará los cambios, tales como la incorporación
de nuevos productos, cambios de tarifas y disponibilidad de stock, entre otros,
de forma inmediata a sus clientes.
A continuación, describiremos brevemente los principales atributos que for-

man un producto:
• Código�del�producto: generalmente se trata de un código numérico o al-

fanumérico que identifica de forma única un producto. A menudo las em-
presas asignan más de un código a cada producto (por ejemplo, un código
comercial o código de barras, y un código de almacén), pero es muy im-
portante que el sistema de comercio electrónico opere con un único códi-
go que identifique de manera única e inequívoca cada uno de los produc-
tos del catálogo.
• Precio: habitualmente cada producto tiene un precio fijo de venta, que

puede estar expresado en diferentes monedas. No obstante, algunos co-
mercios pueden asignar precios variables en función del volumen de com-
pra, el momento en el que se efectúe la compra u otras variables.
• Peso,�volumen�y�tamaño: esta información es relevante de cara al envío

del pedido, puesto que, junto con el destino del cliente, permite a los ope-
radores logísticos calcular el coste y la duración del transporte desde el
almacén. En el momento de hacer el pedido hay que utilizar ya esta in-
formación para indicar al cliente el coste que tendrá el transporte de los
productos que está adquiriendo.
• Stock: la información actualizada sobre el stock de cada producto, en com-

binación con el domicilio de entrega indicado por el comprador y la in-
formación del operador logístico sobre la duración del transporte, nos per-
mite informar al cliente sobre el día de recepción de su pedido. Además,
cuando se detecta que el stock disponible es inferior a un stock mínimo
determinado, se puede generar una orden de fabricación o compra del
producto que se está agotando, y así evitar la ruptura de stocks.
Los atributos descritos hasta ahora no dependen del idioma del establecimien-
to electrónico, puesto que todos ellos son numéricos. No obstante, hay otro
tipo de información de carácter textual, como los nombres, la descripción del
producto y la categoría a la cual pertenece, que varía para cada idioma, de
modo que hay que almacenar un valor diferente para cada idioma en el que
opera el establecimiento. Es aconsejable tener un idioma de referencia y em-
pezar por asegurar que todos los productos tengan la denominación, descrip-
ción y categoría correctas en esta lengua. Una vez elaboradas las traducciones,
el sistema podrá mostrar las denominaciones, descripciones y nombres de las
categorías según las preferencias de idioma de cada cliente:
• Nombre�del�producto: breve denominación del producto, que lo identifi-

ca de manera clara para el cliente. Suele estar limitado a un cierto número
de caracteres.
• Descripción�del�producto: descripción más exhaustiva del producto, don-

de se facilitan todo tipo de detalles relacionados con el producto. Habi-
tualmente, se presenta al cliente una lista de productos para una búsqueda
o categoría determinada utilizando el nombre y una pequeña imagen del
producto, y el cliente puede acceder a esta descripción exhaustiva a partir

de un enlace de “más información” o similar.
• Categoría�del�producto: la categoría permite clasificar productos a partir

de uno o más criterios. Para el buen funcionamiento del establecimiento,
es importante que la clasificación que se define sea sencilla e intuitiva,
de modo que sea fácil para los clientes entender las secciones que com-
ponen el surtido, así como saber dónde pueden localizar un determinado
producto.
Los productos en el caso de BricoTodo
Siguiendo el ejemplo de la ferretería BricoTodo y con lo que hemos comentado sobre los
productos, podemos indicar algunos de los atributos principales que habrá que definir
para cada producto del establecimiento virtual. Claramente, cada producto deberá tener
un código único para referirnos a él de forma única, pero probablemente también habrá
que incorporar la referencia del fabricante y quizá un código interno del almacén. Evi-
dentemente, habrá que incorporar la información básica del producto, como su nombre,
descripción, precio, stock disponible, peso, volumen y tamaño. Para cada producto ha-
brá que incorporar una o más imágenes, puesto que muchas veces no es suficiente con
una sola imagen para hacerse una idea real del producto que estamos comprando en un
establecimiento electrónico. Finalmente, habrá que considerar la estructura de categorías
de productos, donde probablemente un producto podrá formar parte de una o más cate-
gorías (por ejemplo, un destornillador puede pertenecer a la categoría “carpintería” pero
también a las categorías “ferretería” o “electricidad”).
2.2. Datos relativos a los clientes
Resulta conveniente para el establecimiento virtual grabar la máxima infor-

mación posible sobre cada cliente que lo visita, lo que le permitirá aplicar ade-
cuadamente estrategias de segmentación y detectar oportunidades de negocio
(clientes con necesidades insatisfechas, posibilidades de venta cruzada de pro-
ductos complementarios, etc.).
Los tipos de clientes sobre los que se puede llegar a tener información en el
sistema serán los siguientes:
1)�Cliente�no�registrado�(anónimo): es aquel que o bien solo visita el web Cookies

sin comprar o bien compra de vez en cuando sin dejar más datos que los im-
Las cookies por sí mismas no
prescindibles para efectuar los pedidos. Dado que no se identifica previamen- permiten identificar al clien-
te, el sistema no tiene constancia de quién es mientras navega por el estable- te ni recogen ningún tipo de
información personal, sobre
cimiento. Así, cada vez que efectúa un pedido, se ve obligado a proporcionar compras o de pago.
de nuevo todos los datos necesarios. De todos modos, se puede guardar cierta
información de los clientes anónimos, puesto que el uso de cookies, como ve-
remos más adelante, permite reconocer si una conexión anónima proviene de
un ordenador o dispositivo que ya se ha conectado previamente. Esta infor-
mación puede servir para ofrecer productos similares a los que se han buscado
en anteriores conexiones. No obstante, estos datos no se pueden asociar con
clientes concretos si estos clientes no se registran.
2)�Cliente�registrado�en�una�lista�de�correo: es aquel que ha facilitado su

dirección de correo electrónico para que el establecimiento le informe por este
medio de novedades, promociones de venta, etc.
3)�Cliente�registrado�en�el�establecimiento: es aquel que proporciona infor-

mación personal relevante para el establecimiento, como sus datos personales
y sus preferencias de compra en lo que se refiere a formas de pago y envío.
Al acceder al sitio web, el establecimiento solicita la identificación del cliente
con un nombre de usuario y una contraseña, y esto permite que el sistema
lo reconozca y pueda mostrarle unos precios y unas ofertas personalizadas. Al
efectuar los pedidos, se le recuerdan sus datos, por lo que no hace falta que los
introduzca cada vez. Los clientes registrados también pueden segmentarse en
función de los criterios que se consideren más adecuados en cada momento
(demográficos, socioeconómicos, comportamiento de compra, etc.).
Los datos que obtenemos de los clientes, a diferencia de otros datos como
el catálogo de productos, son introducidos directamente por los clientes me-
diante la interfaz web del establecimiento electrónico. Por lo tanto, es impor-
tante asegurarnos de que introducen todos los datos que son necesarios para
el correcto funcionamiento del establecimiento, pero también otros datos que
nos pueden resultar de utilidad para entender el perfil de cliente que tenemos
y podernos ajustar a sus necesidades y demandas. De ahí la importancia de
que los formularios para la introducción de estos datos estén bien diseñados
y nos permitan las siguientes acciones:
1) Obtener todos los datos que consideramos relevantes, haciendo que sea
obligatorio introducir los datos de estos campos en los formularios web.
2) Especificar y validar el formato de los datos que introducen los clientes. Por Edad del cliente
ejemplo, si solicitamos la fecha de nacimiento del cliente, no podemos dejar
La edad del cliente se obtiene
que la introduzca en cualquier formato, puesto que se complicaría bastante su habitualmente por medio de
procesamiento posterior. su fecha de nacimiento. Es pre-
ferible contar con este atribu-
to que con la edad del cliente,
que cambiará cada año.
Formato de la fecha de nacimiento
Si solicitamos la fecha de nacimiento, hay que indicar y validar claramente el formato

que ha de tener esta información. Si no es así, podemos encontrarnos que un cliente
indique “1-mar-89” para señalar que nació el día 1 de marzo de 1989, mientras que otro
cliente nacido en el mismo día lo recoja mediante el texto “1/3/89” y un tercero lo haga
en el formato norteamericano “3-1-89”.
A continuación describiremos brevemente los principales atributos que se pue-

den recoger sobre los clientes y daremos algunas indicaciones para asegurar la
calidad de los datos recabados:
• Nombre� y� apellidos� de� los� clientes: es aconsejable que se indique por

separado el nombre, el primer apellido y el segundo apellido. El formula-
rio web tendría que presentar tres cuadros de texto con obligatoriedad de
rellenar el nombre y el primer apellido.
• Sexo: normalmente introduciremos esta información en la base de datos

mediante un carácter que indique si es hombre (H) o si es mujer (M). Es
aconsejable que el formulario web recoja o bien un desplegable con los
dos valores con la obligación de seleccionar uno, o bien dos botones de
opción con la obligación de elegir uno de ellos.
• Fecha�de�nacimiento: hay que indicar el día, el mes y el año. Para evitar los
errores que se producen al utilizar caracteres separadores, es preferible que
los datos sobre este atributo se introduzcan en tres campos diferenciados.
Sin embargo, internamente se puede guardar todo junto.
• NIF�(número�de�identificación�fiscal): esta información consta de ocho

números y una letra, que se obtiene a partir de una fórmula matemática
que se aplica a los ocho números anteriores. Se puede requerir que solo
se puedan introducir números en los ocho caracteres iniciales y una letra
en el último, donde podemos aplicar esta fórmula a los datos introducidos
para comprobar que la letra asignada sea la correcta. En el supuesto de que
no sea así, se puede avisar al usuario y solicitar su corrección.
• Código�postal: es un código formado por cinco números, en el caso del

territorio español. Si también se solicita la población, se puede utilizar una
base de datos de códigos postales y poblaciones para comprobar la corres-
pondencia entre el código postal y la población que se introduce. También
se puede obtener la población correspondiente a partir de su código pos-
tal. Esta opción tiene la ventaja de impedir que se guarde con nombres
diferentes una misma población.
• Población: normalmente es preferible que el formulario de gestión no so-

licite abiertamente la población, dado que no todo el mundo la escribirá
igual. Para evitar estos errores, lo más adecuado es que, a partir del código
postal introducido, se muestre la población asociada para que el usuario
valide si esta es correcta o, en caso de haber más de una, seleccione la co-
rrecta.
• Dirección: es recomendable que la dirección se introduzca de la manera

más detallada y cuidadosa posible. Para facilitarlo, se puede separar el tipo
de vía (que se puede indicar mediante un desplegable para reducir los erro-
res), del nombre de la vía (en un cuadro de texto), del número (en cuadro
de texto) y de toda la información restante, como el piso y la puerta.
• Provincia�y�país: es recomendable que la introducción de los datos refe-

rentes a la provincia o el país del cliente se haga mediante un desplegable
que permita al usuario elegir una opción de entre todas las posibles. De
este modo se evitarán los errores que se producen al introducir manual-
mente esta información.
• Correo�electrónico: es recomendable verificar que la dirección de correo

electrónico se ha introducido de manera correcta, ya sea mediante la com-
probación del formato (una cadena alfanumérica, seguida de un símbolo
“@” y de un nombre de dominio o subdominio válido) o enviando un co-
rreo de validación al buzón del cliente.
Los clientes en el caso de BricoTodo
La gestión de la base de datos de clientes no suele variar mucho de un establecimien-

to a otro puesto que generalmente se requieren los mismos datos para hacer efectiva la
transacción comercial. En primer lugar, habrá que registrar toda la información personal
del cliente, como por ejemplo su nombre y apellidos, sexo, fecha de nacimiento y DNI
o NIF. En segundo lugar, habrá que almacenar la dirección de facturación y la dirección
de envío, que pueden ser la misma o diferentes. Evidentemente, para cada dirección re-
queriremos los campos que hemos mencionado anteriormente. En tercer lugar, podemos
pedir al cliente datos que van más allá de lo que es estrictamente necesario para la venta
electrónica, pero que nos pueden ayudar a personalizar y mejorar su experiencia de na-
vegación o compra en nuestro establecimiento. Por ejemplo, en qué categorías de pro-
ductos está más interesado, si quiere recibir algún boletín informativo, etc.
2.3. Datos relativos a los pedidos
La información sobre los pedidos de los clientes es la tercera parte imprescin-

dible de un sistema de comercio electrónico. La información sobre cada pedi-
do contiene, por un lado, los datos�generales�del�pedido, tales como la fecha
y hora de la compra, el cliente que la ha efectuado, el importe y forma de pago,
etc.; y, por otro lado, las líneas�o�detalles�del�pedido. Cada una de estas líneas
o detalles del pedido se corresponde con uno de los productos comprados, e
incluye información sobre el producto, como su código, descripción, cantidad
adquirida, precio, descuento, etc.
En los datos de los pedidos resulta muy habitual replicar algunas informacio-
nes sobre el cliente y los productos adquiridos. Por un lado, es importante al-
macenar en cada pedido los datos de envío y facturación del cliente en el mo-
mento de efectuar la compra, puesto que estos pueden cambiar en el futuro y
nos interesa tener constancia de los datos en aquel preciso momento. Por otro
lado, en las líneas o detalles del pedido también nos interesa guardar el código
de cada producto comprado, su descripción, el precio y la cantidad adquirida.
Podría parecer que guardando el código del producto y la cantidad adquirida
ya sería suficiente porque, mediante la relación con la tabla de productos, se
pueden extraer la descripción y el precio. Pero dado que las descripciones y los
precios de los productos pueden variar en el tiempo, es conveniente guardar
las que estaban vigentes en el momento de efectuar el pedido.
A continuación, describiremos brevemente los principales atributos que for-

man parte de los datos�generales de los pedidos:
1)�Código�del�pedido: generalmente se usa un código numérico o alfanumé-

rico que identifica de forma única un pedido. Una parte de este código sue-
le contener una referencia al año en el que se hace el pedido. Por ejemplo,
“2016/001735” indica el pedido 1.735 del año 2016.
2)�Fecha�y�hora�de�la�compra: guardaremos en uno o dos campos la fecha y

hora de la compra. Esta información nos será de gran utilidad para estudiar el
comportamiento de nuestros clientes, y poder ver en qué épocas del año, qué
días de la semana y a qué horas del día formulan los pedidos.
3)�Estado�del�pedido: este indicador permite conocer rápidamente en qué es-

tado se encuentra un pedido, como por ejemplo pendiente de pago, en proce-
so de fabricación, listo para envío, en transporte o entregado.
4)�Código�del�cliente: el código del cliente nos permitirá vincular al cliente

con sus pedidos de manera inequívoca y rápida.
5)�Datos�del�cliente: tal y como ya hemos comentado, duplicaremos algunos

datos del cliente en el pedido para guardar los valores de estos atributos en el
momento concreto en el que se hace el pedido. Así no perderemos estos valores
si más adelante el cliente modifica sus datos personales. Además, también se
deberán grabar todos los datos referentes al envío, como la dirección donde
se tiene que efectuar la entrega y, si procede, el medio de transporte elegido
o el coste de este.
6)� Importe� de� la� compra: este campo, calculado a partir de las líneas del Importe del envío
pedido, indica el importe total del pedido. Generalmente no se trata de un
Cuando el área geográfica que
solo campo, sino que se calcula y almacena información sobre el precio bruto cubre el establecimiento es
de los artículos, el importe de los impuestos, el coste del envío, los descuentos muy amplia, el importe del en-
vío dependerá de varios facto-
aplicados y el importe total del pedido. res, como, por ejemplo, el des-
tino del pedido, el tamaño, el
peso y el volumen. Por lo tan-
to, el establecimiento deberá
7)�Forma�de�pago: Generalmente se detalla la forma de pago elegida por el calcular en función de estos
cliente, y si este ha sido validado y se ha efectuado correctamente o no. Si, por parámetros el importe del en-
vío y comunicárselo al usuario.
ejemplo, el pedido se paga con tarjeta de crédito, el establecimiento redirige al
usuario hacia el sitio web del banco pasándole el código de pedido y el importe
total para pagar. Una vez que el cliente efectúa el pago, el banco lo devuelve
al web del establecimiento y, a través del código de pedido, actualiza en el es-
tablecimiento la información sobre el resultado de la transacción. Si el pedido
se paga mediante transferencia, el vendedor tiene que esperar a recibirla para
entregar el producto.
(1)
A continuación, veremos algunos de los principales atributos de las líneas o Esto es especialmente relevante
cuando los precios o las descripcio-
detalles�de�pedidos, que guardan relación con los productos adquiridos por el
nes de los productos cambian en
cliente. Del mismo modo que en los datos generales del pedido que hacían re- el tiempo.
ferencia al cliente, aquí también duplicaremos algunos datos para poder con-
servar la información que estaba vigente en el momento de formularse el pe-
dido1. Los atributos son estos:
• Código�del�producto: nos permite identificar el producto adquirido de

manera inequívoca y rápida.
• Nombre�o�descripción�del�producto: normalmente solo guardaremos el

nombre o una descripción muy breve del producto. No es habitual dupli-
car la descripción larga en las líneas de pedido.
• Precio�del�producto: guardar el precio del producto en el momento de

hacer el pedido nos permite tener constancia de este en el supuesto de que
el precio del producto varíe en el futuro.
• Cantidad�adquirida: la cantidad de producto adquirida es relevante para

calcular el importe de la compra, así como a mantener el control de stocks
y preparar el pedido.
• Descuento�aplicado: en algunos casos se pueden aplicar descuentos. Al-

gunos clientes pueden tener descuentos especiales en la compra de deter-
minados de productos, por ejemplo, porque hacen un consumo conside-
rable. En estos casos no se puede aplicar un descuento general a todo el
pedido y se aplica solo a artículos concretos.
• Importe�parcial: el importe parcial es un atributo calculado o derivado Importe parcial e importe

del precio del artículo, la cantidad adquirida y el descuento, si procede. de la compra
Generalmente, se calcula para cada artículo del pedido y se almacena por A diferencia del importe de la
cuestiones de rendimiento y velocidad, puesto que de este modo no es ne- compra, que forma parte de
los datos generales de cada
cesario efectuar estos cálculos cada vez que hay que generar una consulta pedido, el importe parcial se
recoge en las líneas o detalles
o un informe de ventas. del pedido.
La suma de todos los importes
parciales recogidos en los de-
talles del pedido, más el coste
del envío, los impuestos y los
2.4. Datos relativos a los contenidos posibles descuentos aplicables
sobre toda la compra, ha de
coincidir con el importe de la
Una práctica muy habitual en los webs de establecimientos electrónicos con- compra.
siste en ofrecer información muy completa sobre los productos del surtido,
que va más allá de lo que sería necesario para tomar una decisión de compra.
Así, el sitio web intenta atraer a aquellos clientes potenciales que, por el mo-
mento, solo buscan información sobre unos determinados productos o cate-
gorías de productos a través de los motores de búsqueda de internet. Al ofre-
cer una información muy extensa y detallada sobre las categorías y productos
(características, productos relacionados, procedimientos de instalación, repa-
ración, etc.), el consumidor percibe que el vendedor tiene un conocimiento
exhaustivo de los productos, es un experto en la temática y tiene una verda-
dera voluntad de servicio al cliente.
Esta información adicional se puede proporcionar mediante diferentes recur-

sos, que comentamos a continuación. Cabe destacar que suele estar almace-
nada únicamente en la base de datos operativa del comercio electrónico y que,
por tanto, no se incorpora en otros elementos del sistema de información de la
empresa, puesto que esta información está dirigida principalmente a clientes
finales y no es relevante para los procesos internos de la empresa.
2.4.1. Noticias, agenda, novedades, foros, anuncios y FAQ
Las siguientes secciones pueden ofrecer a los clientes, o potenciales clientes,

información adicional relacionada con los productos del establecimiento elec-
trónico con el fin de proporcionar una imagen de experto en el sector, ofre-
cer a los clientes una mejor experiencia de compra y un servicio de atención
satisfactorio:
1)�Noticias: informan de las principales novedades sobre el sector que puedan

ser de interés para los clientes del establecimiento.
2)�Agenda: recoge el calendario de los acontecimientos más importantes que

afectan a la empresa y al sector, como por ejemplo ferias, conferencias y pre-
sencia en medios de comunicación.
3)�Novedades: esta sección destaca algunas noticias sobre los productos que
son de especial interés, como por ejemplo los últimos productos que se han
incorporado en el catálogo.
4)�Foros: permiten que los clientes interactúen con otros clientes o con el es- Estrategias para el foro
tablecimiento, ya sea planteando y resolviendo dudas o compartiendo opinio-
Es aconsejable que el foro se
nes sobre determinados productos del establecimiento. El objetivo es propor- active cuando el sitio web ten-
cionar un servicio de atención a los clientes, pero también crear un ambien- ga un número de visitas con-
siderable y que la empresa se
te de comunidad virtual que ayude a dar una imagen de pericia al estableci- implique en su seguimiento
activo. El personal del servicio
miento. de atención al cliente se tendrá
que encargar de que no quede
ninguna pregunta sin respues-
5)�Anuncios: dan a conocer a los usuarios acontecimientos, productos en los ta.
que están interesados, etc. En algunos casos puede ser interesante ofrecer este
espacio para el intercambio de productos de segunda mano entre los propios
clientes.
6)�FAQ: las respuestas a las preguntas más frecuentes permiten resolver dudas
y cuestiones habituales entre los nuevos clientes del establecimiento. Los foros
pueden ser un buen lugar para conocer las dudas recurrentes de los clientes
y añadirlas a las FAQ.
2.4.2. Información ampliada de los productos
Para mejorar o mantener la imagen de pericia de la empresa, es habitual ofrecer

información adicional de los productos, como por ejemplo documentación
técnica, manuales de uso, información sobre mantenimiento y reparación, ví-
deos demostrativos, etc. Cuando los productos tienen un componente técnico
o tecnológico importante, esta información se suele ofrecer en formato PDF,
de modo que la base de datos graba la referencia en el documento, la fecha de
publicación, el título, el resumen, etc. Esta información puede estar, incluso,
alojada en el sitio web del fabricante en el supuesto de que se trate de produc-
tos elaborados por terceros.
En algunos casos, dependiendo del tipo de producto que se está ofreciendo, Los tamaños de los
es interesante almacenar varias fotografías o imágenes para cada producto y archivos
así facilitar más detalles al cliente. Por otro lado, hay que tener en cuenta Si hacemos cálculos, vemos
que, para un mismo producto, se pueden proporcionar varias imágenes de que con estas medidas de imá-
genes se ocupan unos 80 kB
diferentes tamaños y calidades, en función de la página que el cliente esté por imagen. Por lo tanto, un
catálogo de 1.000 productos,
consultando y del dispositivo que esté empleando. Los sistemas de comercio cada uno con cinco imágenes,
pesará 400 MB en imágenes.
electrónico modernos automatizan esta tarea y generan diferentes calidades
de las imágenes que se incorporan a un producto para optimizar el tamaño y
el peso. Por ejemplo, la imagen del producto que aparece en las listas generales
de productos suele ser una miniatura de unos 80 × 80 píxeles y 5 kB de peso
(denominada habitualmente thumbnail). La imagen mediana (de unos 300 ×
300 píxeles y 25 kB de peso) se puede mostrar cuando el usuario ha elegido
un determinado producto, y se puede proporcionar una imagen ampliada (de
unos 800 × 800 píxeles y 50 kB de peso) en el supuesto de que el cliente solicite
ver más información del producto o la galería de imágenes del mismo.
2.5. Diseño de la base de datos de BricoTodo
A continuación veremos cómo se puede desarrollar un esquema conceptual

(modelo ER) para el caso de BricoTodo, y cómo se puede trasladar este esquema
conceptual a un esquema lógico (modelo relacional) que sea aplicable a una
base de datos relacional de este establecimiento comercial.
2.5.1. El modelo ER de BricoTodo
Para mantener la simplicidad del ejemplo, hemos obviado muchos detalles

que habría que incorporar en un modelo ER real, pero que quedan fuera del
alcance de los objetivos de este módulo.
En el ejemplo se consideran los tres bloques principales e indispensables de la

base de datos de un sistema de comercio electrónico: catálogo de productos,
clientes y pedidos.
Como se puede ver en el diagrama de la figura siguiente, hemos definido una

entidad productos con un conjunto de atributos que permiten definir las ca-
racterísticas de cada producto: código, referencia, nombre, descripción y precio.
El código está marcado como clave primaria de la entidad, puesto que será el
atributo elegido para identificar de forma única cada uno de los registros. Hay
que destacar que la referencia del producto, habitualmente proporcionada por
el fabricante o proveedor, también es un código único para cada registro, y
por eso está marcado como clave candidata. Esta entidad se relaciona, por un
lado, con la entidad categorías de productos, mediante la relación pertenece. Ca-
da artículo ha de pertenecer a una y solo a una categoría, mientras que una
categoría puede contener tantos productos como se desee. Esta característica
se indica en los diagramas ER mediante la conectividad de la relación, donde
leemos que “Un producto pertenece a 1 categoría” y en sentido inverso, “Una
categoría contiene N productos”.
Modelo ER
Por otro lado, los productos también se relacionan con los detalles de pedidos
mediante una relación 1:N, es decir, el detalle de pedido se relaciona con un
producto, y un producto se puede relacionar con muchos detalles de pedidos.
La entidad detalles de pedidos contiene atributos como la cantidad de producto,
el precio unitario, el descuento y el importe parcial, que es un atributo derivado o
calculado. Este concepto se refiere al hecho de que su valor se calcula a partir
de otros valores, en este caso de la cantidad, el precio y el posible descuento.
Los detalles de los pedidos están relacionados con la entidad pedidos, que con-
tiene los datos generales de cada pedido, como por ejemplo el código del pedi-
do, la fecha y el estado de preparación de este. Y aquí hay que tener presente
que el estado del pedido es también un atributo derivado, puesto que su valor
viene determinado por diferentes condiciones de la base de datos (como por
ejemplo, ¿están los productos del pedido en stock?, ¿se ha facturado el pedi-
do?, ¿se ha servido el pedido?).
Finalmente, cada pedido está relacionado con un cliente. La entidad clientes

contiene los datos básicos que BricoTodo almacenaría de cada cliente, como
son el código de cliente, el NIF (que se define como clave candidata) y el nombre
del cliente. Evidentemente, en un sistema real habría que almacenar muchos
más datos de los clientes, pero los hemos obviado para mantener el esquema
simple y de fácil lectura. Los clientes, de manera similar a los productos, se
clasifican según una tipología que reflejamos en la relación es y la entidad tipo
de clientes.
2.5.2. El modelo relacional de BricoTodo
A continuación se presenta un posible modelo relacional desarrollado a par-

tir del modelo ER que acabamos de estudiar. Hay que tener en cuenta que el
proceso de conversión de un modelo conceptual a un modelo relacional no
es único ni sencillo, y que en muchos casos es un proceso iterativo que hay
que ir refinando y ajustando a las necesidades específicas del sistema. La figu-
ra siguiente muestra un modelo relacional que satisface las restricciones del
modelo conceptual definido anteriormente.
Esquema relacional
El modelo relacional completo consta de seis tablas. En primer lugar, pode-

mos ver la tabla productos, que contiene la información básica descrita ante-
riormente en los campos código, referencia de compra, nombre, descripción, precio
y código de categoría. Este último campo es el que relaciona cada producto con
la categoría concreta a la que pertenece, y contiene el código de la categoría,
que se encuentra en la tabla categorías de productos. De este modo, la base de

datos es capaz de vincular cada producto con su categoría y permite conocer
también todos los productos de una categoría determinada.
De modo similar, la tabla pedidos contiene la información general del pedido,

que, como hemos visto anteriormente, incluye el código del pedido, la fecha
en la que se ha hecho el pedido, el estado de este y el código del cliente que ha
efectuado el pedido. Mediante este último atributo, podemos vincular cada
pedido con su cliente. Los detalles del pedido, es decir, los productos concretos
que se han adquirido en el pedido, están almacenados en la tabla detalles de
pedidos. Esta tabla contiene todos los atributos descritos anteriormente (can-
tidad, precio, descuento, importe parcial) y dos campos adicionales: el código de
pedido, que vincula cada línea de detalle con el pedido al que pertenece; y el
código de producto, que permite vincular cada línea de pedido con su producto.
Finalmente, la tabla clientes contiene la información necesaria de cada cliente,

que incluye el código del cliente, el NIF, el nombre del cliente y el código de tipo
de cliente, que permite vincular los clientes con su tipología. La tabla tipos de
clientes nos permite agrupar los clientes según una tipología. Cada tipología de
clientes se identifica a través del código de tipo, y contiene información sobre
el nombre y una descripción que asignamos a este tipo de clientes.
3. Personalización y monitorización de los usuarios
Además de la información que se puede obtener a través de encuestas en línea,

dinámicas de grupo en línea y otras técnicas de investigación de mercados
que se pueden utilizar en internet, la tecnología de la red permite obtener y
grabar de manera sistemática y automatizada mucha información relacionada
con el comportamiento de los clientes en el sitio web. Esta información, una
vez analizada, permite mejorar la adecuación del establecimiento al compor-
tamiento de los usuarios.
Distinguimos tres tipos de técnicas para recoger información sobre los usua-
rios de manera automatizada. En primer lugar, veremos aquellas técnicas que
permiten identificar al usuario y guardar información que hay que tener en
cuenta para mejorar y personalizar su experiencia en futuras visitas; en segun-
do lugar, trataremos aquellas técnicas que generan información como resul-
tado de la navegación del usuario por el sitio web y que nos pueden facilitar
estadísticas de los accesos y los comportamientos de los usuarios en el estable-
cimiento electrónico, y en tercer y último lugar, comentaremos brevemente
las herramientas de analítica social que nos pueden aportar información sobre
el grado de satisfacción de los usuarios del establecimiento electrónico.
3.1. Personalización y preferencias de los usuarios
Para adaptar un establecimiento de comercio electrónico a sus usuarios, es im-

portante conocer de manera detallada el comportamiento de los usuarios que
visitan repetidamente el establecimiento y construir un historial de su nave-
gación y preferencias. Mediante estas técnicas podremos guardar las preferen-
cias de los usuarios del establecimiento y les podremos ofrecer una navegación
más personal y satisfactoria por nuestro sitio web.
En este punto es importante recordar que cualquier sitio web funciona utili- Protocolo sin estado
zando el protocolo HTTP (o HTTPS en su versión segura), que es un protocolo
Un protocolo sin estado es un
sin�estado, es decir, que no guarda ningún tipo de información sobre los ac- protocolo de comunicaciones
cesos y las decisiones que hace el cliente en su navegación por el sitio web. No que trata cada petición como
una transacción independien-
obstante, un sitio de comercio electrónico requiere mantener un estado con el te, que no tiene relación con
ninguna solicitud anterior. De
cliente, puesto que, por ejemplo, es necesario guardar información sobre los este modo, la comunicación se
desarrolla a través de pares in-
productos que el cliente acaba de incorporar a la cesta de compra. Para que el dependientes de solicitud (por
servidor pueda mantener este tipo información, se utilizan las cookies. ejemplo, del navegador del
cliente) y respuesta (del servi-
dor del sitio web del estableci-
miento).
Las cookies son pequeños ficheros de texto que se almacenan en el or-

denador, o en general en el dispositivo del usuario, mientras este nave-
ga por diferentes sitios web, y que guardan una pequeña cantidad de
información, como por ejemplo un código identificativo único del dis-
positivo o las preferencias de navegación del usuario.
Hay que remarcar que las cookies solo pueden almacenar un volumen muy re-
ducido de información, y que no guardan muchos de los datos de los clientes
que son relevantes para el establecimiento. De hecho, tanto la información
personal del usuario (su nombre y apellidos, la dirección de correo electrónico,
la dirección física, etc.), que se obtiene habitualmente a través de los formula-
rios de registro en el sitio web, como la información generada por los ficheros
de registro sobre el comportamiento de navegación del cliente (páginas visi-
tadas, productos consultados, etc.), como la que hace referencia a su compor-
tamiento de compra (artículos adquiridos, momento de la compra, etc.) se al-
macenan en la base de datos operativa del establecimiento y no en las cookies.
Dado que las cookies se almacenan en el dispositivo del usuario, este puede
decidir (a través de las opciones de su navegador) si autoriza o no que la pá-
gina web escriba estos ficheros en su dispositivo. De todos modos, cuando el
establecimiento virtual detecta que el navegador del usuario tiene la opción
de las cookies desactivada, es habitual que lo avise de la necesidad de activarla
para poder navegar por el sitio web, puesto que las cookies, entre otras cosas,
mantienen el código de sesión. Este código permite encadenar los diferentes
procesos que un mismo usuario hace en un sitio web (por ejemplo, seleccionar
productos, introducir los datos de envío y pago, etc.). Por este motivo, hay
muchos sitios web que no permiten efectuar ciertas operaciones si el usuario
tiene las cookies desactivadas.
Hay dos alternativas principales para identificar y reconocer a los clientes cada
vez que vuelven a acceder al sitio web:
• Usuario�registrado: requiere que el cliente se haya registrado como usua- Recordando el idioma
rio del establecimiento electrónico. Cuando el usuario se registra en el es-
Si el usuario selecciona una
tablecimiento, se le solicitan sus datos personales, que serán empleados preferencia de idioma, la apli-
para formalizar los diferentes pedidos que pueda hacer, pero también otros cación web guardará en una
cookie el idioma seleccionado,
datos sobre sus preferencias, tales como el idioma, las categorías de pro- y cada vez que el mismo usua-
rio entre al web, la aplicación
ductos en las que está más interesado, si desea recibir algún tipo de boletín web consultará si existe alguna
cookie donde haya guardado
electrónico (o newsletter) con novedades e información del establecimien- esta preferencia. Si la encuen-
to, etc. Por lo tanto, cada vez que un cliente registrado accede al estable- tra, mostrará el web de acuer-
do con la preferencia. En caso
cimiento y se identifica mediante el nombre de usuario y contraseña que contrario, puede consultar el
idioma del navegador o mos-
previamente ha facilitado, podemos adaptar el idioma y las preferencias trar el idioma por defecto del
de navegación a las que nos ha indicado previamente. establecimiento.
• Uso�de�cookies: si el usuario no está registrado, podemos consultar el có-

digo de la cookie y reconocer si el usuario ya ha visitado previamente el
establecimiento. También podemos utilizar las cookies para guardar cierta
información sobre el usuario y sus preferencias, como el idioma en el que
desea ver los contenidos del establecimiento o la fecha en la que accedió
por última vez, lo que nos puede permitir, por ejemplo, mostrarle las no-
vedades del establecimiento desde esa última visita.
En el supuesto de que los clientes accedan al establecimiento electrónico a

través de una aplicación móvil o app, la casuística en relación con la perso-
nalización y monitorización de los usuarios es idéntica. Por cuestiones de se-
guridad de la información, las aplicaciones móviles no se pueden conectar di-
rectamente a la base de datos para obtener la información, y generalmente
requieren un servidor web que les envíe la información del establecimiento
electrónico (catálogo de productos, información de clientes, pedidos, etc.). Por
lo tanto, a pesar de que las aplicaciones móviles ofrecen una interfaz más ami-
gable y adaptada al dispositivo, la obtención, el tratamiento y el envío de la
información es igual que en el caso de acceder al establecimiento electrónico a
través del navegador web. Una vez que el cliente se ha identificado en la apli-
cación móvil, las opciones de personalización y preferencias son las mismas
que acabamos de comentar para un usuario registrado; y mientras el usuario
no se identifica, la aplicación móvil guarda cierta información para facilitar la
navegación, de manera similar a lo que hacen las cookies en el navegador web.
Cabe señalar que cuando los clientes acceden al establecimiento electrónico

a través del navegador web, a pesar de estar registrados como usuarios, pue-
den optar por no dar sus credenciales y navegar como usuarios anónimos. En
cambio, los clientes que acceden al establecimiento electrónico a través de
una aplicación móvil solo pueden navegar como usuarios anónimos hasta que
introducen sus credenciales. A partir de ese momento, la aplicación móvil re-
cuerda las credenciales del cliente y lo identifica como tal cada vez que accede
al establecimiento electrónico.
3.2. Estadísticas de acceso de los usuarios
Cada vez que un usuario accede a una de las páginas de nuestro establecimien-
to electrónico, genera información como resultado de la navegación, y esta
información puede ser utilizada para generar estadísticas de los accesos y de
los comportamientos de los usuarios en el establecimiento electrónico.
Cuando un usuario accede a una página web del establecimiento, podemos

saber:
1) la página�web concreta a la que ha accedido, y que puede hacer referencia,

por ejemplo, al detalle de un producto determinado o a la búsqueda de una
categoría de productos concreta;
2) la fecha�y�hora del acceso;
3) el código�de�sesión, es decir, un código numérico único que identifica el Código de sesión

ordenador o dispositivo del usuario y su sesión de navegación, y
Cada vez que un usuario entra
al sitio web se le asigna un nú-
4) el nombre�del�usuario, solo en el supuesto de que se haya registrado pre- mero que se mantiene durante
toda la navegación por las di-
viamente y se haya identificado al iniciar la visita al sitio web. ferentes páginas web; de este
modo, el establecimiento pue-
de saber las páginas que visita
un mismo usuario.
Esta información puede ser almacenada, principalmente, mediante las tres téc-
nicas que analizamos a continuación:
Dirección IP
1)�Ficheros�de�registro�(logs): el servidor web es el responsable de proporcio-
Recordemos que la dirección
nar toda la información de la página web. Salvo excepciones muy puntuales, IP es un código que identifica
cada ordenador conectado a la
el servidor almacena automáticamente las páginas que va proporcionando, la
red de internet.
fecha y hora en las que las sirve, la dirección IP de la máquina que las solicita
y el código que identifica la sesión del usuario en unos ficheros de texto, lla-
mados ficheros de registro o ficheros de log. Esta técnica tiene algunas limita-
ciones que hacen que los datos que se obtienen puedan ser inexactos. La prin-
cipal limitación se debe a que los proveedores de acceso a internet emplean
los llamados servidores de memoria intermedia (proxy cache), que son unas
máquinas que almacenan las páginas web más visitadas por sus clientes. Para
reducir el tiempo de respuesta y el consumo de red, al solicitar una página, se
envía la que se tiene almacenada en la memoria caché en lugar de ir a buscar
la información del sitio web original. Aun así, hay técnicas de programación
web que permiten indicar a los servidores de memoria intermedia que no al-
macenen las páginas web, evitando de este modo que sirvan la página web sin
consultar al servidor web original. La principal ventaja de esta técnica es que
se ofrece gratuitamente con el plan de alojamiento del servidor y que todo
el proceso de obtención y almacenamiento de la información es automático.
Además, se suelen ofrecer herramientas de consulta y análisis en línea de la
actividad del web que son exportables a varios formatos y que admiten múl-
tiples criterios de búsqueda.
2)�Marcadores�de�página�(tags): esta técnica consiste en introducir un código

específico en cada página web que se quiere analizar para que, cada vez que un
usuario solicite acceder a ella, se grabe la información que se desea en la base
de datos operativa. Una de las principales ventajas de esta técnica es que no
se ve afectada por los servidores de memoria intermedia, puesto que estos no
pueden guardar las páginas web que incorporan marcadores. Por el contrario,
hay que hacer primero un estudio muy esmerado de qué información se quiere
obtener y cada cuánto se quiere guardar, con el fin de preparar la estructura de
la base de datos operativa para acoger esta información y no derrochar espacio
de almacenamiento. Además, al ser una técnica que se desarrolla específica-
mente según las necesidades de cada establecimiento, normalmente habrá que
programar a medida las herramientas de análisis de la información obtenida.
3)�Herramientas�externas�de�análisis: actualmente existen diferentes servi-

cios de estadísticas de sitios web que ofrecen información agrupada del tráfico
del sitio web. La utilización de estos servicios externos es sencilla, y solo re-
quiere indicar un código de seguimiento para cada establecimiento, que pro-
porciona el proveedor del servicio, y añadir unas librerías o plugins que permi-
tan la comunicación entre el servidor del establecimiento electrónico y el pro-
veedor del servicio. A partir de aquí, el proveedor almacena información sobre
el acceso y uso de los usuarios (mediante ficheros de registro o marcadores de
página), y ofrece una interfaz de consulta y análisis en línea de la información
de navegación de los usuarios. Al igual que en los casos anteriores, también es
habitual exportar la información en diferentes formatos para luego explotarla.
Google Analytics
Uno de los servicios externos de análisis más empleados y conocidos actualmente es

Google Analytics, que es la herramienta de analítica web de la empresa Google. Permite
obtener informes de seguimiento de usuarios exclusivos, rendimiento del segmento de
usuarios, resultados de las diferentes campañas de marketing en línea, tasas de rechazo,
duración de las sesiones, contenidos visitados, dispositivos empleados por los navegan-
tes, ubicaciones de procedencia, etc.
La mayoría de los sistemas de comercio electrónico y sistemas de gestión de contenidos

(CMS) actuales facilitan la comunicación con el sistema Google Analytics, de tal manera
que solo hay que indicar el código de seguimiento que se facilita en el momento del
alta del servicio y no es necesario modificar ninguna página del sitio web; el propio
sistema añade las librerías o plugins necesarios para la correcta comunicación entre las
dos plataformas.
Las tres técnicas comentadas, con diferentes matices y detalles, permiten guar-
dar información de las páginas visitadas por cada usuario. A partir de estos
datos se puede extraer la siguiente información:
• Páginas y secciones del establecimiento más visitadas, y productos más

consultados.
• Duración de cada visita al sitio web.
• Itinerario de navegación (orden de las páginas visitadas) seguido por el

usuario en su visita al establecimiento.
• Página final de navegación, es decir, última página visitada por el usuario

antes de abandonar el sitio web. Esta información permite detectar si hay
alguna página que desorienta a los usuarios y provoca el abandono del
sitio web.
• Estadística de acceso de los usuarios registrados, que nos facilita informa-

ción sobre la frecuencia de visita de los usuarios registrados, los días y
franjas horarias preferidas, los dispositivos que utilizan para acceder al es-
tablecimiento electrónico, etc.
3.3. Herramientas de analítica social
Además de analizar el comportamiento de los usuarios en el establecimiento

electrónico, es importante considerar la repercusión de las acciones del estable-
cimiento en medios sociales. Por ejemplo, es habitual que los establecimientos
electrónicos utilicen plataformas como Facebook o Twitter para promocionar
sus acontecimientos, nuevos productos del catálogo, etc. Estas acciones pue-
den dar notoriedad a la marca, tener una gran difusión a través de los propios
usuarios y acabar generando afluencia de público hacia el establecimiento.
Para analizar la respuesta de los usuarios a las iniciativas del establecimiento en

medios sociales se pueden emplear herramientas que recaban información de
los diferentes medios sociales y la presentan en informes para ser interpretada
y extraer las conclusiones pertinentes.
Podemos definir tres grupos de datos que ofrecen diferente tipo de informa-
ción para el establecimiento: volumétricos, cuantitativos y cualitativos.
3.3.1. Datos volumétricos
Los datos volumétricos representan el primer grado del análisis y permiten

conocer la difusión y repercusión del contenido publicado. En este nivel po-
demos extraer información sobre cuántas veces se han compartido nuestras
publicaciones (posts), cuántos usuarios han nombrado nuestra marca, cuántas
veces se ha mostrado nuestro contenido, etc.
Concretamente, existen cinco grandes grupos de datos volumétricos:
1)�Actividad: frecuencia de publicación de la marca en los diferentes medios

sociales.
2)�Comunidad: número de usuarios que siguen la marca en cada uno de los

medios sociales en los que se está presente.
3)� Visibilidad: número de menciones que recibe la marca por parte de los
usuarios de los medios sociales.
4)�Interacción: reacción que generan las publicaciones hechas por el estable-

cimiento en medios sociales. Dependiendo del tipo de medio (sitios de redes
sociales, microblogs, etc.) se pueden analizar diferentes reacciones, como por
ejemplo comparticiones o comentarios en Facebook y retuits en Twitter.
5)�Difusión: número de usuarios de medios sociales a los que les llega el con-
tenido, ya sean seguidores o no de la marca.
3.3.2. Datos cuantitativos
El segundo grado del análisis considera al usuario como el centro de la comu-

nicación y se propone obtener información sobre la comunidad de usuarios
que hay en torno al establecimiento electrónico, tales como su idioma, el gé-
nero, la edad, la localización o sus intereses.
El estudio de los intereses de una comunidad de usuarios se puede efectuar

considerando los temas de las conversaciones que mantienen, y el sentimiento
o tono de estas. Existen herramientas que permiten identificar de manera au-
tomática el sentimiento predominante o el tono de una conversación a partir
de las palabras que se utilizan en ella. Generalmente, se definen un conjunto
de palabras con un significado o connotación negativa, y otro conjunto para
las palabras positivas. Considerando la distribución y la frecuencia de estas
palabras en las conversaciones se puede identificar de manera bastante precisa
el sentimiento o tono de una conversación, normalmente presentado como
un valor dentro de una escala. A partir de un análisis de estas características
se puede saber si la comunidad de usuarios apoya las acciones que va desarro-
llando la marca o establecimiento.
Este tipo de análisis se puede hacer de forma manual, con herramientas de

inteligencia artificial o mediante metodologías específicas para el análisis de
sentimiento, como por ejemplo SMCA-MRI.
3.3.3. Datos cualitativos
Finalmente, el tercer grado del análisis se hace con datos que no se represen-
tan numéricamente. Aquí el esfuerzo se centra en estudiar e interpretar las
conversaciones de los usuarios. Por lo tanto, se requiere la participación de un
especialista, generalmente conocido como social media manager, que se encar-
gará de analizar qué comentan los usuarios.
Conocer los temas de conversación y los intereses de los usuarios permite de-
finir mejor las estrategias de negocio, efectuar acciones más focalizadas a los
intereses de una determinada comunidad y conectar mejor con los usuarios.
Por lo tanto, es importante prestar atención a todo lo que los usuarios puedan
compartir y comentar de la marca, sus intereses y sus inquietudes y tendencias.
El conocimiento de los contenidos más relevantes, las opiniones más compar-

tidas y aplaudidas, así como las críticas de la comunidad, permiten al estable-
cimiento adaptarse mejor a las demandas e intereses de sus usuarios.
4. Bases de datos analíticas
Los sistemas operacionales suelen presentar un grado de heterogeneidad muy

superior al que sería deseable dentro de una misma empresa, debido a causas
tan variadas como el momento en el que se desarrolló cada aplicación, los
requerimientos funcionales de cada aplicación o la falta de planificación en
su diseño. Esto provoca que, si los analistas quisieran acceder directamente a
los sistemas operacionales para efectuar sus consultas, en primer lugar sería
necesario que resolvieran estas heterogeneidades de los datos. Además de que
esta no es una tarea nada sencilla, los analistas tendrían un problema todavía
mayor: los sistemas operacionales están pensados para realizar acciones repe-
titivas de manera eficiente y, por lo tanto, no suelen almacenar información
que no sea relevante para poder mantener un nivel de eficiencia aceptable.
Concretamente, no suelen guardar datos históricos si no es necesario, puesto
que esto implicaría gestionar un gran volumen de datos. Pero precisamente los
datos históricos son esenciales para el tipo de consultas que quieren hacer los
analistas. Además, los tipos de consultas que hay que responder en un entorno
analítico no tienen una respuesta eficiente en los sistemas operacionales.
En este apartado, precisamente, nos centraremos en conocer los tipos de base

de datos que dan apoyo a los analistas en la toma de decisiones y los principales
conceptos asociados.
¿Qué información pueden obtener los analistas de la base de datos

analítica?
La base de datos analítica ha de poder dar respuesta a preguntas del tipo siguiente:
• ¿Cuáles han sido los productos más vendidos por el establecimiento virtual en cada
país y durante cada trimestre de los últimos cinco años?
• ¿Qué efecto ha tenido una determinada acción de marketing digital sobre las compras
efectuadas por parte de clientes jóvenes (por ejemplo, de entre 18 y 25 años)?
• ¿Cómo podemos segmentar los clientes en línea y dirigirnos a grupos de clientes con
características similares, de manera que despleguemos acciones comerciales específi-
cas para cada grupo?
4.1. El almacén de datos o data warehouse
Los almacenes de datos o data warehouse surgen para aportar conocimiento

útil en la toma de decisiones. Además, deben estar concebidos de tal manera
que permitan hacer consultas empleando el lenguaje natural del mundo de los
negocios y han de poder ser fácilmente utilizados por personas responsables de
diferentes áreas o departamentos de la empresa, que no serán necesariamente
expertos en gestión de bases de datos.
4.1.1. ¿Qué es el data warehouse?
El almacén de datos, o data warehouse, es una base de datos que integra en una
única plataforma datos procedentes de fuentes y subsistemas operativos dife-
rentes, con el objetivo de dar apoyo en la toma de decisiones para el negocio.
Podemos imaginar el data warehouse como un gran almacén en el que se van

guardando los valores que las variables o atributos van registrando a lo largo
del tiempo. Cada vez que se guarda un nuevo dato en este entorno, este queda
asociado al periodo o al momento del tiempo en el que se produjo.
La ventaja principal de los almacenes de datos consiste en la capacidad de

almacenar la información de manera homogénea y fiable en una estructura de
datos jerárquica pensada para facilitar las consultas estratégicas de la dirección
de la organización.
Lectura complementaria
El almacén de datos es una colección de datos orientados al tema, inte-
grados, historiados y no volátiles, organizados para dar apoyo en pro- W.�H.�Inmon;�R.�D.�Hackat-
horn (1994). Using the data
cesos de ayuda a la decisión. warehouse. Nueva York: Wi-
ley.
De esta definición se desprende el hecho de que estamos ante un nuevo tipo

de bases de datos cuya importancia radica en el apoyo que ofrecen a las orga-
nizaciones desde el punto de vista estratégico. A continuación analizaremos
con más detalle los principales rasgos característicos que definen cómo han
de ser los datos de un data warehouse:
1)�Orientados�al�tema: dado que no podemos conocer los requerimientos de

los usuarios en el momento en el que se construye el almacén de datos, la in-
formación no se estructura según su funcionalidad, sino dividida por temas de
interés. Por ejemplo, en un data warehouse se pueden considerar como temas
las ventas, los clientes, los envíos, etc.
2)�Integrados: el data warehouse incorpora datos provenientes de varias fuen- La importancia de la

tes, como por ejemplo la base datos operativa, el sistema de gestión de la in- integración de los datos
formación interna de la empresa e incluso otras bases de datos externas. Por lo Todos los atributos que expre-
tanto, es muy importante organizar correctamente la información e integrar- sen sus valores en forma de fe-
chas deben estar guardados en
la en un formato común. El objetivo es que los analistas, a pesar de que los el mismo formato (por ejem-
plo “dd/mm/aaaa”) y con la
datos provengan de fuentes diferentes, lo vean como si provinieran de una misma precisión (por ejemplo,
fecha expresada en año, mes y
única fuente. El sistema debe facilitar la resolución de heterogeneidades tanto día sin tener en cuenta la hora
de semántica como de sistema. y minutos).
3)�Historiados: todo dato almacenado en el data warehouse lleva asociado una

marca de tiempo, que indica el momento o periodo en el que ha ocurrido el
acontecimiento en el mundo real. La historicidad es importante para analizar
cómo han evolucionado las cosas y poder hacer estudios longitudinales sobre
los fenómenos que interesan.
4)�No�volátiles: la no volatilidad nos muestra cuándo hemos tenido conoci-

miento de los hechos y nos permite saber si un cierto informe se hizo tenien-
do en cuenta unos datos u otros. Esta característica implica que no existan las
operaciones de modificar y borrar propiamente dichas. Los datos no se borran
o modifican, sino que se insertan las correcciones y la fecha en la que se han
hecho.
A partir de lo que hemos visto sobre las bases de datos operativas y de la defi-
nición que acabamos de dar de las bases de datos analíticas, la tabla siguien-
te nos muestra un resumen de sus características y las principales diferencias
entre ellas.
Rasgos característicos y principales diferencias entre los entornos operativos y analíticos
Base de datos operacional Data warehouse
Datos sobre las operaciones o actividades habituales del negocio Datos sobre temas que afectan a la evolución del negocio
Diseño orientado a que la aplicación cumpla su finalidad Diseño orientado a las áreas de interés del negocio
Datos actuales o muy recientes Largas series históricas de datos
Datos muy detallados Datos muy detallados, pero también datos resumidos
Información cambiante, muy volátil Información estable, a la cual se va añadiendo los datos más re-
cientes
Muchos usuarios concurrentes Pocos usuarios concurrentes
Consultas predefinidas Consultas imprevistas
Pequeño volumen de datos Gran volumen de datos
Tiempo de respuesta muy breve El tiempo de respuesta de la base de datos no es crítico
Fuente: Òscar Alaverdra Martí (2006). Almacenamiento y explotación de datos en el comercio electrónico. Barcelona: Ediciones UOC.
4.1.2. El modelo de datos
La dificultad principal a la hora de llevar a cabo la creación de un almacén de

datos se encuentra en el hecho de saber, a priori, qué datos se necesitan y de qué
manera se han de organizar. La construcción de un modelo de datos para un
data warehouse es compleja y queda fuera de los objetivos de esta asignatura.
Aun así presentaremos, con un ejemplo, cómo podría ser un primer modelo,
muy sencillo y simplificado, para un almacén de datos centrado en un único
tema que es de interés para un establecimiento electrónico, como por ejemplo
las ventas.
Modelo centrado en las ventas en el caso de BricoTodo

Almacenes de datos
orientados a temas
Supongamos que BricoTodo quiere crear un almacén de datos que le permita extraer
información relevante sobre las ventas que hace a través de su tienda electrónica.
El ejemplo de almacén de da-
tos que se recoge a continua-
A partir del ejemplo recogido en el subapartado 2.5 sobre el diseño de la base de datos
ción está centrado en un único
operativa de BricoTodo, donde hemos descrito un modelo conceptual basado en el mo- tema, como son las ventas, y
delo ER, construiremos ahora otro esquema conceptual muy simple. Este segundo mo- por lo tanto no se consideran
delo incorporará algunos elementos relevantes que hay que considerar al diseñar el al- otros temas importantes (clien-
macén de datos. tes, productos, devoluciones,
etc.).
Modelo centrado en el tema de las ventas
La figura anterior muestra un posible diseño conceptual del data warehouse e ilustra algu-
nas diferencias entre el modelo analítico y el modelo de la base de datos operativa, pero
no es un modelo completo que sea funcional en un entorno real.
En primer lugar, podemos ver que la entidad ventas está en el centro del esquema y se
relaciona con otras tres entidades, que son clientes, productos y tiempo.
Las entidades ventas y clientes se relacionan entre sí de tal manera que un cliente pue-
de haber ordenado varias ventas, pero una venta solo puede estar asociada a un único
cliente. De modo similar, una venta tiene asociado un único producto y cada producto
puede estar asociado a múltiples ventas. Y finalmente, una venta sucede en un instante
de tiempo, aunque un mismo instante de tiempo puede tener más de una venta asociada.
Las entidades clientes y productos ya las hemos visto anteriormente. Por el contrario, en
este esquema aparece una nueva entidad, tiempo, que, como ya hemos comentado, per-
mitirá asociar cada una de las entidades del almacén de datos al instante de tiempo en el
que se ha producido, de tal manera que conservaremos el detalle de los acontecimientos
que han ido sucediendo en orden cronológico. Cada instante de tiempo vendrá definido
por un identificador, la fecha, el número de trimestre del año, el número de semestre y el año.
A pesar de que estas tres últimas informaciones puedan parecer redundantes, permiten
acelerar las consultas en la base de datos, puesto que es muy habitual agrupar resultados
trimestral, semestral o anualmente.
Por lo tanto, la entidad ventas contendrá información sobre cada producto que se ha
vendido, a qué cliente se ha vendido y en qué instante de tiempo. Es interesante remarcar
que en el modelo operacional esta información va agrupada en un pedido, pero en cambio
en el entorno analítico es más probable que nos interese acceder a información sobre
el volumen de compras de cada cliente, el volumen de ventas de cada producto o los
momentos de más ventas, sin tener en cuenta cómo estas ventas se agrupan en pedidos.
Tal y como ilustra este ejemplo, el tiempo adquiere una importancia capital en el almacén
de datos analítico.
4.1.3. Los usuarios
Los sistemas operacionales suelen tener muchos usuarios que acceden a pocos
datos, mientras que en los sistemas analíticos para la toma de decisiones tene-
mos pocos usuarios que acceden a grandes volúmenes de información. Pode-
mos identificar tres tipos de usuarios en un data warehouse:
1)�Granjero: este tipo de usuario se encarga de tareas predecibles y repetitivas

de acceso a la información. De forma regular encuentra información que ayu-
da al funcionamiento de la empresa. En todo momento sabe qué busca y có-
mo lo tiene que obtener; generalmente utiliza de manera periódica las mismas
consultas o informes.
2)�Explorador: este usuario accede a los datos de manera imprevisible e irre- Ved también
gular. Planifica y prepara estudios que analizan una gran cantidad de datos de
El big data se analiza más ade-
forma simultánea. A diferencia del anterior tipo de usuario, a menudo no sabe lante, en el subapartado 4.2.5
realmente lo que busca hasta que lo encuentra, y no garantiza que haya resul- de este mismo módulo.
tados satisfactorios de su análisis. Pero en algunos casos los resultados son muy
interesantes y permiten mejorar de modo sustancial el negocio. Es habitual
que este usuario sea informático y/o estadístico experto en minería de datos
y análisis estadístico. En el contexto actual, con la aparición del big data, la
figura del explorador ha evolucionado hacia una nueva figura conocida como
científico de datos (data scientist).
3)�Turista: este último tipo de usuario habitualmente se corresponde con un

equipo de dos o más personas. Por un lado, encontraremos a una persona
con una visión global de la empresa, que planteará la posibilidad de hacer
un estudio sobre un determinado tema. Por otro lado, encontraremos a un
informático que conoce los sistemas analíticos de la empresa y que será el
encargado de analizar si el estudio es factible con los datos y las herramientas
disponibles. Los resultados de su trabajo serán proyectos que desarrollarán los
granjeros o los exploradores.
4.1.4. Las fuentes de información
Los datos del data warehouse se obtienen a partir de los sistemas operacionales
del establecimiento y de fuentes externas. Los datos obtenidos de diferentes
fuentes no se pueden utilizar directamente en el almacén de datos, a causa
principalmente de las diferencias que hay entre ellos en cuanto a su estructu-
ra y organización. Por lo tanto, hay que adaptar cada una de las fuentes de
información a los requerimientos del almacén de datos.
Una vez hemos seleccionado las fuentes de datos de las que nos interesa im-
portar información al data warehouse, hay que tener en cuenta tres situaciones
que pueden generar problemas en el proceso de inserción de datos:
• Cada conjunto de datos puede tener una estructura diferente dependiendo

de la fuente de donde proceda. Por lo tanto, habrá que aplicar un proceso
de�transformación a cada conjunto de datos con el fin de adaptarlo a la
estructura del almacén de datos.
• Hay que depurar los errores o conflictos que se puedan detectar dentro de
los datos de cada una de las fuentes.
• Finalmente, hay que integrar los datos depurando los errores o conflictos
que puedan aparecer entre datos de diferentes fuentes.
El proceso de transformación puede ser muy variado e incluir operaciones co-

mo cambios en el formato de los datos, cambios en la codificación, reestruc-
turación de campos, cambios de unidades o cálculo de atributos derivados,
entre otras muchas.
Durante el proceso de depuración hay que detectar y corregir valores incon-

sistentes (por ejemplo, edades que no puedan ser correctas), añadir valores por
defecto en ciertos campos sin valor definido y detectar y corregir información
duplicada dentro de la misma fuente.
El proceso de integración es diferente dependiendo de si se trata de la carga

inicial de los datos del almacén o de una actualización periódica. En la carga
inicial el volumen de datos suele ser muy grande, mientras que en las actuali-
zaciones periódicas el volumen es bastante menor.
Una vez definido el proceso de importación, hay que decidir en qué momen-
to y con qué frecuencia se ejecutará este proceso. Podemos distinguir distin-
tas frecuencias de refresco de los datos, que van desde la actualización unos
segundos después de que se produzcan las modificaciones en las aplicaciones
operacionales, hasta una actualización de manera no planificada.
La frecuencia con la que se traspasa la información de las estructuras tempo-

rales hacia el data warehouse se programa según las necesidades de actualiza-
ción de la información para efectuar análisis de los hechos que sean bastante
completos.
Cabe remarcar que este traspaso de información no se produce directamente

para no sobrecargar el sistema operacional y asegurar que la base de datos
operacional continúe trabajando con un tiempo adecuado de respuesta a las
operaciones que habitualmente se efectúan en ella. Por lo general, se usan unas
estructuras de datos temporales que almacenan la información durante un
corto plazo de tiempo. Y, en los momentos en los que el sistema operacional
es menos utilizado, la información se traspasa al data warehouse.
Enriquecer a través de fuentes de información externas
Si la empresa desea obtener más información de los clientes de la que tiene

distribuida entre las diferentes bases de datos operacionales, existe la posibili-
dad de obtener más información por medio de bases de datos externas. Bási-
camente podemos identificar cuatro vías que permiten este enriquecimiento:
(2)
• A� partir� de� los� censos: el INE hace encuestas de manera periódica a la La sección censal es una par-
tición de un término municipal
población española y ofrece a las empresas la posibilidad de consultar una
con un volumen de entre 1.000 y
parte de la información agregada obtenida, que se proporciona a nivel 2.500 ciudadanos.
de detalle máximo de sección censal2. Para cada sección censal se ofrece

información sobre variables demográficas y socioeconómicas, como por
ejemplo el número de personas según grupos de edades, nivel de estudios,
situación laboral, número de hijos, etc.
• A�partir�de�bases�de�datos�de�empresas�especializadas: otra opción es

adquirir la información de otras bases de datos que comercializan empre-
sas especializadas, como RTA Clavites, Dun & Bradstreet o Acxiom, entre
muchas otras.
• A�partir�de�encuestas�a�los�clientes�actuales: una tercera vía es efectuar

encuestas a los clientes para actualizar los datos y ampliar la información
con sus intereses, necesidades o preferencias.
• A�partir�de�la�monitorización�de�los�clientes�actuales: también es posi-

ble monitorizar al usuario mientras navega por el establecimiento electró-
nico y guardar parte de esta información en el perfil del cliente. La opción
más habitual es considerar qué productos y categorías consulta o compra
con más frecuencia. Por ejemplo, si consulta a menudo las herramientas
de jardinería, podemos asociar a este cliente un interés en los temas de
jardinería y ofrecerle productos que le puedan interesar.
4.2. Técnicas de explotación de datos
El objetivo final de los almacenes de datos es generar conocimiento que ayude

a los gestores y responsables de los negocio en la toma de decisiones estraté-
gicas.
Las técnicas de explotación de los almacenes de datos permiten conver-

tir la información almacenada en el data warehouse en conocimiento
útil para la toma de decisiones.
Se conoce como plataforma�de�apoyo�de�decisiones (decision support work-

bench) el conjunto de herramientas y aplicaciones de las que disponen los
usuarios del almacén de datos para acceder, recuperar, manipular y analizar
los datos ubicados en el data warehouse. Según el perfil de usuario que haga
uso de estas herramientas, diferenciamos dos modos de uso:
• Modo�de�verificación: generalmente es empleado por los granjeros, que

se plantean una hipótesis y, a través del análisis de datos, examinan su
validez. Existen dos técnicas principales dentro de este grupo:
– las consultas� y� listas, que permiten efectuar análisis simples de los
datos del data warehouse, y
– el análisis�multidimensional, que es una técnica más apropiada cuan-
do se plantean cuestiones más complejas.
• Modo�de�descubrimiento: este modo es empleado por los exploradores

del almacén de datos, que habitualmente se plantean cuestiones y, me-
diante el análisis de los datos, tratan de darles respuesta. La minería�de
datos es la técnica mediante la que analizan los datos del data warehouse,
o parte de ellos, e intentan descubrir relaciones entre los datos que no son
evidentes por el gran volumen de información almacenada.
A continuación, estudiaremos una por una todas estas técnicas que permiten
consultar y analizar los datos almacenados en el data warehouse.
4.2.1. Consultas y listas
Las consultas y listas son técnicas que no son exclusivas del entorno analítico.
Cuando se utilizan para hacer consultas al data warehouse permiten elegir los
datos que interesa obtener, los criterios para filtrarlos, los análisis que se pue-
den efectuar y las formas como se mostrarán los resultados de estos análisis.
Básicamente, estas técnicas permiten acceder y recuperar los datos almacena-

dos en el data warehouse, realizar análisis simples de los datos y presentar los
resultados en forma de listas, informes, hojas de cálculo, gráficas, cuadros de
mando, etc.
¿A qué cuestiones podemos responder empleando consultas y listas?
Algunas preguntas que podemos resolver empleando estas técnicas son estas:
• ¿Hay productos que concentran sus ventas en determinadas épocas del año?
• ¿Cuál es la tendencia de venta de un determinado producto en los últimos 24 meses?
• ¿Cuáles son los diez mejores clientes de cada zona geográfica y cuál es su tendencia
de compra en los últimos 12 meses?
• ¿Cuáles son los productos más y menos vendidos en el último año?
Ejemplo de consulta en el caso de BricoTodo
En el caso de BricoTodo el proceso puede ser el siguiente:
1)�Definición�de�la�hipótesis: los responsables de BricoTodo se plantean, por ejemplo,

si las herramientas de ferretería se venden más cuando se aproximan los meses de va-
caciones, puesto que mucha gente dispone de más tiempo libre y, por lo tanto, podría
aprovechar para arreglar y mejorar algunos acabados de la casa o garaje.
2)�Necesidades�de�datos: para poder evaluar la hipótesis hay que estudiar las ventas de
todos los productos que pertenecen a la categoría ferretería durante un cierto periodo
de tiempo.
3)�Acceso�y�recuperación�de�datos: en primer lugar, hay que decidir en qué periodo de

tiempo queremos obtener los datos, y a continuación aplicar el filtro de tiempo y obtener
los datos que hemos determinado en el paso anterior.
4)�Análisis�y�presentación�de�los�resultados: una vez que hemos obtenido la informa-

ción que cumple los requisitos deseados, hay que elegir la mejor forma de presentación
(formato informe, gráficas de evolución, diagramas de barras, etc.) que permita una lec-
tura fácil y rápida de la información.
Este proceso se puede iterar y refinar tantas veces como sea necesario, hasta que la hipó-
tesis (esto es, las herramientas de ferretería se venden más en época de vacaciones) quede
validada o desestimada.
4.2.2. Análisis multidimensional
Las herramientas de análisis multidimensional se basan en el procesamiento

analítico en línea, y son también conocidas como técnicas OLAP (online analy-
tical processing) en contraposición a las técnicas de procesamiento de transac-
ciones en línea u OLTP (online transaction processing), que normalmente se uti-
lizan en los entornos operativos de bases de datos.
Las técnicas OLAP presentan cinco características importantes:
1) Permiten una respuesta rápida a la mayoría de las consultas que se efectúan

en el data warehouse. Por ello implementan técnicas específicas de indexación
y de búsqueda que facilitan un acceso rápido a gran cantidad de datos.
2) Ofrecen herramientas�de�análisis estadístico y generación de resultados

sin que sea necesario un conocimiento elevado de técnicas informáticas de
programación.
3) Implementan los mecanismos de seguridad de acceso a la información y

concurrencia necesarios para poder compartir la información y evitar blo-
queos de datos.
4) Son capaces de almacenar la información necesaria para los diferentes aná- Metadatos
lisis teniendo en cuenta no solo el volumen de datos (que puede llegar a ser
Los metadatos son toda aque-
muy grande), sino también el significado�de�los�datos, que se suele materia- lla información descriptiva so-
lizar a través de los metadatos. bre el contexto, la calidad, la
condición o las características
de un dato u objeto, que faci-
lita su recuperación y evalua-
5) Son multidimensionales. Esta es, probablemente, la característica más im- ción. Por ejemplo, cuando ha-
cemos una fotografía con una
portante y la detallaremos a continuación. cámara digital se guarda auto-
máticamente información refe-
rente a la fecha, hora, diafrag-
Las técnicas OLAP están diseñadas para dar apoyo específico a las consultas ad ma, velocidad, modo de cap-
tura, etc. Estos datos son los
hoc que el usuario ha de formular a medida que se le va planteando la nece- metadatos de la fotografía.
sidad de analizar determinados datos. Para facilitar esta tarea, las herramien-
tas OLAP presentan los datos de manera similar a como los analistas están
acostumbrados a verlos, es decir, en función de hechos y dimensiones –y no a
partir de las tablas, atributos y relaciones que son típicas de las bases de datos
del entorno operacional.
El concepto de multidimensionalidad se basa en la dicotomía entre los datos

métricos (lo que queremos analizar) y los datos descriptivos (quién, dónde,
cuándo, cómo, etc.). Las dimensiones (datos descriptivos) definen un espacio
n-dimensional, conocido como hipercubo, en el que colocamos los hechos
(datos métricos) que deseamos analizar. Se puede ver este proceso como una
generalización de las hojas del cálculo, donde en lugar de trabajar en dos di-
mensiones podemos operar en espacios de n dimensiones. Cada posición de
este espacio se denomina celda y corresponde a un hecho concreto, que queda
determinado por las dimensiones que indican su posición.
La multidimensionalidad consiste en concebir los datos que queremos

analizar en términos de hechos y dimensiones de análisis, de modo que
sea posible situarlos en un espacio n-dimensional.
Ejemplo de hipercubo empleado en un análisis multidimensional
La figura siguiente muestra un hipercubo en un espacio tridimensional, formado por tres

dimensiones, que corresponden a la población del cliente, el producto adquirido y la fecha
de compra. Cada población, producto y fecha concreta definen una celda del espacio
donde indicamos el hecho; en este caso, el número de productos que se han vendido en
la fecha y la población seleccionadas.
La multidimensionalidad permite a los analistas, por un lado, focalizarse en

un único o un conjunto reducido de hechos. Es decir, el analista selecciona
los datos que quiere analizar, que definen las dimensiones del hipercubo, y a
continuación informa cada celda con los hechos que le corresponden. Así, se
reduce la complejidad del problema y la cantidad de datos que hay que em-
plear. Por otro lado, la multidimensionalidad proporciona a los analistas las
funcionalidades que necesitan, en términos de niveles�de�detalle y jerarquías
de�agregación de los datos. Los puntos que hay en cada dimensión se pue-
den agrupar por niveles según una cierta jerarquía, es decir, un conjunto de
puntos en un cierto nivel se agrupan para formar un punto del nivel superior.
Por ejemplo, si un hipercubo contiene una dimensión con información sobre
las poblaciones de los clientes, podemos agrupar las poblaciones y crear una
nueva dimensión que haga referencia a la provincia. Esto permite la genera-
ción de datos resumidos o agregados, que son muy importantes en la toma
de decisiones.
Cuestiones a las que podemos responder empleando las técnicas OLAP
Algunas preguntas a las que podemos responder empleando estas técnicas son estas:
• ¿Cuántas unidades de cada producto de una determinada categoría se vendieron a

mujeres de entre 20 y 40 años durante unos meses específicos y en una población
o barrio concreto?
• Partiendo de los filtros indicados en la pregunta anterior, ¿podemos comparar estos

datos con los obtenidos en el mismo periodo de tiempo de los cinco últimos años?
En los análisis multidimensionales se suele trabajar con dimensiones que hacen referen-
cia al tiempo, áreas geográficas, edad o sexo de los clientes, tipologías o grupos de clientes
y tipologías o grupos de productos, entre otras.
4.2.3. Minería de datos
Las dos técnicas de explotación de datos que hemos visto hasta ahora pertene-
cen al grupo de métodos que hemos denominado de verificación. Como tales,
esencialmente, nos permiten validar o desmentir una hipótesis previamente
definida. En cambio, la minería de datos pertenece al grupo que hemos deno-
minado de descubrimiento, y se define como el proceso no trivial de descubrir
patrones válidos, nuevos, potencialmente útiles y comprensibles dentro de un
conjunto de datos.
La minería de datos permite identificar y extraer conocimiento que no

es evidente, a priori, de grandes volúmenes de datos sobre, por ejemplo,
el comportamiento de los clientes o las relaciones entre productos.
Algunas de las principales diferencias de las técnicas de minería de datos res-

pecto al análisis de consultas y listas o el análisis multidimensional son estas:
• No son conducidas por el especialista (ya sea analista o explorador), sino

que muchas veces se despliegan de manera automática o casi automática.
• El número de dimensiones con las que trabajan es muy superior al de las

dos técnicas vistas anteriormente. Este es uno de los motivos que provoca
que sean capaces de descubrir relaciones entre datos que no son evidentes.
• Se centran en encontrar relaciones de causa-efecto o correlaciones entre los

datos o hechos del data warehouse, y también permiten descubrir automá-
ticamente patrones de comportamiento entre los clientes o consumidores.
• Hacen tareas de predicción y pronóstico.
Existe una gran cantidad de técnicas de minería de datos. Todas ellas tienen
el mismo objetivo: extraer conocimiento de los datos; pero los métodos que
utilizan pueden diferir mucho entre ellas. Sin pretender ser exhaustivos, enu-
meraremos los principales grupos de técnicas de la minería de datos:
1) Análisis estadístico y multivariante (regresión lineal, análisis de componen-

tes principales, análisis discriminante, etc.).
2) Reglas de asociación y dependencia.
3) Métodos bayesianos.
4) Árboles de decisión y sistemas de reglas.

5) Métodos relacionales y estructurales.
6) Redes neuronales artificiales.
7) Máquinas de vectores apoyo.
8) Algoritmos evolutivos y redes difusas.
Dentro de cada uno de estos grupos podemos encontrar diferentes técnicas Cuestiones a las que
y algoritmos, cada una de ellas con características propias. El problema y los podemos responder
empleando la minería de
datos determinan, en gran medida, cuáles son las técnicas más efectivas en datos
cada situación.
Algunas preguntas a las que
podemos responder emplean-
Ejemplo de análisis en el caso de BricoTodo do esta técnica son estas:
• ¿Cuántos y qué tipo de per-
Un ejemplo de análisis utilizando herramientas de minería de datos consiste en anali- files de clientes podemos
zar el perfil y el comportamiento de todos los clientes del data warehouse con el fin de encontrar en el estableci-
identificar grupos de clientes con características, preferencias e intereses similares. Este miento electrónico?
agrupamiento puede resultar muy útil para definir acciones de marketing específicas para
• ¿Qué relaciones hay entre
cada grupo.
los productos que ofrece-
mos en el establecimien-
to? Si, por ejemplo, detec-
En algunos casos, debido a la gran cantidad, variabilidad y dispersión de datos, tamos que hay grupos de
puede ser necesario el uso de almacenes de datos NoSQL o técnicas específicas dos o más productos que
se suelen comprar conjun-
de big data. En estos casos continuamos hablando de procesos de minería de tamente, podremos reco-
mendar productos relacio-
datos, pero con unas especificaciones suficientemente interesantes como para nados cuando un cliente
adquiere uno de ellos.
ser consideradas aparte.
4.2.4. Bases de datos NoSQL

Lectura complementaria
Actualmente, el modelo relacional es el más utilizado por los sistemas de ges- Pramod�J.�Sadalage;�Martin
tión de bases de datos. Pero a pesar de que este modelo es útil, la difusión Fowler (2012). NoSQL disti-
lled: a brief guide to the emer-
de internet y de los dispositivos móviles, además de la internacionalización y ging world of polyglot persisten-
la compartición de información, han impuesto nuevos requisitos a las aplica- ce. Pearson Education.
ciones que los modelos relacionales no pueden satisfacer; o al menos, con la

eficiencia que podríamos esperar. Por este motivo, en los últimos tiempos han
aparecido varios modelos de bases de datos y extensiones al modelo relacional
que permiten tener en cuenta otras necesidades: el tratamiento de informa-
ción con finalidades analíticas, el tratamiento de información geográfica, el
tratamiento de información semiestructurada en formato de grafos, etc.
Las principales características distintivas de las bases de datos NoSQL son que El lenguaje SQL
estas no aplican el modelo relacional, no utilizan el lenguaje SQL como len-
El lenguaje de consultas estruc-
guaje de consultas y están enfocadas a resolver problemas endémicos del mo- turado o SQL (structured query
delo relacional, como por ejemplo gestionar tipos de datos complejos. language) es un lenguaje de-
clarativo de acceso a bases de
datos relacionales que permite
especificar varios tipos de ope-
Dentro de esta categoría encontramos las bases�de�datos�orientadas�a�grafos, raciones, como por ejemplo
consultas, modificaciones o in-
un tipo de base de datos NoSQL que representan la información basándose en serciones, basándose en el ál-
la estructura de un grafo, es decir, como un conjunto de nodos y las relaciones gebra y el cálculo relacional.
entre pares de nodos. Estas bases de datos permiten emplear la teoría de gra-
fos para recorrer la base de datos y hacer consultas sobre los datos. Cualquier
información que se pueda modelar, de forma natural, empleando un grafo
es susceptible de ser implementada utilizando una base de datos orientada a
grafos.
Análisis de Twitter en el caso BricoTodo

Ejemplo completo
Imaginemos que después de un fuerte crecimiento e implantación en todo el país, la
empresa BricoTodo decide hacer un análisis exhaustivo de la repercusión de sus acciones Cristina�Pérez�Solà (2012).
de marketing en la red social Twitter. Diseño de una base de datos
para analizar la actividad de
De manera muy resumida, esta red social de microblogging permite el intercambio de pe- usuarios en Twitter. Barcelona:
Editorial UOC.
queños mensajes de texto, conocidos como tuits, entre los usuarios de la red. Estos men-
sajes se muestran en la página de perfil del usuario y son también enviados de forma
inmediata a otros usuarios que han elegido la opción de recibirlos mediante la opción de
seguir (follow) al usuario originario del mensaje. Por lo tanto, los usuarios de la red esta-
blecen relaciones unidireccionales entre ellos. Cualquier usuario puede responder (reply)
a los tuits de otros usuarios, creando cadenas de conversaciones o reenviar el mensaje de
un usuario a todos sus seguidores (followers), lo que se conoce como retuit.
Los responsables de BricoTodo se plantean algunas preguntas que consideran importan-

tes para ellos y para el buen desarrollo del negocio. Entre ellas destacamos:
• ¿Cuántos grupos de usuarios, o comunidades de usuarios, podemos encontrar en el

conjunto de seguidores de BricoTodo? ¿Cuáles son sus principales características y
diferencias?
• ¿Cómo se expande a través de la red la información que publica la empresa en sus

tuits?
• ¿Hay usuarios especialmente importantes a la hora de hacer difusión de esta infor-

mación? Y si es así, ¿cuántos y quiénes son?
A pesar de que es posible representar esta información en una base de datos relacional,
si optamos por una base de datos NoSQL, concretamente una base de datos orientada a
grafos, obtenemos una serie de ventajas importantes:
• Los datos se expresan de manera mucho más natural en una base de datos orientada
a grafos, ofreciendo una representación muy próxima al dominio de interés.
• Algunas de las preguntas que nos hemos planteado pueden ser resueltas aplicando
teoría de grafos, por ejemplo podemos emplear la segmentación de usuarios o com-
munity detection para detectar comunidades de usuarios en el grafo, basándonos en
las relaciones entre usuarios y sus atributos. También encontramos muchas medidas
de centralidad en la teoría de grafos que nos permitirán identificar a los usuarios más
importantes en el análisis del flujo de la información a través de la red.
• Muchas de estas bases de datos implementan algoritmos de teoría de grafos que per-
miten, por ejemplo, buscar el camino de coste mínimo, calcular la distancia entre
dos vértices, etc.
• Podemos añadir nuevos atributos a los nodos sin necesidad de modificar el esquema
de la base de datos.
4.2.5. Big data
La explosión de datos de los últimos años es una realidad. El incremento ex- Lectura complementaria
ponencial de dispositivos con conexión a internet, así como la aparición y el
Viktor�Mayer-Schönberger;
éxito de los medios sociales, han provocado una explosión en el volumen de Kenneth�Cukier (2013). Big
datos disponibles. Además, muchos de estos datos son abiertos y accesibles, lo data. La revolución de los datos
masivos. Madrid: Turner Pu-
que permite que puedan ser analizados por empresas e instituciones de todo blicaciones.
el mundo. Pero los datos en sí mismos no aportan valor, y ha sido necesaria la

aparición de nuevas tecnologías para procesarlos, analizarlos e interpretarlos,
y así darles valor.
Junto con la aparición de los datos masivos, o big data, ha surgido un nuevo
paradigma en el que la correlación ha sustituido a la causalidad como ob-
jetivo o centro del análisis. Si identificamos una correlación entre diferentes
variables de la muestra (por ejemplo, los adultos de una determinada región
geográfica consumen más productos de una determinada categoría), podemos
explotar esta información aunque desconozcamos la causa. De hecho, proba-
blemente la causa no es ni siquiera relevante para la empresa. Por lo tanto,
en este nuevo paradigma no interesa explicar el porqué de los hechos, sino
identificar correlaciones entre ellos.
Generalmente, el término big data se utiliza para describir las tecnologías, las
técnicas y las metodologías relacionadas con el procesamiento de grandes y
heterogéneos volúmenes de información.
A pesar de que no existe una definición formalmente aceptada, pode-

mos definir el término big data como el conjunto de técnicas y tecno-
logías destinadas a entornos de gran volumen de información, con va-
riedad de orígenes y en los que la velocidad de respuesta es crítica.
Esta definición se conoce como las tres uves del big data: volumen, velocidad
y variedad. Últimamente se ha añadido una cuarta característica, que es la
veracidad. Veámoslas brevemente:
1)�Volumen: se considera que un data warehouse tradicional puede asumir un

crecimiento de unos pocos gigabytes diarios. Al introducir nuevos orígenes
de datos podemos multiplicar la información y sobrepasar estos límites, lo
que afectará de manera importante al rendimiento del sistema analítico. Los
sistemas de big data resuelven este problema y son capaces de gestionar estos
volúmenes de información.
2)�Velocidad: es importante que el sistema de big data ofrezca la información

necesaria para la toma de decisiones en el menor tiempo posible. Esto implica
que tanto los tiempos de carga de los datos como los tiempos de procesamiento
de datos deben ser mínimos.
3)�Variedad: esta característica se refiere a que las técnicas de big data integran Fichero CSV
y trabajan con datos que tienen diferentes formatos y estructuras. Habitual-
El fichero CSV (comma-separa-
mente distinguimos entre datos estructurados, que son datos atómicos o ele- ted values) es un tipo de docu-
mentales, fácilmente interpretables y manipulables (como, por ejemplo, los mento en formato abierto pa-
ra representar datos en forma
de un fichero CSV); datos semiestructurados, que son datos elementales sin de tabla, donde las columnas
se separan mediante una coma
estructura fija (como es el caso, por ejemplo, de los documentos XML), y da- (o punto y coma cuando utili-
zamos la coma para separar los
tos no estructurados (por ejemplo, un documento entero de texto o una foto- decimales) y las filas por saltos
grafía). En este último caso la información no está representada por datos ele- de líneas.
mentales y esto hace que la interpretación y la manipulación resulten mucho

más complejas; a pesar de que bien tratados estos datos suelen proporcionar
Fichero XML
más información que los datos estructurados y semiestructurados.
Es un fichero semiestructura-
do compuesto por datos ele-
4)�Veracidad: la veracidad de los datos debe ser un requisito para poder tomar mentales. La estructura del do-
cumento no es previamente
las decisiones correctas en cada momento. Aun así, muchas de las técnicas conocida, por lo que general-
mente incluye etiquetas para
empleadas en big data trabajan con un cierto grado de incertidumbre. describir su propia estructura.
Escenario de big data en el caso de BricoTodo

Conversión en bytes
Supongamos ahora que BricoTodo experimenta un fuerte crecimiento durante años y
que el volumen de datos que gestiona crece también de manera exponencial: empezamos
9
gestionando decenas de gigabytes (GB) de información, pasamos después a centenares Gigabyte = 10 =
o miles de terabytes (TB) de información y acabamos teniendo centenares de petabytes 1.000.000.000 bytes
(PB). Llegará un momento en el que el sistema gestor del data warehouse tradicional em- 12
Terabyte = 10 =
pezará a tener problemas de rendimiento, así que las capacidades analíticas consumirán 1.000.000.000.000 bytes
días o semanas para completar los análisis. 15
Petabyte = 10 =
1.000.000.000.000.000 bytes
Imaginemos también que la empresa se plantea el lanzamiento de una nueva línea de
productos pero quiere analizar su viabilidad antes de empezar este proceso, que tiene
un gran coste. Los diferentes departamentos recogen datos para analizar la aceptación
que podría tener la nueva línea de productos. Supongamos que se recopila la siguiente RFID
información para analizar y evaluar el lanzamiento de esta nueva línea de productos:
RFID (identificación por radio-
• Históricos de las series temporales de ventas. frecuencia o radio frequency
identification) se basa en unas
• Segmentación de los clientes. tarjetas identificadoras que ha-
cen posible la lectura de infor-
• Datos facilitados por los institutos de estadística: datos demográficos, sociales, eco- mación sin contacto. Permiten,
nómicos, etc. de los consumidores en los territorios a los que atiende. entre otras aplicaciones, susti-
tuir los códigos de barras en
los productos y en las tarjetas
• Comentarios y gustos de los usuarios de Facebook.
magnéticas.
• Tuits, retuits y respuestas de los usuarios de Twitter.
• Perfiles de navegación y comentarios de los usuarios de la tienda electrónica.
• Desplazamientos de los clientes por las tiendas físicas de la empresa, obtenidos gracias
a las etiquetas RFID que llevan los productos.
• Resultados de encuestas y focus groups.
Este nuevo escenario presenta los problemas relacionados con las cuatro uves y, por lo
tanto, puede ser tratado mediante técnicas de big data. En primer lugar, a pesar de que
el volumen no supera los límites de las bases de datos relacionales, se sitúa en el límite
aconsejado para un buen rendimiento del data warehouse. En segundo lugar, la velocidad
de las técnicas tradicionales de análisis puede tener un coste temporal elevado con este
volumen y variedad de datos. En tercer lugar, existen diferentes orígenes de datos; algunos
de ellos son semiestructurados, como la relación entre los usuarios, tuits y retuits de
Twitter; y otros son no estructurados, como por ejemplo los comentarios de Facebook
o los surgidos en los focus groups, y esto hace que haya una variedad importante en los
datos que analizar. Y en cuarto y último lugar, tratamos con datos provenientes de medios
sociales (con abreviaturas, faltas de ortografía, interpretaciones ambiguas, etc.), encuestas
(pueden haber respondido en blanco o informaciones ambiguas) y focus groups (que no
aportan información generalizable para el mercado estudiado), que elevan el grado de

incertidumbre de los datos.
Las cuatro uves son un síntoma que puede indicar la conveniencia de utilizar un sistema
de big data para un cierto análisis. La principal diferencia, respecto a un análisis tradicio-
nal, es que se analizan todos los datos de las diferentes fuentes de manera integrada. Al
utilizar todos los datos combinados se reduce la pérdida de información y se incrementan
las posibilidades de encontrar correlaciones en comparación con aquellos análisis que
consideran los datos de manera separada.
Resumen
En este módulo didáctico hemos presentado los conceptos relacionados con la

gestión de la información empleada en una solución informática de comercio
electrónico.
En primer lugar, hemos introducido los conceptos básicos relacionados con el

diseño de una base de datos, poniendo especial énfasis en el diseño lógico y
conceptual de una base de datos. Estos diseños nos permiten entender cómo
está estructurada la base de datos y qué información contiene.
A continuación hemos estudiado cómo debe ser la base de datos operacional

de un sistema de comercio electrónico, que será la responsable de hacer fun-
cionar el día a día del establecimiento. Esta base de datos registra toda la in-
formación relacionada con los productos, los clientes, los pedidos y otra in-
formación adicional que ofrecemos en el establecimiento electrónico.
En el tercer apartado del módulo hemos detallado cómo podemos recoger in-
formación de los usuarios del establecimiento electrónico, que nos permitirá
conocer mejor a nuestros clientes y personalizar su experiencia de navegación.
Finalmente, en el cuarto y último apartado de este módulo nos hemos centra-

do en la base de datos analítica del negocio. Esta base de datos, denominada
almacén de datos o data warehouse, nos permite almacenar información histó-
rica con el fin de guiar los procesos de toma de decisiones del negocio. Tam-
bién hemos visto algunas de las técnicas más habituales de aprovechamiento
de esta base de datos para transformar la información en conocimiento útil
para el negocio.
Ejercicios de autoevaluación
1. Imaginad que estáis creando un establecimiento electrónico que se dedicará a la venta de
vehículos de segunda mano, concretamente de coches y furgonetas. De cada vehículo que
tendréis disponible, el cliente estará interesado en conocer la marca, el modelo, el año de
fabricación, la matrícula, el kilometraje, el color, el número de puertas y una descripción
general del estado del vehículo. Definid el esquema conceptual, empleando el modelo ER,
que permita modelar los conceptos necesarios para representar la información mencionada.
2. Definid el esquema lógico para una base de datos relacional, es decir, el modelo relacional
a partir del modelo ER del ejercicio anterior.
3. Para ayudar a montar el establecimiento electrónico de BricoTodo, proponed diferentes

criterios de agrupación de los productos en categorías, de modo que se puedan usar estos
atributos como secciones del establecimiento.
4. Se quiere analizar a los clientes de un establecimiento en línea para comprender las prefe-
rencias de compra en función de determinadas características demográficas y socioeconómi-
cas (estado civil, rango de edad, nivel educativo, etc.). Además, se quiere realimentar la base
de datos operacional para que el sistema ofrezca al cliente registrado aquellos productos que
pueden ser de su interés. El establecimiento considera que serán productos interesantes para
ellos aquellos productos que hayan sido comprados mayoritariamente por clientes con las
mismas características demográficas y socioeconómicas. Explicad cuáles serían las dimensio-
nes del análisis y el proceso de alimentación del data warehouse.
Solucionario
Ejercicios de autoevaluación
1. Aunque el modelo ER no es único, la figura siguiente proporciona un posible modelo ER

que da respuesta a la problemática presentada en el enunciado.
Esquema ER
2. La figura siguiente muestra el modelo relacional generado a partir del ejercicio anterior.
Esquema relacional
3. Una posible propuesta de agrupación de los productos podría ser la siguiente:
• Pintura/decoración
• Herramientas
• Ferretería
• Electricidad e iluminación
• Baño y cocina
• Carpintería
• Jardín
• Construcción
• Reformas y proyectos
4. El data warehouse puede analizar las ventas a partir de las dimensiones estado_civil,
rango_edad y producto, por ejemplo.
Por lo tanto, cuando en el entorno operacional se produzca una venta, se debe alimentar el
data warehouse con la información correspondiente para poderla analizar de acuerdo con las
dimensiones anteriores. Para hacerlo efectivo, la base de datos operacional podría contar con
una estructura temporal que fuera almacenando la información de las ventas (con todas las
dimensiones asociadas) hasta que esta se traspasara definitivamente al data warehouse. Por
lo tanto, la tabla “ventas” de la base de datos analítica tendría la información sobre cada
venta, desglosada a partir del estado civil del cliente, el rango de edad, el tipo de cliente y
el producto comprado.
Como ejemplo de resultado de este análisis tendríamos: “Los clientes solteros con edades
comprendidas entre los 20 y los 25 años han comprado el producto con referencia 102”.
Glosario
atributo m Propiedad de un tipo de entidad que interesa representar.
base de datos operativa f Sistema encargado de almacenar toda la información necesaria

para que el establecimiento realice las operaciones de ventas y otras operaciones relacionadas.
conectividad f Expresión del tipo de correspondencia entre las entidades de una relación.
data warehouse m Sistema de almacenamiento de grandes masas de datos obtenidos de

distintas fuentes o subsistemas operacionales que han sido organizados, integrados y prepa-
rados en un formato común para facilitar el proceso de toma de decisiones.
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 independiente de la tecnología que se quiere
emplear.
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 de sistema gestor de bases de
datos con el que se desea implementar la base de datos.
dividir para vencer f Estrategia que propone resolver un problema complejo a partir de
dividirlo en un conjunto de problemas más sencillos, donde la resolución de los diferentes
subproblemas acabará conduciendo a la resolución del problema inicial. En inglés se conoce
como divide & conquer.
grado de una relación m Número de entidades que asocia la relación.
entidad f Objeto del mundo real que podemos distinguir del resto de los objetos y del cual
nos interesan algunas propiedades.
lenguaje SQL (structured query language) m Lenguaje declarativo de acceso a bases

de datos relacionales que permite especificar varios tipos de operaciones, como por ejemplo
consultas, modificaciones o inserciones, basándose en el álgebra y el cálculo relacional.
minería de datos f Conjunto de técnicas estadísticas que permiten analizar la informa-

ción obtenida en el proceso de data warehouse e identificar patrones de comportamiento y
afinidades, lo que ayuda a comprender mejor a los consumidores.
modelo entidad-interrelación (ER) m Modelo de datos de alto nivel ampliamente uti-

lizado para el diseño conceptual de las aplicaciones de bases de datos. Su objetivo principal
es permitir a los diseñadores reflejar en un modelo conceptual los requisitos del mundo real.
sistema gestor de bases de datos (SGBD) m Tipo de software específico dedicado a

servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. En inglés,
database management system (DBMS).
tipo de relación m Asociación entre entidades.

Bibliografía
Adamson, C.; Venerable, M. (1998). Data warehouse design solutions. Nueva York: John
Wiley & Sons.
Casas Roma, J.; Conesa i Caralt, J. (2013). Diseño conceptual de bases de datos en UML.
Barcelona: Editorial UOC.
Herrera Joancomartí, J.; Alavedra Martí. O.; Domingo Ferrer, J.; Rius Gavidia,
M. A.; Sebé Feixas, F.; Soriano Ibáñez, M. (2001). Comerç electrònic. Barcelona: Editorial
UOC.
Kimball, R.; Ross, M. (2013). The data warehouse toolkit: the definitive guide to dimensional
modeling. Indianapolis, Indiana: John Wiley & Sons.
Krishnan, K. (2013). Data warehousing in the age of big data. Waltham, Massachusetts: Mor-
gan Kaufmann.
Provost, F.; Fawcett, T. (2013). Data science for business: what you need to know about data
mining and data-analytic thinking. Sebastopol, California: O’Reilly Media.
Silverston, L.; Agnew, P. (2008). The data model resource book. Nueva York: John Wiley
& Sons.

Pid 00221682-4 PDF

Cargado por

Copyright:

Formatos disponibles

Pid 00221682-4 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pid 00221682-4 PDF

Cargado por

Copyright:

Formatos disponibles

Almacenamiento

1. Sistemas de almacenamiento en el comercio electrónico........ 9

2. Bases de datos operativas................................................................ 19

3. Personalización y monitorización de los usuarios.................... 33

4. Bases de datos analíticas................................................................. 40

4.2.2. Análisis multidimensional ............................................. 48

El establecimiento electrónico, con la ayuda de la tecnología, debe ofrecer to-

En el ámbito del comercio electrónico, el cliente suele acceder al estableci-

Además, no hay que recurrir a técnicas específicas de investigación (como la

Dedicaremos este módulo didáctico a estudiar el nivel de datos de las aplica-

continuación, veremos cómo podemos personalizar la experiencia del usuario

En los materiales didácticos de este módulo encontraremos las herramientas

1. Comprender las funciones, los objetivos y las diferencias principales entre

2. Conocer el ciclo de diseño de una base de datos, especialmente las etapas

3. Conocer la estructura de datos que da apoyo a una aplicación de comercio

5. Entender los objetivos y el funcionamiento de un data warehouse, identi-

6. Comprender cómo y de qué datos se alimentará el data warehouse.

7. Estudiar diferentes técnicas de explotación de los almacenes de datos en

1. Sistemas de almacenamiento en el comercio

En las aplicaciones de comercio electrónico, y en general en cualquier aplica-

1)� Nivel� de� presentación: es la parte responsable de presentar el estableci-

2)�Nivel�lógico: es la parte que se encarga de realizar las operaciones con los

3)�Nivel�de�datos: es la parte responsable de almacenar todos los datos que

A su vez, en el nivel de datos podemos distinguir dos entornos diferenciados:

• el entorno� operativo, orientado a almacenar los datos necesarios para

• un entorno�analítico, donde se llevan a cabo análisis de los datos para

A continuación, veremos brevemente el proceso de diseño de una base de da-

1.1. El proceso de diseño de una base de datos

El diseño de bases de datos es el proceso de diseñar la estructura conceptual,

Tareas del proceso diseño

El proceso de diseño de una base de datos es el proceso en el que se

el diseño final de nuestra base de datos. De este modo, se descompone un

Etapas del diseño de bases de datos

Tipos de sistemas gestores de bases de datos

• Bases�de�datos�relacionales: son los tipos de bases de datos más utilizadas actual-

• Bases�de�datos�orientadas�a�objetos: permiten almacenar y recuperar colecciones de

• Bases�de�datos�geográficas: permiten la representación digital de entidades, objetos

• Bases�de�datos�documentales: permiten almacenar y recuperar documentos de toda

1.1.1. Recopilación y análisis de requisitos

El caso de la empresa BricoTodo

El personal de almacén de la empresa BricoTodo necesita acceder a una aplicación que

1.1.2. Diseño conceptual

1.1.4. Diseño físico

La etapa de diseño físico adapta el esquema lógico a las necesidades específicas

1.1.5. Implementación y optimización

La última de las etapas es la de implementación y optimización de la base de

1.2. Diseño conceptual

Tal y como hemos comentado anteriormente, el objetivo de esta fase es crear

El modelo ER (modelo entidad-interrelación) es un esquema conceptual de Modelo ER

Este modelo facilita el diseño conceptual de una base de datos y es aplicable al

El proceso de diseño conceptual de una base de datos se puede enfocar como

Ejemplo de tipo de entidad y atributos

Ejemplo de entidad y atributos

3) Una clave� candidata es un conjunto de atributos mínimo que permite

Cuando haya más de una clave candidata posible, el diseñador de la base de

Ejemplo de entidad con las claves

Ejemplo de entidad y claves primaria y candidata

Se define el grado�de�una�relación como el número de entidades que partici-

intervienen tres entidades, y de relaciones de grado n, o n-arias, cuando inter-