The relationships between entities within data is a major factor in working with data in any facet, whether that be [[Data Modeling]], [[Analytics]], or [[Web Development]]. Each type of relationship can be modeled differently regardless of using a [[Relational Data Model]] or [[NoSQL Data Models]]. The primary difference on how to model the relationships comes down to the level of [[normalization]] you may want present in your data model. The surface-level difference is normalization reduces duplicated data across the data model, but denormalization allows for data to be located together hence eliminating or reducing the needs for joins. This difference may seem slight, but can cascade into major implications in a system, especially with large volumes of data. >[!info] >The images below are displaying relationships between data, but not a data model. A data model for the data could look like the diagrams if strict [[normalization]] is used, but could also end up looking very different. # One-to-one Relationships Simple! A single record for one [[entity]] is tied to a single record for another entity. ![[Data Relationships 2024-11-16 06.48.53.excalidraw.svg]] %%[[Data Relationships 2024-11-16 06.48.53.excalidraw|🖋 Edit in Excalidraw]]%% # One-to-Many Relationships A single entity can have many of another entity. This is the same as many-to-one, but you're just switching the perspective of the main type of entity you are discussing. This is where the differences in normalization start to be seen. In a relational model, you would model as separate tables, with a foreign key in the 'many' table that ties to the primary key in the 'one' table (see [[Relational Data Model#Relationships]]). In a NoSQL data model, you could embed each of the 'many' entities into the 'one' entity. Basically, store them as a list attribute within the 'one' entity. This eliminates joins during processing, but adds complexity to the database, which can impact maintenance. What if a player changes teams? It can be difficult to remove a player from one team and add to another, compared to simply updating a foreign key if the players were in their own table. ![[Data Relationships 2024-11-16 06.54.59.excalidraw.svg]] %%[[Data Relationships 2024-11-16 06.54.59.excalidraw|🖋 Edit in Excalidraw]]%% # Many-to-Many Relationships Things get extra complicated in a many-to-many relationship. In a relational data model, this requires an entire extra table to maintain these relationships and in a document model, it may cause either so many joins or data duplication that the model may not be practical for actual use. ![[Data Relationships 2024-11-17 06.15.28.excalidraw.svg]] %%[[Data Relationships 2024-11-17 06.15.28.excalidraw|🖋 Edit in Excalidraw]]%%