Overview

For every backend developer, it is crucial that you understand how to store application data in a way that allows for data consistency, minimizes redundancy, and preserve the integrity of your data.

Hence, knowing how to use an ORM library alone would serve you well in the long run. Can you describe what the function your ORM library provides you does?

In this article, we will explore database relationships from a conceptual design standpoint, building upon a previous discussion about database properties. To ensure clarity in our discussion, I'll begin by defining a few terms commonly employed in conceptual database design. This foundation will help establish a shared understanding as we delve deeper into the topic.

Common Terms Used in Conceptual Database Design

There are four key terms integral to conceptual database design, namely: Entity, Instance, Attribute, and Relationship. Before delving into their meanings within a conceptual design framework, it's essential to understand what conceptual database design entails.

Conceptual database design revolves around the examination and modeling of data in a manner independent of specific technologies. The conceptual data model, which is created during this phase, can theoretically be implemented on any database. Its purpose is to articulate and describe how real-world business data should be organized to optimize data integrity, facilitate effortless retrieval, and ensure security.

Now that we understand what conceptual database design is, let's explain what these key terms stated above are.

1. Entity - An entity refers to a real-world object, be it a person, thing, event, or concept, for which data is gathered and stored in a database. It can be a tangible or abstract entity that holds sufficient interest to warrant data capture and storage.

2. Instance - In the context of conceptual modeling, an instance is an object belonging to a specific entity class. Each entity depicted in a conceptual model represents the entire class of that entity. To clarify, consider this concept through the lens of Object-Oriented Programming (OOP).

3. Attribute - An attribute is a discrete piece of information that characterizes an entity in some manner. For instance, for a Customer entity, an attribute describing it could be the customer's first name.

4. Relationship - A relationship denotes the connection between two or more entities. Given that databases primarily revolve around storing interconnected data, these relationships serve as the binding element that unifies the database. A more in-depth exploration of relationships will be undertaken in the next section.

Relationships

In a conceptual design diagram, relationships are typically depicted as lines connecting one or more entities. Each terminus of a relationship line indicates the maximum cardinality, representing the highest number of instances of one entity in the relationship. The maximum cardinality may be one (denoted by an absence of special symbols) or many (indicated by a crow's foot symbol at the line's end).

More on this cardinality concept will be explained along with diagrams to describe how conceptual models are defined will also be in another article.

There exist three types of relationships, namely:

1. One-to-One - This association signifies that an instance of one entity can be linked to at most one instance of another entity, and vice versa. Unless a minimum cardinality of zero is specified at either end of the line, this relationship is mandatory in both directions. In practical terms, this implies that an instance of one entity must have precisely one instance of the other entity associated with it, and vice versa.

2. One-to-Many - This type of relationship involves two entities where each instance of the first entity can be linked to one or more instances of the second entity, while each instance of the second entity may be associated with at most one instance of the first.

   This form of relationship stands as the most prevalent and serves as a foundational element in the relational database model. In fact, all relationships within a relational database are implemented as if they were inherently one-to-many.

   More on this in an upcoming article.

3. Many-to-Many - This form of association involves two entities, allowing any instance of the first entity to be linked with zero, one, or multiple instances of the second, and vice versa. Notably, this is the only relationship type accompanied by data termed as intersection data. This data gains significance only when associated with both entities simultaneously.

   In logical database design, handling many-to-many relationships is typically managed by storing this intersection data in a dedicated table. This practice is adopted because relational databases lack built-in support for directly accommodating many-to-many relationships.

Conclusion

This concludes the current article. While I am tempted to delve further into this topic (indeed, there is much more to explore), I must adhere to the self-imposed word limit. In the subsequent article, our focus will shift towards examining conceptual database design through a visual and illustrative lens.

Thanks for reading!