Pid 00160565

Gestió de la
informació
Bases de dades per a aplicacions B2C
PID_00160565
Óscar Alavedra i Martí

M. Àngels Rius Gavidia
© FUOC • PID_00160565 Gestió de la informació
Óscar Alavedra i Martí M. Àngels Rius Gavidia
Enginyer de Telecomunicacions per Llicenciada en Informàtica per la

la Universitat Politècnica de Catalu- Universitat Politècnica de Catalu-
nya (UPC). Ha desenvolupat la seva nya. Professora associada adscrita a
experiència professional a la UPC, l'Escola Universitària Politècnica de
com a programador i administra- Vilanova i la Geltrú des de 1996. El
dor de sistemes informàtics i com seu àmbit de recerca s'enmarca dins
a cap de la Unitat de Suport Tècnic del camp de les bases de dades. Ac-
per al Servei de Gestió Acadèmica. tualment professora pròpia dels Es-
Col·laborador en diversos projectes tudis d'Informàtica i Multimèdia de
de comerç electrònic. la Universitat Oberta de Catalunya.
Cap part d'aquesta publicació, incloent-hi el disseny general i la coberta, no pot ser copiada,
reproduïda, emmagatzemada o transmesa de cap manera ni per cap mitjà, tant si és elèctric com
químic, mecànic, òptic, de gravació, de fotocòpia o per altres mètodes, sense l'autorització
prèvia per escrit dels titulars dels drets.
© FUOC • PID_00160565 Gestió de la informació
Índex
Introducció.................................................................................................. 5
Objectius....................................................................................................... 6
1. Bases de dades, el motor del comerç electrònic......................... 7

1.1. Escenari d'una aplicació de comerç electrònic B2C .................... 7
1.1.1. B2C des del punt de vista de l'empresa ......................... 7
1.1.2. B2C des del punt de vista del client .............................. 8
1.2. Informació operativa enfront d'informació d'ajut a la presa
de decisió ..................................................................................... 9
2. Base de dades operativa................................................................... 11

2.1. Agents d'una transacció econòmica ............................................ 11
2.2. Disseny de la base de dades ........................................................ 13
2.2.1. Disseny conceptual ........................................................ 14
2.2.2. Disseny lògic .................................................................. 21
2.2.3. Disseny físic ................................................................... 27
2.3. Manipulació de dades ................................................................. 27
2.3.1. Catàleg de productes ..................................................... 28
2.3.2. Bossa o cistell d'anar a comprar (comandes) ................. 31
2.3.3. Clients ............................................................................ 34
3. Data warehouse: base de dades estratègica................................. 38

3.1. Necessitat d'un entorn estratègic ................................................ 38
3.2. Què és el data warehouse? ........................................................... 39
3.3. Model de dades per a l'anàlisi de les vendes .............................. 42
3.4. Alimentació del data warehouse.................................................... 44
3.5. CRM (customer relationship management) ..................................... 46
Resum............................................................................................................ 48
Activitats...................................................................................................... 49
Exercicis d'autoavaluació........................................................................ 49
Solucionari.................................................................................................. 50
Glossari......................................................................................................... 52
Bibliografia................................................................................................. 54
© FUOC • PID_00160565 5 Gestió de la informació
Introducció
En els últims anys, les empreses han vist com Internet ha canviat la manera
d'actuar de molts dels seus processos, fent-los molt més eficients i rendibles,
i, al mateix temps, ha permès de millorar la relació i comunicació amb els
clients, empleats i proveïdors.
Per a una empresa d'avui en dia, l'adaptació als canvis que Internet li repre-
senta es converteix més en una necessitat que en una elecció. L'empresa que
no adopti o no sàpiga adoptar bé aquests canvis, perdrà avantatge competitiu
respecte als competidors que sí que l'hagin integrat en els seus processos.
Per a aconseguir utilitzar eficientment tots els avantatges que Internet ens ofe- Sistemes d’informació de
reix caldrà integrar bé tots els sistemes d'informació de l'empresa, fet que no l’empresa
és una tasca gens fàcil, ja que hi intervenen un gran nombre de processos ges- Recursos humans, gestió eco-
tionats per diferents persones i departaments, que molt sovint treballen aïllats nòmica, gestió de recursos,
etc.
els uns dels altres.
En aquest mòdul ens centrarem en dues parts del sistema d'informació global
de l'empresa: el subsistema responsable de permetre les operacions de venda
dels productes mitjançant la xarxa i l'encarregat d'oferir suport a la presa de
decisions, des d'un punt vista estratègic.
El primer subsistema el suporta l'anomenada base de dades operativa.

S'anomena així perquè està orientada a operacions quotidianes relacionades
amb els processos de venda, com ara la construcció i presentació del catàleg
de productes (depenent dels diferents criteris que cal triar per part del client)
i l'emmagatzematge de tota la informació relativa a les comandes (productes
que ha triat un determinat client).
El segon subsistema el suporta una base de dades dissenyada a propòsit per a

donar suport a la presa de decisions estratègiques per a l'empresa. Estudiarem
la necessitat d'un segon dipòsit d'informació i veurem un model de dades per
a aquesta base de dades estratègica orientat a l'anàlisi de les vendes. En el dar-
rer apartat veurem com s'ha d'aplicar el concepte de CRM per tal d'orientar
l'estratègia d'empresa envers el client en lloc d'envers el producte.
Objectius
En els materials didàctics d'aquest mòdul l'estudiant trobarà la informació in-

dispensable per a assolir els objectius següents:
1. Conèixer el marc de referència sobre el qual s'han de concebre les aplica-

cions de comerç electrònic entre consumidor i empresa.
2. Saber identificar dos grans tipus d'informació, la que fa referència a les

operacions de vendes de l'empresa i la que és útil per a la presa de decisions.
3. Comprendre la importància de les bases de dades com a dipòsit de tota la

informació que gestiona una empresa en l'entorn del comerç electrònic.
4. Entendre els models de dades, que es presentaran com a genèrics, i ser

capaç d'introduir les modificacions necessàries per a adaptar-los a models
d'empresa específics.
5. Saber aplicar els mecanismes de manipulació de dades per a gestionar les

vendes de l'empresa de la manera més adequada.
6. Comprendre la necessitat d'un data warehouse per a transformar la infor-

mació en idees i accions que repercuteixin en la productivitat del negoci.
7. Ser capaç de recollir tota la informació d'interès per al negoci de manera

que serveixi per a donar suport a la gestió de relacions amb els seus clients.
1. Bases de dades, el motor del comerç electrònic
Des del punt de vista de la gestió de la informació, veiem un procés de comerç

electrònic com un conjunt d'operacions asíncrones entre diversos agents que
s'ubiquen en diferents punts de la xarxa.
El fet que la compra es realitzi a partir d'un seguit de fluxos d'informació, que
provenen d'ubicacions i agents diversos requereix un dipòsit de dades capaç
d'emmagatzemar i identificar unívocament cadascuna de les transaccions eco-
nòmiques que s'esdevenen a l'entorn web.
L'element ("motor") que fa possible la compravenda en l'entorn web són

les bases�de�dades.
Es desprèn, doncs, que les bases�de�dades són la tecnologia de gestió de la

informació que necessitem, ja que ens permeten d'integrar les dades i alhora
compartir-les entre múltiples usuaris.
Un cop justificat l'ús de la tecnologia que cal emprar, ara veurem en quin
context se situen les aplicacions B2C i la informació que han de gestionar.
1.1. Escenari d'una aplicació de comerç electrònic B2C
Hi ha diferents tipus de comerç electrònic. En aquest mòdul didàctic ens cen- Vegeu també
trarem en el comerç electrònic B2C que fàcilment introdueixen els dos agents
Per a més informació sobre
principals: l'empresa (B) i el client (C). Per tant, podem veure el comerç elec- el B2C (Business to Consu-
trònic B2C com la relació que s'estableix entre el client i l'empresa durant el mer) i altres classificacions
del comerç electrònic, vegeu
procés de compra. l'apartat "Tipus de comerç
electrònic" del mòdul didàctic
"Introducció al comerç electrò-
nic".
Atès que aquesta relació es produeix entre dos agents, l'analitzarem des dels
dos punts de vista, primerament des de la perspectiva de l'empresa i després
des del punt de vista del client.
1.1.1. B2C des del punt de vista de l'empresa
Un dels objectius principals d'una empresa és la venda dels seus pro-

ductes.
Una aplicació per a vendre productes en l'entorn web ha de ser capaç de ges- Nota
tionar el catàleg de productes i facilitar-ne el manteniment. Això implica que
Per simplificar, el terme pro-
haurà de permetre donar d'alta productes, modificar-ne les característiques ducte l'utilitzarem indistinta-
(preu, descripcions, estoc), eliminar-los del catàleg i consultar la disponibilitat ment per a referir-nos a pro-
ductes i serveis.
d'existències en tot moment.
Per a poder vendre el nombre més gran de productes, el venedor ha de

poder oferir-los al nombre de clients més gran possible. La millor manera
d'aconseguir-ho serà que la web pugui mostrar tota la informació relativa als
productes a diversos països i, per tant, en diferents idiomes i expressant les
quantitats monetaries amb la moneda de cada país.
A més, un punt important per al venedor és la part de la transacció en què

es fa el pagament del producte. La importància del sistema de pagament en
les aplicacions de comerç electrònic fa necessari un tractament més exhaustiu
que s'estudia en el mòdul didàctic "Sistemes de pagament electrònic".
Un altre requisit que ha de satisfer l'aplicació B2C, per a donar suport a la

venda de productes, és mantenir el registre de les comandes realitzades pels
clients. Ha de ser possible, doncs, emmagatzemar les dades d'enviament i de
pagament per a cada client al mateix temps que enregistrar les referències dels
productes sol·licitats, la quantitat demanada de cadascun d'ells i el seu preu.
D'altra banda, pot resultar interessant conèixer altres dades relacionades amb
les comandes, com, per exemple, la data en què s'ha confeccionat la comanda,
el temps emprat a realitzar-la, el tipus de navegador utilitzat, etc.
Un cop l'aplicació cobreix les necessitats de gestió de productes, comandes i

clients, l'empresari es pot plantejar de demanar suport a l'aplicació per a ex-
traure informació que l'ajudi en l'estratègia de l'empresa.
Per exemple, pot ser útil disposar d'informació referent a les preferències dels seus cli-
ents i altres visitants, ja que, així, el venedor podrà adaptar la política de màrqueting de
l'empresa amb més garanties d'èxit.
Un altre exemple podria ser que l'empresa utilitzés aquesta informació per a segmentar
el mercat i, en conseqüència, poder oferir condicions especials per a diferents tipus de
clients (descomptes, promocions, etc.) i personalitzar el tracte amb el client.
1.1.2. B2C des del punt de vista del client
Per la banda del client, l'objectiu primordial és utilitzar la xarxa per a

poder comprar de manera ràpida, còmoda i segura.
El comerç electrònic ha de permetre al client de localitzar ràpidament i

d'una manera senzilla el producte que més s'ajusta a les seves necessitats. És
l'aplicació B2C la que ha de possibilitar prou flexibilitat quant a criteris de
cerca i, alhora, ha de facilitar l'elecció de productes, mostrant aquelles carac-
terístiques que ajudin el consumidor en la tria.
Un cop decidit el producte o productes d'interès, el client espera gestionar

