DOCSLIB.ORG

Powerdesigner® 15.3 Vs. Computer Associates Erwin 7.3

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Powerdesigner® 15.3 Vs. Computer Associates Erwin 7.3 WHITE PAPER PowerDesigner® 15.3 vs. Computer Associates ERwin 7.3 www.sybase.com TABLE OF CONTENTS 1 Introduction 10 Database Support 1 Product Overviews 12 Repository (Collaborative Modeling) 1 ERwin Data Modeler 7.3 12 CA ERwin Model Navigator 1 PowerDesigner 15.3 12 Sybase PowerDesigner Viewer 2 User Interface Differences 13 Sybase PowerDesigner Portal 3 Modeling Features 13 Extensibility and Customization 4 Required Features for a Data Modeling Solution 14 Business Process Modeling 4 Model Types 15 Object Oriented Modeling 5 Conceptual > Logical > Physical > 15 Enterprise Architecture Modeling Logical > Conceptual 15 Dependency Matrices 6 Model Comparisons and Merges 16 Projects 7 Impact Analysis 16 Framework Matrices 9 Reverse / Forward Engineering 17 Summary 9 Modeling Notation 17 About the Author 10 Import / Export TABLE OF FIGURES 4 Figure 1 PowerDesigner Orthogonal Layout 11 Figure 9 PowerDesigner Oracle 6 Figure 3 PowerDesigner LDMTools Datatype Examples 8 Figure 4 ERwin Impact Analysis 14 Figure 12 PowerDesigner Allows Data to be 8 Figure 5 PowerDesigner Impact Analysis Assigned to Business Processes 11 Figure 6 PowerDesigner Oracle Physical Options INTRODUCTION When a project requires data modeling, there is a choice of several different products. Two market-leading products are ERwin (from CA) and PowerDesigner (from Sybase). Both will allow a modeler to create data models, reverse engineer databases, document database systems, create basic reports and create/modify diagrams in a Windows- standard manner. If an organization needs to create a database one time, generate the script to build it and never modify it again, then the best choice would be the product with the least acquisition cost. However, it is rare that an organization needs to create one database and leave it alone. As a business’ needs get more complex, the products reviewed in this paper quickly diverge. There is one clear winner: PowerDesigner. PRODUCT OVERVIEWS With the tools reviewed, there were similarities. Both modeling tools reviewed provide a drawing canvas and a navigator or explorer and a log window. Toolbars can be turned on or off, but only PowerDesigner allows for toolbar customization. Both tools have undo/redo capabilities. These are Windows applications and, as such, are intuitive from a user-experience perspective. Please see the table for differences in user-experience features following the vendors’ descriptions. ERwin Data Modeler 7.3 CA states “CA ERwin Data Modeler is a data modeling solution that enables you to create and maintain databases, data warehouses and enterprise data resource models. These models help you visualize data structures so that you can effectively organize, manage and moderate data complexities, database technologies and the deployment environment.” When I made an attempt to download ERwin, I found that the link on the website was broken. I called CA to request an evaluation copy of ERwin. After gathering my information, I was told that a salesperson would call me back. I never received a phone call from a salesperson. Two days later, I tried the link again and was able to successfully obtain an evaluation copy—good for 25 entities and 15 days. Installing Data Modeler seemed to work correctly. However, it did not create a Program Group in Windows, nor did it create a desktop link for starting the product. In order to use the modeling tool, I needed to navigate through the Windows folder hierarchy to find the program. PowerDesigner 15.3 Sybase “PowerDesigner uniquely combines several standard modeling techniques (UML, Business Process Modeling and market-leading data modeling) together with leading development environments, such as .NET, Workspace, PowerBuilder, Java, and Eclipse, to bring business analysis and formal design solutions to the traditional software development lifecycle. And it works with more than 60 RDBMS.” The ability to download the fully functional evaluation version of PowerDesigner 15 was provided from Sybase’s website. Installation was flawless. 1 User Interface Differences FEATURE POWERDESIGNER ERWIN Model Organization Yes, a full workspace that can be No. The model explorer within the saved independently from the tool only allows visibility into one models. Multiple models and model model at a time, regardless the types can be open simultaneously. number of open models. Workspace Yes—this can be saved independently No. from the models. Full flexibility and organization is provided. Multiple Diagrams within a Model Yes. Yes. Subject Areas in a Model Yes, via UML standard packages— Yes, but only one level. allows nesting. Object Placement Standard windows controls Standard windows controls Model Layouts Auto layouts include Basic, Under Format->Preferences, there is a Hierarchical, Organic, Orthogonal, “layout entire diagram” button but it Circular, Tree with scope of selected did not work, even when tables were symbols or all symbols. stacked on each other. Freeform Text Yes. No. Customize Toolbars Yes. No. Edit Text Directly on Graphic Yes. Yes. Page Grid Yes. Yes. Find Objects Yes. Yes. Product Documentation Yes, there are PDF versions of the Yes. documentation as well as full documentation online at http://sybooks.sybase.com. Undo/Redo Yes, unlimited. Yes and when using the repository, the undo/redo is maintained across modeling sessions. Zoom in/out Yes. Yes. 2 Modeling Features FEATURE POWERDESIGNER ERWIN Conceptual, Logical and Yes No Physical Models Naming Standards Yes Yes through templates Shortcuts to Objects in Other Models Yes No Templates for Model Creation Yes Yes Check Model (Validation) Yes—customizable to include user- Yes defined constraints such as tables must have three columns. Multidimensional Modeling Yes, extensive Yes Generate Test Data Yes No Impact and Lineage Analysis Yes No Object Oriented Model Yes No Business Process Model Yes No Enterprise Architecture Model Yes No Projects and Framework Matrices Yes No User Profiles Yes No Mapping Tool (Connections between Yes No objects in different models) Inter-Model Generation & Extensive, CDM-LDM-PDM, including Yes, only with LDM-PDM Synchronization other model types 3 Figure 1: PowerDesigner Orthogonal Layout REQUIRED FEATURES FOR A DATA MODELING SOLUTION Model Types To fully model a system, it is necessary to combine business analysis with technology implementations. Where data modeling is concerned, an organization must create conceptual data models, logical data models and physical data models. A conceptual data model (CDM) is usually in the form of an entity-relationship diagram, however it is purely data and relationships. A CDM is not relational. It is developed in order to understand, capture, and analyze the business needs from a data perspective. These models will be devoid of implementation details (data storage structures) or software constraints. Entities, attributes and identifiers are found in a CDM. Additionally, the relationships and inheritances that connect the objects, or artifacts, exist in the CDM. The CDM is a higher-level business model. Some of the relationships might be one-to-many yet some might be many-to-many. The CDM will typically be created prior to an LDM for a new system. The CDM might also be used for an existing system where the technology needs to be verified with the business. Once a CDM has been created, a modeler should be able to generate a logical data model (LDM) from it. The LDM is quite similar to the CDM in terms of the objects that are contained therein. However, the beginning of physical data storage is modeled in the LDM. Many-to-many relationships are not permitted in an LDM so they become intermediate entities. One-to-many relationships become primary key-foreign key identifiers. LDMs illustrate the logical entity types, the data attributes describing the entities and the relationships between the entities. A CDM does not have foreign-key constraints—these are created when a CDM is used to generate an LDM. Additionally, while a CDM supports a many-to-many relationship, the LDM does not permit many-to-many. Since the LDM is relational, many-to-many relationships cannot exist as many-to-many violates relational storage concepts. The LDM is relational but the CDM can transform to different types of logical models (hierarchical, object-oriented, and relational) so the CDM is better to represent the use of the data by the business. 4 The physical data model (PDM) would typically be created after the LDM. This model will be used to design the schema of the database that will be used for the system. Entities become tables, attributes become data columns and the relationships will be implemented in the database-specific structures (referential integrity, stored procedures). When creating or generating a PDM, the specific database is chosen (Oracle 11i, Sybase ASE 15, Microsoft SQL Server are several choices). The PDM is frequently used to generate the data description language (DDL) that will allow for database creation or modification. The LDM and the PDM are similar but vastly different in terms of the level of detail each supports. The LDM is used to explore domain concepts with the business stakeholders; the PDM is used to create and maintain the database. Multiple PDMs can be generated from a single LDM—this can be useful for database migrations, creation of production and development databases or application migrations. A modeling tool should provide the ability to model at any level, with generation to the other model types. All artifacts should be linked to their corresponding objects in the other models (for example, the entity “Customer” in the CDM should be linked to the “Customer” entity in the LDM as well as the “Customer” table in the PDM). All linkages should be maintained in the modeling tool so that a proposed change in an object can be analyzed before it is changed. Conceptual > Logical > Physical > Logical > Conceptual A data modeling tool MUST support round-trip engineering. Whether a modeler is starting from a conceptual model or reverse engineering a database into a physical model, a tool is useless unless it can support all aspects.
Load more

