Datenbank designen - Grobe Architektur

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
mattse123
User
Beiträge: 6
Registriert: Montag 29. Mai 2017, 16:05

Hallo liebe Python-Community,

ich habe vor 3 Wochen mit meiner Promotion begonnen und hierbei soll ich als ersten Schritt eine Datenbank erstellen, die alle möglichen Messungen aus unserer Forschungsgruppe zusammenstellt.

Ich bin dabei, was Datenbankerstellung anbetrifft, ein ziemlich blutiger Anfänger, daher sicherlich auch einige 'naive' Fragen im Bezug auf die Strukturierung.

Unsere Forschungsgruppe sieht folgendermaßen aus: Wir stellen organische Solarzellen her, diese werden anschließend mit den verschiedensten Messmethoden ausgemessen, sagen wir es gibt für jede Solarzelle N Messmethoden.

Daher wollte ich, was das grobe Design angeht, eine Hierarchie über 2 Ebenen entwerfen,
also zum Beispiel:

Solarzelle 1; Messung 1 (IV-Kennlinie); Messung 2 (IR-Messung bzgl. Störstellen); Messung 3 (Ladungsträgerdichte)

Da ich noch nicht mit Python gearbeitet habe, sondern fast ausschließlich mit C++, hätte ich jetzt ganz naiv eine Klasse Solarzelle entworfen, und eine Unterklasse Messmethode. Wie ich das ganze dann geordnet ablege, ist wahrscheinlich das Problem und dabei kommen dann die Datenbank-Bibliotheken ins Spiel.

Meine Frage: Kann ich eine solche Hierarchie aus nur zwei Ebenen mit sqlite3 umsetzen, oder brauche ich hierfür die volle SQL Version? Soweit ich bisher recherchiert habe, scheint mit sqlite viel leichter zu handeln sein als mySQL.

Alternativ würde ich mich über praktische Beispiele oder auch gute Literatur freuen.

Danke und viele Grüße,

MAttse1213
mattse123
User
Beiträge: 6
Registriert: Montag 29. Mai 2017, 16:05

Schwachsinn mit der Klasse, ich meinte natürlich Objekte anlegen, es gibt ja keine Methoden sondern nur Einträge. Sorry für den Fehler
BlackJack

@mattse123: Mir ist die Hierarchie mit zwei Ebenen nicht so ganz klar. Soll das *eine* Tabelle sein mit der Solarzelle als erste Spalte und dann eine Spalte pro Messung? Das wäre kein guter Entwurf, weil damit Messmethoden festgeschrieben sind. Man kann da später schlecht weitere hinzufügen und wenn man welche für spätere Messungen weglassen möchte, dann hat man lauter NULL-Werte in den entsprechenden Spalten.

Auch das mit den Klassen/Objekten habe ich nicht verstanden.

Und rate wie es mir nach dar Frage mit SQLite geht. :-)

Was ist denn bitte die „volle SQL-Version“? Es gibt standard SQL. Und verschiedene Implementierungen, die jeweils eigene Erweiterungen mitbringen. Wenn man sich auf den SQL-Standard beschränkt ist es fast egal welche SQL-Implementierung man verwendet. Bei der Wahl des DBMS muss man schauen was deren Stärken und Schwächen sind und wie das zu den eigenen Anforderungen passt. Solange man sich auf Standard-SQL beschränkt und/oder eine Bibliothek verwendet, die die Unterschiede abstrahiert, kann man das DBMS auch austauschen und Programme schreiben die mit SQLite, MySQL, PostgreSQL, … arbeiten. Ich persönlich verwende für fast jeden Datenbankzugriff SQLAlchemy als Bibliothek. Wenn man den „Object Relational Mapper“-Teil von SQLAlchemy verwendet, dann ergeben sich daraus auch gleich die Klassen für die Datenhaltung.

Du solltest Dich auf jeden Fall mit dem relationalen Datenbankmodell auseinander setzen, und so Sachen wie Normalform und vielleicht auch grafische Darstellungen wie ER- oder UML-Diagramme. Die sind IMHO zumindest zum lernen ganz nützlich.
mattse123
User
Beiträge: 6
Registriert: Montag 29. Mai 2017, 16:05

