IT-Berufe-Podcast Archiv

In der achzehnten Episode meines Anwendungsentwickler-Podcasts setze ich die Reihe der häufigen Fragen im Fachgespräch zum Thema Datenbanken mit dem Themenbereich der Normalisierung fort. TL;DR Ich gehe mit dir typische Fragen zur Normalisierung relationaler Datenbanken im Fachgespräch durch. Dabei erfährst du, wie mehrfach gespeicherte Daten zu Anomalien führen und wie du die ersten drei Normalformen anhand einer CD-Datenbank erklärst. Außerdem geht es um referenzielle Integrität und darum, wie eine Datenbank mit bestehenden Fremdschlüsselbeziehungen beim Löschen von Datensätzen umgeht. Für deine Prüfung empfehle ich dir ein vertrautes Beispiel aus deinem Abschlussprojekt oder deinem Betrieb. Kapitelmarken [00:00:01] Einstieg ins Fachgespräch [00:00:37] Datenbanken als Thema im Fachgespräch [00:01:34] Warum relationale Datenbanken normalisiert werden [00:02:20] Redundante Daten und Denormalisieren im Data-Warehouse [00:04:31] Einfügeanomalie [00:05:38] Änderungsanomalie [00:06:28] Löschanomalie [00:07:11] Antworten zu Normalformen im Fachgespräch strukturieren [00:08:40] Definitionen der ersten drei Normalformen [00:09:32] Ein eigenes Beispiel für die Prüfung wählen [00:10:46] Erste Normalform und atomare Werte [00:12:57] Zusammengesetzte Werte und Listen aufteilen [00:15:49] Zweite Normalform und vollständige Schlüsselabhängigkeit [00:19:58] m:n-Beziehungen und Zuordnungstabellen [00:21:50] Dritte Normalform und transitive Abhängigkeiten [00:23:49] Daten zu Interpret:innen in eine eigene Tabelle auslagern [00:25:25] 1:n-Beziehung zwischen Interpret:innen und CDs [00:26:38] Prüfungsrelevanz weiterer Normalformen [00:27:34] Referenzielle Integrität [00:29:04] Umgang mit Fremdschlüsselbeziehungen [00:29:26] Ungesicherte Referenzen unter der Bezeichnung No Action [00:30:25] Restrict: Löschen bei bestehenden Referenzen sperren [00:31:40] Cascade: abhängige Datensätze automatisch löschen [00:32:34] Set Null: Fremdschlüssel auf NULL setzen [00:33:41] Ausblick auf Datenbankmodellierung und SQL [00:34:30] Kontakt, Shownotes und Newsletter Inhalt Normalisierung Warum werden Datenbanken normalisiert? Vermeidung von Redundanzen, die zu Anomalien führen können. Welche Anomalien gibt es und was sind Beispiele dafür? Einfüge-, Änderungs- und Löschanomalie Normalformen Normalform: nur atomare Werte Normalform: 1. Normalform und alle Attribute sind voll funktional vom Primärschlüssel abhängig (hier werden die m:n-Beziehungen aufgelöst) Normalform: 2. Normalform und keine transitiven Abhängigkeiten (hier werden die 1:n-Beziehungen aufgelöst) Was bedeutet referentielle Integrität? Alle Fremdschlüssel zeigen auf gültige Datensätze. Welche technischen Maßnahmen zur Wahrung der referentiellen Integrität gibt es? No Action, Restrict, Cascade, Set Null Literaturempfehlungen *(direkt beim Rheinwerk-Verlag bestellen*) Das passende Kapitel im OpenBook: 12 Datenbanken - Rheinwerk Computing :: IT-Handbuch für Fachinformatiker Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Normalisierung (Datenbank) – Wikipedia mysql - Setting up table relations what do "Cascade", "Set Null" and "Restrict" do? - Stack Overflow Advanced MySQL - Referentielle Integrität - Fremdschlüssel - Referenzaktionen Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden! Zusammenfassung Warum Datenbanken normalisiert werden Wenn ich Kundendaten zusammen mit gekauften Artikeln in einer Tabelle speichere, stehen dieselben Kundeninformationen bei jedem Kauf erneut in einem Datensatz. Solche mehrfach abgelegten Daten heißen Redundanzen. Daraus können Anomalien entstehen, die durch das Normalisieren vermieden werden sollen: Einfügeanomalie: Du möchtest eine:n Kund:in anlegen, bevor eine Bestellung vorliegt. Sind die Artikeldaten in derselben Tabelle als Pflichtfelder definiert, lässt sich der Datensatz erst mit diesen Angaben speichern. Änderungsanomalie: Ändert sich der Nachname einer Person, müssen sämtliche Datensätze mit diesem Namen angepasst werden. Wird dabei ein Datensatz übersehen, enthält die Datenbank widersprüchliche Angaben. Löschanomalie: Beim Löschen eines Artikeldatensatzes verschwinden zugleich die darin gespeicherten Kundendaten. Hat die betreffende Person nur diesen Artikel gekauft, gehen ihre Daten vollständig verloren. Bewusst redundant gespeicherte Daten im Data-Warehouse Für ein Data-Warehouse kann ich Daten bewusst redundant ablegen, damit große Datenmengen schnell abgefragt werden können. Enthält eine Tabelle bereits die Kundendaten zusammen mit den Bestellungsdaten und den zugehörigen Artikeln, entfallen zusätzliche Joins für diese Informationen. Ein klassisches Data-Warehouse enthält häufig einen zeitlichen Ausschnitt aus der Produktionsdatenbank. Dieser sogenannte dispositive Datenstand dient dazu, Auswertungen durchzuführen. Wenn dadurch Abfragen schneller werden, kommt auch das gezielte Denormalisieren einer Datenbank infrage. Deine Antwort im Fachgespräch vorbereiten Bei einer offenen Frage zu Normalformen empfehle ich dir, zunächst die allgemeinen Definitionen zu nennen und anschließend ein Beispiel schrittweise durchzugehen. Daran kannst du auch Fremdschlüssel und Beziehungen zwischen Tabellen erläutern. Wähle möglichst eine Datenbank aus deinem Abschlussprojekt oder deinem Betrieb, mit der du vertraut bist. So kannst du gegenüber den Prüfer:innen begründen, warum bestimmte Daten auf diese Weise abgebildet wurden. Für die folgenden Schritte verwende ich eine CD-Datenbank aus dem Wikipedia-Artikel zum Normalisieren. Erste Normalform: atomare Werte Die erste Normalform verlangt, dass eine Tabelle ausschließlich atomare Werte enthält. Jeder Wert steht dabei für eine einzelne Information. Eine vollständig in einem Feld gespeicherte Adresse wird dafür auf passende Spalten verteilt, etwa eine eigene Spalte für die Postleitzahl und eine für den Ort. Dadurch lässt sich gezielt nach diesen Angaben suchen, ohne den gesamten Adresstext zerlegen zu müssen. Auch eine Liste gekaufter CD-IDs in einem einzelnen Feld enthält mehrere Werte. Im beschriebenen Beispiel entsteht deshalb für jede gekaufte CD eine eigene Zeile, die zunächst auch die Kundendaten erneut enthält. Jede Zelle enthält nun einen einzelnen Wert. Die wiederholten Kundendaten führen allerdings zu Redundanzen, die in weiteren Schritten bearbeitet werden. Zusätzliche Spalten wie CD1 oder CD2 würden bei weiteren Käufen Änderungen an der Tabellenstruktur erfordern. Bei Personen mit wenigen Käufen blieben außerdem viele dieser Felder leer. Zweite Normalform: abhängig vom gesamten Schlüssel Damit die zweite Normalform vorliegt, muss die erste erfüllt sein. Alle Nichtschlüsselattribute müssen vollständig funktional vom gesamten Primärschlüssel abhängen. In meinem CD-Beispiel enthält die Ausgangstabelle pro Zeile einen Track samt Albumdaten. Ein Datensatz wird durch die Kombination aus CD-ID und Track-ID eindeutig bestimmt. Der Albumtitel hängt dabei bereits von der CD-ID allein ab. Damit besteht eine Abhängigkeit von einem Teil des zusammengesetzten Schlüssels. Die Albumdaten werden deshalb in eine eigene Tabelle ausgelagert: Die Tabelle CD enthält die CD-ID und den Albumtitel sowie zunächst Angaben zur interpretierenden Person. Die Tabelle Track enthält die CD-ID als Fremdschlüssel, die Track-ID als weiteren Teil des Primärschlüssels und den Titel des Tracks. In der CD-Tabelle hängt der Albumtitel von der CD-ID ab. Der Track wird in der Track-Tabelle über die vollständige Kombination aus CD-ID und Track-ID bestimmt. Eine CD kann mehrere Titel enthalten, während derselbe Titel auf mehreren CDs erscheinen kann, etwa auf einem Best-of-Album. Diese m:n-Beziehung wird im Podcast im Zusammenhang mit der zweiten Normalform besprochen. Eine Zuordnungstabelle enthält die Schlüssel der beteiligten Datensätze. Dritte Normalform: transitive Abhängigkeiten auflösen Die dritte Normalform setzt die zweite voraus. Transitive Abhängigkeiten entstehen, wenn ein Nichtschlüsselattribut über ein weiteres Nichtschlüsselattribut vom Primärschlüssel abhängt. In der CD-Tabelle steht zunächst neben der interpretierenden Person auch deren Gründungsjahr. Dieses Jahr gehört zur Person beziehungsweise zur Band. Über diese Angabe hängt es mittelbar von der CD-ID ab. Ich lagere die entsprechenden Daten in eine eigene Tabelle aus. Daraus ergibt sich folgendes Modell: CD: CD-ID, Albumtitel und Interpret:innen-ID. Interpret:innen: Interpret:innen-ID, Name und Gründungsjahr. Track: CD-ID, Track-ID und Titel des Tracks. Das Gründungsjahr hängt damit direkt vom Schlüssel der Interpret:innen-Tabelle ab. Zwischen dieser Tabelle und der CD-Tabelle besteht im Beispiel eine 1:n-Beziehung: Eine interpretierende Person kann mehrere CDs veröffentlichen. Dabei gilt die Annahme, dass jede CD genau einer Person beziehungsweise Band zugeordnet ist. Alben mit mehreren beteiligten Künstler:innen sind in diesem Modell ausgeklammert. Für deine Prüfung empfehle ich dir, die ersten drei Normalformen anhand eines Beispiels erklären zu können. Weitere Formen wie die Boyce-Codd-Normalform werden erwähnt; in meinen bisherigen schriftlichen und mündlichen Prüfungen habe ich dazu keine Fragen erlebt. Referenzielle Integrität Wenn die Interpret:innen-ID einer CD auf einen vorhandenen Datensatz in der Interpret:innen-Tabelle verweist, lässt sich diese Beziehung korrekt auflösen. Referenzielle Integrität bedeutet, dass Fremdschlüssel auf gültige Datensätze zeigen. ...

