가치관제작소

・개념적설계는 뭐하는 거냐면여~

-수집한 요구사항을 분석해 엔티티와 관계를 추출

-엔티티와 어트리뷰트들, 관계에 속한 어트리뷰트인지를 분류

-최종적으로 er다이어그램을 그리는 것

・개념적 설계 방식

-bottom up 상향식:최소단위의 정보들을 상위개념의 정보 그룹으로

-top down 하향식 : 상위 그룹의 내용을 쪼개 하위그룹으로 나아가는 것

-주로 하향식 방법을 사용함

-그 이유는 전체의 큰그림을 그린 후 작은단위로 나아가기 때문에 넓게보기 좋음

-상향식 방법은 최소단위가 빠질 것을 우려해 보안책으로 사용함

・개념적 설계 플로우

데이터베이스 요구사항 ->엔티티 추출(약한, 강한 엔티티타입 설정) -> 관계설정 -> 카디날리티 설정 -> 애트리부트 설정(키 애트리뷰트 설정, 의도된 애트리뷰트 설정, 다치 애트리뷰트 설정) -> er다이어그램

・K대학교의 데이터베이스 요구사항

<학생관리>

 학번,이름주소,생년월일 등 개인정보를 관리, 그리고 학생은 하나의 전공학과에 속해야하며 , 한분의 지도교수 밑에서 전공지도를 받는다. 매 학기마다 강의를 신청하여 수업을 듣는다.

<과목관리>

교내에 개설된 과먹에 대한 정보를 관리한다(과목번호, 과목명, 과목개요) 그리고 각 과목은 여러개의 섹션으로 나누어서 관리한다. 단 섹션이 존재하지 않는 과목이 존재할 수도 있다.

<교수관리>

교수의 이름, 전공분야, 보유기술 등의 정보를 관리. 특히 보유기술은 여러가지가 있을 수 있음.그리고 교수는 관련 과목을 강의하고 지도학생을 보유한다.

<학과관리>

학과의 학과명, 사무실 위치, 전화번호 등의 정보를 관리한다. 그리고 각 학과의 교수들 중 학과장을 임명한다. 학과장은 임명날자가 있다.

<수강신청>

학생들은 과목을 수강하기 위해 등록을 한다.

・1.엔티티 추출하기

-엔티티 : 실체가 명확히 존재하는 것, 각 엔티티는 독립적으로 고유식별이 가능해야함(사람 vs 물건 과 같이, 미시가 잘되어야함)

-1.명사 정제하기 : 디비 요구사항으로부터 얻어낸 명사들중 엔티티라고 생각되는 명사를 추출, 구분보통 문장에서 명사가 엔티티인 경우가 많더라.. 이 명사들을 구분지어 엔티티 생성

-엔티티 네이밍 센스 : 중복x, 너무 길지않은, 의미없는 수식어x

-2.명사 그룹짓기 : 대표하는 명사로 그룹의 이름을 붙이고, 다른 그룹에 속하는 단어를 옮기기,

다른 그룹과 연관된 명사 제거(전공학과, 수강과목, 지도교수, 지도학생, 학과장 제거)

-3.엔티티 정의내리기

-4.엔티티 표기하기

학생:학번 이름 주소 생일 전공 과목 교수

과목:과목번호 과목명 과목개요 섹션

교수:이름 전공분야 보유기술 지도학생

학과:학과면 사무실위치 전화번호 학과장

・2.관계설정하기

-관계 : 문장속에서 주로 동사인 경우가 많음.

엔티티 간의 관계를 설명하는 동사나 이벤트를 나타내는 동사를 찾음

<그림설명>

-섹션이라는 엔티티는 독립적으로 존재할 수 없고, 과목이 존재해야만 존재할 수 있는 엔티티 이다

따라서 약한 엔티티타입이라고 할 수 있다(이중마름모)

-1,2,3,4,5는 문장으로된 요구사항이다. 각 문장의 명사인 주어 목적어와 동사를 구분하면 엔티티타입과 관계를 구분할 수 있다.

