JJ_blog

Semaphore Vs Mutex

HJ39 — Tue, 9 Jan 2024 17:11:54 +0900

Mutex

Mutual Exclusion의 합성어로 공유된 자원의 데이터나 임계영역(critical Section) 같은 곳에 스레드들의 서로 겹치지 않거나 하나의 프로세스나 스레드가 접근하는 것을 막는다.

동기화 대상이 1개
다른 스레드들은 뮤텍스의 lock을 가지기 위해 대기하고 락을 해제하는 스레드가 있을 때까지 접근하지 못한다.
Key 기반으로 한 상호배제 기법이다.
다중 프로세스들의 공유 리소스에 접근을 조율하기 위해 동기화(Sync) 또는 락(Lock)을 사용

그림을 보면 쉽게 이해할 수 있다.

카운터에 있는 화장실 키를 누군가가 가지고 화장실을 이용 중인 경우

다른 사람은 해당 화장실을 이용할 수 없다.

하지만 이용을 마친 누군가가 Key를 카운터에 다시 가져다 놓으면 다른 사람들이 화장실을 이용할 수 있다.

이러한 방법이 Mutex이다.

Semaphore

사용하고 있는 스레드/프로세스의 수를 공통으로 관리하는 하나의 값을 이용해 상호배제를 달성한다.
공유 자원에 접근할 수 있는 프로세스의 최대 허용치만큼 동시에 접근할 수 있다.
다른 프로세스들이 모두 사용 중인 경우 기다려야 한다.

화장실이 칸이 여러 개인 경우

비어있으면 즉시 이용가능하지만

만약 칸이 모두 차있는 경우 다음 사람은 이용하지 못하고 기다려야 한다.

이런 방법이 세마포어이다.

차이점

	Mutex	Semaphore
동기화 개수	1개	1개 이상
자원 소유	자원 소유가 가능 + 책임	자원 소유 불가
해제	소유하고 있는 스레드만이 해제가능하다.	소유하지 않는 스레드도 해제할 수 있다.
범위	프로세스의 범위를 가지고 종료될때 자동으로 사라진다.	시스템 범위에 걸쳐있고 파일 시스템 상 파일로 존재한다.

데이터 무결성을 보장할 수 없고, 모든 교착상태를 해결하지 못한다.

# 참고한 사이트

[OS] 뮤텍스(Mutex)와 세마포어(Semaphore)란?

프로세스 간 메시지를 전송하거나, 공유메모리를 통해 공유된 자원에 여러 개의 프로세스가 동시에 접근하면 Critical Section 문제가 발생할 수 있다. 이를 해결하기 위해 데이터를 한 번에 하나의

chelseashin.tistory.com

Component Scan

HJ39 — Tue, 9 Jan 2024 00:52:18 +0900

의존 관계 자동 주입

설정정보가 없어도 자동으로 스프링 빈을 등록해 준다.
@Autowired 기능도 제공해 준다.

사용방법

□ Config파일에 @ComponentScan Annotation 붙이기

@Configuration
@ComponentScan
public class AutoAppConfig {

}

□ 스프링 빈에 등록할 클래스들에 @Component Annotation을 붙인다.

@Component
public class MemoryMemberRepository implements MemberRepository {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
 public class MemberServiceImpl implements MemberService {
     private final MemberRepository memberRepository;
     
