# ER Diagramm so richtig?



## n3oth3on3 (10. Mai 2010)

Guten Tag,
Ich muss für mein Fach Datenbank eine komplette Datenbank in den nächsten Wochen erstellen. Als erstes sollten wir ein "ER Diagramm" erstellen, was ich woll soweit habe... Nun würde ich aber gerne wissen ob es richtig ist 

http://img232.imageshack.us/img232/158/hon.png
oder im Dateianhang...

Da ich nicht besonders gut in Datenbank stehe, kann hier  vielleicht einer mal kurz drübergucken. Will nur Tipps, und so, also keine Lösungen 

HON = Heroes of Newerth, ist ein Spiel und ich habe mir das ganze so gedacht :

Es gibt einen Benutzer ( User ), und der kann ein Spiel spielen. Das Spiel hat zwei Seiten ( gut und böse ), und jede Seite hat 5 Helden. Nun haben die Helden jeweils ein Hauptarribute ( Int,Agi,...), sie haben jeweils einen attacktype ( nahkampf oder fernkampf ) und sie haben jeweils einen spell...

Mit denn Spells wußte ich nicht ganz wie ich das machen soll, jeder Spell gehört zu einem Hero, und jeder Hero hat nur 4 Spells. Hoffe das geht so 

Zu denn Items, es gibt Kauforte ( Shops ) wo man halt Items kaufen kann.


----------



## vfl_freak (10. Mai 2010)

Moin,

so auf den ersten Blick sieht es sehr hübsch aus 

Aber ohne die detaillierte Aufgabenstellung zu kennen, wird Dir keiner sagen können, ob es denn auch richtig modelliert ist  ;-]

Gruß
Klaus


----------



## n3oth3on3 (10. Mai 2010)

Es gibt keine Aufgabenstellung 

Jeder durfte sich einen Bereich auswählen wie z.b. die Börse, Schulnetzwerk, Spiele, Banken, Autos usw...

Dazu sollten wir dann halt ein ER-Diagramm machen, die Datenbank halt und später noch Abfragen via mysql...

Aber damit ich anfangen kann brauche ich halt ein richtiges ER-Diagramm.

Zu dem Diagramm und die Erklärung des Spiels : Das meiste steht schon oben, HON ist eine Dota Kopie was vielleicht mehr leute kennen, und ich wollte dazu halt eine Datenbank machen...

*Also nochmal etwas genauer erklärt :*

In dem Spiel, hat jeder Spieler einen Account. Wenn man dann einem spiel joint, gibt es zwei Seiten ( gut und böse ) mit jeweils 5 Helden, also können max. 10 Spieler in einem Spiel mitspielen, aber es gibt auch 2vs2 usw.

Nachdem man nun in dem Spiel ist, kann man sich einen Helden aussuchen, die sind in drei Kategorien unterteilt ( intelligenz ( Magier...), Fernkampf ( Bogenschütze), Nahkampf ( Krieger ) und dann gibt es noch Nah und Fernkampf...), wenn man sich dann einen Hero ausgewählt hat, fängt das Spiel an.

Im Spiel kann man dann Items kaufen, die es in bestimmten Shops gibt.


----------



## Parantatatam (10. Mai 2010)

Wie ich meine, solltest du dich an dein ER-Diagramm noch einmal ransetzen:


es gibt nur vier Verhältnistypen: 1:1, n:m, 1:m und n:1. Du verwendest allerdings auch so etwas: 1:5, was es aber nicht gibt
bei 1:1-Verhältnissen brauchst du keine Zwischentabelle, die die Verhältnisse beinhaltet. Generell werden diese Tabellen nicht in einem ER-Diagramm eingezeichnet, da diese erst bei der Umsetzung erstellt werden, theoretisch aber nicht existieren.


----------



## n3oth3on3 (10. Mai 2010)

Ohhh, dann hab ich das leicht "verpennt", werde das heute abend wenn ich wieder zurück bin nochmal überarbeiten...

das heißt z.b. bei attribute und held bräuchte ich die Zwischentabellen nicht? Also immer nur bei 1:n und n:m ?

und wie mach ich das dann, wenn man nur max. 5 Helden "auswählen" kann? Gar nicht in das Diagramm also 1:n dann?

mfg


----------



## Parantatatam (10. Mai 2010)

Genau. Wie du richtig erkannt hast, sind die Attribute zwischen den Tabellen "attribute" und "held" falsch. Aber auch bei 1:m, n:1 und n:m gehören diese Zwischentabellen nicht hin, da sie, wie schon gesagt, Teil der praktischen Umsetzung und nicht der Theorie - was das ER-Diagramm nun mal ist - sind. Und auch die Beschränkung, dass man nur maximal fünf Helden auswählen kann, ist Teil der praktischen Umsetzung und hat in dem Diagramm keineswegs etwas zu suchen.


----------



## n3oth3on3 (10. Mai 2010)

So habs nun mal leicht verbessert, hoffe es ist nun "ganz" richtig 

Muss in Datenbank noch bissl was an meiner Note machen 

