Projektowanie systemów informacyjnych
|
|
- Kinga Skrzypczak
- 8 lat temu
- Przeglądów:
Transkrypt
1 Projektowanie systemów informacyjnych Wykład 15 i 16: Od modelu obiektowego do relacyjnej bazy danych Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 1 Dlaczego obiektowość zastępuje model relacyjny? Chodzi o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości, a myśleniem o danych i procesach, które zachodzą na danych Percepcja świata Model pojęciowy Model struktur danych W modelu relacyjnym odwzorowanie percepcji świata jest ograniczone środkami implementacyjnymi. W rezultacie, schemat relacyjny gubi część semantyki danych. Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata rzeczywistego. Dłogofalową tendencją w rozwoju SZBD jest uzyskanie zgodności pomiędzy tymi modelami. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 2
2 Zalety baz danych Bazy danych mają bezwględną przewagę nad konstruowaniem aplikacji przy pomocy języków obiektowych takich jak C++ i Java. Uzyskanie niżej wymienionych własności w tych językach bez wspomagania ze strony SZBD może okazać się nieosiagalne nawet dla bardzo wydajnych i doswiadczonych zespołów programistycznych. Wysoka niezawodność, efektywność i stabilność Bezpieczeństwo i prywatność danych, spójność i integralność przetwarzania Automatyczne sprawadzanie warunków integralności danych Wielodostęp, przetwarzanie transakcji Rozszerzalność (zarówno dodawanie danych jak i dodawanie ich rodzajów) Możliwość geograficznego rozproszenia danych Dostęp poprzez języki zapytań (SQL, OQL) Zintegrowanie z dużą liczbą narzędzi i udogodnień K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 3 Obiektowość kontra model relacyjny Model relacyjny przegrał konfrontację z obiektowością w strefie intelektualnej; trwał w tej strefie tylko lat. Nie istnieje użytkowa własność systemów relacyjnych, która nie mogłaby być zrealizowana w systemach obiektowych. Powstało szereg systemów relacyjnych, dojrzałych technicznie i użytecznych, ale posiadających zasadnicze odstępstwa od założeń modelu relacyjnego. Teorie matematyczne związane z modelem relacyjnym są nieadekwatne do praktyki. Zalety wynikające z matematyzacji dziedziny baz danych okazały się iluzją (nie pierwszą tego typu w informatyce) SQL ma zalety, ale jest językiem tworzonym ad hoc, niesystematycznym, nieregularnym, nieortogonalnym, bez istotnego podkładu teoretycznego. Nowy standard SQL3 jest ogromny, eklektyczny, z dość przypadkowymi pomysłami. Tworzone są ideologie i systemy eklektyczne, obiektowo-relacyjne. Nieregularne, trudne do standardyzacji, dekadenckie. Generowana jest mnogości mitów i fałszywych stereotypów dotyczacych zalet modelu relacyjnego. Twórcy systemów relacyjnych wzmacniają ich interfejsy o pojęcia obiektowe, oraz umożliwiają obiektowe perspektywy relacyjnych struktur danych. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 4
3 Garby modelu relacyjnego (1) Z góry ustalony konstruktor typu danych (relacja), rozszerzany ad hoc przez wytwórców systemów relacyjnych; brak złożonych obiektów. Informacje o pojęciach wyróżnialnych i manipulowalnych w rzeczywistości są rozproszone w krotkach wielu tablic. Skojarzenie tych informacji następuje w zapytaniach SQL, przez co wzrasta ich złożoność oraz czas wykonania. Optymalizacja zapytań nie zawsze jest skuteczna. Brak wyspecjalizowanych środków do realizacji powiązań pomiędzy danymi. Brak środków do przechowywania danych proceduralnych. Wszelkie informacje wykraczające poza strukturę relacyjną (perspektywy, procedury bazy danych, BLOBy, aktywne reguły,...) są implementowane ad hoc. Brak środków hermetyzacji i modularyzacji: wykroczenie przeciwko zasadom abstrakcji i oddzielenia implementacji od specyfikacji. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 5 Garby modelu relacyjnego (2) Brak uniwersalności środków dostępu do danych, powodujący konieczność zanurzenia ich w uniwersalne języki programowania niższego poziomu; (niezgodność impedancji, impedance mismatch). Niespełnione obietnice co do przetwarzania makroskopowego. Ubogie możliwości relacyjnych struktur danych powodują znaczne zwiększenie długości kodu aplikacji. Połączenie SQL z językiem programowania wymaga również dodatkowego kodu (szacuje się na 30%). Łącznie kod aplikacji (w porównaniu do systemów obiektowych) może zawierać nawet 70% nadmiarowego kodu. Brak możliwości rozszerzania typów, ignorowanie zasad bezpieczeństwa typologicznego. Niespójne mechanizmy wartości zerowych, brak wariantów. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 6
4 Czy model relacyjny był pomyłką ludzkości? Poglądy są podzielone. Na korzyść tej tezy przemawia fakt, że podstawowym założeniem było wykorzystanie matematycznych własności relacji. Od strony systemów komercyjnych, korzyści z matematyki są iluzją. Po co więc ograniczenia struktur danych i interfejsów, rzekomo wymuszone przez matematykę? Relational databases set the commercial data processing industry back at least ten years. (Dr. Henry G. Baker, Comm. ACM 35/4, 1992) Jest to oczywiście twierdzenie niesprawdzalne. Nie wiadomo jak potoczyłaby się dziedzina baz danych, gdyby nie model relacyjny. Podstawowym wkładem modelu relacyjnego była nie matematyka, a założenie o logicznej niezależności danych: uwolnienie programisty od myślenia nad niskim poziomie, w kategoriach fizycznej organizacji danych. Jakkolwiek to założenie pojawiło się w czasach przed modelem relacyjnym, dopiero systemy relacyjne uczyniły go powszechnie obowiązujacym faktem. Tak czy inaczej, pozostaje rzeczywistość, której szybko zmienić się nie da... K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 7 Rzeczywistość... (1) Dla 90% rzeczywistych projektów systemy relacyjne są wystarczające. To powoduje zredukowanie zainteresowania systemami czysto obiektowymi. Łączne światowe inwestycje (komercyjne, akademickie, organizacyjne) w systemy relacyjnych baz danych są szacowane na ponad 100 miliardów dolarów. Jest mało prawdopodobne, że te inwestycje będą w krótkim czasie powtórzone dla modeli i systemów obiektowych baz danych. Nie oznacza to, że nie mają one szans; raczej, że ich rozwój, osiągnięcie dojrzałości i popularności będzie trwać dłużej niż przypuszcza wielu fanów obiektowości. Chyba, że nastąpi skok jakościowy... Nadzieje są związane z systemami obiektowo-relacyjnymi, które wzbogacają systemy relacyjne o pewne cechy obiektowości. Jest to podejście ewolucyjne. Pytanie, czy kiedyś zredukują złożoność odwzorowania modelu pojęciowego na model implementacyjny, pozostaje jednak otwarte. Wiele aplikacji potrzebuje tylko warstwy trwałych danych, która w istocie jest ukryta przed użytkownikiem. Użytkownik dokonuje operacji na danych poprzez pewien z góry ustalony interfejs, który całkowicie izoluje go od struktury BD. Niskie nakłady na pielęgnację (maintenance) oprogramowania jest podstawowym wymaganiem biznesu. Model obiektowy umożliwia zmniejszenie tych nakładów. Przejście na model relacyjny powoduje zwiększenie kosztów pielęgnacji kodu. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 8
5 Rzeczywistość... (2) Zdania SQL wkodowane do aplikacji obiektowej i operujące bezpośrednio na nazwach relacji i atrybutów są w wielu przypadkach niekorzystne, gdyż zmniejszają możliwości ponownego użycia oraz zmiany schematu. Znacznie lepszym rozwiązaniem jest dynamiczny SQL, który odwołuje się do informacji znajdującej się w katalogach. (Jest on jednak nieco wolniejszy.) Automatyczne generatory interfejsów w SQL (takie jak TopLink) mogą okazać się zbyt wolne. Wiele aplikacji obiektowych musi przystosować się do danych spadkowych (legacy data), z reguły relacyjnych. Nie powinno to jednak oznaczać, że (świadomego lub podświadomego) przykrojenia projektu obiektowego do zastanych danych. Raczej, trzeba przeprowadzić reinżynierię w celu stwierdzenia, z jakim modelem obiektowym mamy do czynienia w spadkowej bazie danych. Powszechną pomyłką jest kojarzenie z obiektowymi bazami danych interfejsów bazujących na SQL takich jak ODBC i JDBC. Jakkolwiek posiadają one cechy obiektowości (klasy), są to cechy interfejsów użytkownika, a nie wspomaganie odwzorowania modelu obiektowego na schemat relacyjny. Java + relacyjna baza danych + JDBC nie tworzy obiektowej bazy danych! K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 9 Rzeczywistość... (3) Złączenia (joins) są wolne. Mimo sprawnych metod, takich jak hash join, sort&merge join, optymalizacji zapytań, itd, złączenia powodują poważny narzut na wydajność. Należy ich unikać, np. poprzez denormalizację lub wykorzystanie dodatkowej wiedzy semantycznej. Klucze tablic nie powinny mieć znaczenia w dziedzinie przedmiotowej (co jest w poprzek głównej doktrynie modelu relacyjnego). Nawet trywialne zmiany w dziedzinie biznesu mogą podważyć dokonany wcześniej wybór klucza. Klucze tablic nie powinny być złożone; powinny być jednym atrybutem (co podważa sens dziesiątków prac teoretycznych). Praktyka pokazała, że złożone klucze (poza relacjami modelującymi związki) są powodem poważnych trudności wielu projektów. (Ale istnieją też poglądy odwrotne.) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 10
6 Konieczność odwzorowania modelu obiektowego na relacyjny Sprzymierzeńcem wszystkich wdrożonych technologii baz danych, w tym relacyjnych, jest ogromna bezwładność rynku zastosowań, który niechętnie zmienia swoje preferencje ze względu na zainwestowane duże pieniądze i czas. Klient baz danych nie tylko nie lubi kosztownych zmian; musi mieć także pewność, że nie pozostanie sam w swojej dziedzinie działalności lub rejonie geograficznym i może liczyć na zarówno środowisko specjalistów jak i ogólną kulturę techniczną wytworzoną w związku z daną technologią. Systemy relacyjne opanowały dużą grupę nisz ekologicznych i można przyjąć jako pewnik, że pozostaną w nich przez kilka, kilkanaście, lub nawet kilkadziesiąt lat. Systemy obiektowe muszą poszukiwać innych nisz, które nie są zagospodarowane przez wcześniejsze technologie. Natomiast w dziedzinie projektowania baz danych odwrót od modelu relacyjnego nastąpił bardzo szybko (Chen, 1976, model encja-związek). Obecnie nie istnieje metoda projektowania nie oparta w jakiś sposób o pojęcia obiektowe. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 11 Podejścia do integracji projektu obiektowego z systemami relacyjnymi System relacyjny jako back-end, tj. baza implementacyjna. Na czubku systemu relacyjnego budowany jest front-end, tj. zestaw interfejsów do zarządzania złożonymi obiektami, klasami, dziedziczeniem, itd. Podejście mające sporo opracowań oraz zaimplementowany co najmniej jeden prototyp (Starburst). Wady: Podejście wymaga budowy nowego systemu; narzuty relacyjnego back-end na czasy wykonania mogą być istotne i trudne do wyeliminowania. Obiektowe perspektywy nad strukturą relacyjną - możliwość na razie w strefie akademickiej z kilku powodów (aktualizacja perspektyw, wydajność,...). Odwzorowanie obiektowego projektu na struktury relacyjne. Podejście tradycyjne (znane z modelu encja-związek). Wady: niemożliwość odwzorowania wszystkich detali schematu obiektowego, zniekształcenie semantyki danych, konieczność wprowadzania sztucznych cech do schematu (niektórych atrybutów, itd.). Problemem może być konieczność kompromisu pomiędzy zajętością pamięci a czasami dostępu (normalizacjadenormalizacja). K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 12
7 Zalecana infrastruktura projektów obiektowych Graficzny interfejs użytkownika (GUI) Warstwa programów aplikacyjnych C++, Smaltalk, Java Warstwa obiektów biznesowych Warstwa odwzorowania obiektów na relacje SQL System zarządzania relacyjną bazą danych Relacyjna baza danych Ścisłe przestrzeganie warstwowości tej architektury ma istotne znaczenie dla pielęgnacyjności oprogramowania. Nieco trudne jest zbudowanie uniwersalnego interfejsu pomiędzy obiektami biznesowymi i relacjami. Zbudowanie tej infrastruktury może być bardzo korzystne dla firmy realizującej wiele projektów obiektowych. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 13 Obiektowo-relacyjne bazy danych Ostatnio karierę robi termin uniwersalny serwer (universal server), dający możliwość zastosowania systemu do przechowywania i przetwarzania obiektów, relacji, danych multimedialnych, itd. Podstawą ideologiczną systemów obiektoworelacyjnych jest zachowanie sprawdzonych technologii relacyjnych (np. SQL) i wprowadzanie na ich wierzchołku innych własności, w tym obiektowych. Systemy te powstają w wyniku ostrożnej ewolucji systemów relacyjnych w kierunku obiektowości. Liczą na pozycję systemów relacyjnych na rynku i odwołują się do ich wiernej klienteli. Kluczowymi produktami tej technologii są systemy: Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne. Systemy te są wyposażane w atrakcyjne cechy umożliwiające efektywną produkcję aplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiekty BLOB, CLOB i pliki binarne), dane przestrzenne (spatial), abstrakcyjne typy danych (ADT), metody (funkcje i procedury) definiowane przez użytkownika w różnych językach (C, C++, VisualBasic, Java), kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Stosunek tej technologii do projektów czysto obiektowych nie jest do końca jasny.wydaje się, że mimo postępu, w większości implikują one problemy z odwzorowaniem modelu obiektowego. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 14
8 Projektowanie logiczne Tradycyjny termin (nie mający związku z logiką matematyczną) oznaczający odwzorowanie modelu pojęciowego (np. encja-związek lub obiektowego) na model lub wyrażenia języka opisu danych konkretnego SZBD. Podstawowe problemy przy przechodzeniu na schemat logiczny: Nie ma możliwości przechowywania wielu wartości jednego atrybutu Każda tablica musi byc wyposażona w unikalny klucz Powiązania muszą być zaimplementowane jako tablice/relacje z kluczami obcymi Nie można zagnieżdżać danych Występują ograniczenia na rozmiar krotek, wartości elementarne i typy danych Brak dziedziczenia i wielodziedziczenia Brak wariantów (natomiast są wartości zerowe) Konieczność istnienia klucza (wartości identyfikującej krotkę) w każdej tablicy. Dodatkowo należy uwzględnić: Cechy ilościowe (charakterystyka ilościowa danych i funkcji) Unikanie redundancji w danych (normalizacja 2NF, 3NF, BCNF). Wymagania użytkowe: czas odpowiedzi, utylizacja pamięci (denormalizacja) Przejście na schemat logiczny nie może być całkowicie automatyczne. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 15 Proces projektowania logicznego Charakterystyka ilościowa danych Schemat pojęciowy Opis docelowego modelu BD Wymagania użytkowe Schemat pojęciowy Charakterystyka ilościowa danych PROJEKTOWANIE LOGICZNE wysokiego poziomu NIEZALEŻNE OD TYPU BD PROJEKTOWANIE LOGICZNE Opis docelowego modelu BD Wymagania użytkowe PROJEKTOWANIE LOGICZNE ZALEŻNE OD TYPU BD Schemat logiczny dla docelowego modelu BD Schemat logiczny dla docelowego modelu BD K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 16
9 Sprowadzenie do pierwszej formy normalnej - odwzorowanie powtarzalnych atrybutów Tablice relacyjne nie mogą przechowywać wielokrotnych wartości atrybutów. Model obiektowy (np. w UML) umożliwia zadeklarowanie takich atrybutów. Jest regułą, że takie atrybuty należy odwzorować jako odrębne tablice. Pojawią się także nowe atrybuty. Pierwsza sytuacja: wartości powtarzalne nie mogą być identyczne. Id Zawód[0..*] Id Wyszkolenie Id Zawód Druga sytuacja: wartości powtarzalne mogą być identyczne. Ten przypadek umożliwia rownież odwzorowanie sytuacji gdy porządek wielokrotnych wartości jest istotny, poprzez wybór dodatkowego klucza (takiego jak NrWypłaty), który ustali ten porządek. Id Wypłata[0..*] Id Zarobki Id NrWypłaty Wypłata K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 17 Sprowadzenie do pierwszej formy normalnej - odwzorowanie związków/asocjacji Dla liczności 1:1 można zaimplementować jako jedną tablicę: Państwo Nazwa Stolica Miasto Państwo Nazwa Stolica Dla liczności 1:n można zaimplementować jako dwie tablice: (Atrybuty związku na ogół powodują konieczność zastosowania następnej metody.) IdPrac PracujeW Firma IdFirmy Nazwa IdPrac IdFirmy Firma IdFirmy Nazwa Dla liczności m:n należy zaimplementować jako trzy tablice: IdPrac PracujeW Firma IdFirmy Nazwa IdPrac PracFirma IdPrac IdFirmy Firma IdFirmy Nazwa K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 18
10 Odwzorowanie złożonych obiektów Podstawowymi metodami jest spłaszczenie ich struktury (zamiana atrybutów złożonych na proste), usunięcie powtarzalnych atrybutów oraz różne formy normalizacji (2NF, 3NF, 4NF, BCNF). Po tych zabiegach złożony obiekt jest reprezentowany jako zestaw krotek, często w wielu tablicach. Informacja o złożonym obiekcie jest utrzymywana w strukturze relacyjnej w postaci tzw. integralności referencyjnej (referential integrity). Polega ona na tym, że dla każdego klucza obcego (foreign) musi istnieć krotka posiadająca taki sam klucz główny (primary). Nie wszystkie systemy relacyjne podtrzymują systemowo integralność referencyjną. Integralność referencyjna nie jest w stanie odwzorować całej semantyki złożonych obiektów. Np. zgubiona jest informacja, co jest korzeniem obiektu, zgubione są reguły hermetyzacji obiektu, zgubiona jest semantyka operacji na obiektach, np. semantyka usuwania. Istnieją propozycje wprowadzenia dodatkowej informacji do struktury tablic umożliwiających przechowanie pełnej semantyki złożonych obiektów. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 19 Odwzorowanie metod/operacji Model relacyjny nie przewiduje specjalnych środków. Najczęściej są one odwzorowane na poziomie programów aplikacyjnych jako procedury napisane w w klasycznych lub obiektowych językach programowania i dedykowane do obsługi pewnej tablicy/tablic w relacyjnej bazie danych. Niekiedy w systemach relacyjnych mogą być odwzorowane w postaci procedur baz danych (w SQL) lub w postaci aktywnych reguł. Odwzorowanie polimorfizmu, przesłaniania, dynamicznego wiązania i hermetyzacji jest w zasadzie niemożliwe. Programista może napisać procedurę, która w środku ma przełączenie explicite na różne przypadki specjalizacji klas. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 20
11 Trzy metody obejścia braku dziedziczenia Użycie jednej tablicy dla całego drzewka klas poprzez zsumowanie wszystkich występujących atrybutów i powiązań w tym drzewie oraz ewentualnie dodanie dodatkowego atrybutu - dyskryminatora wariantu. B A C A B C dyskr Użycie tablic dla każdej klasy konkretnej. Usunięcie klas abstrakcyjnych i przesunięcie ich atrybutów/powiązań do klas konkretnych. B A C A B A C Użycie tablicy dla każdej klasy. Zamiana generalizacji na powiązania łączące nadklasę ze wszystkimi podklasami. B A C B A C K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 21 Przykład obejścia braku dziedziczenia PIT pojedyncz podatnika Adres PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony PIT pojedyncz podatnika Adres Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok dodatkowe pole PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok Adres Adres męża Adres żony Rodzaj PIT PIT Id_pitu Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedyncz podatnika Id_pitu Adres PIT małżeństwa Id_pitu Adres męża Adres żony K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 22
12 Zalety i wady metod obejścia braku dziedziczenia Cecha Jedna tablica dla hierarchii Tablica dla klasy konkretnej Tablica dla każdej klasy Łatwość implementacji Prosta Średnia Trudna Łatwość dostępu do danych Prosta Prosta Średnia Łatwość przypisania OID Prosta Średnia Średnia Związanie informacji Bardzo duże Duże Małe Szybkość dostępu Bardzo szybki Szybki Wolny Wspomaganie dla polimorfizmu Słabe Średnie Duże Konsumpcja pamięci Duża Mała Mała K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 23 Prowadzenie słownika danych Jest konieczne dla przechowania informacji o sposobie odwzorowania modelu obiektowego na strukturę relacyjną. Co powinien zawierać wiersz takiego słownika? Nazwę odwzorowywanej klasy Nazwę odwzorowanego atrybutu tej klasy Nazwę kolumny, w którą taki atrybut jest odwzorowany Nazwę tablicy, która zawiera tę kolumnę. Niekiedy potrzebna jest także następująca informacja: Nazwę bazy danych, w którą odwzorowany jest dany fragment modelu Wskazanie, czy dany atrybut jest używany jako klucz główny Wskazanie, czy dany atrybut jest używany jako klucz obcy K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 24
13 Obejście braku wielodziedziczenia Jest często konieczne, ale psuje strukturę logiczną modelu i komplikuje pielęgnację oprogramowania. Może odbyć się na poziomie modelu obiektowego. Można też bezpośrednio zastosować metody zaproponowane dla obejścia braku dziedziczenia. Przykład: status płacowy Specjalizacje klasy zależą od aspektu stosunek do emerytury godzinowy etatowy na zlecenie nie emerytowany emerytowany godzinowy nie emerytowany Specjalizacje wg płac Specjalizacje wg emerytury K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 25 Jak obejść brak wielo-dziedziczenia: delegacja z użyciem ról Płace pracownika status płacowy Emerytura pracownika stosunek do emerytury godzinowy etatowy na zlecenie nie emerytowany emerytowany Płace pracownika Specjalizacje wg płac Emerytura pracownika Specjalizacje wg emerytury K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 26
14 Dziedziczenie Jak obejść brak wielo-dziedziczenia: użycie dziedziczenia i delegacji status płacowy Emerytura pracownika Delegacja stosunek do emerytury godzinowy etatowy na zlecenie nie emerytowany emerytowany Emerytura pracownika Specjalizacje wg płac Specjalizacje wg emerytury K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 27 Jak obejść brak wielo-dziedziczenia: zagnieżdżona generalizacja Permutacja klas klas status płacowy godzinowy stosunek do emerytury etatowy stosunek do emerytury na zlecenie stosunek do emerytury godzinowy nie emerytowany godzinowy emerytowany etatowy nie emerytowany etatowy emerytowany na zlecenie nie emerytowany na zlecenie emerytowany K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 28
15 Brak wielo-dziedziczenia - zalecenia Jeżeli klasa ma kilka super-klas, wszystkie jednakowo ważne, najlepiej użyć delegacji, która zachowuje symetrię modelu. Jeżeli jedna super-klasa wyraźnie dominuje, zaś inne są mniej ważne, tę jedną zaimplementować poprzez dziedziczenie, zaś pozostałe przez delegację. Jeżeli liczba kombinacji klas jest mała, można rozpatrywać zagnieżdżoną generalizację. Jeżeli jedna superklasa ma zdecydowanie więcej cech niż pozostałe lub może powodować wąskie gardło w wydajności, wyróżnić tę superklasę poprzez dziedziczenie. Przy zagnieżdżonej generalizacji, najważniejszy czynnik powinien być pierwszym kryterium podziału; pozostałe dalej, w hierarchii ważności. Unikać zagnieżdżonych generalizacji, jeżeli duża ilość kodu musi być powtórzona. Te zalecenia mogą okazać się nieistotne o ile zdecydujemy się bezpośrednio obejść brak wielodziedziczenia metodami takimi samymi jak dla obejścia dziedziczenia. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 29 Normalizacja - 2NF, 3NF, BCNF,... Polega na zdekomponowaniu tablic na dwie lub więcej celem uniknięcia niekorzystnych własności: redundancji w danych oraz zwiazanych z redundancją anomalii aktualizacyjnych. Zależność funkcyjna (functional dependency) pomiędzy atrybutami: wartość atrybutu A2 zależy od wartości atrybutu A1, jeżeli dla każdego wyobrażalnego stanu bazy danych, dla każdej wartości atrybutu A2 można przyporządkować dokładnie jedna wartość atrybutu A1; A2 = f(a1) Każdy atrybut jest funkcyjnie zależny od klucza. Druga forma normalna (2NF): nie ma atrybutów, które zależą funkcyjnie od części klucza. Trzecia forma normalna (3NF): nie ma zależności funkcyjnych tranzytywnych, tj.nie ma różnych atrybutów A1, A2, A3 takich, że A3 = f(a2) i A2 = f(a1). BCNF - każdy determinant (argument funkcji) jest kluczem kandydującym. Mocniejszy warunek od 3NF, nie zawsze realizowalny. Inne formy normalne - znaczenie marginalne. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 30
16 Krytyka normalizacji Temat jest zdecydowanie przegrzany przez teoretyków baz danych (niewspółmierna złożoność teorii w stosunku do użyteczności). Głównym jej zastosowaniem jest zamulanie podręczników dla studentów. Praktyczna przydatność normalizacji jest znikoma. Dlaczego? Wbrew wczesnym opiniom, teoria normalizacji nie może być samodzielną metodą projektowania, ponieważ przykrywa nikłą część aspektów projektu. Może być niekiedy przydatna jako pomocnicze narzędzie do jego walidacji. Zależności funkcyjne są bardzo mętną (nieczytelną) formą wyrażania semantyki danych. Muszą one być zadane a priori przez projektantów, co często jest równie trudne jak przerobienie całego modelu od podstaw. Jako skutek, metodyki oparte na modelu encja-związek i metodyki obiektowe w naturalny sposób prowadzą do znormalizowanych schematów. Podejście top-down oraz tendencja do dekompozycji/separowania pojęć również w naturalny sposób prowadzą do znormalizowanych schematów. Czynniki inne niż zależności funkcyjne mogą okazać się bardziej istotne (wydajność --> denormalizacja). K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 31 Denormalizacja Odwrotność normalizacji: połączenie dwóch lub więcej tablic relacyjnych w jedną. Denormalizacja jest konsekwencją dwóch problemów: - niskiej efektywności operacji złączenia - zbytniego skomplikowania struktury relacyjnej bazy danych utrudniajacej pielęgnację oprogramowania. Z reguły, denormalizacja polega na wykonaniu zewnętrznego złączenia (outer join) dwóch lub więcej tablic: Pracownicy IdPrac Kowalski Malinowski Nowak Grot Leski PrzynależnośćDoZZ IdPrac ZwiązekZaw Solidarność OPZZ Solidarność Pracownicy IdPrac Kowalski Malinowski Nowak Grot Leski ZwiązekZaw NULL Solidarność Solidarność OPZZ NULL K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 32
17 Analiza wartości zerowych Analiza ta, podobnie do zależności funkcjonalnych, może nam przynieść informację o konieczności zdekomponowania tablicy na dwie lub więcej. IdPrac Panieńskie[0..1] GrupaKrwi[0..1] DataBadaniaGrKrwi[0..1] } Zapełnione w 25% przypadków Zapełnione w 10% przypadków To rozwiązanie implikuje, że ok. połowy BD będzie zapełnione wartościami zerowymi. IdPrac Mężatka IdPrac Panieńskie BadanieKrwi IdPrac GrupaKrwi DataBadaniaGrKrwi K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 33 Brak wartości zerowych, objętość danych zmniejszyła się o 40%. Wydajność może być gorsza ze względu na złączenia lub lepsza ze względu na zmianę charakterystyki buforowania krotek. Analiza długich/złożonych wartości Podobnie do wartości zerowych i zależności funkcyjnych, analiza długich wartości może być również podstawą zdekomponowania tablicy na dwie lub więcej. Te same metody mogą dotyczyć złożonych atrybutów. IdPrac: char[5] : char[20] ZwiązekZawodowy: char[100] Załóżmy, że w zakładzie pracy działa 10 związków zawodowych, zaś pracowników jest Łatwo policzyć, że rozmiar tablicy będzie znaków. Dodatkowo, występuje możliwość drobnych i grubych błędów w pisowni nazwy związku. IdPrac: char[5] : char[20] IdZZ: char[5] ZwiązekZawodowy IdZZ: char[5] Nazwa: char[100] Po tym zabiegu rozmiar bazy danych zredukował się 4-krotnie. Jak poprzednio, wydajność może być gorsza ze względu na złączenia lub lepsza ze względu na zmianę charakterystyki buforowania krotek. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 34
18 Podział poziomy klasy Na podstawie przewidywanych charakterystyk ilościowych przetwarzania. Klasa 1 Klasa 1 As1 As11 As12 Klasa 2 a1 a2 m1 m2 Klasa 21 a1 a2...? m1 m2...? Klasa 22 a1...? a2 m1...? m2 As2 As21 As22 Klasa 3 Klasa 3 Niekiedy przy takim podziale w niektórych klasach można zredukować atrybuty i/lub metody. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 35 Podział pionowy klasy Na podstawie przewidywanych charakterystyk ilościowych przetwarzania oraz przewidywanej pielęgnacyjności kodu aplikacji. Klasa 1 As1 Klasa 1 Klasa 2 a1 a2 a3 a4 m1 m2 m3 m4 As11? Klasa 2 a1 a2 m1 m2 As21? As12? Klasa 2 a3 a4 m3 m4 As22? As2 Klasa 3 Klasa 3 K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 36
19 Klucze kandydujące Dla każdej klasy trzeba rozpatrzyć atrybut (lub ich kombinację), które mogą być kluczem. Jeżeli takich atrybutów nie ma, wówczas należy powołać klucz sztuczny (generowany automatycznie OID). Migracja kluczy : kluczem kandydującym klasy lub związku może być także kombinacja atrybutów innych klas lub związków, które przeciąga się poprzez związki asocjacji. Dla Dla asocjacji: Kombinacja kluczy klas klas obiektów. Osoba PosiadaAkcje Osoba PracujeW Kraj Stolica Firma Klucz kandydujący: (Osoba + Firma) Firma Klucz kandydujący: (Osoba) Miasto Klucze kandydujące: (Kraj) lub (Miasto) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 37 Wybór klucza Może być wiele kluczy kandydujących ale tylko jeden klucz główny Kryteria wyboru klucza głównego: LICZBA OPERACJI, korzystających z danej klasy, odwołujących się bezpośrednio poprzez dany klucz TYP KLUCZA * klucze proste przed złożonymi * klucze wewnętrzne przed zewnętrznymi * klucze krótsze przed dłuższymi Data_ur Nr_PESEL Nr_prac Nr_na_wydziale Data_ur Nr_PESEL Nr_prac Wydział Id_wydziału 4 Nr_na_wydziale K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 38
20 Wybór klucza obiektu - zalecenia Klucz nie powinien mieć znaczenia w dziedzinie przedmiotowej. Istnieje sporo przykładów wskazujących na to, że (poza nielicznymi przypadkami, np. PESEL) klucz mający znaczenie semantyczne powoduje niekorzystne efekty. Np. jeżeli kluczem jest nr telefonu osoby, wówczas funkcjonowanie systemu jest uzależnione od przypadkowych zmian tych numerów jak również zmian przypisania numerów do osób. Podobnie np. dla kombinacji, Imię, RokUrodzenia, ImięOjca. W większości, klucz powinien być generowany automatycznie. Problemem może okazać się dostęp do danej przechowującej ostatnio nadany klucz. Staje się ona wąskim gardłem dla transakcji, gdyż transakcja tworząca nowy obiekt musi zablokować tę daną aż do potwierdzenia. Inne transakcje muszą czekać, aby nie było możliwości dwukrotnego nadania tego samego klucza. Może to powodować nieakceptowalne narzuty na czasy wykonania. Jedno z rozwiązań (S.W.Ambler): klucz mam postać HIGH:LOW. HIGH jest unikalną liczbą, generowaną dla każdej sesji użytkownika na podstawie w/w danej. LOW jest kolejnym numerem obiektu utworzonego wewnątrz tej sesji. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 39 Charakterystyka ilościowa danych INFORMACJE OPISUJĄCE DANE: ZAJĘTOŚĆ PAMIĘCI (liczba wystąpień danych) ZMIENNOŚĆ (spodziewany przyrost w czasie) KLIENT mies. śr.1000 zakupił mies. śr.50 TOWAR mies. Charakterystyki ilościowe pozwalają określić własności fizyczne struktury danych. Istnieje sporo zaleceń i analiz pozwalających wykorzystać te własności. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 40
21 Charakterystyka ilościowa procesów INFORMACJE OPISUJĄCE PROCESY: OPERACJE ELEMENTARNE (FUNKCJE UŻYTKOWE) TYP (on-line, batch) CZĘSTOTLIWOŚĆ ZACHODZENIA (ew. dodatkowo rozkład w czasie) FORMA (ręczna, automatyczna) SPOSÓB WYZWALANIA (warunki - zdarzenia - wyzwalacze) DOSTĘP DO ELEMENTÓW MODELU DANYCH (Tablica krzyżowa, związek ze schematami nawigacji w strukturze danych) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 41 Przejście na model relacyjny - przykłady (1) Klient IdKlienta NazwaKlienta ma InfoDostawy AdresDostawy KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy) Klient IdKlienta NazwaKlienta posiada KartaKredytowa IdKarty TypKarty LimitKarty Klient (Id_Klienta, Nazwa_Klienta) KartaKredytowa (IdKarty, TypKarty, IdKlienta, LimitKarty) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 42 Projektant nie zdecydował się na jedną tablicę, gdyż założył, że będzie zbyt dużo wartości zerowych.
22 Przejście na model relacyjny - przykłady (2) Kobieta IdKobiety Kobiety DataŚlubu Mężczyzna IdMężczyzny Mężczyzny Kobieta( IdKobiety, Kobiety ) Mężczyzna( IdMężczyzny, Mężczyzny ) Ślub( IdKobiety, IdMężczyzny, DataŚlubu ) STUDENT Id_Studenta _Studenta Suma_Pkt_Studenta Ocena_semestr Semestr STUDENT (Id_Studenta, _Studenta, Suma_Pkt_Studenta) KURS (Id_Kursu, Nazwa_Kursu) STUDENT_ZAPISANY_NA_KURSY (Id_Studenta, Id_Kursu, Semestr, Ocena_semestr) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 43 KURS Id_Kursu Nazwa_Kursu Przejście na model relacyjny - przykłady (3) Miasto NazwaMiasta LiczbaMieszkM LeżyW Województwo NazwaWojewództwa Wojewoda LiczbaMieszkW Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM) Województwo(NazwaWojewództwa, Wojewoda, LiczbaMieszkW) ZAMÓWIENIE Id_Zamów Data_Zamów SPRZEDAWCA _S Nr_Tel_S Upust_w_Zamów SPRZEDAWCA(_S, Nr_Tel_S) ZAMÓWIENIE (Id_Zamów, Data_Zamów) NAPISANE_ZAMÓWIENIA (Id_Zamów, _S, Upust_w_Zamów) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 44
23 Przejście na model relacyjny - przykłady (4) jest_przełożonym PRACOWNIK Prac DataUrodzPrac podległość jest_podwładnym M:N PRACOWNIK (Prac, DataUrodzPrac) PODLEGŁOŚĆ (PracPrzełoż, PracPodwład) 1:N PRACOWNIK (Prac, DataUrodzPrac) PODLEGŁOŚĆ(PracPodwład, PracPrzełoż) Różnica w kluczach 1:1 PRACOWNIK (Prac, DataUrodzPrac, PracPrzełoż) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 45 Przejście na model relacyjny - przykłady (5) TOWAR Id_Towaru Nazwa_Towaru KLIENT Id_Klienta Nazwa_Klienta sprzedaż SPRZEDAWCA Id_Sprzedawcy Nazwa_Sprzedawcy Ilość_Towaru Data_Sprzedaży KLIENT (Id_Klienta, Nazwa_Klienta) TOWAR (Id_Towaru, Nazwa_Towaru) SPRZEDAWCA (Id_Sprzedwcy, Nazwa_Sprzedawcy) SPRZEDAŻ (Id_Klienta, Id_Sprzedawcy, Id_Towaru, Data_Sprzedaży, Ilość_Towaru) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 46
24 Przejście na model relacyjny - przykłady (6) Firma Nazwa Miejsce * FZ Zatrudnienie Wypłata * Ocena * PZ Zawód * Osoba Imię * Adres * Firma( NrF, Nazwa) Lokal( NrF, Miejsce) Zatrudnienie( NrF, NrP) ( NrP, NrOs) Oceny( NrOceny, Ocena, NrF, NrP) Dochód( NrDochodu, Wypłata, NrF, NrP) Osoba( NrOs, ) Wyszkolenie( Zawód, NrP) Imiona( NrOs, Imię) Adresy( NrOs, Adres) K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 47 Różnice na poziomie kodu w języku zapytań Zapytanie Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu : OQL: select p.adres from Firma as f, f.fz.pz as p where Radom in f.miejsce SQL: select a.adres from Lokal as k, Zatrudnienie as z, as p, Osoba as s, Adresy as a where k.miejsce = Radom and k.nrf = z.nrf and z.nrp = p.nrp and p.nros = s.nros and s.nros =a.nros Zapytanie w SQL jest znacznie dłuższe od zapytania w OQL głównie wskutek tego, że pojawiły się w nim złączeniowe predykaty (takie jak k.nrf=z.nrf i następne), które kojarzą informację semantyczną zgubioną podczas odwzorowania schematu obiektowego na schemat relacyjny. To skojarzenie, oprócz wymienionej porcji dodatkowego kodu, wymaga od programisty dokładnego rozumienia nieformalnej semantyki schematu. Zminimalizowanie złączeń w SQL jest celem denormalizacji. K.Subieta. Projektowanie systemów informacyjnych, Wykład 15 i 16, Folia 48
Projektowanie baz danych
Projektowanie baz danych Uwagi ogólne Projektowanie baz danych jest częścią tworzenia systemu z bazą danych. Podlega ogólnym zasadom tworzenia projektu. Przed rozpoczęciem projektowania Modelowanie biznesowe
Bardziej szczegółowoProjektowanie baz danych
Projektowanie baz danych Uwagi ogólne Projektowanie baz danych jest częścią tworzenia systemu z bazą danych. Podlega ogólnym zasadom tworzenia projektu. Przed rozpoczęciem projektowania Modelowanie biznesowe
Bardziej szczegółowo1. Mapowanie diagramu klas na model relacyjny.
Rafał Drozd 1. Mapowanie diagramu klas na model relacyjny. 1.1 Asocjacje Wpływ na sposób przedstawienia asocjacji w podejściu relacyjnym ma przede wszystkim jej liczność (jeden-do-jednego, jeden-do-wielu,
Bardziej szczegółowoJak wiernie odzwierciedlić świat i zachować występujące w nim zależności? Jak implementacja fizyczna zmienia model logiczny?
Plan wykładu Spis treści 1 Projektowanie baz danych 1 2 Zależności funkcyjne 1 3 Normalizacja 1NF, 2NF, 3NF, BCNF 4 4 Normalizacja 4NF, 5NF 6 5 Podsumowanie 9 6 Źródła 10 1 Projektowanie baz danych Projektowanie
Bardziej szczegółowo030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła
030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty,
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoProgram wykładu. zastosowanie w aplikacjach i PL/SQL;
Program wykładu 1 Model relacyjny (10 godz.): podstawowe pojęcia, języki zapytań (algebra relacji, relacyjny rachunek krotek, relacyjny rachunek dziedzin), zależności funkcyjne i postaci normalne (BCNF,
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoDefinicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.
TECHNOLOGIE BAZ DANYCH WYKŁAD 1 Wprowadzenie do baz danych. Normalizacja. (Wybrane materiały) Dr inż. E. Busłowska Definicja bazy danych Uporządkowany zbiór informacji, posiadający własną strukturę i wartość.
Bardziej szczegółowoPodstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko
Podstawowe pojęcia dotyczące relacyjnych baz danych mgr inż. Krzysztof Szałajko Czym jest baza danych? Co rozumiemy przez dane? Czym jest system zarządzania bazą danych? 2 / 25 Baza danych Baza danych
Bardziej szczegółowoWykład 2. Relacyjny model danych
Wykład 2 Relacyjny model danych Wymagania stawiane modelowi danych Unikanie nadmiarowości danych (redundancji) jedna informacja powinna być wpisana do bazy danych tylko jeden raz Problem powtarzających
Bardziej szczegółowoBaza danych. Modele danych
Rola baz danych Systemy informatyczne stosowane w obsłudze działalności gospodarczej pełnią funkcję polegającą na gromadzeniu i przetwarzaniu danych. Typowe operacje wykonywane na danych w systemach ewidencyjno-sprawozdawczych
Bardziej szczegółowoPLAN WYKŁADU BAZY DANYCH ZALEŻNOŚCI FUNKCYJNE
PLAN WYKŁADU Zależności funkcyjne Anomalie danych Normalizacja Postacie normalne Zależności niefunkcyjne Zależności złączenia BAZY DANYCH Wykład 5 dr inż. Agnieszka Bołtuć ZALEŻNOŚCI FUNKCYJNE Niech R
Bardziej szczegółowoBazy danych - wykład wstępny
Bazy danych - wykład wstępny Wykład: baza danych, modele, hierarchiczny, sieciowy, relacyjny, obiektowy, schemat logiczny, tabela, kwerenda, SQL, rekord, krotka, pole, atrybut, klucz podstawowy, relacja,
Bardziej szczegółowoWYKŁAD 1. Wprowadzenie do problematyki baz danych
WYKŁAD 1 Wprowadzenie do problematyki baz danych WYKŁAD 2 Relacyjny i obiektowy model danych JĘZYK UML (UNIFIED MODELING LANGUAGE) Zunifikowany język modelowania SAMOCHÓD
Bardziej szczegółowoModel logiczny SZBD. Model fizyczny. Systemy klientserwer. Systemy rozproszone BD. No SQL
Podstawy baz danych: Rysunek 1. Tradycyjne systemy danych 1- Obsługa wejścia 2- Przechowywanie danych 3- Funkcje użytkowe 4- Obsługa wyjścia Ewolucja baz danych: Fragment świata rzeczywistego System przetwarzania
Bardziej szczegółowoPodstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38
Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem zajęcia 1 dr Jakub Boratyński pok. A38 Program zajęć Bazy danych jako podstawowy element systemów informatycznych wykorzystywanych
Bardziej szczegółowoProgramowanie obiektowe - 1.
Programowanie obiektowe - 1 Mariusz.Masewicz@cs.put.poznan.pl Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która
Bardziej szczegółowoBazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000
Bazy Danych LITERATURA C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000 J. D. Ullman, Systemy baz danych, WNT - W-wa, 1998 J. D. Ullman, J. Widom, Podstawowy
Bardziej szczegółowoBazy danych Wykład zerowy. P. F. Góra
Bazy danych Wykład zerowy P. F. Góra http://th-www.if.uj.edu.pl/zfs/gora/ 2012 Patron? Św. Izydor z Sewilli (VI wiek), biskup, patron Internetu (sic!), stworzył pierwszy katalog Copyright c 2011-12 P.
Bardziej szczegółowoNormalizacja relacyjnych baz danych. Sebastian Ernst
Normalizacja relacyjnych baz danych Sebastian Ernst Zależności funkcyjne Zależność funkcyjna pomiędzy zbiorami atrybutów X oraz Y oznacza, że każdemu zestawowi wartości atrybutów X odpowiada dokładnie
Bardziej szczegółowoSystemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi
Systemy baz danych w zarządzaniu przedsiębiorstwem W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Proces zarządzania danymi Zarządzanie danymi obejmuje czynności: gromadzenie
Bardziej szczegółowoJarosław Kuchta Projektowanie Aplikacji Internetowych. Projektowanie warstwy danych
Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie warstwy danych Zagadnienia Sposoby zapisu danych zewnętrznych Odwzorowanie dziedziny problemu w dziedzinę danych Normalizacja relacyjnej
Bardziej szczegółowoBazy Danych. Bazy Danych i SQL Podstawowe informacje o bazach danych. Krzysztof Regulski WIMiIP, KISiM,
Bazy Danych Bazy Danych i SQL Podstawowe informacje o bazach danych Krzysztof Regulski WIMiIP, KISiM, regulski@metal.agh.edu.pl Oczekiwania? 2 3 Bazy danych Jak przechowywać informacje? Jak opisać rzeczywistość?
Bardziej szczegółowo1 Wstęp do modelu relacyjnego
Plan wykładu Model relacyjny Obiekty relacyjne Integralność danych relacyjnych Algebra relacyjna 1 Wstęp do modelu relacyjnego Od tego się zaczęło... E. F. Codd, A Relational Model of Data for Large Shared
Bardziej szczegółowoObiektowość BD Powtórka Czas odpowiedzi. Bazy Danych i Systemy informacyjne Wykład 14. Piotr Syga
Bazy Danych i Systemy informacyjne Wykład 14 Piotr Syga 18.01.2019 Motywacja Ograniczenia relacyjnych baz danych proste typu i struktury klucze (w tym sztuczne) relacje między tabelami uwzględniane w triggerach
Bardziej szczegółowoTechnologia informacyjna
Technologia informacyjna Bazy danych Dr inż. Andrzej Czerepicki Politechnika Warszawska Wydział Transportu 2016 Plan wykładu Wstęp do baz danych Modele baz danych Relacyjne bazy danych Język SQL Rodzaje
Bardziej szczegółowoProgramowanie obiektowe
Programowanie obiektowe Wykład 13 Marcin Młotkowski 27 maja 2015 Plan wykładu Trwałość obiektów 1 Trwałość obiektów 2 Marcin Młotkowski Programowanie obiektowe 2 / 29 Trwałość (persistence) Definicja Cecha
Bardziej szczegółowoTemat : SBQL 1 obiektowy język zapytań.
Laboratorium Języki i środowiska przetwarzania danych rozproszonych Temat : SBQL 1 obiektowy język zapytań. Historia zmian Data Wersja Autor Opis zmian 23.4.2012 1.0 Tomasz Kowalski Utworzenie dokumentu
Bardziej szczegółowoNormalizacja. Pojęcie klucza. Cel normalizacji
Plan Normalizacja Tadeusz Pankowski www.put.poznan.pl/~tadeusz.pankowski 1. Cel normalizacji. 2. Klucze schematów relacyjnych atrybuty kluczowe i niekluczowe. 3. 2PN druga postać normalna. 4. 3PN trzecia
Bardziej szczegółowoModelowanie hierarchicznych struktur w relacyjnych bazach danych
Modelowanie hierarchicznych struktur w relacyjnych bazach danych Wiktor Warmus (wiktorwarmus@gmail.com) Kamil Witecki (kamil@witecki.net.pl) 5 maja 2010 Motywacje Teoria relacyjnych baz danych Do czego
Bardziej szczegółowoDiagramy związków encji. Laboratorium. Akademia Morska w Gdyni
Akademia Morska w Gdyni Gdynia 2004 1. Podstawowe definicje Baza danych to uporządkowany zbiór danych umożliwiający łatwe przeszukiwanie i aktualizację. System zarządzania bazą danych (DBMS) to oprogramowanie
Bardziej szczegółowoPODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"
PODSTAWY BAZ DANYCH 5. Modelowanie danych 1 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań
Bardziej szczegółowoMariusz Trzaska Modelowanie i implementacja systemów informatycznych
Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się
Bardziej szczegółowoNormalizacja baz danych
Wrocławska Wyższa Szkoła Informatyki Stosowanej Normalizacja baz danych Dr hab. inż. Krzysztof Pieczarka Email: krzysztof.pieczarka@gmail.com Normalizacja relacji ma na celu takie jej przekształcenie,
Bardziej szczegółowoS y s t e m y. B a z D a n y c h
S y s t e m y B a z D a n y c h Wykład na przedmiot: Bazy danych Studia zaoczne i podyplomowe UAM Anna Pankowska aniap@amu.edu.pl W y k ł a d I Temat: Relacyjne bazy danych Plan wykładu: - cel stosowania
Bardziej szczegółowoDariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki
Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego
Bardziej szczegółowoCel normalizacji. Tadeusz Pankowski
Plan Normalizacja Tadeusz Pankowski www.put.poznan.pl/~tadeusz.pankowski 1. Cel normalizacji. 2. Klucze schematów relacyjnych atrybuty kluczowe i niekluczowe. 3. 2PN druga postać normalna. 4. 3PN trzecia
Bardziej szczegółowoProjektowanie Systemów Informacyjnych
Projektowanie Systemów Informacyjnych Wykład II Encje, Związki, Diagramy związków encji, Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoInformatyka (10) dr inż. Katarzyna Palikowska Katedra Transportu Szynowego i Mostów p. 4 Hydro
Informatyka (10) dr inż. Katarzyna Palikowska Katedra Transportu Szynowego i Mostów p. 4 Hydro katpalik@pg.gda.pl katarzyna.palikowska@wilis.pg.gda.pl Architektura Klient-Serwer Gruby klient Cienki klient
Bardziej szczegółowoInformatyka I BAZY DANYCH. dr inż. Andrzej Czerepicki. Politechnika Warszawska Wydział Transportu 2017
Informatyka I BAZY DANYCH dr inż. Andrzej Czerepicki Politechnika Warszawska Wydział Transportu 2017 Plan wykładu Definicja systemu baz danych Modele danych Relacyjne bazy danych Język SQL Hurtownie danych
Bardziej szczegółowoBazy danych. Zenon Gniazdowski WWSI, ITE Andrzej Ptasznik WWSI
Bazy danych Zenon Gniazdowski WWSI, ITE Andrzej Ptasznik WWSI Wszechnica Poranna Trzy tematy: 1. Bazy danych - jak je ugryźć? 2. Język SQL podstawy zapytań. 3. Mechanizmy wewnętrzne baz danych czyli co
Bardziej szczegółowoHurtownie danych. 31 stycznia 2017
31 stycznia 2017 Definicja hurtowni danych Hurtownia danych wg Williama Inmona zbiór danych wyróżniający się następującymi cechami uporządkowany tematycznie zintegrowany zawierający wymiar czasowy nieulotny
Bardziej szczegółowoModelowanie i Programowanie Obiektowe
Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do
Bardziej szczegółowoSpis treści. Przedmowa
Spis treści Przedmowa V 1 SQL - podstawowe konstrukcje 1 Streszczenie 1 1.1 Bazy danych 1 1.2 Relacyjny model danych 2 1.3 Historia języka SQL 5 1.4 Definiowanie danych 7 1.5 Wprowadzanie zmian w tabelach
Bardziej szczegółowoWykład XII. optymalizacja w relacyjnych bazach danych
Optymalizacja wyznaczenie spośród dopuszczalnych rozwiązań danego problemu, rozwiązania najlepszego ze względu na przyjęte kryterium jakości ( np. koszt, zysk, niezawodność ) optymalizacja w relacyjnych
Bardziej szczegółowoSystemy baz danych. mgr inż. Sylwia Glińska
Systemy baz danych Wykład 1 mgr inż. Sylwia Glińska Baza danych Baza danych to uporządkowany zbiór danych z określonej dziedziny tematycznej, zorganizowany w sposób ułatwiający do nich dostęp. System zarządzania
Bardziej szczegółowoPojęcie bazy danych. Funkcje i możliwości.
Pojęcie bazy danych. Funkcje i możliwości. Pojęcie bazy danych Baza danych to: zbiór informacji zapisanych według ściśle określonych reguł, w strukturach odpowiadających założonemu modelowi danych, zbiór
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoRelacyjny model baz danych, model związków encji, normalizacje
Relacyjny model baz danych, model związków encji, normalizacje Wyklad 3 mgr inż. Maciej Lasota mgr inż. Karol Wieczorek Politechnika Świętokrzyska Katedra Informatyki Kielce, 2009 Definicje Operacje na
Bardziej szczegółowoProjektowanie warstwy danych
Jarosław Kuchta Internetowych Projektowanie warstwy danych qhta@eti.pg.gda.pl J.Kuchta@eti.pg.gda.pl Zagadnienia Sposoby zapisu danych zewnętrznych Odwzorowanie dziedziny problemu w dziedzinę danych Normalizacja
Bardziej szczegółowoBaza danych. Baza danych to:
Baza danych Baza danych to: zbiór danych o określonej strukturze, zapisany na zewnętrznym nośniku (najczęściej dysku twardym komputera), mogący zaspokoić potrzeby wielu użytkowników korzystających z niego
Bardziej szczegółowoProjektowanie struktury danych
Jarosław aw Kuchta Rozproszonych Projektowanie qhta@eti.pg.gda.pl J.Kuchta@eti.pg.gda.pl Zagadnienia Sposoby zapisu danych zewnętrznych Odwzorowanie dziedziny problemu w dziedzinę danych Normalizacja relacyjnej
Bardziej szczegółowoModelowanie danych, projektowanie systemu informatycznego
Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym
Bardziej szczegółowoZwiązki pomiędzy tabelami
Związki pomiędzy tabelami bazy danych. Stosowanie relacji jako nazwy połączenia miedzy tabelami jest tylko grą słów, którą można znaleźć w wielu podręcznikach ( fachowo powinno się używać związku). Związki
Bardziej szczegółowoWykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.
Bazy Danych Wykład II Encja, atrybuty, klucze Związki encji Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło 1 Encja Byt pojęciowy
Bardziej szczegółowoBazy danych 2. Wykład 1
Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoGrzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat
Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych
Bardziej szczegółowoBaza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.
PI-14 01/12 Baza danych to zbiór wzajemnie powiązanych ze sobą i zintegrowanych danych z pewnej dziedziny.! Likwidacja lub znaczne ograniczenie redundancji (powtarzania się) danych! Integracja danych!
Bardziej szczegółowoBAZY DANYCH. Anomalie. Rozkład relacji i normalizacja. Wady redundancji
BAZY DANYCH WYKŁAD 5 Normalizacja relacji. Zapytania zagnieżdżone cd. Wady redundancji Konieczność utrzymania spójności kopii, Marnowanie miejsca, Anomalie. (Wybrane materiały) Dr inż. E. Busłowska Copyright
Bardziej szczegółowoWykład 7. Projektowanie kodu oprogramowania
Wykład 7 Projektowanie kodu oprogramowania Treść wykładu cykl życiowy oprogramowania zagadnienia inżynierii oprogramowania tworzenie oprogramowania z gotowych elementów tworzenie niezawodnego oprogramowania
Bardziej szczegółowoPodyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle
Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle EFEKTY KSZTAŁCENIA Wiedza Absolwent tej specjalności
Bardziej szczegółowoBlaski i cienie wyzwalaczy w relacyjnych bazach danych. Mgr inż. Andrzej Ptasznik
Blaski i cienie wyzwalaczy w relacyjnych bazach danych. Mgr inż. Andrzej Ptasznik Technologia Przykłady praktycznych zastosowań wyzwalaczy będą omawiane na bazie systemu MS SQL Server 2005 Wprowadzenie
Bardziej szczegółowoPAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W NOWYM SĄCZU SYLABUS PRZEDMIOTU. Obowiązuje od roku akademickiego: 2011/2012
PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W NOWYM SĄCZU SYLABUS Obowiązuje od roku akademickiego: 2011/2012 Instytut Techniczny Kierunek studiów: Informatyka Kod kierunku: 11.3 Specjalność: Informatyka Stosowana
Bardziej szczegółowo2010-10-21 PLAN WYKŁADU BAZY DANYCH MODEL DANYCH. Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna HISTORIA
PLAN WYKŁADU Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna BAZY DANYCH Wykład 2 dr inż. Agnieszka Bołtuć MODEL DANYCH Model danych jest zbiorem ogólnych zasad posługiwania
Bardziej szczegółowoInformacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4
Utrwalanie danych zastosowanie obiektowego modelu danych warstwy biznesowej do generowania schematu relacyjnej bazy danych Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 1. Relacyjne
Bardziej szczegółowoPLAN WYKŁADU BAZY DANYCH GŁÓWNE ETAPY PROJEKTOWANIA BAZY MODELOWANIE LOGICZNE
PLAN WYKŁADU Modelowanie logiczne Transformacja ERD w model relacyjny Odwzorowanie encji Odwzorowanie związków Odwzorowanie specjalizacji i generalizacji BAZY DANYCH Wykład 7 dr inż. Agnieszka Bołtuć GŁÓWNE
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoBazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)
Bazy danych 1 Wykład 5 Metodologia projektowania baz danych (projektowanie logiczne) Projektowanie logiczne przegląd krok po kroku 1. Usuń własności niekompatybilne z modelem relacyjnym 2. Wyznacz relacje
Bardziej szczegółowoUtwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji. podstawie kluczy podstawowych wiązanych relacji.
TRANSFORMACJA DO SCHEMATU RELACYJNEGO pojęcia podstawowe Repetytorium pojęcia podstawowe relacyjnego modelu danych Schemat implementacyjny (logiczny) bazy danych: schemat, na którym działają aplikacje.
Bardziej szczegółowoLITERATURA. C. J. Date; Wprowadzenie do systemów baz danych WNT Warszawa 2000 ( seria Klasyka Informatyki )
LITERATURA C. J. Date; Wprowadzenie do systemów baz danych WNT Warszawa 2000 ( seria Klasyka Informatyki ) H. Garcia Molina, Jeffrey D. Ullman, Jennifer Widom; Systemy baz danych. Kompletny podręcznik
Bardziej szczegółowoPojęcie zależności funkcyjnej
Postacie normalne Plan wykładu Zależności funkcyjne Cel normalizacji Pierwsza postać normalna Druga postać normalna Trzecia postać normalna Postać normalna Boyca - Codda Pojęcie zależności funkcyjnej Definicja
Bardziej szczegółowoModel relacyjny. Wykład II
Model relacyjny został zaproponowany do strukturyzacji danych przez brytyjskiego matematyka Edgarda Franka Codda w 1970 r. Baza danych według definicji Codda to zbiór zmieniających się w czasie relacji
Bardziej szczegółowoBAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza
BAZY DANYCH Microsoft Access NORMALIZACJA BAZ DANYCH Adrian Horzyk Akademia Górniczo-Hutnicza Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej Katedra Automatyki i Inżynierii
Bardziej szczegółowoSQL w 24 godziny / Ryan Stephens, Arie D. Jones, Ron Plew. Warszawa, cop Spis treści
SQL w 24 godziny / Ryan Stephens, Arie D. Jones, Ron Plew. Warszawa, cop. 2016 Spis treści O autorach 11 Podziękowania 12 Część I Wprowadzenie do języka SQL 13 Godzina 1. Witamy w świecie języka SQL 15
Bardziej szczegółowopoziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS
poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS Niniejszy dokument jest syllabusem obowiązującym dla certyfikatu EUCIP ver. 2.6. Prezentuje obszary wiedzy, których znajomość jest niezbędna do
Bardziej szczegółowoPodstawy Programowania Obiektowego
Podstawy Programowania Obiektowego Wprowadzenie do programowania obiektowego. Pojęcie struktury i klasy. Spotkanie 03 Dr inż. Dariusz JĘDRZEJCZYK Tematyka wykładu Idea programowania obiektowego Definicja
Bardziej szczegółowo*Grafomania z. Neo4j. Praktyczne wprowadzenie do grafowej bazy danych.
*Grafomania z Neo4j Praktyczne wprowadzenie do grafowej bazy danych. Jak zamodelować relacyjną bazę danych reprezentującą następujący fragment rzeczywistości: Serwis WWW opisuje pracowników różnych firm
Bardziej szczegółowoZasady transformacji modelu DOZ do projektu tabel bazy danych
Zasady transformacji modelu DOZ do projektu tabel bazy danych A. Obiekty proste B. Obiekty z podtypami C. Związki rozłączne GHJ 1 A. Projektowanie - obiekty proste TRASA # * numer POZYCJA o planowana godzina
Bardziej szczegółowoProjektowanie aplikacji z bazami danych
Systemy mapowania relacyjno-obiektowego Instytut Informatyki Uniwersytet Wrocławski Plan wykładu Wprowadzenie do trwałości Niedopasowanie paradygmatów Architektura warstwowa Czym jest ORM? Problemy i pytania
Bardziej szczegółowoI. KARTA PRZEDMIOTU CEL PRZEDMIOTU
I. KARTA PRZEDMIOTU 1. Nazwa przedmiotu: BAZY DANYCH 2. Kod przedmiotu: Bda 3. Jednostka prowadząca: Wydział Mechaniczno-Elektryczny 4. Kierunek: Automatyka i Robotyka 5. Specjalność: Informatyka Stosowana
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoPierwsza postać normalna
Normalizacja Pierwsza postać normalna Jedynymi relacjami dozwolonymi w modelu relacyjnym są relacje spełniające następujący warunek: każda wartość w relacji, tj. każda wartość atrybutu w każdej krotce,
Bardziej szczegółowoSIECI KOMPUTEROWE I BAZY DANYCH
KATEDRA MECHANIKI I ROBOTYKI STOSOWANEJ WYDZIAŁ BUDOWY MASZYN I LOTNICTWA, POLITECHNIKA RZESZOWSKA SIECI KOMPUTEROWE I BAZY DANYCH Laboratorium DB2: TEMAT: Relacyjne bazy danych Cz. I, II Cel laboratorium
Bardziej szczegółowoPODSTAWY BAZ DANYCH. 19. Perspektywy baz danych. 2009/2010 Notatki do wykładu "Podstawy baz danych"
PODSTAWY BAZ DANYCH 19. Perspektywy baz danych 1 Perspektywy baz danych Temporalna baza danych Temporalna baza danych - baza danych posiadająca informację o czasie wprowadzenia lub czasie ważności zawartych
Bardziej szczegółowoWprowadzenie do baz danych
Wprowadzenie do baz danych Bazy danych stanowią obecnie jedno z ważniejszych zastosowań komputerów. Podstawowe zalety komputerowej bazy to przede wszystkim szybkość przetwarzania danych, ilość dostępnych
Bardziej szczegółowoTechnologia informacyjna
Technologia informacyjna Pracownia nr 9 (studia stacjonarne) - 05.12.2008 - Rok akademicki 2008/2009 2/16 Bazy danych - Plan zajęć Podstawowe pojęcia: baza danych, system zarządzania bazą danych tabela,
Bardziej szczegółowoObiektowe bazy danych
Obiektowe bazy Obiektowy model Wykład prowadzi: Tomasz Koszlajda Plan wykładu Przesłanki dla nowej generacji systemów baz Podstawowe elementy obiektowego modelu Konstruktory złożonych typów Abstrakcyjne
Bardziej szczegółowoTechnologie obiektowe
WYKŁAD dr inż. Paweł Jarosz Instytut Informatyki Politechnika Krakowska mail: pjarosz@pk.edu.pl LABORATORIUM dr inż. Paweł Jarosz (3 grupy) mgr inż. Piotr Szuster (3 grupy) warunki zaliczenia Obecność
Bardziej szczegółowoWPROWADZENIE DO BAZ DANYCH
1 Technologie informacyjne WYKŁAD IV WPROWADZENIE DO BAZ DANYCH MAIL: WWW: a.dudek@pwr.edu.pl http://wgrit.ae.jgora.pl/ad Bazy danych 2 Baza danych to zbiór danych o określonej strukturze. zapisany na
Bardziej szczegółowoHistoria modeli programowania
Języki Programowania na Platformie.NET http://kaims.eti.pg.edu.pl/ goluch/ goluch@eti.pg.edu.pl Maszyny z wbudowanym oprogramowaniem Maszyny z wbudowanym oprogramowaniem automatyczne rozwiązywanie problemu
Bardziej szczegółowoBAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza
BAZY DANYCH Microsoft Access NORMALIZACJA BAZ DANYCH Adrian Horzyk Akademia Górniczo-Hutnicza Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej Katedra Automatyki i Inżynierii
Bardziej szczegółowoSystemy GIS Systemy baz danych
Systemy GIS Systemy baz danych Wykład nr 5 System baz danych Skomputeryzowany system przechowywania danych/informacji zorganizowanych w pliki Użytkownik ma do dyspozycji narzędzia do wykonywania różnych
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
Bardziej szczegółowoProjektowanie bazy danych przykład
Projektowanie bazy danych przykład Pierwszą fazą tworzenia projektu bazy danych jest postawienie definicji celu, założeń wstępnych i określenie podstawowych funkcji aplikacji. Każda baza danych jest projektowana
Bardziej szczegółowoSpis treści. 1 Modelowanie logiczne. Plan wykładu. 1 Modelowanie logiczne 1
Plan wykładu Spis treści 1 Modelowanie logiczne 1 2 Transformacja modelu pojęciowego do logicznego 2 2.1 Transformacja własności............................ 3 2.2 Transformacja związków............................
Bardziej szczegółowoKrzysztof Kadowski. PL-E3579, PL-EA0312,
Krzysztof Kadowski PL-E3579, PL-EA0312, kadowski@jkk.edu.pl Bazą danych nazywamy zbiór informacji w postaci tabel oraz narzędzi stosowanych do gromadzenia, przekształcania oraz wyszukiwania danych. Baza
Bardziej szczegółowo