In der siebzehnten Episode meines Anwendungsentwickler-Podcasts geht es um relationale Datenbanken und mögliche Fragen dazu im Fachgespräch. TL;DR Für dein Fachgespräch als IT-Azubi gehe ich häufige Fragen zu relationalen Datenbanken und verschiedenen NoSQL-Datenbanken durch. Du erfährst, wie Tabellen aufgebaut sind, welche Aufgaben Primärschlüssel und Fremdschlüssel haben und wie du Beziehungen über Kardinalitäten beschreibst. An Beispielen mit Bestellungen und Artikeln wird deutlich, wo Fremdschlüssel stehen und wann du eine Zwischentabelle brauchst. Ein objektrelationaler Mapper (ORM) verbindet die Tabellen mit den Objekten deiner Programmiersprache. Kapitelmarken [00:00:01] Informationen zum Fachgespräch [00:00:37] Datenbanken als Thema im Fachgespräch [00:01:30] Datenbankformen und ihre Prüfungsrelevanz [00:03:06] NoSQL in der Praxis und im Abschlussprojekt [00:04:47] Objektorientierte Datenbanken [00:05:44] Key-Value-Stores und das Warenkorb-Beispiel [00:06:29] Dokumentendatenbanken [00:07:50] Graphdatenbanken und Graphalgorithmen [00:09:39] Spaltenorientierte Datenbanken [00:11:19] NoSQL als Ergänzung relationaler Datenbanken [00:12:15] Aufbau relationaler Datenbanken [00:13:08] Mengenlehre und flexible SQL-Abfragen [00:14:20] Bekannte relationale Datenbanksysteme [00:15:25] Primärschlüssel und Fremdschlüssel [00:16:41] Natürliche und künstliche Schlüssel [00:18:10] Anonyme Schlüssel und sprechende Materialnummern [00:20:24] Kardinalitäten in beide Richtungen erklären [00:21:59] Beispiele für Beziehungen zwischen Tabellen [00:24:52] 1:n-Beziehungen mit Fremdschlüsseln umsetzen [00:26:49] Fremdschlüssel bei 1:1-Beziehungen [00:28:01] Zuordnungstabellen für m:n-Beziehungen [00:29:22] Objektrelationale Mapper [00:30:52] Ausblick auf weitere Datenbankthemen [00:31:23] Shownotes, Feedback und Kontakt [00:32:47] Newsletter und Checklisten Inhalt Datenbanken Welche Formen von Datenbanken gibt es? relationale, hierarchische, spaltenorientierte, objektorientierte Datenbanken, Key-Value-Stores, Dokumentendatenbanken, Graphendatenbanken Was ist NoSQL und wofür braucht man das? Steht für "Not only SQL". Fasst die "modernen" Datenbanken zusammen. Sinnvolle Ergänzung zu relationalen Datenbanken. Relationale Datenbanken Wie sind relationale Datenbanken aufgebaut? Tabellen (Relationen) und Beziehungen zwischen diesen. Was ist der Vorteil relationaler Datenbanken? Sie sind flexibel mit SQL abfragbar. Nennen Sie einige bekannte relationale Datenbanken. Oracle, Microsoft SQL Sever, MySQL, DB2, PostgreSQL, SQLite Was sind Primär- und Fremdschlüssel? Primärschlüssel identifizieren einen Datensatz eindeutig. Was sind natürliche und künstliche Schlüssel? Natürliche Schlüssel sind Attribute der Entitäten, die diese bereits eindeutig identifizieren. Künstliche Schlüssel werden zusätzlich für die Entität vergeben. Was sind anonyme Schlüssel? Schlüssel ohne Bedeutung (z.B. forlaufende Nummer im Vergleich zu Materialnummern wie "HO12CM0"). Welche Kardinalitäten gibt es und was sind Beispiele? 1:1 (Benutzer/Login), 1:n (Benutzer/Bestellung), m:n (Benutzer/Benutzergruppe) Wie werden die einzelnen Kardinalitäten (1:1, 1:n, m:n) in Tabellen umgesetzt? 1:1: Fremdschlüssel in beliebiger Tabelle, 1:n: Fremdschlüssel in n-Tabelle, m:n: Zwischentabelle für Fremdschlüssel Was ist ein ORM? Objekt-relationaler Mapper, verknüpft objektorientiere Programmierung mit der relationalen Datenbank. Literaturempfehlungen *(direkt beim Rheinwerk-Verlag bestellen*) Das passende Kapitel im OpenBook: 12 Datenbanken - Rheinwerk Computing :: IT-Handbuch für Fachinformatiker * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Zusammenfassung Datenbanken im Fachgespräch Für dein Fachgespräch empfehle ich dir, passende Beispiele aus deinem Abschlussprojekt vorzubereiten. Gerade bei Beziehungen zwischen Tabellen hilft es, wenn du ein konkretes Beispiel bereits durchdacht hast. Relationale Datenbanken und SQL gehören zu den Themen, die in den Prüfungen der IT-Berufe regelmäßig vorkommen. Auch aktuelle Datenbanktechnologien wie NoSQL können im Fachgespräch angesprochen werden. Welche Datenbankformen gibt es? Neben relationalen Datenbanken gibt es hierarchische Datenbanken sowie objektorientierte und spaltenorientierte Systeme. Hinzu kommen Key-Value-Stores, Dokumentendatenbanken und Graphdatenbanken. Unter NoSQL fasse ich folgende fünf Formen zusammen: Objektorientierte Datenbanken, beispielsweise db4o, speichern Objekte aus der objektorientierten Programmierung. Dabei können sie auch die Verweise zwischen Objekten abbilden. Das erleichtert es, Objekte dauerhaft abzulegen. Key-Value-Stores speichern Schlüssel-Wert-Paare und lassen sich als große Hashmap vorstellen. Sie sind auf schnelle Zugriffe ausgelegt. Als Beispiel kann ein kompletter Warenkorb unter einem Schlüssel gespeichert werden, sodass ein Zugriff seinen gesamten Inhalt liefert. Dokumentendatenbanken wie CouchDB oder MongoDB speichern Dokumente, häufig im JSON-Format. Durch ihren schemalosen Ansatz lassen sich Dokumente mit unterschiedlichen Attributen ablegen und durchsuchen. Das passt beispielsweise zu einem XML-Format, das in mehreren Varianten vorkommt. Graphdatenbanken wie Neo4j bilden Beziehungen durch Knoten und Kanten ab. Damit lassen sich etwa Kontakte in sozialen Netzwerken über mehrere Ebenen durchsuchen. Eigene Abfragesprachen und etablierte Graphalgorithmen helfen dabei, beispielsweise einen kürzesten Weg zu finden. Spaltenorientierte Datenbanken legen die Werte einer Spalte zusammenhängend ab. Wenn eine Abfrage nur bestimmte Spalten auswertet, muss dadurch ein kleinerer Datenbereich gelesen werden. Das ist etwa für Data-Warehouse-Anwendungen und große Datenmengen relevant. Als Vertreter nenne ich Apache Cassandra. Die verbreitete Lesart "Not Only SQL" beschreibt, wie sich solche Systeme mit relationalen Datenbanken kombinieren lassen. Ein Key-Value-Store kann beispielsweise einen Warenkorb zwischenspeichern. Für Analysen können Daten aus einer relationalen Datenbank in ein spaltenorientiertes System übertragen werden. Wie sind relationale Datenbanken aufgebaut? In Tabellen, auch Relationen genannt, stehen die Datensätze zeilenweise. Die Spalten beschreiben ihre Attribute. Eine Personentabelle kann etwa Namen und Adresse enthalten. Zwischen den Tabellen bestehen Beziehungen. Die mathematische Grundlage stammt aus der Mengenlehre, für die seit Langem etablierte Algorithmen existieren. Mit SQL lassen sich flexible Abfragen formulieren, auch wenn diese beim Entwurf der Datenbank noch nicht vorgesehen waren. So kannst du verschiedene Bedingungen zu einer Suche kombinieren. Zu den bekannten relationalen Datenbanksystemen gehören Oracle, Microsoft SQL Server, IBM Db2, MySQL, PostgreSQL und SQLite. Welche Aufgaben haben Schlüssel? Ein Primärschlüssel identifiziert einen Datensatz innerhalb einer Tabelle eindeutig. Ein Fremdschlüssel verweist auf einen Datensatz in einer bestimmten Tabelle. Der Verweis kann auch innerhalb derselben Tabelle liegen. Wenn in meiner Personentabelle die Berufs-ID 3 steht, verweist sie auf den entsprechenden Beruf in der Berufstabelle. Dort identifiziert die 3 beispielsweise den Datensatz "Softwareentwickler:in". In der Personentabelle ist diese ID der Fremdschlüssel; in der Berufstabelle dient sie als Primärschlüssel. Natürliche und künstliche Schlüssel Ein natürlicher Schlüssel ergibt sich aus vorhandenen Attributen, sofern diese im jeweiligen Datenmodell eindeutig sind. Eine ISBN kann dafür ein Beispiel sein. Bei einem künstlichen Schlüssel wird ein zusätzlicher Wert vergeben. Häufig ist das eine fortlaufende Zahl, die beim Einfügen eines Datensatzes erhöht wird. Anonyme Schlüssel Ein anonymer Schlüssel trägt keine fachliche Bedeutung. Eine fortlaufende ID eignet sich dafür. Eine Materialnummer kann dagegen Angaben über das Material oder seine Stärke enthalten. Für Beziehungen zwischen Tabellen empfehle ich dir anonyme Schlüssel. Wenn sich die Bedeutung einer sprechenden Materialnummer ändert, müssten sonst auch die Schlüssel und ihre Verweise angepasst werden. Eine Materialnummer kannst du als zusätzliches Attribut speichern, damit ein:e Sachbearbeiter:in damit arbeiten kann. Wie beschreibst du Kardinalitäten? Bei einer Beziehung gibst du an, wie viele Datensätze einander zugeordnet sind. Beschreibe dabei immer beide Richtungen. | Kardinalität | Beziehung und Beispiel | | --- | --- | | 1:1 | Ein Datensatz aus Tabelle A gehört genau zu einem Datensatz aus Tabelle B und umgekehrt. Ein Beispiel sind Benutzer:innendaten und Login-Daten, wenn jede:r Benutzer:in genau einen Login hat und jeder Login genau einer Person gehört. | | 1:n | Einem Datensatz aus Tabelle A können mehrere Datensätze aus Tabelle B zugeordnet sein. Jeder dieser Datensätze aus B gehört zu einem Datensatz aus A. Beispielsweise kann ein:e Kund:in mehrere Bestellungen aufgeben, während jede Bestellung genau einer Person zugeordnet ist. | | m:n | Auf beiden Seiten können mehrere Datensätze miteinander verbunden sein. Eine Bestellung kann mehrere Artikel enthalten; derselbe Artikel kann in mehreren Bestellungen vorkommen. | Wenn Benutzer:innendaten und Login-Daten in getrennten Tabellen stehen, lassen sich Zugriffsrechte gezielt vergeben. Ein:e Administrator:in, der/die ein Passwort zurücksetzt, braucht beispielsweise keinen Zugriff auf Gehaltsdaten. Für ein:e Sachbearbeiter:in, der/die Gehaltsdaten bearbeitet, können die Login-Daten gesperrt bleiben. Wie setzt du diese Beziehungen um? Über Fremdschlüssel verknüpfst du die Tabellen miteinander: Bei 1:n steht der Fremdschlüssel auf der n-Seite. In der Bestellungstabelle wird also die ID der zugehörigen Person gespeichert. Deren Bestellungen findest du anschließend über diese ID. Mehrere Bestell-IDs in einem einzelnen Feld der Personentabelle würden die erste Normalform verletzen. Bei 1:1 kann der Fremdschlüssel grundsätzlich auf beiden Seiten stehen....

