- Shopping Bag ( 0 items )
Other sellers (Paperback)
-
All (12) from $22.52
-
New (8) from $39.95
-
Used (4) from $22.52
More About This Textbook
Overview
Data Architecture: From Zen to Reality
Find proven methods and technologies to solve the complex issues of dealing with data
I am extremely thrilled that Mr. Tupper has decided to write this book. This book would fill a void in knowledge and know-how in the area of data administration and architecture. Mr. Tupper built over the years an impressive expertise and authority on the subject of enterprise data architecture.
Daniel Fitzpatrick, Principal Consultant, Nakama Consulting Group
I see a wealth of information ranging from technical reference information to higher level concepts and principles. Overall a very comprehensive guide where some sections can be read in a flowing manner to enhance understanding of the topic and other sections can be flipped to/from to provide greater detail and context.
Lynn Rivera, Consultant, LMR Consulting
Data is an expensive and expansive asset. Information capture has forced storage capacity from megabytes to terabytes, exabytes and, pretty soon, zetabytes of data. So the need for accessible storage space for this data is great. To make this huge amount of data usable and relevant, it needs to be organized effectively. Database Base Management Systems, such as Oracle, IBM’s DB2, and Microsoft SqlServer are used often, but these are being enhanced continuously and auxiliary tools are being developed every week; there needs to be a fundamental starting point for it all. That stating point is Data Architecture, the blueprint for organizing and structuring of information for services, service providers, and the consumers of that data.
Data Architecture: From Zen to Reality explains the principles underlying data architecture, how data evolves with organizations, and the challenges organizations face in structuring and managing their data. It also discusses proven methods and technologies to solve the complex issues dealing with data. The book uses a holistic approach to the field of data architecture by covering the various applied areas of data, including data modelling and data model management, data quality , data governance, enterprise information management, database design, data warehousing, and warehouse design. This book is a core resource for anyone emplacing, customizing or aligning data management systems, taking the Zen-like idea of data architecture to an attainable reality.
Charles D Tupper is the Assistant Director of Data Architecture at Boehringer-Ingelheim Pharmaceuticals. His previous experience has been in Telecommunications, Finance , Insurance, Manufacturing and Transportation. He has also worked as a consultant specializing in: Data Architectures, Data Modeling, Physical Model Translation, CASE design tools, CASE Model Management and Warehouse Modeling and Design. He has also provided project management, consulting, knowledge transfer, retooling consultation, Business Intelligence architecture, mentoring and training in current CASE design methods, and has published several articles in Data Base Programming and Design.
Editorial Reviews
From the Publisher
I am extremely thrilled that Mr. Tupper has decided to write this book. This book would fill a void in knowledge and know-how in the area of data administration and architecture. Mr. Tupper built over the years an impressive expertise and authority on the subject of enterprise data architecture.Daniel Fitzpatrick, Principal Consultant, Nakama Consulting Group
I see a wealth of information ranging from technical reference information to higher level concepts and principles. Overall a very comprehensive guide where some sections can be read in a flowing manner to enhance understanding of the topic and other sections can be flipped to/from to provide greater detail and context.
Lynn Rivera, Consultant, LMR Consulting
Product Details
Related Subjects
Read an Excerpt
Data Architecture
From Zen to RealityBy Charles D. Tupper
MORGAN KAUFMANN
Copyright © 2011 Elsevier Inc.All right reserved.
ISBN: 978-0-12-385127-7
Chapter One
UNDERSTANDING ARCHITECTURAL PRINCIPLESDefining Architecture ar·chi·tect (är'kitekt') n. (Abbr. arch., archt.)
1. One who designs and supervises the construction of buildings or other large structures.
2. One who plans or devises: The United States is considered to be the chief architect of the economic recovery of the Middle East.
The word "architect" is of Greek origin and is composed of two roots: arch and tect. Arch means "primary," "primitive," or "coming before," and tect means "make" or "come into being." Thus, when the two roots are combined to form the word "architectos," it can mean "coming before" + "come into being." Using these multiple meanings, we can figure out the definitions of architect and architecture. A good working definition of architecture would be "a primitive plan" or "a plan before construction." This definition captures the essence of it: Architecture is an analytical effort that is created prior to the occurrence of any real construction activity. It is the abstracted framework or outline that provides guidelines for the construction from the beginning to the end.
The discussion of architecture is interesting both from the point of its expansive concepts to its detailed specificity at the point of physical implementation. The following is an excerpt from an Information Architecture course (that ultimately never came to fruition) that speaks to the concept requirements:
The object of this course is to lead to an understanding and application of the principles of design—particularly architectural design. The fundamental purpose of architectural design is illuminated by the logic of the process of design: target, options, concepts, actions, and completion. Exploring the design process integrates both the physical and nonphysical requirements and influences; the measure of human processes and the collective events of many processes; the social and cultural influences operating in such processes; and the meaning of information extensions, directions, order, and closure. The importance of the relationship between human processes and the information environment is introduced with an emphasis upon construction of information models. Composition, especially the theory of wholes and parts, is examined in the light of structural reusability, continuity, and change—principles and conditions applicable either to a single business process or, in a much wider context, to the task of capturing an entire enterprise into its business environment.
Architecture is an ancient skill that has been practiced by visionaries since the prehominids decided to create and build shelters to cope (interface) with the chaotic life patterns of their natural world. A primitive designer probably had the same level of respect in his tribe as the shaman (if they were not one in the same). As humanity evolved, these special individuals carried forward the inherent principles or patterns that had proven successful in their evolution. Knowledge of structures and the patterns and mechanisms of building was accumulated and passed on—and on and on. This process of handing down skills and patterns hastened the development of communication.
What would happen if a primitive hut builder created a very radical design? Most likely, no one would accept the structure unless the designer communicated the advantages of the new design to the tribe. Additionally, when the primitive designer/ builder started his effort, he just had to create a few huts. As tribal growth occurred, there was much more work to design and lay out the groundwork for many huts and meeting places in addition to creating the huts.
These habitation structures had to be made to interface with and take advantage of the natural background and environment. The designer/builder's input to the site selection of camping grounds became critical. He became an integral asset to the tribe's survival. Just as the designer/builder had to keep learning to construct and maintain the structures out of local materials, he had to accumulate and retain the knowledge he had gained to be passed on to future primitive architects.
All along the way there was a continual implementation of what knowledge had been accumulated up to that point, and, more important, that knowledge was made public. It would not be kept private or restricted because the tribe's livelihood rested on the designer/builder's integrity. The design had to be understood and accepted by the entire tribe and had to be depended on for the tribe's survival. At each level appropriate knowledge was imparted to those concerned.
The individuals in the tribe were educated in the best techniques. This skill sharing allowed more growth and stability. Implementation had provided a new plateau to build on. As the tribes were educated, all of the members learned the skills necessary to build and keep the structure intact. Adaptations had to be made for the differences in environment. Some of the designs had to be ultimately flexible, while others had to be extremely stable and less flexible. Evolution of designs became more complex and more important to the survival of the whole tribe. The adaptability of the designs became an important feature of the designs and was therefore included in the saved information. These codes of construction and site selection became, after a millennium, building codes. This body of principles and logic used in designing for those codes would ultimately be called "architecture."
These individuals were astute at recognizing patterns in the real world around them. The strength of a wood and grass wattle hut wasn't as great as a cave's, but it served the same purpose: it kept them safe from the elements. After all, caves wouldn't be available everywhere they went, so such natural shelters were at a premium and often had to be competed for. Primitive hut designers realized that a hut could be built in the same design as a cave—tall in the middle and low at the sides for storage room and sleeping. Fire could be put at the mouth of the hut or outside with the heat reflected in, or, better yet, heated stones from the fire could be rolled into the hut to radiate warmth.
Situating the construction on a higher foundation isolated it from the ravages of heavy rains. Building it on the sheltered side of a hill kept cold winter blasts from chilling the inhabitants and also protected the fire. They also learned to build these shelters close to water and plentiful sources of game. In essence they adapted the housing to the environment, being respectful of it and integrating the structure with as many natural principles as possible.
Pattern recognition and pattern use are embedded in the principles of early humankind's existence, so the use of architectural principles is quite ancient. While it may have had different names through the ages, and its practitioners had different labels, the principles are the same: Plan before you build, and design with the user in mind. Integrate the plan into the environment where it will be situated.
These are the same principles that prompted the first individual of vision to step out of the cave and find a way to bring it along with him as he moved around to follow food. He had the responsibility of defining a working structure and method, showing and convincing others that the structure and method were feasible, and, finally, ensuring that the structure and method would be reusable in spite of the local environmental conditions. All of these concepts and his ability to perceive the patterns where they could best be implemented led to humankind's success and adaptation.
Obviously, we no longer have to worry about building safe habitats for cave dwellers. They already did that themselves. But we learned things along the way. And the primitive art and science of architecture evolved from simple tribal housing to providing a place for the very essence of cultures. Architecture and its principles have burgeoned and expanded to include all parts of the fabric of today's society.
Design Problems
The design process is unique, and it is easy to see that the goal of the design process is a solution. So this all seems very simple, but unfortunately, this is not the case. As we have already discussed, the real crux of design is defining the problem in the context in which it must be resolved. The contextual analysis is the hard part. In a true design process, the work area must first be defined and delineated from the context it is in. Whether it is a problem or opportunity, it needs to be separated from the matrix in which it exists. If the matrix or context is dynamic, however, the problem area is dynamic as well.
The design solution ends up being a balancing of the solution to the forces defining the problem's boundaries. It becomes an integral fit and, if constructed properly, will adjust to the context in which it exists. Take a simple problem like building a mechanical device. The forces in play are economy (or the cost of the components), performance (both of the product itself and of the ability to create the product), simplicity (the more components involved, the more complex the building process), and interfit (assembling the components to create the product).
Material handling studies indicate that the fewer the types of material used, the faster assembly will be, so simplicity is important. This will conflict with the performance force because we know that using the best material for each part will make the product last longer. The performance may affect the interfit force vector, since the materials chosen for the best performance may require more effort to assemble than simpler, less functional materials. All of these force vectors affect economy because they all impact the price of the item in some way. It is the balancing of these forces that determines the solution. Figure 1.1 shows how the resolution can be reached. By assigning a positive or negative quality to the interaction among these forces, we can come up with a simple solution depending on the product's purpose.
We have chosen economy as our driving force, so we can see that a positive relationship exists between simplicity and economy. Based on this, we can apply whatever performance and complexity choices we want as long as they remain in that quadrant. If assembly was primary and simplicity was secondary, then balancing would be in that quadrant, with the resulting solution not being as economical as might be desired.
While this is an extremely simple visual display of a complex set of interactions, in the end it is the balancing of those dynamic forces at work in the context of the problem/solution area that will provide the optimum solution. Simply put, the problem area cannot be removed from its context because it is a part of the context of the whole and is defined by the dynamic forces working on it in that context. How, then, are problems addressed in an architectural manner? The answer is, by using patterns and pattern interactions.
(Continues...)
Table of Contents
Preface
Foreword
Section One: The Principles
1: Understanding Architectural Principles
2: Enterprise Architecture Frameworks and Methodologies
3. Enterprise Level Data Architecture Practices
4: Understanding Development Methodologies
Section Two: The Problem
5: Business Evolution
6 Business Organizations
7. Productivity inside the Data Organization
8. Solutions That Cause Problems
Section Three: The Process
9. Data Organization Practices
10. Models and Model Repositories
11. Model Constructs and Model Types
12. Time as a Dimension of the Database
13. Concepts of Clustering, Indexing and Structures
Section Four: The Product
14. Basic Requirements for Physical Design
15. Physical Database Considerations
16. Interpretation of Models
Section Five: Specialized Databases
17. Data Warehouses I
18. Data Warehouses II
19. Dimensional Warehouses from Enterprise Models
20. The Enterprise Data Warehouse
21. Object and Object/Relational Databases:
22. Distributed Databases