Announcement

Collapse
No announcement yet.

Ist das so richtig?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ist das so richtig?

    Hi @all,

    ich programmiere gerade mit Java und versuche mit der javadb(derby) eine Anwendung zu schreiben, welche die Stunden für Personal speichert und sie auch ausrechnet. Jetzt habe ich mal mit einem SQL-Editor die Datenbank "designed". Das sind meine ersten Versuche mit SQL und relationalen Datenbanken und ich dachte vielleicht kann hier einer seine Meinung zu meinem Modell mitteilen. Was ist falsch, fehlerhaft und nicht optimal?

    Anmerkungen zu Buchstaben und DataTypes:

    A=AutoIncrement
    N=NotNull
    P=Primary Key
    F=Foreign Key
    D=Default Value

    status= sollte eigentlich boolean werden. Die Idee dahinter ist es den Mitarbeiter auf den Status "aktiv" oder "passiv" zu setzen. z.B. Mitarbeiter verlässt das Unternehmen, und wird dann auf "passiv" gesetzt. Schlussendlich soll es dann so sein, dass der Mitarbeiter wenn er gelöscht wird, auch die Einträge in der Tabelle tbl_stunden und tbl_urlaub gelöscht werden. Soweit ich das jetzt weiß, unterstützt javadb kein boolean und man soll sich smallint bedienen.

    date und time= auch hier habe ich mich an den Datentypen der javadb orientiert.

    Der Code sieht folgendermaßen aus:
    Code:
    /* SQLEditor (Generic SQL)*/
    
    CREATE TABLE 'tbl_einsatzort'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'orte' CHAR(10),
    PRIMARY KEY ('id')
    );
    
    CREATE TABLE 'tbl_einsatztyp'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'typ' CHAR(10),
    PRIMARY KEY ('id')
    );
    
    CREATE TABLE 'tbl_mitarbeiter'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'vorname' CHAR(30) NOT NULL,
    'nachnahme' CHAR(30) NOT NULL,
    'sollstunden' DOUBLE NOT NULL,
    'eintrittsstunden' DOUBLE NOT NULL,
    'id_einsatzort' INTEGER NOT NULL,
    'id_einsatztyp' INTEGER NOT NULL,
    'status' SMALLINT(1) DEFAULT '0',
    'sollurlaub' DOUBLE NOT NULL,
    'vorurlaub' DOUBLE NOT NULL,
    PRIMARY KEY ('id')
    );
    
    CREATE TABLE 'tbl_pause'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'pause' DOUBLE NOT NULL,
    PRIMARY KEY ('id')
    );
    
    CREATE TABLE 'tbl_tagtyp'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'tagtyp' CHAR(20) NOT NULL,
    PRIMARY KEY ('id')
    );
    
    CREATE TABLE 'tbl_stunden'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'datum' DATE NOT NULL,
    'id_mitarbeiter' INTEGER NOT NULL,
    'anfang' TIME NOT NULL,
    'ende' TIME NOT NULL,
    'id_pause' INTEGER NOT NULL,
    'id_tagtyp' INTEGER NOT NULL,
    PRIMARY KEY ('id')
    );
    
    CREATE TABLE 'tbl_urlaub'
    (
    'id' INTEGER NOT NULL AUTO_INCREMENT,
    'id_mitarbeiter' INTEGER NOT NULL,
    'von' DATE NOT NULL,
    'bis' DATE NOT NULL,
    PRIMARY KEY ('id')
    );
    
    ALTER TABLE 'tbl_mitarbeiter' ADD FOREIGN KEY ('id_einsatzort') REFERENCES 'tbl_einsatzort' ('id');
    
    ALTER TABLE 'tbl_mitarbeiter' ADD FOREIGN KEY ('id_einsatztyp') REFERENCES 'tbl_einsatztyp' ('id');
    
    ALTER TABLE 'tbl_stunden' ADD FOREIGN KEY ('id_mitarbeiter') REFERENCES 'tbl_mitarbeiter' ('id');
    
    ALTER TABLE 'tbl_stunden' ADD FOREIGN KEY ('id_pause') REFERENCES 'tbl_pause' ('id');
    
    ALTER TABLE 'tbl_stunden' ADD FOREIGN KEY ('id_tagtyp') REFERENCES 'tbl_tagtyp' ('id');
    
    ALTER TABLE 'tbl_urlaub' ADD FOREIGN KEY ('id_mitarbeiter') REFERENCES 'tbl_mitarbeiter' ('id');
    Für Anregungen bin ich dankbar!
    Beste Grüße
    Attached Files

  • #2
    Sieht doch ganz gut aus Zum Löschen kannst Du einen Cascading Constraint definieren. Damit werden z.B. alle Stunden gelöscht die zu einem Mitarbeiter gehören, wenn der Mitarbeiter gelöscht wird.
    Ich weiss aber nicht ob das alle Datenbanken zur Verfügung stellen. Ansonsten müsstest Du manuell zuerst alle Stunden löschen und danach den Mitarbeiter.

    Comment


    • #3
      Ok, Danke! Nur schauen was derby sagt. Den oben stehenden Code wollte er nicht haben, da stimmte die Syntax nicht und den Begriff AUTO-INCREMENT kennt er auch nicht. Das heißt dann eher so: GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1). Aber irgendwie habe ich es doch hin bekommen.
      Cascading Constraint ist das Stichwort! So soll das ganze auch funktionieren. Mal schauen wie das bei derby läuft.
      Eine Frage: Wie läuft das eigentlich mit doppelten Einträgen? Kann man sowas mit SQL abfragen oder sollte ich die Überprüfung eher über Java laufen lassen? Kleines Beispiel:

      Mitarbeiter A: 25.10.2010 17:00 - 23:00 0,5 Pause //wenn dieser Eintrag schon steht, soll das System meckern und der Nutzer darauf hingewiesen werden, dass der Eintrag schon stattgefunden hat. Die Überprüfung des Tages hielt ich nicht für sinnvoll, weil es ja sein kann, das A am selben Tag auch zwichen 14:00 und 16:00 gearbeitet hat. Also die Überschneidung der Uhrzeiten prüfen. Geht das mit SQL?

      Alternativ mt Java:

      1. Java nimmt Eintrag des Nutzers entgegen.
      2. Java generiert SQL-Anweisung: Sag mir ob es einen Eintrag für A am 25.10 gibt?
      3. Java nimmt SQL-Output entgegen und vergleicht Uhrzeiten? Antwort:
      3.1 keine Überschneidung: Java generiert Insert-Code und trägt den Eintrag ein.
      3.2 Überschneidung: Java gibt Fehlermeldung aus und springt auf 1 zurück!

      Jetzt wo ich das schreibe, fällt mir auf das es ja eigentlich auch egal ist, ob die Überprüfung mittels Java oder SQL stattfindet, ich muss ja eh das Feedback der Datenbank verarbeiten.
      Ich teste!
      THX

      Comment


      • #4
        Hmmm... an dieser Stelle würde ich sagen lass das einfach den Benutzer machen. Wen sollte es stören, wenn man 2 Einträge zur gleichen Uhrzeit macht. Einen Administrator brauchst Du sowieso und der kann die Einträge dann richtig ziehen. Ich würde sagen es kommt sowieso sehr selten vor, da eine Person ziemlich schwer an 2 Positionen gleichzeitig sein kann.

        Mein Kredo:
        Benutzer nicht mit überflüssigen Regeln gängeln, sondern die Benutzer bei ihrer Arbeit unterstützen. Heisst: Stellt jemand überschneidende Termine ein, dem Adminstrator in irgendeiner Form eine Meldung zukommen lassen. Er hat sich darum zu kümmern die Zeiten zu korrigieren.

        Damit erübrigt sich auch die Frage wo Du Deine Regeln unterbringst, nämlich in Java. Das hat auch den Vorteil, dass die Geschäftsregeln nicht über das gesamte System verstreut sind, sondern zentral an einem Punkt abgelegt werden (Geschäftslogik). Für das UserInterface können Regeln meiner Meinung auch dupliziert werden (z.B. Name muss für Person ausgefüllt sein). Die maßgeblichen Regeln sollten aber immer in der Geschäftslogik zu finden sein.

        Comment

        Working...
        X