Beiträge von AnnaWInf

Hi, kurze Verständnisfrage aus dem IT-Infrastruktur-Modul.

Virtualisierung und Container wurden bei uns in derselben Sitzung behandelt, mit dem Fazit „beides trennt Anwendungen voneinander“. Im Praktikum sollten wir dann eine kleine Webanwendung einmal in einer VM und einmal als Container bereitstellen – und da war der Unterschied ziemlich deutlich: Die VM hat gefühlt ewig gebootet und rund 8 GB belegt, der Container war in zwei Sekunden da und ein paar hundert MB groß.

Jetzt frage ich mich:

• Was ist der technische Unterschied, wenn doch beides „virtualisiert“?
• Warum ist ein Container so viel kleiner und schneller – was fehlt ihm?
• Und wann nimmt man in der Praxis was? Wenn Container in allem besser wären, gäbe es ja keine VMs mehr.

Die Klausurfrage wird vermutlich „Vergleichen und beurteilen Sie“ lauten, und da will ich nicht nur „Container ist leichter“ hinschreiben. 😅

Daniel hat die Klausurantwort komplett, ich ergänze den Punkt, bei dem viele Skripte (und leider auch manche echte Software) stehen bleiben: SHA-256 allein ist für Passwörter trotzdem keine gute Wahl.

Der Grund: SHA-256 ist darauf optimiert, schnell zu sein – super für Prüfsummen und Signaturen, schlecht für Passwörter. Wer eine gestohlene Datenbank hat, probiert einfach Wörterbücher und Varianten durch, und auf einer einzigen Grafikkarte sind das Milliarden Versuche pro Sekunde. Das Salt verhindert zwar vorberechnete Tabellen, aber nicht das gezielte Durchprobieren eines einzelnen Kontos.

Deshalb nutzt man für Passwörter absichtlich langsame Verfahren:

• bcrypt – mit einstellbarem Kostenfaktor
• PBKDF2 – viele tausend Iterationen einer Hashfunktion
• scrypt und Argon2 – zusätzlich speicherintensiv, was massenhaftes Parallelrechnen auf Grafikkarten teuer macht. Argon2 hat 2015 die Password Hashing Competition gewonnen und gilt heute als Empfehlung.

Für den Nutzer fällt eine Viertelsekunde beim Login nicht auf. Für einen Angreifer, der Milliarden Kandidaten testen will, ist das der Unterschied zwischen Stunden und Jahrhunderten. Alte Verfahren wie MD5 oder SHA-1 gelten für diesen Zweck als unsicher.

Mein Merksatz für die Klausur:

Verschlüsselung schützt Daten, die man wieder lesen muss. Hashing schützt Daten, die man nur prüfen muss.

Und als Grenze, falls „beurteilen“ gefragt ist: Kein Hashverfahren rettet ein schwaches Passwort wie „123456“ – das steht in jedem Wörterbuch ganz oben. Deshalb gehören Passwortrichtlinien und Zwei-Faktor-Authentifizierung in eine vollständige Antwort zur Zugangssicherheit dazu. Einordnung in die Schutzziele: Hashing unterstützt vor allem Integrität und schützt bei Passwörtern indirekt die Vertraulichkeit der Konten.

Ich schreibe gerade selbst Tests im Praxisprojekt und ergänze noch drei Begriffe, die bei uns in der Klausur direkt nach den Teststufen dran waren.

1. Die Testpyramide. Sie beschreibt, wie viele Tests man auf welcher Ebene haben sollte: unten viele Unit-Tests (schnell, billig, genau lokalisierbar), in der Mitte weniger Integrationstests, oben nur wenige End-to-End-Tests über die Oberfläche (langsam, wartungsintensiv, bei Fehlschlag schwer zu deuten). Das Gegenbild heißt Eistüte: kaum Unit-Tests, dafür Hunderte manuelle Klicktests. Das ist der Zustand, in dem jede Änderung zur Mutprobe wird.

2. Stub und Mock. Daniel hat geschrieben, dass Unit-Tests die Nachbarkomponenten durch Platzhalter ersetzen. Davon gibt es zwei wichtige Sorten:

• Ein Stub liefert nur feste Antworten, damit der Test überhaupt laufen kann – etwa ein Wechselkursdienst, der immer 1,10 zurückgibt.
• Ein Mock prüft zusätzlich, ob und wie er aufgerufen wurde – etwa ob beim Abschluss einer Bestellung genau eine Bestätigungsmail ausgelöst wurde.