・3.카디날리티 설정

-커디날리티 설정: 한 엔티티타입의 어트리뷰트(그림에서 점)이 한 개의 선만을 가지면 1 여러개의 선을 가지면 n

-하나의 학과는 하나의 교수에게 학과장 당하고, 하나의 교수는 하나의 학과의 학과장한다.

-학생은 여러개의 한 학생은 하나의 학과만을 전공하지만, 한 학과는 여러명의 학생으로 부터 전공당한다.

-한 교수는 여러 과목을 강의하지만, 여러과목은 한 교수에게 강의된다.

-한 학생은 한명의 교수에게 전공지도 받지만, 한 교수는 여러명의 학생을 전공지도한다.

-여러명의 학생은 여러과목을 수강신청하고, 여러과목은 여러학생에게 수강신청 당한다.

・4.키어트리뷰트 설정

-엔티티마다 서로 다른 값을 가지는 고유한 어트리뷰트로 각각 유일한 값을 가져 식별이 가능한 값

-키어트리뷰트의 기준 

-어트리뷰트 값이 변하지 않아야한다

-반드시 값을 갖고 있어야한다.

-한 엔티티 타입내에 복수의 키어트리뷰트가 존재할 수 있다.(학생 엔티티타입 내에 학번, 주민번호)

-키어트리뷰트를 설정 후 ,개념적 설계도에서 밑줄을 긋는다!

<개념적 설계 그림설명>

-한 교수가 보유한 보유기술은 여러개가 존재할 수 있으므로 다치 어트리뷰트

-나이는 생년월일을 통해 계산되므로 유도된 어트리뷰트

・5.관계타입 어트리뷰트 정의

-관계타입 어트리뷰트:관계 타입도 엔티티아비과 유사하게 어트리뷰트를 지닐 수 있다.

・요구사항 분석의 플로우

-요구사항 수집의 기대되는 최종적 아웃풋은 다음단계의 개념적 설계의 인풋으로 사용되는 엔티티,어트리뷰트, 관계를 파악하는 것 어떤 조사를 하던 요구 조사단계의 최종 아웃풋을 잊어서는 안돼.

-> 어떤 조사 방법들을 사용하면, 무지한 클라이언트들로부터 그들이 요구사항을 구체적으로 뽑아내고, 개념적 설계로 나아갈 수 있는 인풋 자료들을 확보할 수 있을지..

-먼저 클라이언트 들은 데이터 베이스에 대한 개념도 없을 것이므로, UI베이스로 클라이언트가 어떤 것을 만들고 싶은지(예를 들어, 수강신청, 학생조회 시스템등), 구축하고 싶은 시스템이나 어플이 무엇인지와 그 시스템이 어떤 기능을 가지고 있는지를 파악.

-클라이언트가 희망하는 시스템에 따라, '아 당신들이 원하는 시스템이나 어플을 만들기 위해서는 이런이런 데이터들이 피요하겠군요' 하고 데이터들을 설명하고, 클라이언트의 요구사항을 구체화

-프로젝트를 더 효율적으로 진행시키기 위해서, 기존에 어떤 시스템을 가지고 있고 어떤 인프라를 가지고 있는지에 대한 조사도 필요

-클라이언트가 희망하는 시스템에 필요한 데이터들을 뽑아낸 이후에는 그 데이터들을 어떻게 엔티티와 애트리뷰트 그리고 관계로 만들어 낼 수 있을지 고민하기

・조사할 때 고려사항

-조사목적(요구사항 조사의 목적이 무엇인가)

-조사범위(어떤 부서, 어떤 사람들에게 질의를 할 것인가)

-개발 비용과 일정

-조사 결과

・K대학교의 데이터베이스 요구사항

-나 : 저희 왜부르셧어요, 뭐하고 싶으세요?

-관계자 : 다음과 같은 데이터들이 필요합니다(이런 똑똑한 클라이언트는 존재하지 않음 사실)

