Data uit meerdere kolommen samenvoegen met SQL

[yozgoesdigital]

Mijn vraag
Via een interview applicatie op telefoon krijg ik een tabel aangeleverd met dezelfde data in meerdere kolommen. Het verzamelen van de informatie kan ik niet aanpassen dus wil nu in database de data aggregeren. Als voorbeeld ziet de data er zo uit:

ID	Datum	ph totaal	temperatuur totaal	Bron1Naam	Bron1hoeveelheid	Bron2Naam	Bron2hoeveelheid	Bron3Naam	Bron3hoeveelheid
1	21-8-2017	7.4	30.5	A	2.1	B	8.9	C	7.5
2	21-8-2017	7.3	30.5	B	8.1	A	7.9	A	6.5
3	20-8-2017	7.6	30.7	A	8.7	B	5.0

In totaal kan tot 8 bronnen toegevoegd worden. Elke bron komt vanuit dezelfde lijst bronnen (ca 35) waar en af en toe wat bronnen bij kunnen komen. We hebben het hier over ca 500 ID's per jaar met gemiddeld ca 3 bronnen per ID, dus problemen met traagheid etc verwacht ik niet tegen te komen.
Omdat waarschijnlijk al veel meer mensen met meer ervaring en kennis over nagedacht hebben, is mijn vraag hoe zouden jullie de data beschikbaar maken om per ID en/of per dag/week/maand te kunnen agregreren?
Subvraag:Is de onderstaande oplossing logisch of kan dat makkelijker?

Relevante software en hardware die ik gebruik
De data komt vanuit de server van de mobiele app naar een Postgresql database.

Wat ik al gevonden of geprobeerd heb:
Zelf zat ik te denken om in materialized views meerdere tabellen te maken. Ik wilde de ideën afwachten voordat ik met SQL aan de slag ga:
1) Een tabel te maken met de generieke data (ID, datum, totaal pH en tempertuur)
2) een andere tabel waar de 8 kolommen onder elkaar geplaatst worden met ID, bron naam en bron hoeveelheid
Deze twee tabellen zijn dan weer samen te voegen met ID als 1:many relationship en te groeperen op gewenste parameter

[desmond]

Volgens mij zit je in de goede richting de denken. Het vuile werk doe je eerst door jouw puntje 2). Ik zou in eerste instantie gewoon een view bouwen. Materialiseren kan altijd nog als performance daarom vraagt. En vervolgens netjes categoriseren via jouw puntje 1) - dat laatste op het laagst mogelijke niveau. Daarbovenop kan je dan de aggregaties ontwikkelen al naar gelang de behoefte. Die aggregaten kan je ook materialiseren, bijvoorbeeld in plaats van de views uit puntje 2). Het ligt eraan wanneer je wat ververst wilt hebben.

[yozgoesdigital]

Ik heb me meer verdiept in in views en zolang het niet te lang duurt om views te genereren kan ik volgens mij het beste bij views blijven.
De tabel onder 2) was uiteindelijk zo gemaakt met UNION (Ik begin mij steeds meer af te vragen waarom ik niet jaren geleden al met SQL aan de gang ben gegaan, maar daarvoor in plaats in spreadsheets ben blijven hangen)
Ik heb het geheel nog niet helemaal kunnen neerzetten omdat ik nog een probleempje heb met waardes die als 'empty strings' worden geïmporteerd, maar zodra ik opgelost komt ik er wel uit.