Kirjahaku

Understand the language and vocabulary of Data Architecture. The Data Architecture field is rife with terms that have become "fashionable." Some of the terms began with very specific, specialized, meanings - but as their use spread, they lost the precision of their technical definitions and become, well, "buzzwords."A buzzword is "a word or expression from a particular subject area that has become fashionable because it has been used a lot." Compliance is "the obeying of an accepted principle or instruction that states the way things are or should be done."The assignment is to take buzzwords and follow rules to use them correctly. We cut through the hype to arrive at buzzword compliance - the state where you fully understand the words that in fact have real meaning in the data architecture industry. This book will rationalize the various ways all these terms are defined.Of necessity, the book must address all aspects of describing an enterprise and its data management technologies. This includes a wide range of subjects, from entity/relationship modeling, through the semantic web, to database issues like relational and "beyond relational" ("NoSQL") approaches. In each case, the definitions for the subject are meant to be detailed enough to make it possible to understand basic principles--while recognizing that a full understanding will require consulting the sources where they are more completely described.The book's Glossary contains a catalogue of definitions and its Bibliography contains a comprehensive set of references.

Here you'll find one key to the development of a successful information system: Clearly capture and communicate both the abstract and concrete building blocks of data that describe your organization. In 1995, David Hay published Data Model Patterns: Conventions of Thought - the groundbreaking book on how to use standard data models to describe the standard business situations. Enterprise Model Patterns: Describing the World builds on the concepts presented there, adds 15 years of practical experience, and presents a more comprehensive view.You will learn how to apply both the abstract and concrete elements of your enterprise's architectural data model through four levels of abstraction: Level 0: An abstract template that underlies the Level 1 model that follows, plus two meta models: Information Resources. In addition to books, articles, and e-mail notes, it also includes photographs, videos, and sound recordings. Accounting. Accounting is remarkable because it is itself a modeling language. It takes a very different approach than data modelers in that instead of using entities and entity classes that represent things in the world, it is concerned with accounts that represent bits of value to the organization. Level 1: An enterprise model that is generic enough to apply to any company or government agency, but concrete enough to be readily understood by all. It describes: People and Organization. Who is involved with the business? The people involved are not only the employees within the organization, but customers, agents, and others with whom the organization comes in contact. Organizations of interest include the enterprise itself and its own internal departments, as well as customers, competitors, government agencies, and the like. Geographic Locations. Where is business conducted? A geographic location may be either a geographic area (defined as any bounded area on the Earth), a geographic point (used to identify a particular location), or, if you are an oil company for example, a geographic solid (such as an oil reserve). Assets. What tangible items are used to carry out the business? These are any physical things that are manipulated, sometimes as products, but also as the means to producing products and services. Activities. How is the business carried out? This model not only covers services offered, but also projects and any other kinds of activities. In addition, the model describes the events that cause activities to happen. Time. All data is positioned in time, but some more than others. Level 2: A more detailed model describing specific functional areas: Facilities Human Resources Communications and Marketing Contracts Manufacturing The Laboratory Level 3: Examples of the details a model can have to address what is truly unique in a particular industry.

Here you will learn how to develop an attractive, easily readable, conceptual, business-oriented entity/relationship model, using a variation on the UML Class Model notation. This book has two audiences: Data modelers (both analysts and database designers) who are convinced that UML has nothing to do with them; and UML experts who don't realize that architectural data modeling really is different from object modeling (and that the differences are important). David Hay's objective is to finally bring these two groups together in peace. Here all modelers will receive guidance on how to produce a high quality (that is, readable) entity/relationship model to describe the data architecture of an organization. The notation involved happens to be the one for class models in the Unified Modeling Language, even though UML was originally developed to support object-oriented design. Designers have a different view of the world from those who develop business-oriented conceptual data models, which means that to use UML for architectural modeling requires some adjustments. These adjustments are described in this book. David Hay is the author of Enterprise Model Patterns: Describing the World, a comprehensive model of a generic enterprise. The diagrams were at various levels of abstraction, and they were all rendered in the slightly modified version of UML Class Diagrams presented here. This book is a handbook to describe how to build models such as these. By way of background, an appendix provides a history of the two groups, revealing the sources of their different attitudes towards the system development process.