API zur Datenbankmodelierung?

[damianh]

Liebe Alle. Ich habe folgendes Problem:

Ich möchte eine Datenbank von Lebensmittel designen. Diese soll möglichst nachhaltig sein, d.h. alle Normalformen erfüllen. Das heisst im Grunde genommen ja nichts anderes, als dass:
1. NF: Jedes Feld nur einen Wert hat, d.h. Listen mit unterschiedlich vielen Einträgen in einer separaten Tabelle gespeichert werden.
2.-5. NF: Jeder eingetragene Wert ausschliesslich vom (ganzen) Schlüssel abhängt und falls Werte irgendwie zusammenhängen, diese zusammen in einer seperaten Tabelle gespeichert werden.

Nun möchte ich, dass jeder der ein Lebensmittel eintragen will, diese in einer einfachen Maske eingegeben werden kann. Je nach Spalten-Art soll automatisch auf externe Tabellen verwiesen werden:
1. Aufzählungen wie "Inhalt: Wasser, Zucker, Salz" werden in einer separaten Tabelle(npartition) gespeichert.
2. Zusammenhängende Information wie "Deutsch: Wasser, Englisch: water, Französisch: eau" werden ebenfalls in einer separaten Tabelle gespeichert. Es genügt dann "Wasser" einzugeben.

Nun habe ich gemerkt, dass so etwas selbst mit php zu modellieren viel aufwändiger ist, als ich gedacht habe. Deshalb wollte ich fragen, ob es Software gibt, die diese Arbeit erleichtert. Ich glaube es gibt APIs, die Entity Relationship Modelle automatisch in SQL Datenbanken transferieren können. Allerdings keine Opensource/Freie Software.

Habt ihr sonst irgendwelche Ideen zu diesem Thema?
Wie wird das ganze in Grossunternehmen gelöst?

Besten Dank für jede Antwort!

 

[Hony%]

1. NF: Jedes Feld nur einen Wert hat, d.h. Listen mit unterschiedlich vielen Einträgen in einer separaten Tabelle gespeichert werden.
2.-5. NF: Jeder eingetragene Wert ausschliesslich vom (ganzen) Schlüssel abhängt und falls Werte irgendwie zusammenhängen, diese zusammen in einer seperaten Tabelle gespeichert werden.

Die Normalformen bedingen die vorherigen. Wobei die 5.NF ein Sonderfall ist, da die dekomponierten Daten nicht zwingend vollständig rekonstruiert werden können. Die BCNF ist meiner Meinung nach gut als Standard-Normalform zu gebrauchen.

Nun habe ich gemerkt, dass so etwas selbst mit php zu modellieren viel aufwändiger ist, als ich gedacht habe.

Datenbankdesign hat nichts mit der Programmiersprache zu tun. Wenn doch hast du einen Designfehler.

Deshalb wollte ich fragen, ob es Software gibt, die diese Arbeit erleichtert. Ich glaube es gibt APIs, die Entity Relationship Modelle automatisch in SQL Datenbanken transferieren können. Allerdings keine Opensource/Freie Software.

Das kommt natürlich auch auf die verwendete Datenbank an.
Auf die schnelle fallen mir zwei ein:
http://www.pgmodeler.com.br/
http://www.altova.com/de/databasespy.html

 

[damianh]

Danke für Deine Antwort. Das mit den Normalformen verstehe ich.

Du hast mich aber auf eine ganz wichtige Frage gebracht: Datenbankdesign ist unabhängig von der Programmiersprache, das ist klar. Nur soll meine Eingabe- und Suchmaske, die in einem Browser laufen soll (daher in PHP), Produkte eintragen und suchen können. Daher muss die PHP-Maske aus der Eingabe resp. für die Ausgabe entsprechende SQL-Anfragen erzeugen und Resultate darstellen -- da kommt man nicht drum rum, oder?

Ich möchte nun eine Engine mit Klassen und Vererbung etc. generieren, mit der Ein- und Ausgabe, sowie die gesamte Darstellung etc. möglichst simpel geschehen kann und das Datenbankdesign auch gleich entsprechend der Normalformen designt. Ich glaube ich weiss mitlerweile wie so etwas aussehen muss, ich habe mir ewigs den Kopf darüber zerbrochen.