fàcilment la seva comanda. Per tant, l'aplicació B2C ha de permetre d'afegir
productes, eliminar-los i modificar-ne les quantitats que es desitja comprar.
No solament això, sinó que també li cal obtenir una referència que identifiqui
la seva comanda, bé per raons de seguiment de la compra, o bé per a possibles
reclamacions.
Un cop feta la comanda, el comprador ha de realitzar el pagament. Les propi-

etats de seguretat que ha de tenir aquest pagament estan descrites en el mòdul
didàctic "Seguretat en el comerç electrònic" i la descripció acurada dels dife-
rents sistemes de pagament electrònic la trobareu en el mòdul didàctic "Siste-
mes de pagament electrònic".
Si el client està satisfet de compres anteriors, pot interessar-li registrar-se. El

fet de registrar-se li permetrà de fer més senzill el procés de confecció de co-
mandes posteriors, i així evitarà haver de tornar a introduir les seves dades
que són comunes a totes les comandes. El registre d'un client pot reportar-li
encara més avantatges, ja que l'aplicació el reconeixerà a partir del moment
que s'hagi registrat i, per tant, li podrà presentar ofertes més adaptades a les
seves preferències.
1.2. Informació operativa enfront d'informació d'ajut a la presa

de decisió
Si ens fixem en l'escenari descrit en els subapartats anteriors, veiem que

qualsevol empresa que opera per mitjà d'Internet gestiona un gran volum
d'informació. Podem, doncs, distingir dues grans categories: informació per a
les operacions de l'empresa i informació d'ajut a la presa de decisions.
La informació necessària per a la venda i catalogació de productes és la

informació�operativa de l'empresa.
(1)
Organitzarem la informació operativa en una base de dades convencional, que En anglès, entity relationship.
anomenarem base�de�dades�operativa. Aquesta base de dades es dissenyarà
segons el model entitat interrelació1 (ER) i utilitzant la tecnologia que oferei-
xen les bases de dades relacionals.
La informació útil per a prendre decisions estratègiques és la que ano-

menarem informació�d'ajut�a�la�presa�de�decisions o informació�es-
tratègica.
Per a aquest altre tipus d'informació, l'organització de les dades serà diferent
a la de la base de dades operativa, ja que la seva finalitat també és una altra.
Estem parlant de la base de dades estratègica o data�warehouse.
El fet d'aprofitar dades generades durant el temps de vida del negoci i utilit-
zar-les per a temes més estratègics i de personalització de tracte amb el client
no és nou. En les aplicacions B2C el fet que no hi hagi presència implica que
es coneix els clients exclusivament a partir de les dades històriques de les seves
compres, raó per la qual és fonamental tenir-les emmagatzemades.
En resum, doncs, les aplicacions de comerç electrònic mantenen

paral·lelament dues bases de dades: l'operativa i l'estratègica (data warehouse).
2. Base de dades operativa
En aquest segon apartat ens centrarem en l'estudi de tota la informació que

intervé en el procés de comerç electrònic des del punt de vista del conjunt
d'operacions de l'empresa.
Inicialment, estudiarem un petit exemple de transacció econòmica via web,

per comprendre millor quina és la informació que emmagatzemarà aquesta
base de dades. Després, tenint en compte l'escenari de l'aplicació B2C en el seu
vessant operatiu, dissenyarem la base de dades i determinarem quines opera-
cions són útils per a aquest entorn.
2.1. Agents d'una transacció econòmica
Començarem mostrant un possible procés de compra per mitjà de la web.
Aquest procés de compra electrònica, ens permetrà d'analitzar una seqüència

de passos, entre client o comprador i venedor (botiga o empresa), que ha de
conduir a la fi de la transacció econòmica.
La figura següent mostra la seqüència d'una transacció econòmica de compra-

venda:
Figura 1
La descripció dels passos de la compravenda és la següent:

Un cas possible
1. El client accedeix a la botiga virtual.
L'exemple, que tot seguit mos-
2. El venedor permet la visualització del seu catàleg de productes segons trem, no l'hem de prendre
com a model, ja que depenent
uns criteris de selecció. del tipus d'empresa admetrà
unes variants o unes altres.
L'hem de veure, tan sols, com
3. El client visualitza els productes d'acord amb un dels criteris de selec- un possible procés de compra.
ció, el que més s'ajusti a les seves necessitats.
4. El client confecciona la seva comanda.
5. El venedor presenta el desglossament de la comanda.
6. El client confirma les dades de la comanda.
7. El venedor sol·licita dades al client: d'enviament, contacte, etc.
8. El client complementa els formularis de dades.
9. El venedor comprova que les dades del client siguin vàlides.
10. El client fa el pagament.
11. El venedor envia la comanda al comprador.
La seqüència anterior ajudarà a identificar tots els agents que hi intervenen i

la manera en què interaccionen.
Fixeu-vos que, en principi, hi intervenen dos agents (CLIENT, VENEDOR) i Vegeu també
diversos tipus i fluxos d'informació (dades de productes, comandes, pagament,
En el mòdul "Sistemes de pa-
etc.). gament electrònic" tractarem
de manera exclusiva el pas 10
de la figura anterior, en què el
De la figura 1, també en resulta clar que el desglossament de la seqüència client fa el pagament, i veurem
que en aquest pas s'afegeixen
s'ha realitzat depenent de l'agent que genera un nou flux a cada pas. Trobem altres agents com poden ser
un o dos bancs i passarel·les de
l'explicació en el fet que la transacció econòmica és suportada per un entorn pagament.
client-servidor.
Tampoc és difícil veure que la base de dades té un paper fonamental en aquest

escenari, ja que cal emmagatzemar les dades que es van generant al llarg de
tot el procés i, alhora, ha de ser possible identificar-les de manera que es pugui
veure el procés de compra com a ens únic.
2.2. Disseny de la base de dades
L'objectiu d'aquest segon apartat és dissenyar la base de dades operativa del

venedor. Tal com hem vist en l'apartat anterior, els tres agents que ens interes-
sen són el venedor, per al qual fem el model de dades, el client, que és la
peça clau del model, i les entitats�bancàries, agents intermediaris que inter-
venen puntualment en el procés de pagament i de les quals no pretenem fer
cap model de dades.
Vegeu també
Per tal de dissenyar la base de dades operativa utilitzarem els principis
de disseny d'una base de dades, el model ER i la seva transformació a El disseny de la base de da-
des operativa es farà seguint
relacional. la metodologia de disseny de
bases de dades estudiada a
l'assignatura Bases de dades I.
Si bé aquestes metodologies són necessàries i imprescindibles per a abor-

dar amb èxit un bon model de dades, no hem d'oblidar que, en aplicacions
d'envergadura com les B2C, un bon disseny va precedit d'un bon anàlisi de
requeriments. Aquesta anàlisi ens ajudarà a identificar tots aquells aspectes
que s'han de modelar i que cal tenir en compte en el moment de triar les es-
tructures de dades capaces de suportar tots els requisits.
És un fet que totes les empreses comparteixen gran part del model de dades,
aproximadament un 50%, ja que la manera d'operar de totes aquestes es for-
ça comuna. En el cas que ens ocupa, empreses que venen els seus productes
per mitjà d'Internet (B2C), aquesta similitud pot arribar a ser superior al 75%,
fet que ens deixa un marge ben reduït per a variar el model de dades i fer-lo
exclusiu per a una empresa en concret.
2.2.1. Disseny conceptual
L'objectiu de l'etapa de disseny conceptual és obtenir una estructuració

de la informació independentment de la tecnologia que cal emprar.
Per això, modelarem les dades que intervenen en l'escenari de les aplicacions
B2C fent servir el model ER. El diagrama ER ens ajudarà a entendre el perquè
de certes relacions i atributs, atès que la raó de ser d'algun d'aquests es donarà
per la mateixa manera d'operar empresarial.
De manera general, hem vist que, en el tipus d'aplicacions que estem consi-
derant, els clients, per mitjà de la web, compren productes i que el mecanis-
me habitual per a encomanar els productes és mitjançant la confecció d'una
comanda. Per tant, resulta fàcil entendre que intervinguin en el model con-
ceptual les entitats següents: PRODUCTES, CLIENTS i COMANDES. Com que
l'escenari descrit en l'apartat anterior és força més complex, desenvoluparem
el diagrama ER a partir d'aquestes entitats assenyalades com a rellevants.
Figura 2. Model conceptual de dades de la base de dades operativa
Observeu en el diagrama ER que l'entitat IDIOMA és la que s'interrelaciona amb un nombre d'entitats més gran.
Si ens fixem en el diagrama ER de la figura 2, a primer cop de vista, es desprèn

que l'entitat IDIOMA té un paper tan destacat, o més, com les altres tres enti-
tats abans esmentades.
Les aplicacions B2C han de permetre la venda de productes a diferents

països i, per tant, tots aquells atributs que contenen un valor textual
que s'hagi de mostrar a la web s'hauran d'emmagatzemar en diferents
idiomes.
Com que la base de dades ha de guardar cada descripció en més d'un idioma
i un dels principis del bon disseny de les bases de dades consisteix a evitar la
redundància de dades, s'ha fet necessari considerar noves entitats per a guardar
una única vegada cada descripció en cada idioma.
Tal com s'ha comentat abans, el diagrama ER és la representació d'un model

conceptual de dades genèric per l'escenari en què ens trobem. L'estudiarem
centrant-nos en cadascuna de les entitats principals identificades (CLIENT,
PRODUCTE, COMANDA i IDIOMA) i les seves interrelacions amb la resta
d'entitats.
Client
Per a aconseguir un dels objectius de l'aplicació B2C, que és oferir la màxima

facilitat de compra als clients, se'ls permet de confeccionar la seva comanda
sense demanar-los cap tipus d'informació fins al moment de confirmar-la. Per
a permetre aquest funcionament, s'ha de distingir entre clients registrats i no
registrats.
Clients no registrats
Els clients no�registrats compren sense que l'aplicació els reconegui, per
tant, malgrat que comprin diverses vegades, es consideren com si fossin Per aquest motiu, el client hau-
rà d'introduir les seves dades
clients diferents. personals i d'enviament cada
vegada que confeccioni una
comanda.
Els clients registrats són aquells dels quals la base de dades conté la in-
formació següent: dades personals, dades sobre el seu historial de com-
pres i dades addicionals per a identificar-lo en cas que oblidi el seu codi
secret.
L'avantatge per a l'usuari registrat és que podrà estalviar-se d'omplir els formu-
laris corresponents a les dades personals i d'enviament en el procés de compra
i que el sistema, en identificar-lo, li pot oferir ofertes depenent de les seves
preferències.
Atès que els clients poden ser d'un d'aquests dos tipus, registrats i no regis-
trats, sembla lògic que conceptualment es representi mitjançant una jerarquia
d'especialització-generalització disjunta i total.
Dels clients registrats, és interessant que l'aplicació pugui tenir en compte Classificació dels clients
les seves preferències. Aquesta informació, pel fet de ser estratègica, també
Es podrà classificar els clients
s'emmagatzemarà en la base de dades estratègica. En la base de dades operaci- segons diferents agrupacions,
onal normalment guardarem informació sobre clients que servirà per a establir per exemple, preferents i no
preferents, per pertànyer a una
una classificació de clients per tipus i oferir-los, així, descomptes per a grups determinada associació, etc. El
sistema permetrà d'oferir des-
o col·lectius. Si la manera d'operar de l'empresa té en compte aquesta classifi- comptes personalitzats a cada
agrupació.
cació i volem evitar la redundància de dades, haurem de separar en el mòdul
conceptual de dades l'atribut tipus de client de la resta d'atributs del client, que
són específics de cadascun. D'aquí la necessitat de l'entitat TIPUS CLIENT que
conté els atributs que comparteixen tots els clients d'un mateix tipus.
La interrelació ASSOCIACIÓ representa el fet que els clients estan classificats