Merksatz: Stub = Zustand prüfen, Mock = Verhalten prüfen.

3. Testgetriebene Entwicklung (TDD). Erst den Test schreiben, der fehlschlägt, dann gerade so viel Code, dass er grün wird, dann aufräumen – im Kreislauf „Red, Green, Refactor“. Das passt übrigens schön zu Tobis Hinweis, dass das erwartete Ergebnis vorher feststehen muss: Bei TDD ist das gar nicht anders möglich.

Hi zusammen,

ich studiere Wirtschaftsinformatik und habe ein Angebot von einer kleinen Agentur bekommen: Frontend-Entwicklung, ca. 15–20 Stunden die Woche. Der Haken: Die wollen mich nicht als Werkstudentin anstellen, sondern als Freelancerin auf Rechnung. Begründung: „Dann sparen wir uns den Papierkram und du verdienst pro Stunde mehr.“

Klingt erst mal gut, aber: Ich soll feste Kernzeiten haben, täglich ins Stand-up, bekomme einen Firmenlaptop und eine Firmen-E-Mail-Adresse, und andere Kunden hätte ich realistischerweise keine. Eine Kommilitonin meinte sofort „Das ist doch Scheinselbstständigkeit“. 😬

Woran macht man das eigentlich fest? Und falls es so wäre – bekomme ich dann Ärger oder die Agentur? Wir hatten das Thema kurz in Wirtschaftsprivatrecht, aber nur als Randnotiz.

Hi zusammen,

mein Notebook hat nach 14 Monaten einen Defekt am Netzteilanschluss. Im Laden hieß es, die Garantie sei nach zwölf Monaten abgelaufen, da könne man nichts machen. Ich habe ein ungutes Gefühl, weil ich mich dunkel erinnere, dass es zwei verschiedene Dinge gibt – aber ich kriege die Systematik nicht zusammen.

Passenderweise hatten wir das Thema im Modul Wirtschaftsrecht, und in der Probeklausur kam ein Fall dazu vor, bei dem ich unsicher war, in welcher Reihenfolge die Ansprüche geprüft werden.

Kann mir jemand erklären:

• Was genau ist der Unterschied zwischen Gewährleistung und Garantie?
• Was bedeutet die Sache mit den zwölf Monaten wirklich – ist da etwas dran oder ist das schlicht falsch?
• Und welche Ansprüche habe ich in welcher Reihenfolge, wenn tatsächlich ein Mangel vorliegt?

Danke!

Ich hänge noch die Frage an, die im Studium selten gestellt wird, in der Praxis aber zuerst kommt: Wozu modelliere ich überhaupt? Daran hängt die Notationswahl nämlich mehr als am persönlichen Geschmack.

• EPK: stark bei der fachlichen Ist-Aufnahme mit Nicht-Technikern. Der Zwang zum Wechsel Ereignis ↔ Funktion macht das Modell im Workshop gut vorlesbar.
• BPMN: stark, wenn der Prozess später ausgeführt oder automatisiert werden soll, und immer dann, wenn mehrere Beteiligte zusammenspielen – Pools und Lanes plus Nachrichtenfluss zeigen sauber, wer mit wem kommuniziert. Das kann eine EPK so nicht.

Und ein Fehler, der in Korrekturen fast immer angestrichen wird: Ein Prozess, der mit einem bestimmten Konnektor aufgespalten wurde, sollte mit demselben Typ wieder zusammengeführt werden. Besonders das ODER beim Zusammenführen ist tückisch, weil unklar bleibt, worauf gewartet werden muss – der Prozess weiß nicht, ob noch ein zweiter Pfad ankommt. Wenn ihr unsicher seid: erst überlegen, ob wirklich beide Wege laufen können (UND) oder genau einer (XOR) – das ODER braucht man deutlich seltener, als man denkt.

Hi zusammen, wir behandeln gerade Anforderungsmanagement und ich stolpere ständig über Lastenheft und Pflichtenheft. In den Folien steht „Lastenheft = Auftraggeber, Pflichtenheft = Auftragnehmer“ – so weit klar. Aber ehrlich gesagt verstehe ich nicht, warum man zwei Dokumente braucht, wenn am Ende doch dasselbe System herauskommen soll.

Kann das jemand am Beispiel erklären? Und wie sieht das aus, wenn agil gearbeitet wird – da gibt es die Hefte doch gar nicht mehr, oder?