<학생관리>

 학번,이름주소,생년월일 등 개인정보를 관리, 그리고 학생은 하나의 전공학과에 속해야하며 , 한분의 지도교수 밑에서 전공지도를 받는다. 매 학기마다 강의를 신청하여 수업을 듣는다.

<과목관리>

교내에 개설된 과먹에 대한 정보를 관리한다(과목번호, 과목명, 과목개요) 그리고 각 과목은 여러개의 섹션으로 나누어서 관리한다. 단 섹션이 존재하지 않는 과목이 존재할 수도 있다.

<교수관리>

교수의 이름, 전공분야, 보유기술 등의 정보를 관리. 특히 보유기술은 여러가지가 있을 수 있음.그리고 교수는 관련 과목을 강의하고 지도학생을 보유한다.

<학과관리>

학과의 학과명, 사무실 위치, 전화번호 등의 정보를 관리한다. 그리고 각 학과의 교수들 중 학과장을 임명한다. 학과장은 임명날자가 있다.

<수강신청>

학생들은 과목을 수강하기 위해 등록을 한다.

http://somnode.com/database-deiteobeiseu-seolgyewa-ermodel/

ER 모델

1. 실세계를 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현함
2. 카디날리티 비율, 참여 제약조건을 표현하기도 함

엔티티

• 독립적으로 존재하면서 고유하게 식별 가능한 객체
• 실체가 명확히 존재하는 실재적, 개념적인 것(사람,조직,물건,설계,돈)

엔티티타입

• 일반적으로 엔티티라고 부르는 단어가 사실은 엔티티타입을 의미함
• 동일한 애트리뷰트들을 가진 엔티티들의 틀
• ER데이터 모델에서 직사각형으로 나타냄
• 엔티티타입 안에 엔티티가 존재하고, 엔티티 안에 어트리부트가 존재.
  따라서, 엔티티타입안에 어트리부트가 존재한다고 심플하게 생각하면됨
• 실체가 명확히 존재하는 실재적, 개념적인 것(사람,조직,물건,설계,돈)
• 데이터베이스에서 최종적으로 테이블로 표현이 되는 요소
• 두 엔티티 간에 비슷한 애트리뷰트가 많이 있다면 두 엔티티를 하나로 통합

엔티티집합

• 동일한 애트리뷰트들을 가진 엔티티들의 모임
• 관계 모델의 릴레이션의 외연에 해당
  

강한 엔티티타입

• 엔티티타입 내에서 자신의 키 애트리뷰트를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티타입
• 예) 사원 엔티티타입

약한 엔티티타입

• 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티타입
• 소유 엔티티타입의 키 애트리뷰트와 결합해야만 고유하게 엔티티들을 식별할 수 있음
• 예) 부양가족 엔티티타입
  

애트리뷰트

• 엔티티의 특성들
• 엔티티는 독립적인 의미를 갖지만, 애트리뷰트는 독립적인 의미를 갖지 못함
• 애트리뷰트 도메인은 그 애트리뷰트가 가질 수 있는 값의 범위
• 타원형으로 나타냄
• 기본키 애트리뷰트는 밑줄을 그어 표시함

단순 애트리뷰트

• 더 이상 다른 애트리뷰트로 나눌 수 없는 애트리뷰터
  

복합 애트리뷰트

• 두 개 이상의 애트리뷰트로 이루어진 애트리뷰트
  

단일 값 애트리뷰트

• 각 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트

다치 애트리뷰트

• 각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트
  

저장된 애트리뷰트

• 다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트
• 예) 사원 엔티티타입에서 사원이름, 급여는 다른 애트리뷰트와 독립적으로 존재함

유도된 애트리뷰트

• 다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트
• 유도된 애트리뷰트는 관계 데이터베이스에서 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋음
  

관계

• 두 개 이상의 엔티티 타입들 사이의 사상

관계집합

• 동질의 관계들의 집합

관계타입

• 동질의 관계들의 틀
  

관계의 애트리뷰트

