Default database "postgres": kann sie gelöscht werden?

saerdna schrieb:
Nicht, dass ihr mich falsch versteht: wenn manche Dinge nur via Befehl gehen ist das OK und ich wende das dann an. Aber im Moment möchte ich wenigstens die Basisoperationen wie Anlegen, Laden, Speichern, Löschen mit dem GUI-Tool erledigen können.
Zum Vergrößern anklicken....

Wozu? Grundlagen lernt man am besten mit den Basics. Wenn man weiß wie etwas manuell gemacht wird versteht man GUI Programme später besser. Wenn man nur GUI nutzt oder damit anfängt man hat sicher mehr Schwierigkeiten sich auf die CLI oder andere GUIs umzustellen, wenn es einmal nötig sein muss.
 
Werbung:
Dukel schrieb:
Wozu? Grundlagen lernt man am besten mit den Basics. Wenn man weiß wie etwas manuell gemacht wird versteht man GUI Programme später besser.
Zum Vergrößern anklicken....

Sehr richtig!

Grad so administrative Dinge (Backup erstellen, Backup einspielen) sollte man ohne GUI hinbekommen. Nein, muß man sogar, denn Backups will man automatisch erstellen, und auch automatisch prüfen. Eine "Klick mich hier" - GUI ist da eher nutzlos ...
 
Interessantes Thema. Eine Vertiefung würde hier jedoch zu weit führen. Ich bleibe skeptisch zur pauschalen Aussage "Das UI Konsole fördert das Verstehen besser als ein GUI". Wäre spannend, was es an empirischen Untersuchungen dazu gibt. Oder was Kognitionsforscher und Usability-Experten dazu sagen können.

Was Anderes:
Konzeptionell erstaunt es mich, dass es keinen SQL-Befehl zum "Restaurieren" einer Datenbank aus einer externen Quelle gibt. Und ebenso erstaunlich finde ich es, dass der Prozess "Restaurieren" genannt wird, wo es eigentlich ja um einen Import geht. Semantisch verstehe ich unter Restaurieren jedenfalls das Wiederherstellen eines zuvor existierende Zustands.

Wo wir bei Konzepten sind:
Sind euch erfahrene Datenbanker bekannt, die beim Entwurf einer neuen Datenbank zunächst ausschließlich mit Diagrammen modellieren - bis die Normalisierung abgeschlossen ist?
 
saerdna schrieb:
Konzeptionell erstaunt es mich, dass es keinen SQL-Befehl zum "Restaurieren" einer Datenbank aus einer externen Quelle gibt. Und ebenso erstaunlich finde ich es, dass der Prozess "Restaurieren" genannt wird, wo es eigentlich ja um einen Import geht. Semantisch verstehe ich unter Restaurieren jedenfalls das Wiederherstellen eines zuvor existierende Zustands.
Zum Vergrößern anklicken....
"Restaurieren" ist in diesem Fall die falsche Übersetzung von "restore".
Die korrekte Übersetzung ist in diesem Zusammenhang ist: "wiederherstellen".
Und das ("Wiederherstellen") ist auch genau das, was gemacht wird.

Der Inhalt eines Datenbank-Dumps ("logisches Backup") stellt den vollständigen Zustand der Datenbank dar, von dem Moment als der Dump erstellt wurde (präziser: von dem Moment wo der Dump-Prozess gestartet wurde).

Das Zurückspielen eines Dumps stellt exakt den Zustand der Datenbank wieder her, wie er beim Erstellen des Dumps war. Daher ist "restore" - Wiederherstellen - auch die korrekte Bezeichnung.

Von einem "Import" spricht man eher wenn man externe Daten in eine Datenbank einspielt. Z.B. eine CSV/Text Datei die von einem anderen System übertragen wurde. Letztendlich hängt das aber auch ein wenig vom Datenbanksystem am. Bei Oracle heißen die Tools für das logische Backup ("Snapshots") DataPump Export und DataPump Import - aber auch das sind Kommandozeilen Tools.

Die wenigsten Datenbanken bieten SQL Befehle zum zurückspielen eines Dumps an (eigentlich kenne ich das nur vom Microsofts SQL Server). Meistens liegt es an der Architektur des Systems. In Oracle kann man z.B. gar keinen SQL Befehl ausführen, wenn man keine "Datenbank" angelegt hat - wie also sollte man dann eine "Datenbank" zurückspielen. Aber der Begriff "Datenbank" bedeutet in Oracle auch etwas vollständig anderes als z.B. in Postgres oder SQL Server.

Grundsätzlich kann man durchaus mit Postgres ein System aufsetzen bei dem Benutzer einen "Dump" via SQL anstoßen oder einspielen können (habe ich erst kürzlich bei einem Kunden gemacht).

Die Postgres Entwickler halten das aber offensichtlich für nicht wichtig, da der Fokus dort auf Backuplösungen liegt welche für einen zentralen (z.B. unternehmensweiten) Datenbankserver wichtig sind. Und das sind nun mal Lösungen die sich automatisieren lassen (das ist bei Oracle, DB2 oder SQL Server nicht wesentlich anders). Außerdem laufen alle (Linux) Server ja ohne eine graphische Oberfläche, weswegen Tools um die Datenbank zu verwalten erst mal als Kommandozeilen-Befehl zur Verfügung stehen müssen.

Das Schöne an einer OpenSource Lösung ist aber: wenn sich genug Leute finden, die eine Steuerung via wichtig fänden, dann findet sich vermutlich auch jemand der es implementiert.
Vor 10 Jahren hat auch keiner geglaubt, dass Postgres mal eine eingebaute Replikation haben würde ;)

Es gibt noch einen Grund warum es kein SQL Befehl ist (zumindest bei Postgres): ein (logisches) Backup wird typischerweise nicht auf dem Datenbankserver erstellt oder gespeichert (es dient ja als Datensicherung und wen der DB-Server nicht mehr funktioniert, hätte man auch keinen Zugriff auf das Backup). Da dann aber ein Programm auf einem anderen Rechner verwendet werden muss, kann es kein (reiner) SQL Befehl sein, da ein Befehl der über SQL auf dem Server ausgeführt wird, ja nur auf dem Server Daten lesen und schreiben kann. Das ist es sinnvoller ein Client-Programm zu haben welches das erledigt, da dieses Programm dann auch auf dem "Backuprechner" die Daten direkt schreiben kann.

Um Deine Verwirrung bzgl "restore" oder "import" zu komplettieren: viele Begriffe in der IT-Welt haben in unterschiedlichen Umgebungen unterschiedliche Bedeutungen. Wie oben schon erwähnt ist "Datenbank" so ein Begriff. Wenn ein Oracle DBA von einer "Datenbank" redet meint er etwas vollständig anderes als ein Postgres oder SQL Server DBA. Ähnlich ist es mit den Begriffen "backup", "restore" oder "import". Die wenigsten DBAs (Postgres DBAs eingeschlossen) würden einen "Dump" als richtiges Backup bezeichnet. Ein Backup (zumindest im Kontext eines Datenbankservers) ist ein ständiger Prozess der alle gemachten Änderungen (Transaktionen) kontinuierlicher sichert in dem Moment wo sie passieren.

Postgres (wie auch Oracle, SQL Server, DB2 und andere Datenbankserver) ist für den Betrieb als zentraler Dienst ausgelegt, nicht als "Desktop-Datenbank" für einen einzelnen Benutzer wie z.B. Microsoft Access. Die Konzepte sind komplett unterschiedlich und das wirkt sich auf die Tools und die Prozesse wie bestimmte Dinge zu gemacht werden, aus.

saerdna schrieb:
Sind euch erfahrene Datenbanker bekannt, die beim Entwurf einer neuen Datenbank zunächst ausschließlich mit Diagrammen modellieren - bis die Normalisierung abgeschlossen ist?
Zum Vergrößern anklicken....
Ich ;)

