Codd와 Zachman (from FlashMapSystems)

아래 글은 웹 사이트 (www.flashmapsystems.com)에서 퍼 온 Jeff Tash의 글로서 관계형 데이터모델의 이론적 근거를 만든 Codd와 정보시스템에 대한 큰 그림이라고 할 수 있는 Enterprise Architecture의 개념적 구성을 제시한 Zachman의 산출물을 비교하고 있습니다.

 

Codd의 관계형 데이터모델이나 Zachman의 (Enterprise Architecture) Framework는 모두 표(table) 형태로 정의된다는 점에서는 공통점이 있는데 Codd의 표는 단순, 명확한 논리를 포함하고 있음에 반해, Zachman의 표는 애매하고 복잡한 의미를 담고 있음을 지적하고 있습니다.

 

Mr. Tash의 글에 대해 저는 다음과 같은 점을 이야기하고 싶네요.

- 현실세계를 모델링 할 때 1차적으로는 개념적(conceptual) 모델을, 2차적으로는 논리적(logical) 모델을, 그 다음에 컴퓨터 시스템 내에서 다루기 위한 물리적(physicla) 모델을 사용합니다. 데이터 모델링 분야에서 개념적 모델의 대표적인 것이 P. P. Chen의 E-R (Entity-Relationship) 모델이고 관계형 모델은 논리적 모델이라고 할 수 있습니다.

- 논리적 모델은 명확하기는 하지만 현실세계의 의미(semantics)를 놓칠 수 있다는 약점이 있고 개념적 모델은 기계적인 처리는 어렵지만 현실세계의 의미를 충분히 반영할 수 있다는 장점이 있지요.

- 개념적 세계를 다룰 것인가 또는 논리적 세계를 다룰 것인가라는 목적에 따라 여러 가지 모델은 각각 장/단점을 갖게 됩니다. 크고 막연한 문제를 이해하고 의사소통하기 위해서는 먼저 개념적 모델이 동원되어야 하는데 Zachman Framework는 그런 점에서 큰 그림을 볼 수 있는 통찰력을 제공해 줍니다.  

Rows and Columns: Codd vs. Zachman

by Jeff Tash, ITscout

Both Ted Codd and John Zachman spent the bulk of their professional careers working for IBM. Both are recognized as “fathers” of major technological innovations. Codd invented the “relational model.” Zachman is credited with pioneering “enterprise architecture” (EA) -- being the first to apply the principles of the building industry’s use of architecture and construction to the planning and development of information systems. Both, after publishing their original concepts back in the 1970s and 1980s (while still employed at IBM), encountered stiff resistance to their revolutionary new ideas. But both also shared an evangelical zeal which led each to open up his own consulting practice -- both on the west coast -- Codd in Silicon Valley and Zachman in Los Angeles. Unfortunately, neither gentleman ever achieved the great riches commensurate with their invaluable contributions to the industry.

Both Codd’s relational model and Zachman’s Framework are usually described in terms of simple two-dimensional tables consisting of “rows” and “columns.” Despite this similarity, plus the many parallels cited above that connect these two brilliant luminaries, there are also strikingly stark contrasts. Most notably, the “simplicity” of Codd’s model versus the “complexity” of Zachman’s framework. In reality, there are huge differences between Codd’s simple tables and Zachman’s complex rows and columns.

One would be hard pressed nowadays to identify a single Global 2000 (G2000) organization where relational DBMSs, based on Codd’s theory, are not the strategic data store for the enterprise. These products include Oracle, SQL Server, DB2, and countless other database management systems ranging from MySQL to Teradata. Conversely, EA, especially as espoused by Zachman as a framework for managing information technology and organizational change, has barely penetrated the G2000 corporate culture. Where it has, EA has mainly ridden atop the rising wave of “process” popularity as organizations have come to realize the value of modeling and managing their business processes.

What Codd brought to the table with his relational model was, first and foremost, “simplicity.” Prior to Codd, the only way to access data in a database was to specify the navigational logic that literally described programmatically “how” to retrieve records and fields. Users were required to understand their databases’ physical structure, including its pointers and indexes. The relational model only calls for users to specify “what” data to retrieve. The software automatically generates the navigational code needed to retrieve the data. As an analogy, you can compare a relational DBMS to a navigational DBMS as similar to a compiler language versus an assembler language. With relational, people view their data as a collection of tables. Simple relational algebraic ｅxpressions are used to specify queries. Users can select a subset of a table’s rows or a subset of a table’s columns. Furthermore, two tables can be joined together by matching common values in the rows of one table with rows from another table.

While Zachman’s rows and columns outwardly appear simple, beneath the surface, the contents of each cell is unimaginably complex. Zachman’s goal of metaphorically equating intangible “models” used to describe enterprises with the “design artifacts” normally associated with architecture and construction (or engineering and manufacturing), loses something in the translation. The columns of Zachman’s Framework represent the “what,” “how,” “where,” “who,” “when,” and “why” of EA. These are good, open-ended questions -- excellent to ask when studying any complicated subject. But the definition of Zachman’s rows are complex, abstract, obfuscated and arbitrary. Zachman labels his rows “scope,” “business model,” “system model,” “technology model,” and “detailed implementations,” which are supposed to correspond to “contextual,” “conceptual,” “logical,” “physical,” and “out-of-context.” Zachman further suggests associating each row with a role such that contextual relates to “planner,” conceptual to “owner,” logical to “designer,” physical to “builder,” and out-of-context to “subcontractor.” Simple, huh? Who’s ready to jump in and start examining the contents of each individual cell -- those intersections between rows and columns? Who can guess what those contents must be? Certainly not any non-technical business managers I’ve ever known!

EA, as it’s practiced today, is excruciatingly complex -- totally the opposite of relational’s remarkable simplicity. This painstaking complexity makes EA almost unapproachable. It reminds me of the old Maine farmer who, when asked for directions by the city slicker, responds (in a heavy down east accent) “you can’t get there from here.”

Organizations need to find a better way to get started with EA. The first thing a building architect does before designing a new home is to look at the "terrain" on which the structure will be situated. For EA, IT should do the same. Look at past technology investments. Define which characteristics of the existing terrain you want to keep, what you need to change, what should be discarded, and what needs to be developed. This topographical mapping of your terrain is the foundational blueprint that serves as the groundwork for future EA initiatives.
 

---

Jeff Tash is CEO of Flashmap Systems, Inc. (www.FlashmapSystems.com). He’s also the creator of the Flashmap Roadmap series of wall posters that cover IT Infrastructure, Business Intelligence, Application Development, and COTS (Commercial-Off-The-Shelf) Applications. Register on Jeff's free personal web site at www.ITscout.org for an interactive version of his roadmap models.