So nun meine Erklärung dazu : 

Ein Benutzer spielt ein Spiel.
Ein Spiel hat mehrere Rassen ( Gut und Böse ). (2)
Eine Rasste hat mehrere Helden. ( 5)
Ein Held hat einen attacktype.
Ein Held hat ein Hauptarrtibute.
Ein Held kann mehre Items kaufen, und mehrer Items haben einen Shop.
Ein Held hat mehrer Spells. (4)

Ist das nun dann so richtig? Die Zahlen in denn (z.b.2), sind die Zahlen die da eigentlich reinmüssten, da aber sowas nicht in ein ER Diagramm reinkommt hab ich das mal so hingeschrieben 

Achso, was mich gerade noch so Interessiert... Wofür steht das "m"? "n" ist doch unendlich oder? und 1:m z.b.?


----------



## Parantatatam (10. Mai 2010)

Ich konnte jetzt nichts mehr finden, von dem ich sagen würde, dass es falsch ist. Aber zu dem _*m*_: wie du schon richtig gesagt hast, ist *n* unendlich oder steht für eine beliebig große natürliche Zahl. Da aber ein _*n:n*_-Verhältnis bedeuten würde, dass auf beider Seite gleichviele Verknüpfungen existieren müssen, nimmt man gerne den Buchstaben, der im Alphabet nachfolgend kommt. Das ist in diesem Falle eben das _*m*_.


----------



## n3oth3on3 (10. Mai 2010)

Danke, für tolle Hilfe hier 

Wenn einer noch was findet, dann bitte sagen ;D Aber ein großes Danke schön an "einfach nur crack"


----------



## gorefest (11. Mai 2010)

einfach nur crack hat gesagt.:


> Wie ich meine, solltest du dich an dein ER-Diagramm noch einmal ransetzen:
> 
> 
> es gibt nur vier Verhältnistypen: 1:1, n:m, 1:m und n:1. Du verwendest allerdings auch so etwas: 1:5, was es aber nicht gibt
> bei 1:1-Verhältnissen brauchst du keine Zwischentabelle, die die Verhältnisse beinhaltet. Generell werden diese Tabellen nicht in einem ER-Diagramm eingezeichnet, da diese erst bei der Umsetzung erstellt werden, theoretisch aber nicht existieren.



[smartshit]
* 1:5 kannst Du sehr wohl modellieren, indem Du fünf foreign key Spalten  an Deine Entity klemmst ODER eine Relation mit einem passenden CHECK CONSTRAINT versiehst (was mysql afaik net kann)
* bei 1:1 Verhältnissen brauchst Du dann eine Zwischentabelle, wenn Du der Beziehung Attribute hinzufügst, die weder der einen noch der anderen Entity zughörig sind (Beispiel Person>-Aktueller Job-<Job. Hier würde beispielsweise das Eintrittsdatum weder der einen, noch der anderen Entity zugehörig sein)
[/smartshit]

Grüße
gore


----------



## Parantatatam (11. Mai 2010)

an *gorefest*: In den Punkten hast du zwar recht, was die praktische Umsetzung betrifft, allerdings ging es hier um die theoretische Darstellung in einem ER-Diagramm, welche - ich wiederhole mich, aber anscheinend verstehst du das noch nicht - solche Möglichkeiten nicht berücksichtigt!


----------



## gorefest (12. Mai 2010)

das ist aber eben falsch.

Du kannst in einem ER-Diagramm sehr wohl eine Kardinalität angeben. Das heisst beispielsweise, dass eine 1:5 Beziehung eben sehr wohl modelliert werden kann und auch in Datenbanken umgesetzt werden kann.

Grüße
gore


----------



## Parantatatam (12. Mai 2010)

Ich will mich jetzt in nichts verrennen, aber das wäre für mich neu, wenn man eine andere Kardinalität bei ER-Diagrammen verwenden könnte. Wenn du mir es nachweisen kannst, dass es irgendwo steht, dann lass ich mich gerne überzeugen, aber solange behaupte ich das Gegenteil.


----------



## gorefest (12. Mai 2010)

Zitat Wikipedia:



> Grundlage der Entity-Relationship-Modelle ist die Typisierung von Objekten und deren Beziehungen untereinander:
> 
> .....
> 
> Kardinalität: Die Kardinalität eines Beziehungstyps legt fest, an wie vielen Beziehungen eine Entität teilnehmen kann (zum Beispiel kann ein Angestellter mehrere Projekte leiten, während ein Projekt von genau einem Angestellten geleitet wird).



möglich sind hierbei

1:1
c:1 (=0..1 : 1)
n:1 (n=1,2,3,4,... )
1:* 

und natürtlich *:* bez. n:m

und wird im übrigen von jedem mir bisher bekannten ER-Modeling Tool unterstützt (namentlich ERWIN und PowerDesigner). Warum sollte eine Modellierungssprache auch auf etwas verzichten, was  relationale Datenbanken eh unterstützen?

Grüße
gore


----------



## Parantatatam (12. Mai 2010)

