Tietokantakaavion suunnittelu: Miksi asiakkaasi eivät voi tehdä kyselyjä tietoihisi (ja miten asia korjataan)

Jos olet kehittämässä SaaS-alustaa tai datatuotetta, on tärkeää pohtia, mitä BI-työkaluja asiakkaasi jo käyttävät. He haluavat yhdistää Tableau-, Power BI-, Logi Symphony -työkalut tai oman analytiikkaympäristönsä suoraan dataasi. He haluavat päästä käsiksi dataan SQL:n avulla ja tehdä kyselyjä alustallasi samalla tavalla kuin muissakin järjestelmissä.

Odotukset eivät kuitenkaan täysin vastaa todellisuutta, kun tukipyynnöt alkavat tulvia sisään. Tämä on yleinen ongelma itsenäisten ohjelmistotoimittajien (ISV) keskuudessa, jotka saavat keskimäärin 6–20 analytiikkapyyntöä kuukaudessa insightsoftwaren ja Hanover Researchin tutkimuksen mukaan. Lähes puolet (45 %) organisaatioista käyttää 40–59 % ohjelmistokehitysmäärärahoistaan analytiikan kehittämiseen ja tukemiseen.

Vaikka alusta toimii täysin suunnitellusti, asiakkaat saattavat joutua umpikujaan. He eivät osaa päättää, mihin taulukoihin liittyä. Kenttien nimet eivät vastaa heidän odotuksiaan. Tiedoissa loogisesti olemassa olevat suhteet eivät tule esiin missään, mistä heidän työkalunsa voisi ne havaita. Kyselyt, joiden pitäisi olla yksinkertaisia, eivät tuota mitään hyödyllistä tulosta tai eivät edes toimi. Alusta toimii täysin suunnitellusti. Asiakkaat ovat silti umpikujassa.

Tämä on yksi yleisimmistä ongelmakohdista SaaS- ja datapalvelualustojen toimittajien kannalta, eikä sitä lähes koskaan saada ratkaistua vaihtamalla tietokantaa. Tässä artikkelissa käsittelemme, miksi asiakkaillasi on vaikeuksia tehdä tietokyselyjä ja miten ongelma voidaan korjata.

Miksi sisäiset mallit eivät sovellu analytiikkaan

Operatiiviseen sovellukseen suunniteltu skeema ja analytiikkakäyttöön suunniteltu skeema ratkaisevat erilaisia ongelmia. Operatiiviset skeemat on optimoitu kirjoitusnopeuden, transaktioiden johdonmukaisuuden ja sovelluslogiikan kannalta siten, että taulukot on rakennettu sen mukaan, miten sovellus lukee ja kirjoittaa tietoja, eikä sen mukaan, miten analyytikko niitä tarkastelee.

Tämä tarkoittaa usein erittäin normalisoituja rakenteita, joissa käsite, jonka asiakas näkee yhtenä kokonaisuutena, on hajautettu useisiin taulukoihin. Kenttien nimet, jotka olivat järkeviä järjestelmän kehittäneille insinööreille, eivät välttämättä ole käyttäjäystävällisiä, kun taas sovellusohjelmistossa olevia avainsuhteita ei ole määritelty tietokannassa, minkä vuoksi BI-työkalut eivät pysty tunnistamaan niitä.

Ongelma juontaa juurensa itse suunnittelusta: odotetaan, että tietomalli, joka on luotu yhtä tarkoitusta varten, toimisi täysin eri tarkoitukseen.

Missä useimmat ohjeet menevät pieleen

Jos asiakkaillasi on vaikeuksia skeemasi kanssa, vaisto kehottaa meitä usein pitämään sitä skeeman suunnitteluongelmana.

Vaikka esimerkiksi dokumentaation parantaminen, sekavien kenttien uudelleennimeäminen ja uusien näkymien luominen ovat järkeviä toimia, kun aloitetaan alusta, ne voivat jo käytössä olevalla tuotantoympäristöllä, jossa on asiakkaita, aiheuttaa enemmän ongelmia kuin ne ratkaisevat. Esimerkiksi:

• Kenttien uudelleennimeäminen katkaisee olemassa olevat integraatiot.

• Taulukoiden uudelleenjärjestely edellyttää koordinoituja siirtoja.

• Rinnakkaisen, analytiikkaan soveltuvan skeeman lisääminen tarkoittaa kahden tietomallin samanaikaista ylläpitoa, mihin liittyy kaikki siitä aiheutuva synkronointityö.

Periaatteessa tämä lähestymistapa ei osu ongelman ytimeen.

Skeeman julkistaminen on tuotepäätös

Sisäisen tietomallisi ja asiakkaiden hakukyselyjen välinen ero on pohjimmiltaan yhteysongelma.

