Normalisierung einer Tabelle

Moderator: ModerationP

Re: Normalisierung einer Tabelle

Beitragvon Bitsqueezer » 11. Sep 2018, 07:13

Hallo,

1:1-Tabellen sind möglich - aber in der Praxis höchst selten. Klar, wenn man eine flache Tabelle einfach senkrecht aufteilt und aus einzelnen "Themen" der Tabelle einzelne Tabellen macht, erhält man eigentlich das gleiche wie vorher, nämlich eine flache Tabelle, nur daß sie jetzt auf mehrere Tabellen nebeneinander aufgeteilt ist (also 1:1) - in dieser Form macht Normalisierung auch keinen Sinn, dann kann man einfach bei der einen Tabelle bleiben.

Im Regelfall wird aus den aufgeteilten Tabellen aber fast automatisch eine 1:n- oder sogar m:n-Beziehung, wenn man sie so aufteilt, daß sie so flexibel wie möglich sind. Die flache Tabelle scheitert ja bereits an erheblicher Redundanz, was wohl hier selbst der ursprüngliche Programmierer gemerkt hat, als er Benutzernamen in eine eigene Tabelle ausgelagert hat - somit müssen Zusatzdaten wie Telefonnummer, Arbeitsplatz uvm. nicht in jeder Zeile redundant wiederholt werden.

Genau so wäre auch bei den anderen Vorgängen zu verfahren, da hier Aktionen "nebeneinander" stehen und wenn es mal eine zweite von der gleichen Art gibt, auch einfach eine weitere Feldgruppe des gleichen Typs eingefügt wird. Das erschwert die Programmierung, ganz besonders von Abfragen der Art "wieviele Reparaturen gab es für Gerät X?" oder "Zeige alle Reparaturen von Gerät 1 bis 100 im Zeitraum A bis B".

Entsprechend gibt es hier natürlich auch keine 1:1-Beziehung sondern, wie bereits vorgeschlagen wurde, eine Aufteilung in Stammdaten wie Benutzerliste und Geräteliste und Bewegungsdaten wie Aktionen, die über eine Aktionskategorie (weitere Tabelle) typisiert werden. Damit sind Abfragen dann ein Kinderspiel.

Es ist allerdings ein Trugschluß zu glauben, in der Benutzeroberfläche könne dann alles weitestgehend so bleiben wie bisher. Wenn Du die Datenbank ordentlich normalisierst, ist ein Komplettumbau der GUI absolut unvermeidbar, es sei denn, Du möchtest komplizierte Programmierung verwenden, nur um die GUI zu erhalten (was ebenso kontraproduktiv wäre, sowohl aus Performance-, Usability- wie Kostengründen). Durch eine optimierte Umstellung der Datenbank kann und sollte die GUI entsprechend auch umgestellt werden.

Letzten Endes muß man sich bei solchen Umprogrammierungen immer fragen, was der Kunde mit der Datenbank anfangen möchte. Wenn das einzige Ziel ist, Daten zu erfassen und gelegentlich Eingaben zu suchen, Abfragen aber nicht von Bedeutung sind und der "Gewöhnungsfaktor" am Frontend wichtiger ist, stellt sich automatisch die Frage, ob es den Kostenaufwand einer Umprogrammierung rechtfertigt, auch wenn die zugrundeliegende Datenbank noch so schlecht ist.

Liegt der Fokus aber darauf, Daten in Zukunft besser abfragen zu können, mehr Wert aus den Daten durch Abfragen zu schöpfen, die i.d.R. meist für die Geschäftsführung wichtiger sind als für den User, wenn man plant, große Erweiterungen drumherum einzubauen, die eine Normalisierung erforderlich machen uvm., dann sollte man sich auch nicht vor dem Aufwand scheuen, alles evtl. komplett in den Lokus zu kippen und neu anzufangen, was meist schneller geht. Und dann gleich eine ordentliche Planung anzusetzen, bei der kaum je eine 1:1-Beziehung auftreten wird.
(Was nicht heißt, daß 1:1-Beziehungen verpönt oder schlecht wären, sie haben ebenso ihre Daseinsberechtigung, nur ist ihr Anwendungsfall oder -notwendigkeit eher sehr selten.)

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Normalisierung einer Tabelle

