Entity Relationship Diagrams
Entity Relationship Diagrams (ERDs) are visual representations of the relationships between entities in a database. They use symbols and lines to illustrate how different entities are connected and the nature of their relationships, such as one-to-one, one-to-many, or many-to-many. ERDs are commonly used in database design to help developers understand and plan the structure of a database system.
4 Key excerpts on "Entity Relationship Diagrams"
eBook - ePub- John R. Talburt(Author)
- 2011(Publication Date)
- Morgan Kaufmann(Publisher)
...F. Codd (1970), was later refined into what we now know as the ERM by Peter Chen (1976). In the ERM, information systems are conceptualized as a collection of entities, each having a set of descriptive attributes and also having well-defined relationships with other entities. Figure 1.1 shows a simple ERD illustrating a data model with three entity types: Instructor, Course, and Student. The line connecting the Instructor and Course entity types indicates that there is a relation between them. Similarly, the diagram shows that Course and Student entity types are related. Furthermore, in the ERD style used here, the adornments on the relation line give more detail about these relationships. For example, the triangular configuration of short lines, sometimes called a crow's foot, at the junction of the relation line with an entity indicates a many-to-one relationship. In this example it indicates that one Instructor entity may be related to (be the instructor for) more than one Course entity. The additional adornment of a single bar with the crow's foot further constrains the relation by indicating that each Instructor entity must be related to (assigned to) at least one Course entity. The double bar at the junction of this same relation and the Instructor entity is used to indicate an exactly-one relationship. Here it represents the constraint that each Course entity must be related to (has assigned to it) one, and only one, Instructor entity. The crow's foot symbol with a circle that appears at both ends of the relation between the Course and Student entities indicates a zero-to-many relation. This means that any given Student entity may be related to (enrolled in) several Course entities, or in none. Conversely, any given Course entity may be related to (have in it) several Student entities, or none. Figure 1.1 Example of a Simple ERD Each entity type also has a set of attributes that describes the entity...
- Gerhard Greeff, Ranjan Ghoshal(Authors)
- 2004(Publication Date)
- Newnes(Publisher)
...requirements to plan, perform and monitor the activities: • Identifies information required to perform an activity • Focuses on business needs rather than software requirements • Is structured around activities and technology • Maintains a high level of redundancy. Entity relationship models Models the concepts (people, places, things, etc.) of interest to an enterprise and helps to identify the data that must be captured and stored to satisfy information requirements. The entity relationship (ER) modeling technique is a discipline used to illuminate the microscopic relationships among data elements. The highest art form of ER modeling is to remove all redundancy in the data. This is immensely beneficial to transaction processing because transactions are made very simple and deterministic. The transaction of updating a customer’s address may devolve to a single record lookup in a customer address master table. This lookup is controlled by a customer address key, which defines uniqueness of the customer address record and allows an indexed lookup that is extremely fast. It is safe to say that the success of transaction processing in relational databases is mostly due to the discipline of ER modeling (refer Figure 5.2). Figure 5.2 ER model • Identifies the concept of relevance • Concept can be abstract or concrete • Structured around objects • Optimized for updates • Reusable and generic, no redundancy • Relevant to current and future activities. Dimensional models Dimensional models (DMs) are intuitive and identify the data required for business analysis and decision support. The DM is a logical design technique often used for data warehouses. It is the only viable technique for databases that are designed to support end-user queries in a data warehouse. Every dimensional model is composed of one table with a multi-part key, called the fact table, and a set of smaller tables called dimension tables...
eBook - ePubStreamlining Business Requirements
The XCellR8 Approach
- Gerrie Caudle(Author)
- 2009(Publication Date)
- Berrett-Koehler Publishers(Publisher)
...CHAPTER 4 The XCellR8™ Approach: The Event Entity Relationship Diagram and Data Attribution N ow that you know how to develop an event process model, let’s look at the other components that should be included in the business requirements document. The Event Entity Relationship Diagram The event entity relationship diagram (EERD) illustrates the relationships between the objects identified in an event process model. The main purpose of the EERD is to help us identify missing requirements. Missing requirements are the hardest requirements errors to correct.1 (Similarly, if a required object is not present in a business event, its absence will prevent us from responding appropriately to the business event.) The EERD will help you understand the different pieces of information that will be thrown at you during the requirements session. You have to know where all the information belongs, what that information may allow you to discover, and what each piece of information will let you do. This will help you define the requirements much more effectively and comprehensively. Remember that an object is a person, place, thing, or concept—a noun—participating in a business event. Some of the nouns you’ll discover during the requirements-gathering process may not be objects, but data attributes, pieces of data that belong to and describe objects. To determine whether a noun is an object or an attribute, try to further decompose it into descriptive attributes. If the noun cannot be further decomposed, it is an attribute. If the noun can be further decomposed, it is an object. It can be difficult to define objects. Sometimes, even the naming of an object itself is a daunting task. I remember facilitating a requirements session for a parts warranty tracking system at which the subject matter experts struggled to articulate what a “part” was! Related to the EERD is another essential component of the business requirements document: the data dictionary...
eBook - ePubCritical Systems Analysis and Design
A Personal Framework Approach
- Nandish Patel(Author)
- 2004(Publication Date)
- Routledge(Publisher)
...Conversely, this separation enables database administrators to change the physical database design with no impact on the logical design and users. They may need to do so to improve the efficiency of the database. People are not involved in database design, to them the DBMS is a black box. The DBMS provides physical data independence. As it is not possible to predict the volume of actual queries of the database, estimates are generated and used to anticipate usage patterns. The structure of the data defined during systems analysis determines the data model of the database and the data models from systems analysis are used to design the logical database. The logical record structure and how the records will be accessed is derived from the E-R model. Each set of E-R diagrams can be converted into a logical record type. Logical record structures are defined at the system level and include the primary keys of records. For example, for a relational database model the conceptual database is determined by converting the E-R model into a relational model. An entity is represented as a relation. A relationship is represented as a relation too with the primary keys of the entities in the relationship. 11.7 Object-oriented systems design The focus in object-oriented design is on the architecture of the new IS, quality and standards issues. Systems designers create additional classes for files or database storage. Unlike structured systems design, in object-oriented systems design a class model is not transformed but refined. In this sense there is no separation between systems analysis and systems design in object-oriented systems ontology. The class systems model produced during systems analysis is enhanced with more detail but remains essentially the same model, though different diagrams are used to produce the logical design or implementation...