Ich Frage mich nun gerade ob mir ein solcher Datenbank modellierer Arbeit abnehmen könnte. Ich denke ich weiss es wenn ich mir deine beiden Vorschläge mal angeschaut habe, im Moment kann mein Hirn aber gerade nicht mehr so gut denken

 

[Hony%]

Datenbankdesign ist unabhängig von der Programmiersprache, das ist klar.

Das ist der Teil von SQL den man auch Data Definition Language (DDL) nennt. Dieser Teil kann mit ER-Editoren entworfen werden.

Daher muss die PHP-Maske aus der Eingabe resp. für die Ausgabe entsprechende SQL-Anfragen erzeugen und Resultate darstellen

Das wird mit der Data Manipulation Language (DML) bewerkstelligt. Also zum Beispiel SELECT, UPDATE und DELETE.

Ich möchte nun eine Engine mit Klassen und Vererbung etc. generieren, mit der Ein- und Ausgabe, sowie die gesamte Darstellung etc. möglichst simpel geschehen kann und das Datenbankdesign auch gleich entsprechend der Normalformen designt.

Die Ein- und Ausgabe kannst du natürlich in Klassen kapseln. PDO und Prepared Statements sind hier einen Blick wert. Das Datenbankdesign (DDL) sollte zu diesem Zeitpunkt eigentlich fertig sein.

Eine Software die funktionale Abhängigkeiten analysiert und verschiedene Designentscheidungen gewichtet halte ich grundsätzlich für machbar. Aber ich bezweifle, dass sich der Aufwand lohnt.

Ich Frage mich nun gerade ob mir ein solcher Datenbank modellierer Arbeit abnehmen könnte.

Genau das ist das Ziel dieser Werkzeuge. Du kannst damit grafisch das ER-Modell/Relationenschema erstellen und anschließend als SQL ausgeben lassen.

 

[damianh]

Vielen Dank für die Stichworte. Ich werde mir alles genau anschauen!

 

[damianh]

Eine Software die funktionale Abhängigkeiten analysiert und verschiedene Designentscheidungen gewichtet halte ich grundsätzlich für machbar. Aber ich bezweifle, dass sich der Aufwand lohnt.

So meinte ich das nicht, das wäre ja unendlich aufwändig.

Ich meine eine Software, die eine Datenbank modeliert und Abfragen automatisiert. Die Logik dahinter ist dass jeder Eintrag ausschliesslich aus 1. atomaren Werten und 2. Fremdschlüssel zu anderen Einträgen besteht.

Die Tabellen werden dann automatisch definiert, Einträge und Abfragen durch einfache Befehle anstatt komplizierten Joins realisiert.

Ich frage mich einfach weshalb ich der einzige bin der das so machen will

 

[Hony%]

Ich meine eine Software, die eine Datenbank modeliert

Dann verstehe ich auch nicht was du damit meinst.

Die Logik dahinter ist dass jeder Eintrag ausschliesslich aus 1. atomaren Werten und 2. Fremdschlüssel zu anderen Einträgen besteht.

Auch da bin ich mir nicht so sicher was du eigentlich vor hast. Nicht-Schlüssel Attribute sind normalerweise "die Daten".

Die Tabellen werden dann automatisch definiert, Einträge und Abfragen durch einfache Befehle anstatt komplizierten Joins realisiert.

Ohne Joins bleibt nur eine einzige große Tabelle die dann auch maximal in der 1NF ist. Das kann sogar richtig schnell sein. Und kompliziert sind Joins eigentlich nur wenn man die zugrunde liegende relationale Algebra nicht versteht.

Ich frage mich einfach weshalb ich der einzige bin der das so machen will

Entweder du bist genial oder auf dem Holzweg. Ich befürchte allerdings Letzteres.

Datenbankdesign ist gar nicht so schwierig. Allerdings ist ein wenig solides Grundwissen über relationale Algebra sowie der Zusammenhänge von Funktionalen Abhängigkeiten und Normalformen hilfreich. Ansonsten handelt man sich gerne Designfehler und Anomalien ein. Alternativ aber auch einfach eine sehr langsame Datenbank.

 

[damianh]

Ja, "die Daten" meine ich mit "atomaren Werten".

Und Wissen über Datenbankdesign und über relationale Algebra habe ich durchaus -- va. theoretisches von der Uni, und mehr praktisches in Applikationsentwicklung. Ich glaube eben dass man sich durch eine höhere Abstraktionsebene langfristig viel Arbeitsaufwand sparen kann. (Joins werden daher schon durchgeführt, sie müssten nur nicht mehr jedes Mal von Hand modelliert werden.)

 

