ER Diagram

Download ER Diagram

Post on 18-Aug-2014

325 views

Category:

Documents

3 download

Embed Size (px)

TRANSCRIPT

<p>Banyak Perusahaan Tidak Mempunyai Standar Dokumentasi Pengembangan SoftwareApril 2, 2008 oleh Arry Akhmad Arman Bagaimanapun bentuknya, saya kira perusahaan-perusahaan besar pada umumnya mempunyai standar proses pengembangan software yang secara umum biasanya disebut SDLC (Software Development Life Cycle). Di beberapa perusahaan yang manajemen TI nya sudah mapan, SDLC tersebut biasanya diterapkan secara konsisten baik untuk pengembangan software oleh pihak internal, maupun pengembangan software yang melibatkan pihak eksternal (outsourcing). SDLC yang diterapkan secara ketat secara tidak langsung akan meningkatkan kualitas software yang dihasilkan. Bagian dari SDLC juga mensyaratkan adanya dokumentasi software yang baik. Apakah SDLC saja serta keberadaan dokumentasi software sudah cukup? Jawabannya biasanya baru diketahui setelah ada masalah-masalah berkaitan dengan software aplikasi yang sudah pernah dibuat. Beberapa permasalahan tipikal diantaranya adalah sebagai berikut: 1. Dokumentasi software ternyata tidak lengkap, ada bagian penting dari software yang tidak dijelaskan dengan cukup, sehingga sulit untuk memahaminya. 2. Format dan struktur dokumen berbeda-beda 3. Cara pemodelan berbeda-beda. Mungkin ada yang masih menggunakan flowchart + ER Diagram saja, ada yang menambahkan Data Flow Diagram (DFD), ada yang mencampur adukan UML dengan DFD, atau ada yang secara penuh sudah menerapkan UML. Permasalahan-permasalahan tersebut di atas akan menghambat tujuan-tujuan sebagai berikut: 1. Melakukan modifikasi software menjadi sulit dilakukan. Kadang perusahaan ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi. 2. Melakukan pengembangan lebih lanjut menggunakan vendor lain. Dokumentasi yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh pihak lain yang akan meneruskan pekerjaan tersebut. 3. Melakukan integrasi dengan aplikasi lain. Ketika sistem berkembang dan ada tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan modifikasi algoritma untuk mencapai tujuan integrasi. Bagaimana solusinya? Sederhana! Buatlah standar (template) dokumentasi pengembangan software aplikasi di perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan (SDLC). Semua pengembangan software, baik yang dilakukan oleh pihak internal maupun cara outsource harus membuat dokumentasi sesuai standar tersebut. Hal yang harus diingat adalah:</p> <p>Jangan membuat standar dokumentasi yang bentuknya tidak biasa. Saya sarankan untuk mengadopsi dari suatu standar, lalu lakukan penyesuaian minor. Untuk pemodelannya, saya menganjurkan untuk menggunakan UML secara penuh. Nah, kalau ini sudah tercapai, anda buka dokumen software manapun selalu sama bentuknya dan kelengkapannya cenderung lebih terjamin karena mengikuti template yang sudah ada. Semoga bermanfaat! Ditulis dalam Manajemen TI, Teknologi Informasi | Bertanda software, standar dokumentasi, standar dokumentasi pengembangan software, UML | 6 Komentar Suka Be the first to like this post.</p> <p>6 Tanggapan</p> <p>1. pada April 2, 2008 pada 9:48 am | Balas</p> <p>kaitokid724</p> <p>Tulisan artikel di blog Anda bagus-bagus. Agar lebih bermanfaat lagi, Anda bisa lebih mempromosikan dan mempopulerkan artikel Anda di infoGue.com ke semua pembaca di seluruh Indonesia. Salam Blogger! http://www.infogue.com/ http://www.infogue.com/bisnis_keuangan/banyak_perusahaan_tidak_mempunyai_sta ndar_dokumentasi_pengembangan_software/</p> <p>2. pada April 2, 2008 pada 12:32 pm | Balas Identifikasi Ancaman dalam Disaster Recovery Jangan Terfokus Hanya Pada Bencana Alam | Sharing Vision [...] Artikel diambil dari sini, dari Blog Arry Akhmad [...]</p> <p>3. pada April 2, 2008 pada 1:01 pm | Balas SW = program + data + dokumentasi Tepat sekali bu!</p> <p>ayi purbasari</p> <p>4. pada Desember 16, 2008 pada 8:45 pm | Balas</p> <p>agus sukoco</p> <p>Buatlah standar (template) dokumentasi pengembangan software aplikasi di perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan (SDLC).?? standardnya apa ya?</p> <p>5. pada Desember 17, 2008 pada 7:19 am | Balas</p> <p>Arry Akhmad Arman</p> <p>SDLC hanya menjelaskan siklus. Pengembangan yang menggunakan siklus yang sama bisa mempunyai cara mendokumentasikan yang berbeda-beda. MUngkin semuanya benar, tidak ada yang salah, tetapi itu akan menyulitkan bagi perusahaan yang sering melakukan outsource pengembangan aplikasi, karena style-nya berbedabeda. Standar dokumentasi adalah buku panduan standar menyajikan report pengembangan aplikasi, dalam hal ini untuk kemudahan perusahaan yang sering melakukan outsource. SDLC bisa dipilih yang manapun. Walaupun paling kuno, Waterfall masih sering digunakan, karena lebih memudahkan dari sisi manajemen proyek. Standar dokumentasi, sebaiknya simbol-simbolnya menggunakan UML dan diatur penulisannya dengan ketat.</p> <p>6. pada Juli 22, 2010 pada 5:50 pm | Balas Maaf pak, punya contoh format dokumentasi yang baik? boleh saya minta? untuk dijadikan referensi. thanks</p> <p>Indri</p> <p>From Wikipedia, the free encyclopedia Jump to: navigation, search</p> <p>A sample Entity-relationship diagram using Chen's notation In software engineering, an entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs. The definitive reference for entity-relationship modeling is Peter Chen's 1976 paper.[1] However, variants of the idea existed previously,[2] and have been devised subsequently.</p> <p>Contents[hide] </p> <p>1 Overview 2 The building blocks: entities, relationships, and attributes 3 Diagramming conventions o 3.1 Crow's Foot Notation 4 ER diagramming tools 5 See also 6 References 7 Further reading 8 External links</p> <p>[edit] OverviewThe first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a</p> <p>database. The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain area of interest. In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design".</p> <p>[edit] The building blocks: entities, relationships, and attributes</p> <p>Two related entities</p> <p>An entity with an attribute</p> <p>A relationship with an attribute</p> <p>Primary key An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world.[3] An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term. Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem. The model's linguistic aspect described above is utilized in the declarative database query language ERROL, which mimics natural language constructs.</p> <p>Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute. Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key. Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set. In other words, a relationship set corresponds to a relation in mathematics, while a relationship corresponds to a member of the relation. Certain cardinality constraints on relationship sets may be indicated as well.</p> <p>[edit] Diagramming conventionsEntity sets are drawn as rectangles, relationship sets as diamonds. If an entity set participates in a relationship set, they are connected with a line. Attributes are drawn as ovals and are connected with a line to exactly one entity or relationship set. Cardinality constraints are expressed as follows: </p> <p>a double line indicates a participation constraint, totality or surjectivity: all entities in the entity set must participate in at least one relationship in the relationship set; an arrow from entity set to relationship set indicates a key constraint, i.e. injectivity: each entity of the entity set can participate in at most one relationship in the relationship set; a thick line indicates both, i.e. bijectivity: each entity in the entity set is involved in exactly one relationship. an underlined name of an attribute indicates that it is a key: two different entities or relationships with this attribute always have different values for this attribute.</p> <p>Attributes are often omitted as they can clutter up a diagram; other diagram techniques often list entity attributes within the rectangles drawn for entity sets.</p> <p>Two related entities shown using Crow's Foot notation Chen's notation for entity-relationship modeling uses rectangles to represent entities, and diamonds to represent relationships appropriate for first-class objects: they can have attributes and relationships of their own. Related diagramming convention techniques: </p> <p>Bachman notation EXPRESS IDEF1X[4] Martin notation (min, max)-notation of Jean-Raymond Abrial in 1974 UML class diagrams</p> <p>[edit] Crow's Foot Notation</p> <p>Crow's Foot notation is used in Barker's Notation, SSADM and Information Engineering. Crow's Foot diagrams represent entities as boxes, and relationships as lines between the boxes. The ends of these lines are shaped to represent the cardinality of the relationship. Usage of Chen notation is more prevalent in the United States, while Crow's Foot notation is used primarily in the UK. Crow's Foot notation was used in the 1980s by the consultancy practice CACI. Many of the consultants at CACI (including Barker) subsequently moved to Oracle UK, where they developed the early versions of Oracle's CASE tools, introducing the notation to a wider audience. Crow's Foot notation is used by these tools: ARIS, System Architect, Visio, PowerDesigner, Toad Data Modeler, DeZign for Databases, Devgems Data Modeler, OmniGraffle, and MySQL Workbench. CA's ICASE tool, CA Gen aka Information_Engineering_Facility also uses this notation.</p> <p>[edit] ER diagramming toolsThere are many ER diagramming tools. Some free software ER diagramming tools that can interpret and generate ER models, SQL and do database analysis are MySQL Workbench (formerly DBDesigner), and Open ModelSphere (open-source). A freeware ER tool that can generate database and application layer code (webservices) is the RISE Editor. The Open Source Erviz takes a simple textual description of the ERD and then uses Graphviz to automatically produce a nice, if slightly spaced out, layout. Some of the proprietary ER diagramming tools are ARIS, Avolution, Aqua Data Studio, dbForge Studio for MySQL, DeZign for Databases, ER/Studio, Devgems Data Modeler, ERwin, MEGA International, ModelRight, OmniGraffle, Oracle Designer, PowerDesigner, Rational Rose, Sparx Enterprise Architect, SQLyog, System Architect, Toad Data Modeler, SQL Maestro, Microsoft Visio, Visible Analyst, and Visual Paradigm. Some free software diagram tools just draw the shapes without having any knowledge of what they mean, nor do they generate SQL. These include Gliffy[5], Kivio and Dia. DIA diagrams, however, can be translated with tedia2sql.</p> <p>Database design is the process of producing a detailed data model of a database. This logical data model contains all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database. A fully attributed data model contains detailed attributes for each entity. The term database design can be used to describe many different parts of the design of an overall database system. Principally, and most correctly, it can be thought of as the logical design of the base data structures used to store the data. In the relational model these are the tables and views. In an object database the entities and relationships map directly to object classes and named relationships. However, the term database design could also be used to apply to the overall process of designing, not just the base data structures, but also the forms and queries used as part of the overall database application within the database management system (DBMS).[1]</p> <p>The process of doing database design generally consists of a number of steps which will be carried out by the database designer. Usually, the designer must: </p> <p>Determine the relationships between the different data elements. Superimpose a logical structure upon the data on the basis of these relationships.[2]</p> <p>Contents[hide] </p> <p>1 ER Diagram (Entity-relationship model) 2 The Design Process 3 Determining data to be stored 4 Normalization 5 Types of Database design o 5.1 Conceptual schema o 5.2 Logically structuring data o 5.3 Physical database design 6 See also 7 References 8 Further reading 9 External links</p> <p>[edit] ER Diagram (Entity-rel...</p>