Krautkanal.com

Veröffentlicht am 2016-05-06 00:11:11 in /prog/

/prog/ 8782: Schemaentwurf

madebyvadim Avatar
madebyvadim:#8782

Ich hab 3 Tabellen in meinem Schema. A,B,C. A steht in einer 1:n Beziehung zu B und B steht in einer 1:n Beziehung zu C.

D.h. C ist transitiv von A abhängig, aber über mehrere Relationen hinweg.

Mach ich was falsch oder kann ich das so machen? Wie mach in ne Aggregation über C in Abhängigkeit von A?
Also zähle alle Einträge in C, welche in Abhängigkeit zu B stehen, welche gerade in Abhängigkeit zu meinem gegeben a ∈ A stehen.

aaronstump Avatar
aaronstump:#8783

>>8782
>Mach ich was falsch oder kann ich das so machen?
Wüsste nicht, warum nicht. Solange du in der 3. NF bist sollte es keine Probleme geben.
>Wie mach in ne Aggregation über C in Abhängigkeit von A?
Select Unterabfrage mit (inner) join B C ?

Sorry, bin mir selber nicht ganz sicher, lerne momentan gerade erst SQL :3

erikdkennedy Avatar
erikdkennedy:#8784

Normalformen sind nur über Abhängigkeiten innerhalb einer Relation, daher mach ich mir hier keine Sorgen.

Ich fand es halt nur sehr sperrig. Mir fällt aber auch keine andere semantisch äquivalente Lösung ein.

joshhemsley Avatar
joshhemsley:#8785

>>8784
Ich wollte damit eher sagen, dass sich es nach einem ganz normalen ER-Modell anhört
Du musst(solltest) ja letztendlich Attribute von Determinanten in eine andere Relation auslagern (Konsistenz), von daher passt das.

andychipster Avatar
andychipster:#8787

Mach ein konkretes Beispiel, wenn du wirklich eine Antwort haben willst.

jqueryalmeida Avatar
jqueryalmeida:#8789

>>8787
Okay, hier ist mein Schema. Ich soll ein Umfragetool entwerfen:

CREATE TABLE umfrage ( -- Tabelle A
id int auto_increment primary key,
name text not null,
-- ...
);
CREATE TABLE antwortmöglichkeit ( -- Tabelle B
id int auto_increment primary key,
umfrage_id int not null,
name text not null,
foreign key(umfrage_id) references (umfrage.id),
-- ...
);
CREATE TABLE antwort ( -- Tabelle C
id int auto_increment primary key,
antwortmöglichkeit_id int not null,
session_id text,
foreign key(antwortmöglichkeit_id) references (antwortmöglichkeit.id),
-- ...
);

katiemdaly Avatar
katiemdaly:#8791

>>8789
SELECT antwort.id
FROM antwort INNER JOIN antwortmöglichkeit
ON antwort.antwortmöglichkeit_id = antwortmöglichkeit.id
INNER JOIN umfrage
ON antwortmöglichkeit.umfrage_id = umfrage.id
WHERE umfrage.id = [dein a ∈ A]

So oder so ähnlich

t. Muss diese Woche über SQL-Abfrageoptimierung referieren Hab aber noch nichts gemacht

abdots Avatar
abdots:#8792

>>8789
>>8791
Sieht soweit in Ordnung aus, ausreichend normalisiert.
Mit der Abfrage erhälst du eine lange Liste an ausgewählten Antwort-IDs zu einer Umfrage.
Mit dem Ergebnis kannst du also eigentlich nicht viel anfangen, du willst ja wahrscheinlich die Summe der Antworten zu jeder Antwortmöglichkeit haben (quasi sowas wie "Ja": 255 mal ausgewählt, "Nein": 186 mal ausgewählt). Dafür kannst du GROUP BY verwenden.

grantrobinson Avatar
grantrobinson:#8793

>>8792

>>8791
Hier (und nicht >>8789)

Habe das mit dem Summe bilden weggelassen, daran sollte es ja nicht scheitern.

mhwelander Avatar
mhwelander:#8794

>>8792
>>8793
Da wir schon mal nen SQL-Faden haben, hätte ich auch mal ne kurze Frage

4. und 5. NF sind in der Praxis weniger oft zu finden, oder? Vielleicht noch 4. weil man das eh intuitiv macht?

carloscrvntsg Avatar
carloscrvntsg:#8799

>>8794
Ja, in der Praxis wird das alles eher intuitiv gemacht bzw. man orientiert sich daran, was man in der Anwendung braucht. Mit ein bisschen Erfahrung sieht man ja sehr schnell, dass da Redundanz entstehen würde.

ankitind Avatar
ankitind:#8804

>>8791
Normalerweise geben wir hier keine Hausaufgabenhilfe

>>8794
In der Praxis brichst du auch mal die erste Normalform oder so. Meistens lässt sich so sogar eine performantere Datenbank designen, da manche Daten eben in der Anwendung logisch zusammen hängen und man die gar nicht getrennt betrachten muss. Oder du hast hier mehrere Fremdschlüssel in allen.jpg Verteilt (Hier: C enthält den Schlüssel zu A genau wie B) dadurch pflegst du zwar 4 Bytes pro Zeile zuviel mit, lohnt sich aber meistens wenn es um die Abfragen und die Geschwindigkeit geht. Kein Mensch kehrt wenn du 1gb Indexdaten aufbaust die man nicht brauch. Jeder Mensch kehrt wenn es langsam ist.

p_kosov Avatar
p_kosov:#8811

>>8804
Interessant, danke.
Hört sich sinnvoll an.

Dachte zuerst man sollte schauen sein Zeug immer nach mind. der 3. NF aufbauen, weil ich das so mehr oder weniger aus meinen Unterlagen rausgelesen habe.

Wieder was gelernt.

vickyshits Avatar
vickyshits:#8818

>>8811
So lernt man das auch überall wenn es um Datenbanken geht. Geh mal in die Wirtschaft. Welcher Wissenschaftsheini verbietet mir da für 100% Performance den PK von A auch in C zu hinterlegen?

zacsnider Avatar
zacsnider:#8819

>>8818
Was sind Materialized Views?

Neuste Fäden in diesem Brett: