Office: (Office 2016) Beziehungen

Hallo, ich bin neu hier und möchte mir eine private Filmdatenbank aufbauen. Ich habe bisher die Tabellen und Beziehungen soweit fertig und würde gerne wissen ob hier gravierende Designfehler bestehen. Also mir geht es jetzt z.B. nicht um Namenskonventionen.
Würde mich über jegliche Kritik freuen, denn es macht keinen Sinn mit einer fehlerhaften Basis eine Datenbankanwendung zu erstellen.

Gruß und Danke schon mal*wink.gif*

:)

 

Mit "Ausgeliehen" kann ich nichts anfangen. Ansonsten würde ich Film und Person nur über eine Verknüpfungstabelle zusammenbringen. Die Funktion (Schauspieler, Regisseur, Produzent, Beleuchter, ...) würde ich aus einer solchen Tabelle als weiteren Fremdschlüssel in die Verknüpfung einbringen.

Da wäre man variabler. Auch würden sich Abfragen vereinfachen, wenn man wissen will, wer alles in einem Film mitgewirkt hat bzw. auch, was das filmische Lebenswerk einer Person ist.

 

"Ausgeliehen" behinhaltet Filme, die ich zur Zeit an Freunde ausgeliehen habe. Daher auch die Spalten "Regisseur", "Schauspieler", und "Freund".
Denn keiner meiner Freunde kann ein Schauspieler in einem Film sein sowie ein Schauspieler niemals Filme von mir ausgeliehen bekommt.

Habe gemerkt, dass ich ein paar Tabellen vergessen habe...

Gruß

 

Servus bitterlemoncola,
auf den ersten Blick ist mal empfehlenswert,
1. die Namen von in Beziehung stehenden Schlüsselfeldern identisch zu bezeichnen.
2. Beziehungen von Primärschlüsseln zu Primärschlüsseln sind falsch m.E.n.
Eine Person darf keine Funktion enthalten, denn sie kann (die Realität sagt das)
in einem Film Schauspieler, in einem anderen Kameramann und in einem 3. z.B.
Komponist sein.

Wenn Du etwas ausleihst, dann willst Du bestimmt nicht nur den Namen wissen wollen, sondern Titel, Zeitraum u.v.m.
Möglicherweise auch noch ein Abrechnungswesen...etc.

Schlussendlich solltest Du möglichst keine Leerzeichen in den TabellenNamen,
Feldnamen usw. benutzen. Ebenso auch keine sonstigen Sonderzeichen.

Das nur mal grob überflogen gesagt.

 

Welche Beziehungen meinst du? Ich kann nur Beziehungen zu einem Teil eines zusammengesetzten Primärschlüssel erkennen und das ist zulässig. Natürlich könnte man in m:n Tabellen auch eine ID als Primärschlüssel einführen und dann eine unique Schlüssel mit den beiden Fremdschlüssel Feldern erstellen, muß man aber nicht.

Ulrich

 

Hallo,
vielen Dank für Eure Mühe!

OK, das werde ich noch nachholen

Wie knobbi38 schon erwähnte, wollte ich damit eine n:m Beziehung auflösen und habe den Primärschlüssel aus den zwei Fremdschlüsseln zusammengefügt.

OK, das mit den Sonderzeichen werde ich noch abändern*wink.gif*

Leider verstehe ich noch nicht wirklich wie ich das Problem mit den Personen umsetzen soll.

 

Servus,
@knobbi38: Nun gehts wohl um des Kaiser's Bart?
Technisch gesehen ist ja fast alles zulässig in Access.
Sonderzeichen in Objekt- bzw. Feldnamen.
Beliebige Benamung von PS-Feldern, beliebig andere Benamung von
ihnen zugeordneten FS-Feldern.
Doppelte Feldnamen in verschiedenen Tabellen.
Zusammengesetzte PS schon im ersten Tabellenmodell.
Anwendung von verschiedenen Beziehungsmethoden schon beim Erstellen
des Tabellenmodells.
Beliebige Benamung von Tabellen, Abfragen, Modulen, Berichten etc.

