Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
[CD] Gemischte Fragen
Hi,
folgende Fragen sind bei mir auch nach ausfuehrlicher Lektuere noch vorhanden. Die Relevanz ist von mir von oben nach unten geordnet - die unteren Sachen sind also eher unwichtig, da geht es mir nur mehr um eure Meinung dazu.
1. Was ist der Unterschied zwischen dem hierarchischen und dem Netzwerk-Datenmodell?
2. Was hat es mit der 4. ORDB-Haupteigenschaft, dem Regelsystem, auf sich? Weiss da irgendjemand *irgendetwas* drueber?
3. Die Terminologie bei den Data Warehouses verwirrt mich etwas: Was genau ist dabei eine Dimension, eine Kategorie und eine Klassifikation?
4. Kann man die totale Teilnahme einer Entitaet in einer Beziehung in eine Relation mappen? Man muesste doch dann die entsprechenden Fremdschluessel auf NOT NULL setzen, oder?
5. Beim Mappen von ganzen Hierarchien: sollte man hier erst eine Ebene nach der anderen betrachten oder muss man den gesamten Zusammenhang sehen, um die Entscheidungen treffen zu koennen?
6. Beim Definieren von mindestens 2 Triggern kann es zu Zyklen kommen. Weiss jemand, ob gaengige Datenbanken das ueberpruefen oder anderweitig damit umgehen?
7. Kann man mit Data Mining Produkten auch bestehende Hypothesen untersuchen, oder koennen diese nur autonom solche generieren?
8. Die 12 Regeln von Codd bzgl. OLAP - sind die wichtig, sollte man die (wenigstens ungefaehr) koennen?Viele Gruesse und vielen Dank,
-Steppenwolf
uii, ist zwar länger her, aber ich gib mal nen Versuch:
Nach meiner Auffasung kannst Du beim Netzwerk-Datenmodell die Satztypen mit beliebigen anderen Satztypen verbinden, also Sets oder sowas etablieren. D.h. jetzt mal die Datenmodelle aus der Ferne betrachtet: Zuordnungen im hierarchischen Modell kannst Du als Baum darstellen (bis auf die Ausnahmen mit den virtuellen Satztypen), während bei Netzwerkmodellen für die Darstellung der Zuordnungen/Zusammenhänge zwischen Satztypen ein (gerichteter, kann auch zyklisch sein) Graph nötig ist. Ich glaub wenn du dieses Bild vor den Augen führst, dann lassen sich die beiden Datenmodelle recht gut voneinander unterscheiden.
Hmm, also aus der Folie könnte ich mir irgendwelche Seiteneffekte vorstellen, die durch diese Regeln beheben werden, allerdings sollten das ja eben Transaktionen bewerkstelligen… Die Folie müsste in der Prüfung langen … ansonsten weglassen, oder schnell das Thema wechseln:)
Dimensionen sind glaub dasselbe wie Kategorien. Diese Dimensionen werden hierarchisch untergliedert/verfeinert, z.B. die Zeitdimension wird auf Jahr, Jahre auf Monate, Monate auf Tage usw. untergliedert. Glaub damit ist hier Klassifikation gemeint.
NOT NULL bewirkt da nichts. Stell dir eine Abbildung von einer n:m Relation vor, wobei eines der Entitity-Typen total Teilnehmen soll. Durch NOT NULL erreichst du nur, dass nie NULL zum Tupel der anderen Entität assoziiert wird, nicht aber, dass alle in der Relation teilnehmen. Dies kannst du evtl. durch Trigger erreichen.
Mappen von Hierarchien auf übliche RDBS? Glaub das Vorgehen nach der Hierarchie müsste ausreichen. Sofern es keine Zyklen gibt… 
Hab’s nie ausprobiert. Gibt’s da etwa eine Endloschleife? Ich meine in den SQL-Übungen mit Oracle mal sowas in der Tafelübung von Maciej gehört zu haben, dass die Trigger in der Reihenfolge aktiviert werden, in welcher sie dem System hinzugefügt wurden. Wenn also ein Trigger abgearbeitet ist, dann kommt der nächste dran, und dessen Veränderungen triggern keinen der vorangegangenen Trigger. Also es kommt nicht zu Zyklen. (Aber einen Versuch wär’s mal Wert! )
Hmm, generieren müsste möglich sein, hängt von der drunterliegenden Wissensbasis bzw. dessen „Intelligenz“ ab. Hab noch leider nie ein Data Mining Tool in der Hand gehabt.
Hmm, ich würde sie mir schon einprägen, da recht vieles von denen auch Data Warehousing beschreibt, was auf jeden Fall drankommen kann.
Dass was ueber ORDB oder Data Warehousing dran kommt, wage ich mal zu bezweifeln.
Jablonski hat zumindest in der letzten Stunde angemerkt, dass man zu diesen Themen nur Eckpunkte zu wissen braucht.
Beim Herrn Meyer-Wegener kann sowohl ORDB als auch Data Warehousing drankommen. Ok, ich hab auch OODB gehabt, deswegen war auch ORDB wohl dran, aber ich kenn auch jemanden, von dem KMW einiges über Data Warehousing wissen wollte.
@Beatbull: Danke fuer deine ausfuehrlichen Antworten!
Und danke an euch beide fuer die Einschaetzungen!
Hast Du am 20. April Prüfung?
Generell hab ich bisher nur von 2 Einstiegsfragen gehört:
- beliebiges ER-Diagramm malen und daran die Bestandteile erklären
- relationale Algebra
Ich weiss zwar nicht, über welche Vorlesungen Du Dich prüfen lässt, aber ArchDB fragt KMW angeblich anders ab, als Jablonski es in seiner Vorlesung bringt.
Ich persönlich hab OODB & MMDB noch gehabt. Bei OODB musste ich u.A. mein Beispiel-ER-Diagramm auf das OO-Schema abbilden. Dann gab’s noch paar Detailfragen bzgl. References (siehe unten). Zu MMDB hatte er nicht mehr viel Zeit, da hat er nur gefragt was ein DBMS mehr können muss um MM zu unterstützen.
KMW meinte zu mir nach der Prüfung, dass für ihn derjenige ein Kandidat für eine 1,x ist, bei dem er durcheinander fragen und an beliebigen stellen für einen Moment tiefer eintauchen kann - natürlich ohne, dass der Prüfling dabei durcheinander kommt oder aus seiner Spur gerät. Auch vorlesungsübergreifende Fragen sind bei ihm nicht unüblich, z.B. fragte er mich, warum die References in OODB besser sind als die Fremdschlüssel in Relationen. (References beinhalten die Satznummer des Tupels, auf den verwiesen wird, Fremdschlüssel müssen gesucht werden, wozu ggf. mehrere Sätze einer Relation gelesen werden müssen um diesen Schlüssel zu finden).
Hab grad zufällig einiges über Regelsysteme in RDBMS gefunden:
http://www.postgresql.org/files/documentation/books/pghandbuch/html/rules.html
Evtl. steht ja was interessantes oder brauchbares drin.
Ich habe tatsaechlich am 20. (uebermorgen) Pruefung. Danke fuer deine Tips!
Noch ein paar Anmerkungen und Fragen von mir:
-
Das Mapping einer totalen Teilnahme kann man unter Umstaenden schon mit NOT NULL machen, denke ich. Dann naemlich, wenn man die Beziehung zu einer anderen Entitaetstabelle (z.B. im 1:n-Fall) hinzufuegt. Falls diese Entitaet total teilnimmt, kann man den Fremdschluessel auf die andere einfach NOT NULL setzen.
Im allgemeinen m:n-Fall mit eigener Tabelle kann man das nur mit einer Forderung a la “ID in projectID” machen, denke ich.
Ist aber wohl auch nicht so wichtig. -
Macht der Systempuffer in einer virtuellen BS-Umgebung Sinn? Dann werden ja “eingelagerte” Seiten evtl. durch das BS ausgelagert…
-
Wenn der Anwender seine Transaktion nicht bestaetigt bekommt, dann weiss er doch nicht, ob sie ausgefuehrt worden ist oder nicht, oder? Er weiss nur, dass sie entweder ausgefuehrt worden ist oder eben nicht. Also muesste er doch nochmal pruefen, ob es erfolgreich war oder nicht, bevor er sie nochmal absetzt. Oder ist das DBS verpflichtet, eine Antwort (ja/nein) rauszugeben? Aber das kann es doch nicht, wenn es komplett abstuerzt…
Hmm, du meinst also, dass du eine 1:n Relation so abbildest, dass du auf der n-Seite einen Fremdschlüssel einführst, und totale Teilnahme mit NOT NULL sicherstellst. Die totale Teilnahme funktioniert so nur in eine Richtung. Stell dir vor, du hast z.B. Firmen und Personen, jede Person arbeitet bei genau einer Firma. Die Firmenid-s werden bei den Personen als Fremdschlüssel abgespeichert. Durch NOT NULL auf den Fremdschlüssel erzielst du nur, dass jede Person garantiert einer Firma zugewiesen wird, nicht aber dass jede Firma auch Mitarbeiter hat. Also NOT NULL liefert dir schon noch eine totale Teilnahme, aber nur in eine Richtung.
Das Problem ähnelt diesem Schokofabrik-Beispiel vom Tanenbaum aus VS. Keine Ahnung wo der Schlussstrich gezogen wird, ich nehme an bevor z.B. in sqlplus die Bestätigung erscheint. Wie es z.B. bei JDBC abläuft weiss ich auch nicht. Ich glaub die Benachrichtigung des Clients über den Abschluss der Transaktion gehört nicht zu der Transaktion dazu, da eben diese Benachrichtigung von vielen externen Gegebenheiten abhängt (z.B. Netzwerkzusammenbruch, Client killt sein Programm welches grade eben commit aufgerufen hat usw.). Es könnte ja auch sein, dass genau nachdem die Info über den Abschluss der Transaktion in den Bildschirmspeicher geschrieben wurde und auf dem Weg zum Monitor ist, der Strom ausfällt und der User diese Benachrichtigung nicht mitbekommt - kann das DBMS darauf reagieren? Ich vermute die Transaktion wird vor dieser Benachrichtigung vom DBMS als abgeschlossen betrachtet.
Wuerd ich so nicht sagen 
Genau das hat er mich gefragt. KMW wollte dann Loesungsansaetze. Ich hab mich dann auf Trigger eingeschossen, war aber nicht genug.
Haette dann sagen sollen, dass man das innerhalb der Anwendung abfangen soll.