Ho trovato il modo migliore per iniziare sempre abbozzando un modello di dominio logico. Questo tipo di modello è indipendente dall'implementazione e si concentra sull'identificazione dei concetti chiave e delle loro relazioni. "Domain Driven Design" di Eric Evan è un ottimo riferimento per questo.
Il prossimo passo è progettare il modello di implementazione. Per questo, una buona regola è quella di determinare l'interfaccia che i client useranno per interagire con il tuo modello e iniziare da lì.
Ad esempio, se si sta costruendo un nuovo sistema OLTP utilizzando un framework basato su ORM (come Rails o Grails), i servizi e i controller interagiranno con il modello utilizzando l'interfaccia ORM. Per questo motivo, vorrai iniziare con la progettazione del modello di oggetto e lasciare che il modello di dati segua da quello. I framework ORM hanno ciascuno i propri modi preferiti per modellare i concetti orientati agli oggetti a livello di database e seguendo il modo preferito dal framework saranno più veloci e meno bug. Se si progetta il modello di dati per primo e poi si esegue il mapping al framework ORM, si può finire per dover passare da un anello all'altro per farlo funzionare correttamente.
D'altro canto, se stai costruendo un sistema OLAP supportato da un data warehouse in stile Kimball, probabilmente ci sarà una varietà di client che accedono ad esso, come app personalizzate e strumenti di BI. Un'interfaccia comune da utilizzare in questo caso è l'accesso diretto a SQL. Offre una grande flessibilità e consente ai clienti di sfruttare tutta la potenza del database. Quindi, in questo caso, prima dovresti concentrarti sulla progettazione del database.