ComputerBase Menü
Aktuelles

VisualBasic Access DB Normalisierung

zer0core

zer0core

Ensign
Registriert
Sep. 2007
Beiträge
174
Hallo Leute,

im Anhang ist ein Screenshot eines aktuellen Datenbankprojekts von mir.
Es ist die Frage ob ich in der Tabelle Kunde die Adressen (Kunde und Rechnungsadresse) in eine separate Tabelle auslagern soll oder ob das letzten Endes zu viel ist?
beziehungen.jpg

Ich freue mich über eure Vorschläge =)

LG
 
Ich würde sogar behaupten das ist zu wenig.
Eigentlich könnte es sogar noch eine Tabelle Ansprechpartner geben. Du hast garantiert pro Kunde nicht immer nur eine Adresse, nicht immer nur eine Telefonnummer und nicht immer nur eine Email Adresse.
Die Rechnungsbezogenen Daten könnten allerdings durchaus beim Kunden bleiben
 
Addressen Tabelle erstellen, Type hinzufügen (Rechnung/Lieferaddresse). Andrede kann auch darin
Ergänzung ()

Terminart und Kundenart gibt keinen Sinn. Einfach in Termin/Kunden Tablle einfügen
Ergänzung ()

Die Tabelle Objekt darf nie verändert werden. Du kannst den Preis zB nicht erhöhen weil sonst durch deine Verbindung abgeschlossen Verträge verändert werden
 
Danke für die Antwort.
Terminart habe ich aus dem Grund hinzugefügt, da es wirklich verschiedene Termine gibt...

Auftragsdatum
Anfragedatum
Kaufvertragsdatum
Besichtigungstermin
Notartermin
Mietvertragsdatum

Wenn ich Adressen auslagere benötige ich auch wieder eine Hilfstabelle richtig?
Da es ja für jeden Kunden mehrere Adressen gibt n:m
 
Ja brauchst du.

Du kannst deine Terminart trotzdem in deinen Termin einfügen.
Eine verlinkte Tabelle hat keinen Sinn wenn sie nur eine Information hat

Termin
- 24/10/2017
- Notartermin
- Notar schmit

Da hast du genau die gleichen Infos aber in einer Tabelle
Ergänzung ()

Objektart kanns du eigentlich auch in Objekt einfügen.
So weit ich verstehe geht es hier um ein Makler Modelle (Häuser und Wohnungsverkauf zum vermieten oder verkaufen)
 
Ich habe es früher so gelernt immer wo sich etwas wiederholen kann, sollte man in eine separate Tabelle auslagern um Speicher zu sparen?
 
Das stimmt ja auch. Aber nur wenn es sin macht.
Zb TerminArt, das ist nur ein Feld. Du verbrauchst mehr Speicher für eine Tabelle wo nur ein Wert und eine Verbindung drin steht.

zB du setzt terminart in Termin dann hast du einen Eintrag
du setzt terminart in eine andere tabelle dann hast du einen Eintrag in Termin für die Verbindung, Eine neue Tabelle, eine Verbindung in der neuen Tabelle und eine Beschreibung in der neuen Tabelle

Erste Lösung = 1 Eintrag
Zweite Lösung = 4 Einträge
Ergänzung ()

Bei Adress lohnt es sich dann allerdings eine Tabelle zu machen.
Du hast viel Daten und die können sich häufig wiederholen zB Grosskunde der mehrere Objekte kauft.

Hier zB würde ich es so machen

tblKunde - > tblLinkAdresse -> tblAdresse
...............->... KundenId........->...AdressenId
...............->... AdressenId......->.........
...............->...Typ.....................>.........
Ergänzung ()

dann hast du nur einen Eintrag Adress für jeder Art von adresse (liefer rechnung) und kanns es bei grossen kunden einfach nur verlinken
 
Zuletzt bearbeitet:
Setz AdressenArt in die AdressenHilfe, Wenn du die gleiche Liefer und RechenAdresse hast sparst du viel Speicher
Ergänzung ()

Warum der Unterschied Anrede und Briefandrede?
Kannst du vielleicht eine Tabelle sparen
Ergänzung ()

AdresseId in tblKunde brauchst du nicht mehr
Ergänzung ()

Objektart kanns du in Objekt einfügen (wäre besser aber nicht wirklich nötig)
Rest ist soweit ich sehe OK
 
Vielen Dank für deine Unterstützung.
Anrede und Briefanrede ist ja meist unterschiedlich Herr, Herrn, sehr geehrter Herr etc.
AdressID habe ich wie empfohlen entfernt.

vlt komme ich die Tage nochmal auf dich zu ;-)
 
Dann würde ich noch Andrede in tblKunde und BriefAndrede in tblAdresse reinschreiben.

Kein Problem, kannst mir ja eine Mitteilung schreiben :hammer_alt:
 
