Fachrat Informatik - Forum

Quoted

Original von Diktator
[list]1. zu sperren
gibt es eine reihenfolge bezüglich mehrerer aufeinanderfolgender unlocks? also gibt es z.b. einen unterschied zwischen <unlock A, unlock B> und <unlock B, unlock A>?
[/list]

[list]
Nein, da die eigentliche Anweisung ein commit ist und dieser dann sämtliche unlocks impliziert. Also gibt es da keinen Unterschied. Nicht wirklich eine Begründung, aber die Sperren werden meiner Meinung nach quasi zeitgleich aufgehoben, so dass sich keine andere Transaktion, welche auf die Freigabe von z.B. A wartet, vor unlock B schieben kann.

Quoted

2. zu Aufgabe 12.2 a)
herr brügemann hat zu transaktion 1 an die tafel geschrieben:
lock A, write A, read G, unlock A.
müsste es aber nicht
lock A, write A, rwarn C, rlock G, read G, unlock A
korrekt heissen?

[/list]

Quoted

danke für alle antworten.

Das stimmt schon so, da laut Folie 6.17 lock A ein Sperren von A und aller Teilobjekte bewirkt, C und G sind somit gesperrt. Ein Warnen oder "Lesesperren" wäre eine Abschwächung der Sperre und somit nicht zulässig.

Quoted

Original von Informatik Minister

Quoted

Original von Diktator
[list]1. zu sperren
gibt es eine reihenfolge bezüglich mehrerer aufeinanderfolgender unlocks? also gibt es z.b. einen unterschied zwischen <unlock A, unlock B> und <unlock B, unlock A>?[/list]

Nein, da die eigentliche Anweisung ein commit ist und dieser dann sämtliche unlocks impliziert. Also gibt es da keinen Unterschied. Nicht wirklich eine Begründung, aber die Sperren werden meiner Meinung nach quasi zeitgleich aufgehoben, so dass sich keine andere Transaktion, welche auf die Freigabe von z.B. A wartet, vor unlock B schieben kann.

Prinzipell können sich auch andere Transaktionen "dazwischenschieben", das hängt von der Sichtweise ab.

Wenn man das Commit als Anweisung sieht, die Unlocks implizit ausführt, bilden die Unlocks und das Commit in der Tat einen untrennbaren Anweisungsblock.

Faßt man das Commit jedoch als Anweisung auf, die erst ausgeführt werden darf, wenn vorher explizit Unlocks erfolgt sind, können sich sehr wohl andere Transaktionen (die z. B. auf "unlock A" gewartet haben) "dazwischenschieben". Ich tendiere eher zu dieser Sichtweise.

Aber die Reihenfolge der unlock-Anweisungen vor dem commit ist in der Tat egal.

Was versteht man unter Modellinhärente Integritätsbedingungen??? Ich kann leider mit diesem Wort nicht viel anfangen und aus dem Skript verstehe ich das nur so halb. Kann jemand eine verständliche Erklärung abgeben? Danke.
mfg
MAX

Quoted

Original von MAX
Was versteht man unter Modellinhärente Integritätsbedingungen??? Ich kann leider mit diesem Wort nicht viel anfangen und aus dem Skript verstehe ich das nur so halb. Kann jemand eine verständliche Erklärung abgeben?

Inhärent bedeutet soviel wie "mit etwas zusammenhängend", "an etwas haftend" oder "innewohnend".

Modellinhärente Integritätsbedingungen sind daher Integritätsbedingungen, die sich bereits durch das Relationenschema ausdrücken lassen.

Eine solche Integritätsbedingung ist zum Beispiel: "Das Attribut X darf keine Nullwerte enthalten."

Eine nicht modellinhärente Integritätsbedingung ist beispielsweise: "Der Mittelwert über alle Attributwerte des Attributes X muß kleiner als 1000 sein."

Quoted

Original von Diktator

Quoted

Original von Joachim
Eine solche Integritätsbedingung ist zum Beispiel: "Das Attribut X darf keine Nullwerte enthalten."

