Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Datenbank Modell Hilfestellung (Screenshots)
Gehe zu Seite 1, 2, 3  Weiter
zurück: Tabellenwerte zum Teil vergleichen weiter: Frage zu Modelltyp Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
Bootylicious
Gast


Verfasst am:
18. Jun 2013, 17:55
Rufname:

Datenbank Modell Hilfestellung (Screenshots) - Datenbank Modell Hilfestellung (Screenshots)

Nach oben
       Version: Office 2003

Hi,
ich habe vorher noch nie soetwas gemacht, hoffe demzufolge man wird
ein wenig verstehen, was mein Problem darstellt.
Ich habe Grundkenntnisse von Datenbanken durch meine Ausbildung,
fühle mich aber dennoch stark eingeschränkt in meinen Kenntnissen.

Ausgangslage: Erstellung einer Datenbank.
Ich habe dazu eine schnelle Übersicht angefertigt wie ich mir die DB
im groben vorgestellt habe: (Uebersicht.png)

die wesentlichen Bestandteile:
- Teilnehmer (mit Angaben ID,Name,Vorname ect.)
- Kostenträger (mit Angaben ID,Name, ect.)
- Kategorien ( Aufteilung in Ausbildungsgruppen zb.: Medien-Design, Grafik-Design)
- Bildung (mit Angaben von Teilnehmer + Kostenträger Angaben)

Konkrete Abbildung der Beziehungen aus Access 2003

Modell 1) (Model1.png)
Anmerkungen:
-Ich wollte zunächst alle Daten trennen und eine Abhängigkeit schaffen.
-Merkte danach recht schnell, dass dieses Modell recht kompliziert wird
und ich nicht im Stande bin, dass so zu Verwalten;;

Modell 2) (Model2.png)
Anmerkungen:
- Habe dieses Modell konkret nach der ersten Abbildung angelegt um, dass
ganze zu vereinfachen.
-Ich habe so meine Bedenken bei der Bildungs-Tabelle, ob es nicht da zu Redundanzen kommen könnte.

-----------------------------------------------------------------
Die Kategorie-Tabelle dient später der Einfachheit im Formular:
IDEE
- Übersichts Formular wo man Auswählen kann zwischen den Oberkategorien
- darauf folgen alle Teilnehmer für diese Kategorie via Abfrage

Ich hoffe es macht so einigermaßen Sinn und jemand kann mir eventuell weiterhelfen! Confused



Uebersicht.png
 Beschreibung:
 Dateigröße:  71.66 KB
 Angeschaut:  632 mal

Uebersicht.png



Model1.png
 Beschreibung:
 Dateigröße:  35.94 KB
 Angeschaut:  633 mal

Model1.png



Model2.png
 Beschreibung:
 Dateigröße:  34.26 KB
 Angeschaut:  632 mal

Model2.png


GastXY
Gast


Verfasst am:
18. Jun 2013, 18:23
Rufname:


AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,

Dein Datenmodell ist noch ziemlich wirr und mit redundanten Tabellen (zwei Anrede-Tabellen, Namen und Adressen in zwei Tabellen, ist "Kostenträger" eine Person?) und redundaten Feldern.

Mache dir am besten erstmal klar, welche Objekte du hast (Teilnehmer, Kostenträger, Bildung = Schul- bzw. Ausbildung?, Teilnehmer von Kursen, die diese Personen absolvieren müssen? Oder?).
Dann verallgemeinere: Teilnehmer sind Personen, Lehrende (falls du diese überhaupt erfassen mußt) sind Personen. "Kostenträger" scheinen bei dir auch Personen zu sein oder eine Firma einer Einzelperson, jedenfalls wenn ich mir deine Felder der Kostentabelle ansehe.

Also brauchst du eine Tabelle tblPerson.
Eine Person hat eine Adresse, manchmal auch zwei und in einem Gebäude (Adresse) können auch mehr als eine Person wohnen. Ev. mußt du auch Privat- und Dienstadresse erfassen? Also brauchst du eine Tabelle tblAdresse, welche mit der Personentabelle in einer n:m-Beziehung steht.

Was genau muß denn deine Datenbank leisten? Sollen Personen zu verschiedenen Kursen geschickt werden (dies wäre aus deiner Tabelle "Kostenträger_Teilnehmer" zu schließen, wobei der Tabellennname eher nichtsagend ist)? Oder soll von Teilnehmern (woran nehmen die teil?) der bisherige Ausbildungsstand erfaßt werden (das wäre aus deiner Tabelle "Bildung_Teilnehmer" zu schließen, wobei auch hier der Tabellenname reichlich nichtsagend und verwirrend ist).
Dies mußt du erstmal klären. Erst dann kannst du ein Datenmodell erstellen.

Die benötigten Tabellen gliedern sich ja einmal in die Stammdaten (bei den Personen sind das Name, Anrede, Geburtsdatum, Adresse) und einmal in Anwendungsdaten (Personen sollen Kurse besuchen --> Terilnehmer- und Kursverwaltung und/oder Abrechnung der Kurse).

Zur Erstellung deines Datenmodells hilft dir dieses Tutorial weiter:
Datenmodell entwickeln: Welche Tabellen und Beziehungen?
bootylicous
Gast


Verfasst am:
18. Jun 2013, 19:45
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

ugh. Ich bin erfreut über die schnelle Antwort und dennoch niedergeschlagen.

