ch4. intermediate SQL

◆ Join operation 

type : 

- inner 

- left outer

- right outer

- full outer

condition : 

 natural / on <predicate> / using ( a1, ...,an ) 

 

◆ outer join

 - to avoid loss of information (정보 손실을 막기 위해)

 - null 값까지 넣으면서 하는 이유? missing information 알 수 없음, 

 

◆ inner join : 중복되는 attribute 다 보여줌

- inner join VS natural join 

http://stackoverflow.com/questions/8696383/difference-between-natural-join-and-inner-join

◆ view

  사용이유 : 1. 보안 , 2. 자주 쓰는거 편하게 쓰려고

  base 에서 특정속성만 뽑아 접근할 수 있게

  (참고) : view definition

 - mechanism to hide certain data from the view of certain users.

 - "virtual relation"

◆ view definition

  create view v as <query expression>

 : 이미 만들어진 view이용해서 새로운 view 생성 가능

예) create view view_name as  < select - from [other view] - where >

◆ view defined using other views

  depend directly

  depend on

  recursive

◆ update of  view

 - view 를 업데이트하면 해당 relation도 업데이트 된다 - constraint도  그대로적용

 - view 업데이트 제한 조건

: from 절에는 하나의 relation 만 !   (only one relation)

: select 절에는 오직 attribute 이름만 ! (오직 속성 이름만!)

: select 절에 올려지지 않은 attribute는 null로 설정 

: 업데이트 쿼리에 group by나 having 사용 불가

  - view의 조건에 맞게! consistency !!! integrity !!!

◆ materialized view 

  - view를 physical data로 저장 ~ 하나의 새로운 릴레이션으로 봐도 무방

  - update를 하기 보다 읽기/검색 자주하는 데이터들에게 유리

  

◆ transaction (pass)

◆ integrity constraints (무결성 제약조건)

  - 데이터의 일관성을 손상시키지 말아야 함

integrity constraint --- single relation

- not null

- primary key

- unique

- check(P)     // predicate 

* unique - unique specification states that the attributes  a1, ...,an 

 form a candidate key. 

* check ( Predicate ) 

ex. check ( semester in ('Fall', 'Winter', 'Spring','Summer'))

◆ referential integrity --- 2개 이상의 relation에 대해
 - 릴레이션의 한 값이, 다른 릴레이션에 대한 속성 집합의 값으로써 반드시 나타나야함!

 - referential integrity가 지켜지지 않으면 consistency가 지켜지지 않음.

 * cascading actions in Referential integrity

  - alternative actions to cascade : set null, set default

◆ complex check clauses 

  - check ( attribute in ( select attribute from relation))

* check 대안 ~ triggers( )

* create assertion <asst_name> check <predicate>;

  -> 항상 참이 되도록

◆ built-in data types in SQL

  - date : 4 digit  year ___ Y2K

  - time 

  - timestamp 

  - interval : period of time

  

◆ index creation 

◆ user-defined types

  - create type type_name as numeric(12,2) final

 

◆ domain

  - create domain domain name char(20) not null 

  - type : 값

  - domain : constraint를 갖는다.

◆ Large-Object type

blob - binary large object

clock - character large object

◆ authorization

 - forms of authorization on parts of the database

   Read  - reading , but not modification

   Insert - insertion of new data , but not modification

   Update - modification, but not deletion

   Delete - deletion

 - forms of authorization to modify the database schema

   Index - creation, deletion of indices

   Resources - creation of new relation

   Alteration - addition or deletion of attributes in a relation

   Drop -  deletion of relation

◆ authorization specification in SQL

  - grant : 권한 부여 

    grant <privilege list> on <relation/view> to <user list>

    <privilege list> : select, update,  delete, insert, all privileges ...

    <user list> : user-id,  public (allows all valid users), role

  - revoke : 권한 취소

    revoke <privilege list> on <relation/view> to <user list>

 *똑같은 권한이 다른 개런티이들에 의해 같은 사용자에게 두번 부여되었을때, 유저는 아마 제거 후 권한 유지할 수도 있음.

◆ role (역할)

 - create role instructor ;

    grant instructor to Amit;

 - role에게도 권한 부여 가능

    grant select on <Relation> to <Role>

 - role의 권한을 role에게도 줄 수 있다

 - chain of roles

◆ authorization on view

create view geo_instructor as (select *

from instructor
where dept_name = ’Geology’);

 grant select on geo_instructor to gio_staff 

  - view에 대해 권한을 주더라도 안됨! geo_instructor에 대해서만 

      ... materialized view 는 괜찮음  

◆ authorizations on Schema

references privilege to create foreign key
 grant reference (dept_name) on department to Mariano;

 why is this required? 

  ** foreign key 제약조건은 참조되는 릴레이션에 대해 삭제와 갱신을 제한하니까

◆ transfer of privilege

Transfer of privileges
 grant select on department to Amit with grant option;
 revoke select on department from Amit, Satoshi cascade; 

 revoke select on department from Amit, Satoshi restrict;

 Etc. read Section 4.6 for more details we have omitted here.