Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/dbp13/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/dbp13/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/dbp13/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Datenbankpraktikum SS 2013 - Datenvisualisierung - ER-Diagramm

Dokumentation: ER-Diagramm

Christoph Knauft, Niels Hellwig

Entity-Relationship-Diagramm, Version 1:

Das ER-Diagramm basiert auf den in der Aufgabenstellung formulierten Anforderungen. Der Einfachheit halber sind Schlüssel nicht angegeben, da Rails automatisch künstliche Schlüssel (IDs) vergibt. Um die gemeinsame Kommunikation zu vereinfachen wurde das ER-Diagramm auf Deutsch formuliert. Die Rails-Applikation wird gemäß der Konvention englische Begriffe verwenden.

Typisch für ER-Modelle ist die Vereinfachung eines real existierenden Problems innerhalb dieses Schemas. Dadurch werden einige Informationen, die noch im Data Warehouse vorhanden sind, innerhalb der Applikation vernachlässigt. Konkret sind dies z.B. Urlaubs- und Krankheitssemester, für die keine ausdrückliche Berücksichtigung in der Aufgabenstellung gefordert sind.

In der Aufgabenstellung wird eine Unterscheidung zwischen Absolventen und Studenten gefordert. Dies ist innerhalb dieses Modells dadurch abgebildet, dass ein Studium eines Studenten einen Abschluss haben kann. Hat das Studium eine Verknüpfung zu einem Abschluss, ist dieser Student für genau dieses Studium ein Absolvent. Dadurch kann ein Absolvent gleichzeitig Student sein (eine Anforderung, die sich bspw. bei BA-/MA-Studiengängen ergibt). Problematisch ist die Modellierung des k-ten Fachsemesters für aktuelle Studenten bzw. die benötigten Semester für Absolventen. Für Absolventen wird diese Information doppelt gehalten. Das k-te Fachsemester am Studium wird idR den benötigten Semestern beim Abschluss entsprechen. Das ist ein Problem in der Modellierung, sollte aber in der Praxis keine Schwierigkeiten darstellen.

Eine andere Herausforderung ist die Unterscheidung der Städte. Es gibt in der Aufgabenstellung zwei Mengen von Städten: einerseits Städte in Deutschland, andererseits ausländische Städte. Deutsche Städte haben zusätzlich ein Bundesland. Diese Verbindung wird über die Relation zur Entität Bundesland hergestellt. Für ausländische Städte werden Provinzen oder Staaten nicht berücksichtigt.

Jedes Studium kann grundsätzlich mehrere Studienfächer umfassen. Praktisch sollten aber maximal zwei Studienfächer pro Studium vorkommen (z.B. 2-Fächer-Bachelor). Jedes Studienfach gehört zu genau einer Lehreinheit, zu einer Lehreinheit können aber viele Studienfächer gehören (z.B. gehören die Studienfächer Informatik und Geoinformatik zur Lehreinheit Informatik). Jede Lehreinheit wird in genau einem Fachbereich angeboten, in einem Fachbereich können aber mehrere Lehreinheiten vorkommen (z.B. Die Lehreinheiten Informatik und Mathematik werden nur im Fachbereich 6 angeboten, dieser hat darüberhinaus weitere Lehreinheiten).

Entity-Relationship-Diagramm, Endversion (mit den in der Implementation verwendeten Bezeichnungen der Entities und Attribute):

Im Laufe der Implementation sind einige Felder hinzugefügt und Bezeichnungen verändert worden. Aus einer Anforderung für die Maps-Repräsentation wurden für Orte, Bundesländer und Länder die Längen- und Breitengrade sowie die Iso-Codes für Bundesländer und Länder hinzugefügt. Um die Migration zu vereinfachen wurden an Studienfächer und Orte data_warehouse_ids ergänzt. Für die Eindeutigkeit der verschiedenen Namensattribute an Orte, Bundesländern, Länder, Studienfächer, Lehreinheiten und Fachbereiche wurden jeweils die Namen um die Domäne ergänzt. Dies ist eine Anforderung für eine eindeutige Suche nach diesen Attributen innerhalb der Rails-Applikation.

Umsetzung in Ruby on Rails

Die Models wurden mittels dem Befehl

 rails generate scaffold Modelname [attributename:datentyp]

erstellt. Diese generate-Methode erzeugt automatisch das Model, den passenden Controller und die standardmäßigen Views. Außerdem legt der Befehl das Objekt-Relationale-Mapping zum Datenbank-Schema in der Schema.rb an. Eine ausführliche Einführung zum generate-Befehl findet sich unter http://guides.rubyonrails.org/command_line.html#rails-generate

Um das Schema physikalisch als Datenbank anzulegen (z.B. als SQLite oder MySQL-Datenbank) muss zuvor eine Migration durchgeführt werden. Die Dateien für die Migration werden von Ruby on Rails automatisch angelegt und die Migration selbst muss mit dem Befehl

 rails db:migrate

durchgeführt werden.

Beziehungen zwischen den Models werden zu den assozierten Models mittels Associations hergestellt. Diese werden in den Models selbst als Attribut eingetragen. Insgesamt gibt es sechs dieser Associations. Im Projekt verwenden wir vier:

  • has_many für die n-Seite einer 1:n Beziehung
  • belongs_to für den 1-Seite einer 1:n Beziehung
  • has_one für eine 1-Seite einer 1:1 Beziehung
  • has_and_belongs_to_many für beide Seiten einer n:m Beziehung

Eine ausführliche Einführung zu Assoziationen findet sich unter http://guides.rubyonrails.org/association_basics.html

Studienköpfe, Studiengänge, Studienfälle #Studienköpfe

Bei der Zählweise gibt es unterschiedliche Interpretationsmöglichkeiten. Unter Studienköpfen versteht man jeden einzelnen Studenten als individuelle Person. Studiengänge entsprechen den Studies im ER-Diagramm. Joint man diese Studies an die Studenten, will man nicht mehr einzelne Studenten zählen, sondern jeden einzelnen Studiengang. Als Studienfälle werden die zu jedem Studiengang gehörenden Studienfächer erfasst. Die Zählung funktioniert analog zur Unterscheidung zwischen Studienköpfen und Studiengängen.


Page last modified on August 23, 2013, at 06:58 PM