Ergänzend der Punkt, über den in Klausuren am meisten gestolpert wird: Schichten sind etwas anderes als Rechner. Die drei Schichten sind eine logische Aufteilung der Software. Wie viele Rechner daran beteiligt sind, ist die physische Verteilung – dafür sagt man meist „Tiers“.

Heißt konkret: Wenn du eine Anwendung mit sauber getrennter Oberfläche, Logik und Datenhaltung komplett auf deinem Laptop laufen lässt, ist das trotzdem eine Drei-Schichten-Architektur – nur eben auf einem einzigen Rechner. Umgekehrt macht das bloße Verteilen auf drei Server aus einem Programm noch keine saubere Schichtung.

Und weil in Aufgaben gern nach Nachteilen gefragt wird – die gibt es nämlich auch:

• mehr Kommunikation über Schichtgrenzen hinweg und damit zusätzliche Latenz,
• höherer Entwicklungs- und Betriebsaufwand, mehr Komponenten zu überwachen,
• bei schlecht geschnittenen Schichten muss man für eine Kleinigkeit trotzdem alle drei anfassen.

Der Standardnutzen (Wartbarkeit, Austauschbarkeit, Sicherheit) überwiegt bei größeren Systemen deutlich – für ein Ein-Personen-Skript wäre die Trennung Overkill. Genau diese Abwägung ist meist die erwartete Antwort.

Später Nachtrag, weil in Klausuren nach dem ERP-Begriff sehr gern die Abgrenzung zu den Nachbarsystemen kommt – und die ist mit dem Prozessgedanken von oben leicht zu merken:

• CRM setzt vor dem ERP an (Interessent, Angebot, Kampagne, Kundenhistorie),
• SCM reicht über das eigene Unternehmen hinaus (Lieferanten, Transport, Netzwerkplanung),
• MES sitzt unter dem ERP direkt an der Maschine (Feinsteuerung, Betriebs- und Maschinendaten in Echtzeit),
• BI/Data Warehouse liegt über allem und wertet aus, statt zu buchen.

Dazu die Zwei-Ebenen-Sicht, die gern als Definitionsfrage kommt: Das ERP ist ein operatives Administrations- und Dispositionssystem – es führt Geschäftsvorfälle aus. Auswertung und Entscheidungsunterstützung sind Aufgabe der analytischen Ebene. Deshalb löst man Reporting-Probleme nicht dadurch, dass man Auswertungen ins ERP hineinbaut.

Und ein Punkt, der bei Daniels Integrationsgedanken oft untergeht: Integration ist nicht dasselbe wie eine Schnittstelle. Zwei Systeme, die nachts Dateien austauschen, sind gekoppelt, aber nicht integriert – es gibt weiterhin zwei Wahrheiten, nur mit Zeitverzug. Echte Datenintegration heißt: eine Datenbasis, kein Abgleich nötig.

Moin, ich übe gerade für die Datenbank-Klausur und stolpere ständig über dieselbe Fehlermeldung.

Ich möchte pro Abteilung die Anzahl der Mitarbeiter und will nur Abteilungen sehen, in denen mehr als fünf arbeiten. Schreibe ich die Bedingung in WHERE, meckert die Datenbank, dass eine Aggregatfunktion dort nicht erlaubt sei. Nehme ich zusätzliche Spalten in SELECT auf, kommt die Meldung, die Spalte müsse in der GROUP-BY-Klausel stehen.

Ich bekomme es mit Ausprobieren irgendwann hin, aber ich verstehe die Regel dahinter nicht. Also:

• Woran entscheide ich, ob eine Bedingung in WHERE oder in HAVING gehört?
• Warum muss jede Spalte aus SELECT auch in GROUP BY stehen?
• Und ist COUNT(*) dasselbe wie COUNT(spaltenname)? In meinen Ergebnissen kommt manchmal etwas anderes raus.

Danke schon mal – ich glaube, mir fehlt hier ein Grundprinzip und nicht die Syntax. 🙈

Ich hänge noch die Werkzeug-Perspektive dran, weil man sich damit selbst kontrollieren kann: Die Dimensionsregel aus dem Thread ist genau das, was Software beim Rechnen prüft.

In Tabellenkalkulationen macht das die Funktion MMULT – markierten Ergebnisbereich in der Größe (m×p) auswählen und die beiden Bereiche übergeben. Passen die inneren Dimensionen nicht, kommt ein Fehlerwert statt eines Ergebnisses. In Python mit NumPy ist es der Operator @ bzw. numpy.matmul, und die Fehlermeldung nennt sogar beide Formate im Klartext.