Das mit den festgeschriebenen Messmethoden (oder besser deren Anzahl) ist natürlich ein Nachteil, zu Beginn dachte ich auch, man kann einfach die Anzahl der Einträge flexibel lassen ähnlich wie bei <vector>; aber dazu habe ich bisher nichts gefunden.

Des weiteren sind zum Beispiel Einträge zur UV-Messmethode die folgenden:

Temperatur, Intensität, Name, Pin, Parameter zu I_SC und V_OC, Zeit, ... einige mehr ... , und anschließend die Messung selbst, also eine Liste mit

Spannung Strom

U1 I1
. .
. .
. .
U_N I_N

______________

Kurz gesagt, ich hatte erstens die Hoffnung, ich kann die Menge der Einträge variabel halten, zweitens dachte ich, ich kann die Tabellen einfach verschachteln, also eine Tabelle als Eintrag einer übergeordneten Tabelle verwenden. Beides trifft leider (soweit ich bisher recherchiert habe) nicht zu; es wird also komplizierter werden.
Das Ding ist, ich will jetzt nicht einfach irgendwas hinklatschen ich glaube die Sache sollte man, bevor man beginnt, erstmal gut durchdenken sonst gibt's später das böse Erwachen.


Danke und viele Grüße,

Mattse123
Melewo
User
Beiträge: 320
Registriert: Mittwoch 3. Mai 2017, 16:30

N Messmethoden ist eine recht ungenaue Angabe. Ich meine, wenn es sich jeweils nur um Einzeldaten handelt, genügt da eine Tabelle, die da

Id, | Datum/Uhrzeit | Messung durchgeführt von | Solarzelle | IV-Kennlinie | IR-Messung usw.

enthalten könnte. Doch wenn sich jede Messung noch einmal aus 30 bis 300 oder mehr Einzeldaten zusammensetzt, wie ich einmal bei einer Kennlinie vermuten würde, sehe die Angelegenheit etwas anders aus. So ähnlich beschreibst Du das ja. Tabellen lassen sich ja verknüpfen, so dass dann z.B. die Kennlinien einzeln in einer Tabelle gespeichert werden könnten, nur die Zuordnung müsste stimmen.
BlackJack

@mattse123: Ich denke Du müsstest Dich dringend mit dem relationalen Datenbankmodell beschäftigen. In C++-Datenstrukturen und verschachtelten Datenstrukturen zu planen und die dann versuchen in ein RDBMS zu quetschen ist ziemlich sicher keine gute Idee. SQL kennt Tabellen mit Spalten und die Anzahl und Typen der Spalten einer Tabelle sollte man als fest betrachten. Denn nur dafür sind RDBMS ausgelegt. Die Tabellen kann man dann über Schlüssel/Fremdschlüssel miteinander verknüpfen.
mattse123
User
Beiträge: 6
Registriert: Montag 29. Mai 2017, 16:05

Ich denke, dass das schon funktionieren würde, allerdings fände ich es eleganter, wenn man eine Struktur konzipieren könnte, in denen alles zusammengefasst ist, also
(Zelle, Messung) und dieses dann soweit wie möglich flexibel hält. Was die Messungen angeht, wird wahrscheinlich in nächster Zeit keine neue dazukommen, sondern wir werden mit etablierten Methoden arbeiten, allerdings natürlich längerfristig möglicherweise ein Problem.

Allgemein und was ich noch vergessen habe zu sagen, ist die Performance; alle Suchoperationen oder ähnliches sollten extrem schnell laufen, da das ganze Richtung big Data gehen soll.

Achja und Danke nochmal für die schnellen Antworten, ich habe die Sache wohl ziemlich unterschätzt; ich denke ich werde mich erstmal eingehender mit RDBMS beschäftigen.
BlackJack

