Hat jemand irgendwelche guten Szenarien, um relationale Datenbanken und SQL zu unterrichten? Alle Beispiele, die ich finden kann, sind entweder trivial oder haben unwahrscheinliche Domänenbeschränkungen (wie vollständiger Name ist einzigartig).
Ich versuche insbesondere, einige gute Beispiele für die Normalisierung zu finden: Tabellen, die nicht sofort 3NF und BCNF passen. Im Moment verwende ich für jedes Level ein anderes Problem.
Natürlich würde ich auch gute Beispiele schlecht gestalteter Datenbanken lieben, aber es ist ein wenig störend, bis die Grundlagen gemeistert sind.
Danke, ein paar nette Beispiele. Ich habe den Schüler / die Klasse eins als die Antwort markiert, wie ich denke, es ist der beste bisher, aber wenn jemand mehr beitragen möchte, bitte tun.
Ich glaube, dass ich mich daran erinnere, dass Schüler / Klasse ein Klassiker ist. Sie können auch Noten hinzufügen, um es etwas komplexer zu machen.
Der Schüler kann viele Klassen besuchen
Klassen haben viele Schüler
Für jede Klasse, die ein Schüler besucht, kann er eine Note haben
Zunächst können Sie dies in einer Tabelle tun und bis zu drei denormalisieren.
off topic
Nachdem ich Datenbankklassen unterrichtet habe, würde ich vorschlagen, Design zu vergessen, bis die Grundlagen der Abfrage gemeistert sind. Die Leute verstehen die Notwendigkeit der Normalisierung viel besser, wenn sie erst einmal verstanden haben, wie man Daten aus einer Datenbank holt. Wenn Sie mit der Normalisierung und dem Design beginnen, werden Sie die meisten Schüler für den Rest der Klasse verlieren. Design sollte das allerletzte Modul eines Datenbankkurses sein, aber alle Lehrbücher, die ich jemals überprüft habe, haben damit begonnen.
Noch besser, wenn sie sowohl gute als auch schlechte Datenbankdesigns abfragen, wenn sie Abfragen lernen, und dann werden sie wirklich verstehen, wie schmerzhaft schlechtes Design ist, wenn es Zeit ist, Design zu unterrichten.
E-Commerce / Warenkorb Design ist gut, weil die meisten Leute das Konzept verstehen und Sie können es in viele verschiedene Richtungen schieben.
Sie können einfache Dinge wie Einkaufswagen, Einkaufswagen, Benutzer, Bestellungen, Bestellartikel usw. tun.
Dann können Sie tiefer gehen mit user_addresses, user_emails, items, item_details, item_history, etc.
Dies kann eine Menge guter Debatten bieten, da es viele Beurteilungen gibt.
Ein Konzept, das ich nie vergessen werde, ist die ganze "Plural" gegen "Singular" -Ding mit Namen. Ein großer Mentor, den ich schon lange zurück hatte, sagte mir einmal, dass Sie Ihre Tabellennamen als Plural und Ihre Spaltennamen als Singular entwerfen sollten und dass Sie niemals temporalspezifische Namen für Spaltennamen erstellen sollten. Temporale Namen Beispiele sind NutsSold1998, NutsSold1999, NutsSold2000, etc. Fügen Sie niemals eine Jahres- oder Monats- oder Wochennummer oder -zeit usw. zu einem Spaltennamen hinzu.
Tabellenname Beispiele: Mitarbeiter (nicht Mitarbeiter) Teile (nicht Teil) Studenten (Studenten)
Spaltenname Beispiele: EmployeeID (nicht EmployeesID oder EmployeeIDS, etc) PartID (nicht PartsID oder PartIDS, usw.) StudentID (nicht StudentID oder StudentIDS, etc)
Und um auf die korrekte Verwendung von ID, Code, Schlüssel, Nummer usw. zu achten, wurde mir immer beigebracht, "Schlüssel" nicht im Namen einer Spalte zu verwenden, außer es war ein tatsächlicher Tabellenschlüssel (primär oder fremd, aber nicht notwendigerweise alternierend) .. Die meiste Zeit ist das Anhängen von "ID" eine bessere Wahl als das Anhängen von "Nummer" oder "Code", aber alles hängt vom Kontext ab.
Und das kommt mit der Zeit und der Erfahrung bei der Gestaltung von Tischen, beim Lesen guter Materialien wie dem Datenbankdesign für mere Sterbliche und Datenmodellierung für alle . Außerdem viel Zeit damit verbringen, gute Designs zu betrachten und auseinander zu nehmen. Es ist definitiv ein Handwerk und Sie werden nur mit Zeit und Übung besser.
Hier ist ein Beispiel, das auf meine eigene Universitätszeit zurückgeht - es wurde sowohl als Datenbankdesign-Herausforderung als auch als objektorientierte Design-Herausforderung verwendet.
Nicht alle Informationen wurden sofort aufgedeckt - ein Teil der Herausforderung bestand darin, zu sehen, wie ein Design an neue Anforderungen angepasst werden kann und wie eine ordnungsgemäße Normalisierung dies vereinfacht.
Angenommen, Sie müssen eine Datenbank für eine Universität / Hochschule erstellen und Anmeldungen bearbeiten.
Sie haben die Kurse unterrichtet. Jeder Kurs hat jede Woche einen Titel und ein reguläres Zeitfenster.
Jeder Kurs hat einen Dozenten , der den Kurs vorstellt.
Jeder Kurs hat viele Studenten s, die den Kurs studieren.
Jeder Kurs hat einen oder mehrere Tutoren , die den Studenten beim Lernen helfen. Sie müssen nicht verfolgen, welche Tutoren welche Schüler unterstützen.
Einige Kurse haben mehrere reguläre Zeitfenster.
Einige Kurse haben mehrere Dozenten.
Dozenten und Tutoren werden bezahlt, was bedeutet, dass wir einige Informationen für Steuerzwecke verfolgen müssen. Der Steuerabteilung ist es egal, wofür sie bezahlt wurden - sie erwarten, dass wir einen einzigen Datensatz pro Person haben.
Bei einigen Kursen arbeitet der Dozent auch als Tutor, um eine genaue Übersicht darüber zu bekommen, wie einige Schüler mit dem Material umgehen.
Einige Tutoren sind auch Dozenten in anderen Kursen.
Um ein Tutor in einem Kurs zu sein, müssen Sie zu einem früheren Zeitpunkt ein Student auf diesem Kurs gewesen sein.
Nicht jeder Student wird für das Bestehen des Kurses anerkannt - manche auditieren nur den Kurs, ohne dass ein Kredit benötigt wird.
Ein Student, der einen Kurs nicht besteht, kann den Kurs später wieder besuchen. Wir müssen Aufzeichnungen über jeden Versuch führen.
Es gibt immer auch das Bibliotheksbeispiel (Eine Bibliothek hat viele Bücher, jedes Buch hat einen Autor und einen Verleger, die bei der Normalisierung in separate Tabellen verschoben werden können)
Re:
Ich versuche besonders, etwas zu finden gute Beispiele für die Normalisierung: Tabellen, die nicht sofort 3NF passen und BCNF.
Sie finden normalisierte Datenbankschema-Beispiele hier: Ссылка . Sie können sie von Grund auf aufbauen, um Ihren Schülern den "Weg der Normalisierung" zu zeigen. Schauen Sie sich insbesondere das Schema des Kontaktmanagements an. Sie können das Schema leicht denormalisieren und es auf 3NF oder tiefer zurückbringen.
Itzik Ben Gans neues Buch, Microsoft SQL Server 2008: T-SQL-Grundlagen, hat ein sehr einfaches Beispiel, das Sie sehen können, stammt aus einer vereinfachten Northwind-Datenbank.
Microsoft SQL Server 2008: T-SQL Fundamentals Autor-Support-Seite
Ein anderes gutes Modell ist das Rechnungspositionsmodell, da die "beste Wahl" von verschiedenen Faktoren abhängt:
Sehen Sie sich dieses Datenmodell an:
Rechnung
Rechnungstyp
Anwendungsfunktionen sind:
Angenommen, Sie haben im Durchschnitt 5 Artikel pro Rechnung und 100 Rechnungen pro Tag, die Sie für jeden Tag erledigen:
Also ist total = 1800 Operationen / Tag, vorausgesetzt, Lese- und Schreibvorgänge haben die gleichen Kosten.
Wenn Sie das Attribut "TotalAmount" für die Entität "Invoice" hinzufügen, ist die Situation etwas anders:
mit insgesamt 800 Operationen:)
Tags und Links database-design normalization scenarios