Projektowanie baz danych
|
|
- Bogumił Rudnicki
- 6 lat temu
- Przeglądów:
Transkrypt
1 Projektowanie baz danych
2 Uwagi ogólne Projektowanie baz danych jest częścią tworzenia systemu z bazą danych. Podlega ogólnym zasadom tworzenia projektu.
3 Przed rozpoczęciem projektowania Modelowanie biznesowe co się dzieje w rzeczywistości, którą implementujemy? Wymagania użytkownika jaką funkcjonalność chcemy zaimplementować?
4 Wyznaczanie priorytetów Wymaganie jest konieczne, jeżeli nie można się bez niego obejść w systemie Wymaganie jest przydatne, jeżeli jego pominięcie nie spowoduje poważnych problemów związanych z realizacją podstawowych zamierzeń Wymaganie jest nieistotne, jeżeli mogą okazać się przydatne w pewnych zastosowaniach, lecz wprowadzenie ich do systemu nie jest warte wysiłku Wymaganie jest zbędne, jeżeli nie wiąże się w żaden sposób z celem projektu
5 Etapy projektowania bazy danych konceptualne (bez odniesienia do SZBD) zapisanie informacji o projekcie w standardowej notacji ER (diagramy Chena lub UML) niezależnej od docelowego SZBD. logiczne (dla SZBD konkretnego typu, np. relacyjnego lub obiektowego) podział danych na struktury dostępne w SZBD. fizyczne (dla konkretnego SZBD) zdefiniowanie dziedzin, relacji, indeksów, perspektyw, użytkowników z uprawnieniami itp.
6 Modelowanie konceptualne
7 Do czego służy modelowanie konceptualne? Eksploracja modelowanej dziedziny Analiza wymagań systemu w formie modelu konceptualnego/analitycznego Opis szczegółowego obiektowego projektu systemu
8 Ogólne problemy Jak modelować dane niezależnie od implementacji? Jak osiągnąć dobry schemat bazy danych? Efektem modelowania jest nieformalne przedstawienie bazy danych w postaci diagramów
9 Co powinniśmy osiągnąć? Porozumienie dotyczące schematu bazy danych przed podjęciem decyzji o implementacji. Powinniśmy wiedzieć: Jakie jednostki(encje) modelować Jak jednostki (encje) są powiązane nawzajem Jakie są ograniczenia w modelowanej dziedzinie. Powinniśmy osiągnąć dobry projekt
10 Model Chena
11 Model Chena Jednostka (ang. Entity) obiekt, encja; Atrybuty (ang. Attributes) Związki (ang. Relationship)
12 Diagramy Chena zbiór encji Encja - zbiór jednorodnych elementów, o skończonej, regularnej strukturze, które można wyróżnić w zagadnieniu rzeczywistym. Pracownik Firma Stanowisko Oddział
13 Diagramy Chena atrybuty Atrybut - cecha encji. Encja ma ustaloną liczbę atrybutów. Dla każdego atrybutu określamy typ jego wartości oraz ewentualne ograniczenia nałożone na te wartości (zakres, format itp.) Imię Nazw Regon Nazwa Pracownik DataUr Firma Kapitał
14 Diagramy Chena Osoba Pesel Nazwa Płeć DataUr Tytuł Imię Drugie Imię Nazwisko Encje mogą być proste lub złożone
15 Diagramy Chena - klucze Klucz minimalny podzbiór atrybutów encji pozwalający jednoznacznie wyznaczyć encję; Rodzaje kluczy: Klucz kandydujący dowolny klucz zbioru encji; Klucz główny wybrany jeden klucz spośród kandydujących; Klucze alternatywne klucze kandydujące oprócz głównego; Podział kluczy: Klucz złożony: {Nazwisko, Imie, DataUr} Klucz prosty: {PESEL}, {NIP}, Klucz sztuczny: {OsID}
16 Diagramy Chena - klucze Każdy typ jednostki musi posiadać klucz. Klucz oznaczany jest przez podkreślenie. Regon Nazwa Firma Kapitał
17 Diagramy Chena związki Związek określamy pomiędzy zbiorami encji. Funkcyjny (1-n) 1 n Firma ma Oddział Wieloznaczny (n-m) Pracownik n ud m Firma Jednoznaczny (1-1) Kraj 1 ma 1 Stolica
18 Diagramy Chena atrybuty związku Związek może mieć atrybuty Samochód n 1 ma Osoba datazak cena Firma n Ud m Osoba datazat płaca
19 Diagramy Chena związki k-arne Możliwe są związki pomiędzy >2 zbiorami encji. Grupa Przedmiot ma Sala termin Wykładowca
20 Diagramy Chena związki rekurencyjne Związek pomiędzy encjami tego samego zbioru. Definiując taki związek określamy rolę każdej z encji w związku. jest podwładnym OSOBA podległość jest przełożonym
21 Diagramy Chena związki hierarchiczne PRACOWNIK ZESPÓŁ isa kieruje MANAGER Premia Data
22 Większy przykład OSOBA isa isa poprzedza * STUDENT PRACOWNIK następstwo KURS * 1 isa następuje_po zapisany zawiera PROFESOR 1..* 1..* WYKŁAD * prowadzi 1
23 Podsumowanie procesu tworzenia modelu konceptualnego 1. określ zbiory encji; 2. określ związki pomiędzy zbiorami encji i ich rodzaj; 3. określ atrybuty encji i związków (uwaga na atrybuty redundantne); 4. wyznacz dziedziny atrybutów i ich ograniczenia; 5. wyznacz klucze kandydujące i wybierz klucze główne; 6. określ więzy ogólne;
24 Diagramy klas
25 Klasa- części składowe Nazwa klasy Atrybuty klasy Metody klasy
26 Klasa - przykład Trzy rodzaje pól: nazwa klasy, atrybuty klasy oraz metody klasy. Możliwe są różne poziomy szczegółowości. Pracownik Nazwisko DataUr PESEL Pracownik Firma Nazwa Regon Adres Firma
27 Dziedziczenie klas Definicja generalizacji: Związek pomiędzy elementem bardziej ogólnym a elementem bardziej szczegółowym. Element szczegółowy jest w pełni spójny z elementem ogólnym, może jednak zawierać dodatkowe informacje. Instancje elementu szczegółowego mogą być wykorzystywane wszędzie tam, gdzie wymagane jest użycie instancji elementu ogólnego. Wskazuje, że obiekt klasy dziedziczącej (podklasy) jest wymienialny z obiektem klasy dziedziczonej (nadklasy).
28 specjalizacja generalizacja Dziedziczenie Dziedziczenie pozwala na tworzenie drzewa klas. Osoba Osoba Pracownik Pracownik Asystent Adiunkt Docent Profesor Asystent Adiunkt Docent Profesor
29 Asocjacje (1) Definicja: Asocjacja jest relacją pomiędzy dwoma lub więcej klasami, specyfikującą połączenie pomiędzy instancjami tych klas. Asocjacja pomiędzy dwoma klasami oznacza, że obiekt na jednym końcu asocjacji rozpoznaje obiekty na drugim końcu asocjacji i może im wysyłać wiadomości. Przykład: Pracownik pracuje dla firmy Firma Osoba
30 Asocjacje (2) Asocjacja może mieć nazwę (pracuje_dla), która wyznacza znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę przedmiotową. Czarny trójkąt określa kierunek (czytania) wyznaczony przez nazwę asocjacji. Firma 1 pracuje_dla 1..* Osoba Asocjacje mogą być wyposażone w oznaczenia liczności. Liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy.
31 Role asocjacji (1) Asocjacje mogą być wyposażone w nazwy ról (przy końcach), np. pracodawca i pracownik. W tym przypadku liczność asocjacji oznacza liczność roli. Firma * pracodawca pracuje_dla 1..* pracownik * podwładny Osoba 0..1 szef Role asocjacji są niezbędne, gdy powiązania łączą obiekty tej samej klasy. Można opuszczać nazwę asocjacji, gdy jest oczywista i jest jedyną asocjacją łączącą dwie klasy. Firma 1 1..* Pracownik
32 Atrybuty asocjacji klasy asocjacyjne Plik * dostępny dla * Użytkownik Prawo dostępu dostęp { dostęp oznacza: czytanie lub czytanie-pisanie} kieruje szef 0..1 Osoba nazwisko pesel adres * pracownik 1..* zatrudnia 0..1 Zatrudnienie zarobek stanowisko Firma nazwa adres Ocena wydajności ocena
33 Kiedy stosować atrybuty asocjacji? Zalecane jest, by przypisywać do klasy tylko te atrybuty, które są dla tej klasy stabilne. Osoba nazwisko pesel adres 1..* pracuje_w 0..1 Zatrudnienie zarobek stanowisko Firma nazwa adres Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów. Osoba nazwisko pesel adres zarobek stanowisko 1..* pracuje_w 0..1 Firma nazwa adres
34 Przykładowy diagram klas Osoba poprzedza zapisany_na 1..* 0..1 Kurs * 1 zawiera następuje_po Student Pracownik Profesor prowadzi 1 1..* 1..* Wykład *
35 Budowa modelu obiektowego Poszczególne kroki podczas tworzenia modelu konceptualnego Identyfikacja klas użytkownika Identyfikacja związków Identyfikacja atrybutów Identyfikacja relacji dziedziczenia
36 Identyfikacja klas użytkownika Uwaga skoncentrowana na dziedzinie aplikacyjnej, a nie na szczegółach implementacyjnych Punktem wyjścia może być znalezienie rzeczowników (kandydaci na nazwy klas) oraz czasowników (kandydaci na operacje) na podstawie opisu projektu, specyfikacji przypadków użycia oraz ogólnej wiedzy na temat rozważanej dziedziny projektowej
37 Identyfikacja klas użytkownika - wskazówki Należy unikać synonimów i nazw o zbliżonym znaczeniu Nazwa klasy powinna być rzeczownikiem lub rzeczownikiem poprzedzonym przymiotnikiem Należy wydzielić i usunąć z dalszych rozważań klasy, które nie mieszczą się z zakresie systemu Należy rozważyć i sprecyzować znaczenie przypisywanej każdej klasie. Jeśli zakres klasy nie jest wyraźnie wydzielony, należy rozważyć połączenie jej z inną (innymi klasami)
38 Identyfikacja klas użytkownika - wskazówki Należy odróżnić nazwy klas od nazw atrybutów klas. Nazwy klas powinny odnosić się do obiektów reprezentujących niezależne byty, podczas gdy atrybuty odnoszą się do własności charakteryzujących takie obiekty Należy pomijać nazwy, które charakteryzują role pełnione przez klasy w łączących je związkach (będą określone później). Wybrane nazwy klas powinny być niezależne od związków z innymi klasami Należy eliminować klasy, które reprezentują elementy implementacji Należy rozważyć eliminację klas bez operacji Klasy, które odnoszą się do więcej niż jednej abstrakcji (niespójne) powinny być podzielone na kilka klas
39 Identyfikacja związków pomiędzy klasami Należy unikać związków reprezentujących zależności implementacyjne Związki powinny reprezentować zależności trwałe (niezależne od czasu) Należy unikać związków, które można wyrazić za pomocą istniejących już związków (w przeciwnym razie występuje nadmiarowość) Należy dążyć do związków binarnych (obejmujących dwie klasy) Należy określić liczność charakteryzującą liczbę obiektów poszczególnych klas
40 Identyfikacja atrybutów Atrybuty powinny opisywać własności obiektów Należy rozpatrywać tylko te atrybuty, które mają sens aplikacyjny; nie należy wprowadzać atrybutów dodatkowych (np. identyfikatory obiektów) Atrybut, który zasadniczo różni się od innych atrybutów danej klasy może sugerować, że klasa jest niespójna i powinna być rozbita na różne klasy Należy rozważyć eliminację klas tylko z jednym atrybutem
41 Identyfikacja relacji dziedziczenia Należy zwrócić uwagę na klasy o podobnych cechach (atrybutach, związkach, operacjach) i zdefiniować dla nich klasy nadrzędne zawierające wspólne cechy Należy eliminować relacje dziedziczenia gdy podklasa nie jest szczególnym przypadkiem nadklasy
42 Transformacja modelu logicznego do modelu fizycznego
43 Przejście na model relacyjny Transformacja modelu logicznego do fizycznego polegać będzie na przeniesieniu klas oraz związków do odpowiednich tabel bazodanowych Podstawowe problemy przy przechodzeniu na model relacyjny: nie ma możliwości przechowywania wielu wartości jednego atrybutu, każda tabela musi byc wyposażona w unikalny klucz, powiązania muszą być zaimplementowane jako tabele/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, Dodatkowo należy uwzględnić: cechy ilościowe (charakterystyka ilościowa danych i procesów), unikanie redundancji w danych (normalizacja), wymagania użytkowe: czas odpowiedzi, utylizacja pamięci (denormalizacja). Przejście na model relacyjny nie może być całkowicie automatyczne.
44 Podstawowe informacje Zasadniczo można rozważać konwertowanie klas do tabel bazy danych nie zawsze jednak jest to możliwe. Przeszkody: np. brak obsługi dziedziczenia. Atrybuty klasy są konwertowane na kolumny tabeli przypadek najprostszy Nie wszystkie atrybuty są trwałe niektóre są używane do obliczeń tymczasowych. Wtedy nie są mapowane. Jeśli atrybuty obiektu są obiektami, wówczas tworzona jest asocjacja pomiędzy nimi: np.: klient posiada adres, który jest bytem złożonym Tabela może zawierać atrybuty, które nie są wyszczególnione w klasie
45 Rodzaje relacji Rodzaje relacji 1:1 - jeden do jednego 1:N jeden do wielu M:N wiele do wielu
46 Odwzorowanie asocjacji Dla liczności 1:1 można zaimplementować jako jedną tablelę. Państwo Nazwa Stolica Miasto Państwo IdPaństwa Nazwa Stolica Dla liczności 1:n można zaimplementować jako dwie tabele: (Atrybuty związku na ogół powodują konieczność zastosowania następnej metody.) Pracownik Nazwisko 1..* pracuje_w 1 Firma Nazwa Pracownik IdPrac Nazwisko IdFirmy Firma IdFirmy Nazwa Dla liczności m:n należy zaimplementować jako trzy tabele. Pracownik Nazwisko pracuje_w 1..* * Firma Nazwa Pracownik IdPrac Nazwisko PracFirma IdPrac IdFirmy Firma IdFirmy Nazwa
47 Trzy metody obejścia braku dziedziczenia Użycie jednej tabeli dla całego drzewa klas poprzez zsumowanie wszystkich występujących atrybutów i powiązań w tym drzewie oraz dodanie dodatkowego atrybutu - dyskryminatora wariantu. B A C A B C dyskr Użycie oddzielnych tabel 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 tabel dla każdej klasy. Zamiana dziedziczenia na powiązania łączące nadklasę ze wszystkimi podklasami. B A C B A 0..1 C 0..1
48 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 dodatkowy atrybut dyskryminator PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok Adres Adres męża Adres żony Rodzaj PIT PIT pojedyncz podatnika Adres PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony
49 Zalety i wady każdej z trzech metod Cecha Jedna tabela dla hierarchii Tabela dla klasy konkretnej Tabela 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
50 Przejście na model relacyjny; przykłady (1) Klient NazwaKlienta ma InfoDostawy AdresDostawy KlientDostawa (IdKlienta, NazwaKlienta, AdresDostawy) Klient NazwaKlienta posiada 0..1 KartaKredytowa IdKarty TypKarty LimitKarty Klient (Id_Klienta, Nazwa_Klienta) KartaKredytowa (IdKarty, TypKarty, IdKlienta, LimitKarty) Projektant nie zdecydował się na jedną tabelę, gdyż założył, że będzie zbyt dużo wartości zerowych.
51 Przejście na model relacyjny; przykłady (2) Kobieta NazwiskoKobiety Ślub DataŚlubu Mężczyzna NazwiskoMężczyzny Kobieta( IdKobiety, NazwiskoKobiety ) Mężczyzna( IdMężczyzny, NazwiskoMężczyzny ) Ślub( IdKobiety, IdMężczyzny, DataŚlubu ) Student Nazwisko_Studenta Suma_Pkt_Studenta 1..* Student_Kurs Ocena_semestr Semestr Kurs Nazwa_Kursu Student (Id_Studenta, Nazwisko_Studenta, Suma_Pkt_Studenta) Kurs (Id_Kursu, Nazwa_Kursu) Student_Kurs (Id_Studenta, Id_Kursu, Semestr, Ocena_semestr) *
52 Przejście na model relacyjny; przykłady (3) Miasto NazwaMiasta LiczbaMieszkM 1..* leży_w Miasto(NazwaMiasta, NazwaWojewództwa, LiczbaMieszkM) Województwo(NazwaWojewództwa, Wojewoda, LiczbaMieszkW) Województwo NazwaWojewództwa Wojewoda LiczbaMieszkW Sprzedaż IdSprzedaży Data * Sprzedawca Nazwisko NrTel Sprzedaż_Sprzedawca NazwaTowaru Ilość Sprzedawca(Nazwisko, NrTel) Sprzedaż(IdSprzedaży, Data) Sprzedaż_Sprzedawca (IdSprzedaży, Nazwisko,NazwaTowaru, Ilość)
53 Przejście na model relacyjny; przykłady (4) jest_przełożonym Pracownik NazwiskoPrac DataUrodzPrac podległość jest_podwładnym M:N 1:N 1:1 Pracownik (IdPracownika, NazwiskoPrac, DataUrodzPrac) Podległość (IdPracPrzełoż, IdPracPodwład) Pracownik (IdPracownika, NazwiskoPrac, DataUrodzPrac, IdPracPodwład) Pracownik(IdPracownika, NazwiskoPrac, DataUrodzPrac, IdPracPrzełoż)
54 Przejście na model relacyjny; przykłady (5) Towar Nazwa_Towaru Klient Nazwa_Klienta Sprzedawca Nazwa_Sprzedawcy Sprzedaż 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)
55 Normalizacja czy denormallizacja Normalizacja polega na zdekomponowaniu tabeli na dwie lub więcej celem uniknięcia niekorzystnych własności: redundancji w danych oraz związanych z redundancją anomalii aktualizacyjnych. Istnieje 5 postaci normalnych relacji 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).
56 Należy zapamiętać Klasa jest odwzorowana na tabelę Atrybut klasy jest odwzorowany na kolumnę tabeli Implementacja relacji 1:1 polega na połączeniu atrybutów w jedną tabelę Implementacja relacji 1:N polega na dodaniu klucza obcego do tabeli po stronie wiele Implementacja relacji N:M polega na stworzeniu tabeli asocjacyjnej, która zawiera kombinację kluczy głównych Dziedziczenie można obejść przez agregację, stworzenie jednej wspólnej tabeli lub jednej tabeli dla każdej klasy Osiągnięcie rozsądnego kompromisu między normalizacją a denormalizacją Przy projektowaniu należy brać pod uwagę rozmiar tabel oraz przyrost danych w przyszłości
57 Dziękuję
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 Etapy procesu projektowania BD Określenie celów, jakim ma służyć baza danych (w kontakcie z decydentem z firmy zamawiającej projekt). Sprecyzowanie zakresu dostępnych danych, kategorii
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ół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ół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ół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ół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ółowoBazy Danych i Systemy informacyjne Wykład 7. Piotr Syga
Bazy Danych i Systemy informacyjne Wykład 7 Piotr Syga 27.11.2017 Wstęp Projektowanie baz bazodanowy komponent aplikacji projektujemy w sposób analogiczny do całej aplikacji ustalamy główne wymagania klienta,
Bardziej szczegółowoTechnologie baz danych
Technologie baz danych Wykład 4: Diagramy związków encji (ERD). SQL funkcje grupujące. Małgorzata Krętowska Wydział Informatyki Politechnika Białostocka Plan wykładu Diagramy związków encji elementy ERD
Bardziej szczegółowoMAS dr. Inż. Mariusz Trzaska
MAS dr. Inż. Mariusz Trzaska Wykład 4 Model obiektowy cz. 2 Zagadnienia Asocjacja binarna Agregacja a kompozycja Modelowanie generalizacji-specjalizacji Obejście dziedziczenia wielokrotnego Asocjacja kwalifikowana
Bardziej szczegółowoBazy danych i usługi sieciowe
Bazy danych i usługi sieciowe Modelowanie związków encji Paweł Daniluk Wydział Fizyki Jesień 2014 P. Daniluk (Wydział Fizyki) BDiUS w. II Jesień 2014 1 / 28 Modelowanie Modelowanie polega na odwzorowaniu
Bardziej szczegółowoSystemy informatyczne. Modelowanie danych systemów informatycznych
Modelowanie danych systemów informatycznych Diagramy związków encji Entity-Relationship Diagrams Modelowanie danych diagramy związków encji ERD (ang. Entity-Relationship Diagrams) diagramy związków encji
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 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ółowoProjektowanie systemów informacyjnych
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
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ół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ółowoZaawansowane Modelowanie I Analiza Systemów Informatycznych
Zaawansowane Modelowanie I Analiza Systemów Informatycznych ORM - Kroki 4 (c.d.) i5 mgr. inż. Tomasz Pieciukiewicz tomasz.pieciukiewicz@gmail.com ORM 7 kroków tworzenia schematu 1. Przekształć przykłady
Bardziej szczegółowoTransformacja modelu ER do modelu relacyjnego
Transformacja modelu ER do modelu relacyjnego Wykład przygotował: Robert Wrembel BD wykład 4 (1) 1 Plan wykładu Transformacja encji Transformacja związków Transformacja hierarchii encji BD wykład 4 (2)
Bardziej szczegółowoINFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji
Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami
Bardziej szczegółowoAutor: Joanna Karwowska
Autor: Joanna Karwowska W bazie danych przechowujemy tylko niektóre informacje o świecie rzeczywistym. Wybór właściwych wycinków rzeczywistości i dotyczących ich danych jest bardzo istotny od niego zależy
Bardziej szczegółowoBAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski
BAZY DANYCH model związków encji Opracował: dr inż. Piotr Suchomski Świat rzeczywisty a baza danych Świat rzeczywisty Diagram związków encji Model świata rzeczywistego Założenia, Uproszczenia, ograniczenia
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
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ół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 wykład trzeci. trzeci Modelowanie schematu bazy danych 1 / 40
Bazy danych wykład trzeci Modelowanie schematu bazy danych Konrad Zdanowski Uniwersytet Kardynała Stefana Wyszyńskiego, Warszawa trzeci Modelowanie schematu bazy danych 1 / 40 Outline 1 Zalezności funkcyjne
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ół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ółowoZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH ZSE - Systemy baz danych 2 rzeczywistość uzyskanie od użytkowników początkowych informacji i wymagań dotyczących przetwarzania danych analiza
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ółowoProjektowanie BD Diagramy związków encji
Wykład 10 Projektowanie BD Diagramy związków encji Bazy Danych - A. Dawid 2011 1 Diagramy związków encji Model Entity/Relationship (E/R) pozwala na opisanie statycznych aspektów rzeczywistości przy pomocy
Bardziej szczegółowoZaawansowane Modelowanie I Analiza Systemów Informatycznych
Zaawansowane Modelowanie I Analiza Systemów Informatycznych Wprowadzenie mgr. inż. Tomasz Pieciukiewicz tomasz.pieciukiewicz@gmail.com Agenda ZMA jako przedmiot Wprowadzenie do Object Role Modeling ZMA
Bardziej szczegółowoTRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO
TRANSFORMACJA MODELU ER DO MODELU RELACYJNEGO Biologiczne Aplikacje Baz Danych dr inż. Anna Leśniewska alesniewska@cs.put.poznan.pl REPETYTORIUM Schemat bazy danych zbiór schematów relacji Relacja (tabela)
Bardziej szczegółowoNormalizacja Projektowanie Diagramy encji. Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga
Bazy Danych i Systemy informacyjne Wykład 7 Piotr Syga 23.11.2018 Wprowadzenie Idea Cel usuwanie redundancji usuwanie anomalii (przy wstawianiu, usuwaniu, modyfikowaniu wierszy) Wprowadzenie Przykład idwyk
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ółowoTransformacja modelu EER do postaci relacyjnego modelu danych. Zbyszko Królikowski
Transformacja modelu EER do postaci relacyjnego modelu danych Zbyszko Królikowski 1 Repetytorium pojęcia podstawowe relacyjnego modelu danych Schemat implementacyjny (logiczny) bazy danych: schemat, na
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
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ółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoRysunek 1: Przykłady graficznej prezentacji klas.
4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez
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ółowoDiagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com
Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,
Bardziej szczegółowoBazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,
Bazy Danych Modele danych Krzysztof Regulski WIMiIP, KISiM, regulski@agh.edu.pl Cele modelowania Strategia informatyzacji organizacji Cele informatyzacji Specyfikacja wymagań użytkownika Model procesów
Bardziej szczegółowoKsięgarnia PWN: Michael J. Hernandez Bazy danych dla zwykłych śmiertelników
Księgarnia PWN: Michael J. Hernandez Bazy danych dla zwykłych śmiertelników Słowo wstępne (13) Przedmowa i podziękowania (drugie wydanie) (15) Podziękowania (15) Przedmowa i podziękowania (pierwsze wydanie)
Bardziej szczegółowoProgram nauczania. Systemy baz danych. technik informatyk 351203
Program nauczania Systemy baz technik informatyk 351203 Treści nauczania Lp. Temat Liczba godzin Efekty kształcenia 1. Zapoznanie z pojęciem baz 53 1. Pojęcie bazy podstawowe definicje 2 PKZ(E.b)11 2.
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ółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoKARTA PRZEDMIOTU. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI Ogólne umiejętności posługiwania się komputerem
WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Zał. nr 4 do ZW 33/01 KARTA PRZEDMIOTU Nazwa w języku polskim: Nazwa w języku angielskim: Kierunek studiów (jeśli dotyczy): Specjalność (jeśli dotyczy): Stopień studiów
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ół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ółowoTECHNOLOGIE OBIEKTOWE. Wykład 3
TECHNOLOGIE OBIEKTOWE Wykład 3 2 Diagramy stanów 3 Diagram stanu opisuje zmiany stanu obiektu, podsystemu lub systemu pod wpływem działania operacji. Jest on szczególnie przydatny, gdy zachowanie obiektu
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ół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ół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ółowoProjekt małej Bazy Danych.
Artykuł pobrano ze strony eioba.pl Projekt małej Bazy Danych. Przykałdowa baza danych dotycząca forum dyskusyjnego. Autor: Magister inżynier Ireneusz Łukasz Dzitkowski Wałcz, dnia: 08. 02. 2012r. Wszystkie
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ółowoDiagramy związków encji ERD Ćwiczenia w modelowaniu danych
Diagramy związków encji ERD Ćwiczenia w modelowaniu danych dr Lidia Stępień wykład 5 ERD ang. Entity-Relationship Diagram Diagram związków encji Proces konstruowania projektu systemu bazy danych. Abstrakcyjna
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ół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ółowoModelowanie konceptualne model EER
Modelowanie konceptualne model EER adeusz Pankowski www.put.poznan.pl/~tadeusz.pankowski Model EER rozszerzenie modelu ER 1. Liczne rozszerzenia modelu ER mają przede wszystkim na celu uwzględnienie zależności
Bardziej szczegółowoModelowanie związków encji. Etapy budowy systemu informatycznego przedsiębiorstwa (1/4) Etapy budowy systemu informatycznego przedsiębiorstwa (2/4)
1 Plan rozdziału 2 Modelowanie związków encji Przykładowy opis miniświata Encje Związki stopień związku typ asocjacji Notacje diagramów E Hierarchie encji Etapy budowy systemu informatycznego przedsiębiorstwa
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ół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ół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ółowoPodstawy projektowania systemów komputerowych
Podstawy projektowania systemów komputerowych Diagramy klas UML 1 Widok logiczny Widok logiczny Widok fizyczny Widok przypadków użycia Widok procesu Widok konstrukcji Używany do modelowania części systemu
Bardziej szczegółowoFUNKCJE SZBD. ZSE - Systemy baz danych 1
FUNKCJE SZBD ZSE - Systemy baz danych 1 System zarządzania bazami danych System zarządzania bazami danych (SZBD, ang. DBMS) jest zbiorem narzędzi stanowiących warstwę pośredniczącą pomiędzy bazą danych
Bardziej szczegółowoProjektowanie bazy danych
Projektowanie bazy danych Cel wykładu Umiejętność zamodelowania bazy danych na diagramie Plan wykładu Cel modelowania konceptualnego i modelu ER Etapy modelowania konceptualnego Model ER (związków encji)
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ółowoProjektowanie BAZY DANYCH
Projektowanie BAZY DANYCH Podstawowe pojęcia Encją jest każdy przedmiot, zjawisko, stan lub pojęcie, czyli każdy obiekt, który potrafimy odróżnić od innych obiektów ( np. pies, rower,upał). Encje podobne
Bardziej szczegółowoUML. zastosowanie i projektowanie w języku UML
UML zastosowanie i projektowanie w języku UML Plan Czym jest UML Diagramy przypadków użycia Diagramy sekwencji Diagramy klas Diagramy stanów Przykładowe programy Visual Studio a UML Czym jest UML UML jest
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ół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ół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ół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ółowoBazy danych wykład trzeci. trzeci Przekształcenie modelu ER na model relacyjny 1 / 19
Bazy danych wykład trzeci Przekształcenie modelu ER na model relacyjny Konrad Zdanowski Uniwersytet Kardynała Stefana Wyszyńskiego, Warszawa trzeci Przekształcenie modelu ER na model relacyjny 1 / 19 Przekształcanie
Bardziej szczegółowoTemat: Modelowanie schematu bazy danych za pomocą diagramów związków encji (Entity Relationship Diagrams ERD)
W y k ł a d II Temat: Modelowanie schematu bazy danych za pomocą diagramów związków encji (Entity Relationship Diagrams ERD) Plan wykładu: Cel modelowania konceptualnego i modelu ER Etapy modelowania konceptualnego
Bardziej szczegółowoDiagramy klas. WYKŁAD Piotr Ciskowski
Diagramy klas WYKŁAD Piotr Ciskowski przedstawienie statyki systemu graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi obiekty byt, egzemplarz
Bardziej szczegółowoLaboratorium 6 DIAGRAM KLAS (Class Diagram)
Laboratorium 6 DIAGRAM KLAS (Class Diagram) Opisuje strukturę programu (a także zależności między nimi), co znajduje odzwierciedlenie w kodzie. Charakteryzuje zależności pomiędzy składnikami systemu: klasami,
Bardziej szczegółowoModelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie klas i obiektów Jarosław Kuchta Podstawowe pojęcia (1) Byt, encja (entity) coś co istnieje, posiada własne cechy i wyodrębnioną tożsamość (identity); bytem może być rzecz, osoba, organizacja,
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ółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Analiza przypadków użycia - diagramy klas w fazie analizy Przygotował: mgr inż. Radosław Adamus Wstęp Poprzednie ćwiczenie
Bardziej szczegółowoBazy danych. dr inż. Andrzej Macioł
Bazy danych dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Ontologia Dziedzina metafizyki, która para się badaniem i wyjaśnianiem natury jak i kluczowych właściwości oraz relacji rządzących
Bardziej szczegółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
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ół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ółowoInżynieria oprogramowania. Część 5: UML Diagramy klas
UNIWERSYTET RZESZOWSKI KATEDRA INFORMATYKI Opracował: mgr inż. Przemysław Pardel v1.01 2010 Inżynieria oprogramowania Część 5: UML Diagramy klas ZAGADNIENIA DO ZREALIZOWANIA (3H) 1. Diagram klas... 3 Zadanie
Bardziej szczegółowoTECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ
TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ 1. Diagram obiektów i związków (DOZ) 2. Szczegółowa specyfikacja obiektów, atrybutów i związków GHJ 1 Metodyki strukturalne IE (Information Engineering) Martin
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoDiagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Bardziej szczegółowoBazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych
Plan wykładu Bazy danych Wykład 9: Przechodzenie od diagramów E/R do modelu relacyjnego. Definiowanie perspektyw. Diagramy E/R - powtórzenie Relacyjne bazy danych Od diagramów E/R do relacji SQL - perspektywy
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ółowoBazy danych 1. Wykład 4 Metodologia projektowania baz danych
Bazy danych 1 Wykład 4 Metodologia projektowania baz danych Fazy cyklu Ŝycia aplikacji bazodanowych Planowanie bazy danych Definicja systemu Gromadzenie i analiza wymagań Projektowanie bazy danych Konceptualne
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ółowoModelowanie związków encji. Etapy budowy systemu informatycznego przedsiębiorstwa (1/4) Etapy budowy systemu informatycznego przedsiębiorstwa (2/4)
1 Plan rozdziału 2 Modelowanie związków encji Przykładowy opis miniświata Encje Związki stopień związku typ asocjacji opcjonalność i mandatoryjność Notacje diagramów E Hierarchie encji Etapy budowy systemu
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ółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoMAS dr. Inż. Mariusz Trzaska
MAS dr. Inż. Mariusz Trzaska Wykład 5 Model obiektowy cz. 3 Zagadnienia Dziedziczenie asocjacji Asocjacje pochodne Redukcja liczności Role wielowartościowe Trochę więcej o agregacji Agregacja rekursywna
Bardziej szczegółowoTransformacja modelu ER do modelu relacyjnego
Transformacja modelu ER do modelu relacyjnego Wykład przygotował: Robert Wrembel BD wykład 4 (1) Plan wykładu Transformacja encji Transformacja związków Transformacja hierarchii encji BD wykład 4 (2) Pojęcia
Bardziej szczegółowo