Modelowanie danych , projektowanie systemu informatycznego

Wykład IV
Modelowanie danych , projektowanie systemu informatycznego
Modelowanie – odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie
informatycznym.
Modele
- konceptualne
reprezentacja obiektów w uniwersalnym modelu niezależnym od modelu
implementacyjnego
• model związków – encji ( diagramy ER )
• model UML
- implementacyjne
• modele wykorzystywane do implementacji modeli konceptualnych
• modele danych ( relacyjne, obiektowe, itp. )
Obiekty świata rzeczywistego – materialne i niematerialne
• materialne – pracownik, samochód, budynek, towar, mieszkanie
• niematerialne – konto bankowe, zamówienie, polisa ubezpieczeniowa
• zdarzenia – choroba pracownika, urlop, przyznanie nagrody
• fakty – znajomość języka obcego, stan magazynowy towaru
•
•
•
•
Modelowanie pojęciowe na encjach ( założenia:)
świat składa się z obiektów – encji
ęncje można pogrupować w typy
każda encja ma własność służącą do jej identyfikacji
encje są między sobą powiązane
1
Wykład IV
Encja (ang. entity ) - reprezentuje zbiór obiektów w modelowanym fragmencie rzeczywistości, które
posiadają te same cechy i są na tyle istotne, by trwale przechowywać o nich informacje.
Cechy encji:
•
•
•
•
•
każda encja posiada własności zwane też atrybutami
każda encja posiada unikalny identyfikator
konkretny obiekt świata rzeczywistego jest reprezentowany jako wystąpienie encji
( instancja encji )
każda encja ma unikalną nazwę ( podawana w liczbie pojedynczej np. STUDENT )
dowolny obiekt jest reprezentowany wyłącznie przez jedną encję
Zapis własności encji
Związki
określają zbiór asocjacji pomiędzy instancjami encji ( powiązania pomiędzy obiektami
świata rzeczywistego ).
Encje objęte danym związkiem są uczestnikami tego związku. Liczba uczestników w związku jest
nazwana jego stopniem.
Typy związków:
• unarne, binarne, ternarne
• obligatoryjne lub opcjonalne
• jeden do jeden, jeden do wiele, wiele do wiele
związki unarne
wiążą instancję z instancją tej samej encji ( najczęściej reprezentują rekurencyjne
powiązanie hierarchiczne) dla związków unarnych należy określić rolę jaką gra każda instancja
encji w związku.
2
Wykład IV
związki binarne
wiążą instancje dwóch encji ( najczęściej spotykane )
związki ternarne
wiążą instancje trzech encji
Typ asocjacji
określa liczbę instancji związku, w których może brać udział instancja encji
asocjacja 1 : 1
każda instancja bierze udział w co najwyżej jednej instancji związku
asocjacja 1 : N
instancja jednej encji bierze udział w co najwyżej jednej instancji związku, instancja drugiej
w dowolnej liczbie instancji związku
asocjacja N : M
instancje obu encji biorą udział w dowolnej liczbie instancji związku
Opcjonalna przynależność do związku
mogą istnieć instancje encji nie biorące udziału w żadnej instancji związku
Obligatoryjna przynależność do związku
wszystkie instancje encji muszą brać udział w instancji związku
Zapis związków
3
Wykład IV
Projektowanie systemu informatycznego
Projekt fizyczny bazy danych
jest realizowany przez informatyków na podstawie specyfikacji wymagań i modelu
logicznego. Powiązany ze ściśle określonym Systemem Zarządzania Bazą Danych. Określa
struktury logiczne i fizyczne.
Efektem projektu fizycznego będą skrypty zawierające definicje:
•
•
•
•
•
tabel
ograniczeń integralnościowych
parametrów fizycznych bazy danych
dodatkowych obiektów ( perspektywy, indeksy, sekwencje itp. )
użytkowników i ich uprawnień
Dla relacyjnych baz danych narzędziem fizycznej realizacji będzie część SQL'a nazwana DDL
( ang. Data Definition Language )
zawierająca niezbędne polecenia do:
tworzenia CREATE . . .,
usuwania DROP . . .
i modyfikacji ALTER . . . struktur danych.
4
Wykład IV
CREATE TABLE [<schemat>.]< nazwa_tabeli >
( <własności_relacyjne >)
[<własności_fizyczne>]
[<własności_tabeli>] ;
Definicja kolumn – własności relacyjnych tabeli
CREATE TABLE [<schemat>.]< nazwa_tabeli >
( <nazwa_kolumny1> <typ> [ ( rozmiar )]
[ DEFAULT < wyrażenie > ]
[ < więzy_kolumny1> ]
[, <nazwa_kolumny2 > . . . ]
[, <więzy_tabeli>]
);
Własności fizyczne tabeli
CREATE TABLE < nazwa_tabeli >
( <własności_relacyjne > )
[ { < atrybuty_segmentu > [ < kompresja > ]
| ORGANIZATION { < typ_organizacji_segmentu > }
| CLUSTER < nazwa > ( < nazwa_kolumny1 [ , < kolumna2 ] . . . ) } ] ;
przykłady:
CREATE TABLE Tymczasem
( Kol1 NUMBER,
Kol2 VARCHAR2(30) );
CREATE TABLE Mieszkancy
( Pesel NUMBER(11) NOT NULL,
Nazwisko VARCHAR2(30),
Imiona VARCHAR2(30),
Data_zameldowania DATE DEFAULT Current_date ) ;
CREATE TABLE Demo
( Id NUMBER( 10 ) )
TABLESPACE przykład
STORAGE ( INITIAL 6144 );
CREATE TABLE Dzialy
( Id NUMBER( 2 ) PRIMARY KEY ,
Nazwa VARCHAR2( 50 ) ,
Lokalizacja VARCHAR2( 20 )
)
ORGANIZATION INDEX
PCTHRESHOLD 30
OVERFLOW TABLESPACE Nadmiar ;
5
Wykład IV
CREATE TABLE Klienci
( Id NUMBER( 6 ) ,
Nazwisko VARCHAR2( 50 ) ,
Imiona VARCHAR2( 30 ) ,
Kraj VARCHAR2( 30 ) ,
Email VARCHAR2( 25 )
)
PARTITION BY LIST ( Kraj )
(
PARTITION Azja VALUES ( 'CHINY' , ' TAJLANDIA') ,
PARTITION Europa VALUES ( 'NIEMCY' , 'WŁOCHY' ) ,
PARTITION Ameryka VALUES ( 'USA' , 'KANADA' ),
PARTITION Reszta VALUES ( DEFAULT )
);
CREATE TABLE Pracownicy_archiwum AS
SELECT * FROM Pracownicy WHERE Id_zesp = 20 ;
Definiowanie ograniczeń ( więzów spójności )
sposoby :
• dla kolumny – definiowane „inline” lub „out_of_line” (za wyjątkiem NOT NULL )
• dla tabeli – definiowane „out_of_line”
• tworzone w poleceniu modyfikacji struktury tabeli – wyłącznie „out_of_line”
• każde ograniczenie jest nazwane przez użytkownika lub przez system
Definicja ograniczeń „inline”
CREATE TABLE < nazwa_tabeli >
( < nazwa_kolumny1 > < typ> [ ( rozmiar) ]
[ DEFAULT < wyrażenie >]
[ [ CONSTRAINT < nazwa_ogr_kolumny > ] {
[ NOT ] NULL
| UNIQUE
| PRIMARY KEY
| REFERENCES < nazwa_tabeli > (< nazwa_kolumny1>[ ,< nazwa_kolumny2 > ] . . . )
[ ON DELETE { CASCADE | SET NULL } ]
| CHECK ( <warunek_logiczny >) } [DISABLE | ENABLE ] ], . . ) ;
przykłady:
CREATE TABLE Stanowiska
( Stanowisko VARCHAR2(15) constraint pk_stanowiska PRIMARY KEY,
Placa_min NUMBER(7,1) constraint war1 CHECK ( Placa_min > 1500),
Placa_max NUMBER(7,1) NOT NULL,
constraint war CHECK (Placa_max >= Placa_min)) ;
CREATE TABLE Kursy
( Kod NUMBER(3) constraint p_kod PRIMARY KEY,
Nazwa VARCHAR2(30) NOT NULL,
Koszt NUMBER( 7,1) constraint c_koszt CHECK ( Koszt > 0 ));
6
Wykład IV
CREATE TABLE Pracownicy_kursy
( Numer NUMBER(4) constraint fk_numer REFERENCES Pracownicy,
Kod NUMBER(3) constraint fk_kod REFERENCES Kursy,
constraint pk_pk PRIMARY KEY (Numer, Kod));
DROP TABLE [< schemat>.]<nazwa_tabeli >
[ CASCADE CONSTRAINTS ] [ PURGE ] ;
Polecenie powyższe
• usuwa definicję tabeli i dane z tabeli oraz wyzwalacze, indeksy związane z tabelą
• zwalnia fizyczny segment i jego rozszerzenia
• ustawia atrybut niepoprawności dla powiązanych perspektyw, synonimów, procedur itp.
ALTER TABLE . . .
Dodanie kolumn ; ALTER TABLE < nazwa_tabeli > ADD
( < nazwa_kol1 >< typ> [ DEFAULT < wyrażenie > ] [< więzy_kol1>]
[, < nazwa_kol2 > <typ> [ DEFAULT < wyrażenie > ] [< więzy_kol2>] . . . ) ;
Modyfikacja kolumn; ALTER TABLE < nazwa_tabeli > MODIFY
( < nazwa_kol1 > <typ> [ DEFAULT < wyrażenie > ] [< więzy_kol1>]
[, < nazwa_kol2 > <typ>[ DEFAULT < wyrażenie > ] [< więzy_kol2>] . . . ) ;
Usunięcie kolumn; ALTER TABLE < nazwa_tabeli > DROP
COLUMN < nazwa_kol1 > | ( < nazwa_kol1 > [, < nazwa_kol2 > ] . . . ) ;
Zmiana nazwy kolumny; ALTER TABLE < nazwa_tabeli > RENAME
COLUMN < stara_nazwa_kol > TO < nowa_nazwa_kol > ;
przykłady:
ALTER TABLE Dzialy DROP COLUMN
Lokalizacja;
ALTER TABLE Kursy ADD
( Data_rozpoczecia DATE,
Data_zakonczenia DATE ) ;
ALTER TABLE Stanowiska MODIFY
( Stanowisko VARCHAR2(40)) ;
7
Wykład IV
Modyfikacja ograniczeń
ALTER TABLE < nazwa_tabeli >
{ ADD CONSTRAINT < nazwa_ograniczenia >
| PRIMARY KEY
| UNIQUE (< nazwa_kol1> ) [, UNIQUE ( <nazwa_kol2 > ]
| MODIFY CONSTRAINT < nazwa_ograniczenia >
| PRIMARY KEY
| UNIQUE (< nazwa_kol1> ) [, UNIQUE ( <nazwa_kol2 > ]
| RENAME CONSTRAINT < stara_nazwa > TO < nowa_nazwa >
| DROP { PRIMARY KEY | UNIQUE ( < nazwa_kol1 > [, < nazwa_kol2] . . . )
[ CASCADE ] [KEEP | DROP INDEX ] | CONSTRAINT < nazwa_ograniczenia >
[ CASCADE ] }
| ENABLE | DISABLE { PRIMARY KEY | CONSTRAINT < nazwa_ograniczenia > } } ;
przykłady:
ALTER TABLE Mieszkancy ADD
CONSTRAINT Nr_dok UNIQUE ( Nr_dokumentu ) ;
ALTER TABLE Rachunki
ENABLE PRIMARY KEY ;
Perspektywa ( WIDOK ) - wirtualna tabela
Intuicyjnie, perspektywa jest pewnego rodzaju „ oknem „, przez które użytkownik bazy danych
widzi udostępniane przez nią dane.
•
•
•
•
perspektywa bazuje na tabelach, na innych perspektywach lub tabelach i perspektywach
z użytkowego punktu widzenia, perspektywa posiada taką samą strukturę jak tabela
na poziomie fizycznym różni się od tabeli tym, że nie posiada własnych danych
w słowniku bazy danych (metadane ) perspektywa jest przechowywana w postaci zapytania
ją definiującego
Cele stosowania perspektyw
•
•
•
•
•
ograniczenie i autoryzacja dostępu do danych
ułatwienie pracy z danymi
możliwość prezentowania tych samych danych w różny sposób
zapewnienie logicznej niezależności danych poprzez odseparowanie aplikacji od schematu
konceptualnego bazy danych
możliwość wprowadzenia dodatkowego poziomu ograniczeń integralnościowych
( klauzula WITH CHECK OPTION )
CREATE [ OR REPLACE ] VIEW < nazwa > [ ( <lista_kolumn > ) ]
AS SELECT . . . [{ WITH READ ONLY | WITH CHECK OPTION }] ;
8
Wykład IV
•
•
•
wyrażenia nie będące kolumnami, z klauzuli SELECT podzapytania, muszą być zaopatrzone
w aliasy lub perspektywa musi przewidzieć nowe nazewnictwo wszystkich kolumn wyniku
podzapytania
istnieje możliwość modyfikacji danych za pośrednictwem pod warunkiem, że polecenie
będzie dla systemu jednoznaczne ( uniemożliwiają to grupowanie, funkcje, złączenia,
podzapytania, porządkowanie, DISTINCT, wyrażenia złożone, brak klucza głównego, brak
uprawnień, ograniczenie WITH READ ONLY)
opcja WITH CHECK OPTION – umożliwia sprawdzenie, czy modyfikowane za
pośrednictwem perspektywy dane spełniają warunki logiczne zawarte wewnątrz
podzapytania perspektywy
przykłady:
CREATE OR REPLACE VIEW Zespoly_pracownicze ( nazwa, liczba_prac )
AS
SELECT nazwa, count(nr_akt) FROM Pracownicy RIGHT JOIN Dzialy USING (id_dzialu)
GROUP BY nazwa;
CREATE OR REPLACE VIEW Szefowie ( nazwisko, stanowisko, staz )
AS
SELECT nazwisko, stanowisko, trunc(months_between(sysdate, data_zatr)/12)
FROM Pracownicy WHERE nr_akt IN
( SELECT DISTINCT kierownik FROM Pracownicy );
CREATE OR REPLACE VIEW Wynagrodzenia
AS
SELECT p.nr_akt, p.nazwisko, p.stanowisko, p.placa FROM Pracownicy p
WHERE p.placa < ( SELECT placa FROM Pracownicy WHERE nr_akt = p.kierownik )
WITH CHECK OPTION constraint za_wysokie_wynagrodzenie ;
CREATE OR REPLACE VIEW Studentki
AS
SELECT nr_albumu, nazwisko, imiona,rok, rodzaj_studiow FROM Studenci
WHERE imiona LIKE '%A' AND rok IS NOT NULL
ORDER BY nazwisko ;
SELECT * FROM Szefowie WHERE staz >= 20 AND stanowisko = 'DYREKTOR'
SELECT * FROM Studentki WHERE rok= 2 AND rodzaj_studiow =' INŻ_ST';
Dodatkowe polecenia języka SQL dotyczące perspektyw:
DESCRIBE < nazwa_perspektywy >
DROP VIEW <nazwa_perspektywy > ;
UPDATE Wynagrodzenia SET placa= 5500 WHERE nazwisko='MALIK';
SQL Error: ORA-01402: naruszenie klauzuli WHERE dla perspektywy z WITH CHECK OPTION
01402. 00000 - "view WITH CHECK OPTION where-clause violation"
9
Wykład IV
INSERT INTO Szefowie VALUES ('OLEJNIK','RADCA',null);
SQL Error: ORA-01733: w tym miejscu kolumna wirtualna nie jest dozwolona
01733. 00000 - "virtual column not allowed here"
Metadane ( perspektywy słownikowe ) - informacje na temat struktury bazy danych, zawartych
w niej obiektów, kontach użytkowników, uprawnieniach, itp.
Przedrostki perspektyw słownika danych:
USER_ – obiekty posiadane przez użytkownika,
ALL_ – obiekty, do których użytkownik ma dostęp,
DBA_ – obiekty całej bazy danych
Wybrane perspektywy słownika dla:
•
•
•
•
•
•
•
•
tabel: %_TABLES
ograniczeń: %_CONSTRAINTS
kolumn z ograniczeniami: %_CONS_COLUMNS
perspektyw: %_VIEWS
aktualizacji perspektyw: %_UPDATABLE_COLUMNS
indeksów: %_INDEXES
sekwencji: %_SEQUENCES
obiektów: %_OBJECTS
przykłady:
SELECT table_name,constraint_name, constraint_type,column_name
FROM USER_CONSTRAINTS NATURAL JOIN USER_CONS_COLUMNS;
SELECT * FROM USER_UPDATABLE_COLUMNS;
SELECT Object_name, Object_type, Created, Status FROM USER_OBJECTS;
Wykorzystano
Wykłady dr inż. Olga Siedlecka-Lamch - Bazy danych z roku 2012
http://wazniak.mimuw.edu.pl/images/c/c7/BD-2st-1.2-w03.tresc-1.1.pdf
10