Recommended publications
  • Enterprise Architecture
    Enterprise Architecture The Zachman Framework: Intro to Sample Models © 1990-2011 John A. Zachman, Zachman International® Observation Enterprises are COMPLEX The US Pentagon GM Plant © 1990-2011 John A. Zachman, Zachman International® Agenda I. Enterprise Models from Literature II. Implementation Discussion III. Architecture Discussion IV. Column 1 Model Samples V. Row 1 Model Samples VI. Column 2 Model Samples VII.Etc., Etc. ‘till Time Is Up © 1990-2011 John A. Zachman, Zachman International® Models on my Bookshelf 1. "Requirements Analysis" by David C. Hay Activity Management A Complete Sarson and Gane Data Flow Diagram Physical Asset Value Constraints 2. "Information Modeling and Relational Databases" by Terry Halpin and Tony Morgan IT Company Schema and University Schema 3. "Enterprise Architecture for Integration" by Clive Finkelstein Strategic Model for sample solution Order entry data map with all attributes 5BNF data map - ORG and ROLE STRUCTURES 4. "Designing Quality Databases with IDEF1X Information Models" by Thomas A. Bruce Case Study Supplementary Material (Logical Data Model) 5. "Business Process Management"by Roger T. Burlton The Scope for Global Software Human Resources © 1990-2011 John A. Zachman, Zachman International® Models on my Bookshelf 6. "Enterprise Architecture at Work" by Marc Langhorst Services provided by Handle Claims Process Handle Claims and IT Support 7. "Business Process Engineering" by August Scheer ERM for Human Resource Planning Event-driven process chain for inbound logistics 8. "Data Model Resource
    [Show full text]
  • Enterprise Architecture As Explanatory Information Systems Theory for Understanding Small- and Medium-Sized Enterprise Growth
    sustainability Article Enterprise Architecture as Explanatory Information Systems Theory for Understanding Small- and Medium-Sized Enterprise Growth Aurona Gerber 1,2,* , Pierre le Roux 1,3 and Alta van der Merwe 1 1 Department of Informatics, University of Pretoria, 0083 Pretoria, South Africa; [email protected] (P.R.); [email protected] (A.v.d.M.) 2 CAIR, Center for Artificial Intelligence Research, 0083 Pretoria, South Africa 3 Moyo, 0157 Centurion, South Africa * Correspondence: [email protected] Received: 31 July 2020; Accepted: 7 October 2020; Published: 15 October 2020 Abstract: Understanding and explaining small- and medium-sized enterprise (SME) growth is important for sustainability from multiple perspectives. Research indicates that SMEs comprise more than 80% of most economies, and their cumulative impact on sustainability considerations is far from trivial. In addition, for sustainability concerns to be prioritized, an SME has to be successful over time. In most developing countries, SMEs play a major role in solving socio-economic challenges. SMEs are an active research topic within the information systems (IS) discipline, often within the enterprise architecture (EA) domain. EA fundamentally adopts a systems perspective to describe the essential elements of a socio-technical organization and their relationships to each other and to the environment in order to understand complexity and manage change. However, despite rapid adoption originally, EA research and practice often fails to deliver on expectations. In some circles, EA became synonymous with projects that are over-budget, over-time and costly without the expected return on investment. In this paper, we argue that EA remains indispensable for understanding and explaining enterprises and that we fundamentally need to revisit some of the applications of EA.
    [Show full text]
  • CA Erwin Data Modeler Implementation Guide
    CA ERwin® Data Modeler Implementation Guide r7.3 r7.3.8 SP2 Edition This documentation and any related computer software help programs (hereinafter referred to as the "Documentation") are for your informational purposes only and are subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be used or disclosed by you except as may be permitted in a separate confidentiality agreement between you and CA. Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.
    [Show full text]
  • Study of Implementing Zachman Framework for Modeling Information Systems for Manufacturing Enterprises Aggregate Planning
    Proceedings of the 2011 International Conference on Industrial Engineering and Operations Management Kuala Lumpur, Malaysia, January 22 – 24, 2011 Study of Implementing Zachman Framework for Modeling Information Systems for Manufacturing Enterprises Aggregate Planning Radwan, A., and Majid Aarabi Department of Manufacturing and Industrial Engineering, Faculty of Mechanical Engineering, Universiti Teknologi Malaysia, 81310 Skudai, Johor, MALAYSIA [email protected] , [email protected] Abstract Response time on orders of customers is becoming a critical issue to achieve a competitive advantage. A major problem is a lack of strategic perspective of information systems. A need for adequate tools and methodologies to model the system structure and to define integrated requirements is a must for the manufacturing enterprises. This paper presents a study of implementing Zachman Framework ZF to model information systems for aggregate planning activities within the manufacturing enterprises. An Information System for simulating the aggregate planning activities such as evaluating the various planes for determining the production rate, inventory levels, subcontracting and the required human resources is modeled. This is assumed to provide control over the order processes and reporting the orders status online. It is assumed that the customer can have access to the system to follow up with his order progressing status. Managers would have control on orders transactions, and workshop floor supervisors could monitor and control the orders processing online. Some artifacts are introduced to ZF to enhance its capability for modeling of information systems for Aggregate Planning in Manufacturing Enterprises. Keywords: Manufacturing Information Systems, Zachman Framework, Enterprise architecture, Aggregate planning, Modeling. 1. Introduction Nowadays, the enterprises encounter with numerous amount of data.
    [Show full text]
  • Erwin Data Modeler Workgroup Edition Implementation And
    erwin® Data Modeler Workgroup Edition Implementation and Administration Guide Release 9.8 This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as the “Documentation”), is for your informational purposes only and is subject to change or withdrawal by erwin Inc. at any time. This Documentation is proprietary information of erwin Inc. and may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of erwin Inc. If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all erwin Inc. copyright notices and legends are affixed to each reproduced copy. The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to erwin Inc. that all copies and partial copies of the Documentation have been returned to erwin Inc. or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, ERWIN INC. PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL ERWIN INC. BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF ERWIN INC.
    [Show full text]
  • Examining Capabilities As Architecture
    September 2013 BPTrends ▪ Examining Capabilities as Architecture Examining Capabilities as Architecture Ralph Whittle Introduction This Article is a direct response to one written by Mike Rosen titled, “Are Capabilities Architecture?” [1] published in February 2013 by BPTrends It offers a different and contrasting point of view on accepting capability modeling and mapping as “architecture.” Business Architecture (BA) approaches and methods, while still evolving, have at least reached a point of maturity where the enterprise can fairly assess how it will develop and advance this initiative. As with any emerging field, a variety of approaches and methods will develop and enjoy success. From an historical perspective, consider the number of Business Process Management (BPM), Enterprise Architecture (EA) and Service-Oriented Architecture (SOA) approaches that have matured over the years. And no doubt, the same will eventually occur with the Business Architecture over the next few years. However, just as with the BPM, EA and SOA some different and contrasting points of view will find their way into the various Business Architecture approaches, techniques and methods. Today, at least two different and contrasting organizing principles are considered for Business Architecture. One is “capability centric” and the other is “process centric.” This article advocates and supports the “process centric” organizing principle, specifically using a value stream which is an end-to-end collection of activities that creates a result for a “customer,” who may be the ultimate customer or an internal “end user” of the value stream. The value stream has a clear goal: to satisfy (or, better, to delight) the customer.[2] This is a well known term, familiar in Six Sigma, Lean Manufacturing and BPM approaches.
    [Show full text]
  • CA Erwin Data Modeler
    CA ERwin Data Modeler From Wikipedia, the free encyclopedia CA ERwin Data Modeler (ERwin) is a software tool for data modeling (data requirements analysis, database design etc.) of custom developed information systems, including databases of transactional systems and data marts. ERwin's data modeling engine is based upon the IDEF1X method, although it now supports diagrams displayed with information engineering notation as well. Logic Works stylised "ERwin" from an abbreviation of "Entity Relationships" and Microsoft's "Windows". Contents [hide] 1 History 2 Distinguishing features 3 Physical Modeling support 4 Limitations 5 Associated products 6 See also 7 Publications 8 References 9 External links History[edit] ERwin CASE tool on Windows 2000 ERwin was created by Logic Works. It was acquired in 1998 by Platinum Technology, which was later acquired in May 1999 by Computer Associates, who added it to their AllFusion suite under the name AllFusion ERwin Data Modeler. The tool was later renamed to CA ERwin Data Modeler. Distinguishing features[edit] Logical Data Modeling: Purely logical models may be created, from which physical models may be derived. Combinations of logical and physical models are also supported. Supports entity-type and attribute logical names and descriptions, logical domains and data types, as well as relationship naming. Physical Data Modeling: Purely physical models may be created as well as combinations of logical and physical models. Supports the naming and description of tables and columns, user defined data types, primary keys, foreign keys, alternative keys and the naming and definition of constraints. Support for indexes, views, stored procedures and triggers is also included.
    [Show full text]
  • CA Erwin Data Modeler Data Modeling Overview Guide
    CA ERwin® Data Modeler Data Modeling Overview Guide Release 9.64.01 This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as the “Documentation”), is for your informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection wi th that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.
    [Show full text]
  • Enterprise Architecture 1 Zachman Framework
    member of The Zachman Framework Prof. Dr. Knut Hinkelmann Introduction to Business-IT Alignment and Enterprise Architecture 1 Zachman Framework ■ Regarded the origin of enterprise architecture frameworks (originally called "Framework for Information Systems Architecture") ■ First version published in 1987 by John Zachman ■ It is still further developed by Zachman International (http://www.zachman.com) ■ Often referenced as a standard approach for expressing the basic elements of enterprise architecture Zachman, J.A., 1987. A framework for information systems architecture. IBM Systems Journal, 26(3). Prof. Dr. Knut Hinkelmann Enterprise Architecture Frameworks 2 Rationale of the Zachman Architecture ■ There is not a single descriptive representation for a complex object ... there is a SET of descriptive representations. ■ Descriptive representations (of anything) typically include: ♦ Perspectives Abstractions ♦ Abstractions Perspectives (Zachman 2012) Prof. Dr. Knut Hinkelmann Enterprise Architecture Frameworks 3 Dimension 1 – Perspectives Zachman originally used the analogy of classical architecture For the different stakeholders different aspects of a building are relevant - models of the building from different perspectives Bubble charts: conceptual representation delivered by the architect Architect's drawing: transcription of the owner's perceptual requirements – owner's perspective Architect's plans: translation of the owner's requirements into a product – designer's perspective Contractor's plans: phases of operation, architect's plans contrained by nature and technology – builder's perspective Shop plans: parts/sections/components of building details (out-of-context specification) – subcontractor's perspective The building: physical building itself (Zachman 1987) Prof. Dr. Knut Hinkelmann Enterprise Architecture Frameworks 4 Dimension 1: Architectural Representations with analogies in Building and Information Systems (Zachman 1987) Prof.
    [Show full text]
  • 075 06/09/2017 HSSCCG17J00025 Depart
    ORDER FOR SUPPLIES OR SERVICES I PAGE 0~ PAGES IMPORTANT: Mark all packages and papers with contract and/or order numbers. I 1 13 1. DATE OF ORDER 2. CONTRACT NO. g' aE~ 6. SHIP TO. HSHQDC-13- - 075 06/09/2017 a. NAME OF CONSIGNEE 3. ORDER NO. 14. REQUISITION/REFERENCE NO. Departme nt of Homeland Security HSSCCG17J00025 5. ISSUING OFFICE (Address correspondence to) b. STREET ADDRESS USCIS Contracting Office Citi zenshi p & Immigration Services Depar t ment of Home l a nd Securi ty Chi ef Informa t ion Officer 70 Kimball Avenue 5th floor #102 South Burlington VT 054 03 111 Massachus etts Ave NW c CITY Id . STATE I:e ZIP CODE Washington DC 20001 7. TO I SHIP VIA a NAME OF CONTRACTOR SEVATEC INC 8. TYPE OF ORDER b. COMPANY NAME O a PURCHASE IRJ b. DELIVERY c. STREET ADDRESS REFERENCE YOUR: 3112 FAIRVI EW PARK DR IVE Sevatec Of fer Except lor billing instructions on the reverse, this delivery order is Dated Decembe r 2, 2016 subject to instructions contained on thiS side only of this form and is Please lumish the lollow1ng on the terms issued subject to the terms and and conditions specified on both sides or conditions or the above-(lumbered d. CITY Ie . STATE Ir . ZIP CODE this order and on the attached sheet, il contract FALLS CHURCH VA 2204 245 04 anv. 1ncludinc deliverv as ind1cated. 9. ACCOUNTING AND APPROPRIATION DATA 10. REQUISITIONING OFFICE See Schedul e users Co ntracting Office 11 . BUSINESS CLASSIFICATION (Check appropriate box(es)) 12.
    [Show full text]
  • The Selection of Cloud Services for {ER}-Diagrams Construction In
    The selection of cloud services for ER-diagrams construction in IT specialists databases teaching Tetiana A. Vakaliuk1,4, Olha V. Korotun1 and Serhiy O. Semerikov2,3,4,5 1Zhytomyr Polytechnic State University, 103 Chudnivska Str., Zhytomyr, 10005, Ukraine 2Kryvyi Rih State Pedagogical University, 54 Gagarin Ave., Kryvyi Rih, 50086, Ukraine 3Kryvyi Rih National University, 11 Vitalii Matusevych Str., Kryvyi Rih, 50027, Ukraine 4Institute of Information Technologies and Learning Tools of the NAES of Ukraine, 9 M. Berlynskoho Str., Kyiv, 04060, Ukraine 5University of Educational Management, 52-A Sichovykh Striltsiv Str., Kyiv, 04053, Ukraine Abstract One of the main aspects of studying databases in higher education institutions by future IT specialists is database design and software product development. This, in turn, is the most important problem of the developer’s interaction with the customer. To facilitate the process of database design, ER-diagrams are used, which are based on the concepts of “Entity” and “Relationship”. An ER diagram allows you to present a database in the form of visual graphical objects that define a specific subject area. The article considers the available cloud services for the construction of ER-diagrams for learning databases of future IT specialists and their selection the method expert evaluation. For this purpose, the criteria and indicators for the selection of cloud services for the construction of ER-diagrams of databases by future information technology specialists have been determined. As a result, it was found that the cloud services Dbdesigner.net and Lucidchart are the most convenient to learn. It is determined that for a teacher of a higher education institution the use of cloud services is an opportunity to use licensed software in education without additional costs.
    [Show full text]
  • A Methodology to Create Data Architecture in Zachman Framework
    World Applied Sciences Journal 3 (Supple 2): 43-49, 2008 ISSN 1818-4952 © IDOSI Publications, 2008 A Methodology to Create Data Architecture in Zachman Framework 1Reza Rezaei and 2Fereidoon Shams 1Computer Engineering Department, Faculty of Engineering,Islamic Azad University of Saveh Branch, Saveh, Iran 2Computer Engineering Department, Shahid Beheshti University, Tehran, Iran Abstract: Lack of methodology for applying Zachman framework is a challenge that an architect who use it will face. Although there have been methodologies which were some how mapped with this framework but until now no methodology has supported one or more columns of this framework completely and in an integrated way. In this paper, we proposed an integrated process for developing Data Architecture views in Zachman framework. One of the most important advantages of this approach is its property which is based on the enterprise's strategic plan, goals and responsibilities, Business and applications Architecture. Key words : Zachman framework • methodology • data architecture • enterprise architecture framework • modeling. INTRODUCTION The rest of this paper is organized as follows. In Section 2, we introduce Zachman Framework. It goes without saying that nowadays utilizing Next, the problem was defined in section 3. We discuss information and communication technologies in our proposed approach in section 4 and present a enterprises is one of the most challenging tasks. An case study in section 5. Finally, in section 6, we enterprise is considered a set of elaborate physical and make conclusions and suggest some comments for logical processes in which information flow plays a future works. crucial role. The common way to comprehend procedures in an enterprise is to provide views of Zachman framework: In 1987, an IBM researcher, components within that enterprise, which is called named John A.
    [Show full text]