per tipus. Fixeu-vos que és una interrelació M-N; això vol dir que és possible
que un client pertanyi a diversos tipus de client alhora i, com que el nombre
de clients que ha de permetre la base de dades no ha de ser restrictiu, ans el

contrari, s'ha de tenir en compte la possibilitat que diversos clients puguin ser
d'un mateix tipus.
D'altra banda, com que la base de dades ha de contenir informació en diver-

sos idiomes i cal que les descripcions dels diferents tipus de clients estiguin
en els diferents idiomes, és normal que l'entitat TIPUS CLIENT es relacioni
amb l'entitat IDIOMA. En un mateix idioma tindrem la descripció de cadas-
cun dels tipus de client possibles i es podrà descriure un mateix tipus de client
en diferents idiomes. Veiem, doncs, que per aquest motiu hi ha la interrelació
DESC_TIP_CLI entre IDIOMA i TIPUS CLIENT, que és M-N.
Figura 3
PRODUCTE
L'entitat PRODUCTE representa els diferents productes que formen part

d'un catàleg de productes i, per tant, que l'empresa ven. Aquesta entitat
emmagatzemarà els atributs que descriuen les característiques de cada
producte amb independència de l'idioma.
Com que l'aplicació ha d'oferir la màxima flexibilitat als clients per a localitzar
el producte que desitgen, cal que els productes, de la mateixa manera que hem
fet amb els clients, es puguin classificar atenent a característiques comunes.
A l'entitat TIPUS PRODUCTE es guarden totes les dades comunes a tots els
productes d'un mateix tipus, i aquesta entitat s'interrelaciona amb PRODUCTE
mitjançant la interrelació PERTÀNYER.
La interrelació PERTÀNYER associa els productes amb els tipus de productes i

és M-N, ja que d'un tipus de producte existeixen diversos productes d'aquest
tipus i un producte específic es pot catalogar en diversos tipus de producte.
Alhora, com que el client ha de poder localitzar les dades d'un producte segons
diversos criteris de cerca, cal possibilitar diferents formes d'accés Per aquesta
raó, cal que els diferents tipus de producte es puguin relacionar els uns amb
els altres, de manera que sigui possible establir-hi relacions, de producte més
genèric o més especialitzat. D'aquí la interrelació reflexiva CLASSIFICACIÓ,
que també és M-N, i amb opcionalitat a les dues bandes, ja que per cada parella
de tipus de producte hi pot haver relació o no amb altres instàncies de tipus
de producte.
Exemple de classificació per tipus de producte
Si el producte que cal vendre fos un llibre que vingués identificat pel seu International
Standard Book Number (ISBN), també es podria classificar per àmbit temàtic. De més ge-
neral a més específic, podríem catalogar-lo com a llibre tècnic; dins dels llibres tècnics
estaria en l'àmbit de la informàtica i més concretament en una àrea de coneixement dins
de la informàtica, posem per cas, les bases de dades.
Com que les dades referents a productes hauran d'aparèixer tant en el catàleg
que es presenta al client com en la comanda, caldrà que tots aquells atributs
de producte que siguin de tipus text i s'hagin de presentar en diferents idiomes
se separin de l'entitat PRODUCTE, evitant així redundància de dades.
És per aquest motiu que en el diagrama ER hi ha la interrelació DESC_PROD

amb grau M-N, ja que permet de modelar el fet que un producte es pot descriu-
re en diversos idiomes i que en un idioma es pot descriure més d'un producte.
Si volem emmagatzemar diverses descripcions d'un producte, posem pel cas,
una descripció resumida, una detallada i una altra cara a la publicitat, aquests
atributs serien atributs de la interrelació DESC_PROD.
Anàlogament al que hem comentat per als tipus de client, els tipus de producte
també tenen una descripció que interessa emmagatzemar en els diversos idi-
omes. Per tant, la interrelació DESC_TIP_PROD estableix la interrelació entre
TIPUS PRODUCTE i IDIOMA. Justament, com a atribut d'interrelació tindríem
la descripció del tipus de producte en l'idioma que correspongui, i els atributs
comuns a tots els productes del mateix tipus que no calgués traduir anirien a
l'entitat TIPUS PRODUCTE.
Figura 4
COMANDA
La comanda és precisament el nexe entre CLIENT i PRODUCTE, ja que,

un cop el client ha seleccionat els productes que desitja, els demana
formulant la comanda. De la comanda, n'hem d'emmagatzemar moltes
dades, per això sembla lògic representar-la com a entitat en lloc de fer-
ho com a interrelació entre CLIENT i PRODUCTE.
Una comanda tindrà, a més de les dades dels productes seleccionats, les da- Clients registrats
des de facturació (a qui enviar la factura) i d'enviament (a qui s'envien els
En el cas de clients registrats es
productes de la comanda). Aquestes dades les guardarem en una altra entitat podran recuperar les dades de
FACTURA_ENVIAMENT que s'interrelacionarà amb COMANDA en grau 1-N. facturació i enviaments de co-
mandes anteriors.
Si considerem que la COMANDA la CONFECCIONA un client i que un client

