Wij werken op volle kracht, er is geen vertraging in productie en levering door het Coronavirus. Meer informatie via deze link.

€ 28,50

ePUB ebook

niet beschikbaar

PDF ebook

niet beschikbaar

Sterren en Dimensies (6-de druk)

ontwerp en onderhoud van datawarehouses en datamarts

Harm van der Lek • Boek • paperback

  • Samenvatting
    Deel I: Sterschemas en het onderhoud
    Dit deel is sterk geïnspireerd door de boeken en artikelen van Kimball. Sterschemas staan hierin centraal. Behandeld worden de verschillende soorten dimensietabellen. Verder uiteraard de manieren waarop historie in de dimensies kan worden aangepakt.
    In het hoofdstuk 'het pletten van een ster' introduceren we het zogenaamde OASI concept (One Attribute Set Interface). Aan de hand hiervan komen we tot de conclusie dat sterschema’s in principe technische constructies zijn, alhoewel het dimensie begrip ook in de gebruikers wereld een rol kan spelen. Maar vaak is het dan ook verstandig om een onderscheid te maken tussen technische dimensies (= tabellen in het sterschema) en gebruikersdimensies. Verder blijkt bijvoorbeeld iets als ‘aggregaat navigatie’ nu heel eenvoudig uit te leggen, met andere woorden het OASI-concept heeft ook didactische waarde.
    Ook sterk op het inzicht gericht is hoofdstuk 8 waarin we het verband zoeken (en vinden!) tussen sterschema’s, sneeuwvlokken en OASI’s enerzijds en ‘gewone’ ER-diagrammen anderzijds. Dit is bijvoorbeeld van belang wanneer men, model gedreven, een sterschema wil genereren. Dus eigenlijk voer voor tool-bouwers. Toch wordt ook door praktijkmensen het verhoogde begrip van deze zaken erg gewaardeerd.
    Dit deel is redelijk onafhankelijk van waar men staat in de architectuur discussie tussen Kimball en Inmon, waarop we in het derde deel dieper ingaan.

    Deel II: Gebruikersontsluiting van een sterschema
    Wanneer we eenmaal een database hebben ontworpen via de in deel I besproken dimensionale modelering-technieken en we zijn er ook nog in geslaagd om de database tabellen met data uit de bronsystemen te vullen (dat is vaak het lastigste) dan blijft er nog één onderdeel over. We moeten deze gegevens voor de eindgebruikers benaderbaar maken. Men zou kunnen zeggen: geef de gebruikers een SQL hulpmiddel en klaar. En in de begintijd kwam men daar wel mee weg. Je ziet zelfs dat Kimball soms nog met argumenten om de hoek komt die te maken hebben met het idee dat de gebruikers zelf op deze manier hun rapporten maken. Maar tegenwoordig worden daarvoor Rapportage tools en OLAP-tools gebruikt en die moeten ingericht (geconfigureerd) worden.
    Nu is dit gedeelte meestal niet het grootste struikelblok bij projecten. Er zijn goede tools en wizards beschikbaar. Toch zijn er een aantal conceptuele aspecten een aparte bespreking waard. Het gaat dan met name om meetwaarden een hiërarchieën. Verder worden ook de karakteristieken van dergelijke tools besproken.

    Deel III: Architectuur en Data Vault
    In dit deel gaan we na wat de discussie tussen Kimball en Inmon nu precies inhoud. Nadat we zelf ook kleur hebben bekend, gaan we na wat voor consequenties voor de modellering van het Centrale (‘Enterprise’) Datawarehouse dit heeft. Dit moet volgens Inmon immers een genormaliseerde relationele database worden, waarin echter wel ook historie moet worden bijgehouden. Wanneer we deze punten combineren met het idee dat ‘business entiteiten’ (zoals Klant, Product, Factuur, etc, etc) naast hun identificatie zoals die in de bronsystemen wordt gehanteerd (KlantCode, ProductNummer, Factuurnummer, etc, etc) ook een betekenisloze sleutel krijgen, dan komen we op een vrij natuurlijke manier uit op datgene dat Dan Linstedt in de markt heeft gezet onder de naam ‘Data Vault’. We gaan diep op de structurele aspecten hiervan in. We sluiten het deel af met een tweetal hoofdstukken die geavanceerdere historie begrippen behandelen.
  • Productinformatie
    Binding : Paperback
    Distributievorm : Boek (print, druk)
    Formaat : 170mm x 240mm
    Aantal pagina's : 274
    Uitgeverij : Niet bekend
    ISBN : 9789492182180
    Datum publicatie : 04-2015
  • Inhoudsopgave
    Deel I: Sterschema's en het onderhoud
    Hoofdstuk 1 Wanneer een ster de job doet
    Hoofdstuk 2 Dimensies in soorten en maten
    Hoofdstuk 3 Historie in de sterren
    Hoofdstuk 4 De geboorte van een ster
    Hoofdstuk 5 Het pletten van een ster
    Hoofdstuk 6 Aggregaten, de planeten bij een ster
    Hoofdstuk 7 Het vullen van een ster
    Hoofdstuk 8 Op jacht naar de sterren
    Hoofdstuk 9 Wat een toestanden
    Hoofdstuk 10 De vijf historie typen
    Hoofdstuk 11 Onderhoud van dimensies ETL keten
    Hoofdstuk 12 Wat nog rest

    Deel II: Gebruikersontsluiting van een sterschema
    Hoofdstuk 13 Waar liggen de grenzen van een ster?
    Hoofdstuk 14 Meten op niveau
    Hoofdstuk 15 Hoeveel sterren krijgt uw rapportagetool?

    Deel III: Architectuur en Data Vault
    Hoofdstuk 16 Sterschema's als Starschema's
    Hoofdstuk 17 Data Vault: gegevenskluizen?
    Hoofdstuk 18 Asymmetrische links in Data Vault
    Hoofdstuk 19 HUB of Link; dat is de vraag
    Hoofdstuk 20 Geschiedenis van de historie
    Hoofdstuk 21 Dweilen met de kraan dicht

    Literatuur
    Lijst van figuren
    Sponsors
  • Reviews (0 uit 0 reviews)

€ 28,50

niet beschikbaar

niet beschikbaar

3-5 werkdagen
Veilig betalen Logo
14 dagen bedenktermijn
Delen 

Fragment

De met de normalisatieregels van Codd opgegroeide lezers zullen misschien al hebben gezien dat het feit “Arnhem ligt in Gelderland” ook in de winkeltabel (Figuur 7) ligt opgeslagen, en wel twee keer! “Foei, redundantie”, zullen zij roepen, “dat leidt tot update-anomalie”. Weet u het nog? Stel dat we besluiten dat ook de Veluwe een provincie wordt en dat Arnhem daar bij hoort. We veranderen daarom in de eerste regel keurig de provincie van Gelderland in Veluwe, maar vergeten dat natuurlijk in de derde regel en de inconsistente database is daar. ×
SERVICE
Contact
 
Vragen