Office: (Office 2013) Kombinationsfeld

Hallo Benny
Das ist eine schöne Lösung und ich würde diese gerne weiterverfolgen ... das mit dem Hinzufügen und Löschen der Kat. finde ich sehr praktisch! ...
Doch ich befürchte ich kann nicht ... siehe weiter unten ... *sorry*

 

Guten Tag allerseits

Leider, leider muss ich nocheinmal einen Gang zurückschalten ...
Mein Vorgesetzter sagte mir, ich soll mich für die simpelsten (einfachen) Lösungen entscheiden und die "intelligenteren" Lösungen - d.h. diejenigen, die grafisch und programmtechnisch anspruchsvoll(er) sind für später aufbewahren...
Er möchte sehen das die DB grundlegend funktioniert... Somit kommen viele intelligente Vorschläge der Forumsmitglieder (zurzeit) nicht in Frage - es fehlt die Zeit sich einzuarbeiten!
Es sieht so aus, als müsse ich einfache Checkboxen für die Mehrfachauswahl verwenden ...

Da ich keine grundlegenden Denkfehler machen möchte und eine Grundlage für eine stabile und sichere DB legen möchte, möchte ich auch nicht einfach herumexperimentieren. Es geht hier vor allem um einfache zweckmässige, sinnvolle Verknüpfungen/Beziehungen.

Ich habe hier einen Printscreen aller meiner (momentanen) Tabellen gemacht:
Printscreen_VerknüpfungenTabellen_.gif
Wie man sieht ist momentan alles noch seeehr übersichtlich ...
Es geht hier momentan weder um Kunden noch um Aufträge, sondern lediglich um Listen und Formulare um Mitarbeiter zu erfassen u.ä.
Selbstverständlich muss eine Anbindung von Kunden u. Aufträgen für die Zukunft nicht ausgeschlossen sein. Deshalb sollen die Tabellen korrekt verknüpft werden.

Erklärungen zu den Tabellen:
============================
Tab. A
>> Haupt-Tabelle der allgem. personenbezogenen Angaben/Adressen welche KEINE sensiblen Daten enthalten (wenn später weitere Personendaten wie z.B. Kunden und Lieferanten hinzukommen werde ich eine separate DB od. zusätzliche Tabellen machen)
-------------------------------------------------
Tab. B
>> Diese Neben-Tabelle (Kategorie Bezeichnungen) soll nur als Auswahl in einem Hfo dienen und wird nicht beschrieben!
Neben der Spalte: "Kat_Bezeichnung" gibt es eine Spalte: "Kategorie_Nr" als spez. Zahl welche diese Kategorie in anderen Tab. erkennbar und zuordenbar machen soll.
-------------------------------------------------
Tab. C
>> In dieser Tabelle soll eine Kombination der beiden anderen Tabellen stattfinden (Kategorie_Nr + Personen_ID)
Eine "Person" muss min. einer Kategorie angehören, kann aber auch mehreren Kategorien angehören.
Hier soll in den Spalten: "Mitarbeiter_A", "Mitarbeiter_B", "Vereinsmitglieder", etc. alle Personen_ID's eingetragen werden, die in diese Kategorie gehören! Das sind pro Spalte logischerweise diverse Personen_ID's.
-------------------------------------------------
Tab. D
>> Mehrere Zusatz-Tabellen (Eine pro Kategorie) welche alle die SENSIBLEN Angaben der Personen enthalten! (sofern vorhanden) inkl. paar Zusatzfelder.
Momentan drehen sich alle meine Fragen um die korrekte Zuordnung.
d.h. jede Kategorie: Mitabeiter A, Mitarbeiter B, Vereinsmitglied, etc. ist solch eine separate Tabelle und in jeder einzelnen Tabelle können diverse Personen_ID's sein.
Selbstverständlich darf eine Person (ID) nur einmal pro Kategorie (in dieser Zusatz-Tabelle) auftauchen!
Diese Zusatz-Tabellen (auch Kategorie-Tabellen genannt) können auch als Erweiterung bzw. Auslagerung (personenbezogener Daten) der Tab. "A" angesehen werden.

Erklärungen zur Personen_ID:
=======================
Diese ist lediglich eine Fantasieziffer (alphanumerisch) welche der eindeutigen Zuordnung einer Person dienen soll und unveränderbar mit dieser verbunden ist. Wird im Tabellenentwurf als Text definiert - nicht als Zahl.

