Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/dbp09/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/dbp09/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/dbp09/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Datenbankpraktikum SS 2009 - Gruppe 1 - Backend-modellierung

Konzeptuelle Modellierung

ER-Diagramm

Zunächste wurde das Beschlossene Spielkonzept in ein ER-Diagramm mit sämtlichen benötigten Entitäten und den Beziehungen zwischen ihnen überführt.

Entitäten mit Active Record

Das Modellieren von Entitäten und Beziehungen zwischen ihnen gestaltet sich mit dem in Rails integrierten ActiveRecord Framework als äußerst komfortabel.

Zunächst legt man eine Migration an, die die Tabelle in der Datenbank mit den benötigten Feldern erstellt:

class CreateBuildings < ActiveRecord::Migration # Erbt von ActiveRecord::Migration
 
  # Methode zum erzeugen der Tabelle
  def self.up
 
    create_table :buildings do |t| # Tabelle erstellen namens buildings
 
      # Datenfelder erstellen
      t.integer :level  # Level des Gebäudes
      t.string :name    # Name des Gebäudes
 
      t.integer :planet_id # Fremdschlüssel für den Planeten auf dem das Gebäude ist.
 
      t.timestamps
    end
 
  end
 
  # Methode zum entfernen der Tabelle
  def self.down
    drop_table :buildings
  end
end

Führt man nun auf der Konsole den Befehl "rake db:migrate" aus, so wird der Ruby-Code in der Migration in passendes SQL zur verwendeten Datenbank übersetzt und ausgeführt.

Nun benötigt man noch eine Model-Klasse:

class Building < ActiveRecord::Base
 
  belongs_to :planet # Gebäude stehen auf Planeten
  has_one :build_order # Wird ein Gebäude gerade ausgebaut hat es eine BuildOrder
 
end

ActiveRecord generiert dynamisch die passenden Instanz-Methoden für den Zugriff auf die Attribute, indem es über "SHOW FIELDS" auf die entsprechende Tabelle die möglichen Attribute ausliest.

Man kann dann z.B. direkt auf das Attribut "level" zugreifen, oder den Planeten erfragen, auf dem das Gebäude ist:

b = Building.find(:first) # irgendeine Gebäudeinstanz aus der Datenbank hoolen
b.level # Level des Gebäudes
b.planet # Liefert ein Planeten-Objekt mit dem Planeten auf dem das Gebäude steht

Aufgrund der belongs_to-Beziehung kann man auch sehr komfortabel zu einem Planeten alle seine Gebäude erfragen ( Das Planetenmodel enthält entsprechend ein "has_many :buildings" ):

p = Planet.find(:first) # Einen beliebigen Planeten finden
b = p.buildings # liefert eine Collection aller Gebäude des Planeten als Building-Objekte.

Regelwerk

Das komplette Regelwerk wurde in einer zentralen Datei abgelegt. Dazu gehören sowohl Konstanten wie beispielsweise die Grundkosten eines Raumschiffes, als auch Methoden welche beispielsweise die Erzkosten eines bestimmten Schiffes bei gegebener Stufe aus einer Formel und dem Grundwert des Schiffes berechnet. Die Methoden, die oftmals noch von weiteren Faktoren abhängen (Rasse des Spielers, Forschungslevel einer bestimmten Sparte, Rohstoffbonus auf Planeten), und die Konstanten sind in der Moduldatei rules_and_regulations.rb hinterlegt, welche die Realisation des vorab entwickelten Regelwerks darstellt. Durch den Befehl

include "rules_and_regulations"

lassen sich alle Modulinhalte des RulesAndRegulations Modul wie folgt ansprechen:

  • Konstanten: RulesAndRegulations::Konstantenname
  • Methoden: RulesAndRegulations.Methodenname()

Die Entscheidung für diese lokale Art der Speicherung gegenüber einer Ablegung von Teilen des Regelwerk in der Datenbank hatte verschiedene Gründe. Generell ist es von Vorteil, die Daten an einer zentralen Stelle zu halten, da sich so Änderungen schnell realisieren lassen. Balancing und Feintuning werden somit deutlich komfortabler und weniger fehleranfällig. Die Benutzer des RulesAndRegulations-Modul können die Methoden weiterhin wie gewohnt aufrufen, auch wenn sich beispielsweise der Wert einer Konstante oder eine Formel zur Berechnung komplett geändert hat. Auch die Zugriffszeit auf eine Moduldatei ist deutlich schneller als ein Zugriff auf Daten in der Datenbank. Die zunächst angedachte Abspeicherung von Gebäude- und Schiffsdaten als Entitytyp Building/Spaceship_category wurde im Zuge der Optimierung wieder verworfen, da die Anpassung dieser Daten unkomfortabel ist und die Verarbeitung deutlich langsamer von Statten ging. Des weiteren sollte verhindert werden, dass das Regelwerk zu teilen als Daten in der Datenbank und als Methoden im Quellcode abgelegt sind. Von dem Versuch, die nötige Funktionalität durch Stored Procedures zu realisieren wurde abgesehen, da das Zeitfenster für Planung und Umsetzung sehr knapp begrenzt war.


Page last modified on August 23, 2009, at 03:50 PM