SQL - Wprowadzenie - Założenie relacyjnego modelu baz danych

 Założenia relacyjnego modelu baz danych

W 1970 roku doktor E.F. Codd opublikował pracę zatytułowaną "A Relational Model of Data for Large Shared Data Banks", w której proponował prezentowanie danych w postaci zestawu tabel. Zamiast wskaźników używanych do poruszania się między powiązanymi encjami, nadmiarowe dane mają być używane do łączenia rekordów w różnych tabelach. 

W modelu relacyjnym dane są prezentowane przez zbiory krotek (pól tabel), do których dostęp zapewniają operatory algebry relacji, takie jak selekcja, projekcja czy suma.

Każda tabela w relacyjnej bazie danych zawiera informacje unikatowo identyfikujące rekord w danej tabeli (tzw. klucz podstawowy) oraz informacje dodatkowe niezbędne do pełnego opisania encji. 

Każdy serwer bazy danych dostarcza mechanizm pozwalający na generowanie unikatowych zbiorów liczb używanych jako wartości klucza podstawowego. Dlatego nie trzeba zajmować się sprawdzaniem, jaki liczby zostały przypisane jako klucze podstawowe. 

E.F. Codd określił 12 podstawowych zasad, które musiał spełniać system, by mógł zarządzać relacyjnym modelem danych. 

Postulaty dotyczące struktury danych

Spełnienie postulatów dotyczących struktur danych pozwala w ten sam sposób, niezależnie od wykorzystywanego serwera bazodanowego, zarządzać przechowywanymi w bazie informacjami. Do tych postulatów należą:

• Postulat informacyjny - Informacje są reprezentowane w postaci logicznych tabel. Oznacza to, że fizyczny sposób organizacji i przechowywania danych przez serwer bazodanowy nie może mieć wpływu na działanie programów klienckich.
• Postulat dostępu - Każda informacja musi być dostępna za pomocą nazwy tabeli, kolumny i wartości klucza podstawowego. Innymi słowy, znajomość struktury tabeli i wartości identyfikatorów musi wystarczyć do odczytania dowolnej informacji z bazy.
• Postulat fizycznej niezależności danych - Sposób przechowywania danych i wewnętrzne mechanizmy dostępu do nich przez serwer nie mogą mieć wpływu na aplikacje klienckie. Na przykład to, czy dane są przechowywane w jednym pliku, czy w wielu plikach, dla programów klienckich musi być całkowicie niewidoczne.
• Postulat logicznej niezależności danych - Zmiany w strukturze bazy danych, np. zmiana definicji tabeli, o ile tylko nie powodują utraty informacji i są poprawne semantycznie, nie mogą mieć wpływu na aplikację kliencką.
• Postulat niezależności dystrybucyjnej - Odwołania do danych za pomocą języka SQL muszą być niezależne od fizycznej lokalizacji danych. Innymi słowy, aplikacje klienckie powinny mieć taki sam dostęp do danych znajdujących się  na lokalnym dysku twardym jak do danych rozproszonych pomiędzy różne lokalizacje.
• Postulat zabezpieczenia przed modyfikacjami przeprowadzanymi za pomocą języków proceduralnych - Jeśli serwer bazodanowy umożliwia bezpośrednie modyfikowanie poszczególnych rekordów za pomocą języków niższego poziomu, zmiany te nie mogą naruszać spójności danych, w szczególności nie mogą być sprzeczne z nałożonymi na tabele ograniczeniami.

Postulaty dotyczące przetwarzania danych

Relacyjny model danych został stworzony z myślą o wydajnym i łatwym modyfikowaniu zapisanych w bazach informacji. Te zmiany muszą być przeprowadzane z uwzględnieniem poniższych postulatów:

• Postulat pełnego języka danych - Serwer baz danych musi implementować jeden język pozwalający definiować tabele, widoki i ograniczenia (więzy spójności), zarządzać dostępem użytkowników i transakcjami oraz odczytywać i modyfikować dane.
• Postulat modyfikowania bazy danych przez widoki - Zmiany danych przeprowadzane poprzez widoki muszą być odzwierciedlane w odpowiednich tabelach, a bezpośrednie zmiany danych w tabelach muszą być automatycznie widoczne poprzez widoki.
• Postulat modyfikowania danych na wysokim poziomie abstrakcji - Odczytanie, zmodyfikowanie, wstawienie lub usunięcie danych musi być możliwe za pomocą pojedynczej operacji. 

