Soll die Anfrage in 4 c) derart redundant sein oder liegt ein Fehler vor?

Normal denk ich mir: das ist Absicht um die "Sinne zu schärfen"
aber:
bin erst bei 3. aber selbst diese Aufgabe ist fehlerhaft
beim ProjektArbeiter
Leiter → Personal.PID
Nur dass es in der Tabelle keinen "Leiter" gibt…

Genau wegen diesem Flüchtigkeitsfehler (gemeint ist wohl "PID -> Personal.PID") und dem Vertipper in 4 b), wo es statt "Abteilungen" zweimal "Abteilung" heißt, frage ich nach. ;)

andere frage zu 4.: ist das normal, dass da kardinalitätswerte <1 rauskommen? ich dachte, das soll die tupel- bzw. zeilenanzahl darstellen?

Soll die Anfrage in 4 c) derart redundant sein oder liegt ein Fehler vor?

Auf den ersten Blick finde ich das doch ganz gut und würde keinen Fehler vermuten. Es muss halt optimiert werden und da kann es sein, dass die Ausgangsanfrage Redundanz enthält.

bin erst bei 3. aber selbst diese Aufgabe ist fehlerhaft
beim ProjektArbeiter
Leiter → Personal.PID
Nur dass es in der Tabelle keinen "Leiter" gibt…

Scheint wirklich ein Tippfehler zu sein, gemeint ist wohl PID → Personal.PID, dann macht das wieder Sinn.

andere frage zu 4.: ist das normal, dass da kardinalitätswerte <1 rauskommen? ich dachte, das soll die tupel- bzw. zeilenanzahl darstellen?

Ja das ist möglich, da es ja eine Berechnung auf statistischen Werten(SF) ist. Und wenn man nun 5Tupel hat und einen Selektivitätsfaktor von 1/500 dann kommt man auf 1/100 Tupel..

Soll die Anfrage in 4 c) derart redundant sein oder liegt ein Fehler vor?

Auf den ersten Blick finde ich das doch ganz gut und würde keinen Fehler vermuten. Es muss halt optimiert werden und da kann es sein, dass die Ausgangsanfrage Redundanz enthält.

Naja, die ersten beiden Teilaufgaben enthielten einigermaßen sinnvolle Anfragen, insofern tanzt c) schon mal etwas aus der Reihe.
Ich nehme zudem an, dass auf den zweiten Blick - nämlich beim Betrachten des Datenbankschemas aus Aufgabe laut Aufgabenstellung - nicht auf die dortigen Einträge geachtet werden soll (denn PID 22 ist ja dezidiert angegeben)?

Ich denke, dass man sich bei Aufgabe 4 auf die Berechnung der Zwischenergebnisse anhand von Kardinalitäten und Selektivitätsfaktoren beschränken sollte und einzelne Datenbankeinträge aus Aufgabe 3, mit denen eine Anfrage zufällig konkret beantwortet werden kann, getrost vernachlässigen darf.

In Aufgabenblatt 3 haben sich leider tatsächlich zwei kleine Tippfehler eingeschlichen:

Aufgabe 3: bei der Relation "ProjektArbeiter" ist statt "Leiter → Personal.PID" die Beziehung "PID → Personal.PID" gemeint.

Aufgabe 4b: hier ist stets die Relation "Abteilungen" an Stelle von der nicht existierenden Relation "Abteilung" gemeint.

Soll die Anfrage in 4 c) derart redundant sein oder liegt ein Fehler vor?

Naja, die ersten beiden Teilaufgaben enthielten einigermaßen sinnvolle Anfragen, insofern tanzt c) schon mal etwas aus der Reihe.

Was meinst du mit "redundant" und "tanzt aus der Reihe"? Die Anfrage in Aufgabe 4c) ist durchaus sinnvoll. Hast du dir die exakte Bedeutung klar gemacht?

Ich denke, dass man sich bei Aufgabe 4 auf die Berechnung der Zwischenergebnisse anhand von Kardinalitäten und Selektivitätsfaktoren beschränken sollte und einzelne Datenbankeinträge aus Aufgabe 3, mit denen eine Anfrage zufällig konkret beantwortet werden kann, getrost vernachlässigen darf.

Genau so ist es gedacht.

Soll die Anfrage in 4 c) derart redundant sein oder liegt ein Fehler vor?

Naja, die ersten beiden Teilaufgaben enthielten einigermaßen sinnvolle Anfragen, insofern tanzt c) schon mal etwas aus der Reihe.

Was meinst du mit "redundant" und "tanzt aus der Reihe"? Die Anfrage in Aufgabe 4c) ist durchaus sinnvoll. Hast du dir die exakte Bedeutung klar gemacht?

