Eftersom det rör sig om SCADA-relaterade databaser så är det viktigt att du och/eller ni anlitar en databasarkitekt som har specialiserat sig på just SCADA-relaterade databaser då industriprocesser som förlitar sig på tröskelvärden lagrade i databaser kan få förödande socioekonomiska konsekvenser om de inte har implementerats så genomtänkt som möjligt.
Startpunkten med relationsbaserade databaser är att varje Tabell (varje "CREATE TABLE Tabellnamn();" ska "beskriva en sak". Varje rad bör också vara unik för att undvika upprepningar/motsägelser. Varje rad bör också kunna fyllas med innehåll varje gång det förs in något i tabellen för att undvika så kallade "NULL"-värden (dvs., tomma tabellceller).
Så när du då tänker på tabellkolumner så tänker du, "Vad beskriver en produkt? Namn? Antal? Batch-/serienummer?". Nu har du ju situationen att varje Produkt kan ju ha olika värden såsom dimensioner, massa/vikt och kanske andra mätbara egenskaper (t.ex. färg(er)). En sammanhängande fråga blir då: "När jag för in data om produkten, vad för jag alltid in då vid första skedet?"
Anta att du inte för in några dimensioner ännu för din Bananprodukt. Då är det inte bra att ha en tabell som heter Banan som har kolumner med dimensioner eftersom dessa inte förs in ännu och skapar då onödiga NULL-värden. Istället har du kanske en tabell som heter Bananprodukt och en annan tabell som heter Bananegenskaper där du då har fyra kolumner: Tabellrad-id, Banan-id, Bananegenskap och Bananegenskapsvärde.
Egentligen ska du inte ha Bananprodukt som tabell utan helst en Produkttabell där Banan är en av de olika produkter som finns. Sedan en tabell Produktegenskaper med samma kolumner. Produktegenskaper är också vad som kallas för "svag entitet" eller typ "varje rad här får bara existera om den kan peka/referera via referensnyckel på en rad i en annan tabell". Dvs., du kan ju inte ha dimensioner om en banan om inte en banan finns först, eller hur?
En sak jag lärt mig från något svensk YT-klipp (en svensk databaslärare, men jag tror ej det var Padron) om databaser är att tabellerna ska "Helst växa på höjden och inte bredden". Med andra ord: hellre fler tabeller och/eller fler tabellrader än fler nya kolumner. Varje ny kolumn i en tabell innebär ju att du måste fylla alla befintliga rader med den nya kolumnens data och då kan det leda till fula NULL-värden och/eller motsägelser.
När du har två tabeller, exempelvis Produkt och Produktegenskaper så kan en rad i Produktegenskaper referera till en rad i Produkt vilket - om du visualiserar dig en klassisk tabell i Excel - innebär att en rad kan i princip ha fyra celler på den raden medan en annan rad i samma Exceltabell bara har tre celler på den raden eftersom ingen referenscell från Produktegenskaper har använts. Det är så jag visualiserar tabeller med referensnycklar som pekar på en tabell med primärnyckel, särskilt när du gör JOIN-förfrågan på dem.
Ja just det, kommentarsfrågan för bananer: Då har du en tabell för Produktkommentarer där varje rad måste "peka" (referera) till en Produkt vars produkttyp kanske är "banan" (fast helst har du en tabell som heter Produkttyp så det som pekas mot är siffran för tabellrad-id i Produkttyp). Då kan du ha flera kommentarer mot samma enskilda bananprodukt.
OCH: I Produktkommentarer-tabellen så kanske du även vill "peka" på vem som kommenterade så det går att spåra/se vem som kommenterade vad då du berättade om olika som kan kommentera olika. En kommentar har ju ("beskrivs av") vanligtvis kommentaren i sig, datumet för det och oftast _vem_ som kommenterade. Personerna blir så klart också sin egen tabell. Godkännande-grejen bör vara egen tabell då det kan argumenteras att ett Godkännande eller icke-Godkännande av en produkt inte kan "beskrivas" av en tabellen Produkt. (Icke-)godkännande är ju snarare en (dynamisk) process än något statiskt som exempelvis en Produkt.
Förhoppningsvis har A4-uppsatsen ovan gett dig flera tankar att mentalt tugga igenom nu!
Mvh,
WKF.
