In the Entity-Relationship model, where data is abstractly and conceptually represented in software engineering, associative entities are one part of the model. Relational models are often made to represent data in a database or system, where they are used to organize data into an understandable and readable schema. Entities in a relational model could represent anything, including people, places, objects, events or concepts. Associative entities are connections that describe a relationship between two different entities. These entities can have many-to-many relationships, meaning that one of the associative entities may have multiple relationships and connections to a parent or child entity.

Associative entities convey information about their attributes and their connections. They are considered an entity because they have attributes, and they are considered a relationship because they link entities together. These kinds of entities very frequently have many relationships and connections because they are attributable, but they can have independent meaning from other entities. It is also good practice in a relational model for the associative entity to have, at the very least, one attribute that is distinguishable from the identifier entity. Associative entities can also be participants in relationships separate from the associated entity relationships.

Ad

Primary keys should be a part of associative entities as well, because they are identifiers that adjoin certain tables in a relational model. Though tables may only contain one, primary keys are combinations of columns that uniquely specify rows. There is a difference between unique keys and primary keys, in that primary keys can enforce a “not null” constraint in a table or entity. Another aspect that differentiates primary keys from unique keys is that primary keys are selected as a key of most, or first, importance. Primary indexes are created for the management of primary keys and for ease of use and enforcement by a database manager.

Associative entities are contained in and used by junction tables — tables in a relational model that contain common fields from two or more other tables. Junction tables are employed because they can deal with many-to-many relationships in a particular database. One example of a database that employs the associative entity through the use of junction table is the enrollment of students in a course. In this case, a table with data about students is connected indirectly to a table with data about courses through an intermediate table which contains data associated with student and course data from the connecting tables.

Discuss this Article

anon352270Post 4

Can a associative entity act as a parent entity to a fourth table in a ERD?

SkyWhispererPost 3

@David09 - That’s just it. I don’t think you can incorporate entity modeling in an incremental way. I think it’s pretty much all or nothing, because the whole point is for the model to be created from your whole database, associative entities, tables and all.

I’ve used it and think it’s great. If you want to tinker first I would use it for small projects to test it out. If all works out, you should start using it in production databases.

David09Post 2

@MrMoody - From what I gather the entity relationship database model is more of a high level abstraction of your database. The associative entity that the article talks about is nothing more than a relationship, similar to what you could create in any database platform.

I suppose the only thing that makes it different from a simple relationship is that it has properties. I don’t know how important that is for most applications. Most people just want to relate information together so that their queries make sense and they can generate meaningful reports.

Personally, I think with any new technology you should try to integrate it around the edges of what you currently use to see how it works first, before going full throttle with it.

MrMoodyPost 1

I work for a software company where we have recently started to work with entity relationship models of database design. Basically what happens is instead of building the database and the software independently, you build the database first with all of its relationships and tables with primary keys.

Then you use a wizard tool which will create an entity relational diagram from the database along with skeleton code that will allow you to modify the database directly. The diagram contains the associative entities, which correspond to the relationships in your original database.

In other words, your completed database serves as a template that drives what your code looks like. This is different from traditional approaches to software engineering, where you build the database and software separately, and then have to wire your software to talk to the database and manipulate it.

Post your comments

Please enter the code:

Login

Register

Make changes/additions/deletions to the article below, and one of our editors will publish your suggestions if warranted.

Optional: Explanation of your recommended changes

Thank You!

One of our editors will review your suggestion and make changes if warranted.
Note that depending on the number of suggestions we receive,
this can take anywhere from a few hours to a few days.
Thank you for helping to improve wiseGEEK!