最好的开始方式是找出"用户故事"(或"用例" - 但"故事"方法往往真的很有效,并开始将股东拖入共享的讲故事......! - ); 最重要的是,将数据库模式设计为可以找到的最佳规范化思想,以满足用户故事的所有数据层需求.
第三,您可以在模式顶部绘制视图等图层; 第四,可选地,可能存在于DB中的触发器和存储过程,以确保更高层的一致性和易用性(但是,无论DBA如何强烈推动您使用,都不接受他们保证他们是必须:它们不是 - 如果您的存储层在规范化方面设计得很好并且可能在顶层有用的视图,非存储层功能CAN总是驻留在其他地方,这是一个方便和性能的问题,而不是逻辑一致性,完整性,正确).
我认为应该追求业务层和用户体验层.我意识到这是一个有争议的立场,但我的观点是,用户故事(以及随之而来的隐含的业务规则)已经告诉你很多关于业务和用户层的事情 - 所以,"确定下来"(相对来说 - - 敏捷和"拥抱变化!"应该始终规则;-)数据存储层是下一个业务的顺序,精炼("向下钻取")更高层可以而且应该在之后.