Mehrere verschiedene Zeiträume für ein Attribut ermitteln

gamma_matrices

Cadet 4th Year
Registriert
Sep. 2018
Beiträge
121
Hallo,
ich möchte eine Abfrage erstellen, in der ich für ein Attribut (a) mehrere zeitliche Informationen aus einer Tabelle (T) herauskriegen möchte. Das Attribut a selbst ist in T enthalten. Beispielsweise möchte ich wissen, von wann bis wann eine Person bei welchem Arbeitgeber (Attribut b ist auch in T enthalten) genau beschäftigt war.
Hat da jemand eine Idee, wie man genau an die Zeiten rankommen könnte?

Danke!
 
die Frage ist mit den aktuellen Infos faktisch nicht zu beantworten ...
"Abfrage" = relationale Datenbank? SQL? Oder doch was anderes wie InfluxDB oder ... oder ...

Wenn rel. DB, wie sieht das Schema aus? Aktuell wissen wir nur dass es ein Attribut A gibt, aber werden ueberhaupt temporale Daten worin auch immer vorhanden sein fuer die Abfrage? Du kannst nur das abfragen was die Daten enhalten
 
  • Gefällt mir
Reaktionen: guzzisti und ReignInBlo0d
ist relationale DB und möchte ein SQL statement erstellen. Die Zeitattribute (c = Beginn und d = Ende) sind auch in T enthalten.
 
Hilfreich wäre jetzt noch der Datentyp der jeweiligen Spalten, damit man eine sinnvolle Query formulieren kann. Sonst ist das nur Rätselraten.
Also bitte am besten einmal wie bereits in #2 gefordert das Schema hier auflisten. Dann gehts am einfachsten vorwärts.
 
SQL:
CREATE TABLE Arbeitgeber( 
    PERSONALID NUMBER NOT NULL, 
    ARBEITGEBER_NAME VARCHAR2(255) NOT NULL, 
    BEGINN DATE,   
    ENDE DATE,
    ...
    PRIMARY KEY (PERSONALID)
);

Zum PK müssten alle AGs mit Zeiträumen angegeben werden. Dabei ist zu beachten, dass zum selben PK mehrere AGs existieren können!
 
Zuletzt bearbeitet:
Dein Primärkey funktioniert so nicht - ein PK MUSS eindeutig sein. Die PersonalID sollte mit dem vorliegenden Infos m.E. eher ein Fremdschlüssel auf eine Personal Tabelle sein. Der Primärkey auf die Arbeitgeber Tabelle ist dann entweder was künstliches (Sequenz) oder muss sich aus mehreren Feldern zusammen setzen.

Die Daten über alle Arbeitgeber inkl. Beginn und Ende sind mit einem simplem SELECT * FROM Arbeitgeber abzufragen - irgendwie hab ich aber grad das Gefühl dass das nicht die Antwort ist die du suchst.

Entweder es fehlen noch relevante Infos oder dein Problem ist eigentlich ein anderes...
 
Sorry da kam wohl was durcheinander. PK muss PersonId und die Tabelle Person heissen. Außerdem hat sie als FK ArbeitgeberId (Referenz zum Arbeitgeber)

SQL:
CREATE TABLE Person (
    PERSONID NUMBER NOT NULL,
    BEGINN DATE,
    ENDE DATE,
    ARBEITGEBERID NUMBER NOT NULL
    ...
    PRIMARY KEY (PERSONALID)
);
 
Das funktioniert m.E. so immer noch nicht, jetzt kannst du nur einen Beschäftigungszeitraum pro Person angeben.

Beschreibe doch einmal vollständig und verständlich was du überhaupt erreichen willst.
 
Ich möchte erreichen, dass ich für eine PersonId alle Beschäftigungszeiträume (BEGINN und ENDE) ausgeben lassen kann, so dass ich weiss, bei wem die Person in welchem Zeitraum jeweils beschäftigt war.
Ergänzung ()

Kann man das irgendwie mit einer Schleife lösen?
 
Zuletzt bearbeitet:
Das ist eine N:M Beziehung - dazu brauchst du eine passende Relation zwischen Personal und Arbeitgeber.