Beitragvon pfoti » 13. Sep 2018, 17:55

Servus,

Bitsqueezer hat geschrieben:1:1-Tabellen sind möglich - aber in der Praxis höchst selten. Klar, wenn man eine flache Tabelle einfach senkrecht aufteilt und aus einzelnen "Themen" der Tabelle einzelne Tabellen macht, erhält man eigentlich das gleiche wie vorher, nämlich eine flache Tabelle, nur daß sie jetzt auf mehrere Tabellen nebeneinander aufgeteilt ist (also 1:1) - in dieser Form macht Normalisierung auch keinen Sinn, dann kann man einfach bei der einen Tabelle bleiben.


Bei uns im Kurs war der einzige vorgebrachte Fall einer 1:1 Beziehung der, dass Daten, die nicht in jedem FE sichtbar sein dürfen (Gehalt, SV-Nummern, usw.) aus Sicherheitsgründen in eine 1:1 Tabelle gehören.
Ich habe hier noch eine weitere Situation:
Wenn eine importierte Tabelle, die einen Datenstamm hat, regelmäßig neu importiert wird und nicht verändert/ergänzt werden darf (z.B. CNC-Maschinendaten) kann man in einer 1:1 Tabelle Informationen zu den einzelnen DS anlegen.
Man muss eben dafür sorgen, dass keine Inkonsistenz auftritt.

MfG
Pfoti
MfG
Pfoti
pfoti
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 250
Registriert: 16. Feb 2015, 19:06

Re: Normalisierung einer Tabelle

Beitragvon KlausMz » 13. Sep 2018, 18:33

Hallo,
1:1-Tabellen sind möglich - aber in der Praxis höchst selten. Klar, wenn man eine flache Tabelle einfach senkrecht aufteilt und aus einzelnen "Themen" der Tabelle einzelne Tabellen macht, erhält man eigentlich das gleiche wie vorher, nämlich eine flache Tabelle, nur daß sie jetzt auf mehrere Tabellen nebeneinander aufgeteilt ist (also 1:1) - in dieser Form macht Normalisierung auch keinen Sinn, dann kann man einfach bei der einen Tabelle bleiben.
ganz sehe ich das nicht so.

Es kann ja z.B. für verschiedene Geräte gemeinsame Merkmale geben und und Merkmale die nur für eine bestimmte Gerätesorte zutreffend sind. Ein flache Tabelle a'la Excel hätte alle Felder nebeneinander in der Tabelle. Zutreffende Merkmale sind ausgefüllt und nicht zutreffende bleiben leer.
Wenn ich jetzt diese Tabelle aufteile mit 1:1 Beziehungen zwischen den gemeinsamen Merkmalen und den jeweils zutreffenden so habe ich doch nicht den gleichen Aufbau wie die ein flache Tabelle. Ich habe viel weniger leere Felder, denn je nach Gerät habe ich in der zweiten 1-Tabelle nur die Felder die für dieses Gerät auch zutreffend sind.
Hier gibt es keine leeren Felder

Und der Fall von Kerstin scheint mir auch für 1:1 Beziehungen geeignet.
Es geht um Elektrogeräte. Und in dieser Tabelle werden die verschiedensten Fälle bearbeitet, die mit dem Gerät passieren können. Es kann gefunden werden. In diesem Fall werden verschiedene Felder für das Finden gefüllt (Datum, Ort, Finder etc.). Es kann auch angekauft werden. Dann werden Datum, Person, die verkauft etc. in andere für diesen Fall vorgesehene Felder eingetragen.
Das Gerät wird 1x gefunden und 1x verkauft.

Oder auch der obige Hinweis von pfoti. Das ist im Access Tutorial auch beschrieben. Siehe Bild.
Bei einer Tabelle a'la Excel wären ja die Felder KundeSeit, Gehalt, Sonderkonditionen in einer Tabelle und zwei der drei Felder würden je nach Person leer bleiben.
Also für mich gibt es durchaus sinnvolle Anwendung (wenn auch selten) für 1:1 Beziehungen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Benutzeravatar
KlausMz
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 38240
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Normalisierung einer Tabelle

Beitragvon knobbi38 » 13. Sep 2018, 19:17

Hallo,

