# Entity Relationship Modell



## kossy (31. Jan 2010)

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 (31. Jan 2010)

kossy hat gesagt.:


> 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 (31. Jan 2010)

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 (31. Jan 2010)

kossy hat gesagt.:


> 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 (31. Jan 2010)

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 (31. Jan 2010)

kossy hat gesagt.:


> 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
> ...



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 (31. Jan 2010)

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 (31. Jan 2010)

kossy hat gesagt.:


> 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 (31. Jan 2010)

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 (2. Feb 2010)

kossy hat gesagt.:


> 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.


----------