• 관계타입은 관계의 특징을 나타내는 애트리뷰트를 가질 수 있음
• 키 애트리뷰트는 갖지 않음
  

차수(degree)

• 관계에 연결된 엔티티타입들의 개수
  

카디날리티

• 한 엔티티가 참여할 수 있는 관계의 수
  

카디날리티의 최소값과 최대값

역할(role)

• 관계 타입의 의미를 명확하게 하기 위해 사용
• 하나의 관계타입에 하나의 엔티티타입이 여러번 나타나는 경우, 반드시 역할을 표기해야함
  

전체참여

• 엔티티타입 E1의 모든 인스턴스가 관계에 참여해야 하는 것

부분참여

• 엔티티타입 E2의 인스턴스 중 일부만 관계에 참여해도 되는 것
  

다중 관계

• 두 엔티티타입 사이에 두 개 이상의 관계 타입이 존재할 수 있음
  

순환적 관계

• 하나의 엔티티 타입이 자기 자신과 관계를 맺는 것
  

새발 표기법(crow-feet)

1:1 관계

1:N 관계

M:N 관계

엔티티 타입과 애트리뷰트

ER 스키마를 관계 모델의 릴레이션으로 사상

단계1: 정규 엔티티타입과 단일 값 애트리뷰트

• 정규 엔티티타입에 있는 단순 애트리뷰트들을 릴레이션에 포함시킴
  

단계2: 약한 엔티티타입과 단일 값 애트리뷰트

• 약한 엔티티타입에 있는 단순 애트리뷰트들을 릴레이션에 포함시킴
• 소유 엔티티타입의 기본 키를 외래키로 포함시킴
• 릴레이션의 기본 키는 약한 엔티티타입의 부분 키와 소유 엔티티타입에 해당하는 릴레이션을 참조하는 외래 키 조합으로 이루어짐
  

단계3: 2진 1:1 관계 타입

단계4: 정규 2진 1:N 관계 타입

단계5: 2진 M:N 관계 타입

단계6: 3진 이상의 관계 타입

단계7: 다치 애트리뷰트

데이터베이스 설계 과정(라이프 사이클)

1. 요구사항 수집과 분석
   • 기존의 문서 조사
   • 인터뷰, 설문조사
2. 개념적 설계
   • ER 모델링
   • 엔티티 타입, 관계 타입, 애트리뷰트들을 식별
   • 애트리뷰트들의 도메인 결정
   • 후보키와 기본키 결정
   • 개념적 설계 단계에서는 보통 큰 틀부터 세부적인 애트리뷰트까지를 분류하는 하향식 방법을 사용
3. DBMS 선정
   • (기술적인 요인)DBMS가 제공하는 데이터 모델, 저장 구조, 인터페이스, 질의어, 도구, 제공되는 서비스
   • (경제적인 요인)DBMS 구입비용, 하드웨어 구입비용, 유지보수 비용, 기존 시스템 변환 비용, 인건비, 교육비
4. 논리적 설계
   • 개념적 설계를 관계 데이터베이스 스키마로 사상
5. 스키마 정제
   • 중복 제거, 스키마 정규화
6. 물리적 설계
   • 성능 고려, 인덱스 정의
   • 저장 구조, 접근 경로 결정
   • 응답시간 : 질의와 갱신이 평균적으로 얼마나 오래 걸리는가?
   • 트랜잭션 처리율 : 1초당 얼마나 많은 트랜잭션이 처리되는가?
   • 전체 데이터베이스에 대한 보고서를 생성하는데 얼마나 오래 걸리는가?
7. 보안 설계
   • 사용자 권한 부여 및 접근 제한
8. 구현 단계
• 데이터베이스 구축과 튜닝
  
  
  
  
  
  
  
  
  
  
  
  http://somnode.com/database-deiteobeiseu-seolgyewa-ermodel/

・데이터모델링

-디비를 구축하고자 하는 대상이 되는 기관에서 사용되는 데이터를 분석하여 제약조건을 체계적으로 정의하고개념적인 도구를 이용하여 간결하고 이해하기 쉽게 표현하는 것

