Hi, die nicht funktionalen Anforderungen sind jene, die sich nicht auf die Fachlichkeit des zu bauenden Systems beziehen (das wären alles rund um die Prozesse Flugbuchungen, Flugzeugdispo, Kundenservice etc). Insofern sind viele davon branchenunabhängig. Typische nichtfunktionale Anforderungen sind: Systemverfügbarkeit (7*24), Grad der Parallelisierung (auf wievielen Servern läuft die DB), geplante und ungeplante Ausfallzeiten (Systemwartung oder Crash, Konzepte hierzu), maximale Zahl parallel zugreifender Benutzer (Stresstest), Schutz vor Manipulation (Sicherheitskonzept) VG Thomas

Sorry, aber der Aufgabensteller (wer auch immer das ist) hat keine Ahnung von DB-Entwicklung. Ich habe noch nie einen Trigger gesehen, der Statusmeldungen per DBMS_OUTPUT weitergibt... Nicht in meinen ganzen 20 Jahren Berufserfahrung!

Stell Dir mal selber folgende Fragen: Wann soll der Trigger zünden? Was muß der Trigger ggf. noch zusätzlich ermitteln? Darf ein negativer Bestand herauskommen? Wenn dieser entstehen würde, was muß man tun, um die ggf. Transaktion rückabzuwickeln? Macht es u. U. Sinn Teile davon (z. B. Aktualisierung Bestand) in eine eigene Stored Procedure auszulagern?

kleiner Nachtrag:

Der Fall "receives" ist eine einfache 1:n-Beziehung und kann daher einfach als Feld RECEIVING_DEPT_ID in der Order-Tabelle angelegt werden, wenn die Bestellung tatsächlich ausgeliefert wurde.

VG Thomas

Hallo nach Berlin,ich denke mal es geht um die doppelte Beziehung zwischen Order und Department beim Fall "forwarded". Es gibt hier nur die Möglichkeit, diese Weiterleitung in eine eigene Tabelle auszulagern, die einen FK zur Order und zwei FKs zu den Abteilungen hat. Sinnvollerweise (eine Bestellung kann ja mehrfach weitergeleitet werden) würde ich noch einen Zeitstempel anfügen.Die fertige Tabelle sähe dann etwa so aus:

Tabelle ORDER_FORWARDING

Spalten

• ID (PK)
• ORDERNO (FK zur Order)
• FORWARDED_BY_DEPT (FK zum Department, Absenderbeziehung)
• FORWARDED_TO_DEPT (FK zum Department, Empfängerbeziehung)
• FORWARDED_TS (Zeitstempel)

Viele Grüße

Thomas

Funktional kann Oracle mit den entsprechden Optionen mehr.
Der große Unterschied ist einfach der Preis.

Hallo,

zuerst die gute Nachricht: Ja, Dein Problem ist grundsätzlich machbar. Jetzt die schlechte: Einfach wird das nicht. Es heißt nämlich, daß die SQL-Abfrage, die hinter einem Bericht liegt veränderlich ist. In diesem Fall spricht man von dynamischem SQL, also von einer Abfrage, die erst zur Laufzeit "gebastelt" wird. Für dieses Basteln mußt Du dann eine VBA-Prozedur erstellen, die den Wert der Kontrollkästchen ermittelt , diesen in SQL umsetzt und an die Abfrage unter dem Bericht zurückgibt.

VG Thomas

Gewöhnliche Briefsendungen haben zwar eine Regellaufzeit, aber keine Laufzeitgarantie.

Die Post ersetzt (wenn überhaupt) nur den Portowert aus Kulanz, aber nicht den Wert des Inhalts.

Der Fehler liegt aber auch zu einem Teil beim Versender, der trotz Terminbindung der Karte keinen Expressbrief (dieser hat eine Laufzeitgarantie) gewählt hat.

