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
AlbumAn 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 | AL05is 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
YearThese attributes define the information song records can contain.
The Artist entity might have:
Artist ID
Artist NameDifferent entities can have different attribute sets.
For Song:
Song IDcan serve as the unique identifier.
For Artist:
Artist IDcan identify artist records.
For Album:
Album IDcan 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 ---- AlbumThe 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 BandS002 | Northern Lights | A002The shared value:
A002lets 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 SongsThat 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 NameThat 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.