-디테일한 설계도 라기 보다는 나중에 건물이 어떤식으로 보일까 하는 조감도라고 보는게 적절

-아래의 개념 -> 논리 -> 물리적 데이터모델은 단순한 밑그림에서 부터 구체적으로 데이터베이스에 데이터를 넣는 마지막 단계까지 플로우에 따라 진행이된다.

・개념적 데이터 모델

개념 데이터 모델이란 업무 요건을 충족하는 데이터의 주제 영역과 핵심 데이터 집합을 정의하고 관계를 정의한 모델을 의미한다. 기관이나 기업의 업무 특성에 적합한 주제 영역과 핵심 데이터 집합 과의 관계를 정의하여 향후에 정의하게 될 상세 논리 데이터 모델과 물리 데이터 모델과의 데이터 구 조적 정렬(Alignment)을 지원한다. 또한 주제 영역을 통해 전체 업무 범위와 업무 구성 요소를 확인 할 수 있다.

데이터 구조를 위한 데이터 모델은 건축물을 짓는 공법과 유사하다. 큰 건축물에서 방 하나의 인테 리어부터 시작하지 않고 건물의 용도, 건물의 전체적 구조, 쓰이는 자재의 분류부터 시작하듯이 데이 터 구조에 대한 정의 역시 같은 방법으로 접근해야 한다.

개념 데이터 모델은 건축물의 조감도와 같이 구축하고자 하는 업무 모델의 핵심 데이터 구조를 큰 그림으로써 전체 업무에 대한 큰 윤곽을 잡고 세부적인 단계로 나아갈 수 있게 한다. 개념 데이터 모델 의 정의로부터 접근하는 것은 골조가 튼튼한 건물을 짓는 것과 같이 데이터 구조에 대한 기본 구조를 확실히 정의하고 업무 요건 변경에 취약하지 않는 데이터 구조를 세우는 것과 같다. 경우에 따라서는 개념 데이터 모델의 상위 모델인 개괄 데이터 모델을 둘 수 있다.

・논리적 데이터모델

-논리 데이터 모델이란 개념 데이터 모델을 상세화 하여 논리적인 데이터 집합, 관리 항목, 관계를 정의한 모델을 말한다. 논리 데이터 모델은 전체 데이터 구조에서 가장 핵심을 이루는 모델로서 전체 업무 범위와 업무 구성요소를 확인할 수 있다.

-모든 업무의 데이터 구조를 구체적으로 정의하고 최신의 내용으로 관리될 수 있도록 해야 한다. 논리 데이터 모델은 데이터 구조 정의시 상세하게 정의될 수 있는 모든 정보를 포함해야 하며, 논리 데이터 모델이 구체적이고 상세할수록 업무에서 관리하는 모든 데이터 구조는 상세하게 관리될 수 있다.

-데이터가 논리 데이터 모델 단계에서 상세하게 관리되면 불필요한 데이터 중복을 방지할 수 있다. 데이터의 중복은 결과적으로 중복된 데이터로 인해 발생하는 데이터의 불일치(Inconsistency)를 방지하므로 궁극적으로 목적하는 데이터의 품질을 보장할 수 있다. 즉, 구조적이고 상세화된 논리 데이터 모델의 관리와 현재의 논리 데이터 모델이 현재의 업무를 반영하는 주의 깊은 논리 데이터 모델의 관리는 데이터의 품질 보증을 위한 핵심 사항이다.

-논리적 데이터모델을 설계하는 모델로써 아래와 같은 종류가 존재한다.
:네트워크 데이터모델, 계층 데이터모델, 객체지향 데이터모델, 관계형 데이터모델, 객체-관계형 데이터모델

・물리적 데이터모델