Hm. Nun ja ich muss ja einmal die Adressdaten, was da so alles mit zu gehört von jeweils den Teilnehmern und Kostenträgern erfassen, deswegen sind diese 2mal vorhanden?

Kostenträger: zuständige Unternehmen für Finanzierung von Kursen für Teilnehmer (z.B.: Arbeitsagentur mit Sachbearbeiter + Adresse)
Teilnehmer: Personen die Kurse besuchen (Kategorie Tabelle: z.B.: Hans Meier besucht Kurs Lokführer)

Ich halte es für notwendig demnach die Teilnehmer & Kostenträger in unterschiedliche Tabellen zu packen.

hmm ich fühl mich nun nur noch mehr unsicherer, was diese DB betrifft und habe so meine Zweifel ob mir da auch dieses Tutorial noch helfen kann Sad
Stehe so ziemlich auf dem Schlauch.
GastXY
Gast


Verfasst am:
18. Jun 2013, 23:20
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,
Zitat:
und dennoch niedergeschlagen.
Dazu besteht kein Grund. Die allersersten hingekritzelten Bleistiftstriche bei der Erstellung eines Datenmodell sehen bei mir auch nicht anders aus. Wink

Zitat:
Nun ja ich muss ja einmal die Adressdaten, was da so alles mit zu gehört von jeweils den Teilnehmern und Kostenträgern erfassen, deswegen sind diese 2mal vorhanden?
Die Adressdaten gehören in eine extra Tabelle. Alle in eine Tabelle. Du brauchst aber deutlich mehr Tabellen als die du bisher in deinem Modell hast, allerdings anders aufgebaut als bei dir. Beim Tabellenaufbau mußt du auch immer daran denken, daß du später, wenn neue Dinge hinzukommen wie eine weitere Telefonnummer oder eine neue Art der Kontaktaufnahme (z.B. Fax-Nr. bei einem Teilnehmer), nicht die Notwendigkeit einer Tabellenanpassung (neues Feld hinzufügen!) bestehen darf, sondern daß diese Aufgabe ohne Tabellenanpassung lediglich durch Hinzufügen eines Datensatzes zu erledigen ist.

Nehmen wir erstmal die Stammdaten mit den grundlegenden Feldern. Ich mache hier ein paar Allgemeine Annahmen. Falls die Sachverhalte bei dir anders sind, dann müßte man das Modell entsprechend anpassen.

tblPerson mit den Feldern
PersonID_P (Primärschlüssel)
AnredeID_F (Fremdschlüssel)
Nachname ("Name" ist ein sehr schlechter Feldname, da es ein von Access reserviertes Wort ist)
Vorname
Geschlecht
Geburtsdatum

tblAnrede mit den Feldern:
AnredeID_P (Primärschlüssel)
Anrede