nicht zu vergessen sind noch Optimierungsfälle, wo in Multiuserumgebungen mit Access Backends bei Locking auf Datensatzebene an Bereichen der Tabellen gleichzeit gearbeitet werden soll. In speziellen Fällen kann man mit einer Aufteilung einer Tabelle auf zwei Tabellen mit einer 1:1 Struktur das Locking-Problem erheblich mindern bzw. auch vermeiden.
Hinzu kommen Optimierungen auf Netzwerkebene, die bei Remoteanbindungen manchmal auftreten können.
Zugegeben, daß sind technsche Gründe und entsprechen nicht unbedingt den Entwurfsregeln, aber alles schon gehabt und in der Praxis vorgekommen.

Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 406
Registriert: 02. Jul 2015, 14:23

Re: Normalisierung einer Tabelle

Beitragvon Bitsqueezer » 14. Sep 2018, 10:39

Hallo,

@Klaus: Nein, das ist kein gutes Beispiel. Du zerfledderst eine flache Tabelle in viele einzelne und mußt am Ende etliche Abfragen zusammenbasteln, um Daten wieder zusammenzuführen.

Was die Personentabelle angeht: Ja, kann man so machen, aber das gezeigte Konstrukt ist fehlerhaft, da es erlaubt, die gleiche PersonenID in Lieferanten und Mitarbeiter einzutragen, was normalerweise keinen Sinn macht. Der übliche Aufbau ist, eine Personentyp-ID in die Haupttabelle einzutragen und in den Untertabellen eine Festwert-Spalte (in Servern ein Calculated Persisted Field mit immer dem Wert 4 z.B., in Access müßte es ein normales Zahlenfeld mit einem konstanten Defaultwert sein). Diese Spalte speichert man mit der PersonenID als Unique Index, damit kann man dann eine 1:1-Beziehung aufbauen, die eindeutig ist, bei der ein Mitarbeiter nicht auch noch Lieferant sein kann. Ja, das ist eines der seltenen und in der Praxis wenig verwendeten Szenarios (ich nutze das übrigens in meinem aktuellen Projekt ebenfalls genau so). Tatsächlich ist der Aufwand der Programmierung aber auch hier beträchtlich, um Formulare erzeugen zu können, mit denen man solche Konstrukte sinnvoll bearbeiten kann. Aus Datenbanksicht ist es sehr gut, aus Frontendsicht nicht.

@knobbi, pfoti: Ja, natürlich gibt es auch andere Szenarios, in denen eine 1:1-Beziehung Sinn macht. Datentrennung aus Sicherheitsgründen, Lock Szenarios, ebenso Dinge wie senkrechte Aufteilung einer Tabelle mit vielen Daten, um sie auf verschiedenen Datenträgern speichern zu können (mit DB-Servern, mit Access nicht möglich). Meine Aussage war lediglich, daß diese Szenarios im Verhältnis zu herkömmlichen Beziehungstypen eher sehr selten sind. Von meinen über 350 Tabellen in meinem aktuellen Projekt verwenden vielleicht 10 eine 1:1-Beziehung.

Das Beispiel aus dem aktuellen Thread hier ist jedenfalls keins für eine 1:1-Beziehung.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Normalisierung einer Tabelle

Beitragvon KlausMz » 14. Sep 2018, 10:54

Hallo,
@Christian
und wie würdest Du es machen um leere Felder zu vermeiden ?
1:n Beziehungen machen doch da auch keinen Sinn.
In dem Beispiel mit dem Bild aus dem Tutorial würden ja leere Felder entstehen.
Und wenn man das als n:m aufbauen würde mit den möglichen Personenarten als Tabelle, hätte man ein Feld für verschiedne Werte, Datum, Währung und z.B. Prozent. Was wieder ein erhöhter Aufwand für die Validierung bedeutet.
bei der ein Mitarbeiter nicht auch noch Lieferant sein kann
was aber auch vorkommen kann. Und ein Mitarbeiter kann auch Kunde sein, was wahrscheinlicher ist.

Ich möchte das einfach mal aus reinem Interesse disskutieren, ich möchte nur meinen Horizont erweitern. :badgrin:
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Benutzeravatar
KlausMz
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 38240
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Normalisierung einer Tabelle

