160 Folgen

Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer im Beruf Fachinformatiker für Anwendungsentwicklung. Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles was sonst noch mit dem Beruf des Anwendungsentwicklers zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer und alle, die Interesse an der Softwareentwicklung haben, ist bestimmt etwas Interessantes dabei!



http://anwendungsentwicklerpodcast.de

Anwendungsentwickler-Podcast Stefan Macke

    • Technologie

Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer im Beruf Fachinformatiker für Anwendungsentwicklung. Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles was sonst noch mit dem Beruf des Anwendungsentwicklers zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer und alle, die Interesse an der Softwareentwicklung haben, ist bestimmt etwas Interessantes dabei!



http://anwendungsentwicklerpodcast.de

    Praktikumsinhalte in der IT-Abteilung – Anwendungsentwickler-Podcast #149

    Praktikumsinhalte in der IT-Abteilung – Anwendungsentwickler-Podcast #149

    um Ideen für Inhalte von Praktika im IT-Bereich geht es in der einhundertneunundvierzigsten Episode des Anwendungsentwickler-Podcasts.



    Inhalt



    * Warum sind Praktika für Ausbildungsunternehmen wichtig?



    * Praktikanten werden ggfs. direkt zu Bewerbern auf die Ausbildung.

    * Unter Schülern spricht sich ein gutes Praktikum herum. Das bedeutet kostenfreie Werbung für die Ausbildung.

    * Das Unternehmen bekommt Input von außen zur Attraktivität der Ausbildung und des Unternehmens.

    * Die eigenen Azubis lernen durch das Lehren ihre Ausbildungsinhalte besser.







    Tipps für die konkrete Umsetzung



    * Die Azubis sollten die komplette Betreuung des Praktikanten übernehmen.

    * Das Praktikum kann wie ein echtes Projekt geplant und durchgeführt werden (z.B. im Ticketsystem).

    * Dazu zählen auch organisatorische Dinge wie die Datenschutzerklärung, das Einrichten eines Windows-Benutzers, Anfordern einer Bezahlkarte usw.

    * Der Praktikant sollte einen realistischen Einblick in den Ablauf der Ausbildung erhalten und keine „heile Welt“ präsentiert bekommen.



    Mögliche Praktikumsinhalte



    * Der Umfang hängt von der Dauer des Praktikums ab. In zwei Wochen kann man natürlich tiefer in die Programmierung einsteigen als in einer.

    * Die Inhalte sollten an die Vorkenntnisse und das Alter des Praktikanten angepasst werden. Ein Schulpraktikum in der 9. Klasse bietet sich z.B. weniger für Hardcore-Programmierung an.

    * Die nötigen Praktikumsartefakte (z.B. Praktikumsbericht, -präsentation) sollten in den Praktikumsalltag integriert werden. Fotos können z.B. direkt während der Arbeit gemacht werden.



    Allgemeiner Einstieg ins Praktikum



    * Begrüßung durch Ausbildungsleiter und betreuende(n) Azubi(s)

    * Organisatorische/rechtliche Rahmenbedingungen klären (z.B. Arbeitszeiten, Verhalten bei Krankheit)

    * Rundgang durch



    * das Unternehmen (z.B. Kantine, Serverraum, Besprechungsräume, Schulungsraum)

    * die Abteilung (z.B. nächstes WC, Kaffeeküche)





    * Vorstellungsrunde mit allen Azubis



    Technische Inhalte (Was lernt man in der Ausbildung?)



    * Eigenen Arbeitsplatz aufbauen



    * Monitor, Tastatur usw. verkabeln

    * eigenes Passwort ändern

    * ggfs. Software installieren





    * PC auseinander-/zusammenbauen

    * Eigenen Steckbrief mit HTML/CSS gestalten

    * Einstieg in die Programmierung, z.B. mit dem Calliope Mini*

    * RaspberryPi* aufsetzen (z.B. RetroPi)

    * Tieferer Einstieg in eine Programmiersprache

    * Windows-/Linux-Server aufsetzen (VMs)

    * Blogartikel/Instagram-Post für die eigene Azubi-Website schreiben

    * Praktikumsmappe/-präsentation vorbereiten (insb. Fotos)



    Organisatorische Inhalte (Wie läuft der Arbeitsalltag ab?)



    * Teilnahme an allen anfallenden Meetings (z.B. Abteilungsbesprechung, Projektplanung, Standup)

    * Lernzielkontrollen mit anderen Azubis gemeinsam durchführen

    * Pair-Programming mit Azubis durchführen, um echte Projekte kennenzulernen

    * Vier-Augen-Gespräch mit Ausbi...

    • 1 Std. 1 Min.
    Handelskalkulation, Skonto und Rabatt – Häufige Fragen im Fachgespräch – Anwendungsentwickler-Podcast #148

    Handelskalkulation, Skonto und Rabatt – Häufige Fragen im Fachgespräch – Anwendungsentwickler-Podcast #148

    Um die Handelskalkulation inkl. Skonto und Rabatt geht es in der einhundertachtundvierzigsten Episode des Anwendungsentwickler-Podcasts.



    Inhalt



    * Käufer zahlen immer so spät wie möglich ihre Rechnungen, da sie in der Zwischenzeit mit ihrem Geld andere Dinge machen können (z.B. verzinslich anlegen).

    * Verkäufer wollen das Geld aber so früh wie möglich haben, da sie bereits in Vorleistung gegangen sind.

    * Ein übliches Zahlungsziel bei Rechnungen ist 30 Tage. Das würde ein Käufer immer ausnutzen.

    * Damit der Käufer schneller zahlt, kann der Verkäufer Skonto gewähren, wenn z.B. bereits bis zum 10. Tag gezahlt wird. Übliche Skontosätze sind 2% oder 3%.

    * Ein Rabatt ist ein allgemeiner Preisnachlass des Verkäufers.

    * Käufer ziehen sich Rabatt und Skonto (in dieser Reihenfolge) vom ihnen angebotenen Preis ab („vom Hundert“).



    * Beispiel: PC kostet 1.000 EUR. 10% Rabatt ergeben einen Abzug von 100 EUR.





    * Verkäufer müssen Skonto und Rabatt (in dieser Reihenfolge) auf ihre Preise aufschlagen („im Hundert“), damit sie nicht zu ihren Ungunsten abgezogen werden. Die Basis 100% ist dabei der zu errechnende Preis und nicht der, auf den aufgeschlagen wird.



    * Beispiel: PC soll für 1.000 EUR verkauft werden. Der Kunde soll 10% Rabatt abziehen können dürfen. 1.000 EUR entsprechen dabei 90%, der gesuchte Zielpreis 100%. Mittels Dreisatz ergibt sich ein Preis von 1.111,11 EUR (und nicht etwa 1.100 EUR!). 10% Abzug von 1.111,11 EUR sind 111,11 EUR, sodass der ursprünglich gewünschte Preis von 1.000 EUR beim Händler landet.







    Handelskalkulation



    * Mittels der Handelskalkulation berechnen Handelsunternehmen ihre Verkaufspreise auf Basis der Einkaufspreise bei ihren Lieferanten.

    * In produzierenden Unternehmen oder bei Dienstleistern wird ggfs. anders kalkuliert, z.B. mittels des Betriebsabrechnungsbogens bzw. eines Stundensatzes.



    So sieht eine vollständige Handelskalkulation aus:

       Listeneinkaufspreis (steht beim Lieferanten auf dem Preisschild)

    − Lieferantenrabatt (handelt ein vernünftiger Kunde vom Preis runter)

    = Zieleinkaufspreis (müsste der Kunde bei Zahlung auf Rechnung am 30. Tag überweisen)

    − Lieferantenskonto (zieht der Kunde ab, wenn er schneller zahlt, z.B. bis zum 10. Tag)

    = Bareinkaufspreis (müsste der Kunde „bar“ auf den Tisch legen, um das Produkt mitzunehmen)

    + Bezugskosten (ggfs. Porto, Spedition)

    = Bezugspreis (zahlt der Kunde, damit das Produkt „bei ihm auf dem Hof“ steht)

    + Handlungskosten (alle Kosten für den Geschäftsbetrieb, z.B. Miete, Strom, Gehälter usw.)

    + Lagerzins (falls Waren eingelagert werden müssen)

    = Selbstkostenpreis (hiermit sind alls Kosten des Händlers abgedeckt)

    + Gewinn (das bleibt am Ende dem Händler übrig)

    = Barverkaufspreis (das müsste der Kunde bar bezahlen, um alle Kosten + Gewinn des Händlers zu decken)

    + Kundenskonto (im Hundert) (zieht der Kunde sich vom nächsten Preis ab)

    + Provision (im Hundert) (bekommt ggfs. ein Handelsvertreter von uns)

    = Zielverkaufspreis (müsste der Kunde zahlen, wenn er auf Rechnung kauft)

    + Kundenrabatt (im Hundert) (handelt der Käufer runter)

    = Listenverkaufspreis (auch Nettoverkaufspreis)

    + Umsatzsteuer (geht abzgl. der Vorsteuer ans Finanzamt)

    = Bruttoverkaufspreis (schreibt der Händler auf sein Preisschild)

    Links



    * Permalink zu dieser Podcast-Episode...

    • 46 Min.
    Code Smells und Refactorings – Anwendungsentwickler-Podcast #147

    Code Smells und Refactorings – Anwendungsentwickler-Podcast #147

    Um Code Smells und ihre Behebung mittels Refactorings geht es in der einhundertsiebenundvierzigsten Episode des Anwendungsentwickler-Podcasts.



    Inhalt



    * Was ist ein Code Smell?



    * Smells sind Indikatoren für Code, der überarbeitungswürdig ist.

    * Man erkennt sie anhand verschiedener Muster (z.B. lange Methoden).

    * Die Smells können mit Refactorings überarbeitet und (hoffentlich) eliminiert werden.

    * Nicht alle Smells sind immer schlecht. Sie dienen nur als Anhaltspunkt, noch einmal über den Code nachzudenken.





    * Woher kommt der Name Code Smell?



    * Kent Becks Oma wird das Zitat „If it stinks, change it.“ zugesprochen, das sich auf das Wechseln von Windeln bei Babys bezieht.

    * Kent Beck hat diese Idee auf Code übertragen: Wenn der Code seltsam „riecht“, sollte man ihn anpassen.





    * Wobei helfen uns Code Smells?



    * Mit Code Smells können wir Stellen im Code aufdecken, die problematisch sind, und diese überarbeiten. Dadurch wird der gesamte Code insgesamt „besser“.

    * Die benannten Smells helfen uns durch eine gemeinsame Sprache bei der Diskussion mit anderen Entwicklern (ähnlich wie Design Pattern).





    * Was können wir gegen Code Smells tun?



    * Das Mittel gegen Code Smells sind die Refactorings.

    * Im Buch von Martin Fowler* gibt es eine übersichtliche Tabelle, welche Refactorings gegen welche Smells helfen können.





    * Sind Code Smells immer böse?



    * Code Smells sind nur ein Anhaltspunkt für Optimierungen. Der Entwickler muss selbst entscheiden, ob der Smell schlecht ist.

    * Einige Code Smells hängen zusammen und das Auflösen des einen (z.B. Introduce Parameter Object) führt zur Einführung eines anderen (z.B. Data Class).





    * Welche Code Smells gibt es?



    * Duplicate Code



    * Doppelter Code führt bei Änderungen schnell zu Fehlern, weil zu ändernde Stellen übersehen werden.

    * Refactorings: Extract Method, Pull Up Method





    * Comments



    * Kommentare können helfen, den Code zu verstehen, aber häufig sind sie überflüssig und können durch sprechendere Bezeichner komplett eliminiert werden.

    * Refactorings: Extract Method, Rename Method





    * Long Method



    * Lange Methoden sind schwieriger zu verstehen, zu testen und anzupassen.

    * Refactorings: Extract Method





    * Large Class



    * Zu große Klassen machen häufig mehr als sie sollen und verletzen das Single Responsibility Principle. Das macht sie u.a. schwer testbar.

    * Refactorings: Extract Class, Extract Subclass





    * Long Parameter List



    * Viele Parameter bei Methoden deuten darauf hin, dass diese zu viele Aufgaben übernehmen. Sie machen die Methoden schwer testbar und schwer verständlich. Außerdem müssen die Parameterlisten tendenziell oft angepasst werden.

    * Refactorings: Replace Parameter with Method, Introduce Parameter Object





    * Feature Envy



    * Wenn Methoden oder Klassen sich viele Informationen „besorgen“ müssen, bevor sie ihren Job machen können, ist das ein Zeichen dafür, dass die Komponenten besser an einer anderen Stelle aufgehoben wären.

    * Refactorings: Move Method





    * Data Clumps



    * Wenn verschiedene Daten immer zusammen herumgereicht werden (z.B. Startdatum und Endedatum), ist das ein Zeichen für eine fehlende Abstraktion (z.B. Zeitraum).

    * Refactorings: Introduce Parameter Object, Extract Class

    • 55 Min.
    Kryptographie – Funktionsweise von HTTPS – Anwendungsentwickler-Podcast #146

    Kryptographie – Funktionsweise von HTTPS – Anwendungsentwickler-Podcast #146

    Zum Abschluss meiner kleinen Reihe zum Oberthema Kryptographie widmen wir uns der Funktionsweise von HTTPS in der einhundersechsundvierzigsten Episode des Anwendungsentwickler-Podcasts.



    Inhalt



    * Wiederholung



    * Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.

    * Um die Authentizität öffentlicher Schlüssel zu gewährleisten, werden Zertifikate verwendet, die von vertrauenswürdigen Zertifizierungsstellen ausgegeben werden.





    * Probleme



    * Wie können wir bei Millionen verschiedenen Websites sicherstellen, dass sie korrekte Schlüssel nutzen, ohne dass wir alle Websitebetreiber persönlich kennen müssen?

    * Wie kann bei den großen Datenmengen im Internet eine performante Verschlüsselung gewährleistet werden?





    * HTTPS



    * Um mit einem Webserver verschlüsselt kommunizieren zu können, benötigt der Webbrowser den öffentlichen Schlüssel des Webservers.

    * Diesen kann er einfach direkt vom Webserver selbst herunterladen. Aber wer garantiert ihm die Echtheit dieses Schlüssels? Vielleicht wurde der Server gehackt oder der private Schlüssel gestolen.

    * Deswegen liefert der Webserver nicht direkt den öffentlichen Schlüssel aus, sondern ein von einer CA ausgestelltes Zertifikat, das den öffentlichen Schlüssel des Webservers enthält, aber zusätzlich noch die Signatur der CA, die dessen Echtheit bestätigt.

    * Wenn dieses Zertifikat gültig ist (die Prüfung erfolgt gegen die „eingebauten“ CAs im Browser), weiß der Browser sicher, dass er den korrekten Schlüssel erhalten hat und kann ihn für die Verschlüsselung nutzen.



    * Dabei prüft der Browser auch, ob das Zertifikat zur aktuellen Domain gehört. Der CN enthält bei HTTPS-Zertifikaten diese Domain.

    * Es gibt seit einiger Zeit auch eine kostenlose CA: Let’s Encrypt. Damit kann sich jeder Webserverbetreiber gültige Zertifikate erzeugen, indem er technisch nachweist, dass die Domain und der Server wirklich ihm gehören.



    * Der Datenverkehr wird bei HTTPS symmetrisch verschlüsselt, da die Schlüssellängen hierbei deutlich kürzer sind, was deutliche Performancevorteile hat. Um diesen Schlüssel zwischen Browser und Webserver auszutauschen wird das obige asymmetrische Verfahren genutzt. Deswegen ist HTTPS ein hybrides Verfahren.





    * Technischer Ablauf



    * CA



    * CA generiert privaten und öffentlichen Schlüssel.

    * CA erstellt selbstsigniertes Root-Zertifikat: ihr eigener öffentlicher Schlüssel signiert mit ihrem privaten Schlüssel.

    * CA-Root-Zertifikat wird in Browser eingebaut.





    * Webserver



    * Webserver generiert privaten und öffentlichen Schlüssel.

    * Webserver lässt öffentlichen Schlüssel von CA mit ihrem privaten Schlüssel signieren.

    * Webserver installiert dieses Zertifikat und konfiguriert HTTPS.





    * Browser



    * Browser öffnet Website auf dem Webserver.

    * Webserver liefert sein Zertifikat aus.

    * Browser prüft das Zertifikat mit dem öffentlichem Schlüssel der CA aus seinem eingebautem Root-Zertifikat und erhält den öffentlichen Schlüssel des Webservers.

    * Browser generiert einen zufälligen temporären Sitzungsschlüssel und verschlüsselt ihn mit dem öffentlichen Schlüssel des Webservers.

    * Browser sendet den verschlüsselten Sitzungsschlüssel an den Webserver, der ihn mit seinem privaten Schlüssel entschlüsselt.

    * Nun kennen Browser und Webserver den Sitzungsschlüssel und können damit symmetrisch den Datenverkehr verschlüsseln.









    * Mögliche Probleme mit HTTPS-Zertifikaten



    * Das Zertifikat ist abgelaufen.

    * Das Zertifikat passt nicht zur Domain.

    * Das Zertifikat wurde von einer nicht vertrauenswürdigen CA ausgestellt.

    • 39 Min.
    Kryptographie – Zertifikate und Zertifizierungsstellen – Anwendungsentwickler-Podcast #145

    Kryptographie – Zertifikate und Zertifizierungsstellen – Anwendungsentwickler-Podcast #145

    Die Fortsetzung zum Oberthema Kryptographie mit Zertifikaten und Zertifizierungsstellen gibt es in der einhunderfünfundvierzigsten Episode des Anwendungsentwickler-Podcasts.



    Inhalt



    * Wiederholung: Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.

    * Probleme



    * Wer garantiert dem Absender, dass ein öffentlicher Schlüssel auch wirklich dem angegebenen Empfänger gehört?

    * Wie kann sichergestellt werden, dass ein öffentlicher Schlüssel nicht von einem Angreifer durch seinen eigenen ausgetauscht wurde?





    * Zertifikat



    * Mit einem Zertifikat bestätigt eine unabhängige dritte Partei die Echtheit des öffentlichen Schlüssels des Empfängers. Diese dritte Partei wird Zertifizierungsstelle genannt.

    * Die Zertifizierungsstelle (englisch Certificate Authority, abgekürzt CA) bestätigt die Authentizität des Schlüssels des Empfängers, indem sie z.B. dessen Adresse und Identität prüft.

    * Das kostet meistens Geld, je nachdem wie intensiv diese Prüfung gemacht wird. Das geht von „muss eine E-Mail-Adresse mit dieser Domain abrufen können“ bis hin zu „das Unternehmen existiert tatsächlich unter der postalischen Adresse“.

    * Wenn Alice statt dem öffentlichen Schlüssel von Bob ein Zertifikat erhält, kann sie es wiederum mit dem Zertifikat der CA prüfen. Sie weiß nun sicher, dass sie den korrekten öffentlichen Schlüssel nutzt und nicht einen kompromittierten.

    * Alice muss dafür allerdings dem Zertifikat der Zertifizierungsstelle selbst vertrauen, da auch diese kompromittiert werden kann. Es entsteht also eine Vertrauenskette, die irgendwo in einem Root-Zertifikat endet. Und diesem Zertifikat muss manuell vertraut werden.

    * Das „Urvertrauen“ in die verschiedenen CAs wird hergestellt, indem sie z.B. in Browser wie Firefox oder Chrome vom Hersteller fest „eingebaut“ und als vertrauenswürdig gekennzeichnet werden.

    * Sollte ein Zertifikat kompromittiert werden, gibt es sog. Certificate Revocation Lists (CRL), in die die nicht mehr validen Zertifikate eingetragen werden können. Dafür müssen diese Listen aber natürlich bei jeder Prüfung eines Zertifikats kontrolliert werden, was sehr aufwändig ist.





    * Technische Umsetzung



    * Zertifikate sind (Plain-Text-)Dateien, die verschiedene technische Informationen enthalten wie z.B. den Namen des Ausstellers, den zertifizierten öffentlichen Schlüssel des Empfängers, ein Ablaufdatum, die elektronische Signatur der ausstellenden CA.

    * Vereinfacht (!) gesagt, ist das Zertifikat der mit dem privaten Schlüssel der CA signierte öffentliche Schlüssel des Empfängers. Nur mit dem öffentlichen Schlüssel der CA kann diese Signatur geprüft werden. Und dieser öffentliche Schlüssel ist für alle wichtigen CAs im Browser hinterlegt.

    * Genauer gesagt werden alle Inhalte des Zertifikats signiert und vom öffentlichen Schlüssel des Empfängers nur der Hash. Und im Browser sind auch nicht nur die öffentlichen Schlüssel der CAs hinterlegt, sondern wiederum Zertifikate, die wiederum zertifizert sind usw.

    * Die Root-Zertifikate am Ende dieser Kette werden dann von der CA selbst signiert und heißen selbstsignierte Zertifikate. Dabei garantiert quasi die CA selbst, dass sie wirklich diese CA ist.



    * Der Aufbau der Dateien ist standardisiert, z.B. im Format X.509.

    * Aussteller und Zertifikatinhaber werden durch eine Reihe von Attributen beschrieben, z.B. den sog. Common Name (CN), Land und Ort.







    Links



    * Permalink zu dieser Podcast-Episode

    * a href="https://fachinformatiker-anwendungsentwicklung.net/feed/podcast/" title="RSS-Feed des Anwendung...

    • 36 Min.
    Normalisierung einer Datenbank am konkreten Beispiel – Anwendungsentwickler-Podcast #144

    Normalisierung einer Datenbank am konkreten Beispiel – Anwendungsentwickler-Podcast #144

    Wir gehen ein komplettes Beispiel zur Normalisierung einer relationalen Datenbank durch in der einhundertvierundvierzigsten Episode des Anwendungsentwickler-Podcasts.



    Inhalt

    Theoretische Grundlagen



    * Wir normalisieren Datenbanken um Redundanzen zu vermeiden, die zu Anomalien führen können. Mehr dazu in Podcast-Episode 18.

    * Grundlagen wie Schlüssel, Kardinalitäten usw. erkläre ich in Podcast-Episode 17.

    * Merksatz: „The key, the whole key, and nothing but the key.“



    Beispieldaten

    Wir verwenden ein „klassisches“ Beispiel, das so oder ähnlich in vielen IHK-Prüfungen genutzt wird.



    * Umfeld: Kunden bestellen Artikel aus verschiedenen Artikelgruppen.

    * Ein Kunde kann mehrere Bestellungen durchführen. Eine Bestellung wird immer von genau einem Kunden getätigt.

    * Zu den Kunden werden Name und Adresse erfasst.

    * Jede Bestellung hat ein Bestelldatum.

    * In einer Bestellung können mehrere Artikel enthalten sein. Ein Artikel kann auch in mehreren Bestellungen auftauchen.

    * Artikel haben eine Bezeichnung und einen Preis.

    * Ein Artikel kann zu genau einer Artikelgruppe gehören. Eine Artikelgruppe kann mehrere Artikel enthalten.

    * Artikelgruppen haben eine Bezeichnung und einen Rabatt.



    Ausgangssituation (nicht normalisiert)



    * Alle Bestellungen stehen in einer einzelnen Tabelle. Jede Bestellung steht komplett inkl. mehrerer Artikel in einer Zeile. Die Adresse steht komplett in einem einzigen Attribut.

    * Beispiele für Probleme: Viele Redundanzen (z.B. Adressen, Artikelbezeichnungen), Sortierung nach Ort ist nicht möglich, Selektion aller gekaufter Fernseher ist nicht möglich.





    1. Normalform



    * Definition: Es gibt 1) nur atomare Attribute und 2) keine Wiederholungsgruppen.

    * „the key“: Alle Datensätze sind eindeutig über einen Primärschlüssel identifizierbar.

    * Durch 2) werden Redundanzen zunächst eingeführt, da aus einer Zeile nun mehrere Zeilen mit redundanten Inhalten werden.

    * Vorgehen: Nicht-atomare Attribute auf mehrere Spalten aufteilen. Wiederholungsgruppen auf mehrere Zeilen aufteilen.

    * Ein Datensatz ist über einen zusammengesetzten Schlüssel aus drei Attributen identifizierbar.

    * Redundanzen: Kunden-, Bestell- und Artikeldaten sind jeweils mehrfach vorhanden.

    * Ursache: Tabelle enthält drei Konzepte (Kunde, Bestellung, Artikel), die alle nur von Teilen des Schlüssels abhängen und nicht vom gesamten.





    2. Normalform



    * Definition: (1. Normalform erfüllt und) alle Attribute sind voll funktional vom Primärschlüssel abhängig.

    * „the whole key“: Alle Attribute hängen vom gesamten Schlüssel ab (und nicht nur von seinen Teilen).

    * Vorgehen: Alle drei Konzepte auf einzelne Tabellen aufteilen. Fremdschlüssel für Referenzen einführen. Zuordnungstabelle Position mit zusammengesetztem Schlüssel aus Fremdschlüsseln einführen.

    * m:n-Beziehungen werden aufgelöst.

    * Menge gehört an die Kombination aus Bestellung und Artikel und weder an das eine noch das andere allein.

    * Redundanzen: Artikelgruppe und Rabatt gehören zusammen und sind mehrfach vorhanden.

    * Ursache: Rabatt hängt von Artikelgruppe ab und nicht von der Artikelnummer (=transitive Abhängigkeit).





    3. Normalform



    * Definition: (2.

    • 1 Std. 1 Min.

Kundenrezensionen

AndreDevpunk ,

Super Podcast

Habe den Podcast während meiner Ausbildung gehört, ist aber auch abseits der Ausbildungsthemen super interessant und informativ. Werde ihn auf jeden Fall weiterhin hören.
Mach weiter so Stefan.

eGofox ,

Großartig der IT Podcast ist sehr empfehlenswert!

Es werden viele wichtige und zugleich spannende Themen besprochen.

Awesome CS-Podcast ,

Großartiger Podcast

Ich habe den Podcast vor etwas mehr als einem Jahr entdeckt und freue mich mittlerweile auf jede neue Folge. Immer wieder interessante Themen aus allen IT-Bereichen und zwar nicht nur Anwendungsentwicklung. Absolut nachvollziehbar und verständlich erklärt.
Klare Empfehlung. Unbedingt reinhören, wenn Ihr Euch für IT-Themen interessiert.

Warum gibt es hier nicht mehr vergleichbare Angebote?

Top‑Podcasts in Technologie

Zuhörer haben auch Folgendes abonniert: