Fragen zum Stoff


Ich kann nur manche Fragen beantworten:
-Ja, Ontologien kommt definitiv nicht dran
-XML: Bei der Währungssache hast du Recht

Ich hoffe auch, dass XPath maximal mit Multiple Choice dran kommt… immerhin hatten wir es nicht einmal in der Vorlesung sondern nur auf den Folien!
Außerdem hoffe ich, dass Multidimensionale Modellierung nicht dran kommt, ich konnte dem Dozenten einfach nicht zuhören @.@ (und passender Weise fehlt bei den Videoaufzeichnungen auch genau dieses Kapitel >.>)


  1. Was genau meinst du? In sqlite hatte ich bisher keine Probleme, wenn ich es nicht getan habe.(Aber ich bin mir unsicher, ob das was ich gemacht habe, immer den Standards entsprach ;)).

  2. Unser Tutor hat soweit ich mich erinnere in seinen Übungen immer gemeint, dass Performanz nicht ausschlaggeben ist und dass es uns überlassen bleibt, welche Art von Join wir nutzen - wenn nichts anderes verlangt ist. Allerdings sollte ein gutes System da auch einiges optimieren können.


Du sollst nur Sachen machen, die im Standard erlaubt sind. Wenn sqlite das nicht kann, dann stehts wahrscheinlich im Standard so drin.

[quote=coMar]
2) Ist Performance relevant für die Richtigkeit unserer Lösung? Gerade bei mehr als 2 tables finde ich es wesentlich praktischer zum Lösen einfach die Kreuzprodukte zu benutzen und dann in der where-Klausel zu spezifizieren. Allerdings geht die Performance auch gerade bei mehr als 2 tables dabei vor die Hunde.
[/quote]Ich glaube kaum, dass Performance wichtig ist.
Ausserdem glaube ich, dass

from a, b
where a.att = b.att

und

from a
join b
using(att)

gleich behandelt werden. Da wird intern bestimmt optimiert (waer jedenfalls sinnvoll).


Danke für die schnellen Antworten

Zur Multidimmod:
Verlass dich nicht darauf dass nur Theorie dran kommt bzw das ganze Kapitel gar nicht dran kommt. In der letzten Klausur hat er nicht nur eine Modellierungs- sondern auch noch eine mapping/sql Aufgabe dazu gehabt in einer Dimension von ~20 Punkten.

/edit
Ich kann mich wirklich kaum daran erinnern (verdrängt!):
20 Punkte sind mehr oder weniger aus der Luft gegriffen.
Modellierungsteilaufgabe war glaube ich nach mE/R Übungsblatt 10 (A2 - Pannendienst)
SQL/Mapping war ähnlich wie die letzte Aufgabe auf dem Übungsblatt 10 (A3 - Umsatz - Star Shema/SQL)

Musst mal auf deine Ausgabe im sqlite achten: bei „select k.gewinn, […]“ steht dann auch „k.gewinn“ als Spaltenname


hi,

also ich hab noch ne frage zu einer Aufgabe aus dem 6. Übungsblatt zu SQL

Aufgabenstellung:

Bestimmen Sie alle Produkte, die der Kunde mit der Kreditkartennummer
4929092626735051 bestellt hat. Listen Sie im Ergebnis das Datum der Bestellung, die
Artikelbeschreibung, die Menge, den Einzelpreis, sowie einen Gesamtpreis als Produkt
aus Anzahl und Einzelpreis. Sortieren Sie anschließend aufsteigend nach Bestelldatum
und absteigend nach Gesamtpreis.

Tabellenkopf:

bestelldatum | produktbeschreibung | menge | einzelpreis | gesamtpreis

Lösung:

SELECT bestellung.bestelldatum
, produkt.produktbeschreibung
, bestellung_produkt.anzahl AS menge
, produkt.preis AS einzelpreis
, produkt.preis * bestellung_produkt.anzahl AS
gesamtpreis
FROM bestellung_produkt
JOIN produkt
USING (artikelnummer)
JOIN bestellung
ON bestellung_produkt.bestellung = bestellung.id
WHERE bestellung.kunde = 4929092626735051
ORDER BY bestelldatum ASC, gesamtpreis DESC;

Hab dazu ein paar Fragen:

wann benutzt man denn diese punktschreibweise? Immer nu bei JOIN? also, dass man quasi schreibt: produkt.preis statt preis.
wieso steht da nur FROM bestellung_produkt, obwohl bei der bestellung_produkt keine Kreditkartennummer dabei steht?
wird bei JOIN USING benutzt weil in beiden relationen die Artieklnummer drin vorkommt?
und wie muss ich das denn dann mit dem ON verstehen?

