관계형 데이터 모델링 (1)

 

https://opentutorials.org/course/3883

관계형 데이터 모델링 - 생활코딩

https://youtube.com/playlist?list=PLuHgQVnccGMDF6rHsY9qMuJMd295Yk4sa

관계형 데이터 모델링

관계형 DB를 위한 데이터 모델링입니다!

--------------------------------------------------------------------------------------------------------------------

@1.수업소개

 

MODEL이란, 목적을 갖고 진짜를 모방한 것.

'좋은' MODEL이란, 목적에 부합하는 모방

 

우리의 목표는 (컴퓨터에? -> DB? -> RDBS? -> 더 구체적으로는 표에) 표에 정보를 담는 것.

 

정보를 DB의 표에 담는것에 성공만 하면 인간의 기본적인 능력으로는 상상도 못하는 거대한 양의 데이터를 다룰 수 있게됨.

 

문제는 무한히 거대하고 복잡한 현실을 정보로 만들어서, 표에 담는 것이 매우매우 어려운 일

 

천재라도 어렵고, 인생을 갈아넣은 사람에게도 어렵다. 과거엔 아무나 할 수 있는 일이 아니었음.

이를 안타깝게 여긴 전문가들이 천재가 아닌 사람들도 현실의 복잡성을 컴퓨터에 담을 수 있는 기가막힌 방법론을 만듦.

 

그게 바로 DATA MODELING

 

우리는 복잡한 현실을 컴퓨터로 이사시키는 이삿짐센터가 될 것. 또, 아무리 복잡한 정보도 위대한 표에 담을 수 있다는 자신감을 갖게될 것.

--------------------------------------------------------------------------------------------------------------------

@2.전체 흐름

데이터 모델링이 일반적으로 어떤 순서로 진행되는지를 좀 소개해드리고

 

결론은 정보를 DB로 옮기는 작업을 할것임.

 

1.업무파악 : 의뢰한 사람이 어떤 것을 꿈꾸고 있는가, 기획서 같은 것을 받을 수 있음.

 

2.개념적 데이터 모델링

현실의 업무를 뜯어내서 공중부양 시켜서 거기에서 이제 개념을 찾아내는

내가 하고자 하는 일에는 어떤 개념들이 있고, 각각의 개념들은 서로 어떻게 상호작용하고 있는가. 라는 것을 심사숙고 해보는시간. 그리고 이 과정에서 er다이어그램이라고 하는 요렇게 생긴 그림을 얻게 되는 것이고 그 다음과정으로 가기 위한 초석이 됨.

 

3.논리적 데이터 모델링

2에서 개념을 충분히 숙고했다면 그 다음엔 이 개념을 관계형 DB에 맞게 잘 구성을 해야겠죠

관계형 DB의 패러다임에 맞게 표로서 우리가 생각했던 개념을 전환하는 작업하는 것.

그것이 이제 논리적 데이터 모델링이라고 하는 단계.

 

4.물리적 데이터 모델링

표를 이상적으로 잘 그린다고 해서 그게 실제로 DB상에서 표가되는건 아님.

그 다음 단계에서는 내가 어떤 DB제품을 사용할 것인가.

그 DB제품에 최적화된 코드를 작성해서 실제 표를 만드는 것이 물리적 데이터 모델링 단계가 하는일이고

그때의 산출물은 표를 생성할 수 있는 sql코드를 갖게되는 것.

 

 

제가 데이터 모델링 수업을 준비하면서 든 생각

데이터 모델링이란,

1. 문제를 현실로부터 뜯어내서

2. 고도의 추상화 과정을 거쳐서 그것을

3. 컴퓨터라는 새로운 현실로 옮겨담는 작업이구나.

 

이 두 개의 세계는 서로 다르기 때문에 처음에 해결하려고 했던 문제가 DB의 표에 잘 담겼는지를 확인하는 작업을 끊임없이 계속해서 해나가야 되겠구나 이런생각이 들었습니다.

 

