I have started to study ER diagrams. When I browse through the ER diagram tutorials, I found something like figure 1:
I tried to create a sample ER Diagram in MySQL Workbench like:
I browsed Google images for ER Diagrams, and I saw both types of images. I don't know the similarities and differences between them.
One can say that a proper entity-relationship diagram is that which was created using the constructs introduced by Dr. P. P. Chen (e.g., rectangular and diamond-shaped boxes) in his famous 1976 paper entitled The Entity-Relationship Model—Toward a Unified View of Data.
Regarding your specific comparison, Figure 1 displays symbols (perhaps shapes) that look much closer to the Chen’s originals than the ones shown in Figure 2.
Pertinent considerations
But, if a certain drawing portrays (a) entity types, and (b) the corresponding entity types interrelationships, then it can be considered some kind of entity-relationship representation (and multiple methods are associated in a certain way with the work of Dr. Chen).
In this respect, IDEF1X is a data modeling technique —established as a standard in 1993 by the U.S. National Institute of Standards and Technology (NIST)— that takes Dr. E. F. Codd’s relational concepts (e.g., foreign keys and alternate keys) and combines them with entity-relationship ideas and first-order logic elements in order to assist in the composition of more rich and expressive diagrams (which can, e.g., depict supertype-subtype associations, entity type properties or attributes, etc.).
There are other efforts that produced, e.g., the enhanced entity-relationship approach, which also added new notions to the original view.
These paradigms (some more complete than the others) are platforms that were developed to capture business-domain-specific data meaning (i.e., data semantics). With their help, a practitioner can supply communication instruments that facilitate managing the data as it actually is, i.e., an important and independent asset, presenting the scenario of interest from a conceptual perspective (sometimes incorporating logical level aspects) to all the involved parties.
Asides
Concerning some aside comments, it must be said that (i) application program components are different from (ii) database structures, therefore they definitely hold different implications. In this manner, you can use “general” implements like UML sketches to shape object-oriented application program items, e.g., classes (basically, object templates), methods (i.e., object processes, behaviour), etc. In addition, application program components are part of the external level of a computerized information system, so any kind of sketch depicting them should not necessarily have a one-to-one correspondence with a diagram illustrating structures of the conceptual level.
That being so, and since software development is a profession that entails accuracy, identifying and employing the right tool for each clearly delimited task is paramount.
The first one is traditional Chen's notation.
The second one is modern Crow Foot or Baker's notation, used today by majority of tools and people. It is perferred because it is more readable and uses less space.
The first is an ER-Diagram (Entity Relationship Diagram).
The second is an EA Diagram (Entity Attribute Diagram).