pot fer moltes comandes o cap (en el cas que s'enregistri, però no compri),
tenim una interrelació 1-N amb opcionalitat al cantó N.
Tal com hem esmentat abans, la comanda conté molta informació i, com és
habitual, distingim entre capçalera�de�la�comanda i línia�de�comanda.
Les dades de la comanda s'emmagatzemen en diverses entitats: CO-

MANDA, FACTURACIO_ENVIAMENT i LINIA_COMANDA.
La informació que s'emmagatzema a l'entitat FACTURACIO_ENVIAMENT

conté dades sobre el destinatari dels productes demanats (no ha de coincidir
necessàriament amb el client, imaginem que es tracta d'un regal), i també da-
des de facturació (a qui se li envia la factura de la comanda). La capçalera de la
comanda emmagatzema dades sobre el pagament, opció d'enviament, etc. La
comanda ES-COMPON de moltes línies de comanda. Cada línia és la petició
d'un producte en una comanda, per tant, la podíem haver representat com
a interrelació entre comanda i producte. Però si considerem que l'existència
d'una línia de comanda està condicionada al fet que existeixi la comanda, po-
dem representar-la com a entitat dèbil.
L'entitat LINIA_COMANDA és relaciona amb PRODUCTE per la interrelació

REFERIR_SE, ja que una línia de comanda sempre es refereix a un producte
(referència, preu unitari, nombre d'unitats, etc.) i un producte pot figurar en
diverses línies de comanda o en cap; per tant, es tracta d'una interrelació 1-N
amb opcionalitat al cantó N. D'aquesta manera, es reflecteix la relació que hi
ha entre PRODUCTE i COMANDA.
Dins l'argot que s'utilitza en el món web, la comanda correspondria al "carro, bossa o
cistell d'anar a comprar" que tots estem acostumats a veure en les botigues virtuals i cada
producte dins el "cistell" correspondria a una línia de comanda.
Un altre cop, hem de considerar l'efecte que té la diversitat d'idiomes sobre les
dades de la comanda que tenen valors textuals diferents per a cada idioma.
Caldrà mostrar la informació sobre l'estat de la comanda en l'idioma del Estat de la comanda
client i, per tant, convé tenir-la deslligada de la capçalera de la coman-
L'estat de la comanda indica
da. Com que hi pot haver moltes comandes en un mateix estat i una co- en quin punt del procés de
manda en tot moment té un únic estat, la interrelació entre COMANDA i compra es troba. És interessant
que el client el pugui consultar
ESTAT_COMANDA és 1-N. La mateixa consideració serveix per a les dades re- en qualsevol moment, per sa-
ber si encara està pendent, re-
ferents a la forma d'enviament (FORMA_ENVIAMENT) i a la forma de paga- tingut, en procés, etc.
ment (FORMA_PAGAMENT). Totes aquestes entitats que contenen informació
descriptiva de la comanda depenent de l'idioma es relacionarien amb l'entitat
IDIOMA amb grau N-M, tal com hem vist prèviament en descriure l'entorn de
les entitats CLIENT i PRODUCTE.
Figura 5
IDIOMA
A l'entitat idioma s'emmagatzemarà el codi d'idioma amb la seva des-

cripció en un idioma de referència.
Qualsevol entitat que estigui relacionada amb idioma mitjançant una interre-
lació M-N contindrà els atributs d'interrelació que són la descripció de l'atribut
en qualsevol idioma.
Codificació d'idiomes
Codificació d'idiomes
Suposem l'entitat ESTAT_COMANDA que pot tenir tres estats possibles –pendent, en pro-
cés i retinguda, codificats respectivament pels codis 10, 20 i 30. Aleshores, la interrelació Una possible codificació
DESC_ESTAT contindria per a cada idioma la traducció de cadascun dels valors possibles d'idiomes podria ser:
de l'atribut que descriu l'estat. Per a l'estat 10 en l'idioma 0 (català), el valor de l'atribut 0 Català
seria "pendent", per a l'idioma1 (castellà), "pendiente" i per a l'idioma 02 (anglès) "pending"; 1 Castellà
per a l'estat 20 en l'idioma 0 el valor associat seria "en procés", en l'idioma 1 "en proceso" 2 Anglès
i en l'idioma 2 "processing", etc. 3 Francès
...
2.2.2. Disseny lògic
Per a obtenir el disseny�lògic de la base de dades operativa partirem del

model conceptual genèric presentat i el transformarem perquè s'adapti
a la tecnologia que s'hagi d'emprar.
En el nostre cas farem servir les bases de dades relacionals, per tant, en aquesta Vegeu també
etapa obtindrem un conjunt de relacions amb els seus atributs, claus primàries
Vegeu l'apartat "Disseny lògic:
i foranes. la transformació del model ER
al model relacional" del mòdul
"Introducció al disseny de base
Traduirem el model conceptual per parts, considerant l'entorn de les entitats de dades", de l'assignatura Ba-
ses de dades I.
destacades (CLIENTS, PRODUCTE, COMANDA i IDIOMA).
CLIENT
Les relacions obtingudes a partir de la transformació relatives a clients són les

següents:
CLIENT (id_client)
CLIENT_REGISTRAT (id_client, nif, nom, cognoms, email,

contrasenya, pregunta, resposta, data_naixement,
estat_civil, data_primera_compra, data_darrera_compra
import_acumulat_compres , nombre_compres, baixa_logica)
on {email} és clau alternativa
on {id_client} referencia CLIENT
CLIENT_NO_REGISTRAT (id_client)
on {id_client} referencia CLIENT
TIPUS_CLIENT (id_tipus_client, dte)
DESC_TIP_CLI (id_tipus_client, id_idioma,

descripcio_tipus_client)
on {id_tipus_client} referencia TIPUS_CLIENT i
{id_idioma} referencia IDIOMA
ASSOCIACIO (id_client, id_tipus_client)

on {id_client} referencia CLIENT i
{id_tipus_client} referencia TIPUS_CLIENT
Observem que la relació CLIENT NO REGISTRAT no aporta més informació ad-

dicional de la que aporta la relació CLIENT i, per tant, a nivell lògic en podem
prescindir. Si en algun moment s'hagués d'emmagatzemar alguna dada que no
conté l'entitat CLIENT_REGISTRAT aleshores tindria sentit considerar-la.
Observeu que la relació CLIENT, malgrat tenir un únic atribut, no l'eliminem

perquè els clients no registrats també poden comprar i, per tant, poden fer
comandes.
També és interessant notar que, en la relació TIPUS_CLIENT, no hi tenim la

descripció del tipus de client, ja que per a un mateix codi de client tindríem
diverses descripcions, una per a cada idioma. La descripció del tipus de client
està a la interrelació DESC_TIP_CLI, de manera que assegurem que hi hagi una
única descripció per a cada tipus de client i idioma.
Gràficament podem veure aquesta part del disseny lògic tal com es mostra a
continuació:
Figura 6
PRODUCTE
Les relacions obtingudes a partir de la transformació relatives a productes són

les següents:
PRODUCTE (id_producte, preu_actual, es_oferta,

preu_oferta, estoc_inicial, estoc_actual, estoc_notificacio)
TIPUS_PRODUCTE (id_tipus_producte, dte)
DESC_TIP_PROD (id_tipus_producte, descripció, id_idioma)

on {id_tipus_prod} referencia TIPUS_PRODUCTE i
CLASSIFICACIO (id_classid, id_tipus_generic, id_tipus_especific)

on {id_tipus_prod_generic} referencia TIPUS_PRODUCTE i
{id_tipus_prod_especific} referencia TIPUS_PRODUCTE
DESC_PROD (id_producte, id_idioma, descripcio_curta,

descripcio_llarga)
on {id_producte} referencia PRODUCTE i
PERTANYER (id_producte, id_tipus_producte)

on {id_producte} referencia PRODUCTE i
{id_tipus_producte} referencia TIPUS_PRODUCTE
Observeu que, tal com passava amb la descripció tipus de client, la diversitat
d'idiomes fa que s'hagin de relacionar els productes (PRODUCTE) o tipus de
productes (TIPUS_PRODUCTE) amb les descripcions per a cada idioma, fet que
dóna lloc a les respectives DESC_PROD i DESC_TIP_PROD.
Podeu veure la representació gràfica d'aquesta part del disseny lògic a conti-
nuació:
Figura 7
COMANDA
Les relacions obtingudes a partir de la transformació relativa a comanda són

les següents:
FACTURA_ENVIAMENT (id_fact_env, nif, nom, cognoms,

adreça, població, codi_postal, país, telèfon, fax
email, nomenv, cognomsenv, adreçaenv,
poblacioenv, codi_postalenv, paisenv)
ESTAT_COMANDA (id_estat)
FORMA_ENVIAMENT (id_enviament)
FORMA_PAGAMENT (id_pagament)
COMANDA (id_comanda, id_client, id_fact_env, total_comanda,

data_comanda, hora_inici_compra,
hora_fi_compra, adre_ip_compra,
id_estat,num_transaccio, data_transaccio,
id_resultat_tansaccio, id_pagament, id_enviament,
data_lliurament, hora_lliurament)
on {id_estat} referencia ESTAT_COMANDA,
{id_enviament} referencia FORMA_ENVIAMENT,
{id_pagament} referencia FORMA_PAGAMENT
LINIA_COMANDA (id_linia, id_comanda, id_producte, descripcio,
unitats, preu_unitari_brut, dte, preu_net)
on {id_producte} referencia PRODUCTE,
{id_comanda} referencia COMANDA.
DESC_ENV (id_enviament, id_idioma, descripcio)

on {id_idioma} referencia IDIOMA
DESC_ESTAT (id_estat, id_idioma, descripcio)

DESC_PAG (id_pagament, id_idioma, descripcio)

Anàlogament al que hem observat per a les descripcions referents a clients i

productes, succeeix el mateix per a altres atributs de comanda, com ara l'estat,
el mode d'enviament i el de pagament, que se separen de les dades de la co-
manda perquè les descripcions constin a la base de dades una única vegada
per idioma.
Observeu que, a la relació COMANDA, hi guardem l'id_client, que tant pot

referir-se a un client anònim no registrat (CLIENT) com a un client registrat.
A continuació mostrem la representació gràfica del disseny lògic referent a les

comandes.
Figura 8
IDIOMA
Les transformacions referents a l'entitat IDIOMA han anat apareixent en fer

les transformacions del disseny conceptual, considerant l'entorn de CLIENT,
PRODUCTE i COMANDA. Per tant, ens queda únicament la relació IDIOMA,
que constarà dels atributs id_idioma i descripció (expressats en l'idioma de
referència).
IDIOMA (id_idioma, descripcio)
2.2.3. Disseny físic
L'etapa de disseny físic té com a objectiu el bon rendiment de la base

de dades. Per a això, cal transformar el disseny lògic per a obtenir més
eficiència i, a més, tenir en compte certs aspectes d'implementació física
que depenen del sistema de gestió de la base de dades (SGBD).
Com que nosaltres no fixem cap SGBD, sinó que donem orientacions generals,
aquesta etapa no la desenvoluparem. Únicament, després d'haver detallat els
processos que consulten i actualitzen les dades i sabent els camins d'accés que
s'utilitzaran, i també les freqüències d'execució, podrem desenvolupar aquesta
etapa per un marc de referència concret.
2.3. Manipulació de dades
En aquest apartat ens centrarem en les operacions bàsiques de manipulació de

dades que permetran, de manera còmoda i eficaç, el funcionament d'aquesta
base de dades. Per tant, estudiarem les operacions que cal fer sobre la base de
dades operativa, i ho farem fixant-nos en els agents que hi intervenen (tal com
vàrem fer en l'etapa de disseny), i també en els paràmetres d'entrada i sortida
d'aquestes operacions.
Les diferents operacions que es mostraran s'indicaran mitjançant el nom de

l'operació seguida de la llista de paràmetres d'entrada entre parèntesis, i els pa-
ràmetres de sortida o accions que realitzi l'operació s'explicaran a continuació,
però no apareixeran a la signatura de l'operació, per tal que siguin adaptables
a diferents implementacions.
Distingirem dos tipus d'operacions depenent de l'entorn on s'executin:

les operacions que es fan per mitjà de la xarxa�pública, és a dir, aquelles
que es realitzaran a petició del client des d'Internet, i les operacions que
es fan per mitjà de la xarxa�interna (intranet) per part de la pròpia em-
presa, és a dir, aquelles operacions restringides a usuaris amb privilegis.
Dels diferents mecanismes dels quals disposa una base de dades per a gesti- Vegeu també
onar la informació (vistes, procediments emmagatzemats i disparadors), bà-
Per a més informació sobre
sicament n'utilitzaren els procediments, i, en alguns casos, els disparadors. aquests conceptes vegeu
Les vistes no s'utilitzen perquè la majoria d'operacions requereixen paràmetres l'apartat "Components de
Control" del mòdul "Compo-
d'entrada. nents lògics d'una base de da-
des de Bases de dades II.
També hem de tenir en compte que certes operacions s'han de fer com a unitat Vegeu també
bàsica de treball a efectes de concurrència i integritat. Per exemple, una alta
Vegeu el mòdul "Transaccions
de producte implica la inserció a dues taules, la taula de PRODUCTES i la taula en les bases de dades", del ma-
DESC_PROD i, en conseqüència, caldrà definir una transacció que contingui terial didàctic de Bases de da-
des II.
ambdues operacions i asseguri la consistència de la base de dades.
2.3.1. Catàleg de productes
El catàleg és l'exteriorització en format web dels productes que el vene-

dor ofereix als seus clients per mitjà d'operacions de consulta.
El venedor s'encarregarà del manteniment del catàleg de productes, per tant,

haurà de disposar d'operacions que el mantinguin actualitzat.
Manteniment�del�catàleg�de�productes
Totes les operacions de manteniment (altes/baixes/modificacions) es realitza-

ran, per part de l'empresa, des de l'entorn restringit (intranet).
1) Altes
alta_producte_desc (id_producte, id_idioma, descripcio_curta,

descripcio_llarga)
alta_producte_atribut (preu_actual, es_oferta, preu_oferta,

estoc_inicial, estoc_actual, estoc_notificacio)
Aquestes dues operacions permeten d'inserir les dades d'un producte (caracte- Exemples d'altes d'un
rístiques i descripcions) en el catàleg. La primera operació fa una inserció a la producte
taula DESC_PROD afegint les descripcions referents al producte en un idioma. alta_producte_atribut (30, 1,
25, 100, 100, 10)
Dóna d'alta el producte amb
La segona operació afegeix, a la taula PRODUCTE, les dades que són indepen- preu 30 euros, en oferta, amb
preu d'oferta 25 euros, amb
dents de l'idioma. Noteu que són necessàries ambdues operacions per a fer
estoc inicial i actual de 100
efectiva l'alta d'un producte i que s'hauran d'executar en una única transacció. unitats i amb estoc de notifica-
ció de 10 unitats.
altra_producte_desc (56, 1,
A continuació veurem operacions que permetran de jerarquitzar els diferents ‘sql server 2000', ‘microsoft sql
server 2000 claro y conciso)
tipus de productes de més genèrics a més específics. Dóna d'alta les descripcions
curta i llarga del producte amb
id_producte 56 i amb el codi
id_idioma 1.
alta_tipus_producte_desc (id_tipus_producte,id_idioma,descripcio,dte)
alta_classifica_producte (id_tipus_generic, id_tipus_especific)

L'operació alta_tipus_producte_desc permet de donar d'alta tipus de productes

en l'idioma corresponent. Aquesta operació tindrà doble funcionalitat: alta de
tipus de productes nous amb el seu descompte i alta d'una nova descripció per
un tipus de producte donat.
Exemple d'altes
alta_tipus_producte_desc (101, 0, ‘informàtica')

alta_tipus_producte_desc (102, 0, ‘biologia')
alta_tipus_producte_desc (103, 0, ‘sistemes operatius'))
alta_tipus_producte_desc (104, 0, ‘sistemes gestors de bases de dades')
Suposem que el sistema els assigna els id_tipus_producte 101, 102 i 103 i 104 respecti-
vament
alta_classifica_producte (NULL,101)
alta_classifica_producte (NULL,102)
alta_classifica_producte (101,103)
alta_classifica_producte (101,104)
Aquestes operacions afegiran dos tipus de productes (informàtica i biologia) al nivell su-
perior de la jerarquia (que s'indica amb el id_tipus_genèric igual a 0). Després s'han donat
d'alta dos tipus de producte: sistemes operatius (id_tipus_producte 103) i sistemes gestors
de bases de dades (id_tipus_producte 104) que tenen com a grup genèric informàtica.
2) Baixes
Exemple de baixes
baixa_producte (id_producte)
baixa_producte (56), dona-
rà de baixa el producte amb
id_producte 56 sempre i quan
L'operació baixa_producte permetrà d'eliminar el producte del catàleg. ho permetin les restricions
d'integritat referencial.
D'una banda, suprimirà el registre de la taula PRODUCTE corresponent al
id_producte especificat i de l'altra, suprimirà les descripcions associades al pro-
ducte en els diferents idiomes. Exemple de modificació
modifica_producte_desc
3) Modificacions (56,1,‘sql server 2000', ‘micro-
soft sql server 2000 claro y fia-
ble)
modifica_producte_atribut
modifica_producte_desc (id_producte, id_idioma descripcio_curta, (56, 32, 1, 28, 100, 100, 10)
descripcio_llarga)
modifica_producte_atribut (id_producte, preu_actual, es_oferta,

preu_oferta,estoc_inicial, estoc_actual,
estoc_notificacio)
De la mateixa manera que en el cas de les altes, necessitarem dues operacions

per a modificar la informació relativa a un producte.
Fixeu-vos que en les operacions de modificació s'hauran de passar per parà-

metre tots els atributs, canviïn o no de valor.
alta_producte_tipus (id_producte, id_tipus)
baixa_producte_tipus (id_producte, id_tipus_producte)
Aquestes dues operacions permetran de gestionar la classificació del producte,

de manera que el producte es pugui catalogar dins d'un agrupament o altre,
segons convingui.
Com que totes les operacions de manteniment requereixen paràmetres

d'entrada, s'implementaran mitjançant procediments�emmagatzemats.
Consultes�del�catàleg�de�productes
Totes les operacions de consulta sobre el catàleg es faran en l'entorn de la xarxa

pública.
Exemple
productes_tipus (id_tipus_producte, id_idioma)
Aquesta operació permetrà d'obtenir les dades dels productes a partir d'algun
dels seus agrupaments i de l'idioma corresponent. Per tant, el resultat d'aquesta
operació retorna un conjunt de registres (recordset). En idioma català (codi 0) i en el cas dels
llibres d'informàtica-sistemes operatius
(codi 103), la crida seria productes_tipus
(103,0) i el retorn del procediment seria
el conjunt de registres (recordset) que
Per a poder sol·licitar els productes d'un determinat tipus, el client ha de poder compleix els criteris.
saber quins agrupaments de productes té el catàleg. Per tant, serà necessària

una operació que mostri la classificació dels productes. Exemple de mostra
de classificació dels
productes
mostra_tipus_producte (id_tipus_producte, id_idioma) mostra_tipus_producte (101,

0)
Aquesta operació mostraria els
tipus més específics que el ti-
Aquesta operació retornarà el conjunt de tipus de productes que depenen d'un pus 101(informàtica), és a dir
103 (sistemes operatius) i 104
tipus més genèric, que és l'indicat pel paràmetre d'entrada. (sistemes gestors de bases de
dades).
L'usuari també voldrà consultar les dades de productes segons altres caracte-
rístiques diferents del tipus de producte. Algunes possibles operacions serien:
productes_preus (preu_inferior, preu_superior, id_idioma)
productes_paraula (paraula_clau, id_idioma)

Aquestes operacions cerquen els productes que compleixen uns requeriments

específics: amb preu entre un interval de valors, amb descripció que conté
una paraula clau, etc. Per tant, també s'obtindrà com a resultat el conjunt de
registres corresponents als productes que compleixin els criteris de cerca.
Altre cop, les operacions descrites requereixen paràmetres d'entrada i, per això,
s'implementaran mitjançant procediments�emmagatzemats.
Actualització�d'estocs
Hi haurà operacions sobre el catàleg de productes que provocaran l'execució

automàtica d'altres operacions relacionades. El cas més típic és el control
d'estocs, ja que, cada cop que es produeix la venda d'un producte, s'haurà de
modificar el nombre d'unitats disponibles en estoc d'aquest producte.
modifica_estoc (id_producte, unitats_venudes)
Per a implementar aquesta operació utilitzarem un disparador que s'activaria

com a conseqüència d'una actualització de la taula COMANDA i un valor con-
cret d'id_estat que indicaria que la comanda és acceptada per l'empresa.
2.3.2. Bossa o cistell d'anar a comprar (comandes)
La bossa d'anar a comprar representa, en cada moment i per a cada client, el

desglossament dels articles seleccionats per a ser comprats. Requereix, doncs,
el detall de dades per a cada producte del cistell: la referència, descripció, uni-
tats demanades, subtotals per concepte, impostos, import del transport, totals,
etc.
El client s'encarregarà de la confecció de la comanda i l'empresa gestionarà

l'estat d'aquestes.
Confecció�i�gestió�de�comandes
Una comanda es correspon amb un registre a la taula COMANDA i di-

versos registres de la taula LINIA_COMANDA (un per a cada producte
comprat).
Per a confeccionar una comanda, ens caldran les operacions següents:
1)�Afegir�un�producte�a�la�comanda.
Per a afegir un producte a la comanda, haurem de comprovar si existeix la

capçalera de la comanda o no. En cas d'existir, únicament haurem d'afegir les
dades corresponents a la taula LINIA_COMANDA, altrament caldrà crear la
comanda, fent una inserció a la taula COMANDA, que donarà lloc a la capça-
lera, i inserir igualment les dades del producte a la taula LINIA_COMANDA.
Exemple d'adicció d'un

crea_comanda (data_inici, adreça ip) producte a la comanda
afegeix_comanda (id_producte, unitats, id_comanda) crea_comanda

(‘01/01/2001','192.168.1.1')
afegeix_comanda (56, 2, 32)
Es crea la comanda amb els va-
Aquestes operacions donen d'alta una comanda i no retornen cap conjunt de lors de data i adreça ip del cli-
ent.
registres. S'afegeix a la comanda, amb
id_comanda 32, 2 unitats del
producte 56.
2)�Modificar�una�línia�de�comanda.
El client pot, en qualsevol moment, modificar les unitats dels productes que
cal comprar:
modifica_comanda (id_linia, id_comanda, unitats)
Aquesta operació permetrà que el client pugui canviar les unitats de cadascun
dels productes de dins la bossa, de manera que s'haurà de passar com a parà-
metre el codi de línia i l'id_comanda, que identifica unívocament cada línia
de la bossa.
3)�Eliminar�una�línia�de�comanda.
També s'ha d'oferir la possibilitat de suprimir algun producte de la comanda:
Exemple d'eliminació de
elimina_comanda (id_linia, id_comanda) comanda
elimina_comanda (112, 1001)

elimina la línia de comanda
Aquesta operació elimina el registre associat a la taula LINIA_COMANDA. amb id_línia 112 i id_comanda
1001.
4)�Modificar�informació�d'una�comanda.
Les dades de la comanda s'actualitzen diverses vegades. Una actualització es

produeix quan el client acaba de confeccionar la comanda i introdueix les
dades del destinatari, d'enviament i de mode de pagament.
dades_comanda (nif, nom, cognoms, adreça, poblacio, codi_postal,

pais, telefon, fax , email, nomenv, cognomsenv,
adreçaenv, poblacioenv, codi_postalenv, paisenv,
id_client, total_comanda ,
data_comanda, hora_inici_compra,
hora_fi_compra, adre_ip_compra,id_pagament,
id_enviament, data_lliurament, hora_lliurament)
Una altra possible modificació de les dades de la comanda es dóna quan es

coneix el resultat de la transacció econòmica de pagament.
Exemple de modificació de
resultat_economic_comanda (id_comanda, num_transaccio, comanda
data_transaccio, id_resultat_transaccio
resultat_economic_comanda
(42, 134543, ‘01/01/2001', 0)
La comanda amb id_comanda
Quan canvia l'estat de la comanda també cal actualitzar el camp id_estat_co- 42, té el número de transac-
ció 134543 amb da-
manda. L'operació corresponent seria la següent: ta ‘01/01/2001' i amb
l'id_resultat_transaccio 0 que
vol dir que s'ha fet correcta-
ment.
estat_comanda (id_comanda, id_estat)
Per exemple
Observeu que el venedor farà aquesta darrera operació per mitjà de la xarxa estat_comanda (42, 101) in-
privada (intranet). dica que la comanda amb
id_comanda 42 passa a tenir
l'estat corresponent a l'id_estat
101, per exemple, "en procés".
5)�Presentació�de�les�dades�de�la�comanda.
Necessitarem operacions per a mostrar les dades relatives a una comanda a

partir del codi de comanda (id_comanda):
dades_comanda (id_comanda)
Aquesta operació extreu totes les dades relatives a la comanda. Per tant, retor-
narà un conjunt de registres.
Observem que les operacions que manipulen la comanda es fan des de la xarxa
pública, a excepció del canvi d'estat de la comanda. Totes requereixen parà-
metres d'entrada i, per tant, s'implementaran mitjançant procediments�em-
magatzemats.
2.3.3. Clients
Les operacions relacionades amb els clients seran operacions de manteniment

de les seves dades personals, de gestió de la seva contrasenya, de reconeixe-
ment del client per part de l'aplicació i de seguiment de les compres efectuades.
Manteniment�de�les�dades�personals
Aquest manteniment es pot fer tant des de la xarxa� pública, en què cada
usuari podrà gestionar les seves dades, com des de la xarxa�privada, en què
el venedor podrà fer modificacions sobre les dades de qualsevol client.
1) Alta d'un nou client.
alta_client (nif, nom, cognoms, email , contrasenya, pregunta, resposta,
data_naixement, estat_civil)
Aquesta operació inserirà un nou registre a la taula de CLIENTS.
2) Modificació de les dades d'un client.
modifica_client (idclient, nif, nom, cognoms, email , contrasenya,
pregunta, resposta, data_naixement, estat_civil)
Un client, des de la xarxa�pública, podrà modificar les seves dades personals.

Aquesta operació actualitzarà el registre corresponent al client amb les noves
dades.
3) Baixa d'un client.
baixa_client (idclient)
Aquesta operació actualitzarà un camp del registre de client indicant que és

baixa; físicament no s'esborrarà.
Totes les operacions d'aquest subapartat s'implementaran com a procedi-

ments�emmagatzemats.
Gestió�de�les�contrasenyes
Per restringir l'accés a la base de dades per mitjà de la xarxa pública, es pot
utilitzar un procés d'autenticació via usuari i contrasenya. En aquest cas,
l'aplicació oferirà als clients la possibilitat de canviar la contrasenya personal
i de recordar-la en cas d'oblit.
1) Canvi de la contrasenya.
canvi_contrasenya (id_client, contrasenya)
Aquesta operació actualitzarà la contrasenya del client. En el cas de fer-se des

