unschlüssige Prüfungsaufgaben

[ha20]

Hallo.

Habe gerade mal wieder paar AP-Aufgaben durchgemacht, die wir in der Schule bekommen haben. Da ist eine Frage dabei... mal sinngemäß:

Zeichnen Sie ein ER-Model zu obigen Angaben. Beachten Sie dabei die ersten 3 Normalformen.

Da hackt's bei mir aus. ER-Model soweit klar. Normalformen sind auch klar. Aber wie um Himmels willen soll ich die bei einem ER-Model einhalten?!? In dem Model hab ich doch garkeine Attribute.

Hab mir dazu mal unsere Musterlösung angeschaut... Das war ein relationales Datenbankmodel.

Klar, da kann man das schön mit den Normalformen beachten, aaaaaber, wie zum Teufel soll ich in der Prüfung drauf kommen, dass wenn die nach einem ER_Model fragen, die in Wirklichkeit ein relationales Model wollen??????

[matthias_nordwig]

Was ist ein ER-Model(Entity-RELATIONSHIP-Model) deiner Meinung nach, wenn kein relationales Model?

Und wer sagt eigentlich das es bei einem ER-Model keine Attribute gibt?

Google mal nochmal danach. Oder habe ich das jetzt falsch verstanden?

[ha20]

Hier ein ER-Model

Bei dem bei uns in der Schule als "relationales Datenbank-Model" bezeichnete Model handelt es sich imo um ein Model, wo die ganzen Tabellen konkret gezeichnet werden und die ganzen Attribute (evtl noch deren Datentyp) gezeichnet werden...

[AVi]

und dass was die lösung beschreibt nennt sich meiner meinung nach .... datenbank modell aber halt nicht nur auf die entities bezogen

oder so.. vom vielen lernen weiß ich gar nich mehr wo oben und unten ist

und unter einem ERM versteh ich dasselbe wie die wikiseite

[matthias_nordwig]

Hier mal ein mustergültiges Beispiel für ein ER-Model:

http://www.uni-koeln.de/rrzk/kurse/unterlagen/access/alt/er.pdf

Obwohl ich persönlich, das Teil so für schwachsinnig halte. Sinnvoll ist das wie es beispielsweise im QDesigner oder meinetwegen auch in der Beziehungsansicht von Access dargestellt wird.

Mich würde an dieser Stelle interessieren wie die IHK das will. Ach ja im IT-Handbuch ist dieses zweckfreie Teil auch so verkorkst drin.

Vielleicht währe an dieser Stelle ein Kommentar von einem Prüfer mal net schlecht.

Um jetzt aber keine Verwirrung zu stiften: Das Ding auf der ersten Seite ist normalerweise das mustergültige Teil!

[The_red_one]

So mal zur Aufklärung wie man ein DB-Modell entwickelt und wann welches Diagramm:

1. Informationanalyse (-> was will ich darstellen?)

2. Konzeptuelles Modell/ ER-Modell erstellen (Entities (evtl. inkl. Attribute/ muss hier meiner Meinung noch nicht sein) und Relationen)

hier gibts etliche veschiedene Notationen, die "bekanntesten" sind:

a) Bachmann-Notation = Martin-Notation = "Krähenfuß-Notation"

so habs ich gelernt und mich für die Prüfung umgestellt, weil ich nicht riskieren wollte, dass den Prüfern diese Notation nicht geläufig ist...

Chen-Notation (wie in der BS gelernt)

3. Relationales Modell erstellen (Tabellen-Darstellung incl. Attribute)

hierzu werden die Entities und Relations in Tabellen und Schlüsselbeziehungen umgewandelt/ aufgelöst -> Normalisierung! in die 3. Normalform

4. Implementirung in Oracle, Access, mySQL oder sonst wo....

Ich hatte die Prüfung wo ein ER-Modell in 3.NF verlangt wurde.... und ich habe hingeschrieben, dass ein ER-Modell in der 3.NF ein Widerspruch in sich ist und eine Normalisierung erst in der nächsten Modellierungsphase ansteht und ich mich für die relationelle Tabellen-Darstellung entschieden habe um die 3.NF korrekt abbilden zu können. -> 20Punkte!

Hier mal ein schönes Beispiel, gut und durchgängig sauber erklärt.

... ich liebe die DB-Modellierung... :hodata

[matthias_nordwig]

Ich hatte die Prüfung wo ein ER-Modell in 3.NF verlangt wurde.... und ich habe hingeschrieben, dass ein ER-Modell in der 3.NF ein Widerspruch in sich ist

Diese Aussage ist so, jedoch schlichtweg falsch! Begründung: Selbstverständlich lässt sich ein ER-Model normalisiert realisieren!

Denn es kann Attribute und Schlüsselattribute beinhalten!

