Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Die Suche hat 1694 Ergebnisse ergeben.
Seite 14 von 113 Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6, 7 ... 11, 12, 13, 14, 15, 16, 17 ... 107, 108, 109, 110, 111, 112, 113  Weiter
Index
Autor Nachricht
  Thema: Beziehungen mit vielen Tabellen 
astern

Antworten: 12
Aufrufe: 480

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 23. Dez 2011, 22:00   Titel: AW: Beziehungen mit vielen Tabellen Version: Office 2007
Ach was,
so schwer ist das gar nicht. Du musst das Datenmodell nur lesen können (siehe mein Tutorium: http://www.office-loesung.de/ftopic318127_0_0_asc.php!):
Das geht so:

Zu EINEM Kunden gehören MEHRERE Baustellen.
EINE Baustelle gehört zu EINEM Kunden.

EINE Baustelle hat EINEN Baustellentyp.
Von EINEM Baustellentyp gibt es MEHRERE Baustellen.

EIN Zimmer gehört zu EINER Baustelle.
Auf EINER Baustelle gibt es MEHRERE Zimmer.
(Vielleicht sollte man es besser "Raum" nennen.)

EIN Zimmer hat EINEN Zimmertyp.
Von EINEM Zimmertyp gibt es MEHRERE Zimmer.

EIN Zimmer hat EINEN Bodenbelagtyp, EINEN Unterbodentyp und liegt in EINER Etage.
Entsprechend umgekehrt.

Wenn diese Sätze Deine Realität wiedergeben, dann ist das Datenmodell brauchbar. Wenn nicht, dann musst Du sagen, was bei Dir anders ist und das Datenmodell muss geändert werden. So einfach ist das!

Frohe Weihnachten!
MfG
A*
  Thema: Beziehungen mit vielen Tabellen 
astern

Antworten: 12
Aufrufe: 480

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 22. Dez 2011, 22:56   Titel: Re: AW: Beziehungen mit vielen Tabellen Version: Office 2007
Hallo!
ich habe noch eine Gebäudetabelle vorgesehen
Ich denke, das Entscheidende für Guck79 ist die Baustelle. Du hast zwar recht - in einem Gebäude können mehrere Mietwohungen sein. Ich denke aber, dass das für den vorgegebenen Zweck unerheblich ist. Jede einzelne Mietwohnung (und jedes Haus usw.) ist einfach eine Baustelle.
Zwischentabellen für die im Gebäude vorhandenen Zimmer und Geschoße
EIN Zimmer kann nur in EINEM Gebäude sein! Da braucht man keine Zwischentabellen. Bei mir ist die Tabelle tblZimmer die Zwischentabelle zwischen tblBaustelle und tblZimmertyp!
in der Zwischentabelle Gebäude-Zimmer auch die Fremdschlüssel für die Bodenbeläge unterzubringen
Ist bei mir der Fall: botyp_id_f in tblZimmer!
Dann würde ich die Zim_id als Fremdschlüssel in der Baustelle zu speichern und nicht die Baustellenid im Zimmer.
Das würde aber bedeuten:
Zu EINER Baustelle gehört EIN Zimmer.
EIN Zimmer gehört zu MEHREREN Baustellen.
Wie denn das?
Auch den Kunden würde ich dann dem Geb ...
  Thema: Beziehungen mit vielen Tabellen 
astern

Antworten: 12
Aufrufe: 480

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 22. Dez 2011, 20:02   Titel: Re: AW: Beziehungen mit vielen Tabellen Version: Office 2007
Hallo!
Ich bin mit meinem Vorschlag noch einige Schritte weitergegangen.
Inwiefern?

MfG
A*
  Thema: Beziehungen mit vielen Tabellen 
astern

Antworten: 12
Aufrufe: 480

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 22. Dez 2011, 19:51   Titel: AW: Beziehungen mit vielen Tabellen Version: Office 2007
Hallo!
Was Du bisher gemacht hast, geht so überhaupt nicht. Ich habe Dir mal ein vernünftiges Datenmodell gebastelt!

MfG
A*
  Thema: Porsche Bauteildatenbank - ein paar Fragen 
astern

Antworten: 3
Aufrufe: 766

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 22. Dez 2011, 00:41   Titel: Re: AW: Porsche Bauteildatenbank - ein paar Fragen Version: Office XP (2002)
Hallo!
Der C2 kann mit 3,4l und 3,8l bestückt sein. Der C4 wird auch mit diesen beiden Motoren bestückt. Dann ist es doch richtig, dass zwischen der Tabelle "tblDerivate" und "tblMotor" eine 1:n Beziehung steht oder?
Ich weiß nicht, was ein "Derivat" ist, aber es klingt eher nach m:n:
Zu EINEM Derivat ("C2", "C4"??) gehören MEHRERE Motoren?
EIN Motor gehört zu MEHREREN Derivaten?
Dann wäre es eine m:n-Beziehung zwischen tblMotor und tblDerivat.
Es ist in der Tat so, dass eigentlich fast alles eine eigene Teilenummer, sogar das Rad, aber in der Datenbank werden sie wirklich nur als Typ aufgefasst.
Tja, "in der Wirklichkeit ist es so und in der Datenbank ist es so", gibt es nicht! Die DB soll ja die Wirklichkeit abbilden. Du musst Dich also definitiv entscheiden, ob es um ein Rad (=individuell identifizierbar über eine Seriennummer) oder um einen Radtyp geht! Offenbar ist doch Ersteres der Fall!?

Gleich noch ein Tipp ...
  Thema: Datenmodellierung -> Mitarbeiterverwaltung 
astern

Antworten: 3
Aufrufe: 476

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 21. Dez 2011, 21:46   Titel: AW: Datenmodellierung -> Mitarbeiterverwaltung Version: Office 2007
Hallo!
Der Ansatz ist ja schon mal gut - klingt, als hättest Du mein Tutorium gelesen (http://www.office-loesung.de/ftopic318127_0_0_asc.php). Aber dann weißt Du ja auch, wie es weiter geht ;-)
Aber im Ernst: Du könntest jetzt anfangen, entsprechend Deinem Datenmodell (das sicher noch nicht ganz komplett ist ...) Tabellen anzulegen. Achtung: Du solltest von Anfang an auf die saubere Vergabe der Namen für die Tabellen und deren Spalten achten (dazu Click auf "www" links neben meinem Posting und dort die Seite "Namenskonvention" studieren!).
Dann kannst Du die zunächst noch leere DB ja mal hier hochladen (http://www.office-loesung.de/ftopic126638_0_0_asc.php) und wir können uns das ansehen.
Unabhängig davon hat derArb natürlich Recht: Damit wir wissen, was Du willst, wären einige Zeilen Prosa zur Erläuterung Deines Projektes nicht schlecht!

Für den Neuling noch einige Formalien:

(1) Bitte nenn Deine DB nicht "test" oder so ähnlich, sondern gib ihr ...
  Thema: Mediendatenbank für Studium 
astern

Antworten: 5
Aufrufe: 574

BeitragForum: Access Hilfe   Verfasst am: 20. Dez 2011, 22:58   Titel: AW: Mediendatenbank für Studium Version: Office 2010
Hallo!
Wenn Du links neben diesem Posting auf "www" clickst, dann findest Du dort unter "Downloads" eine Datenbank für eine Bücherverwaltung. Das ist zwar nicht so allgemein für "Medien", wie Du es möchtest, zeigt aber evtl., wie es geht. Kannst Dir die DB "verleih" ja mal runterladen und ansehen.

MfG
A*
  Thema: Frage zum Aufbau: Adressverwaltung 
astern

Antworten: 6
Aufrufe: 890

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 20. Dez 2011, 19:12   Titel: AW: Frage zum Aufbau: Adressverwaltung Version: Office 2003
Hallo!
Ich habe' Dir mal was gebastelt!

Hier noch einige Formalien:
(1) Lad' Deine Dateien doch direkt hier hoch (http://www.office-loesung.de/ftopic126638_0_0_asc.php). Diese free-download-sites sind immer ziemlich nervig!
(2) Bitte nenn Deine DB nicht "test", sondern gib ihr einen sachbezogenen Namen, damit man schon am Namen erkennt, worum es geht - also z.B. "Auftraege"!
(3) Eine saubere Versionsverwaltung ist das A und O der Software-Entwicklung! Du wirst Deine DB sicher Schritt für Schritt verbessern und dann noch öfter hier hochladen und die, die Dir hier helfen, speichern sich die DB auf ihrem Rechner. Dann möchte man schon wissen, um welche Version es aktuell geht.
Der vollständige Name Deiner DB sollte also z.B. lauten "Auftraege-v03"!

MfG
A*
  Thema: Porsche Bauteildatenbank - ein paar Fragen 
astern

Antworten: 3
Aufrufe: 766

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 19. Dez 2011, 17:17   Titel: AW: Porsche Bauteildatenbank - ein paar Fragen Version: Office XP (2002)
Hallo!
Du brauchst erst einmal ein vernüftiges Datenmodell - den ganzen Code kannst Du vergessen. So weit bist Du noch LAAANGE nicht!!
Lies' Dir mal mein Tutorium durch: http://www.office-loesung.de/ftopic318127_0_0_asc.php und dann bilde die "A*'schen Sätze" mit den Worten:

- Projekt,
- Derivat,
- Motor (typ!),
- Getriebe (typ!),
- Bremsen (typ!),
- Fahrwerk (typ!),
- Räder (typ!)

Ich habe überall (typ!) dahinter geschrieben, weil ich denke, dass es nicht um ein ganz bestimmtes Rad geht (die sind ja wohl kaum durchnummeriert - oder!?), sondern um einen bestimmten Radtyp. Genauso bei allen anderen Objekten.

Also:
Zu EINEM Projekt gehört EIN Motor(typ).
EIN Motor(typ) gehört zu MEHREREN Projekten.
Also eine 1:n-Relation zwischen tblProjekt und tblMotortyp.
Richtig?

Zu EINEM Motor(typ) können MEHRERE verschiedene Getriebe(typen) gehören.
EIN Getrieb(typ) kann zu MEHREREN verschiedenen Motor(typen) gehören.
Also eine m:n-Relation zwischen tblMoto ...
  Thema: Frage zum Aufbau: Adressverwaltung 
astern

Antworten: 6
Aufrufe: 890

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 19. Dez 2011, 14:56   Titel: AW: Frage zum Aufbau: Adressverwaltung Version: Office 2003
Hallo!
Ich habe auf meinen Webseiten (Click auf "www" links neben dem Posting) unter "Lösungen" eine ganze Reihe von Beispielen, in denen es um eine ähnliche Problematik geht wie bei Dir. Such mal einfach auf der Webseite mit der Suchfunktion des Browsers nach dem Wort "Kontakt" - so nenne ich nämlich immer die Tabelle mit den Kontaktangaben (Adresse, Telefon, Fax, ... usw.). Vielleicht hilft Dir das schon weiter. Sonst melde Dich nochmal und dann basteln wir ein Datenmodell für Dich!
Achtung: Sieh' Dir auf meinen Webseiten auch mal den Punkt "Namenskonvention" an!!

MfG
A*
  Thema: Portraits - Von wem?! Über wen?! 
astern

Antworten: 3
Aufrufe: 499

BeitragForum: Access Hilfe   Verfasst am: 17. Nov 2011, 08:39   Titel: AW: Portraits - Von wem?! Über wen?! Version: Office 2010
Also:
Am Portrait EINER Person wirken MEHRERE Personen mit.
EINE Person wirkt an MEHREREN Portraits mit.
Also eine m:n-Beziehung zwischen Person und Portrait.

ABER: Eine Tabelle tblPortrait wird gar nicht benötigt, denn:

Zu EINER Person gibt es EIN Portrait.
EIN Portrait gehört zu EINER Person.
Also eine 1:1-Beziehung zwischen Person und Portrait.
Damit sind das gar nicht zwei Tabellen, sondern nur eine.

Also lesen sich die ersten zwei Sätze eigentlich so:
An EINER Person (="Portrait"!) wirken MEHRERE Personen mit.
EINE Person wirkt an MEHREREN Personen (="Portraits"!) mit.
Also eine m:n-Beziehung zwischen Person und Person.

siehe Beispiel unten:
Am Portrait von Klaus ("per_id_f1=1") haben Petra ("per_id_f2=2") und Carmen ("per_id_f2=4") mitgearbeitet. Carmen ("per_id_f2=4") hat aber außerdem auch am Portrait von Petra ("per_id_f1=2") mitgearbeitet. usw.

MfG
A*

PS: Sorry, Namensfehler im ...
  Thema: Tabellenstruktur 
astern

Antworten: 27
Aufrufe: 3411

BeitragForum: Access Hilfe   Verfasst am: 17. Nov 2011, 07:36   Titel: AW: Tabellenstruktur Version: Office 2003
Hallo!
Das ist so: Bei jeder Ein- und Auslagerung erfolgt ein Eintrag in der Tabelle tblArt_Ort. Dazu gehört dann auch die Bemerkung. Erfolgt eine neue Ein- oder Auslagerung, so gibt es einen neuen Eintrag in tblArt_Ort - ebenfalls wieder mit einem Feld Bemerkung. Es gibt dann also z.B. eine Bemerkung zu der Einlagerung am 17. ("Lieferant Meier, am 12. bestellt") und eine Bemerkung zu der Auslagerung am 22. ("Kunde Lehmann"). Angezeigt wird immer der letzte Stand - also die letzte Ein- oder Auslagerung zusammen mit der dazugehörigen Bemerkung. Dadurch sieht es so aus, als wäre die vorherige Bemerkung gelöscht worden. Ist sie aber nicht. Sie steht nur in einer anderen Zeile der Tabelle tblArt_Ort. (Sieh mal direkt in der Tabelle tblArt_Ort nach!)
Ich habe mittlerweile eine neue Version der LagerDB, in der eine "Artikelhistory" und eine "Ortshistory" angezeigt werden können. Dort sieht man dann alle Einträge in der Tabelle tblArt_Ort und somit a ...
  Thema: Spielergebnisse auswerten und drucken 
astern

Antworten: 13
Aufrufe: 573

BeitragForum: Access Hilfe   Verfasst am: 06. Nov 2011, 19:49   Titel: AW: Spielergebnisse auswerten und drucken Version: Office 2010
Hallo!
Ich habe hier vor längerer Zeit schon mal das Thema "Billard" bearbeitet:
[url=http://www.office-loesung.de/ftopic355386_0_0_asc.php]Spieldatenbank für Billardspiele
Vielleicht hilft das?

Wenn jemand "vollkommener Access-Laie" ist, dann ist das schwer, hier im Forum zu helfen. Access lernt man nicht nebenbei und auch nicht durch ein paar gute Tipps. Da muss man sich ein Buch kaufen und selber richtig viel Zeit und Mühe investieren! Das ist nicht wie Excel, wo jeder mal fix ein paar Tabellen erstellen und irgendwie irgendetwas berechnen kann. Access ist halt anders und aufwändiger! Du musst Dich wirklich selber da reinknieen und dann konkrete Detailfragen stellen, die man auch beantworten kann, ohne gleich ein Access-Buch zu posten.

MfG
A*

PS: "Leihe" = "Laie", "Exel" = "Excel"!!
  Thema: Hilfe beim Erstellen einer Datenbank 
astern

Antworten: 8
Aufrufe: 324

BeitragForum: Access Hilfe   Verfasst am: 26. Aug 2011, 15:44   Titel: AW: Hilfe beim Erstellen einer Datenbank Version: Office 2010
Hallo!
derArb hat Dich ja schon auf mein Tutorial hingewiesen. Das arbeite erst mal durch. Ich muss Dich aber gleich warnen: Access ist nicht einfach! Da muss man sich schon reinknien und sich eine Menge Wissen Stück für Stück erarbeiten.
Warum muss es denn unbedingt Access sein? Überleg doch erst mal, ob Du Dein Problem auch mit Excel lösen kannst. Das ist nämlich deutlich einfacher. Da kommst Du nämlich mit ziemlicher Sicherheit ohne VBA-Programmierung aus - in Access definitiv nicht!
Wenn es denn unbedingt Access sein soll, musst Du Dein Problem umfassender und exakter beschreiben! Ohne Bezugnahme auf irgendwelche Tabellen! Erst mal geht es um die Identifizierung von Objekten und den Beziehungen zwischen ihnen (siehe mein Tutorial!).
Gibt es Fahrzeuge? Touren? Orte? Aufträge? ...

Dann etwa so:

EIN Auftragnehmer fährt MEHRERE Touren.
EINE Tour wird von EINEM Auftragnehmer gefahren.

EINE Tour führt über MEHRERE Orte.
EIN Ort gehört zu MEHREREN Touren.

Jeder Satz beg ...
  Thema: Beziehungen so richtig? 
astern

Antworten: 52
Aufrufe: 2806

BeitragForum: Access Tabellen & Abfragen   Verfasst am: 26. Aug 2011, 13:03   Titel: Re: AW: Beziehungen so richtig? Version: Office XP (2002)
Hallo!
Zum Lernen: ein gutes Buch ist sicherlich nicht verkehrt. Aber man lernt auch viel aus guten Beispielen und Tutorien
Dort lernt man aber fast ausschließlich, die BEDIENUNG von Access ("Wie realisiere ich zwei abhängige Kombinationsfelder?"). Das ist aber schon der zweite Schritt. Der erste ist immer und immer wieder das Datenmodell. Bei einem schlechten Datenmodell helfen auch die genialsten Programmiertricks nicht mehr weiter. Das Datenmodell ist das A und O. Damit steht und fällt alles!
Wer übereilt anfängt, Formulare zu entwickeln, wird das sehr schnell bereuen, aufgeben und auf "Sch...-Access" schimpfen. Du schreibst ja selber:
Bevor Du aber tiefer einsteigst, prüfe noch einmal genau das vorliegende Datenmodell - denn es wäre schade um die Zeit, wenn Formulare gebastelt werden, die hinterher einzustampfen sind.
Das kann ich nur GANZ DICK unterstreichen!! Und das sollte man hier im Forum den Fragestellern immer und immer wieder sagen: "Leute - ...
 
Seite 14 von 113 Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6, 7 ... 11, 12, 13, 14, 15, 16, 17 ... 107, 108, 109, 110, 111, 112, 113  Weiter
Gehe zu:  
Alle Zeiten sind
GMT + 1 Stunde

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Microsoft Excel Tricks