물리 데이터 모델이란 논리 데이터 모델을 DBMS의 특성 및 성능을 고려하여 구체화시킨 모델을 말한다. 물리 데이터 모델은 DBMS 선정 이후에 해당 DBMS 상에서 최상의 성능을 보장하도록 논리 데이터 모델에서 저장하는 데이터의 물리적 특성을 최대한 반영하여 설계하고 이를 관리한다. 논리 데이터 모델이 1:1로 데이터베이스의 객체로 대응되어 생성되지 않으므로 DBMS의 성능을 최대한 살릴 수 있고 저장되는 데이터의 특성을 충분히 반영할 수 있다.

물리 데이터 모델로의 설계 단계에서 샘플 데이터를 이용하여 논리 데이터 모델의 정합성을 재 검증할 수 있다. 물리 데이터 모델의 설계를 위해서는 업무 요건과 필요에 따라 사용자 화면이 완성되어야 하므로 사용자 애플리케이션과 상호 검증 하에 설계될 수 있다. 물리 데이터 모델의 설계 시점은 애플리케이션의 설계나 업무 요건이 명확해지는 단계이므로 업무 요건을 반영한 물리 데이터 모델을 설계할 것을 권장한다.

물리 데이터 모델의 테이블명, 관계명, 칼럼명 등은 표준 데이터에서 명시한 표준 단어와 표준 용 어 규칙에 따른 물리명을 선언하고 이를 기준으로 하여 생성할 것을 권장한다. 물리 데이터 모델에서 는 무엇보다 도메인의 선언이 중요하며 도메인 규칙에 대한 충실한 준수는 물리 데이터 모델 내에서 유지하는 데이터를 고품질로 유지할 수 있는 필수 조건이 될 것이다. 물리 데이터 모델에 대한 예로 [그림 6-2-8]을 들 수 있다. [그림 6-2-9]는 IE표기법을 기준으로 작성한 예이다.

http://www.dbguide.net/db.db?cmd=view&boardUid=12830&boardConfigUid=9&categoryUid=216&boardIdx=37&boardStep=1

・데이터 베이스 관리 시스템(DBMS, database management system)

-데이터 베이스를 만들거나 관리하는 소프트웨어

-오라클사의 oracle, 마소의 ms sql, 리눅스의 mysql

・데이터 베이스 시스템(DBS, database system)

-사용자가 데이터베이스 관리 시스템을 통하여 물리적인

데이터베이스와 소통하는 형태의 시스템

・데이터베이스

-실제 데이터가 쌓이는 스페이스

・데이터 베이스 관리 시스템의 장점

-데이터의 중복성과 불일치성감소

-데이터 보안

-질의처리(query)에 효율적인 저장구조

-백업과 복구 가능

-다양한 ui

-일관된 데이터유지

-데이터베이스 설계, 운용관리, 유지 비용감소

・데이터 베이스 관리 시스템의 단점

-자원이 많다. 개발도 새로 해야되고  개발하려면 사람써야하고, 인프라 구축해야하고 ,서버도 필요하고...

-비싸다

・데이터베이스 시스템을 사용하지 않는 경우

-데이터베이스와 응용 프로그램이 매우 단순하고 변경이 거의 없는경우

-단일 사용자만이 데이터베이스에 접근 하는 경우

-실시간서이 제일 중요한 데이터베이스 시스템의 경우

・데이터베이스 스키마

-데이터베이스의 구조와 제약조건에 대해서 분명하고 자세하게 기술한것

-구체적으로 데이터베이스를 구성하는 attribute와 관계 등의 집합

-테이블 등을 묶는 하나의 묶음을 스키마라고도 종종 들어왔기 때문에 혼동

===========

스키마는 3계층 스키마로 나누어져 구성되어있고, 이 각각의 스키마는 결국 데이터베이스의 구조와 제약조건에 대한 전반적인 명세를 기술한 것을 의미한다. 3계층으로 스키마를 나눈 이유는 관점에 따라서 분류한 것이다.

 - 외부스키마 : 개인의 입장, '서브스키마'라고도 한다, 사용자 뷰를 가리킨다. 

하나의 외부스키마는 여럿이 공유 가능하며, 