de la xarxa�pública només es permetrà el canvi al client que ho sol·liciti. En el
cas que la modificació es faci des de la xarxa�privada el venedor podrà escollir
el client del qual es vulgui canviar la contrasenya.
2) Recordatori de la contrasenya.
És habitual haver de resoldre la situació en la qual un client oblida la contrase-

nya. És per això que en el formulari d'alta es demana una pregunta i la corres-
ponent resposta a l'usuari. La pregunta triada pel client i la resposta associada
han de servir per a autenticar-lo.
mostra_pregunta (email)
verifica_resposta(email, resposta)
La primera operació retorna la pregunta associada a l'adreça de correu electrò-

nic que se li passa com a paràmetre d'entrada. Fixeu-vos que en aquest cas
particular agafem l'adreça de correu electrònic com a login.
La segona operació verifica si la resposta d'un determinat client (identificat pel

seu correu electrònic) és correcta o no. L'operació retornarà un booleà indicant
el resultat de la comprovació.
Autenticació�del�client
(2)
Quan un client entra a la xarxa�pública dins l'àrea clients, s'ha de comprovar Recordeu que en aquest cas par-
2 ticular prenem l'e-mail com a login.
que l'adreça de correu electrònic i la contrasenya corresponguin a un client
vàlid de la taula de CLIENTS.
user_login (email, contrasenya)

Aquesta operació ha de comprovar que la combinació de correu electrònic i la Vegeu també