Bei einfachen Modelle (3-4 Tabellen) lässt man das Diagramm schon mal weg, aber meistens bereut man es ein Jahr später wenn aus den 4 Tabellen auf einmal 40 geworden sind.

Eine der besten Methoden ein DB Modell zu dokumentieren ist und bleibt ein ER Model (und nein ein "UML" Modell ist kein vernünftiger Ersatz).

Ich betreue viele Entwicklungsprojekte beim Datenbankfragen und versuche immer die ständige Pflege des ER Modells durchzusetzen. Häufig gelingt mir das nicht, und dann kommen die Entwickler nach einem halben Jahr und fragen ob man nicht so ein schönes Diagramm erstellen könnte um die Datenbank dokumentieren. Das Problem ist, dass eine "schönes" Diagramm manuelle Pflege braucht - und das geht am schnellsten wenn man es kontinuierlich pflegt. Automatisch erstellte Diagramme sind meistens sehr schwer zu lesen - ich habe jedenfalls noch keine wirklich brauchbares automatische Layout gesehen.

Was ich damit sagen will: Dein bestreben ein ER Modell zu erstellen ist sehr sinnvoll und jeder professionelle DB Entwickler (bzw. Modellierer) wird Dir dabei Recht geben.
 
@castorp
Vielen Dank für die interessanten Hintergründe und Erklärungen zu "restore", "Backup", etc.

Zu ERM:
Gut zu wissen, dass Du und andere Profis das für nützlich halten. Kannst Du (oder ein anderer Leser hier) mir vielleicht eine Handvoll "schöner" Diagramme nennen oder per PM zusenden, damit ich mal eine Ahnung bekomme, was ihr genau mit hoher Qualität meint.
Insbesondere interessiert mich, ob die FKs in den Diagrammen eine Rolle spielen. Wenn ich es bisher richtig sehe, kommen nur Entitätsmengen, Attribute, Assoziationen und Kardinalitäten zum Einsatz. Gibt es also gar keine Diagramme/Visualisierungen, die auch die Verwendung der FKs abbilden?

Welche Software verwendest Du zum Zeichnen der schönen Diagramme?

Gibt es Software, die aus einem Diagramm einen Tabellensatz mit allen Spalten erzeugt?
 
saerdna schrieb:
Insbesondere interessiert mich, ob die FKs in den Diagrammen eine Rolle spielen. Wenn ich es bisher richtig sehe, kommen nur Entitätsmengen, Attribute, Assoziationen und Kardinalitäten zum Einsatz. Gibt es also gar keine Diagramme/Visualisierungen, die auch die Verwendung der FKs abbilden?
Zum Vergrößern anklicken....
Die Linien zwischen den Entitäten sind die FKs

saerdna schrieb:
Welche Software verwendest Du zum Zeichnen der schönen Diagramme?
Zum Vergrößern anklicken....
Wir verwenden Toad Data Modeller.

Eine etwas günstigere Lösung ist DbSchema: The Best Database Management & Diagram Design Tool das läuft auch auf dem Mac

Es gibt eine OpenSource Lösung für Postgres: https://pgmodeler.io/
Für vor-compilierte Binaries möchte der Entwickler eine Spende haben, ansonsten müsstest Du das selber compilieren.

Das einzige halbwegs brauchbare freie Tool das ich kenne ist Data Modeling & Profiling Tool: SQL Power Architect | SQL Power Software da bin ich mir aber nicht sicher in wie weit das noch gepflegt wird.

saerdna schrieb:
Gibt es Software, die aus einem Diagramm einen Tabellensatz mit allen Spalten erzeugt?
Zum Vergrößern anklicken....
Das kann eigentlich jedes vernünftige ER Tool.
 
@castorp
Die Linien zeigen eben nur auf die ganzen Tabelle (Entitätsset) und nicht auf den FK.

Danke für die Hinweise zu den Tools.

Bei dem von Dir genannten Tool DBSchema, sehe ich erstmals ein Diagramm, wo die FKs auf der Linie stehen.
https://www.dbschema.com/images/overview/database-diagram.png

Falls doch jemand meiner Bitte um einige schöne (hochwertige) ER-Diagramme nachkommen möchte: ich freue mich drüber.
 
Zuletzt bearbeitet:
Hier nochmal ein Diagramm der weiter oben besprochenenen Beispieldaten, erzeugt in DBSchema, mit FKs auf den Linien:

Dropbox - Screenshot 2018-08-27 10.02.58.png

Ist es richtig, dass die Darstellung von FKs auf den Linien in der Spezifikation von ERM-Diagrammen nicht vorgesehen ist?
Stellt es sozusagen eine Anreicherung durch den Softwarehersteller dar?
 
@castorp
Bezeichnest Du (in Verbform) in Deinen ER-Diagrammen die Beziehung zwischen zwei Entitäten?

Beispiel: https://upload.wikimedia.org/wikipedia/de/thumb/a/ab/Er-diagramm.svg/600px-Er-diagramm.svg.png

Noch nicht klar ist mir anhand der (Chen-)Notation, wie man dort die Leserichtung festlegt.
Die Raute ist ja ungerichtet.

Wird hier allein auf die übliche Leserichtung rechts->links und oben->unten vertraut?
Oder existieren Notationen (Symbole) die die Leserichtung für solche Beziehungen eindeutig festlegen?
"Buch verfasst Autor" will ja niemand.

Dann fällt mir noch auf, dass in der Chen-Notation überhaupt keine Zuordnung der Beziehung zu einem FK vorgesehen ist.

Ist es richtig, dass im DBMS selbst keine formale Dokumentation der Beziehungen vorgesehen ist? Handelt es sich vielmehr um eine optionale Dokumentation durch den Datenbankmodellierer?

Zu vorbildlichen ER-Diagrammen von Beispieldatenbanken werde ich nochmal im allgemeinen Forum nachfragen, weil hier ja niemand welche nennen möchte ;)
 
Zuletzt bearbeitet:
Bezeichnest Du (in Verbform) in Deinen ER-Diagrammen die Beziehung zwischen zwei Entitäten?
Zum Vergrößern anklicken....
Eigentlich nicht, da man jede Beziehung in beide Richtungen lesen kann (siehe unten). Wenn überhaupt, dann ein Verb welches die "Hauptrichtung" bezeichnet.

Meistens vergebe ich nur die technischen Namen der daraus resultierenden FK constraints. Ich modelliere aber immer das physische ER Modell. Die Idee des logischen (oder konzeptionellen) Modells ist zwar nett, in der Realität aber nicht wichtig, da ich ja immer das Modell in irgendeiner Datenbank erstelle. Und dann brauche ich halt die Link-Tabellen für M:N Relationen und möchte die Tabellennamen vergeben.

Noch nicht klar ist mir anhand der (Chen-)Notation, wie man dort die Leserichtung festlegt.
Die Raute ist ja ungerichtet. Wird hier allein auf die übliche Leserichtung rechts->links und oben->unten vertraut?
Zum Vergrößern anklicken....
Natürlich ist sie das, weil sie eine M:N Beziehung darstellt die in beide Richtungen gelesen werden kann.
  • Ein Buch wird von einem Autor verfasst.
  • Ein Autor verfasst ein Buch.
In einem physischen ER Modell (Dein Bild ist ein logisches ER Modell) wird die Raute ja zu einer Tabelle.
Ich verwende immer die "Krähenfußnotation" weil ich das lesbarer finde.
"Buch verfasst Autor" will ja niemand.
Zum Vergrößern anklicken....
Naja, "ist geschrieben von" vermutlich schon.

Ist es richtig, dass im DBMS selbst keine formale Dokumentation der Beziehungen vorgesehen ist? Handelt es sich vielmehr um eine optionale Dokumentation durch den Datenbankmodellierer?
Zum Vergrößern anklicken....
Doch natürlich: Foreign Key Constraints: PostgreSQL: Documentation: 10: 5.3. Constraints