Einschreiben hilft nix. Wenn auch nur der leere Umschlag ankommt, gibts keinen Cent. Außerdem hast Du keine Laufzeitgarantie.

Tip: Expressbrief Laufzeitgarantie und der Inhalt ist mitversichert, leider aber teuer

Warensendungen haben eine Regellaufzeit von 4 Tagen, da diese nur tagsüber sortiert werden. Dazu kommt dann noch der Sonntag, an de nicht gearbeitet wird.

Wenn die Sendund aus Versehen mal fehlgeleitet sein sollte, dauerts doppelt so lange

Deutsche Post AG Personalabteilung Am Briefzentrum Langwasser

einfach mal vorbeigehen Die sind auch zuständig für den Paketbereich in Feucht

Hallo Daniel,

geht viel einfacher:

select p.name, count(a.*) as anzahl_abgeordnete from abgeordneter a inner join partei p on a.partei=p.id group by p.name;

select * from partei p inner join (select a.partei, count(a.) as anzahl from abgeordneter a group by a.partei having count(a.)>0) sub on sub.partei=p.id;

Gruß Thomas

Hallo,

zu c) Check Constraint auf Tabelle Studentin mit MaNr>0

zu h) select stud.Name, v.Bezeichnung as Vorlesungstitel from Studentin stud inner join schreibt schr on stud.MaNr = schr.MaNr inner join Klausur kl on schr.KNr = kl.KNr inner join Vorlesung V on kl.FNr = v.FNr order by stud.Name

select count(schr.MaNr) as AnzahlStudis, v.Bezeichnung as Vorlesungstitel from schreibt schr inner join Klausur kl on schr.KNr = kl.KNr inner join Vorlesung V on kl.FNr = v.FNr order by count(schr.MaNr)

Viele Grüße Thomas

Kaskadierendes Löschen bedeutet folgendes: Wenn zwei Tabellen über einen Foreign Key Constraint miteinander verbunden sind, der kaskadierendes Löschen unterstützt, werden beim Löschen des Masterdatensatzes in Tabelle 1 auch alle von ihm abhängigen Sätze in Tabelle 2 gelöscht.

Cascaded update funktioniert ähnlich, wenn sich der Fremdschlüsselwert selbst ändert. Dann werden die referenzierten Sätze in der zweiten Tabelle mit geändert.

Während cascaded delete zur Datenbereinigung sinnvoll sein kann, ist aus meiner Sicht cascaded update immer Anzeichen für einen Modellierungsfehler. Primär- und Fremdschlüssel sollten technische Schlüssel sein, wo es auf den Wert selbst nicht ankommt.

Viele Grüße Thomas

Hallo,

das geht nur mit einer Stored Procedure innerhalb der DB. Und wie die aussieht, hängt vom DBMS ab, das Du verwendest. Stand ja leider nicht dabei.

Gruß Thomas

Hallo Maus,

das ist ganz einfach. Wenn Du ein Objekt aus der Wirklichkeit in einer Datenbank beschreiben willst, mußt Du eine Struktur festlegen. Sowas nennt man dann Entität. Du wählst also aus, welche Merkmale dieses Objekt haben soll, z. B. hast Du die Entität Spielzeug, die hat die Merkmale Name, Typ, Farbe und in der Regel eine fortlaufende Nummer, die immer eindeutig ist.

Es kann also einen Datensatz geben mit den Werten Name=Fußball, Typ=Ball, Farbe=schwarzweiß, Nr=1; daneben noch einen Datensatz mit Name="Mensch ärgere Dich nicht", Typ=Brettspiel, Farbe=bunt, Nr=2 Die Nummer ist dafür gut, falls mal zwei Fußbälle da sein sollten, die man immer eindeutig unterscheiden will.