@mattse123: Du denkst das *was genau* funktionieren würde? Ich habe die Erfahrung gemacht, das man nicht einfach einen beliebigen objektorientierten Entwurf in eine relationale Datenbank pressen kann. Da wird man ziemlich schnell *gegen* das relationale Datenbankmodell programmieren. Und gegen ein Technik statt mit ihr zu arbeiten, ist selten eine gute Idee. Bei relationalen Datenbanken verteilt man die Daten auf Tabellen und fasst sie nicht zu Strukturen zusammen. Denn die Tabelle ist letztlich die einzige Struktur. Komplexere Strukturen muss man auf Tabellen abbilden und bei der Abfrage dann die Beziehungen herstellen/berücksichtigen.

Man muss wissen wie relationale Datenbanken funktionieren. Welche Bausteine und Abfragemöglichkeiten einem zur Verfügung stehen und auch welche Einschränkungen.

Man kann das natürlich auch sehr flexibel gestalten, wobei dabei immer noch gilt, dass Tabellendefinitionen statisch sind. Das ist das was ein DBMS erwartet, darauf sind die optimiert.

Vergiss die Performance. Entweder ist es schnell genug, oder Du brauchst dafür sowieso Datenbankspezialisten, denn dann muss man anfangen an den ganzen Schräubchen des eingesetzten DBMS zu drehen.
Melewo
User
Beiträge: 320
Registriert: Mittwoch 3. Mai 2017, 16:30

Was Allgemeines zur Performance. Ich kenne praktisch nur MySQL und alles andere nur vom Namen. Bei MySQL erinnere ich mich, dass es da bei einem Test mit einer Million Datensätze noch keine Verzögerungen gegeben haben soll. Ist Jahre her und da wurde weiterhin behauptet, dass MySQL locker bis zu 5 Millionen Datensätze vertragen würde und weniger wird es mit den Jahren nicht geworden sein.
Auch kenne ich zum Beispiel keine WordPress-Installation, die bei einem Seitenaufruf nicht mindestens 30 bis 40 Datenbankabfragen am Stück machen würde, bei Frameworks liegen bis zu 250 Datenbankabfragen pro Seitenaufruf noch im Grenzbereich, las ich zumindest des Öfteren. Was da mehr die Bremse ist, sind die Datenbankserver von den Hostern und bei Webseiten dann der ganze Müll, der da oft zusätzlich abgefragt und eingeblendet wird.

Aber, ich brauchte es noch nicht, man könnte Indizes anlegen, z.B. auf Solarzelle, nur das müsste dann auch wieder durchdacht werden.
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

wie sehen denn die Daten bei
Solarzelle 1; Messung 1 (IV-Kennlinie); Messung 2 (IR-Messung bzgl. Störstellen); Messung 3 (Ladungsträgerdichte)
Messung 1, 2 etc. aus? Ist das _ein_ Wert (wahrscheinlich nicht...)? Sind das X Werte, aber X ist für jede Zelle gleich (also gleiche Länge des Datensatzes)?

Wenn z.B. Messung 1 aus X Werten besteht, musst du die DB später mal durchsuchen wie "zeige mir alle Zellen, bei denen ein Wert von Messung 1 im Bereich zwischen 5 und 10 liegt"?

Die Frage zielt übrigens darauf ab, ob ein RDBMS überhaupt die richtige (beste) DB-Form ist oder ob du nicht z.B. mit einem spaltenorientierten oder dokumentenorientierten DB besser fährst.

Gruß, noisefloor
mattse123
User
Beiträge: 6
Registriert: Montag 29. Mai 2017, 16:05

noisefloor hat geschrieben:Hallo,

wie sehen denn die Daten bei
Ist das _ein_ Wert (wahrscheinlich nicht...)? Sind das X Werte, aber X ist für jede Zelle gleich (also gleiche Länge des Datensatzes)?