     @Autowired
     public MemberServiceImpl(MemberRepository memberRepository) {
         this.memberRepository = memberRepository;
     }
}

생성자에 @Autowired Annotation을 붙이면 자동으로 객체를 주입시켜 준다.

작동 순서

□ @ComponentScan

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.

□ @Autowired 의존관계 자동 주입

생성자에 @Autowired를 지정하면 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.

탐색 위치와 기본 스캔 대상

모든 자바 클래스들을 스캔하면 너무 오래 걸린다. 따라서 꼭 필요한 위치부터 탐색하도록 시작 위치를 지정할 수 있다.

@ComponentScan(
         basePackages = "hello.core",
}

package를 "hello.core"로 시작위치를 정할 수 있다. 해당 패키지 하위 패키지를 모두 탐색한다.
지정하지 않은 경우 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.
설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것을 권장한다.

컴포넌트 스캔 대상

종류	설명
@Component	- 컴포넌트 스캔에서 사용
@Controller	- 스프링 MVC 컨트롤러에서 사용
@Service	- 스프링 비즈니스 로직에서 사용
@Repository	- 스프링 데이터 접근 계층에서 사용 - 데이터 계층의 예외를 스프링 예외로 변환
@Configuration	- 스프링 설정 정보에서 사용 - 스프링 빈이 싱글톤을 유지하도록 추가 처리

중복 등록과 충돌

□ 자동 빈 등록 vs 자동 빈 등록

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 이름이 같은 경우 스프링은 오류를 발생시킨다.
- ConflictingBeanDefinitionException 예외 발생

□ 수동 빈 등록 vs 자동 빈 등록

수동 빈 등록이 우선권을 가지고 자동 빈을 오버라이딩 해버린다.

Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true`

충돌이 나는 경우 이와 같은 에러를 스프링에서 발생시킨다.

하지만 spring.main.allow-bean-definition-overriding=true 다음과 같이 설정하는 경우 오버라이딩 된다.

# 참고한 자료

인프런 김영한 님 강의

Singleton Container

HJ39 — Tue, 9 Jan 2024 00:24:52 +0900

□ 스프링 없는 DI 컨테이너로 구성된 경우

스프링 없는 순수한 DI 컨테이너인 AppConfig를 요청할 때마다 새로 생성한다.
- ex) 트래픽이 초당 100인 경우 초당 100개 객체가 생성되고 소멸된다. → 메모리 낭비가 심하다.
- 싱글톤 패턴으로 해결 가능

□ 싱글톤 컨테이너를 적용 후

싱글톤 패턴

private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.
객체 인스턴스를 2개 이상 생성하지 못하게 막아야 한다.

□ 싱글톤 예제 코드

 public class SingletonService {
    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();
    
    //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingletonService getInstance() {
         return instance;
    }
    
    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다. 
    private SingletonService() { }
    
    public void logic() { 
    	System.out.println("싱글톤 객체 로직 호출");
    } 
}

□ 싱글톤 패턴 테스트 코드

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용") 
public void singletonServiceTest() {
    //private으로 생성자를 막아두었다. 컴파일 오류가 발생한다.
    //new SingletonService();
    
    //1. 조회: 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService1 = SingletonService.getInstance(); 
    
    //2. 조회: 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService2 = SingletonService.getInstance();
    
    //참조값이 같은 것을 확인
    System.out.println("singletonService1 = " + singletonService1); 
    System.out.println("singletonService2 = " + singletonService2);
    
    // singletonService1 == singletonService2
    assertThat(singletonService1).isSameAs(singletonService2);
    singletonService1.logic();
}

해당 코드에는 문제점이 존재한다.

□ 문제점

싱글톤 패턴을 구현하는 코드가 많이 들어간다.
의존관계상 클라이언트 객체가 구체 클래스에 의존한다. → DIP를 위반한다.
클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
테스트하기 어렵다.
내부 속성을 변경하거나 초기화하기 어렵다.
private 생성자로 자식 클래스를 만들기 어렵다.
유연성이 떨어진다.
안티패턴으로 불린다.

싱글톤 컨테이너

싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
- 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.

□ 스프링 컨테이너를 사용한 테스트 코드

@Test
@DisplayName("스프링 컨테이너와 싱글톤") 
void springContainer() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    //1. 조회: 호출할 때 마다 같은 객체를 반환
    MemberService memberService1 = ac.getBean("memberService", MemberService.class);

    //2. 조회: 호출할 때 마다 같은 객체를 반환
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);

    //참조값이 같은 것을 확인
    System.out.println("memberService1 = " + memberService1); 
    System.out.println("memberService2 = " + memberService2);
    
    //memberService1 == memberService2
    assertThat(memberService1).isSameAs(memberService2);
}

싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
- 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
- DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

주의점

stateless(무상태)로 설계해야 한다.
- 특정 클라이언트에 의존적인 필드가 있으면 안 된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 된다.
- 가급적 읽기만 가능해야 한다.
- 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

□ 자바 코드 설정 파일

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
         return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public OrderService orderService() {
         return new OrderServiceImpl(
                 memberRepository(),
                 discountPolicy());
    }
    
    @Bean
    public MemberRepository memberRepository() {
         return new MemoryMemberRepository();
    }
	... 
}

해당 코드를 유심하게 보면

memberService()를 호출하는 경우 memberRepository()를 호출하여 MemoryMemberRepository객체가 생성된다.

orderService()를 호출하는 경우 memberRepository()를 호출하여 MemoryMemberRepository객체가 생성된다.

이런 경우 각각 2개의 MemoryMemberRepository 객체가 생성되는 것이 아닐까?

□ 위 상황을 위한 테스트 코드

public class ConfigurationSingletonTest {
    @Test
    void configurationTest() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        //모두 같은 인스턴스를 참고하고 있다.
        System.out.println("memberService -> memberRepository = " + memberService.getMemberRepository());
        System.out.println("orderService -> memberRepository  = " + orderService.getMemberRepository());
        System.out.println("memberRepository = " + memberRepository);
        
        //모두 같은 인스턴스를 참고하고 있다.
        assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
    }
}

테스트 결과를 보면 MemoryMemberRepository 객체가 2번 생성되는 것이 아닌 1개의 객체를 생성하는 것을 알 수 있다.

왜 그런 걸까?

Configuration 살펴보면 알 수 있다.

@Configuration

□ 스프링 빈에 등록된 클래스 정보를 알아보는 코드

@Test
void configurationDeep() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    
    //AppConfig도 스프링 빈으로 등록된다.
    AppConfig bean = ac.getBean(AppConfig.class);
    System.out.println("bean = " + bean.getClass());
	//출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70 
}

출력 결과를 보면 AppConfig$$xxxxxxxCGLIBxxxxx 이러한 형태로 출력되어 있다.

스프링 빈에 등록할 때 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들어 스프링 빈에 등록한 것이다! (@Configuration 내부에 CGLIB 라이브러리가 있다.)

이를 통해 예상할 수 있는 것은

CGLIB 내부 코드에서 MemoryMemberRepository 객체가 스프링 컨테이너에 생성되어 있다면 찾아서 return 하고,

없다면 MemoryMemberRepository 객체를 생성하여 스프링 컨테이너에 등록한다는 것을 예상할 수 있다.

# 참고한 자료

인프런 김영한 님 강의

Container와 Bean

HJ39 — Mon, 8 Jan 2024 23:43:51 +0900

□ 스프링 컨테이너 생성

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext는 스프링 컨테이너이다.
ApplicationContext는 인터페이스이다.
Annotation 기반의 자바 설정 클래스, 스프링 컨테이너는 XML을 기반으로 만들 수 있다.

스프링 컨테이너 생성 과정

□ 스프링 컨테이너 생성

new AnnotationConfigApplicationContext(AppConfig.class);

스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야 한다.
해당 사진에서는 AppConfig.class 구성 정보로 지정했다.

□ 스프링 빈 등록

스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록한다.

▷ 빈 이름 특징

빈 이름은 메서드 이름을 사용한다.
빈 이름을 직접 부여할 수 있다.

□ 스프링 빈 의존 관계 설정 - 준비

스프링 컨테이너에 설정 정보들을 등록한다.

□ 스프링 빈 의존 관계 설정 - 완료

스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다.

※ 스프링 빈을 조회할 때 조회 대상이 없는 경우

NoSuchBeanDefinitionException: No bean named 'xxxxx' available

위와 같은 에러가 발생한다.

스프링 빈 조회 - 상속 관계

부모 타입으로 조회하면, 자식 타입도 함께 조회된다.
Object타입으로 조회하면, 모든 스프링 빈을 조회한다.

BeanFactory와 ApplicationContext

BeanFactory

스프링 컨테이너의 최상위 인터페이스
스프링 빈을 관리하고 조회하는 역할을 담당
getBean() 제공

ApplicationContext

BeanFactory 기능을 모두 상속받아서 제공

ApplicationContext 제공하는 부가기능

메시지소스를 활용한 국제화 기능
- 한국에서 들어오면 한국어로, 영어로 들어오면 영어로 출력

환경변수
- 로컬, 개발, 운영 등을 구분해서 처리
애플리케이션 이벤트
- 이벤트를 발행하고 구독하는 모델을 편리하게 지원
편리한 리소스 조회
- 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

다양한 설정 형식 지원 - 자바코드, XML

스프링 컨테이너는 다양한 형식의 설정 정보를 받아들일 수 있게 유연하게 설계되어 있다.
역할과 구현을 개념적으로 나누어서 설계되어 있다.
- XML 파일인지 자바 코드인지 상관없이 BeanDefinition만 알면 잘 작동한다.

# 참고한 자료

인프런 김영한 님 강의

객체지향원칙 5가지

HJ39 — Thu, 4 Jan 2024 00:50:30 +0900

SRP (Single Responsibility Principle) 단일 책임의 원칙

하나의 모듈이 하나의 책임을 가져야 한다.

모듈이 변경되는 이유가 한 가지여야 한다

장점

변경이 필요할 때 수정할 대상이 명확해진다.

ORP (Open-Closed Principle) 개방 폐쇄 원칙

확장에 대해 열려있고 수정에 대해서는 닫혀있어야 한다는 원칙

확장에 대해 열려있다: 요구사항이 변경될 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있다.

수정에 닫혀 있다: 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하고나 변경할 수 있다.

→ 추상화에 의존하면 문제 해결 가능

ISP (Interface Segregation Principle) 인터페이스 분리 원칙

클라이언트의 목적과 용도에 적합한 인터페이스만 제공
모든 클라이언트가 자신의 관심에 맞는 public interface만 접근하여 불필요한 간섭을 최소화할 수 있다.
클라이언트에 따라 인터페이스를 분리하면 변경에 대한 영향을 더욱 세밀하게 제어할 수 있다.

LSP (Liskov Substitution Principle) 리스코프 치환 원칙

하위 타입은 상위 타입을 대체할 수 있어야 한다는 원칙
자식 클래스가 부모 클래스를 대체하기 위해 부모 클래스에 대한 클라이언트의 가정을 준수해야 한다.
클라이언트의 입장에서 생각해야 함!!

□ LSP를 위반할 수 있는 상황

DIP (Dependency Inversion Principle) 의존 역전 원칙

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되며, 저수준 모듈이 고수준 모듈이 의존해야 한다
- 고수준 모듈: 입력과 출력으로부터 먼(비즈니스 관련) 추상화된 모듈
- 저수준 모듈: 입력과 출력으로부터 가까운(HTTP, DB, 캐시등) 구현 모듈
비즈니스와 관련된 부분이 세부 사항에는 의존하지 않는 설계 원칙을 의미

의존 역전 원칙이 위배되는 경우 개방 폐쇄 원칙 역시 위배될 가능성이 높다.

의존 역전 원칙에서 의존성이 역전되는 시점은 컴파일 시점이다.

# 참고한 사이트

[OOP] 객체지향 프로그래밍의 5가지 설계 원칙, 실무 코드로 살펴보는 SOLID

이번에는 객체 지향 프로그래밍의 5가지 핵심 원칙인 SOLID에 대해 알아보고자 합니다. 실제로 애플리케이션을 개발할 때 어떻게 적용할 수 있을지 구체적인 예시를 들어 살펴보고자 합니다. 아

mangkyu.tistory.com

스프링 핵심 원리 이해 1, 2

HJ39 — Thu, 4 Jan 2024 00:32:50 +0900

요구사항에 따른 코드 구현 및 설계도는 생략하였다.

□ 문제점 코드

public class OrderServiceImpl implements OrderService {
 //    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
     private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
 }

이런 코드의 경우 OrderServiceImpl 는 Interface인 OrderService 에 의존하고 있다. (설계된 의도)

FixDiscountPolicy(), RateDiscountPolicy()를 직접적으로 객체를 생성하므로 두 클래스에도 의존을 하게된다. → DIP를 지키지 못했다.

□ 원래 목적

□ 잘못된 의도

□ 요구사항이 변경된 경우 클라이언트 코드를 직접 수정해야함

클라이언트 코드를 수정하여 OCP를 위반한다.

해결방법

Interface에 의존하게끔 변경한다.

public class OrderServiceImpl implements OrderService {
     //private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
     private DiscountPolicy discountPolicy;
}

외부 클래스를(AppConfig) 생성하여 객체를 주입시켜 준다.

public class AppConfig {
     public MemberService memberService() {
         return new MemberServiceImpl(new MemoryMemberRepository());
     }

     public OrderService orderService() {
         return new OrderServiceImpl(
                        new MemoryMemberRepository(),
                        new FixDiscountPolicy());
     }
}

OrderServiceImpl에 생성자 생성

public class OrderServiceImpl implements OrderService {
     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;
     public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
     }
}

위와 같은 방식으로 수정하면

□ 변경된 후 클래스 다이어그램

조금 더 코드를 깔끔하게 수정하면!!

□ 리팩토링한 AppConfig

public class AppConfig {

     public MemberService memberService() {
         return new MemberServiceImpl(memberRepository());
	 }
        
     public OrderService orderService() {
         return new OrderServiceImpl(memberRepository(), discountPolicy());
	 }
        
     public MemberRepository memberRepository() {
         return new MemoryMemberRepository();
	 }
     
     public DiscountPolicy discountPolicy() {
         return new FixDiscountPolicy();
     }
}

메소드를 각자의 역할에 맞게 분리하였다.

결론

이렇듯 interface로 역할을 나눈 뒤 class가 역할을 수행하도록만 구현하면 요구사항이 변해도 손쉽게 갈아끼울 수 있다.

요구사항이 변해도 사용 영역의 코드는 변하면 안된다!! (중요!)

→ 사용 영역 코드가 변한다면 잘못 설계한 것!

JOIN

HJ39 — Tue, 2 Jan 2024 18:19:53 +0900

중복 데이터를 피하기 위해서 데이터를 쪼개 여러 테이블로 나눠서 저장된 관계형 데이터베이스에서 분리된 데이터를 원하는 결과로 도출하기 위해 여러 테이블을 조합하기 위해 컬럼 기준으로 행을 합쳐주는 연산

□ JOIN 예시

SELECT ...
FROM R, S
WHERE R.A <비교연산자> S.B;

다음과 같은 SELECT문은 릴레이션 R의 Attribute A와 릴레이션 S의 Attribute B를 비교연산자를 통해 조건을 만족하는 튜플들의 집합을 구한다.

R.A <비교연산자> S.B; 인 경우 R.A와 S.B는 주로 기본 키와 외래 키의 관계를 갖는다.

특징

- N개의 릴레이션을 연관시키기 위해서는 N-1개의 JOIN 조건이 필요하다.
- JOIN 조건을 생략하거나 틀리게 표현한 경우 카티션 곱이 생성된다.

SELECT * FROM Company.EMPLOYEE;

SELECT * FROM Company.DEPARTMENT;

셀프 조인

자기 자신의 테이블을 조인하는 방법

질의: 모든 사원에 대해서 사원의 이름과 직속 상사의 이름을 검색하고 월급이 많은 순서로 정렬하여 출력하시오.

SELECT E.EMPNAME as MENTEE, E.SALARY, M.EMPNAME as MENTO
from Company.EMPLOYEE E, Company.EMPLOYEE M
where E.MANAGER = M.EMPNO
order by E.SALARY DESC;

중첩 질의

외부 질의 안에 중첩된 쿼리문들을 중첩 질의라고 한다.

한 개의 스칼라 값이 반환되는 경우

select EMPNAME, TITLE
from Company.EMPLOYEE
where TITLE = (select TITLE from Company.EMPLOYEE where EMPNAME = "박영권");
-- EMPLOYEE 릴레이션에서 EMPNAME이 "박영권"인 사람의 직급과 같은 사람들을 EMPLOYEE 릴레이션에서 조회한다.

한 개의 Attribute로 이루어진 릴레이션이 반환된 경우

외부 질의의 WHERE절에서 IN, ANY(SOME), ALL, EXISTS 같은 연산자를 사용한다.

연산자	설명
IN	한 Attribute가 값들의 집합에 속하는지 테스트할 때 사용
ANY	하나 이상의 값들과 어떤 관계를 갖는지 테스트할 때 사용
EXISTS	여러 Attribute로 이루어진 릴레이션이 반환되는 경우에 사용
ALL	한 Attribute가 값들의 집합에 속하는 모든 값들과 어떤 관계를 갖는지 테스트할 때 사용
=, <>, <=, <>, >=, >의 비교연산자도 같이 사용

select EMPNAME, TITLE, DNO
from Company.EMPLOYEE
where DNO in (select DEPTNO from Company.DEPARTMENT where DEPTNAME = "영업" OR DEPTNAME = "개발");
-- 영업부나 개발부에 근무하는 사람들의 이름과 직급을 조회한다.

여러 Attribute들로 이루어진 릴레이션이 반환되는 경우

select EMPNAME
from Company.EMPLOYEE E
where EXISTS
        (select * 
         from Company.DEPARTMENT D 
         where E.DNO = D.DEPTNO 
         	AND (DEPTNAME = "영업" OR DEPTNAME = "개발"));
-- 영업부나 개발부에서 근무하는 사원들의 이름을 조회

상관 중첩 질의

위 EXISTS를 사용한 예시에서 외부 질의 from에서 명시된 EMPLOYEE릴레이션을 중첩 질의 WHERE에서 사용되므로 상관 중첩 질의가 적용된다.

내부 조인(INNER JOIN)

기본 테이블과 조인 테이블 모두 데이터가 존재해야 조회된다.

(교집합으로 생각하면 편하다)

-- 중첩 질의
select EMPNAME, TITLE, DNO
from Company.EMPLOYEE
where DNO in (select DEPTNO from Company.DEPARTMENT where DEPTNAME = "영업" OR DEPTNAME = "개발");

-- INNER JOIN
select EMPNAME, TITLE, DNO
from Company.EMPLOYEE as E
inner join Company.DEPARTMENT as D
	on (E.DNO = D.DEPTNO) AND (D.DEPTNAME = "영업" OR D.DEPTNAME = "개발");

두 쿼리문의 결과 값은 같다.

외부 조인(OUTER JOIN)

내부 조인은 두 테이블에 모두 데이터가 있어야만 결과가 나오지만, 외부 조인은 한쪽에만 데이터가 있어도 결과가 조회된다.

SELECT <열 목록>
FROM <첫 번째 테이블(LEFT 테이블)>
    <LEFT | RIGHT | FULL> OUTER JOIN <두 번째 테이블(RIGHT 테이블)>
     ON <조인 조건>
[WHERE 검색 조건]

LEFT OUTER JOIN

□ 교집합을 포함하는 경우

select EMPNAME, TITLE, DNO, DEPTNAME
from Company.EMPLOYEE as E
	left outer join Company.DEPARTMENT as D
		on (E.DNO = D.DEPTNO) AND (D.DEPTNAME = "영업" OR D.DEPTNAME = "개발");

□ 교집합을 포함하지 않는 경우 (DEPTNAME이 NULL인 경우를 제외)

select EMPNAME, TITLE, DNO, DEPTNAME
from Company.EMPLOYEE as E
	left outer join Company.DEPARTMENT as D
		on (E.DNO = D.DEPTNO) AND (D.DEPTNAME = "영업" OR D.DEPTNAME = "개발")
where D.DEPTNAME is NOT NULL

RIGHT OUTER JOIN

select EMPNAME, TITLE, DNO, DEPTNAME
from Company.EMPLOYEE as E
	right outer join Company.DEPARTMENT as D
		on (E.DNO = D.DEPTNO) AND (D.DEPTNAME = "영업" OR D.DEPTNAME = "개발")

select EMPNAME, TITLE, DNO, DEPTNAME
from Company.EMPLOYEE as E
	right outer join Company.DEPARTMENT as D
		on (E.DNO = D.DEPTNO) AND (D.DEPTNAME = "영업" OR D.DEPTNAME = "개발")
where E.DNO is NULL

FULL OUTER JOIN

MySQL에서는 FULL OUTER JOIN을 지원하지 않는다고 한다.. 머쓱..

LEFT, RIGHT OUTER JOIN의 결과값 모두 출력된다고 생각하면 된다.

상호 조인 (CROSS JOIN)

한쪽 테이블의 모든 행과 다른 쪽 테이블의 모든 행을 조인시키는 기능

상호 조인 결과의 전체 행 개수는 두 테이블의 각 행의 개수를 곱한 수만큼 생성된다.

카티션 곱이라고 부른다.

□ 양식

SELECT *
FROM <첫 번째 테이블>
    CROSS JOIN <두 번째 테이블>

select EMPNAME, TITLE, DNO, DEPTNAME
from Company.EMPLOYEE as E
	cross join Company.DEPARTMENT D

끝!

# 참고한 자료

https://github.com/Songwonseok/CS-Study/blob/main/Database/JOIN.md
MS SQL 서버 기반 데이터베이스 배움터 책
https://hongong.hanbit.co.kr/sql-%EA%B8%B0%EB%B3%B8-%EB%AC%B8%EB%B2%95-joininner-outer-cross-self-join/
https://gent.tistory.com/376

Key

HJ39 — Mon, 1 Jan 2024 00:46:56 +0900

데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 다른 튜플들과 구별할 수 있는 유일한 기준이 되는 Attribute(속성)

최악의 경우 모든 Attribute들을 사용하면 튜플을 고유하게 식별할 수 있는데 다음과 같은 이유로 최소한의 Attribute로 이루어진 키에 관심을 갖게 된다.

1. 불필요하게 중복되는 Attribute가 많아지면 데이터 저장 공간이 낭비되고, 쿼리 성능이 저하될 수 있다.

릴레이션 A

신용카드번호	이름	주민등록번호	주소
1	A	XXXX-XXXX	서울특별시...
2	B	YYYY-YYYY	인천광역시...

릴레이션 B

신용카드번호	이름	주민등록번호	주소	사용금액
1	A	XXXX-XXXX	서울특별시...	1,000,000
2	B	YYYY-YYYY	인천광역시...	600,000

릴레이션 A, B에 키를 (신용카드번호, 이름, 주민등록번호, 주소)라고 했을 때, 연관된 릴레이션마다 (신용카드번호, 이름, 주민등록번호, 주소)이 키값들이 릴레이션에 중복되서 들어가게 된다.

불필요하게 중복되므로 데이터베이스 저장공간이 낭비되고, 많은 양의 키 값을 처리해야 하므로 쿼리 성능이 저하될 수 있다.

2. 키가 작을수록 인덱스의 크기가 줄어들고 인덱스 검색하는 시간이 단축된다.

릴레이션의 튜플들에 접근하기 위해 키에 인덱스들을 만드는데, 키가 작을 수록 인덱스의 크기가 줄어들어 시간이 단축된다.

인덱스에 대한 설명은 다음에..

수퍼키(SuperKey)

한 릴레이션 내의 특정 튜플을 고유하게 식별하는 하나의 Attribute 또는 Attribute들의 집합이다.

릴레이션 A

신용카드번호	이름	주민등록번호	주소
1	A	XXXX-XXXX	서울특별시...
2	B	YYYY-YYYY	인천광역시...

릴레이션 A에서 수퍼키는 (신용카드번호, 주소), (주민등록번호, 이름), (주민등록번호)등이 수퍼키가 될 수 있다.

수퍼키의 단점
튜플들을 고유하게 식별하는데 필요하지 않은 Attribute들을 포함할 수 있다. (주의)

후보키 (Candidate Key)

각 튜플을 고유하게 식별하는 최소한의 Attribute들의 모임

후보키의 Attribute들 중 한 개의 Attribute를 빼면 고유하게 식별하는 능력을 잃어버린다.

수퍼키 중 하나인 (신용카드번호, 주소)에서 신용카드번호는 후보키이다.

모든 릴레이션에는 한 개 이상의 후보키가 존재한다. (최악의 경우 모든 Attribute를 사용해야 한다)

후보키가 두 개 이상의 Attribute로 구성되어 있는 것을 복합 키(Composite Key)라고 한다.

기본키 (Primary Key)

한 개의 릴레이션에서 두 개 이상의 후보키가 있으면 DB설계자가 이들 중 한 개를 기본 키로 설정한다.

(후보키가 한 개인 경우 후보키가 기본키가 된다.)

자연스러운 기본 키를 선택하는 것이 좋다.

자연스러운 기본 키가 없는 경우 인위적인 키를 Attribute를 릴레이션에 추가할 수 있다.

추가된 키를 대리키(Surrogate Key)라고 한다.

ex) 신용카드 회사의 고객 릴레이션에서 신용카드번호와 주민등록번호가 후보키가 된다.

실질적으로 신용카드 회사에서는 분실 신고 빈도보다 정상적인 카드 결제 빈도가 훨씬 높으므로 신용카드 회사의 고객 릴레이션에서 신용카드번호를 기본 키로 설정하는 것이 좋다.

기본키 설정시 고려사항

- 모든 튜플을 고유하게 식별해야하므로 null값이나 중복된 값을 가질 수 없다.
- Attribute값이 변경될 가능성이 높은 Attribute는 기본키로 설정하지 않는다.
- 가능하면 작은 정수 값이나 짧은 문자열을 갖는 Attribute
- 복합 기본키를 가능하면 피하는 것이 좋다.

대체 키(Alternate Key)

기본 키로 선정되지 않는 후보키를 의미

릴레이션 A

신용카드번호	이름	주민등록번호	주소
1	A	XXXX-XXXX	서울특별시...
2	B	YYYY-YYYY	인천광역시...

해당 릴레이션에서 신용카드번호가 기본 키로 설정한 경우 주민등록번호는 대체 키가 된다.

그림을 보면 한 번에 이해할 수 있다.

외래키 (Foreign Key)

다른 릴레이션의 기본키를 참조하는 Attribute

R-DBMS에서 릴레이션들 간의 관계를 나타내기 위해 사용

외래키의 여러 유형

□ 다른 릴레이션의 기본 키를 참조하는 외래키

□ 자체 릴레이션의 기본 키를 참조하는 외래 키

외래 키인 직속상관은 기본 키인 직원 번호를 참조하고 있다.

직속상관이 없는 경우 NULL로 표현이 가능하다.

□ 기본 키의 구성요소가 되는 외래 키

수강 릴레이션은 과목 릴레이션의 기본 키와 학생 릴레이션의 기본 키를 참조하여 구성된다.

수강 릴레이션에 최소한의 Attribute로 구성된 기본키가 없으므로 (학번, 과목번호)가 기본 키가 된다.

자연키

기본키만을 위한 데이터가 아니라 비즈니스 모델에서 자연스레 나오는 속성으로 기본 키를 결정

인조키

비즈니스 모델과 달리 키를 위한 데이터이다.

대리키와 같은 의미

# 참고한 사이트

App thinning

HJ39 — Sun, 23 Jul 2023 23:58:47 +0900

애플리케이션을 설치할 때, 앱스토어와 운영체제가 디바이스의 환경에 맞게 설치하는 설치 최적화 기술

필요한 만큼의 리소스만 다운로드하기에 적은 디스크 사용량, 빠른 다운로드를 제공

Slicing

여러 가지 디바이스와 운영체제를 위한 앱 번들의 variants(변형)을 생성 및 제공하는 과정

variants(변형)에는 각 디바이스와 운영체제가 필요로 하는 실행 가능한 아키텍처와 리소스가 담겨있다.

개발자가 앱스토어 커넥트에 풀버전의 앱 빌드를 업로드하게 되면 앱스토어는 자동적으로 variants를 생성하고 전달한다.

유저가 앱스토어에서 앱을 다운로드하게 되면, 유저의 디바이스와 운영체제 버전에 맞는 variants를 다운로드하게 된다.

on-demand resource(ODR)

주문형 리소스는 이미지, 음원과 같은 앱의 리소스를 키워드로 태그 해놓고, 태그를 통해 그룹으로 요청이 가능한 리소스

앱스토어는 사용자에게 현재 필요한 리소스를 관리하고 다운로드하게 한다.

또한 주문형 리소스의 슬라이싱 작업을 통해 variants의 최적화 작업을 진행한다.

앱의 사이즈가 작아지게 되고, 이를 통해 더 빠른 다운로드를 제공, 사용자가 앱의 최초 실행 경험을 개선하게 된다.
사용자가 앱을 체험하면서 필요하게 되는 주문형 리소스들을 백그라운드에서 다운로드하게 된다.
운영체제가 더 이상 필요로 하지 않는 주문형 리소스들은 제거하게 되고, 이로 인해 저장공간을 절약한다.

대표적인 예시를 들 수 있는 경우가 게임의 추가 리소스 다운이다. 일반적으로 이미지와 음원이 많은 게임 앱의 경우, 최초 실행을 위한 최소한의 리소스를 우선적으로 받고, 게임 실행 후 필요한 부분만 리소스를 추가적으로 다운로드하여 저장공간 절약, 실행을 위한 다운로드 시간 감소 등 대용량 앱 사용에 더욱 쾌적한 환경을 제공할 수 있다.

위 그림으로 살펴보자면 현재 필요한 리소스는 Level 1만 필요한데 처음 다운로드를 할 때 Level 2를 다운로드하여 휴대폰의 리소스를 낭비하지 않게 하는 방법이다.

Level 1을 사용하던 중 Level 2 ODR을 사용하기 위해 Level 2를 다운로드하면 자동적으로 이제는 필요 없는 Level 1 ODR을 삭제하여 공간을 확보하는 방법이다.

bitcode

개발자는 앱스토어 커넥트에 자신의 앱에 비트 코드를 포함시켜 올릴 수 있으며 그러한 비트 코드는 컴파일되어 앱스토어에 연결된다.

애플은 업로드된 비트 코드를 통해서 개발자의 새로운 버전의 앱 업로드 없이도 앱 바이너리를 최적화할 수 있다고 한다.

따라서 최신 컴파일러용으로 자동으로 앱을 컴파일하고, 특정 아키텍처(예 : iPhone 6 및 iPad Air 2와 같은 64 비트 프로세서의 경우 arm64)에 맞게 최적화한다고 한다.

Bitcode는 다른 아키텍처에 대한 최적화를 제거하여 다운로드는 더 작게 만듦 / 관련 최적화만 다운로드하여 위에 언급한 App Thining 기술과 함께 사용됩니다. (App Slicing 방법을 사용한다고 한다)

Bitcode는 기계어와 인간이 읽을 수 있는 언어 중간 단계의 언어로 일련의 지침이 주어지면 다양한 방식으로 다시 컴파일하는 데 사용할 수 있는 앱의 추상 인코딩이다.

→ 예전

이런 사건도 있었다고 한다. ㅎ

지금은 bitcode가 적용되어 새로운 아키텍처가 나와도 개발자가 다시 코드를 수정할 필요가 없다고 한다. ㅎㅎ

※ 참고

Async/Await

HJ39 — Sun, 23 Jul 2023 01:59:43 +0900

async는 함수가 비동기로 처리된다는 것을 의미한다.

await은 마킹된 곳은 potential suspension point(잠재적 일시 중단 지점)로 지정된다.

async로 선언한 함수가 완료될 때까지 일시 중지 되는 지점이다.

□ 예시

func asyncTest() async throws -> String {
    try await Task.sleep(nanoseconds: 3_000_000_000) //3초
    return "sleep 끝"
}

print("before task")
Task{
    let string: String = try await asyncTest()
    print(string)
}
print("after task")

// 출력
// before task
// after task
// sleep 끝

asyncTest() 함수는 3초 뒤에 "sleep 끝"을 출력한다.

※ 참고

https://jeong9216.tistory.com/498