Entity Relationship Modell

[kossy]

Hallo !

Ich ahbe mla eine Frage. Gehört ein Entity Relationship Modell eigentlich in die Entwurfsphase eines Softwareprojektes, oder eher in die Definitionsphase eines Softwareprojektes? Nach Balzert gehört es angeblich in die Definitionsphase, allerdings klingt das für mich unlogisch. Wie seht ihr das?

 

[ThreadPool]

Hallo !

Ich ahbe mla eine Frage. Gehört ein Entity Relationship Modell eigentlich in die Entwurfsphase eines Softwareprojektes, oder eher in die Definitionsphase eines Softwareprojektes? Nach Balzert gehört es angeblich in die Definitionsphase, allerdings klingt das für mich unlogisch. Wie seht ihr das?

Ich zitiere ihn mal: "Ziel des ER-Modells ist es, die permanent gespeicherten Daten und ihre
Beziehungen untereinander zu beschreiben. Die Analyse erfolgt aus fachlogischer Sicht". Das ERM ist
also ein Werkzeug zur Modellierung der "statischen" Sicht auf die Daten eines Systems. Nach Balzert
fällt in der Definitionsphase ein konzeptionelles Modell ab, was gegen Veränderungen der Funktionalität
weitgehend stabil ist. Dieses Modell dient als Ausgangspunkt für den Datenbankentwurf in der
Entwurfsphase. Man hat also auf eine abstrakte Art beschrieben (in diesem Fall mithilfe eines ERM)
was es für Daten gibt und wie sie untereinder zusammenhängen. In der Entwurfsphase kannst du nun
überlegen ob du z.b. ein relationales DB Modell daraus zaubern möchtest oder ein objektrelationales
Modell oder was anderes. Es ist also nachvollziehbar weshalb Balzert das in der Definitionsphase
angesiedelt hat.

 

[kossy]

Ok danke dazu habe ich nochmal eine Frage. Im Anhang habe ich ein ER Modell meines aktuellen Projektes hochgeladen. Diese würde ich dann nach Herrn Balzert in der Definitionsphase vorstellen / einbauen.

Wie genau sieht denn dann der konkrete Entwurf dazu aus bzw was müsset ich dann in der Entwurfsphase aufzeigen?

Könnte ich nicht einfach sagen, dass ich anhand des in der Definitionsphase vorliegenden ER Modell eine relationale Datenbank aufbauen möchte und einfach wieder dasselbe Bild einfüge? Oder sollte ich in der Entwurfsphase lieber bereits konkrete Datenbanktabellen beschreiben? Also eher die Transformation in ein richtiges Datenbankmodell?

 

[ThreadPool]

Könnte ich nicht einfach sagen, dass ich anhand des in der Definitionsphase vorliegenden ER Modell eine relationale Datenbank aufbauen möchte und einfach wieder dasselbe Bild einfüge? Oder sollte ich in der Entwurfsphase lieber bereits konkrete Datenbanktabellen beschreiben? Also eher die Transformation in ein richtiges Datenbankmodell?

Also wenn es nach Balzert geht dann erstellst du in der Entwurfsphase ein sog. logisches Schema bzw.
DB-Schema. Damit meint er das du dein konzeptionelles Schema (ER-Modell) in ein (für dich)
relationales Schema überführst. Für die Überführung eines ER-Modells in ein relationales Schema gibts
ja bestimmte Vorgehensweisen d.h. Schemata wie z.B. m:n Beziehungen in Relationen umgeformt
werden. Wie das aussieht findest du z.B. in "Datenbanksysteme, Kemper/Eickler", der Balzert hat auch
ein paar Beispiele fand ich damals aber nich sooo super. Nach der Umwandlung deines ER-Modells in ein
relationales Schema solltest du das Ganze noch in eine Normalform deiner Wahl überführen
(hauptsächlich die dritte), Views festlegen und auch Zugriffsrechte festlegen. Balzert nennt dann den
letzten Schritt die Erstellung eines DB-Schemas. Und bevor deine Frage zur Implementierung kommt
die Umformung in SQL zum Anlegen der Tabellen etc. passiert dann in der Implementierungsphase
(nach Balzert)

EDIT: An deiner Stelle würde ich die "tbl" Sachen aus dem ERM rausnehmen, dass das mal relationale
Tabellen werden ist an der Stelle nicht von Bedeutung.

 

[kossy]

ok danke, müssen denn meine geplanten Views in der Entwurfsphase so ähnlich modelliert werden, wie das im folgenden Beispiel der Fall ist?

http://i.msdn.microsoft.com/Aa902653.smalllibrarysample_fig1(de-de,SQL.80).gif

Oder gibt es dafür andere Transformationsregeln? Oder vielleicht gar keine?

 

[ThreadPool]

