Questo è il cuore di qualsiasi applicativo. Noi chiamiamo regole del compito,ma sempre se lo applicativo non è usato da un compito(vedi un applicativo potrebbe essere quello che manovra un vs DVD) così usa le regole per definire ciò che rappresenta dati accetabili e non.
Un banale esempio può essere richiedere tutti i numeri di telefono appartenenti ad una associata area .Finchè un DB non ha problemi a memorizzare un codice in una area bianca, il vs compito può essere prendere contatto con un cliente tramite il numero telefonico. Ciò è (possibile) perchè questa è una regola del compito e non un DB distribuito.
Le regole del compito sono anche usate per rappresentare il processo del compito. Per esempio, puo accadere che offriate ad un cliente un articolo gartis dopo che ha comprato un certo numero di articoli. Il vs compito oggetto per ricordare gli acquisti deve contenere il codice per aggiornare liberamente lo stato del cliente quando ha raggiunto lo obiettivo che si era prefissato con gli acquisti.
Una buona regola pratica per progettare è che si definisca un separato bizobj ( abbreviazione di business object) per ciascuna tabella in ciascun DB. Poichè idealmente una tabella di DB rappresenta una singola entità ci dovrebbe essere una singola classe bizobj per manovrare la validazione dei typi di entità. Ci sono molte eccezioni a queste regole, per contro, ma queste sono di solito argomento della scelta dello argomento di DB. Se inserite le nozioni di una bizobj per una entità, il vs codice sarà molto più pulito.