Goede Business Intelligence (BI) stelt uw organisatie in staat gegevens uit betrouwbare bronnen op te vragen en de antwoorden te gebruiken om een concurrentievoordeel te behalen in uw branche. De eerste stap om tot effectieve BI te komen is een goed ontworpen data warehouse. Data warehouse ontwerp is het proces van het bouwen van een oplossing om gegevens uit meerdere bronnen te integreren die analytische rapportering en gegevensanalyse ondersteunen. Een slecht ontworpen data warehouse kan resulteren in het verwerven en gebruiken van onnauwkeurige brongegevens die een negatieve invloed hebben op de productiviteit en groei van uw organisatie. Deze blog post zal een high-level blik werpen op het data warehouse ontwerpproces van requirements verzamelen tot implementatie.
Requirements Gathering
Het verzamelen van requirements is stap één van het data warehouse ontwerpproces. Het doel van de requirements gathering fase is het bepalen van de criteria voor een succesvolle implementatie van het data warehouse. De bedrijfsstrategie van een organisatie op lange termijn moet net zo belangrijk zijn als de huidige bedrijfs- en technische vereisten. Gebruikersanalyse en rapportage-eisen moeten worden geïdentificeerd, evenals hardware, ontwikkeling, testen, implementatie en gebruikerstraining.
Als de zakelijke en technische strategie is bepaald, is de volgende stap hoe de organisatie een back-up van het datawarehouse zal maken en hoe het zich zal herstellen als het systeem uitvalt. Het ontwikkelen van een disaster recovery plan tijdens het verzamelen van de requirements, zorgt ervoor dat de organisatie voorbereid is om snel te reageren op directe en indirecte bedreigingen voor het data warehouse.
Physical Environment Setup
Nadat de business requirements zijn vastgesteld, is de volgende stap het bepalen van de fysieke omgeving voor het data warehouse. Op zijn minst moeten er afzonderlijke fysieke applicatie- en databaseservers zijn, evenals afzonderlijke ETL/ELT-, OLAP-, kubus- en rapportageprocessen die zijn opgezet voor ontwikkeling, testen en productie. Het bouwen van afzonderlijke fysieke omgevingen zorgt ervoor dat alle wijzigingen kunnen worden getest voordat ze naar productie worden verplaatst, ontwikkeling en testen kunnen plaatsvinden zonder de productieomgeving te onderbreken, en als de gegevensintegriteit verdacht wordt, kan de IT-staf het probleem onderzoeken zonder de productieomgeving negatief te beïnvloeden.
Gegevensmodellering
Als de vereisten zijn verzameld en de fysieke omgevingen zijn gedefinieerd, is de volgende stap het definiëren van hoe gegevensstructuren zullen worden benaderd, verbonden, verwerkt en opgeslagen in het datawarehouse. Dit proces staat bekend als gegevensmodellering. Tijdens deze fase van het data warehouse ontwerp worden de gegevensbronnen geïdentificeerd. Weten waar de oorspronkelijke gegevens zich bevinden en, net zo belangrijk, de beschikbaarheid van die gegevens, is cruciaal voor het succes van het project. Zodra de gegevensbronnen zijn geïdentificeerd, kan het data warehouse team beginnen met het bouwen van de logische en fysieke structuren op basis van de vastgestelde eisen.
ETL
Het ETL proces vergt de meeste tijd om te ontwikkelen en neemt het grootste deel van de implementatie in beslag. Het identificeren van gegevensbronnen tijdens de gegevensmodelleringsfase kan helpen om de ETL-ontwikkelingstijd te verkorten. Het doel van ETL is om optimale laadsnelheden te bieden zonder aan kwaliteit in te boeten. Falen in deze fase van het proces kan leiden tot slechte prestaties van het ETL proces en het gehele data warehouse systeem.
OLAP Cube Design
On-Line Analytical Processing (OLAP) is de antwoordmachine die de infrastructuur biedt voor ad-hoc gebruikers query’s en multi-dimensionale analyses. Specificatie van het OLAP-ontwerp moet komen van degenen die de gegevens zullen bevragen. Documentatie die de OLAP kubus dimensies en maatregelen specificeert moet worden verkregen tijdens het begin van het data warehouse ontwerpproces. De drie kritische elementen van OLAP ontwerp zijn:
- Groepeer maatregelen – numerieke waarden die u wilt analyseren, zoals omzet, aantal klanten, hoeveel producten klanten kopen, of gemiddeld aankoopbedrag.
- Dimensie – waar maatregelen worden opgeslagen voor analyse, zoals geografische regio, maand of kwartaal.
- Granulariteit – het laagste niveau van detail dat u wilt opnemen in de OLAP-dataset.
Zorg er tijdens de ontwikkeling voor dat het OLAP-kubusproces wordt geoptimaliseerd. Een data warehouse is meestal niet een nachtelijke prioriteit run, en zodra het data warehouse is bijgewerkt, is er weinig tijd over om de OLAP cube bij te werken. Het niet tijdig bijwerken van een van beide kan leiden tot verminderde systeemprestaties. De tijd nemen om het meest efficiënte OLAP cube generatie pad te onderzoeken kan performance problemen verminderen of voorkomen nadat het data warehouse live is gegaan.
Front End Development
Op dit punt zijn de business requirements vastgelegd, de fysieke omgeving compleet, het datamodel bepaald, en het ETL proces gedocumenteerd. De volgende stap is te werken aan hoe gebruikers toegang krijgen tot het data warehouse. Front end ontwikkeling is hoe gebruikers toegang krijgen tot de gegevens voor analyse en rapporten. Er zijn veel opties beschikbaar, waaronder het zelf bouwen van een front end of het kopen van een kant-en-klaar product. Hoe dan ook, er zijn een paar overwegingen om in gedachten te houden om de beste ervaring voor eindgebruikers te garanderen.
Veiligde toegang tot de gegevens vanaf elk apparaat – desktop, laptop, tablet of telefoon moet de eerste overweging zijn. De tool moet uw ontwikkelingsteam in staat stellen de backend-structuur te wijzigen als de rapportage-eisen op ondernemingsniveau veranderen. Het moet ook een grafische gebruikersinterface (GUI) bieden die gebruikers in staat stelt hun rapporten naar behoefte aan te passen. De OLAP engine en de gegevens kunnen de beste in zijn klasse zijn, maar als gebruikers niet in staat zijn de gegevens te gebruiken, wordt het data warehouse een dure en nutteloze opslagplaats van gegevens.
Report Development
Voor de meeste eindgebruikers is het enige contact dat zij met het data warehouse hebben, de rapportage die zij genereren. Zoals vermeld in de paragraaf over front-end ontwikkeling, is de mogelijkheid voor gebruikers om snel en efficiënt hun rapportcriteria te selecteren een essentiële eigenschap voor het genereren van data warehouse rapporten. Leveringsopties zijn een andere overweging. Naast het ontvangen van rapporten via een beveiligde webinterface, willen of moeten gebruikers misschien ook rapporten ontvangen als e-mailbijlage of spreadsheet. Het beheren van de stroom en zichtbaarheid van gegevens is een ander aspect van rapportontwikkeling dat moet worden aangepakt. Het ontwikkelen van gebruikersgroepen met toegang tot specifieke gegevenssegmenten moet zorgen voor gegevensbeveiliging en -controle. Rapportage zal en moet veranderen lang na de initiële implementatie. Een goed ontworpen data warehouse zou in staat moeten zijn om de nieuwe rapportageverzoeken te verwerken met weinig tot geen aanpassingen aan het data warehouse systeem.
Performance Tuning
Eerder in deze post was de aanbeveling om gescheiden ontwikkel- en testomgevingen te creëren. Hierdoor kunnen organisaties systeemprestaties afstemmen op ETL, queryverwerking en levering van rapporten zonder de huidige productieomgeving te onderbreken. Zorg ervoor dat de ontwikkel- en testomgevingen – hardware en applicaties – de productieomgeving nabootsen, zodat de prestatieverbeteringen die in de ontwikkelomgeving zijn gemaakt, ook werken in de live productieomgeving.
Testen
Als het datawarehouse-systeem eenmaal is ontwikkeld volgens de zakelijke eisen, is de volgende stap het testen ervan. Testen, of kwaliteitsborging, is een stap die niet mag worden overgeslagen omdat het data warehouse team hiermee problemen kan blootleggen en aanpakken voordat het systeem in gebruik wordt genomen. Het niet afronden van de testfase kan leiden tot vertraging in de implementatie of beëindiging van het data warehouse project.
Implementatie
Tijd om live te gaan. De beslissing om het systeem in één keer voor iedereen beschikbaar te stellen of om een gespreide release uit te voeren, hangt af van het aantal eindgebruikers en de manier waarop zij toegang krijgen tot het data warehouse-systeem. Een ander belangrijk aspect van een systeemimplementatie, dat vaak wordt overgeslagen, is de training van eindgebruikers. Hoe “intuïtief” het data warehouse team en de ontwikkelaars de GUI ook vinden, als de werkelijke eindgebruikers de tool moeilijk te gebruiken vinden, of niet begrijpen wat de voordelen zijn van het gebruik van het data warehouse voor rapportage en analyse, dan zullen ze er niet aan beginnen.
Begrijpen van Best Practices voor Data Warehouse Design
Data warehouse design is een tijdrovende en uitdagende onderneming. Er zullen goede, slechte en lelijke aspecten aan elke stap zitten. Echter, als een organisatie de tijd neemt om goede requirements te ontwikkelen aan het begin, zullen de volgende stappen in het proces logischer verlopen en leiden tot een succesvolle data warehouse implementatie.