Die Termin_Art direkt in die Termine-Tabelle rein zuschreiben ist nicht gerade sehr clever.
Wie wird denn die Termin_Art dort jetzt eingetragen? Wahrscheinlich aus einer Liste mit Werten.
Und aus welcher Quelle wird diese Werteliste gefüllt? Wahrscheinlich fest codiert. Und wenn man mal eine neue Art Termin aufnimmt oder einen bestehenden Termin streichen muss? Das ist schon nicht nur Antipattern, das ist einfach, sorry, schlecht.

Und deswegen machen wir bei der Datenbankentwicklung konsequent die 3. Normalform und nicht die 2. Auch wenn es auf dem ersten Blick umständlich erscheint mit mehreren Tabellen zu arbeiten, anstatt mit einer einzigen, ergeben sich erst durch die 3. Normalform die Vorteile einer Datenbank. Es gibt nur ganz wenige Ausnahmen, bei denen man auf die 2. Normalform zurückfällt, aber das sind, wie gesagt, Ausnahmen. Niemals fängt man an und vermischt beim generellen DB-Design die 2. und 3. Normalform. Da kommt am Ende nur schlechte Software und ein Chaos bei der Erweiterung der Anwendung bei raus.

Kleiner genereller Tipp zum Datenbankdesign: Einfach mal das Vorhaben in natürlicher Sprache aufschreiben und jedes Hauptwort unterstreichen. Das sind dann die Entitäten mit denen man dann ein ERM anfertigt. Abschließend die Kardinalität festlegen und daraus ergibt sich dann das Relationenmodell.
 
ayngush, ich denke nicht, dass der TE mit dem zweiten und dritten Absatz viel anfangen kann....
 
Dann hilft Tante Google mit den Begriffen durchaus weiter.
Ich kann ja nicht jedesmal beim Ausführen der Probleme beim "Aneinanderreiben von Stöcken erzeugt Reibungswärme, mit der man in der Lage ist leicht entzündliches Material wie getrockneten Zunder (ein Baumpilz) zum Glühen zu bringen, mit dessen Glut unter Zuführung von Sauerstoff aus der Atemluft weiteres leicht entzündliches Material... und so brachten wir das Feuer unter Kontrolle." anfangen.
 
ayngush schrieb:
Die Termin_Art direkt in die Termine-Tabelle rein zuschreiben ist nicht gerade sehr clever.
Wie wird denn die Termin_Art dort jetzt eingetragen? Wahrscheinlich aus einer Liste mit Werten.
Und aus welcher Quelle wird diese Werteliste gefüllt? Wahrscheinlich fest codiert. Und wenn man mal eine neue Art Termin aufnimmt oder einen bestehenden Termin streichen muss? Das ist schon nicht nur Antipattern, das ist einfach, sorry, schlecht.
Zum Vergrößern anklicken....
Das, denke ich, kommt auf die Verwendung an. Benutzt man das Attribute rein informell hast du sicherlich recht, denn dann muss man statt dem Programm nur einen Eintrag in der TerminArt-Tabelle ändern/ergänzen/löschen. Sobald das Attribut aber programatisch verarbeitet wird, erfordert jede Änderung/Ergänzung/Entfernung einer Termin-Art sowieso eine Änderung des Programms und dann sind fest codierte Werte nicht nur kein Mehraufwand, sondern zwingend erforderlich. Das gilt dann unabhängig davon wie die Daten letztenendes in der Datenbank abgelegt werden.

ayngush schrieb:
Und deswegen machen wir bei der Datenbankentwicklung konsequent die 3. Normalform und nicht die 2.
Zum Vergrößern anklicken....
Mein Studium ist schon ein bisschen her und ich bin eher Software- als DB-Entwickler, aber auch nach einem Nachschlagen der 3NF-Definition sehe ich nicht, inwiefern das Attribut Termin-Art in der Tabelle Termin eine Verletzung der 3NF darstellt. Termin-Art ist einzig abhänig vom Primärschlüssel.
 
TerminArt ist in Deinem Beispiel kein Schlüssel, sondern ein Nichtschlüsselattribut, genauso wie Termin an sich und damit wäre Termin wieder abhängig von anderen Nichtschlüsselattributen, was eine Verletzung der 3NF darstellt.

Grüße
 
Rechnung in 'Kunde' auslagern, Kaufpreis auslagern (Währung, Wert, etc. ), Doppelungen auslagern (PLZ, Ort, Land). Beachte, dass z.B. Irland keine PLZ hat und es HausNr. mit Buchstaben gibt!
 
ayngush schrieb:
TerminArt ist in Deinem Beispiel kein Schlüssel, sondern ein Nichtschlüsselattribut, genauso wie Termin an sich und damit wäre Termin wieder abhängig von anderen Nichtschlüsselattributen
Zum Vergrößern anklicken....
Mag sein, dass ich auf dem Schlauch stehe, aber wieso ist Termin (damit ist doch der Zeitpunkt gemeint?) von TerminArt abhängig? Man kann doch einen Termin verschieben (Attribut Termin ändern) ohne dass das Auswirkungen auf die Terminart hat.

