Beziehung über mehrere Entitäten?

Ja, glücklich bin ich mit der Darstellung auch aktuell nicht. Habe eine alte Version eines Zeichen Programms genutzt, dass eigtl extra die ER-Diagramm Funktion hatte ... allerdings sieht das ganze unglücklich aus.. versuche die Notation mal etwas anzupassen.

Ja, wahrscheinlich habe ich tatsächlich an der falschen Stelle gespart, habe mir nicht so viel Gedanken über das Erstellen der Tabellen gemacht.

Schaue mir nun noch MS SQL Server an, habe festgestellt, dass ich immer nach SQL Befehlen gelernt hatte, wovon einige scheinbar bei PostgreSQL nicht funktionieren (zB DATEDIFF zum Errechnen des Alters) - hab eine Weile gebrauccht herauszufinden, dass der Befehl bei Postgre SQL ein anderer ist :)
 
Werbung:
kolom schrieb:
Schaue mir nun noch MS SQL Server an, habe festgestellt, dass ich immer nach SQL Befehlen gelernt hatte, wovon einige scheinbar bei PostgreSQL nicht funktionieren (zB DATEDIFF zum Errechnen des Alters)
Zum Vergrößern anklicken....

Nun ja, M$SQL ist halt Lizenzsoftware. Was PostgreSQL betrifft: wenn man weiß, wonach man sucht, findet man das auch in der Doku. Errrechnen des Alters: -> Date/Time Functions and Operators -> age().
Das sind Funktionen, die nicht vom Standard definiert sind. PostgreSQL hat sehr, sehr viele Datentypen und dazu passende Funktionen. Es ist unwahrscheinlich, daß man nichts passendes findet.
 
Ja, gefunden habe ich es dann auch - hat mich aber eine Weile gebraucht herauszufinden, dass ich ständig den falschen Befehl genommen habe :)
Habe MS SQL genommen, da das am Schnellsten zu finden war und auch in der Version die ich genutzt habe (Express) erstmal kostenlos.
Bin aber auch hier für Alternativen offen :)
 
Edit (geht leider nicht mehr)

Habe das ER Diagramm mal in einer anderen Notation geschrieben, bin mir aktuell nicht sicher, ob dort auch alle notwendigen Informationen drin stehen - denke aber eigtl schon.
 

Anhänge

  • Crow Foot.png
    Crow Foot.png
    90 KB · Aufrufe: 3
kolom schrieb:
hat mich aber eine Weile gebraucht herauszufinden, dass ich ständig den falschen Befehl genommen habe
Zum Vergrößern anklicken....
Das ist nicht wirkllich ein Problem, Internet Suche mit "datediff postgres" oder auch "Datum substrahieren Postgres" ergibt sehr schnell brauchbare Treffer, wahlweise Tutorials, Gegenüberstellungen unterschiedlicher Server oder einfach die Dokumentation. Natürlich auch für andere DB.
Standard in den meisten RDBMS ist übrigens, dass man einfach mit Datumswerten rechnen kann, also z.B. aktuelles Tagesdatum - Geburtsdatum = Zeitwert der Differenz.
Es ist sogar standardisiert. In MS SQL geht es allerdings nicht. Und Sonderfälle sorgen hier für Überraschungen. Z.B.:
Aktuelles Tagesdatum - Aktuelles Tagesdatum = 0, laut Definition und gesundem Menschverstand.
ergibt in MS SQL
Code: 
1900-01-01
blöd

Bei SQL Fehlern muss man m.E. unterscheiden, handelt es sich um eine bloße Funktion oder um syntaktische Fehler. Es ist wirklich- egal welcher Server- meist sehr einfach, die passende Funktion im Internet zu finden. Leider halten sich nicht alle an die Standards und selbst wenn, wer, erst Recht welcher Anfänger kennt den Standard? Egal, es reicht zu wissen, dass man beliebige Funktionen im Internet flott finden kann. Wirklich kein Ding.
Syntaxprobleme sind eine andere Klasse. Und da besonders kommt es auch auf die Fehlermeldungen an. Die sind meist mittelprächtig und erfordern häufig etwas Überlegung, was einem die Fehlermeldung sagen will. Bei einigen Systemen unterirdisch, bei anderen verhältnismäßig vorbildlich. Fairerweise muss man sagen, dass Parser in dem Moment wo sie etwas anderes vorliegen haben als vorgesehen, naturgemäß ins Schlingern kommen (aussteigen). Die Parser wissen idealerweise vornehmlich, was wie geht. Dafür sind sie gebaut. In einem falschen SQL Statement die Fehler zeigen und benennen zu können, ist eine andere Hausnummer.

