• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • Alles
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DevOps
    • Digital Days
    • Docker
    • eHealth
    • Enterprise Architecture
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • Alles
    • Bloggers
    • Speakers
Home » DWH voor informatica-studenten (deel 2: lokale opslag)
  • DWH voor informatica-studenten (deel 2: lokale opslag)

    • By Koos van Strien
    • Business Intelligence 10 years ago
    • Business Intelligence 0 comments
    • Business Intelligence Business Intelligence
    DWH voor informatica-studenten (deel 2: lokale opslag)

    In de vorige post is ingegaan op de wenselijkheid van het bijhouden van de historie van een transactioneel systeem. Als voorbeeld werd hier het “transactionele systeem” Twitter gebruikt. Hier wordt een analyse op uitgevoerd over het verband tussen het gebruik van bepaalde hashtags of mentions en de mutatie in het followers-bestand. Het bleek dat er een systeem nodig was dat periodiek kijkt naar het Twitter-systeem, en de historie daarvan opslaat.

    Naar aanleiding van de vorige post zijn er nog wat openstaande vragen, die in deze post behandeld worden:

    1. Hoe vaak moet Twitter gecontroleerd worden op nieuwe data?
    2. Waar wordt data lokaal opgeslagen? (Bestandssysteem? Database?)
    3. Met welke structuur wordt data lokaal opgeslagen? (XML, Json, derde normaalvorm, anders?)
    4. Is er een vertaalslag nodig van de data zoals deze van Twitter komt en zoals die lokaal opgeslagen wordt?

    Hoe vaak moet Twitter op nieuwe data gecontroleerd worden?

    Gegeven de volgende punten lijkt het ruim voldoende om ieder uur te controleren op nieuwe data:

    • Vanaf @kvstrien wordt zelden meer dan eens per uur getweet
    • @kvstrien heeft nog nooit meer dan eens per uur een follower erbij gekregen
    • Deze blog (die ook lijkt mee te wegen) wordt ook minder vaak dan eens per uur bijgewerkt.

    Bijkomend voordeel is dat met de Twitter-ontwikkelaarsaccounts het aantal API-requests dat je mag doen per uur opnieuw ingesteld worden. Een Twitter-hyperactieve politicus of mediaman, zal waarschijnlijk meerdere malen per uur moeten controleren of er nieuwe updates waren van tweets, followers en andere zaken. Het is bij de Twitter-API zelfs mogelijk om een systeem op de ‘streaming API‘ aan te sluiten, waardoor het systeem dat hier gebruik van maakt wijzigingen automatisch gepusht krijgt. In de huidige case is dat echter overkill.

    Verdieping: Granulariteit

    Bij BI wordt vaak gesproken over de “granulariteit” van data. Daarmee wordt bedoeld tot op welk detailniveau er zinnige dingen over de data gezegd kunnen worden. In dit geval is gekozen om ieder uur Twitter te checken op nieuwe tweets of een mutatie in de followers-groep. Wat betreft de tijdsspanne waarop met data onderbouwde uitspraken gegdaan kunnen worden, ligt de granulariteit dus op uurniveau. Vragen als “Hoeveel minuten duurt het voordat mensen @kvstrien gaan volgen na een populaire tweet?” zullen dus vanuit dit systeem niet te beantwoorden zijn. Wordt echter gevraagd hoeveel uren of dagen het duurt voordat mensen @kvstrien gaan volgen, dan is dat wel te beantwoorden.

    Waar wordt de data lokaal opgeslagen?

    De opgeslagen data wordt gebruikt om verbanden te leggen – bijvoorbeeld tussen het aantal hashtags, mentions en de mutatie in de followers-groep. Daarom moet een manier van opslag gekozen worden die het makkelijk maakt om relaties te leggen. Het simpelweg opslaan van elk request in een bestand op het bestandssysteem is dan niet erg handig. Beter is het om de data in een relationeel database-systeem (rdbms) te zetten. Het maakt hierbij niet uit welk rdbms dit is – in de praktijkposts zal het gratis, overal beschikbare en open source MySQL gebruikt worden. Mocht je een ander rdbms klaar hebben staan (Postgres, SQL Server, Oracle, DB2, SAS) dan kan dat evengoed gebruikt worden.

    Met welke structuur wordt de data opgeslagen?

    Er zijn inmiddels al een aantal eigenschappen voorbij gekomen die wenselijk zijn in de structuur waarin de data wordt opgeslagen:

    • De structuur moet historie kunnen opslaan
    • Binnen de structuur moet het makkelijk zijn relaties te leggen
    • De structuur moet makkelijk te verkennen zijn. Deze is niet expliciet genoemd, maar denk hierbij aan zaken als duidelijke, consistente naamgeving (geen afkortingen e.d.) en eenvoudige structuren (geen 20 niveaus aan tabellen voordat je alle data verzameld hebt).
    • Bij het verkennen van de data(structuur) is het belangrijk dat er geen ongeldige relaties gelegd worden (een follower die erbij gekomen is mag niet gekoppeld worden aan een tweet die pas een halfuur later is geplaatst).

    In dit geval kiezen we om de data te modelleren naar het Dimensioneel Model. Daar ben je vermoedelijk niet bekend mee, en ik ga er vóór de volgende theorie-post niet teveel over vertellen. Mocht je nu alvast meer willen weten, kijk dan eens rond op Wikipedia.

    Is er een vertaalslag nodig van Twitter naar een Dimensioneel Model?

    Twitter biedt de data aan in bijvoorbeeld JSON, XML, RSS  of ATOM. Om de data in een Dimensioneel Model binnen een rdbms te krijgen, is het nodig om een vertaalslag hiervoor te schrijven. Ik heb nog niet verteld hoe een Dimensioneel Model eruit ziet, dus we kunnen inhoudelijk nog niet echt ingaan op die vertaalslag. Wat we wél kunnen doen, is een structuur opzetten waar we de vertaalslag straks in kunnen hangen. We nemen de volgende stappen:

    1. We halen de Twitter-data op (REST, dus HTTP GET requests)
    2. We slaan de resultaten op in een structuur die klaar is voor het Dimensioneel Model
    3. We laden de data in het Dimensioneel Model

    Dit proces noemen we ETL. Extract (stap 1), Transform (stap 2) and Load (stap 3). Aan ETL zal nog een uitgebreidere post geweid worden.

    Achtergrond: ETL-tooling

    Er zijn talloze handige tools die je helpen bij het opzetten van een ETL-proces: het periodiek uitvoeren, het kopiëren van bestanden die je gaat inlezen, het uitpakken van XML, het verbinding maken met verschillende soorten databases, en het proces schematisch weergeven. Die tools zijn echter niet nodig of verplicht. Als je je ETL-proces wilt opzetten in Bash, Powershell, C#, Python of PHP, dan kan dat. En aangezien we als informatici graag weten wat er achter de schermen gebeurt, zal in de praktijk-posts in het begin de ETL-tooling zelf geschreven worden.

    Samenvatting en conclusie

    De afgelopen twee posts zijn veel keuzes gemaakt die het systeem gaan vormgeven:

    • Het te bouwen systeem moet helpen om analyses te doen over Twitter-data.
    • Data wordt opgeslagen in een rdbms
    • Binnen het rdmbs wordt data gemodelleerd naar een Dimensioneel Model
    • Het systeem wordt elk uur bijgeladen met ‘verse’ data uit Twitter.
    • Wat tijd betreft, is de laagste granulariteit van de data dus één uur.

    Na al deze begrippen en basis-theorie is er voldoende basis voor wat praktijk-werk: in de volgende post zal het systeem gebouwd worden dat Twitter-data naar onze database laadt!

    Share this

