Datenbank - Modellierung Anlagevermögen / Umlauf

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo zusammen,

ich entwerfe gerade ein Datenbankmodell, in dem ich das Anlagevermögen und Umlaufvermögen (Fuhrpark, Mta, BGA, etc…) eines Unternehmens darstellen will.

Die große Frage die ich mir nun stelle ist, welche Logik verwende ich bzw. wie Teile ich die Daten auf welche Tabellen auf:

  1. Ich definiere in einer Tabelle die einzelnen möglichen Bereiche wie Fuhrpark, MtA, FE, UE etc. und lege dann für jeden einzelnen Bereich eine eigene Tabelle mit den jeweiligen notwendigen Informationen an (Z.B. beim Fuhrpark - Hersteller, Typ, Kennzeichen, Kilometerstand, etc…)

  2. Ich lege eine Tabelle an, in der ich jede Position anlege und definiere nun über eine Spalte den zugehörigen Bereich (Fuhrpark, MtA, FE, UE etc.). In der Tabelle pflege ich weiterhin Standardinformationen zu jeder Position wie Bezeichnung, Hersteller (Lieferant), Wertansatz. Weitere Detail-Informationen wie z.B. Kennzeichen, Kilometerstand bei einem PKW würde ich dann wieder separat in einer separaten Beschreibungstabelle für Fahrzeuge auslagern.

Welche Logik hat nun welche Vorteile/Nachteile? Im Endeffekt geht es ja für mich um die Entscheidung, ob ich entweder die Standardinformationen wie Bezeichnung, Hersteller, Typ, Wertansatz für alle Bereiche in einer Tabelle („Position“) anlege oder diese Daten mit in der Detailtabelle („Fuhrpark“, „MTA“, etc…) anlege?

Danke schon mal für eure Hilfe
LG
Wilhelm

#2

Also die zweite Variante hört sich eher nach einer gut normalisierten Datenbank an.

Die Wartungsarbeit bei dieser Variante dürfte wesentlich geringer sein, da du zusammenhängende Information, also Informationen, die jeder verwendet in eine gemeinsame Tabelle legst und diese dann mit einer 1:1 Beziehung zu den speziellen Informationen verlinkst. Du kannst also ohne Probleme auch im Laufe der Zeit neue Tabellen hinzufügen, ohne besonderen Aufwand in Beziehungen zu stecken.

Wenn du zudem als Anbindung der Datenbank eine Objektorientierte Sprache verwendest (c++, Java, …) dann kannst du hier gut das Prinzip des ORM-Mappings mit Vererbungsstrukturen (Diskriminatorspalte im Typ, also Fuhrpark, Mta, FE, etc) realisieren.

Wenn du dir sehr unsicher bist, dann verwende einfach die Normailisierung bis zur 3. Normalform (http://de.wikipedia.org/wiki/Normalisierung_%28Daten…) Wenn du diese Standardverfahren nutzt, dann erhälst du immer eine gute Struktur für deine Datenbank.

mit freundlichen Grüßen
R3van

#3

Hallo Wilhelm,

wenn Du das diskutieren willst…07159 40 59 09 12
Sonst schreiben wir uns die Finger wund :smile:
Peter Zimmermann www.pzAccess.de

#4

Hallo Wilhelm,

das relationale Datenbankmodell sieht vor, eine Tabelle t_Bereiche anzulegen, in der du nur die Bereiche einträgst.
Dann legst du eine zweite Tabelle t-Positionen an, in der du alle Positionen erfasst und in einer „Spalte“ (=Feld) den Bereich aus der Untertabelle eingibst.
Hierzu musst du die beiden Tabellen mit einer 1:n Verknüpfung (t_Bereich=1, t_Positionen=n) verbinden.
nachteil: Du musst alle nur möglichen Felder in die Tabelle t_Positionen packen! Vorteil: Auswertungen gehen immer nur auf die eine Datentabelle t_Positionen. So kann man aber easy Abfragen machen. bei deiner Möglichkeit 1 nämlich brauchst du ziemlich viel SQl-Code mit Union-Abfragen, falls du eine übergreifende Auswertung benötigst.
Des weiteren kannst du eine dritte Tabelle t-Details anlegen, die du z.B. über den Index-Key „POS-Nr.“ mit t_Positionen verknüpfst. Hier nimmt man dann t_Positionen als 1 und t_Details als n.
Ich hoffe, dass du damit zurechtkommst, ansonsten melde diche einfach wieder.
Viel Erfolg
LG Heike

#5

Hallo Wilhelm,

grundsätzlich sind beide Varianten austauschbar, für die Variante 1 hast du zwar Redundanz, da du gleichartige Werte in verschiedenen Tabellen speicherst und allfällig Constraints / Trigger etc. doppelt führen musst, es kann aber ein Vorteil sein dies so zu machen, wenn du beispielsweise eine OO-Anwendung hast und dann schön eine Klasse auf eine Tabelle mappen kannst. Es macht die Queries schön übersichtlich und klar verständlich

Bei der Variante 2 kannst du die Vorteile des RDBMS voll ausnutzen und gleiches gleich behandelt, so kannst du mit Contraints allgemein gültige Regeln definieren und auch eine History-Tabelle anlegen welche sich leicht pflegen lässt. Die Queries werden zwar etwas komplexer, aber immer noch machbar. Wenn du Vergeleiche zwischen den Bereichen machen willst, hast du hier natürlich alle Vorteile, da du nicht zuerst aus verschiedenen Tabellen die Infos zusammensuchen musst. Mit Hilfe von Views kannst du die Bereiche auch wieder logisch auseinander nehmen um so das Mapping zu erleichern. Wenn neue Bereiche dazukommen dann hast du es hier auch einfachen, da du einfach neue Records erzeugen kannst und nicht eine neue Tabelle anlegen musst.

Von daher würde ich sagen: Es kommt darauf an wie du auf die Daten wieder zugreifen willst. Wenn du eine OO-Applikation hast, dann würde ich eher Variante 1 wählen, wenn du mehr auf der DB-Seite arbeitest bzw. dort auch noch Reports etc. erstellen willst, bist du mit der Variante 2 wohl besser bedient.

Das sind so meine Gedanken dazu.

Gruss Stefan

#6

Hallo,

ich möchte euch allen schon mal ganz recht herzlich für eure Antworten bedanken. Hilft mir schon mal ein wenig weiter mich zurecht zu finden.
Ich bin gerade dabei unser komplettes Unternehmen abzubilden und werde wohl noch den ein oder anderen Kampf vor mir haben. Wenn das Datenmodell nicht passend ist, dann bekomme ich danach nur Probleme…

Vielen Dank
Gruß
Wilhelm

#7

Hallo,

meine Erfahrung mit den Datenbanken ist, dass die Tabellenstruktur Auswirkungen auf die Performance hat. Konkret: Jede zusätzliche Tabelle kostet einen JOIN in den Abfragen und jeder JOIN macht Abfragen langsamer.

Bei Alternative 1 glaube ich, dass es schwierig ist, wenn alle Daten zusammen dargestellt werden müssen. Gut ist jedoch, dass die bei Suchen die Tabellen unabhängig voneinander durchsucht werden können.

Bevorzugen würde ich Alternative 2. Die „Bereiche wie Fuhrpark …“ wären Fremdschlüssel in der Tabelle mit den relevanten Daten.

Ich hoffe, das hilfe und sende viele Grüße.