벡엔드에서 짱먹기.

01. 임베디드 타입과 테이블 매핑

임베디드 타입은 엔티티의 값일 뿐이다.

따라서 값이 속한 엔티티의 테이블에 매핑한다.

임베디드 타입 덕분에 객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다.

잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

테이블 하나에 여러 클래스를 매핑하는 것은 상상하기도 싫을 것이다..

이런 지루한 반복 작업은 JPA에게 맡기고 더 세밀한 객체지향 모델을 설계하는 데에 집중해야한다.

02. 임베디드 타입과 연관관계

임베디드 타입은 값 타입을 포함하거나 엔티티를 참조할 수 있다.

@Entity
public class Member
{
    @Embedded Address address; // 임베디드 타입 포함
    @Embedded PhoneNumber phoneNumber; // 임베디드 타입 포함
    ...
}

@Embeddable
public class Address
{
    String street;
    String city;
    String state;
    @Embedded Zipcode zipcode; // 임베디드 타입 포함
}

@Embeddable
public class Zipcode
{
    String zip;
    String plusFour;
}

@Embeddable
public class PhoneNumber
{
    String areaCode;
    String localNumber;
    @ManyToOne PhoneServiceProvider provider; // 엔티티 참조
    ...
}

@Entity
public class PhoneServiceProvider
{
    @Id
    String name;
    ...
}

값 타입인 Address 가 값 타입인 Zipcode를 포함하고, 값 타입인 PhoneNumber가 엔티티 타입인 PhoneServiceProvider를 참조한다.

03. @AttrivuteOverride : 속성 재정의

임베디드 타입에 정의한 매핑정보를 재정의하려면 엔티티에 @AttributeOverride를 사용하면 된다.

@Entity
public class Member
{
    @Id
    @GeneratedValue
    private Long id;
    
    private String name;
    
    @Embedded Address homeAddress;
    @Embedded Address companyAddress;
}

만약 회원에게 주소가 하나 더 필요하면 어떻게 해야할까?

위 코드에서 문제는 테이블에 매핑하는 컬럼 명이 중복되는 것이다.

이때는 @AttributeOverrides를 사용해서 매핑정보를 재정의해야 한다.

@Entity
public class Member
{
    @Id
    @GeneratedValue
    private Long id;
    
    private String name;
    
    @Embedded Address homeAddress;
    
    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name = "city", column = @Column(name = "COMPANY_CITY")),
        @AttributeOverride(name = "street", column = @Column(name = "COMPANY_STREET")),
        @AttributeOverride(name = "zipcode", column = @Column(name = "COMPANY_ZIPCODE"))
    }
    Address companyAddress;
}

이렇게 엔티티를 정의하면

CREATE TABLE MEMBER
(
    COMPANY_CITY varchar(255),
    COMPANY_STREET varchar(255),    
    COMPANY_ZIPCODE varchar(255),    
    city varchar(255),
    street varchar(255),
    zipcode varchar(255),
    ...
)

이렇게 생성된다.

04. 임베디드 타입과 null

임베디드 타입이 null이면 매핑한 컬럼 값은 모두 null이 된다.

01. 값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다.

위 그림의 상황은

memver1.setHomeAddress(new Address("OldCity"));
Address address = member1.getHomeAddress();

address.setCity("NewCity"); // 회원1의 address 값을 공유해서 사용
member2.setHomeAddress(address);

이렇게 표현할 수 있다.

회원2에 새로운 주소를 할당하려고 회원1의 주소를 그대로 참조해서 사용했다.

이 코드를 실행하면 회원1의 주소도 "NewCity"로 변경된다.

영속성 컨텍스트에서는 회원1과 회원2 둘 다 city 속성이 변경된 것으로 판단해서 회원1, 회원2 각각 UPDATE SQL을 실행한다.

이런 부작용을 막으려면 값을 복사해서 사용하면 된다.

02. 값 타입 복사

값 타입의 실제 인스턴스인 값을 공유하는 것은 위험하다.

대신에 값(인스턴스)을 복사해서 사용해야 한다.

위 그림의 상황은

member1.setHomeAddress(new Address("OldCity"));
Address address = member1.getHomeAddress();

// 회원1의 address 값을 복사해서 새로운 newAddress 값을 생성
Address newAddress = address.clone();

newAddress.setCity("NewCity");
member2.setHomeAddress(newAddress);

이렇게 표현할 수 있다.

회원2에 새로운 주소를 할당하기 위해 clone() 메소드를 만들었는데, 이 메소드는 자신을 복사해서 반환하도록 구현했다.

그러면 영속성 컨텍스트는 회원2의 주소만 변경된 것으로 판단해서 회원2에 대해서만 UPDATE SQL을 실행한다.

이처럼 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.

문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이라는 것이다.

자바는 기본 타입에 값을 대입하면 값을 복사해서 전달한다.

int a = 10;
int b = a; // 기본 타입은 항상 값을 복사한다.
b = 4;

이 코드의 최종 결과는 a = 10, b = 4 다.

int b = a에서 a의 값 10을 복사해서 b에 넘겨준다.

따라서 a, b는 완전히 독립된 값을 가지고 부작용도 없다.

문제는 Address같은 객체 타입이다.

자바는 객체에 값을 대입하면 항상 참조값을 전달한다.

Address a = new Address("Old");
Address b = a; // 객체 타입은 항상 참조 값을 전달한다.
b.setCity("New");

Address b = a 에서 a가 참조하는 인스턴스의 참조 값을 전달하기 때문에 

b에서 city를 바꿔도 a의 city도 같이 바뀌게 된다.

Address a = new Address("Old");
Address b = a.clone(); // 항상 복사해서 넘겨야 한다.
// Address b = a; // 이렇게 참조만 넘기면 부작용이 발생할 수 있다.
b.setCity("New");

이때도 값 타입 복사를 해주면 된다.

객체의 공유 참조는 피할 수 없다.

따라서 근본적인 해결책이 필요한데 가장 단순한 방법은 객체의 값을 수정하지 못하게 막으면 된다.

03. 불변 객체

값 타입은 부작용 걱정 없이 사용할 수 있어야 한다.

부작용이 일어나면 값 타입이라 할 수 없다.

객체를 불변하게 만들면 값을 수정할 수 없으므로 부작용을 원천 차단할 수 있다.

따라서 값 타입은 될 수 있으면 불변 객체로 설계해야 한다.

@Embeddable
public class Address
{
    private String city;
    
    protected Address() {} // JPA에서 기본 생성자는 필수다.
    
    // 생성자로 초기 값을 설정한다.
    public Address(String city) {this.city = city}
    
    // 접근자(Getter)는 노출한다.
    public String getCity()
    {
        return city;
    }
    
    // 수정자(Setter)는 만들지 않는다.
}

위의 Address 는 이제 불변 객체이다.

Address address = member1.getHomeAddress();
// 회원1의 주소 값을 조회해서 새로운 주소값을 생성
Address newAddress = new Address(address.getCity());
member2.setHomeAddress(newAddress);

만약 값을 수정해야 하면 위 코드처럼 새로운 객체를 생성해서 사용해야 한다.

01. 값 타입 컬렉션 사용

Member member = new Member();

// 임베디드 값 타입
member.setHomeAddress(new Address("통영", "몽돌해수욕장", "660-123"));

// 기본값 타입 컬렉션
member.getFavoriteFoods().add("짬뽕");
member.getFavoriteFoods().add("짜장");
member.getFavoriteFoods().add("탕수육");

// 임베디드 값 타입 컬렉션
member.getAddressHistory().add(new Address("서울", "강남", "123-123"));
member.getAddressHistory().add(new Address("서울", "강북", "000-000"));

em.persist(member);

위 코드는 등록하는 코드다.

마지막에 member엔티티만 영속화 했다.

JPA는 이때 member의 엔티티 값 타입도 함께 저장한다.

• member : INSERT SQL 1번
• member.homeAddress : 컬렉션이 아닌 임베디드 값 타입이므로 회원테이블을 저장하는 SQL에 포함된다.
• member.favoriteFoods : INSERT SQL 3번
• member.addressHistory : INSERT SQL 2번

따라서 em.persist(member) 한 번 호출로 총 6번의 INSERT SQL을 실행한다.

// SQL : SELECT ID, CITY, STREET, ZIPCODE FROM MEMBER WHERE ID = 1
Member member = em.find(Member.class, 1L); // 1. member

// 2. member.homeAddress
Address homeAddress = member.getHomeAddress();

// 3. member.favoriteFoods
Set<String> favoriteFoods = member.getFavoriteFoods(); // LAZY

// SQL : SELECT MEMBER_ID, FOOD_NAME FROM FAVORITE_FOODS WHERE MEMBER_ID = 1
for (String favoriteFood : favoriteFoods)
{
    System.out.println("favoriteFood = " + favoriteFood);
}

// 4. member.addressHistory
List<Address> addressHistory = member.getAddressHistory(); // LAZY

// SQL : SELECT MEMBER_ID , CITY, STREET, ZIPCODE FROM ADDRESS WHERE MEMBER_ID = 1
addressHistory.get(0);

지연로딩으로 설정

1. member : 회원만 조회한다. 이때 임베디드 값 타입인 homeAddress도 함께 조회한다. SELET SQL을 1번 호출한다.
2. member.homeAddress : 1번에서 회원을 조회할 때 같이 조회해둔다.
3. member.favoriteFoods : LAZY로 설정해서 실제 컬렉션을 사용할 때 SELECT SQL을 1번 호출한다.
4. member.addressHistory : LAZY로 설정해서 실제 컬렉션을 사용할 때 SELECT SQL을 1번 호출한다.

Member member = em.find(Member.class, 1L);

// 1. 임베디드 값 타입 수정
member.sethomeAddress(new Address("새로운도시", "신도시1", "123456"));

// 2. 기본값 타입 컬렉션 수정
Set<String> favoriteFoods = member.getFavoriteFoods();
favoriteFoods.remove("탕수육");
favoriteFoods.add("치킨");

// 3. 임베디드 값 타입 컬렉션 수정
List<Address> addressHistory = member.getAddressHistory();
addressHistory.remove(new Address("서울", "기존 주소", "123-123"));
addressHistory.add(new Address("새로운도시", "새로운 주소", "123-456"));

• 임베디드값 타입 수정 : homeAddress 임베디드 값 타입은 MEMBER 테이블과 매핑했으므로 MEMBER 테이블만 UPDATE한다. 사실 Member 엔티티를 수정하는 것과 같다.
• 기본값 타입 컬렉션 수정 : 탕수육을 치킨으로 변경하려면 탕수육을 제거하고 치킨을 추가해야 한다. 자바의 String타입을 수정 불가하다.
• 임베디드 값 타입 컬렉션 수정 : 값 타입은 불변해야 한다. 따라서 컬렉션에서 기존 주소를 삭제하고 새로운 주소를 등록했다. 참고로 값 타입은 equals, hashcode를 꼭 구현해야 한다.

02. 값 타입 컬렉션 제약사항

엔티티는 식별자가 있어서 엔티티 값을 변경해도 식별자로 DB에 젖아된 원본 데이터를 쉽게 찾아서 변경 가능하다.

하지만 값 타입은 식별자가 없고 단순한 값들의 모음이므로 값을 변경해버리면 DB에 저장된 원본 데이터를 찾기 어렵다.

특정 엔티티 하나에 소속된 값 타입은 값이 변경되어도 자신의 소속된 엔티티를 DB에서 찾고 값을 변경하면 된다.

문제는 값 타입 컬렉션이다. 

값 타입 컬렉션에 보관된 값 타입들은 별도의 테이블에 보관되어서 DB에 있는 원본 데이터를 찾기 어렵다.

이런 문제로 인해 JPA 구현체들은 값 타입 컬렉션에 변경사항이 발생하면 값테입 컬렉션이 매핑된 테이블의 연관된 모든 데이터를 삭제하고, 현제 값 타입 컬렉션 객체제 있는 모든 값을 DB에 다시 저장한다.

따라서 실무에서는 값 타입 컬렉션이 매핑된 테이블에 데이터가 많다면 값 타입 컬렉션 대신에 일대다 관계를 고려해야 한다.

지금까지 나온 문제를 해결하려면 값 타입 컬렉션을 사용하는 대신에 새로운 엔티티를 만들어서 일대다 관계로 설정하면 된다.

여기에 추가로 영속성 전이(Cascade) + 고아 객체 제거(ORPHAN REMOVE) 기능을 적용하면 값 타입 컬렉션처럼 사용할 수 있다.

1.1 각각의 테이블로 변환

각각을 모두 테이블로 만들고 조회할 때 조인을 사용한다.

JPA에서는 조인 전략이라고 한다.

엔티티 각각을 모두 테이블로 만들고 자식 테이블이 부모 테이블의 기본 키를 받아서 기본 키 + 외래 키로 사용하는 전략이다.

따라서 조회할 때 조인을 자주 사용한다.

이 전략을 사용할 때 주의할 점이 있는데 객체는 타입으로 구분할 수 있지만 테이블은 타입의 개념이 없다.

따라서 타입을 구분하는 DTYPE 컬럼을 구분 컬럼으로 사용한다.

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Item
{
    @Id
    @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;
    
    private String name;
    private int price;
    ...
}

@Entity
@DiscriminatorValue("A")
public class Album extends Item
{
    private String artist;
    ...
}

@Entity
@DiscriminatorValue("M")
public class Movie extends Item
{
    private String director;
    private String actor;
    ...
}

위 코드를 분석해보자

01. @Inheritance(strategy = InheritanceType.JOINED)

상속 매핑은 부모 클래스에 @Inheritance를 사용해야 한다.

그래고 매핑 전략을 지정해야 하는데 여기서는 조인 적략을 사용하므로 InheritanceType.JOINED를 사용했다.

02. @DiscriminatorColumn(name = "DTYPE") 

부모 클래스에 구분 컬럼을 지정한다.

이 컬럼으로 저장된 자식 테이블을 구분할 수 있다.

기본값이 DTYPE이므로 @DiscriminatorColumn으로 줄여서 사용해도 된다.

03. @DiscriminatorValue("M")

엔티티를 저장할 때 구분 컬럼에 입력할 값을 지정한다.

만약 영화 엔티티를 저장하면 구분 컬럼인 DTYPE에 값 M이 저장된다.

기본 값으로 자식 테이블은 부모 테이블의 ID 컬럼명을 그대로 사용하는데, 만약 자식 테이블의 기본 키 컬럼명을 변경하고 싶으면 @PrimaryKeyJoinColumn을 사용하면 된다.

@Entity
@DiscriminatorValue("B")
@PrimaryKeyJoinColumn(name = "BOOK_ID") // ID 재정의
public class Book extends Item
{
    private String author;
    private String isbn;
    ...
}

BOOK 테이블의 ITEM_ID 기본 키 컬럼명을 BOOK_ID로 변경했다.

장점

• 테이블이 정규화된다.
• 외래 키 참조 무결성 제약조건을 활용할 수 있다.
• 저장공간을 효율적으로 사용한다.

단점

• 조회할 때 조인이 많이 사용되므로 성능이 저하될 수 있다.
• 조회 쿼리가 복잡하다.
• 데이터를 등록할 INSERT SQL을 두 번 실행한다.

특징

• JPA 표준 명세는 구분 컬럼을 사용하도록 하지만 하이버네이트를 포함한 몇몇 구현체는 구분컬럼(@DiscriminatorColumn)없이도 동작한다.

02. 통합 테이블로 변환

테이블을 하나만 사용해서 통합한다.

JPA에서는 단일 테이블 전략이라고 한다.

위 그림과 같이 이름 그대로 테이블을 하나만 사용한다.

구분 컬럼(DTYPE)으로 어떤 자식 데이터가 저장되었는지 구분한다.

조회할 때 조인을 사용하지 않으므로 일반적으로 가장 빠르다.

이 전략을 사용할 때 주의점은 자식 엔티티가 매핑한 컬럼은 모두 null을 허용해야 한다.

예를 들어 Book 엔티티를 저장하면 ITEM 테이블의 AUTHOR, ISBN 컬럼만 사용하고 다른 엔티티와 매핑 된 ARTIST. DIRECTOR, ACTOR 컬럼은 사용하지 않으므로 null이 입력되기 때문이다.

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Item
{
    @Id
    @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;
    
    private String name;
    private int price;
    ...
}

@Entity
@DiscriminatorValue("A")
public class Album extends Item { ... }


@Entity
@DiscriminatorValue("M")
public class Movie extends Item { ... }


@Entity
@DiscriminatorValue("B")
public class Book extends Item { ... }

InheritanceType.SINGLE_TABLE 로 지정하면 단일 테이블 전략을 사용한다.

테이블 하나에 모든 것을 통합하므로 구분 컬럼을 필수로 사용해야 한다.

단일 테이블 전략의 장단점은 하나의 테이블을 사용하는 특징과 관련 있다.

장점

• 조인이 필요 없으므로 일반적으로 조회 성능이 빠르다.
• 조회 쿼리가 단순하다.

단점

• 자식 엔티티가 매핑한 컬럼은 모두 null을 허용해야 한다.
• 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다.
• 그러므로 상황에 따라서는 조회 성능이 오히려 느려질 수 있다.

특징

• 구분 컬럼을 꼭 사용해야 한다. 따라서 @DiscriminatorColumn을 꼭 설정해야 한다.
• @DiscriminatorValue를 지정하지 않으면 기본으로 엔티티 이름을 사용한다.

03. 서브타입 테이블로 변환

서브 타입마다 하나의 테이블을 만든다.

JPA에서는 구현 클래스마다 테이블 전략이라 한다.

위 그림과 같이 자식 엔티티마다 테이블을 만든다.

그리고 자식 테이블 각각에 필요한 컬럼이 모두 있다.

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item
{
    @Id
    @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;
    
    private String name;
    private int price;
    ...
}

@Entity
public class Album extends Item { ... }

@Entity
public class Movie extends Item { ... }

@Entity
public class Book extends Item { ... }

InheritanceType.TABLE_PER_CLASS를 선택하면 구현 클래스마다 테이블 전략을 사용한다.

이 전략은 자식 엔티티마다 테이블을 만든다.

일반적으로 추천하지 않는 전략이다.

장점

• 서브 타입을 구분해서 처리할 때 효과적이다.
• not null 제약조건을 사용할 수 있다.

단점

• 여러 자식 테이블을 함께 조회할 때 성능이 느리다(SQL에 UNION을 사용해야 한다.)
• 자식 테이블을 통합해서 쿼리하기 어렵다.

특징

• 구분 컬럼을 사용하지 않는다.

이 전략은 DB 설계자와 ORM 전문가 둘 다 추천하지 않는 전략이다.

조인이나 단일 테이블 전략을 고려하자.

지금까지 학습한 상속 관계 매핑은 부모 클래스와 자식 클래스를 모두 DB 테이블과 매핑했다.

부모 클래스는 테이블과 매핑하지 않고 부모 클래스를 상속받는 자식 클래스에게 매핑 정보만 제공하고 싶으면 @MappedSuperclass를 사용하면 된다.

@MappedSuperclass는 비유를 하자면 추상 클래스와 비슷한데 @Entity는 실제 테이블과 매핑되지만 @MappedSuperclass는 실제 테이블과는 매핑되지 않는다.

이것은 단순히 정보를 상속할 목적으로만 사용된다.

회원(Member)과 판매자(Seller)는 서로 관계가 없는 테이블과 엔티티이다.

@MappedSuperclass
public abstract class BaseEntity
{
    @Id
    @GeneratedValue
    private Long id;
    private String name;
    ...
}

@Entity
public class Member extends BaseEntity
{
    // ID 상속
    // NAME 상속
    private String email;
    ...
}

@Entity
public class Seller extends BaseEntity
{
    // ID 상속
    // NAME 상속
    private String shopName;
    ...
}

테이블은 그대로 두고 객체 모델의 id, name 두 공통 속성을 부모 클래스로 모으고 객체 상속 관계로 만든 코드이다

BaseEntity에는 객체들이 주로 사용하는 공통 매핑 정보를 정의했다.

그리고 자식 엔티티들은 상속을 통해 BaseEntity의 매핑 정보를 물려받았다.

여기서 BaseEntity는 테이블과 매핑할 필요가 없고 자식 엔티티에게 공통으로 사용되는 매핑 정보만 제공하면 된다.

