Gestió de la informació

Bases de dades per a aplicacions B2C

  • Óscar Alavedra i Martí

    Óscar Alavedra i Martí

    Enginyer de Telecomunicacions per la Universitat Politècnica de Catalunya (UPC). Ha desenvolupat la seva experiència professional a la UPC, com a programador i administrador de sistemes informàtics i com a cap de la Unitat de Suport Tècnic per al Servei de Gestió Acadèmica. Col·laborador en diversos projectes de comerç electrònic.

  • M. Àngels Rius Gavidia

    M. Àngels Rius Gavidia

    Llicenciada en Informàtica per la Universitat Politècnica de Catalunya. Professora associada adscrita a l'Escola Universitària Politècnica de Vilanova i la Geltrú des de 1996. El seu àmbit de recerca s'enmarca dins del camp de les bases de dades. Actualment professora pròpia dels Estudis d'Informàtica i Multimèdia de la Universitat Oberta de Catalunya.

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

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 representa 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 ofereix caldrà integrar bé tots els sistemes d'informació de l'empresa, fet que no és una tasca gens fàcil, ja que hi intervenen un gran nombre de processos gestionats per diferents persones i departaments, que molt sovint treballen aïllats 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 darrer 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ó indispensable per a assolir els objectius següents:

  1. Conèixer el marc de referència sobre el qual s'han de concebre les aplicacions 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 informació 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 econò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 centrarem en el comerç electrònic B2C que fàcilment introdueixen els dos agents principals: l'empresa (B) i el client (C). Per tant, podem veure el comerç electrònic B2C com la relació que s'estableix entre el client i l'empresa durant el procés de compra.
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 productes.
Una aplicació per a vendre productes en l'entorn web ha de ser capaç de gestionar el catàleg de productes i facilitar-ne el manteniment. Això implica que haurà de permetre donar d'alta productes, modificar-ne les característiques (preu, descripcions, estoc), eliminar-los del catàleg i consultar la disponibilitat 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 extraure 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 clients 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 caracterí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 propietats 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 diferents sistemes de pagament electrònic la trobareu en el mòdul didàctic "Sistemes 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 comandes 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.
Organitzarem la informació operativa en una base de dades convencional, que anomenarem base de dades operativa. Aquesta base de dades es dissenyarà segons el model entitat interrelació (1) (ER) i utilitzant la tecnologia que ofereixen les bases de dades relacionals.
La informació útil per a prendre decisions estratègiques és la que anomenarem informació d'ajut a la presa de decisions o informació estratè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 utilitzar-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 operacions 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 compravenda:
Figura 1
Figura 1
La descripció dels passos de la compravenda és la següent:
1. El client accedeix a la botiga virtual.
2. El venedor permet la visualització del seu catàleg de productes segons uns criteris de selecció.
3. El client visualitza els productes d'acord amb un dels criteris de selecció, 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 diversos tipus i fluxos d'informació (dades de productes, comandes, pagament, etc.).
De la figura 1, també en resulta clar que el desglossament de la seqüència s'ha realitzat depenent de l'agent que genera un nou flux a cada pas. Trobem l'explicació en el fet que la transacció econòmica és suportada per un entorn 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 interessen 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 intervenen puntualment en el procés de pagament i de les quals no pretenem fer cap model de dades.
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 relacional.
Si bé aquestes metodologies són necessàries i imprescindibles per a abordar 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 estructures 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 considerant, els clients, per mitjà de la web, compren productes i que el mecanisme 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 conceptual 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.
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 entitats 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.
Els clients no registrats compren sense que l'aplicació els reconegui, per tant, malgrat que comprin diverses vegades, es consideren com si fossin clients diferents.
Els clients registrats són aquells dels quals la base de dades conté la informació següent: dades personals, dades sobre el seu historial de compres 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 formularis 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 registrats, 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 les seves preferències. Aquesta informació, pel fet de ser estratègica, també s'emmagatzemarà en la base de dades estratègica. En la base de dades operacional normalment guardarem informació sobre clients que servirà per a establir una classificació de clients per tipus i oferir-los, així, descomptes per a grups o col·lectius. Si la manera d'operar de l'empresa té en compte aquesta classificació 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 diversos 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 cadascun 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
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 general 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 descriure 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 idiomes. 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
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 dades de facturació (a qui enviar la factura) i d'enviament (a qui s'envien els productes de la comanda). Aquestes dades les guardarem en una altra entitat FACTURA_ENVIAMENT que s'interrelacionarà amb COMANDA en grau 1-N.
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: COMANDA, 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é dades 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, podem 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 client i, per tant, convé tenir-la deslligada de la capçalera de la comanda. Com que hi pot haver moltes comandes en un mateix estat i una comanda en tot moment té un únic estat, la interrelació entre COMANDA i ESTAT_COMANDA és 1-N. La mateixa consideració serveix per a les dades referents a la forma d'enviament (FORMA_ENVIAMENT) i a la forma de pagament (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
Figura 5
IDIOMA
A l'entitat idioma s'emmagatzemarà el codi d'idioma amb la seva descripció en un idioma de referència.
Qualsevol entitat que estigui relacionada amb idioma mitjançant una interrelació M-N contindrà els atributs d'interrelació que són la descripció de l'atribut en qualsevol idioma.
Codificació d'idiomes
Suposem l'entitat ESTAT_COMANDA que pot tenir tres estats possibles –pendent, en procés i retinguda, codificats respectivament pels codis 10, 20 i 30. Aleshores, la interrelació DESC_ESTAT contindria per a cada idioma la traducció de cadascun dels valors possibles de l'atribut que descriu l'estat. Per a l'estat 10 en l'idioma 0 (català), el valor de l'atribut seria "pendent", per a l'idioma1 (castellà), "pendiente" i per a l'idioma 02 (anglès) "pending"; per a l'estat 20 en l'idioma 0 el valor associat seria "en procés", en l'idioma 1 "en proceso" i en l'idioma 2 "processing", etc.
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 etapa obtindrem un conjunt de relacions amb els seus atributs, claus primàries i foranes.
Traduirem el model conceptual per parts, considerant l'entorn de les entitats 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ó addicional 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
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
{id_idioma} referencia IDIOMA
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
{id_idioma} referencia IDIOMA
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 continuació:
Figura 7
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)
on {id_idioma} referencia IDIOMA
DESC_PAG (id_pagament, id_idioma, descripcio)
on {id_idioma} referencia IDIOMA
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 comanda 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
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 parà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 empresa, és a dir, aquelles operacions restringides a usuaris amb privilegis.
Dels diferents mecanismes dels quals disposa una base de dades per a gestionar la informació (vistes, procediments emmagatzemats i disparadors), bàsicament n'utilitzaren els procediments, i, en alguns casos, els disparadors. Les vistes no s'utilitzen perquè la majoria d'operacions requereixen paràmetres d'entrada.
També hem de tenir en compte que certes operacions s'han de fer com a unitat bàsica de treball a efectes de concurrència i integritat. Per exemple, una alta de producte implica la inserció a dues taules, la taula de PRODUCTES i la taula DESC_PROD i, en conseqüència, caldrà definir una transacció que contingui 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 venedor 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 realitzaran, 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 (característiques i descripcions) en el catàleg. La primera operació fa una inserció a la taula DESC_PROD afegint les descripcions referents al producte en un idioma.
La segona operació afegeix, a la taula PRODUCTE, les dades que són independents de l'idioma. Noteu que són necessàries ambdues operacions per a fer efectiva l'alta d'un producte i que s'hauran d'executar en una única transacció.
A continuació veurem operacions que permetran de jerarquitzar els diferents tipus de productes de més genèrics a més específics.
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 respectivament
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 superior 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
baixa_producte (id_producte)
L'operació baixa_producte permetrà d'eliminar el producte del catàleg. D'una banda, suprimirà el registre de la taula PRODUCTE corresponent al id_producte especificat i de l'altra, suprimirà les descripcions associades al producte en els diferents idiomes.
3) Modificacions
modifica_producte_desc (id_producte, id_idioma descripcio_curta,
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.
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).
Per a poder sol·licitar els productes d'un determinat tipus, el client ha de poder saber quins agrupaments de productes té el catàleg. Per tant, serà necessària una operació que mostri la classificació dels productes.
mostra_tipus_producte (id_tipus_producte, id_idioma)
Aquesta operació retornarà el conjunt de tipus de productes que depenen d'un tipus més genèric, que és l'indicat pel paràmetre d'entrada.
L'usuari també voldrà consultar les dades de productes segons altres caracterí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 concret 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ó, unitats 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 diversos 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çalera, i inserir igualment les dades del producte a la taula LINIA_COMANDA.
crea_comanda (data_inici, adreça ip)
afegeix_comanda (id_producte, unitats, id_comanda)
Aquestes operacions donen d'alta una comanda i no retornen cap conjunt de registres.
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:
elimina_comanda (id_linia, id_comanda)
Aquesta operació elimina el registre associat a la taula LINIA_COMANDA.
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.
resultat_economic_comanda (id_comanda, num_transaccio,
data_transaccio, id_resultat_transaccio
Quan canvia l'estat de la comanda també cal actualitzar el camp id_estat_co-manda. L'operació corresponent seria la següent:
estat_comanda (id_comanda, id_estat)
Observeu que el venedor farà aquesta darrera operació per mitjà de la xarxa privada (intranet).
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, retornarà 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 emmagatzemats.
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 reconeixement 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 procediments 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 contrasenya. És per això que en el formulari d'alta es demana una pregunta i la corresponent 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
Quan un client entra a la xarxa pública dins l'àrea clients, s'ha de comprovar que l'adreça de correu electrònic (2) 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 contrasenya corresponguin a un dels clients registrats. Retornarà una variable booleana amb el resultat de la comprovació, i el codi de client en cas de client vàlid; aleshores el codi de client s'emmagatzemarà en una variable global per a fer-lo servir posteriorment.
Un cop reconegut el client, s'han de determinar els descomptes que li pertoquen.
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 emmagatzemats.
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àlogament, 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 magatzem de dades i, tot seguit, veurem un exemple de model de dades orientat 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 preguntes 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òrica. La nostra base de dades operativa guardarà informació de les vendes durant els darrers seixanta o noranta dies, marge de temps insuficient per a extrapolar el comportament de les vendes i planificar l'aprovisionament futur.
La segona pregunta es formularia per a analitzar els resultats obtinguts com a conseqüència d'una determinada acció vers el mercat, per a veure l'efecte produït i plantejar-se de fer més campanyes publicitàries o no, o, si més no, per 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, àrea o país. Aquesta anàlisi ens permetrà d'arribar a conèixer les preferències de compra dels nostres clients segons la zona geogràfica i així poder oferir promocions per àrea o zona.
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 construcció 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.
L'anàlisi de dades s'ha de fer a partir d'informació estable, no canviant, com és el cas de la informació que conté la base de dades operativa. És per això que ens plantegem la necessitat de considerar dos entorns: l'entorn OLTP (3) , suportat per la base de dades operativa, i l'entorn OLAP (4) , suportat per la base de dades estratègica. Tots dos dipòsits tenen finalitats diferents i, per tant, s'estructuren 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 estudiarem 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 (vendes, clients, enviaments, etc.), no a partir dels processos que fan les aplicacions. 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 informació que formarà part del data warehouse ha de passar prèviament per un procés d'integració a diversos nivells (noms, mesures de camps, implementació 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 emmagatzema 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.
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 operacional. 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 dimensions.
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 conseqüè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.
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
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 multidimensional.
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 dades 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 informació 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 derivar 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 comanda, a part del producte, quantitat i preu, és l'instant en què la direcció considera 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 de la definició dels fets. Ens trobem que no hi ha cap taula anomenada VENDES ni cap atribut amb aquest nom, però sabem que les vendes esdevenen després d'haver-se confeccionat una comanda que passa per diversos estats fins a considerar-se servida. Des del punt de vista estratègic, cal determinar què s'entén per venda i, un cop aclarit aquest punt, podrem determinar quines dades de la base de dades operativa seran considerades vendes i, per tant, podran passar a formar part de les files de la taula de fets.
El que resulta clar és que les vendes estan estretament relacionades amb les comandes, 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 informació ú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 dades operativa, però es podria donar el cas en què calgués informació d'altres fonts, per exemple, les dades d'un altre departament. Aleshores, hi ha altres consideracions que cal tenir en compte, com ara la integració de dades, des del punt de vista del format, semàntic, etc. Per tant, la informació recollida de diverses fonts a mesura que es produeixen fets, s'ha d'integrar per a poder passar a formar part del data warehouse.
Figura 12. Extracció, Integració, Càrrega
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) coneix 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 oferirà 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ó empresa-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 partir 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 quedar-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 columna 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.
11034_m3_15.gif
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 venuts 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 informació, es pot fer una gràfica, de manera que es visualitzi clarament l'augment i la disminució 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 reclamen 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.