Erklärungen zur Verknüpfung B C :
=======================
Eigentlich ist es meine Absicht "Kategorie_Nr" zu "Kat_Nr" zu verknüpfen funktioniert jedoch nicht ganz richtig...
Deshalb "ID" zu "Kat_Nr"... wahrscheinlich mache ich was verkehrt.
-------------------------------------------------

Meine Fragen betreffen vor allem diese "rudimentären" Tabellenverknüpfungen - vor allem aber die Verknüpfung und Zurdnung der Zusatz-Tabellen "D" zu den anderen personenbezogenen Tabellen "A".
Die Zugehörigkeit für "D" soll alleine aus der Tab "C" gezogen werden. A+B+C soll eine n:m Beziehung darstellen ...

Ich hoffe es ist einigermassen klar beschrieben ...
Tut mir Leid Euch mit solchen grundlegenden Fragen zu belästigen ...
Es gibt genug Themen betr. PW-Schutz und Sicherheit in diesem Forum, deshalb soll eine grundlegende Diskussion über das Thema hier vermieden werden. Trotzdem soll im Hinblick auf die spätere "Schützbarkeit" der "sensiblen" Daten von den Zusatz-Tabellen "D" bei den Verknüpfungen Beachtung geschenkt werden. Natürlich nur falls es nötig scheint!

Vielen Dank für Eure Hilfe und Eure Nachsicht meine "Kindergarten-Fragen" auszuhalten

 

So ganz bin ich nicht durch das gewünscht/vorgesehene Modell durchgestiegen.

Tabelle A scheint zu passen (zumindest das was ich im Screen und der Beschreibung entnehmen kann)
Tabelle B: Wozu zu einer ID (Primärschlüssel) die eine Kategorie eindeutig identifizierbar macht noch eine weiter "Nummer"?
Tabelle C: Scheint mir "falsch" zu sein; Mitarbeiter_A und Mitarbeiter_B sowie Vereinsmitglieder deuten auf fehlende Normalisierung hin. Weiter verstehe ich nicht was hier gespeichert werden soll ("alle Personen_IDs ... einer Kategorie")
Tabellen D: Scheinen mir überflüssig bzw. falsch zu sein; Du wirst hoffentlich nicht für jede "Personengruppierung" eine eigene Tabelle aufbauen wollen *eek.gif*

Generell: Bevor Du (bzw. Ihr (Du und Dein Chef)) euch noch weiter "verirrt" solltet ihr ein Konzept aufstellen, was die Anwendung/das Tool/die Datei bzw. Datenbank können soll und vor allem, was sie nicht können soll.
Es ist nicht zielführend "einfach mal drauf los" zu entwicklen ohne eine entsprechende Basis zu haben (die fehlt offensichtlich).
Wenn es ein Konzept (im Sinne eines Anforderungskatalogs gibt) wäre dieser hilfreich um ein Datenmodell zu erzeugen; die momentanen Beschreibungen sind mir zu "schwammig"

 

Es mag sein, dass wir die techn. Umsetzung nicht genau durchblicken, es ist aber nicht wahr das wir nicht planen und nicht wissen was wir wollen.
Das wurde alles (über Wochen) geplant und auseinandergehalten!

Zu Tab. B: Wieso ein zusätzliche Nummer ?
Weil ein Autowert nunmal hässlich ist. Und weil eine selbstdefinierte Zahl in den Tabellen für mehr Übersichtlichkeit betr. Kategorie-Zugehörigkeit sorgen soll. Ein Autowert wirkt da sehr beliebig.

zu Tab. C: Wieso deutet eine Spalten-Überschrift auf eine fehlende Normalisierung hin ? Für die Bezeichnung könnte ich auch Zahlen od. Kurzbezeichnungen nehmen - der Zweck bleibt derselbe.
Diese Tabelle ist eine Kombination aus Tab A + B und soll eine Schlüsselrolle haben. Ich habe mir auch schon überlegt die Informationen direkt in den Zusatztabellen zu speichern, aber eine Trennung von Kategorisierung und personenbezogenem Zusatz scheint mir sehr wohl zur Normalisierung beizutragen!

