Hallo zusammen,
ich bin Anfänger was Access angeht und bräuchte ein wenig (mehr) Hilfe beim Design meiner ersten Datenbank, einer Projektverwaltung.
Was ich machen möchte: Eine ,,Tabelle" zur Verfügung stellen, in der (wie in einer Exceltabelle) alle Projekte zu sehen sind (Datensätze) und in der Projekte angelegt, bearbeitet und gelöscht werden können.
Es sollte eine "Gesamttabelle" geben mit allen Projekten und deren wichtigsten Informationen. Dann sollte es weitere Details mit weiteren Informationen zu Kosten, Einsparungen, Terminplänen zu den Projekten geben (entweder in gleicher Tabelle oder in einem neuem Formular?).
Ein Teil dieser Tabelle wird mit Datensätzen (Projekten samt Informationen) aus einer externen Exceltabelle gefüttert (Daten stammen aus externem Tool). Die Anzahl der Datensätze bzw. die Informationen können sich also ändern.
Es sollen aber für den Nutzer alle Projekte (aus externer Datei und per Hand hinzugefügte Projekte) in einer Tabelle stehen.
Nun habe ich zwar eine grobe Idee und vereinzelnde Kenntnisse, weiß aber nicht wie ich starten soll. Welche Tabellen brauche ich, wie kann man externe Daten (mit sich ändernder Anzahl an Datensätzen) und händisch zu pflegende Daten kombinieren...?!
Ich hoffe man kann das vertehen, wäre über jeden Hilfe für den Start sehr dankbar!
Grüße
Hallo,
sportlich ;)
Zitatich bin Anfänger was Access angeht und bräuchte ein wenig (mehr) Hilfe beim Design meiner ersten Datenbank, einer Projektverwaltung.
Die bekommst Du, allerdings nicht ohne eigenes Dazutun. Soll heißen, beschäftige Dich anhand von Büchern, Tutorials oder auch vorgeschlagenen Links mit den Grundlagen von Access (einen relationalen Datenbanksystem), bevor Du "loslegst". Siehe auch u. st. Links 1 bis 5. Speziell Links 1, 1a, 1b sind essentiell!
ZitatWas ich machen möchte: Eine ,,Tabelle" zur Verfügung stellen, in der (wie in einer Exceltabelle) alle Projekte zu sehen sind (Datensätze) und in der Projekte angelegt, bearbeitet und gelöscht werden können.
In einer (solchen) DB gibt es nicht "eine" Tabelle, es gibt deren (sehr) viele... Access ist NICHT Excel! Tabelllen sind auch nicht zur Bearbeitung der Daten zu verwenden, dafür gibt es Formulare und für Analysen Berichte.
ZitatEs sollte eine "Gesamttabelle" geben mit allen Projekten und deren wichtigsten Informationen. Dann sollte es weitere Details mit weiteren Informationen zu Kosten, Einsparungen, Terminplänen zu den Projekten geben (entweder in gleicher Tabelle oder in einem neuem Formular?).
Wie oben gesagt, gibt es keine Gesamttabelle. Benötigte Daten werden für jede Situation mittels Abfragen, die mehrere Tabellen miteinander verknüpfen, ausgelesen und Formularen oder Berichten zur Verfügung gestellt.
Die Tabellen/Abfragen selber soll(t)en später (während der Bedienung)
nicht für den Anwender sichtbar sein.
ZitatEin Teil dieser Tabelle wird mit Datensätzen (Projekten samt Informationen) aus einer externen Exceltabelle gefüttert (Daten stammen aus externem Tool). Die Anzahl der Datensätze bzw. die Informationen können sich also ändern.
Erst nachdem ein durchgängiges Daten (Tabellen-) Konzept (Stichwort "Normalisierung" Links 1, 1a 1b) erstellt ist, kann über einen Import nachgedacht werden. Üblicherweise wird die Excel-Datei in Access verknüpft und mittels Insert-Abfragen werden Daten in die entspr. Tabellen angefügt oder durch Update-Abfragen aktualisiert. Diese Aktualisierung kann aber problematisch sein.
ZitatEs sollen aber für den Nutzer alle Projekte (aus externer Datei und per Hand hinzugefügte Projekte) in einer Tabelle stehen.
Vergiss das. Wie oben gesagt, besteht eine DB aus mehreren Tabellen, nicht einer einzigen. Alle Manipulation an den Daten werden über Formulare bewerkstelligt, außer evtl. der angesprochene Import.
ZitatNun habe ich zwar eine grobe Idee und vereinzelnde Kenntnisse, weiß aber nicht wie ich starten soll. Welche Tabellen brauche ich,
Erstelle zunächst ein Datenanalyse: Welche Daten habe ich, welche Daten brauche ich, welche Daten gehören sinngemäß (inhaltlich) "zusammen" , was erwarte ich als Ergebnis aus der DB...
Wende die Normalisierungsregeln (zwingend) an (Links 1, 1a, 1b).
Erstelle das Tabellenkonzept (Beziehungen mit referenzieller Integrität, Datentypen konsequent beachten/definieren). Die Tabellen richten sich nach Deiner Datenstruktur.
Prüfe das Konzept.
Prüfe das Konzept nochmal,
und nochmal,
und nochmal.
Wenn das Konzept durchgängig ist, wäre der nächste Schritt, für jede Tabelle ein eigenes Formular zu erstellen.
1:n-Beziehungen können (werden) durch Haupt/Unterformular-Konstruktion dargestellt.
Hier ist es auch an der Zeit, über den Arbeitsablauf (wie soll die Db bedient werden) nachzudenken. Die Formulare bieten Ereignisse, mit deren Hilfe eine Ablaufsteuerung zu realisieren ist.
Zitatwie kann man externe Daten (mit sich ändernder Anzahl an Datensätzen) und händisch zu pflegende Daten kombinieren...?!
Ist eigentlich schon beantwortet. Wenn mit der Db gearbeitet wird, braucht nicht mehr zwischen externen (die gar keine mehr sind) und händisch gepflegten Daten unterschieden werden.
Hallo und vielen Dank für die Infos und Links.
Ich habe mich nun über Bücher, Youtube, etc. weiter vertraut gemacht aber hänge immer wieder an verschiedenen Stellen:
Ich habe meine Haupttabelle Projekte "tblProjects" in der ich folgende Felder habe:
ProjectID
ProjectName
ProgrammeID
ProjectTypeID
ComponentID
ResponsabilityID
StatusID
Value
Die Fremdschlüsselfelder verweisen auf Tabellen, die als "Lookup Tabellen" ausgegliedert wurden, um verschiedene Auswahlmöglichkeiten vorzugeben (z.B. verschiedene Projekttypen).
Jetzt ist meine Frage ob das so sinnvoll ist? Ich habe irgendwo gelesen, dass wenn man später in einer Abfrage mehrere Tabellen verknüpft und diese als Quelle für eine Form nimmt, kann man Datensätze nicht mehr verändern, bzw. neue Satensätze anlegen.
Was wäre in diesem Fall eine gute Strategie?
Danke und Grüße
Hi,
es kommt wohl auf die Art der Projekte an, die Du erfassen willst bzw. musst. Gemein dürften alle Projekte haben, dass sie inhaltlich und zeitlich geplant sind. Nach der Planung wird die Realisierung (vielfach in Einzelabschnitten, manchmal paralellel, oft von unterschiedlichen Persoinenkreisen) durchgeführt, die entweder dem Plan entspricht oder bei Abweichungen Korrekturen am Projekt erforderlich machen, was in der Regel in Projektbesprechungen stattfindet. Aus dem Bauch heraus wirst Du vielleicht Projekte wie Kindergeburtstagsfeiern in einer Haupttabelle (Nachschlagtabellen lasse ich mal außer acht) erzielen können - ein Haus- oder Brückenbau wird hingegen bei ordentlicher Struktur mehr Aufwand als nur eine Grundstruktur erfordern, denn es gilt ja nicht nur die Dinge und Personen eines Projekts zu erfassen, sondern auch die zeitlichen Abläufe relevanten Handlungs-bzw. Gestaltungsabschnitte in Einklang zu bringen.
Vielen Dank für die schnelle Info.
Ich habe für meine Art von Projekten weitere Tabellen nach den Themen Kosten, Zeitpläne, Meilensteine, etc. angelegt. In diesem Fall geht es mir konkret um die beschriebene Tabelle mit den Projektdetails. Ist es sinnvoll diese Details in verschiedene Tabellen auszugliedern und dann über Fremdschlüssel in die tblProjects zu holen?
Eine alternative wäre eine Auswahl über das Listenfeld oder combobox, aber ich habe gelesen, dass sowas vermieden werden sollte.
Hallo,
zeige uns einen Screenshot des Beziehungsfensters. Wenn noch keine Beziehungen (Primärschlüsselfelder-- Fremdschlüsselfelder) existieren, lege die an. Ziehe dabei die Tabellen-Fenster soweit auf, dass alle Felder zu erkennen sind.
aber ich habe gelesen, dass sowas vermieden werden sollte.
Wo hast Du das gelesen?
Das ist eigentlich der Normalfall, wenn die Auswahlkombifelder sind in Formularen befinden.
In der Tat sollte man auf Nachschlagefelder in Tabellen verzichten.
Hallo,
angehängt habe ich ein screenshot meiner Tabellen und der Beziehungen.
Dazu noch zwei Screenshots von Formularen, um zu zeigen was ich mir vorstelle. Dir Form Projects soll die Übersicht sein, in der eine einige Infos der Projekte angezeigt werden, aber nicht bearbeitet werden können. Die Infos die hier angezeigt werden kommen lediglich aus der Tabelle tblProjects.
Durch klicken auf "Edit Projects" möchte ich ein Formular öffnen, auf dem man über verschiedene Tabs zu den Meilensteinen/Schedule, Costs, Resources kommt, um dort diese Daten zu bearbeiten.
Hallo,
-- es sind nicht alle Tabellen im Beziehungsfenster aufgeführt.
-- die Beziehung tblDepartment/tblProjects kann (muss) entfallen. Die Zuordnung zum Department wird über tblEmployee hergestellt.
-- bei tbpProjectCapex/tblProjects und tbpProjectOpex/tblProjects ist keine ref. Integrität eingestellt.
-- tblYears kann entfallen, außer es soll eine "komfortable" Auswahl einer Jahreszahl möglich sein. Dann wäre die Jahreszahl selbst der Primärschlüssel und ein ID-Feld braucht es nicht. Weiterhin ist in diesem Fall auch keine Beziehung mehr nötig.
-- Haupttabelle wäre tblProjects. Detailtabellen dazu sind tblMilestones, tblProjectCapex, tblProjectOpex und tblEmployee. Alle anderen Tabellen sind Nachschlagetabellen.
Die Project-Liste ist ein Kandidat für einen (Analyse-)Bericht, weil vermutlich Gruppierungen dort stattfinden müssen.
Für alle Tabellen wären (Endlos-)Formulare zu erstellen, außer für tblProjects ein Einzelform. Für die Auswahl von Nachschlagewerten können Kombifelder mit Datensatzherkunft zur entspr. Tabelle eingesetzt werden. Für die Darstellung der der Detailtabellen kann eine Hauptform/Unterformkonstruktion dienen. Das Hauptform(frm_Project) enthält 4 Ufo-Steuerelemente, die die Detailtabellen-Formulare anzeigen.
Die Formularablaufsteuerung könnte allein im frm_Project stattfinden. Für neue Daten in den Nachschlagetabellen könnte das enstpr. Form mittels Doppelklick auf das entspr. Kombifeld geöffnet oder die Eigenschaft "Nicht in Liste" des Kombis benutzt werden.
Das Öffnen des Berichtes (rpt_Projeke) ist ebenfalls mit Hilfe eines Buttons dort möglich.
Wow, vielen Dank für die Mühe. Das werde ich jetzt mal versuchen nacheinander zu verstehen und abzuarbeiten:)
Einige Fragen hätte ich aber noch zum Verständnis:
- Du unterscheidest Detailtabellen und Nachschlagetabellen. Diese Unterscheidung kann ich nachvollziehen und leuchtet ein. Nur kann ich noch nicht ganz nachvollziehen was "Nachschlagetabelle" in derUmsetzung für mich bedeutet. Ich habe verstanden, dass man den Nachschlageassistenten für Felder nicht benutzen soll (https://www.tek-tips.com/viewthread.cfm?qid=1699756 (https://www.tek-tips.com/viewthread.cfm?qid=1699756)). Erstelle ich denn eine Beziehung zwischen Nachschlagetabelle und Haupttabelle oder verzichte ich auf die Beziehung und nutze ich die Nachschlagetabelle erst im Formular also RowSource?
- Für meine Formulare: Nutze ich die Tabellen direkt als Quelle oder ist es (generell) sinnvoller Abfragen für die Formulare zu erstellen?
Vielen Dank für die Hilfe und die Geduld!
Einen schönen Sonntag
Hallo,
zu 1)
Beziehungen solltest Du anlegen, auch für die Nachschlagefelder.
Nachschlagefelder werden aber nur in Formulare (=Kombinationsfelder) genutzt und erfüllen dort die gleiche Funktionalität.
In einer Datenbank sind grundsätzlich Beziehungen anzulegen und referentielle Integrität einzustellen.
Zu 2)
Im Regelfall immer Abfragen. Sobald Du eine zuverlässige Sortierung benötigst (was ja meist der Fall ist) musst Du ohnehin Abfragen verwenden. Eine Tabelle ist zunächst mal als unsortiert zu betrachten, bzw. wird immer nach dem Primärschlüssel sortiert angezeigt.
Eine Abfrage (mit Namen gespeichert, oder als Select ...) als Datenquelle ist auch der schnellste Zugriff auf die Daten. Schneller als auf die Tabelle direkt. Was natürlich erst bei großen Datenmengen spürbar wird bzw. werden kann.
Außerdem kannst Du nur mit einer Abfrage die Felder wählen die tatsächlich im Formular angezeigt werden sollen.
Und noch eine Frage:
Kommt der Projektleiter immer aus der verantwortlichen Abteilung ?
Nur dann könnte nämlich die Zuordung Abteilung entfallen.
@Klaus
ZitatAußerdem kannst Du nur mit einer Abfrage die Felder wählen die tatsächlich im Formular angezeigt werden sollen.
Bist du dir da sicher? Ich hatte da auch mit Tabellen als RecordSource
nie ein Problem?
Dem Rest stimme ich natürlich vollkommen zu.
gruss ekkehard
Hallo,
ZitatBist du dir da sicher? Ich hatte da auch mit Tabellen als RecordSource
nie ein Problem?
ja bin ich. Und es muss ja auch kein Problem sein bzw. geben.
Wenn Du auf die Tabelle zugreifst ist das gleichbedeutend wie "Select * From Tabellenname".
Mit einer Abfrage kannst Du gezielt nur die Felder laden/verwenden die auch benötigt werden.
ZitatMit einer Abfrage kannst Du gezielt nur die Felder laden/verwenden die auch benötigt werden.
Das könnte man nicht nur, das sollte man auch. Am Ende hat man schon in der Tabelle berechnete Felder, die werden dann auch fleißig alle durchgerechnet, ob man es braucht oder nicht.
Ein einfaches "SELECT * FROM Tabelle" macht genau das gleiche wie ein angegebener Tabellenname. Es wird alles geladen, das ergibt dann keinen Unterschied, auch hinsichtlich Performance nicht.
Schnneller wird es, wenn man die anzuzeigende datenmenge hinsichtlich Breite (Anzahhl Felder) als auch hinsichtlich Länge (verwendete Datensätze) auf das beschränkt, was wirklich benötigt wird. Weniger Masse braucht weniger Zeit zum Laden ... das muss wohl nicht explizit begründet werden.
Hallo,
etwas Off Topic:
ich selbst bin mit der Methode, nur den Tabellennamen, bzw. "Select * from tblTabelle.." in der Datenherkunft anzugeben, i. A. besser gefahren als am Anfang der Entwicklung eine dedizierte Select (Feld-) Liste anzugeben.
Trotz der intensiven Planung der benötigten Felder in einer Tabelle kommt es häufig vor, (z. B. durch "Vergesslichkeit" des Kunden), dass doch noch ein oder mehrere erwünschte/s Feld/er fehlt/en. Es genügt dann, nur das Feld in der Tabelle einzufügen (und im Formular natürlich, sofern erforderlich) und nicht auch noch die Select-Liste anzupassen.
ZitatSchneller wird es, wenn man die anzuzeigende Datenmenge hinsichtlich Breite (Anzahl Felder) als auch .... auf das beschränkt, was wirklich benötigt wird.
Dazu habe ich auch andere Meinungen/Untersuchungen gelesen, die behaupten, dass es schneller wäre, den ganzen DS auf einmal zu laden, als entspr. der Feldliste die Felder dediziert aus der Tabelle zu lesen, bzw. zu laden.
Das ist wie gesagt, "gelesene" Meinung und keine nachgeprüfte.
Hallo Klaus, hallo Eberhard,
Danke, ist mir alles bewusst. Dies
Zitatwenn man die anzuzeigende datenmenge hinsichtlich Breite (Anzahhl Felder) als auch hinsichtlich Länge (verwendete Datensätze)
ist IMO für einen Anfänger aber nicht so leicht aus Klaus' Aussage heraus
zu lesen, die sich doch sehr explizit anhört. Solche "Feinheiten" liest/lernt
man ja meist erst später.
gruss ekkehard