Przyjmuje się, że nazwa encji jest rzeczownikiem w licznie pojedynczej (nie jest to jednak obowiązkowe), a tabeli w liczbie mnogiej. Z tego powodu na powyższym diagramie w prostokątach symbolizujących encje pojawiły się nazwy takie jak: "klient", "pracownik", "zamówienie" i inne. Zauważmy też, że pomiędzy encjami pojawiły się specjalnie oznakowane kreski, które symbolizują związki encji. Jak już wspominałem, sposobów na ich oznakowanie jest kilka. Tu użyte jest oznakowanie wg notacji Martin-McClure'a, czyli: "okrąg" oznacza słowo "może", "kreska" - musi, a "wronie pazury" na zakończeniu symbolu - "do wielu". Odczyt powyższego diagramu jest prostszy niż diagramu Venna. Czytając związki encji (czytamy w obie strony związku) widzimy, że:
* "Jeden klient może złożyć wiele zamówień"
* "Zamówienie może być złożone przez maksymalnie jednego klienta"
* "Pracownik może przyjąć wiele zamówień"
* "Zamówienie musi być przyjęte przez jedneg
o pracownika"
* "Każde z zamówień dotyczy przynajmniej jednego typu bombonierki, ale może wielu"
* "Każdy typ bombonierki może być składnikiem wielu zamówień".
* "Każdy typ bombonierki zawiera przynajmniej jednen typ czekoladki"
* "Każdy typ czekoladki może być składnikiem wielu typów bombonierek".
* "Do każdego zamówienia możemy wystawić maksymalnie dwie faktury"
* "Każda faktura musi być wystawiona tylko do jednego zamówienia".
Tu jeszcze raz zaznaczę, że analizowany podczas zajęć projekt nie nadaje się do zastosowań profesjonalnych, a dzieje się tak m.in. dlatego, że nie uwzględniamy w nim konkretnych dostaw towaru. Przyjmujemy, że mamy zawsze pełne magazyny niepsujących się bombonierek i z tego powodu mówiąc bombonierka mamy na myśli raczej typ bombonierki, a nie konktetną bombonierkę z konktetnej dostawy. Z tego powodu przeczytałem związki encji mówiąc o typach bombonierek, czy typach czekoladek. W przyjętym modelu bombonierka ma zawsze taką samą cenę (pamiętaną dla bombonierki), a tymczasem powinien być do niej przypisany cennik, który obowiązuje w danym okresie czasu. Pomijamy ten problem w celu uproszczenia projektu.
Rys. 3. Diagram związków encji
W tym wypadku zostanią dodane encje przejściowe "szczegół zamówienia" (właściwie powinna się ona nazywać "pozycja zamówienia" mówimy przecież "pozycja pierwsza", a nie "szczegół pierwszy") oraz "zawartość bombonierki", a także odpowiednie związki jeden do wielu (wiele po stronie encji przejściowej!), które należy czytać:
* "Każde zamówienie musi posiadać przynajmniej jeden szczegół zamówienia"
* "Każdy szczegół zamówienia musi być fragmentem jednego zamówienia"
* "Każdy szczegół zamówienia musi dotyczyć jednego typu bomonierki"
* "Każdy typ bombonierki może być elementem wielu szczegółów zamówienia"
* "Każda zawartość bombonierki musi opisywać część jednego typu bomonierki"
* "Każdy typ bombonierki musi składać się z przynajmniej jednej zawartości bombonierki"
* "Każda zawartość bombonierki musi dotyczyć jednego typu czekoladki"
* "Typ czekoladki może być składnikiem wielu zawartości bombonierek".
Po wykonaniu diagramu (już bez związków wiele do wielu) określamy jeszcze jakie atrybuty powinna posiadać każda z encji (czyli określamy cechy obiektów ze świata rzeczywistego). Dodatkowo określmy, czy podanie wartości do danego atrybutu jest wymagane (NOT NULL), czy nie (NULL).
Przy projektowaniu ważne jest opisanie znaczenia zarówno encji jak i ich atrybutów. Te opisy to fragment tzw. metadanych (dane o danych), a bez nich wybieranie informacji z bazy jest mocno utrudnione (w wypadku dużych, złożonych systemów - niemożliwe, ponieważ nie wiemy jakie informacje wybieramy). Nie każdy SZRBD posiada możliwość zapamiętania dodatkowych opisów tabel i kolumn (np.: poleceniem COMMENT ON w przypadku Oracle lub opis pola - z tego powodu opisy te są ważne.
Zarówno przy wykonywaniu diagramu związków encji jak i przy określaniu atrybutów encji przydatna jest znajomość dokumentów, które używane są w firmie. Z tych dokumentów możemy się dowiedzieć jakie właściwości obiektów musimy znać, aby można było wykonywać takie dokumenty używając danych z bazy.
Muszę stworzyć zapytania sql do tabel, niestety nie miałem z sqlem nic do czynienia i nie wiem jak zrobić te zapytania proszę o pomoc
1) tworzenie tabel
2)modyfikacje * 5 co najmniej 5 modeli - modyfikacja tabeli
3) inserty(3) do każdej tabeli insert aby bazowały na sekwencjach
4) update, delete min 2
5) selecty (5prostych )bazujących na innej tabeli, oraz 5 złożonych
proszę o pomoc