zu Tab. D: Doch, genau das habe ich im Sinn - jede Personengruppierung (schlussendliche ca. 10) soll eine eigene Tabelle haben.
Für einige Zusatzinformationen könnte man sicherlich eine Zusammenfassung machen, andere Informationen jedoch sind "sensibler" als andere. Deshalb eine Auseinanderhaltung pro Kategorie. Evtl. auch besser schützbar - nicht?

ich habe mich bemüht alles ganz genau zu beschreiben ... wieso schwammig?

 

In deiner Tabelle C ist der Wurm drin, mehr dazu gleich. Und die Tabs D sind eigentlich komplett überflüssig (aber du willst sensible Daten trennen, also OK). Wegen der gewünschten Trennung der sensiblen Daten vom Rest der Tabellen brauchst du aber trotzdem nicht für jede Personengruppierung eine eigene Tabelle, sondern es reicht eine Tabelle für alle Gruppen.

Zu Tab. C: Alle Felder von "MitarbeiterA" bis "Zuweiser_Berufsberater" gehören da raus. Stattdessen machst du ein neues Feld "Status" (Typ Zahl, Long Integer) in die Tabelle. Dann setzt du den Primärschlüssel in dieser Tabelle über 3 Felder: Pers_ID, Kat_Nr und das neue Feld Status. (Das Feld ID kannste dann löschen)
Ab jetzt kann jede Person mit jeder Kategorie und mit jedem Status verknüpft werden, aber jede Kombination der 3 Felder ist nur einmal möglich (wegen dem Primärschlüssel).

Jetzt machst du eine neue Tabelle mit 2 Spalten: IDStatus (AutoWert, Primärschlüssel), Beschreibung (kurzer oder langer Text)
In diese Tabelle schreibst du alle Stati in die Spalte Beschreibung rein.

In deiner Tabelle C wird dann im Feld Status die IDStatus aus der neuen Tabelle gespeichert. Mit einem Kombinationsfeld sehen die User dann nur die Beschreibung für jeden Status.

Denk mal drüber nach, das löst viele deiner Probleme glaube ich (ohne jetzt den ganzen Thread hier durchgelesen zu haben).

 

Offenbar habe ich mich missverständlich ausgedrückt... ich wollte weder unterstellen dass ihr nicht geplant habt noch dass ihr nicht sauber arbeitet. Sorry dafür.

Die Konstruktion Deiner Tabellen deutet jedoch auf ein unvollständig, nicht normalisiertes Datenmodell.
Um Zugriff auf Daten zu unterbinden/einzuschränken benötigt es mehr als eigene Tabellen.

Die TabelleC ist so nicht praktikabel (zumindest wenn ich sie richtig verstehe) und scheint eher noch nach Excelmuster (für jedes Attribut eine eigene Spalte) konstruiert zu sein.
Korrigiere mich bitte wenn ich falsch liege...

Echten "Schutz" der Daten wirst Du in Access nicht hinbekommen; wenn jemand die Datei bekommt hat er auch Zugriff auf die Daten (mit mehr oder weniger Aufwand).
Zum Thema Schutz lasse ich mich hier nicht aus, dazu findest Du im Forum mehr als einen Thread.

Zum Thema "schwammig":
Auch das war nicht böse gemeint; nur kenne ich weder die konkrete Anforderung an die gewünscht Lösung noch den aktuellen Stand jener.

 

Die Sicherheits-/Schutz-Diskussion war schon:
http://www.ms-office-forum.net/forum...d.php?t=323399

 

Vielen Dank für Deine Mithilfe
Also wenn ich das richtig verstanden habe, dann ist die Tabelle "B" entweder zu löschen oder in Deinen Vorschlag (neue Tabelle) "IDStatus" umzuwandeln.

Betr. Tabelle "C" -
Die "Kat_Nr" ist nichts anderes als die "numerische" Bezeichnung des "Status" ? ich hoffe, wir verstehen uns richtig!
Der Status ist für mich gleichbedeutend wie die Kategorie.
D.h. 10 Bezeichnungen der Stati = 10 Nummern. Ok?

Und soll ich jetzt meinen Primärschlüssel für die Tabelle "A" auf den (Auto)ID-Wert setzen? Denn wie könnte ich sonst die Tabelle "C" mit "A" verknüpfen? 2 Primärschlüssel miteinander geht ja nicht.
Betr. Primärschlüssel - "Personen_ID" für Tabelle "A" wäre doch passend ...