Beitragvon Nouba » 14. Sep 2018, 11:49

Ich glaube, hier liegt ein Mißverständnis vor. Klaus will ja gerade anhand eines generischen Aufbaus, der in der Praxis so vermutlich kaum jemand umsetzen wird, aufzeigen, dass eine Person sowohl als Kunde, als auch als Mitarbeiter sowie auch als Lieferant auftreten kann, wobei spezifische Merkmale zu der entsprechenden Rolle dann in den Tabellen rechts im Diagramm vorzufinden sind.

Christian will hingegen mit Ausschlüssen dafür sorgen, dass eine Person mehr als eine Rolle einnimmt.

@Christian:

zum Üblichen sei vermerkt, dass AFAIK nur SQL-Server und Oracle - vielleicht auch noch DB2 (bin mir da nicht sicher) sogenannte Computed Persisted Fields unterstützen.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 17187
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Normalisierung einer Tabelle

Beitragvon KlausMz » 14. Sep 2018, 12:33

Hallo,
Ich glaube, hier liegt ein Mißverständnis vor.
ja, auch.
Mir geht es auch darum, wie man eine Datenbank aufbaut mit z.B. unterschiedlichen Geräten, die gemeinsame Merkmale haben, aber auch merkmale die für eine bestimmte Geräteart gültig sind. Wie würde man solche Tabellen aufbauen ohne 1:1 Beziehungen herzustellen ?
Christian hat ja einfach nur gesagt "schlechtes Beispiel" aber keinen anderen Vorschlag gemacht.
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Benutzeravatar
KlausMz
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 38240
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Normalisierung einer Tabelle

Beitragvon Nouba » 14. Sep 2018, 13:47

Klaus,

ich kann das jetzt auch nur aus meinem Gefühl heraus sagen. Sollen Wertevergleiche stattfinden, würde ich auch zu einem Schema, wie Du es oben vorgestellt hast, tendieren, dabei jedoch den PK auf das FK-Schlüsselfeld setzen- Bei einem Kühlschrank würde vermutlich die Dimension interessant sein, während bei einem Ventilator eher die Anzahl der Umdrehungen und der Durchmesser interessieren dürfte.

Bei speziellen, eher beschreibenden und selten vorkommenden Attributen würde ich, um die 1:1-Beziehungen nicht ausarten zu lassen und die Tabelle wie eine schwachbesetzte Matrix aussehen zu lassen, zu einer Attributbeschreibung neigen, wie Du sie häufig für Kontaktinfos (Email, Tel, Fax, Mobil, etc.) vorschlägst und die Attribute selbst m:n-verknüpft über eine weitere Tabelle pflegen. Diese könnte dann in einer Berichtsansicht alle Einzelattribute zum aktuellen Gerät relativ übersichtlich darstellen und ein horizontales Scrollen der Ansicht gering halten.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 17187
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Normalisierung einer Tabelle

Beitragvon KlausMz » 14. Sep 2018, 14:43

Hallo,
mal folgendes konkrete Beispiel aus dem Leben gegriffen.
Eine Inventardatenbank in der z.B. auch Motoren erfasst werden, auf die ich mich jetzt beschränke..
Es sollen folgen Werte erfasst werden:
- Inventarnummer
- Antriebsart (Benzin, Diesel, Strom als FS)
- Leistung (Integer)
- Hubraum (Integer)
- Zylinderzahl (Byte)
- Spannung (Integer)
- CosPhi (Kommazah <1)
- Wirkungsgrad (%)
Es gäbe noch mehr Merkmale, aber ich will mich mal darauf beschränken.

Eine Tabelle mit allen Feldern a'la Excel hätte je nach Motorart leere Felder zur Folge.
Als generischer Aufbau als n:m müsste erst mal eine Zuordnungstabelle erstellt werden, damit nur die passenden Merkmale gewählt werden können
Für Benzin und Diesel wären das Hubraum und Zylinderzahl
Für Strom, Spannung, CosPhi und Wirkungsgrad.
Zusätzlich zu der Zuordnungstabelle wird dann auch noch eine n:m Tabelle benötigt zur Erfassung der eigentlichen Werte.
Wobei dann das Feld zur Aufnahme der Werte Text sein muss, da hier verschiedene Datentypen eingetragen werden müssen.
Hier ist ein erhöhter Aufwand nötig, dass sinnvolle Werte erfasst werden.

