Fragen über Datenbanken

Datenbanksysteme Allgemeines
1

Wichtig! Es gibt nicht direkt einen Bereich Datenbanken, daher hier. Ich muss ein Prüfung schreiben, wichtig. :frowning:
Kennt ihr gute Seiten im Netz, Tutorials, Videos, etc., in denen Folgendes gut beschrieben oder erklärt wird:
sql, Syntax, Konstrukte, Anfragen an Datenbank, einfache Anfragen, komplizierte Anfragen über 5 Tabellen, z. B. über Tabelle 1, 3 und 5; ER-Modell oder ERM, „Datentypen“ oder „Datentypen“-Bezeichnungen im ER-Modell oder ERM; Theorie über Datenbanken, aber nicht so, ich will jetzt ne Datenbank entwerfen; und wie man eine Datenbank auf Windows 7 installiert, also nicht so kompliziert.

Diese Fragen gehen sollen auch an Bleiglanz, Landei, und Spacerat. Danke fürs Lesen.

2

Gefällt dir der Bereich hier nicht?
Verschoben. Wenn dir der Titel nicht gefällt, melden.

3

Ich habe mich hier durchgewühlt:
SQL Tutorial
Für praktische Aufgaben fand ich die Seite hilfreich. An Theorie mangelt es, meiner Meinung nach, leider.
Kleiner Tipp so am Rande: Bei Abfragen über viele Tabellen, lohnt es sich, mal bei den Joins reinzugucken. Es hilft die Abfrage strukturierter zu gestalten und sich nicht im Wirrwarr der Abfrage zu verheddern.
Zum Testen hab ich mir mal XAMPP gezogen und Übungsdatenbanken genutzt.

4

http://sql.learncodethehardway.org/book/

5

Wenn es ein MOOC-sein darf:

6

[QUOTE=Jango]Gefällt dir der Bereich hier nicht?
Verschoben. Wenn dir der Titel nicht gefällt, melden.[/QUOTE]

Nein, ist in Ordnung. Ich hab den Bereich nur zuerst nicht gesehen. :DaumenHoch:

Danke für die vielen Links/URLs. :daumen:hoch:

Btw. hab ich @mla.rue und @Bleiglanz eine wichtige PN geschrieben/geschickt. … Mal schauen, ob Sie Antworten. Bis morgen.

7

Bin weiter gekommen. ZB mySql unterteilt in 3 Kategorien:

Primary not null unique auto_increment,
Secondary not null unique,
Multi not null,

second und multi sind foreign keys und dürfen auch null sein, allerdings ist das nicht zu empfehlen.

8

Ok, jetzt/nun zu den komplizierten Anfragen.

a) Wie kann ich alle Zeilen einer Tabelle auswählen, auf die kein Fremdschlüssel einer anderen Tabelle zeigt?

b) Wie kann ich alle Zeilen einer Tabelle auswählen, auf die keine Fremdschlüssel 1 bis n anderer Tabellen zeigen (quasi: A.id != B.id AND A.id != C.id AND… bzw. A.id != B.id OR A.id != C.id OR …)? Versteht ir, was ich meine? Quasi Zeilen einer Tabelle, die noch nicht zugeordnet wurden.

TRUNCATE leider geht net auf Tabellen, zu denen es Tabellen gibt, die deren Attribute als Fremdschlüssel verwenden. (constraints)

c) Geben Constraints idealerweise die Reihenfolge beim Einfügen vor, wie kann ich bei AUTO_INCREMENT die neue id sofort beim Einfügen als Fremdschlüssel einer anderen Tabelle (beim Einfügen) verwenden?

Danke, wer sich diese schwierigen Fragen vornehmen möchte. :eek:

9

a) geht z.B. mit minus

[SQL]select * from A
MINUS
select a.* from A a, B b where a.id = b.fk[/SQL]

b) verstehe ich nicht. Siehe a)

c) geht z.B. mit Stored-procedures.
Dort alle Daten mitgeben und beim ersten Insert die ID zurückgeben lassen und damit dann die zweite Abfrage ausführen.