Postulaty dotyczące integralności danych

Przestrzeganie postulatów dotyczących integralności danych gwarantuje zachowanie logicznej spójności przechowywanych w bazie informacji:

• Postulat wartości NULL - Serwer bazodanowy w spójny sposób przetwarza specjalną wartość NULL, jak brakującą informację. a nie jak zero czy pusty ciąg znaków ("").
• Postulat słownika danych - Metadane (informacje o strukturze bazy danych) są przechowywane i udostępniane tak samo (w postaci tabel) jak zapisane w bazie informacje.
• Postulat niezależności ograniczeń - Ograniczenia (więzy spójności) muszą być definiowane w tym samym języku SQL i przechowywane po stronie bazy danych, a więc nie jest obowiązkowe implementowanie ich po stronie aplikacji klienckiej. Serwer baz danych musi umożliwić zdefiniowanie przynajmniej dwóch typów ograniczeń:
• ograniczenia klucza podstawowego, które gwarantują spójność w ramach tabel.
• ograniczenia klucza obcego, które gwarantują spójność danych zapisanych w powiązanych tabelach.

SQL - Wprowadzenie - Modele baz danych

Modele baz danych

Wyróżniamy trzy modele baz danych: relacyjny, obiektowy i jednorodny.

Model jednorodny

W tym modelu wszystkie dane są przechowywane w jednym arkuszu, tabeli lub pliku (stąd nazwa modelu).

Zaletą tego modelu jest łatwość i szybkość odczytywania interesujących nas danych. (w tym przypadku wystarczy tylko znaleźć rekord opisujący np. szukany zakup, żeby poznać wszystkie szczegóły danej operacji).

Wadą modelu jednorodnego jest duża liczba duplikatów (powtarzających się danych). Wielokrotne zapisywanie tych samych danych nie tylko zajmuje więcej miejsca da dysku i w pamięci, lecz także:

• Utrudnia modyfikowanie danych. Gdyby na przykład firma zmieniła adres lub numer telefonu, musielibyśmy je zmieniać w wielu różnych rekordach. Gdybyśmy przeoczyli jeden z nich, dane byłyby niespójne, tj. odczytując dwa razy tę samą informację (adres lub telefon) moglibyśmy otrzymać różne wyniki.
• Większe ryzyko wpisania błędnych danych. Podając po raz kolejny nazwę tej samej firmy, możemy przypadkowo dodać spację, zmienić wielkość liter czy w inny sposób pomylić się przy jej wpisywaniu. W rezultacie w bazie zostaną zapisane różne nazwy i gdybyśmy chcieli w przyszłości np. podsumować zakupy u poszczególnych dostawców, otrzymane wyniki byłyby nieprawdziwe.

Model relacyjny

W modelu relacyjnym dane są przechowywane w wielu odrębnych, ale powiązanych ze sobą tabelach. W jednej tabeli powinno się zapisywać dane o obiektach jednego typu, np. wyłącznie informacje o produktach czy klientach. Te łączące tabele powiązania nazywa się relacjami (stąd nazwa modelu).

Zaletą modelu relacyjnego jest zapobieganie tworzeniu duplikatów danych - dane np. o poszczególnych sprzedawcach i nazwach towarów są zapisane tylko raz. Nie tylko zmniejsza to ilość przechowywanych w bazie informacji, lecz także ułatwia ich modyfikowanie i wstawianie.

Wadą modelu relacyjnego jest jego skomplikowanie i wolne odczytywanie z niego danych. W dodatku dane odczytane z jednej tabeli należy właściwie połączyć z danymi odczytanymi z pozostałych tabel.

Żeby relacje były jednoznaczne, połączone z nimi tabele muszą mieć klucze podstawowe, a zapisane w nich identyfikatory muszą być powtórzone w każdej z połączonych z nią tabel. Kolumna, która zawiera identyfikator rekordu innej tabeli, nazywa się kluczem obcym.

Charakterystyczną cechą modelu relacyjnego jest prostota struktur danych (poszczególne tabele przechowują informacje o bardzo uproszczonych obiektach).

