Lösungsvorschlag Einführung in Datenbanksysteme FS06

Aus VISki
Wechseln zu: Navigation, Suche

Aufgabe 1

a) Die Relation spielen muss eine N:M:1 Relation sein. Wenn nämlich eine Mannschaft und der Schiedsrichter bestimmt ist, können wir daraus nicht auf die andere Mannschaft schliessen, so wie das dieses Modell suggeriert.

b)

Mannschaft: {Land*, Trainer, Kaptain}
Schiedsrichter: {Name*, Land}
spielen { Land_Mannschaft1*, Land_Mannschaft2*, Name, Datum, Ergebnis}

Aufgabe 2

Ein Versuch:

a)

select m.name, sum(tore)
from spieler s, mannschaft m
where s.mannschaft = m.name
group by m.name

Variante:

select mannschaft, sum(tore)
from spieler
group by mannschaft

b)

Neuer Versuch (mit kleiner korrektur):

select s.name
from spieler s
where 2 * s.tore > (select sum(alle.tore)
                    from spieler alle
                    where s.mannschaft = alle.mannschaft);


Unser Vorschlag

select s.name
from spieler s, ( select mannschaft, sum(tore) as toretotal
                  from spieler
                  group by mannschaft) m
where s.mannschaft = m.mannschaft and
      2*s.tore > m.toretotal

Weiterer Vorschlag:

select s1.name 
from spieler s1 
where 2 * tore >= 
  ( select sum(s2.tore) 
    from spieler s2 
    group by s2.mannschaft 
    having s1.mannschaft = s2.mannschaft );

Aufgabe 3

a)

  • enthalten weder Aggregatfunktionen, noch Anweisungen wie distinct, group by und having
  • in der select-Liste sind nur eindeutige Spaltennamen und ein Schlüssel der Basisrelation enthalten
  • verwenden nur genau eine Tabelle (also Basisrelation oder Sicht), die ebenfalls veränderbar sein muss.

b)

create table employee
  ( id integer not null primary key auto_increment,
    name varchar(30) not null,
    street varchar(30) not null,
    place varchar(30) not null,
    zip integer not null,
    phone varchar(30) not null,
    salary integer not null );

create view employee_addr as
  select id, name, street, place, zip
  from employee;

Mit der View employee_addr kann man keine neuen Tupel zur Tabelle employee hinzufügen.

Bei Mysql werden jedoch nur Warnungen ausgegeben:

mysql> insert into employee_addr values (42, "Zaphod", "Ego Rd.", "Betelgeuse", 4242);
Query OK, 1 row affected, 2 warnings (0.00 sec)

Warning (Code 1423): Field of view 'exercise.employee_addr' underlying table doesn't have a 
default value
Warning (Code 1423): Field of view 'exercise.employee_addr' underlying table doesn't have a 
default value

--Duh 14:17:13, 9. Jun 2009 (CEST): War hier nicht ein Beispiel einer Relation gefragt, die theoretisch veränderbar (also imo updatebar) wäre, jedoch SQL verbietet? Also eher sowas wie:

  • Tab1 = {A*, B, C}
  • Tab2 = {A*, D, E}

Sicht: "CREATE VIEW (select A from Tab1) INTERSECT (select A from Tab2)"

Aufgabe 4

a)

FD's:

nur die trivialen

MVD's:

Titel ->-> Nr
Titel ->-> Name
(und hinzugefügt by PeeDee): bin der Meinung dass das nicht stimmt, eine begründung habe ich auf der diskussionsseite hingeschrieben.
Name ->-> Titel
+ die trivialen

Kandidatenschluessel:

{Nr, Titel, Name}

b) Die Relation ist in BCNF

c) In 4NF mit Dekompositionsalgorithmus umwandeln.

U1(Titel,Nr)
U2(Titel,Name)

Für alle Zerlegungsalgorithmen in alle Normalformen ist die Verlustlosigkeit garantiert. Jedoch ist die Dekompostion in 4. NF nicht immer abhängigkeitsbewahrend. Hier jedoch ist es abhängigkeitsbewahrend.

Alternative Zerlegung die nicht abhängigkeitsbewahrend ist:

V1(Name,Titel)
V2(Name,Nr)