Die kommerziellen Marktführer (Oracle, MSSQL, ..) erlauben sich einen recht eigenwilligen Umgang mit den Standards. Teils weil sie schon vor dem Standard vergleichbare Funktionen anboten, teils weil sie sich halt erlauben können, es anders zu machen. Und natürlich will man auch noch was besonderes können. Man kämpft schließlich um die Marktführerschaft. Der Anwender ist da meist der Dumme. Den Jägern (der Marktführer) bleibt fast nichts anderes übrig, als verschiedene Standards zu bedienen, bspw. auch durch addons, die sie zu einem bestimmten Hersteller besonders kompatibel machen. Das hat natürlich seine Grenzen (siehe SQL Ergebnis 1900-01-01, wer will dazu kompatibel sein?).

Also, viel Erfolg mit Deinem ersten Projekt.
 
Ich denke nicht. Habe nochmal drüber geschaut und ein wenig aufgeräumt - ich denke nun bin ich zufrieden :)
Dann kann ich mich so langsam an den Rest wagen, der sicherlich auch noch einige Hürden für mich bereit hält.

Vielen Dank bis hierhin!
 

Anhänge

  • Crow Foot.jpg
    Crow Foot.jpg
    119,9 KB · Aufrufe: 3
Du steigerst Dich, 2 Punkte noch
1 Umlaute usw. würde ich mir in solchen Namen wirklich verkneifen. Wir leben zwar im 3. Jahrtausend und Unicode wurde schon im letzten erfunden, aber .. tu Dir einen Gefallen, ASCII ANSI.
Vielleicht freut sich auch jemand darüber, dass Du in den Objektnamen genderst, aber es sieht eh niemand, außer Du hängst Dir das Modell übers Bett.
2 Mitarbeiter1 , Mitarbeiter2
Wenn Du anfängst, Tabellen oder Spalten zu nummerieren, ist es zu 97 % Schrott. Irgendwann ist Dir vermutlich klar, wann du das machen must, solltest, kannst, aber hier nicht.
Alle Mitarbeiter in eine Tabelle.
Zwei kleine Hilfestellungen dazu:
- Wie fertigst Du beim jetztigen Modell eine Liste aller Mitarbeiter an?
- Was geschieht, wenn 3 Mitarbeiter eingetragen werden müss(t)en und das wirklich umgesetzt werden soll?
 
Danke noch für die Hinweise, sind in meiner neuesten Version auch bereits korrigert :)
Die Umlaute habe ich aus Gewohnheit geschrieben. Habe es mir mal angewöhnt, nun ist es schwer sich das in diesem Zusammenhang wieder abzugewöhnen. Habe es aber auch beim Übertragen in meine lokale DB gemerkt, da ist der Name ohne Umlaute.

Mitarbeiter1 und Mitarbeiter2 habe ich lediglich als Hilfestellung für mich gemacht, da das Programm mit dem ich das gemacht habe die Verbindungen immer so seltsam gelegt hat bei den beiden Beziehungen zwischen Mitarbeiter und Kindertagesstätte. So sah es lediglich aufgeräumter aus (ist noch ein Überbleibsel aus meiner kurzen Erfahrung mit Access, dort hat Access das nämlich so gemacht bei 2 Beziehungen zwischen den gleichen Tabellen).

Nun werde ich erstmal die Tabellen ein wenig mit Inhalt füllen und herum probieren - ich bin mir sicher meine nächste Frage wird nicht lange warten ;) Vielen Dank bis hierhin auf jeden Fall!
 
Da kommt auch bereits meine erste Frage auf - zugegebenermaßen hat das schon lange nichts mehr mit dem Topic zu tun, ich hoffe das ist in Ordnung..