fällt darunter ausser not null und unique noch was?

Alles, was auf den Folien 2.32 und 2.33 steht.

Quoted

Original von Diktator
aber ich könnte mir vorstellen, dass eine solche abfrage unmöglich ist, weil keine schleifenbildung möglich ist.
ist meine überlegung richtig?

Ja habe ich auch so geschrieben und volle Punktzahl bekommen. Eine feste Verschachtelungs-Tiefe ist in RA möglich, beliebig viele Verschachtelungen sind es nicht.

Quoted

Original von Diktator
leider bin ich mir hier nicht über die richtige antwort sicher. aber ich könnte mir vorstellen, dass eine solche abfrage unmöglich ist, weil keine schleifenbildung möglich ist.
ist meine überlegung richtig?

Diese Fluglinien-Relation ist ein klassisches Beispiel für die Grenzen der Relationenalgebra bezüglich Bestimmung der transitiven Hülle einer zweistelligen Relation.

Und es es nach Folie 3.16 keinen solchen Operator gibt, ist auch eine Abfrage wie in Aufgabe 3.2e nicht mit der Relationenalgebra formulierbar.

Da hab ich auch nochmal n paar Fragen:

Übung3 Ist das beides auch richtig?
2b) Pie (Eqipment) (G (to<>Paris)(Schedule) Join (Usable)
2c) Pie (Pilot,Flight) G(From = Base) (Schedule join Based)

Übung 5
1b) Warum muss vor das Gamma noch was vor?

Übung 6
1) Geht das auch?
(Pie (Pres_name) (G (P.party = Republican) (President p) join G(m.Nr_children>1) (Pres_Marriage m) join G (h.hobby=Riding) (Pres_hobby h))) – pie (e.candidate) G(WinnerLoserIndic = L) (Election e)

Übung 7
1d) Was bedeutet das genau? < = >

Übung 8
Woran erkenn ich, ob etwas schon optimiert ist? Wenn man mit den Sachen aus dem Skript nichts mehr anfangen kann?

Übung 9
1) Wo ist I(S( C)) ? Sollte es nicht für jedes Schlüsselattribut einen Index geben?
2) Woher weiß ich wann ich für was einen Index benutze? Könnte ich hier auch nen Index bei Wettkampf setzen?

Quoted

Original von NullAhnung
Übung3 Ist das beides auch richtig?
2b) Pie (Eqipment) (G (to<>Paris)(Schedule) Join (Usable)

Gefragt war nach den Flugzeugtypen, die nie in Paris landen. Deine Anfrage liefert alle Flugzeugtypen, für die es einen Flug gibt, der nicht in Paris endet.

Werte die Anfrage doch einfach mal anhand der Beispielinstanz aus. Du wirst festellen, daß Du als Ergebnis u. a. "320" erhälst, obwohl dieser Typ in Paris landet.

Quoted

2c) Pie (Pilot,Flight) G(From = Base) (Schedule join Based)

Wie willst Du denn SCHEDULE und BASED joinen? Die haben keine gemeinsamen Attribute.

Quoted

Übung 5
1b) Warum muss vor das Gamma noch was vor?

Keine Ahnung, was Du meinst.

Quoted

Übung 6
1) Geht das auch?
(Pie (Pres_name) (G (P.party = Republican) (President p) join G(m.Nr_children>1) (Pres_Marriage m) join G (h.hobby=Riding) (Pres_hobby h))) – pie (e.candidate) G(WinnerLoserIndic = L) (Election e)

Fast. Die Differenz darf man nur auf Tupelmengen mit den selben Attributnamen anwenden. Daher mußt Du candidate noch in pres_name umbenennen.

Quoted

Übung 7
1d) Was bedeutet das genau? < = >

Was meinst Du? Ich kann dieses Zeichen auf dem Übungszettel nicht entdecken. Meinst Du das Symbol für Äquivalenz?

Quoted

Übung 8
Woran erkenn ich, ob etwas schon optimiert ist? Wenn man mit den Sachen aus dem Skript nichts mehr anfangen kann?