Mit 1:1 Beziehungen habe ich dieses Problem nicht. Für jede Motorart eine extra Tabelle mit den relevanten Feldern (Datentypkonform) und 1:1 mit der Haupttabelle verknüpft. Der FK wird dann auch zum PK.

Und analog zu meinem Beispiel mit den Motoeren war die Eingangsfrage von Kerstin.
In diesem Fall werden verschiedene Felder für das Finden gefüllt (Datum, Ort, Finder etc.). Es kann auch angekauft werden. Dann werden Datum, Person, die verkauft etc. in andere für diesen Fall vorgesehene Felder eingetragen.


@Christian:
Wie würdest Du das machen?
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Benutzeravatar
KlausMz
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 38240
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Normalisierung einer Tabelle

Beitragvon Nouba » 14. Sep 2018, 15:40

Das würde ich bestimmt ähnlich machen, wobei dann hier Christians zusätzliches Feld durchaus zur Geltung käme, weil ein E-Motor keinen Hubraum und keine Zyndkerzen etc. hat und umgekehrt andere Attribute eines E-Motors nicht im Verbrennungsmotors vorhanden sind. Auf das obige Diagramm bezogen, würde dieses dann auch von rechts nach links gelesen werden.

Wenn es aber um Peanuts (unwesentliche Attribute) am Motor geht, die man vielleicht erwähnen will, und die vielleicht auch nur in einer bestimmten Art Verbrennungsmotor oder E-Motor Verwendung finden (ich bin kein Motor-Experte), dann spricht IMHO nichts gegen die Datenhaltung in der anderen Struktur.

Welche Angaben als wesentlich und welche als unwesentlich für die Datenhaltung zu betrachten sind, bestimmt der Zweck und natürlich der Kunde/Betreiber der Datenbank.
mit freundlichen Grüssen Nouba

Wenn beim Lesen eines Beitrags der Eindruck entsteht, dass sich der Fragesteller wenig Mühe gegeben hat, so erhöht das nicht unbedingt die Motivation, eine Antwort zu verfassen.
Nouba
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 17187
Registriert: 13. Mär 2006, 12:55
Wohnort: Berlin

Re: Normalisierung einer Tabelle

Beitragvon Bitsqueezer » 16. Sep 2018, 13:47

Hallo,

@Klaus: Es wurden doch schon andere Beispiele genannt und ich habe noch die Aufteilung auf verschiedene Datenträger hinzugefügt. Generell würde ich 1:1-Beziehungen vermeiden, solange man dazu noch in der Designphase dazu in der Lage ist.

Der Datenbankdesigner und auch der Frontenddesigner sollte den Wert darauf legen, Daten zu normalisieren (aber nicht um jeden Preis) und Daten einfach und standardisiert eingebbar zu machen. Wenn man sich daran orientiert, steht das Modell der Untertabellen in Widerspruch dazu. Ja, es paßt zur Normalisierung, aber unter dem Gesichtspunkt "um jeden Preis", der Preis ist eine große Menge Extratabellen, die alle im Frontenddesign einzeln behandelt werden müssen, die keine standardisierte Eingabe mehr ermöglichen, die Einzeltests für jede weitere Tabelle benötigen, für die man ein Frontend schreiben muß (auch ein Unterformular ist ein "eigenes" Frontend). Ein weiterer Preis dieses Modells ist es, jede weitere Objektart wieder mit eigenen Tabellen ausstatten zu müssen, was in etwa genauso kontraproduktiv ist, wie Aufzählungsfelder (wie das bekannte Jahreszahlenbeispiel) in Tabellen.

Die Überlegung des Designers sollte also sein, Daten so anzuordnen, daß sie möglichst zeilenorientiert arbeiten, 1:1-Beziehungen dagegen sind nur eine Verschleierung von "breiten Tabellen", bei denen man sich lediglich nicht benötigte Zeilen in den Extratabellen spart. Das Einsparen von Datenmengen ist heutzutage, bei denen aktuell Seagate eine (!) Festplatte mit einer Kapazität von 14 TB liefert, absolut kein Thema mehr. Viel wichtiger ist es, Designzeit, Programmierzeit zu sparen und Performance zu liefern und dabei Redundanzen zu vermeiden, die groß angelegte Updates erforderlich machen, wenn man ihre Schlüsselwerte verändert (also als Negativbeispiel, eine String-Projektnummer als PK/FK in allen Tabellen zu verwenden, bei der eine Änderung der Projektnummer viele Änderungen in vielen Tabellen bedeuten würde).