수업이 끝나면 나의 현실에 어울리는 모델링 기법을 각자 발전시켜 나가게 될것입니다.

 

--------------------------------------------------------------------------------------------------------------------

@3.1 업무파악 : 인트로

업무파악을 못했는데 제대로된 테이블을 만들 수 없겠죠

이 순서로 갈 것

 

컴퓨터 공학이 해결하는 문제 크게 두가지

1.컴퓨터 자체의 문제를 해결 : DB를 만든다 --이런 직업

2.현실의 문제를 해결 : DB를 통해 현실의 문제 해결, 인터넷 뱅킹시스템을 만든다든지, 생각하고 있는 아이디어를 구현한다든지 --이 직업은 컴퓨터를 잘 이해하는 것만으로는 부족. 해결하고자 하는 문제를 컴퓨터라는 강력하고, 안똑똑한 기계에게 설명할 수 있을정도로 업무를 이해해야지만 우리는 컴퓨터 프로그램을 만들 수가 있다.

 

그러기 위해서는 그 분야의 실무자들과 정확하게 소통하는 것이 중요

문제는 실무자들도 그 분야에 대해서 정확한 이해가 있다기보다는 익숙해져서 일을 잘하는 것일수도 있거든요

 

이해를 했다면 설명도 할 수 있어야 합니다. 일은 잘하지만 설명은 못한다면 그것은 이해하기도 전에 익숙해져버리고 덮은 것. --어 이거 아는거지~하고 넘어간 것 나도 경험해봄

나쁜건 아니고 실제로 우리는 그렇게 일에 익숙해짐. 근데 문제는 익숙함만으론 컴퓨터를 다룰수가 없다.

컴퓨터는 하나하나 컴퓨터가 해야될일을 정확하게 이해해줘야 동작하는 기계니까요

익숙해진 사람으로부터 필요한 정보를 끌어내기 위해서는 정말 많은 노하우와 노력이 필요함. 소프트웨어엔지니어가 공부를 멀리할 수 없으면서 + 또 인간관계를 등한시 할 수 없는 이유기도 한거죠

 

업무파악할 때 많이 사용하는 방법은 UI를 '같이' 그려보는 것

UI는 사용자가 기계를 작동할 때 사용하는 여러 조작장치들

우리가 꿈꾸는 앱에서 어떤 UI를 갖게될것인가를 일을 의뢰한 사람과 함께 그려보는 과정에서 원하는 것을 분명히 할 수 있다. 서로 생각하는 것을 일치시키는데 이것만큼 좋은 것이 없다.

말의 힘을 불신하는 아주 좋은 사례

 

말의 힘을 불신하십쇼. 말의 진의를 불신하라는게 아니고 말의 기능을 불신하라는 말.

말을 불신할수록 말의 신뢰성은 높아짐.

 

군대에 있을 때 상급자들이 복명복창을 엄청 강조

누구도 저한테 왜 복명복창을 해야하는지 설명해주지 않음.

단지 군기를 증명하는 역할밖엔 없어보였음.

제대하고 사회생활 하다가 생각해보니까 복명복창이 대표적인 불신의 기술이었던 것임.

내가 한말을 상대가 잘 이해했는지를 크로스체크 했던 것. 훨씬 정확하게 서로의 생각을 동기화하고 확인할 수 있음. 업무파악이 잘 안되면 뒤는 볼 것도 없죠.

 

말을 불신해서 말의 신뢰성을 높이는 테크닉인 기획서를 한번 만들어보면서 우리수업에서 사용할 예제를 같이 동기화 시키는 작업을 해봅시다.

 

--------------------------------------------------------------------------------------------------------------------

@3-2. 기획

기획하는 툴이 있다. ovenapp 카카오에서 만든 좋은 도구

5분 동안 사용법 등을 알려줌 https://youtu.be/rWEaUh4DjUo

이런식으로 UI를 같이 만들어보면서 이해당사자들끼리 명확하게, 동기화 시킬 수 있다.

 

--------------------------------------------------------------------------------------------------------------------

@4.1.개념적 데이터 모델링 소개

우리가 파악한 업무에서 개념을 뽑아내는 과정.

 

근데, 개념적 데이터 모델링은 관계형 데이터 모델링 전체의 프로세스의 극치임.

 

일을 하는 순서와 공부를 하는 순서는 다를 수 있다.

개념적 모델링을 잘했다면 논리적 모델링이나, 물리적 모델링은 비교적 기계적임.

 

이걸 배우면 저걸 나 혼자 할 수 있을까? 라는 생각이 들 것.

당연해 모델링은 업무라는 현실과, DB라는 또다른 현실이 있을 때 그것을 이사시키는 작업.

이 두가지에 정통하지 않은 사람이 개념을 뽑아낸다는 것은 가능한 일이 아님.

이 수업을 전체 다 듣고, 현실에서 해보면 아 이런얘기였구나 할 것이니 괜찮습니다. 

지금은 편안한 마음으로 수업에 참여하세요

 

 

개념적 데이터 모델링이 우리에게 주는 효용

ERD라는 애가 엄청난 선물 두가지를 줌

1.현실에서 개념을 추출하는 일종의 필터를 제공.

2.개념에 대해서 다른사람들과 대화하게 해주는 언어로써 작용

이런걸 가능하게 해주는 하나의 도구 ERD라고 하는 그림

Entity(독립체) Relationship Diagram

자 보세요 왼쪽 오른쪽 무슨 관계일까?

 

현실은 믿을수 없을 정도로 복잡, 작은 세포 안에서도 무한히 많은 일이 일어나고있음.

이렇게 지옥 같은 현실에서 개념을 뽑아내는 것은 무척이나 어려운일.

 

현실을 간단하게 바라볼 수 있는 파인더와 같은 것이 있다면 얼마나 도움이 될까?

ERD는 현실을 세 개의 관점으로 바라볼 수 있는 파인더를 제공함.

 

첫 번째는 정보, 발견하고 그걸 다른사람에게 표현할 수 있게 도와줌

두 번째는 정보그룹, 서로 연관된 정보를 그루핑해서 인식하고 이것을 다른사람들에게 표현할 수 있게 해줌.

세 번째는 정보그룹사이의 관계를 인식하고 그것을 다른사람에게 표현할 수 있게 해줌.

 

현실로부터 개념을 인식하는 도구이면서 그것을 다른사람도 알아볼 수 있게 표현하는 도구가 ERD

 

그리고 ERD는 매우 쉽게 표로 전환할 수 있는 환상적인 기능이 있다.

 

ERD를 어떻게 하면 표로 전환할 수 있을 것인가에 대한 정교한 규칙들이 수십년동안 정립됐기 때문에

여러분은 ERD까지만 만들면 표로 만드는 것은 서서 떡먹기와 같다.

 

개념적 모델링과 ERD에 대한 욕심을 충분히 충전하셨나요?

 

--------------------------------------------------------------------------------------------------------------------

@4.2. 관계형 DB 다운 개념의 구조

 

ERD를 만드는 방법을 하나씩 쪼개서 볼 것.

 

기획서에는 여러 가지 정보가 흩어져있음

글제목, 저자이름, 댓글의 내용 등등..

 

여기서 여러 가지 정보를 묶어주는 큰 덩어리부터 끄집어내야함.

 > 저는 글, 저자, 댓글, 저자이런게 보이네요 > 정답은 없다, 설명이 가능하고 모순이 없다면 다 타당한 것.

 

위에는 글 속에 댓글이 있고 저자가 있고, 댓글 안에 저자가 있고.. 왼쪽의 구조를 잘 표현하고 있음. 근데?