Kann ich Dir morgen zusammen schreiben wenn nicht über Nacht sich jemand die Arbeit macht.
 
  • Gefällt mir
Reaktionen: gamma_matrices
Angenommen die Tables würden bereits existieren:
SQL:
SELECT
    ANAG.*
FROM
    Arbeitnehmer AS AN
    INNER JOIN ArbeitnehmerArbeitgeber AS ANAG ON ANAG.ANID = AN.ANID
    INNER JOIN Arbeitgeber AS AG ON AG.AGID = ANAG.AGID
WHERE
    AN.ANID = 10
 
  • Gefällt mir
Reaktionen: guzzisti
Merke: was in SQL "gefühlt" nicht in eine Tabelle gehört, das gehört auch meist tatsächlich nicht in die Tabelle. Das ist natürlich nicht exakt, aber zumindest eine gewisse "Gedächtnisstütze":
  • Hat eine Person "Beginn" und "Ende"?
  • Soweit es über deren Geburt und Tod hinausgeht: nein.

Da man in SQL Relationen nur zweidimensional verknüpfen kann ( A x B ) eine n x m Relation aber dreidimensional ist, braucht man immer eine Zwischentabelle. Und muß drauf achten, welcher PK und welcher FK wohin kommt.

Die brauchen ein bißchen Abstraktionsvermögen um zu kapieren was da rein kommt. In allen Fällen ist die Struktur aber grundsätzlich dieselbe:
SQL:
CREATE TABLE table_A
(
id int NOT NULL PRIMARY KEY
-- ....
)

CREATE TABLE table_B
(
id int NOT NULL PRIMARY KEY
)

CREATE TABLE intermediate_table
(
id_a int NOT NULL REFERENCES table_A(id),
id_b int NOT NULL REFERENCES table_B(id)
PRIMARY KEY(id_a, id_b)
)
sodaß:
1. Weder Table_A noch Table_B referenzieren einander (die haben exakt nichts miteinander zu tun im Sinne von SQL)

2. der PK der Zwischentabelle ist notwendigerweise zusammengesetzt aus mindestens zwei PK Spalten der "teilnehmenden" Tabellen

3. je nach Situation können das auch mehr als zwei teilnehmende Tabellen sein, je nachdem wieviele Aspekte eine solche Verknüpfung berücksichtigen muß.

4. Weitere Spalten in diese Relation beschreiben die Eigenschaften der Verknüpfung.
Das wird in diesem Fall wichtig. Weder der Arbeitgeber noch der Arbeitnehmer "beginnt" oder "endet" irgendwann, sondern die Beziehung zwischen den beiden tut dies. Entsprechend wandern beginn und ende in die Zwischentabelle.

Ebenso wenn weitere Anforderungen an die Verknüpfung gestellt werden müßten oder weil es keine Zeit*räume* sondern Zeit*fenster* geben würde.
Dann kommen nicht beginn und ende in die Zwischentabelle, sondern in eine Tabelle Zeitfenster und deren PK wird zusätzlich in den PK der Zwischentabelle eingetragen werden (als zusätzliche Dimension dort).

Sind die PK einer teilnehmenden Tabelle schon zusammengesetzt, müssen auch alle Spalten dieses PK mitgenommen werden. Weswegen ein einteiliger PK den mehrteiligen vorzuziehen ist, wo möglich.
 
Ich möchte darauf hinweisen, dass die Person innerhalb desselben Zeitraums nur bei einem AG tätig sein darf und ich somit nur für die jeweilige Person wissen möchte wo er überall wie lange bis dato chronologisch in der Zeit beschäftigt war.
Daher bin ich jetzt eher nicht von einer n:m Beziehung ausgegangen, sondern von 1:n.
Ergänzung ()

Rein hypothetisch: es existieren drei Tabellen (AG, AN und Beschäftigung). Wäre das dann mit Join möglich an die Info heranzukommen, wenn zwischen den Tabellen Schlüsselbeziehungen existieren?
 
Zuletzt bearbeitet:
Zurück
Oben