Keys and Relationships

🗝️ The Kingdom of Data: Keys and Relationships

Imagine a magical kingdom where every citizen has a special ID card, and everyone is connected to each other in different ways…

🏰 Welcome to Data Kingdom!

Think of a database like a giant toy box. Each toy needs a special sticker so you can find it again. That sticker is called a KEY. And just like friends at school, toys can be connected to each other in different ways - these are called RELATIONSHIPS.

🎫 Chapter 1: Primary Keys - Your Special ID Card

What is a Primary Key?

Imagine your school gives you a student ID number. No two students have the same number. That’s exactly what a Primary Key is!

Simple Example:

@Entity
public class Student {
    @Id
    private Long studentId;  // This is the Primary Key!
    private String name;
}

Think of it like:

• Your house has a unique address 🏠
• Your phone has a unique number 📱
• Each book in the library has a unique code 📚

Rules of Primary Keys:

1. Unique - No two can be the same
2. Not null - Must always have a value
3. Never changes - Once set, stays the same

graph TD
    A["Student Table"] --> B["studentId: 1"]
    A --> C["studentId: 2"]
    A --> D["studentId: 3"]
    B --> E["Only ONE student can have ID 1"]

🎲 Chapter 2: UUID Primary Keys - Random Magic Codes

What is a UUID?

UUID stands for Universally Unique Identifier. It’s like generating a super-random password that’s almost impossible to guess!

Simple Example:

@Entity
public class Order {
    @Id
    @GeneratedValue
    private UUID orderId;
    // Example: "550e8400-e29b-41d4-a716-446655440000"
}

Why use UUID?

• Works across different computers 🌍
• Can’t guess the next ID 🔒
• Perfect for secret stuff 🕵️

Real Life:

• Like a lottery ticket number - totally random!
• Like a secret spy code that no one can predict

graph TD
    A["UUID Generator"] --> B["Creates Random ID"]
    B --> C["550e8400-e29b..."]
    B --> D["7c9e6679-b7e5..."]
    B --> E["Each one unique!"]

🧩 Chapter 3: Composite Primary Keys - Team IDs

What is a Composite Key?

Sometimes ONE key isn’t enough! It’s like identifying a seat in a theater - you need BOTH the row number AND seat number.

Simple Example:

@Embeddable
public class SeatId {
    private String rowLetter;  // "A"
    private Integer seatNum;   // 5
}

@Entity
public class TheaterSeat {
    @EmbeddedId
    private SeatId seatId;  // Together: "A-5"
}

Think of it like:

• Chess position: Column “B” + Row “4” = B4
• Apartment: Building “C” + Unit “201” = C-201
• Date: Month “12” + Day “25” = December 25th

graph TD
    A["Composite Key"] --> B["Part 1: Row = A"]
    A --> C["Part 2: Seat = 5"]
    B --> D["Together: A5"]
    C --> D
    D --> E["Unique Seat!"]

🤝 Chapter 4: Entity Relationships - Making Friends

What are Entity Relationships?

Just like people have different types of relationships (best friend, classmates, family), data tables can be connected in different ways!

The 4 Types of Relationships:

graph TD
    A["Entity Relationships"] --> B["One-to-One"]
    A --> C["One-to-Many"]
    A --> D["Many-to-One"]
    A --> E["Many-to-Many"]

💑 Chapter 5: One-to-One Relationships

The “Only One Partner” Rule

Like a person and their passport - each person has exactly ONE passport, and each passport belongs to exactly ONE person.

Simple Example:

@Entity
public class Person {
    @Id
    private Long id;
    private String name;

    @OneToOne
    private Passport passport;
}

@Entity
public class Passport {
    @Id
    private Long id;
    private String number;
}

Real Life Examples:

• Person ↔ Fingerprint 👆
• Country ↔ Capital City 🏛️
• User ↔ Profile Settings ⚙️

graph LR
    A["Person: John"] --> B["Passport: ABC123"]
    C["Person: Mary"] --> D["Passport: XYZ789"]

👨‍👩‍👧‍👦 Chapter 6: One-to-Many Relationships

The “Parent with Many Children” Rule

Like a mother with multiple children - ONE mother can have MANY children, but each child has only ONE mother.

Simple Example:

@Entity
public class Mother {
    @Id
    private Long id;
    private String name;

    @OneToMany(mappedBy = "mother")
    private List<Child> children;
}

@Entity
public class Child {
    @Id
    private Long id;
    private String name;

    @ManyToOne
    private Mother mother;
}

Real Life Examples:

• Teacher → Students 👩‍🏫
• Playlist → Songs 🎵
• Shopping Cart → Items 🛒

graph TD
    A["Mother: Lisa"] --> B["Child: Emma"]
    A --> C["Child: Jack"]
    A --> D["Child: Lily"]

👥 Chapter 7: Many-to-One Relationships

The “Many Going to One” Rule

It’s the opposite view of One-to-Many! Many employees work for ONE company.

Simple Example:

@Entity
public class Employee {
    @Id
    private Long id;
    private String name;

    @ManyToOne
    private Company company;
}

@Entity
public class Company {
    @Id
    private Long id;
    private String name;
}

Real Life Examples:

• Many books → One author 📖
• Many orders → One customer 📦
• Many students → One school 🏫

graph TD
    A["Employee: Tom"] --> D["Company: TechCorp"]
    B["Employee: Sara"] --> D
    C["Employee: Mike"] --> D

🎭 Chapter 8: Many-to-Many Relationships

The “Everyone Knows Everyone” Rule

Like students and courses - ONE student can take MANY courses, and ONE course can have MANY students!

Simple Example:

@Entity
public class Student {
    @Id
    private Long id;
    private String name;

    @ManyToMany
    @JoinTable(
        name = "student_course",
        joinColumns = @JoinColumn(
            name = "student_id"),
        inverseJoinColumns = @JoinColumn(
            name = "course_id")
    )
    private List<Course> courses;
}

@Entity
public class Course {
    @Id
    private Long id;
    private String title;

    @ManyToMany(mappedBy = "courses")
    private List<Student> students;
}

The Secret: A special join table sits in the middle!

Real Life Examples:

• Authors ↔ Books (co-authors!) 📚
• Actors ↔ Movies 🎬
• Tags ↔ Blog Posts 🏷️

graph TD
    A["Student: Alex"] --> C["Join Table"]
    B["Student: Beth"] --> C
    C --> D["Course: Math"]
    C --> E["Course: Art"]
    C --> F["Course: Music"]

🗺️ The Complete Map

Here’s how all relationships work together:

graph TD
    subgraph Keys
        K1["Primary Key - Unique ID"]
        K2["UUID Key - Random ID"]
        K3["Composite Key - Team ID"]
    end

    subgraph Relationships
        R1["One-to-One"]
        R2["One-to-Many"]
        R3["Many-to-One"]
        R4["Many-to-Many"]
    end

    K1 --> R1
    K1 --> R2
    K1 --> R3
    K1 --> R4

🎯 Quick Remember Guide

🚀 You Did It!

Now you understand how data is organized and connected in Jakarta EE! Remember:

1. Keys help us find things quickly
2. Relationships show how things connect
3. Every relationship has TWO sides

You’re now ready to build amazing apps that store data properly! 🎉