You have already worked with:
Data modeling uses broader terms for these same ideas.
Three important concepts are:
These concepts prepare you to read and create an entity-relationship diagram.
An entity is a category of thing the data system needs to represent.
In a music library, useful entities might include:
Song
Artist
Album
An entity is not one particular row.
It describes a kind of record.
The entity Song represents the kind of information stored for songs.
If Song is an entity, then:
S002 | Northern Lights | A002 | AL05
is one record representing one particular Song instance.
This is similar to the class/object distinction you encountered in UML, but entity-relationship modeling has a data-oriented purpose.
The formal comparison with UML comes later.
For now:
Entity → kind of record
Record → one particular item of that kind
An attribute is a field associated with an entity.
The Song entity might have:
Song ID
Title
Artist ID
Album ID
Genre
Year
These attributes define the information song records can contain.
The Artist entity might have:
Artist ID
Artist Name
Different entities can have different attribute sets.
For Song:
Song ID
can serve as the unique identifier.
For Artist:
Artist ID
can identify artist records.
For Album:
Album ID
can identify albums.
The unique identifier gives each record within the entity its own identity.
A music library needs more than isolated entities.
Songs are connected to artists.
Songs can be connected to albums.
Conceptually:
Artist ---- Song ---- Album
The relationship tells us that the records are not independent.
A particular song belongs to an artist and may belong to an album.
Suppose:
A002 | Example Band
S002 | Northern Lights | A002
The shared value:
A002
lets the song record connect to the artist record.
At the data level, IDs make the relationship usable.
At the model level, we describe the entities as related.
One artist can have many songs.
Conceptually:
one Artist → many Songs
That does not mean every artist must have the same number of songs.
It describes the possible relationship structure.
Likewise, one album can contain many songs.
The next batch introduces ERD notation for expressing these relationships visually.
Avoid creating an entity that contains unrelated information simply because all of it appears in the same spreadsheet.
For example, an Artist entity should describe artists.
A Song entity should describe songs.
Separating concepts can reduce repetition and make relationships clearer.
Consider:
Artist Name
That naturally describes the Artist entity.
If every Song record repeats the artist's full descriptive information, the dataset may be mixing responsibilities.
A related identifier can connect the song to the artist instead.
This is one reason data modeling helps before a dataset becomes large.
A real song has an enormous amount of possible information.
A music library might choose only:
A real artist also has far more information than:
The model includes what supports the current purpose.
It leaves out what does not.
When analyzing structured data, ask:
What kinds of things need records?
Those are candidates for entities.
What information belongs to each kind of thing?
Those are attributes.
How are the kinds of things connected?
Those are relationships.
The next Learning Activity turns those ideas into a visual entity-relationship diagram.