[생활코딩] 관계형 데이터 모델링 (8-14강의 : 개념적 모델링)

8. 엔티티 정의

• 앱을 하나의 건물이라고 하면 ui는 옥상,db는 지하 .
ui와 db사이를 원인과 결과의 관점에서 한번 생각해보자 ui가 원인이 되어서 db의 데이터를 변경하는 결과를 낳고 데이터라는 원인에 의해서 ui에 내용이 표시되는 결과를 낫는다. 즉 사용자가 마주하는 ui와 컴퓨터에 저장되는 데이터는 서로 원인과 결과의 관계에있다고 할수있다. 원인과 결과를 번갈아가면서 순차적으로 점검하지 않는다면 좋은 모델링이 나오기 어렵다. 그런점에서 기획자와 구현자가 다르다면 데이터 모델링까지는 최소한 함께 동행하는 것이 이!상!적!

• 데이터 모델링은 기획에게 또 기획은 데이터 모델링에게 놓치면 안되는 중요한 틈을 보여주는것과 같다.

• ✓제일 먼저할 일은 기획서에서 엔티티를 찾아내는 것이다. 
본능적으로 연관된 데이터를 그룹핑한 능력이있닼ㅋㅋㅋ 무의식적으로 하고 있다!!
읽기에서는 그것을 찾아내기가 어렵고 쓰기 화면에서는 괜찮다.

• Draw.io라는 프로그램을 이용하실것임.. —> 글.저자,대글 쓴게 엔티티 만든거

• 엔티티를 추출하는 것까지 했으니 엔티티에다가 필요한 속성들을 정리해볼것임 (담시간)

  9.속성 정의

  

• 속성은 각가의 엔티티의 소속이된다.

• 소속관계는 작성을 통해 쉽게 파악할수있다. 제목/본문이 속성이다. 저자목록같은 경우에는 select box인것은 저자목록이 복합적인 속성이라서 별도의 엔티티로 독립해 나가야됨

• 쓰기만으로 부족한것은 읽기(언제 작성됐는지에 대한 작성정보) 즉 엔티티의 속성으로 날짜 정보까지 있어야함. 저자, 제목,본문,날짜 까지

• erd에서 속성은 원을 사용한다.

• 댓글은 내용과 작성자명이 있다. 이때 작성자명은 로그인을 했다면 (가입된 저자만이 쓸수있다면) 우리 이전에 글작성할때 썼던 셀렉트 박스로 바꿔라.

• 우리가 모델링을하게 되면 모델링이 ui를 검증하고 ui가 모델링을 검증하는 교차검증이 가능하기 때문에 두가지를 번갈아 가면서 살펴보는것이 유익하다.

• 엔티티와 엔티티의 속성들을 정의함.
  

10.식별자 지정

• 국가는 국민의 주민번호로 식별, 웹사이트는 도메인 이름 으로 식별함 이런것들을 식별자라고 하고 식별자가 하는일은 원하는 대상을 정확하게 타겟팅하는 것. 그래야 그 대상에 대해 정확한 것을 할 수 있으니!

• 식별자가 되기 위해서 가장 중요한 것은 그 대상을 제외한 그 누구도 같은 값을 가지고 있으면 안된다. (주민등록번호가 1이라면 국민 중 누구도 1이라는 주민번호를 가지고 있으면 안됨)

• erd에서도 우리가 아이덴티파이어(식별자)를 어떤 속성을 할것인가 지정해야됨.
이렇게 지정한 식별자는 훗날 PK(프라이머리 키)가 될것임
  

