Catálogo de publicaciones - libros

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.

A relational database adheres to a greater or lesser extent to the 12 rules of an RDBMS drawn up by Codd. In developing a relational system, you use the process of normalization, which is verifying the relational nature of your data organization against the various degrees of normal form. We covered 1NF, 2NF, 3NF, and BCNF and showed how they help you verify the following:

You then looked at the power and risks of denormalization, the process by which you break the rules of normalization in order to improve application performance. This is something that requires experience in order to tailor its use appropriately for any given application, but it can prove invaluable in enhancing the user experience of your application.

In this chapter we introduced relational modeling terminology and the concepts used every day to build Conceptual, Logical, and Physical data models. Specifically, you looked at the following:

We covered some alternatives in data modeling graphic syntax languages, focusing on the IDEF1X notation we’ll use in all the models throughout this book. Many of the concepts that the symbols represent are the same. Although some symbols are unique to one style or another, the higher-level concepts are largely independent of the graphic symbol sets used in these languages. The symbols cover notations for many different aspects of set members and their attributes, which can be read as sentences when you know what the symbols represent. The symbols cover meaning for the following:

In the next chapter, we’ll cover how UML, an object-oriented modeling syntax with its own distinctive modeling symbols, relates to relational modeling.

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 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.

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 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 saw the iterative nature of the process by which you’ve drawn up this model. You poured over each entity and its attributes to ensure that the definitions and relationships you have are accurate and make sense. The key steps in the creation of a Logical model are as follows:

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.