Data Warehousing en de Infrastructure Challenge - dummies

De aard van een datawarehouse (dat het voornamelijk of uitsluitend bestaat uit gegevens die van elders komen, andere toepassingen databases, en wordt omgezet in een data-item) betekent dat het niet op zichzelf kan staan ​​als een onafhankelijke entiteit binnen uw organisatie.

De fenomenale groei van distributed computing (internet en intranet, evenals data warehousing van interne en externe gegevens) heeft geleid tot een fundamentele verschuiving in de manier waarop applicaties worden gebouwd.In de oude dagen van mainframes en minicomputers bevatte een enkel fysiek systeem grotendeels de infrastructuur (besturingssystemen, databases en bestandssystemen, en communicatie- en transactiebeheerders)

< ! --1 ->

Met distributed computing is nu het dominante model (zelfs mainframes en minicomputers maken meestal deel uit van een grotere gedistribueerde omgeving), de infrastructuur is verspreid over veel verschillende p latforms binnen uw onderneming en mogelijk buiten uw onderneming.

Wanneer u een toepassing of systeem ontwikkelt, ofwel datawarehousing of een meer traditionele transactieverwerkingstoepassing, hebt u aanzienlijke afhankelijkheden van onderdelen van de algemene omgeving waarover u geen directe controle hebt. Hier zijn enkele voorbeelden specifiek voor data warehousing:

• U ontwerpt een datawarehouse dat op basis van bedrijfsvereisten en toepassingsbeschikbaarheidsbeleid van apps ongeveer 25 gigabyte aan nieuwe en bijgewerkte gegevens moet hebben die elke avond uit verschillende bronnen worden geëxtraheerd en via het netwerk naar de hardwareplatform waarop het datawarehouse draait.

  Uw zakelijke netwerkinfrastructuur is nog steeds ondermaats. Na aanvullende analyse kan het netwerk de verwerkingscapaciteit die nodig is om de gegevens naar uw magazijn te verplaatsen in het beschikbare tijdvenster niet te ondersteunen.

• Tijdens de scoopfase van het data warehousing-project, bepaalt u dat een push-strategie om het datawarehouse bij te werken het meest geschikte model is om te volgen. Voor het implementeren van een pushstrategie moet u echter elke brontoepassing zodanig aanpassen dat deze code bevat die detecteert wanneer die toepassing gegevens moet pushen (verzenden) naar het datawarehouse.

  De oudere toepassingen die gegevens aan het magazijn leveren, zijn helaas zo moeilijk te begrijpen dat een beleid van geen wijzigingen aanbrengen, tenzij het absoluut noodzakelijk is, geldt voor elke toepassing.

• U besluit een relationele OLAP (of ROLAP) -oplossing na te streven en een reeks benchmarks uit te voeren voor drie relationele DBMS-producten (RDBMS) om te zien welke de beste informatie- en besluitondersteunende verwerking ondersteunt (in plaats van transactieverwerking).

  Het product dat het slechtst presteerde in uw benchmarks is helaas ook uw bedrijfsstandaard en elke relationele database die overal in uw bedrijf is geïnstalleerd, moet van deze variëteit zijn, ongeacht hoe u deze wilt gebruiken.

Denk conceptueel (geen zorgen te maken over details over de implementatie) in de vroege stadia van een datawarehousing-project of andere ontwikkelingsinspanningen - het is niet alleen aanvaardbaar, het is ook een goede praktijk voor systeemontwikkeling.

Op een gegeven moment moet u echter rekening houden met hardware, software, kosten, budget en andere typen beperkingen in de praktijk. Voordat u met de bouw begint, moet u alles overwegen wat van invloed kan zijn op uw ontwerpen en plannen voor uw datawarehouse.

Dit project lijkt veel op het bouwen van een huis. U volgt een proces waarbij u uw behoeften bepaalt en vervolgens maakt de architect blauwdrukken. De blauwdrukken benadrukken de materialen die u nodig hebt om aan uw vereisten te voldoen - ervoor te zorgen dat het eindproduct voldoet aan de visie die in het begin is vastgesteld.