Dataverse (eBook)

55 Bauanleitungen

Heike Hofert (Autor)

eBook Download: EPUB

2025 | 1. Auflage
312 Seiten
Books on Demand (Verlag)
978-3-7693-6390-6 (ISBN)

Infos

Datenchaos in Excel? Zeit für eine smarte Lösung! Viele kleine und mittelständische Unternehmen verarbeiten ihre Daten immer noch auf altbewährte Weise - mit Excel. Doch sobald die Datenmengen wachsen und die Komplexität zunimmt, stoßen auch Excel-Nutzer schnell an ihre Grenzen. Listen, die per E-Mail hin- und hergeschickt werden, komplexe S- oder XVerweis-Funktionen und wachsende Sicherheitsbedenken - all das kostet Geld, Zeit, Nerven und birgt Risiken. Aber was, wenn es eine einfachere und sicherere Lösung gibt? In diesem Buch erfahren Sie, warum eine Datenbank die Antwort auf Ihre Probleme ist und wie Sie mit Microsoft Dataverse den Sprung in die Zukunft der Datenverarbeitung schaffen. Egal, ob Sie große Datenmengen effizienter verwalten, den Überblick über Zugriffsrechte behalten oder Ihre Daten online im Team bearbeiten wollen - hier finden Sie den einfachen Einstieg in die Welt von Dataverse, abgestimmt auf Microsoft 365. Sagen Sie dem Excel-Chaos Lebewohl und entdecken Sie, wie Sie Ihre Daten sicherer, schneller und professioneller verwalten!

Heike Hofert ist seit mehr als 30 Jahren IT-Trainerin, Beraterin und Entwicklerin für digitale Lösungen mit Microsoft-Produkten.

Textauszug

Ohne Basics läuft nix

3 BEZIEHUNGEN

Fragen & Aussagen eines Teams:

Was ist das denn? Wir wollen doch keine Datenbankspezialist:innen werden. Wir wollen nur unsere Daten in eine App einbauen, so dass alle daran arbeiten können.

Schritt 1: Nein, ich möchte nicht Ihr Berufsfeld nicht ändern. Doch wenn Sie später einmal höhere Ansprüche an Ihre Daten stellen wollen (und ich verspreche Ihnen, das wird kommen), dann ist diese Bauanleitung für Sie sehr wichtig. Lassen Sie mich also zunächst die Frage beantworten: Was ist ein Datenmodell?

Bei einem Datenmodell geht es darum, Ihre Daten aus verschiedenen Tabellen miteinander zu verknüpfen. Ein Datenmodell bildet die Grundlage Ihrer Daten und ist entscheidend dafür, wie Daten gefunden und gepflegt werden.

Wenn von einer Entität die Rede ist, dann ist eine Tabelle gemeint, oder besser gesagt, die Dinge oder Objekte, die sich in einer solchen Tabelle befinden.

In diesem Buch-Beispiel geht es um das Ausleihen von Büchern. In der Tabelle Bücher werden alle Buchobjekte mit all ihren zugehörigen Eigenschaften (Attributen) eingetragen. Dazu gehören die ISBN, eine Kurzbeschreibung des Buches, die genaue Seitenanzahl und das Erscheinungsdatum.

An dieser Stelle könnte man meinen, dass auch der Verlag dazu gehört. Doch so ein Verlag veröffentlicht ja mehr als nur dieses eine Buch. Was machen Sie dann? Sie müssten den gleichen Verlagsnamen mit Adresse mehrmals in die Tabelle Bücher eingeben. Das kostet Zeit, führt zu Fehlern und erhöht die Datenmenge. An diesem Punkt müssen Sie über ein Datenmodell nachdenken. Die Verlage gehören also in eine eigene Tabelle, wo man sie nach Firmennamen, Gründungsjahr, Adresse usw. genau voneinander unterscheiden kann.

Wenn das alles klar ist, können Sie eine Beziehung (engl. Relation) zwischen einem Verlag und dessen Büchern herstellen. So eine Beziehung heißt hier „1:n-Beziehung”, weil ein (1) Verlag ja viele (n) Bücher veröffentlichen kann.

