Microsoft Word - DDL.doc

1. Wstęp

DDL – Data Definition Language, jest częścią języka SQL umożliwiającą tworzenie
i zarządzanie obiektami w bazie danych, jak również uprawnieniami do tych obiektów.
Możemy do nich zaliczyć:

1. tabele – obiekty przechowujące dane,
2. perspektywy – wirtualne tabele, których zawartość wyznaczana jest na bieżąco, na

podstawie zdefiniowanego w perspektywie zapytania SQL,

3.  indeksy – struktury przyspieszające wyszukiwanie danych,
4.  użytkowników – obiekty umożliwiające kontrolę dostępu do danych,
5.  przywileje – określające zakres uprawnień użytkownika w bazie danych,
6.  role – nazwane grupy uprawnień.

Podstawowe instrukcje języka DDL są wspólne dla wielu systemów zarządzania bazami
danych, jednak poszczególne opcje lub typy danych mogą różnić się w implementacjach,
w różnych serwerach baz danych. W kolejnych rozdziałach omówione zostaną polecenia
języka DDL dostępne w systemie SQL Server. Polecenia te przedstawione są w ich wersji
podstawowej. Wersja rozszerzona dostępna jest w dokumentacji serwera SQL Server Books
OnLine.

W prezentowanych instrukcjach językach SQL przyjęta została następująca konwencja:

— [] – opcjonalność, możliwość pominięcia danego elementu,

— [,..n] – możliwość wielokrotnego powtórzenia elementu,
— {…|…|…} – możliwość wyboru jednej z opcji wymienionych w nawiasach

klamrowych, a oddzielonych znakiem pionowej kreski,

— < > – uszczegółowienie definicji elementu w dalszej części polecenia,

— podkreślenie – oznaczenie wartości domyślnej.

2. Baza danych

Podstawowym zadaniem bazy danych jest umożliwienie gromadzenia i zarządzania
informacją o określonej tematyce. Składa się ona z plików danych oraz z pliku log.
Najprostsze polecenie tworzenia bazy danych wymaga podania tylko jej nazwy:

CREATE DATABASE nazwa_bd

Przykład

1. Utworzyć bazę danych o nazwie BiuroProjektow

CREATE

DATABASE

biuroProjektow

Polecenie to można jednak rozszerzyć o informacje dotyczące liczby, rozmiaru i lokalizacji
plików składających się na bazę danych. Ponieważ dyskusja nad fizyczną budową bazy
danych nie jest przedmiotem ćwiczenia, zainteresowanych odsyła się do dokumentacji
serwera.

3. Tabele

Analizując polecenie tworzenia nowej tabeli, można w nim wydzielić dwie części:

— definiującą kolumny składające się na tabelę

<definicja_kolumny>

— określającą warunki integralności, które muszą spełnić dane wprowadzane do tabeli

<ograniczenia_na_poziomie_tabeli>

Definicja kolumny składa się z dwóch elementów: nazwy oraz jej typu (podstawowe typy
danych dostępne w systemie SQL Server 2005 prezentuje tabela 1). Ponadto dla każdej
z kolumn można definiować ograniczenia dotyczące wprowadzanych do niej wartości.
Ograniczenia te można określić bezpośrednio w definicji kolumny
(

<ograniczenie_nakładane_na_kolumnę>

)

lub w części deklaracji ograniczeń

(

<ograniczenia_na_poziomie_tabeli>

znajdującej się poniżej definicji wszystkich kolumn.

W tej części definicji tabeli buduje się wyrażenia logiczne, w których wykorzystywane są
zależności pomiędzy:

— kolumną i wartością stała lub zwracaną przez funkcję,
— kolumnami aktualnej tabeli,

— pomiędzy kolumnami różnych tabel – więzy referencyjne klucza obcego.

Kluczem obcym tabeli (nazywanej podrzędną) określa się kolumnę, która związana jest
z kluczem głównym w innej tabeli (nazywanej nadrzędną). Dzięki więzom referencyjnym
istnieje możliwość kontroli zgodności danych wprowadzanych do kolumny klucza obcego
z wartościami znajdującymi się w kolumnie klucza głównego:

— serwer nie dopuści do wprowadzenia wartości w tabeli podrzędnej, dla których nie

istnieją odpowiednie dane w tabeli nadrzędnej,

— próba usunięcia lub modyfikacji rekordów w tabeli nadrzędnej, które mają swoje

odpowiedniki w tabeli podrzędnej, zakończy się niepowodzeniem chyba, że domyślne
ustawienia serwera (

ON DELETE, ON UPDATE

) zostaną zmienione w definicji tabeli

w frazie

FOREIGN KEY

W systemie MS SQL Server w tabeli można także definiować kolumny wyliczane
(

<kolumna_wyliczana>

), których wartości nie są przechowywane w bazie danych, lecz są

wyznaczane w trakcie realizacji zapytania, na podstawie warunków zdefiniowanych w tej
kolumnie.

Znaczenie słów w poleceniu definiującym tabelę:
NULL | NOT NULL – dopuszczenie lub nie, pustych wartości w kolumnie,
CONSTRAINT – ograniczenie, którym może być:

— DEFAULT – definicja wartości domyślnej dla pola,

—

IDENTITY – autonumerowanie wartości w kolumnie, począwszy od wartości
wskazanej w

wartość_poczatkowa

z krokiem wskazanym w

krok

— PRIMARY KEY – oznaczenie kolumny jako klucz główny,

— UNIQUE – zapewnienie wartości unikalnej w kolumnie,
— FOREIGN KEY – oznaczenie kolumny jako klucz obcy, z możliwością określenia

dozwolonych zmian w kolumnie klucza głównego:

o NO ACTION – wartość kolumny klucza głównego nie może być usunięta ani

zmodyfikowana, w przypadku istnienia odpowiadających wartości klucza
obcego,

o  CASCADE – kaskowe usunięcie lub modyfikacja powiązanych pól,
o  SET NULL – ustawienie w kolumnie klucza obcego wartości NULL,
o  SET DEFAULT – ustawienie w kolumnie klucza obcego wartości domyślnej

dla tej kolumny.

— CHECK – nałożenie ograniczeń w postaci wyrażeń logicznych,

— CLUSTERD, NONCLUSTERD – pojęcia te wyjaśnione są w rozdziale Indeksy.

Tabela 1. Podstawowe typy danych

TYP Liczba

bajtów

int

bigint 8
smallint 2
tinyint 1
decimal(p[,s]) 2-17
numeric (p[,s])

2-17

float(n)

N<8 – 4B, N<16 – 8B

real 4
money 8
smallmoney 4
datetime 8
smalldatetime 4
char(n) 0-8000
varchar(n) 0-8000
uniqueidentifier 16
bit 1
timestamp 8

Polecenie tworzące tabelę:

CREATE TABLE nazwa_tabeli
(

{ <definicja_kolumny> | <kolumna_wyliczana> }

[ <ograniczenia_na_poziomie_tabeli> ] [ ,...n ]
)

<definicja_kolumny> ::=
nazwa_kolumny typ_danych
[ NULL | NOT NULL ]
[[ CONSTRAINT nazwa_ograniczenia ] DEFAULT wyrażenie_definujące_ograniczenie ]

| [ IDENTITY [ ( wartość_poczatkowa, krok ) ]]
[ <ograniczenie_nakładane_na_kolumnę> [ ...n ] ]

< ograniczenie_nakładane_na_kolumnę > ::=
[ CONSTRAINT nazwa_ograniczenia ]
{ { PRIMARY KEY | UNIQUE }
| [ FOREIGN KEY ]

REFERENCES nazwa_tabeli_klucza_głównego [(kolumna_klucza_głównego[ ,...n)]
[ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]

[ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]

| CHECK ( wyrażenie_logiczne )
}

<kolumna_wyliczana> ::=
nazwa_kolumny AS wyliczane_wyrażenie_definujące_zawartość_kolumny

<ograniczenia_na_poziomie_tabeli> ::=
[ CONSTRAINT nazwa_ograniczenia ]
{
{ PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]

(nazwa_kolumny [ ASC | DESC ] [ ,...n ] )

| FOREIGN KEY

(nazwa_kolumny [ ,...n ] )
REFERENCES nazwa_tabeli_klucza_głównego [(kolumna_klucza_głównego[ ,...n])]
[ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
[ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]

| CHECK ( wyrażenie_logiczne )
}

Przykłady

2. Utworzyć tabelę o nazwie pracownicy zawierającą dwie kolumny: nr_prac oraz nazwisko. Kolumna

nr_prac w momencie wstawiania nowego rekordu powinna być automatycznie inkrementowana
począwszy od 100 z krokiem 1 i powinna być kluczem głównym.

CREATE

TABLE

pracownicy

(

nr_prac

int

IDENTITY

(

100

)

PRIMARY

KEY

nazwisko

varchar

(

))

3. Utworzyć tabelę o nazwie pracownicy zawierającą kolumny, nr_prac, pensja, data_ur, opis. Na

kolumnę pensja należy nałożyć warunki integralności zapewniające, że wartość wprowadzana do tego
pola zawsze będzie większa od zera, natomiast data_ur powinna być zawsze mniejsza od daty bieżącej
(do stworzenia warunku wykorzystać funkcję getdate() zwracającą bieżąca datę)

CREATE

TABLE

pracownicy

(

nr_prac

int

IDENTITY

(

100

)

PRIMARY

KEY

pensja

int

check

(

pensja

data_ur

datetime

opis

varchar

(

constraint

data_mniejsza

check

(

data_ur

getdate

()))

4. Utworzyć tabelę o nazwie projekty, która będzie miała trzy kolumny, nr_proj (klucz główny) start

i koniec, reprezentujące odpowiednio daty rozpoczęcia i zakończenia projektu. Należy zapewnić, by data
startu projektu nie była późniejsza niż data jego zakończenia.

CREATE

TABLE

projekty

(

nr_proj

int

PRIMARY

KEY

start

datetime

koniec

datetime

constraint

koniec_po_starcie

check

(

start

koniec

))

4. Perspektywy (View)

Perspektywa jest wirtualną tabelą reprezentującą dane z jednej lub kilku tabel. Zatem
polecenie tworzenia perspektywy, w zasadniczej części, składa się z instrukcji select
tworzącej określony zbiór rekordów.

CREATE VIEW nazwa_perspektywy [ (kolumna [ ,...n ] ) ]
AS polecenie_SELECT [ ; ]

Przykład

5. Utworzyć perspektywę wyświetlającą średnią zarobków wszystkich pracowników. Do utworzenia

perspektywy wykorzystać tabelę stworzoną w przykładzie numer 2.

CREATE

VIEW

srednia

(

kwota

)

SELECT

avg

(

pensja

)

from

pracownicy

5. Indeksy

W systemie SQL Server można tworzyć dwa rodzaje indeksów:

— klastrowy (

CLUSTERED

), który powoduje przebudowanie rekordów w strukturę B-drzewa,

w oparciu o wskazany w poleceniu atrybut – zazwyczaj jest to atrybut kluczowy;

utworzenie w tabeli klucza głównego powoduje automatyczne utworzenie na nim
indeksu klastrowego,

— nieklastrowy (

NONCLUSTERED

), który stanowi osobną strukturę B-drzewa zawierającą

posortowane wartości ze wskazanej kolumny oraz wskaźnik do rekordu zawierającego
tę wartość; jest to domyślny rodzaj indeksu.

Uwaga ! W tabeli może istnieć tylko jeden indeks klastrowy.

Znaczenie słów w poleceniu definiującym indeks:

— UNIQUE

– indeks unikalny, nie dopuszcza powtarzających się wartości,

— CLUSTERD, NONCLUSTERD – odpowiednio oznaczenie indeksu klastrowego

i nieklastrowego,

— ASC, DESC – sposób sortowania wartości w kolumnie – odpowiednio rosnąco

(domyślnie) i malejąco.

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX nazwa_indeksu
ON nazwa_tabeli_lub_perspektywy ( nazwa_kolumny [ ASC | DESC ] [ ,...n ] )

Przykłady

6. Utworzyć nieklastrowy indeks dla tabeli Projekty na kolumnie start.

CREATE

INDEX

id_start

projekty

(

start

)

7. Utworzyć indeks dla tabeli Pracownik na kolumnach data_ur i pensja. Pensje w ramach dat urodzenia

powinny być posortowane malejąco.

CREATE

INDEX

id_pen

pracownicy

(

data_ur

pensja

DESC

)

6. Użytkownicy

Kontrola dostępu do danych, znajdujących się na serwerze MS SQL Server 2005, realizowana
jest dwustopniowo. Każdy użytkownik, chcący z nich korzystać, musi posiadać swoje konto
serwerowe (Login), na podstawie którego tworzony jest użytkownik w bazie danych
(Database User). Jedno konto serwerowe może być mapowane do wielu użytkowników baz
danych.

6.1 Konta serwerowe

Konta serwerowe mogą być tworzone poprzez:

— mapowanie użytkowników systemu Windows, co uzyskuje się podając nazwę

użytkownika w systemie Windows, poprzedzoną nazwą domeny oraz frazę

FROM

WINDOWS

— stworzenie niezależnego obiektu znajdującego się tylko na serwerze SQL, w tym celu

podaje się nazwę użytkownika (

LOGIN_NAME

) oraz jego hasło (

PASSWORD

Dla każdego konta serwerowego można dodatkowo określić, między innymi, domyślną bazę
danych, do której będzie on przyłączany (

DEFAULT_DATABASE

) oraz domyślny język

komunikatów (

DEFAULT_LANGUAGE

CREATE LOGIN nazwa_konta_serwerowego { WITH <option_list1> | FROM <źródło> }

<źródło> ::=
WINDOWS [ WITH <windows_options> [ ,... ] ]

<option_list1> ::=
PASSWORD = 'hasło'

[, <Windows_option> [ ,... ] ]

<windows_options> ::=
DEFAULT_DATABASE = nazwa_bazy_danych
| DEFAULT_LANGUAGE = język

Przykłady

8. Utworzyć konto serwerowe dla użytkownika lab systemu Windows, należącego do domeny ZTI.

CREATE

[ZTI\lab]

FROM

WINDOWS

9. Utworzyć lokalne konto serwerowe o nazwie lab_air z hasłem lab_air1234 i domyślną bazą danych

labbd

CREATE

lab_air

WITH

PASSWORD

'lab_air1234'

DEFAULT_DATABASE

labbd

6.2 Konta bazodanowe

Konta bazodanowe umożliwiają użytkownikom, posiadającym konta serwerowe, na
korzystanie z określonej bazy danych i są tworzone w niej wyłącznie poprzez mapowanie
kont serwerowych. Nie ma możliwości utworzenia użytkownika bazy danych, jeśli nie
posiada on konta serwerowego. Nowoutworzonemu użytkownikowi bazy danych
przypisywany jest domyślny schemat, tzn. zbiór obiektów stanowiących dla niego domyślną
przestrzeń nazw. Jeśli w poleceniu tworzącym użytkownika, pominięty zostanie ten parametr
będzie on domyślnie przypisany do schematu dbo (czyli takiego, jaki posiada właściciel bazy
danych).

CREATE USER nazwa_użytkownika { FOR | FROM } LOGIN nazwa_konta_serwerowego

[ WITH DEFAULT_SCHEMA = nazwa_schematu ]

Przykłady

10. Dla stworzonych wcześniej kont serwerowych utworzyć użytkownika w bazie danych Test. Domyślnym

schematem użytkownika lab ma być schemat projekty.

CREATE

USER

[lab_air]

FROM

[lab_air]

CREATE

USER

[lab]

FROM

[ZTI\lab]

WITH

DEFAULT_SCHEMA

projekty

7. Przywileje

Przywileje pozwalają sterować uprawnieniami przydzielanymi poszczególnym
użytkownikom w zakresie dostępu do różnych obiektów. Przywileje te można podzielić na
dwie grupy:

—

proceduralne – obejmujące uprawnienie do tworzenia obiektów –

CREATE DATABASE,

CREATE TABLE, CREATE VIEW

—

obiektowe – umożliwiające realizacje operacji na rekordach w tabeli lub perspektywie –

SELECT, UPDATE, INSERT.

Do zarządzania przywilejami służą trzy polecenia:

GRANT

– nadające uprawienie,

GRANT przywilej [ ( kolumna [ ,...n ] ) ] [ ,...n ]

[ ON obiekt ] TO użytkownik [ ,...n ]

[ WITH GRANT OPTION ]

REVOKE

– odbierające przywilej,

REVOKE [ GRANT OPTION FOR ]

przywilej [ (kolumna [ ,...n ] ) ] [ ,...n ]

[ ON obiekt ] { TO | FROM } użytkownik [ ,...n ]

[ CASCADE]

DENY

– zabraniające dokonywania operacji na obiekcie, polecenie mocniejsze niż

REVOKE

(dokładne wyjaśnienie różnicy znajduje się w rozdziale Role)

DENY przywilej [ (kolumna [ ,...n ] ) ] [ ,...n ]

[ ON obiekt ] TO użytkownik [ ,...n ]
[ CASCADE]

Przywileje mogą być przekazywane przez użytkownika, jeśli nadano mu je z opcją

WITH

GRANT

. W takim przypadku odebranie uprawnień może odbyć się z opcją

CASCADE

, co

powoduje odebranie wszystkich uprawnień nadanych przez konkretnego użytkownika.

Przykłady

11. Użytkownikowi lab_air nadać uprawnienie pozwalające na odczyt i modyfikację rekordów z tabeli

projekty

GRANT

SELECT

UPDATE

projekty

lab_air

12.

Użytkownikowi lab_air odebrać uprawnienia usuwania rekordów z tabeli pracownicy

REVOKE

DELETE

pracownicy

FROM

lab_air

13. Użytkownikowi lab_air zabronić tworzenia nowych tabel

DENY

CREATE

TABLE

lab_air

8. Role

Role to mechanizmy umożliwiające zbiorowe nadawanie uprawnień. Wykorzystuje się je
w przypadku, kiedy kilka osób ma zrealizować te same zadania w bazie danych. Wygodnie
jest wtedy zebrać wszystkie, niezbędne dla nich uprawnienia w postaci roli i przypisać do niej
właściwych użytkowników.
Roli uprawnienia nadaje się w taki sam sposób, jak w przypadku tabel, tzn. z wykorzystaniem
poleceń

GRANT

REVOKE

DENY

. Jeśli użytkownik posiada przywileje nadane indywidualne

oraz poprzez rolę, to jego prawa stanowią sumę wszystkich przywilejów. Wyjątek stanowi
użycie, w którymkolwiek przydziale uprawnień, polecenia

DENY

. Ma ono zawsze silniejsze

działanie niż

GRANT

. Zatem, jeśli użytkownik uzyskuje przywilej poprzez przypisanie go do

roli, a indywidualnie, dla tego uprawnienia, zastosowano w stosunku do niego polecenie

DENY

to nie będzie mu wolno wykonywać określonych działań w bazie danych. Zasada to ma
zastosowanie również w przypadku, gdy roli zabroni się wykonywania określonej czynności,
a użytkownik należący do tej roli posiada indywidualnie nadany przywilej.

CREATE ROLE nazwa_roli

W systemie SQL Server istnieją predefiniowane role systemowe i bazodanowe, wybrane
z nich prezentują zamieszczone dalej tabele.

Role serwerowe

Role bazodanowe

Przyłączanie użytkowników do ról odbywa się za pomocą procedur wbudowanych:

a. dla ról serwerowych –

sp_addsrvrolemember nazwa_konta_serwerowego,

nazwa_roli,

b. dla ról bazodanowych –

sp_addrolemember

nazwa_roli nazwa_użytkownika,

polecenie to musi być wykonywane w bieżącej bazie danych.

Przykład

14.

Utworzyć rolę o nazwie prac i nadać jej uprawnienia do wprowadzania i odczytu rekordów z tabeli
pracownicy oraz zakazać modyfikacji i usuwania rekordów z tej tabeli

Rola Uprawnienia

sysadmin dowolne

działanie w SQLServer’ze.

dbcreator

tworzy, zmienia i usuwa bazy danych

diskadmin zarządza plikami dyskowymi

processadmin zarządza procesami SQLServer’a

serveradmin

konfiguracja opcji serwera

securityadmin zarządza kontami użytkowników

Rola Uprawnienia

public

posiada wszystkie domyślne uprawnienia

db_owner wszystkie

działania w bazie danych

db_accessadmin

dodaje, usuwa użytkowników i role baz danych

db_ddladmin

dodaje, zmienia, usuwa obiekty bazy danych

db_securityadmin zarządza uprawnieniami

db_backupoperator

wykonywanie kopii bazy danych

db_datareader

odczyt danych z dowolnej tabeli

db_datawriter

wstawia, modyfikuje i usuwa rekordy

db_denydatareader

zakaz odczytu jakichkolwiek danych

db_denydatawriter

zakaz zmiany jakichkolwiek danych

opis elementów znajduje
się na str. 4

CREATE

ROLE

prac

GRANT

SELECT

INSERT

pracownicy

prac

DENY

UPDATE

DELETE

pracownicy

prac

15.

Do roli umożliwiającej odczyt bazy danych dołączyć użytkownika lab_air

sp_addrolemember db_datareader, lab_air

9. Zmiana definicji obiektów

Zmiany raz utworzonego obiektu można dokonać za pomocą polecenia:

ALTER nazwa_typu_obiektu nazwa_obiektu.

Polecenie to będzie różnić się dla poszczególnych obiektów, ale będzie pokrywało się
z zasadami obowiązującymi przy jego tworzeniu. W dalszej części rozdziału przedstawione
zostaną polecenia zmiany definicji tabeli oraz kont serwerowych i użytkowników baz danych.

9.1 Zmiana definicji tabeli

Zmiana definicji tabeli może obejmować:

— zmianę definicji kolumny – fraza

ALTER COLUMN,

— dodanie nowej kolumny lub ograniczenia – fraza

ADD

— usunięcie kolumny lub ograniczenia – fraza

DROP

W prezentowanym dalej poleceniu pojawiają się nowe opcje

WITH { CHECK | NOCHECK }

Określają one, czy dane znajdujące się w tabeli są poddawane walidacji w momencie zmiany
definicji tabeli (

CHECK

), czy walidacja ta będzie pominięta (

NOCHECK

ALTER TABLE nazwa_tabeli
{

ALTER COLUMN nazwa_kolumny
{
nazwa_typu [ NULL | NOT NULL ]
}
| [ WITH { CHECK | NOCHECK } ] ADD
{
<definicja_kolumny>
| <kolumna_wyliczana>
| <ograniczenia_na_poziomie_tabeli>

} [ ,...n ]
| DROP
{
[ CONSTRAINT ] nazwa_ograniczenia

| COLUMN nazwa_kolumny

} [ ,...n ]
| [ WITH { CHECK | NOCHECK } ] { CHECK | NOCHECK } CONSTRAINT

{ ALL | constraint_name [ ,...n ] }
}

Przykład

16. Zmodyfikować tabelę projekty utworzoną w przykładzie 3 i dodać do niej kolumnę nr_prac (numer

pracownika, który będzie odpowiedzialny za prowadzenie projektu). Kolumna ta ma być kluczem obcym,
dla którego klucz główny znajduje się w tabeli pracownicy stworzonej w przykładzie 1. Zapewnić, by
w przypadku usunięcia pracownika z tabeli pracownicy, w polu klucza obcego pojawiała się wartość
NULL.

ALTER

TABLE

projekty

ADD

nr_prac

int

FOREIGN

KEY

REFERENCES

pracownicy

(

nr_prac

)

DELETE

SET

NULL

17. Zmodyfikować tabelę projekty utworzoną w przykładzie 3 i dodać do niej ograniczenie zabezpieczające

przed możliwością wprowadzenia do pola start daty wcześniejszej niż bieżąca. W trakcie dodawania
ograniczenia nie należy walidować już istniejących rekordów.

ALTER

TABLE

projekty

WITH

NOCHECK

ADD

CONSTRAINT

start_data

CHECK

(

start

getdate

())

18. Usunąć ograniczenie stworzone w przykładzie 15

ALTER

TABLE

projekty

DROP

CONSTRAINT

start_data

9.2 Zmiana definicji użytkownika

Zmiana definicji konta serwerowego oraz użytkownika bazy danych obejmuje ponowne
określenie jego nazwy, bądź przydzielonych mu właściwości. W definicji konta serwerowego
pojawia się dodatkowo możliwość jego włączenia lub wyłączenia (

ENABLE | DISABLE

9.2.1 Konta serwerowe

ALTER LOGIN nazwa_konta
{
ENABLE | DISABLE

| WITH <set_option> [ ,... ]
}

<set_option> ::=
PASSWORD = 'hasło'
[

OLD_PASSWORD = 'stare_hasło'
]

| DEFAULT_DATABASE = nazwa_bazy_danych
| DEFAULT_LANGUAGE = język
| NAME = nowa_nazwa_konta

9.2.2 Użytkownicy bazy danych

ALTER USER nazwa_użytkownika
WITH <opcje> [ ,...n ]

<opcje> ::=
NAME = nowa_nazwa_użytkownika
| DEFAULT_SCHEMA = nazwa_schematu

Przykłady

19. Utworzonemu wcześniej kontu serwerowemu lab_air zmień domyślną bazę danych na biblio1

ALTER

lab_air

WITH

DEFAULT_DATABASE

biblio1

10. Usuwanie obiektów

Polecenie usuwania jest jednakowe dla wszystkich obiektów i ma postać:

DROP nazwa_typu_obiektu nazwa_obiektu

Przykłady

DROP

USER

lab_air

DROP

lab_air

DROP

ROLE

prac

DROP

INDEX

projekty

id_start

DROP

TABLE

projekty