A Decathlon hűségprogramja és egy adattárház probléma

A minap a Decathlonban (népi nyelven Kecsua, Kekua) jártam. Fizetés közben a pénztáros megkérdezte, hogy

  • van hűségkártyája?
  • Nincsen.
  • Adhatok egyet?
  • Természetesen.

Kaptam egy üres jelentkezési lapot, melynek tetején ott figyelt egy vonalkód. Miután a pénztáros lehúzta az összes árut, leolvasta a vonalkódot is. Így bekerült az alaprendszerükbe, hogy ezt a vásárlást az 1111 vonalkódú vevő eszközölte. Egyelőre csak ennyi, mert még nem töltöttem ki a jelentkezési lapot, így nem tudják, hogy az 1111 vonalkódú vevő mögött Kővári Attila áll.

Eljön az este és elindul a Decathlon adattárházának betöltője. Elkezdődik a vevő dimenziótábla feltöltése. A betöltő odaér az 1111 vevőkódhoz. Betölti a dimenzió táblába, majd mivel semmilyen jellemzőmet sem találja (név, cím, kor, ...) feltölti a dimenziótábla attribútumait csupa „ismeretlen"-nel.

Kisvártatva elindulnak a ténytábla betöltők is és összepároztatják az 1111 vevő jellemzőit és az 1111 vevő vásárlását. A betöltés sikeresen lezárult, az ismeretlen adatok belebetonozódtak az adattárházba.

De ekkor Kővári Attila kitölti a jelentkezési lapot és visszaküldi a Decatlonnak. Az ügyintézők felbontják a levelet majd bemennek a Decatlon számlázó rendszerébe és kitöltik az 1111-es vevő adatait. Neve: Kővári Attila, Neme: férfi, kedvenc sportja: Hegymászás, stb.

Este újra elindul az adattárház betöltése és a betöltő program észreveszi, hogy hopsz, az 1111 számú vevő attribútumai megváltoztak. Lejáratja (lezárja) az „ismeretlen" jellemzőket tartalmazó sort és létrehoz egy új verziójú rekordot, amiben nyilvántartja, hogy mától fogva az 1111 számú vevő nem ismeretlen, hanem ő Kővári Attila, aki férfi és szeret hegyet mászni. Ha legközelebb elmegyek a Decathlonba, akkor a vásárlásom mellé már nem egy ismeretlen jellemzőjű vevőt kötnek, hanem engem személyesen az összes tulajdonságommal együtt.

Technikailag ez helyes is. Semmi kivetni való nincs benne, de nézzük meg az üzleti felhasználók oldalát. Őket vajon érdekli, hogy a 1111 vevő tegnapig ismeretlen volt, de mától már nem az? Nem. Ők arra kíváncsiak, hogy mit vásárolnak a férfiak, mennyit költenek a férfiak, milyen terméket vásárolnak azok, akik a hegymászást jelölték meg első helyen stb. És baromira nem érdekli őket, hogy mit vásároltak az „ismeretlen" vevők. Csakhogy az én első vásárlásom még egy ismeretlen vevőre lett rögzítve

Az adattárház definíciója szerint az nem változó, azaz ami egyszer bekerült az úgy is marad. Ha azonban betartanánk ezt a szabályt, akkor kitolnánk az üzleti elemzőkkel, amit nem szeretnénk, hiszen nekik építettük az adattárházat. Kivételt kell tehát tennünk és az ilyen típusú problémák esetén bizony felül kell csapnunk az adattárházban tárolt adatokat az új információkkal. Az én korábbi, még ismeretlen vevőként elkövetett vásárlásom adatait át kell vezetni Kővári Attila nevű vevőre. De - és itt jön az igazi probléma - ha nekem megváltozik a címem, a családi állapotom, akkor az adattárházból le kell tudni kérdezni, hogy mennyit vásároltam amíg nem voltam házas, mennyit vásároltam, amíg Budapasten laktam, stb. Azaz ebben az esetben már nem csaphatjuk felül az adattárházban a régi címemet, családi állapotomat az újjal.

A probléma nem új. Kimball az „Early Arriving Fact" címszó alatt tárgyalja, de magyarul itt a BI blogon is olvashat róla:

  • Az eszköz független megoldásról a hiányzó dimenzió elemek című cikkben olvashat részletesen. Röviden összefoglalva ennek tartalmát annyit kell tennünk, hogy az 1111 vevő mellé el kell tárolnunk, hogy még „nem teljes a kitöltöttsége". A betöltő program pedig figyeli ezt a jelzőt, és amíg meg nem változik „a rekord hiánytalan"-ra addig felül kell csapnia a rekordban tárolt értéket. Utána azonban minden változást historikusan nyomon kell követnie.
  • Az eszközfüggő megoldásról - azaz arról, hogy mindezt hogyan lehet a gyakorlatban megvalósítani a Microsoft adatbetöltő eszközével - az "Early Arriving Facts" adattárház probléma megoldása című cikkben olvashat.

A mostani cikknek az volt a célja, hogy egy létező adattárház építési problémát egy magyarországi példán keresztül tegyen szemléletessé. A Decathlonnak nem építek adattárházat és azt sem tudom, hogy van-e nekik, és ha van, akkor kezelik-e a problémát. A lényeg a probléma volt, amit a sportáruház példáján keresztül érthetően be tudtam mutatni. Remélem sikerült.

Kővári Attila - BI projekt

hozzászólás

Én az ETL folyamat megbonyolítása helyett (ahol is elágazást kéne tennünk az adatfolyamba, attól függően, hogy mi az értéke a kitöltöttségnek) javasolnám az AS-IS lekérdezések használatát az AS-WAS-al szemben(ahol a jelenlegi dimenzió állapothoz kell csak hozzákapcsolni a tény adatokat). Ahol pedig már az első vásárláshoz is fontos a pontosan kitöltött AS-WAS dimenzió adatok használata - tessék inkább egy új / javított / konszolidált / reporting célú "vásárló" táblát létrehozni. A kitöltési hibák, többszörös létrehozások, stb adathibák javításának is könnyebb így teret adni, mint az alap DW táblákban update-elgetni, az mindíg fájdalmasan erőforrás igényes dolog szokott lenni. Egyébként ügyes dolog ez az élő példával való játék :-), nagyon szemléletes. üdv, Csillag Péter

Érdekes egy szemlélet, csak 1 gond: a Decathlon nem maga miatt találta ki a hűségkártyát sőőőt az sem érdekli, h házas-e vagy sem. A vásárló kényelmét szolgálja, mivel nem kell papírdarabokat őriznie, hanem elég, h ha csak a kártyáját hozza magával a vásárló, így le tudjuk kérni blokkot. A cím sem egy fontos tényező. Ha a vásárló meg akarja kapni a neki járó vásárlási utalványt, akkor nyilván jelezni fogja a címváltozást. RÖviden tömören a hűségkártya nem a Decathlonnak fontos, hanem a vevőnek.

Új hozzászólás