Kun asiakas yhdistää BI-työkalunsa alustaanne, sisäisen tietomallinne ja asiakkaan työkalun edellyttämän rajapinnan välillä on oltava jonkinlainen muunnoksikerros. Tämä muunnoksikerros määrää, mitkä taulujen nimet asiakkaalle näkyvät, mitkä suhteet työkalunsa pystyy tunnistamaan, mitkä tietotyypit raportoidaan takaisin ja tuottaako yksinkertainen vedä ja pudota -kysely Tableau-ohjelmassa tuloksen vai virheen.

Useimmat tietojen toimittajat eivät pohtineet tätä käännöskerrosta nimenomaisesti. Yhteys toimii, minkä vuoksi tuntuu siltä, että homma on hoidettu. Mutta ”toimii” ja ”haettavissa” ovat eri asioita, ja juuri niiden välisessä kuilussa syntyvät tukipyynnöt.

Jos skeeman paljastamista pidetään tarkoituksellisena tuotepäätöksenä, on syytä esittää erilaisia kysymyksiä, kuten:

• Mitä asiakkaiden on voitava tehdä näiden tietojen avulla?

• Mitä heidän BI-työkalunsa tarvitsee nähdä, jotta nämä tehtävät sujuisivat vaivattomasti?

• Miten sisäisen mallin monimutkaiset tai sisäkkäiset rakenteet tulisi tasoittaa relaatiotaulukoiksi, joita analyytikot voivat käyttää työssään?

• Mitkä suhteet on tuotava nimenomaisesti esiin metatiedon avulla, vaikka sovellus noudattaisikin niitä koodin tasolla?

Näiden kysymysten ratkaiseminen edellyttää sellaisen käännöskerroksen rakentamista, joka sijaitsee tietojesi ja asiakkaidesi työkalujen välissä.

Miten kuljettajat ratkaisevat tämän ongelman

Erityisesti alustallesi kehitetty ohjain pystyy hoitamaan tämän muunnoksen. Ohjain voi hakea tietoja sisäisestä tietomallistasi, kuvata ne asiakkaidesi odottamaan relaatiorakenteeseen, tuoda esiin suhteet ja skeeman metatiedot, jotka heidän työkalunsa pystyvät tunnistamaan automaattisesti, sekä palauttaa tulokset standardinmukaisen SQL-rajapinnan kautta ODBC- tai JDBC-protokollan avulla.

Asiakkaan näkökulmasta BI-työkalun liittäminen toimii samalla tavalla kuin minkä tahansa hyvin jäsennellyn tietokannan kanssa: se on käyttäjäystävällistä, vaikka sisäisen mallin taustalla oleva monimutkaisuus jää asiakkaalta huomaamatta.

Sinun näkökulmastasi katsottuna sisäinen rakenne ei muutu.

Tämä on arkkitehtuuri, jota varten insightsoftwaren Simba SDK on kehitetty. SDK tarjoaa kyselyjen jäsentämisen, skeemakartoituksen ja metatietojen tunnistamisen infrastruktuurin, jota räätälöityjen ohjainten kehittäminen edellyttää. Se huolehtii SQL-kielen kääntämisestä tietovarastosi suorittamiksi kyselyiksi, sisäisten rakenteiden kartoittamisesta relaatiotaulukoiksi sekä BI-työkalujen moitteettoman toiminnan edellyttämien skeematietojen esittämisestä.

Tämän ansiosta kehitystiimisi voi keskittyä tietolähteiden integrointiin ajurien infrastruktuurin sijaan. Alustasi ja asiakkaidesi työkalujen välinen käännöskerros rakennetaan kerran, sitä ylläpidetään alustasi kehittyessä, ja se tarjoaa yhdenmukaisen SQL-käytön kaikissa asiakkaidesi käyttämissä BI-työkaluissa.

Loppujen lopuksi asiakkaat, jotka eivät pysty hyödyntämään tietojaan, eivät pysy asiakkaina. Mutta rakentamalla käännöskerroksen tarkoituksellisesti sen sijaan, että se jätettäisiin jälkikäteen, voit luoda alustan, joka toimii niille, jotka siitä ovat riippuvaisia. Simba SDK tarjoaa alustatiimeille infrastruktuurin tämän toteuttamiseen ilman, että ajurikehitystä tarvitsee aloittaa tyhjästä, sillä se sisältää skeemakartoituksen, metatietojen tunnistuksen, SQL-jäsennelyn sekä standardipohjaisen ODBC- ja JDBC-tiedostomuodon tuotannon. Tiimisi yhdistää SDK:n tietovarastoonne ja määrittää asiakkaiden tarvitseman skeeman esitystavan.

Haluatko tietää lisää? Katso, kuinka rakennamme ODBC-ajurin 30 minuutissa: Simba SDK:n live-esittely.