Title: Standard für DBS2

Standardkategorie für Fragen, die im Kontext 'DBS2' freigegeben sind.

Feedback shared by this category's questions, if right: Die Antwort ist richtig.
Feedback shared by this category's questions, if partly right: Die Antwort ist teilweise richtig.
Feedback shared by this category's questions, if wrong: Die Antwort ist falsch.

Q: Die Bestandteile einer Aggregation in UML  ...
- können zu mehreren Aggregaten gehören.
- gehören sich selber.
- gehören zu genau einem Aggregat.
- stehen in Ist-ein-Beziehung zum Aggregat.
A: können zu mehreren Aggregaten gehören.

Q: In dem folgenden UML-Klassendiagramm wird dargestellt, dass zwischen einem Objekt der Klasse [...] eine Beziehung zu einem Objekt der Klasse [...] vorhanden sein Antwort [...] .

[Image]
A: B; A; muss
Gap 1 offers: A; B
Gap 2 offers: A; B
Gap 3 offers: kann; muss
Feedback: In UML geben die Werte einer Multiplizität die minimale und die maximale Anzahl von Objekten an, die an einer Beziehung teilnehmen. Dabei stehen die Werte an der Seite der Klasse, die in Beziehung gesetzt wird, hier wird also B in Beziehung zu A gesetzt. Mit den Werten 1..* steht also jedes Objekt von B mit mindestens einem Objekt von A in Beziehung. Über die Multiplizität der Beziehung zwischen A und B wird keine Aussage getroffen. a) A ... B ... kann. b) A ... B ... muss. c) B ... A ... kann. d) B ... A ... muss.

Q: Ein Objekt der Klasse A kann nur existieren, wenn es einem Objekt der Klasse B zugeordnet ist. Welche Assoziation verwenden Sie am besten?
- Eine Komposition mit Raute bei Klasse B (Die Komposition bei B fasst Objekte der Klasse A zusammen und modelliert die Existenzabhängigkeit der A-Objekte von einem B-Objekt.)
- Eine Aggregation mit Raute bei Klasse B
- Eine Komposition mit Raute bei Klasse A
- Eine Aggregation mit Raute bei Klasse A
A: Eine Komposition mit Raute bei Klasse B

Q: test
- Kandidatschlüssel | DataId
- Zone 2 | SensorId

Einführung

Die Normalisierung dient der Vermeidung von Redundanzen der Daten in relationalen Datenbanken und damit dem Auftreten von Anomalien bei Änderungen der Daten. Eigentlich ist ein solcher Prozess bei einem sauberen Entwurf einer Datenbank überflüssig. In der Praxis hat sich die Normalisierung aber neben dem Entwurf einer Datenbank nach dem EER-Modell als zusätzliche Möglichkeit zur Beseitigung oder Minimierung von Redundanzen etabliert.

Wir wollen die Normalisierung anhand einer beispielhaften Tabelle "personen" eines Betriebes mit verschiedenen Abteilungen und Projekten nachvollziehen.

Q: 1. Normalform (1NF)

Eine Tabelle befindet sich in der 1. Normalform (1NF), wenn ihre Attribute nur einfache (atomare) Attributwerte aufweisen bzw. keine Wiederholfelder vorkommen.

Rezept: Auslagern der nicht-atomaren Attribute in verschiedene Zeilen oder Einfügen von zusätzlichen Spalten oder Erstellen einer Tabelle mit Schlüssel und dem nicht-atomaren Attribut.

Tabelle "personen"

PNr | PName | AbtNr | AbtName | ProjektNr | ProjektName | ProjektZeit
101 | Hans | 1 | Physik | 11, 12 | A, B | 60, 40
102 | Rolf | 2 | Chemie | 13 | C | 100
103 | Urs | 2 | Chemie | 11, 12, 13 | A, B, C | 20, 50, 30
104 | Paul | 1 | Physik | 11, 13 | A, C | 80, 20