10

Danke für deinen Beitrag! Ja, das scheint logisch.

Nicht: Wähle jede Zeile aus, gehe alle anderen Zeilen der anderen Tabelle (n) durch.

Das ist leider so, wenn man als Progger nur die prozedurale, imperative und objektorientierte Sicht (sowie etwas deklarative und logische Sicht) gewöhnt ist.

Auch das theoretische kartesische Produkt umfasst viel zu viel.

a) Kannst du mir etwas über cross join, outer, inner, union und natural usw. join sagen?

b) Cross, outer und union würde ich zusammenfassen. Right?

c) Und wie füge ich sinnvoll ein, wenn ich A B C habe, und B sowohl Fremdschlüssel auf A wie C hat? Erst A C, aber wie sollte C dann mit A verknüpft werden?

d) Ist es legitim, wenn jede Tabelle immer ‘nur’ einen eigenen Primärschlüssel hat, der nix mit dem (n) Fremdschlüssel (n) in derselben Tabelle zu tun hat? Würdest du das auch so machen?

e) In Erstellungsskripten sieht das besser aus.

Wie gesagt, > 4 := (hab ich schon mal etwas zu geschrieben).

Noch eine gute Nacht. (Damit werd ich mich auch die nächsten Tage beschäftigen.)

11

ehrlich gesagt lassen sich die meisten Fragen allein mit google lösen :wink: bzw. müssten die in deinen Unterlagen stehen.

Das kommt immer auf die Situation an, du kannst auch aus zwei Fremdschlüssel einen Primärschlüssel bauen. Er muss halt nur eindeutig sein.

*** Edit ***

Also mal meine eigene Interpretation von deinem geschriebenen:
Primärschlüssel B ist, als Fremdschlüssel in A und C.
Somit musst du erst B anlegen, da du sonst keine Beziegung zwischen A und B, sowie C und B anlegen kannst.

*** Edit ***

https://www.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap7.htm

12

a) JOIN macht aus

a
b
c

und

1
2

das Ergebnis
(a,1)
(a,2)
(b,1)
(b,2)
(c,1)
(c,2)

in verschiedenen varianten (links alles, rechts alles, auf beiden seiten alles, NUR die verknüpften) (vgl left,right,outer, inner)

UNION macht aus

a
b
c

und

1
2

einfach (sofern die “gleichen” Spalten in beiden Resultsets/Tabellen vorhanden sind)

a
b
c
1
2

=> das ist was ganz anderes als ein JOIN

Und wie füge ich sinnvoll ein, wenn ich A B C habe, und B sowohl Fremdschlüssel auf A wie C hat? Erst A C, aber wie sollte C dann mit A verknüpft werden?

erst A und C, dann hast du die PKs von A und C und dann kannst du diese PKs als Fremdschlüssel beim Einfügen von B verwenden

Wieder mal schlecht formuliert: du schreibst “B sowohl Fremdschlüssel auf A wie C” und fragst dann “wie sollte C dann mit A verknüpft werden?”; das ist entweder unsinnig, ein Tippfehler, Getrolle oder echte genuine Unfähigkeit: C ist doch gar nicht mit A verknüpft?? WTF??

**Ist es legitim, wenn jede Tabelle immer ‘nur’ einen eigenen Primärschlüssel hat, der nix mit dem (n) Fremdschlüssel (n) in derselben Tabelle zu tun hat? **

Unverständlich. Jede Tabelle hat sinnvollerweise eine Primärschlüssel. Was meinst du mit “dem (n) Fremdschlüssel”, warum dem? DEM?

Wenn es in der Tabelle Fremdschlüssel auf andere Tabellen gibt, können diese sehr wohl Bestandteil des Primärschlüssels sein.

13

[QUOTE=Bleiglanz]

Wieder mal schlecht formuliert: du schreibst “B sowohl Fremdschlüssel auf A wie C” und fragst dann “wie sollte C dann mit A verknüpft werden?”; das ist entweder unsinnig, ein Tippfehler, Getrolle oder echte genuine Unfähigkeit: C ist doch gar nicht mit A verknüpft?? WTF??[/QUOTE]

