DOCSLIB.ORG

Data Model Standards and Guidelines, Registration Policies And

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Data Model Standards and Guidelines, Registration Policies And Data Model Standards and Guidelines, Registration Policies and Procedures Version 3.2 ● 6/02/2017 Data Model Standards and Guidelines, Registration Policies and Procedures Document Version Control Document Version Control VERSION D ATE AUTHOR DESCRIPTION DRAFT 03/28/07 Venkatesh Kadadasu Baseline Draft Document 0.1 05/04/2007 Venkatesh Kadadasu Sections 1.1, 1.2, 1.3, 1.4 revised 0.2 05/07/2007 Venkatesh Kadadasu Sections 1.4, 2.0, 2.2, 2.2.1, 3.1, 3.2, 3.2.1, 3.2.2 revised 0.3 05/24/07 Venkatesh Kadadasu Incorporated feedback from Uli 0.4 5/31/2007 Venkatesh Kadadasu Incorporated Steve’s feedback: Section 1.5 Issues -Change Decide to Decision Section 2.2.5 Coordinate with Kumar and Lisa to determine the class words used by XML community, and identify them in the document. (This was discussed previously.) Data Standardization - We have discussed on several occasions the cross-walk table between tabular naming standards and XML. When did it get dropped? Section 2.3.2 Conceptual data model level of detail: changed (S) No foreign key attributes may be entered in the conceptual data model. To (S) No attributes may be entered in the conceptual data model. 0.5 6/4/2007 Steve Horn Move last paragraph of Section 2.0 to section 2.1.4 Data Standardization Added definitions of key terms 0.6 6/5/2007 Ulrike Nasshan Section 2.2.5 Coordinate with Kumar and Lisa to determine the class words used by XML community, and identify them in the document. 0.7 6/15/2007 Ulrike Nasshan Revise section 3 to include DMR Policy 0.8 6/26/2007 Venkatesh Kadadasu Incorporated Holly’s feedback on final draft 1.0 6/29/2007 Venkatesh Kadadasu Final draft 1.1 9/24/2007 Venkatesh Kadadasu Added process flows for DMR 2.0 06/21/2011 Rick Armwood Final - updated to 2011 Format standards 3.0 12/14/2011 Major changes to content reflecting the existence of the Enterprise Data Services (EDS) team and, Data Governance Committee. Also removed all references to XML, XML R&R and PESC. 3.0.1 12/19/2011 Rick Armwood Minor updates to errors in TOC and Document Version Control 3.1 2/28/2017 EITASME Converted to new FSA Master Template format and improved TOC 3.2 6/02/2017 EITASME Enhanced Appendices and made document 508 compliant Version: 3.2 ii 6/2/2017 Data Model Standards and Guidelines, Registration Policies and Procedures Table of Contents Table of Contents SECTION 1. OVERVIEW ............................................................................................................................................... 1 1.1. INTRODUCTION ...................................................................................................................................................... 1 1.2. PURPOSE ............................................................................................................................................................. 1 1.3. SCOPE ................................................................................................................................................................. 1 1.4. BENEFITS ............................................................................................................................................................. 1 1.5. INTENDED AUDIENCE ............................................................................................................................................. 2 1.6. ORGANIZATION OF THE DOCUMENT ......................................................................................................................... 2 1.7. FSA DATA MODELING ENVIRONMENT ...................................................................................................................... 2 1.8. REFERENCES ........................................................................................................................................................ 3 SECTION 2. MODELING STANDARDS AND GUIDELINES ........................................................................................ 4 2.1. OVERIEW OF FSA DATA MODELS ........................................................................................................................... 4 2.2. FSA DATA MODEL DEFINITIONS ............................................................................................................................. 4 2.2.1. Entity-Relationship Data Model (ERDM) ..................................................................................................... 4 2.2.2. Entity Data Model ....................................................................................................................................... 4 2.2.3. Entities ........................................................................................................................................................ 5 2.2.4. Relationships .............................................................................................................................................. 5 2.2.5. Attributes..................................................................................................................................................... 5 2.2.6. Class Word ................................................................................................................................................. 5 2.2.7. Meta Data ................................................................................................................................................... 5 2.3. FSA DATA STANDARDIZATION ENVIRONMENT .......................................................................................................... 5 2.4. COMMON NAMING AND DEFINITION STANDARDS ....................................................................................................... 6 2.4.1. Naming Standards ...................................................................................................................................... 6 2.4.2. Definition Standards ................................................................................................................................... 6 2.5. UNIQUE DATA OBJECT NAMING AND DEFINITION STANDARDS AND GUIDELINES ........................................................... 7 2.5.1. Entity versus Object Modeling .................................................................................................................... 7 2.5.2. Data Object Naming Conventions ............................................................................................................... 8 2.5.3. Data Object Definitions ............................................................................................................................. 10 2.5.4. Generic Class Words ................................................................................................................................ 10 2.6. CONCEPTUAL DATA MODELING (CDM) STANDARDS AND GUIDELINES ...................................................................... 11 2.6.1. Conceptual data model packaging: ........................................................................................................... 11 2.6.2. Conceptual data model level of detail: ...................................................................................................... 11 2.6.3. CDM Review Template ............................................................................................................................. 12 2.7. LOGICAL DATA MODELING (LDM) STANDARDS AND GUIDELINES .............................................................................. 12 2.7.1. LDM Review Template ............................................................................................................................. 12 2.8. PHYSICAL DATA MODEL (PDM) STANDARDS AND GUIDELINES ................................................................................. 13 2.8.1. PDM Review Template ............................................................................................................................. 14 SECTION 3. DATA MODEL REGISTRATION (DMR) ................................................................................................. 15 3.1. DMR POLICY ...................................................................................................................................................... 15 3.2. DMR PROCEDURES ............................................................................................................................................ 15 3.2.1. DMR Procedures for existing applications ................................................................................................ 15 3.2.2. DMR Procedures for future developments in support of TSV ................................................................... 16 3.2.3. DMR Process Flows ................................................................................................................................. 16 3.3. ROLES AND RESPONSIBILITIES FOR THE DMR PROCESS ......................................................................................... 18 3.3.1. DMR Responsibilities of the EDS Team ................................................................................................... 18 3.3.2. DMR Responsibilities of the System Developer........................................................................................ 18 3.4. REGISTRATION REQUIREMENTS FOR DATA-RELATED ARTIFACTS.............................................................................. 18 3.4.1. Data Model Meta Data Registration Requirements ..................................................................................
Load more