Das überzeugt mich leider keineswegs, da *n* und *m* letztendlich nur für eine beliebig große Ganzzahl steht, die größer eins ist, aber nicht genau definiert wird. Das ist Fakt. Und es handelt sich bei den ER-Diagrammen um *Diagramme* und *nicht* um eine *Modellierungssprache*, diesen Unterschied solltest du langsam erkennen.


----------



## gorefest (12. Mai 2010)

Stimmt, natürlich. Diagramme sind keine Modellierung. Bei einem ER-Diagramm spricht deswegen auch nicht solten von einem Datenmodell. 

Deswegen spricht man bei UML Diagrammen auch nicht von einer MODELLING LANGUAGE. Und ein ER-Diagramm wird nicht zufällig in ein relationales MODELL überführt? Ein Entity-Relationship-Diagramm ist eine logische Darstellungsform eines Datenmodells. 

Entschuldigung also, wenn ich diese Begriffe vermatscht habe. 

Und : Niemand hindert Dich, in ER-Diagrammen statt 1 und *  eben auch 1 und 5 zu schreiben. Bei 1: N ist N nur eine Ganzzahl und die Festlegung der Kardinalität ist keine Restriktion, die ER-Diagramme verbieten.

Schönen Tag noch,
gore


----------



## n3oth3on3 (18. Mai 2010)

Mein Lehrer meinte das wäre nicht ganz korrekt, hab das etwas neu gemacht sie Dateianhang...

Hab nun die Map und die Mods nochmal einzelnt gemacht, da die öfter vorkommen... und mein Lehrer meinte das ich sowas wie Geschwindichkeit, Schaden, Rüstung als Eigenschaft nehmen soll, und das dann auflisten kann... Findet ihr das Sinvoll ? Ansich sind das alles nur Zahlenwerte, aber sollen die dann so zusammengepackt  werden, oder wie bei denn Mods und Maps, extra aufzählen? weiß nur nicht ob sich die Zahlen wiederhollen werden...

Mfg
n3oth3on3


----------



## gorefest (18. Mai 2010)

Hi,

es ist immer sinnvoll, diese Objekte direkt an die Master-Entity zu hängen, wenn es möglich ist und nicht hinderlich wirkt.

Hintergrund :


```
Person 3 -> "Rüstung", 10
Person 3 -> "Geschwindigkeit", 3
...
```

ist zum einen für die Abfragen viel unhandlicher (zumal das korrekterweise als attributierende Beziehungsrelation zwischen person und Eigenschaft definiert werden müsste).

Zum anderen hast Du eine stärkere Typenbindung, da du 

```
Person 3,  Rüstung 10, Geschwindigkeit 3
```

direkt an die Tabelle Person hängen kannst und z.B. Werte erzwingen kannst (z.b. NOT NULL , >0 etc pp)
Das Bestehen einer Beziehung zwischen Eigenschaft und Person  kannst Du nicht so ohne weiteres Erzwingen, sondern ist immer mit programmatischen Eingriffen verbunden.


Grüße
gore


----------



## n3oth3on3 (18. Mai 2010)

wie stelle ich das dann im ER Diagramm dar ? Kann mir das gerade leider nicht so wirklich vorstellen 

Eine kleine Skizze in Paint ? Genau wie gorefest das schon beschrieben hat, brauch ich das, also muss ich auch so machen....


----------



## gorefest (18. Mai 2010)

hi,

genauso, wie du eigenschaftID und eigenschaftname dargestellt hast - als kreis mit dem namen eigenschaft angehangen an "held".

grüße
gore


----------



## i123 (20. Mai 2010)

Sorry, das ich erst wieder schreiben kann, danke nun hab ich es verstanden 

Kann man noch irgendwas so in der Art  "vereinfachen"? Suche schon ganze Zeit, nach Sachen die doppelt oder so vorkommen aber finde langsam nichts mehr...


----------



## i123 (20. Mai 2010)

So, denke das ER-Diagramm ist nun fertig, werde dann mit der Datenbank nun anfangen...

Kann die aber einer nochmal bitte überfliegen?


----------



## Parantatatam (23. Mai 2010)

Was mir beim kurzen Überfliegen auffiel: ändere mal "n:n" in "n:m" um, da "n:n" bedeuten würde, dass nur solche Kombinationen möglich sind: 2:2, 3:3, 4:4, 5:5, aber nicht solche: 2:3, 4:5, 5:2 et cetera.


----------



## japp (24. Mai 2010)

Wenn jedes Item eine eigene ID hat (z.B. wenn 10 Items mit gleichen Namen 10 verschiedene IDs haben), dann sind bei held - items und items - kaufort 1:n Kombinationen sinnvoll.
Dann kann jedem Item ein eindeutiger Held und ein Eindeutiger Kaufort zugeteilt werden. Falls alle Items mit dem Namen "X" die gleiche ID haben, stimmen natürlich die n:m Verhältnisse.
*Keine Gewähr!* Hab erst vor kurzem mit Datenbanken angefangen


----------

