Klausur DES §

• Alexander Weichart
• 2170749
• B.A. Medieninformatik, Informationswissenschaft, Philosophie
• 3. Fachsemester

Aufgabe 1 §

Schema on read wird für das Speichern strukturierter Daten verwendet, da die Daten z.B. in Releationen passen müssen. Das Auslesen ist dort auch wichtiger als das Schreiben. Schema on write wird eher für unstrukturierte Daten, die ggf. auch auf mehreren Systemen gespeichert werden verwendet. Das Speichern ist dort wichtiger als das Auslesen.

Aufgabe 2 §

1. §

2. §

Die Impfung wurde als assoziative Entität modeliert, da sie beschreibt, wie der Impfstoff zum Bürger gelangt. Deshalb würde es keinen Sinn machen sie als einzelne starke Entität zu beschreiben. Impfgruppe und Bürger sind beides starke Entitäten, da sie beide einzeln existieren müssen. Der Impfstoff an sich ist eine starke Entität aber kann verschieden beschaffen sein, deshalb die verschiedenen Subtypes, von denen aber immer nur ein einziger möglich ist, und für jeden Impfstoff einer nötig ist. Außerdem wurden noch extra Attribute hinzugefügt, wie z.B. bei Impfung die Nummer der Impfung (also die wievielte es war) und ob die Impfung erfolgreich war.

3. §

• Bürger(BürgerID(PK), ImpfstoffgruppeID(FK), Name, Adresse, Telefon, Email, Versicherungsnummer, Alter, Vorerkrankungen, isRelevant)
• Impfgruppe(ImpfstoffgruppeID(PK), Prioritätslevel, Beschreibung, averageAge, anzahlGeimpfter)
• Impfung(BürgerID(FK) ImpfstoffID(FK), wievielteImpfung, wasSucessful, Datum, Arzt)
• Impfstoff(ImpfstoffID(PK), Name, requiredDoses, empfohlenesAlter, bekannteNebenwirkungen, Type)
• mRNA-Impfstoff(ImpfstoffID(FK), Spezialkühlschrank)
• Vektorimpfstoff(ImpfstoffID(FK), Virusart)
• Totimpfstoff(ImpfstoffID(FK), Aufreinigungsgrad)

Aufgabe 3 §

1. SELECT FirstName, LastName FROM Person;
2. SELECT p.FirstName, p.LastName FROM Person AS p RIGHT OUTER JOIN Customer AS c ON c.PersonID = p.PersonID
3. SELECT s.StartTime, s.EndTime FROM Shift AS s JOIN Employee as e ON s.ShiftID = e.ShiftID
4. SELECT p.FirstName, p.LastName, s.OrderDate FROM Person AS p RIGHT OUTER JOIN Customer AS c ON p.PersonID = c.PersonID JOIN SalesOrderHeader AS s ON c.CustomerID = s.BusinessEntityID JOIN SelesOrderDetail AS sd ON s.BusinessEntityID sd.BusinessEntityID WHERE sd.ProductID = (SELECT ProductID FROM Product WHERE name = “Chair”)
5. SELECT p.Name, max(Price) FROM Product AS p GROUP BY p.Name
6. SELECT BirthDate, count(*) FROM Employee GROUP BY BirthDate HAVING BirthDate > “01.01.1960” AND BirthDate < “30.03.1960”
7. SELECT ProductID, avg(ListPrice) FROM Product GROUP BY ProductID ORDER BY ProductID ASC

Aufgabe 4.1 §

Atomic ist beim committen der Änderungen relevant, da es bedeutet, dass jeder Commit komplett durchgeführt wird. Dadurch werden keine Änderungen halb durchgeführt bzw. Unterbrochen und später durchgeführt, das kann nämlich zu Problemen führen, wenn z.B. die Zieldaten geändert wurden. Consistent bedeutet, dass alle Commits valide sind und die Datenbank somit auch valide bleibt. Dadurch können durch Transactions keine Schäden an der Datenbank enstehen, die sie unbrauchbar machen würden. Isolated bedeutet, dass Transactions unabhängig voneinander laufen, sich also nicht gegenseitig beeinflussen können. Dadurch wird das Problem, dass z.B. durch Queries sich gegenseitig manipulieren behoben. Durability bedeutet, dass Commits bestehen bleiben und nicht aus versehen rückgängig gemacht werden. Dadurch wird die Integrität einer Änderung garantiert, denn man muss davon ausgehen können, dass Änderungen nicht einfach revertiert werden. Diese ACID Eigenschaften werden durch Serialisierung (eine Transaction nach der anderen), Locking (Locken von gerade zu bearbeitenden Daten) bzw. MultiVersioning (Logging von transactions, merging, conflicts) umgesetzt.