Ihr würdet mir mit anworten echt sehr helfen. SQL is echt nicht so meins. :confused:


[quote=me95zuho]
wann benutzt man denn diese punktschreibweise? Immer nu bei JOIN? also, dass man quasi schreibt: produkt.preis statt preis.
[/quote]Immer dann, wenn du gleichnamige Attribute in mehreren Tabellen hast. Also z.B. wenn du Student.name von Professor.name unterscheiden willst/musst.

[quote]
wieso steht da nur FROM bestellung_produkt, obwohl bei der bestellung_produkt keine Kreditkartennummer dabei steht?
[/quote]Weil du von bestellung_produkt nachher noch die anzahl brauchst (steht in deinem select drin). Wie kommst du denn auf Kreditkartennummer?

[quote]
wird bei JOIN USING benutzt weil in beiden relationen die Artieklnummer drin vorkommt?
[/quote]Ja.

[quote]
und wie muss ich das denn dann mit dem ON verstehen?
[/quote]Das weiss ich selbst nicht so genau, glaube aber, dass
from A join B on
das gleiche bedeutet wie
from A, B where
Weiss da jemand genaueres?


Korrekt, genauso ist es. Ich mache in meinen Anwendungen auch lieber die JOIN ON Variante, ist Geschmackssache


[quote=MalteM]

[quote=me95zuho]
wann benutzt man denn diese punktschreibweise? Immer nu bei JOIN? also, dass man quasi schreibt: produkt.preis statt preis.
[/quote]Immer dann, wenn du gleichnamige Attribute in mehreren Tabellen hast. Also z.B. wenn du Student.name von Professor.name unterscheiden willst/musst.

Gut. Ich glaub jetzt blick ich etwas besser durch.

Aber wieso die kreditkartennummer nicht gebraucht wird verstehe ich nicht eil in der aufgabenstellung steht ja:
Bestimmen Sie alle Produkte, die der Kunde mit der Kreditkartennummer
4929092626735051 bestellt hat.


Die Kreditkartennummer brauchst du schon, steht ja so auch in der Lösung drin.

FROM bestellung_produkt JOIN produkt USING (artikelnummer) JOIN bestellung ON bestellung_produkt.bestellung = bestellung.id

Du hast 3 Tabellen zu einer gejoint. In Bestellung ist ein Fremdschlüssel (Kunde) auf den Primärschlüssel Kreditkartennummer von Kunde. Auf die greifst du später mittels bestellung.kunde zurück.


[quote=MalteM]

äquivalent sind:
from table1 a join table2 b on a.attributAusTable1 = b.attributAusTable2

from table1 a, table2 b
where a.attributAusTable1 = b.attributAusTable2

Zumindest aus Ergebnissicht, denn beide liefern die gleiche Tabelle

from table1 a join table2 b using (gemeinsamesAttribut)

Während ich bei der ersten Variante, das gleichgesetzte Attribut 2 mal in der Tabelle hab, hab ich bei dieser Variante das gemeinsame Attribut nur einmal drin.

WHERE bestellung.kunde = 4929092626735051

Die wird direkt da eingesetzt wo sie als Fremdschlüssel auftaucht um sich einen weiteren join zu sparen.


achso okay danke.

Vielen dankf ür eure netten erklärungen!


Sooo :slight_smile: Jetzt hab ich auch wieder ne Frage :wink:

und zwar gehts mir um die Use-case Diagramme. Woher weiß man denn aus dem Text wann man da {abstract} drunter schreiben muss und wann nicht?

Und wie siehts aus dem dem <> und <>… zum Beispiel beim Übungsblatt 11 bei dem Use case diagramm. Wann benutz ich extrend und wann include?
Weil mir kommts so vor als wärs egal und man müsste nur die pfeilrichtung dementsprechend anpassen. Aber das kann ja ned sein? oder doch?

Bin grad echt verwirrt darüber…


<>: immer dann wenn eine Aktivität automatisch mit anderen ausgeführt wird. Z.B. wenn ein Benutzer etwas essen will, muss er früher oder später auch kauen und schlucken. Es gibt also eine include Beziehung von essen auf kauen und schlucken. Die Pfeilspitze zeigt dabei auf das kauen und schlucken (Richtung ist immer so bei include).

