One important facet of software design is the cardinality between items in your system design. As an example, consider a simple credit card based design from telecommunications: Given this design, you can explore many boundary conditions with your business partners. Can you have a customer without services? Can you have billing information without an account? How about the other way? I'm diagramed this as having multiple BillingInfo entities. Should they allow overlap? How about one time payments? Refunds and chargeback processing? Getting into the details of how the business works will provide you a lot of leading conversations as you develop your system, but I want to focus just the one relationship in dark black above, specifically the qualitative dimensions of the 0 or more accounts. If you think about a mass consumer product, you will have a fairly low cardinality of accounts. A wireless customer may have a family plan with multiple phones,...