따라서 @MappedSuperclass를 사용했다.

부모로부터 물려받은 매핑 정보를 재정의하려면 @AttributedOverrides나 @AttributeOverride를 사용하고, 연관관계를 재정의하려면  @AssociationOverrides나 @AssociationOverride를 사용한다.

@Entity
@AttributeOverrides({
        @AttributeOverride(name = "id", column = @Column(name = "MEMBER_ID")),
        @AttributeOverride(name = "name", column = @Column(name = "MEMBER_NAME"))
})
public class Member extends BaseEntity { ... }

정리

• 테이블과 매핑되지 않고 자식 클래스에 엔티티에 매핑 정보를 상속하기 위해 사용한다.
• @MappedSuperclass로 지정한 클래스는 엔티티가 아니므로 em.find()나 JPQL에서 사용할 수 없다.
• 이 클래스를 직접 생성해서 사용할 일은 거의 없으므로 추상 클래스로 만드는 것을 권장한다.
• @MappedSuperclass를 사용하면 등록일자, 수정일자, 등록자, 수정자 같은 여러 엔티티에서 공통으로 사용하는 속성을 효과적으로 관리할 수 있다.

01. 식별관계 vs 비식별 관계

DB 테이블 사이에 관계는 외래 키가 기본 키에 포함되는지 여부에 따라 식별 관계와 비식별 관계로 구분한다.

식별 관계

식별 관계는 부모 테이블의 기본 키를 내려받아서 자식 테이블의 기본 키 + 외래 키로 사용하는 관계다.

위 그림을 보면 PARENT 테이블의 기본 키 PARENT_ID를 받아서 CHILD 테이블의 기본 키(PK) + 외래 키(FK)로 사용한다.

비식별 관계

비식별 관계는 부모 테이블의 기본 키를 받아서 자식의 테이블의 외래 키로만 사용하는 관계이다.

위 그림을 보면 PARENT 테이블의 기본 키 PARENT_ID를 받아서 CHILD 테이블의 외래 키(FK)로만 사용한다.

비식별 관계는 외래 키에 NULL을 허용하는지에 따라 필수적 비식별 관계와 선택적 비식별 관계로 나눈다.

• 필수적 비식별 관계(Mandatory) : 외래 키에 NULL을 허용하지 않는다. 연관관계를 필수적으로 맺어야 한다.
• 선택적 비식별 관계(Optional) : 외래 키에 NULL을 허용한다. 연관관계를 맺을지 말지 선택할 수 있다.

DB 테이블을 설계할 때 식별 관계나 비식별 관계 중 하나를 선택해야 한다.

최근에는 비식별 관계를 주로 사용하고 꼭 필요한 곳에만 식별 관계를 사용하는 추세다.

JPA는 식별관계와 비식별 관계를 모두 지원한다.

식별 관계와 비식별 관계를 어떻게 매핑하는지 알아보자.

02. 복합키 : 비식별 관계 매핑

@Entity

public class Hello
{

    @Id
    private String id;
}

기본 키를 구성하는 컬림이 하나면 위 코드처럼 단순하게 매핑한다.

@Entity

public class Hello
{

    @Id
    private String id1;
    
    @Id
    private String id2; // 실행 시점에 매핑 예외 발생
}

둘 이상의 컬럼으로 구성된 복합 기본 키는 위 코드처럼 매핑하면 될 것 같지만 막상 해보면 매핑 오류가 발생한다.

JPA에서 식별자를 둘 이상 사용하려면 별도의 식별자 클래스를 만들어야한다.

JPA는 영속성 컨텍스트에 엔티티를 보관할 때 엔티티의 식별자를 키로 사용한다.

그리고 식별자를 구분하기 위해 equals와 hashCode를 사용해서 동등성 비교를 한다.

그런데 식별자 필드가 하나일 때는 보통 자바의 기본 타입을 사용하므로 문제가 없지만, 식별자 필드가 2개 이상이면 별도의 식별자 클래스를 만들고 그곳에 equals와 hashCode를 구현해야 한다.

JPA는 복합 키를 지원하기 위해 @IdClass와 @EmbeddedId 2가지 방법을 제공하는데 @IdClass는 관계형 DB에 가까운 방법이고 @EmbeddedId는 좀 더 객체지향에 가까운 방법이다.

@IdClass

PARENT 테이블을 보면 기본 키를 PARENT_ID1, PARENT_ID2로 묶은 복합 키로 구성했다.

따라서 복합 키를 매핑하기 위해 식별자 클래스를 별도로 만들어야 한다.

부모 클래스

@Entity
@IdClass(ParentId.class)
public class Parent
{
    @Id
    @Column(name = "PARENT_ID1")
    private String id1; // ParentID.id1 과 연결
    
    @Id
    @Column(name = "PARENT_ID2")
    private String id2; // ParentID.id2 와 연결
    
    private String name;
    ...
}

식별자 클래스

public class ParentId implements Serializable
{
    private String id1; // Parent.id1 매핑
    private String id2; // Parent.id2 매핑
    
    public ParentId() {}
    
    public ParentId(String id1, String id2)
    {
        thid.id1 = id1;
        this.id2 = id2;
    }
    
    @Override
    public boolean equals(Object o) { ... }
    
    @Override
    public int hashCode() { ... }
}

PARENT 테이블을 매핑한 코드이다.

각각의 기본 키 컬럼을 @Id로 매핑했다.

그리고 @IdClass를 사용해서 ParentId 클래스를 식별자 클래스로 지정했다.

@Entity
public class Child
{
    @Id
    private String id;
    
    @ManyToOne
    @JoinColumns({
            @JoinColumn(name = "PARENT_ID1",
                referencedColumnName = "PARENT_ID1"),
            @JoinColumn(name = "PARENT_ID2",
                referencedColumnName = "PARENT_ID2")
    }
    private Parent parent;
}

부모 테이블의 기본 키 컬럼이 복합 키 이므로 자식 테이블의 외래 키도 복합 키다.

따라서 외래 키 매핑 시 여러 컬럼을 매핑해야 하므로 @JoinColumns 어노테이션을 사용하고 각각의 외래 키 커럼을 @JoinColumn으로 매핑한다.

참고로 위 코드처럼 JoinColumn의 name 속성과 referencedColumnName 속성의 값이 같으면 referencedColumnName은 생략해도 된다.

@EmbeddedId

@IdClass가 DB에 맞춘 방법이라면 @EmbeddedId는 좀 더 객체지향적인 방법이다.

@Entity
public class Parent
{
    @EmbeddedId
    private ParentId id;
    
    private String name;
    ...
}

Parent 엔티티에서 식별자 클래스를 직접 사용하고 @EmbeddedId 어노테이션을 적어주면 된다.

@Embeddable
public class ParentId implements Serializable
{
    @Column(name = "PARENT_ID1")
    private String id1;
    @Column(name = "PARENT_ID2")
    private String id2;
    
    // equals and hashCode 구현
    ...
}

@IdClass와는 다르게 @EmbeddedId를 적용한 식별자 클래스는 식별자 클래스에 기본 키를 직접 매핑한다.

@EmbeddedId를 적용한 식별자 클래스는 다음 조건을 만족해야한다.

• @Embeddable 어노테이션을 붙여주어야 한다.
• Serializable 인터페이스를 구현해야 한다.
• equals, hashCode를 구현해야 한다.
• 기본생성자가 있어야 한다.
• 식별자 클래스는 public이어야한다.

Parent parent = new Parent();
ParentId parentId = new ParentId("myId1", "myId2");
parent.setId(parentId);
parent.setName("parentName");
em.persist(parent);

저장하는 코드이다.

식별자 클래스 parentId를 직접 생성해서 사용한다.

ParentId parentId = new ParentId("myId1", "myId2");
Parent parent = em.find(Parent.class, parentId);

조회 코드도 식별자 클래스 parentId를 직접 사용한다.

복합 키와 equals(), hashCode()

복합 키는 equals()와 hashCode()를 필수로 구현해야 한다.

ParentID id1 = new parentId();
id1.setId1("myId1");
id1.setId2("myId2");

ParentID id2 = new parentId();
id2.setId1("myId1");
id2.setId2("myId2");

id1.equals(id2) // ??

이것은 순수한 자바 코드이다.

id1과 id2 인스턴스 둘 다 myId1, myId2라는 같은 값을 가지고 있지만 인스턴스는 다르다.

그래서 오버라이딩을 하지 않으면 마지막 줄은 거짓이다.

그 이유는 기본 equals()는 인스턴스 참조 값 비교인 ==비교(동일성 비교)를 하기 때문이다.

영속성 컨텍스트는 엔티티의 식별자를 키로 사용해서 엔티티를 관리한다.

기르고 식별자를 비교할 때 equals() 와 hashCode()를 사용한다.

따라서 식별자 객체의 동등성이 지겨지지 않으면 예상과 다른 엔티티가 조회되거나 엔티티를 찾을수 없는 등 심각한 문제가 발생한다.

따라서 복합 키는 equals()와 hashCode()를 필수로 구현해야 한다.

03. 복합 키 : 식별 관계 매핑

위 그림은 부모, 자식, 손자까지 계속 기본 키를 전달하는 식별 관계다.

식별 관계에서 자식 테이블은 부모 테이블의 기본 키를 포함해서 복합 키를 구성해야 하므로 @IdClass나 @EmbeddedId를 사용해서 식별자를 매핑해야 한다.

@IdClass와 식별 관계

부모 엔티티

// 부모
@Entity
public class Parent
{
    @Id
    @Column(name = "PARENT_ID")
    private String id;
    private String name;
    ...
}

자식 엔티티

// 자식
@Entity
@IdClass(ChildId.class)
public class Child
{
    @Id
    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    public Parent parent;
    
    @Id
    @Column(name = "CHILD_ID")
    private String childId;
    
    private String name;
    ...
}

// 자식 ID
public class ChildId implements Serializable
{
    private String parent; // Child.parent 매핑
    private String childId; // Child.childId 매핑
    
