Access-o-Mania

Hallo Forum,

Ich habe ein Problem, wenn ich mehrere Gruppen von abhängigen Kombifelder in einem Formular benutzen möchte.

Ich fange einfach mal an und erkläre kurz was ich realisieren möchte:

Ich habe mehrere Tabellen (tblKategorie, tblHersteller, tblArtikelKatalog).
In einem Formular frmEquipment, möchte ich abhängige Kombinationsfelder mit Daten aus den obigen Tabellen füttern.
Diese Datensätze werden in einer weiteren Tabelle (tblEquipments) eingetragen. Hier werden jeweils nur die ID´s eingetragen, so wie es ja auch sein sollte.
Im Formular sind auch noch zusätzliche Textfelder vorhanden, die bei der Auswahl eines Artikels dann automatisch ausgefüllt werden, mit den Daten aus der tblArtikel.
Das alles habe ich bis hierhin auch gut hinbekommen und funktioniert.

Und jetzt zum Problem:
Jetzt habe ich versucht im gleichen Formular eine weitere Gruppe abhängiger Kombinationsfelder hinzuzufügen, und ein paar dazugehörige Textfelder für weitere Detailinformationen. Hier sollte wiederum aus den oben genannten Tabellen ein weiterer Artikel ausgewählt und automatich die dazugehörige Textfelder ausgefüllt werden können.
Zweck ist hier dass zu einem ausgewählten Artikel (z.B. eine Leuchte) auch noch ein Zubehör ausgewählt werden kann (z.B. Leuchtmittel). Auch diese Daten sollen im tblEquipment gespeichert werden.

Ich habe versucht den enstprechenden Code für die abhängige Kombifelder zu erweitern, aber nicht wirklich erfolgreich.Ich kriege es einfach nicht hin.
Ich kann jetzt wohl in der 2. Kombifeldgruppe ein Artikel auswählen, jedoch werden die dazugehörigen Textfelder mit den weiteren Infos zum Artikel nicht mit aktualisiert.
Irgendwie sind die Zubehör-Textfelder an das Equipment gebunden, denn diese ändern immer mit wenn ein Equipment geändert wird und nicht wenn ein Zubehör geändert wird.

Ich hoffe es einigermassen verständlich erklärt zu haben. Eine Kopie der DB ist im Anhang.

Gibt es vielleicht hier eine Beispiel DB mit mehreren abhängigen Kombifeldgruppen, woran ich mich inspirieren könnte?

Ich bitte um Hilfe

Vielen Dank im Voraus
Gruss
Kei-Koo

[Anhang gelöscht durch Administrator]

Hallo,

ich denke mal, dass die Tabellenstrukur Mängel besitzt.



Wenn ein Equipment irgend eine Zusammenstellung aus einem (Haupt-) Artikel und evtl. mehreren (Zubehör-) Artikeln besteht, dann fehlt die Tabelle "tblEquipmentZubehöre", die 1:n mit tblEquipment in Beziehung stehen muß.

Die Felder KategorieID, HerstellerID, ZubehörartukelID, ZubehörKategorieID, ZubehörHerstelleID in Tabelle tblEquipments sind falsch/überflüssig und müssen entfernt werden,


Abhängige  Kombifelder sind m. E. nur für die Auswahl des (Haupt-) Artikels  (Artikel_ID in tblEquipments) sinnvoll, (desgl. für den ZubehörArtikel in tblEquipmentZubehöre)


Weiterhin sollte (muss) tblArtikelkatalog von den Feldern "Zubehör...." befreit werden, dafür aber ein Feld ("ArtikelTyp") eingebaut werden, das einen Artikel als Haupt- oder Zubehör-Artikel einstuft.


Dieses Feld wird als Kriterium für das gebundene Auswahlkombi "ArtikelID" in tblArtikelkatalog und für das (angenommene) Auswahlkombi "ZubArtikelID" in tblEquipmentZubehöre herangezogen.



Wenn es immer nur max einen Zubehörartikel gibt (aber auch NUR dann) , ist die Tabelle  tblEquipmentZubehöre überflüssig und (nur) das Feld ZubehörArtikelID kann in tblArtikelkatalog verbleiben.

Hallo,

habe mir die DB mal schnell ohne besonders in die Tiefe zu gehen angeschaut...

Die Datenherkunft des frmEquipment beruhtr auf einer Abfrage, damit das Ganze Sinn macht muss das Recordset aber aktualisierbar sein - ist es das?

Die Datenherkünfte ALLER Kombis bauen auf UNION - Abfragen auf ----  WOZU? Ein einfaches SELECT mit ID und Bezeichnung als Felder genügt doch.

Bei dem Aufgbau wäre es nur möglich ein einziges Zubehör je Artikel zu definieren - ist das wirklich so gewünscht?

ZITATE von DF6GL

ZitatAbhängige  Kombifelder sind m. E. nur für die Auswahl ....
.... ich denke mal, dass die Tabellenstrukur Mängel besitzt ...

Was im allgemeinen interessant wäre:  Was soll die DB leisten, welche Aussage soll aus den gesammelten Daten gezogen werden können - also grob gesagt wozu dient sie?

Hallo,
und schon mal vielen Dank für die ersten Beiträge hier.

Ich muss auch mal nachreichen dass ich relativ unbefleckt bin, was Access angeht.
Arbeite seit Jahre mit Datenbanken, aber nur als Frontend User. Dies ist mein erster Versuch
eine eigene DB aufzusetzen. Deshalb, bitte die Antworten auch entsprechend formulieren.

@DF6GL
Zu Punkt 1:
Das ist ja nur für den Fall dass mehr als 1 Zubehör pro Equipment möglich sein sollte!??
Bis jetzt bin ich immer von einem möglichen Zubehör ausgegangen (wäre schon froh gewesen das hinzubekommen). Bin noch nicht sicher ob aber auch mehrere Zubehör möglich sein müssen.
Wäre vielleicht sinnvoll es so zu programmieren das diese Möglichkeit besteht.

Zu Punkt 2:
Hmmm, warum sind die überflüssig. Kann ich im Moment leider nicht verstehen?

Zu Punkt 3:
Das verstehe ich jetzt auch nicht. Soll das heissen dass es immer nur eine Gruppe abhängiger Kombifelder pro Formular gibt. Oder wie soll ich das verstehen?

Zu Punkt 4 & 5:
???, das wirft das ganze Konzept meiner DB jetzt um.....

Zu Punkt 6:
Siehe zu Punkt 1


@ Database

ZitatDie Datenherkunft des frmEquipment beruhtr auf einer Abfrage, damit das Ganze Sinn macht muss das Recordset aber aktualisierbar sein - ist es das?

Wenn ich die Frage richtig verstanden habe, denke ich schon dass es das ist.

ZitatDie Datenherkünfte ALLER Kombis bauen auf UNION - Abfragen auf ----  WOZU? Ein einfaches SELECT mit ID und Bezeichnung als Felder genügt doch.

Hmm, dazu muss ich sagen dass ich diesen Teil meiner DB aus Beispieldatenbanken aus dieser und anderen Internetseite habe. Daraus habe ich mir meine Kombifelder sozusagen angepasst.
Ob es nicht vielleicht anders und besser geht...., das weiss ich nicht.
Falls es aber eine bessere Lösung gibt, bin ich ganz Ohr.

ZitatBei dem Aufgbau wäre es nur möglich ein einziges Zubehör je Artikel zu definieren - ist das wirklich so gewünscht?

Wie bereits hier oben unter "zu Punkt 1:" geschrieben, wäre es sinnvoller es mal so zu Programmieren dass es flexibler benutzt werden kann.

ZitatWas im allgemeinen interessant wäre:  Was soll die DB leisten, welche Aussage soll aus den gesammelten Daten gezogen werden können - also grob gesagt wozu dient sie?

Ich denke auch dass es hilfreich ist, wenn ich mal erleutere was mit dieser DB gemacht werden soll:

Zweck dieser DB ist es eine elektrische Installation zu dokumentieren.
Es sollen alle eingebaute Equipments erfasst werden, mit deren Einbauort, z.B:
- Ein Gerät aus der Kategorie "Aktoren" z.B. ein Schaltaktor, vom Hersteller ABB, Typ xyz, Bestellnummer 2222,  ist eingebaut im Schaltschrank Nr1, im Obergeschoss, Raum1.
- Ein Gerät aus der Kategorie "Leuchten" z.B. eine Deckeneinbauleuchte, vom Hersteller EVN, Typ abc, Bestellnummer 1111, ist eingebaut in der abgehängten Decke, im Erdgeschoss, Raum2.
Zu dieser Leuchte gibt es noch ein Zubehör aus der Kategorie "Leuchtmittel", z.B. eine Halogen NV Lampe, vom Hersteller OSRAM, Typ 0815, Leistung 20W, Bestellnummer 12345
- usw.
Diese Informationen sollen alle in einer Tabelle tblEquipments gesammelt werden und über ein Formular frmEquipments eingegeben werden. Die abhängige Kombifelder dienen logischerweise dazu die Auswahl übersichtlicher zu gestalten.

In einem weiteren Schritt soll auch noch eine Tabelle erstellt werden, mit den vorhandenen Kabel dieser Installation. Hier soll es möglich sein in einem Formular mittels abhängigen Kombifelder den Kabeltyp aus dem ArtikelKatalog zu wählen und diesen Datensätze mit weiteren Informationen wie z.B. Kabellänge zu ergänzen.
Hier soll das Kabel dann auch an 2 Equipments gebunden werden, um sozusagen den Startpunkt und Endpunkt des Kabels zu definieren.
Im Formular frmKabel sollte man dann sehen dass ein Kabel ABC das Equipment XY mit dem Equipment NM verbindet.

Ich denke hiermit relativ genau beschrieben zu haben, was die DB jetzt abdecken sollte und hoffe auf eure Hilfe um es auch richtig umzusetzen zu können.

Falls der Ansatz den ich beim programmieren meiner DB nicht der richtige oder beste ist, wäre ich mit eurer Hilfe auch gerne bereit es so umzustellen wie ihr es mir empfehlen würdet.

Ich freue mich über jede Hilfe.

Gruss

Kei-Koo

Hallo,

kurz und gut eine Art Stückliste für durchgeführte oder durchzuführende Insatllationen.
Diese Stücklisten sollten einem bestimmten Projekt zugeordnet werden können - sonst machts ja keinen Sinn.
Wobei sich diese Projekte durch einen Standort, Projektort, Auftraggeber, Auftragsnummer etc. definieren können.

Zusätzlich soll nicht nur eine Stückliste mit Preisinformationen herauskommen sondern auch ersehen werden können wo und wozu das Equipment verwendet wurde.

Eine nicht uninteressante Geschichte!

So nun noch zu deinen Verständnisfragen ... 

ZitatWäre vielleicht sinnvoll es so zu programmieren das diese Möglichkeit besteht

JA

ZitatHmmm, warum sind die überflüssig. Kann ich im Moment leider nicht verstehen

Weil sie bereits in der Artikeltabelle enthalten sind.
Zudem werden einige (viele) Felder aus der Artikeltabelle verschwinden (vor allem die, die idente Informationen beinhalten)

Zitatdas wirft das ganze Konzept meiner DB jetzt um

Wenn du mit meiner obigen Definition einverstanden bist, wird es auch in Hinblick auf die Informationen, die du von DF6GL erhalten hast darauf hinauslaufen.  :-\

Wobei ich bemerken muss, dass du dich schon redlich bemüht hast - aber es geht ein bisschen richtiger auch noch ...   ;) ::)

Hallo,

Ja, genau so was soll die DB können :-)
Richtig bemerkt, die Projekte sollen auch anhand eines Projektname und paar weiteren Infos definiert werden.

- Ich werde jetzt auf jeden Fall die flexiblere Variante, was die Zubehöranzahl angeht, anstreben.

- Und jetzt habe ich es auch bemerkt, da hatte ich wohl nen Brett vorm Kopf.
Die aufgezählten Felder müssen in der Tat aus dem tblEquipment raus, da ja sonst redundante Informationen vorhanden sind. Eigentlich hatte ich diesen Punkt auch im Kopf, da ich aber Probleme mit der Anzeige einiger Informationen im Formular hatte, bin ich irgendwann diesen Weg gegangen ohne auf redundante Informationen zu achten.
Mea culpa

