In my previous article, I talked about why it is important to promote the value of good data management practices in our organizations, who our target audience is, and what our message should be. Now, I′d like to discuss how our recommendations should be implemented, and when and where we can get our message out. 数据挖掘实验室
First, let′s talk about how we implement our six core concepts (application independence, data integrity, data security, performance, ease of use, and low cost of maintenance) in our databases. Here are a few of our recommended database best practices:
- We use a normalized logical design (and base table structure) to promote application independence and data extensibility, but
- At the same time, we use views to create non-normalized, application-specific, object-friendly physical views of data. We should not force developers to work at the logical level, with the normalized base tables. This is what gives rise to what application developers refer to as "the object-relational impedance mismatch," and causes databases (and DBAs) to be regarded as "nonagile." If you haven′t done so already, you should read Scott Ambler′s book "Agile Database Techniques," a 340-page chronicle of the headaches and frustrations of working with normalized base tables. However, the book is at fault in not mentioning views or any other form of entity abstraction. Therefore, I would like to humbly suggest that you read my online article "Views: the Key to Database Agility;" it′s my response to the concerns expressed in Ambler′s book.
- We try to abstract and encapsulate database structure and functionality as much as possible using views (which help mask the complexity of normalized database structures and improve performance); our fundamental stored procedures (FSPs), which encapsulate much of the work of database updating (including transaction management, concurrency checking, error detection and reporting, supertype/subtype management, and even multi-language text support); our data access component (DAC), which in turn encapsulates much of the work of using FSPs and other stored procedures (it automatically uses our FSPs to handle dataset and datatable updates, manages the timestamp values used for concurrency checking, and supports typed datasets and parameterized SQL queries); triggers (which are used for complex and cross-database RI and data-specific business logic); user-defined data types (UDTs), which can be used to create complex data structures that map more easily to application objects; and user-defined functions (UDFs), which help manage UDTs and can also be used to perform tasks such as giving developers a relational view of XML data and an XML view of relational data. These features help safeguard our data while making it easier for developers to use our databases.
- We enforce data security and integrity at the database level, not in the application. This enables easy reuse of data, while saving developers the work of having to write and test code-level constraints in every application that uses a given piece of data.
- We try to keep database processing on the database server as much as possible for maximum performance, ease of maintenance, security, scalability, reduced network traffic and lower cost of development. For example, we recommend that all complex SQL queries be implemented as stored procedures in the database, instead of being embedded in the application code, and that queries use server-side rather than client-side cursors.
Just as important as these best practices are the methods used to put them into practice. All too often, we try to impose our data standards on developers and project teams, with no regard for their impact on development schedules, project costs, business value or ROI. In our group, we′ve learned to take the following approach to implementing our best practices:
- Automate database development processes as much as possible. In our group, we can go from a logical data model to a fully implemented database in less than an hour. We′ve developed tools and macros that enable us to automatically generate database tables, indexes, triggers, views, constraints, and our fundamental stored procedures all to our standards. No manual modifications are required. Not only does this speed up development time, but it also eliminates coding errors, and enables us to respond more quickly - with more agility - to changes in business and application requirements.
- Promote database standards and best practices as recommendations, rather than requirements, and be prepared to always give reasons for these recommendations. Database standards should never be a threat to the success of a project. If they are, you may have to find more effective or more creative ways of implementing them. You may even have to relax them on occasion. All you can do, on any given project, is to implement the best-quality solution possible given the constraints of the project, learn what you can from the experience, and apply what you′ve learned to future projects. Success is rarely absolute; failure, unfortunately, almost always is.
- One way that we promote our database standards is to link them to various support levels. At the highest level of support, we guarantee all aspects of data integrity and performance, in exchange for being allowed to design and build the database according to our standards. At lower levels of support, development teams can take on the responsibility - and risk - of coding and maintaining their own database update procedures and using their own data access layer.
- Establish project needs and support requirements up front to reduce misunderstandings about what the project team wants (and doesn′t want) from the data group. We created a survey that covers which of our database standards the project team is willing to adhere to; which of our services (such as gathering the business data requirements, conceptual design, process modeling, helping to develop the data layer, migrating data from existing databases and so on) will be needed for the project; what types of data (relational, XML, object, etc.) will be involved; and the level of support that will be required from our group during development and after implementation. This checklist becomes our contract with the project team.
- Communicate constantly with the project team both during development and after implementation to detect and resolve any issues as early as possible. This includes reviewing data access code, stored procedures, views and database functions written by the development team; this will help reveal any problems with the database design (or their understanding of it).
Our approach to doing data work in the context of application development projects can be summarized as follows:
- Make using the database as quick, easy, and painless as possible.
- Stay business-focused; the objective is meeting the business requirements and deriving the maximum business value from the project. It doesn′t help to win the battles and lose the war.
- Adopt a "can do" attitude, and be as helpful as possible. If you′re always telling people "no," don′t be surprised when they choose to ignore you and go behind your back. People need to do whatever they need to do; if you don′t help them succeed, they may help you fail.
- Accept any defeats and failures encountered during a project as lessons learned, that can be applied to future projects. You don′t have to win every battle. If problems arise from having done things wrong, you can always point to them later as reasons for doing things right in the future.
- Communicate with people on their level, and in their terms. As I′ve pointed out, it′s better to talk with businesspeople in terms of business needs and ROI and with developers in terms of object orientation and ease of development. Nobody is interested in relational database theory.
- Concentrate on solving other people′s problems, not your own. Nobody is interested in your problems.
Aside from demonstrating our competence, our professionalism, and our commitment to helping our colleagues and stakeholders succeed, day in and day out, there are a number of other forums we can use to get our message out and educate people in the business and developer communities about the benefits of good data management practices:
- Classes, such as the database classes we teach at Paccar. By attending these classes, developers and project managers learn how to develop database applications faster and more effectively by taking advantage of the functionality we build into our databases. They learn how to use views and data access objects, code effective SQL and solve performance problems. The classes also provide a forum where we can explain the advantages of our data standards to project teams and to the company, and where developers and project managers can talk to us about problems they′re having and suggest areas of improvement.
- Blogs are another good forum for making our ideas known. I have a blog on our internal blog site called "Data-Based," and make occasional contributions to other blogs as well.
- There are a number of other good online forums as well, such as ComputerWorld, TDAN (The Data Administration Newsletter), and DM Review. My best advice for contributing to blogs, discussion groups and other online forums: stay out of arguments! State your opinions as clearly and as gently as possible, then move on. Don′t get embroiled in holy wars; nobody ever learns anything from them.
- Meetings can be a good forum, as long as you remember that the purpose of meetings is to contribute solutions, not just opinions. If you can become respected as a provider of quality solutions, not just a spouter of dogmatic opinions, people will listen to what you have to say.
- Lastly, don′t forget the value of one-on-one conversation. Take advantage of any opportunity to talk with developers, project managers, business users and management; listen carefully, and understand their concerns and their needs. This will open up new opportunities for making data management relevant to your organization and for increasing the regard in which our work is held.
To sum up, we need to understand who our stakeholders are, and what their needs and concerns are. We need to develop a set of clear, concise, practical, business-focused standards for doing the best possible work in the best possible way. And we need to teach and implement those standards in a way that provides maximum value to our stakeholders and earns their respect for us as facilitators, contributors and solution providers. As they used to say in the ′60s, "lead, follow or get out of the way." The choice is ours. 数据挖掘实验室