<>: Modelliert Ausnahmefälle wie es so schön auf der Folie heißt. Ein ‘Ausnahmefall’ beim essen wäre z.B. trinken. Ein Benutzer muss nicht unbedingt trinken, kann es aber manchen wenn er will. Die Pfeilspitzer ist hier genau andersherum, also von der ‘Ausnahme’ hin zum eigentlichen Anwendungsfall.

… ist vielleicht nicht das beste Beispiel :smiley:

In der Übung haben wir {abstract} relativ willkürlich (IMHO) verwendet. D.h. immer wenn mehrere Funktionen irgendwie gemeinsames Verhalten teilen, haben wir einfach einen weitere abstrakte Funktion eingeführt. Die kann nicht direkt ausgeführt werden (also keine Linie zum Benutzer), sondern gibt nur eine grobe Verhaltensstruktur für die restlichen Funktionen an. Funktioniert praktisch genauso wie abstrakte Klassen in Java, die lassen sich auch nicht initiieren.


dein trink beispiel hats mri aber jetzt verdeutlicht :smiley:

danke!

Deine erklärungen sind echt toll :slight_smile: ohne die würd ich gar nix raffen :blush:


-XPath: kam doch in der Vorlesung dran, ich zumindest war anwesend als er darüber „geredet“ hat :wink:
-Mitschnitt MultiDim: Konzeptionelle Modellierung


=.= Hat er nicht kurz vor XPath aufgehört?..

Ich hab mir die Vorlesung über Multidimensionale Modellierung jetzt mal per Video (danke, bulsa) angeguckt, aber was OLTP un OLAP wirklich sind, das habe ich immer noch nicht verstanden, kann mir das bitte jemand kurz und bündig erklären und vor allem auch, wo die Unterschiede sind? - Danke!


OLTP (Online Transaction Processing): Schwerpunkt liegt auf Schreiben von Daten. Überall dort wo die Datenbank im wesentlichen befüllt wird (z.B. bei Verkäufern die Daten von Kunden eingeben).

OLAP (Online Analytic Processing): Schwerpunkt liegt auf der Analyse. Nimmt die Daten die durch das OLTP enstanden sind und erlaubt es sie genauer zu untersuchen (z.B. Experten die versuchen rauszufinden welche Geschäfte besonders lukrativ sind…).

Kurz: das eine befüllt die Datenbank, das andere liest und bereitet die Daten beliebig auf (sehr grob gesprochen).

Auf den letzten Seite der Vorlesung ist auch noch mal eine sehr schöne Gegenüberstellung mit zig Unterschieden.

Hoffe das hilf…


OLTP: einfache Datenbank(en), bei der lauter Angestellte in vorgefertigte Forumlare Dinge zu konkreten Ereignissen eingeben und einsehen. Hier geht es darum kleine Datensätze festzuhalten/einzusehen
OLAP: am Ende von Perioden/Quartalen werden alle Datenbanken aus allen Bereichen eines Unternehmen genommen und ausgewertet von Managern/Analysten. Die nehmen dieses Data Warehouse und benutzen das um Analysen über das Unternehmen anzustellen (Customer-Relationship Management, Supply-Chain Management, etc…)


Danke ihr zwei, das hat wirklich sehr geholfen :wink:

Und weil ich schon gleich dabei bin: Während ich mir die Folien zu UML noch einmal durchgesehen habe, bin ich auf seq und par gestoßen, die irgendwie nicht wirklich Unterschiede aufweisen. Dann habe ich gegoogelt, bin aber leider auch nicht schlauer geworden. Ein Google-Ergebnis war allerdings interessant, da es aus dem Forum hier kam:

Kann jemand diese Antwort bestätigen? Ich glaube nämlich nicht, dass bei par die Reihenfolge der Interaktionen auf einer Lebenslinie egal ist. Leider helfen die Beispiel-Traces auf den Folien dazu nicht weiter, weil die essentiellen Beispiele fehlen.


Bei seq: müssen auf einer Lebenslinie wirklich alle der Sendungen nacheinander eintreten.
Bei par: muss das nicht Fall sein und auf einer Lebenslinlie können zum Beispiel schon Sendungen empfangen werden bevor vorherige Aufgaben erledigt wurden.

/edit hatte mich beeilt um schneller als Maddoc zu sein deshalb nochmal ausführlicher :stuck_out_tongue:

Bei par ist der entscheidende Unterschied soweit ich das verstanden hab, dass auf einer Lebenslinie jederzeit Sendungen empfangen werden dürfen; eigene Sendungen dürfen aber erst erfolgen wenn alle Vorgänger empfangen wurden.

Bin mir da aber auch ehrlich gesagt nicht 100%ig sicher