아래쪽에 있는 모델이 관계형 DB에 더 잘 어울리는 모델이다. 왜? 당장 다 설명하긴 어려워. 일단 꼼꼼하게 따지진 말고 큰틀에서 보기

 

 

1.

RDB는 내포관계허용X

 : 위의 그림은 표가 왼쪽처럼 만들어짐. 표 안에 다른 표가 내포돼있는 관계. --RDB는 이걸 허용 안함. 불가능.

 

2.

거대단일테이블 --어떻게 하나의 표에 표현을 어떻게든 한 것.

 : 두 번째처럼 내포 관계를 어떻게어떻게 한 표에다가 표현할 순 있는데 규모가 크다면 컬럼이 1000개가 될 수도 있다. 우리는 글제목 글내용만 보고싶을 때 1000개의 컬럼을 다 가져와야 하기 때문에 흥청망청 데이터를 쓰고있는 상황이 될 수 있다. 또 만약 글 저자가 중복이 되고 있다고 하고 1억개가 중복된다면 저장장치를 흥청망청 쓰는 것.

만약 저자의 이름을 바꾼다면 1억개를 바꿔야하는데 시간도 오래 걸리고 실수를 할 확률도 있다.

 

∴ 거대 단일 테이블이 아니라, 주제에 따라서 테이블을 쪼개는 방법을 사용함.

- 이러면 주제에 따라서 데이터를 그루핑할 수 있고 --가장 중요

- 쪼개놨기 때문에 만약에 글에 대한 정보만 필요하면 글을 담고 있는 표만을 조회하는걸 통해서 컴퓨터의 자원을 아낄 수 있다.

- 그리고 join이라는 방법을 통해 필요할 때마다 순간순간 합성해낼 수가 있다.

- ▽수정시 편함

 

그래서 포함관계가 아니라 평면적인 관계로!

 

--------------------------------------------------------------------------------------------------------------------

@4.3. ERD의 구성요소

 

앞서 설명드렸던 이유로 인해 [댓글 글 저자]를 동등한 표로 표현할 수 있습니다 라고 어영부영 말했음.

->더욱 구체적인 설명은 미래의 경험을 통해서 채워주세요

 

이렇게 찾아낸 개념[댓글, 글, 저자]을 ERD에서는 Entity라고 부름, 얘는 후에 Table로 전환되게 됨.

Entity중에 글만놓고보면 글은 실제 데이터가 아님.

구체적인 데이터는 제목, 생성일, 본문에 담겨 있음. 이러한것들을 그루핑한 것이 ‘글‘이라는 Entity인 것.

이렇게 구체적인 데이터를 Attribute, 한글로는 속성이라고 함. 이것은 후에 표의 column이 됨.

근데 왜 저자의 이름, 댓글 이런것들은 글의 속성이 되지 않는가?

전에 살펴봤던 내용과 동일한 내용이지만 한번만 더

만약 저자의 이름 만! 우리시스템에 필요하다면, 저자의 이름은 속성이 되면 됨.

하지만 저자의 이름 뿐만 아니라, 저자에 대한 자기소개, 가입일과 같은 정보가 필요하다면 저자는 이름, 소개, 가입일과 같은 속성을 포함하는 Entity가 되는 것. --wow!

Entity를 디렉토리

Attribute를 파일이라고 비유해보면

Entity란 파일을 담을 수 있고, 자식디렉토리는 담을 수 없는 제한적인 디렉토리다. 다른 디렉토리를 품을 수 없는 혁명적인 디렉토리다.

▽묶어지면 무조건 Entity로 빼야되는것같구만

 

 

 

Entity들 간의 관계는 저자, 글, 댓글은 서로 복잡미묘한 관계를 갖고 있다.

 

- 글과 저자는 쓴다 라는 관계를 갖고 있다.

- 글과 댓글은 소속관계를 갖고 있다.

- 댓글은 저자와 쓴다 라는 관계.

 