Befindet sich die Relation bereits in der 1. Normalform?
- Ja (Leider falsch! Die Relation befindet sich noch nicht in der 1. Normalform.)
- Nein (Richtig! Die Relation befindet sich noch nicht in der 1. Normalform.)
A: Nein
If right: Die Attribute "ProjektNr", "ProjektName" und "ProjektZeit" enthalten noch nicht-atomare Attibute!
If partly right: Die Attribute "ProjektNr", "ProjektName" und "ProjektZeit" enthalten noch nicht-atomare Attibute!
If wrong: Die Attribute "ProjektNr", "ProjektName" und "ProjektZeit" enthalten noch nicht-atomare Attibute!

Q: 3. Zweite Normalform (2NF) 1/2

Wenn Sie ein wenig nach unten scrollen, sehen Sie die neue Tabelle "personen_und_projekte", die sich durch Aufteilung der Mehrfacheinträge auf mehrere Tupel nun in der ersten Normalform befindet.

Wir sehen nun auf den ersten Blick, dass die Tabelle Redundanzen enthält. Der Personenname ist mit der Personennummer gekoppelt und wird für jedes Projekt wiederholt. Wenn der Name geändert werden soll, dann muss die Änderung bei mehreren Tupeln geschehen, um das Auftreten einer Änderungsanomalie zu verhindern. In der Tabelle sind offensichtlich verschiedene Sachverhalte - Personalien, Abteilungszugehörigkeit und Projektaspekte - enthalten, die aber voneinander unabhängig sind. Jeder Sachverhalt soll  mit einer eigenen Tabelle dargestellt werden.

Eine Tabelle befindet sich in der 2. Normalform (2NF), wenn sie in der 1. Normalform ist und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist.

Alternativformulierung: Eine Tabelle in der 1NF ist nicht in der 2NF, wenn Attribute von einem Teil des Schlüssels eindeutig identifiziert werden.

Hinweis: Wenn der Primärschlüssel nicht zusammengesetzt ist, sondern nur aus einem Attribut besteht, dann ist die Tabelle automatisch in 2NF.

Rezept: Auslagern von Teilschlüsseln und zugehörigen Informationen in eigene Tabellen bzw. separate Entitätstypen mit eigenem Schlüssel finden.

PNr | PName | AbtNr | AbtName | ProjektNr | ProjektName | ProjektZeit
101 | Hans | 1 | Physik | 11 | A | 60
101 | Hans | 1 | Physik | 12 | B | 40
102 | Rolf | 2 | Chemie | 13 | C | 100
103 | Urs | 2 | Chemie | 11 | A | 20
103 | Urs | 2 | Chemie | 12 | B | 50
103 | Urs | 2 | Chemie | 13 | C | 30
104 | Paul | 1 | Physik | 11 | A | 80
104 | Paul | 1 | Physik | 13 | C | 20

Identifizieren Sie alle Primär- bzw. Kandidatschlüssel, indem sie diese dem entsprechenden Feld zuordnen.
- Zone 1 | PNr
- Zone 2 | ProjektNr
Also offered: PName; AbtNr; AbtName; ProjektName; ProjektZeit

Q: 3. Zweite Normalform (2NF) 1/2

Wenn Sie ein wenig nach unten scrollen, sehen Sie die neue Tabelle "personen_und_projekte", die sich durch Aufteilung der Mehrfacheinträge auf mehrere Tupel nun in der ersten Normalform befindet.

Wir sehen nun auf den ersten Blick, dass die Tabelle Redundanzen enthält. Der Personenname ist mit der Personennummer gekoppelt und wird für jedes Projekt wiederholt. Wenn der Name geändert werden soll, dann muss die Änderung bei mehreren Tupeln geschehen, um das Auftreten einer Änderungsanomalie zu verhindern. In der Tabelle sind offensichtlich verschiedene Sachverhalte - Personalien, Abteilungszugehörigkeit und Projektaspekte - enthalten, die aber voneinander unabhängig sind. Jeder Sachverhalt soll  mit einer eigenen Tabelle dargestellt werden.

Eine Tabelle befindet sich in der 2. Normalform (2NF), wenn sie in der 1. Normalform ist und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist.

Alternativformulierung: Eine Tabelle in der 1NF ist nicht in der 2NF, wenn Attribute von einem Teil des Schlüssels eindeutig identifiziert werden.

Hinweis: Wenn der Primärschlüssel nicht zusammengesetzt ist, sondern nur aus einem Attribut besteht, dann ist die Tabelle automatisch in 2NF.

