Data warehousing og infrastrukturudfordringen - dummies

Et datalageres karakter (at det primært består eller udelukkende består af data, der kommer fra andre steder, andre applikationer databaser og konverteres til et dataaktiv) betyder, at det ikke kan stå som en selvstændig enhed i din organisation.

Den fænomenale vækst i distribueret databehandling (internet og intranet samt datalagring af interne og eksterne data) har resulteret i et grundlæggende skift i måden applikationer er opbygget på. I de gamle dage af mainframes og minicomputere indeholdt et enkelt fysisk system stort set infrastrukturen (operativsystemer, databaser og filsystemer og kommunikations- og transaktionschefer).

< ! - 1 ->

Med distribueret computing er den dominerende model (selv mainframes og minicomputere normalt en del af et større distribueret miljø), infrastrukturen spredes over mange forskellige p latforms på tværs af din virksomhed og muligvis uden for din virksomhed.

Når du udvikler et program eller system, enten datalagring eller et mere traditionelt transaktionsbehandlingsprogram, har du betydelige afhængigheder på dele af det generelle miljø, som du ikke har nogen direkte kontrol over. Her er nogle eksempler, der er specifikke for datalagring:

• Du designer et datalager, der skal baseres på forretningskrav og applikations data tilgængelighed politikker, skal have cirka 25 gigabyte nye og opdaterede data hentet fra forskellige kilder hver aften og sendes over netværket til hardwareplatform, hvor datalageret kører.

  Din virksomhedsnetværksinfrastruktur er stadig under størrelse. Efter yderligere analyse kan netværket ikke komme tæt på at understøtte den nødvendige gennemgang til at flytte dataene til dit lager i det tilgængelige tidsvindue.

• I datafarehusprojektets omfangsfase bestemmer du, at en pushstrategi til opdatering af datalageret er den mest hensigtsmæssige model, der skal følges. For at implementere en push-strategi skal du dog ændre hvert kildeprogram til at omfatte kode, der registrerer, når applikationen skal push (send) data til datalageret.

  De gamle applikationer, der leverer data til lageret, er desværre så svært at forstå, at en politik, der ikke ændrer sig, medmindre det absolut er nødvendigt, gælder for hver applikation.

• Du beslutter dig for at forfølge en relativ OLAP (eller ROLAP) løsning og køre en række benchmarks mod tre relationsbaserede DBMS (RDBMS) produkter for at se, hvilken der bedst understøtter informativ og beslutningsstøttende behandling (i stedet for transaktionsbehandling).

  Det produkt, der har haft de dårligste resultater i dine benchmarks, er desværre også din virksomhedsstandard, og enhver relationsdatabase, der er installeret overalt i din virksomhed, skal være af denne sort, uanset hvordan du planlægger at bruge den.

Tænk konceptuelt (ikke bekymre dig om implementeringsdetaljer) i de tidlige stadier af et datalagringsprojekt eller nogen anden applikationsudviklingsindsats - det er ikke kun acceptabelt, det er også god systemudviklingspraksis.

På et tidspunkt skal du dog overveje hardware, software, omkostninger, budget og andre typer af virkelige begrænsninger. Før du begynder at bygge, skal du overveje alt, hvad der kan påvirke dine designs og planer for dit datalager.

Dette projekt ligner meget på at bygge et hus. Du følger en proces, hvor du bestemmer dine behov, og så udarbejder arkitekten tegninger. Tegningerne fremhæver de materialer, du har brug for til at understøtte dine krav - sikre, at det færdige produkt opfylder den vision, der blev etableret i starten.