Wenn diese Beziehungen dann von einer Tabelle zur anderen gezogen werden, entsteht ein Datenmodell. So ein Modell heißt übrigens auch ER-Modell, abgeleitet von Entity-Relationship-Model.

Diese Beziehungen kann man ganz einfach und verständlich beschreiben. Ein Verlag veröffentlicht viele Bücher (1:n). Und umgekehrt: Veröffentlicht ein Buch auch viele Verlage ? Nein, so nicht!

Also, ein Verlag veröffentlicht viele Bücher und jedes Buch gehört zu genau einem Verlag. Dadurch haben wir eine 1:n-Beziehung. So wie dieses Beispiel zeigt, spielt die Leserichtung eine große Rolle.

Schritt 2: Nehmen wir doch mal ein anderes Beispiel: Die Bücher werden in einer Bücherei ausgeliehen. Wie sieht die Beziehung zwischen den Personen und den Büchern aus (mehrere Nennungen sind möglich)?

Beziehung 1: Eine Person kann viele Bücher ausleihen

Beziehung 2: Ein Buch kann von vielen Personen ausgeliehen werden

Beziehung 3: Viele Personen können viele Bücher ausleihen

Beziehung 4: Jede Person kann genau ein Buch ausleihen

Beziehung 5: Ein Buch kann von genau einer Person ausgeliehen werden

Nach dem Lesen der fünf Fälle, war Ihnen sicherlich schon sofort klar, dass die Beziehungen 4 und 5 für eine Bücherei völlig untauglich sind. Das liegt daran, dass in diesen Beziehungen jedes Buch und jede Person genau nur einmal vorkommen dürfen. Beziehung 1 lässt sich als „1 Person : n Bücher“ formulieren und Beziehung 2 als „1 Buch : n Personen“. Wenn beide gelten sollen (und das ist das Konzept einer Bücherei), dann führt das automatisch zu Beziehung 3 nämlich „m Personen : n Bücher“. Das ist eine sogenannte many-to-many-Beziehung oder kurz m:n-Beziehung.

Schritt 3: Warum ist diese n:m bzw. m:n Beziehung so wichtig? Weil sie eine weitere Tabelle erforderlich macht. Eigentlich ist es eine Verbindung aus zwei 1:n-Beziehungen mit eigenen Inhalten. Schauen Sie sich mal diese Infografik an:

Abbildung 15: m:n Beziehungen, um die Ausleihen zu speichern

Sie zeigt, wie auf Umwegen zwei Tabellen miteinander verbunden werden und sich nun eine weitere Tabelle dazwischen befindet. Eigentlich gibt es technisch gesehen nur n:1- oder 1:n-Beziehungen, aber genau dieses m:n-Konstrukt wird Ihnen in Datenbankmodellen immer wieder begegnen.

Sie können ohnehin nicht einfach alle Informationen in nur einer Tabelle unterbringen. Dann würden ganz viele gleiche Daten immer wieder erscheinen. Wir sprechen dann von redundanten Daten. Das bedeutet, dass sich in einer solchen Tabelle Autoren, Buchnamen, Ausleiher:innen usw. mit jedem weiteren Ausleihdatum ständig wiederholen. Diese Datenmenge kann bei nur wenigen Ausleihen schon enorm groß werden und das sollten Sie verhindern.

4 WOZU SIND BEZIEHUNGEN GUT?

Fragen & Aussagen eines Teams:

Das ist alles schöne Theorie, aber was nützt uns all der Datenbank-Schnickschnack in der täglichen Arbeit?

Schritt 1: Stellen Sie sich doch mal vor eine andere Person oder Sie selbst würden eine Tabelle in Dataverse löschen? Würde Ihr System das jetzt bemerken? Die Antwort lautet „Ja“, denn Sie beziehen sich auf Daten einer anderen Tabelle. Bitte nicht nachmachen: In diesem Fall habe ich mal schnell eine Tabelle Nutzer in meinem System gelöscht. Diese Tabelle war mit der Tabelle Ausleihinformationen verbunden. Zuerst wurde ich gewarnt, dass damit dieses Objekt und dessen Daten gelöscht werden. Dann habe ich den Button gedrückt !