W praktyce relacyjne bazy danych składają się z wielu powiązanych ze sobą relacjami tabel. Informacje na temat tego,jak tabele są ze sobą powiązane, są prezentowane w postaci diagramów E/R (diagramów Encja/Relacja).

Relacyjną bazę danych można porównać do magazynu z meblami, w którym każda cześć mebla jest umieszczana w osobnym, przeznaczonym wyłącznie dla nich kontenerach (ich odpowiednikami w SQL są tabele). Umieszczając meble w takim magazynie, rozbieramy je na części i osobno układamy drzwi, półki i tak dalej. Taki sposób przechowywania jest bardzo wydajny, ale wyjmując mebel z magazynu, każdorazowo musimy złożyć go w jedną całość.

Model obiektowy

W opracowanym w latach 90. XX wieku modelu obiektowym informacje są przechowywane w bazie nie w postaci rekordów, ale całych obiektów. Tak zapisane dane są dostępne za pośrednictwem metod tych obiektów, np. obiekt Produkt może mieć metodę pozwalającą odczytać nazwę tego produktu i inną metodę zwracającą dane producenta tego produktu.  

Model obiektowy przypomina magazyn, w którym meble są ustawiane bez rozbierania na części. W rezultacie korzystanie z magazynu jest prostsze, za to liczba mebli, jaką można zmieścić na tej samej powierzchni, jest znacznie mniejsza.

Model obiektowy jest bardzo popularny wśród programistów takich języków programowania, jak C# czy Java, zakłada że wszystko jest obiektem o nieznanej nam wewnętrznej budowie. Owa wewnętrzna budowa z reguły nas jednak nie interesuje, za to musimy wiedzieć jak używać tych obiektów.

Zaletą modelu obiektowego jest zgodność z obowiązującym paradygmatem programowania. W tym przypadku programiści nie natrafiają na problemy takie jak:

• niezgodność składni - składnia języka SQL jest zupełnie inna niż składnia takich języków, jak C, Java czy Visual Basic.
• niezgodność typów - większość języków programowania, w przeciwieństwie do języka SQL, ma wbudowaną statyczną kontrolę typów, a w prawie żadnym z niech nie występuje podstawowy dla języka SQL typ "relacja".
•  niezgodność użycia - w języku SQL programista określa wynik, ja chce otrzymać, a nie sposób w jaki ma on być osiągnięty. Ponadto SQL jest językiem interpretowanym, a nie kompilowanym.

SQL - Dodatki - Słowa kluczowe języka SQL

Słowa kluczowe języka SQL

SQL jest językiem opartym na słowach kluczowych. (Słowo kluczowe jest specjalnym słowem używanym w trakcie wykonywania zapytania). Słowa te są zarezerwowane prze język SQL, więc nie należy ich zatem używać jako nazw baz danych, tabel, kolumn ani innych obiektów baz danych. 

W tym dodatku wymieniam listę najczęściej stosowanych słów kluczowych w najpopularniejszych systemach zarządzania bazami danych. 

Należy jednak pamiętać że słowa kluczowe są ściśle uzależnione od systemu zarządzania bazą danych i nie wszystkie wymienione słowa kluczowe muszą występować w każdym systemie. 

Aby zapewnić zgodność kodu z różnymi systemami zarządzania bazą danych i jego przenośność, warto unikać wszystkich zarezerwowanych słów kluczowych, nawet tych, które nie są zarezerwowane w używanym przez nas systemie. 

ABORT                                                                    

ABSOLUTE

ACTION

ACTIVW

ADD

AFTER

ALL

ALLOCATE

ALTER

ANALYZE

AND

ANY

ARE

AS

ASC

ASCENDING

ASSERTION

AT

AUTHORIZATION

AUTO

AUTO-INCREMENT

AVG

BACKUP

BEFORE

BEGIN

BETWEEN

BIGINT

BINARY

BIT

BOOLEAN

BOTH

BREAK

BROWSE

BY

BYTES

CACHE

CALL

CASCADE

CASCADED

CASE

CAST

CATALOG

CHANGE

CHAR

CHARACTER

CHECK

CHECKPOINT

CLOSE

CLUSTER

CLUSTERED

COALESCE

COLLATE

COLUMN

COLUMNS

COMMENT

COMMIT

COMMITED

COMPUTE