Die sind nicht nur für die Konsistenz der Daten wichtig, sonder helfen auch beim Verstehen von Datenbanken für die es eben kein ER Diagram gibt.
Ausserdem helfen sie beim Schreiben von Joins, da man sofort weiß welche Spalten für die Join-Bedingung verwendet werden müssen. (das Tool das ich verwende kann die JOIN Bedingungen automatisch in einem SQL Statement vervollständigen wenn die entsprechenden FK constraints definiert sind)

Zu vorbildlichen ER-Diagrammen von Beispieldatenbanken werde ich nochmal im allgemeinen Forum nachfragen, weil hier ja niemand welche nennen möchte
Zum Vergrößern anklicken....
Die Modelle die ich beruflich erstelle, darf ich nicht veröffentlichen, da sie ja dem Kunden gehören.
Zudem sind das meistens Modelle mit mehreren 100 Tabellen (das Größte hat über 1000), die auf verschiedene Diagramme aufgeteilt werden. Das ist als Bitmap in Upload-freundlicher Größe nicht wirklich lesbar.

@Walter: So langsam sollten wir diesen Thread auftrennen. Diese Diskussion hat nichts mehr mit "Darf ich die Default-DB von Postgres löschen" zu tun.
 
@castorp
Danke für Deine hilfreiche Antwort. Vor allem ist mir jetzt klar, dass Du Dich bei den Diagrammen auf die Modellage der physischen DB fokussierst und nicht auf dem universelleren Modell der betrachteten realen Situation.

Zu "Ist es richtig, dass im DBMS selbst keine formale Dokumentation der Beziehungen vorgesehen ist?":
Damit meinte ich die Bezeichnung einer Beziehung mit einem Verb, im Beispiel wäre das "verfasst". So eine verbale Bezeichnung wird in Postgres nicht dokumentiert, oder?

Zu Veröffentlichung von ER-Diagrammen:
Das ist natürlich klar, dass hier niemand seine im Beruf erstellten ER-Diagramme (mit möglicherweise schutzwürdigen Daten) posten kann. Daher auch mein Smiley.
Ich dachte eher an private, freie Projekte an denen vielleicht einige hier auch arbeiten.

Zu Foreign Key Constraints:
Das ist bei meinem geringen Wissensstand im Moment zu schwieriger Stoff, aber ich habe das auf Schirm. Kommt später mal dran.
 
Damit meinte ich die Bezeichnung einer Beziehung mit einem Verb, im Beispiel wäre das "verfasst". So eine verbale Bezeichnung wird in Postgres nicht dokumentiert, oder?
Zum Vergrößern anklicken....
Du kannst dem constraint einen Namen geben, und Du kannst einen Kommentar für den Constraint definieren.

Code: 
create table buch
(
  id            integer primary key,
  titel         varchar(100) not null,
  anzahl_seiten integer,
  erschienen_in integer
);

create table author
(
  id        integer primary key,
  vorname   varchar(100),
  nachname  varchar(100) not null
);

-- diese Tabelle wäre die "Raute" im logischen ER Modell
create table buch_author
(
   author_id integer not null,
   buch_id   integer not null
);

alter table buch_author
   add constraint verfasst_von
   foreign key (author_id) references author;
  
alter table buch_author
   add constraint hat_verfasst
   foreign key (buch_id) references buch;

comment on constraint verfasst_von on buch_author is 'Der Author der dieses Buch verfasst hat';
comment on constraint hat_verfasst on buch_author is 'Das Buch welches dieser Author verfasst hat';
 
Werbung:
saerdna schrieb:
Ich habe jetzt statt des Formates TAR das "Format" directory gewählt.

Der Dialog von DBeaver hat einen Fehler, denn er erlaubt keine Auswahl eines Verzeichnisses, sondern nur einer Datei.
Wenn ich den Pfad danach manuell kürze, klappt alles.
Zum Vergrößern anklicken....
Ich hatte den Fehler in der Community von DBeaver gemeldet.
Es ist ein bestätigter Bug:
Pg_restore directory format still not working -5.1.6 · Issue #4090 · dbeaver/dbeaver
Nur der Vollständigkeit halber.
 
Zurück
Oben