Im Anhang finden sich einige ER-Diagramme, die das Datenbankschema wiedergeben. Einige Stellen des Datenbankschemas bedürfen jedoch noch einer zusätzlichen Erklärung. Die Beziehungen ``Mitarbeiter beaufsichtigt Klausur'' und ``Student beaufsichtigt Klausur'' wurden durch eine gemeinsame Relation 'personal_beaufsichtigt_klausur' realisiert. Diese Relation enthält als Schlüssel 'vorlesungnummer', 'klausurnummer' (beide Primärschlüssel der Relation 'vorlesung'), 'aufsicht_istmitarbeiter' (entscheidet, ob es sich um einen Mitarbeiter oder Studenten handelt) und 'aufsicht_nummer' (Primärschlüssel aus 'mitarbeiter' bzw. 'student'). Dabei handelt es sich nicht um eine Generalisierung, da keine Oberklasse gebildet wird, sondern nur zwei gleichartige Beziehungen zusammengefasst werden. Ähnliches gilt für die Beziehungen ``Übungsblatt hat Aufgabe'' und ``Klausur hat Aufgabe''. Hier existiert jedoch keine eingene Beziehungsrelation. Da es sich jeweils um 1:n-Beziehungen handelt, wurde die Beziehung durch Fremdschlüsselimport in die Relation 'aufgabe' realisiert.
Die in den ER-Diagrammen aufgeführten Entities ``Vorlesungspersonal'', ``Vorlesungsteilnehmer'', ``Seminarteilnehmer'', ``Praktikumspersonal'' und ``Praktikumsteilnehmer'' wurden nicht durch eigene Relationen realisiert. Im ER-Diagramm sind sie jedoch notwendig, um einige Beziehungen (zum Beispiel ``Vorlesungspersonal betreut Übungsgruppe'') ordentlich zu modellieren. In der Datenbank wird das Entity ``Vorlesungspersonal'' durch die Relation ``arbeitet_fuer_vorlesung'' abgedeckt. Dies ist eigentlich eine Beziehungsrelation zwischen 'student' und 'vorlesung' bzw. 'mitarbeiter' und 'vorlesung'. (Hier gilt das, was im letzten Absatz dargestellt wurde.) Bei dem Entity ``Praktikumspersonal'' verhält es sich genau so. Die Entities ``Vorlesungsteilnehmer'' und ``Praktikumsteilnehmer'' werden durch die Relationen 'student_besucht_vorlesung' bzw. 'student_macht_praktikum' abgedeckt. Auf diesen Beziehungsrelationen werden dann selbst wieder Beziehungen aufgesetzt. Dies ist beispielsweise bei 'student_besucht_uebung' der Fall. Wie im ER-Diagramm vorgegeben, wird dadurch garantiert, dass ein Übungsteilnehmer auch Vorlesungsteilnehmer sein muss. Das Entity ``Seminarteilnehmer'' fällt mit der Beziehung ``Seminarteilnehmer hält Seminarvortrag'' zusammen und findet sich in der Relation 'student_haelt_seminarvortrag' wieder. Auf diese Relation bezieht sich außerdem die Relation 'student_anwesend_bei_vortrag'.
Die im ER-Diagramm dargestellte Beziehung ``Vorlesungsteilnehmer besucht Übung'' kommt eigentlich mehrmals vor. Ein Student kann mehrere Präferenzen für die Übungsteilnahme angeben, bevor er einer Übungsgruppe endgültig zugeteilt wird. Schaut man sich die Relation 'student_besucht_uebung' an, stellt man fest dass hier neben der genannten Beziehung auch mehrere ``Präferenz''-Beziehungen festgelegt sind.
Die Beziehungen ``Student nimmt teil an Praktikum'' und ``Praktikumsteilnehmer gehört zu Praktikumsgruppe'' scheinen redundant zu sein. Da jedoch die Anmeldung zu einem Praktikum und die Gruppeneinteilung oft zeitlich weit auseinander liegen, ist diese Modellierung sinnvoll. Außerdem sind auch Praktikas denkbar, bei denen keine Gruppen gebildet werden.
Das Entity-Relationship-Diagramm für das FoPra gilt in gleicherweise für Diplomarbeiten. Das Relationship ``Student macht Diplomarbeit'' ist als eigene Relationen ausgeführt, auch wenn es sich hierbei aller Voraussicht nur um eine 1:n-Beziehung handelt. Da die Relation für das Entity ``FoPra'' Daten längerfristig speichern soll (History), die Relation 'student' aber aus datenschutzrechtlichen Gründen regelmäßig bereinigt werden muss, ist eine eigene Beziehungsrelation an dieser Stelle sinnvoll. Die Diplomarbeit kann dann auch unabhängig vom Student existieren. In der Beziehungsrelation kann trotzdem das Attribut 'studentnummer' mit der Einschränkung ``NOT NULL'' versehen werden. Die anderen Beziehungen müssen sowieso als eigene Relationen ausgeführt werden, da von m:n-Beziehungen ausgegangen werden muss.