Koos van Strien

View profile

Related IT training

Go to training website

Related Consultancy solutions

Go to infosupport.com

Related blogs

  • "Garbage in, Garbage out" Vincent Lukassen - 2 years ago

  • Data Governance, een hot topic in menig organisatie

    Data Governance, een hot topic in menig organisatie Vincent Lukassen - 2 years ago

  • Foodsector laat kansen liggen door beperkt gebruik van …

    Foodsector laat kansen liggen door beperkt gebruik van … Hans Geurtsen - 3 years ago

Related downloads

  • Beslisboom voor een rechtmatig ‘kopietje productie’

  • Klantreferentie: Remmicom zet wetgeving om in intellige…

  • Klantreferentie RDW: Samenwerken voor veilig en vertrou…

  • Klantreferentie BeFrank: Strategische IT voor een innov…

  • Wie durft te experimenteren met data in de zorg?

Related videos

  • mijnverzekeringenopeenrij.nl

    mijnverzekeringenopeenrij.nl

  • Winnaar | Innovation Projects 2017

    Winnaar | Innovation Projects 2017

  • Explore | Info Support & HAN & Poliskluis

    Explore | Info Support & HAN & Poliskluis

  • LifeApps bij HagaZiekenhuis

    LifeApps bij HagaZiekenhuis

  • Info Support | Bedrijfsfilm

    Info Support | Bedrijfsfilm

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel
Altijd actief
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Beheer opties Beheer diensten Beheer leveranciers Lees meer over deze doeleinden
Voorkeuren
{title} {title} {title}