Was das Personenbeispiel angeht: Wie Nouba schon sagt, kommt es natürlich darauf an, was man erreichen möchte. Wenn man wirklich einen Mitarbeiter auch als Kunden anlegen möchte, muß man ja nicht das Modell nehmen, das ich beschrieben habe, dann kann man ja das im Tutorial beschriebene Modell beibehalten. Entsprechend ist es nicht grundsätzlich falsch, aber die Wahrscheinlichkeit, daß man je solche Konstrukte haben möchte, ist eher sehr gering. Für den seltenen Fall, daß so ein Fall auftritt, könnte man den betreffenden Mitarbeiter auch einfach nochmal als Kunden anlegen und mit einer ParentID auf den Originaldatensatz verweisen, somit wäre die Eindeutigkeit und genaue Typisierung der Daten gesichert, ohne allzuviel Redundanz. Wie mein Kollege in meinem aktuellen Projekt gerne sagt "das fällt unter die 80:20-Regel". Also in 80% kommt es nicht vor und für die 20% Ausnahme dann die 80% zu riskieren oder extra zu programmieren, macht keinen Sinn. Ich würde hier eher sagen: 98:2-Regel...

(@Nouba: Computed Columns gibt es mind. in Oracle, DB2 und MySQL, wenn auch vielleicht nicht als Unique Index einsetzbar. Letzten Endes erfüllt aber ein einfaches Zahlenfeld mit einem festen Defaultwert den gleichen Zweck, also auch in Access).

Das Problem ist eigentlich keins, wenn man sich nur vor Augen führt, um welche Art Spalten einer Tabelle es sich handelt. Es gibt auch hier "Stammdaten" und "Bewegungsdaten", nur würde man sie eher als "feste Bestandteile" und "dynamische Bestandteile" bezeichnen und dann auch entsprechend designen. Als feste Bestandteile kommt in Felder, was im Regelfall für alle oder die allermeisten Datensätze von Bedeutung ist. Ebenso auch solche Felder, die vielleicht nur selten befüllt, aber trotzdem benötigt werden, z.B. um einen Datensatz irgendwie zu kennzeichnen, um ihn leichter auswählen zu können. Als "dynamische Bestandteile" würde ich alle Daten bezeichnen, die für eine Frontendentwicklung ohne Bedeutung sind, die nur existieren, um sie fallabhängig eingeben zu können. Und dafür läßt sich eine (verhältnismäßig) einfache, wiederverwendbare und jederzeit ausbaubare Logik entwickeln, für die später (weitestgehend) KEINE zusätzliche Programmierung mehr erforderlich ist.

Als einfaches Beispiel wurde bereits genannt, eine Aktionstabelle zu verwenden, und jede Aktion über eine Aktionslookup-Tabelle zu typisieren. Das ist aber nur eine Vorstufe der Umarbeitung von spalten- zu zeilenorientierter Eingabe.
Komplexer im Aufbau, dafür unendlich flexibler in der Anwendung, ist die konsequente Verwendung von Konfigurationstabellen.
Um das mal anhand Deiner Inventurdatenbank zu beschreiben (ebenso anwendbar auf das eigentliche Threadthema):

Man braucht eine Tabelle, die das Objekt selbst beschreibt. Mal ganz einfach gedacht, Daten wie ID_Objekt, F_ObjektName, F_DatumErstellung, F_DatumVerschrottung. Dazu sicherlich einige andere Felder, die je nach Wunsch weitere Dinge beschreiben, die basismäßig immer zum Objekt (zu JEDEM) gehören. Dabei ist es also egal, ob es ein Lolli oder ein Motor ist.

Eine weitere Tabelle kann man verwenden, um Objekte zu gruppieren, also etwa ID_ObjektTyp, F_ObjektTypName und weitere, die eine bessere Typisierung ermöglichen (je nach Daten).