ok danke, müssen denn meine geplanten Views in der Entwurfsphase so ähnlich modelliert werden, wie das im folgenden Beispiel der Fall ist?

http://i.msdn.microsoft.com/Aa902653.smalllibrarysample_fig1(de-de,SQL.80).gif

Kannst du halten wie du möchtest, Balzert z.B. gibt die rein textuell an.

Ein Beispiel aus seinem alten Buch "Lehrbuch der Software-Technik I (2004)":

Folgende Sicht gibt alle Veranstaltungen zu dem Seminartyp SWT aus die öffentlich sind.

View Schema
Name: Veranstaltungen zu SWT
Attribute: Titel:= Seminartyp.Seminartitel
Veranstaltungsort:= Seminarveranstaltung.Ort
Hotel:= Seminarveranstaltung.Hotel_Firma
Anfang:= Seminarveranstaltung.Vom
Ende:= Seminarveranstaltung.Bis
Conds: Seminarveranstaltung.Kurzitel="SWT"

Du siehst das er eine View aus vorhandenen Relationen und deren Attributen zusammensetzt, wobei
die "Conds" (Selektionsbedingungen) die Bedinungen zur "Auswahl" sind. Er meint diese seien in
Relationenalgebra anzugeben, ich find nur keine in seinen Beispielen. Das ist eher Pseudo-
Relationenalgebra.

 

[kossy]

Könnte ich nciht einfach schreiben, aus welchen Datenbanktabellen sich die View zusammensetzt und was sie bezwecken soll. Muss ich denn dafür unbedingt so eine fixierte Vorgehensweise anwenden?

 

[ThreadPool]

Könnte ich nciht einfach schreiben, aus welchen Datenbanktabellen sich die View zusammensetzt und was sie bezwecken soll. Muss ich denn dafür unbedingt so eine fixierte Vorgehensweise anwenden?

Macht er ja auch, schau dir das Beispiel an "Viewattribut := RelationDieDasAttributEnthält.AttributDas
GebrauchtWird".

Im Prinzip ist es wichtig eine einheitliche und eindeutige Darstellung zu wählen, das Schlimmste was dir
passieren kann ist das jmd der die Anforderung umsetzen will es nicht versteht oder die Anforderung
mehrdeutig interpretiert werden kann. Deshalb empfiehlt es sich da wo es geht eine standardisierte
Darstellung zu verwenden, wie die aussieht oder welche du bevorzugst ist dabei dir überlassen.
Aber so bist du auf der "sicheren Seite" das es eindeutig definiert ist was da zu passieren hat.

 

[kossy]

Ich habe nochmal eine Frage. Wenn ich innerhalb der Definitionsphase erste Benutzeroberflächenprototypen erstelle (nur Papierskizzen und nichts ablauffähiges), kann ich dass dann so in meiner Arbeit verkaufen, dass ich anhand dieser Skizzen, den Inhalten des Pflichtenheftes sowie den gesammelten Anforderungen ein ersten konzeptionelles DB-Schema (ER-Modell) erstelle? Klingt das plausibel?

 

[ThreadPool]

Ich habe nochmal eine Frage. Wenn ich innerhalb der Definitionsphase erste Benutzeroberflächenprototypen erstelle (nur Papierskizzen und nichts ablauffähiges), kann ich dass dann so in meiner Arbeit verkaufen, dass ich anhand dieser Skizzen, den Inhalten des Pflichtenheftes sowie den gesammelten Anforderungen ein ersten konzeptionelles DB-Schema (ER-Modell) erstelle? Klingt das plausibel?

Irgendwie verstehe ich das glaube ich nicht richtig und kann nicht einordnen auf was deine Frage
abzielt. Als Erstes geht deine Definition eines Prototypen irgendwie an der allg. Def. eines Prototypen
in diesem Zusammenhang vorbei. Ich hab noch keinen GUI-Prototypen gesehen der nicht ablauffähig
war, also wo man nichts klicken konnte oder die GUI irgendwie grafisch "simuliert" wurde. Das ist alles
schon da nur die Fachlogik fehlt oft komplett.

Zu der Frage ob es plausibel klingt. Kommt drauf an, wenn du z.B. nach Balzert gehst,
gehören "Artefakte" wie ein ER-Modell zu den formalen Methoden der Beschreibung von Anforderungen.
Die wiederum teil des sog. Produkt-Modells sind, das basierend auf dem (meist verbal formulierten)
Pflichtenheft erstellt wird. Das Produkt-Modell (nach Balzert) ist also ein Ergebnis auf der selben
Stufe wie das Pflichtenheft innerhalb der Definitionsphase und das eigentliche Ziel der
Definitionsphase. So gesehen ist dein Satz zwar komisch formuliert jedoch plausibel.