A hat prim 1, B hat prim 2, C hat prim 3, B hat außerdem zwei Fremdschlüssel, dann trage “ich” in B (2, …, 1, 3) ein, dann ist Zeile 3 (aus C) mit Zeile 1 (aus A) “indirekt” verknüpft.

Also zusammengesetzte Schlüssel wichtig für union und natural? Schlüssel sollten doch nicht zusammengesetzt sein.

Entschuldigung, wenn man meine Formulierungen nicht sofort versteht.

Du bist heute gereizt.

Erst mal wärs das.

14

warum nicht?
Es gibt Tabellen wo es eine gute Entscheidung ist, das man z.B: mehrere Fremdschlüssel zu einen Primärschlüssel zusammensetzt.

15

[quote=Unregistered]a) geht z.B. mit minus[/quote]oder mit not in[SQL]select * from A
where a.id not in( select nvl(b.fk,-1) from B b)[/SQL]Falls fk in B nie null ist kann das nvl wegfallen.

[quote=Machareder;113064][quote=CyborgBeta;113063]d) Ist es legitim, wenn jede Tabelle immer ‘nur’ einen eigenen Primärschlüssel hat, der nix mit dem (n) Fremdschlüssel (n) in derselben Tabelle zu tun hat? Würdest du das auch so machen?[/quote]Das kommt immer auf die Situation an, du kannst auch aus zwei Fremdschlüssel einen Primärschlüssel bauen. Er muss halt nur eindeutig sein.[/quote]Es muss fachlich sinnvoll sein.
Ist die Tabelle ein reines Mapping um eine m-n Beziehung zu realisieren? Dann wäre ein zusätzlicher unabhängiger Primärschlüssel unnötig und die Kombination der Fremdschlüssel kann als Primärschlüssel genutz werden (sofer keine Kombination mehrfach vorkommen soll, oder ein Fremdschlüssel optional ist). Wenn es aber außer den Fremdschlüsseln weitere fachliche Attribute gibt, und die Fremdschlüssel sich unabhängig von diesen ändern können ist ein separater unabhängiger Primärschlüssel hilfreich.

[quote=CyborgBeta;113063]Auch das theoretische kartesische Produkt umfasst viel zu viel.
a) Kannst du mir etwas über cross join, outer, inner, union und natural usw. join sagen?[/quote]cross join ist genau dass: das karthesische Produkt.

inner join selektiert aus der beiden beteiligten Tabellen alle Einträge, für die die join-Bedingung (idR. Gleichkeit des FK->PK) zutrifft. Dabei wird jede Zeile aus der Tabelle, bei der das Attribut der PK ist so oft wiederholt, wie es entsprechende Treffer in der anderen Tablelle gibt, wo das Attribut der FK ist.

outer joinmach nur Sinn, wenn der FK NULL sein kann oder es keinen refferential constraint auf den FK-Attribut gibt. In dem Fall kann die Tabelle wo das Attribut der FK ist für diesen Werte enthalten, die in der referenzierten Tabelle nicht als PK vor kommen. outer join liefert auch diese Zeilen aus der abhängigen Tabelle.

union ist kein join.
Du erzeugst eine virtuelle Tabelle aus 2 Queries. ACHTUNG: beide Queries müssen übereinstimmende Anzahl von Attributen haben und deren Typen müssen in der Reihenfolge zusammen passen. Die Namen der Attribute müssen nicht gleich sein (zumindest bei Oracle).
BTW: wenn die 2 Queries keine überschneidende Ergebnismenge haben sollte man union all nutzen, weil beim union ohne all Oracle die Duplicate entfernt, wass natürlich Zeit kostst, selbst wenn es keine Duplikate gibt.