So ungefähr. Muß man auch ein wenig nach Gefühl machen.

Quoted

Übung 9
1) Wo ist I(S( C)) ? Sollte es nicht für jedes Schlüsselattribut einen Index geben?

Für welche Attribute es einen Index gibt, bestimmt das Datenbanksystem bzw. der Administrator. Für Schlüsselattribute muß nicht zwingend ein Index vorhanden sein.

Quoted

2) Woher weiß ich wann ich für was einen Index benutze? Könnte ich hier auch nen Index bei Wettkampf setzen?

Kommt immer drauf an, was Du in dem Fall für günstiger hälst. Ich habe bei dieser Aufgabe ganz auf die Verwendung der Indexe verzichtet und die Selektionen ganz nach innen gezogen, da ich vermute, daß die Filterungswirkung derselben sehr groß ist. Wenn man sowas macht, muß man das allerdings auch gut begründen.

Hier ist dieses Vorgehen erlaubt, da man aus der Aufgabenstellung keine Informationen zum Datenbestand hat.

Quoted

Original von NullAhnung
Übung3 Ist das beides auch richtig?
2b) Pie (Eqipment) (G (to<>Paris)(Schedule) Join (Usable)

Da habe ich:
pi_Equipment(USABLE) -
pi_Equipment(sigma_To='Paris'(SCHEDULE join USABLE))

(laut Korrektor richtig)

Quoted

Original von NullAhnung
2c) Pie (Pilot,Flight) G(From = Base) (Schedule join Based)

Einfacher:
pi_Pilot,Base,Flight(SCHEDULE join BASED)

Quoted

Original von NullAhnung
Übung 6
1) Geht das auch?
(Pie (Pres_name) (G (P.party = Republican) (President p) join G(m.Nr_children>1) (Pres_Marriage m) join G (h.hobby=Riding) (Pres_hobby h))) – pie (e.candidate) G(WinnerLoserIndic = L) (Election e)

Ja, das ist korrekt. Die Selektionen in den Join zu ziehen, ist sogar sehr geschickt.

Quoted

Original von NullAhnung
Übung 7
1d) Was bedeutet das genau? < = >

So wie ich es verstanden habe, bedeutet es, dass der andere Präsident genau die gleichen Hobbies hat wie 'Washington G'. Deshalb die Äquivalenz. Ein einfaches logisches Und würde wohl nur für je ein Hobby gelten.
Darauf war ich aber auch nicht gekommen.

Quoted

Original von NullAhnung
Übung 8
Woran erkenn ich, ob etwas schon optimiert ist? Wenn man mit den Sachen aus dem Skript nichts mehr anfangen kann?

Gute Frage!

Quoted

Original von NullAhnung
Übung 9
1) Wo ist I(S( C)) ? Sollte es nicht für jedes Schlüsselattribut einen Index geben?

Gibt es ja auch. Doch I(S(C)) brauchen wir gar nicht, da ein natürlicher Verbund über das gemeinsame Attribut D durchgeführt wird.

Quoted

Original von NullAhnung
2) Woher weiß ich wann ich für was einen Index benutze? Könnte ich hier auch nen Index bei Wettkampf setzen?

Darüber habe ich auch schon nachgegrübelt. Ich habe kein Gegenargument gefunden. Meiner Einschätzung nach kann man es auch umgekehrt machen, also erst WName='Weitsprung Herren' selektieren und dann nach dem Verbund erst Weite>8,5.
Was nun effizienter ist, weiß ich nicht. Vielleicht könnte man argumentieren, dass auch bei anderen Disziplinen Weite>8,5 gelten kann und somit mehr Tupel geliefert werden, wenn man vor dem Verbund nach Weite selektiert.

Quoted

Original von Joachim

Quoted

Original von NullAhnung
Übung 6
1) Geht das auch?
(Pie (Pres_name) (G (P.party = Republican) (President p) join G(m.Nr_children>1) (Pres_Marriage m) join G (h.hobby=Riding) (Pres_hobby h))) – pie (e.candidate) G(WinnerLoserIndic = L) (Election e)