    // equals, hashCode
    ...
}

손자 엔티티

// 손자
@Entity
@IdClass(GrandChildId.class)
public class GrandChild
{
    @Id
    @ManyToOne
    @JoinColumn({
            @JoinColumn(name = "PARENT_ID"),
            @JoinColumn(name = "CHILD_ID")
    }
    private Child child;
    
    @Id
    @Column(name = "GRANDCHILD_ID")
    private String id;
    
    private String name;
    ...
}

// 손자 ID
public class GrandChildId implements Serializable
{
    private ChildId child; // GrandChild.child 매핑
    private String id; // GrandChild.id 매핑
    
    // equals, hashCode
    ...
}

식별 관계는 기본 키와 외래 키를 같이 매핑해야 한다.

@Id
@ManyToOne
@JoinColumn(name = "PARENT_ID")
public Parent parent;

따라서 식별자 매핑인 @Id와 연관관계 매핑인 @ManyToOne을 같이 사용하면 된다.

Child 엔티티의 parent 필드를 보면 @Id로 기본 키를 매핑하면서 @ManyToOne과 @JoinColumn으로 외래 키를 같이 매핑한다.

@EmbeddedId와 식별 관계

@EmbeddedId로 식별 관계를 구성할 때는 @MapsId를 사용해야 한다.

부모 엔티티

// 부모
@Entity
public class Parent
{
    @Id
    @Column(name = "PARENT_ID")
    private String id;
    
    private String name;
    ...
}

자식 엔티티

// 자식
@Entity
public class Child
{
    @EmbeddedId
    private ChildId id;
    
    @MapsId("parentId") // ChildId.parentId 매핑
    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    public Parent parent;
    
    private String name;
    ...
}

//자식 ID
@Embeddable
public class ChildId implements Serializable
{
    private String parentId; // @MapsId("parentId")로 매핑
    
    @Column(name = "CHILD_ID")
    private String id;
    
    // equals, hashCode
    ...
}

손자 엔티티

// 손자
@Entity
public class GrandChild
{
    @EmbeddedId
    private GrandChildId id;
    
    @MapsId("childId") // GrandChildId.childId 매핑
    @ManyToOne
    @JoinColumns({
            @JoinColumn(name = "PARENT_ID"),
            @JoinColumn(name = "CHILD_ID")
    })
    private Child child;
    
    private String name;
    ...
}

// 손자 ID
@Embeddable
public class GrandChildId implements Serializable
{
    private ChildId childId; // @MapsId("childId")로 매핑
    
    @Column(name = "GRANDCHILD_ID")
    private String id;
    
    // equals, hashCode
    ...
}

@EmbeddedID는 식별 관계로 사용할 연관관계의 속성에 @MapsId를 사용하면 된다.

@MapsId("parentId")
@ManyToOne
@JoinColumn(name = "PARENT_ID")
public Parent parent;

@IdClass와 다른 점은 @Id 대신에 @MapsId를 사용한 점이다.

@MapsId는 외래 키와 매핑한 연관관계를 기본 키에도 매핑하겠다는 뜻이다.

@MapsId의 속성 값은 @EmbeddedId를 사용한 식별자 클래스의 기본 키 필드를 지정하면 된다.

04. 비식별 관계로 구현

부모 엔티티

@Entity
public class Parent
{
    @Id
    @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;
    private String name;
    ...
}

@Entity
public class Child
{
    @Id
    @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;
    private String name;
    
    @ManyToOne
    @JoinColumn(name = "PARENT_ID")
    private Parent parent;
    ...
}

@Entity
public class GrandChild
{
    @Id
    @GeneratedValue
    @Column(name = "GRANDCHILD_ID")
    private Long id;
    private String name;
    
    @ManyToOne
    @JoinColumn(name = "CHILD_ID")
    private Child child;
    ...
}

식별 관계의 복합 키를 사용한 코드와 비교하면 매핑도 쉽고 코드도 단순하다.

그리고 복합 키가 없으므로 복합 키 클래스를 만들지 않아도 된다.

05. 일대일 식별 관계

위 그림에서 일대일 식별 관계는 자식 테이블의 기본 키 값으로 부모 테이블의 기본 키 값만 사용한다.

그래서 부모 테이블의 기본 키가 복합 키가 아니면 자식 테이블의 기본 키는 복합 키로 구성하지 않아도 된다.

// 부모
@Entity
public class Board
{
    @Id
    @GeneratedValue
    @Column(name = "BOARD_ID")
    private Long id;
    
    private String title;
    
    @OneToOne(mappedBy = "board")
    private BoardDetail boardDetail;
    ...
 }
 
 // 자식
 @Entity
 public class BoardDetail
 {
     @Id
     private Long boardId;
     
     @MapsId // BoardDetail.boardId 매핑
     @OneToOne
     @JoinColumn(name = "BOARD_ID")
     private Board board;
     
     private String content;
     ...
}

BoardDetail처럼 식별자가 단순히 컬럼 하나면 @MapsId를 사용하고 속성 값은 비워두면 된다.

이때 @MapsId는 @Id를 사용해서 식별자로 지정한 BoardDetail.boardId와 매핑된다.

public void save()
{
    Board board = new Board();
    board.setTitle("제목");
    em.persist(board);
    
    BoardDetail boardDetail = new BoardDetail();
    boardDetail.setContent("내용");
    boardDetail.setBaord(board);
    em.persist(boardDetail);
}

저장하는 코드.

06. 식별, 비식별 관계의 장단점

DB 설계 관점에서 보면 다음과 같은 이유로 식별 관계보다는 비식별 관계를 선호한다.

• 식별 관계는 부모 테이블의 기본 키를 자식 테이블로 전파하면서 자식 테이블의 기본 키 컬럼이 점점 늘어난다. 때문에 조인할 때 SQL이 복잡해지고 기본 키 인텍스가 불필요하게 커질 수 있다.
• 식별 관계는 2개 이상의 컬럼을 합해서 복합 기본 키를 만들어야 하는 경우가 많다.
• 식별 관계를 사용할 때 기본 키로 비즈니스 의미가 있는 자연 키 컬럼을 조합하는 경우가 많다. 반면에 비식별 관계의 기본 키는 비즈니스와 전혀 관계없는 대리 키를 주로 사용한다. 비즈니스 요구사항은 시간이 지마넹 따라 언젠가는 변한다. 식별 관계으 ㅣ자연 키 컬럼들이 자식에 손자까지 전파되면 변경하기 힘들다.
• 식별 관계는 부모 테이블의 기본 키를 자식 테이블의 키본 키로 사용하므로 비식별 관계보다 테이블 구조가 유연하지 못하다.

객체 관계 매핑의 관점에서 보면 다음과 같은 이유로 비식별 관계를 선호한다.

• 일대일 관계를 제외하고 식별 관계는 2개 이상의 컬럼을 묶은 복합 기본 키를 사용한다. JPA에서 복합 키는 별도의 복합 키 클래스를 만들어서 사용해야 한다. 따라서 컬럼이 하나인 기본 키를 매핑하는 것보다 많은 노력이 필요하다.
• 비식별 관계의 기본 키는 주로 대리 키를 사용하는데 JPA는 @GenerateValue처럼 대리 키를 생성하기 위한 편리한 방법을 제공한다.

물론 식별 관계가 가지는 장점도 있다.

기본 키 인덱스를 활용하기 좋고, 상위 테이블들의 기본 키 컬럼을 자식, 손자 테이블들이 가지고 있으므로 특정 상황에 조인 없이 하위 테이블만으로 검색을 완료할 수 있다.

DB 테이블의 연관관계를 설계하는 방법은 크게 2가지다.

• 조인 컬럼 사용(외래 키)
• 조인 테이블 사용(테이블 사용)

조인 컬럼 사용

테이블 간에 관계는 주로 조인 컬럼이라 부르는 외래 키 컬럼을 사용해서 관리한다.

회원과 사물함이 있다.

각각 테이블에 데이터를 등록했다가 회원이 원할 때 사물함을 선택할수 있다는 가정.

회원이 사물함을 사용하기 전까지는 아직 둘 사이에 관계가 없으므로 MEMBER 테이블의 LOCKER_ID 외래 키에 null을 입력해두어야 한다.

이렇게 외래 키에 null을 허용하는 관계를 선택적 비식별 관계라 한다.

선택적 비식별 관계는 외래 키에 null을 허용하므로 회원과 사물함을 조인할 때 외부 조인을 사용해야 한다.

실수로 내부 조인을 사용하면 사물함과 관계가 없는 회원은 조회되지 않는다.

그리고 회원과 사물함이 아주 가끔 관계를 맺는다면 외래 키 값 대부분이 null로 저장되는 단점이 있다.

조인 테이블 사용

이 방법은 조인 테이블이라는 별도의 테이블을 사용해서 연관관계를 관리한다.

위의 조인 컬럼과 비교해보면 조인 컬럼을 사용하는 방법은 단순히 외래 키 컬럼만 추가해서 연관관계를 맺지만

조인 테이블을 사용하는 방법은 연관관계를 관리하는 조인 테이블을 추가하고 여기서 두 테이블의 외래 키를 가지고 연관관계를 관리한다.

따라서 MEMBER와 LOCKER에는 연관관계를 관리하기 위한 외래 키 컬럼이 없다.

위 그림을 보면 회원과 사물함 데이터를 각각 등록했다가 회원이 원할 때 사물함을 선택하면 MEMBER_LOCKER 테이블에만 값을 추가하면 된다.

조인 테이블의 가장 큰 단점은 테이블을 하나 추가해야 한다는 점이다.

따라서 관리해야 하는 테이블이 늘어나고 회원과 사물함 두 테이블을 조인하려면 MEMBER_LOCKER 테이블까지 추가로 조인해야 한다.

따라서 기본은 조인 컬럼을 사용하고 필요하다고 판단되면 조인 테이블을 사용하는게 바람직하다.

01. 일대일 조인 테이블

일대일 관계를 만들려면 조인 테이블의 외래 키 컬럼 각각에 총 2개의 유니크 제약조건을 걸어야 한다.

(PARENT_ID는 기본 키이므로 유니크 제약조건이 걸려있다.)

// 부모
@Entity
public class Parent
{
    @Id
    @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;
    private String name;
    