Aufgabe 4.2 §

a. Locks: Zieldaten werden für andere gesperrt, entweder durch shared lock (read only für andere) oder exclusive lock (no access at all für andere). Dadurch kann garantiert werden, dass bei Transactions nicht die gleichen Zieldaten von unterschiedlichen Transactions bearbeitet werden. Multiversioning Funktioniert wie Git, nur mit Transactions statt Code Änderungen. Alle Transactions werden geloggt (read, manippulate, commit). Unter der Vorraussetzung, dass die base version mit der commited version übereinstimmt können Transactions commited werden, sonst müssen changes manuell resolved werden. Man kann dann auch mit Sequential consistency die in wirklichkeit parallelen transactionen als sequenziell interpretieren. Rollbacks werden verwendet, um Fehler Rückgängig zu machen.

b.

• Grob: Zu viele Daten werden gelockt, andere Transactions werden aufgehalten, Deadlock unwahrscheinlicher
• Fein: Weniger Daten werden gelockt, mehr Transactions können durchgeführt werden, Deadlock wahrscheinlicher

c. Man kann dann auch mit Sequential consistency die in wirklichkeit parallelen transactionen als sequenziell interpretieren, dadurch ist es einfacher die Änderungen zu überprüfen

Aufgabe 5 §

<botanical_names> {for $x in CATALOG/PLANT return <botanical>{$x/COMMON}</botanical>} </botanical_names> 2. <cheap_plants> { for $x in CATALOG/PLANT where ($x/PRICE < "$5") return <common>{$x/COMMON}</common>} ) </cheap_plants> 3. <light_type> { for $x in CATALOG/PLANT let $lightElement := replace($x/LIGHT, '\s+', '_') let $commonElement := replace($x/COMMON, ',', '_') let $z := element {$lightElement}{} return element {$lightElement} {$z} } </light_type>

Aufgabe 7.1 §

a. Man kann den Aufbau von XML-Dokukmenten mit einem Schema beschreiben und überprüfen, bei JSON könnte man ihn nur mit einer Beispieldatei beschreiben aber nicht überprüfen. Mit XML Schemata kann man außedem die Datentypen, Attribute, Elemente, Reihenfolgen, Gruppen, Einschränkungen definieren, das alles geht nicht ohne ein Schema. Eigene Datentypen können nur per XML-Schema definiert werden, nicht mit JSON alleine. b. JSON:

• Pro: Simpel, wenig falsch zu machen
• Con: Viele Limitationen, da nicht sehr flexibel XML(Schema):
• Pro: erweiterbar, typrüfung, validitätsprüfung, flexibel
• Con: Komplizierter, für simple Daten etwas umständlich

Aufgabe 7.2 §

a. Data Binding:

• Mit Hilfe von Annotationen werden Elemente im Code markiert, mit einem Persistierer werden dann die Objekte automatisch serialisiert bzw. mit einem Mapper deserialisiert Streaming:
• Event Basierend, der Parser Parst das Dokument und ruft Callback Methoden auf, wenn ein Match vorliegt Manuelles Bearbeiten:
• Der parser parst das Dokument und gibt das Ergebnis als Baum aus, dann kann man manuell (z.B. mit Methoden) die Struktur durchgehen und bearbeiten etc.

b. Data Binding:

• Wenn man schnell und automatisch aus einer Datein Objekte erstellen will (z.B. Java Objekte) Streaming:
• Beim durchsuchen von großen Dokumenten, die z.B. den Arbeitsspeicher überlasten würden, wenn man auch nicht das komplette Dokument benötigt Manuelles Bearbeiten:
• Wenn einem Automatisierung nicht so wichtig ist und man das komplette Dokument haben will, voralllem bei komplexen Dokumenten der Fall

Erklärung §

Eidesstattliche Erklärung zur Prüfungsleistung

Hiermit versichere ich, Alexander Weichart, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen Hilfsmittel als die angegebenen verwendet habe. Die Stellen, die anderen Werken (gilt ebenso für Werke aus elektronischen Datenbanken oder aus dem Internet) wörtlich oder sinngemäß entnommen sind, habe ich unter Angabe der Quelle und Einhaltung der Regeln wissenschaftlichen Zitierens kenntlich gemacht. Diese Versicherung umfasst auch in der Arbeit verwendete bildliche Darstellungen, Tabellen, Kartenskizzen und gelieferte Zeichnungen. Mir ist bewusst, dass Täuschungen nach der für mich gültigen Studien- und Prüfungsordnung geahndet werden.