natural join ist gefährlich!
Oracle (andere womöglich auch) entscheidet auf Grund von Namensgleichkeit, welche Attribute die PF/PK Beziehung darstellen. Viele Anwendungen haben an den Tabellen “Status”-Attribute (zb: insert_date, update_date oder auch status). Die würde Oracle ebenfalls als FK/PK-Beziehung ansehen. Dass Du dann nie Treffer bekommst dürfte klar sein…
Schlimmer ist aber, dass Du Probleme bekommen kannst, wenn später ein Attribut zu einer Tabelle hinzugefügt wird, das es in einer anderen Tabelle schon gibt. Dann hat Deine Anwendung plötzlich keine Ergebnisse mehr und keiner weis warum…

bye
TT

16

Danke für alle eure Beiträge. Ich arbeite/lern jetzt im Stillen weiter, grob hab ich ja schon eine Einordnung/Zuordnung.

17

a)
Tabelle A erhält Primärschlüssel.
Tabelle B erhält Primärschlüssel, und Fremdschlüssel mit NULL-default und (NOT) UNIQUE zu A.

A sieht so aus:
1, ‘abcdeIRGENDWAS’
2, ‘abcdeIRGENDWAS’
…

B so:
1, ‘afcdeIRGENDWAS’, NULL
2, ‘abcdeIRGENDWAS’, 1
3, ‘abcdfIRGENDWAS’, NULL
…

Jetzt sieht man ja schnell, die ersten 4 Buchstaben aus Zeile 2 und 3 aus B sind gleich. Ich möchte jetzt Zeile 2 und 3 aus B zusammenfassen, weil sie mit den gleichen 4 Buchstaben anfangen, s. d. beide als Fremdschlüssel entweder 1 oder 2 erhalten, weil Zeile 1 und 2 aus A auch mindestens mit den gleichen 4 Buchstaben anfangen. Eine Gruppierung, wenn man so will, die nach und nach durchgeführt wird, bis in B kein NULL-Wert mehr steht.

Ob das “Konzept” sinnvoll sei, sei mal egal.

b)
Das mit dem MINUS hab ich hin bekommen:

SELECT f.id, f.name, s.* FROM FILMT f, SUL s, BESCHREIBUNG b, HAUPTSCHAU h WHERE s.id_t = f.id AND b.id_t = f.id AND b.id_ha = h.id AND f.id IN (SELECT id FROM FILMT WHERE id NOT IN (SELECT id_t FROM FILMU WHERE id_t IS NOT NULL)) ---- und sortieren, die Reihenfolge erschließt sich mir noch nicht

Eine s. g. Unterabfrage. Eine Abfrage in einer Abfrage in einer Abfrage. Vielleicht kann sql ja für mich optimieren.

Jetzt zu meiner Frage: Hättet ihr das auch so geschrieben?

18

[quote=CyborgBeta]Jetzt sieht man ja schnell, die ersten 4 Buchstaben aus Zeile 2 und 3 aus B sind gleich.[/quote]Bedeutet das, dass B eine innere Struktur hat?
Wenn ja, solltest Du schnellstens das Datenmodell ändern. Jedes feld in der DB muss eine einzige Eigenschaft repräsentieren. Wenn dem so wäre würde Dein Problem nämlich gar nicht auftreten.

bye
TT

19

Ja, sowohl die Spalte/Attribut von A als auch von B hat VARCHAR und eine innere Struktur. Ich bin noch nicht dazu gekommenen, das zu verändern. Denn dafür bräuchte ich erst mal die Syntax des Attributs, und einen Parser.

20

Kommen wir nun zu Namenskonventionen. Auch eigentlich ein spannendes Thema.

Tabelle AB:
id Numeric not null unique primär

Tabelle EF:
id Numeric not null unique primär

Tabelle CD:
id Numeric not null unique primär
id_ab1 Numeric (not) null (unique) sekundär
id_ef2 Numeric (not) null (unique) sekundär

Numeric: z. B. SMALLINT, …

id_… : referenziert andere Tabelle.

Meine Frage: Spalten/Attribute richtig benannt, auch mit Blick auf natural Join, natürlicher Join?

Danke, wer sonntags mitlesen möchte.