Catálogo de publicaciones - libros

This chapter covered the best practices you’ll need in case you have to leap straight into a Physical model-only design. This is often the case when you have insufficient project time or money to follow a rigorous Conceptual/Logical/Physical model designing methodology. You looked at what you can do to improve upon existing Physical model designs, prior to their implementation, in order to ensure that the application being developed not only runs smoothly but also has some room for expansion to meet future requirements. In particular, this chapter noted the need to do the following:

It bears repeating that these steps are to be taken only when time or budget constraints don’t allow for a more rigorous analysis. To thoroughly understand the full set of options for Physical model design implementation, you should always carry out the Conceptual/ Logical/Physical model design methodology outlined earlier in this book. Don’t rush straight to the Physical model design; this approach is always to be a “make-do” approach to data modeling.

This chapter covered the best practices you’ll need in case you have to leap straight into a Physical model-only design. This is often the case when you have insufficient project time or money to follow a rigorous Conceptual/Logical/Physical model designing methodology. You looked at what you can do to improve upon existing Physical model designs, prior to their implementation, in order to ensure that the application being developed not only runs smoothly but also has some room for expansion to meet future requirements. In particular, this chapter noted the need to do the following:

It bears repeating that these steps are to be taken only when time or budget constraints don’t allow for a more rigorous analysis. To thoroughly understand the full set of options for Physical model design implementation, you should always carry out the Conceptual/ Logical/Physical model design methodology outlined earlier in this book. Don’t rush straight to the Physical model design; this approach is always to be a “make-do” approach to data modeling.

In this chapter you considered the nature of reverse engineering. It’s the process by which you extract information from existing systems in order to work backward and derive a Physical model and work further back to a Logical model, if possible. The nuances of different database systems and development platforms often make this process a difficult task. You’ve seen how modeling tools such as ERwin can help in taking snapshots of existing databases and in producing Physical models from which you can begin to verify table and column names. While you can generally document table and column names through using such tools, or by reviewing database creation scripts, it’s the relationships between tables that are the most difficult to verify. This is where screen analysis, documentation, employee know-how, training, and other “soft” skills can prove invaluable in figuring out exactly how data is being used by the system in question. Only by learning as much as possible about using the application can you determine how the existing data structures are being used and how this compares with the original design.

Reverse engineering has an important role to play in helping improve the efficiency of enterprise applications (by determining faults in the design), aiding integration of existing systems (by pinpointing table and column definitions and relationships between such tables), and allowing comparisons of existing systems with potential new system solutions.

Data models form the foundation documentation for many types of enterprise analysis, such as database development, reverse engineering, or application integration projects. Such models can be enhanced through judicious use of text, images, color, and formatting in order to help customers focus more easily on important features. This makes impact analysis, data element usage, and changes to the model, through the various iterations that will inevitably take place, more immediately obvious. Without a simple means of keeping the whole development team, as well as the clients, aware of the current version of the model or any modifications that are required, confusion will reign.

Models also have to have a reliable publication method tailored to any security and access requirements. This may involve models being published on a company intranet or the creation of a central model repository. Creating a repository makes for improved reuse of existing models and, as a result, more efficient management of data elements (and their subsequent growth) within a given enterprise.

In this chapter, you looked at data quality issues and the analysis that can help identify and address them. We discussed suggestions for analysis that should be addressed up front in the Logical modeling process. Unfortunately, in our experience modeling software doesn’t store this information (although some gives you options of creating user-defined elements to deal with these issues). When creating mapping, documentation becomes more common; the tools will probably adapt to store this information and provide the capability to track what you’ve discovered for each entity, table, attribute, and column. We discussed documenting the following:

You also looked at creating mappings, which are documents that help you manage the relationships between your models and other documentation, organizations, and requirements. Keeping this type of information in mapping documents is a stopgap measure that you’ll have to continue until metadata management becomes an integral part of your enterprise. In discussing mapping documents, you looked at many different examples, including the following:

In this chapter you considered the nature of metadata, which is becoming ever more crucial. If you take the example of an order entry system, you now know that metadata isn’t the orders in the order entry system but rather the following:

The importance of metadata is its ability to help you manage staff, clients, and resources. You need to serve everyone better by providing cost-effective, high-quality tools and the faster delivery of your results to your customers. To do that, you need to be able to use the knowledge of your enterprise’s successes, failures, existing solutions, and abandoned efforts to make intelligent decisions. In short, you need to recognize the importance of your ability to manage your data’s shared environment.

In this chapter you considered the nature of metadata, which is becoming ever more crucial. If you take the example of an order entry system, you now know that metadata isn’t the orders in the order entry system but rather the following:

The importance of metadata is its ability to help you manage staff, clients, and resources. You need to serve everyone better by providing cost-effective, high-quality tools and the faster delivery of your results to your customers. To do that, you need to be able to use the knowledge of your enterprise’s successes, failures, existing solutions, and abandoned efforts to make intelligent decisions. In short, you need to recognize the importance of your ability to manage your data’s shared environment.