Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or ERDs for short.
The definitive reference for entity relationship modelling is generally given as Peter Chen's 1976 paper. However, variants of the idea existed previously (see for example A.P.G. Brown) and have been devised subsequently.
A sample ER diagram
Definition: An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.
Also Known As: ER Diagram, E-R Diagram, entity-relationship model
Examples: Consider the example of a database that contains information on the residents of a city. The ER digram shown in the image above contains two entities -- people and cities. There is a single "Lives In" relationship. In our example, due to space constraints, there is only one attribute associated with each entity. People have names and cities have populations. In a real-world example, each one of these would likely have many different attributes.
Introduction
This document is an entity-relationship diagram, or “ERD,” for a system to manage electronic resources. An ERD is a model that identifies the concepts or entities that exist in a system and the relationships between those entities. An ERD is often used as a way to visualize a relational database: each entity represents a database table, and the relationship lines represent the keys in one table that point to specific records in related tables. ERDs may also be more abstract, not necessarily capturing every table needed within a database, but serving to diagram the major concepts and relationships. This ERD is of the latter type, intended to present an abstract, theoretical view of the major entities and relationships needed for management of electronic resources. It may assist the database design process for an e-resource management system, but does not identify every table that would be necessary for an electronic resource management database.
This ERD should be examined in close consultation with other components of the Report of the DLF Electronic Resource Management Initiative, especially Appendix E (Data Element Dictionary) and Appendix F (Data Structure). The ERD presents a visual representation of e-resource management concepts and the relationships between them. The Data Element Dictionary identifies and defines the individual data elements that an e-resource management system must contain and manage, but leaves the relationship between the elements to be inferred by the reader. The Data Structure associates each data element with the entities and relationships defined in the ERD. Together, these three documents form a complete conceptual data model for e-resource management.
Overview
The 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 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 universe of discourse (i.e. 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".
There are a number of conventions for entity-relationship diagrams (ERDs). The classical notation is described in the remainder of this article, and mainly relates to conceptual modeling. There are a range of notations more typically employed in logical and physical database design, such as IDEF1X.
There are 3 relationship link that is:
1. One To One : Mount the relation one to one expressed with one occurence of at first entitas, only have one relation with one occurence of at secondary entitas conversely.
2. One To Many or Many to One : Mount the relation one to a lot of is equal to a lot of to one depended from which direction of the relation of dilihat.Untuk one occurence of at first entitas can have the more relation with the occurence of at secondary entitas, if on the contrary one occurence of at secondary entitas can only have the hubugan with one occurence of at first entitas.
3. Many To Many : happened by if every occurence of at a entitas have a lot of relation with the occurence of at other entitas.
Symbolic notation in diagram ER is:
1. Long Persegi express the gathering entitas
2. Radian express the attribute
3. Rhombic of menyakatan of relationship gathering
4. Mark with lines as link of between relationship gathering with the gathering of entitas and Gathering Entitas with its attribute
Connection
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. Entities are represented as rectangles.
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. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.
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. Attributes are represented as ellipses connected to their owning entity sets by a line.
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.
Lines are drawn between entity sets and the relationship sets they are involved in. If all entities in an entity set must participate in the relationship set, a thick or double line is drawn. This is called a participation constraint. If each entity of the entity set can participate in at most one relationship in the relationship set, an arrow is drawn from the entity set to the relationship set. This is called a key constraint. To indicate that each entity in the entity set is involved in exactly one relationship, a thick arrow is drawn.
ER diagramming tools
There are many ER diagramming tools. Some of the proprietary ER diagramming tools are Avolution, dbForge Studio for MySQL, DeZign for Databases, ConceptDraw, ER/Studio, ERwin, MEGA International, OmniGraffle, Oracle Designer, PowerDesigner, Rational Rose, SmartDraw, Sparx Enterprise Architect, SQLyog, Toad Data Modeler, Microsoft Visio, and Visual Paradigm. A freeware ER tool that can generate database and application layer code (webservices) is the RISE Editor.
Some free software ER diagramming tools that can interpret and generate ER models, SQL and do database analysis are StarUML, MySQL Workbench, and SchemaSpy. Some free software diagram tools which can't create ER diagrams but just draw the shapes without having any knowledge of what they mean or generating SQL are Kivio, Dia. Although DIA diagrams can be translated with tedia2sql.
Conclusions
This entity-relationship diagram depicts the major concepts and relationships needed for managing electronic resources. It is neither a complete data model depicting every necessary relational database table, nor is it meant to be a proscriptive design for implementations of electronic resource management systems. Alternate models may capture the necessary attributes and relationships. Hopefully this document, along with the other components of the Report of the DLF Electronic Resource Management Initiative will assist developers with envisioning the complexity of the environment that an ERM system must address, and ensure that crucial relationships and features will be included in ERM products.
REFERENCE
http://en.wikipedia.org/wiki/Entity-relationship_model
http://www.library.cornell.edu
http://databases.about.com/cs/specificproducts/g/er.htm
Tidak ada komentar:
Posting Komentar