Da die Normalisierung sich im Prinzip nur mit diesen und Ihren Abhängigkeiten auseinandersetzt ist das durchaus möglich. Wo steckt dabei jetzt der Wiederspruch? Siehe von mir oben angegebenen Link!

...und eine Normalisierung erst in der nächsten Modellierungsphase ansteht und ich mich für die relationelle Tabellen-Darstellung entschieden habe um die 3.NF korrekt abbilden zu können. -> 20Punkte!

Die 20 Punkte gabs dann wohl für das korrekte ER-Model

Denn: Was ist diese "relationelle Tabellen-Darstellung", wenn kein ER-Model?

Es beinhaltet Relationen und Entitätsmengen. Der einzige inhaltliche Unterschied dieser beiden Darstellungsarten, ist die Tatsache das diese Chen-Notation ebend nur Entitäten und die Tabellen-Darstellung Entitätsmengen bezeichnet. Und das Beziehungen mit Attributen sowie n:m-Beziehungen im Tabelle-Model als eigenständige Tabellen modelliert werden.

Hier mal ein schönes Beispiel, gut und durchgängig sauber erklärt.

Schade das der net funzt!

...ich liebe die DB-Modellierung...

Ich hasse es! Es ist eine elendige Arbeit. Wenn man dabei von größeren Datenbanken ausgeht.

MfG

Matthias

[Railer]

Diese Aussage ist so, jedoch schlichtweg falsch! Begründung: Selbstverständlich lässt sich ein ER-Model normalisiert realisieren!

Denn es kann Attribute und Schlüsselattribute beinhalten!

Da die Normalisierung sich im Prinzip nur mit diesen und Ihren Abhängigkeiten auseinandersetzt ist das durchaus möglich. Wo steckt dabei jetzt der Wiederspruch?

ER-Model und ein relationales Modell sind unterschiedliche Dinge obwohl sie oft verwechselt werden. Wenn man nach den Regeln geht, darf ein ER-Modell gar keine Schlüssel haben. Weder Primär- noch Fremdschlüssel, denn dafür sind die Beziehungen da. Wenn man zwei Tabellen mit einander mittles Beziehung (Raute) verbindet und dabei noch an den beiden Tabellen Primär- und Fremdschlüssel malt, ist es einfach falsch.

Wie bereits erwähnt, ist ein ER-Modell eine grobe Konzeptionierung, während das relationale Modell das Resultat der weiterentwicklung davon ist, also Feinkonzept der DB.

Ein normalisiertes ER-Modell ist humbug.

[The_red_one]

Diese Aussage ist so, jedoch schlichtweg falsch! Begründung: Selbstverständlich lässt sich ein ER-Model normalisiert realisieren!

Denn es kann Attribute und Schlüsselattribute beinhalten!

Da die Normalisierung sich im Prinzip nur mit diesen und Ihren Abhängigkeiten auseinandersetzt ist das durchaus möglich. Wo steckt dabei jetzt der Wiederspruch? Siehe von mir oben angegebenen Link!

Attribute ja. Schlüsselattribute nur begrenzt, da bei einer Auflösung(Normalisierung) von m:n-Beziehungen die Schlüssel erst im tabellarischen Modell entstehen.

Ich versteh dein Problem ned.

Die 20 Punkte gabs dann wohl für das korrekte ER-Model

Wenn du meinst.

Schade das der net funzt!

hier der funktionierende LINK

Ich hasse es! Es ist eine elendige Arbeit. Wenn man dabei von größeren Datenbanken ausgeht.

Ich mache nur "grössere" Sachen!

[AroganzOn]Und bei mir klappts, weil ichs kann![/AroganzOn]

Kuck dir die ppt an und dann verstehst du auch wie ich das mit ER-Modell und Normalisierung etc. sehe.

[The_red_one]

Ein normalisiertes ER-Modell ist humbug.

D a n k e!

[matthias_nordwig]

da bei einer Auflösung(Normalisierung) von m:n-Beziehungen die Schlüssel erst im tabellarischen Modell entstehen.

Auch Beziehungen können Attribute haben!

ER-Model und ein relationales Modell sind unterschiedliche Dinge obwohl sie oft verwechselt werden. Wenn man nach den Regeln geht, darf ein ER-Modell gar keine Schlüssel haben.

Also diese Aussage ist verallgemeinernd und ebenfalls falsch!

Zitat dazu:

"There is no standard for representing data objects in ER diagrams. Each modeling methodology uses its own notation."

Link:

http://www.utexas.edu/its/windows/database/datamodeling/dm/erintro.html

Betreiber: University of Texas at Austin

Überschrift: "ER-Notation"

Stand: 27.04.2005

Ein normalisiertes ER-Modell ist humbug.

Ebenfalls falsch: Denn dann dürfte es nichteinmal in der Ersten Normalform stehen und genausowenig in der Zweiten-> Also alles in einer einzigen Liste