Zum ursprünglichen Frage: Ich würde neben der Adresse auch die Telefonnummern und die e-Mail-Adresse in separate Tabellen auslagern, denn es durchaus nicht ungewöhnlich, dass es davon eine variable Anzahl von gibt, z.B. Handy- oder Faxnummer und auch verschiedene e-Mail-Adressen. Zudem Frage ich mich, ob es wirklich gewollt ist, dass pro Kunde nur ein Termin gespeichert werden kann.
 
In TerminArt steht in dem Beispiel ein Wert drinnen und kein Schlüssel. TerminArten sind jedoch eine eigene Entität.
Damit wäre die Kombination Termin + TerminArt abhängig vom Schlüssel "ID" aus der Tabelle "tbl_Termine" und genau da liegt die Verletzung der 3NF vor.

TerminArt muss eine eigene Tabelle werden, da es eine eigene Entität ist und mit einen eigenen Schlüssel als Fremdschlüssel in die Tabelle "tbl_Termin" geschrieben werden. Das Problem ergibt sich daraus, dass in der Termine-Tabelle folgende Konstruktionen stehen:

1, "01.02.2016", "Besichtigung", "Brekkis für Hund vom Kunden mitbringen"
2, "05.02.2016", "Gespräch", "Kunde möchte reden"
3, "05.02.2016", "Besichtigung", "Taschenlampe mitnehmen!"
4, "18.02.2016", "Schlüsselübergabe", "Schokolade + Schlüssel"

Fragen in Prüfungen zu solchen Konstruktionen könnten jetzt lauten:

Ermitteln sie alle möglichen TerminArten, um damit eine Werteliste ("VB: Combofeld") in der zu Grunde liegenden Anwendung zu füllen.
Sie ändern den Termin 1 am 1.2.2016 von "Besichtigung" in "Wohnungsbesichtigung"
Was passiert jetzt mit der Werteliste?
Die Performance bei der Abfrage in welchem Monat die meisten Besichtigungen stattfinden ist sehr schlecht. Beschreiben sie, warum dieses Problem besteht.
Wie kann man die oben beschrieben Effekte und Probleme verhindern, erläutern Sie ihren Lösungsansatz.

usw.
 
ayngush schrieb:
Damit wäre die Kombination Termin + TerminArt abhängig vom Schlüssel "ID" aus der Tabelle "tbl_Termine" und genau da liegt die Verletzung der 3NF vor.
Zum Vergrößern anklicken....
Termin und auch TerminArt sind direkt abhängig vom Schlüssel ID. Da aber Termin und TerminArt nicht voneinander abhängig sind, besteht doch auch keine transitive Abhängigkeit zum Schlüssel und damit auch keine Verletzung der 3NF.

ayngush schrieb:
1, "01.02.2016", "Besichtigung", "Brekkis für Hund vom Kunden mitbringen"
2, "05.02.2016", "Gespräch", "Kunde möchte reden"
3, "05.02.2016", "Besichtigung", "Taschenlampe mitnehmen!"
4, "18.02.2016", "Schlüsselübergabe", "Schokolade + Schlüssel"
Zum Vergrößern anklicken....

ayngush schrieb:
Ermitteln sie alle möglichen TerminArten, um damit eine Werteliste ("VB: Combofeld") in der zu Grunde liegenden Anwendung zu füllen.
Zum Vergrößern anklicken....
Du gehst also von einer definierten Menge an möglichen Terminarten aus. Die Frage ist dann doch erst einmal wo diese Menge definiert ist. Man kann sie entweder in der Datenbank definieren, dann bräuchte man eine separate Tabelle, so wie du sie vorschlägst. Man kann sie aber auch direkt in der Software definieren. Das ist häufig sinnvoller, denn nur so können verschiedene Terminarten in der Software unterschiedlich gehandhabt werden. In dem Falle wäre die zusätzliche Tabelle TerminArt redundant. Ich verstehe, dass das aus DB-Entwickler-Sicht unschön ist, da man sich darauf verlassen muss, dass die Software nur "gültige" Werte einträgt, aus Software-Entwickler-Sicht erspart das einem aber "doppelte Buchführung", die nicht nur einen Mehraufwand bedeuten, sondern auch eine potentielle Fehlerursache darstellen würde.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

W
MS Access Datenbank erstellen
Antworten
8
Aufrufe
811
Raijin
Raijin
S
IONOS Hosting: was heißt "Angriffsversuche"?
Antworten
9
Aufrufe
788
lazsniper
L
Ghost_Rider_R
C# Methoden in andere Klasse verschieben (Visual Studio)
Antworten
9
Aufrufe
823
Ghost_Rider_R
Ghost_Rider_R
K
MS Access Datenbank: PLZ + Ort auslagern
Antworten
8
Aufrufe
2.025
VmaxGunni
VmaxGunni
P
schlanke Alternative zu einem CMS
Antworten
7
Aufrufe
1.260
sandreas
S
Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 165 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz