WinFuture-Forum.de: Hilfe bei Access Datenbank - WinFuture-Forum.de

Zum Inhalt wechseln

Seite 1 von 1

Hilfe bei Access Datenbank Korrekte Beziehungen/Aufbau


#1 Mitglied ist offline   Phil69 

  • Gruppe: Mitglieder
  • Beiträge: 4
  • Beigetreten: 23. November 16
  • Reputation: 0

geschrieben 23. November 2016 - 13:49

Hey,
bei einer recht einfachen Datenbank komme ich dennoch nicht weiter.
Die Tabellen (siehe Bild) sollten so in Beziehung stehen, dass ein Kunde eben mehrere Ansprechpartner haben kann und auch mehrmals angerufen werden kann (Akquise bedeutet hier Anrufe).
Im späteren Formular soll es so möglich sein den Kunden zu sehen, mit den Ansprechpartnern als Unterformular.
In einem weiteren Formular den Kunden, mit den Kontaktversuchen (Akquise).

Für euch sicherlich nicht schwierig, aber mir raubt es bereits zu viel Zeit.
Über einen Tipp für die Beziehungen wäre ich sehr dankbar.

Beste Grüße, Phil

Angehängte Miniaturbilder

  • Angehängtes Bild: Akquise.PNG

Dieser Beitrag wurde von Phil69 bearbeitet: 23. November 2016 - 13:50

0

Anzeige



#2 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.591
  • Beigetreten: 14. August 15
  • Reputation: 392

geschrieben 23. November 2016 - 14:35

Erstmal sollte man doppelte Einträge zu vermeiden. Deswegen gilt, sobald etwas mehrmals vorkommen kann, werden diese Werte in eine weitere Tabelle ausgelagert. Außerdem, wenn jede Tabelle eine ID hat, dann wird die Verknüpfung über eine weitere Tabelle gemacht in der dann nur die IDs stehen oder aber man macht dass per Code oder wenn es eindeutig ist, kann es auch als ID in der passenden Tabelle stehen.

Ich seh da auch noch Felder die fehlen.

ich kann das ganze ja mal in SQL bauen und dann hier listen

Frage dazu:

Was stellt das Feld Sachbearbeiter in der Tabelle Kunden dar? soll dort eine Zahl rein oder ein Name? Bei Mitarbeiter vermute ich eine Anzahl. Normal nennt man das aber Beschäftigte.^^

Struktur:

kunden (
  ID
  Firma
  Straße
  Nummer
  Postfach
  Postleitzahl
  Ort
  Land
  Sachbearbeiter
  Mitarbeiter
  Umsatz
  Branche
  Kontaktabbruch
  Letzte_Dienstleistung
  Erneute_Kontaktaufnahme
)

geschäftsführer (
  ID
  Anrede
  Titel
  Vorname
  Nachname
)

ansprechpartner (
  ID
  Anrede
  Titel
  Vorname
  Name
  Position
  Telefon
  Fax
  Mobil
  Email
)

akquise (
  ID
  Kontaktdatum
  Termin_vereinbart
  Wiedervorlage
  Notizen
  Status
  Flyer_gesendet
  Angebot_gesendet
)

kunden_geschäftsführer (
  Kunden_ID
  Geschäftsführer_ID
)

kunden_akquise (
  Kunden_ID
  Akquise_ID
)

kunden_ansprechpartner (
  Kunden_ID
  Ansprechpartner_ID
)



Wenn Sachbearbeiter ein Name sein soll, müsste dafür auch eine eigene Tabelle erstellt werden, vielleicht noch mit Datum. Oder aber 4 weitere Felder für Anrede, Titel, Vorname, Name des Sachbearbeiters genau wie bei Geschäftsführer.

Normal könnte man hier auch noch weiter gehen. Eine Firma kann mehrere Anschriften/Postfächer haben.

Der Umsatz ändert sich jährlich, also eventuell eine weitere Tabelle mit Jahr und Umsatz. Je nachdem ob es nötig ist.

Die Verknüpfung wie du das willst erfolgt über die 3 letzten Tabellen. Man kann das aber auch per Code machen und die Tabellen weglassen.

Ich muss aber sagen, dass ich lange keine deutschen Wörter mehr in einer DB gesehen habe. ;) Ich habe mir angewöhnt, und das ist auch der Standard weltweit, dass Datenbank-, Tabellen- und Feldnamen in englisch sind. Aber in Access ist alles möglich.^^

Dieser Beitrag wurde von Gispelmob bearbeitet: 23. November 2016 - 15:16

AMD Ryzen 9 5950X, Asus ROG Strix X570-F Gaming, 32GB Corsair DDR4-3200, Asus Geforce GTX 3060 12GB, Creative Sound Blaster AE-7, 240GB SSD, 500GB SSD, 3x 1TB SSD, Win11 Home, 4x Acer G246HL Bbid, Logitech MX518 Gaming Mouse, Logitech G440 Mousepad, Logitech K120 Keyboard, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#3 Mitglied ist offline   Phil69 

  • Gruppe: Mitglieder
  • Beiträge: 4
  • Beigetreten: 23. November 16
  • Reputation: 0

geschrieben 23. November 2016 - 15:29

Hey,
vielen Dank. Damit komme ich gut zurecht. Mit den Begriffen hast du natürlich recht^^
Richtig, Sachbearbeiter wäre dann auch eine weitere Tabelle. Einiges gelernt. Thx
0

#4 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 23. November 2016 - 18:59

Eh? Gibt es gar keine Mitarbeiter/Beschäftigte da? :unsure:

- Die Tabelle muß natürlich sinngemäß "Mitarbeiter" heißen. Geschäftsführer sind auch Mitarbeiter, ebenso wie Sachbearbeiter, eben so wie... naja... Praktikanten oder so.

Wenn nötig, kann man dann noch ausgliedern, weil Geschäftsführer *außer* den normalen Mitarbeitereigenschaften noch andere Eigenschaften haben, die rein "geschäftsführerspezifisch" sind und die die übrigen Mitarbeiter nur unnötig mit Leerfeldern auffüllen würden.

Je nachdem bräuchte man dann entweder ein Flag is_Geschäftsführer:BOOL (bzw entsprechend für die anderen) oder man müßte Abfragen auf bestimmte "Mitarbeiterklassen" dann auf die abgeleiteten Tabellen loslassen und die restlichen Mitarbeiterinformationen dann aus der Elterntabelle ran-join-en.

Wozu da jetzt eine dedizierte Relation Kunde_GS da ist.. seh ich grad allerdings nicht ein. Aber, gut, wenn Kunden mit Geschäftsführern interagieren müssen und diese Interaktionen auch noch Eigenschaften haben müssen und diese insbesondere weder ableitbar noch verzichtbar sind, dann muß halt eine Relation Kunde_GS her.

Am Ende wären das eh alles Mitarbeiter-IDs.

Dieser Beitrag wurde von RalphS bearbeitet: 23. November 2016 - 19:01

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#5 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.591
  • Beigetreten: 14. August 15
  • Reputation: 392

geschrieben 23. November 2016 - 20:27

Beitrag anzeigenZitat (RalphS: 23. November 2016 - 18:59)

Wozu da jetzt eine dedizierte Relation Kunde_GS da ist.. seh ich grad allerdings nicht ein.
Die 3 Relation-Tabellen kann man auch weglassen wenn man die Abfrage per Code, per SQL JOIN oder verschachteltem SELECT erledigt. Ist nur eine Vereinfachung um 2 einfache SELECTs nacheinander auszuführen. Ich weiß leider nicht wie das Wissen des TE in der Sache ist. Deswegen hab ich es so einfach wie möglich gemacht. Und natürlich ist mir nicht klar in wie weit das Ganze überhaupt benutzt wird.

Dieser Beitrag wurde von Gispelmob bearbeitet: 23. November 2016 - 20:28

AMD Ryzen 9 5950X, Asus ROG Strix X570-F Gaming, 32GB Corsair DDR4-3200, Asus Geforce GTX 3060 12GB, Creative Sound Blaster AE-7, 240GB SSD, 500GB SSD, 3x 1TB SSD, Win11 Home, 4x Acer G246HL Bbid, Logitech MX518 Gaming Mouse, Logitech G440 Mousepad, Logitech K120 Keyboard, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#6 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 23. November 2016 - 21:48

Nieder mit Access :lol:

Gut, ich geh einfach davon aus, daß man damit RDBMS irgendwie abbilden kann. Vielleicht ist das schon ein Fehlschluß. Ich find halt nur, daß der Entwurf schon passen muß, weil DEN ändert man im Betrieb dann nicht wieder, egal wie unpassend und/oder sonst scheiße der war.

-- Das soll jetzt keine Kritik sein, und schon gar nicht persönlich; ich will damit nur sagen, wenn man re: DB-Entwurf keinen Plan hat, und auch nicht weiß, wie man da rangehen *könnte*, daß man dann sagt, okay Scheffchen sorry das übersteigt meine Kompetenzen, und DB-Entwurf ist aber wichtig für uns als Unternehmung, also müssen wir wohl irgendwie wen suchen, der davon doch Ahnung hat. Die Angelegenheit scheint ja auf den ersten Blick recht klein zu sein, das sollte also nicht viel Mannstunden kosten.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#7 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.591
  • Beigetreten: 14. August 15
  • Reputation: 392

geschrieben 23. November 2016 - 21:57

Es scheint doch immer wieder welche zu geben die in Access ihre ersten DB Schritte machen. Und ich mein, Access kann VBA, man kann da ne Oberfläche passend zur DB basteln. Ist schon verführerisch und ist recht einfach für den Anfang.^^ Gibt aber auch ältere Semester die schon ganz schön komplexe Sachen in Access aufstellen. Das sind aber die gleichen die Word Dokumente mit Tausend Seiten und Exceltabellen mit 10K Zeilen erstellen.^^
AMD Ryzen 9 5950X, Asus ROG Strix X570-F Gaming, 32GB Corsair DDR4-3200, Asus Geforce GTX 3060 12GB, Creative Sound Blaster AE-7, 240GB SSD, 500GB SSD, 3x 1TB SSD, Win11 Home, 4x Acer G246HL Bbid, Logitech MX518 Gaming Mouse, Logitech G440 Mousepad, Logitech K120 Keyboard, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#8 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.111
  • Beigetreten: 11. September 10
  • Reputation: 458
  • Geschlecht:Männlich

geschrieben 24. November 2016 - 12:28

Nur mal allgemein gefragt, weil ich das vom Ansatz her so ähnlich gemacht habe und eigentlich zufrieden damit bin. Wäre es nicht sinnvoll, eine Tabelle mit allen Firmen zu machen, eine Tabelle mit allen Personen und eine Tabelle mit allen Funktionen (also Geschäftsführer, Ansprechpartber, Sachbearbeiter usw.) und dann einfach über die IDs zu verknüpfen, welche Person zu welcher Firma gehört und welche Person welche Funktion bekleidet?
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#9 Mitglied ist offline   Phil69 

  • Gruppe: Mitglieder
  • Beiträge: 4
  • Beigetreten: 23. November 16
  • Reputation: 0

geschrieben 24. November 2016 - 15:04

Der Sinn hinter allem ist der, dass es eine Art CRM sein soll.
So dass man abbilden kann, wann wurde ein Kunde angerufen und was wurde vereinbart.
Dementsprechend ist es, da habt ihr recht, ein eher kleines Projekt.
0

#10 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.111
  • Beigetreten: 11. September 10
  • Reputation: 458
  • Geschlecht:Männlich

geschrieben 24. November 2016 - 15:15

Ich hatte mich nur kurz eingemischt, weil die Meister sich ja über die allgemeine sinnvolle Konstruktion solch einer Datenbank abstimmten. Ich will da jetzt aber nichts durcheinanderbringen, was das konkrete Projekt betrifft. Ich hab ja was ähnliches gebastelt, also so eine Art Auftragsabwicklung, Anfrage kommt, Entwurf geht raus, Kunde antwortet, Korrekturfahne geht raus, Kunde bestätigt, Materialbestellung, Eingang, Produktion, Fertig, Lieferung, Rechnung gestellt, Bezahlt, Archiv. Da das aber nun doch recht umfangreich geworden ist, ist die eigentliche Datenbank insgesamt doch ein bißchen Angefrickel geworden.
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#11 Mitglied ist offline   Phil69 

  • Gruppe: Mitglieder
  • Beiträge: 4
  • Beigetreten: 23. November 16
  • Reputation: 0

geschrieben 24. November 2016 - 15:32

Hallo Holger,
alles Gut. Die Auftragsabwicklung klingt top. Geht ja quasi in die Richtung, nur viel weiter ^^
0

#12 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.111
  • Beigetreten: 11. September 10
  • Reputation: 458
  • Geschlecht:Männlich

geschrieben 24. November 2016 - 15:45

Ja und da habe ich ja auch eine Personendatenbank und kenne die Problematiken, wenn eine Firma sowohl Kunde, als auch Lieferant ist oder eine Person zwei Firmen hat und bei einer Geschäftsführer ist, bei der anderen auch aber nur bei einer Firma der Ansprechpartner für bestimmte Projekte mit unterschiedlichen Kontaktdaten je Firma usw. und das meinen die Beiden, über was man sich vorher schon Gedanken machen muß, wie man das dann am Besten konstruiert.
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#13 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.591
  • Beigetreten: 14. August 15
  • Reputation: 392

geschrieben 24. November 2016 - 16:53

Du solltest sowieso für einzelne Rubriken eigene Tabellen anlegen. Also für Firmen, Personen, deren Funktionen etc. pp. Ich gehe z.B. auch immer soweit das ich für Anschriften, Telefonnummern, Faxnummer, Emailadressen, Handynummern immer eigene Tabellen anlegen weil diese Daten bereits bei einer Person oder Firma mehrfach vorkommen können.

Eine Verknüpfung der Daten findet dann entweder im Code statt (php, vba oder was auch immer) dann wird es von dem Server berechnet auf welchem der Code läuft oder aber man lässt dies von der Datenbank erledigen in dem man die Abfrage so formuliert, dass die Verknüpfung mit erledigt wird z.B. durch SQL JOIN, verschachtelte SELECTs und andere Möglichkeiten. Der Vorteil ist hier das die "Berechnung" von dem Server erledigt wird auf dem die DB läuft. In professionellen Umgebungen gibt es meistens Webserver oder Application-Server die den Code ausführen und für Datenbanken DB-Server. Wenn das aber beides auf einem PC, Server gemacht wird ist es egal welche Methode man nimmt.^^

Wie oben beschrieben, du kannst und solltest für alles was mehrfach vorkommen kann eigene Tabellen erstellen und außerdem auch für verschiedene Rubriken wie Firmen, Kunden, Einkauf, Verkauf, Bestand und was du alles sonst noch brauchst. Auch Positionen innerhalb einer Firma können entweder mehrfach belegt sein wie Geschäftsführer oder in der Buchhaltung etc. oder aber eine Person kann mehrere Positionen inne haben. Je größer die Firma desto mehr Personen können eine Arbeit erledigen und umso kleiner umso mehr Aufgaben fallen auf eine Person zu.

Mach es aber auch nicht zu kompliziert. Es sollte am Ende auch nur das enthalten sein was für den Einsatzzweck nötig ist.
AMD Ryzen 9 5950X, Asus ROG Strix X570-F Gaming, 32GB Corsair DDR4-3200, Asus Geforce GTX 3060 12GB, Creative Sound Blaster AE-7, 240GB SSD, 500GB SSD, 3x 1TB SSD, Win11 Home, 4x Acer G246HL Bbid, Logitech MX518 Gaming Mouse, Logitech G440 Mousepad, Logitech K120 Keyboard, Razer Tiamat 7.1 V2 Headset, Creative Inspire 5.1 5300 Soundsystem
0

#14 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 5.111
  • Beigetreten: 11. September 10
  • Reputation: 458
  • Geschlecht:Männlich

geschrieben 24. November 2016 - 18:58

Jupp, Telefonnummern sind bei mir auch wieder eine neue Tabelle. Das ganze läuft auf einem Webserver. Also ne MySQL-Datenbank und als Schnittstelle ne php-Seite, so kann man plattformunabhängig von jedem Rechner in der Firma zugreifen.
Bauernregel: Regnets mächtig im April, passiert irgendwas, was sich auf April reimt.
0

#15 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 24. November 2016 - 20:45

Telefonnummern sind immer so ne Sache. Die müßte man eigentlich auftrennen in Fest und Mobil, oder ggf anhand anderer Kriterien.

Denn Festnetztels sind Eigenschaften von zB einem Raum und müßten in der DB dort hinterlegt werden, aber Mobilföns sind Eigenschaften von Personen - also Mitarbeitern --- und müßten entsprechend *dort* hinterlegt werden, bloß wenn man jetzt Mitarbeiter sozusagen austauscht, dann ist ja wieder die Frage ob der das Telefon behalten darf oder nicht und dann bräuchte man wie angesprochen eine Referenz aufs Telefon.

Eigentlich ist Datenbankentwurf zumindest in den grundsätzlichen Zügen (und die reichen in den meisten Fällen) fast trivial, wenn man sich nur hinsetzt und drüber nachdenkt.

Zusammen gehört, was zusammen gehört. Klingt logisch? Ist es auch.
Datenbanken folgen seit Anbeginn der Tage einem Schlüssel-Wert-Prinzip, auch zu Zeiten vor RDBMS war das schon so. Bei RDBMS hat man einfach mehrere Werte zu jedem Schlüssel und kriegt so die Tabellen (= Relationen, das R in RDBMS) zusammen.
Ergo, es muß für jede semantische Einheit etwas geben, was diese eindeutig identifiziert. Beispiel: Personentabelle und als Schlüssel dafür die Personalausweisnummer. Die ist eindeutig; Name und Vorname sind es nicht, und zusammen auch nicht, und mit Geburtstag zusammen immer noch nicht, egal wie unwahrscheinlich das ist.

Das macht man für alle Zusammenhänge, die man so findet, und die man abgebildet haben will oder soll oder muß.

Als nächstes schaut man sich das an und fragt sich, okay was ist hier doppelt. Doppelt gleich schlecht, das ist sozusagen schon der zweite unumstößliche Grundsatz in RDBMS. Redundanz fliegt raus. Punkt.