In der siebten Episode meines Anwendungsentwickler-Podcasts geht es um häufige (aber vermeidbare) Fehler in der Projektpräsentation. Ich gebe 11 Praxisbeispiele für Fehler in der Projektpräsentation und wie Prüflinge es besser machen können. TL;DR Aus meinen Erfahrungen als Prüfer zeige ich dir elf häufige Fehler bei der Projektpräsentation und wie du sie vermeidest. Damit dein Projekt auch ohne Vorwissen verständlich wird, gehören die technische Umsetzung und die wirtschaftlichen Ergebnisse in deinen Vortrag, wobei deine Eigenleistung klar erkennbar sein muss. Halte die Unternehmensvorstellung kurz und stelle fachliche Inhalte mit passenden Diagrammen dar. Durch wiederholtes Üben unter Prüfungsbedingungen bereitest du dich darauf vor, verständlich zu sprechen und die vorgesehenen 15 Minuten einzuhalten. Kapitelmarken [00:00:00] Einstieg zur Projektpräsentation [00:00:35] Anlass und Überblick über die elf häufigsten Fehler [00:01:55] Fehler 1: Das Ausbildungsunternehmen zu ausführlich vorstellen [00:03:45] Fehler 2: Fachbegriffe verwenden, die du kaum erklären kannst [00:05:52] Fehler 3: Zu viel Text auf den Folien [00:07:38] Fehler 4: Den Vortrag zu wenig üben [00:09:03] Fehler 5: Die vorgesehenen 15 Minuten verfehlen [00:10:56] Fehler 6: Wichtige Angaben zum Projekt auslassen [00:12:35] Fehler 7: Die Wirtschaftlichkeit auslassen [00:14:16] Fehler 8: Die technische Umsetzung kaum zeigen [00:15:38] Fehler 9: Das methodische Vorgehen auslassen [00:17:10] Fehler 10: Das gesamte Projekt bleibt unklar [00:18:25] Fehler 11: Der eigene Anteil bleibt unklar [00:20:20] Abschluss und Wünsche für die Prüfung [00:20:50] Shownotes und weiterführende Links [00:21:03] Feedback und Fragen zum Podcast Inhalt Die Vorstellung des Ausbildungsunternehmens ist zu lang und umfangreich. Es werden Fachbegriffe verwendet, ohne sie zu kennen. Praxisbeispiel: "XP" -> "Programmieren ohne Regeln". Prüfling weist in Präsentation explizit auf MVC hin und kann Fragen dazu im Fachgespräch nicht beantworten. Es wird zu viel Text auf die Folien geschrieben. Anstatt aussagekräftige Diagramme oder andere Visualisierungen zu nutzen. Der Vortrag wurde nicht perfekt eingeübt. Folienübergänge sind stockend oder es werden Inhalte vergessen und später ergänzt. Bei so einer wichtigen (und auch noch sehr kurzen) Präsentation ist mehrfaches Üben Pflicht. Die Zeitvorgabe von 15 Minuten wird nicht eingehalten. Abweichung von 3 Minuten sind schon 20% der Gesamtzeit. Zu kurz: Verfügbare Möglichkeiten nicht ausgenutzt. Meist fehlen wichtige Inhalte. Zu lang: Priorisierung des Prüflings mangelhaft. Häufig viel uninteressantes "Gelaber". Wichtige Informationen zum Projekt werden nicht erwähnt. Zum Beispiel die verwendete Programmiersprache. Nicht alle Prüfer im Ausschuss kennen die Dokumentation! Es wird keine Wirtschaftlichkeitsbetrachtung vorgestellt. Sie ist ein wichtiger Bestandteil jeder Projektpräsentation! Es werden keine technischen Details gezeigt. Wird anscheinend in einigen Unternehmen so gelehrt. Stimmt aber überhaupt nicht. Es werden keine angewendeten Methoden gezeigt. Der Prüfling muss zeigen, dass er methodisch vorgegangen ist und nicht einfach "irgendwie" entwickelt hat. Das Projektziel wird nicht deutlich. Das zentrale Thema des Projekts wird nicht klar herausgestellt. Was wurde eigentlich umgesetzt? Der Eigenanteil des Prüflings wird nicht deutlich. Hat der Prüfling überhaupt etwas Anspruchsvolles umgesetzt? Ich kann nur allen Prüflingen empfehlen, sich einmal näher mit "Presentation Zen" auseinanderzusetzen. Hier ist ein tolles (und kurzes) Video von Garr Reynolds zum Thema: Ein schönes Beispiel für eine in Anlehnung an Presentation Zen gestaltete Projektpräsentation gibt es hier: Literaturempfehlungen Nachfolgend einige sehr gute Literaturempfehlungen zur Präsentationsgestaltung. Ich habe alle Bücher selbst gelesen und kann sie absolut empfehlen. "Presentation Zen" ist mehr eine allgemeine Einführung ins Thema als eine Sammlung konkreter Tipps. Die anderen Bücher enthalten aber von der Farbgestaltung und Typographie über das Layout bis hin zum Einsatz von Bildern direkt umsetzbare Hinweise zur besseren Foliengestaltung. * * * * * * * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Mein Vortrag zum Thema "Tod durch PowerPoint" (mit Handout zum Thema Präsentationsgestaltung) Projektpräsentation von Gerda Feldhaus (mit 100% bewertet) (als positives Beispiel) Abschlusspräsentation im Stil von Presentation Zen (Diskussion bei fachinformatiker.de) Weitere Infos zur ProjektpräsentationDu suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.Jetzt anmelden! Zusammenfassung Elf häufige Fehler bei der Projektpräsentation Aus meinen Erfahrungen als Prüfer gebe ich dir Hinweise, wie du als IT-Azubi deine Projektpräsentation vorbereitest. Die Beispiele stammen aus Prüfungen zum/zur Fachinformatiker:in; die Aufnahme entstand im April 2015 und bezieht sich auf einen Vortrag von 15 Minuten. 1. Das Ausbildungsunternehmen zu ausführlich vorstellen Für das Unternehmen empfehle ich dir ein bis zwei Folien, auf denen du das Umfeld deines Projekts beschreibst. Eine ausführliche Unternehmensgeschichte oder sämtliche Standorte nehmen Zeit in Anspruch, die du für deine eigene Arbeit brauchst. Bei einer Unternehmensvorstellung von drei Minuten ist bereits ein Fünftel deiner Vortragszeit vergangen. 2. Fachbegriffe verwenden, die du kaum erklären kannst Wenn du einen Fachbegriff erwähnst, solltest du ihn verstehen und Fragen dazu beantworten können. Mit den Begriffen aus deinem Vortrag beeinflusst du, welche Themen die Prüfer:innen im Fachgespräch aufgreifen. In einer meiner Prüfungen kündigte ein:e Prüfungsteilnehmer:in ausdrücklich Fragen zum verwendeten MVC-Muster an, konnte anschließend aber kaum mehr als die Abkürzung erklären. Bei einem anderen Projekt wurde Extreme Programming als regelloses Programmieren beschrieben. Zu diesem Konzept gehören festgelegte Praktiken und Werte, mit denen du dich vor einer solchen Aussage beschäftigen musst. 3. Zu viel Text auf die Folien schreiben Durch passende Diagramme kannst du fachliche Zusammenhänge anschaulich zeigen. Für eine Datenbank eignet sich beispielsweise ein ER-Modell; Klassen und ihre Beziehungen lassen sich in einem Klassendiagramm darstellen. Auch ein Use-Case-Diagramm kann Inhalte deines Projekts verständlich machen. Beschränke den Text auf deinen Folien, damit die Prüfer:innen deinem Vortrag folgen können. Umfangreiche Texte vorzulesen beansprucht einen großen Teil der verfügbaren Zeit. Wähle Grafiken passend zum Inhalt und halte die Folien frei von überflüssigen Animationen. 4. Den Vortrag zu wenig üben Ich empfehle dir, deinen Vortrag zehn bis zwanzig Mal laut zu halten. Stell dich dafür mit einem Presenter in einen Raum und arbeite möglichst mit einem Beamer, damit du unter ähnlichen Bedingungen wie in der Prüfung übst. Dabei kannst du prüfen, ob die Grafiken lesbar sind und die Folienübergänge passen. Wenn du den Ablauf gut kennst, sinkt das Risiko, durch Nervosität den Faden zu verlieren. Miss beim Üben auch die Zeit. 5. Die vorgesehenen 15 Minuten verfehlen Richte deine Inhalte auf die vorgegebene Dauer aus. Schon drei Minuten Abweichung entsprechen bei diesem Zeitrahmen 20 Prozent. Wenn dein Vortrag deutlich früher endet, bleibt Zeit für bewertbare Inhalte unbesetzt. Du könntest darin beispielsweise ein relevantes Quelltextbeispiel erläutern. Bei einem zu langen Vortrag stellt sich die Frage, ob du deine Inhalte angemessen gewichtet hast. Durch wiederholte Probeläufe findest du heraus, welche Inhalte in die 15 Minuten passen. 6. Wichtige Angaben zum Projekt auslassen Gehe davon aus, dass einzelne Prüfer:innen deine Dokumentation noch nicht gelesen haben. In vielen Prüfungsausschüssen wird das Lesen der Dokumentationen aufgeteilt, sodass dein Vortrag eigenständig verständlich sein muss. Beschreibe das Problem, das du bearbeitet hast, und erläutere dein Ergebnis. Zur technischen Einordnung gehören die verwendete Programmiersprache sowie die Architektur und gegebenenfalls eingesetzte Frameworks. Die Prüfer:innen bringen technisches Fachwissen mit, brauchen aber die konkreten Angaben zu deinem Projekt. 7. Die Wirtschaftlichkeit auslassen Als Fachinformatiker:in arbeitest du in einem Beruf mit wirtschaftlichem Bezug. Zeige deshalb, welche Kosten dein Projekt verursacht hat und wie du diese berechnet hast. Erläutere auch die erwarteten Einsparungen und wann sich die Kosten dadurch ausgleichen. Dafür können zwei bis drei Folien ausreichen. Deine Berechnungen müssen nachvollziehbar machen, weshalb sich das Projekt für das Unternehmen lohnt. 8. Die technische Umsetzung kaum zeigen Zur Prüfung in der Anwendungsentwicklung gehört, dass du deine technische Arbeit sichtbar machst. Beschreibe, wie die Software aufgebaut ist und wie du sie umgesetzt hast. Mit UML-Diagrammen oder einem ER-Modell kannst du passende Ausschnitte zeigen. Auch Ablaufdiagramme kommen dafür infrage. Die Prüfer:innen sollen erkennen können, welche technischen Aufgaben du bearbeitet hast. 9. Das methodische Vorgehen auslassen Zeige anhand deines Projekts, wie du Software systematisch entwickelst und dabei Qualität sicherst. Dazu gehören beispielsweise dein Projektplan und die Analysephase. Für die fachlichen Schritte kannst du eine objektorientierte Analyse erläutern oder zeigen, wie du beim Datenbankentwurf normalisiert hast. Mit einem passenden Diagramm wird sichtbar, dass du Methoden aus der Ausbildung auf ein Praxisprojekt übertragen kannst. 10....