Betr. Tab. "D" soll ich also nur 1 Tabelle für alle Kategorien verwenden ...
Dies würde bedeuten, dass, entweder die ganze Tabelle mit demselben PW-Zugang zu erreichen wäre?
Oder kann man für 1 Tabelle die einzelnen Spalten (od. Zeilen) Zugriffsbeschränkungen pro User-Gruppe separat regeln ??

Habe ansonsten schon alles so umgestaltet wie du gesagt hast.

 

Nein, du brauchst eine neue Tabelle für den Status, nennen wir sie mal "tblStatus", in dieser Tabelle gibt es 2 Felder, IDStatus und Status.

In deiner Tabelle "C" brauchst du dann ein weiteres Feld um die IDStatus zu speichern. Dieses Feld ersetzt dann quasi die Felder von "MitarbeiterA" bis "Zuweiser_Berufberater" (und vielleicht auch die beiden Felder darunter).
Für mich ist das der Status, also ob jemand freiter Mitarbeiter ist oder nicht, und dieser Status wird dann pro Person und pro Status in je einer Zeile in Tabelle C gespeicher. Wenn also jemand sowohl MitarbeiterA als auch Vereinstmitglied udn obendrein noch Spender_Goenner ist, dann erhält diese Person 3 Zeilen in Tabelle C.

siehe oben, "Status" und "Kategorie" hat nichts miteinander zu tun

Dein Primärschlüssel in A spielt bei der Sache nur eine untergeordnete Rolle, hauptsache du hast einen. Aber natürlich ist es (fast) immer ratsam, sich die Primärschlüssel von einem AutoWert-Feld machen zu lassen.

Was du glaube ich noch nicht verstanden hast, ist der Primärschlüssen in Tab. C nach der Umwandlung:
In Tab C löscht du erst mal das Feld "ID" komplett raus.
Dann wie gesagt die überflüssigen Felder raus und ein neues Feld "IDStatus" rein, vgl. Erklärung oben.
Dann den Primärschlüssel über 3 Felder: Pers_ID, Kat_Nr und IDStatus.

einen PK über mehrere Felder zu setzen geht so:
In der Entwurfsansicht der Tabelle die 3 Felder (also 3 Zeilen) markieren und dann auf das Schlüsselsymbol, fertig!

Lass uns später über Tabelle D reden, du verwechselt ständig die Begriffe. Mach erst mal das was ich oben geschrieben habe, dann schauen wir später nach Tab. D.

 

Hallo Benny
Sorry das ich erst jetzt antworte, arbeite nur bis Do... und privat eher nicht.
Ich habe mir den Ausdruck "schwammig" nochmals durch den Kopf gehen lassen und er trifft durchaus zu!

Wir sind hier ein wenig ein Chaotenhaufen - d.h. wir wünschen uns zwar gewisse Dinge und versuchen sie auseinanderzuhalten. Die meisten hier sind EDV-mässig nicht wirklich bewandert deshalb wird das ganze auch outgesorced.
Mein Vorgesetzter u.a. arbeiten vor allem mit Word und Excel. Ich versuche Sie nur EDV technisch zu beraten... und helfe beim Denken.
Da ich selbst sehen wollte wie weit ich komme, war ich mit diesem Unterfangen einverstanden.

Ich bin eigentlich hier um als Schreiner zu arbeiten, da jedoch bis Juli keine Kapazität bestand mich sofort in der Schreinerei zu beschäftigen, machte man mir den Vorschlag ich könne versuchen solange "provisorisch" eine DB zu entwicklen (um das Chaos etwas zu vereinfachen) bis ich dann endgültig im Handwerksberuf arbeite - d.h. nicht mehr am PC.

Es ist also nur ein Versuch wie weit ich komme ...
Niemand erwartet etwas von mir und man setzt mich auch nicht unter Druck jetzt schnell noch bis Ende Juli fertig zu werden!

Betr. Sicherheit
Die DB, soll schliesslich über einen Microsoft SQL-Server laufen - mit FE und BE.
Niemand erwartet ernsthaft von mir ein Mass an Sicherheit wie man es nur von anderen DB-Modellen anderer Anbieter kennt.
Im Rahmen der Möglichkeit eben! :-))

 