- Ich habe deiner Definition nichts entgegen zu bringen und bin auch bereit die entsprechende Änderungen an der DB vorzunehmen.
Ich habe nochmals Punkt 4 & 5 von DF6GL gelesen und da heisst es ja dass die Artikel im ArtikelKatalog einen ArtikelTyp zwecks Zuordnung bekommen sollen (Equipment oder Zubehör).
Kann in diesem Fall dann ein Artikel immer noch Equipment und Zubehör sein.
oder wird das ein weiteres Problem darstellen?

Jetzt muss ich nur mal sehen wo ich den Hebel richtig ansetzen tue.........

ZitatWobei ich bemerken muss, dass du dich schon redlich bemüht hast - aber es geht ein bisschen richtiger auch noch ...   Zwinkernd Augen rollen

richtiger gehts immer...... :D, und ich bin ja bereit was dazu zu lernen

Danke
Gruss
Kei-Koo

Hallo,

ZitatKann in diesem Fall dann ein Artikel immer noch Equipment und Zubehör sein.

Ist das denn bislang der Fall? Kann eine Leuchte denn Artikel und Zubehör zugleich sein?

Nur ... die Klassifizierung alleine wird nicht verhindern, dass ein Leuchtmittel OHNE Leuchte in die Stückliste aufgenommen werden kann  ;)

ZitatJetzt muss ich nur mal sehen wo ich den Hebel richtig ansetzen tue

Beginne am Besten ganz von Vorne
Überlege, wie ein Projekt definiert wird, welche Informationen benötigt werden um einen Artikel zu speichern,
Welche Informationen die Stückliste benötigt, wie die die Zusätzlichen Infos zusammenspielen (Einheiten, Preise, ...)

Beim Erstellen der Stückliste ist es z.B. unsinnig Informatioen zu erfassen, die sowieso schon in anderen Tabellen vorhanden sind.
Wie du richtig geschrieben hast 'redundante Daten' zu erfassen ist unsinnig.
Für die Stücklistenerstellung wird ein Artikel ausgewählt, zusätzliche Infos angezeigt und die benötigte Stückzahl eingegeben.

Zeichne dir mit deinen Vorstellungen ein Szenario, versuche dann dieses in ein ERM umzulegen und dann eine Tabellenstruktur zu schaffen,
die du mit Hilfe der Infos, die du unter Anderem auch aus den Links #1 und #2 aus der Signatur von DF6GL beziehen kannst, versuchst zu normalisieren.

Stell das Datenmodell dann hier wieder rein und wir werden es durchdiskutieren.
Erst danach solltest du daran gehen Formulare zur Erfassung zu erstellen.

HTH

Hallo,

ZitatIst das denn bislang der Fall? Kann eine Leuchte denn Artikel und Zubehör zugleich sein?

Ja, dans hängt ein wenig davon ab wie man die Instalation interpretiert.
- Eine Leuchte kann z.B. das Equipment sein, wenn es sich um eine herkömliche, direkt an 230V, angeschlossene Leuchte handelt. Dessen Zubehör dann logischerweise die gute alte Glühlampe wäre.
- Es kann aber auch sein dass die Leuchte an einem Schaltaktor betrieben wird, dann kann die Installation auch so gedeutet werden dass der Schaltaktor das Equipment ist und die Leuchte ist das Zubehör......

Dann werde ich nochmals versuchen meine Tabellenstruktur neu zu definieren.
Der erste Link ist mir schon längere Zeit bekannt und ist unter anderem auch die Seite woher meine Grundkenntnisse stammen....:-)
Danke aber für den bildenden Anstoss.....

Das ganze Thema zur Normalisierung ist das A&O eines DBprogrammierers, für mich als neuling auch logisch aber manchmal schwer vom Gedanken in die Realität umzusetzen.
Aber ich arbeite daran!

ZitatErst danach solltest du daran gehen Formulare zur Erfassung zu erstellen.

Ja eigentlich schon. Wenn aber so wie in meiner DB einige funktionen wie abhängige Kombifelder auf Formularebene erst programmiert werden können, ist das parallel Arbeiten an den Tabellen und dem Formular, für einen nicht erfahrenen Neuling wie mich, etwas hilfreicher. Ich denke so besser das Zusammenspiel und die mögliche Probleme zu erkennen.

Folgende Aussage aus deinem ersten Beitrag beschäftigt mich irgendwie im Hinterkopf:

ZitatDie Datenherkünfte ALLER Kombis bauen auf UNION - Abfragen auf ----  WOZU? Ein einfaches SELECT mit ID und Bezeichnung als Felder genügt doch.

Ohne wirklich den Grund zu erkennen...........
Da dies aber sowieso erst bei der Formularerstellung relevant sein wird, warte ich mal bis dahin mit weitere Fragen diesbezüglich.

Sobald ich was zusammen gestellt habe, werde ich mich wieder melden.

Vielen Dank
Gruss

Hallo,

Ich hoffe dass dieser lange Beitrag hier euch jetzt nicht entmutigt............. :)

So, jetzt habe ich meine Tabellen neu strukturiert und denke so ein funktionierendes
Datenmodel erstellt zu haben.
Die Querys und Formulare habe ich nur Zwecks Inspiration noch drin stehen lassen,
funktionieren jetzt aber natürlich nicht mehr.

Ich wäre froh wenn ihr euch meine Tabellen mal anschauen könntet. Falls da noch andere
Vorschläge sind, werde ich gerne noch nachbessern.
Falls das jetzt soweit ok ist, müsste ich jetzt an die Formulare ran, und da würde ich mich sehr über weitere Hilfe freuen. Wie ihr ja bereits in den ersten Beiträge erfahren habt, bin ich noch relativ unerfahren und habe meine bisherige Kenntnisse durch fleissiges Lesen im Netz und durch Beispieldatenbanken woraus ich meine bisherige Codes angepasst habe.

Im Anhang ist die aktuelle Datenbank in der Version Access2003, und eine PDF Datei mit dem Text der hier unten folgt.

Hier noch eine Erklärung zu den Tabellen, welche Formulare ich mir vorstelle
und wie die funktionieren sollen.

TABELLEN:

- tbl_Projekte:
  Hier werden Daten zum Projekt hinterlegt (Projektname, Adresse usw.),
  die anschliessend auch dazu dienen sollen die Equipments dem jeweiligen Projekt zuzuordnen

- tbl_Kategorie:
  Die Geräte der Installation werden Kategorien zugewiesen.
  Hier werden die Kategorien für sämtliche Hardware der Installation gelistet.
  (Beim erstellen neuer Datensätze im tbl_ArtikelKatalogEquipment und im
  tbl_ArtikelKatalogZubehör soll auf diese Kategorietabelle zurückgegriffen werden)

- tbl_Hersteller:
  Hier werden die Hersteller für sämtliche Hardware der Installation gelistet.
  (Beim erstellen neuer Datensätze im tbl_ArtikelKatalogEquipment und im
  tbl_ArtikelKatalogZubehör soll auf diese Herstellertabelle zurückgegriffen werden)

- tbl_ArtikelKatalogEquipment:
  Hier werden alle Equipments einmal erfasst, inklusive Informationen wie Leistung,
  Bestellnummer, Preis, usw., und an eine Kategorie und einem Hersteller
  aus den gleichnamigen Tabellen (tbl_Kategorie & tbl_Hersteller) gebunden.
  Der so erstellte Equipmentkatalog dient dann dazu ein neues Equipment
  in der tbl_Equipment aufzunehmen.

- tbl_ArtikelKatalogZubehör:
  Hier werden alle Zubehöre einmal erfasst, inklusive Informationen wie Leistung,
  Bestellnummer, Preis, usw., und an eine Kategorie und einem Hersteller
  aus den gleichnamigen Tabellen (tbl_Kategorie & tbl_Hersteller) gebunden.
  Der so erstellte Zubehörkatalog dient dann dazu ein neues Zubehör
  in der tbl_Equipment aufzunehmen.
  (Ein Equipment kann ein oder mehrere Zubehöre haben,
  Z.B. hat eine Leuchte ein oder mehrere Leuchtmittel als Zubehör)

- tbl_ArtikelKatalogKabel: 
  Hier werden alle Kabeltypen einmal erfasst, inklusive Informationen wie Kabeldurchmesser,
  Aderanzahl, Aderquerschnitt, usw., und an eine Kategorie und einem Hersteller
  aus den gleichnamigen Tabellen gebunden.
  Der so erstellte Kabelkatalog dient dann dazu ein neues Kabel in der tbl_Kabel
  aufzunehmen.

- tbl_Equipments:
  Hier werden alle in einer Elektroinstallation vorhandene Equipments,
  mit eventuel vorhandenem Zubehör, erfasst.
  Das Equipment und das dazugehörige Zubehör soll aus den entsprechenden
  Artikelkataloge stammen.
  Hier sollen auch Angaben zum Einbauort mit genauen Wand- und Deckenkoordinaten gelistet
  werden, dazu wird auf Informationen aus den Tabellen tbl_Stockwerke, tbl_Räume,
  tbl_Wände zurückgegriffen. 

- tbl_EquipmenZubehöre:
  Dies ist die Zwischentabelle um die n:m Beziehung zwischen der tbl_Equipments
  und der tbl_ArtikelKatalogZubehör zu erstellen.
  (Dadurch soll die Möglichkeit geschaffen werden dass einem Equipment
  mehr als nur ein Zubehör zugewiesen werden kann)

- tbl_Kabel:
  Hier werden alle Kabel der Elektroinstallation erfasst,
  mit Detailinfos zum Kabel wie Länge usw.
  Der Kabeltyp soll aus dem Kabelkatalog tbl_ArtikelKatalogKabel stammen.
  Hier wird auch jeweils ein (Start)-Equipment und ein (Ziel)-Equipment definiert,
  um zu zeigen woran das jeweilige Kabel angeschlossen ist.

- tbl_Stockwerke:
  Diese Tabelle enthält alle mögliche Bezeichnungen von Stockwerke,
  wo die Equipments eingebaut sein können.
  Diese Tabelle ist sozusagen ein Katalog mit Stockwerkbezeichnungen.

- tbl_Räume:
  Diese Tabelle enthält alle mögliche Bezeichnungen von Räume,
  wo die Equipments eingebaut sein können.
  Diese Tabelle ist sozusagen ein Katalog mit Raumbezeichnungen.

- tbl_Wände:
  Diese Tabelle enthält alle mögliche Bezeichnungen von Wände,
  wo die Equipments eingebaut sein können.
  Diese Tabelle ist sozusagen ein Katalog mit Wandbezeichnungen.

FORMULARE:

- frm_ArtikelKatalogEquipment:
  Dieses Formular soll dazu dienen neue Datensätze (Equipments) in der gleichnamigen
  Tabelle tbl_ArtikelKatalogEquipments einzugeben.
  Die Auswahl der Kategorie und des Herstellers soll jeweils in einem Kombinationsfeld
  möglich sein, und als Datenherkunft sollen die gleichnamigen Tabellen tbl_Kategorie
  und tbl_Hersteller dienen.
  Weitere Informationen zum Artikel sollen in entsprechende Textfelder eingegeben werden
  (Typenbezeichnung, Bestellnummer, Preis, usw.).
  (In diesem Formular soll man über eine Schaltfläche zum Formular frm_Equipments
  gelangen können)

- frm_ArtikelKatalogZubehör:
  Dieses Formular soll dazu dienen neue Datensätze (Zubehöre) in der gleichnamigen
  Tabelle einzugeben.
  Die Auswahl der Kategorie und des Herstellers soll jeweils in einem Kombinationsfeld
  möglich sein, und als Datenherkunft sollen die gleichnamigen Tabellen tbl_Kategorie
  und tbl_Hersteller dienen.
  Weitere Informationen zum Artikel sollen in entsprechende Textfelder eingegeben werden
  (Typenbezeichnung, Bestellnummer, Preis, usw.).
  (In diesem Formular soll man über eine Schaltfläche zum Formular frm_Equipments
  gelangen können)

- frm_ArtikelKatalogKabel:
  Dieses Formular soll dazu dienen neue Datensätze (Kabel) in der gleichnamigen
  Tabelle einzugeben.
  Die Auswahl der Kategorie und des Herstellers soll jeweils in einem Kombinationsfeld
  möglich sein, und als Datenherkunft sollen die gleichnamigen Tabellen tbl_Kategorie
  und tbl_Hersteller dienen.
  Weitere Informationen zum Artikel sollen in entsprechende Textfelder eingegeben werden
  (Typenbezeichnung, Bestellnummer, Preis, usw.).
  (In diesem Formular soll man über eine Schaltfläche zum Formular frm_Kabel
  gelangen können)

