BI Projektin kuvaus

Yleinen kuvaus prosessimaisesti:

Liiketoimintatarpeiden määritykset

Tämä on kaiken perusta. Liiketoiminta vaatimukset ja niiden lisäarvo ohjaa päätöksiä kaikilla kolmella osuudella. Nämä vaikuttavat rajauksiin ja suunnitelmiin.

Dataprofiili raportit

Profilointi auttaa huomattavasti mallinnuksessa. Se tarkoittaa käytännössä kantaa tutustumista, johon helposti kuluu huomattavasti aikaa ’käsipelillä’

Liiketoimintaprosessien mukainen dimensionaalinen malli

Dimensionaalinen mallinnus Excell illä tarkoittaa lähde ja kohdetaulujen datan ja kenttien mäppäystä, sekä tietotyyppien tilantarpeen laskentaa. Lisäksi sen perusteella saadaan kannan luontilause. Tästä luetaan mallinnusvälineeseen (Visio, ErWin jne.) kuvaus dokumentointia ja ylläpitoa varten.

Nimeämiskäytännöt

On olemassa erilaisia nimeamiskäytäntöstandardeja ja ehdotamme käytettäväksi organisaation normaalinkäytännön mukaisia nimiä. Jos on tarpeen, otetaan käyttöön esimerkiksi seuraavan lainen jota sovelletaan tarpeen mukaan:

Dim_Customer

Fact_Sales

Idx_pk_Fact_Sales

Idx_Dim_Customer

Relaatiokannan fyysinen malli

Luo skripti mallinnusvälineillä tai käsin. Skriptissä on oltava partitionti ja sen elinkaarenhallinta. Toisin sanoen uusien partitioiden luonti lennossa tai etukäteen niin paljon partitioita, että ne riittävät halutulle ajanjaksolle (esim. 5 vuotta)

ETL prosessien suunnittelu ja toteutus

Dokumentissani ja tässä blogissa toisaalla ’invenco ETL_Specification Methodology ToC’ löytyy kuvaus ETL prosessien määrityksistä siinä muodossa, kun suosittelemme sitä käytettäväksi

SCD – hitaasti muuttuvat dimensiot

Hitaasti muuttuvien dimensioiden käsittelyt voidaan jakaa kahteen päätyyppiin. Nämä ovat yleisesti tunnettu Type1 ja Type 2 nimillä. Lisäksi on olemassa rajoitettu historiointi vaihtoehto, jossa nämä yhdistetään ja sitä kutsutaan Type 3:ksi. Joskus kuulee käytettävän vielä Type 0 nimitystä, mutta tämä tarkoittaa yksinkertaisesti, ettei muutosta käsitellä mitenkään. Tietoja ei myöskään silloin muuteta. Viimeisenä voidaan mainita Type 4, jolla tarkoitetaan historiataulua. Se on kokonaan uusi taulu.

Tyyppi 1

Tässä tapauksessa tietoja ei historioida lainkaan, vaan uusi tieto korvaa aiemman.

Esimerkiksi:

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State
123	ABC	Acme Supply Co	CA

Muuttuu uuden tiedon saapuessa:

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State
123	ABC	Acme Supply Co	IL

Tyyppi 2

Tässä tapauksessa toteutuu täysi historiointi lisäämällä uusi rivi, kun historioitava tieto muuttuu. Kullakin rivillä tulee olemaan sama luonnollinen avain ja uudelle riville muodostetaan uusi synteettinen avain (surrogaatti)

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Version
123	ABC	Acme Supply Co	CA	0
124	ABC	Acme Supply Co	IL	1

Usein käytetty tapa on lisätä muuttuneen tiedon mukaan muutos pvm, jonka käyttöä on syytä välttää todella suurissa dimensiotauluissa. Varsinkin jos käytössä ei ole tehokkaita pakkaus tekniikoita.

Supplier_Key	Supplier_Code	Supplier_Name	Supplier_State	Start_Date	End_Date
123	ABC	Acme Supply Co	CA	01-Jan-2000	21-Dec-2004
124	ABC	Acme Supply Co	IL	22-Dec-2004

Tyyppi 3

Tässä tapauksessa käytetään rajoitettua historiointia lisäämällä ennalta sovittu määrä sarakkeita tauluun ilmaisemaan muutamia kertoja muuttuvia historiointeja. Tämä soveltuu erityisen hyvin tapauksiin, joissa tiedetään ettei seuranta/raportointi jaksolla tule koskaan kun muutamia muutoksia ko. tietoihin. Haittapuolena on mahdollisesti hankala toteutustapa.

Supplier_Key	Supplier_Code	Supplier_Name	Original_Supplier_State	Effective_Date	Current_Supplier_State
123	ABC	Acme Supply Co	CA	22-Dec-2004	IL

Tyyppi 4