Die nächste Tabelle verwaltet Feldtypen (wie Text, Zahl, Projektnummer, was auch immer, alles losgelöst von der speziellen Verwendung in einem Attribut) . Etwa ID_FeldTyp, F_FeldTypName und z.B. F_RegularExpression.

Für Lookup-IDs kann man auch noch eine Tabelle "Lookups" erstellen, die ID_Lookup, ID_FeldTyp, F_LookupWert, F_Sortierung beinhaltet.

Man braucht eine Tabelle, die nun die zusätzlichen Attribute beschreibt. Als einfaches Beispiel, Felder wie ID_ObjektAttribut, ID_FeldTyp, F_ObjektAttributName. Damit kann man nun spezielle Attribute wie "Antriebsart", "Leistung", "Zuckergehalt", "Lutschbarkeit" beschreiben und ihnen die Feldtypen "Antriebsart", "Integer", "Gramm" und "Boolean" zuweisen. Wenn es in der "Lookups"-Tabelle die Einträge "Benzin", "Diesel", "Strom" gibt und diese auf den Feldtyp verweisen, kann man diese in einer Combobox zur Auswahl anbieten. Wenn es keine Lookups gibt, kann man eine Textbox anzeigen und je nach RegularExpression eine Validierungsregel anwenden. Oder durch weitere Felder wie "F_MinValue", "F_MaxValue". Das läßt sich ja beliebig ausbauen.

In einer weiteren Konfigurationstabelle ordnet man die Objekttypen per m:n zu den Attributen hinzu, so daß man diese wiederverwenden kann für jeden anderen Objekttyp. Also auch einen lutschbaren Motor, wenn es sein muß.

Das ist jetzt nur eine gaaanz grobe Skizze, das kann man noch beliebig ausschlachten und erweitern, aber das Modell erfüllt alle eingangs genannten Designrichtlinien: Die Daten sind normalisiert gespeichert, sie sind leicht abzufragen, leicht zu konfigurieren und das dazu passende Frontend muß nur einmal programmiert werden. Wenn es ein neues Objekt mit neuen Attributen gibt, ändert man ein paar Konfigurationsdaten und erhält das neue Objekt, ohne das Frontend ändern zu müssen. Leere Felder gibt es in dem Modell nicht, wenn man es nicht will.

Ja, Access wirft einem dabei Steine in den Weg, da es schwieriger ist, in einem Endlosformular in unterschiedlichen Zeilen unterschiedliche Dinge zu machen. Hier muß man ein wenig experimentieren und ungewohnte Wege gehen, etwa mit ADO Disconnected Recordsets, bei denen im Endlosformular Comboboxen mit unterschiedlichen Inhalten möglich sind, oder durch ein Einzelformular, das man so aussehen läßt, als sei es ein Endlosformular (wie in meinem bekannten Popupfilter), dem man genug versteckte Felder hinzufügt, um das Erscheinungsbild dynamisch anzupassen. Hier kann man sich einfach damit behelfen, daß die Anzahl an Zusatzattributen zu einem Objekt in den allermeisten Fällen sehr begrenzt ist, so daß man mit einer bestimmten maximalen Anzahl auskommt. Die Anzahl kann man z.B. in einer Systemattributstabelle festlegen, so daß auch das Frontend, das man schreibt, um die Konfigurationstabellen zu befüllen, diesen Wert auslesen und begrenzen kann, wieviele Attribute je Objekt eingebbar sind - usw.

Im Frontend ist es, je nach Wunsch, ebenso möglich, alle Felder eines Objekttyps immer anzuzeigen (nicht befüllte aber nicht zu speichern) oder den Attributstyp bei jeder Eingabe eines neuen Objektes per Combobox wählen zu lassen, was meist umständlicher in der Eingabe ist.

