Skilningur á gagnalíkani Abler
Hleð…
Hvernig prógrömm, skráningar, hópar, viðburðir og mæting tengjast saman í Abler API-inu — og hvernig má útfæra þetta í eigin CRM-kerfi, gagnagrunni eða skýrslutóli án þess að tapa þeim tengslum sem máli skipta.
Allt í Abler hangir á tveimur keðjum færslna sem báðar enda á einstaklingi. Önnur lýsir skráningu — hver skráði sig í hvað. Hin lýsir rekstrarlegri virkni — hvað var í raun framkvæmt og hver tók þátt.
Skráning
Notandi→Áskrift→Þjónusta
Áskrift (Subscription) segir þér að einhver hafi skráð sig í prógramm.
Rekstrarleg virkni
Þjónusta→Hópur→Viðburður→Viðburðarþátttakandi→Notandi
Viðburðarþátttaka segir þér hvað viðkomandi einstaklingur tók í raun þátt í.
Sami notandi getur því birst á báðum hliðum. Afgangurinn af þessari grein fer í gegnum hvert fyrirbæri fyrir sig, og sýnir síðan hvernig þú getur sameinað þau í þínu eigin kerfi.
1
Fyrsta hugtakið sem vert er að hafa í huga: það sem Abler-viðmótið kallar Prógramm (Program) er í API-inu táknað sem Service (þjónusta). U10 fótbolti, vor 2026 er prógramm séð frá sjónarhóli notanda, en undirliggjandi API-fyrirbærið er Service.
Í þínu eigin kerfi skaltu tákna það með því hugtaki sem þú notar fyrir prógramm eða námskeið, og geyma Abler Service ID sem ytra auðkenni. Þannig færðu stöðugan lykil til að para við þegar áskriftir, hópar, viðburðir og aðrar færslur berast síðar.
Tengdu aldrei færslur með nöfnum
Nöfn breytast, og mismunandi prógrömm geta haft nákvæmlega sama nafn. Notaðu Abler-auðkennin til að koma á öllum tengslum.
2
Prógramm getur haft eina eða fleiri vörur (Products) tengdar sér. Munurinn er í grófum dráttum þessi:
Service
Það sem einhver tekur þátt í — U10 fótbolti, vor 2026.
Product
Það sem hægt er að kaupa eða skrá sig fyrir — skráningar- eða greiðslumöguleikarnir sem tengjast því prógrammi, t.d. Allt tímabilið eða Mánaðarlega.
Hvort vörur þurfa eigin færslur í þínu kerfi fer eftir því hvað þú þarft kerfið til að gera. Ef þú ert aðallega að fylgjast með fólki og þátttöku, þá skiptir samband prógramms og áskriftar mestu máli. Ef þú þarft líka ítarlegar viðskiptaupplýsingar, skaltu halda Product sem sjálfstæðu fyrirbæri líka.
3
Áskrift (Subscription) táknar skráningu eða aðild einstaklings í prógrammi. Hún inniheldur serviceId, productId og notandans Abler userId, auk síns eigin einkvæma auðkennis, stöðu, upphafsdags, lokadags og stofnunardags.
Notandi→Áskrift→Þjónusta
Subscription { userId: 123, serviceId: 456, productId: 789 }
→ Notandi 123 er skráður í prógramm 456 í gegnum vöru 789.
Í þínu kerfi verður áskriftin tengifærsla á milli einstaklingsins og prógrammsins — kallaðu það skráningu, innritun eða þátttökufærslu. Einn einstaklingur getur haft margar áskriftir yfir tíma, og prógramm hefur eðlilega marga áskrifendur, þannig að áskriftin segir þér hver er skráður í hvað.
4
Áskrift segir þér að einstaklingur sé skráður í prógramm. Hún segir ekki til um hvort viðkomandi hafi mætt á einstakar æfingar innan þess.
Jane er með áskrift að U10 fótbolta, vor 2026 — þriggja mánaða prógrammi sem inniheldur 24 æfingar. Kerfið þitt ætti að geyma eina áskrift fyrir skráningu Jane (stundum fleiri en eina), síðan 24 viðburði fyrir einstakar æfingar og, mögulega, 24 mætingarfærslur sem sýna hvort hún mætti á hverja þeirra.
Áskrift
Heildarskráningin.
Viðburðarþátttaka
Virkni á tilteknum degi og tíma.
Það að halda þessu tvennu aðskildu er það sem gerir þér kleift að skila skýrslum um skráningar, virka þátttakendur, tíðni þátttöku, mætingu, viðhald þátttakenda, æfingar sem haldnar voru og þátttökugráðu eftir prógrammi.
5
Þegar prógramm er sett upp eru þátttakendur skipulagðir í hópa (Groups). Í hlutum API-sins geta þessir birst sem ageGroupId eða sambærilegt hópsauðkenni. Rekstrarleg virkni er yfirleitt skipulögð í kringum hópa: prógrammið U10 fótbolti, vor 2026 gæti innihaldið hópinn U10 þriðjudagsæfing, og hópurinn heldur utan um þá viðburði sem í raun eru haldnir.
Þjónusta→Hópur→Viðburður
Tvennt sem þarf að hafa í huga
Ekki meðhöndla reiti eins og productOption.groupIds sem endanleg tengsl milli vöru og rekstrarhóps hennar — þeir geta verið núll, og sambandinu getur verið breytt hvenær sem er. Og prógrömm geta, og gera oft, deilt hópum; þetta fer eftir því hvernig félagið er sett upp.
6
Viðburður er raunveruleg áætluð athöfn — eitt tilvik í framkvæmd prógramms.
Prógramm U10 fótbolti, vor 2026
Hópur U10 þriðjudagsæfing
Viðburðir þri. 8. sept. 17:00 · þri. 15. sept. 17:00 · þri. 22. sept. 17:00 · …
Því ætti prógramm aldrei að vera kortlagt sem viðburður í þínu kerfi. Prógrammið er það sem einhver skráir sig í; viðburðurinn er ein æfing innan þess. Geymdu hvern viðburð með upprunalegu Abler viðburðarauðkenni hans og, þar sem við á, haltu hópsauðkenni hans og prógrammssamhengi í stað þess að treysta eingöngu á nafn viðburðarins.
7
Síðasta lagið er einstaki þátttakandinn í viðburði. Þetta svarar hver tók þátt í þessari tilteknu æfingu og, þar sem mætingarupplýsingar eru til staðar, mætti viðkomandi. Það er önnur spurning en hver er skráður í prógrammið — sem kemur frá áskriftum.
Viðburður→Viðburðarþátttakandi→Notandi
Tengiliður Jane Smith
→ Áskrift → U10 fótbolti, vor 2026
→ Viðburðarþátttaka → Æfing, 8. september
→ Viðburðarþátttaka → Æfing, 15. september
→ Viðburðarþátttaka → Æfing, 22. september
Mæting án áskriftar er eðlileg
Það er mögulegt að mæta á viðburð án þess að hafa áskrift — stök þátttaka (drop-in) er algeng í sumum prógrömmum. Líkanið þitt þarf að geta tekið tillit til þess.
8
Áskriftarupplýsingar geta stundum birst í kringum viðburðarþátttöku, en samþættingin ætti ekki að treysta á að viðburðarþátttakandi beri áreiðanlegt áskriftarauðkenni. Öruggari uppbyggingin tengir hverja staðreynd sjálfstætt:
Mæting
Viðburðarþátttakandi→Notandi
Viðburðarþátttakandi→Viðburður
Dragðu síðan prógrammssamhengið út frá Viðburður → Hópur → Þjónusta.
Skráning
Áskrift→Notandi
Áskrift→Þjónusta
Haldið algjörlega aðskildu frá mætingu.
Þetta heldur skráningu og mætingu sem aðskildum staðreyndum, sem er mun hreinna líkan, og það tekur á þeim tilvikum þar sem þátttakandi er á viðburði án þess að einföld ein-á-móti-einni áskrift liggi þar að baki.
9
Þegar þetta er sett saman lítur uppbyggingin svona út. Skráningarhliðin er vinstra megin, framkvæmdarhliðin hægra megin, og báðar mætast við Notanda og Þjónustu.
Skráningarsýn
Hver skráði sig í hvaða prógrömm? — Þjónusta + Áskrift + Notandi
Þátttökusýn
Í hvaða viðburðum tók viðkomandi í raun þátt? — Hópur + Viðburður + Viðburðarþátttakandi + Notandi
10
Sanngjarn upphafspunktur fyrir flest CRM-kerfi og gagnagrunna. Þín eigin fyrirbæranöfn geta fylgt núverandi arkitektúr — mikilvægi hlutinn er að varðveita tengslin.
Abler | Í þínu kerfi | Tilgangur |
|---|---|---|
UserProfile / User | Tengiliður / Einstaklingur | Einstaklingurinn |
Service | Prógramm | Prógrammið eða athöfnin í heild |
Product | Vara / Prógrammsvalkostur | Valkvæð viðskiptaleg vara |
Subscription | Innritun / Skráning | Tengir einstakling við prógramm |
Group / Age group | Prógrammshópur / Hópur | Rekstrarleg hópaskipting |
Event | Æfing / Viðburður | Einstök framkvæmd athafnar |
EventPlayer / Participant | Mæting / Viðburðarþátttaka | Tengir einstakling við viðburð |
11
Fyrir hvert fyrirbæri sem flutt er inn frá Abler skaltu geyma upprunalega Abler-auðkennið sem ytra auðkenni — til dæmis abler_user_id, abler_service_id, abler_subscription_id, abler_group_id, abler_event_id og abler_event_participant_id.
Þetta gerir samþættingunni kleift að uppfæra eða búa til (upsert) frekar en að búa til nýjar færslur í hvert sinn sem gögn eru sótt, og einfaldar tengslaleysi: þegar áskrift 98765 berst með serviceId = 456, flettu upp prógramminu þar sem abler_service_id = 456 og tengdu það.
12
Flyttu inn foreldrafærslur á undan barnafærslum svo hægt sé að leysa úr öllum tengslum um leið og þau berast.
Búðu til eða uppfærðu prógrammsfærslur, og haltu Abler Service-auðkenninu.
Búðu til þá viðskiptalegu eða skráningarvalkosti sem þú vilt að séu til staðar.
Fyrir hverja, notaðu userId til að finna einstaklinginn og serviceId til að finna prógrammið. Þetta myndar innritunina.
Sæktu rekstrarlegu hópauppbygginguna, og haltu Abler hóps- / aldurshópsauðkenninu.
Búðu til einstaka æfingar og tengdu þær við hóps- og prógrammssamhengi þeirra.
Fyrir hvern þátttakanda, tengdu einstaklinginn við viðburðinn. Þetta gefur þér þátttöku- og mætingargagnasafnið.
13
Notandi auðk. 1001 · Jane Smith
Þjónusta auðk. 2001 · U10 fótbolti, vor 2026
Vara auðk. 2101 · Allt tímabilið
Áskrift auðk. 3001 · userId 1001 · serviceId 2001 · productId 2101
Hópur auðk. 4001 · U10 þriðjudagur
Viðburður auðk. 5001 · hópur 4001 · U10 æfing · 15. september
Viðburðarþátttakandi notandi 1001 · viðburður 5001 · Mætti
Jane Smith
→ Innritun → U10 fótbolti, vor 2026 (frá áskriftinni)
→ Mæting → U10 æfing, 15. september (frá viðburðarþátttakandanum)
Bæði vísa til sama einstaklingsins, en lýsa ólíkum hlutum.
14
Fyrir fyrsta áfanga skaltu tryggja að þessi tengsl séu rétt áður en þú flytur inn hvert einasta svæði sem API-ið býður upp á. Mikilvægustu auðkennin eru notandaauðkenni (einstaklingurinn), Service-auðkenni (prógrammið), áskriftarauðkenni (skráning viðkomandi einstaklings), hóps- / aldurshópsauðkenni (rekstrarhópurinn), viðburðarauðkenni (einstök æfing) og viðburðarþátttakandaauðkenni / notandaauðkenni (þátttaka í þeirri æfingu).
Þegar þetta er komið á hreint er tiltölulega auðvelt að bæta við prógrammseiginleikum, dagsetningum, stöðu, lýðfræðiupplýsingum, mætingarstöðu og greiðsluupplýsingum.
Það eina sem ber að forðast
Ekki fletja allt út í eitt fyrirbæri. Prógrömm, skráningar og viðburðir hafa ólíkan líftíma og ólík mörg-á-móti-mörgum tengsl. Hugsaðu um Abler sem veitanda tveggja tengdra gagnasafna — hver hefur skráð sig í hvað og í hverju tók viðkomandi í raun þátt — sem saman gefa mun heildstæðari mynd af þátttöku en hvort um sig eitt og sér.