Recommended publications
  • Data Analytics EMEA Insurance Data Analytics Study Contents
    A little less conversation, a lot more action – tactics to get satisfaction from data analytics EMEA Insurance data analytics study Contents Foreword 01 Introduction from the authors 04 Vision and strategy 05 A disconnect between analytics and business strategies 05 Articulating a clear business case can be tricky 07 Tactical projects are trumping long haul strategic wins 09 The ever evolving world of the CDO 10 Assets and capability 12 Purple People are hard to find 12 Data is not always accessible or trustworthy 14 Agility and traditional insurance are not natural bedfellows 18 Operationalisation and change management 23 Operating models have no clear winner 23 The message is not always loud and clear 24 Hearts and minds do not change overnight 25 Are you ready to become an IDO? 28 Appendix A – The survey 30 Appendix B – Links to publications 31 Appendix C – Key contacts 32 A little less conversation, a lot more action – tactics to get satisfaction from data analytics | EMEA Insurance data analytics study Foreword The world is experiencing the fastest pace of data expansion and technological change in history. Our work with the World Economic Forum in 2015 identified that, within financial services, insurance is the industry which is most ripe for disruption from innovation owing to the significant pressure across the value chain. To build on this work, our report ‘Turbulence ahead – The future of general insurance’, set out various innovations transforming the industry and subsequent scenarios for The time is now the future. It identified that innovation within the insurance industry is no longer led by insurers themselves.
    [Show full text]
  • Constructing a Meta Data Architecture
    0-471-35523-2.int.07 6/16/00 12:29 AM Page 181 CHAPTER 7 Constructing a Meta Data Architecture This chapter describes the key elements of a meta data repository architec- ture and explains how to tie data warehouse architecture into the architec- ture of the meta data repository. After reviewing these essential elements, I examine the three basic architectural approaches for building a meta data repository and discuss the advantages and disadvantages of each. Last, I discuss advanced meta data architecture techniques such as closed-loop and bidirectional meta data, which are gaining popularity as our industry evolves. What Makes a Good Architecture A sound meta data architecture incorporates five general characteristics: ■ Integrated ■ Scalable ■ Robust ■ Customizable ■ Open 181 0-471-35523-2.int.07 6/16/00 12:29 AM Page 182 182 Chapter 7 It is important to understand that if a company purchases meta data access and/or integration tools, those tools define a significant portion of the meta data architecture. Companies should, therefore, consider these essential characteristics when evaluating tools and their implementation of the technology. Integrated Anyone who has worked on a decision support project understands that the biggest challenge in building a data warehouse is integrating all of the dis- parate sources of data and transforming the data into meaningful informa- tion. The same is true for a meta data repository. A meta data repository typically needs to be able to integrate a variety of types and sources of meta data and turn the resulting stew into meaningful, accessible business and technical meta data.
    [Show full text]
  • Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes
    Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes “The Business Driven Application Lifecycle” Bob Sherman Procter & Gamble Pharmaceuticals [email protected] Michael Sutherland Galactic Solutions Group, LLC [email protected] Prepared for the Telelogic 2005 User Group Conference, Americas & Asia/Pacific http://www.telelogic.com/news/usergroup/us2005/index.cfm 24 October 2005 Abstract: The fact that most Information Technology (IT) projects fail as a result of requirements management problems is common knowledge. What is not commonly recognized is that the widely haled “use case” and Object Oriented Analysis and Design (OOAD) phenomenon have resulted in little (if any) abatement of IT project failures. In fact, ten years after the advent of these methods, every major IT industry research group remains aligned on the fact that these projects are still failing at an alarming rate (less than a 30% success rate). Ironically, the popularity of use case and OOAD (e.g. UML) methods may be doing more harm than good by diverting our attention away from addressing the real root cause of IT project failures (when you have a new hammer, everything looks like a nail). This paper asserts that, the real root cause of IT project failures centers around the failure to map requirements to an accurate, precise, comprehensive, optimized business model. This argument will be supported by a using a brief recap of the history of use case and OOAD methods to identify differences between the problems these methods were intended to address and the challenges of today’s IT projects.
    [Show full text]
  • Principles of the Concept-Oriented Data Model Alexandr Savinov
    Principles of the Concept-Oriented Data Model Alexandr Savinov Institute of Mathematics and Computer Science Academy of Sciences of Moldova Academiei 5, MD-2028 Chisinau, Moldova Fraunhofer Institute for Autonomous Intelligent System Schloss Birlinghoven, 53754 Sankt Augustin, Germany http://www.conceptoriented.com [email protected] Principles of the Concept-Oriented Data Model Alexandr Savinov Institute of Mathematics and Computer Science, Academy of Sciences of Moldova Academiei 5, MD-2028 Chisinau, Moldova Fraunhofer Institute for Autonomous Intelligent System Schloss Birlinghoven, 53754 Sankt Augustin, Germany http://www.conceptoriented.com [email protected] In the paper a new approach to data representation and manipulation is described, which is called the concept-oriented data model (CODM). It is supposed that items represent data units, which are stored in concepts. A concept is a combination of superconcepts, which determine the concept’s dimensionality or properties. An item is a combination of superitems taken by one from all the superconcepts. An item stores a combination of references to its superitems. The references implement inclusion relation or attribute- value relation among items. A concept-oriented database is defined by its concept structure called syntax or schema and its item structure called semantics. The model defines formal transformations of syntax and semantics including the canonical semantics where all concepts are merged and the data semantics is represented by one set of items. The concept-oriented data model treats relations as subconcepts where items are instances of the relations. Multi-valued attributes are defined via subconcepts as a view on the database semantics rather than as a built-in mechanism.
    [Show full text]
  • Metamodeling the Enhanced Entity-Relationship Model
    Metamodeling the Enhanced Entity-Relationship Model Robson N. Fidalgo1, Edson Alves1, Sergio España2, Jaelson Castro1, Oscar Pastor2 1 Center for Informatics, Federal University of Pernambuco, Recife(PE), Brazil {rdnf, eas4, jbc}@cin.ufpe.br 2 Centro de Investigación ProS, Universitat Politècnica de València, València, España {sergio.espana,opastor}@pros.upv.es Abstract. A metamodel provides an abstract syntax to distinguish between valid and invalid models. That is, a metamodel is as useful for a modeling language as a grammar is for a programming language. In this context, although the Enhanced Entity-Relationship (EER) Model is the ”de facto” standard modeling language for database conceptual design, to the best of our knowledge, there are only two proposals of EER metamodels, which do not provide a full support to Chen’s notation. Furthermore, neither a discussion about the engineering used for specifying these metamodels is presented nor a comparative analysis among them is made. With the aim at overcoming these drawbacks, we show a detailed and practical view of how to formalize the EER Model by means of a metamodel that (i) covers all elements of the Chen’s notation, (ii) defines well-formedness rules needed for creating syntactically correct EER schemas, and (iii) can be used as a starting point to create Computer Aided Software Engineering (CASE) tools for EER modeling, interchange metadata among these tools, perform automatic SQL/DDL code generation, and/or extend (or reuse part of) the EER Model. In order to show the feasibility, expressiveness, and usefulness of our metamodel (named EERMM), we have developed a CASE tool (named EERCASE), which has been tested with a practical example that covers all EER constructors, confirming that our metamodel is feasible, useful, more expressive than related ones and correctly defined.
    [Show full text]
  • The Importance of Data Models in Enterprise Metadata Management
    THE IMPORTANCE OF DATA MODELS IN ENTERPRISE METADATA MANAGEMENT October 19, 2017 © 2016 ASG Technologies Group, Inc. All rights reserved HAPPINESS IS… SOURCE: 10/18/2017 TODAY SHOW – “THE BLUE ZONE OF HAPPINESS” – DAN BUETTNER • 3 Close Friends • Get a Dog • Good Light • Get Religion • Get Married…. Stay Married • Volunteer • “Money will buy you Happiness… well, it’s more about Financial Security” • “Our Data Models are now incorporated within our corporate metadata repository” © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable 2. Data Models can in be incorporated into your corporate metadata repository © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable 2. Data Models can in be incorporated into your corporate metadata repository 3. ASG Technologies can provide an overall solution with services to accomplish #2 above and more for your company. © 2016 ASG Technologies Group, Inc. All rights reserved AGENDA Data model imports to the metadata collection View and search capabilities Traceability of physical and logical
    [Show full text]
  • Towards the Universal Spatial Data Model Based Indexing and Its Implementation in Mysql
    Towards the universal spatial data model based indexing and its implementation in MySQL Evangelos Katsikaros Kongens Lyngby 2012 IMM-M.Sc.-2012-97 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk IMM-M.Sc.: ISSN XXXX-XXXX Summary This thesis deals with spatial indexing and models that are able to abstract the variety of existing spatial index solutions. This research involves a thorough presentation of existing dynamic spatial indexes based on R-trees, investigating abstraction models and implementing such a model in MySQL. To that end, the relevant theory is presented. A thorough study is performed on the recent and seminal works on spatial index trees and we describe their basic properties and the way search, deletion and insertion are performed on them. During this effort, we encountered details that baffled us, did not make the understanding the core concepts smooth or we thought that could be a source of confusion. We took great care in explaining in depth these details so that the current study can be a useful guide for a number of them. A selection of these models were later implemented in MySQL. We investigated the way spatial indexing is currently engineered in MySQL and we reveal how search, deletion and insertion are performed. This paves the path to the un- derstanding of our intervention and additions to MySQL's codebase. All of the code produced throughout this research was included in a patch against the RDBMS MariaDB.
    [Show full text]
  • An Enterprise Information System Data Architecture Guide
    An Enterprise Information System Data Architecture Guide Grace Alexandra Lewis Santiago Comella-Dorda Pat Place Daniel Plakosh Robert C. Seacord October 2001 TECHNICAL REPORT CMU/SEI-2001-TR-018 ESC-TR-2001-018 Pittsburgh, PA 15213-3890 An Enterprise Information System Data Architecture Guide CMU/SEI-2001-TR-018 ESC-TR-2001-018 Grace Alexandra Lewis Santiago Comella-Dorda Pat Place Daniel Plakosh Robert C. Seacord October 2001 COTS-Based Systems Unlimited distribution subject to the copyright. This report was prepared for the SEI Joint Program Office HQ ESC/DIB 5 Eglin Street Hanscom AFB, MA 01731-2116 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. FOR THE COMMANDER Norton L. Compton, Lt Col, USAF SEI Joint Program Office This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2001 by Carnegie Mellon University. Requests for permission to reproduce this document or to prepare derivative works of this document should be addressed to the SEI Licensing Agent. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
    [Show full text]
  • HANDLE - a Generic Metadata Model for Data Lakes
    HANDLE - A Generic Metadata Model for Data Lakes Rebecca Eichler, Corinna Giebler, Christoph Gr¨oger, Holger Schwarz, and Bernhard Mitschang In: Big Data Analytics and Knowledge Discovery (DaWaK) 2020 BIBTEX: @inproceedingsfeichler2020handle, title=fHANDLE-A Generic Metadata Model for Data Lakesg, author=fEichler, Rebecca and Giebler, Corinna and Gr{\"o\}ger,Christoph and Schwarz, Holger and Mitschang, Bernhardg, booktitle=fInternational Conference on Big Data Analytics and Knowledge Discovery (DaWaK) 2020g, pages=f73{88g, year=f2020g, organization=fSpringerg, doi=f10.1007/978-3-030-59065-9 7g g c by Springer Nature This is the author's version of the work. The final authenticated version is avail- able online at: https://doi.org/10.1007/978-3-030-59065-9 7 HANDLE - A Generic Metadata Model for Data Lakes Rebecca Eichler1, Corinna Giebler1, Christoph Gr¨oger2, Holger Schwarz1, and Bernhard Mitschang1 1 University of Stuttgart, Universit¨atsstraße38, 70569 Stuttgart, Germany [email protected] 2 Robert Bosch GmbH, Borsigstraße 4, 70469 Stuttgart, Germany [email protected] Abstract The substantial increase in generated data induced the de- velopment of new concepts such as the data lake. A data lake is a large storage repository designed to enable flexible extraction of the data's value. A key aspect of exploiting data value in data lakes is the collec- tion and management of metadata. To store and handle the metadata, a generic metadata model is required that can reflect metadata of any potential metadata management use case, e.g., data versioning or data lineage. However, an evaluation of existent metadata models yields that none so far are sufficiently generic.
    [Show full text]
  • XV. the Entity-Relationship Model
    Information Systems Analysis and Design csc340 XV. The Entity-Relationship Model The Entity-Relationship Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of E-R Diagrams and Business Rules 2002 John Mylopoulos The Entity-Relationship Model -- 1 Information Systems Analysis and Design csc340 The Entity Relationship Model The Entity-Relationship (ER) model is a conceptual data model, capable of describing the data requirements for a new information system in a direct and easy to understand graphical notation. Data requirements are described in terms of a conceptualconceptual (or, ER) schema. ER schemata are comparable to class diagrams. 2002 John Mylopoulos The Entity-Relationship Model -- 2 Information Systems Analysis and Design csc340 The Constructs of the E-R Model AND/XOR 2002 John Mylopoulos The Entity-Relationship Model -- 3 Information Systems Analysis and Design csc340 Entities These represent classes of objects (facts, things, people,...) that have properties in common and an autonomous existence. City, Department, Employee, Purchase and Sale are examples of entities for a commercial organization. An instance of an entity is an object in the class represented by the entity. Stockholm, Helsinki, are examples of instances of the entity City, and the employees Peterson and Johanson are examples of instances of the Employee entity. The E-R model is very different from the relational model in which it is not possible to represent an object without knowing its properties (an employee is represented by a tuple containing the name, surname, age, and other attributes.) 2002 John Mylopoulos The Entity-Relationship Model -- 4 Information Systems Analysis and Design csc340 Examples of Entities 2002 John Mylopoulos The Entity-Relationship Model -- 5 Information Systems Analysis and Design csc340 Relationships They represent logical links between two or more entities.
    [Show full text]
  • ER Studio Data Architect Quick Start Guide
    Product Documentation ER Studio Data Architect Quick Start Guide Version 11.0 © 2015 Embarcadero Technologies, Inc. Embarcadero, the Embarcadero Technologies logos, and all other Embarcadero Technologies product or service names are trademarks or registered trademarks of Embarcadero Technologies, Inc. All other trademarks are property of their respective owners. Embarcadero Technologies, Inc. is a leading provider of award-winning tools for application developers and database professionals so they can design systems right, build them faster and run them better, regardless of their platform or programming language. Ninety of the Fortune 100 and an active community of more than three million users worldwide rely on Embarcadero products to increase productivity, reduce costs, simplify change management and compliance and accelerate innovation. The company's flagship tools include: Embarcadero® Change Manager™, CodeGear™ RAD Studio, DBArtisan®, Delphi®, ER/Studio®, JBuilder® and Rapid SQL®. Founded in 1993, Embarcadero is headquartered in San Francisco, with offices located around the world. Embarcadero is online at www.embarcadero.com. March, 2015 Embarcadero Technologies 2 CONTENTS Introducing ER/Studio Data Architect............................................................................ 5 Notice for Developer Edition Users ................................................................................... 5 Product Benefits by Audience ............................................................................................ 5 What's
    [Show full text]
  • ER/Studio Enterprise Team Edition
    ER/Studio Enterprise Team Edition THE ULTIMATE COLLABORATIVE ENTERPRISE DATA ARCHITECTURE AND MODELING SOLUTION With many organizations seeing a significant increase in data, along with more emphasis on compliance to industry and government regulations, it’s clear that having a solid strategy for data management is extremely important. ER/Studio Enterprise Team edition provides a comprehensive solution that empowers users to easily define models and metadata, establish a foundation for data governance initiatives, and define an enterprise architecture to effectively manage data across the whole organization. THE CHALLENGE OF MANAGING AND UTILIZING ENTERPRISE DATA Physically capturing and properly integrating data is challenging, especially for ER/Studio gives data management professionals the metadata unstructured content. Incorporating the new data, interpreting it correctly, and foundation to quickly respond to business process demands, reduce making it available to decision makers in a timely manner poses three distinct the risk of noncompliance, and deliver more actionable insight. challenges for data management professionals: Many organizations must deal with both relational and NoSQL data, • Leveraging enterprise data as an organizational asset as well as a broad landscape of platforms. ER/Studio Enterprise Team • Improving and managing data quality edition continues to build on its support of strategic enterprise systems including Teradata, Netezza, and Azure, as well as Big Data platform • Clearly and effectively communicating data throughout an organization support for Hadoop Hive and MongoDB, giving organizations an To address these issues, ER/Studio Enterprise Team edition gives data modelers interpretive and collaborative enterprise advantage for leveraging their and data architects the capabilities needed to analyze, document, and share data residing in diverse locations, from data centers to mobile platforms.
    [Show full text]