Rezept: Auslagern von Teilschlüsseln und zugehörigen Informationen in eigene Tabellen bzw. separate Entitätstypen mit eigenem Schlüssel finden.

PNr | PName | AbtNr | AbtName | ProjektNr | ProjektName | ProjektZeit
101 | Hans | 1 | Physik | 11 | A | 60
101 | Hans | 1 | Physik | 12 | B | 40
102 | Rolf | 2 | Chemie | 13 | C | 100
103 | Urs | 2 | Chemie | 11 | A | 20
103 | Urs | 2 | Chemie | 12 | B | 50
103 | Urs | 2 | Chemie | 13 | C | 30
104 | Paul | 1 | Physik | 11 | A | 80
104 | Paul | 1 | Physik | 13 | C | 20

Identifizieren Sie alle Primär- bzw. Kandidatschlüssel, indem sie diese dem entsprechenden Feld zuordnen.
- Zone 1 | PNr
- Zone 2 | ProjektNr
Also offered: PName; AbtNr; AbtName; ProjektName; ProjektZeit
If right: Richtig! PNr und ProjektNr sind die gesuchten Primärschlüssel. In diesem Beispiel, gibt es keinen weiteren Kandidatschlüssel, der als Primärschlüssel gewählt werden könnte.
If partly right: Noch nicht ganz richtig. Tipp: Es sind genau zwei Primär-, bzw. Kandidatschlüssel gesucht.
If wrong: Leider falsch, versuchen Sie es noch einmal!

Q: 2. Normalform (2NF) 1/2

Wenn Sie ein wenig nach unten scrollen, sehen Sie die neue Tabelle "personen_und_projekte", die sich durch Aufteilung der Mehrfacheinträge auf mehrere Tupel nun in der 1. Normalform befindet.

Wir sehen nun auf den ersten Blick, dass die Tabelle Redundanzen enthält. Der Personenname ("PName") ist mit der Personennummer ("PNr") gekoppelt und wird für jedes Projekt wiederholt. Wenn der Name geändert werden soll, dann muss die Änderung bei mehreren Tupeln geschehen, um das Auftreten einer Änderungsanomalie zu verhindern. In der Tabelle sind offensichtlich verschiedene Sachverhalte - Personalien, Abteilungszugehörigkeit und Projektaspekte - enthalten, die aber voneinander unabhängig sind. Jeder Sachverhalt soll mit einer eigenen Tabelle dargestellt werden.

Eine Tabelle befindet sich in der 2. Normalform (2NF), wenn sie in der 1. Normalform ist und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist.

Alternativformulierung: Eine Tabelle in der 1NF ist nicht in der 2NF, wenn Attribute von einem Teil des Schlüssels eindeutig identifiziert werden.

Hinweis: Wenn der Primärschlüssel nicht zusammengesetzt ist, sondern nur aus einem Attribut besteht, dann ist die Tabelle automatisch in 2NF.

Rezept: Auslagern von Teilschlüsseln und zugehörigen Informationen in eigene Tabellen bzw. separate Entitätstypen mit eigenem Schlüssel finden.

Tabelle "personen_und_projekte"

PNr | PName | AbtNr | AbtName | ProjektNr | ProjektName | ProjektZeit
101 | Hans | 1 | Physik | 11 | A | 60
101 | Hans | 1 | Physik | 12 | B | 40
102 | Rolf | 2 | Chemie | 13 | C | 100
103 | Urs | 2 | Chemie | 11 | A | 20
103 | Urs | 2 | Chemie | 12 | B | 50
103 | Urs | 2 | Chemie | 13 | C | 30
104 | Paul | 1 | Physik | 11 | A | 80
104 | Paul | 1 | Physik | 13 | C | 20