Ergo, es gibt nicht wie bei Excel eine Liste von Name, Funktion, und Büro, sondern es gibt drei Tabellen jeweils für die Namen (die gehören den Mitarbeitern, ergo kommt es in diese Tabelle) eine Tabelle Funktion (das ist eine Klassifizierung, ergo haben wir eine Tabelle namens Funktion wo die einzelnen Funktionsnamen eingetragen werden, also alles von Hausmeister über Putzfrau bis hin zu Türhintermchefzumacher; und zuletzt haben wir noch eine Tabelle für die Büros, wo diese dann aufgelistet werden, zB nach Raumnummern aufgeschlüsselt (wenn diese eindeutig waren).

Erst JETZT gibt es eine vierte Tabelle, die das abbildet, was Excel vorsetzen würde. Hier stehen die Zusammenhänge drin, und zwar so, daß individuelle Bedürfnisse auch abgebildet werden können bzw Einträge nach Bedarf ausgeschlossen werden.

Entsprechend kann man also Person zu Funktion zuordnen. Das hat mit Büro vermutlich nix zu tun. Eine Zuordnung von Büro zu Funktion gibt es aber vermutlich doch wieder. Und wenn man dann noch einen Zeitstempel in die Tabelle aufnimmt und diesen dann als extra Attribut in den Tabellenschlüssel stopft, dann kann man sogar sagen, in welchen Zeiträumen welches Büro welcher Funktion zugeordnet war, ist und sein wird. Für Personen ist sowas an dieser Stelle auch dringend notwendig; denn ohne den Zeitstempel könnte man bei Beförderungen ja nicht sagen, okay letzte Woche war das ein Tellerwäscher, aber ab nächsten Morgen isser Millionär; ohne den Zeitstempel wäre der Mitarbeiter entweder das eine ODER das andere und OHNE die Möglichkeit, das zuzuordnen. Ganz schlecht für die Buchhaltung, und für die Steuer, und für die Entlohnung. :wink:

Und so haben wir jetzt schon in irgendeiner Form alle Verweistypen abgedeckt:

Ad 1; die Eins-zu-Eins-Relation, wo genau einem Schlüsel hier genau ein anderer Schlüssel da zugeordnet wird; üblicherweise Primärschlüssel-zu-Primärschlüssel oder zumindest zu Primärschlüsselkandidat.
Das macht man bei Spezialisierungs/Generalisierungstabellen. Also ich hab eine Tabelle Mitarbeiter und ich hab eine Tabelle Professoren; dann hab ich in der Tabelle Professoren natürlich einen eindeutigen Primärschlüssel, aber der ist nicht autogeneriert, sondern besteht aus den Schlüsselwerten der Mitarbeitertabelle. Somit kann ein Professor nur in de r Tabelle auftauchen, wenn er auch ein Mitarbeiter war. Andersherum muß ein Mitarbeiter natürlich nicht zwangsläufig ein Professor sein; aber *wenn* er einer ist, dann gibt es nur genau einen Eintrag in der Professorentabelle für diesen Mitarbeiter.
1-1-Relationen zeichnen sich dadurch aus, daß man sie weglassen und in eine Tabelle stopfen kann, und daß wenn man das tut sehr viele Leerfelder in dieser Tabelle landen, und/oder die gesamte Tabelle durch spezifische Eigenschaften sehr stark aufgeblasen wird (jeder Professor hat sein Foto mit in der Datenbank drin, das tun die anderen nicht. Oder sowas in der Art.) Das ist auch der Hauptgrund für diese Verknüpfungsform.

Ad 2 haben wir die eins-zu-viele Relation, wenn genau einem Objekt mehrere andere zugeordnet werden können bzw müssen. Erforderlich wird dies zB bei Büros: ohne 1-n-Relation würde in jedes Büro nur genau eine Person passen und das will man üblicherweise nicht haben.

1-n-Beziehungen zeichnen sich dadurch aus, daß sie "umgedreht" abgebildet werden. Wenn in ein Büro mehrere Mitarbeiter passen sollen, dann kommt der zugehörige Referenzwert zu den Mitarbeitern und nicht zu den Büros. Denn dem Büro ist es egal, wer da ist. Aber der Mitarbeiter muß wissen, WELCHES Büro er hat und so können auch zB zwei Mitarbeiter denselben Schlüsselwert für ihr Büro kriegen - dann sitzen sie halt beide drin. Das würde nicht funktionieren, wenn das Büro eine Referenz auf den Mitarbeiter hätte; würde man das sorum machen, hieße das, jeder Mitarbeiter kann in beliebig vielen Büros sitzen. Üblicherweise macht das eher weniger Sinn.

Und schließlich gibt es ad 3 noch die viele-zu-viele Beziehung. Die hat man, wenn man in beide Richtungen mehr als nur einen Wert zuordnen will. Hier paßt ein Beispiel aus dem Support recht gut. Person X ruft an und Mitarbeiter Y kümmert sich drum; das ist aber noch nicht erledigt und jetzt ruft Person X nochmal an und Mitarbeiter Y ist aber nicht da (andere Schicht oder was weiß ich). Also muß Mitarbeiter Z her. Gleichzeitig müssen sich aber Mitarbeiter Y und Z auch noch um Anrufer A und B und R kümmern. Kurz, mit 1-1 ist es ganz sicher nicht getan und 1-n reicht auch nicht aus.

Hier brauchen wir dann eine extra Relation, die das in Beziehung setzt. Nennen wir sie Anrufprotokoll. Hier steht dann der Zeitstempel drin (Datum plus Uhrzeit), der Mitarbeiter von uns, der Anrufer und ggf noch Notizen dazu.

Recht einfach kann man sich das geometrisch vorstellen: 1-1 ist eine Linie von hier nach da - eine Dimension. 1-n ist ein wenig komplizierter, hier hat man eine funktionale Abbildung eines Originals auf ein Bild - eine Zuordnung von der Eins zum n und damit ein zweidimensionales Konstrukt. n-m setzt beides zusammen, ist aber gemeinerweise nicht limitiert (das kann auch m-n-o oder sowas werden, wenn man Pech hat); diese Beziehungsform ist aber zumindest dreidimensional.

Das funktioniert so, weil Dimensionen ebenso wie Tabellen als "unabhängig von allem anderen" definiert sind und "nicht durch andere Dimensionen/Tabellen darstellbar" sein dürfen. 1:1 gibt es nur eine Unabhängige. 1:n gibt es davon schon zwei - zB Personen und ihre Büros. Und ab m-n gibt es zumindest drei, je nachdem, was da involviert ist: also zum Beispiel die Zuordung von Anrufern zu Zeit und Mirbeitern.


Das wars auch schon. Der Rest ist Fleißarbeit.


PS. Daten gehören nicht getrennt. Was die DB leisten kann, soll die Datenbank auch leisten. Warum? Weil nicht nur ein Client drauf zugreift. Gut, bei Access ist das ... ähm... gut. Reden wir nicht drüber ^_^ aber, angewöhnen sollte man es sich trotzdem nicht.

Daher folgen an dieser Stelle zum einen die Views - die Sichten -- die es ermöglichen, die das multidimensionale Konstrukt namens Datenbank wieder in ein maximal zweidimensionales Konstrukt namens Tabelle zu stopfen, welche man auch anschauen kann -- sowie Prozeduren und Funktionen, welche dafür sorgen, daß insbesondere 1-n-Beziehungen ohne großen Aufwand nachvollzogen werden können und/oder die der Konsistenzsicherung des Datenbanksystems selber dienen (zB in Form von Triggern). Beispiel: Eine Funktion getOfficeForUser(bigint), die für eine Mitarbeiter-ID das zugehörige Büro aus der Datenbank sucht - und insbesondere nicht nur die Büro-ID, sondern einen kompletten Datensatz, der auch noch weitergehende Informationen beinhalten kann, die nicht in der Bürotabelle vorhanden waren und/oder die überhaupt nirgendwo vorhanden waren (=> berechnet sind).

Frontends wie zB Webservern obliegt dann nur noch der simple Zugriff auf das, was durch die Views bereitgestellt wird oder, falls das tatsächlich "ungewöhnliche" Abfragen waren (also solche, die nicht standardmäßig vorkommen) dann natürlich ihre eigenen SELECTs zusammenbauen.

Je mehr man aber die Verarbeitungslast auf die Clients verschiebt, desto größere Probleme bekommt man mit der Konsistent-Haltung der Daten. Nützt einem gar nix, wenn jetzt Client A anfängt Daten zu ändern die er eigentlich gar nicht hätte ändern sollen... oder wenn Client B der Meinung war, Transaktionen in ihre Einzelteile zerlegen zu müssen. Wenn sowas passiert, kann man den Datenbestand eigentlich auch gleich wegwerfen.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0