Hulp bij design van meetdatabase

[Brandts]

Ik ben (voor het eerst) een database aan het opzetten om meetgegevens van ons product in op te slaan en makkelijk terug te vinden. Ik heb alleen moeite met het bepalen van een efficiënt design.

Ik zal eerst maar eens abstract proberen uit te uitleggen hoe het product opgebouwd is en wat voor een soort meetdata hier uit komt. Ons product is opgebouwd uit meerdere onderdelen en aan ieder onderdeel worden metingen verricht:



Product A en B zijn 2 losse onderdelen waar metingen aan verricht worden. Hier zit een meting bij die 1000 individuele meetpunten voor product A oplevert en 500 individuele meetpunten voor product B. Twee producten B en één product A worden geassembleerd tot product C waar ook weer metingen aan zitten die 1000 individuele meetpunten opleveren. Drie producten C worden geassembleerd tot het eindproduct D. Een bijkomend probleem is dat op het moment dat product A of B gemeten wordt nog niet bekend is welke gecombineerd worden tot product C. Het zelfde geld voor de drie producten C in het eindproduct D.
Daarnaast worden er per product nog individuele metingen gedaan die maar 1 meetpunt opleveren.

De metingen die gedaan worden hebben onderlinge relaties met elkaar. Deze heb ik proberen te weergeven in onderstaande tabel.



Nu vraag ik me af hoe ik de tabellen in de database zo kan inrichten zodat er efficiënt met query's nieuwe tabellen gegenereerd kunnen worden zoals, alle metingen die aan een eindproduct zijn uitgevoerd (voorbeeldtabel) of de meetwaarde van dezelfde meting over meerdere producten in de tijd.

Zelf had ik het idee om voor drie soorten tabellen te maken:

• Tabellen met meetwaarden (voor iedere meting een eigen tabel). Maar hoe moet ik bijvoorbeeld de 3000 meetwaarden van bijvoorbeeld meting 10 opslaan? Iedere meetwaarde in een eigen kolom (dus uiteindelijke 3000+ kolommen) of voor iedere meting een eigen record, waardoor het aantal records uiteindelijk snel oploopt tot miljoenen?
• Eén tabel die de relaties tussen de verschillende producten vastlegd? Of 2 tabellen, één voor de koppelingen van product A en B tot C, en één voor de koppelingen tussen producten C en het eindproduct D?
• Één of meerdere tabellen die de relaties vastlegt tussen de meetpunten van de verschillende metingen?

Ik denk uiteindeijke alles in Access te gaan doen, of zijn er goede redenen om Access hier niet voor te gebruiken?

Al het advies, opmerkingen of vragen zijn welkom

[farlane]

Op het moment dat metingen (nieuwe) tabellen of kolommen gaan opleveren ben je op de verkeerde weg.

Begin eens met een productentabel en een metingen tabel (en ja, daar gaan veel records in komen) en maak een manier om metingen aan producten te koppelen (Hint: een meting hoort maar bij 1 uniek product, maar een product kan meerdere metingen hebben)

[DHH]

Allereerst de disclaimer: ik heb niet eerder een dergelijke omgeving opgezet, dus neem mijn advies met een korreltje zout, maar ik zou het zelf als volgt aanpakken.

Misschien goed om eerst even stil te staan bij de vraag of alle metingen behouden moeten blijven, of dat bijv. de min, max, mediaan en het gemiddelde van de 3000 meetwaarden al voldoende is en je deze over al je producten al kan vergelijken.

Daarnaast geef je niet aan wat voor soort metingen het zijn. Zijn de metingen enkele waarden of bereiken, moet er per meting aanvullende informatie worden meegestuurd zoals de datum en het tijdstip? Door welke medewerker en met welke apparatuur de meting is verricht? Kan je dit soort informatie groeperen?

Als alle 3.000 metingen door dezelfde apparatuur worden verricht en op dezelfde dag en hetzelfde tijdstip is het wellicht slimmer om een aparte tabel te maken met deze gegevens en een subtabel naar de individuele rijen met meetwaarden (vergelijk het met een ordertabel waarin je in de 'header' de ordergegevens zet zoals het ordernummer, de klant, het leveringsadres, etc. en daarnaast een aparte tabel hebt voor de orderregels met de individuele artikelen, aantallen, prijzen, etc.

Ik ken Access niet heel goed, maar lees dat er beperkingen zijn zoals een max. dataset van 2gb. Afhankelijk van de hoeveelheid informatie en hoe efficiënt deze opgeslagen worden, zou het best kunnen zijn dat je tegen die beperking aan gaat lopen. SQL Server zou hier geen problemen mee moeten hebben, maar wellicht dat andere gebruikers betere oplossingen kunnen aandragen.

[ewoutw]

Ohhh lastig, ik kan weinig brijen van de gegevens die je geeft. Heel abstract.
Maar het proses wat je moet is doen heet normaliseren.

Is eigenlijk vooral een denkwijze. Maar begin met met alle kolommen van je tabellen op 1 hoop te gooien. Daarna ga je ze in groepjes verdelen (deze groepjes zullen de basis van je tabellen vormen).

Een webwinkel heeft klanten (groep1) en natuurlijk ook producent(groep2). Die klanten bestellen producten. Bestellingen (groep3) bestaat uit dus uit 1 klant die een 1 of meer verschillende producenten besteld. En daar wordt het lastig. Want nu moet ik bestellingen in 2 groepen verdelen. Groep3.1 (betellingen) koppeld klant X aan bestelling Y. Vervolgens groep3.2 die product A ook aan bestelling Y koppels. Maar evt ook product B aan bestelling Y.

Vervolgens kan je met 1 query zowel de klantgegevens als de bestelde producten ophalen die een bepaalde bestelling hoord. Maar ook alle bestelde producent van 1 klant. Of zien welke klanten dit speciefie product hebben gekocht.

Duidelijk? Gok van niet. maar begin eens met alle gegevens te benoemen en te groeperen. Dit kan je het best doen door je proces te doorlopen.

[CurlyMo]

DHH schreef op donderdag 26 juli 2018 @ 23:25:
Misschien goed om eerst even stil te staan bij de vraag of alle metingen behouden moeten blijven, of dat bijv. de min, max, mediaan en het gemiddelde van de 3000 meetwaarden al voldoende is en je deze over al je producten al kan vergelijken.

Waarom al beginnen met optimaliseren als je nog niet weet of dit een probleem gaat vormen? TS geeft helemaal niet aan hoe vaak er gemeten wordt, dus ook niet hoe snel de database groeit. En TS geeft niet aan hoe snel gegevens getoond dienen te worden. Mag een query een paar seconde draaien voordat er resultaat dient te zijn of moet het bijna realtime?

Ik meet sinds 12 november mijn energieverbruik en PV in PostgreSQL. Dat zijn bijna 2 miljoen metingen zonder indexes. Simpele aggregraties doet de database binnen een seconde.

Zonder aanvullende informatie kunnen we hier dus niks over zeggen. Het is wel zo dat je eventueel datasets kan maken van die aggregaties in Access of SPSS zodat anderen die weer verder kunnen analyseren.

Brandts schreef op donderdag 26 juli 2018 @ 17:52:
Ik denk uiteindeijke alles in Access te gaan doen, of zijn er goede redenen om Access hier niet voor te gebruiken?

Access is bijna altijd een slecht idee als je naar een serieuze database opzet wil. Andere gratis alternatieven zijn PostgreSQL of MySQL, of inderdaad met betaalde ondersteuning MSSQL server.

Verder geeft @farlane een goede voorzet om dit aan te vliegen.

[Brandts]

Bedankt voor alle reacties. Ik merk uit de reacties dat ik te weinig informatie heb gegeven en de informatie te abstract is. Ik zal daarom de situatie wat minder abstract te maken door het te vertalen naar een productie van een scherm (ok, dit wordt absoluut geen realistisch voorbeeld, maar dit maakt het wel minder abstract )

• We maken schermpjes van 1000 pixels. In de productie wordt de oppervlakte van iedere pixel gemeten voordat het schermpje verder geassembleerd wordt (product A in het abstracte voorbeeld).
• Ieder schermpje wordt aangestuurd door 2 chips. Voordat het deze chips aan het scherm bevestigd wordt, wordt eerste gemeten hoeveel stroom iedere uitgang van de chip genereert. Iedere uitgang stuurt een individuele pixel aan (product B in het abstracte voorbeeld)
• Vervolgens worden 2 chips en 1 scherm geassembleerd. Aan dit geassembleerd product wordt de helderheid en kleurwaarde per pixel gemeten (product C in het abstracte voorbeeld)
• Als laatste worden 3 van deze schermpjes geassembleerd tot 1 groter scherm waar opnieuw de helderheid en kleurwaarde per pixel gemeten wordt (product D in het abstracte voorbeeld).

Hier nog even schematisch weergeven:



Nu heb ik het idee om de tabellen als volgt te genereren (in dit voorbeeld neem ik alleen even de assemblage van het kleine scherm (product C):



Dit levert tabellen op met duizenden kolommen en 1 regel per nieuw product. Mijn vraag is of dit efficient zal zijn of is een andere opbouw van de tabellen verstandiger?


Om nog even jullie reacties te beantwoorden:

farlane schreef op donderdag 26 juli 2018 @ 23:24:
Op het moment dat metingen (nieuwe) tabellen of kolommen gaan opleveren ben je op de verkeerde weg.

Begin eens met een productentabel en een metingen tabel (en ja, daar gaan veel records in komen) en maak een manier om metingen aan producten te koppelen (Hint: een meting hoort maar bij 1 uniek product, maar een product kan meerdere metingen hebben)

Misschien is nu duidelijker dat ik alleen een tabel wil hebben per type meting. Als een nieuwe meting aan een nieuw product verricht wordt resulteert dit in een nieuwe regel van een bestaande tabel

DHH schreef op donderdag 26 juli 2018 @ 23:25:
Allereerst de disclaimer: ik heb niet eerder een dergelijke omgeving opgezet, dus neem mijn advies met een korreltje zout, maar ik zou het zelf als volgt aanpakken.

Misschien goed om eerst even stil te staan bij de vraag of alle metingen behouden moeten blijven, of dat bijv. de min, max, mediaan en het gemiddelde van de 3000 meetwaarden al voldoende is en je deze over al je producten al kan vergelijken.

Daarnaast geef je niet aan wat voor soort metingen het zijn. Zijn de metingen enkele waarden of bereiken, moet er per meting aanvullende informatie worden meegestuurd zoals de datum en het tijdstip? Door welke medewerker en met welke apparatuur de meting is verricht? Kan je dit soort informatie groeperen?

Als alle 3.000 metingen door dezelfde apparatuur worden verricht en op dezelfde dag en hetzelfde tijdstip is het wellicht slimmer om een aparte tabel te maken met deze gegevens en een subtabel naar de individuele rijen met meetwaarden (vergelijk het met een ordertabel waarin je in de 'header' de ordergegevens zet zoals het ordernummer, de klant, het leveringsadres, etc. en daarnaast een aparte tabel hebt voor de orderregels met de individuele artikelen, aantallen, prijzen, etc.

Ik ken Access niet heel goed, maar lees dat er beperkingen zijn zoals een max. dataset van 2gb. Afhankelijk van de hoeveelheid informatie en hoe efficiënt deze opgeslagen worden, zou het best kunnen zijn dat je tegen die beperking aan gaat lopen. SQL Server zou hier geen problemen mee moeten hebben, maar wellicht dat andere gebruikers betere oplossingen kunnen aandragen.

Alle metingen moeten behouden blijven. Het product is nog in ontwikkeling. Om het voorbeeld even te nemen: als 1 specifieke pixel afwijkt wil je kunnen achterhalen of dit aan de stroom of oppervlakte ligt. Daarnaast wil je regressieanalyses kunnen doen aan de verschillende metingen en kunnen kijken hoe een specifieke pixellocatie zich gedraagt in de tijd

Jouw voorbeeld van de ordertabel zou wel kunnen werken, maar de orderregels in de tweede tabel lopen in mijn geval per order dus op tot duizenden regels per order (het aantal meetpunten). Dit wordt dus al snel een tabel met miljoenen records. Maakt dit een database niet inefficiënt?

ewoutw schreef op vrijdag 27 juli 2018 @ 02:34:
Ohhh lastig, ik kan weinig brijen van de gegevens die je geeft. Heel abstract.
Maar het proses wat je moet is doen heet normaliseren.

Is eigenlijk vooral een denkwijze. Maar begin met met alle kolommen van je tabellen op 1 hoop te gooien. Daarna ga je ze in groepjes verdelen (deze groepjes zullen de basis van je tabellen vormen).

Een webwinkel heeft klanten (groep1) en natuurlijk ook producent(groep2). Die klanten bestellen producten. Bestellingen (groep3) bestaat uit dus uit 1 klant die een 1 of meer verschillende producenten besteld. En daar wordt het lastig. Want nu moet ik bestellingen in 2 groepen verdelen. Groep3.1 (betellingen) koppeld klant X aan bestelling Y. Vervolgens groep3.2 die product A ook aan bestelling Y koppels. Maar evt ook product B aan bestelling Y.

Vervolgens kan je met 1 query zowel de klantgegevens als de bestelde producten ophalen die een bepaalde bestelling hoord. Maar ook alle bestelde producent van 1 klant. Of zien welke klanten dit speciefie product hebben gekocht.

Duidelijk? Gok van niet. maar begin eens met alle gegevens te benoemen en te groeperen. Dit kan je het best doen door je proces te doorlopen.

Hopelijk heb ik het nu wat duidelijker kunnen maken

CurlyMo schreef op vrijdag 27 juli 2018 @ 07:27:
[...]

Waarom al beginnen met optimaliseren als je nog niet weet of dit een probleem gaat vormen? TS geeft helemaal niet aan hoe vaak er gemeten wordt, dus ook niet hoe snel de database groeit. En TS geeft niet aan hoe snel gegevens getoond dienen te worden. Mag een query een paar seconde draaien voordat er resultaat dient te zijn of moet het bijna realtime?

Ik meet sinds 12 november mijn energieverbruik en PV in PostgreSQL. Dat zijn bijna 2 miljoen metingen zonder indexes. Simpele aggregraties doet de database binnen een seconde.

Zonder aanvullende informatie kunnen we hier dus niks over zeggen. Het is wel zo dat je eventueel datasets kan maken van die aggregaties in Access of SPSS zodat anderen die weer verder kunnen analyseren.


[...]

Access is bijna altijd een slecht idee als je naar een serieuze database opzet wil. Andere gratis alternatieven zijn PostgreSQL of MySQL, of inderdaad met betaalde ondersteuning MSSQL server.

Verder geeft @farlane een goede voorzet om dit aan te vliegen.

De metingen zullen maar 1 keer per product uitgevoerd worden. De productie zal uiteindelijk oplopen tot ongeveer 200 producten per maand. Een query mag best enkele secondes draaien.

Ik heb de mogelijkheid om de database op een server te laten die dan door gebruikers benaderd kan worden met een ODBC connectie. Ik denk dat de applicatie die gebruikt wordt dan van minder belang is. Ik had het idee om de queries te laten draaien vanuit een Access omgeving omdat alle collega's Access beschikbaar hebben. Is Access dan nog steeds een slechte keuze?

[Caracca]

Een andere opbouw is aanbevolen. een tip hierbij is je te gaan verdiepen een "database normalisatie" (er zit een hele theorie achter)

m.b.t tot de metingen tabel moet je gaan proberen niet de breedte in te gaan, maar meer de diepte
i.e.:
----
Product_ID : 1
PixelNr : 1
PixelWaarde : 0.5
----

Access an sich is niet echt een probleem, je zou wel kunnen kijken naar een Access frontend met een SQL database backend (mysql/mssql)

[ Voor 18% gewijzigd door Caracca op 27-07-2018 09:03 ]

[RobIII]

Wikipedia: Databasenormalisatie

Daarbij is het feit dat aggregates zoals Sum, Avg, Min, Max werken op rijen en niet op kolommen natuurlijk een mega-dikke hint. Probeer eens een AVG te nemen van 3000+ kolommen

[ Voor 5% gewijzigd door RobIII op 27-07-2018 09:04 ]

[CurlyMo]

Een structuur in kolommen is sowieso een slecht idee, maar dat is al gezegd.

Daarnaast heeft @farlane al precies voorgezegd wat je wel en niet moet doen. Wat je nu uitgewerkt hebt is precies wat hij je afraadt te doen. Als je dus een begint met wat je aangeraden wordt vanaf de eerste reactie.

[Black Eagle]

Wellicht denk ik nu te simpel hoor, maar heb je aan onderstaand niet genoeg?

- Tabel met producten (id/description)
- Tabel met meetpunten/tags (id/productid/description)
- Tabel met koppelingen tussen meetpunten (id/parenttagid/childtagid)
- Tabel met meetwaarden (id/tagid/timestamp/value)

[FrankHe]

Na alles te hebben doorgelezen zou ik het als volgt doen:



Laat me weten als er iets niet duidelijk is.

Edit, toevoeging meting lengte:
tbl_kind
7 - product length - mm

tbl_measurement
9013 - 13 - 1 - 7 - 900

[ Voor 24% gewijzigd door FrankHe op 27-07-2018 12:41 ]

[FenixOrange]

Je zou voor dit soort gegevens ook heel goed een zgn NoSQL database kunnen gebruiken, zoals MongoDB.
Hierbij worden de gegevens niet in een relationele tabellenstructuur opgeslagen, maar als losse objecten, die op basis van eigenschappen aan elkaar verbonden kunnen worden.

Een voorbeeld van een object kan dan zijn:

Object: Product
- ID
- Type (A of B of C etc)
- SubProducts [array of strings]
[ - ProductID
....... ]
- Meting [array of objects]
[ - Metingnummer
- Tijdstip
- Gegevens [Array of numbers]
........... ]

Door de opzet van een NoSQL database ben je ook niet gebonden aan een voorgedefinieerde structuur.
Wat als je volgend jaar ineens andere metingen of kenmerken van producten wil vastleggen. Dat kan dan zonder problemen.
NoSQL databases zijn ook zeer efficient en het is ook mogelijk om dmv ODBC deze te koppelen aan een Access of Excel frontend.

[ Voor 0% gewijzigd door FenixOrange op 27-07-2018 13:09 . Reden: opmaak ]

[RobIII]

FrankHe schreef op vrijdag 27 juli 2018 @ 12:25:
Laat me weten als er iets niet duidelijk is.

Ik vind 't vooral jammer dat alles nu helemaal voorgekauwd wordt...

Give a man a fish and feed him for a day. Teach a man how to fish and feed him for a lifetime

Overigens ben ik 't ook niet geheel eens met je voorstel; of laat ik zeggen: er is in ieder geval ruimte voor discussie. Als je foo-metingen en bar-metingen doet die allebei andere eenheden of andere data bevatten, stop dat dan gewoon in een foo_metingen en bar_metingen tabel en frot 't niet in een enkele tabel met een "kind" tabel eraan. Appels bij appels, peren bij peren.

FenixOrange schreef op vrijdag 27 juli 2018 @ 13:07:
Je zou voor dit soort gegevens ook heel goed een zgn NoSQL database kunnen gebruiken, zoals MongoDB.

Ah, ik vroeg me al af waar de "NoSQL roepers" bleven

Ja, dit kun je prima in een NoSQL kwijt. Maar waarom? Noem 1 goed argument om dit niet gewoon in een RDBMS te mikkeren. En kom niet met "big data" Hier is in de verste verte niks "big data" aan.

FenixOrange schreef op vrijdag 27 juli 2018 @ 13:07:
Door de opzet van een NoSQL database ben je ook niet gebonden aan een voorgedefinieerde structuur.
Wat als je volgend jaar ineens andere metingen of kenmerken van producten wil vastleggen. Dat kan dan zonder problemen.

Hoeveel ervaring heb je met "NoSQL"? Je kunt niet "zonder problemen" je datamodel aanpassen zonder dat je applicatie aangepast moet worden. Dit is werkelijk zo'n sprookje...

FenixOrange schreef op vrijdag 27 juli 2018 @ 13:07:
NoSQL databases zijn ook zeer efficient

Nog zo'n fabel. Ze zijn wel efficiënt, vast wel, de vraag is zijn ze ook efficiënter dan een RDBMS in dit geval? Ik betwijfel het ten zeerste.

[ Voor 44% gewijzigd door RobIII op 27-07-2018 13:51 ]

[Kwistnix]

RobIII schreef op vrijdag 27 juli 2018 @ 13:41:
Ja, dit kun je prima in een NoSQL kwijt. Maar waarom? Noem 1 goed argument om dit niet gewoon in een RDBMS te mikkeren. En kom niet met "big data"

Duh. Met een RDBMS kan je geen hype-driven development doen.
Do you even hipster?

[FrankHe]

RobIII schreef op vrijdag 27 juli 2018 @ 13:41:
[...]

Ik vind 't vooral jammer dat alles nu helemaal voorgekauwd wordt...

[...]

Zo ingewikkeld is het nu ook weer niet
Met een beetje basiskennis normaliseren en modelleren kom je al heel snel hier op uit. Maar je hebt helemaal gelijk dat ik de output er volledig in heb gezet. Zal het voortaan bewaren voor een later moment

[RobIII]

FrankHe schreef op vrijdag 27 juli 2018 @ 13:50:
[...]

Zo ingewikkeld is het nu ook weer niet

Dat is 't punt nou net Voor jou, mij, en vele anderen is 't peanuts. Voor TS is het een leermoment. En leren doe je 't best door 't zélf proberen op te lossen (met wat begeleiding, hints en tips onderweg; daarvoor zijn wij) en niet door 't op een zilveren presenteerblaadje aangereikt te krijgen "Normaliseren" was al een paar keer gevallen (en naar gelinkt) en TS had voldoende om mee aan de gang te kunnen.

[ Voor 10% gewijzigd door RobIII op 27-07-2018 13:53 ]

[johnkeates]

Dit is dan geen time series, maar het klinkt bijna als of je (no pun intended) metrics opslaat. Behalve de traditionele RDBMS en en de hipster databases zijn er veel gespecialiseerde databases die misschien voor jouw doel beter werken. Het lijkt er op dat je metingen wil uitvoeren en die later wil kunnen combineren om een berekende waarde voor een samengesteld product te krijgen. Nu betekent dat niet automatisch dat precies de juiste type DBMS bestaat, maar het betekent ook niet dat een RDBMS automatisch de beste optie is.

Nu zal je in dit geval misschien (afhankelijk van de hoeveelheid transacties) ongeacht de DBMS wel een werkend systeem krijgen, maar dat betekent niet dat alle non-relational databases bij elke database-vraag afgeschoten moeten worden. In dit geval is een document database of NoSQL database hier niet zinvol, dat biedt totaal geen meerwaarde. Misschien dat je een TSDB er voor kan misbruiken of een DDDBMS, maar dat zou meer informatie vergen.

[FrankHe]

RobIII schreef op vrijdag 27 juli 2018 @ 13:52:
[...]

Dat is 't punt nou net Voor jou, mij, en vele anderen is 't peanuts. Voor TS is het een leermoment. En leren doe je 't best door 't zélf proberen op te lossen (met wat begeleiding, hints en tips onderweg; daarvoor zijn wij) en niet door 't op een zilveren presenteerblaadje aangereikt te krijgen "Normaliseren" was al een paar keer gevallen (en naar gelinkt) en TS had voldoende om mee aan de gang te kunnen.

Excuses, ik realiseer me dat ik nog weinig, wellicht nooit, iets heb gepost in Devschuur. Zal het in de toekomst meer spannend maken

[RobIII]

FrankHe schreef op vrijdag 27 juli 2018 @ 13:58:
[...]

Excuses

Da's nou ook weer niet nodig Leermomentje voor iedereen En nu weer ontopic verder

[VaanderingM]

4e normaalvorm in Elastic(Search) en dan geen textmapping gebruiken.
Kibana als view.

Heeft mij met miljoenen logs nog nooit teleurgesteld.

[epic007]

FrankHe schreef op vrijdag 27 juli 2018 @ 12:25:
Na alles te hebben doorgelezen zou ik het als volgt doen:

.....

Ik zat ook inderdaad ongeveer in deze richting te denken. Al zou ik de tbl_measurement wel opsplitsen.

Eén tabel waarbij je een measurement_kind aan een product koppelt en een losse tabel met daarin de meetwaarden voor deze meting.

En een relationele database is hier prima voor omdat je data-structuur uiteindelijk toch min of meer vast staat.

[Brandts]

Iedereen bedankt voor de vele antwoorden! Dit zijn er te veel om individueel op in te gaan dus maar even wat algemene antwoorden.

Het is me nu helemaal duidelijk dat ik niet in kolommen moet gaan werken. Ik had dit niet eerder opgemaakt uit het antwoord van @farlane maar door de andere antwoorden en me een beetje te verdiepen in databasenormalisatie begrijp ik nu ook waarom.

Het voorstel van @FrankHe komt heel erg in de buurt van wat ik wil. Ik had dit natuurlijk ook graag zelf willen bedenken omdat ook ik met vallen en stoten beter leer dan dat iets voorgekauwd wordt maar dit helpt natuurlijk wel om snel progressie te maken Zoals ik al zeg komt dit in de buurt, maar is dit het dus nog net niet helemaal dus ik kan zelf nog steeds leren

Wat ik nog mis is de relatie tussen de meetpunten van de verschillende producten. Zo kan bijvoorbeeld een uitgang van de chip op twee verschillende pixels terecht komen. Welke twee pixels dit zijn is bekend maar is dus afhankelijk van de positie binnen het geassembleerd product. Dit is op voorhand nog niet bekend. Als ik deze info wil toevoegen in de database zou ik dit als volgt doen.



Maar volgens mij is dit niet wat het moet zijn. Als ik normalisatie toepas zou ik de twee kolommen die ik toegevoegd heb aan tbl_product ieder een eigen tabel kunnen geven.

tbl_assembly
• scherm_product_id
• chip_posA_product_id
• chip_posB_product_id

tbl_eindproduct
• assemblyA_product_id
• assemblyB_product_id
• assemblyC_product_id

Het voordeel hiervan is dat deze relaties nog niet bekend zijn op het moment dat chips en schermen gemeten worden, maar pas later in het assembly proces. Op het moment dat dit assembly proces uitgevoerd wordt kan deze tabel aangevuld worden met een nieuw record.

De tabel met de relaties van de meetposities blijf ik een moeilijke vinden aangezien deze meerdere tabellen aan elkaar moet koppelen. Is het verstandig om deze te houden zoals ik hem nu heb geïmplementeerd?

Betreft de opmerking van @epic007. Je stelt dus voor om per "kind_id" een eigen tabel met meetwaardes te maken? Ik zie hier wel de voordelen van in omdat de data uit de metingen in het werkelijke product kunnen verschillen van type. Zo komen er getallen maar ook booleans uit (al zijn die makkelijk te veranderen naar 0 en 1 natuurlijk). Ik kan we zelf voorstellen dat hier in de toekomst afbeeldingen bij gaan komen. Maar in het begin werd me juist afgeraden om tabellen per type meting te maken. Wat is nu wijsheid?

Over de NoSQL kunnen we volgens mij kort zijn. De relaties tussen de producten en metingen zijn exact bekend. Zelfs al komen hier achteraf nieuwe type metingen bij dan is dit nog steeds makkelijk toe te voegen in deze structuur. Dus ik zie niet in wat de voordelen zouden zijn van NoSQL.

Ik heb dit weekend helaas geen (priori)tijd om hiermee verder te gaan dus ik ga maandag hier weer mee aan de slag. Nogmaals bedankt voor al jullie input/opmerkingen.

edit:

VaanderingM schreef op vrijdag 27 juli 2018 @ 21:55:
4e normaalvorm in Elastic(Search) en dan geen textmapping gebruiken.
Kibana als view.

Heeft mij met miljoenen logs nog nooit teleurgesteld.

Dat ziet er inderdaad interessant uit. Lijk een beetje op DIAdem van National Instruments. Maar naast het realiseren van de database wil ik ook graag leren hoe een dergelijke database opgebouwd wordt/moet worden. Dus ik laat dit soort applicaties even voor wat het is.

[ Voor 8% gewijzigd door Brandts op 28-07-2018 09:16 ]

[FrankHe]

Brandts schreef op zaterdag 28 juli 2018 @ 09:05:
Iedereen bedankt voor de vele antwoorden! Dit zijn er te veel om individueel op in te gaan dus maar even wat algemene antwoorden.

[...]

Is het wellicht een idee om de positie vast te leggen in X-Y coördinaten? Wil je ook vastleggen welke LED op welke plaats in de matrix zit? Of volstaat een nummering van 1 tot 1000?

Je komt met twee kolommen "positie_in_assembly" en "positie_in_eindproduct". Dat kan prima zo. In beginsel zou je deze ook kunnen samenvoegen tot een enkele kolom "positie". Via "Product_zit_in_id" kun je namelijk van tbl_product een JOIN maken met zichzelf, tbl_product, waarmee je het bovenliggende "parent record" oppakt. En vervolgens kun je via "Product_type_id" te weten komen of je bij de "parent" met een assembly of eindproduct te maken hebt.

Die informatie kun je dan middels een "database query" of "database view" netjes leesbaar presenteren.

Edit:
Voor iedere soort meeting zou je inderdaad een eigen tabel kunnen maken. Al zou ik hier denk ik niet te ver in gaan. Volstaat de opslag van integer waardes? Als je decimalen wilt opslaan dan kun je er ook voor kiezen om in je eenheid een stap omlaag te gaan. Zo is 0,500 A gelijk aan 500 mA en 4,25 lm gelijk aan 4250 mlm. Een boolean past prima in een 32 bit integer veld al is het inderdaad wat overvloedig. Mijn stelling is dat het niet echt de moeite loont om daar heel erg over in te zitten. Zodra je tekstuele meetwaardes wilt opslaan, zou zo snel niet kunnen bedenken wat dat zou kunnen wezen, maar als je dat wenst, dan doe je er wel goed aan om na te denken wat je precies nodig gaat hebben en hoe dat het beste vast te leggen.

epic007 schreef op zaterdag 28 juli 2018 @ 00:01:
[...]

Ik zat ook inderdaad ongeveer in deze richting te denken. Al zou ik de tbl_measurement wel opsplitsen.

Eén tabel waarbij je een measurement_kind aan een product koppelt en een losse tabel met daarin de meetwaarden voor deze meting.

En een relationele database is hier prima voor omdat je data-structuur uiteindelijk toch min of meer vast staat.

In dit geval voelt het wel goed om iets meer naar een spreadsheet matrix opzet toe te kruipen. Dan kunnen normale stervelingen, collega's van TS, er tenminste ook nog een beetje chocola van maken.

Wanneer je weet dat je (in de toekomst) behoefte gaat hebben aan meer dimensies dan is het inderdaad goed om alles verregaand te normaliseren. Met als resultaat een hele hoop meer tabellen. Maar je kunt dingen natuurlijk ook kapot-normaliseren Het is altijd een beetje de balans zoeken.

[ Voor 15% gewijzigd door FrankHe op 28-07-2018 10:07 ]

[VaanderingM]

En je hoeft ook niet persee je “waardentabel” als tabel voor je rapportage te gebruiken.

Event source principe gebruiken en een apparte tabel voor je rapportage, geeft je de vrijheid om je output aan te passen.

[CurlyMo]

VaanderingM schreef op zaterdag 28 juli 2018 @ 20:51:
Event source principe gebruiken en een apparte tabel voor je rapportage, geeft je de vrijheid om je output aan te passen.

Wellicht goed om het event source principe in dummy taal uit te leggen.

[VaanderingM]

Je slaat alle meetgegevens op in een manier die voor opslag handig zijn.
Id|apparaatId|waarde

En daarna draai je om de x tijd een batchjob of stored procedure die de view maakt die past bij je rapportage.

https://martinfowler.com/eaaDev/EventSourcing.html

[FrankHe]

VaanderingM schreef op zondag 29 juli 2018 @ 22:58:
Je slaat alle meetgegevens op in een manier die voor opslag handig zijn.
Id|apparaatId|waarde

En daarna draai je om de x tijd een batchjob of stored procedure die de view maakt die past bij je rapportage.

https://martinfowler.com/eaaDev/EventSourcing.html

Dit is doorgaans om de performance van de rapportages te verbeteren of voor data die continu beweegt. Als het genereren van een rapportage bijvoorbeeld meer dan 10 seconden duurt of wanneer de data over enkele minuten anders gaat worden dan die nu is, dan is het wellicht een goed idee om de informatie apart van de bron op te slaan. Bij uitgebreide JOIN queries, een grote aggregatie en / of ingewikkelde mathematische functies die veel resources vragen kan het vooraf genereren een goede oplossing zijn. En bij bewegende data is het prettig om periodiek een snapshot te maken.

Voor zover ik het nu kan inschatten lijkt dit nog niet echt een probleem te worden. De meetwaardes gaan na de meting waarschijnlijk niet meer veranderen. Een meetrapportage van een LED-muur met een miljoen pixels moet wel binnen luttele seconden te genereren zijn. Op een beetje vlotte machine lukt het denk ik in een fractie van een seconde. Mits de database goed is gemodelleerd, indexes zijn aangelegd en de query goed is geschreven.

Het is niet moeilijk om een inefficiënte query te bouwen. Met de juiste kennis en beginselen is het schrijven van een vlotte query niet razend ingewikkeld. Het is de kunst om de query leesbaar te houden. Schrijf keywords in kapitalen en ik ben zelf altijd expliciet in het gebruik van aliassen en het keyword 'AS':

code:

SELECT p.product_id AS id
FROM tbl_product AS p

Zorg ervoor dat subqueries netjes inspringen en je reporting query / view zal begrijpbaar en onderhoudbaar zijn.

Loop je tegen problemen aan die opgelost kunnen worden door het gebruik van Event Sourcing dan moet je dat zeker gebruiken.

[FrankHe]

@Brandts Ben benieuwd hoe ver je op dit moment bent met het modelleren van de database.

[Brandts]

Helaas ben ik nog niet veel verder gekomen vanwege andere prioriteiten op het werk. Het ziet er naar uit dat ik vanaf maandag hier weer wat meer tijd in kan steken.

[fo0]

Kwistnix schreef op vrijdag 27 juli 2018 @ 13:45:
[...]

Duh. Met een RDBMS kan je geen hype-driven development doen.
Do you even hipster?

Het is tegenwoordig ook heel hip om tegen noSql te zijn waarbij kreten als hype-driven development weer heel hip zijn.

Ondanks dit is data wat relationeel vast te leggen is en dient dus ook zo behandeld te worden. NoSql kan hiervoor dus gebruikt worden maar waarom zou je?

[FrankHe]

Brandts schreef op vrijdag 3 augustus 2018 @ 11:48:
Helaas ben ik nog niet veel verder gekomen vanwege andere prioriteiten op het werk. Het ziet er naar uit dat ik vanaf maandag hier weer wat meer tijd in kan steken.

Goed om te horen dat je genoeg te doen hebt. Een prettig weekend toegewenst!

fo0 schreef op vrijdag 3 augustus 2018 @ 14:13:
Het is tegenwoordig ook heel hip om tegen noSql te zijn waarbij kreten als hype-driven development weer heel hip zijn.

Ondanks dit is data wat relationeel vast te leggen is en dient dus ook zo behandeld te worden. NoSql kan hiervoor dus gebruikt worden maar waarom zou je?

Ik zou proberen het zo simpel mogelijk te houden en dan voldoet een relationele database met een hand vol tabellen prima. Zo verschrikkelijk veel data is het niet wat er opgeslagen gaat worden en we weten vrij goed wat voor data we gaan krijgen. Wat we hier doen is feitelijk een soort veredeld Excel

[Kwistnix]

fo0 schreef op vrijdag 3 augustus 2018 @ 14:13:
[...]

Het is tegenwoordig ook heel hip om tegen noSql te zijn waarbij kreten als hype-driven development weer heel hip zijn.

Ondanks dit is data wat relationeel vast te leggen is en dient dus ook zo behandeld te worden. NoSql kan hiervoor dus gebruikt worden maar waarom zou je?

Mijn opmerking moet je dan ook echt lezen in de context van dit topic
Het is, zoals je zelf aangeeft, een oplossing die niet past.

[Brandts]

Het heeft wat langer geduurd dan gewenst maar ik heb het design zo goed als af. Dit is wat het geworden is:



Ik werk niet meer met het fictieve voorbeeld maar met het echte product omdat het anders als dubbel werk begint te voelen. Ik heb daarom wel het een en ander moeten censureren

Voor de metingen heb ik vanwege praktische overwegingen besloten om verschillende meettabelen te genereren. Nu zijn dit er nog maar 2 maar dit zullen er meer worden zodra ik weet dat dit design definitief is.

Nu ben ik bezig met handmatig wat data in te vullen om hierna wat query's te maken om te kijken of ik de data kan ophalen zoals ik dat wil. In ieder geval bedankt voor jullie input. Mocht ik nog vragen hebben dan meld ik me wel

[raptorix]

Frankhe heeft een aardige opzet gedaan vind ik, dit is inderdaad hoe je het logisch zou opzetten, echter hou rekening dat je data dan met terugwerkende kracht kan veranderen, immers als je normaliseert naar een product tabel dit problemen kan gaan opleveren. Het is eigenlijk de klassieke fout welke je soms ook bij webshops ziet die factuur regels normaliseert naar een product tabel, echter als de prijs wijzigt dan wijzigt ook je factuur regel. Een oplossing is om een extra dimensie aan te brengen, bijvoorbeeld via een versie ID.

[FrankHe]

Brandts schreef op maandag 20 augustus 2018 @ 08:16:
Het heeft wat langer geduurd dan gewenst maar ik heb het design zo goed als af. Dit is wat het geworden is:

[afbeelding]

Ik werk niet meer met het fictieve voorbeeld maar met het echte product omdat het anders als dubbel werk begint te voelen. Ik heb daarom wel het een en ander moeten censureren

Voor de metingen heb ik vanwege praktische overwegingen besloten om verschillende meettabelen te genereren. Nu zijn dit er nog maar 2 maar dit zullen er meer worden zodra ik weet dat dit design definitief is.

Nu ben ik bezig met handmatig wat data in te vullen om hierna wat query's te maken om te kijken of ik de data kan ophalen zoals ik dat wil. In ieder geval bedankt voor jullie input. Mocht ik nog vragen hebben dan meld ik me wel

Het lukt me niet direct om in één oogopslag te zien hoe dit in elkaar steekt maar dit komt misschien omdat er wat context mist. Ik begrijp dat je die context graag voor jezelf wilt houden. Daar heb je neem ik over nagedacht.

Voor mijn gevoel moet het mogelijk zijn om enkele tabellen samen te voegen. In bepaalde gevallen zijn er goede redenen te bedenken om on-the-fly tabellen aan te maken. In dit geval weet ik niet of het er nu makkelijker en overzichtelijker van gaat worden. Misschien wel maar mogelijk wordt het er juist complexer van. Denk er even over na hoe groot en ingewikkeld een rapportagequery er over twee jaar uit gaat zien. Moet je tegen die tijd 40 tabellen aanroepen om alle informatie te verzamelen? Of gaat het zo gek niet worden?

raptorix schreef op maandag 20 augustus 2018 @ 11:27:
Frankhe heeft een aardige opzet gedaan vind ik, dit is inderdaad hoe je het logisch zou opzetten, echter hou rekening dat je data dan met terugwerkende kracht kan veranderen, immers als je normaliseert naar een product tabel dit problemen kan gaan opleveren. Het is eigenlijk de klassieke fout welke je soms ook bij webshops ziet die factuur regels normaliseert naar een product tabel, echter als de prijs wijzigt dan wijzigt ook je factuur regel. Een oplossing is om een extra dimensie aan te brengen, bijvoorbeeld via een versie ID.

Helemaal meer eens dat je de detailgegevens in een factuurregel het beste volledig kunt opslaan. Eigenschappen van product zullen veranderen en dan gaan er inderdaad hele rare dingen gebeuren.

Wanneer je door de tijd heen dezelfde meeting wilt herhalen dan is de historische informatie ook heel interessant om te behouden. Je zou dit kunnen oplossen met een versienummer. Maar wellicht is het niet nodig om het op deze manier te normaliseren. Persoonlijk zit ik te denken aan een lossere vastlegging middels een timestamp (datum en tijd).

Wil je alleen de meest recente meeting tonen dan sorteer je antichronologisch en neem je de TOP 1 / LIMIT 1 van de resultaten. Met alle historische gegevens kun je mooie berekeningen maken van de standaardaf­wij­king en laten zien hoeveel de waardes naar verhouding degraderen. Door deze gegevens te extrapoleren is het mogelijk om verwachtingen (forecasts) te maken over toekomstige meetwaarden, onderhoud en het plannen van vervanging. Dat is interessante informatie voor de lange-termijn-inkoop van nieuwe componenten.