Posts by Chris

    Quote from Almlieschen

    weil in #2 nur von einer "formsache" bezüglich des wechsels geredet wurde....


    wie förmlich ist das??...muss ich nur einfach zur studienabteilung hin, denen das sagen, und das war es? (beim abmelden von einem studium auf der HU hat das zumindest gereicht....)
    oder muss ich alle meine prüfungen beim freund (in einem warte-marathon) um-anrechnen lassen?


    die prüfungen musst du nicht anrechnen lassen. wenn du dann irgendwann mal das fertige bakk.studium einreichst, ist ihnen egal, von welchem informatik-bakk.studium die kennzahl ist...

    Quote from dornröschen

    ja wenn man die id weiss ist das kein problem und die könnte man aus dem traffic in dem fall rauslesen.. deshalb denk ich mal das das so nicht gerade klug ist... (es handelt sich um eine etwas kritische applikation... deshalb der aufwand)


    naja.. also du solltest mal natürlich über deine anwendung verhindern, dass man die session-ids von anderen eingeloggten benutzern zu gesicht bekommt (bzw. eine möglichkeit hat, an die ranzukommen), stichwort session hijacking...


    wenn es jemand schafft, die session id aus dem traffic rauszulesen, ist ja eigentlich eh schon alles egal, weil dann kann er genauso alle anderen daten aus dem traffic rauslesen.. und ob die sid dann über cookie/get/post läuft ist erst recht blunzn.
    wenn du davon ausgehst, dass ein angreifer die kommunikation mit dem webserver abhören kann, und die anwendung wirklich kritisch ist, dann wirst du um https wohl nicht herumkommen...

    Quote from b_UT

    Problematisch kanns mit der session-id und IP-Adresse nur werden, wenn man riesen - Netze hinter Firewalls miteinbezieht. Etwa wenn ein Großteil der User in dem selben Konzern sitzen. Diese können dann untereinander wieder die session-id tauschen.


    nicht nur dann.. ich würd mal sagen, ein viel größeres problem sind firmennetze, die einen öffentlichen ip-pool haben, und wos durchaus vorkommt, dass die einzelnen requests mit verschiedenen ip-adressen in das internet hinausgehen..

    Musti: in deiner lösung ist noch ein fehler; U.N. Known hat nur in einem Film mitgespielt, deine Lösung sagt aber 3. Du musst berücksichtigen, dass eine Person auch mehrere Rollen in einem Film spielen kann...

    ich würd nicht nach namen, sondern nach svnr gruppieren.. laut angabe muss der name nicht eindeutig sein

    Quote from Incazzato


    Bsp: in Verlagsgruppe habe ich
    Buch (PubID, Titel, ISSN, Untertitel, Genre.GenreID, Person.PersID, Verlag.Name) (vergesst die Formatierungen...)
    Hier habe ich Herausgeber durch Person ersetzt, da Herausgeber eh keine neuen Attribute haben. Was spricht dagegen?


    naja, ein Grund würde mir schon einfallen, der da dagegen spricht:
    wenn die PersID ein Fremdschlüssel auf die Herausgeber-Relation ist, stellt die Datenbank sicher, dass auch immer nur gültige PersonenIDs von Herausgebern da eingetragen werden. Bei deiner Variante könnten da auch PersIDs von Personen stehen, die keine Herausgeber sind.


    nullwerte würd ich in der praxis btw auch nicht unbedingt vermeiden, wenn ich dafür eine neue tabelle einführen muss. dann muss man nämlich auch immer um eine tabelle mehr joinen, was doch ein ziemlich hoher preis ist...


    lg, christoph

    Quote from Incazzato

    stimmt schon, ist sie aber nicht ;-)


    naja, aus der Angabe: "Ein Raum hat sowohl Fenseter als auch Türen. Beide haben innerhalb des Raumes eine eindeutige Nummer"
    sieht für mich schon ziemlich eindeutig nach einer schwachen entity aus.. oder hab ich da dein posting falsch verstanden?


    naja.. wenn jetzt noch die Türe weak ist und von raum abhängt, hast du ein Problem :devil:
    wenn sie nämlich mit zwei räumen in verbindung steht, ist nicht ersichtlich zu welchem raum die türnummer gehört, bzw innerhalb welchen raumes sie eindeutig sein soll

    Quote from BlessedOne

    hm also wenn ich z.b. eine firma hab, die spezielle fahrzeuge herstellt und in den fahrzeugen sind sicherheitsscheiben verbaut. und sag ma mal die sicherheitsscheiben bekommen alle einen auf der welt eindeutigen key...
    dann hab ich demnach grundsätzlich eine "normale" entity da ja ein eindeutiger key vorhanden ist.


    ja, genau

    Quote from BlessedOne


    Wenn ich aber nur die fenster die meine firma verbaut hat verwalten will, dann darf ich die fenster nicht als we modellieren da sie einen unique key haben??


    naja.. ja
    die fenster haben ja noch immer einen unique key, auch wenn du nur die von einer firma verwaltest. aber ich fürcht, ich seh nicht ganz, worauf du hinaus willst.. warum solllten die fenster jetzt weak sein, und nicht, wenn du mehrere firmen in der datenbank behältst?

    Quote from BlessedOne


    und natürlich hat der tutor recht ;) besser so? :)


    bei der abgabe hat er natürlich recht. In diesem Fall hat er zufällig einfach so recht :))

    zum Bibliotheksbeispiel: Die Exemplarnummer ist _nicht_ eindeutig, darum ist das Exemplar weak. Die Dopelstriche hätte man einzeichnen können, da aber das Exemplar nur eine Beziehung mit der Vielfachheit [1,1] eingeht, ists in diesem fall eh eindeutig (nämlich abhängig von buch)


    und zu weak entities: es stimmt zwar, dass eine weak entity immer existenzabhängig von einer anderen entity ist; das impliziert aber nicht, dass eine existenzabhängige entity auch als weak entity modelliert werden muss/darf.
    Weak entities verwendet man genau dann, wenn die entity selbst keinen eindeutigen schlüssel besitzt, deshalb muss man Attribute von einer anderen entity zum schlüssel dazunehmen (und dadurch wird die weak entity natürlich auch existenzabhängig von der anderen entity)... der tutor hat schon recht gehabt :)


    lg, chris

    Quote from enemy2k


    Dann wird doch beim Haus der Primäre Schlüssel vom anderen Entity reingezogen oder?
    macht man dies nur bei (1,1)


    naja.. bei (0,n) oder (1,n) wäre es sinnlos und bei bei (0,1) hätte man nullwerte drinnen (böse :devil: ). die antwort wäre also ja, wenn man nullwerte auf jeden fall vermeiden möchte

    Quote from BlessedOne

    Hoffmann:
    Für ein Entity das an einer relationship teilnimmt, kann es auch nur 1 Min Max Paar geben.
    Sprich in einer n-stelligen beziehung gibt es genau n min,max Paare..


    seh ich auch so. n-stellige bezieheungen (mit n > 2) haben es dabei übrigens ansich, dass manche beziehungen unter den tisch fallen, da man nur n [min,max] paare hat..


    Quote from enemy2k


    wie könnte das ausschauen. leider bin ich da sehr verwirrt...


    naja.. eine relation mit den fremdschlüsseln von A und B
    Preisfrage: wie musst du die fremdschlüssel setzen, damit man die beziehung speichern kann, aber doch möglichst restriktiv ist?

    hint: schau dir mal die vielfachheiten zu "-steht in" und zu "-ist exemplar von" an; aus denen sollte das eindeutig hervorgehen


    mfg, chris

    Quote from Hoffmann

    Zum Vermeiden von Nullwerten darf man ja bestimmte Beziehungen nicht in die Entity reinziehen.


    Gilt dies bei einer 1:N Beziehung nur für den 1 Teil ([0,1]) oder auch für den N Teil ([0,n])?


    Ich glaub nämlich fast, folgendes darf man reinziehen: A ----[1,1]---<>---[0,n]----B


    Das darf man sicherlich reinziehen



    Quote from Hoffmann

    Folgendes nicht: A ----[0,1]---<>---[1,n]----B


    dafür würd ich auch eine zusätzliche relation vorschlagen