-> Es gäbe zwar noch Entitäten(Datensätze) aber keine Relationen mehr :beagolisc

Das wähjre dann ein sehr sinnvolles Entity-RELATIONSHIP-Model

Wenn du meinst.

Meine ich!

Ich mache nur "grössere" Sachen!

[AroganzOn]Und bei mir klappts, weil ichs kann![/AroganzOn]

Ich meine damit auch eher die Anspruchslosigkeit. Denn wenn man dann Tabellen modellieren muss die über einhundert Attribute haben dann wird es zur Drecksarbeit. Der Vorteil ist das der Code dann direkt generiert wird.

Aber ganz ehrlich: Für einen Datenbankentwickler ist das doch echt langweilig.

Bei uns ist sowas typische Azubiarbeit ... leider.

Da kann ich auch "Excel-Tabellen-schieben".

[The_red_one]

Ich lasse das ganze jetzt so stehen, denn wer DB-Modellierung als "Azubi-Arbeit" abtut (-> setz neuen Kaffee auf und modellier noch schnell unser DB-Konzept, wir treffen uns dann in 10 Minuten :beagolisc ), der hat keine Ahnung wie komplex die Thematik sein kann.

[matthias_nordwig]

Ich lasse das ganze jetzt so stehen, denn wer DB-Modellierung als "Azubi-Arbeit" abtut (-> setz neuen Kaffee auf und modellier noch schnell unser DB-Konzept, wir treffen uns dann in 10 Minuten :beagolisc ), der hat keine Ahnung wie komplex die Thematik sein kann.

Wir arbeiten hier an einer Oracle-Datenbank mit ca. 150 Tabellen. und einem Speichervolumen von 44 GB. Dort stecken alle 6 Normalisierungsstufen irgendwo mal drin. Es gibt dort auch Selbstreferenzen und sonstigen Kram.

Aber die Hauptarbeit besteht in der Weiterentwicklung und Schaffung neuer Datenschnittstellen zu Fremdsystemen. Die größte und mit Abstand kreativste Arbeit steckt folglich in der Entwicklung diverser PL/SQL-Skripte.

Obwohl mir euer Ansatz mit dem Grob und Feinkonzept bei der Datenmodellierung ganz gut gefällt. Dann erklärt sich geringfügig auch der Sinn dieser Chen-Notation.

p.s. Ausserdem leisten Azubis gute Arbeit.

MfG

Matthias

[matthias_nordwig]

Um die Verwirrung aber ein wenig einzudämmen -> zur ursprünglichen Problematik:

1. Ein ER-Model lässt sich normalisieren! (Links gibt es genug dazu)

2. Nutze Google!

3. Versuche die Gesamtheit zu verstehen und nicht dich daran aufzuhalten dir irgendwelche Symbole in den Kopf zu prügeln, denn die kannst du auch dem IT-Handbuch entnehmen.

4. Und um die Kritiker zur Ruhe zu stellen, kannst du falls du es in der Tabellenform (was ich und auch genügend offizielle Institutionen(Unis) noch immer als ER-Model bezeichnen) zeichnen möchtest, ja dazuschreiben das es sich dabei um eine spezielle Tabellen Form handelt.

MfG

Matthias

[Gosiris]

zu 4.:

Heißt die Darstellungsform nicht offiziell Extended Entity Relationship (EER)? Ich meine sowas mal im Forum von DBDesigner gelesen zu haben. DBDesigner kreiert ja auch eine solche tabellenartige Darstellung, die man eigentllich nicht als ER bezeichnen kann.

In meiner Abschlussprojekt-Dokumentation habe ich auf jeden Fall eine Grafik von DBDesigner verwendet und sie in gutem Glauben als EER bezeichnet, auch wenn ich mir nicht ganz sicher war. Aber das Forum von DBDesigner ist ja leider geschlossen, deswegen konnte ich das nicht mehr nachforschen.

[matthias_nordwig]

zu 4.:

Heißt die Darstellungsform nicht offiziell Extended Entity Relationship (EER)?

...

Jain.

EER-Model bezieht sich auf die Tatsache das Beziehungen auch Attribute besitzen können, nicht aber auf die Darstellungsform. (also Tabelle(entity-sets) oder entitys)

Sprich es konzentriert sich eher auf das objektorientierte Problem, als auf das Relationale.

Wenn ich den Einwand jetzt richtig verstanden habe.

Hier noch ein Link dazu:

http://www.csc.liv.ac.uk/~paolo/COMP507/PDF/23_paolo.pdf

Letztendlich ist aber auch jenes ein ER-Model! :floet:

p.s. Da du ja wahrscheinlich für n:m-Beziehungen auch die entsprechenden Beziehungstabellen mit aufgeführt hast, bin ich der Meinung das die Bezeichnung dann auch richtig ist. :cool:

MfG

Matthias