이렇게 연관성을 표현해준걸 Relation(관계)이라고 하고

 

나중에 논리적 데이터 모델링으로 가게되면 표에서는 기본키, 외래키라는 것으로 이 관계가 표현됨.

그리고 이렇게 표현, 저장된 데이터를 기반으로 JOIN을 통해서 테이블들을 연결하게됨.

 

▽저렇게 개념을 잘 뽑으면 모든게 관계와 속성으로 커버할 수 있군 뭐 이런느낌인가

▽관계는 PK, FK가 전부구나?

 

개념적 데이터 모델링은 개념에 집중하고 DB패러다임으로부터 거리를 두고 있기 때문에 용어가 실제 DB제품들과는 다름. 각각의 용어가 나중에 무엇이 될지는 다음 그림에

다이어그램 상에선 표현되지 않지만, 설계할 때 행에 대한 얘기를 하겠지? 행을 Tuple이라고 부름.

 

--------------------------------------------------------------------------------------------------------------------

@4.4. 엔티티 정의

app을 하나의 건물이라고 하면, UI는 옥상 DB는 지하

UI와 DB를 원인과 결과의 관점으로 생각해보기

 

정보를 입력하는 UI가 원인이 돼서 DB에 데이터를 넘기는 결과

--내가 생각하고있던게 맞구나, DB엔 UI에서 입력한 값이 들어가는 것.

 

DB의 내용이 원인이돼서 UI에 내용이 표시되는 결과

 

사용자가 마주하는 UI와 컴퓨터가 제공하는 DB는 서로 원인과 결과의 관계

 

원인과 결과를 번갈아가면서 순차적으로 점검하지 않는다면 좋은모델링이 나오기 어려울것입니다.

그러므로 기획자가 구현자가 다르다면 데이터모델링까지는 함께하는 것이 이상적.

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

 

1.제일먼저 해야할일 : 기획서에서 Entity를 찾아내는 것.

여러분(인간)은 연관된 데이터를 그루핑하는 타고난 능력이 있다

 

제 요령인데 읽기에서는 그걸 찾아내기가 어려운데 쓰기 화면에서는 좀 보여

이렇게 표로 만들기 좋은 Entity가 드러남.

무리가 없다면 쓰면 되고

DB표에 잘 어울리지 않거나 하면 수정하면 되는 것.

이제 이걸로 ERD를 그릴건데 draw.io라는 서비스가 있음

Entity를 추출한다!

다음 시간엔 엔티티에다 필요한 속성들

 

--------------------------------------------------------------------------------------------------------------------

@4.5. 속성 정의

속성을 정의해야함. 은 각각 Entity의 소속.

소속관계는 작성하는 란을 통해 쉽게 파악할 수 있었다.

제목과 본문이 속성임.

저자목록은 셀렉트 박스인데 좀더 복합적인 속성이라서 별도의 Entity로 독립해 나갔다라는 그런 뜻일 수 있는것이죠

 : 속성이라기보다는 Relation으로 연결해야 합니다. // 위에 저자 Entity있잖아

--나중에 까지 보고오니까 Entity로 만들어서 [이름, 자기소개, 저자아이디, 가입일]의 속성을 가짐.

 

또 쓰기만으로 부족한게 읽기에 보면 올리고 나면 언제 작성됐는지가 뜨는데 이것도 우리의 시스템을 필요로 하기 때문에 속성으로 있어야함.

여기 오른쪽에 2019. 6. 5

그럼 이제 제목, 본문, 날짜까지.

ERD에서 속성은 원, Entity랑 연결(같은 Entity의 식구들이다)함

 

---지금까지 글---

 

---이제부터 저자---

저자Entity로 하면

쓰기에서

이름과

자기소개

 + 그리고 읽기가보면 가입일도 있음.

진 회색 박스 안의 정보들

=>쓰기에서 속성 찾고, 읽기가서 우리 시스템을 필요로하는 뭐 더 없나 보는것이군.

 