    @OneToOne
    @JoinTable(name = "PARENT_CHILD",
            joinColumns = @JoinColumn(name = "PARENT_ID"),
            inverseJoinColumns = @JoinColumn(name = "CHILD_ID")
    )
    private Chile child;
    ...
}

// 자식
@Entity
public class Child
{
    @Id
    @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;
    private String name;
    ...
}

부모 엔티티를 보면 @JoinColumn 대신에 @JoinTable을 사용했다.

@JoinTable의 속성은 다음과 같다.

• name : 매핑할 조인 테이블 이름
• joinColumns : 현재 엔티티를참조하는 외래 키
• inverseJoinColumns : 반대방향 엔티티를 참조하는 외래 키

public class Child
{
    ...
    @OneToOne(mappedBy = "child")
    private Parent parent;
}

양방향으로 매핑하려면 위 코드를 추가하면 된다

02. 일대다 조인 테이블

위 그림은 일대다 관계이다.

일대다 관계를 만들려면 조인 테이블의 컬럼 중 다(N)와 관련된 컬럼인 CHILD_ID에 유니크 제약조건을 걸어야 한다.

(CHILD_ID는 기본 키 이므로 유니크 제약조건이 걸려있다.)

// 부모
@Entity
public class Parent
{
    @Id
    @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;
    private String name;
    
    @OneToMany
    @JoinTable(name = "PARENT_CHILD",
            joinColumns = @JoinColumn(name = "PARENT_ID"),
            inverseJoinColumns = @JoinColumn(name = "CHILD_ID")
    )
    private List<Child> child = new ArrayList<Child>();
    ...
}

// 자식
@Entity
public class Child
{
    @Id
    @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;
    private String name;
    ...
}

03. 다대일 조인 테이블

다대일은 일대다에서 방향만 반대이다.

04. 다대다 조인 테이블

위 그림은 다대다 관계다.

다대다 관계를 만들려면 조인 테이블의 두 컬럼을 합해서 하나의 복합 유니크 제약조건을 걸어야한다.

(PARENT_ID, CHILD_ID는 기본 키이므로 유니크 제약조건이 걸려 있다.)

// 부모
@Entity
public class Parent
{
    @Id
    @GeneratedValue
    @Column(name = "PARENT_ID")
    private Long id;
    private String name;
    
    @ManyToMany
    @JoinTable(name = "PARENT_CHILD",
            joinColumns = @JoinColumn(name = "PARENT_ID"),
            inverseJoinColumns = @JoinColumn(name = "CHILD_ID")
    )
    private List<Child> child = new ArrayList<Child>();
    ...
}

// 자식
@Entity class Child
{
    @Id
    @GeneratedValue
    @Column(name = "CHILD_ID")
    private Long id;
    private String name;
    ...
}

잘 사용하지는 않지만 @SecondaryTable을 사용하면 한 엔티티에 여러 테이블을 잘 매핑할 수 있다.

@Entity
@Table(name = "BOARD")
@SecondaryTable(name = "BOARD_DETAIL",
    pkJoinColumns = @PrimaryKeyJoinColumn(name = "BOARD_DETAIL_ID"))
public class Board
{
    @Id
    @GeneratedValue
    @Column(name = "BOARD_ID")
    private Long id;
    
    private String title;
    
    @Column(table = "BOARD_DETAIL")
    private String content;
    ...
}

Board 엔티티는 @Table을 사용해서 BOARD 테입르과 매핑했다.

그리고 @SecondaryTable을 사용해서 BOARD_DETAIL 테이블을 추가로 매핑했다.

@SecondaryTable 속성

• @SecondaryTable.name :  매핑할 다른 테이블의 이름, 예제에서는 테이블명을 BOARD_DETAIL로 지정했다.
• @SecondaryTable.pkJoinColumns : 매핑할 다른 테이블의 기본 키 컬럼 속성, 예제에서는 기본 키 컬럼 명을 BOARD_DETAIL_ID로 지정했다. 

content 필드는 @Column(table = "BOARD_DETAIL")을 사용해서 BOARD_DETAIL 테이블의 컬럼에 매핑했다.

title 필드처럼 테이블을 지정하지 않으면 기본 테이블인 BOARD에 매핑된다.

더 많은 테이블을 매핑하려면 @SecondaryTables를 사용하면 된다.

@SecondaryTables({
    @SecondaryTable(name = "BOARD_DETAIL"),
    @SecondaryTable(name = "BOARD_FILE")
})

@SecondaryTable을 사용해서 두 테이블을 하나의 엔티티에 매핑하는 방법보다는 테이블당 엔티티를 각각 만들어서 일대일 매핑하는 것을 권장한다.

회원 엔티티

@Entity
public class Member
{
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String username;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    
    //Getter, Setter ...
    
}

팀 엔티티

@Entity
public class Team
{
    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    
    private String name;
    
    // Getter, Setter ...
    
}

회원은 Memger.team으로 팀 엔티티를 참조할 수 있지만 반대로 팀에는 회원을 참조하는 필드가 없다.

따라서 회원과 팀은 다대일 단방향 연관관계이다.

@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;

@JoinColumn(name = "TEAM_ID")를 사용해서 Member.team 필드를 TEAM_ID 외래 키와 매핑했다.

따라서 Member.team 필드로 회원 테이블의 TEAM_ID 외래키를 관리한다.

위 사진에서 실선은 연관관계의 주인이고, 점선은 연관관계의 주인이 아니다.

회원 엔티티

@Entity
public class Member
{
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String username;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    
    public void setTeam(Team team)
    {
        this.team = team;
        
        // 무한루프에 빠지지 않도록 체크
        if(!team.getMembers().contains(this)
        {
            team.getMembers().add(this);
        }
    }
}

팀 엔티티

@Entity
public class Team
{
    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    
    private String name;
    
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<Member>();
    
    public void addMember(Member member)
    {
        this.members.add(member);
        // 무한루프에 빠지지 않도록 체크
        if(member.getTeam() != this)
        {
            member.setTeam(this);
        }
    }
}

• 양방향 외래 키가 있는 쪽이 연관관계의 주인이다.

일대다와 다대일 연관관계는 항상 다(N)에 외래 키가 있다.

여기서는 MEMBER 테이블이 외래 키를 가지고 있으므로 Member.team이 연관관계의 주인이다.

JPA는 외래 키를 관리할 때 연관관계의 주인만 사용한다.

주인이 아닌 Team.members는 조회를 위한 JPQL이나 객체 그래프를 탐색할 때 사용한다.

• 양방향 연관관계는 항상 서로를 참조해야 한다

양방향 연관관계는 항상 서로 참조해야 한다.

어느 한 쪽만 참조하면 양방향 연관관계가 성립하지 않는다.

항상 서로 참조하게 하려면 연관관계 편의 메소드를 작성하는 것이 좋은데 회원의 setTeam(), 팀의 addMember() 메소드가 이런 편의 메소드들이다.

편의 메소드는 한 곳에만 작성하거나 양쪽 다 작성할 수 있는데, 양쪽에 다 작성하면 무한루프에 빠지므로 주의해야 한다.

하나의 팀은 여러 회원을 참조할 수 있는데 이런 관계를 일대다 관계라고 한다.

팀은 회원들을 참조하지만 반대로 회원은 팀을 참조하지 않으면 둘의 관계는 단방향이다.

일대다 단방향 관계는 약간 특이하다.

위 그림을 보면 팀 엔티티의 Team.members로 회원 테이블의 TEAM_ID 외래 키를 관리한다.

보통 자신이 매핑한 테이블의 외래 키를 관리하는데, 이 매핑은 반대쪽 테이블에 있는 외래 키를 관리한다.

어쩔 수 없는게, 일대다 관계에서 외래 키는 항상 다쪽 테이블에 있다.

따라서 반대편 테이블의 외래 키를 관리하는 특이한 모습이 나타난다.

팀 엔티티

@Entity
public class Team
{
    @Id 
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    
    private String name;
    
    @OneToMany
    @JoinColumn(name = "TEAM_ID") // MEMBER 테이블의 TEAM_ID(FK)
    private List<Member> members = new ArrayList<Member>();
    
    // Getter, Setter ...
}

회원 엔티티

@Entity
public class Member
{
    @Id 
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String username;
    
    // Getter, Setter ...
}

일대다 단방향 관계를 매핑할 때는 @JoinColumn을 명시해야 한다.

그렇지 않으면 연결 테이블을 중간에 두고 연관관계를 관리하는 조인 테이블(Join Table) 전략을 기본으로 사용해서 매핑한다.

• 일대다 단방향 매핑의 단점

일대다 단방향 매핑의 단점은 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있다는 점이다.

본인 테이블에 외래 키가 있으면 엔티티의 저장과 연관관계 처리를 INSERT SQL 한번으로 끝낼 수 있지만, 다른 테이블에 외래 키가 있으면 연관관계 처리를 위한 UPDATE SQL을 추가로 실행해야 한다.

public void testSave()
{
    Member member1 = new Member("member1");
    Member member2 = new Member("member2");    
    
    Team team1 = new Team("team1");
    team1.getMembers().add(member1);
    team1.getMembers().add(member2);    
    
    em.persist(member1); // INSERT-member1
    em.persist(member2); // INSERT-member2    
    em.persist(team1); // INSERT-team1
    				   // UPDATE-member1.fk,
    				   // UPDATE-member2.fk,                       
    transaction.commit();
}

위 코드를 실행한 결과 SQL은 다음과 같다.

insert into Member (MEMBER_ID, username) values (null, ?)
insert into Member (MEMBER_ID, username) values (null, ?)
insert into Team (TEAM_ID, name) values (null, ?)
update Member set TEAM_ID=? where MEMBER_ID=?
update Member set TEAM_ID=? where MEMBER_ID=?

Member엔티티는 Team엔티티를 모른다.

그리고 연관관계에 대한 정보는 Team엔티티의 members가 관리한다.

따라서 Member 엔티티를 저장할 때는 MEMBER테이블의 TEAM_ID 외래 키에 아무 값도 저장되지 않는다.

대신 Team엔티티를 저장할 때 Team.members의 참조 값을 확인해서 회원 테이블에 있는 TEAM_ID 외래 키를 업데이트한다.

결국 일대다 단방향  매핑보다는 다대일 양방향 매핑을 사용하는게 맞다.

일대다 단방향 매핑을 사용하면 엔티티를 매핑한 테이블이 아닌 다른 테이블의 외래 키를 관리해야 한다.

이것은 성능 문제 뿐만 아니라 관리도 부담스럽게 된다.

반면에 다대일 양방향 매핑은 관리해야 하는 외래 키가 본인 테이블에 있어서 위와 같은 문제가 발생하지 않는다.

양방향 매핑에서 @OneToMany는 연관관계의 주인이 될 수 없다.

왜냐하면 관계형 DB의 특성상 일대다, 다대일 관계는 항상 다쪽에 외래 키가 있다.

그렇다고 해도 일대다 양방향 매핑이 완전히 불가능한 것은 아니다.

일대다 단방향 매핑 반대편에 같은 외래 키를 사용하는 다대일 단방향 매핑을 읽기 전용으로 하나 추가하면 된다.

팀 엔티티

@Entity
public class Team
{
    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    
    private String name;
    