Gruß, noisefloor
Die Länge des Datensatzes ist leider ebenfalls nicht als konstant gegeben. Eventuell muss dieses dann eben von der Messtechnik angepasst werden; alternativ wählt man eine konstante, ausreichende Größe an Zeilen für die Tabelle, und füllt, falls nicht entsprechend viele Messpunkte aufgenommen wurden, den Rest mit Nullen / VOIDS auf, was natürlich Speicher verschwendet.
Wenn z.B. Messung 1 aus X Werten besteht, musst du die DB später mal durchsuchen wie "zeige mir alle Zellen, bei denen ein Wert von Messung 1 im Bereich zwischen 5 und 10 liegt"?

Gruß, noisefloor
Genau. Intervallabfragen sollen möglich sein, und zwar gegenüber allen physikalischen Parametern bzw. Messpunkten, die verwendet wurden.
BlackJack

@mattse123: Bitte bitte beschäftige Dich mit relationalen Datenbanken! Die Idee Tabellen mit einer bestimmten Grösse anzulegen und die dann mit Werten zu befüllen und nicht gebrauchte Zeilen mit NULL-Werten zu aufzufüllen offenbart eine völlig falsche Vorstellung von Tabellen in relationalen Datenbanken! Es macht wenig Sinn hier über den Datenbankentwurf zu diskutieren solange Du nicht die Grundlagen von relationalen Datenbanken kennst.

Der Entwurf wird am Ende sicher nicht so aussehen wie eine Exceltabelle 1:1 in eine SQL-Tabelle übertragen, also dass man bei einer Exceltabelle mit n Spalten und m Zeilen dann eine SQL-Tabelle mit n Spalten und m Zeilen bekommt wenn das für beliebige Exceltabellen funktionieren soll. Dann wird man nämlich in der Datenbanktabelle eher eine Zeile pro Zelle der Exceltabelle haben und die Information zu welcher Spalte in der Exceltabelle der Wert gehört ist eine der Informationen in der Datenbankzeile. Vielleicht sollte man statt Datenbankzeile auch eher Datensatz sagen um dieses 2D-Tabellenbild ein wenig aufzubrechen. Klar kann man das als 2D-Tabelle darstellen, aber es ist halt doch ein wenig anders als eine Blatt in einer Tabellenkalkulation.
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Die Länge des Datensatzes ist leider ebenfalls nicht als konstant gegeben.
Macht an sich nichts, spricht IMHO aber gegen ein RDBMS.
alternativ wählt man eine konstante, ausreichende Größe an Zeilen für die Tabelle, und füllt, falls nicht entsprechend viele Messpunkte aufgenommen wurden,
Da kann man vielleicht noch machen, wenn man weiß, dass man eine handvoll Messpunkte hat. Aber du willst definitiv keine Dutzende oder gar Hunderte Spalten in einer Tabelle anlegen, wo dann die Daten abgelegt werden.

IMHO brauchst du eine DB, wo du Daten als Liste / Array speichern kannst. Das ginge z.B. mit MongoDB, PostgreSQL mit JSON als Datentype oder Redis. Bei letzterem kannst du die Listen aber nicht in der DB durchsuchen, bei PostgreSQL mit JSON müsstest du schauen, ob du das abfragen kannst, was du brauchst.

Vielleicht ist auch eine der "Big Data" Datenbanken besser geeignet, aber in dem Gebiet kenne ich mich nicht wirklich aus.

Bevor du irgendeine Entscheidung triffst würde ich an deiner Stelle aber mal mit einer überschaubaren Anzahl repräsentativer Testdaten ein paar Versuche mit verschieden DBs / DB-Type machen, um zu sehen, mit welcher DB du deine Daten später am besten Abfragen kannst.

Gruß, noisefloor
mattse123
User
Beiträge: 6
Registriert: Montag 29. Mai 2017, 16:05

BlackJack hat geschrieben:@mattse123: Bitte bitte beschäftige Dich mit relationalen Datenbanken!
Da bin ich gerade dabei. Daher würde ich den Thread gerne erstmal einfrieren, bis ich mehr Grundlagenwissen habe und eventuell schon ein, zwei Versuche zur Umsetzung gestartet habe. Ihr habt mir schon sehr geholfen, danke dafür.
Antworten