Mein Lehrmeister hat zu einem meiner ERDs gesagt, "Circles" sollten vermieden werden, sie bringen sonst später Probleme mit sich. Und um folgenden Fall gehts:
Eine Firma hat Kontakte, genauso ein KMU, beide haben Kontaktpersonen.
Eine grössere Firma kann KMUs besitzen.
==> Problem, der "Circle" entsteht.
Wie kann ich jetzt dieses Problem lösen? Was würdet ihr vorschlagen, welche Alternativen gibt es?
Das sind die Entitäten und Relationen, die ich herauslese:
Firma --hat--> Kontakt
Firma --hat--> Kontaktperson
KMU --hat--> Kontakt
KMU --hat--> Kontaktperson
Firma --besitzt--> KMU
Das sind alles Einbahnstrassen, da führt kein Weg zurück zum Ausgangspunkt. Wo soll da jetzt ein Kreis sein?
Die von Abraxax angesprochene IS-A-Bezieung (ein KMU ist eine Firma) solltest du auf jeden Fall erstmal mit modellieren. Später kannst du die beiden Entitäten vielleicht zu einer zusammenführen. Dann ist es vielleicht nur noch ein Flag "isKMU", eine Spalte im DB-Design in der Tabelle Firma.
Quatsch, jemand, der sowas macht, hat keine Ahnung von Data Modeling. Selbst wenn der Ansprechpartner von Mutter- und Tochtergesellschaft die gleiche Person wäre, warum weist du sie mit Zirkelbezug zu? Warum nicht einfach als unabhängigen Kontakt aufnehmen, denn es könnte sich doch auch ändern, z.B. Übernahme der Tochtergesellschaft durch eine andere Firma.
Ich hätte jetzt spontan die Kontakte in einer separaten Liste abgelegt und jeden Datensatz mit nem PRIMARY KEY versheen und dann überall wo der Kontakt gebraucht wird ne Zuweisung auf die ID. -> Redundanz wird vermieden.
Nein, denn es ist zwar zufällig die gleiche Person, sie ist aber Angestellte in 2 verschiedenen Firmen. Es ist außerdem ein Sonderfall, von daher kannst du nicht von Redundanz sprechen. Nimm doch mal ein CRM Programm und erfasse eine Firma, welches Programm läßt dich denn Daten von bestehenden Ansprechpartnern von fremden, bereits aufgenommenen Firmen der gerade erfassten Firma zuweisen?
Das ist kein Zirkelbezug. Wenn man den Pfeilen folgt, kommt man von Firma über KMU zu Kontakt, aber der letzte Pfeil zeigt in die andere Richtung. Man kann also nicht von Kontakt zu Firma springen.
Als Klassen würde das etwa so aussehen:
class Firma
class KMU extends Firma
class Mitarbeiter {
function __construct(Firma $firma) {}
}
class Kontakt extends Mitarbeiter
Und als Relationen:
Firma(id, name, ...)
KMU(Firma.id, ...)
Mitarbeiter(id, Firma.id, name, ...)
Kontakt(id, Mitarbeiter.id, ...)
KMU ist eine Spezialisierung von Firma, Kontakt eine von Mitarbeiter. Falls KMU und Kontakt keine weiteren Eigenschaften haben, kann man zusammenfassen:
Firma(id, name, ..., isKMU)
Mitarbeiter(id, Firma.id, name, ..., isKontakt)
Wow Leute, mit so vielen Antworten habe ich nicht gerechnet ^^
Zitat:
Firma -> KMU -> Kontakt <- Firma
Damit hatte Abraxax recht, so wars gemeint. Ich habe das nochmals als Bild verdeutlicht.
Ob das ein Zirkelbezug ist oder nicht, vermag ich nicht zu beurteilen.
Mein ihr also, damit, so sei es in Ordnung und müsse nicht verändert werden? Oder wäre doch sowas wie
Zitat:
"Firma hat KMU hat Kontakt"
eine Lösung?
Danke für die Hilfe
Herzlichen Gruss
Onyx
EDIT: Die Logik wurde noch diskutiert; Es kann in meinem Fall durchaus sein, dass eine Person sagen wir zu 50% als Sekretärin bei der grossen Firma und 50% als Sekretärin bei der Tochterfirma arbeitet. Oder zumindest ist sie als Kontaktperson für Aussenstehende eingetragen, unabhängig davon, für wen sie arbeitet.
Geändert von Onyxagargaryll (22-05-2009 um 08:48 Uhr)
Nein, denn es ist zwar zufällig die gleiche Person, sie ist aber Angestellte in 2 verschiedenen Firmen. Es ist außerdem ein Sonderfall, von daher kannst du nicht von Redundanz sprechen.
einverstanden sind, dann haben wirs, ja. Nur wurde der Thread während meiner Abwesenheit heiss diskutiert und oft falsch interpretiert, also habe ich vorerst angenommen, man habe aufgrund unklarer Informationen aufgehört zu diskutieren
Aber wenn das kein Zirkelbezug ist, dann ist ja alles bestens!
Es kann in meinem Fall durchaus sein, dass eine Person sagen wir zu 50% als Sekretärin bei der grossen Firma und 50% als Sekretärin bei der Tochterfirma arbeitet. Oder zumindest ist sie als Kontaktperson für Aussenstehende eingetragen, unabhängig davon, für wen sie arbeitet.
Hm, da würde ich Person als Entität modellieren. Mitarbeiter und Kontakt sind dann Spezialisierungen von Person, ggf. kann es dazwischen auch eine Abstraktion "Rolle" geben.
Wie kommst du eigentlich auf eine 1-zu-N-Beziehung zwischen Firma und KMU in deinem ERD?
MariaDB 5.5 veröffentlicht Die freie MySQL-Alternative MariaDB wurde in der stabilen Version 5.5.23 veröffentlicht und soll einige Verbesserungen gegenüber Oracles Communityversion von MySQL mitbringen.
Login-System und Kundenverwaltung, die sich spielend leicht in bestehende Webseiten einbauen lässt und einen enormen Funktionsumfang bietet.
Ihre eigene Webseite muss mit Advanced Login nicht umständlich an ein fertiges System angepasst werden.
Spezielles CMS für Betreiber von Ferienwohnungen. Komplette Seitenerstellung online, Verwaltung mehrerer Objekte, Reservierungssystem mit sofortigem Abgleich im Belegungskalender und vieles mehr bietet dieses Content Management System.
Alle PHP Scripte anzeigen 
Jetzt registrieren
ERD-"Circles"
)
Berni