Ok - ich glaube ich habe verstanden, was vielleicht noch nicht klar ersichtlich ist ist folgendes:

1. Weiss ich wie man einen Primärschlüssel über mehrere Spalten setzt ;-)

2. In der Tabelle "B" sind unter der Bezeichnung "Kat_Bezeichnung" bereits all die Bezeichnungen: D.h. Mitarbeiter A / Mitarbeiter B / Vereinsmitglied /... drinn. Ich denke diese Spalte muss ich dann auch löschen...
Deshalb denke ich könnten wir uns missverstanden haben.

Wenn Die Tabelle "B" also bestehen bleiben kann - dann wäre sie nur für die Kategorie_Nr zuständig ? Wieso Kategorie_Nr. und Kategorie-Beschreibung in 2 Tabellen aufteilen ? Ist das nötig ? Dann wären es bis jetzt 4 Tabellen !?

3. Habe ich doch gesagt, dass ich es bereits schon so eingerichtet habe wie Du vorgeschlagen hast...
Trotzdem muss ich nachfragen.

Der IDStatus (in der neu-umgestalteten Tabelle C) ist dann nur ein AutoWert-Zahl aus der neuen, zusätzlichen Tabelle tbl_Status ?
Also nicht etwa der Mitglied-Status (Aktiv/Passiv) oder ?

 

Ok, die Mißverständnisse klären sich langsam auf *wink.gif*

Ich habe dich jetzt so verstanden, dass deine Tabelle B bereits das enthält, was ich bis jetzt immer "Status" genannt habe. In diesem Sinne stimmt meine Aussage von vorhin natürlich nicht mehr, weil Status udn Kategorie sind ja dasselbe.

Also brauchst du meine Extra-Tabelle für den Status auch nicht, die hast du schon mit Tabelle B.

Aber ja, du solltest die überflüssigen Ja/Nein-Felder aus der Tabelle C entfernen, also von "MitarbeiterA" bis "Zuweiser_Berufberater" (und vielleicht auch die beiden Felder darunter). Weil diese Info wird ja durch deine Kat_Nr bereits abgedeckt.

Demnach geht der PK in Tabelle C auch nicht über 3 sondern nur über 2 Felder, nämlich Pers_ID und Kat_Nr.

Und zu Tabelle D: Das wird eine Tabelle die in 1:1-Beziehung zur Tabelle C steht. Demnach brauchst du in Tabelle D den gleichen PK wie in C, also auch wieder die beiden Felder Pers_ID und Kat_Nr.
In weiteren Feldern kannst du dann in dieser Tabelle die sensiblen Daten speichern.
Wie das Zeug später angezeigt werden soll ist dann die nächste Frage. Dafür musst du Regeln festlegen (mündlich), bspw. so etwas wie "Jeder Mitarbeiter darf seine eigenen Kategorie_Bezeichnung sehen". So eine Regel kann dann mit verschiedensten Mitteln programmtechnisch umgesetzt werden. Aber wichtig ist zuerst mal ein solides Datenmodell.

 

Ok, bleiben wir mal beim soliden Datenmodell -
Siehe Printscreens von den (unverknüpften) Tabellen und Inhalte.
Wenn ich versuche so - von meinem Verständniss her - sinnvolle Verknüpfungen zu machen, wird ständig gegen das Prinzip der referentiellen Integrität verstossen...
Was mache ich falsch ? Oder ist etwas noch nicht korrekt ?
Printscreen_Tabellen.gif
Printscreen_KatGruppe.gif / Entwurfsansicht
Printscreen_TabellenInhaltAuswahlKategorie.gif / Tabellenansicht)

Genügt in diesem Fall wenn ich den Aktiv-Status (d.h. JA/NEIN) Feld in der Zusatz-Tabelle (Erweiterung) anzeigen lasse ?

Würdest Du das Eintritt & Austritssdatum ebenfalls in die Erweiterung stellen?

Danke!

 

Bin aufm Sprung, schaue es mir heute Abend noch mal genau an, aber dieser Fehler resultiert typischerweise aus bereits vorhandenen Daten in der Tabelle, die dann eben die relationale Integrität verletzen. Musste also erst aufräumen, bevor du die Beziehung mit rel. Integrität setzen kannst.

 

Danke trotzdem!
Bis dann ...