Ja, das Modell ist durchaus anspruchsvoller und man muß von einfachem "Schnell-Zusammenschubsen" von Access-Frontends Abstand nehmen, aber das Modell kommt ja auch nur für solche speziellen Szenarios vor, für die meisten Datenbanken funktioniert es ja, herkömmliche normalisierte Tabellen zu erstellen, die mit einer absehbaren und festen Menge an Attributen daherkommt. Das Modell der dynamischen Attribute ist dafür aber auch wiederverwendbar, wie im Beispiel meines Popup-Filters, der sich selbständig auf jedes angebotene Recordset jedes unbekannten Formulares vollautomatisch konfigurieren kann. Mittlerweile mehrere tausend Downloads beweisen die vielfältige Anwendbarkeit solcher Modelle. Das hier beschriebene Modell (wie gesagt, unvollständig und nur "schnell dahingeschrieben") funktioniert prinzipiell nach ähnlichem Prinzip, und wenn man es nicht auf bestimmte Objekte wie "Motoren" oder "Lollis" spezifiziert, kann man es, einmal programmiert, für alle möglichen Datenbanken unverändert übernehmen. Es funktioniert ebenso für die Personendatenbank. Durch die dynamische Erweiterbarkeit ist der Kunde danach ebenso unabhängig im Ausbau, weil er eben, nachdem er nun auch noch Fahrräder verwalten will, einfach nur ein paar Daten in Tabellen anpassen kann, und schon ist er dazu in der Lage.
Andere Beispiele für so ein Modell habe ich in meinem aktuellen Projekt verwendet, um ein komplexes Rechtesystem aufzustellen (hatte ich hier in einfacherer Form schon mal in einem Thread beschrieben) oder ein Sprachenmodell, bei dem alle Objekte im Frontend und alle Fehlermeldungen etc. in der gewünschten Benutzersprache erscheinen und jederzeit auf Klick gewechselt werden können. Wieder ein anderes Beispiel zeigt, wie man per Konfigurationstabellen das komplette Aussehen des Frontends verändern und ebenfalls auf Klick wechseln kann.

Mit Konfigurationstabellen zu arbeiten, setzt mehr "Normalisierung" voraus, sehr abstraktes Denken, aber hat man es einmal umgesetzt, kann man damit sehr viel mehr machen, als "normale" Tabellen erlauben, das Ergebnis ist sehr flexibel und im Verhältnis auf lange Sicht sehr viel kostengünstiger, auch wenn die erstmalige Umsetzung mehr Zeit und Arbeit kostet.

Übrigens: Die Datenbanken selbst machen es ebenso, indem auch Feldtypen usw. in internen Konfigurationstabellen gespeichert werden, die man dann zur Auswahl in Comboboxen im Tabellendesign hat.

Auch der Einwand von Nouba ist ein Punkt, den man sich immer überlegen sollte, wenn man so eine Datenbank entwirft: Ist das einzugebende Attribut wirklich von Bedeutung für z.B. eine Abfrage/Auswertung zu einem späteren Zeitpunkt, oder ist es nur eine allgemeine Beschreibung, die zwar interessant zu wissen ist, aber ohne weitere Bedeutung für mein Tagesgeschäft? Eine Lagerverwaltung etwa interessiert sich vielleicht grob für einen Objekttyp und sicherlich für Attribute wie Ausmaße, Gewicht, Gefahrenstoff usw., aber es wird hier niemanden interessieren, wieviel Zuckergehalt der Lolli hat oder ob es ein Benzinmotor oder ein Dieselmotor ist. Wenn das Geschäft also ein Lageranbieter ist, wird er solche Daten rein informationshalber gerne in ein Freitextfeld schreiben, aber es muß nicht in einzelne Attribute verteilt, validiert und abgefragt werden.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 6585
Registriert: 21. Jun 2007, 12:17

Re: Normalisierung einer Tabelle

Beitragvon pfoti » 17. Sep 2018, 16:05

Servus,

ohne jetzt alle Threads genau gelesen zu haben:
Das Beispiel ist genauer betrachtet nicht gut gewählt.
Aber es soll ja nur die Möglichkeiten zeigen.

Einen MA auch als Lieferanten anzulegen wir din der Praxis so oder so schwierig werden....

1.) Der MA hat sehr wahrscheinlich eine PersonalNr.
Der Lieferant eine Kunden- bzw. Lieferantennummer.
Diese laufen dann aber in unterschiedlichen Kreisen.
2.) Der MA könnte als Lieferant eine völlig andere Adresse haben.
usw. usw....

MfG
Pfoti
MfG
Pfoti
pfoti
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 250
Registriert: 16. Feb 2015, 19:06

Vorherige

Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste