Ich soll für ein Projekt eine Datenbank erstellen um ein Time Reporting zu ermöglichen. Das heisst es gibt folgende Variablen: Datum, Mitarbeiter, Abteilung, Kunde, Projekt, Projektstunden.
Nun, wie organisiere ich meine Tabellen (Wie viel und mit welchen Variablen), wenn ich folgende Auswertungen machen will?
- Anzahl Gesamtstunden für ein/alle Projekte
- Anzahl Gesamtstunden für einen Kunden
- Anzahl Stunden in einem Zeitraum für einen Arbeiter
Ich habe an folgendes gedacht:
tblMain mit ID, Datum, MitarbeiterID, AbteilungID, KundeID, ProjektID, Projektstunden
und jeweils für die Variablen mit ID Zusatz eine eigene Tabelle.
Ist das sinnvoll?
BITTE helfen Sie uns HEUTE mit einer SPENDE
Helfen Sie das OpenOffice Forum zu erhalten!
> KEINE WERBUNG FÜR REGISTRIERTE BENUTZER!<
Ihre Spende wird für die Deckung der laufenden Kosten sowie den Erhalt und Ausbau 🌱 des OpenOffice Forums verwendet.
🤗 Als Dankeschön werden Sie im Forum als OO-SUPPORTER gekennzeichnet. 🤗
Tabellen Aufbau bei neuer Datenbank
-
heikkisorsa
- Beiträge: 2
- Registriert: Mi 2. Jul 2014, 10:12
Re: Tabellen Aufbau bei neuer Datenbank
Hallo heikkisorsa,
willkommen im Forum.
In Deinem "tblMain" kommt es möglicherweise zu überflüssigen Doppeleingaben, z.B. könnte die Abteilungs_ID bei den Mitarbeiterdaten und die Kunden_ID bei den Projektdaten enthalten sein (Beispiel weiter unten). Führe die Daten besser über Abfragen oder Views zusammen, als sie in einer großen Einzeltabelle zu erfassen. Diese Abfragen oder Views sind dann Grundlage für Formulare und Berichte, die zur Eingabe und Auswertung angelegt werden.
Es kommt halt immer auf den konkreten Fall an. Jedoch ist für eine konkrete Antwort zu wenig Info da. Es stellen sich Fragen wie:
- Welches Betriebssystem und welche Office-Version benutzt Du?
- Welche Art DB ist vorgesehen, eine eingebettete Base_DB, eine mehrplatzfähige MySQL?
- Kann ein Projekt mehrere Kunden betreffen (Stadtteil-Projekte)?
- Ist ein Projekt einer oder mehreren Abteilungen zugeordnet?
- Kann ein Mitarbeiter für mehrere Abteilungen tätig sein (Montage und Wartung)?
- Woher beziehst Du die Daten für die Stundenerfassung und wie sind die aufbereitet (Stundenzettel / Mitarbeiter, Stundenzettel / Projekt)? und, und, und ...
Vorschlag: Folge der Betriebsstruktur und passe Deine DB den vorhandenen Betriebsabläufen an.
Ein sehr simpler Aufbau der "Haupttabelle" könnte beispielsweise sein:
Tabelle "Mitarbeiter im Projekt"
Spalten: ID, ProjektNr, Datum, Mitarbeiter_ID, Stunden
In anderen Tabellen ist dann hinterlegt was repräsentiert die
- ProjektNr - z.B.Kunden_ID, Bezeichnung, Sollstunden, Orte, usw
- Mitarbeiter_ID - z.B. Name, Adresse, Qualifikation, Abteilung, usw
Je nach Erfordernis müssen dann weitere Tabellen für Kunden, Abteilung usw angelegt und zueinander in Beziehung gesetzt werden. Wie oben beschrieben werden die Infos dann über Abfragen/Views, Formulare und Berichte aufbereitet und ausgewertet.
Sehr empfehlenswert ist dazu in den Handbüchern von LibreOffice zu stöbern: http://de.libreoffice.org/hilfe-kontakt/handbuecher/. Auf der Seite ein wenig nach unten scrollen, bis zu den Base Handbüchern und Beispieldateien. Soweit ich weiß, sind Libre- und OpenOffice noch weitgehend kompatibel.
Viel Erfolg
harald
willkommen im Forum.
Das kommt darauf an.heikkisorsa hat geschrieben:Ist das sinnvoll?
In Deinem "tblMain" kommt es möglicherweise zu überflüssigen Doppeleingaben, z.B. könnte die Abteilungs_ID bei den Mitarbeiterdaten und die Kunden_ID bei den Projektdaten enthalten sein (Beispiel weiter unten). Führe die Daten besser über Abfragen oder Views zusammen, als sie in einer großen Einzeltabelle zu erfassen. Diese Abfragen oder Views sind dann Grundlage für Formulare und Berichte, die zur Eingabe und Auswertung angelegt werden.
Es kommt halt immer auf den konkreten Fall an. Jedoch ist für eine konkrete Antwort zu wenig Info da. Es stellen sich Fragen wie:
- Welches Betriebssystem und welche Office-Version benutzt Du?
- Welche Art DB ist vorgesehen, eine eingebettete Base_DB, eine mehrplatzfähige MySQL?
- Kann ein Projekt mehrere Kunden betreffen (Stadtteil-Projekte)?
- Ist ein Projekt einer oder mehreren Abteilungen zugeordnet?
- Kann ein Mitarbeiter für mehrere Abteilungen tätig sein (Montage und Wartung)?
- Woher beziehst Du die Daten für die Stundenerfassung und wie sind die aufbereitet (Stundenzettel / Mitarbeiter, Stundenzettel / Projekt)? und, und, und ...
Vorschlag: Folge der Betriebsstruktur und passe Deine DB den vorhandenen Betriebsabläufen an.
Ein sehr simpler Aufbau der "Haupttabelle" könnte beispielsweise sein:
Tabelle "Mitarbeiter im Projekt"
Spalten: ID, ProjektNr, Datum, Mitarbeiter_ID, Stunden
In anderen Tabellen ist dann hinterlegt was repräsentiert die
- ProjektNr - z.B.Kunden_ID, Bezeichnung, Sollstunden, Orte, usw
- Mitarbeiter_ID - z.B. Name, Adresse, Qualifikation, Abteilung, usw
Je nach Erfordernis müssen dann weitere Tabellen für Kunden, Abteilung usw angelegt und zueinander in Beziehung gesetzt werden. Wie oben beschrieben werden die Infos dann über Abfragen/Views, Formulare und Berichte aufbereitet und ausgewertet.
Sehr empfehlenswert ist dazu in den Handbüchern von LibreOffice zu stöbern: http://de.libreoffice.org/hilfe-kontakt/handbuecher/. Auf der Seite ein wenig nach unten scrollen, bis zu den Base Handbüchern und Beispieldateien. Soweit ich weiß, sind Libre- und OpenOffice noch weitgehend kompatibel.
Viel Erfolg
harald
-
heikkisorsa
- Beiträge: 2
- Registriert: Mi 2. Jul 2014, 10:12
Re: Tabellen Aufbau bei neuer Datenbank
Hallo Harald,
danke für deine ausführliche Antwort. Hier meine Ergänzungen:
- Die Daten sind nicht vorhanden, werden aber täglich bis wöchentlich von den Mitarbeitern selber eingegeben (über ein DB Formular). Darum habe ich einen tblMain vorgeschlagen, damit jeder Formulareintrag da eins zu eins wieder erscheint (Welcher Mitarbeiter hat an welchem Tag wie viel Stunden für welchen Kunden und welches Projekt gearbeitet).
- Betriebssystem ist durchgehend Win 8.1 und Base von OO 4.1
- Im Moment ist wegen der Einfachheit eine eingebettete DB vorgesehen, jedoch optional in Zukunft mehrplatzfähig
- Die feine Unterteilung der Variablen hat den Grund, dass unsere Mitarbeiter in verschiedenen Abteilungen Arbeiten und Kunden verschieden Projekte haben können (und auch verschiedene Kunden an einem Projekt beteiligt)
Bezüglich deinem Beispiel:
Wir brauchen in dieser DB eigentlich gar nicht mehr Variablen als ich am Anfang geschrieben habe. Darum sehen tblMitarbeiter etc. sehr leer aus (Meistens nur eine ID und dann noch eine Wertevariable). Ist das überhaupt sinnvoll?
MfG
danke für deine ausführliche Antwort. Hier meine Ergänzungen:
- Die Daten sind nicht vorhanden, werden aber täglich bis wöchentlich von den Mitarbeitern selber eingegeben (über ein DB Formular). Darum habe ich einen tblMain vorgeschlagen, damit jeder Formulareintrag da eins zu eins wieder erscheint (Welcher Mitarbeiter hat an welchem Tag wie viel Stunden für welchen Kunden und welches Projekt gearbeitet).
- Betriebssystem ist durchgehend Win 8.1 und Base von OO 4.1
- Im Moment ist wegen der Einfachheit eine eingebettete DB vorgesehen, jedoch optional in Zukunft mehrplatzfähig
- Die feine Unterteilung der Variablen hat den Grund, dass unsere Mitarbeiter in verschiedenen Abteilungen Arbeiten und Kunden verschieden Projekte haben können (und auch verschiedene Kunden an einem Projekt beteiligt)
Bezüglich deinem Beispiel:
Wir brauchen in dieser DB eigentlich gar nicht mehr Variablen als ich am Anfang geschrieben habe. Darum sehen tblMitarbeiter etc. sehr leer aus (Meistens nur eine ID und dann noch eine Wertevariable). Ist das überhaupt sinnvoll?
MfG
Re: Tabellen Aufbau bei neuer Datenbank
Hallo heikkisorsa,
Den Namen immer wieder neu zu schreiben führt zu Fehlern. Die Namen in einer festen Werteliste im Formular zu hinterlegen führt zu Unübersichtlichkeit und wird lästig. Von Erweiterbarkeit, eine der Stärken einer Datenbank, ist dann nicht mehr die Rede.
Bisher sind alle meine Datenbanken im Laufe der Zeit gewachsen, weil aus der praktischen Arbeit damit neue Wünsche entstanden sind: Wär doch gut, wenn man bei dem Kunden noch einen Ansprechpartner eingeben könnte ... wär doch nett, wenn bei dem Automechaniker noch der Stundenlohn dabei wäre, usw... Dann baust Du die jeweilige Tabelle einfach aus und mußt nicht die Struktur der DB grundlegend ändern.
Wenn bereits jetzt die Überlegung zu einer Mehrplatz-Lösung im Raume steht, machts vielleicht doch gleich, auch wenn vorerst nur ein Arbeitsplatz genutzt wird. So habt ihr später deutlich weniger Umbau- und Anpassungsbedarf. Dem steht natürlich entgegen, das die eingebettete Datenbank wahrscheinlich schneller zur Verfügung stehen kann und keine Administration erforderlich ist. Hier kommt es wieder auf die tatsächlich vorhandenen Gegebenheiten an.
Gruß harald
Nach meiner Ansicht eindeutig ja.heikkisorsa hat geschrieben:Darum sehen tblMitarbeiter etc. sehr leer aus (Meistens nur eine ID und dann noch eine Wertevariable). Ist das überhaupt sinnvoll?
Den Namen immer wieder neu zu schreiben führt zu Fehlern. Die Namen in einer festen Werteliste im Formular zu hinterlegen führt zu Unübersichtlichkeit und wird lästig. Von Erweiterbarkeit, eine der Stärken einer Datenbank, ist dann nicht mehr die Rede.
Bisher sind alle meine Datenbanken im Laufe der Zeit gewachsen, weil aus der praktischen Arbeit damit neue Wünsche entstanden sind: Wär doch gut, wenn man bei dem Kunden noch einen Ansprechpartner eingeben könnte ... wär doch nett, wenn bei dem Automechaniker noch der Stundenlohn dabei wäre, usw... Dann baust Du die jeweilige Tabelle einfach aus und mußt nicht die Struktur der DB grundlegend ändern.
Wenn bereits jetzt die Überlegung zu einer Mehrplatz-Lösung im Raume steht, machts vielleicht doch gleich, auch wenn vorerst nur ein Arbeitsplatz genutzt wird. So habt ihr später deutlich weniger Umbau- und Anpassungsbedarf. Dem steht natürlich entgegen, das die eingebettete Datenbank wahrscheinlich schneller zur Verfügung stehen kann und keine Administration erforderlich ist. Hier kommt es wieder auf die tatsächlich vorhandenen Gegebenheiten an.
Gruß harald