- frm_Equipments:
  Dieses Formular soll dazu dienen neue Datensätze (Equipments mit dazugehörigem Zubehör)
  in der gleichnamigen Tabelle tbl_Equipments einzugeben, sowie auch die genaue Angaben
  zum Einbauort.
  a) Die Auswahl des Equipments soll schrittweise, mit abhängigen Kombinationsfelder,
     geschehen. Zuerst soll eine Kategorie gewählt werden, anschliessend nur noch die
     für diese Kategorie möglichen Hersteller zur Auswahl stehen.
     Nach dem selektieren eines Herstellers, sollen nur noch Die für die ausgewählte
     Kategorie und Hersteller mögliche Artikeln aus dem tbl_ArtikelKatalogEquipment
     zur Auswahl stehen.
     Beim wählen eines Artikels, sollen die dazugehörigen Informationen
     (Leistung, Abmessung, Bestellnummer, usw.) in die entsprechenden Textfelder
     angezeigt werden.
  b) Für die Auswahl des Zubehör gilt die Beschreibung der Equipmentauswahl,
     ausser dass der Artikel aus dem tbl_ArtikelKatalogZubehör ausgewählt werden soll.
  c) Die Eingabe des Einbauortes soll mittels 3 Kombinationsfelder für "Stock", "Raum"
     und "Wand" geschehen. Datenherkunft ist hier jeweils die gleichnamige Tabelle.
     Weitere Informationen zur Einbaulage (Wandkoordinaten, Deckenkoordinaten und Höhe)
     sollen in entsprechenden Textfelder eingegeben werden.
     (In diesem Formular soll man über 3 Schaltflächen zu den jeweiligen Katalogformulare,
     frm_ArtikelKatalogEquipment, frm_EquipmentKatalogZubehör & frm_EquipmentKatalogKabel,
     gelangen können)
     Desweitere soll in einem Textfeld angezeigt werden an welchen Kabel (aus der tbl_Kabel)
     dieses Equipment angeschlossen ist.

- frm_Kabel:
  Dieses Formular soll dazu dienen neue Datensätze (Kabel) in der gleichnamigen Tabelle
  tbl_Kabel einzugeben, und diesen Kabel an 2 Equipments aus der tbl_Equipments zu binden.
  a) Die Auswahl des Kabels soll schrittweise, mit abhängigen Kombinationsfelder, geschehen.
     Zuerst soll eine Kategorie gewählt werden, anschliessend nur noch die für diese
     Kategorie möglichen Hersteller zur Auswahl stehen. Nach dem selektieren eines
     Herstellers, sollen nur noch die für die ausgewählte Kategorie und Hersteller mögliche
     Kabeln aus dem Tbl_ArtikelKatalogKabel zur Auswahl stehen.
     Beim wählen eines Kabels, sollen die dazugehörigen Informationen
     (Kabeldurchmesser, Aderanzahl, aderquerschnitt, usw., in die entsprechende Textfelder
     angezeigt werden.
  b) In einem Kombinationsfeld soll es möglich sein ein erstes Equipment, das
     Startequipment, Aus dem tbl_Equipment zu wählen dessen Datenfelder wie z.B.
     die Angaben zum Einbauort in entsprechenden Textfelder angezeigt werden.
     Ein zweites Equipment, das Zielequipment, soll genau so ausgewählt und angezeigt
     werden können.
     Um die Suche eines bestimmten Equipment hier erleichtern zu können,
     sollte die Auswahl eventuel auch mit abhängigen Kombinationsfelder geschehen.
     Es bleibt zu klären ob es sinnvoller ist hier auch nach Kategorie und Hersteller
     zu filtern, oder es von Vorteil wäre das Equipment nach dem Einbauort
     heraus zu filtern. z.B. Projekt->Stockwerk->Raum->Wand

VIELEN DANK
GRUSS
KEI-KOO

[Anhang gelöscht durch Administrator]

Hallo,

ZitatStell das Datenmodell dann hier wieder rein und wir werden es durchdiskutieren.
Erst danach solltest du daran gehen Formulare zur Erfassung zu erstellen.

Peter,
Konntest du dir meine Tabellen schon mal anschauen?
Ich würde mich sehr freuen wenn ich jetzt mit den Formulare voran käme, kann ich mit eurer Hilfe rechnen?

Vielen Dank
Gruss
Kei-Koo

Hallo,

bitte um etwas Geduld...
Hab im Moment nur ganz sporadisch Zeit herzukommen ...

Wochenende wird etwas leichter

;) ::)

ja, ok.
Man(n) hat ja auch noch andere Prioritäten  ;D
Danke für dein Antworten und vielleicht bekommen wir es dann bald hin

Gruss
Kei-Koo

Hallo,

so, habe nun Zeit gefunden deine Tabellen anzusehen.

Erst mal möchte ich ein großes Lob aussprechen - du scheinst das Ding wirklich genau zu planen - weiter so!

An deinen Tabellen habe ich ein paar kleine Änderungen vorgenommen. Einesrseits bei Feldbezeichnungen um Umlaute und Leerzeichen zu entfernen,
bei den Datentypen umd die Eingaben von Kommazahlen zu ermöglichen, wo diese benötigt werden.

Das Tabellenkonstrukt um die Kabelsache habe ich neu gestaltet, so kannst du nun unabhängig von der Equipment-Tabelle Kabel zusammenstellen.
Der Bezug zum Projekt ist jedoch in jedem Fall gegeben wodurch die richtige Zuordnung gewährleistet wird.
Die Gestaltung war im Hinblich auf die Auflösung mehrerer n:m Beziehungen notwendig.

Die Tabelle Stockwerke ist hinfällig, ich habe in der tblEquipment ein Feld 'Etage' als Textfeld eingeführt.
Die Behandlung mit der Tabelle tbl_Stockwerke hätte ergeben, dass du nur in Bauten mit einem OG arbeiten kannst.
So bist du flexibler.  ;)

Die Felder für die Artikelarten / Zuordnung ob Artikel oder Zubehör werden nicht gebraucht, habe sie daher aus den Tabllen Artikel und Zubehör entfernt.
Die Zwischentabelle Zubehör/Equipment habe ich geändert.
Wir hatten das schon mal angesprochen glaube ich - so wäre es theoretisch möglich, dass für einen Artikel mehrere Zubehörteile definiert werden können aber natürlich nicht zwangsweise müssen.
Jedenfalls aber ist es nun auch möglich einen Zubehörteil zu mehreren Artikeln zu erfassen. Im Endeffekt wird jedoch die richtige Kombination Artikel/Zubehör an die tbl_Equipment geliefert und durch die Erweiterung der tbl_Equipment um ein Stückzahlfeld - auch die Anzahl der verwendeten Zubehörteile. Die Angabe der Stückzahl beschränkt sich jedoch auf Zubehörteile, da Equipmentartikel per Einbaukoordinaten definiert werden und somit für Equipmentartikel immer die Stückzahl 1 pro Datensatz angenommen werden kann.


Zu den Formularen.

Nachdem sich nun ein paar Dinge in den Tabellen geändert haben, wird der Formularaufbau entsprechend angepasst werden müssen.
Zu Bedenken ist dabei bitte immer von Aussen nach Innen zu arbeiten - das heißt, nicht damit zu beginnen das umfangreichste Formular zuerst zu erstellen sondern die Erfassungsformulare,
welche dann die Auswahltabellen mit Daten versorgen.

Schau dir mal jetzt aber den Tabellenaufbau an ...




[Anhang gelöscht durch Administrator]

Guten Abend Peter,

ZitatErst mal möchte ich ein großes Lob aussprechen - du scheinst das Ding wirklich genau zu planen - weiter so!

Ja das mache ich.
Ich denke dass die Zeit die man für eine gute Planung investiert sich eigentlich immer rechnet, mit Zeitersparniss bei der Realisierung und in der Qualität.
Ich habe beruflich jeden Tag mit vielen Leute zu tun, bei denen ich genau diese Punkte oft vermisse und bemängle. Da will ich ja hier bei meinem ersten DB-Projekt nicht den gleichen Fehler machen.
Ich denke aber auch dass man aus Respekt gegenüber Leute von denen man Hilfe erwartet, man die Vorbereitungen die man durchführen kann, so weit und so gut es geht, selber in Angriff nehmen sollte.
Auch sollte mann sachlich bleiben und klare Vorstellungen haben, und das sauber zu presentieren kann auch nie schaden.

Ich danke dir für das Lob und die Anerkennung für meine Arbeit. :)
Ich muss aber sagen dass ich selber ein wenig erstaunt bin, wie weit man durch lesen im Netz und Forum sich ins Access einarbeiten kann. Mir macht es auf jeden Fall Spass und finde es sehr interessant.
Ich habe schon mal nachgeschaut wo Access Kurse abgehalten werden, was die kosten und wie der Inhalt aussieht.
Damit bin ich mir aber noch nicht so richtig sicher?

Und jetzt zu deinem letzten Beitrag:

Vielen Dank für deine Hilfe und die angepasste Tabellen die ich mir angeschaut habe.

Zu Umlaute und Leerzeichen:
Ist das grundsätzlich ein Problem oder kann mal dadurch ein Problem auftauchen. Ich habe schon gelesen dass einige Zeichen nie verwendet werden dürfen, von Leerzeichen und Umlaute aber noch nichts.

1) Zu tbl_ArtikelKatalogEquipment:
- Hatte auch vermutet dass der Artikel_Typ unnötig ist, wusste aber die richtige Lösung nicht.
- Typ wurde umbenannt in Artikelname (und in der tbl_ArtikelKatalogZubehör in Zubehoername).
Dadurch wird vermieden dass zweimal die Feldbezeichnung Typ benutzt wird und jetzt ist es auch möglich beides im tbl_Equioment aufzunehmen. Richtig?
- Mir ist aufgefallen dass die Kategorie_ID und Hersteller_ID mit den Buchstaben FK erweitert wurde.
Was ist hier der Hintergrund?

2) Zu tbl_ArtikelKatalogKabel:
- Mein Vorschlag (Wunsch) ist gewesen die Auswahl nach folgenden Filtern zu realisieren:
Kategorie -> Hersteller -> Kabeltyp
Mit deiner Änderung wird jetzt gefiltert nach:
Hersteller -> Kabel_Typ_ID_FK
Wie hast du dir das vorgestellt? Ich hatte unter TYP die genaue Typenbezeichnung des Kabels gemeint, also z.B. "NYM-J"
Bei deiner Änderung wähle ich einen Hersteller aus & dann sofort ein Kabeltyp (wenn du unter Kabeltyp auch wie ich die Typenbezeichnung gemeint hast).
In diesem Fall fehlt hier dann die Möglichkeit zuerst eine bestimmte Kabelkategorie zu wählen!?

Oder nein, ich glaube jetzt gesehen zu haben dass du über die neue Tabelle tbl_KabelTyp eine Kabelkategorie definierst und auswählst. Richtig ???
Dann fehlt hier aber der letzte Auswahlschritt nach Kabel Typenbezeichnung ???

3) Zu tbl_ArtikelKatalogZubehoer:
- Artikel_Typ entfernt und Typ umbenannt in Zubehoername. Habe ich bereits unter Punkt 1) kommentiert.

4) tbl_EquipmentKabel:
- Da hast du meine tbl_Kabel umbenannt in tbl_EquipmentKabel.
- Die Kabel wurden auch an die Projekt_ID gebunden. Das soll natürlich so sein  :-[
- Mir ist aufgefallen dass wegen der Start- und Zielequipments, um jeweils auf die Equipment_ID im Katalog verweisen zu können, bei den Tabellenbeziehungen die Tabelle tbl_ArtikelKatalogEquipment dupliziert wurde.
Das kannte ich bis jetzt so noch nicht.
Ist eine Beziehung für die Endpunkt_ID mit der originale Tabelle nicht möglich?

5) Zu tbl_Equipments:
- Die sache mit dem Textfeld "Etage" kommentiere ich unter dem Punkt 8 (tbl_Stockwerke).
- Du hast hier die Datenfelder für das Zubehör und die Zubehörstückzahl hinzugefügt.
Hier besteht jetzt die Möglichkeit eine grössere Anzahl eines Zubehörs an einen Equipment zu binden, aber leider immer nur das selbe Zubehör.
Möchte ich jetzt unterschiedliche Zubehöre an eine Equipment binden, z.B. eine Leuchte mit 3 unterschiedlichen Leuchtmitteln, dann müsste die Struktur hier nochmals anders aussehen!
Was wäre hier möglich?

6) zu tbl_Hersteller:
- Hier hast du das Datenfeld Kategorie_ID entfernt.
Die macht so in der Tabelle keinen Sinn, richtig. Ich hatte die aber wegen den abhängigen Kombinationsfelder im Formular drin.
Mal sehen wie deine Lösung im Formular aussehen wird  ;)

7) zu neuen Tabelle tbl_KabelTyp:
- Diese Tabelle hast du neu erstellt.
Werden hier die Kabeltypen, also die genaue Kabel Typenbezeichnung, oder die Kabelkategorien erfasst?
Unter Punkt 2) habe ich auch schon davon geschrieben.
Das konnte ich irgendwie noch nicht richtig herausfinden :-[

8.) zu tbl_Stockwerke:
- Diese Tabelle soll hinfällig sein.
Das heisst ich werde keine Stockwerke mehr auswählen können, sondern einen Klartext im Datenfeld "ETAGE" eingeben. Richtig?
Damit könnte ich eigentlich leben. Der Grund dieser Tabelle war aber die Eingabe hier zu standardisieren, also zu vermeiden dass der eine OG und der andere 2.G oder Obergeschoss eingibt.
Das Problem das du hier aber zum Vorschein gebracht hast ist natürlich richtig und hatte ich nicht erkannt :-[
Eine Möglichkeit wäre vieleicht eine Tbl_Stockwerke mit genügend Stockwerkbezeichnungen.
Z.B.     usw  <---  -3 , -2 , -1 , EG , 1OG , 2OG , 3OG , 4OG -->  usw , DG
Was hälst du davon?

Vielen Dank und bis bald
Gruss

Hallo, guten Morgen,

na dann ...

Benamsungen mit Leerzeichen und Umlauten etc.:
Leerzeichen und Umlaute KÖNNEN ser schnell zu Problemen führen, vor Allem im VBA-Umfeld, sie sind grundsätzlich in der deutschen Access-Version verwendbar, ich empfehle trotzdem KEINE Umlaute zu verwenden.
Gleiches gilt für Sonderzeichen und 'ß'. Reservierte Worte sind sowieso ausgeschlossen - dazu gibt es im Netz genug Seiten, welche die reservierten Worte für Access beschreiben.

1:
Umbenennung von Typ - da ich empfehle auch bei Feldnamen zumindest annähernd zu beschreiben was darunter gemeint ist. In dem Fall handelt es sich um den Namen des Artikels - daher...
FK oder F verwende ich für Fremschlüsselfelder um diese als solche zu kennzeichnen, verhindert Probleme durch gleichnamige Felder im SQL Umfeld in VBA und bei Abfragen allgemein.

2:
Dadurch, dass die Tabellen leer und ohne Beispieldaten zur Verfügung sind, kann ich nur Vermuten (bin auch kein Elektriker ;))
Wenn du bestimmte Kabeltypen in Kategorien einteilen willst dann fehlt jetzt eine Tabelle - 'tbl_KabelKategorie' was kein Problem sein sollte, erstell' sie und binde sie in die bestehende Struktur nach deiner Vorstellung ein.

Zitatwird jetzt gefiltert nach

.... gefiltert wird in Tabellen gar nicht sondern nur erfaßt  ;)

4:

Zitatdie Tabelle tbl_ArtikelKatalogEquipment dupliziert

Nein, das scheint nur so - es handelt sich dabei um die Aliastabelle der tbl_ArtikelKatalogEquipment ( _1 ) erfolgt dadurch, dass 2 unterschiedliche Felder mit dem Primärschlüssel der gleichen Tabelle in Beziehung stehen.
Die Beziehung wird dadurch IMMER mit der 'Original-Tabelle' hergestellt, das ist lediglich eine Form der Darstellung - wenn du willst - ein graphisches Feature

5:

ZitatWas wäre hier möglich

Ja, dazu braucht es eine Zwischentabelle tbl_EquipmentZubehoerStk  mit EZS_ID (primärschlüssel), EquipmentZubehoer_ID_FK (Zahl, Long), Equipment_ID_FK (Zahl, Long) und Anzahl (Zahl, Long)
Die Tabelle muss dann zwischen tbl_Equipment und tbl_EquipmentZubehoer rein, die Felder EquipmentZubehoerStk und EquipmentZubehoer_ID_FK dann aus der tbl_Equipment wieder raus.

6:
Habe eine Möglichkeit geschaffen die m:n Beziehung zwischen Herstellern und Kategorien aufzulösen.
Die bereits eingtragenen Daten habe ich entsprechend angepasst.

7:
Auch kein Problem, da du ja die Kabelgeschichte anders defiert hast - stell mal um und lass dann sehen

8:
OK, dann lass die tbl_Stokwerke, gib darin aber nur Bezeichnungen an - also EG, OG, UG, DG hänge die per Stockwerk_ID_FK in die tbl_Equipment, ändere das Feld Etage von Text auf Zahl und es passt wieder.
So kannst du nun aus einer Liste die Bezeichnung wählen und gibst manuell daneben ein welche Etage das ist 1,2,3,4, ... n - so gehts auch.
Mit einer vollständigen Liste wirst du nicht glücklich werden, da du ja nie weißt wann die Liste wirklich vollständig ist - immer dann wenn das annimmst kommt sicher ein Baumeister auf die Idee eine Etage tiefer und dazu 2 Etagen höher zu bauen ...  :-\
Nö, bleib dabei die Bezeichnungen zu standardisieren und die Zahl einzugeben.

Ich habe die Zubehörsache geändert und gleich wieder hier angehängt, damit du die Datei für deine Kabelgeschichte bereits mit Zubehöränderung zur Verfügung hast.
Ebenfall integriert ist die Änderung mit den Stockwerken und den Herstellern samt deren Kategorien

Eine wichtige Sache noch:
Wenn du die Änderung der Kabelkonfiguration durchgeführt hast, sollten wir DIESEN Thread abschließen um nicht einen neuen OT-Rekord zu riskieren  :D :D ;D
Weitere Fragen oder neue Fragen danach bitte in einem eigenen Beiträgen, die das angefragte Problem im Titel haben, reinstellen.
Das hilft bei der Forumssuche thematisch richtige Suchergebnisse zu erlangen ungemein.  ;)

[Anhang gelöscht durch Administrator]

Hallo Peter,
Vielen Dank für deine bisherige Hilfe und die Anpassungen in den Tabellen !

Zitat.... gefiltert wird in Tabellen gar nicht sondern nur erfaßt  Zwinkernd

Ja schon klar. War mit den Gedanken schon in den Formularen, wo dann das Filtern entsprechend funktionieren sollte  ;)

- Das mit den Benamsungen werde ich mir dann merken.
- Dein System zur Kennzeichnung der Fremdschlüsselfelder werde ich in Zukunft auch beibehalten.
  Jetzt wo ich das sehe erkenne ich auch den Vorteil  :)
- Zu punkt 4, das mit der Aliastabelle.
  Dass die Tabelle nicht wirklich als neue Tabelle dupliziert wurde ist schon klar. Ich meinte damit schon
  eine "virtuelle" Kopie in der Beziehungenansicht. Ich habe diese Beziehung mal testweise entfernt
  und neu erstellt. Und effektiv wird nach einer Abfrage dann die Beziehung erstellt, aber mit einer
  neuen virtuellen Tabelle.
  Warum macht Access diese Beziehung denn nicht auch von der originalen Tabelle aus?
  Das würde ich logischer und übersichtlicher finden! Ich sehe auch nicht wirklich wo da das Problem
  wäre?
- Zu Punkt 8, mit den Stockwerken. Deine Idee gefällt mir und ist angenommen  :)

Und jetzt noch die Sache mit der neuen Tabelle wegen den Kabel Kategorien.
Ich bin gerade dabei diese Änderungen vorzunehmen und hätte noch folgende Fragen dazu:
- Wenn ich nur diese eine neue Tabelle erstelle, dann ist es ja so dass in der tbl_HerstellerKategorie
  noch das Datenfeld KabelKategorie_ID_FK aus der neuen Tabelle tbl_KabelKategorie hinzugefügt
  und die Beziehung der beiden Tabellen über diesen Fremdschlüssel erstellt wird.
  Dann ist es ja so dass es für die Equipmentkategorien und die Kabelkategorien jeweils eine separate
  Tabelle gibt und die Hersteller für Equipments und Kabel zusammen in einer Tabelle erfasst werden ?
  Soweit richtig ??

Dann stelle ich mir die Frage ob das so ok ist und keine Nachteile oder Probleme auftauchen können, oder es vielleicht sinnvoller ist für die Kabelsache auch separate Tabellen zu erstellen.
Damit meine ich eine tbl_KabelKategorie, tbl_KabelHersteller und eine tbl_KabelHerstellerKategorie.
Der Primärschlüssel KabelHerstellerKategorie_ID aus der tbl_KabelHerstellerKategorie müsste dann an ein neues Datenfeld KabelKategorie_ID_FK in der tbl_ArtikelKatalogKabel gebunden werden.
Dann wäre die Struktur genau so wie sie aktuel für die Equipments besteht!

Hoffentlich sind meine Gedanken jetzt nicht total ....... ::)

Das mit dem OT habe ich in Kenntniss genommen.
Wollte dies aber nochmals hier posten, da es noch zum letzten Beitrag gehört.
Sobald die Tabelle steht, werde ich dann weitere neue Themen hier im Forum erstellen.
Danke für diesen Hinweis, weis auch nicht wie die Moderatoren hier im Forum das sehen.
Es ist auch schwierig in einem solchen Fall wie bei mir den richtigen Zeitpunkt zu finden um ein neues Thema zu erstellen.

Schönen Abend noch

Hallo,

ZitatHersteller für Equipments und Kabel zusammen in einer Tabelle erfasst werden

Sollte kein Problem darstellen, da du diese Hersteller ja auch einer Kategorie - nämlich Kabel - zuweisen kannst.
Beim Aufruf deiner Kabel-Eingabeformulare selektierst du dann nur mehr jene Hersteller in ide Kombifelder (sofern das notwendig wird) welche die Kategorie 'Kabel' aufweisen.

ZitatUnd jetzt noch die Sache mit der neuen Tabelle wegen den Kabel Kategorien

Insgesamt gesehen kannst du da genau so vorgehen, wie es bei ArtikelKatalogEquipment gelöst ist, die Kabelhersteller werden in tbl_HerstellerKategorie erfasst und deren HerstellerKategorie_ID kommt als Fremdschlüssel in den ArtikleKatalogKabel - dadurch ist dann die tbl_HerstellerKategorie mit allen 3 Katalogen in Beziehung

Zitatoder es vielleicht sinnvoller ist für die Kabelsache auch separate Tabellen

Ist prinzipiell möglich, wiederspricht aber den Theorien und Regeln für normalisierte, relationale Datenbanken. (Gleiche Informationen in unterschiedlichen Tabellen).

ZitatZu Punkt 8, mit den Stockwerken. Deine Idee gefällt mir und ist angenommen

Tja da bin ich dann ja mehrfach beruhigt und kann angstfrei schlafen gehen  :D :D

ZitatWarum macht Access diese Beziehung denn nicht auch von der originalen Tabelle aus

Macht Access auch, die Ansicht ist lediglich aus Gründen der Übersichtlichkeit so - also reine graphische Angelegenheit

Zitatden richtigen Zeitpunkt zu finden um ein neues Thema zu erstellen

Der ist immer dann gegeben, wenn Fragen und Folgeantworten mit dem ursprünglich eingebrachtem Thema (z.B. Mehrere Gruppen abhängiger Kombifelder in einem Frm wollen nicht funktionieren)
nicht mehr ursächlich in Zusammenhang stehen.
Die Moderatoren werden dich deswegen aber nicht fressen!  ;) :D ;D

Nun bastle mal deine Kabelkonfektion zusammen und stell sie dann hier nochmal herein, ich schau mir das gerne wieder an.
Wenn die Konstellation dann annehmbar ist und wir fixieren das, dann schließt du den Thread mit 'gelöst' in DEINEM ersten Beitrag ab.
Alles Nachfolgende stellst du dann einfach in ein neues Thema.  8)

