En datalagrets karaktär (att den huvudsakligen består av eller uteslutande av data som kommer från någon annans annan tillämpning databaser och omvandlas till en data tillgång) betyder att den inte kan stå som en självständig enhet inom din organisation.
Den fenomenala tillväxten av distribuerad databehandling (Internet och intranät samt datalagring av interna och externa data) har resulterat i en grundläggande förändring av hur applikationerna konstrueras. I de gamla dagarna av mainframes och minidatorer innehöll ett enda fysiskt system i stor utsträckning infrastrukturen (operativsystem, databaser och filsystem samt kommunikations- och transaktionschefer).
< ! - 1 ->Med distribuerad databehandling är den dominerande modellen (även mainframes och minidatorer vanligtvis en del av en större distribuerad miljö), infrastrukturen sprids över många olika p latforms över hela ditt företag och eventuellt utanför ditt företag.
När du utvecklar något program eller system, antingen datalagring eller ett mer traditionellt transaktionsbehandlingsprogram, har du stora beroenden på delar av den övergripande miljön som du inte har någon direkt kontroll över. Här är några exempel som är specifika för datalagring:
-
Du utformar ett datalager som, baserat på företagskrav och programmets tillgänglighetspolicy, måste ha cirka 25 gigabyte nya och uppdaterade data extraherade från olika källor varje kväll och skickas över nätverket till hårdvaruplattform där datalageret körs.
Din företagsnätverksinfrastruktur är fortfarande underordnad. Efter ytterligare analys kan nätverket inte komma nära att stödja den genomströmning som krävs för att flytta data till ditt lager i det tillgängliga tidsfönstret.
-
Under dataförlagringsprojektets omfattningsfas bestämmer du att en pushstrategi för att uppdatera datalagret är den mest lämpliga modellen att följa. För att implementera en pushstrategi måste du ändå ändra varje källprogram för att inkludera kod som upptäcker när den applikationen måste push (skicka) data till datalagret.
De äldre program som tillhandahåller data till lageret är tyvärr så svåra att förstå att en policy att göra inga ändringar om det inte är absolut nödvändigt gäller för varje ansökan.
-
Du bestämmer dig för att driva en relativ OLAP (eller ROLAP) -lösning och kör en serie riktmärken mot tre relationsbaserade DBMS (RDBMS) produkter för att se vilken som bäst stöder informations- och beslutsstödsbehandling (i stället för transaktionsbehandling).
Den produkt som utförde mest dåligt i dina riktmärken är tyvärr också din företagsstandard, och en relationsdatabas installerad var som helst i ditt företag måste vara av denna sort, oavsett hur du planerar att använda den.
Tänk på begreppsmässigt (inte oroa sig för implementeringsdetaljer) i ett tidigt skede av ett datalagringsprojekt eller någon annan applikationsutvecklingsinsats - det är inte bara acceptabelt, det är också bra systemutvecklingspraxis.
Vid något tillfälle måste du dock överväga hårdvara, programvara, kostnader, budget och andra typer av verkliga hinder. Innan du börjar bygga, var noga med att överväga allt som kan påverka dina mönster och planer för ditt datalager.
Detta projekt liknar att bygga ett hus. Du följer en process där du bestämmer dina behov, och sedan utarbetar arkitekten ritningar. Ritningarna markerar de material som du behöver för att stödja dina krav - för att säkerställa att den färdiga produkten uppfyller den vision som etablerades i början.