Identifizieren Sie alle Primär- bzw. Kandidatschlüssel, indem sie diese im folgendem Tabellenkopf unterstreichen. Ziehen Sie dazu den schwarzen Strich auf die Attribute. (Das Fadenkreuz muss auf das ausgewählte Attribut zielen.)
- Zone 1 | _______
- Zone 2 | _______
If right: Richtig! "PNr" und "ProjektNr" sind die gesuchten Primärschlüssel. In diesem Beispiel, gibt es keinen weiteren Kandidatschlüssel, der als Primärschlüssel gewählt werden könnte. PNr | PName | AbtNr | AbtName | ProjektNr | ProjektName | ProjektZeit
If partly right: Noch nicht ganz richtig. Tipp: Es sind genau zwei Primär-, bzw. Kandidatschlüssel gesucht.
If wrong: Leider falsch, versuchen Sie es noch einmal! Tipp: Es sind genau zwei Primär-, bzw. Kandidatschlüssel gesucht.

Q: 2. Normalform (2NF) 2/2

Nachdem Sie die Primärschlüssel identifiziert haben, bestimmen Sie nun die vollen funktionalen Abhängigkeiten, damit die Tabelle "personen_und_projekte" in kleinere Tabellen zerlegt werden kann.

Tabelle "personen_und_projekte"

PNr | PName | AbtNr | AbtName | ProjektNr | ProjektName | ProjektZeit
101 | Hans | 1 | Physik | 11 | A | 60
101 | Hans | 1 | Physik | 12 | B | 40
102 | Rolf | 2 | Chemie | 13 | C | 100
103 | Urs | 2 | Chemie | 11 | A | 20
103 | Urs | 2 | Chemie | 12 | B | 50
103 | Urs | 2 | Chemie | 13 | C | 30
104 | Paul | 1 | Physik | 11 | A | 80
104 | Paul | 1 | Physik | 13 | C | 20