Der Lerneffekt: Wenn du eine Aufgabe von Hand gerechnet hast und dir unsicher bist, ob du Zeile und Spalte vertauscht hast, tippst du dieselbe Rechnung einmal ein. Kommt ein Fehler, war die Reihenfolge falsch (A·B ≠ B·A ist ja gerade der Punkt). Kommt ein Ergebnis mit unerwartetem Format, hast du beim Aufschreiben Zeilen und Spalten vertauscht.

Fürs Falk-Schema auf Papier bleibe ich trotzdem bei der Empfehlung aus dem Thread – für die Klausur muss man es können. Aber zum Nachrechnen der Übungsaufgaben ist es Gold wert, in zwei Minuten zwanzig Ergebnisse zu prüfen statt zwanzig Minuten neu zu rechnen 🙂

Dein Beispiel ist perfekt, das ist praktisch der Schulbuchfall.

Transitiv heißt: über eine Zwischenstation. Formal liegt eine transitive Abhängigkeit vor, wenn der Schlüssel A ein Attribut B bestimmt und dieses B wiederum ein weiteres Nichtschlüsselattribut C bestimmt – ohne dass C direkt vom Schlüssel abhängt.

In deiner Tabelle:

• BestellNr → KundenNr (jede Bestellung gehört zu einem Kunden)
• KundenNr → KundenName, KundenOrt (die Kundennummer bestimmt Name und Ort)
• also: BestellNr → KundenNr → KundenName

KundenName hängt eben nicht von der Bestellnummer ab, sondern nur vom Kunden. Er ist über die KundenNr durchgereicht – das ist die Transitivität.

Und jetzt zu deiner eigentlichen Frage, warum das ein Problem ist. Die Daten sind richtig, solange nichts passiert. Sobald sich etwas ändert, entstehen die drei klassischen Anomalien:

• Änderungsanomalie: Zieht der Kunde um, musst du den Ort in allen seinen Bestellzeilen ändern. Wird eine vergessen, hat derselbe Kunde zwei Wohnorte – und die Datenbank kann dir nicht sagen, welcher stimmt.
• Einfügeanomalie: Du kannst einen neuen Kunden nicht erfassen, solange er nichts bestellt hat. Es gibt keinen Platz für ihn.
• Löschanomalie: Löschst du die letzte Bestellung eines Kunden, verschwinden auch seine Stammdaten.

Die Lösung ist immer dieselbe: Das transitiv abhängige Bündel wandert in eine eigene Tabelle, und in der Ursprungstabelle bleibt nur der Fremdschlüssel stehen. Also Kunde(KundenNr, KundenName, KundenOrt) und Bestellung(BestellNr, Datum, KundenNr).

Ich ergänze die Notationen, weil daran in Klausuren mehr Punkte hängen als am Konzept – und weil dein „ich rate“ vermutlich genau daher kommt.

Chen-Notation (1, n, m): Die Zahlen stehen an den Verbindungslinien und werden „über Kreuz“ gelesen. Bei Abteilung –1—— beschäftigt ——n– Mitarbeiter heißt die 1 an der Abteilungsseite: Ein Mitarbeiter gehört zu genau einer Abteilung. Diese Leserichtung ist die klassische Fehlerquelle. Sprich beim Zeichnen immer beide Sätze laut aus, jeweils in eine Richtung – dann kann man sich nicht vertun.

(min,max)-Notation: Hier steht an jeder Seite ein Paar, und zwar für die eigene Seite: (0,n) an der Mitarbeiterseite bedeutet, dass eine Abteilung null bis beliebig viele Mitarbeiter hat. Der Vorteil gegenüber Chen ist die Zusatzinformation, ob eine Teilnahme optional (Minimum 0) oder zwingend (Minimum 1) ist. Praktische Bedeutung: Aus einem Minimum von 1 folgt in der Tabelle ein NOT NULL für den Fremdschlüssel, aus 0 eine Spalte, die NULL sein darf.

Woran du n:m im Aufgabentext erkennst, ohne lange nachzudenken: Es steht immer sinngemäß „… kann mehrere … und umgekehrt“ da. Student belegt mehrere Kurse, ein Kurs hat mehrere Studenten. Autor schreibt mehrere Bücher, ein Buch hat mehrere Autoren. Sobald beide Richtungen „mehrere“ ergeben, brauchst du die Zwischentabelle – ausnahmslos.

Ein Punkt noch, der oft als Zusatzfrage kommt: Wenn eine Beziehung eigene Attribute hat (Menge, Datum, Note, Rolle), ist sie fast immer n:m oder wird als eigene Entität modelliert. Bei Student – belegt – Kurs mit dem Attribut „Note“ ist der Fall eindeutig: Die Note gehört weder zum Studenten noch zum Kurs, sondern zur Belegung. Diese Zwischentabelle bekommt dann meist einen eigenen sprechenden Namen – „Belegung“, „Bestellposition“, „Teilnahme“ – und wird dadurch selbst zu einer Entität, an die man weitere Beziehungen anhängen kann.

Hi, wir haben gerade Cloud Computing im Modul und die drei Servicemodelle werden im Skript nur mit einer Schichtgrafik erklärt. Die Begriffe kann ich auswendig, aber sobald eine Aufgabe ein Szenario beschreibt, rate ich eigentlich nur.

Zum Beispiel: Ein Unternehmen mietet virtuelle Server und installiert dort selbst eine Datenbank – ist das IaaS? Und wenn es stattdessen eine fertige Datenbank als Dienst bucht, plötzlich PaaS? Gibt es eine Frage, die ich mir stellen kann, um die Modelle sicher auseinanderzuhalten – und wer haftet eigentlich, wenn Daten verloren gehen? 🤔

Zur Signatur: Da wird das asymmetrische Verfahren einfach andersherum benutzt, und das ist der Aha-Moment.

• Vertraulichkeit: Ich verschlüssele mit dem öffentlichen Schlüssel des Empfängers → nur er kann mit seinem privaten Schlüssel lesen.
• Signatur: Ich „verschlüssele“ mit meinem privaten Schlüssel → jeder kann es mit meinem öffentlichen Schlüssel prüfen. Lesen kann es also jeder, aber erzeugen konnte es nur ich.

Praktisch signiert man nicht das ganze Dokument, sondern dessen Hashwert (Prüfsumme fester Länge). Der Empfänger berechnet den Hash neu und vergleicht ihn mit dem entschlüsselten Wert aus der Signatur. Stimmen beide überein, sind zwei Dinge belegt: Integrität (nichts verändert) und Authentizität (kommt wirklich vom Absender). Als drittes ergibt sich die Nichtabstreitbarkeit, weil außer dem Inhaber niemand den privaten Schlüssel hat. Merksatz für die Klausur: öffentlich verschlüsseln = geheim halten, privat signieren = beweisen, von wem es stammt.

Hi zusammen, in Datenbanken kam der Begriff Trigger dran. Ich habe verstanden, dass das irgendeine Aktion ist, die automatisch „auslöst“ – aber mir fehlt das Bild, wozu ich sowas praktisch brauche. Ist das nicht dasselbe, wie wenn ich die Logik einfach in meiner Anwendung programmiere?

Kann mir jemand mit einem Beispiel erklären, was ein Trigger macht und wann er sinnvoll ist? 🙈

Hi, in Datenbanken kam der Begriff Deadlock dran und ich hab nur so halb verstanden, was da passiert. Zwei Transaktionen blockieren sich gegenseitig – aber wie kommt es überhaupt dazu, und warum hängt dann nicht einfach alles fest?

Kann das jemand an einem einfachen Beispiel erklären? 🙈

Hi, ich übe gerade SQL und merke, dass ich viele Aufgaben sowohl mit einer Unterabfrage als auch mit einem JOIN lösen kann. Gibt es eine Faustregel, wann ich was nehme? Und stimmt es, dass JOINs immer schneller sind, oder ist das nur so ein Mythos?

Ein Beispiel wäre super, an dem man den Unterschied sieht.

Hi zusammen, ich komm bei der Normalisierung ins Straucheln. Die 1. Normalform (atomare Werte) krieg ich hin, und die 3. verstehe ich vom Prinzip. Aber der Schritt 1. NF → 2. NF und diese „partielle Abhängigkeit“ will mir einfach nicht in den Kopf.

Woran erkenne ich konkret, dass ich eine Tabelle in die 2. NF aufteilen muss? Am liebsten an einem Beispiel.

Hi zusammen, im Datenbank-Modul kam heute das Thema Views dran und ich komme mit dem Nutzen nicht so ganz klar. Eine View ist ja nur eine gespeicherte SELECT-Abfrage, die sich wie eine Tabelle ansprechen lässt. Aber wenn ich das SELECT sowieso schreiben kann – warum leg ich mir dafür extra eine View an?

Wann lohnt sich das in der Praxis, und speichert eine View eigentlich Daten oder nicht? 🤔