Hagen: Normalisierung

Hallo,

wir haben in der Uni eine relativ komplexe Fallstudie bekommen die mit einem erm modelliert, in ein relationenmodell überführt und normalisiert werden soll. Folgendes Problem tritt bei mir ziemlich oft auf: Ich habe einen Relationshiptyp(Raute), dieser erbt ja die primärschlüssel der Entitäten, nun sind aber nicht alle Attribute des Relationshiptyp von allen geerbten Primärschlüsseln abhängig(aber mindestens von einem). Ich versuch mal ein konkretes Beispiel(geht um einen Segelflugverein):
ich habe einen Relationshiptyp "fliegt" dieser erbt die Primaärschlüssel der Entitäten(in meinem Fall FlugStrecken_ID; Flugzeug_ID; Flugart_ID, Person_ID(Pilot) ) "fliegt" hat ein Attribut Strecke(in km), nun ist ja dieses Attribut lediglich von der Strecken_ID(ID repräsentiert jeweils eine Route)  abhängig-dies widerspricht der 2NF. Aber es ist nicht sinnvoll die Strecke in  die Entität Flugstrecke aufzunehmen, z.Bsp wenn Start und Landeort gleich sind gäbe es da Probleme, da ja die Strecke nicht konstant wäre. Vielleicht hat ja jemand von euch eine Idee zu dem Thema(ich hoffe ich habs einigermaßen brauchbar erklärt).