Funktionale Abhängigkeiten (FA'en) existieren für die beiden Teilschlüsselattribute "PNr", "ProjektNr" sowie für den zusammengesetzten Schlüssel ["PNr"+"ProjektNr"].

Ziehen Sie zur Bestimmung der FA'en die funktional abhängigen Attribute in die Ablagebereiche neben dem entsprechenden Schlüsselattribut. (Das Fadenkreuz muss auf den ausgewählten Ablagebereich zielen.)
- Zone 1 | PName
- Zone 2 | AbtNr
- Zone 3 | AbtName
- Zone 4 | ProjektName
- Zone 5 | ProjektZeit
If right: Sehr gut! Sie haben alle funktionalen Abhängigkeiten korrekt bestimmt.
If partly right: Leider nur teilweise richtig! Tipp: Alle Nichtschlüsselattribute müssen von einem Schlüssel funktional abhängig sein.
If wrong: Leider falsch. Versuchen Sie es noch einmal...

Q: 3. Normalform (3NF)

Unsere Tabelle befindet sich nun in der 2NF, aber sind auch alle Redundanzen eliminiert?

Eine Tabelle befindet sich in der 3. Normalform (3NF), wenn sie in der 2. Normalform ist und jedes Nichtschlüsselattribut nicht transitiv abhängig vom Primärschlüssel ist.

Tabelle "personen"

PNr | PName | AbtNr | AbtName
101 | Hans | 1 | Physik
102 | Rolf | 2 | Chemie
103 | Urs | 2 | Chemie
104 | Paul | 1 | Physik

Tabelle "projekte"

ProjektNr | ProjektName
11 | A
12 | B
12 | C

Tabelle "personen_und_projekte"

PNr | ProjektNr | ProjektZeit
101 | 11 | 60
101 | 12 | 40
102 | 13 | 100
103 | 11 | 20
103 | 12 | 50
103 | 13 | 30
104 | 11 | 80
104 | 13 | 20

In unserem Beispiel findet sich noch genau eine transitive Abhängigkeit. Ziehen sie einfach die beiden jetzt noch auszulagernden Attribute in den Ablagebereich. (Das Fadenkreuz muss auf den ausgewählten Ablagebereich zielen.)
- Zone 1 | AbtNr
- Zone 2 | AbtName
Also offered: PName; ProjektZeit; ProjektName
If right: Richtig! "AbtName" ist transitiv vom Primärschlüssel abhängig. ("PNr" -> "AbtNr" -> "AbtName")
If partly right: Leider nicht ganz richtig! Tipp: Die gesuchte transitive Abhängigkeit befindet sich in der Tabelle "personen"
If wrong: Leider falsch! Versuchen Sie es noch einmal... Tipp: Die gesuchte transitive Abhängigkeit befindet sich in der Tabelle "personen"

Normalisierte Datenbank

Unsere Datenbank sieht in der 3NF nun folgendermaßen aus:

Tabelle "personen"

PNr | PName | AbtNr
101 | Hans | 1
102 | Rolf | 2
103 | Urs | 2
104 | Paul | 1

Tabelle "projekte"

ProjektNr | ProjektName
11 | A
12 | B
12 | C

Tabelle "personen_und_projekte"

PNr | ProjektNr | ProjektZeit
101 | 11 | 60
101 | 12 | 40
102 | 13 | 100
103 | 11 | 20
103 | 12 | 50
103 | 13 | 30
104 | 11 | 80
104 | 13 | 20

Tabelle "abteilungen"

AbtNr | AbtName
1 | Physik
2 | Chemie

Anwendung

Eine Anwendung zur Messung von Feinstaubdaten verwendet die folgende Tabelle. Jeder Datensatz mit dem Primärschlüssel DataId enthält im Attribut Value den gemessenen Wert eines Sensors SensorId zu einem bestimmten Zeitpunkt TimeStamp . Bei der Spalte SensorType handelt es sich um den Sensortyp. Organization beinhaltet den Betreiber des Sensors mit dessen Ortsangabe Place. Der Aufstellort des Sensors wird in Breiten- und Längengrad mit Location vermerkt.

[Image]

Download: Tabelle (XLS)

Q: Identifizieren Sie die Kandidatschlüssel, indem sie diese im folgenden Tabellenkopf unterstreichen.

Ziehen Sie dazu den schwarzen Strich auf die Attribute. Das Fadenkreuz muss im Bereich für das ausgewählte Attribut landen.

Aus technischen Gründen werden einstellige und zusammengesetzte Schlüssel nicht unterschieden. Kennzeichnen Sie alle Attribute, die Schlüssel sind bzw. Teil eines Schlüssels sind. Tipp: Es gibt jeweils einen Vertreter jeder Kategorie.
- Zone 1 | _______
- Zone 2 | _______
- Zone 3 | _______
If right: DataId und (SensorId, TimeStamp) sind die gesuchten Kandidatschlüssel. DataId ist ein Surrogate-Schlüssel und wird idR als Primärschlüssel gewählt - effizienter in der Nutzung als ein zusammengesetztes Attribut.
If partly right: Noch nicht ganz richtig. Tipp: Es werden zwei Kandidatschlüssel gesucht, einer ist zusammengesetzt.
If wrong: Leider falsch, versuchen Sie es noch einmal!

3. 1NF

Bilden Sie die Tabelle auf genau eine äquivalente Relation in 1NF ab.

Q: Bilden Sie die Tabelle auf genau eine äquivalente Relation in 1NF ab.

Welche der folgenden Attribute enthalten nicht-atomare Attribute?

[Image]
- DataId (Leider falsch.)
- SensorId (Leider falsch.)
- Value (Leider falsch.)
- TimeStamp (TimeStamp ist ein zusammengesetztes Attribut und idR als Datentyp verfügbar.)
- SensorType (Leider falsch.)
- Organization (Leider falsch.)
- Place (Leider falsch.)
- Location (Richtig!)
A: Location
If right: Das Attribut Location enthält noch nicht-atomare Attibute und kann durch Latitude und Longitude ersetzt werden. TimeStamp hingegen ist ein zusammengesetztes Attribut und idR als Datentyp verfügbar.
If partly right: Das Attribut Location enthält noch nicht-atomare Attibute und kann durch Latitude und Longitude ersetzt werden. TimeStamp hingegen ist ein zusammengesetztes Attribut und idR als Datentyp verfügbar.
If wrong: Das Attribut Location enthält noch nicht-atomare Attibute und kann durch Latitude und Longitude ersetzt werden. TimeStamp hingegen ist ein zusammengesetztes Attribut und idR als Datentyp verfügbar.

Q: Ziehen Sie zur Bestimmung der vollen FA'en die funktional abhängigen Attribute in die Ablagebereiche neben dem entsprechenden Schlüsselattribut. Das Fadenkreuz muss vollständig im ausgewählten Ablagebereich enthalten sein. Aus technischen Gründen müssen sich hierbei die Attributnamen teilweise überlagern.

Download: Relation in 1NF (XLS)
- Zone 1 | DataId
- Zone 2 | SensorId
- Zone 3 | Value
- Zone 4 | Value
- Zone 5 | TimeStamp
- Zone 6 | SensorType
- Zone 7 | SensorType
- Zone 8 | Organization
- Zone 9 | Organization
- Zone 10 | Organization
- Zone 11 | Place
- Zone 12 | Place
- Zone 13 | Place
- Zone 14 | Place
- Zone 15 | Latitude
- Zone 16 | Latitude
- Zone 17 | Longitude
- Zone 18 | Longitude
If right: Die Antwort ist richtig. Lösung: DataId -> SensorId, Value, TimeStamp, SensorType, Organization, Place, Latitude, Longitude SensorId -> SensorType, Organisation, Place, Latitude, Longitude SensorId, TimeStamp -> Value, DataId Organization -> Place Location -> Place, Organization
If partly right: Die Antwort ist teilweise richtig. Lösung: DataId -> SensorId, Value, TimeStamp, SensorType, Organization, Place, Latitude, Longitude SensorId -> SensorType, Organisation, Place, Latitude, Longitude SensorId, TimeStamp -> Value, DataId Organization -> Place Location -> Place, Organization
If wrong: Die Antwort ist falsch. Lösung: DataId -> SensorId, Value, TimeStamp, SensorType, Organization, Place, Latitude, Longitude SensorId -> SensorType, Organisation, Place, Latitude, Longitude SensorId, TimeStamp -> Value, DataId Organization -> Place Location -> Place, Organization

Anwendung

Eine Anwendung zur Messung von Feinstaubdaten verwendet die folgende Tabelle.* Jeder Datensatz mit dem Primärschlüssel DataId enthält im Attribut Value den gemessenen Wert eines Sensors SensorId zu einem bestimmten Zeitpunkt TimeStamp . Bei der Spalte SensorType handelt es sich um den Sensortyp. Organization beinhaltet den Betreiber des Sensors mit dessen Ortsangabe Place. Der Aufstellort des Sensors wird in Breiten- und Längengrad mit Location vermerkt.
* Die Daten sind fiktiv.

[Image]

Download: Tabelle (XLS)

Anwendung

Eine Anwendung zur Messung von Feinstaubdaten verwendet die folgende Tabelle.* Jeder Datensatz mit dem Primärschlüssel DataId enthält im Attribut Value den gemessenen Wert eines Sensors SensorId zu einem bestimmten Zeitpunkt TimeStamp . Bei der Spalte SensorType handelt es sich um den Sensortyp. Organization beinhaltet den Betreiber des Sensors mit dessen Ortsangabe Place. Der Aufstellort des Sensors wird in Breiten- und Längengrad mit Location vermerkt.
* Schema und Daten sind fiktiv. Vergleichbare Daten werden beispielsweise im Netzwerk luftdaten.info aus den Daten der einzelnen Feinstaubsensoren zusammengestellt.

[Image]

Download: Tabelle (XLS)

Q: Der Impedance Mismatch tritt auf, wenn eine Anwendung auf eine ... Datenbank zugreift.
- objektorientierte
- objektrelationale
- prozedurale
- relationale
A: relationale

Q: Der Abbau einer Datenbankverbindung bei JDBC wird durch Senden einer Methode an ein Objekt der ... -Klasse implementiert.
- Connection
- DriverManager
- Statement
- ResultSet
A: DriverManager

Q: Die JDBC-Schnittstelle erlaubt die Verwendung von .... SQL.
- dynamischem
- keinem
- statischem
- Java-
A: dynamischem

Q: Ein Iterator in SQLJ liefert ....
- ein Attribut
- ein Tupel
- eine Relation
- eine SQL-Anweisung
A: ein Tupel

Q: Ein objekt-relationaler Mapper ermöglicht ...
- die automatische Persistierung von Objekten in einer relationalen Datenbank.
- die integrierte Verwendung von Objekten in einer Relation.
- die Selbst-Generierung von XML-Files zur Abbildung von Objekten auf Relationen.
- den transparenten Zugriff auf eine relationale Datenbank.
A: den transparenten Zugriff auf eine relationale Datenbank.