All das sollte man beim Erstellen eines DB-Modells bedenken und vermeiden. Aus dieser meiner Sicht heraus ist es falsch, einem Beginner
so etwas von vornherein zu zugestehen, obwohl es möglich ist.
Um die Gesamtproblematik zu begreifen, sind hier Zwischentabellen sehr hilfreich und übersichtliche Hilfen beim
"ERDENKEN" des Tabellenmodells.
Die ausserordentliche Flexibilität von Access und VBA sollte erst eingesetzt werden, wenn man
mal was flicken muss, weil man die DB nicht komplett von vorne neu erstellen kann. Dabei ist dann natürlich auch immer mehr beim "Datenschaufeln" die Kenntnis der SQL-Dialekte von Vorteil.

@bitterlemoncola: Was verstehst Du bei den Personen nicht, abgesehen von meiner Erklärung?

 

Hallo bitterlemoncola,

Ohrkester hat nicht ganz unrecht mit dem Primärschlüssel in m:n Tabellen. Es ist zwar zulässig, mit zusammengesetzen Primärschlüsseln zu arbeiten, aber sicherlich einfacher (gerade für Anfänger), in m:n Tabellen ein Feld ID Typ:Autowert als Primärschlüssel zu verwenden und dann für die beiden Fremschlüsselfelder einen Unique-Index zu erstellen.

Gruß Ulrich

 

OK, ich habe jetzt mal ein paar Anpassungen durchgeführt. Wie mach ich das mit den Unique-Indizes und was bewirkt das?

 

Hallo,

einen zusammengesetzten Index anlegen:
Siehe https://support.office.com/de-de/art...a-38c6c4f1a0ce
oder
https://www.ardiman.de/datenbanken/g...x_anlegen.html

Ulrich

 

Um das mit den Personen zu erklären:
Die Funktionen sind für spätere Abfragen da. Wenn ich z.B. in einem Formular aus verschiedenen Schauspielern auswählen möchte, sollen mir auch wirklich nur Schauspieler und keine "Nur-Regisseure" zur Wahl stehen.
Eine Person kann entweder Schauspieler, Regisseur, Freund oder Schauspieler + Regisseur sein.

 

Hallo,
ich würde das doch etwas anders aufbauen.
Die Personenfunktionen werden als n:m Tabelle erfasst.
Und zu den Funktionen gehört auch der Freund.
Das ist deutlich flexibler.
Bild der Beziehungen anbei, auch den Entwurf der DB habe ich mal angehängt. Ich bin auch kein Freund von zusammengesetzten Primärschlüsseln, die Beziehungen sind daher mit Autowerten und Zahl (Long) angelegt.
Außerdem habe ich referentielle Integrität eingestellt, welche unerlässlich ist.
In der Tabelle "tbl_FilmGenre" habe ich mal einen zusammengesetzten eindeutigen Index angelegt, damit Du siehst, wie das geht.

Ich erhebe aber keinen Anspruch auf Vollständigkeit und Fehlerfreiheit.

 

Hallo und Danke gpswanderer
Das ist interessant. Das heißt die Freunde haben in der Tabelle "tblFilmFunktionPers" ein Leerfeld bei der Spalte "Film"?

Allerdings interessiert mich/uns bei "tblAusleihen" nur das Datum des Ausleihens, falls es im Moment ausgeliehen ist. D.h. "ZurückAm" lasse ich weg.

Das Datum zur Bewertung hinzuzufügen finde ich sehr sinnvoll, da sich Meinungen ändern können.

 

Hallo,

Ja, das hatte ich ursprünglich gedacht. Habe aber meine Meinung inzwischen geändert. Lege in der Personentabelle ein Ja/Nein Feld an "Freund", das ist besser, ausreichend und einfacher. Die anderen Funktionen werden aber über die n:m Tabelle zugeordnet.

 

Vielen Dank für eure bisherige Hilfe! Das ist nun meine finale Version bevor ich mit Abfragen und Formularen weitermache. Vielleicht ändert sich ja noch etwas, aber momentan bin ich zufrieden*wink.gif*