• 식별자로 사용될 수 없는거 : 이름, 도시
식별자로 사용될 수 있는거: 이메일(이메일이 각각 다르면 식별자 가능/정부에서 운영하는 시스템이라면 한사람이 여러개의 이메일을 가질 수 있기때문에 사용할 수 없을수도 있다.) , 주민번호, ID(행이 추가될때마다 자동으로 1씩 증가시켜서 중복되지 않는 값을 부여하는 것을 통해서 식별자를 제공해 줄수도 있다.이러한 식별자를 인조키라고 부른다.(자연스럽게 만들어진 식별자가 아니라고 생각해서)

• 후보키 중에서 우리가 선별한 식별자가 id라고 하면 기본키(PK)라고 한다. 기본키가 아닌 다른 친구들은 대체키(alternate 키라고한다.)
  

• 중복키(composite key)

• 어떠한 부서가 있는데 1번이라는 부서가 있다면 그 부서에는 1번 4번을 갖고 있는 2명의 직원이 포함되어있고 한명의 직원은 여러개의 부서에 포함될수도 있다. 다른 부서에 1번이 속해있는거. 여기 있는 표에는 직원번호, 부서번호만으로 직원을 식별할수없다. 이런경우 직원과 부서번호 두가지를 합쳐서 식별할수있는데 이런걸 중복키라고 한다.

• 글이라는 엔티티에서는 식별자가 될수있는게 없기 때문에 인조(대리키)를 만들어서 글 id 이렇게하고 나중에 db에서는 auto increment, sequence이런것들을 이용해서 다른 것과 중복되지 않는일련번호를 만드는 방법을 사용하면 된다.

• 관계형 데이터 모델링에서 밑줄을 주면 식별자 표시이다.
  

• 각각의 엔티티가 자신을 식별할수있는 자신의 튜플 즉 행을 식별할수있는 컬럼인 식별자 컬럼을 가지게 되었다.

  11.엔티티간의 연결

• relationship은 무엇이 되는가. 각각의 표들은 데이터로써 연결되어있고 각가의 표에 행을 식별하는 유일무이한 식별자를 우리는 PK라고 한다.

• 저자 테이블의 id값을 가리키는 글 테이블의 저자 아이디의 값을 외래에 있는 테이블과 연결할때 사용하는 열쇠라는 뜻에서 외래키라고 한다. 즉 이 관계형 데이터베이스의 relationship은 primary key와 foreign key가 연결되는 것 으로 구현된다.

• 이런 관계를 어떻게 그림으로 표현하는가?
erd에서 우리가 relationship을 표현할때는 마름모꼴로 생긴 도형을 통해 표현

• 저자는 글을 쓰고 글은 저자로부터 글을 쓰여짐 당함. 그래서 <작성>이라는 관계가 있다고 할 것임. 저자와 댓글도 작성이라는 관계가 있고, 글은 댓글을 포함하고 소속하고 댓글은 글에 소속됨 이건 <소속>이라는 관게로 맺어져있음.

• 관계형 데이터 베이스를 우리가 만들때 여러사람들과 협업할때 이런 정보에서 궁금해할만한 핵심적인건 다했는데, 거기서 이제 관계라는 측면에서 얘들보다 덜 중요하지만 나머지

• 애들보다 훨씬 중요한게 있다. 그건 바로 ….다음시간에 알려줄게용….
  

12.cardinality/optionality —> 지인짜 까다롭다 일주일뒤면 까먹는다. 마음을 넉넉히가져라..

• Cardinality(기수..1.2.3.4 - - 이런거)

• 두개의 표는 조인같은 걸로 연결될것임 왼쪽 오른쪽 다 행이 3개가 있다. 이때 우리가 카디널리티를 따져볼려면 담임에게 반은 몇개일까 반에게 담임은 몇개일까를 양쪽다 따져봐야된다. 무슨말인지는 이제 보면된다. 담임은 반을 몇개가질수있을까요? —>각선생님은 1반만 담임한다. Ex)김이라는 선생님은 1반을 맡으면 다른 반을 맡을수없다./각반의 담임은 한명이다. Ex)1반이 선생님이 김이면 다른 선생님은 담임이 될수없다 ->반에게 담임은 하나다. —-> 요것을 1:1 관계라고 한다. ◼︎⎻◼︎ (erd 1:1 표현)