    @OneToMany
    @JoinColumnn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<Member>();
    
    // Getter, Setter ...

}

회원 엔티티

@Entity
public class Member
{
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    pricate String username;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)
    private Team team;
    
    // Getter, Setter ...
    
}

일대다 단방향 매핑 반대편에 단방향 매핑을 추가했다.

이렇게 되면 둘 다 같은 키를 관리하므로 문제가 발생할 수 있다.

따라서 반대편인 다대일 쪽에 insertable = false, updatable = false로 설정해서 읽기만 가능하게 했다.

이 방법은 일대다 양방향 매핑이라기 보다는 단방향 매핑 반대편에 읽기 전용으로 추가해서 양방향처럼 보이도록 하는 방법이다.

그래서 되도록이면 다대일 양방향 매핑을 사용하자.

일대일 관계를 구성할 때 객체지향 개발자들은 주 테이블에 외래 키가 있는 것을 선호한다.

JPA도 주 테이블에 외래키가 있으면 좀 더 편리하게 매핑할 수 있다.

단방향

MEMBER가 주 테이블이고 LOCKER는 대상 테이블이다.

@Entity
public class Member
{
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String username;
    
    @OneToOne
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
    ...
}

@Entity
public class Locker
{
    @Id
    @GerneratedValue
    @Column(name = "LOCKER_ID")
    private Long id;
    
    private String name;
    ...
}

일대일 관계이므로 객체 매핑에 @OneToOne을 사용했고 DB에는 LOCKER_ID 외래 키에 유니크 제약 조건(UNI)을 추가했다.

참고로 이 관계는 다대일 단방향(@ManyToOne)과 거의 비슷하다.

다음은 반대 방향을 추가해서 일대일 양방향 관계이다.

@Entity
public class Member
{
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String username;
    
    @OneToOne
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
    ...
}

@Entity
public class Locker
{
    @Id
    @GerneratedValue
    @Column(name = "LOCKER_ID")
    private Long id;
    
    private String name;
    
    @OneToOne(mappedBy = "locker")
    private Member member;
    ...
}

양방향이므로 연관관계의 주인을 정해야 한다.

MEMBER 테이블이 외래 키를 가지고 있으므로 Member 엔티티에 있는 Member.locker가 연관관계의 주인이다.

따라서 반대 매핑인 사물함의 Locker.member는 mappedBy를 선언해서 연관관계의 주인이 아니라고 설정했다.

단방향

일대일 관계 중 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않는다.

그리고 이런 모양으로 매핑할 수 있는 방법도 없다.

이때는 단방향 관계를 Locker에서 Member방향으로 수정하거나, 양방향 관계로 만들고 Locker를 연관관계의 주인으로 설정해야 한다.

이 방법은 다음 양방향에서 나온다.

(참고로 JPA2.0부터 일대다 단방향 관계에서 대상 테이블에 외래 키가 있는 매핑을 허용했다. 하지만 일대일 단방향은 이런 매핑을 허용하지 않는다.)

양방향

@Entity
public class Member
{
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String username;
    
    @OneToOne(mappedBy = "member")
    private Locker locker;
    ...
}

@Entity
public class Locker
{
    @Id
    @GeneratedValue
    @Column(name = "LOCKER_ID")
    private Long id;
    
    private String name;
    
    @OneToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;
    ...
}

일대일 매핑에서 대상 테이블에 외래 키를 두고 싶으면 이렇게 양방향으로 매핑한다.

주 엔티티인 Member 엔티티 대신에 대상 엔티티인 Locker를 연관관계의 주인으로 만들고, LOCKER 테이블의 외래 키를 관리하도록 했다.

회원 엔티티

@Entity
public class Member
{
    @Id 
    @Column(name = "MEMBER_ID")
    private String id;
    
    private String username;
    
    @ManyToMany
    @JoinTable(
        name = "MEMBER_PRODUCT", 
        joinColumns = @JoinColumn(name = "MEMBER_ID"), 
        inverseJoinColums = @JoinColum(name = "PRODUCT_ID")
        )
    private List<Product> products = new ArrayList<Product>();
    ...
}

상품 엔티티

@Entity
public class Product
{
    @Id
    @Column(name = "PRODUCT_ID")
    private String id;
    
    private String name;
    ...
}

회원 엔티티와 상품 엔티티를 @ManyToMany로 매핑했다.

여기서 중요한 점은 @ManyToMany와 @JoinTable 을 사용해서 연결 테이블을 바로 매핑한 것이다.

따라서 회원과 상품을 연결하는 회원_상품(Member_Product) 엔티티 없이 매핑을완료할 수 있다.

다음은 @JoinTable의 속성이다.

• @JoinTable.name : 연결 테이블을 지정한다. 여기서는 MEMBER_PRODUCT 테이블을 선택했다.
• @JoinTable.joinColums : 현재 방향인 회원과 매핑할 조인 컬럼 정보를 지정한다. MEMBER_ID로 지정했다.
• @JoinTable.inverseJoinColumns : 반대 방향인 상품과 매핑할 조인 컬럼 정보를 지정한다. PRODUCT_ID로 지정했다.

MEMBER_PRODUCT 테이블은 다대다 관계를 일대다, 다대일 관계로 풀어내기 위해 필요한 연결 테이블이 뿐이다.

@ManyToMany로 매핑한 덕분에 다대다 관계를 사용할 때는 이 연결 테이블을 신경 쓰지 않아도 된다.

저장

public void save()
{
    Product productA = new Product();
    productA.setId("productA");
    productA.setName("상품A");
    em.persist(productA);
    
    Member member1 = new Member();
    member1.setId("member1");
    member1.setUsername("회원1");
    member1.getProducts().add(productA) // 연관관계 설정
    em.persist(member1);
    
}

회원1과 상품A의 연관관계를 설정했으므로 회원1을 저장할 때 연결 테이블에도 값이 저장된다.

따라서 이 코드를 실행하면 다음과 같은 SQL이 실행된다.

INSERT INTO PRODUCT ...
INSERT INTO MEMBER ...
INSERT INTO MEMBER_PRODUCT ...

조회

public void find()
{
    Member member = em.find(Member.class, "member1");
    List<Product> products = member.getProducts(); // 객체 그래프 탐색
    for (Product p : products)
    {
        System.out.println("product.name = " + p.getName());
    }
}

member.getProducts()를 호출해서 상품 이름을 출력하면 다음 SQL이 실행된다.

SELECT * FROM MEMBER_PRODUCT MP
INNER JOIN PRODUCT P ON MP.PRODUCT_ID=P.PRODUCT_ID
WHERE MP.MEMBER_ID=?

실행된 SQL을 보면 연결 테이블인 MEMBER_PRODUCT와 상품 테이블을 주인해서 연관된 상품을 조회한다.

@ManyToMany 덕분에 복잡한 다대다 관계를 애플리케이션에서는 아주 단순하게 사용할 수 있다.

@Entity
public class Product
{
    @Id
    private String id;
    
    @ManyToMany(mappedBy = "products") // 역방향 추가
    private List<Member> members;
    ...
}

위 코드를 보면 다대다 매핑이므로 역방향도 @ManyToMany를 사용한다.

그리고 양쪽 중 원하는 곳에 mappedBy로 연관관계의 주인을 지정한다(물론 mappedBy가 없는 곳이 연관관계의 주인이다.)

member.getProducts().add(product);
product.getMembers().add(member);

다대다의 양방향 연관관계는 다음처럼 설정하면 된다.

public void addProduct(Product product)
{
    ...
    products.add(product);
    product.getMembers().add(this);

양방향 연관관계는 연관관계 편의 메소드를 추가해서 관리하는 것이 편리하다.

위 코드처럼 회원 엔티티에 연관관계 편의 메소드를 추가했다.

연관관계 편의 메소드를 추가했으므로 .addProduct() 메소드로 간단히 연관관계를 설정할 수 있게 되었다.

public void findInverse()
{
    Product product = em.find(Product.class, "productA");
    List<Member> members = product.getMembers();
    for (Member m : members)
    {
        System.out.println("member = " + member.getUsername());
    }
}

양방향 연관관계로 만들었으므로 product.getMembers()를 사용해서 역방향으로 객체 그래프를 탐색할 수 있다.

@ManyToMany를 사용하면 연결 테이블을 자동으로 처리해주므로 도메인 모델이 단순해지고 여러 가지로 편리하다.

하지만 이 매핑을 실무에서 사용하기에는 한계가 있다.

예를 들어 회원이 상품을 주문하면 연결 테이블에 단순히 주문한 회원 아이디와 상품 아이디만 담고 끝나지 않는다.

보통은 연결 테이블에 주문 수량 컬럼이나 주문한 날짜 같은 컬럼이 더 필요하다.

위 그림을 보면 연결 테이블에 주문 수량(ORDERAMOUNT) 과 주문 날짜(ORDERDATE) 컬럼을 추가했다.

이렇게 컬럼을 추가하면 더는 @ManyToMany를 사용할 수 없다.

왜냐하면 주문 엔티티나 상품 엔티티에는 추가한 컬럼들을 매핑할 수 없기 때문이다.

결국 위 그림처럼 연결 테이블을 매핑하는 연결 엔티티를 만들고 이곳에 추가한 컬럼들을 매핑해야 한다.

그리고 엔티티 간의 관계도 테이블 관계처럼 다대다에서 일대다, 다대일 관계로 풀어야 한다.

여기서는 회원상품(MemberProduct)엔티티를 추가했다.

@Entity
public class Member
{
    @Id
    @Column(name = "MEMBER_ID")
    private String id;
    
    // 역방향
    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProducts;
    
    ...
}

연결 테이블에 주문 수량(ORDERAMOUNT)과 주문 날짜(ORDERDATE) 컬럼을 추가했고 나머지 테이블은 기존과 같다.

회원과 회원상품을 양방향 관계로 만들었다.

회원상품 엔티티 쪽이 외래키를 가지고 있으므로 연관관계의 주인이다.

따라서 연관관계의 주인이 아닌 회원의 Member.memberProducts에는 mappedBy를 사용했다.

@Entity
public class Product
{
    @Id
    @Column(name = "PRODUCT_ID")
    private String id;
    
    private String name;
    
    ...
}

위 코드를 보면 상품 엔티티에서 회원상품 엔티티로 객체 그래프 탐색 기능이 필요하지 않다고 판단해서 연관관계를 만들지 않았다.

회상품 엔티티 코드

@Entity
@IdClass(MemberProdudctId.class)
public class MemberProduct
{
    @Id
    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member; // MemberProductId.member와 연결
    
    @Id
    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product; // MemberProductId.product와 연결
    
    private int orderAmount;
    
    ...
}

회원상품 식별자 클래스

public class MemberProductId implements Serializable
{
    private String member; // MemberProduct.member와 연결
    private String product; // MemberProduct.product와 연결
    
    // hashCode and equals
    
    @Override
    public boolean equals(Object o) {...}
    
    @Override
    public int hashCode() {...}
}

회원상품(MemberProduct)엔티티를 보면 기본 키를 매핑하는 @Id와 외래 키를 매핑하는 @JoinColumn을 동시에 사용해서 기본 키 + 외래 키를 한번에 매핑했다.

그리고 @IdClass를 사용해서 복합 기본 키를 매핑했다.

• 복합 기본 키

회원상품 엔티티는 기본 키가 MEMBER_ID와 PRODUCT_ID로 이루어진 복합 기본지(간단히 복합키)다.

JPA에서 복합 키를 사용하려면 별도의 식별자 클래스를 만들어야 한다.

그리고 엔티티에 @IdClass를 사용해서 식별자 클래스를 지정하면 된다.

여기서는 MemberProductId 클래스를 복합 키를 위한 식별자 클래스로 사용한다.

복합키를 위한 식별자 클래스는 다음과 같은 특징이 있다.

• 복합 키별도의 식별자 클래스로 만들어야 한다.
• Serializable을 구현해야 한다.
• equals와 hashCode 메소드를 구현해야 한다.
• 기본생성자가 있어야 한다.
• 식별자 클래스는 public 이어야 한다.
• @IdClass를 사용하는 방법 외에 @EmbeddedId를 사용하는 방법도 있다.

• 식별 관계

회원상품은 회원과 상품의 기본 키를 받아서 자신의 기본 키로 사용한다.

이렇게 부모 테이블의 기본 키를 받아서 자신의 기본 키 + 외래 키로 사용하는 것을 DB용어로 식별관계라고 한다.

종합해보면

회원상품(MemberProduct)은 회원의 기본 키를 받아서 자신의 기본 키로 사용함과 동시에 회원과의 관계를 위한 외래 키로 사용한다.

그리고 상품의 기본 키도 받아서 자신의 기본 키로 사용함과 동시에 상품과의 관계를 위한 외래 키로 사용한다.

또한 MemberProductId 식별자 클래스로 두 기본 키를 묶어서 복합 기본 키로 사용한다.

public void save()
{
    // 회원 저장
    Member member1 = new Member();
    member1.setId("member1");
    member1.setUsername("회원1");
    em.persist(member1);
    
    // 상품 저장
    Product productA = new Product();
    productA.setId("productA");
    productA.setName("상품1");
    em.persist(productA);
    
    // 회원상품 저장
    MemberProduct memberProduct = new MemberProduct();
    memberProduct.setMember(member1); 	// 주문 회원 - 연관관계 설정
    memberProduct.setProduct(productA); // 주문 상품 - 연관관계 설정
    memberProduct.setOrderAmount(2); 	// 주문 수량
    
    em.persist(memberProduct);
}

위 코드로 회원상품 엔티티를 만들면서 연관된 회원 엔티티와 상품 엔티티를 설정했다.

회원상품 엔티티는 DB에 저장될 때 연관된 회원의 식별자와 상품의 식별자를 가져와서 자신의 기본 키 값으로 사용한다.

public void find()
{
    // 기본 키 값 생성
    MemberPRoductId memberProductId = new MemberProductId();
    memberProductId.setMember("member1");
    memberPRoductId.setProduct("productA");
    
    MemberProduct memberProduct = em.find(MemeberProduct.class, memberProductId);
    
    Member member = memberProduct.getMember();
    Product product = memberProduct.getProduct();
    
    System.out.println("member = " + member.getUsername());
    System.out.println("product = " + product.getName());
    System.out.println("orderAmount = " + memberProduct.getOrderAmount());
    
}

지금까지는 기본 키가 단순해서 기본 키를 위한 객체를 사용하는 일이 없었지만 복합 키가 되면 이야기가 달라진다.

복합 키는 항상 식별자 클래스를 만들어야 한다.

em.find()를 보면 생성한 식별자 클래스로 엔티티를 조회한다.

복합 키를 사용하는 방법은 복잡하다. 

단순히 컬럼 하나만 기본 키로 사용하는 것과 비교해서 복합 키를 사용하면 ORM 매핑에서 처리할 일이 상당히 많아진다.

복합 키를 위한 식별자 클래스도 만들어야 하고 @IdClass 또는 @EmbeddedId도 사용해야 한다.

그리고 식별자 클래스에 equals, hashCode도 구현해야 한다.

추천하는 기본 키 생성 전략은 DB에서 자동으로 생성해주는 대리 키를 Long값으로 사용하는 것이다.

이것의 장점은 간편하고 거의 영구히 쓸 수 있으며 비즈니스에 의존하지 않는다.

그리고 ORM 매핑 시에 복합 키를 만들지 않아도 되므로 간단히 매핑을 완성할 수 있다.

이번에는 연결 테이블에 새로운 기본 키를 사용할 것이다.

이 정도 되면 회원상품(MemberProduct)보다는 주문(Order)이라는 이름이 더 어울릴 것이다.

ORDER_ID라는 새로운 기본 키를 하나 만들고 MEMBER_ID, PRODUCT_ID 컬럼은 외래 키로만 사용한다.

@Entity
public class Order
{
    @Id
    @GeneratedValue
    @Column(name = "ORDER_ID")
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;
    
    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;
    
    private int orderAmount;
    ...
}

대리 키를 사용함으로써 이전에 보았던 식별 관계에 복합 키를 사용하는 것보다 매핑이 단순하고 이해하기 쉽다.

다음은 저장하고 조회하는 코드이다.

public void save()
{
    // 회원 저장
    Member member1 = new Member();
    member1.setId("member1");
    member1.setUsername("회원1");
    em.persist(member1);
    
    // 상품 저장
    Product productA = new Product();
    productA.setId("productA");
    productA.setName("상품1");
    em.persist(productA);
    
    // 주문 저장
    Order order = new Order();
    order.setMember(member1);	// 주문 회원 - 연관관계 설정
    order.setProduct(productA); // 주문 회원 - 연관관계 설정
    order.setOrderAmount(2); 	// 주문 수량
    em.persist(order);
}

운영체제란

컴퓨터의 효율적인 운영을 담당하는 시스템 소프트웨어

• 시스템의 자원인 CPU, RAM, HDD, I/O장치, 네트워크 등을 효율적으로 관리하고 운영
• 사용자와 컴퓨터 하드웨어 간의 인터페이스 역할을 함

운영체제의 목표

1. 컴퓨터 내의 하드웨어/소프트웨어 자원을 관리함
2. 컴퓨터에 사용자가 쉽게 접근할 수 있는 인터페이스를 제공함
3. 수행 중인 프로그램들의 효율적인 운영을 도움
4. 작업 처리 과정 중의 데이터를 공유함
5. 입출력에 보조적인 기능을 수행함
6. 오류가 발행하면 오류를 처리함

운영체제의 기능

• 프로세스 관리 : 프로세스의 생성, 삭제, 동기화 등에 관여
• 작업 관리 : 프로세스가 수행하는 작업에 대한 관리
• 주기억 장치 관리 : 주기억 장치의 할당과 회수를 관리
• 보조기억 장치 관리 : 보조기억 장치의 사용을 관리
• 입출력 장치 관리 : 입출력 장치를 관리함
• 파일 관리 : 파일 생성·빈 공간 관리·디스크 스케줄링 등을 담당
• 보안 관리사용자 계정 관리 및 불법 침입 등 보안 관련 사항 관리

일괄처리(Batch Processing)

• 여러 사용자들의 작업들을 모아서 일괄적으로 순서대로 처리하는 방식
• 실행 요청 순서에 따라 순차적으로 프로그램을 실행

다중프로그래밍(Multi-programming)

• 한 프로그램이 입출력 등의 작업을 할 때 다른 프로그램을 수행
• 중앙처리장치를 쉬게 하지 않고 처리하게 하여 전체적인 처리 속도를 향상시키는 방식

시분할 시스템(Time-sharing System)

• CPU 운영 시간을 잘게 쪼개어 여러 사용자에게 골고루 처리 시간을 제공
• 특정 사용자가 오래 기다리는 것을 방지

다중처리(Multi-Processing)

• 두 개 이상의 프로세서로 구성된 시스템의 운영체제로서, 단일 처리 시스템보다 많은 양의 작업을 동시에 처리할 수 있는 방식

유닉스(Unix)

• 고가의 컴퓨터를 여러 사람이 이용할 수 있는 운영체제 개발을 시도
• 1960년대 초 : MIT, Bell Lab, GE 등이 공동으로 MULTICS 개발 시작
• 1969년 AT&T 연구원 Ken Tompson과 Dennis Ritchie가 UNICS 개발
• 1973년 Dennis Ritchie가 C언어로 다시 개발 -> 고급 언어로 작성된 최초의 운영체제
• 1976년 미국의 대학과 기업에 확산
• 1978년 버클리 대학의 Bill Joy와 Chuck Haley가 BSD* UNIX 발표
• 1983년 AT&T가 System V 발표
• 특징
  • 전문 프로그래머용으로 개발 다양한 프로그램 제작
  • 고급 언어로 작성되어 다양한 하드웨어에 설치 가능
  • 연구용으로 소스 공개 대학이나 연구소에서 많이 사용
  • 다중 사용자 시스템
  • 강력한 네트워크 기능 지원
  • X Windows 도구로 GUI 환경 제공

리눅스(Linux)

• 1991년 핀란드의 헬싱키 대학생이던 Linus Torvalds가 개발
• GNU 프로젝트에 참여하면서 급속하게 성장
• 무료이며 소스 코드가 완전히 공개된 운영체제
• 누구나 다운받아 설치할 수 있으며, 다수의 배포판이 존재

Mac OS

• 애플에서 개발한 GUI 기반의 운영체제
• FreeBSD를 변형하여 매킨토시 컴퓨터에서 동작
• 1984년~2001년 : 클래식 Mac OS (버전 1 ~ 9)
• 2001년~2015년 : Mac OS X
• 2016년 ~ 현재 : macOS
  • 아이맥, 맥북프로 출시 (인텔기만 매킨토시) 
  • iOS, watchOS, tvOS 와 통일된 명칭 사용

Window OS

• 마이크로소프트사에서 만든 그래픽 사용자 인터페이스(GUI)기반 운영체제
• 1985년 Windows 1.0
• 1992년 Windows 3.1 : MS-DOS에 GUI를 추가한 구조
• 1995년 Windows 95 : 자체적 GUI 환경의 OS
• 2001년 Windows XP : 윈도우 NT 기반으로 전면 개선
• 2009년 Windows 7
• 2012년 Windows 8
• 2015년 Windows 10
• 2021년 Windows 11

프로세스(Process)

실행을 위해서 주기억장치에 올려진 프로그램 (운영체제 관리)

프로그램 코드 뿐만 아니라 실행에 필요한 다양한 정보도 포함

운영체제에서 실행되는 시스템 작업의 기본 단위

프로세스 생명 주기

준비 : 프로세스 실행 기다림

실행 : CPU에서 프로세스 실행, CPU는 한순간에 하나의 프로세스만 실행

대기 : 어떤 사건이 일어나기를 기다림

프로세스 제어 블록(Process Control Block)

• 운영체제는 프로세스 각각에 대한 정보 관리를 통해 프로세스를 제어함
• 프로세스에 대한 정보는 PCB(Process Control Block)에 저장됨
• 임의의 프로세스가 생성되면 PCB가 생성되며 프로세스 종료 시 없어짐
• PCB 정보
  • 프로세스의 상태 : 실행 상태인지 또는 실행을 위해 준비상태인지 등의 정보
  • PC 값 : 다음에 실행될 명령어의 주기억장치 주소를 의미, PC 레지스터에 저장
  • 스케줄링 정보 : 다음에 실행될 프로세스를 결정하는 데 필요한 정보로, 프로세스 스케줄링 정책, 우선순위등을 의미
  • 주기억장치 정보 : 해당 프로세스가 주기억장치 어느 영역에 위치해있는지를 저장 

프로세스 생성

• 생성된 프로세스 A의 프로세스 제어 블록이 준비 큐에 연결 - 준비 상태
• 중앙처리장치가 프로세스 A를 실행 - 실행 상태

프로세스 상태 - 준비, 실행

• 프로세스 B와 C가 생성, 준비 상태
• 중앙처리장치가 프로세스 A를 실행 – 실행 상태

프로세스 상태 - 대기

• 프로세스 A에 디스크 입출력 명령이나 sleep 명령이 발생할 경우 : 대기 상태
• 기다리던 이벤트가 종료되면 준비 큐로 이동해서 준비 상태가 됨

프로세스 종료

• 프로세스 A의 실행이 종료된 경우 : PCB와 프로세스가 메모리에서 삭제됨

다중 프로그래밍(Multi-programming)

• 여러 개의 프로세스를 주기억장치에 적재
• 실행 중인 프로세스가 대기하는 경우 다른 프로세스가 CPU에서 실행
• CPU 이용률을 최대화하는 개념

프로세스 스케줄링(Process Scheduling)

운영체제가 어떤 프로세스를 실행할 지를 결정하는 것

• FCFS(First-Come First-Served) 스케줄링 : 먼저 도착한 프로세스를 먼저 서비스(실행)하는 방법
• 라운드 로빈(Round Robin) 스케줄링
• Shortest-Job-First(SJF)

라운드 로빈(Round Robin) 스케줄링

• 여러 프로세스들이 CPU를 돌아가며 일정한 시간을 할당받아 실행되는 방식
• 프로세스들은 시간 할당량(time quantum) 동안 CPU를 할당받아 실행

Shortest-Job-First(SJF)

• 각 프로세스는 자신의 수행 시간을 제시
• 수행 시간이 가장 작은 프로세스에 먼저 CPU를 할당
• 작업들의 평균 대기시간이 최소가 됨
• 단점 : 무한봉쇄(Indefinite blocking), 기아상태(Starvation)

우선순위(Priority) 스케줄링

• 가장 높은 우선순위의 프로세스에게 먼저 CPU를 할당
• 우선 순위가 같은 프로세스는 FCFS 방법을 적용
• 단점 : 무한봉쇄(Indefinite blocking), 기아상태(Starvation)
• 에이징(Aging) 기법 : 기다린 시간에 비례하여 우선 순위를 높여줌

스케줄링 평가 기준

1. 공정성 (특정 프로세스가 불이익을 당하는가) 
2. Throughput (단위시간에 끝나는 작업 수) 
3. Response time 
4. 요청 목적에 맞는가(급한 작업, 여유 있는 작업) 
5. 예측 가능성 (요청 시마다 시간 편차가 큰지 여부) 
6. 오버 헤드 최소화 (스케줄링에 소요되는 시간과 공간) 
7. 균형적인 자원 이용 (다른 자원의 활용도를 높이는가)

주기억장치(Main Memory)

• 현재 실행 중인 프로그램과 이 프로그램이 필요로 하는 데이터를 일시적으로 저장하는 장치
• 운영체제는 현재 사용되고 있는 주기억장치 영역과 사용되지 않는 영역에 대한 정보를 유지
• 프로세스에게 메모리를 할당하고, 프로세스가 종료되면 회수

단일 프로그래밍

• 주기억장치에 운영체제 외 한 개의 사용자 프로그램만 저장하는 관리 기법
• 주기억장치를 두 영역으로 나누어 저장

다중 프로그래밍 - 분할 메모리 관리

• 주기억장치(메모리)를 n개의 영역으로 분할하여 서로 다른 프로세스를 동시에 저장

분할 메모리 관리 할당 방식

• 새롭게 생성된 프로세스를 메모리에 할당하는 방식
• 최초 적합 : 프로세스의 크기보다 큰 최초의 영역에 할당
• 최적 적합 : 프로세스의 크기보자 큰 영역 중 가장 작은 영역에 할당
• 최악 적합 : 프로세스의 크기보다 큰 영역 중 가장 큰 영역에 할당

가상 메모리(Virtual Memory)

• 실행될 프로그램이 주기억장치보다 크거나 여러 개인 경우에는 주기억장치의 공간 부족으로 인해 프로그램 실행에 제약이 됨
• 당장 실행에 필요한 부분만 주기억장치에 저장하고, 당장 필요하지 않는 나머지 부분은 보조기억장치에 넣어두고 실행

페이지(Page)

• 프로그램을 일정한 크기로 나눈 단위 
• 페이지 단위로 주기억장치에 프로그램이 올라가서 동작

페이징(Paging)

• 가상메모리를 구현하는 한 방법
• 페이지 프레임 : 실제 주기억장치의 페이지가 저장되는 고정된 크기의 블록

페이지 테이블 (Page Table)

• 프로세스마다 각 페이지가 주기억장치의 어느 프레임에 저장되는지를 나타내는 테이블

페이지 교체

새로운 페이지를 주기억장치에 저장할 때 비어있는 프레임이 없으면?

-> 새로운 페이지를 저장하기 위해 주기억장치에서 제거할 페이지를 결정하고 교체함

페이지 교체 알고리즘

• FIFO (First-In First-Out) 알고리즘
  • 페이지를 교체해야 할 때 주기억장치에 가장 먼저 올라온 페이지를 선택해서 제거하는 기법
• LRU (Least Recently Used) 알고리즘
  • 페이지를 교체해야 할 때, 주기억장치에 올라온 페이지들 중에서 가장 오랫동안 사용되지 않았던 페이지를 선택해서 제거하는 기법
• LFU(Least Frequently Used)알고리즘
  • 페이지를 교체해야 할 때 페이지들 중에서 사용 빈도가 가장 낮은 페이지를 선택해서 제거하는 기법

파일 시스템

• 파일은 보조기억장치에 저장된 연관성 있는 정보(데이터)의 집합
• 프로세스가 파일을 생성할 때 이름을 부여
• 파일을 읽고 쓰는 동작은 운영체제가 담당

FAT(File Allocation Table)

• 트랙(Track)과 섹터(Sector)로 구성
• 간단한 구조로 PC 운영체제 대부분이 지원 - 파일 공유에 적합
• 메모리 카드나 USB 메모리 등에서 사용
• 디스크 오류 등 발생 시 안정성이 떨어짐
• FAT, FAT16, FAT32, VFAT 등 형식이 존재
• exFAT는 파일 크기 한계를 극복 - 최대 512TB까지 저장

NTFS(New Technology File System)

• FAT을 대체하기 위해 개발
• 메타데이터 지원, 성능 개선, 신뢰성 향상 등
• 파일 용량 한계 확장
  • FAT32 : 파일 최대 4GB, 드라이브 최대 32GB
  • NTFS : 파일 최대 16TB, 드라이브 256TB
• 보안성, 안정성이 뛰어나지만 호환성이 부족

HFS(Hierarchical Technology File System)

• 애플이 개발한 파일시스템
• Mac OS에서 사용
  • 파일개수 최대 65,536개
  • 파일 용량 최대 2GB
• 1998년 HFS+ 발표
• 2016년 APFS(Apple File System)으로 전환