Denken wir mal weiter und haben noch eine Entität Kind mit den Merkmalen Name, Geburtsdatum (Alter wäre blöd, das ändert sich ja immer), Geschlecht und auch wieder einer eigenen fortlaufenden Nummer. Also haben wir verkürzt geschrieben einen Max/01.05.2007/m/1 und einen Moritz/20.07.2003/m/2.

Beide Entitäten kann man jetzt miteinander in Beziehung setzen (also in Relation) und so jedem Spielzeug seinen Besitzer zuordnen. Dazu gibt man einfach dem Spielzeug noch ein zusätzliches Merkmal mit der eindeutigen Nummer des Kindes, also Name=Fußball, Typ=Ball, Farbe=schwarzweiß, Nr=1, Besitzer=2 Und so wissen wir, daß der Fußball mit der Nr. 1 dem Moritz gehört.

So baut man also Modelle für komplexe Datenstrukturen, die immer ausreichend kommentiert sein müssen und möglichst selbsterklärende Bezeichnungen verwenden. Beim Entwurf eines solchen Modells spricht man auf englisch von Entity-Relationship-Modelling, also der Beschreibung von Entitäten und ihren Beziehungen zueinander.

VG Thomas

Hallo Lumpy,

ist ganz einfach. Daten werden in einer oder mehreren Tabellen gehalten, also dauerhaft gespeichert. Da sie normalerweise dort niemand direkt einträgt, benutzen Menschen Formulare, also Eingabemasken. Wenn man Daten aus einer DB auslesen will, dann werden meist Daten aus mehreren Tabellen miteinander kombiniert. Das geschieht dann in einer Abfrage. Und damit die so abgefragten Daten auch noch optisch ansprechend rübergebracht werden, packt man die Abfrageergebnisse in einen Bericht, der dann z. B. irgendwelche Diagramme enthalten kann.

VG Thomas

Herstellerabhängig: Falls Du mit MySql arbeiten willst, dann empfehle ich Dir den Toad for MySQL; falls Du Dich an eine Oracle Express Edition rantraust, dann den Oracle SQL Developer. Ist alles kostenlos.

Gruß Thomas

Hallo Peter,

ja, es gibt obere Grenzen bei der Zahl der Felder in einer Datenbanktabelle, allerdings sind diese herstellerabhängig. Bei Access sind es 255, bei Oracle 1000. Es hängt wie vermutet davon ab, wieviele Bit der Hersteller der DB intern zur Adressierung der Felder spendiert. Wer sich allerdings der oberen Grenze seines Systems nähert, der sollte sich fragen lassen, ob aus Sicht der Datenmodellierung alles ok ist, oder ob es nicht sinnvoller ist, die Inhalte auf mehrere Tabellen zu verteilen. Breite Datensätze verursachen nämlich viel Disk-I/O, auch wenn man nicht in jedem Fall alle Felder braucht.

Viele Grüße Thomas

Hallo Joseppe,

was Du brauchst ist kein Join sondern eine Mengendifferenz, etwa so:

select * from Tabelle1 minus select * from Tabelle2

Also: Gib alle Artikel aus der größeren Tabelle aus, streiche davon aber diejenigen, die in der kleineren Tabelle vorhanden sind. Es bleiben nur die geforderten Einträge übrig.

Das kann Access allerdings nicht grafisch darstellen, nur im SQL-Editor.

Schöne Grüße Thomas

Hallo,

ich würde die Struktur anders aufsetzen, nämlich so: eine Tabelle "Person" mit den notwendigen Attributen und einer technischen ID als Primärschlüssel (von mir aus als BIGINT), eine zweite Tabelle Beziehung, in der mit zwei Feldern auf je einen Datensatz der Tabelle Person referenziert wird. Diese Tabelle beschreibt also die Relation "ist Freund von". Damit können auch einseitige Beziehungen gut beschrieben werden. Die Businesslogik zum anlegen von Datensätzen klammerst Du am besten in Stored Procedures, sodaß im Frontend so wenig Code wie möglich enthalten ist.

Gruß Thomas