• 저자에게 댓글은 몇개인가를 따져보자
저자는 여러개의 글을 작성할수있다. Ex) 김이라는사람은 3개의 댓글을 작성할수있으므로 댓글은 N이된다. 댓글에게 저자는 몇개인가를 보면 각 댓글은 하나의 저자만 존재한다가 됨. Ex) 댓글1이 김이라는 저자를 가지고 있으면 다른 누구도 그 댓글의 저자가 되면 안된다. 즉 댓글에게 저자는 1개다 ——> 일대다 , 1:N 관계라고 한다. 그래서 n에 해당되는 부분에 까마귀발처럼 생긴 삼발이를 놓는다. ◼︎⎻←◼︎ (이건 표기법이 다양함)

• 저자와 글의 관계
우리가 만들려고 시스템은 하나의 글을 여러명이 편집할 수 있다라고 하면 각 저자는 여러개의 글을 작성할 수 있다.라고 하자. Ex)김이라는 사람은 3개의 글을 작성할수있다고하면 저자에게 글은 여러개다해서 글은 M이라고 표현. 글에게 저자는 몇개냐? 각글은 여러 저자가 존재한다. Ex)글에게 1이 생겼다면 이 글은 여러개의 저자가 참여할수있게 되는거 그럼 글에게 저자는 여러개다 그래서 N이라고 표현—> N:M 혹은 다대다라고 표현◼︎→⎻←◼︎

• 관계성 3가지로 1:1, 1:다, 다:다 라는 게 있음 이중에서 끝에있는 다대다 관계는 실제로 우리가 현실에 데이터베이스 테이블의 세계에서는 표현을 할 수없기 때문에 요상태 그대로 두지않고 중간에 연결 테이블이라고 하는 특별한 테이블을 만들어서 최종적으로는 1:다 관계로 컨버팅을 시킴 (지금은 이해가 안된다… 나중에 이해할것임 원래 헷갈린다고 생각하면 자괴감을 가지지마라라라라라라라ㅏ)

  13.OPTIONALITY에 대해 살펴보자아

• 저자와 댓글 사이에 어떤 관계를 가지고 있는가?
어떤 시스템에 저자가 등록을 했다면 그 사람이 반드시 댓글을 가지고 있어야돼? 아님
등록하고 댓글 안써두 되잖아!
즉, 저자에게 댓글은 옵션이다. 그리고 이것을 다이어그램에서는 ◼︎⎻○◼︎
(옵션의 O라고 생각해라) 방향은 오른쪽에 있음 (이쪽인지 저쪽인지 헷갈린다…)

• 댓글이 일단 존재하면 반드시 저자가 있으므로 댓글에게 저자는 필수이다. Mandatory 는 다이어그램에서 ◼︎ㅣ⎻○◼︎
  

• 저자와 댓글은 필수냐 선택이냐라고 하는 측면도 있지만 동시에 1:1이냐 1:N이냐 M:N이냐 라는 cardinality도 있다. 그러면 이두가지 특성을 모두 반영한다면!

• 저자와 댓글은 1:N의 관계이기도 한다. Erd 관계에서는 오버랩을 시키면 된다. 아 여기 저자는 댓글에 대해서 여러개를 가질수도 있고 댓글을 달지 않을수도 있고 댓글은 반드시 저자가 필요하고 저자가 한명이구나라는 것을 인식할수있어야한다.

14. ERD 완성

• 우리 개념적 모델링에 대한 얘기는 모두 끝남
• 개념적.논리,물리적 모델링에서 어떤일을 해야된다. 어떤 기호를 써야된다는 의견이 분분함
어떤 정해진 엄격한 룰이 있는건 아님. 그래서 우리가 하는 일의 성격에 따라 합의를 통해 진행해나가면됨.