댓글은

제목이 필요 없고

- 내용

- 작성자명 --얘도 가입돼 있는. 저자들만이 댓글을 작성할 수 있게 하고싶다 하면(익명이라면 그냥 내용이랑 똑같이) 글작성할 때 썼던 셀렉트박스로 바꾸는게 맞다

모델링을 하게 되면 모델링과 UI가 서로 검증하는 교차검증이 가능하기때문에. 번갈아가면서 살펴봐야한다. 기획서를 만드는 선수와, 모델링을 하는 선수가 같이(역할이 다를 때, 다른 사람일 때) 머리를 맞대고 상대쪽에 대한 적당한 지식과 경험을 갖고 서로간에 도움을 주고 받으며 하는게 결과가 좋지 않을까요?

 

--------------------------------------------------------------------------------------------------------------------

@4.6.식별자 지정

Identifier

 

속성을 정했으면 Entity에 있는 속성중에서 대표선수를 뽑아야됨.

주민은 주민등록번호로 식별.

자동차는 자동차번호.

웹사이트는 도메인이름.

이런걸 식별자라고 함. 원하는 대상을 정확히 타겟팅 하는 것

그래야 그 대상에 대해 정확하게 어떤일을 할 수 있다.

그 대상을 제외한 누구도 같은 값을 갖고있으면 안된다.

 

ERD에서도 Identifier를 어떤 속성으로 할건지 지정해야함.

그리고 그게 훗날 기본키가 됨(Primary Key)

 

식별자로 쓸수있는 컬럼, 없는 컬럼이 따로 있다

이름은 동명이인, 도시야 뭐 당연하게 안되는것

email도 한사람이 여러 개 가질 수 있기 때문에 안됨. --시스템이 이메일이 다르면 다른 사용자로 치겠다면 쓸 수 있지만

 

만들어질때마다 +1할 수도 있어, 그럼 절대 중복이 안되겠지

 : 자연스럽게 만들어진 식별자가 아니란 뜻에서 인조키라고 부른다, 용어는 안 중요

 

기본키가 될수있는애들을 후보키

선택된애가 기본키

기본키가 아닌애들은 대체키. 얘네는 성능향상을위해 세컨더리 인덱스라고 하는걸 걸기에 아주 좋은 친구들이 됨.

 

컴포짓키, 중복키라는게 조금 특수한 경우로 있는데,

1번이라는 직원이 두 개의 부서에 속해있는 경우임.

직원번호만으로는 행을 식별할 수 없다 --행을 식별해야 한다.

부서번호만으로도 행을 식별할 수 없다.

이런경우엔 직원번호, 부서번호를 합쳐야 식별할 수 있는데 이러한 식별자를 중복키라고 한다.

 

식별자가 될만한 자연스러운 키가 없으면 테이블은 인조, 대리키를 만듦

오토인클리먼트, 시퀀스 로 만든대 --시퀀스말고 또 있구나

ERD에선 밑줄 그은게 식별자

각각의 Entity가 식별자 컬럼을 가져야 한다.

 

--------------------------------------------------------------------------------------------------------------------

@4.7. 엔티티간의 연결

엔티티와 엔티티에 Relationship을 맺어주는 방법

 

최종적으로 Relationship은 무엇이 되는가를 보자

[[[

각각의 표들은 데이터로써 서로 연결돼 있다

이때각각의 표에 행을 식별하는 유일무이한 식별자를 PK라고 함.

저자 테이블의 id값

을 가리키는 글 테이블의 저자 id의 값

을 외래에 있는 테이블과 연결할 때 사용하는 열쇠, 외래키라고함. 포린키.

그래서 관계형DB의 Relationship은 Primary Key와 Foreign Key가 연결되는걸 통해서 실제로 구현됩니다.

]]] --▽관계는 PK, FK뿐이군

 

이런관계를 어떻게 그림으로 표현하나?