하나의 DB시스템에 여러 개의 외부스키마가 존재 가능

 - 내부스키마 : 조직 전체의 입장, 전체적인 뷰를 가리킨다.

개체간의 관계와 제약조건을 나타내고, 

데이터베이스의 접근권한/보안/무결성 규칙에 대한 명세를 정의함, 

  일반적으로 '스키마'라는 내부스키마를 가리킴, 

내부스키마는 DBA가 만듦, 데이터베이스의 전체적인 구조로써 하나만 존재해야 함

 - 개념스키마 : 시스템 프로그래머나 설계자의 관점에서 바라보는 스키마,

                    데이터베이스의 물리적 구조를 가리킴(= 실제 저장방법을 기술하는 물리적인 저장장치와 관련됨) 

===========

출처: http://ykcb.tistory.com/entry/데이터베이스-스키마의-개념-특징 [YKCB Team]

・데이터베이스 상태

-데이터는  빠지거나 들어오는데, 그중 "특정(일시적) 시점"의 데이터베이스 내용

・데이터베이스 언어

-DLL(Data Definition Lang)

:디비 관리자나 설계자가 데이터간의 관계를 정의하거나 이미 정의된 디비의 구조를 변경하거나 수정하는데 사용하는 언어

-DML(Data Manipulation Lang)

:디비 사용자가 응용프로그램이나 질의어를 이용해서 저장된 실제데이터를 검색(select), 삽입(insert), 삭제(delete), 변경 등을 수행하는 언어

-DCL(DAta Conrol Lang)

:디비 관리자가 데이터를 관리하려고 데이터의 보안, 무결성, 데이터복구

병행 수행 제어등을 정의할때나, 사용자의 권한을 설정할때 사용하는 언어

・데이터베이스 사용자

-조직내에 구축된 디비를 사용하는 사람들의 총칭

-디비 관리자(DB admin)

:디비 전체환경 구성과 운영에 관련된 전반적인 책임자

-디비 설계자(DB designer)

:디비를 구축하고자하는 요구 사항을 분석해 디비의 개념,물리적 스키마 설계를 책임

-시스템 프로그램 개발자,응용프로그램 개발자,

:초보적인 유저가 사용할 수 있도록 디비관련 어플을 개발하는 사람

-업무분석가, 일반사용자 등

・데이터베이스 단위

-필드:테이블의 열(=attribute, 속성, 필드, 컬럼)

-레코드:테이블의 행(=투플,레코드, 로우)

-파일:레코드의 집합

-데이터베이스 : 파일들이 모여 연관성이 생기면 디비

・디비의 추상화와 데이터 독립성

-추상화:알필요가 없는 복잡한 부분을 은폐

*디비와 어떤 연관?:내부 스키마에서 외부스키마로 갈수록 필요없는 정보(데이터의 형식같은 것들)를 감추어간다

-데이터 독립성 : 특정 스키마를 변경할 때 상위 스키마에 영향을 미치기 않게 하는 것

・3계층 스키마과 독립성

-논리적 데이터 독립성:외부스키마나 응용프로그램을 변경하지 않고 개념스키마를 변경할 수 있도록하는 것

-물리적 데이터 독립성:개념스키마를 변경하지 않고 내부스키마를 변경할 수 있도록 하는 것

・데이터 모델링 *세가지 모델링 구분이 잘 안간다. 각 예를 좀 보고싶은데.

-개념적 데이터모델

:사용자가 데이터를 어떻게 인식하는지에 관심

:데이터가 어떤 형태로 저장되는가 따위의 세부적인 부분은 관심이 없는 모델링

:엔티티 관계 데이터 모델

-논리적 데이터 모델

:컴퓨터와 사용자 둘다를 고려하는 데이터 모델로 사용자가 이해할 수 있게 하면서

저장될 수 있는 구조를 갖게한다

-물리적 데이터 모델

:데이터가 어떻게 컴퓨터에 저장되는지, 조금 더 컴퓨터의 입장에서 바라봄

:레코드의 형식, 레코드 순서, 접근 경로 같은 정보들