COMPUTED

CONDITIONAL

CONFIRM

CONNECT

CONNECTION

CONSTRAINT

CONSTRAINTS

CONTAINING

CONTAINS

CONTINUE

CONTROLROW

CONVERT

COPY

COUNT

CREATE

CROSS

CSTRING

CUBE

CURRENT

CURRENT_DATE

CURRENT_TIME

CURRENT_TIMESTAMP

CURRENT_USER

DATABASE

DATABASES

DATE

DATETIME

DAY

DEALLOCATE

DEBUG

DEC

DECIMAL

DECLARE

DEFAULT

DELETE

DENY

DESC

DESCENDING

DESCRIBE

DISCONNECT

DISK

DISTINCT

DISTRIBUTED

DIV

DO DOMAIN

DOUBLE

DROP

DUMMY

DUMP

ELSE

ELSEIF

ENCLOSED

END

ERROREXIT

ESCAPE

ESCAPED

EXCEPT

EXCEPTION

EXEC

EXECUTE

EXISTS

EXIT

EXPLAIN

EXTEND

EXTERNAL

EXTRACT

FALSE

FETCH

FIELD

FIELDS

FILE

FILTER

FLOAT

FLOPPY

FOR

FORCE

FOREIGN

FOUND

FREETEXT

FREETEZTTABLE

FROM

FULL

FUNCTION

GENERATOR

GET

GLOBAL

GO

GOTO

GRANT

GROUP

HAVING

HOUR

INDENTITY

IF

IN

INACTIVE

INDEX

INDICATOR

INFILE

INNER

INOUT

INPUT

INSERT

INT

INTEGER

INTERSECT

INTERVAL

INTO

IS

ISOLATION

JOIN

KEY

KILL

LANGUAGE

LAST

LEADING

LEFT

LENGTH

LEVEL

LIKE

LIMIT

LINES

LOAD

LOCAL

LOCK

LOGFILE

LONG

LOWER

MANUAL

MATCH

MAX

MERGE

MERGE

MESSAGE

MIN

MINUTE

MODULE

MONEY

MONTH

MOVE

NAMES

NATIONAL

NATURAL

NCHAR

NEW

NEXT

NO

NOCHECK

NONCLUSTERED

NONE

NOT

NULL

NULLIF

NUMERIC

OF

OFF

OFFSET

OFFSETS

ON

ONCE

ONLY

OPEN

OPTION

OR

ORDER

OUTER

OUTPUT

OVER

OVERFLOW

OVERLAPS

PAD

PAGE

PAGES

PARAMETER

PARTIAL

PASSWORD

PERCENT

PERM

PERMANENT

PIPE

PLAN

POSITION

PRECISION

PREPARE

PRIMERY

PRINT

PRIOR

PRIVILEGES

PROCEDURE

PROTECTED

PUBLIC

PURGE

READ

READTEXT

REAL

REFERANCES

REGEXP

RELATIVE

RENAME

REPEAT

REPLACE

RESERV

RESET

RESTORE

RESTRICT

RETAIN

RETURN

REVOKE

RIGHT

ROLLBACK

ROLLUP

ROWCOUNT

RULE

SAVE

SAVEPOINT

SCHEMA

SECOND

SECTION

SEGMENT

SELECT

SENSITIVE

SEPARATOR

SEQUENCE

SRT

SETUSER

SHADOW

SHARED

SHOW

SHUTDOWN

SINGULAR

SIZE

SMALLINT

SNAPSHOT

SOME

SORT

SPACE

SQL

SQLCODE

SQLERROR

STABILITY

STARTING

STARTS

STATISTICD

SUBSTRING

SUM

SUSPEND

TABLE

TABLES

TEMP

TEMPORARY

TEXT

TEXTSIZE

THEN

TIME

TIMESTAMP

TO

TOP

TRAN

TRANSACTION

TRANSLATE

TRIGGER

TRIM

TRUE

TRUNCATE

TYPE

UNCOMMITTED

UNION

UNIQUE

UNTIL

UPDATE

UPPER

USAGE

USE

USER

USING

VALUE

VALUES

VARCHAR

VARIABLE

VARYING

VIEW

VOLUME

WAIT

WHEN

WHERE

WHILE

WITH

WORK

WRITE

XOR

YEAR

ZONE