The traditional wisdom for performing logical database design can be found in any DBMS textbook. <\/p>\n
Basically, the process is:<\/p>\n\t
Form an entity-relationship (E-R) model of your data<\/em><\/p>\n When you are satisfied with your E-R model, push a button<\/em><\/p>\n Which executes an E-R to third normal form (3NF) translation algorithm<\/em><\/p>\n Create the 3NF schema and code the application logic for this schema<\/em><\/p>\n \u00a0When business conditions change (and they do at least once a quarter), then<\/em><\/p>\n Update the E-R model<\/em><\/p>\n Update the schema<\/em><\/p>\n Evolve the data to the new schema<\/em><\/p>\n Do application maintenance<\/em><\/p>\n\t Applying these principles will guarantee the schema is always in 3NF and is thereby a \u201cgood\u201d schema. In contrast, extensive application maintenance may be required. Also, repeated patching of application code may cause the application to \u201cdecay,\u201d i.e., become more convoluted and harder to maintain. In other words, the traditional wisdom will ensure no database decay but perhaps large application decay.<\/p>\n In the real world, NO SERIOUS DEVELOPERS use the traditional wisdom. Some may use it for initial development, but none use it for evolution. Specifically, developers are almost always interested in minimizing application maintenance, and will endure large amounts of data decay to achieve this goal. To minimize application maintenance, the goal is to change the schema as little as possible (preferably not at all) by introducing data redundancy. Hence, data is allowed to decay to minimize application decay. Sooner or later applications (or the database) become so degraded that a complete project re-implementation is required.<\/p>\n The thesis of this project is that one should perform co-evolution<\/strong> of code and data. Specifically, one should have a holistic metric that minimizes the composition of data and code decay. Sometimes one should focus on application decay and sometimes on data decay. We have obtained six years of application and data evolution from B2W, a very large Brazilian e-tailer. Our data encompasses about 70 iterations of their checkout software. Our initial analysis justifies our thesis, because B2W appears to sometimes evolve application code, sometimes the DBMS schema and sometimes both.<\/p>\n We have mostly built an evolution tool that can quantify the decay in either dimension that any modification will entail. On top of this tool, we hope to build a machine-learning-based recommendation engine that will suggest which evolution tactic to use.<\/p>\n\t Citations<\/strong><\/p>\n Michael L. Brodie, Michael Stonebraker, Ricardo Mayerhofer and Jialing Pei. 2018. The Case for the Co-evolution of Applications and Data, North East Database Day 2018<\/a> (NEDS 2018), January 19, 2018.<\/p>\n Michael Stonebraker, Dong Deng and Michael L. Brodie. 2017. Application-Database Co-Evolution: A New Design and Development Paradigm<\/a>. New England Database Day, (pp. 1\u20133), January 2017.<\/p>\n