[ukulele]

Ich meine eine Software, die eine Datenbank modeliert und Abfragen automatisiert. Die Logik dahinter ist dass jeder Eintrag ausschliesslich aus 1. atomaren Werten und 2. Fremdschlüssel zu anderen Einträgen besteht.

Die Tabellen werden dann automatisch definiert, Einträge und Abfragen durch einfache Befehle anstatt komplizierten Joins realisiert.

Ich frage mich einfach weshalb ich der einzige bin der das so machen will

Sowas würde ich wohl auch machen aber es gibt zwei Dinge die mich davon abhalten:
1. Ich kann nur SQL, keine Programmiersprache.
2. Ich habe kein Anwendungsgebiet. Natürlich schon, aber die Menge an Daten ab der sich das speichertechnisch lohnt ist einfach nicht gegeben. Spannend wäre es schon.

 

[damianh]

Danke. Sehr hilfreich. Programmiersprachen kann ich zum Glück. Ob sich der Aufwand lohnt werde ich auch noch abschätzen müssen. Auf den ersten Blick denke ich immer "das ist ja ganz simpel". Und die Ausführung ist dann doch extrem aufwändig.

Ich werde es auf jeden Fall planen und prüfen und wenns zu viel ist doch traditionell eine Datenbank mit ERM etc. designen.

 

[ukulele]

Es ist ja nicht nur der Aufwand sondern ggf. auch noch Geschwindigkeit die verloren geht.

 

[damianh]

Wenn die Engine stimmt müsste auch die Geschwindigkeit stimmen.

 

[Hony%]

Ich glaube eben dass man sich durch eine höhere Abstraktionsebene langfristig viel Arbeitsaufwand sparen kann. (Joins werden daher schon durchgeführt, sie müssten nur nicht mehr jedes Mal von Hand modelliert werden.)

Sehe ich das richtig, dass du die Funktionalität von Views in die Anwendung verschieben willst?

 

[ukulele]

Theoretisch kann man das auch mit Views lösen. Ich denke es geht eher darum das Änderungen am Datenbanklayout automatisiert werden (z.B. über eine API oder per Trigger / View mit dynamischem SQL).

Aus:

CREATE TABLE autos(
    pk UNIQUEIDENTIFIER PRIMARY KEY,
    marke VARCHAR(20),
    modell VARCHAR(20)
    );

INSERT INTO autos(
    newid(),
    'Mercedes',
    'A100'
    );

wird dann:

CREATE TABLE text_values(
    pk UNIQUEIDENTIFIER PRIMARY KEY,
    fk_viewname VARCHAR(20),
    fk_viewkey UNIQUEIDENTIFIER,
    von DATETIME,
    bis DATETIME,
    valuename VARCHAR(20),
    valuedata VARCHAR(20)
    );

INSERT INTO text_values(
    newid(),
    'autos',
    newid(),
    '2014-01-01 00:00:00.000',
    NULL,
    'marke',
    'Marcedes'
    );

INSERT INTO text_values(
    newid(), -- selbe wie im vorherigen INSERT
    'autos',
    newid(), -- selbe wie im vorherigen INSERT
    '2014-01-01 00:00:00.000',
    NULL,
    'modell',
    'A100'

Ich kann mir aber nicht vorstellen das man Letzteres auf die selbe Geschwindigkeit bekommt.

 

[damianh]

Ja. Funktionalität von Views auf die Anwendungsseite verschieben ist sehr treffend ausgedrückt.

So wie ich es wahrnehme, kann SQL sehr viel aber nicht alles, wie eben eine richtige objektorientierte Programmiersprache.

Gerade wenn die Datenbank auch Online- Suchmaschine und -Shopsystem für den Endverbraucher werden soll, reichen Views eben nicht aus, sondern es kommen auch noch Formatier-Sachen, Bilddarstellung etc. hinzu. Die Frage ist dann immer was man auf Datenbank-Seite und was auf Anwendungs-Seite macht. Weil ich mit Anwendungs-Programmierung mehr Erfahrung habe als mit RDMS tendiere ich dazu zu viel auf der Anwendungsseite machen zu wollen. Daran Views zu benutzen habe ich gar nicht gedacht und Trigger erschienen mir unnötig kompliziert.