Ci sono molte scuole di pensiero riguardo a quale logica & regole che puoi inserire nel database e questo varierà in qualche modo sulle capacità e sul tipo del database.
Tuttavia, una cosa è certa: se non si inserisce una sufficiente logica di dominio nel database per conservare l'integrità dei dati, è necessario avvolgere il database in un servizio e tutte le applicazioni accedono al servizio anziché database direttamente.
Sono d'accordo con Wikipedia sul fatto che le entità, le loro relazioni e requisiti sulla loro integrità referenziale, così come altri vincoli, fanno parte della logica aziendale / di dominio - eppure appartengono codificati nel database (se, per esempio, relazionali), o in un servizio che avvolge il database, ad esempio, se NoSQL. Non penso che tu possa veramente separare dati e amp; persistenza dalla logica aziendale / di dominio, poiché lo schema dei dati è semplicemente è logico per e del dominio aziendale. (Non penso che l'uso di xml risolverà fondamentalmente qualsiasi cosa a questo proposito - sposta semplicemente il problema su un'altra tecnologia.)
Personalmente ritengo che le relazioni one-to-many siano a volte esattamente ciò di cui abbiamo bisogno, ma altre volte possono essere pensate come un'ottimizzazione su relazioni molti-a-molti e, in quanto tale, può essere prematura e (business / dominio) limitando l'ottimizzazione.
Ad esempio, progettare il modello di dati per avere un ufficio per istruttore / professore o un reparto per istruttore, potrebbe funzionare a lungo, quindi cadere sul suo volto quando si incontra uno scenario raro che insegna un istruttore / professore in due (o più) reparti.
Altri esempi di ottimizzazione prematura nello schema sono la creazione di identità separate per l'entità Insegnante e un'entità Studente. Ora uno studente che insegna o un insegnante che segue un corso deve avere due identità nel sistema. Preferita sarebbe un'entità Person che può svolgere più ruoli nel tempo. (Questo vale anche per l'utilizzo di relazioni molti-a-molti su uno-a-molti.)