Saarland Abitur Information Systems common mistakes
Saarland Abitur Information Systems · Understand the traps and how to avoid them.
Beim Entwurf eines Entity-Relationship-Modells werden Beziehungstypen mit Attributen versehen (z. B. eine Note direkt an der Kante zwischen Studierendem und Kurs), obwohl die Note in Wahrheit von der Kombination beider Entitäten abhängt und damit ein eigener Entitätstyp oder eine m:n-Beziehung mit Attributen benötigt.
Viele Kandidaten übertragen Attribute intuitiv auf die nächstliegende Linie im Diagramm, ohne zu prüfen, wovon das Attribut funktional abhängt. Die Unterscheidung zwischen Beziehung mit Attributen und eigenständiger Entität wird selten geübt, weil im Unterricht oft nur einfache 1:n-Fälle modelliert werden.
What to do instead
Vor dem Zeichnen für jedes Attribut die Frage stellen: 'Wovon hängt dieser Wert eindeutig ab?' Wenn er nur durch das Paar (A, B) bestimmt ist, gehört er an den Beziehungstyp oder in eine Zwischentabelle. Anschließend das Modell in Tabellen überführen und prüfen, ob jede Tabelle einen sinnvollen Schlüssel besitzt.
Beim Überführen eines ER-Modells in das relationale Schema werden m:n-Beziehungen als Fremdschlüssel in einer der beiden Tabellen abgelegt, statt eine eigene Zwischentabelle mit zusammengesetztem Primärschlüssel anzulegen; dadurch gehen Mehrfachzuordnungen verloren.
Der Unterschied zwischen 1:n (Fremdschlüssel genügt) und m:n (eigene Tabelle nötig) wird häufig nur oberflächlich gelernt. Unter Zeitdruck wird das bekannteste Muster 'Fremdschlüssel einfügen' ungeprüft auf alle Beziehungen angewendet.
What to do instead
Kardinalitäten systematisch abarbeiten: Bei 1:n wandert der Schlüssel der 1-Seite als Fremdschlüssel in die n-Seite; bei m:n entsteht immer eine neue Tabelle mit beiden Schlüsseln als zusammengesetztem Primärschlüssel. Diesen Schritt an einem Beispiel mit echten Datenzeilen durchspielen, um den Informationsverlust sichtbar zu machen.
SQL-Abfragen mit JOIN, WHERE und GROUP BY liefern falsche Ergebnisse, weil Filterbedingungen für die zweite Tabelle in die WHERE-Klausel geschrieben werden, obwohl ein LEFT JOIN gewünscht ist, oder weil HAVING und WHERE verwechselt werden.
Die logische Ausführungsreihenfolge (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY) wird oft nicht verinnerlicht. Bei LEFT JOIN filtert eine WHERE-Bedingung auf die rechte Tabelle die NULL-Zeilen weg und macht den Outer Join faktisch zum Inner Join – ein Effekt, der ohne Testdaten unsichtbar bleibt.
What to do instead
Bedingungen, die die rechte Seite eines LEFT JOIN betreffen, in die ON-Klausel schreiben; Aggregatfilter immer in HAVING. Jede Abfrage an kleinen Beispieldaten mit erwartetem Ergebnis durchspielen und insbesondere Randfälle ohne Partnerzeile prüfen.
Bei der Analyse eines Algorithmus wird die Laufzeit nur an einem konkreten Eingabebeispiel abgeschätzt ('bei 10 Elementen sind es 4 Schritte') statt eine geschlossene Formel in Abhängigkeit von n anzugeben und die Größenordnung (O-Notation) zu bestimmen.
Kandidaten zählen oft Schleifendurchläufe für ein Beispiel und halten das für eine Laufzeitanalyse. Die Unterscheidung zwischen exakter Schrittzahl, asymptotischer Ordnung und Worst Case wird selten explizit geübt.
What to do instead
Immer zuerst die Anzahl der Elementaroperationen als Funktion von n aufstellen, dann die dominante Termgruppe identifizieren und Konstanten weglassen. Zusätzlich best, average und worst case getrennt benennen und an einem Randfall (n = 0, bereits sortiert) plausibilisieren.
Ein Algorithmus wird zwar korrekt implementiert, aber die geforderte Modellierung (z. B. Struktogramm, Pseudocode oder Objektmodell) fehlt oder weicht von der Implementierung ab, sodass Lösung und Begründung nicht zusammenpassen.
Unter Prüfungsdruck wird direkt Code geschrieben, weil das schneller wirkt. Die Aufgabe verlangt jedoch häufig ausdrücklich einen Entwurf vor der Implementierung; die Punkte für Modellierung und Begründung gehen dann verloren, selbst wenn das Programm läuft.
What to do instead
Die Aufgabenstellung zuerst auf geforderte Artefakte prüfen und diese in der verlangten Reihenfolge anlegen: Modell, dann Algorithmus in Pseudocode, dann Implementierung. Am Ende Implementierung und Modell Zeile für Zeile gegeneinander abgleichen.
Bei der Analyse eines endlichen Automaten oder einer formalen Grammatik wird ein Zustandsübergang bzw. eine Produktion übersehen, sodass ein Wort fälschlich als akzeptiert oder abgelehnt klassifiziert wird; häufig werden auch deterministische und nichtdeterministische Automaten verwechselt.
Automaten werden oft nur grafisch betrachtet, ohne alle Wörter systematisch durchzuspielen. Die Definition von Akzeptanz (Endzustand nach vollständigem Lesen des Wortes) und der Unterschied zwischen Determiniertheit und Nichtdeterminismus sind begrifflich unscharf.
What to do instead
Für jedes Testwort die komplette Konfigurationsfolge als Tabelle aufschreiben (Zustand, gelesenes Zeichen, Folgezustand). Bei nichtdeterministischen Automaten alle möglichen Pfade verfolgen. Grammatik und Automat gegenseitig prüfen, indem aus der Grammatik abgeleitete Wörter im Automaten getestet werden.
Die Begriffe Entscheidbarkeit, Aufzählbarkeit und Berechenbarkeit werden in einer Aufgabenstellung vertauscht, etwa indem behauptet wird, ein nicht entscheidbares Problem sei grundsätzlich unlösbar oder jede aufzählbare Sprache sei entscheidbar.
Die Hierarchie der Berechenbarkeitsklassen wird oft als Merksatz gelernt, ohne die Definitionen (Halteproblem, Diagonalisierung, Semi-Entscheidbarkeit) zu verstehen. Ähnlich klingende Fachbegriffe werden dann synonym verwendet.
What to do instead
Die drei Stufen mit je einem kanonischen Beispiel verknüpfen: entscheidbar (z. B. Wortproblem regulärer Sprachen), semi-entscheidbar (Halteproblem), nicht semi-entscheidbar (Komplement des Halteproblems). Bei jeder Aussage prüfen, ob sie die Definition exakt erfüllt, und die Begründung mit dem passenden Reduktions- oder Diagonalargument belegen.
Bei einer Aufgabe zum Client-Server-Modell oder zu Protokollen werden Schichten verwechselt, etwa HTTP auf die Transportschicht gelegt oder TCP als verbindungslos bezeichnet; zudem wird der Unterschied zwischen Port und IP-Adresse nicht sauber erklärt.
Das Schichtenmodell wird häufig nur als Schaubild erinnert. Ohne Bezug zu konkreten Protokollen bleibt unklar, welche Aufgabe (Adressierung, Zuverlässigkeit, Anwendungslogik) auf welcher Schicht liegt.
What to do instead
Eine Tabelle mit Schicht, Aufgabe, Beispielprotokoll und Adressierungsebene (MAC, IP, Port) auswendig sicher beherrschen und für jede Aussage zuordnen. TCP (verbindungsorientiert, zuverlässig, Ports) und UDP (verbindungslos) an einem konkreten Anwendungsfall wie DNS oder Video-Streaming begründen.
Datenschutzrechtliche Bewertungen bleiben bei allgemeinen Aussagen stehen ('das ist datenschutzrechtlich bedenklich') und benennen weder die betroffenen personenbezogenen Daten noch Rechtsgrundlage, Zweckbindung oder Maßnahmen wie Datenminimierung und Pseudonymisierung.
Kandidaten scheuen die rechtliche Argumentation und formulieren vorsichtig-allgemein. Die Grundprinzipien (Rechtmäßigkeit, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität) werden selten auf den konkreten Fall angewendet.
What to do instead
Jede Bewertung nach festem Schema aufbauen: Welche Daten sind personenbezogen? Welcher Zweck und welche Rechtsgrundlage? Welche Grundsätze sind verletzt? Welche technischen und organisatorischen Maßnahmen (Verschlüsselung, Zugriffsbeschränkung, Löschfristen) beheben das Problem? Dieses Raster vorab einüben.
Sicherheitslücken werden nur benannt, aber nicht erklärt, wie sie ausgenutzt werden und welche Gegenmaßnahme auf welcher Ebene wirkt; SQL-Injection wird etwa mit fehlender Verschlüsselung begründet statt mit ungeprüfter Übernahme von Nutzereingaben in Abfragen.
Sicherheitsbegriffe werden als Vokabelliste gelernt, ohne Angriffsmechanismus und Schutzmaßnahme zu verknüpfen. Dadurch werden Ursache, Angriff und Gegenmaßnahme vermischt.
What to do instead
Für jede Lücke ein Dreieck notieren: Ursache (z. B. String-Konkatenation in SQL), Angriff (Einschleusen von ' OR 1=1 --'), Gegenmaßnahme (Prepared Statements, Rechtebeschränkung, Eingabevalidierung). Dieses Schema auf XSS, Pufferüberlauf und schwache Passwörter übertragen.