Considero 1: N relazioni un'ottimizzazione, e, sai che dicono: quell'ottimizzazione prematura è un male, un cattivo odore di codice, ecc ...
Quindi, la mia raccomandazione è quella di utilizzare le relazioni N: M tra tutte le entità fino a quando non si ha una chiara comprensione di entrambi:
- il modello di business (come sappiamo, in continua evoluzione) e
- i tuoi limiti di rendimento effettivi in condizioni reali.
Codice / dati non ottimizzati sono meno fragili da cambiare, più facili da mantenere. (Pensa a cosa succederà quando due studios collaboreranno a un film?)
In tema di relazioni 1: N:
Per prima cosa, consiglierei di utilizzare uno strumento standard del settore per la creazione e la condivisione dei diagrammi.
In secondo luogo, dovresti fare in modo che l'ordine di lettura delle relazioni segua le frecce, oppure avere un ordine di lettura separato per le relazioni indipendenti dalla direzione del 1: N. Considera la relazione "Proprio" come la stai mostrando. L'ho letto come N Movie (s) Own 1 Studio, ma non è corretto in quanto 1 Studio Owns N Movies. Come ho detto, puoi correggerlo usando Is-Owned-By invece di Own (s), oppure, avendo Own (s) indica che l'oggetto / oggetto deve essere letto al contrario.
Inoltre, potrei aggiungere che potresti avere più relazioni del necessario, quindi dovresti cercare di approfondire ulteriormente i requisiti del tuo business / dominio. "Own" è una duplicazione di "Shot In", e, anche Connected To è forse superfluo, come si potrebbe dedurre che un attore / attrice è stato associato a uno studio dai film che hanno realizzato, in quanto i film sono associati agli studi. / p>
La materializzazione delle relazioni derivate rientra anche nella categoria di ottimizzazione (prematura). Essi comportano un sovraccarico di programmazione, aumentano i requisiti di coerenza e rendono più difficile il mantenimento del codice a lungo termine.
