Konzept und Realisierung eines multimedialen Datenbanksystems

Das Entity Relationship Modell (ERM) wurde 1976 von P. Chen zur Datenmodellierung entwickelt. Ziel des ERMs ist es, die permanent gespeicherten Daten und ihre Beziehungen untereinander zu beschreiben. Die Analyse der Informationen erfolgt aus fachlogischer Sicht. Es entsteht ein konzeptionelles Modell, das gegen Veränderungen der Funktionalität weitgehend stabil ist. Eine Entität (entity) ist ein individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt und wird durch den Wert der Eigenschaft beschrieben. Für Entität wird oft der Begriff „Objekt” verwendet [/Balzert 2/ S. 138]. Damit bildet das ERM eine ideale Grundlage für den Aufbau einer relationalen Datenbank. Die Entität, ein materielles oder immaterielles Objekt, besitzt fachliche Eigenschaften. Entitäten mit gleichen Eigenschaften bilden eine Entitätsmenge (entity set). Als Beispiel für eine Entitätsmenge in der Multimediadatenbank kann das Medium Bild stehen, das einige beschreibende Attribute und ein identifizierendes Attribut, Bild-Nr., besitzt. Über dieses identifizierende Attribut ist eine sichere Zuordnung möglich, da der Wert dieses Attributes eindeutig sein muss, d.h. es darf nicht zwei Entitäten mit gleichem Wert in diesem Attribut geben. Man bezeichnet das identifizierende Attribut auch als Schlüsselattribut. [...]

Das Attribut „image_data” enthält einen Satz an Variablen, in denen Informationen aus der Datenbank zwischengespeichert werden. Die Operation „setData” benötigt zur Ausführung zwei Parameter: image_data, der die gesamten Metadaten zu einem Medium enthält, und die MotivID, eine eindeutige Nummer, über die das Motiv identifiziert wird. Über die Operationen der Klasse „SocketCom” ist es möglich, direkt mit dem PHP-Skript im Webserver zu kommunizieren. Dazu werden die Informationen einfach mit der Operation „sendString” an das PHP-Skript geschickt und mit der Operation „receiveString” entsprechend empfangen, so dass man im gesamten Programm auf diese Klasse zugreifen kann und damit nicht jedes Mal diese Funktionalität neu programmieren muss. Durch diese Kapselung von Operationen und Attributen wird es möglich, komplexe Aufgaben in ihre Einzelteile zu zerlegen und Klasse für Klasse zu realisieren. Dies erleichtert auch die Fehlersuche im fertigen Programm, da alle Operationen, die mit der Datenübertragung zum PHP-Skript zu tun haben, in dieser Klasse gebündelt sind. [...]

Um die Anforderungen an eine Software zu spezifizieren, ist ein Modell notwendig, dass lediglich die Interaktion des Benutzers mit dem Softwaresystem beschreibt. Der Begriff „use case”, zu Deutsch „Anwendungsfall”, wurde von Jacobson geprägt. Erstmals wurde er 1987 in Zusammenhang mit objektorientierten Methoden vorgestellt. Dabei unterscheidet Jacobson zwischen einem use case in einem Informationssystem und in einem Unternehmen. Der use case in einem Informationssystem wird definiert »als eine Sequenz von zusammengehörenden Transaktionen, die von einem Akteur im Dialog mit einem System ausgeführt werden, um für den Akteur ein Ergebnis von messbarem Wert zu erstellen«. Messbarer Wert bedeutet, dass die durchgeführte Aufgabe einen sichtbaren, quantifizierbaren und/oder qualifizierbaren Einfluss auf die Systemumgebung hat. Eine Transaktion ist eine Menge von Verarbeitungsschritten, von denen entweder alle oder keiner ausgeführt werden. Alle use cases zusammen dokumentieren alle Möglichkeiten der Benutzung des Systems (use case model) [/Balzert 1/S. 62]. Der use case in einem Unternehmen (business system) wird »als eine Sequenz von Transaktionen in einem System (=Unternehmen)« definiert. Die ausgeführte Aufgabe soll für den Akteur des Unternehmens von messbarem Wert sein. [/Balzert 1/S. 62] [...]