Abbildung 16: Meldung beim Löschen einer Tabelle

Schritt 2: Danach habe ich die Tabelle Ausleihinformationen geöffnet und die Fehlermeldung gesehen. Hier wird klar, dass die Tabelle der Nutzer eine Abhängigkeit zu dieser Tabelle hatte.

Abbildung 17: Fehler durch Löschen der Entity Nutzertabelle

Schritt 3: Ein Klick auf die Schaltfläche Abhängigkeiten anzeigen, gibt eine kurze Liste zurück. Ich gebe zu, diese könnte ein bisschen lesefreundlicher sein, aber immerhin gibt es diese Anzeige der abhängigen Objekte.

Abbildung 18: Abhängigkeiten zur Tabelle der Nutzer

Schritt 4: In der Tabelle Ausleihinformationen sind diese Daten in Dataverse noch zu sehen. Also wie es scheint, wurden diese Daten doch nicht gelöscht.

Abbildung 19: Unterer Formularteil der Tabellen-Übersicht in Power Apps

Schritt 5: Ein Blick in die Beziehungen zeigt diese Verbindung.

Abbildung 20: Oberer Formularteil der Tabelle Ausleihinformationen in Power Apps

Schritt 6: Wie Sie sehen ist, ist hier eine n:1-Beziehung vorhanden. Da je 1 Nutzer n-mal etwas ausleihen kann, steht hier eine 1;n-Beziehung drin. Die „umgekehrte“ Schreibweise n:1 müsste als Formulierung dann lauten: Es sind n Ausleihen je 1 Nutzer möglich.

Abbildung 21: Zeile zeigt Beziehung zu einer Spalte einer anderen Tabelle an

Schritt 7: Okay, trotz des Löschversuchs scheint es irgend nicht möglich zu sein, die Tabelle Nutzer zu löschen. Dann versuche ich es mal mit der Tabelle Ausleihinformationen. Beim Löschen erhalte ich den gleichen Löschhinweis wie bei der Tabelle der Nutzer auch.

Abbildung 22: Löschhinweis

Schritt 8: Dieser Vorgang dauert schon deutlich länger als beim Löschen der Nutzertabelle. Kurz darauf erhalte ich die Meldung „Objekte erfolgreich gelöscht“ in der Übersicht meiner Tabellen. Meine Objekte wurden also erfolgreich gelöscht.

Abbildung 23: Erfolgsmeldung Löschvorgang

Schritt 9: Damit sind sämtliche Informationen zu meinen Nutzer:innen und den jeweiligen Ausleihen verloren gegangen! Das Datenmodell, das ich zuvor angelegt hatte, sah so aus, wie in dieser Abbildung zu sehen ist. Die Feldnamen könnten unter Umständen abweichen.

Abbildung 24: Importiertes Datenmodell in Dataverse

Haben Sie es erkannt? Bei der Tabelle Ausleihinformationen handelte es sich um eine n:m-Beziehung. Gesehen hatten Sie in Dataverse aber nur die n:1-Beziehung aus der Nutzertabelle. Wie schon in der vorherigen Bauanleitung erklärt, sind diese n:m-Beziehungen eher unauffällig und vor allem technisch wichtig. Angegeben werden sie aber immer nur als 1:n- bzw. n:1-Beziehungen, weil dies echte darstellbare Beziehungen sind.

Fazit: Die Nutzertabelle diente als Nachschlagetabelle für die jeweiligen Ausleihen. Daher war es nicht möglich, zuerst diese Nachschlagetabelle zu löschen. Sobald aber die Verknüpfungstabelle gelöscht ist, wird die Nachschlagetabelle nicht mehr benötigt, so dass diese Art des...

Produkt-Details

• Erscheint lt. Verlag: 13.1.2025
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Datenbanken
• ISBN-10: 3-7693-6390-6 / 3769363906
• ISBN-13: 978-3-7693-6390-6 / 9783769363906