ERD에선 마름모꼴의 도형을 이용함.

글은 저자로부터 쓰여짐 당함, 작성 이라는 관계가 있다고 저는 표현합니다~!

소속하고 소속되면 소속이라는 관계 라고 씁니다

 

--------------------------------------------------------------------------------------------------------------------

@4.8. Cardinality

 

지금까지 했던 게 제일 중요하지만 그 나머지 중에서도 제일 중요한 것

Relationship에서 꼭 따져봐야하는 요소

Cardinality와 Optionality

 

진짜 까다로워서 일주일뒤면 항상 까먹고 다시봄(DB Administrator가 아니고 가끔씩 DB를 보니까요~)

Cardinality : 기수, 123456789 이런 숫자

 

아래 두개의 표, join같은걸로 연결될 것임. --▽테이블과 테이블 간의 관계 인거지?

이때 Cardinality를 따져보려면 담임에게 반은 몇 개인가, 반에게 담임은 몇 개인가를 양쪽 다 따져봐야함.

- 담임은 반을 몇개 가질 수 있나?

- 1반을 맡았으면 다른 반을 맡을 수 있나?

- 그 반의 담임이 kim이면 다른 선생님이 담임이 될 수 있나?

 > 담임에게 반은 한개다

 > 반에게 담임은 한개다.

 

ERD에선 1대1 관계를 저렇게 오른쪽처럼 표현함.

 

- 저자에게 댓글은 몇개?

- 댓글에게 저자는 몇개?

양쪽을 다 따져줘야 한다~

1대n관계는 n에 해당되는 부분에 까마귀 발처럼 달아줌 혹은 1 과 n을 적어주거나.

 

 

우리가 만드는 시스템이 하나의 글을 여러명이 편집할 수 있을 때,

 

N 대 M 관계. 여러 개라는 뜻에서 그냥 M이라고 표현했대.

->이거는 현실의 DB에는 표현을 할 수가 없어서, 중간에 연결테이블을 이라는걸 만들어서 최종적으로는 1대 다 관계로 컨버팅을 시킨다.

 

원래 헷갈리고 어려운거야~ 어려운걸 알고있으면 자괴감이 덜하다.

 

--------------------------------------------------------------------------------------------------------------------

@4.9.Optionality

Optionality : 있을수도있고 없을수도있고 라는 말.

 

- 어떤 시스템에 저자가 등록했다면 반드시 댓글을 갖고 있어야 하나?

 

 

kim은 댓글을 썼지만 나머지 사람들은 쓰지 않았다

저자에게 댓글은 옵션이다. O가 옵션인거에 붙어있음. O를 Option의 O라고 생각하면 도움

 

댓글에게 저자는 필수다(Mandatory) --그림은 약간 모순이있어서 집중하지 마시고요 라고만 하심

기호는 작대기 하나를 찍 긋는다

 

저자와 댓글은 필수냐 아니냐도 있지만 1:1이냐 1대 N이냐 도 있다

모두 반영하면 아래처럼

저자는 여러 개의 댓글가능, 댓글 안달수도, 댓글은 반드시 저자가 필요, 저자가 한명이구나

저 오른쪽 아래에 그림 하나만으로 많은 정보가 있군

 

--------------------------------------------------------------------------------------------------------------------

@4.10.ERD 완성

이전시간의 Entity 간의 관계를 표시하는 시간.

개념, 논리, 물리적 모델링에서 뭘 해야 하고 무슨 기호를 쓰는지 등 절차나 기호등에 대해 엄격한 룰이 있는건 아님.

반드시 양쪽을 다 따져봐야 하는 것

Entity갖고 하는것이군!

 

개념적 모델링 끝!

 

--------------------------------------------------------------------------------------------------------------------

@4.11.Entity Relatiop Diagram Helper

erd.yah.ac

연습할 수 있는 웹 서비스 만들었대

삼지창 기호가 없어서 < 로 함