Fast. Die Differenz darf man nur auf Tupelmengen mit den selben Attributnamen anwenden. Daher mußt Du candidate noch in pres_name umbenennen.

Au, das habe ich übersehen!
In diesem Punkt war ich mir auch nicht ganz sicher, ob die Differenz in der RA identische (also namensgleiche) Schemata voraussetzt. Ist wohl so. (Da hat die Stundenübung mehr verwirrt als geholfen.)
In SQL hingegen spielen die Namen keine Rolle - da muss nur der Datentyp passen.

Quoted

Original von migu

Quoted

Original von Joachim

Quoted

Original von NullAhnung
Übung 6
1) Geht das auch?
(Pie (Pres_name) (G (P.party = Republican) (President p) join G(m.Nr_children>1) (Pres_Marriage m) join G (h.hobby=Riding) (Pres_hobby h))) – pie (e.candidate) G(WinnerLoserIndic = L) (Election e)

Fast. Die Differenz darf man nur auf Tupelmengen mit den selben Attributnamen anwenden. Daher mußt Du candidate noch in pres_name umbenennen.

Au, das habe ich übersehen!
In diesem Punkt war ich mir auch nicht ganz sicher, ob die Differenz in der RA identische (alsonamensgleiche) Schemata voraussetzt. Ist wohl so.

Da war ich mir eben zuerst auch unsicher. Gemäß Definition auf Folie 3.3 gilt:


Gegeben seien endliche Relationen R und S mit zugehörigen Schemata (A_1: D_1, ..., A_n: D_n) bzw. (B_1: D'_1, ..., B_n: D'_n).

Die Differenz R – S ist dann:

{t: (A_1, ..., A_n) | t aus R UND t nicht aus S}

Jedes Tupel t der Differenz besitzt also die Attribute (A_1, ..., A_n). Sind nun die Attribute von R und S verschieden, so gilt zwangsläufig "t nicht aus S" und das Ergebnis der Differenz ist R.


Fazit: Die Differenz ist zwar für beliebige Relationen R und S definiert, wenn man jedoch ein Ergebnis haben möchte, das von R verschieden ist, müssen die Attribute von R und S identisch sein.

Von daher war meine Aussage von oben in der dortigen Form nicht korrekt. Bezogen auf die Aufgabe aber schon.

Quoted

Original von Diktator
ist
{(pres_name) | esGibt year ( STATE(state_name, admin, year) UND year > 1900 )}
äquivalent zu
{(pres_name) | esGibt state_name, admin, year ( STATE(state_name, admin, year) UND year > 1900) )} ?

Also so wie ich es verstanden habe müsste nur die untere Version richtig sein.

Ich verstehe am deinem Beispiel nicht genau, warum "year" entscheidender sein soll, als z.B. admin, da es zunächst ja einfach nur so ein year geben muss. Die Bedingung kommt ja erst danach.

Ausserdem: Müsste pres_name nicht in den Klammer hinter STATE(...) aufgeführt werden, damit die Anfrage auch etwas ausgibt?

Quoted

Original von Diktator
habe eine allgemeine frage zum bereichskalkül.
welche attribute einer relation kommen hinter den esGibt-quantor?
falls ich nämlich richtig sehe, werden im skript immer alle attribute ausgewählt. ich habe aber in den übungen nur die "entscheidenden" hinter den quantor geschrieben und es war auch richtig.

vielleicht am beispiel:

ist
{(state_name) | esGibt year ( STATE(state_name, admin, year) UND year > 1900 )}
äquivalent zu
{(state_name) | esGibt state_name, admin, year ( STATE(state_name, admin, year) UND year > 1900) )} ?

Keines von beiden ist richtig. Gemäß der Defintion auf Folie 3.50 dürfen nur die Ergebnisvariablen als freie Variablen in der Qualifikationsformel vorkommen.

Korrekt müßte dieses Beispiel also lauten:

{(state_name: string) | ES EXISTIEREN admin, year (STATE(state_name, admin, year) UND year > 1900)}