Krótki opis projektowania baz danych z użyciem programu Data
Transkrypt
Krótki opis projektowania baz danych z użyciem programu Data
Tworzenie modelu logicznego i fizycznego danych. W celu stworzenia modelu danych wykorzystamy program Data Architect wchodzący w skład pakietu narzędzi CASE Power Designer, który pozwala utworzyć tzw. logiczny (konceptualny model danych) (CDM), fizyczny model danych (PDM) oraz wygenerować skrypt SQL tworzący bazę danych. Tworzenie modelu logicznego. Na wstępie określa się zbiory encji oraz ich atrybuty (wraz z określeniem typu danych, wymagalności, ograniczeń) i klucze główne. Pomiędzy tak zdefiniowanymi zbiorami encji kreśli się relacje o określonych własnościach. Wszystko to odbywa się w trybie graficznym. Rysunek 1 przedstawia symbole wykorzystywane na schematach modeli CDM (prostokąty odpowiadają encjom, związki są prezentowane za pomocą linii łączących odpowiednie encje). Rys.1. Symbole związków stosowane w modelu logicznym (CDM): jeden do jednego (wymagany z jednej strony), jeden do wielu (nie wymagany z żadnej strony),wiele do jednego (wymagany z jednej strony), wiele do wielu (nie wymagany). Rysunek 2 przedstawia przykładowy model logiczny bazy danych do rejestracji danych klientów i pracowników, z wyszczególnieniem atrybutów poszczególnych encji (wraz z ich dziedzinami), kluczy głównych (podkreślone atrybuty) oraz związków pomiędzy encjami. klient status data_rejestracji punkty VA10 D I zawiera osoba nr_osoby I imię VA10 nazwisko VA30 adres VA40 szkolenie nr_szkolenia I nazwa VA30 data_od D data_do D odbywane przez zawarta przez umowa nr_umowy data_umowy przedmiot_umowy opłata sporządzona przez sporządza pracownik pesel data_zatrudnienia zarobki etat posiada posiada A11 D DC6,2 DC3,2 pracuje w zatrudnia dział ozn_działu A3 nazwa VA30 wprowadza dotyczy wprowadzona przez historia_zmian_zarobków data_zmiany D poprzednie_zarobki DC6,2 kwota_zmiany DC6,2 Rys. .2 Schemat przykładowego modelu logicznego utworzony za pomocą programu Data Architect z pakietu Power Designer. Encja OSOBA posiada dwa podtypy – KLIENT oraz PRACOWNIK. Oznacza to, że dana osoba może być klientem lub pracownikiem. Związki tego typu określa się mianem dziedziczenia. W powyższym przykładzie osoba może być jednocześnie pracownikiem i klientem, natomiast rysunek 3 przedstawia dziedziczenie, w którym osoba może być albo pracownikiem, albo klientem, tzn. oba te podtypy się wzajemnie wykluczają. klient status data_rejestracji punkty VA10 D I osoba nr_osoby imię nazwisko adres I VA10 VA30 VA40 pracownik pesel data_zatrudnienia zarobki etat A11 D DC6,2 DC3,2 Rys. 3. Przykład dziedziczenia. I D VA40 DC5,2 Tworzenie modelu fizycznego. Model logiczny jest podstawą do wygenerowania tzw. fizycznego modelu danych (PDM) - Rys.4. Model ten uwzględnia konkretny system baz danych. W tym przypadku – Interbase 4.x. KLIENT NR_KLIENTA IMIE NAZWISKO ADRES STATUS DATA_REJESTRACJI PUNKTY UMOWA INTEGER VARCHAR(10) VARCHAR(30) VARCHAR(40) VARCHAR(10) DATE INTEGER NR_KLIENTA=NR_KLIENTA NR_UMOWY DATA_UMOWY PRZEDMIOT_UMOWY OPLATA NR_KLIENTA NR_PRAC INTEGER DATE VARCHAR(40) NUMERIC(5,2) INTEGER INTEGER PRACOWNIK SZKOLENIA_PRAC NR_SZKOLENIA NR_PRAC INTEGER INTEGER NR_PRAC=NR_PRAC NR_PRAC IMIE NAZWISKO ADRES PESEL DATA_ZATRUDNIENIA ZAROBKI ETAT OZN_DZIALU INTEGER VARCHAR(10) VARCHAR(30) VARCHAR(40) CHAR(11) DATE NUMERIC(6,2) NUMERIC(3,2) CHAR(3) NR_PRAC=NR_PRAC DZIAL OZN_DZIALU=OZN_DZIALU OZN_DZIALU CHAR(3) NAZWA VARCHAR(30) NR_SZKOLENIA=NR_SZKOLENIA NR_PRAC=NR_PRAC SZKOLENIE NR_SZKOLENIA NAZWA DATA_OD DATA_DO INTEGER VARCHAR(30) DATE DATE KTO_ZMIENIL=NR_PRAC HISTORIA_ZMIAN_ZAROBKOW NR_PRAC DATA_ZMIANY POPRZEDNIE_ZAROBKI KWOTA_ZMIANY KTO_ZMIENIL INTEGER DATE NUMERIC(6,2) NUMERIC(6,2) INTEGER Rys. 4. Przykładowy fizyczny model danych (PDM). W modelu fizycznym tabele zostały uzupełnione o kolumny kluczy obcych – na podstawie odpowiednich związków istniejących pomiędzy encjami w modelu fizycznym. Istnienie związku wiele do wielu pomiędzy encjami PRACOWNIK oraz SZKOLENIE spowodowało powstanie dodatkowej tabeli SZKOLENIA_PRAC. Tworzenie skryptu SQL Na podstawie modelu fizycznego można wygenerować, w postaci pliku tekstowego, skrypt SQL opisujący schemat bazy danych (poniżej). /* ============================================================ */ /* Database name: MODEL_1 */ /* DBMS name: InterBase 4.0 */ /* Created on: 2008-02-15 07:16 */ /* ============================================================ */ /* ============================================================ */ /* Table: KLIENT */ /* ============================================================ */ create table KLIENT ( NR_KLIENTA INTEGER not null, IMIE VARCHAR(10) , NAZWISKO VARCHAR(30) , ADRES VARCHAR(40) , STATUS VARCHAR(10) , DATA_REJESTRACJI DATE , PUNKTY INTEGER , constraint PK_KLIENT primary key (NR_KLIENTA) ); /* ============================================================ */ /* Table: SZKOLENIE */ /* ============================================================ */ create table SZKOLENIE ( NR_SZKOLENIA INTEGER not null, NAZWA VARCHAR(30) , DATA_OD DATE , DATA_DO DATE , constraint PK_SZKOLENIE primary key (NR_SZKOLENIA) ); /* ============================================================ */ /* Table: DZIAL */ /* ============================================================ */ create table DZIAL ( OZN_DZIALU CHAR(3) not null, NAZWA VARCHAR(30) , constraint PK_DZIAL primary key (OZN_DZIALU) ); /* ============================================================ */ /* Table: PRACOWNIK */ /* ============================================================ */ create table PRACOWNIK ( NR_PRAC INTEGER not null, IMIE VARCHAR(10) , NAZWISKO VARCHAR(30) , ADRES VARCHAR(40) , PESEL CHAR(11) , DATA_ZATRUDNIENIA DATE , ZAROBKI DECIMAL(6,2) , ETAT DECIMAL(3,2) , OZN_DZIALU CHAR(3) not null, constraint PK_PRACOWNIK primary key (NR_PRAC) ); /* ============================================================ */ /* Table: UMOWA */ /* ============================================================ */ create table UMOWA ( NR_UMOWY INTEGER not null, DATA_UMOWY DATE , PRZEDMIOT_UMOWY VARCHAR(40) , OPLATA DECIMAL(5,2) , NR_KLIENTA INTEGER not null, NR_PRAC INTEGER not null, constraint PK_UMOWA primary key (NR_UMOWY) ); /* ============================================================ */ /* Table: HISTORIA_ZMIAN_ZAROBKOW */ /* ============================================================ */ create table HISTORIA_ZMIAN_ZAROBKOW ( NR_PRAC INTEGER not null, DATA_ZMIANY DATE not null, POPRZEDNIE_ZAROBKI DECIMAL(6,2) , KWOTA_ZMIANY DECIMAL(6,2) , KTO_ZMIENIL INTEGER , constraint PK_HISTORIA_ZMIAN_ZAROBKOW primary key (NR_PRAC, DATA_ZMIANY) ); /* ============================================================ */ /* Table: SZKOLENIA_PRAC */ /* ============================================================ */ create table SZKOLENIA_PRAC ( NR_SZKOLENIA INTEGER not null, NR_PRAC INTEGER not null, constraint PK_SZKOLENIA_PRAC primary key (NR_SZKOLENIA, NR_PRAC) ); alter table PRACOWNIK add constraint FK_PRAC_DZIAL foreign key (OZN_DZIALU) references DZIAL; alter table UMOWA add constraint FK_UMOWA_KLIENT foreign key (NR_KLIENTA) references KLIENT; alter table UMOWA add constraint FK_UMOWA_PRAC foreign key (NR_PRAC) references PRACOWNIK; alter table HISTORIA_ZMIAN_ZAROBKOW add constraint FK_HISTORIA_ZMIANY_PRAC foreign key (NR_PRAC) references PRACOWNIK; alter table HISTORIA_ZMIAN_ZAROBKOW add constraint FK_HISTORIA_KTO_ZMIEN foreign key (KTO_ZMIENIL) references PRACOWNIK(NR_PRAC); alter table SZKOLENIA_PRAC add constraint FK_ODBYWANE_SZKOL foreign key (NR_SZKOLENIA) references SZKOLENIE; alter table SZKOLENIA_PRAC add constraint FK_SZKOL_PRAC foreign key (NR_PRAC) references PRACOWNIK;