Ich lasse mir aus der Tabelle Kind das Alter mit der folgenen Abfrage ausgeben
Code: 
SELECT name, vorname, geburtsdatum,
CASE WHEN DATEADD(YEAR, DATEDIFF(YEAR, geburtsdatum, GETDATE()), geburtsdatum) > GETDATE()
THEN DATEDIFF(YEAR, geburtsdatum, GETDATE()) - 1
ELSE DATEDIFF(YEAR, geburtsdatum, GETDATE()) END AS 'Alter'

Wie kann ich nun die Spalte 'Alter' weiter nutzen? z.B. in einer Where Alter > 3 Abfrage?
 
Du kannst SQL verschachteln, also Klammern drum, Alias dran und dann wie eine Tabelle handhaben.
Die "Luxusvariante" davon hatte ich schon zuvor erwähnt, nennt sich View.
"Create View NeuerName as Select ... mein komplizierte Abfrage"
Das machst Du in der DB und kannst es "überall" abfragen.
 
CTE wäre auch ein Weg:

Code: 
edb=# select 2 as zahl, 5*zahl as foo from dual;
FEHLER:  Spalte »zahl« existiert nicht
LINE 1: select 2 as zahl, 5*zahl as foo from dual;
                            ^
edb=*# with bla as (select 2 as zahl) select 5*zahl as foo from bla;
 foo
-----
  10
(1 row)

edb=*#
 
kolom schrieb:
nun kommst du noch mit neuen Sachen daher
Zum Vergrößern anklicken....
Eine CTE eignet sich ähnlich wie die simple Schachtelung vorwiegend für den Einsatz innerhalb eines Views bei Mehrfachverwendung des CTE Teils (ein Mengenanteil bzw. Teilergebnis wird mehrfach oder gegen sich selbst gejoint). Es ist moderner als die uralte Verschachtelung und leistungsfähiger.
Views liefern angereicherte Daten global im Schema / in der DB, je nach Berechtigung.
 
Werbung:
Ja, so langsam kann ich mich da nach und nach reinfuchsen und es funktioniert so wie ich mir das vorgestellt hatte 😊 Vielen Dank!
Die Abfrage nach dem Alter mache ich einfach von der SELECT Abfrage in die WHERE Abfrage, dann macht es was es soll - so langsam verstehe ich das Schema :) CTE werde ich mir dann in einem ruhigen Moment am Wochenende genauer anschauen - vielen Dank für den Hinweis noch!

2 Abfragen bereiten mir noch ein bisschen ein Fragezeichen, dann werde ich mich erstmal zurückziehen und herumprobieren 🙄

1. Abfrage:
Ich möchte die Kinder je nach Alter in unterschiedliche Gruppen einteilen, die sollen bei Erreichen des Alters auch entsprechend die Gruppe wechseln.
Gruppe 1: Bis 3 Jahre
Gruppe 2: 3 Jahre bis zum 31.07. nach dem 6. Geburtstag

Gruppe 1 werde ich mit der DATEADD Funktion lösen können.
Gruppe 2 Eintritt wird ebenfalls mit der DATEADD Funktion zu lösen sein, allerdings bin ich bei dem Austritt noch überfragt wie ich das unterbekomme. DATEADD bis Alter 6, aber dann die Ergänzung, der danachfolgende 31.07. - ist das möglich?

2. Abfrage:
Die Darstellung der Kosten wollte ich eine Abfrage reinpacken. Die Kosten hängen von Betreuungsumfang und der Gruppe ab. Meine Vorstellung war (grob):
Wenn Umang 0,5 und Gruppe 1, dann ist es Betrag XXX€
Wenn Umfang 0,5 und Gruppe 2, Betrag YYY€
Wenn Umfang 1 und Gruppe 1, Betrag ZZZ€

usw.

Wäre so etwas umzusetzen? Der Punkt fehlt in meinem ER Diagramm bislang komplett, da ich irgendwie dachte, dass ich das in eine Abfrage unterkriege. Aber nun wo ich versuche das umzusetzen, weiss ich nicht so ganz wie.. Kann ich das in eine Abfrage packen mit den Kosten, oder sollte es womöglich als Attribut zu "Betreuung" ?
 
Zuletzt bearbeitet:
Zurück
Oben