contrasenya corresponguin a un dels clients registrats. Retornarà una variable
Els aspectes concrets relaci-
booleana amb el resultat de la comprovació, i el codi de client en cas de client onats amb la seguretat de
vàlid; aleshores el codi de client s'emmagatzemarà en una variable global per l'autenticació del client ja s'han
tractat en l'apartat "Seguretat
a fer-lo servir posteriorment. en el conjunt de les dades" del
mòdul didàctic "Seguretat en
el comerç electrònic".
Un cop reconegut el client, s'han de determinar els descomptes que li perto-
quen.
descompte_client (idclient)
L'operació descompte_client calcula el descompte més favorable per al client,

depenent del tipus de client que sigui. Retornarà el valor del descompte que
s'emmagatzemarà en una variable global per a accedir-hi posteriorment.
Totes dues operacions s'implementaran com a procediments� emmagatze-

mats.
Seguiment�de�les�compres
Dins de la taula CLIENT_REGISTRAT tenim camps com la data de la primera

compra, la de la darrera compra, l'import acumulat de les compres i el nombre
de compres realitzades.
Tota aquesta informació ens serà útil per poder oferir condicions particulars,
depenent dels valors d'aquests camps; així, per exemple, podríem oferir un
descompte especial als clients que ens han comprat més d'un cert import, als
que fa més de dos mesos que no ens han comprat res, als que ens han comprat
més d'un cop dins la mateixa setmana, etc.
Considerem aquest tipus d'informació com a operativa, ja que ens serveix per a
les operacions diàries de l'empresa. Per a actualitzar aquests camps del registre
de clients es farà ús dels disparadors.
data_primera_compra (idclient)
data_darrera_compra (idclient,data)
import_acumulat_compres (idclient, import)
numero_compres (idclient)
Totes aquestes operacions actualitzen un registre de la taula CLIENT i

s'implementaran amb un disparador que s'activa en actualitzar la taula
COMANDA, sempre que el resultat de la transacció hagi estat correcte
(id_resultat_tansaccio=0 per exemple).
L'operació data_primera_compra insereix la data actual del sistema si el valor

del camp data_primera_comanda de la taula CLIENT té valor nul. Anàloga-
ment, l'operació data_darrera_compra insereix la data actual del sistema en el
camp data_darrera_comanda de la taula CLIENT.
L'operació import_acumulat_compres actualitza el camp

import_acumulat_com-pres incrementant l'import de la compra segons la
quantitat acumulada, camp total_comanda de la taula COMANDA, abans de
produir-se la compra.
L'operació nombre_compres actualitza el camp nombre de compres del client

associat incrementant el valor en una unitat.
3. Data warehouse: base de dades estratègica
Ara que ja coneixem la part operativa d'una aplicació B2C, ens centrarem en la
part de suport a la presa de decisions. Veurem que la base de dades estratègica
ha de servir als responsables de l'empresa per a prendre decisions. L'objectiu
d'aquesta base de dades és transformar informació en accions i idees útils per
a incrementar la productivitat del negoci.
Iniciarem l'apartat veient la necessitat d'una base de dades estratègica que

anomenarem data warehouse, detallarem els trets més rellevants d'aquest ma-
gatzem de dades i, tot seguit, veurem un exemple de model de dades orien-
tat a l'anàlisi de les vendes. Un cop fet el disseny, explicarem com es realitza
l'alimentació del data warehouse i després veurem com explotar-lo, extraient
el coneixement que ens serveixi per a millorar les relacions amb els clients.
3.1. Necessitat d'un entorn estratègic
Recordeu que en el primer apartat vam parlar de dos tipus d'informació i de

la necessitat de dos tipus de bases de dades. Fins ara només hem tractat la
informació operativa.
Us imagineu que la base de dades que coneixem pugui donar resposta a pre-
guntes com les següents?
• Quins han estat els productes més venuts durant els diferents trimestres
de l'any passat?
• Quin efecte ha tingut una determinada campanya publicitària sobre les

vendes?
• Com podem segmentar el mercat depenent de les compres realitzades pels

clients de cada àrea, zona o país?
Per a respondre a la primera pregunta, cal que disposem d'informació�histò- Primera pregunta
rica. La nostra base de dades operativa guardarà informació de les vendes du-
Quins han estat els productes
rant els darrers seixanta o noranta dies, marge de temps insuficient per a ex- més venuts durant els diferents
trapolar el comportament de les vendes i planificar l'aprovisionament futur. trimestres de l'any passat?
La segona pregunta es formularia per a analitzar els resultats obtinguts com Segona pregunta
a conseqüència d'una determinada acció vers el mercat, per a veure l'efecte
Quin efecte ha tingut una de-
produït i plantejar-se de fer més campanyes publicitàries o no, o, si més no, per terminada campanya publicità-
ria sobre les vendes?
a millorar futures promocions. Observeu que hauríem de determinar el període

de temps sobre el qual analitzaríem les vendes i que necessitaríem informació
del departament de vendes que no tenim a la base de dades operativa.
La tercera pregunta respon a una anàlisi dels clients de l'empresa per zona, Tercera pregunta
àrea o país. Aquesta anàlisi ens permetrà d'arribar a conèixer les preferències
Com podem segmentar el
de compra dels nostres clients segons la zona geogràfica i així poder oferir mercat depenent de les com-
promocions per àrea o zona. pres realitzades pels clients de
cada àrea, zona o país?
Preguntes de l'estil de les formulades, responen a qüestions estratègiques, que,

per a donar resposta a partir de la base de dades operativa, requereixen la cons-
trucció de consultes SQL que resultarien molt poc eficients, a causa de la gran
quantitat de taules que cal combinar i a la manca d'informació històrica en
aquest entorn.
(3)
L'anàlisi de dades s'ha de fer a partir d'informació estable, no canviant, com és Les sigles OLTP corresponen en
anglès a On-line Transaction Process
el cas de la informació que conté la base de dades operativa. És per això que ens
(‘transaccions en línia').
plantegem la necessitat de considerar dos entorns: l'entorn OLTP3, suportat
(4)
per la base de dades operativa, i l'entorn OLAP4, suportat per la base de dades Les sigles OLAP corresponen en
anglès a On-line Analysis Process
estratègica. Tots dos dipòsits tenen finalitats diferents i, per tant, s'estructuren (‘anàlisi en línia').
de manera diferent.
En l'apartat anterior, hem vist que el disseny de la base de dades operativa

respon a la necessitat de fer possible les transaccions del dia a dia. Ara estudi-
arem com ha de ser el magatzem de dades de la base de dades estratègica, el
qual integrarà dades que provenen de fonts diverses i heterogènies: base de
dades operativa, informació i dades d'altres aplicacions que són controlades
per altres àrees de negoci de l'empresa (RH, màrqueting, ERP, etc.).
3.2. Què és el data warehouse?
La base de dades estratègica també s'anomena data warehouse.
El data warehouse es caracteritza per ser un magatzem de dades orientat a

les àrees d'interès de l'empresa, que integra informació de diverses fonts,
amb informació no volàtil i informació històrica, i que té, com a darrer
objectiu, donar suport a la presa de decisions.
Veiem amb una mica més de deteniment aquests trets característics del data
warehouse.
Orientat�a�les�àrees�d'interès�de�l'empresa
L'organització de les dades es fa a partir dels fets que es desitja analitzar (ven-
des, clients, enviaments, etc.), no a partir dels processos que fan les aplicaci-
ons. Això fa que el disseny i la representació de les dades s'orienti als fets o
àrees de negoci que es vol estudiar, emmagatzemant només aquelles dades que
ens són útils per a prendre decisions.
Integració�de�dades
La informació que emmagatzema el data warehouse prové de diferents fonts

de dades, entre les quals destaca la base de dades operativa i les dades d'altres
aplicacions de l'empresa que sovint gestionen altres departaments. Tota la in-
formació que formarà part del data warehouse ha de passar prèviament per un
procés d'integració a diversos nivells (noms, mesures de camps, implementa-
ció d'estructures de dades, etc.).
De�temps�variant
Tota dada emmagatzemada en el data warehouse té el corresponent estampillat

de temps, ja que forma part de l'historial�de�dades. Les dades que emmagat-
zema solen ser de cinc a deu anys enrere i, a nivell lògic, hem de veure-les
com una col·lecció d'instantànies sobre els temes d'interès de l'empresa que
ens ajudaran a detectar evolucions i tendències dels fets que cal analitzar.
No�volatilitat
Per a prendre decisions cal basar-se en dades estables. El data warehouse només
admet dos tipus d'operacions: la càrrega de dades i l'obtenció de dades. No
existeix l'operació d'actualització; si alguna dada de resum canvia, s'afegeix la
nova informació amb el corresponent estampillat de temps, per tal de disposar
de l'historial.
Figura 9
Fixeu-vos que el data warehouse s'alimenta a partir de la base de dades operativa, informació històrica i dades d'altres
departaments o aplicacions de l'empresa, i que, a partir d'aquesta, s'extrau informació per als diferents departaments, per a
aplicacions de comerç electrònic, CRM, ERP, per a fer anàlisi estadística, etc.
Una altra manera d'entendre el data warehouse és comparar-lo amb la base de

dades operacional. El quadre següent resumeix les diferències més importants:
BD operacional Data�warehouse
Dades operacionals Dades informatives de negoci
Disseny orientat a l'aplicació Disseny orientat a les àrees d'interès del negoci
Dades actuals (60-90 dies) Dades històriques + actuals
Dades detallades Dades detallades + dades resum
Informació canviant Informació estable
Molts usuaris concurrents Pocs usuaris concurrents
Consultes predefinides Consultes imprevistes
Volum de dades petit Volum de dades gran
Temps de resposta immediata Temps de resposta no crític
A partir d'ara, quan fem referència al data warehouse, ens referirem a aquella
part de la base de dades estratègica que s'alimenta de la base de dades operaci-
onal. Concretament, ens referirem a les dades de la base de dades operacional
útils per a analitzar les vendes, les tendències dels clients, etc.
3.3. Model de dades per a l'anàlisi de les vendes
Construir un model de dades per a dissenyar un data warehouse va més enllà

dels propòsits d'aquesta assignatura, però podem centrar-nos en una única
àrea d'interès de l'empresa i fer un primer disseny, que ens servirà d'exemple
il·lustratiu.
Triarem com a àrea d'interès les vendes i, per tant, dissenyarem un data
warehouse que permeti d'analitzar les vendes des de diferents dimensi-
ons.
Hem vist que, en definir el data warehouse, un dels seus trets característics és
que s'orienta a una àrea d'interès o fet; en el nostre cas hem triat les vendes.
També hem vist que incorpora el component temporal en tota la informació
que emmagatzema, fet que facilita l'anàlisi de vendes per períodes de temps
que ajudarà a descobrir evolucions i tendències en les vendes. Però una anàlisi
profunda d'un fet implica tenir en compte més dimensions En el nostre cas, és
fàcil adonar-se que és necessari considerar altres dimensions com el producte
i el client.
Tenim, per tant, tres�dimensions que cal estudiar en les vendes: client,
producte i temps.
Si prenem un eix tridimensional i en el centre ubiquem les vendes, cadascun

dels eixos correspondria a les tres dimensions triades per a l'anàlisi i, en con-
seqüència, obtindríem un cub com el següent:
Figura 10
Observem que cada element del cub (minicub) conté un valor de les vendes per a un client particular, un producte concret i un
punt de temps concret.
Si volguéssim afegir una dimensió més al fet vendes, per exemple, l'àrea o zona,
el cub ja no ens serviria com a representació. Aleshores podríem fer servir un
dibuix com el següent:
Figura 11. Model de dades d'estrella
Aquest model multidimensional recorda una estrella: el fet central (vendes)