tblAdresse mit den Feldern (könnte man natürlich auch noch weiter normalisieren:
AdresseID_P (Primärschlüssel)
Strasse
PLZ
Ort
(Land)

tblKontakt mit den Feldern:
KontaktID_P (Primärschlüssel)
PersonID_F (Fremdschlüssel --> hier gehe ich davon aus, daß jede Firma für dich mind. einen Sachbearbeiter hat und du die Firma über die jeweiligen Sachbearbeiter kontaktest, unterschiedliche Telefonnummern und Mailadressen bei mehr als einem Sachbearbeiter in einer Firma sind damit auch eindeutig einem Sachbearbeiter zugeordnet)
Kontakt (Datentyp Text)
KontaktArtID_F (Fremdschlüssel)

tblKontaktArt mit den Feldern:
KontaktArtID_P (Primärschlüssel)
KontaktArt (als Datensätze dann: Telefon, Fax, E-Mail, Mobil, Webseite, ist beliebg erweiterbar durch simples hinzufügen eines Datensatzes. Bei deiner Struktur müßtest du jedesmal die Tabellen usw. anpassen!)

tblFirma mit den Feldern:
FirmaID_P (Primärschlüssel)
Firmenname

tblPrivatAdresse mit den Feldern:
PrivatAdresseID_P (Primärschlüssel)
PersonID_F (Fremdschlüssel)
AdresseID_F (Fremdschlüssel)

tblFirmenadresse mit den Feldern:
FirmenadresseID_P (Primärschlüssel)
FirmaID_F (Fremdschlüssel)
AdresseID_F (Fremdschlüssel)

tblSachbearbeiter mit den Feldern:
SachbearbeiterID_P (Primärschlüssel)
FirmaID_F (Fremdschlüssel)
PersonID_F (Fremdschlüssel)
GueltigVon (Datumfeld)
GueltigBis (Datumfeld) --> Sachbearbeiter können ja auch wechseln Wink

Kommen wir zu den Anwendungsdaten:
Es gibt Kurse. Die Kurse gehören zu einer bestimmten Kategorie. Die Kurse werden von Teilnehmern besucht. Firmen (Kostenträger) bezahlen Kurse.

Also brauchst du noch weitere Stmmdaten:
tblKurse mit den Feldern:
KursID_P (Primärschlüssel)
Kursbezeichnung
KursKategorieID_F (Fremdschlüssel)

tblKursKategorie mit den Feldern:
KursKategorieID_P (Primärschlüssel)
KursKategorie (mit den Datensätzen Medien-Design, Grafik-Design usw)

Anwendungsdaten sind dann die einzelnen Fortbildungen:

tblFortbildung mit den Feldern:
FortbildungID_P (Primärschlüssel)
KursID_F (Fremdschlüssel)
KursBeginn
KursEnde
KostentraegerID_F (Fremdschlüssel)

tblTeilnehmer mit den Feldern:
TeilnehmerID_P (Primärschlüssel)
KursID_F (Fremdschlüssel)
PersonID_F (Fremdschlüssel)

Das erst mal als Anregung, wie das erste grobe Grundgerüst aussehen kann.
Zwischen welchen Tabellenfeldern du die Beziehungen setzen mußt, sollte anhand der Feldnamen eindeutig sein.
Du wirst natürlich noch ein paar weitere Tabellen benötigen (deine Tabelle Bildung_Teilnehmer habe ich ja noch gar nicht berücksichtigt), aber wenn man erstmal ein grobes Gerüst hat, dann kann man das anschließend verfeinern und ergänzen. Probiere es erstmal bis hierhin zu erstellen (ein Bild des Beziewhungsfensters ist immer übersichtlicher als ein langer Text) und überlege dir was du noch benötigst.

Zitat:
und habe so meine Zweifel ob mir da auch dieses Tutorial noch helfen kann
Doch, das hilft ungemein! Kann ich nur empfehlen. Exclamation
Bootylicious
Gast


Verfasst am:
19. Jun 2013, 18:19
Rufname:


AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Danke schon mal im vorraus GastXY!

Uh, ich bin mir nicht sicher um einige Verständniss Sachen und werde darauf später eingehen.

Zunächst habe ich mir, mithilfe des Tutorials den du mir entpfohlen hast + weitere Quellen mein ERM noch einmal vorgenommen und versucht, dass zu spezifizieren: (Model3.png)
Bin mir durchaus bewusst, dass da bestimmt etwas nicht korrekt ist.
Habe aber nicht wirklich die Gehirnwindungen die dafür zuständig sind alles im vollen Umfang zu erfassen;;

Konkrete Aufgabenstellung (nach erneutem Nachfragen):
- Ablage von Kundendaten + Kostenträgern in Datenbank
- Überblick welcher Teilnehmer bei welchem Kostenträger untergebracht ist

Hauptaussagen:
- Teilnehmer (Arbeitssuchende) möchten eine Fortbildung machen
- TN brauch Unterstützung von Kostenträger (Arbeitsamt) + Bildungsgutschein

ERM Form (siehe Abbildung oben)
- Teilnehmer benötigt Kostenträger
- Kostenträger finanziert Teilnehmer
- Teilnehmer beginnt Fortbildung

Überblick über Tabellen in Excel: (Tabelle.png)
---------------------------------------------------------------
zu GastXY - Vorschlag:

Ugh, ich verstehe dieses Adressen Problem nicht wirklich.
Ob ich die Adressdaten wie z.B.: Straße + PLZ + Ort in die jeweiligen
Tabellen schreibe wo ich sie brauche oder auslagere (sozusagen).
Ich finde es eher umständlich.

Desweiteren machen die Tabellen die du aufgelistet hast:
tbl Person , Kontaktart , Kontakt + Privat/Firmenadresse für mich wenig Sinn.
Diese Daten, die in diesen separaten Tabellen stehen würden, könnte ich doch
eben sogut in die jeweiligen Tabellen speichern?

Ich will eine einfache und effektive Datenbank Struktur, die später leicht zu verwalten ist.
Vielleicht steht mir wieder mein Unwissen und nicht logisches Verknüpfungsvermögen im Weg. Crying or Very sad
Nachtrag: Bootylicious am 20. Jun 2013 um 09:00 hat folgendes geschrieben:
Hmm vieleicht wäre ein Skype Telefon hilfreicher?

Ich stehe gerade ziemlich auf den Schlauch, da mir der Vorschlag den ich soweit bekommen habe,
für mich, weniger verständlich ist und ich mit meiner Methode auch nicht weit zu kommen scheine. Confused

Nachtrag: Bootylicious am 20. Jun 2013 um 09:01 hat folgendes geschrieben:
*skype telefonat Razz



Model3.png
 Beschreibung:
 Dateigröße:  135.55 KB
 Angeschaut:  650 mal

Model3.png



Tabelle.png
 Beschreibung:
 Dateigröße:  67.37 KB
 Angeschaut:  647 mal

Tabelle.png


GastXY
Gast


Verfasst am:
20. Jun 2013, 10:42
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,
Zitat:
Hmm vieleicht wäre ein Skype Telefon hilfreicher?
Ich habe kein Skype.

Zitat:
Bin mir durchaus bewusst, dass da bestimmt etwas nicht korrekt ist.
Naja, Teilnemehr "betreuen" doch nicht wirklich Sachbearbeiter bei euch? Und eine Fortbildung ist ein Objekt und kann daher niemanden "informieren". Very Happy

Die meisten Stammdatentabellen sind ja jetzt vorhanden. Jetzt mußt du euren Workflow abbilden. Also dieses:

Zitat:
Hauptaussagen:
- Teilnehmer (Arbeitssuchende) möchten eine Fortbildung machen
- TN brauch Unterstützung von Kostenträger (Arbeitsamt) + Bildungsgutschein
Wie läuft das ab? Wird eine Liste von Fortbildungen angeboten, wo ein potentieller Teilnehmer sich direkt anmelden kann? Oder müssen da noch Anträge gestellt werden, die von irgendjemandem genehmigt oder abgelehnt werden?
Bekommen alle potentiellen Teilnehmer einen Bildungsgutschein? Wie ist festgelegt, welcher Kostenträger welche Kurse bezahlt? Oder bezahlt ein Kostenträger die Fortbildung eines potentiellen Teilnehmers unabhängig vom gewünschten Fortbildungskurs?

Schreibe dir am besten mal auf, wie euer Arbeitsablauf bisher, also ohne Datenbank aussieht. Daraus werden in der Datenbank dann die Anwendungsdaten. Die Stammdaten-Attribute (Adresse, Telefon usw.) kannst du hierbei erstmal unberücksichtigt lassen, da wir die meinsten ja schon dargestellt haben in meinem obigen Entwurf. Konzentriere die jetzt erstmal gan auf den Arbeitsablauf.

Zitat:
- Ablage von Kundendaten + Kostenträgern in Datenbank
Das ist bei meinem obigen Datenmodell-Entwotf bereits mit Auswahlabfragen zu erledigen. Ist also abgehakt.

Zitat:
- Überblick welcher Teilnehmer bei welchem Kostenträger untergebracht ist
Das durchschaue ich noch nicht so ganz. Wie ist der Arbeitsablauf hier denn? Ist ein potentieller Teilnehmer (ein "Teilnehmer" ist er ja erst dann, wenn er zur Teilnahme an einem Kurs zugeordnet ist. Davor ist er ein potentieller Teilnehmer oder Antragsteller --> also redet man besser allgemein von "Person", da dies die Sache vereinfacht).

Zitat:
ERM Form (siehe Abbildung oben)
- Teilnehmer benötigt Kostenträger
- Kostenträger finanziert Teilnehmer
- Teilnehmer beginnt Fortbildung
Abhängig von der Beantwortung meiner obien Fragen zu eurem Arbeitsablauf würde ich dies etwas anders ausdrücken. Du mußt hier euren Workflow abbilden.
Fragen, die sich aus deinen obigen drei Punkten ergeben:
- "Benötigt" ein Teilnehmer einen Kostenträger? Warum? Ist es nicht eher so, daß der Teilnehmer eine Fortbildng machen möchte oder machen muß und sich somit irgendwo (beim Kostenträger oder beim Anbieter der Fortbildung?) anmelden muß bzw. dies beantragen muß?
- Finanziert der Kostenträger immer einen Teilnehmer? Oder kann es auch abgelehnt werden? Oder finanziert der Kostenträger dem Anbieter der Fortbildung seine Kurskosten?
- Der Teilnehmer kann die Fortbildung erst beginnen, wenn diese genehmigt wurde? Die Fortbildung ist ja ein übergeordneter Begriff. Welchen konkreten Kurs besucht der Teilnehmer? Es werden zu einer Fortbildung sicherlich immer wieder Kurse angeboten?

Zitat:
Ugh, ich verstehe dieses Adressen Problem nicht wirklich.
Ob ich die Adressdaten wie z.B.: Straße + PLZ + Ort in die jeweiligen
Tabellen schreibe wo ich sie brauche oder auslagere (sozusagen).
Ich finde es eher umständlich.
Wahrscheinlich weil du noch zu sehr der Excel-Denkweise behaftet bist. Wink
Es führen zwar mehrere Wege nach Rom, d.h. es gibt nicht nur das eine Datenmodell, sondern man kann es auf verschiedene Weise lösen. Bei einer sher kleinen Datenbank, wo Adressen nicht für mehrere Objekte benötigt werden und wo die Wahrscheinlichkeit gering ist, daß eine Adresse mehrfach vorkommt, könnte man diese zwar mit in die Stammdatentabelle aufnehmen, aber sobald man die Adressen an mehreren Stellen benötigt (Personen, Firmen), sollte man sie auslagern. Dies erhöht die Flexibilität, die leichtere Erweiterbarkeit der Datenbank (ist erstmal ein Kern der Datenbak vorhanden, weckt das Begehrlichkeiten, d.h. im Laufe der Zeit will man dann noch dies und jenes hinzufügen Wink ) und vor allem auch die spätere Wartung der Datenbank ungemein.

Zitat:
Ich will eine einfache und effektive Datenbank Struktur, die später leicht zu verwalten ist.
Dann solltest du es unbedingt auslagern. Wink
Gleiches in gleiche Tabelle!

Beispiel Kontakt:
Jetzt hast du in deinem Modell Telefon und E-Mail als zwei Felder direkt in der Stammdatentabelle. Nun stellst du irgendwann fest, daß du von einem Teilnehmer auch die Faxnummer erfassen mußt. Was machst du dann? Du fügst in der Tabelle ein Feld hinzu, paßt sämtliche Abfragen an, Erweiterst die Formulare usw. --> dies ist ein enormer Aufwand!
Hast du das aber nach meinem Modell ausgelagert (tblKontakt und tblKontaktArt), dann fügst du in tblKontaktart einfach einen Datensatz ("Fax") hinzu und fertig. Ohne irgendwelche Anpassungen am Datenmodell oder an den Formularen. --> super leicht zu verwalten.
Genauso leicht ist es, wenn du nun von einem Teilnehmer zwei E-Maildaressen oder Telefonnummern (Festnetz, Handy) erfassen mußt. Bei deinem Modell stehst du dann auf dem Schlauch. Bei meinem Modell fügst du diese Datensätze einfach hinzu (1:n-Beziehung zwischen Person und Kontakt).

Es lohnt sich immer, das Datenmodell so zu gestalten, daß es flexibel ist, auch wenn das am Anfang mehr Aufwand bedeutet. Für einen Anfänger mag das erstmal umständlich aussehen, wenn man die Daten auf so viele Tabellen zersplittert, aber diese Mehrarbeit bei der Datenmpdellentwicklung spart man sich tausendfach bei der späteren Wartbarkeit und Erweiterbarkeit wieder ein.
Bootylicious
Gast


Verfasst am:
20. Jun 2013, 12:13
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Erst einmal noch mal vielen herzlichen Dank GastXY für die Tatkräftige Unterstützung soweit! Embarassed

Zitat:
Naja, Teilnemehr "betreuen" doch nicht wirklich Sachbearbeiter bei euch? Und eine Fortbildung ist ein Objekt und kann daher niemanden "informieren". Razz
Meine Abbildung stellt das ganze etwas unglücklich dar;;
-Teilnehmer benötigt Kostenträger.
- Sachbearbeiter betreut Teilnehmer.
- Sachbearbeiter ist angestellt in Kostenträger.
- Kostenträger finanziert Teilnehmer.
- Teilnehmer beginnt Fortbildung.
- Sachbearbeiter wird von Fortbildung informiert.

so war es eigentlich geplant.
----------------------------------------------------------
Ich habe mich nocheinmal mit meinem Ansprechpartner ausgetauscht und
musste feststellen, dass die Datenbank schon zu Umfangreich und
für den eigentlichen Zweck schon zu "mächtig ist", wie ich finde.

zunächst folgenden Informationen zum Workflow:

- Interessent (Arbeitssuchender) meldet sich Fortbildungsunternehmen,
- Erstkontakt Daten werden aufgenommen,
--> Infomaterial wird zugeschickt,

- Person wird auf tauglichkeit überprüft
--> Eignungstests des Weiterbildungsunternehmens

- Arbeitssuchender geht mit bestanden Eignungstests zum Jobcenter,
--> Entscheidung über Zusage oder Ablehnung,
- wenn bestanden,dann Eintragung als Teilnehmer für Kurs

Zweck der Datenbank:
- Aufnahme der Erstkontaktdaten der Personen
=> Übernahme der Person als Teilnehmer für dementsprechenden Kurs

Sodass am Ende eine Formularübersicht erstellt werden kann, mit allen Teilnehmern, der entsprechenden Kurse.
Gast



Verfasst am:
20. Jun 2013, 12:40
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,
Zitat:
dass die Datenbank schon zu Umfangreich und
für den eigentlichen Zweck schon zu "mächtig ist", wie ich finde.
Unterschätze das nicht! Eine Datenbank für euren Zweck ist schon recht komplex. Wird das beim Datenmodell nicht berücksichtigt, dann kann man besser gleich bei Excel bleiben. Access benötigt als relationale Datenbank nun mal einen völlig anderen Tabellenaufbau als Excel.

Zitat:
- Aufnahme der Erstkontaktdaten der Personen
Ist bereits größtenteils erfüllt. Es fehlen jetzt nur noch die Stammdaten für die Kurse.

Zitat:
=> Übernahme der Person als Teilnehmer für dementsprechenden Kurs
Dazu muß euer Workflow abgebildet werden. Ich schaue mr das heute abend mal genauer an.

Zitat:
Sodass am Ende eine Formularübersicht erstellt werden kann, mit allen Teilnehmern, der entsprechenden Kurse.
Mit einem passenden und flexiblen Datenmodell läßt sich das dann recht schnell "zusammenklicken". Wink
Bootylicious
Gast


Verfasst am:
20. Jun 2013, 12:54
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Zitat:
Eine Datenbank für euren Zweck ist schon recht komplex.
Ich unterschätze nicht die Komplexität einer Datenbank. Finde es nur sehr
schwierig, was ich alles mit einbeziehen muss und wie alles später miteinander Verknüpft werden sollte.

Zitat:
Dazu muß euer Workflow abgebildet werden. Ich schaue mr das heute abend mal genauer an.
Ah vielen Dank, dass wäre echt super nett.
Ich verstehe das Problem nicht ganz, warum der Workflow abgebildet werden muss?

Könnte man nicht einfach eine seperate Datenbank anlegen nur für die Aufnahme
der Erstkontaktdaten, erstellt dann eine zweite Datenbank die sich mit der Eingliederung der Person bzw Übernahme der Person in die Kurse beschäftigt und zum Schluss verknüpft man beide Datenbanken für die Übersicht im Formular?
Confused
GastXY
Gast


Verfasst am:
21. Jun 2013, 09:41
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,

Bin gestern abend nicht mehr dazu gekommen zu antworten.
Zitat:
Finde es nur sehr
schwierig, was ich alles mit einbeziehen muss und wie alles später miteinander Verknüpft werden sollte.
Ja, das Datenmodell ist immer der schwierigste Teil einer Datenbankentwicklung. Hier muß man am meisten "Gehirnschmalz" investieren.

Zitat:
Ich verstehe das Problem nicht ganz, warum der Workflow abgebildet werden muss?
Der Zweck einer Datenbank ist doch, daß sie einem die tägliche Arbeit erleichtern und die Arbeitsabläufe zu automatisieren. Das geht aber nur, wenn der Workflow in der Datenbank abgebildet wird, zudindest teilweise, d.h. für den Abschnitt des Workflows, für den man die Datenbank einsetzen will. Es werden in einer Datenbank ja nicht nur Informationen über reale Objekte (Personen, Kurse, Firma) und deren Attribute aneinandergereiht, sondern man will etwas tun mit den Daten (Verteilung der Teilnehmer auf die Kurse). Dies muß aber im Datenmodell berücksichtigt werden bzw. der Workflow bestimmt wie die Daten zusammen gehören. Der Workflow beeinflußt also ganz entscheidend das Datenmodell.

Zitat:
Könnte man nicht einfach eine seperate Datenbank anlegen nur für die Aufnahme
der Erstkontaktdaten, erstellt dann eine zweite Datenbank die sich mit der Eingliederung der Person bzw Übernahme der Person in die Kurse beschäftigt und zum Schluss verknüpft man beide Datenbanken für die Übersicht im Formular?
Nein, das ist eine ganz schlechte Idee. Ein Access-Frontend ist zwar in der Lage, auf Tabellen zuzugreifen, die in mehreren Backends verteilt sind, aber Access kann zwischen den Tabellen verschiedener Backends keine referentielle Integrität setzen. Und auf die referentielle Integrität sollte man bei den Tabellenbeziehungen nicht verzichten!

Zitat:
Zweck der Datenbank:
- Aufnahme der Erstkontaktdaten der Personen
=> Übernahme der Person als Teilnehmer für dementsprechenden Kurs
Dann sind wir ja schon fast fertig mit dem ersten Entwurf (Verfeinerungen und Ergänzungen kommen bestimmt noch wenn man erstmal reale Daten drin hat Wink ). Ich nehme hier meinen Entworf als Grundlage.
Ändere die beiden letzten Tabellen wie folgt:

tblFortbildung mit den Feldern:
FortbildungID_P (Primärschlüssel)
KursID_F (Fremdschlüssel)
KursBeginn
KursEnde

tblTeilnehmer mit den Feldern:
TeilnehmerID_P (Primärschlüssel)
TeilnehmerID_F (Fremdschlüssel zu tblPerson.PersonID_P)
SachbearbeiterID_F (Fremdschlüssel zu tblPerson.PersonID_P)
KursID_F (Fremdschlüssel)
Bildungsgutschein_??? (gibt es da mehrere unterschiedliche oder wird hier nur ja/nein erfaßt?)

Bei den Teilnehmern hast du noch Schulabschluss und Berufsabschluss aufgeführt. Dazu braucht es zwei weitere Tabellen:
tblAusbildung mit den Feldern:
AusbildungID_P (Primärschlüssel)
PersonID_F (Fremdschlüssel)
AbschlussID_F (Fremdschlüssel)

tblAbschluss mit den Feldern:
AbschlussID_P (Primärschlüssel)
Abschluss (Textfeld, Datensätze z.B. Abitur, Tischlermeister usw., also alle Abschlüsse, sowohl die Schulabschlüsse als auch die Berufsabschlüsse)

In deinem ersten Tabellenentwurf hast du noch "Anstellung nach Maßnahme". Was genau mußt du da erfassen? Nur ja/nein oder auch wo und als was und ab wann?
Wenn nur ja/nein, dann kann dieses mit in die tblTeilnehmer mit rein, anderenfalls brauchst du da wieder weitere Tabellen (je nachdem was da erfaßt werden muß).

So, nun kannst du ja mal diesen Datenmodellentwurf in Access erstellen und dann das Beziehungsfenster hier einstellen. Die Texte mit den Tabellenentwürfen sind inzwischen so lang, daß man da die Übersicht verliert. Es ist anhand eines Bildes besser zu erkennen, ob das Datenmodell so einigermaßen stimmt oder wo noch Anpassungen gemacht werden müssen.

Für die Primärschlüsselfelder AutoWert-Felder nehmen. Und du solltest die Primärschlüsselfelder nicht nur ID nennen, denn dann weist du später bei den Abfragen nicht mehr, welches Feld mit namen "ID" nun gemeint ist wenn du Joins aus mehreren Tabellen machen mußt.
Bootylicious
Gast


Verfasst am:
24. Jun 2013, 09:22
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Entschuldigung, dass ich jetzt erst so spät antworte.
Aber ich habe das ganze Datenbank "Problem" erst einmal sacken lassen über das Wochenende um wieder einen klaren Kopf zu bekommen.

Und habe soweit eine Datenbank / Tabellenstruktur erstellt: (siehe Anhang)

Zur Anstellung nach Maßnahme:
- Datenaufnahme von Teilnehmer wo und als was dieser Arbeit gefunden hat. (kein Datum)
------------------------------------------------------
Ich habe mir noch ein wenig Denkanstöße geholt von Zweitpersonen.

Wenn Person zum Bildungsträger kommt und dessen Personalien aufgenommen werden,
kann er doch bei Eignung sofort als Teilnehmer in den Kurs gesteckt werden.
Deshalb wäre die Teilnehmertabelle nicht notwendig, da die Daten in dieser exakt mit denen der zuvor aufgenommenen Person übereinstimmen.

Dann müsste nur zwischen der Person und dem Kurs die Tabelle entsprechend gestaltet werden. Finde diesen Vorschlag eigentlich sehr gut Surprised



Beziehungen.png
 Beschreibung:
 Dateigröße:  51.87 KB
 Angeschaut:  560 mal

Beziehungen.png


Gast



Verfasst am:
24. Jun 2013, 10:25
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,
Zitat:
Deshalb wäre die Teilnehmertabelle nicht notwendig, da die Daten in dieser exakt mit denen der zuvor aufgenommenen Person übereinstimmen.
Du hast das Prinzip der Datenmodellierung immer noch nicht verstanden. Confused Löse doch vollständig von der Excel-Denkweise! Exclamation
Ich habe kein Wort davon gesagt, daß du in der Teilnehmertabelle die Personendaten (Adresse...) nochmal aufnehmen sollst. Warum hast du das nochmal in die Teilnehmertabelle gepackt?

Merke: Daten werden in einer relationalen Datenbank nur an einer Stelle ein einziges mal erfaßt!

Damit dies funktioniert, muß man mit dem Datenmodell Beziehungen zwischen Felder der Tabellen (Primärschlüssel - Fremdschlüssel) setzen. Zwischen der Personentabelle und der Adress-Tabelle besteht eine Beziehung. Über den Fremdschlüssel ist ein Datensatz eindeutig einem Primärschlüssel (und somit einem Datensatz in einer anderen Tabelle) zugeordnet.
In der Teilnehmertabelle gibt es nun den Fremdschlüssel PersonID_F. Da Einer Persone in der Personentabelle eine Adresse aus der Adresstabelle zugeordnet ist, ist dadurch auch dem Teilnehmer eine Adresse zugeordnet. Eine erneute Zuordnung der Adresse in der Teilnehmertabelle ist absolut überflüssig. Das Feld Adresse_ID (du solltest dir wirklich eine Kennzeichnung bei der Benennung der Felder angewöhnen ob eine ID ein Primär- oder Fremdschlüssel ist) hat also in der Teilnehmertablle nichts verloren.

Gleiches gilt für das Feld Kontakt_ID in der Adresstabelle. Das gehört dort nicht hin (hatte ich bei meinem Entwurf auch nicht so geschrieben), da der Kontakt bereits mit der Personentabelle in Beziehung steht.

Auch die Felder zum Abschluß gehören nicht in die Personentabelle. Die stehen doch mit der Person in einer n:m-Beziehung. Bilde doch mal die in dem Link angegebenen Sätze:
Eine Person kann mehrere Abschlüsse haben (Abitur, Tischler-Geselle, Tischler-Meister)
Ein Abschluß kann von mehreren Personen gemacht werden (ein Abitur machen viele Personen).
Dann dürfte klar sein, daß dein Modell an der Stelle nicht stimmt.

Die Tabellen Kurs und Fortbildung sind ebenfalls falsch in Beziehung gesetzt und da ist wegen der Textform auch bei meinem Vorschlag was durcheinander geraten (ein Bild ist eben doch besser als nur Text Wink ):

Das Feld Kurs_ID in der Tabelle Teilnehmer muß eigentlich Fortbildung_ID heißen, da ja ein Teilnehmer eine bestimmte (Kursbeginn, Kursende) Fortbildung macht. Allerdings dürfte es sich hier eher um eine n:m-Beziehung handeln:
Ein Teilnehmer kann mehrere Fortbildungen machen.
Eine Fortbildung wird von mehreren Teilnehmern besucht.

Die Tabelle Kurs ist eigentlich die Tabelle KursArt.

Soweit erstmal die Dinge, die mir sofort ins Auge gesprungen sind. Mache erstmal die Korrekturen, dann sehen wir weiter bzw. können uns dem Kern (Teilnehmer zu Fortbildungen schicken) widmen.
Bootylicious
Gast


Verfasst am:
24. Jun 2013, 12:09
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Crying or Very sad ugh. Mir fällt es ein wenig schwer, die ganzen Verbindungen nach zuvollziehen.
Ich dachte nur, dass da eine Verbindung fehlt zwischen dem Teilnehmer und Adresse.
Wie bekommt sonst der Teilnehmer seine dementsprechnde Adresse zugeordnet?
Über den Kontakt? Ich bin leicht verwirrt;;

Natürlich kann auch ein Teilnehmer mehrer Schul - sowie Berufsabschlüsse haben.
Aber wenn ich die Daten nur einmal aufnehme....kann ich die Problemlos an passender Stelle anhängen.
Ugh ich will schon garnicht daran denken, wie ich das Formular gestalten muss bei so einer Komplexen Struktur. Confused

Hier die hoffentlich verbesserte Übersicht:



Beziehungen.png
 Beschreibung:
 Dateigröße:  49.72 KB
 Angeschaut:  567 mal

Beziehungen.png


Gast



Verfasst am:
24. Jun 2013, 12:37
Rufname:

AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Hallo,

Nur kurze Antwort, da wenig Zeit z.Zt. Ich schaue mir später das Modell nochmal genauer an.

Zitat:
Wie bekommt sonst der Teilnehmer seine dementsprechnde Adresse zugeordnet?
Das habe ich doch versucht, in meinem Post von vorhin zu erklären:
Über die Personentabelle!
Ein Adressdatensatz ist über die Beziehung (Adressetabelle mit Personentabelle) einem Personen-Datensatz zugeordnet, und ein Teilnehmer-Datensatz ist über eine weitere Beziehung (Teilnehmertabelle mit Personentabelle) einem Personendatensatz zugeordnet. Somit ist auch die Adresse des Teilnehmers bekannt ("Beziehungskette" Teilnehmer --> Person --> Adresse). Analog beim Kontakt und beim Abschluß.

Zitat:
Aber wenn ich die Daten nur einmal aufnehme....kann ich die Problemlos an passender Stelle anhängen.
Du solltest es datenbankkonform (ein Google-Stichwort für dich: "Normalisierung") "anhängen" (= in passender Weise in Beziehung setzen). Ansonsten handelst du dir später bei der Erstellung der Abfragen und Formulare Probleme ein, d.h. du mußt komilizierte Klimmzüge veranstalten und wohlmöglich bei jeder kleinsten Erweiterung deine Tabellen ergänzen und somit dann auch alle Abfragen und Formulare anpassen ("von hinten durch die Brust ins Auge"). Sowas will man aber in einer relationalen Datenbank nicht. Man möchte dort bei Erweiterungen nur Datensätze eintragen ohne an den Entwürfen herumfrickeln zu müssen. Wink

Zitat:
Ugh ich will schon garnicht daran denken, wie ich das Formular gestalten muss bei so einer Komplexen Struktur
Keine Panik. Bei Formularen arbeitet man bei Tabellen, die miteinander in 1:n- oder n:m-Beziehung stehen, mit Hauptformularen und darin eingebetteten Unterformularen und mit Kombinationsfeldern. Sind diese korrekt verknüpft, so kümmert sich Access automatisch um den Eintrag des korrekten Fremdschlüssel-Wertes. Der Anwender bekommt von der komplexen Tabellenstruktur nicht das geringste mit und auch die ID-Felder bekommt der Anwender niemals zu sehen.
Bootylicious
Gast


Verfasst am:
24. Jun 2013, 13:01
Rufname:


AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot - AW: Access 2003 - Datenbank Modell Hilfestellung (Screenshot

Nach oben
       Version: Office 2003

Nun ja, ich sage mal die Datenbank erstellen ist das eine.
Die Daten hineinekommen via importieren von Excel Daten ist wieder etwas anderes.
Weil ich dort natürlich die Datenbankstruktur mit einbeziehen muss und auch entsprechend abändern muss. Confused

Ja, ich kenne den Begriff Normalisierung und ich war noch nie begeistern von,
weil ich es meistens nie wirklich hinbekommen habe aufgrund meiner mangelnden Umsichtigkeit;;
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Gehe zu Seite 1, 2, 3  Weiter
Diese Seite Freunden empfehlen

Seite 1 von 3
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: Drucken der Datenbank Struktur? 2 KleinerPrinz 4255 15. Jul 2006, 22:22
KleinerPrinz Drucken der Datenbank Struktur?
Keine neuen Beiträge Access Tabellen & Abfragen: Datenbank aktualisieren und Datensatz automatisch ersetzen 0 HappyDC 4558 07. Jul 2006, 13:02
HappyDC Datenbank aktualisieren und Datensatz automatisch ersetzen
Keine neuen Beiträge Access Tabellen & Abfragen: Brauche eine Datenbank zur Bestandsverwaltung. 1 Gast 5891 15. Jun 2006, 12:43
Snow Brauche eine Datenbank zur Bestandsverwaltung.
Keine neuen Beiträge Access Tabellen & Abfragen: Datenbank für online Dienstplan erstellen 1 frederik 5492 21. Apr 2006, 10:45
s_drink Datenbank für online Dienstplan erstellen
Keine neuen Beiträge Access Tabellen & Abfragen: Daten aus einer anderen Datenbank in Access übernehmen 1 Gast Andreas 1502 22. Jan 2006, 19:34
jens05 Daten aus einer anderen Datenbank in Access übernehmen
Keine neuen Beiträge Access Tabellen & Abfragen: live Mitschnitt von rs232 zu MAccess Datenbank ??? 1 Peter Müller 983 21. Jan 2006, 17:24
Gast live Mitschnitt von rs232 zu MAccess Datenbank ???
Keine neuen Beiträge Access Tabellen & Abfragen: HILFE - Datenbank zur Angebotserstellung 2 Gast 1398 11. Nov 2005, 11:37
LadyRain HILFE - Datenbank zur Angebotserstellung
Keine neuen Beiträge Access Tabellen & Abfragen: Datenbank - Tabelle mit Kalender Übersicht 0 Black is Back 1901 23. Sep 2005, 20:16
Black is Back Datenbank - Tabelle mit Kalender Übersicht
Keine neuen Beiträge Access Tabellen & Abfragen: access datenbank zum dokumentieren 8 siegpes 1097 09. Sep 2005, 08:27
siegpes access datenbank zum dokumentieren
Keine neuen Beiträge Access Tabellen & Abfragen: Suche Strasse, Ort, PLZ Datenbank 0 Snow 3763 01. Sep 2005, 09:18
Snow Suche Strasse, Ort, PLZ Datenbank
Keine neuen Beiträge Access Tabellen & Abfragen: Finanzplan in einer Datenbank umwandeln 3 karim 1136 30. Aug 2005, 09:55
cablit Finanzplan in einer Datenbank umwandeln
Keine neuen Beiträge Access Tabellen & Abfragen: Personal Datenbank, bloß wie?!? 3 derschroe 3576 09. Apr 2005, 12:55
derschroe Personal Datenbank, bloß wie?!?
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: PHP Forum