Gesucht sind mMn PID, Vorname und Nachname des Projektleiters mit der PID=22 und dem Nachnamen=Meier. Dass ausgerechnet zwei Attribute, nach denen innerhalb der Abfrage aussortiert wird, am Ende wieder dargestellt werden sollen, ist im Vergleich mit den Voraufgaben neu, insofern wird hier "aus der Reihe getanzt".
Aber redundant und damit nicht wirklich sinnvoll sind z.B. auch der natürliche Verbund von Personal mit ProjektArbeiter, obwohl die Anfrage nur an Projektleitern interessiert ist, oder auch die Selektion des Nachnamens Meier, nachdem bereits eine einzelne Person selektiert wurde, deren Nachname letztlich auch Teil der abschließenden Projektion ist.

Gesucht sind mMn PID, Vorname und Nachname des Projektleiters mit der PID=22 und dem Nachnamen=Meier. Dass ausgerechnet zwei Attribute, nach denen innerhalb der Abfrage aussortiert wird, am Ende wieder dargestellt werden sollen, ist im Vergleich mit den Voraufgaben neu, insofern wird hier "aus der Reihe getanzt".

Diese Interpretation ist nicht korrekt. In der Aufgabe steht "Leiter=22" und nicht "PID=22". Die Kritik an der Projektion auf Nachname ist jedoch nachvollziehbar. Man kann sie allerdings damit begründen, dass ein schönes Ergebnis gewünscht ist, welches alle interessanten Daten (eben Vor- und Nachname, sowie PID) enhält.

Aber redundant und damit nicht wirklich sinnvoll sind z.B. auch der natürliche Verbund von Personal mit ProjektArbeiter, obwohl die Anfrage nur an Projektleitern interessiert ist

Diese Folgerungen sind ebenfalls nicht korrekt, da sie aus der falschen Interpretation folgen. Beachte, in welchen Relationen die Attribute liegen, auf die selektiert wird.

Diese Interpretation ist nicht korrekt. In der Aufgabe steht "Leiter=22" und nicht "PID=22". [..] Beachte, in welchen Relationen die Attribute liegen, auf die selektiert wird.

Aber Leiter verweist doch auf PID, d.h. das Ergebnis der Anfrage stammt aus Personal, auch wenn "Leiter=22" zunächst auf einer anderen Relation selektiert. Deshalb auch meine Formulierung "Projektleiter mit ID.." anstelle von "Mitarbeiter mit ID..".

Aber Leiter verweist doch auf PID, d.h. das Ergebnis der Anfrage stammt aus Personal, auch wenn "Leiter=22" zunächst auf einer anderen Relation selektiert.

Nein. Schau dir nochmal genau die Definition des natürlichen Verbunds im Skript an. Fremdschlüssel-Eigenschaften finden dort keine Berücksichtigung, da Fremdschlüssel lediglich Integritätsbedingungen darstellen. Integritätsbedingungen werden bei Anfragen jedoch nicht berücksichtigt, da das Datenbanksystem davon ausgeht, dass die gespeicherten Daten konsistent sind (was ja durch Integritätsbedingungen sichergestellt ist).

Nein. Schau dir nochmal genau die Definition des natürlichen Verbunds im Skript an. Fremdschlüssel-Eigenschaften finden dort keine Berücksichtigung, da Fremdschlüssel lediglich Integritätsbedingungen darstellen. Integritätsbedingungen werden bei Anfragen jedoch nicht berücksichtigt, da das Datenbanksystem davon ausgeht, dass die gespeicherten Daten konsistent sind (was ja durch Integritätsbedingungen sichergestellt ist).

Ahh.. Alles klar, das hatte ich nicht berücksichtigt. Vielen Dank!

also das einzig wirklich komische bei 4 ist find ich die Anzahl der Projektleiter und die Anzahl der Projekte:

Anzahl der Projekte = 50

Projektleider ist jeder 25., also 2000/25 = 80

.. und da jedes Projekt eine feste PrID hat kann auch nicht ein Leiter mehrere Projekte leiten…

.. und da jedes Projekt eine feste PrID hat kann auch nicht ein Leiter mehrere Projekte leiten…

Was hat die PrID damit zu tun? Die Leitung eines Projektes ist in diesem Fall eine 1 zu n Beziehung, d.h. jedes Projekt hat einen Leiter, und jeder ProjektArbeiter kann beliebig viele Projekte leiten. Das wird dadurch gewährleistet, dass der Leiter als Fremdschlüssel in der Relation Projekte angeben ist.

Was ich mich dabei aber frage ist, warum bei Projekte "Leiter -> Personal.PID" statt "Leiter -> ProjektArbeiter.PID" steht. Semantisch gesehn könnte demnach auch ein Mitarbeiter, der kein ProjektArbeiter ist, ein Projekt leiten. Oder ist es nicht möglich, einen Fremdschlüssel auf einen Fremdschlüssel einer anderen Relation abzubilden?