i les dimensions al voltant (client, producte, àrea, temps). Per aquest motiu,
s'anomena model d'estrella i és el diagrama més utilitzat per a fer el disseny d'un
data warehouse, ja que permet de respondre consultes formulades en llenguatge
empresarial com, per exemple, quins productes són estacionals, quines línies
de producte incrementen la seva popularitat i quines la disminueixen, etc.
El model�d'estrella és un diagrama que permet de mostrar les relacions

entre fets i taules. Les taules són les dimensions i es relacionen amb
el fet mitjançant interrelacions 1-N. També s'anomena model�multidi-
mensional.
Si ens hi fixem, algunes dimensions corresponen a taules de la nostra base

de dades operacional i les vendes estan clarament relacionades amb la taula
COMANDA. La tecnologia que millor suporta un model de dades basat en
taules relacionades és la tecnologia de bases de dades relacionals, però amb
un enfocament diferent al de la base de dades operativa. Aquesta base de da-
des només ha de contenir informació útil perquè els responsables de l'àrea en
qüestió puguin prendre decisions estratègiques sobre l'àrea o fet d'interès que
vulguin estudiar.
El model conceptual descrit a la figura 11 es transformaria en un model lògic

format per cinc relacions:
Vendes (id_client,�id_producte,�id_temps,�id_area,
quantitat, import)
Client (id_client, nom_complet, adreça)
Producte (id_producte, nom_producte, preu_unitari)
Area (id_area, descripcio_area)
Temps (id_temps, data, num_semestre, num_trimestre, any)

Hi ha algunes coses d'aquest disseny lògic que cal comentar:
1) És important que quedi clar que només s'emmagatzema informació útil

per a la presa de decisions i, per tant, s'ometran dades com ara la majoria de
descripcions.
2) El model d'estrella només permet de representar interrelacions de grau 1-N.

No hi ha taules que representin interrelacions com ara la LINIA_COMANDA
(interrelació entre PRODUCTE i COMANDA). Es tracta de tenir tota la infor-
mació necessària per a l'anàlisi de vendes, de manera que les consultes siguin
com més eficients possible i no impliquin la combinació de múltiples taules
relacionades.
3) La taula temps conté informació detallada sobre els períodes de temps en

què és interessant analitzar les vendes. De fet, a partir d'una data podríem de-
rivar altres intervals de temps, però agilita les consultes el fet de tenir altres
divisions de temps com a atributs. D'altra banda, el que importa de la coman-
da, a part del producte, quantitat i preu, és l'instant en què la direcció consi-
dera la comanda com a venda. Hem suposat que seria l'instant en què s'envia
al destinatari, d'aquí que l'id_temps en el fet vendes correspongui a la data
d'enviament de la comanda.
4) La clau primària del fet és una clau composta per totes les claus primàries
de cadascuna de les dimensions. Aquesta taula és la més consultada, ja que
conté tots els fets reals que es volen analitzar, i les claus foranes d'altres taules
que formen part de la clau primària solen ser útils per a fer agrupacions segons
les dimensions.
3.4. Alimentació del data warehouse
Un cop construït un data warehouse, tenim identificats els fets que cal analitzar
i les dimensions des de les quals el volem estudiar. El pas següent consisteix a
determinar el mecanisme d'alimentació del data warehouse.
Seguim amb l'exemple del nostre data warehouse orientat a les vendes. En
aquest cas, tenim tota la informació que necessitem per a alimentar-lo a la
base de dades operativa.
Un dels problemes inicials que es presenta és la unificació de criteris a l'entorn Què s'entén per venda?
de la definició dels fets. Ens trobem que no hi ha cap taula anomenada VEN-
Fixeu-vos que, per al departa-
DES ni cap atribut amb aquest nom, però sabem que les vendes esdevenen ment de vendes, una venda
després d'haver-se confeccionat una comanda que passa per diversos estats es produeix quan el client vali-
da una comanda; per al depar-
fins a considerar-se servida. Des del punt de vista estratègic, cal determinar tament de logística, quan es
rep l'ordre d'enviar la coman-
què s'entén per venda i, un cop aclarit aquest punt, podrem determinar qui- da al destinatari; per al depar-
tament de comptabilitat, quan
nes dades de la base de dades operativa seran considerades vendes i, per tant, es comprova el pagament de
podran passar a formar part de les files de la taula de fets. la comanda, etc. Com veiem,
hi ha diferents formes de veure
una venda, depenent del punt
de vista des d'on es miri.
El que resulta clar és que les vendes estan estretament relacionades amb les co-
mandes, i sabem que tota comanda té un estat que indica en quin punt es troba
(pendent, en procés, enviada, pagada, etc.). El valor del camp estat_comanda
ens ajudarà a determinar quan una comanda es considera venda des del punt
de vista estratègic.
El mecanisme d'alimentació del data warehouse es basa en el traspàs

d'informació cap a taules temporals, que es fa mitjançant disparadors
que s'activen cada cop que es produeix un fet, abocant tota la informa-
ció útil per a l'anàlisi cap a les taules temporals.
La càrrega del data warehouse no es realitza cada vegada que es produeix un fet a
l'entorn operacional, sinó que es fa quan es disposa de prou dades significatives
que ajudarien a prendre millor les decisions. Aquest és el motiu pel qual les
taules temporals van emmagatzemant informació, que, en el moment en què
es determini, passaran a formar part del data warehouse.
En el nostre cas, només hem considerat una única font de dades, la base de Càrrega del data
dades operativa, però es podria donar el cas en què calgués informació d'altres warehouse
fonts, per exemple, les dades d'un altre departament. Aleshores, hi ha altres Imaginem que el data ware-
consideracions que cal tenir en compte, com ara la integració de dades, des house conté informació de
10.000 vendes. Les anàlisis
del punt de vista del format, semàntic, etc. Per tant, la informació recollida que fem sobre aquests fets no
variaran si hi ha 10 vendes més
de diverses fonts a mesura que es produeixen fets, s'ha d'integrar per a poder o menys, per tant, depenent
del volum de dades que tingui
passar a formar part del data warehouse.
el data warehouse, es carregarà
més o menys sovint.
Figura 12. Extracció, Integració, Càrrega
3.5. CRM (customer relationship management)
La gestió de les relacions amb els clients no és un concepte nou. Un exemple

clar seria el cas d'un petit comerç de barri en què el botiguer (empresari) co-
neix bé les preferències dels seus clients. Com que hi ha una estreta relació
entre ambdues parts, el botiguer utilitza aquesta informació per a proveir-se
de productes que puguin interessar als seus clients. A posteriori, aquest els ofe-
rirà a determinats clients, actuant de manera estratègica pel que fa a vendes
i aprovisionament.
El CRM (customer relationship management) és una estratègia d'empresa

que permet d'entendre el comportament dels clients mitjançant una
estreta i significativa comunicació, i té com a objectiu aconseguir la seva
fidelitat i lleialtat.
En altres paraules, el CRM és un procés interactiu l'objectiu principal del qual

és obtenir informació dels clients dins un entorn basat en la relació empre-
sa-client.
Per al CRM, el client és el centre del negoci. Pretén un tracte personalitzat

per a cada client i això fa que el CRM també s'anomeni relació�one�to�one.
Les empreses actuals tenen la necessitat d'evolucionar cap a aquest model per
a ampliar el seu mercat, per això el CRM s'imposa cada vegada més com a
estratègia d'empresa, sobretot en entorns com el del comerç electrònic en què
els clients estan distribuïts en diferents zones geogràfiques.
El darrer objectiu del CRM és analitzar el comportament dels clients,

fer segmentacions, identificar tendències, tipologies i consums, i, a par-
tir d'aquí, elaborar l'oferta de productes i desenvolupar tota l'estratègia
d'aproximació al mercat.
Com a conseqüència de tot això, veiem que el CRM no és un programari, sinó

que és una estratègia d'empresa suportada per una plataforma tecnològica, que
es basa en l'historial de dades de cadascun dels clients que formen part de la
cartera de l'empresa. Totes aquestes dades s'extrauen del gran magatzem de
dades estratègic, el data warehouse.
S'ha de ser conscient que implantar una estratègia CRM significa haver de fer
canvis dins de l'estructura de l'empresa. Una de les primeres tasques consisteix
a canviar la visió del negoci, revisar els processos de l'empresa per a adaptar-los
a aquest nou enfocament.
Per resumir, el CRM fa que augmenti el valor d'una organització, però per a
això, cal la motivació i incentivació de les persones, l'atenció i el servei al
client, i la capacitat d'una empresa per a convertir dades i informació de clients
en idees i accions.
Resum
En aquest mòdul hem presentat els conceptes relacionats amb la gestió de la

informació en el comerç electrònic.
Primerament, hem justificat la necessitat de la tecnologia de bases de dades

com a peça clau per a la venda per mitjà de la web.
La part central del mòdul es dedica a l'estudi de la base de dades operativa, que
és la que fa possible que es portin a terme les transaccions econòmiques que
equivalen a la venda tradicional. S'ha estudiat el disseny d'una base de dades
genèrica i s'han enumerat les operacions bàsiques que requereix un entorn
de venda electrònic. Tots aquests coneixements es posaran en pràctica en la
darrera part de l'assignatura mitjançant la construcció d'una botiga virtual.
El darrer apartat pretén d'ampliar la visió del comerç electrònic, per no que-
dar-nos només amb la part operativa, i mostra la perspectiva més estratègica
de tot aquest àmbit.
Activitats
1. Visiteu "La Virtual" i compareu-la amb la llibreria que es descriu en l'apartat de la base de
dades operativa. Observeu quins productes es venen, com es mostra el catàleg de productes,
com es visualitza una comanda, quines operacions permet de fer, etc.
2. Utilitzant la bibliografia recomanada del mòdul, feu una llista d'objectius i beneficis del
data warehouse.
Exercicis d'autoavaluació
1. Indiqueu en quin tipus de base de dades trobaríeu les informacions que es detallen a
continuació:
a) Vendes del darrer trimestre tancat.

b) Clients que han deixat de comprar des de fa un any.
c) Clients de tipus preferent.
d) Productes en oferta.
e) Productes catalogats per tipus.
f) Tendències de les vendes per trimestres dels darrers dos anys.
g) Tipus de productes que es venen principalment per Nadal.
2. Com modificaríeu el model de dades conceptual de la base de dades operacional perquè:
a) inclogui l'idioma preferit per a cada client?

b) enregistri descomptes que cal aplicar als clients per tipus de producte?
c) tingui en compte marges de preu diferents per producte?
3. Suposant que el fet que cal analitzar a la base de dades estratègica són els clients, quin
model de dades proposaríeu, tenint en compte que interessa tenir les preferències dels clients
per zona, producte, tipus de client i nivell social.
4. Sobre la base de dades estratègica orientada a vendes, formuleu les consultes SQL que
donarien resposta a les consultes següents en llenguatge empresarial:
a) Hi ha productes que van ser més populars en unes zones que en unes altres durant l'any
passat?
b) Quins productes són estacionals? Considerarem les dades dels darrers cinc anys.
Solucionari
Exercicis�d'autoavaluació
1. La informació que fa referència a dades històriques i de caràcter estratègic aniria a la co-

lumna de la base de dades estratègica, mentre que la informació referent al dia a dia aniria
a la base de dades operacional.
BD estratègica: a, b, g, h.
BD operacional: c, d, e, f.
2. A partir del model conceptual de dades presentat en el mòdul:
a) L'idioma preferit pel client seria una dada personal del client amb un valor atòmic, per
tant, l'inclouria com a atribut a l'entitat CLIENT.
b) Els descomptes que cal aplicar per tipus de client i tipus de producte requeririen una
nova interrelació entre les entitats TIPUS_CLIENT i TIPUS_PRODUCTE amb grau N-M, ja
que, donat un tipus de client, s'haurien d'emmagatzemar diversos descomptes, un per a cada
tipus de producte, i un tipus de producte podria tenir diferents descomptes segons el tipus
de client.
c) Tenir en compte un preu mínim i màxim per producte implicaria tenir unes limitacions
que caldria considerar una vegada determinat el descompte que s'hauria d'aplicar al client.
Podrien afegir-se com a dos atributs a l'entitat PRODUCTE.
3. El client és el fet central i les dimensions sobre les quals s'ha de fer l'estudi són zona,
producte, tipus de client i nivell social.
4. Les consultes SQL serien les següents:
a) Es tracta de veure quins productes són més populars en unes zones que en unes altres. Per
això, buscarem, per a cada producte i àrea, el nombre de vendes i la quantitat de productes
venuts.
SELECT p.nom_producte, , a.descripcio_area, count(*) "Total vendes",

sum(quantitat) as "Total productes"
FROM vendes v, productes p, area a, temps t
WHERE v.id_producte =p.id_producte AND v.id_area=t.id_area

AND v.id_temps = t.id_temps AND an=YEAR(data) -1
GROUP BY p.nom_producte, a.descripcio_area
ORDER BY p.nom_producte, a.descripcio_area;
b) Per a determinar els productes estacionals, s'han d'analitzar les quantitats de productes ve-
nuts durant cada trimestre. Podem fer l'estudi a partir d'una consulta que obtingui una llista
ordenada per nom de producte i número de semestre que mostri la quantitat de productes
que s'han venut durant els diferents trimestres dels cinc darrers anys. A partir d'aquesta in-
formació, es pot fer una gràfica, de manera que es visualitzi clarament l'augment i la dismi-
nució de popularitat dels diferents productes.
SELECT p.nom_producte, t.num_trimestre, sum(quantitat)
FROM vendes as v, productes as p, temps as t
WHERE v.id_producte =p.id_producte AND v.id_temps=t.id_temps

AND p.num_trimestre between 1 and 4
AND t.an between YEAR(date)-5 AND YEAR(date)
GROUP BY p.nom_producte, t.num_trimestre
ORDER BY p.nom_producte, t.num_trimestre;

Glossari
client/servidor Entorn mitjançant el qual s'estableixen comunicacions entre diferents
agents per mitjà d'una xarxa de transmissió de dades, de manera que els agents clients recla-
men serveis oferts per agents servidors.
CRM Vegeu gestió de relació amb el client
customer relationship management Vegeu gestió de relació amb el client
data warehouse Magatzem de dades orientat a les àrees d'interès de l'empresa, que integra
informació de diverses fonts, amb informació no volàtil i informació històrica, i que té, com
a darrer objectiu, donar suport a la presa de decisions.
disparador Procediment emmagatzemat a la base de dades que s'executa automàticament

(es dispara) quan es fa una operació INSERT, DELETE o UPDATE sobre alguna taula en concret.
Aquesta execució, alhora, pot provocar que s'executin sentències com ara INSERT, DELETE,
UPDATE o EXECUTE PROCEDURE.
disseny conceptual Etapa del disseny d'una base de dades que obté una estructura de la
informació de la futura base de dades independentment de la tecnologia que es vol emprar.
disseny físic Etapa del disseny d'una base de dades que transforma l'estructura obtinguda
a l'etapa del disseny lògic amb l'objectiu d'aconseguir una eficiència més gran i que, a més, la
completa amb aspectes d'implementació física que dependran de l'SGBD que s'ha d'utilitzar.
disseny lògic Etapa del disseny d'una base de dades que parteix del resultat del disseny
conceptual i el transforma de manera que s'adapti al model de l'SGBD amb el qual es desitja
implementar la base de dades.
enterprise resources planning Vegeu programari de gestió integrada
ERP Vegeu programari de gestió integrada
gestió de relació amb el client en customer relationship management

Estratègia d'empresa que permet d'entendre el comportament dels clients per mitjà d'una
estreta i significativa comunicació per a aconseguir la seva fidelitat i lleialtat. En altres
paraules, és un procés interactiu l'objectiu principal del qual és obtenir informació dels clients
dins d'un entorn basat en la relació empresa-client.
sigla: CRN
informació estratègica Informació útil relacionada amb la planificació i estratègia de

l'empresa.
informació operacional Informació del "dia a dia" de l'empresa.
màrqueting Mitjans i tècniques utilitzades per a conquerir nous mercats.
OLAP Vegeu procés d'anàlisi en línia
OLTP Vegeu procés de transacció en línia
on-line analysis process Vegeu procés d'anàlisi en línia
on-line transaction process Vegeu procés de transacció en línia
procediment Programa definit per l'usuari que s'emmagatzema a la base de dades. Una
vegada el procediment ha estat creat, s'emmagatzema en format executable a la base de dades
com qualsevol objecte de la base de dades.
procés d'anàlisi en línia en on-line analysis process

Mètode d'anàlisi de dades que es caracteritza perquè redefineix de manera contínua i flexible
el tipus d'informació que cal extreure, analitzar i sintetitzar.
sigla: OLAP
procés de transacció en línia en on-line transaction process

Sistemes de processament de transaccions en línia (OLTP) que tenen com a objectiu guardar
la integritat de les dades necessàries per a administrar una organització de manera eficient.
sigla: OLTP
programari de gestió integrada en enterprise resources planning

Sistema de gestió de la informació per a satisfer la demanda de solucions de gestió

empresarial basat en l'oferiment d'una solució completa que permeti a les empreses d'avaluar,
implementar i gestionar més fàcilment el seu negoci.
sigla: ERP
transacció Conjunt d'operacions de lectura i/o actualització de la base de dades que acaba
confirmant o cancel·lant els canvis que s'han dut a terme.
vista Taula fictícia que es construeix a partir de taules reals emmagatzemades a la base de
dades. La no-existència real de les vistes fa que puguin ser actualitzables o no.
Bibliografia
Franco, J.-M.; EDS-Institut Prométhéus. (1997). El Data Warehouse – El Data Mining.
Barcelona: Gestión 2000.
Gill Harjinder, S.; Rao Prakash, C. (1996) Cliente/Servidor. Data Warehousing. Mèxic:
Prentice Hall.
Inmon W. H.; Imhoff, C.; Sousa, R. (2001). Corporate Information Factory. Estats Units:
Wiley.
Sakhr Youness. (2000). Data Warehousing with SQL Server 7.0 and OLAP Servicies. Wrox.
Silverston, L. (2001). The Data Model Resource Book. Volume 1. Estats Units: Wiley.
Simon Alan, R.; Shaffer Steven, L. (2001). Data Warehousing and Business Intelligence for
E-Commerce. Estats Units: Morgan Kaufmann Publishers.
Todman, C. (2001). Designing a Data Warehouse. Estats Units: Hewlett-Packard Professional

Books.
Swift, R. S. (2000) ACCELERATING Customer Relationships. Prentice Hall.

Pid 00160565

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pid 00160565

Uploaded by

Copyright:

Available Formats

Gestió de la

Óscar Alavedra i Martí

Óscar Alavedra i Martí M. Àngels Rius Gavidia

Enginyer de Telecomunicacions per Llicenciada en Informàtica per la

1. Bases de dades, el motor del comerç electrònic......................... 7

2. Base de dades operativa................................................................... 11

3. Data warehouse: base de dades estratègica................................. 38

El primer subsistema el suporta l'anomenada base de dades operativa.

El segon subsistema el suporta una base de dades dissenyada a propòsit per a

En els materials didàctics d'aquest mòdul l'estudiant trobarà la informació in-

1. Conèixer el marc de referència sobre el qual s'han de concebre les aplica-

2. Saber identificar dos grans tipus d'informació, la que fa referència a les

3. Comprendre la importància de les bases de dades com a dipòsit de tota la

4. Entendre els models de dades, que es presentaran com a genèrics, i ser

5. Saber aplicar els mecanismes de manipulació de dades per a gestionar les

6. Comprendre la necessitat d'un data warehouse per a transformar la infor-

7. Ser capaç de recollir tota la informació d'interès per al negoci de manera

1. Bases de dades, el motor del comerç electrònic

Des del punt de vista de la gestió de la informació, veiem un procés de comerç

L'element ("motor") que fa possible la compravenda en l'entorn web són

Es desprèn, doncs, que les bases�de�dades són la tecnologia de gestió de la

1.1. Escenari d'una aplicació de comerç electrònic B2C

1.1.1. B2C des del punt de vista de l'empresa

Un dels objectius principals d'una empresa és la venda dels seus pro-

Per a poder vendre el nombre més gran de productes, el venedor ha de

A més, un punt important per al venedor és la part de la transacció en què

Un altre requisit que ha de satisfer l'aplicació B2C, per a donar suport a la

Un cop l'aplicació cobreix les necessitats de gestió de productes, comandes i

1.1.2. B2C des del punt de vista del client

Per la banda del client, l'objectiu primordial és utilitzar la xarxa per a

El comerç electrònic ha de permetre al client de localitzar ràpidament i

Un cop decidit el producte o productes d'interès, el client espera gestionar

Un cop feta la comanda, el comprador ha de realitzar el pagament. Les propi-

Si el client està satisfet de compres anteriors, pot interessar-li registrar-se. El

1.2. Informació operativa enfront d'informació d'ajut a la presa

Si ens fixem en l'escenari descrit en els subapartats anteriors, veiem que

La informació necessària per a la venda i catalogació de productes és la

La informació útil per a prendre decisions estratègiques és la que ano-

En resum, doncs, les aplicacions de comerç electrònic mantenen

2. Base de dades operativa

En aquest segon apartat ens centrarem en l'estudi de tota la informació que

Inicialment, estudiarem un petit exemple de transacció econòmica via web,

2.1. Agents d'una transacció econòmica

Començarem mostrant un possible procés de compra per mitjà de la web.

Aquest procés de compra electrònica, ens permetrà d'analitzar una seqüència

La figura següent mostra la seqüència d'una transacció econòmica de compra-

La descripció dels passos de la compravenda és la següent:

4. El client confecciona la seva comanda.

5. El venedor presenta el desglossament de la comanda.

6. El client confirma les dades de la comanda.

7. El venedor sol·licita dades al client: d'enviament, contacte, etc.

8. El client complementa els formularis de dades.

9. El venedor comprova que les dades del client siguin vàlides.

10. El client fa el pagament.

11. El venedor envia la comanda al comprador.

La seqüència anterior ajudarà a identificar tots els agents que hi intervenen i

Tampoc és difícil veure que la base de dades té un paper fonamental en aquest

2.2. Disseny de la base de dades

L'objectiu d'aquest segon apartat és dissenyar la base de dades operativa del

Si bé aquestes metodologies són necessàries i imprescindibles per a abor-

2.2.1. Disseny conceptual

L'objectiu de l'etapa de disseny conceptual és obtenir una estructuració

Figura 2. Model conceptual de dades de la base de dades operativa