MFG Hagen

  1. Yerf!

    ich habe einen Relationshiptyp "fliegt" dieser erbt die Primaärschlüssel der Entitäten(in meinem Fall FlugStrecken_ID; Flugzeug_ID; Flugart_ID, Person_ID(Pilot) ) "fliegt" hat ein Attribut Strecke(in km), nun ist ja dieses Attribut lediglich von der Strecken_ID(ID repräsentiert jeweils eine Route)  abhängig-dies widerspricht der 2NF. Aber es ist nicht sinnvoll die Strecke in  die Entität Flugstrecke aufzunehmen, z.Bsp wenn Start und Landeort gleich sind gäbe es da Probleme, da ja die Strecke nicht konstant wäre. Vielleicht hat ja jemand von euch eine Idee zu dem Thema(ich hoffe ich habs einigermaßen brauchbar erklärt).

    Eine Route definiert also Start und Zielpunkt, aber nicht den exakten Weg und damit die Länge? Damit ist doch dann die Strecke(in km) aus dem Relationshiptyp "fliegt" nicht alleine von der Strecken_ID abhängig, oder versteh ich da etwas falsch?

    Gruß,

    Harlequin

    --
    <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
    1. Hallo Harlequin danke für deine Antwort.

      Eine Route definiert also Start und Zielpunkt, aber nicht den exakten Weg und damit die Länge? Damit ist doch dann die Strecke(in km) aus dem Relationshiptyp "fliegt" nicht alleine von der Strecken_ID abhängig, oder versteh ich da etwas falsch?

      Nein es gibt auch Flüge bei denen Start und Landeort gleich sind, wo die Piloten quasi "just for fun" durch die Gegend fliegen. Und dann habe ich das Problem, dass Start und landepunkt zwar gleich sind aber die Strecke immer unterschiedlich.

      MFG Hagen

  2. yo,

    das attribut strecke (km) hat nichts im Relationshiptyp "fliegt" zu suchen. eine Flugstrecke hat eben eine strecke unabhängig davon, ob man fliegt oder nicht. packst du es in den Relationshiptyp "fliegt" würde es zu anomalien kommen, zum beispiel wenn alle Flüge gelöscht werden würden. dann wüsstest du nämlich nicht mehr, wie weit eine Flugstrecke ist. also das attribut gehört schon wie von dir angesprochen in die entität (relation) Flugstrecke.

    Ilja

    1. Danke für deine Antwort.

      Ok das war wie gesagt auch meine Idee aber folgendes. Jemand macht einen Rundflug von X und landet wieder in X. Da ist die km Anzahl nicht fix, sie kann sich ändern und damit wäre soetwas möglich:
      ID -Startort-Landeort-km
      0___-X______-__X_____-100km
      1___-X______-__X_____-200km
      2___-X______-__X_____-111km

      und das widersprich bereits der 1 NF

      VG Hagen

    2. yo,

      noch mal eine ergänzung, um es ein wenig auseinander zu halten. es gibt zwei verschiedene strecken und ich glaube, du meinst eine andere, als ich erst in den sinn hatte.

      die erste strecke kann zum beispiel sein, die flugentfernung von berlin nach hamburg. diese ist unabhängig von den flügen, wie bereits von mir geschrieben.

      die andere strecke ist die, welche das flugzeug tatsächlich fliegt, kann ja einen umweg fliegen, ein zwischenstop oder eben ein rundflug, whatever. diese zweite strecke gehört tatsächlich in den Relationshiptyp "fliegt" rein. Und da sie unabhängig von der ersten strecke ist, gehört sie auch nicht in die entität Flugstrecke.

      noch ein hinweis zu deinem pk im Relationshiptyp "fliegt". nicht jeder fremdschlüssel muss auch bestandteil des pk sein. schließlich kann in aller regel ein pilot nicht gleichzeitig zwei flüge fliegen, jedenfalls heute noch nicht. die ID des piloten gehört also meiner meinung nach nicht zum pk. was aber fehlt ist vor allem ein attribut im pk, dass du noch nicht angegeben hast, nämlich die zeit. es kann ja sein, dass das gleiche flugzeug mit den gleichen pilot exakt die gleiche strecke fliegt. auch dann musst du die datensätze unterscheiden können.

      Ilja

      1. Hallo nochmal danke für deine ideen,

        die andere strecke ist die, welche das flugzeug tatsächlich fliegt, kann ja einen umweg fliegen, ein zwischenstop oder eben ein rundflug, whatever. diese zweite strecke gehört tatsächlich in den Relationshiptyp "fliegt" rein. Und da sie unabhängig von der ersten strecke ist, gehört sie auch nicht in die entität Flugstrecke.

        "fliegt" habe ich so modelliert(Relationenmodell):

        fliegt(Flugzeug_ID(das Flugzeug), FlugArt_ID(Schulungsflug, Alleinflug o.Ä), Strecken_ID, Person_ID(Pilot), Startdatum, Beiflieger(auch eine Person), Startzeit, Landezeit, Strecke)

        Somit bleibt aber auch bei der real geflogenen Strecke, "Strecke" ja lediglich von der "Strecken_Id" abhängig und keinesfalls vom Flugzeug oder Piloten...!?

        Vg Hagen

        1. yo,

          fliegt(Flugzeug_ID(das Flugzeug), FlugArt_ID(Schulungsflug, Alleinflug o.Ä), Strecken_ID, Person_ID(Pilot), Startdatum, Beiflieger(auch eine Person), Startzeit, Landezeit, Strecke)

          meiner meinung nach würde ich den pk aus den spalten Flugzeug_ID und Startdatum bilden, diese beiden reichen aus, um jeden datensatz eindeutig zu identifizieren. (Flugzeug kann ja nicht zweimal zur gleichen zeit starten). und von diesen beiden attributen ist auch dann die strecke in km vollständig abhängig.

          was da die streckenID soll ist mir noch nicht ganz klar, weil die tabelle fliegt ja eigentlich die strecke schon, das ist quasi doppelt gemoppelt.

          nun muss ich aber gleich von hamburg nach berlin "fliegen", besser gesagt mit der bahn fahren. Muttern hat geburstag.....

          Ilja

          1. Hallo,

            danke für eure Antworten, also ist es ja dann doch richtig wie ichs mir gedacht habe und die sache also auslegungssache:-).

            Strecke ist Strecke in km, Strecken ID ist die ID der Route(Sprich die ID von Start und Landepunkt).

            VG und danke für eure Hilfe.

            MFG Hagen
            "nun muss ich aber gleich von hamburg nach berlin "fliegen", besser gesagt mit der bahn fahren. Muttern hat geburstag....."

            PS: na dann guten appetit(gibt doch bestimmmt lecker kuchen:-))

            1. yo,

              danke für eure Antworten, also ist es ja dann doch richtig wie ichs mir gedacht habe und die sache also auslegungssache:-).

              das stimmt so nicht ganz, es gibt keine "allgemein gültige formel für alle", aber deine spezielle umgebung gibt dir die regeln dazu vor, nach der du dich richten musst. es ist also weniger ausgelgungsache, sondern unterschiedliche umgebungen machen unterschiedliche vorgaben.

              Ilja

        2. Yerf!

          Somit bleibt aber auch bei der real geflogenen Strecke, "Strecke" ja lediglich von der "Strecken_Id" abhängig und keinesfalls vom Flugzeug oder Piloten...!?

          Naja, in gewisser weise schon: der Pilot hat entschieden anders zu Fliegen und das Flugzeug hatte genug Sprit... ;-)

          Deutlicher wirds, wenn man der "fliegt"-Relation einen künstlichen PK gibt: die tatsächlich geflogene Strecke ist einmalig und nur von diesem konkreten Flug abhängig.

          Gruß,

          Harlequin

          --
          <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->