jo, eiglich korrekt.
Ich würde noch weiter ausholen: Ein relationales Datenmodell besteht aus Tabellen mit Datensätzen, und die Tabellen sind über Beziehungen miteinander verknüpft - gugge die relationale GrundIdee. Mit diesen Elementen: Datensatz, Tabelle, Beziehung kann man annähernd jede Anforderung modellieren.

Gut. Eine relationale Datenbank ist ein relationales Datenmodell: Sind Tabellen, Datensätze, Relationen drinne.

Ein Dataset ist auch ein relationales Datenmodell mit Tabellen, Datensätze und Relationen. Der Sinn ist, dass man einen Daten-Cache hat, in dem man vernünftig mit den Daten wirschaften kann, und an den man Databinding zum Gui hin anknüpfen kann.
Also es ist ein Cache. Es ist keine Struktur, sondern der Cache hat eine Struktur, und zwar dieselbe wie die DB.
Man schreibt also nicht jeden Pups in die DB und liests wieder aus, und füllts in die Controls, sondern man füllt den Cache mit einer brauchbaren Menge an Daten, und werkelt nur mit den Daten. Da das Gui an die Daten angebunden ist, muß man sich um die Controls nicht kümmern.
Oft hat man sogar kaum was zu werkeln mit den Daten, denn die Controls werkeln ja auch - also um eine Property zu editieren ist nichts zu tun: Die Textbox ist an die Prop gebunden, und was du da reinschreibst, das ist in den Daten - gebunden eben.

Noch ein wesentlicher Punkt ist die Änderungsverfolgung des Datasets. Das Dataset merkt sich und unterscheidet die Änderungstypen Delete, Update, Insert. Dadurch kann man sehr effiziente Speicher-Routinen schreiben, die nicht den ganzen Cache wieder in die DB pusten, sondern nur, was geändert wurde.
Also es ist ein Cache, und er wird mit der DB synchronisiert einerseits beim Laden, annererseits beim Abspeichern.
Allerdings bekommst du Probleme mittm Abspeichern, wenn du iwelche kunstvolle Sql-Abfragen konstruierst, die Tabellen generieren, die in dieser Form in der DB garnicht vorhanden sind.
Etwa mit InnerJoins.
Die Daten solcher Tabellen können prinzipiell nicht gerückspeichert werden, eben weil in sonem Fall die Struktur des Caches nicht mehr mit der der DB übereinstimmt.
Es ist auch kaum jemals nötig, solche Sql-Übungen zu machen, weil zB einen JoinigView bekommt man auch allein im Gui hin, ohne dass die Daten zusammenzuzmanschen sind.

Noch ganz wichtig die Unterscheidung von untypisiertem und typisiertem Dataset. Das untypisierte Dataset ist die Basis-Klasse, die vom typisierten Dataset beerbt wird.
Zur Benutzung ist das untypisierte eiglich kaum zu gebrauchen, denn in einer DB treten bei mw 5 Tabellen mit je 5 Spalten über 30 verschiedene oder gleiche Datentypen auf, und es gibt 25 Properties auseinanderzuhalten, und über die Relationen mag sich das noch vervielfältigen.
Untypisiert ist man endlos am casten und am zugreifen über hardcodierte String-Schlüssel, und es ist eiglich ausgeschlossen, dass man sich da nicht mal iwie verschreibt oder falsch castet oder sowas.
untypisiertes Dataset ist einfach quick and dirty.

Das typDataset hat alle String-Schlüssel-Zugriffe und Casts (Typumwandlungen) weggekapselt, und stellt dieselben Daten jeweils als einfachen Property-Zugriff bereit, ohne String-Schlüssel und Cast.
Weiters bietet son typDataset enorme Design-Möglichkeiten im Designer. Also ein Datagridview, was an einem typDataset hängt, hat ein ganz neues "Gesicht".
Weil es "kennt" die Properties, und kann geeignete Spalten dafür bereitstellen, fixnFertig mit Überschrift, Spaltenbreite, Format-Zeichenfolge, und vielem vielem mehr. Und es steht nicht nur bereit, sondern es soll ja modifiziert und überarbeitet werden - ebenfalls im Designer.