Physical Data Models
Physical data models represent the design of data while also taking into account both the constraints and facilities of a particular database management system. Generally, it is taken from a logical data model. Although it can also be engineered in reverse from a particular database implementation.
All database artifacts that are needed to create relationships will be included on a physical data model. These include linking tables, indexes, constraint definitions, and partitioned clusters. The model can generally be used as a calculation device for figuring storage estimates. Storage allocation details for a particular system might be included. Physical data modeling is also referred to as database design.
Recent years have seen the spread of agile methodologies – a whole new approach to database design. The concept of evolutionary design is key in these new demands. When you’re working on a project from an agile standpoint, the assumption from the outset is that you will not be able to fix the system’s requirements upfront. So it is not practical to have a detailed design process at the very beginning of the project. Instead, the system’s design is expected to evolve through the software’s iterations. These new agile techniques, which have come to the forefront in methodologies such as XP (extreme programming), have been proven to be incredibly practical when it comes to database design.
Agile methods are distinguished by their flexibility and eagerness to adapt. In contrast to the “waterfall approach” (in which techniques and rules are learned and signed off on early in the design process), agile methods are not driven by advanced plans.
But what is wrong with the waterfall approach? After all, isn’t this the way most of us learn? Sure, but we want a system that is flexible and ready to adapt to change. The waterfall approach tries to eliminate changes in the beginning by doing most of the work upfront. If any changes need to be made once that work is done, then major problems can occur.
Agile methods, then, are more reliable, in that they have a more open approach to change. In fact, they are based on the concept that change is inevitable and that changes will occur throughout the process of development. Of course it is essential that changes be monitored and controlled, but agile methods differ from the waterfall approach in that they actually encourage change.
The reasoning behind this is twofold. First, it provides a more dynamic model for businesses that constantly have to shift their requirements in order to keep up with the competition that the market poses. Secondly, many projects these days are inherently unstable when it comes to systems requirements, so it is best to design a system that incorporates the possibility of change into its components.
What is thus needed for a successful database design is to completely shift one’s attitude, one’s way of thinking about the design process. Instead of viewing it as merely a phase, one that is to be completed before construction begins, it should be viewed as a constant process that is interwoven with testing, construction, and delivery.
This is the main thing that distinguishes evolutionary design from planned design. Agile methods have come up with ways to allow evolutionary design to function in a manner that is controlled, rather than chaotic. Iterative development is key to this approach. It involves the running of the complete life cycle of the software several times throughout the project’s life span. In each iteration, the complete life cycle is run through by the agile process. The iteration is completed with the working code for a subset of the final product’s requirements.
These techniques have garnered widespread interest and are widely used. Yet the question remains: can evolutionary design function for databases? The answer is yes. One such project, Atlas, involved nearly one hundred individuals spread over multiple sites all over the world, more than two hundred tables, and nearly half a million code lines. It took about a year and a half of initial development and continues to evolve to this day. At the beginning, month-long iterations were used, but later, two week iterations proved to be more effective.
The techniques used in the Atlas project included the close collaboration of DBAs with developers, frequent integration into a shared master by developers, automated refactorings, automatically updated database developers, the successful usage of schema and test data, and the clear separation of database access code. On smaller projects, one of the Atlas analysts concluded, a full-time DBA is not even needed. Instead, a developer with interest in DBA issues can do the job part-time.
Author Description