EDIT:

Die Kabel-Hersteller-Geschichte habe ich im angehängten Beispiel implemantiert.
Diese Datei enthält auch ein Formular zum Erfassen von Herstelleren und Kategorien für die tbl_HerstellerKategorie



[Anhang gelöscht durch Administrator]

Das ging ja recht schnell, grosses Dankeschön.

Die DB nimmt so langsam Form an, und bei mir fangen die Augen an zu rollen.....
Hoffe ich halte das bis zum Schluss durch, ohne BLACKOUT  ;D

Habe mir deine letzte Änderungen angeschaut und bin begeistert.
Dazu gleich noch ein nettes Formular....... :)

ZitatSollte kein Problem darstellen, da du diese Hersteller ja auch einer Kategorie - nämlich Kabel - zuweisen kannst. Beim Aufruf deiner Kabel-Eingabeformulare selektierst du dann nur mehr jene Hersteller in die Kombifelder (sofern das notwendig wird) welche die Kategorie 'Kabel' aufweisen.

OK, bin mit der Lösung zufrieden.

ZitatInsgesamt gesehen kannst du da genau so vorgehen, wie es bei ArtikelKatalogEquipment gelöst ist, die Kabelhersteller werden in tbl_HerstellerKategorie erfasst und deren HerstellerKategorie_ID kommt als Fremdschlüssel in den ArtikleKatalogKabel - dadurch ist dann die tbl_HerstellerKategorie mit allen 3 Katalogen in Beziehung

Ja, dann kann ich aus den 2 Tabellen (tbl_Kategorie, tbl_Hersteller) die Kategorie "KABEL" zuweisen und alle an diese Kategorie gebundene Hersteller.

Was ich aber noch nicht durchschaut habe, wahrscheinlich weil es noch nicht implementiert ist, ist die Möglichkeit die Kabel (die ja alle der Kategorie "KABEL" aus der tbl_Kategorie zugeordnet sind) auch noch einer separaten, unterteilten Kabelkategorie zuzuordnen.

Entschuldige dass ich nochmals deswegen nachfrage. Ich bin ein wenig verwirrt, da ich mich bereits mit deinem Vorschlag aus dem heutigen Beitrag von 9:07 unter Punkt2 , zum Erstellen einer neuen zusätzlichen Tabelle (tbl_KabelKategorie) beschäftigt hatte und dies sich bei mir bereits eingeprägt hat. 
Dann hast du im letzten Beitrag (20:42) geschrieben (und auch umgesetzt :)), dass es so wie in tbl_ArtikelKatalogEquipment gelöst wird.

Ich probiere deine Antworten auf folgendes Zitat von mir zuzuordnen:

ZitatUnd jetzt noch die Sache mit der neuen Tabelle wegen den Kabel Kategorien.
Ich bin gerade dabei diese Änderungen vorzunehmen und hätte noch folgende Fragen dazu:
- Wenn ich nur diese eine neue Tabelle erstelle, dann ist es ja so dass in der tbl_HerstellerKategorie
  noch das Datenfeld KabelKategorie_ID_FK aus der neuen Tabelle tbl_KabelKategorie hinzugefügt
  und die Beziehung der beiden Tabellen über diesen Fremdschlüssel erstellt wird.
  Dann ist es ja so dass es für die Equipmentkategorien und die Kabelkategorien jeweils eine separate
  Tabelle gibt und die Hersteller für Equipments und Kabel zusammen in einer Tabelle erfasst werden ?
  Soweit richtig ??

und finde darauf keine Antwort.

Ich glaube schon dass ich diese Tabelle noch erstellen muss, bin aber etwas durcheinander :-[ und deshalb nochmals meine Frage.
Könntest du bitte nochmals spezifisch auf diese Sache eingehen?

Danke
Gruss
Kei-Koo

Hallo,

Zitat... auch noch einer separaten, unterteilten Kabelkategorie zuzuordnen

Ich habe zwar im Moment die Datei nicht zur Hand ...
aber das sollte kein Problem sein. Du erstellst ein bestimmtes Kabel im Kabelkatalog um dieses dann dem verbauten Equipment zuordnen zu können.
In diesem Kabelkatalog kann dann ein Kabel sehr wohl einer speziellen Kabelart oder Kabelkategorie zugeordnet werden bzw. bestimmt werden welcher kategorie von Kabel es zuzuordnen ist.

Die entsprechende Tabelle hierfür existiert noch nicht oder ist es möglich dieses mittels der tbl_KabelTyp abzubilden? Wie schon erwähnt bin ich kein Elektriker und habe von den Materialien nicht gerade viel Ahnung...  ;D
Für mich ist es schwer zu unterscheiden, was ein KabelTyp und eine Kabelkategorie NICHT gemeinsam hätten...  :-\
Auf jeden Fall aber wird die Information in die tbl_ArtikelKatalogKabel mit einfließen müssen ob nun via KabelTyp oder KabelKategorie (eine neu zu erstellendeTabelle) ist nicht das Thema.

Zitatund finde darauf keine Antwort. ....

Ich habe nicht explizit auf diesen Absatz eine Antwort geschrieben sondern auf den nachfolgenden:
Insgesamt gesehen kannst du da genau so vorgehen, wie es bei ArtikelKatalogEquipment gelöst ist ....

ZitatHoffe ich halte das bis zum Schluss durch, ohne BLACKOUT

Warum? Jetzt beginnt es erst so richtig interessant zu werden, da darfst du nicht aussteigen!  ;) :D ;D

Hallo,

Von aussteigen ist hier keine Rede  ;) :)

ZitatDie entsprechende Tabelle hierfür existiert noch nicht oder ist es möglich dieses mittels der tbl_KabelTyp abzubilden? Wie schon erwähnt bin ich kein Elektriker und habe von den Materialien nicht gerade viel Ahnung...   
Für mich ist es schwer zu unterscheiden, was ein KabelTyp und eine Kabelkategorie NICHT gemeinsam hätten... 

Ok, kann ich nachvollziehen und deshalb eine kleine Erklärung dazu:
- Unter KabelTyp verstehe ich die Bezeichnung eines Kabels. D.h. die Bezeichnung des Kabels so wie sie vom Hersteller vergeben wird, aber auch in der NORM festgelegt ist.
Eine Mantelleitung, so wie sie oft in der Hausinstallation verwendet wird hat die Bezeichnung NYM-J.
Falls es dich interessiert, kannst du hier schnell eine verständliche Übersicht sehen: http://de.wikipedia.org/wiki/Typenkurzzeichen_von_Leitungen (http://de.wikipedia.org/wiki/Typenkurzzeichen_von_Leitungen)
- Unter Kabelkategorie verstehe ich den Oberbegriff für eine Reihe Kabel die für einen bestimmten Zweck bestimmt sind. Ich lehne mich hier nicht an eine speziellen Norm fest, sondern lege für mich persönliche Kategorien fest. Ich möchte damit im Formular eine Filterung ermöglichen (abhängige Kombifelder) um Kabel nach folgendem Schema auswählen zu können:

Kategorie                       Kabeltyp                                 Erklärung
      ▼                                   ▼                                            ▼
Datenkabel                    J-Y(St)-Y                       Kabel für Telefonanschluss
Datenkabel                    J-0HSCH                       Netzwerkkabel Kategorie 6
Datenkabel                    A-DQ(ZN)B2Y               Glasfaser Netzwerkkabel (LWL)
Datenkabel                    RG 59 B/U 75 Ohm       Koaxial Datenkabel für 10Base2 Netzwerk
Buskabel                        EIB-Y(St)Y                    BUS-Kabel für EIB Installation (KNX)
Buskabel                        xxxxx                           xxxxxxxxx
Installationskabel          NYM-J                           Mantelleitung (für 230V/400V Hausinstallation)
Installationskabel          NYY-J                            Mantelleitung (für 230V/400V Hausinstallation, zugelassen für Installation im Erdreich)
Installationskabel          xxxxx                           xxxxxxxxx

Ich denke du verstehst jetzt worum es geht.
Was würdest du denn jetzt empfehlen, vielleich mein Vorschlag aus meinem letzten Beitrag ?
D.h.: Eine neue Tabelle tbl_KabelKategorie anlegen, in der tbl_HerstellerKategorie noch das Datenfeld KabelKategorie_ID_FK hinzufügen und
die Beziehung der beiden Tabellen über diesen Fremdschlüssel erstellen??

Danke
Gruss
Kei-Koo

Hallo,

ich habe im Anhang die DB mit den Kabeltypen / Kabelkategorien eingestellt.

Was mich noch ein wenig stört ist das Feld Adernfarben in der Tabelle tbl_ArtikelKatalogKabel - was möchtest du da eintragen? ein Farbcode wäre OK, blau, schwarz, gelbgrün wäre falsch.

[Anhang gelöscht durch Administrator]

Hallo,

Du bist schneller beim Umsetzen als ich zum Überlegen und Fragen stellen brauche  ;D

Die Farbkodierung hat zur Zeit wirklich nur informativen Charakter.
Damit möchte ich jetzt schon die einzelne Adern erfassen, um später vielleicht noch weitere Informationen aufnehmen zu können.
So könnte ich z.B. den einzelnen Adern eine Phase (Spannungsphase L1, L2, L3) zuweisen und einzelne Stromkreise eines Kabels dokumentieren.
Ich denke gerade dass aber nicht immer mit Farben gearbeitet wird. Bei manchen Kabeln ist die Adern auch mit einer Zahl kodiert.

Und was die Eingabeart angeht, da hast du natürlich Recht wegen der Normalisierung der DB.
Da müsste ich also eine weitere Tabelle erstellen mit den Farbcodes (Farben: Schwarz, Braun, Grau, Blau, usw...., und Zahlencodes: 1, 2, 3, 4, 5, 6, usw.....)

Hmmm, ob ich das jetzt aber wirklich umsetzen soll ??? ???

Ich werde mir die Tabelle nachher ansehen, wenn ich zu Hause bin.

Grosses Dankeschön

Gruss
Kei-Koo

NACHTRAG:
::) Dann muss ich ja auch noch schauen wie ich das hinbekomme dass ich mehrere Aderkodierungen für einen Kabel erfassen kann. Im Kabelkatalog steht ja wieviele Ader ein Kabeltyp hat, und entsprechend viele Möglichkeiten müssen ja dann auch für die Farbkodierung vorhanden sein....... ::) ???
Oder gibt es da eine Möglichkeit in einem Datenfeld mehrere Aderkennzeichnungen aus der Aderkennzeichnungstabelle zu erfassen? Hmmm, wohl kaum!
Und ob das dann auch noch im Einklang ist mit dem was ich oben geschrieben habe, wofür ich die Aderkennzeichnung erfassen möchte, nämlich weitere Informationen zuordnen zu können? Ich denke dann wird es nichts daraus mit mehrere Kennzeichnungen in einem Datenfeld......... :P

Hallo,

"Da müsste ich also eine weitere Tabelle erstellen mit den Farbcodes "

scheint mir in dem Fall die einzig gangbare Lösung zu sein - vor allem dann, wenn du aus solchen Eingaben / Daten irgendwann mal Erkenntnisse beziehen willst.
Und sooo schlimm wird das wohl auch nicht sein - die brauchst du ja nur einmalig zu erstellen, bei einem Textfeld schreibst die Codierung bei jedem Datensatz   ::)
"Die Farbkodierung hat zur Zeit wirklich nur informativen Charakter"

Ein Textfeld mit mehreren elementaren Einträgen ist für die Zwecke nicht nur kaum händelbar sondern - schlicht weg - der falsche Lösungsansatz (Normalisierung!)

Womit sich dann dein Nachtrag auch in dieser Erklärung auflöst...  ;)

Also eine tbl_KabelFarbCodes mit KabelFarbCode_ID (Autowert) und FarbCode (Text) erstellen und per KabelFarbCode_ID_FK in den KabelKatalog einbinden.

So wie unten im Anhang ...   ;) ;) ;)

[Anhang gelöscht durch Administrator]

Hallo,

Ich war einsam und du wiederum schneller  ;D Danke für den Anhang.

Ja, auch ich erkenne manchmal meine Gedankenfehler -:)

Wie lautet die beste Lösung um jetzt die Aderanzahl und die entsprechende Anzahl an Farb(Zahlen-)Codes zu vereinen?
Es haben ja nicht alle Kabel die gleiche Anzahl an Adern!
Eine Lösung wäre entsprechend viele (genügend) Datenfelder für Farbcodes im Kabelkatalog zu definieren z.B. Ader1FarbCode, Ader2FarbCode, Ader3FarbCode usw...., aber wo aufhören ??
Ein Problem das ich aber jetzt sehe, ist wie das im Formular aussehen soll.
Wenn ich z.B. eine maximale Farbcodeanzahl für max. 12 Adern im Katalog festlegen würde, würde es nicht professionel aussehen wenn im Formular dann bei einem
3-Adrigen Kabel die 12 Felder für die Aderfarben zu sehen wären.

Wahrscheinlich wirst du mir jetzt vorschlagen einen "SHOW-FILTER" zu setzen, in etwa so: wenn Aderanzahl=6 dann zeige nur die ersten 6 Aderfarbcodefelder ??
Oder wäre eine bessere Lösung im Formular ein Endlosformular zu integrieren, wo ich dann frei die Anzahl der Farbcodes eingeben könnte?

Egal wie, hier fängt es für mich an eine echte Anforderung zu werden, um nicht zu sagen dass ich noch nicht das nötige Wissen besitze.

Falls ein Endlosformular die bessere Lösung sein sollte, käme das dann nicht auch für das Zubehör in Frage.

Gruss
Kei-Koo

PS:
Eine kleine Änderung habe ich aber in deiner DB vorgenommen. Es handelt sich um AderFarben und nicht um KabelFarben, die Tabelle und Datenfelder entsprechend angepasst  ;) ;)

Hallo,

"Eine Lösung wäre entsprechend viele (genügend) Datenfelder für Farbcodes im Kabelkatalog zu definieren z.B. Ader1FarbCode, Ader2FarbCode, Ader3FarbCode usw...., aber wo aufhören ??"


das wäre keine Lösung..

Es wird eine Tabelle ("tblKabeladern") benötigt, die den Farbcode (der wiederum aus einer anderen Tabelle stammen könnte) zu einer Ader zuordnet...

Hallo DF6GL,
und danke für deine Hilfe.

Entweder habe ich bei deinem Vorschlag ein Verständnissproblem oder ich habe nicht genau genug erklärt wo das Problem in der DB ist und deshalb vielleicht dein Tip nicht richtig passt!?

Wenn ich es so wie vorgeschlagen mache, dann wäre es ja so dass durch die neue Tabelle tbl_KabelAdern und die Beziehung zu der Tabelle tbl_AderFarbCodes, es immer so wäre dass für jeden Kabel der DB die Aderfarbe die gleiche wäre für die gleiche Adernummer??
Oder verstehe ich das falsch?

Ich bin der Meinung dass dann, z.B. die Ader 1 immer Schwarz, die Ader 2 immer Blau, die Ader 3 immer Grau, usw. ist (eben so wie es durch die Beziehung dieser 2 neuen Tabellen festgelegt wird)!?
Und das wäre nicht ok, da dies in der Praxis nicht passen würde.

Deshalb nochmals die Erklärung zur gewünchten Funktion:

- Für jeden Kabeltyp wird die Aderanzahl in einem Datenfeld erfasst, somit ergibt sich dann auch für diesen, eine entsprechende Anzahl an Datenfelder die mit AderfarbCodes Informationen gefüttert werden wollen.
Die AderFarbCode Datenfelder Anzahl ist somit nicht für jeden Kabeltyp gleich, sondern variable je nach Kabeltyp!
- Auch sollte die Zuordnung einer Aderfarbe nicht an einer Adernummer gebunden sein.
Beispiel:
Kabel 1 hat 3 Adern: Ader1=Schwarz, Ader2=Blau, Ader3=Grün-Gelb
Kabel 2 hat 3 Adern: Ader1=Schwarz, Ader2=Braun, Ader3=Grau

Ich möchte auch darauf hinweisen dass ich bei diesem Problem auch gleichzeitig immer an eine passende Lösung für das Kabelformular denke. Deshalb waren meine Fragen im letzten Beitrag auch so formuliert.

Für mich bleiben jetzt noch folgende Fragen offen:
Um keine feste Zuordnung der Adernummer zu einer bestimmten Farbe zu haben, fällt mir nur eine Lösung ein (obwohl sie mir ein wenig unprofessionel vorkommt :-[)

1) Sollen im Kabelformular eine Anzahl X an Datenfelder für Aderdefinitionen festgelegt werden (X ist nach einer Schätzung fest zu legen)?
-> Das würde heissen dass ich jetzt eine maximal möglich Aderanzahl für einen Kabeltyp schätzen muss, z.B. 12 Adern und somit 12 Datenfelder für die Aderinformationen festlegen muss?

2) Wenn Punkt 1) so stimmt, dann würde ich im KabelKatalog die Datenfelder zur Aderdefinition z.B. wie folgt benennen:
Ader1FarbCode_ID_FK, Ader2FarbCode_ID_FK, Ader3FarbCode_ID_FK, ...............Ader12FarbCode_ID_FK
und diese Fremdschlüssel mit dem Primärschlüsse AderFarbCode_ID einer neuen AderFarbCode Tabelle verbinden.

Ist hier der Ansatz richtig, oder würdet ihr das "schöner" lösen? ;)


3) Und dann nochmals zum Formular. Wie sieht es da mit meiner Überlegung im letzten Beitrag aus, betreffend Anzahl der zu visualisierenden Felder je nach Kabeltyp und der Endlosformular Geschichte?

Ich will jetzt nicht vorgreifen und jetzt schon die Formulare bearbeiten, möchte nur eine Tabellenstruktur haben die dann auch in Formulare brauchbar angezeigt werden können :)

Vielen Dank für eure Geduld und Hilfe
Gruss
Kei-Koo

Hallo,

ich gehe (fast) mit keinem Deiner Einwände konform...  ;)


Wenn Du keinen Wert auf eine bestimmte Adernr legst, dann lass sie weg...Damit ist auch keine Reihenfolge der Farben bei einem Kabel definierbar.

Jedem Kabel wird entspr. seiner individuellen Aderanzahl ein "Satz Farben" zugeordnet.  Die Aderanzahl wird nirgends gespeichert, sie ergibt sich aus der Summe der dem Kabel zugeordneten einzelnen Farben.




tblFarben
FID (PK, Autowert)
F_Bez  (Text)
.
.


tblRohKabel
RKID (PK,Autowert)
RK_Bez (Text)
.
.


tblRohKabelAderFarben
RKAFID (ÜK, Autowert)  
RKAF_RKID  (Long,Fremdschlüsselfeld für RKID aus tblRohKabel)
RKAF_FID (Long,Fremdschlüsselfeld für FID aus tblFarben)  /edit/
.
.


Die Darstellung der Daten in den Formularen hat sich nach den Tabellenkonstrukten zu richten, nicht umgekehrt. Genauso muß sich die Tabellenkonstruktion nach den Datenzusammenhängen richten und nicht nach irgendwelchen Wertetabellen..

Hallo,

Ok, vielen Dank für deine Erklärungen.
Dann werde ich mir das mal morgen in aller Ruhe anschauen,
jetzt brauche ich mal ne Müze Schlaf  :D

ZitatDie Darstellung der Daten in den Formularen hat sich nach den Tabellenkonstrukten zu richten, nicht umgekehrt. Genauso muß sich die Tabellenkonstruktion nach den Datenzusammenhängen richten und nicht nach irgendwelchen Wertetabellen..

Ja, die Theorie ist mir soweit bekannt. Nur weil es meine erste DB ist, mache ich mir vermutlich zuviele Sorgen um die Ausführung der Formular ;D

Hoffentlich kriege ich das noch alles hin.........

ZitatRKAF_FID (Long,Fremdschlüsselfeld für RKID aus tblRohKabel)

Das soll aber heissen aus FID aus tblFarben, oder ist mein Schlaf dringender als ich dachte ? ;)

Gruss
Kei-Koo

Hallo,

ja doch,

wollte ja nur sehen, ob Du noch wach bist   :P    :D ;D ;)

Hallo,

ich habe mir, nachdem ich munter geworden bin  ;) :D ;D auch ein paar Gedanken drüber gemacht und mir auch die Definitionen zu den Kabeltypen bei Wikipedia angesehen.
Demnach ist es ja so, dass in der vollständigen Typkennzeichnung die Adernanzahl und der Leitungsquerschnitt enthalten ist - oder? ( NYM-J 3x1,5)

Somit sollte dann die Adernanzahl und der Leitungsquerschnitt auch in die tbl_Kabeltyp wandern um von dort aus bei Bedarf zusammengesetzt zu werden.

Eine Zwischentabelle (tbl_AdernFarbCodes) zwischen tbl_KabelTyp und tbl_Farben mit den Feldern AdernFarbCode_ID als PK
sowie Farb_ID_FK und KabelTyp_ID_FK sollte dann die Farbmixerei aufnehmen können.

Die Farbzusammenstellung der einzelnen Adern ist dann über die KabelTyp_ID aus der tbl_ArtikelKatalogKabel für jedes eingetragene Kabel aus tbl_AdernFarbCodes abrufbar.

Beispiel (ohne Farbdaten) im Anhang abgelegt  ;)



[Anhang gelöscht durch Administrator]

Hallo Peter,
und einen schönen Anbend.

Zitatich habe mir, nachdem ich munter geworden bin  Zwinkernd  ;) :D ;D ..........

Du wirst dich ja wohl nicht weggebeamt haben..............? ;D ;)
Aber schön dich hier wieder zu treffen!

Was die Bezeichnung angeht, ja, da hast du recht, soweit es sich um die harmonisierte Kabelbezeichnung handelt. Also aktuelle EU-Norm.
Dass die Aderanzahl und Querschnitte in die Kabeltyp Tabelle gehören klingt logisch.

ZitatEine Zwischentabelle (tbl_AdernFarbCodes) zwischen tbl_KabelTyp und tbl_Farben mit den Feldern AdernFarbCode_ID als PK
sowie Farb_ID_FK und KabelTyp_ID_FK sollte dann die Farbmixerei aufnehmen können.

Wenn du das so sagst! Dann klingt es schon gleich viel einfacher  ;) ;D

Und wie immer, wieder vielen Dank für die Umsetzung.
Werde ich mir dann mal anschauen.

BTW:
Ich finde meine DB bekommt so langsam wirklich professionellen Charakter, zumindest was die Datenstruktur und die darin enthaltene Informationsfülle angeht.
Da die Tabellenanzahl, für meine Verhältnisse, aber so langsam auch etwas gross wird und somit auch die Anzahl an Beziehungen, fange ich so langsam an die Übersicht zu verlieren..... :'(
Dies liegt wohl daran dass ich zwar fleissig die Grundlagen usw lese, aber nie richtig hilfreiches Training erhalten habe :(
Ich werde so langsam nervös wenn ich an die Formulare denke..........

Gruss
Kei-Koo

Hallo,

ZitatIch finde meine DB bekommt so langsam wirklich professionellen Charakter

Naja, wenn das nicht so wäre dann hättest du sie ja auch beim Kurpfuscher untersuchen lassen können  :D :D ;) ;D

Zitat... somit auch die Anzahl an Beziehungen ...

Wieso ? Es stehen IMMER nur 2 Tabellen miteinander in Beziehung - also 2 Tabellen 1 Beziehung - wo siehst du da das Problem?   ::) :D ;D

ZitatIch werde so langsam nervös wenn ich an die Formulare denke

Das legt sich - nach einer gewissen Anlaufphase - bestimmt!  ;)

Schönen Samstag-Abend noch!

Danke für deine ermutigenden Worte :)

Hier mal ein paar Beispiele worüber ich mir Gedanken gemacht habe und welche Fragen mir so durch den Kopf gehen.

- Es existiert eine Beziehung zwischen tbl_EquipmentZubehoere und tbl_ArtikelKatalogEquipment mit dem Datenfeld EquipmentArtikel_ID (FK).
Ich habe ein Problem zu erkennen wo zwischen einem bestimmten Equipment (aus tbl_Equipments) und einem Zubehoer die Beziehung erstellt wird.
Ich würde eher in der tbl_EquipmentZubehoere ein Fremdschlüssel Equipment_ID_FK sehen, der eine Beziehung mit dem Primärschlüssel aus der tbl_Equipments hat !!??  ::) ???
Mit der Beziehung so wie sie aktuel existiert, erkenne ich eher eine Beziehung zwischen einem Zubehoer und einem Artikel aus dem Equipment Katalog, und nicht zu einem eingebauten Equipment.

Ich vermute dass ich vielleicht auch nicht klar genug erleutert hatte wie das mit einem Equipment und dem Zubehoer funktionieren sollte!
So wie ich es im Moment sehe, wird einem Equipment über die tbl_EquipmentZubehoere immer fest ein Zubehoer zugewiesen. Dies wäre aber nicht in meinem Sinn.......
Hmmmmm......, oder kommt jetzt die tbl_EquipmentZubehoerStk ins Spiel.....?
Wird da über die Equipment_ID_FK einem einbgebauten Equipment aus tbl_Equipments ein Zubehoer zugewiesen? Ja, glaube ich schon. Aber warum ist dann noch die oben erwähnte Beziehung zwischen tbl_EquipmentZubehoere und tbl_ArtikelKatalogEquipment mit dem Datenfeld EquipmentArtikel_ID (FK) vorhanden ????

- Auch verstehe ich nicht richtig wo die Beziehung erstellt wird zwischen einem Kabel in tbl_EquipmentKabel und den 2 Equipments (Start- & End-) aus tbl_Equipments?
Ich sehe da die Beziehung zu einem Artikel aus dem EquipmentKatalog, aber nicht die Bindung zu einem eingebauten Equipment.
Damit auch ich dies erkenne, fehlt mir wohl die Beziehung zwischen Startpunkt_ID_FK (und Endpunkt_ID_FK) und der Equipment_ID aus tbl-Equipments .....???


Fragen über Fragen :-[

Ich hoffe euch jetzt nicht damit zu vertreiben :o

Und auch dir Peter, noch ein schönes Wochenende

Hallo,

ZitatIch habe ein Problem zu erkennen wo zwischen einem bestimmten Equipment (aus tbl_Equipments) und einem Zubehoer die Beziehung erstellt wird.

Von tbl_Equipment aus über die tbl_EquipmentzubehoerStk ist es möglich zur tbl_ArtikelKatalogZubehoer und darüber hinaus sogar bis zur Tabelle tbl_Kategorie rückzufragen.
Du musst von deiner 'Ursprungstabelle aus immer nur den Beziehungslinien folgen.
Also von tbl_Equipment aus gesehn ginge das in etwa so:
Schritt 1:
Die Equipment_id kennzeichnet einen Datensatz in der Tabelle EINDEUTIG. Nehmen wir an es handelt sich um die ID 1.
Es besteht eine Verbindung (Beziehung) zu tbl_EquipmentZubehoerStk --- kann dort die Equipment_ID 1 noch gefunden werden? JA
Schritt 2:
Wenn ich die Equipment_ID 1 nun Seklektieren würde erhielte ich eine oder mehrere EquipmentZubehoer_IDs als Fremdschlüssel geliefert. (nehmen wir an es wird einer gefunden - ID 20)
Es besteht eine Beziehung zu tbl_EquipmentZubehoere. Jeder zuvor gefundene FK kennzeichnet in dieser Tabelle wiederum einen Datensatz eindeutig. Existiert da eine ID 20? JA
Schritt 3:
In der Tabelle tbl_EquipmentZubehoere ist zusammen mit der ID 20 eine ZubehoerArtikel_ID als FK gespeichert nehmen wir an die ID 30.
Die Tabelle tbl_ArtikelKatalogZubehoer muss demnach eine ID 30 enthalten - ist das so? JA
Schritt 4:
Nun kann ich aus der Tabelle tblArtikelKatalogZubehoer herauslesen welches Zubehör sich hinter der ID 30 verbirgt.
Ergebnis:

ZitatMit der Beziehung so wie sie aktuel existiert, erkenne ich eher eine Beziehung zwischen einem Zubehoer und einem Artikel aus dem Equipment Katalog, und nicht zu einem eingebauten Equipment

Genau dieses Teil (Zubehör) mit der ID 30 ist der Equipment_ID 1 in der, in der tbl_EquipmentZubehoerStk angegebenen, ZubehoerAnzahl zugeordnet.
Wenn ich jetzt noch möchte, kann ich weitergehen und den Hersteller ermitteln, und würde es gespeichert sein sogar das letztgültige Lungenröntgen dessen Großmutter aufrufen können.  ;) ;D

Druck mal einen Beziehungbericht aus und versuchen solche Wege nachzuvollziehen - du kannst das mit fiktiven IDs machen indem du die mit Bleistift zu den Schlüsselspalten dazuschreibst.
Das ist eine recht einprägsame Übung um die Zusammenhänge in Tabellenkonstrukten zu erkennen.

ZitatAber warum ist dann noch die oben erwähnte Beziehung zwischen tbl_EquipmentZubehoere und tbl_ArtikelKatalogEquipment mit dem Datenfeld EquipmentArtikel_ID (FK) vorhanden

In der Tabelle tbl_EquipmentZubehoere existieren 2 Fremdschlüssel, ZubehoerArtikel_ID_FK und EquipmentArtikel_ID_FK
Durch diese Konstellation ist es möglich einem bestimmten Artikel das passende Zubehör zuzuweisen.
Mach ja auch Sinn, weil es beispielsweise nicht angebracht wäre, einer Deckenleuchte statt dem Leuchtmittel eine Sockelleiste zuzuordnen.
Da diese Tabelle aber auch einen Primärschlüssel besitzt, der eben eine solche richtige Kombination (Deckenleuchte und Leuchtmittel) eindeutig kennzeichnet, ist es möglich einem eingebautem Equipment (Equipment_ID) das zugeordnete Zubehör Leuchtmittel (EquipmentZubehoer_ID_FK in tbl_EquipmentZubehoerStk) in der gewünschten Anzahl zuzuweisen.
Ob diese angesprochenen Kombinationen nun ausschließlich während der Erfassung von Equipments für ein Projekt zusammengesetzt werden oder bereits vorab in einem eigens dafür kreiertem Formular - bleibt dir überlassen, in jedem Fall wird es aber so sein, dass immer wieder mal neue Kombinationen zu erstellen sein werden. Ich würde daher in dem Fall vorschlagen BEIDE Varianten zu berücksichtigen, das die Erstellung eines solchen Kombinier-Formulars kein großer Aufwand ist und die Zusammenstellung von Zubehören für Equipmentartikel rasch erledigt ist.
Zur Erklärung vielleicht noch --- > du wählst einen Equipmentartikel aus den du verbauen willst und kannst dann die Zubehöre auswählen - aber nur jene, die für diesen Artikel bestimmt sind --- ist das sinnvoll?

ZitatAuch verstehe ich nicht richtig wo die Beziehung erstellt wird zwischen einem Kabel in tbl_EquipmentKabel und den 2 Equipments (Start- & End-) aus tbl_Equipments

Auch hier gilt das bereits oben Gesagte!
So wird in dem Fall in der tbl_ArtikelKatalogKabel ein ganz bestimmtes Kabel konfektioniert und dann der tbl_EquipmentKabel zugeordnet.
Festzustellen welchem Equipment aus der tbl_Equipment dieses Kabel nun eigen ist, erfolgt nicht direkt über die tbl_Equipment sondern via Start- und Endpunkt über deren Beziehung zur tbl_ArtikelKatalogEquipment.
Damit feststellbar ist, dass die Kabel zu einem bestimmten Projekt gehören ist dessen ID in der tbl_EquipmentKabel mitgeschrieben.
Somit besteht auch eine Verbindung zu tbl_Equipment, wodurch feststellbar ist welche Equipments und welche Kabel in einem Projekt verbaut wurden.

Ein(e) eventuell noch bestehender Einwand bzw. Frage:
Wie wird gewährleistet, dass Start- und Endpunkt nur Equipments sein können, die auch tatsächlich verbaut wurden?
Das wird auf Formularebene passieren, indem aus entsprechenden Kombis nur jene Equipments auwählbar sind, die bereits in der
tbl_Equipment gespeichert wurden (passende Abfragen für die Datenherkunft der Kombis machen das möglich).
Damit ist folglich auch feststellbar, bei welchem Projekt welche Kabel zwischen welchen Equipments eingebaut sind und wie diese Kabel
beschaffen sind --- weiter noch --- welche Leuchtmittel sie zum Strahlen bringen und wer diese hergestellt hat. WOW

ZitatIch hoffe euch jetzt nicht damit zu vertreiben

Sieht nicht so aus - oder?  ;)
Ich hoffe nur, dass du meinen Ausführungen folgen kannst - die sind halt auch ein wenig komplex - aber ich denke wenn du das mal wirklich so nachstellst wie ich versucht habe das oben zu skizzieren, kommt auch das Verständnis langsam aber stetig!  ::)

Hallo,

Vielen Dank für die ausführliche Erklärungsversuche.
Ich werde dann mal probieren anhand eines Ausdrucks der Beziehungen das nachzustellen.

ZitatZur Erklärung vielleicht noch --- > du wählst einen Equipmentartikel aus den du verbauen willst und kannst dann die Zubehöre auswählen - aber nur jene, die für diesen Artikel bestimmt sind --- ist das sinnvoll?

Ja, das ist durchaus sinnvoll und eigentlich genau das was ich mir immer vorgestellt habe.

Auf dem ersten Blick scheint es dann doch so als hätte ich die Tabellen und Beziehungen doch nicht so falsch verstanden.
Dann ist es ja so dass einem Artikel im Vorfeld über die tbl_EquipmentZubehoere immer ein festes Zubehoer zugeordnet wird?  ??? :-[

Was ich aber am liebsten vermeiden möchte, ist dass ich, z.B. bei der Kombination Leuchte & Leuchtmittel,
eine vielzahl an Kombinationen in einer Tabelle festlegen muss.
Eine einzige Leuchte, z.B. ein Decken Halogen Einbaustrahler, kann ohne weiteres bis zu 12 oder mehr unterschiedliche Leuchtmittel aufnehmen. So müsste ich für jeden Leuchtentyp eine unmenge an Kombinationen erstellen! Das würde ich nicht so toll finden.
Und dann kommen evtl. noch solche Sondersituationen, wo eine "mehrflammige" Leuchte (z.B. mit 3 Leuchtmittel) 2 unterschiedliche Leuchtmittel verbaut werden und somit 2 unterschiedliche Zubehoere zugeordnet werden müssen.

ZitatOb diese angesprochenen Kombinationen nun ausschließlich während der Erfassung von Equipments für ein Projekt zusammengesetzt werden oder bereits vorab in einem eigens dafür kreiertem Formular - bleibt dir überlassen, in jedem Fall wird es aber so sein, dass immer wieder mal neue Kombinationen zu erstellen sein werden. Ich würde daher in dem Fall vorschlagen BEIDE Varianten zu berücksichtigen, das die Erstellung eines solchen Kombinier-Formulars kein großer Aufwand ist und die Zusammenstellung von Zubehören für Equipmentartikel rasch erledigt ist.

Und das deutet aber stark auf diese fest definierte Kombinierungen in einer Tabelle........?

ZitatAuch hier gilt das bereits oben Gesagte!
So wird in dem Fall in der tbl_ArtikelKatalogKabel ein ganz bestimmtes Kabel konfektioniert und dann der tbl_EquipmentKabel zugeordnet. OK, verstanden
Festzustellen welchem Equipment aus der tbl_Equipment dieses Kabel nun eigen ist, erfolgt nicht direkt über die tbl_Equipment sondern via Start- und Endpunkt über deren Beziehung zur tbl_ArtikelKatalogEquipment.  Und hier liegt mein Problem. Dass hier Start- und Endpunkt eine Rolle spielen verstehe ich noch, aber warum dann auf ein Artikel im Katalog verwiesen wird......, ist mir unklar! Ich suche hier immer noch die Verbindung zu einem Equipment.
Damit feststellbar ist, dass die Kabel zu einem bestimmten Projekt gehören ist dessen ID in der tbl_EquipmentKabel mitgeschrieben. OK, das leuchtet mir auch ein.
Somit besteht auch eine Verbindung zu tbl_Equipment, wodurch feststellbar ist welche Equipments und welche Kabel in einem Projekt verbaut wurden.  Auch das ist ok. Dadurch ist die Projektzugehörigkeit der Equipments und Kabel nachvollziehbar.
Aber für mich leider immer noch nicht ersichtlich wo die Zugehörigkeit Kabel ->Start- -> Endequipment festgelegt wird?

Sorry, aber da blicke ich nicht richtig durch.

ZitatEin(e) eventuell noch bestehender Einwand bzw. Frage:
Wie wird gewährleistet, dass Start- und Endpunkt nur Equipments sein können, die auch tatsächlich verbaut wurden?
Das wird auf Formularebene passieren, indem aus entsprechenden Kombis nur jene Equipments auwählbar sind, die bereits in der
tbl_Equipment gespeichert wurden (passende Abfragen für die Datenherkunft der Kombis machen das möglich).
Damit ist folglich auch feststellbar, bei welchem Projekt welche Kabel zwischen welchen Equipments eingebaut sind und wie diese Kabel
beschaffen sind --- weiter noch --- welche Leuchtmittel sie zum Strahlen bringen und wer diese hergestellt hat. WOW

Und das wird wohl die Antwort auf meine letzten Fragen hier oben sein. Nur leider für mich zur Zeit nicht zu verstehen........Bin ich bekloppt  :-[ :'(

Ich erkläre einfach mal die Beziehungen so wie ich sie verstehe und sinnvoll sehen würde. Vielleicht ist daraus erkennbar wo mein Gedankenfehler ist!

Wenn ich mir die komplette Beziehungenansicht anschaue, dann teile ich mal grob wie folgt ein:

- Links ist der Teil der alle Kataloge darstellt, d.h. untereinander gesehen die tbl_ArtikelKatalogZubehoer, tbl_ArtikelKatalogEquipment und tbl_ArtikelKatalogKabel.
Noch weiter links in der Ansicht, die feinheiten zu obigen Kataloge, d.h. die Tabellen die Hersteller, Kategorie und Kabeltyp ermöglichen.

- Rechts, das sind die Tabellen die für die Räumliche zugehörigkeit zuständig sind, d.h. tbl_Projekte, tbl_Stockwerke, tbl_Raeume und tbl_Waende.

- Und dann in der mitte, die eigentlichen Tabellen für die zwei zu erfassenden Artikelarten. Die tbl_Equipments und die tbl_EquipmentKabel.

- Dann gibt es noch die Hilfstabellen tbl_EquipmentZubehoere und tbl_EquipmentZubehoerStk.

Und nun zu den Beziehungen, so wie ich mir das vorstelle. D.h. so wie ich denke dass die Tabellen miteinander verknüpft sein müssten damit der Informationsfluss gegeben ist:

- Alle Tabellen links von den Katalogtabellen ist soweit klar und werde ich nicht drauf eingehen.

- Die Tabellen für die räumliche Zugehörigkeit ist auch klar. Hier werden direkte Beziehungen zwischen der tbl_Equipment und den jeweiligen Tabellen erstellt. Primärschlüssel dieser Tabellen ist jeweils Fremdschlüssel in der tbl_Equipments.

- Und jetzt zu den Beziehungen was die Equipments und Kabel angeht.
Vereinfacht erklärt, stelle ich mir das so vor.

* In der tbl_Equipments wird einer Equipment_ID, über Equipment_ID_FK, ein Artikel aus tbl_EquipmentKatalog zugewiesen. Und hier mache ich gedanklich dann auch ein unterschied. Sobald ein Artikel in der tbl_Equipments landet, ist es kein Artikel mehr sondern ein (eingebautes) Equipment.

* In der tbl_EquipmentKabel wird einer EquipmentKabel_ID, über KabelArtikel_ID_FK, ein Kabelartikel aus tbl_ArtikelKatalogKabel zugewiesen.

* So, die 2 Haupttabellen wäre soweit ok.
Nun geht es drum einem Kabel aus tbl_EquipmentKabel zwei Equipments aus tbl_Equipments zuzuweisen. D.h. ein Equipment als Startequipment und eins als Endequipment.
Der für mich logische Weg diese Zugehörigkeit zu erstellen, wäre jeweils eine Beziehung von Startpunkt_ID_FK & Endpunkt_ID_FK, nicht zu den Katalogtabellen sondern zu der Equipment Tabelle tbl_Equipments an Equipment_ID zu ziehen.
Denn ich möchte ja ein (verlegtes) Kabel aus tbl_EquipmentKabel an eingebaute Equipments binden und nicht an Artikel aus dem Katalog. Ich sehe die Kataloge als Quelle für die Equipmenttabelle und EquipmentKabeltabelle, um dort Datensätze zu erstellen, aber nicht mehr um Beziehungen zwischen Kabel und Equipment zu erstellen.
Irgendwie wiederspricht es "meiner" Logik, wenn hier auf Artikel im Katalog verwiesen wird, denn dort ist jeder Artikel ja nur 1x vorhanden und somit für mich nicht nachvollziehbar wie man dann mehrmals eine eingebaute Leuchte identisches Typs (also gleicher Artikel aus dem Katalog aber unterschiedliche Equipment_ID) mit unterschiedlichen Kabeln aus tblEquipmentKabel binden kann.
?????????

Vielleicht denke ich aber auch nur zu direkt..............

Und jetzt bitte nicht wegschmeissen vor Lachen, ;)
ich tue mein bestes :D

Gruss

ZitatUnd jetzt bitte nicht wegschmeissen vor Lachen,
ich tue mein bestes

Sicher nicht, deine Fragen haben ja allesamt Hand und Fuß ...

Zitatwäre jeweils eine Beziehung von Startpunkt_ID_FK & Endpunkt_ID_FK, nicht zu den Katalogtabellen sondern zu der Equipment Tabelle tbl_Equipments an Equipment_ID zu ziehen.

Da hast du überlegungstechnisch ja nicht unrecht und meine Überlegung dazu war die folgende:.
Dennoch ist ein Start- und ein Endpunkt ein Teil aus dem Artikelkatalog und hat insofern auch dahin eine 'nähere' Beziehung.
Um bei der Eingabe der Daten über Formular aber nicht willkürlich aus dem Katalog zu schöpfen wird für Start- und Endpunkt eine Auswahlliste generiert, die auf den verbauten Artikeln beruht.

Was ich aber bei der ganzen Geschichte übersehen habe ist der Umstand, dass sich seit einiger Zeit die Kabel nicht mehr direkt in der tbl_Equipment finden sondern in eine Zwischentabelle ausgelagert sind.
Durch die ganze Kabeldebatte ist das irgendwie in die Versenkung gerutscht - jetzt hast du aber mit einem einzigen Satzteil ---> "... mehrmals eine eingebaute Leuchte identisches Typs   ..." <---
dazu beigetragen, dass diese Versenkung wieder aufgefüllt wurde.
Natürlich muss in dem Fall die Equipment_ID der verbauten Teile in diese Tabelle verbunden werden und nicht die Katalog_ID!  ::)
... eijeijeijei ...   

ZitatVielleicht denke ich aber auch nur zu direkt

Nein, ich habe da einen wichtigen Punkt übersehen.:o

Ich habe das Tabellenkonstrukt auch gleich umgestellt - befindet sich im Anhang.

[Anhang gelöscht durch Administrator]

ZitatSicher nicht, deine Fragen haben ja allesamt Hand und Fuß ...

Danke  :)

ZitatWas ich aber bei der ganzen Geschichte übersehen habe ist der Umstand, dass sich seit einiger Zeit die Kabel nicht mehr direkt in der tbl_Equipment finden sondern in eine Zwischentabelle ausgelagert sind.

Komisch, und genau das war die erste Änderung die du in meiner DB vorgenommen hast  ;D

Das positive daran dass du was übersehen hast ist, dass ich dadurch indirekt auf die "Prüfbank" gesetzt worden bin und jetzt eine kleine Bestätigung erhalten habe für meine Aufmerksamkeit und ich,  langsam aber stetig, was dazu gelernt habe. :)

Ich bin deinem Rat auch gefolgt und habe einen Beziehungsbericht ausgedruckt und versucht die Beziehungen nachzuvollziehen.
Was den Teil des Equipments angeht, also die Schritte 1 bis 4, das dürfte jetzt klar sein.
Mit dem Zubehoer, da hapert´s leider noch.
Ich denke aber dass es auch daran liegen könnte, dass ich andere Vorstellungen habe was die Beziehungen zwischen Equipment und Zubehoer angeht.
Ich hatte im letzten Beitrag, auch bezogen auf deinem Zitat

ZitatOb diese angesprochenen Kombinationen nun ausschließlich ....

darüber geschrieben:

Zitat
Was ich aber am liebsten vermeiden möchte, ist dass ich, z.B. bei der Kombination Leuchte & Leuchtmittel,
eine vielzahl an Kombinationen in einer Tabelle festlegen muss.
Eine einzige Leuchte, z.B. ein Decken Halogen Einbaustrahler, kann ohne weiteres bis zu 12 oder mehr unterschiedliche Leuchtmittel aufnehmen. So müsste ich für jeden Leuchtentyp eine unmenge an Kombinationen erstellen! Das würde ich nicht so toll finden.
Und dann kommen evtl. noch solche Sondersituationen, wo eine "mehrflammige" Leuchte (z.B. mit 3 Leuchtmittel) 2 unterschiedliche Leuchtmittel verbaut werden und somit 2 unterschiedliche Zubehoere zugeordnet werden müssen.

Wie sieht es jetzt mit diesem Teil aus?
- Ist es so dass das Zubehoer fest einem Artikel zugeordnet wird und jeweil neu aufgenommen werden muss wenn eine neue Kombination auftaucht?
- Dann ist es ja so wie beschrieben dass für ein einzelner Leuchtentyp, entsprechend den möglichen Leuchtmitteltypen, eine grosse Anzahl an Kombinationen in der Tabelle erstellt werden müssen.
- Ich persönlich würde es bevorziehen einem Equipment einen beliebigen Zubehoer zuordnen zu können. Eine Einschränkung auf die für einem Equipment zutreffende Zubehoere wäre natürlich positiv.
- Auch sehe ich noch Probleme wenn einem Equipment mehrere Zubehoere zugewiesen werden sollen die von unterschiedlichem Zubehoertyp sind!( Also das Beispiel 1 Leuchte mit 3 Leuchtmittel aber 2 Leuchtmitteltypen)

Ich denke wenn ich bei der Zubehoersache noch etwas Klarheit hinein bekommen würde, könnte ich die DB mal mit realistischen Beispieldaten füttern und dann mal an die Formulare ran gehen.

Grosses Lob für deine Arbeit hier im Forum und ganz speziell für deinen persönlichen Einsatz in diesem Thread !

Noch einen schönen Sonntag Abend
Gruss

Hallo,

danke für die Blumen ...   ::)

ZitatIst es so dass das Zubehoer fest einem Artikel zugeordnet wird und jeweil neu aufgenommen werden muss wenn eine neue Kombination auftaucht

ich würde da eher sagen KANN und nicht MUSS
Den Rest deiner Aussagen dazu kann ich gut nachvollziehen - es ist durchaus möglich eine Mischung aus beiden Varianten zu realisieren.
Man kann es so gestalten, dass man Zubehör aus der Liste der fix zusammengestellten (es wird sicher auch solche geben) wählen kann ODER individuell aus dem ZubehoerKatalog
Wenn das generell nicht so gewünscht ist, ist es relativ einfach zu ändern, indem die Tabelle tbl_EquipmentZubehoere ersatzlos gestrichen und in der Tabelle
tbl_EquipmentZubehoerStk  das Feld EquipmentZubehoer_ID_FK auf ZubehoerArtikel_ID_FK umbenannt wird. Zwischen tbl_EquipmentZubehoerStk und tbl_ZubehoerArtikel wird
dann die Beziehung über die Schlüsselspalten erstellt.
Somit wäre es dann z.B. auch möglich verschiedene Zubehöre für ein und das selbe Leuchtenmodell zu erfassen.

Schau mal im Anhang ... habe das mal so umgestellt, die tbl_EquipmentZubehoere vorerst aber noch nicht gelöscht!

ZitatIch denke wenn ich bei der Zubehoersache noch etwas Klarheit hinein bekommen würde, könnte ich die DB mal mit realistischen ...

Tja wenn nun Klarheit besteht - warum nicht!  ;) :D ;D

auch dir och einen schönen Sonntag Abend


[Anhang gelöscht durch Administrator]