An entity-relationship diagram (ERD), also known as an entity-relationship model, is a graphical representation of an information system that depicts the relationships among people, objects, places, concepts or events within that system. An ERD is a data modeling technique that can help define business processes and be used as the foundation for a relational database (Rouse, Biscobing, & Aberle, 2018).
Importance of ERDs and their uses
Entity-relationship diagrams provide a visual starting point for database design that can also be used to help determine information system requirements throughout an organization. After a relational database is rolled out, an ERD can still serve as a referral point, should any debugging or business process re-engineering be needed later.
However, while an ERD can be useful for organizing data that can be represented by a relational structure, it can't sufficiently represent semi-structured or unstructured data. It's also unlikely to be helpful on its own in integrating data into a pre-existing information system.
Main components of an ERD
ERDs are generally depicted in one or more of the following models:
- A conceptual data model, which lacks specific detail but provides an overview of the scope of the project and how data sets relate to one another.
- A logical data model, which is more detailed than a conceptual data model, illustrating specific attributes and relationships among data points. While a conceptual data model does not need to be designed before a logical data model, a physical data model is based on a logical data model.
- A physical data model, which provides the blueprint for a physical manifestation -- such as a relational database -- of the logical data model. One or more physical data models can be developed based on a logical data model.
There are three basic components of an entity-relationship diagram:
1. Entities, which are objects or concepts that can have data stored about them.
Example:
2. Attributes, which are properties or characteristics of entities. An ERD attribute can be denoted as a primary key, which identifies a unique attribute, or a foreign key, which can be assigned to multiple attributes.
Example:
3. The relationships between and among those entities.
Example:
For example, an ERD representing the information system for a company's sales department might start with graphical representations of entities such as the sales representative, the customer, the customer's address, the customer's order, the product and the warehouse. (See diagram above.) Then lines or other symbols can be used to represent the relationship between entities, and text can be used to label the relationships.
A cardinality notation can then define the attributes of the relationship between the entities. Cardinalities can denote that an entity is optional (for example, a sales rep could have no customers or could have many) or mandatory (for example, there must be at least one product listed in order.)
While there are tools to help draw entity relationship diagrams, such as computer-aided software engineering (CASE) tools, some relational database management systems also have design capabilities built-in.
Most Complete Cardinality based on Information Engineering (IE), Martin and Crow’s Foot has the following:
Data Structure
— Database has two parts:
- Data
- Data Structure: how the data is organized.
Data Model:
representation of entities and their relationships to the real world
Primary Key:
- a unique identifier in the database
- one or more fields
Data Type
each field in the database needs to be of a certain type
Examples: text, number, dates
Database Management Systems Approaches
— Database Models
— The Hierarchical Model
— The Network Model
— Relational Model
— Normalization
— Associations
Database Models: Hierarchical Model
In a hierarchical database, data is organized like a family tree or organization chart, with branches representing parent records and child records
Example:
Records in parent entities can have many child records, but each child can have only one parent.
Database Models:
1. Network Model
A network database resembles a hierarchical design but provides somewhat more flexibility
Example: In this case you can have multiple children and parents
2. Relational Model
The relational model was introduced during the 1970s and became popular because it was flexible and powerful. Because all the tables are linked, a user can request data that meets specific conditions. New entities and attributes can be added at any time without restructuring the entire database
— A good relational database design eliminates unnecessary data duplications and is, therefore, easier to maintain
— Relationship: joining two tables on a common field
Works Cited
No comments:
Post a Comment