Tämä on kaikessa yksinkertaisuudessaan uuden taulun luonti. Tämä voi soveltua esimerkiksi vanhoille osoitteille tai postinumeropille. Kankein, mutta joskus erittäin helppo ja käyttökelpoinen tapa.

Analysis services kannan mallinnus ja toteutus

Analysis services kanta Visual studiossa

Kuution kantamalli.

’Solution explorer’ visual studion työtilan tiedostot.

Dimensioiden ja faktojen käyttö.

Laskennalliset mittarit.

MDS masterdata malli

MDS on Microsoft SQL server optio ja termi on yksinomaan MS tuotteiden yhteydessä käytetty nimitys, joka tarkoittaa Microsoft SQL Server masterdata services toiminnallisuutta.

Esimerkin Tuotekategoria malli ja hierarkiat

• Malli luodaan kunkin raportointijärjestelmän tarpeen mukaan tiedoilla, jotka saadaan aihealueen tarpeista.

• Kaikkien dimensio taulujen master mallit muodostuvat kyseisen aihealueen (datamart) mallinnuksessa ja ETL prosessien toteutuksen ja suunnittelun aikana.

• Oleellista on se, että malli on oltava jaettavissa muiden – myös operatiivisten – kanssa.

• Lisäksi Master data strategia on suunniteltava. Se kertoo tavan millä Etl prosessit, joko käyttävät MDS dataa lähteenä tai käyttävät sitä ns. lookup lähteenä tietojen tarkistuksessa.

• Tämä kokonaisuus ei yleensä kuulu BI projektiin.

• Vain tämän BI projektin aihealueen osalta se kuuluu mukaan

Trendit – ja pitkänaikavälin epäsäännöllisyys

Pitkillä aikaväleillä trendilaskenta tulisi olla suoraviivaista historiaan perustuvaa ’keskiarvo’ laskentaa

Jos tämä ei ole mahdollista on kehitettävä ’jyvitys’ algoritmi huolellisesti, koska tämä vastaa todellisuutta

· Kk, kvartaali, vuosijako

· Erilaiset painotukset

· Ennustus

BI sovellus Reporting servicesissä

Reporting services raportit tehdään report builderilla tai visual studiossa (BIDS)

Esimerkki on BIDS – eli SQL Server kehitysympäristö – Visual Studio

Powerpivot ja Excel mallit

Powerpivot data.

Powerpivot ’faktaa’.

Powerpivot dimensiodataa.

Powerpivot raportti, joka voidaan vielä viimeistellä ’nätimmäksi’ julkaisua varten esim SharePoint 2010 saitille.

BI portaali ja SharePoint

Asennus ja konfigurointi Microsoft oheistuksen mukaan. Lisäksi Sharpoint saittin (WSP) ’solution’ tiedosto on aktivoitava Sharpointissa tai käytetään olemassa olevia paketteja, kuten BI Site collection solution.

MS Ohjeistuksen lisäksi on syytä tehdä alla olevien pohjien mukaiset valmistelut ja dokumentointi, joka toimitetaan Invenco BI projektin aikana malliksi Sharepoint tiimille.

Kuvaus muutamista dokumenteista jotka on hyvä toimittaa joka tapauksessa tiimille ja asiakkaalle.

Tietoturva suunnittelu ja toteutus

Harvoin mikään excel dokumentti pystyy kuvaamaan tietoturvaa tai käyttöoikeuksia kyllin hyvin. Siksi kannattaa muotoilla mahdollisimman selkeä kuvaus tämän mallin mukaisesti, siitä mitä tietoja kullekkin käyttäjälle tai ryhmälle saa näkyä. Tämä myös siksi, että varsinainen autorisointi tehdään ns. muualla kun kannassa. Tämä ’muualla’ on yleensä Active Directory tai LDAP. Sen sääntöjen mukaanhan data saa näkyä käyttäjille. Kaikki erikoisuudet, kuten oma autorisointi kannoissa on vastoin yleisiä tietoturva käytäntöjä ja sellaiset jäävät hyvin nopeasti jälkeen normaalissa tietosuoja ylläpidossa.

Metadata suunnitelma

Jos päätetään toteuttaa varsinainen metadata kanta, on sen tekoon valmiina kanta skriptit ja lataus proseduurit. Kuva niistä tässä malliksi.

Lisäksi esimerkki metadata ’browser’ raportit toteutettuna visual studiolla. Esimerkki on erittäin hyvä Kimball malli ja toimitetaan Datawarehouse toolkitin mukana.

Jos päätetään toteuttaa varsinainen metadata kanta, on sen tekoon valmiina kanta skriptit ja lataus proseduurit. Kuva niistä tässä malliksi.

Ylläolevat raporttipohjat tässä vielä Visual Studio työtilassa.

ETL:stä RS linkki raportointiautomaatioon

Kuva1 – Orders Data Load Complete ajastusksen ominaisuudet SQL Server Management Studio:ssa

Kuva2 – Raportin tilaus (subscription) Orders Data Load Complete ajastuksessa