1. Projektowanie schematu bazy danych w modelu E-R:

• używanie atrybutów bądź też całego zestawu elementów w celu reprezentacji objektów.
• wyrażenie rzeczywistego problemu bazodanowego przy pomocy zestawu elementów lub odpowiedniego zestawu relacji.
• korzystanie z potrójnych relacji bądź też pary relacji binarnych.
• używanie silnie albo słabo związanych elementów.
• korzystanie z generalizacji (nawiązuje do pewnej modularności systemu dopuszczając reprezentację w jednym miejscu diagramu E-R wspólnych atrybutów podobnych zestawów elementów).
• korzystanie z agregacji (pozwala na traktowanie zestawów elementów jako pojedyncze jednostki bez konieczności analizy ich wewnętrznej struktury).

Fazy projektowania

• określenie przez projektującego potrzeb użytkowników jakie system ma zaspokajać (z ang. specification of user requirements)
• przekształcenie tych potrzeb na koncepcyjny schemat bazy danych. Zdefiniowanie zatem wszystkich zestawów elementów, relacji oraz atrybutów. Następnie analiza otrzymanej struktury w celu wyeliminowania ewentualnych konfliktów danych, oraz nadmiarowych cech systemu. W pełni skonstruowany schemat powinien także zawierać obsługę operacji modyfikujących, aktualizujących, wyszukujących oraz usuwających określone dane (specification of functional requirements).
• proces przenoszenia obiektu abstrakcyjnego do implementacji bazy danych przebiega w dwóch zasadniczych etapach:
• etap logiczny (z ang. logical – design phase) – w, którym schemat bazy danych jest implementowany w modelu DBMS (z ang. Data Base Management System – system sterowania bazą danych).Tak otrzymany model DBMS jest używany w drugim etapie:
• etap fizyczny (z ang. physical – design phase) – w, którym zostają określone fizyczne cechy systemu, czyli: struktura plików oraz wewnętrzna architektura przechowywanych danych.

• bank jest zorganizowany w kilku filiach, z których każda znajduje się w określonym mieście i ma swoją unikatową nazwę. Jednocześnie administracja banku monitoruje stan aktyw każdej z nich.
• klienci banku sa identyfikowani poprzez numery. Bank przechowuje imię, nazwisko klienta oraz ulicę i miasto, w którym mieszka. Klienci mogą mieć konta, brać pożyczki, a także korzystać z usług określonego bankiera.
• Pracownicy są także identyfikowani przy pomocy numerów. Administracja banku przechowuje imię, nazwisko oraz numer telefonu każdego z nich. Każdy podwładny jest skojarzony ze swoim przełożonym poprzez numer pesel. Zbierane są także informacje dotyczące daty zatrudnienia pracownika, a co za tym idzie długości czasu zatrudnienia.
• bank oferuje dwa typy kont: oszczędnościowe oraz oszczędnościowo – rozliczeniowe. Kontem może zarządzać więcej niż jedna osoba. Również pojedynczy klient może posiadać kilka rachunków. Każde konto posiada swój unikatowy numer, ponadto bank przechowuje stan każdego z nich oraz daty dokonywanych na koncie transakcji, oczywiście wraz informacją kto ich dokonał. Prowadzona jest także statystyka ilości dokonywanych na każdym rachunku transakcji.
• pożyczka może zostać wzięta w jednym z banków przez jednego lub więcej klientów. Jest ona identyfikowana za pomocą swojego unikatowego numeru. Każdy kredyt jest monitorowany pod względem ilości pieniędzy pozostałych do spłacenia oraz wysokości rat. Numer pożyczki nie identyfikuje konkretnej raty, jednakże konkretna rata określa pożyczkę. Odnotowywana jest również data i kwota dokonanej wpłaty.

b. Określanie elementów logicznych (wraz z atrybutami):

• element: branża; atrybuty: nazwa, miasto, aktywa
• element: klient; atrybuty: imię, nazwisko, nr pesel, ulica, miasto, bankier.
• element: pracownik; atrybuty: nr pesel, nazwisko, nr tel., pensja, kierownik.
• element: konta; atrybuty: numer, stan.
• element: k. oszcz.; atrybuty: stopa procentowa.
• element: k. oszcz.- rozl.; atrybuty: przekroczenie limitu.
• element: kredyt; atrybuty: numer, kwota, miejsce pobrania.
• element: rata; atrybuty: numer, data wpłaty, kwota wpłaty.

c. Określanie relacji elementów:

• relacja: kredytobiorca - pomiędzy klientem a kredytem.
• relacja: kredytodawca - pomiędzy filią a kredytem.
• relacja: kredyt-rata - pomiędzy kredytem a ratą.
• relacja: depozytor - pomiędzy klientem a kontem.
• relacja: doradztwo - pomiędzy bankierem a klientami.
• relacja: zatrudnienie - pomiędzy pracownikiem a kierownikiem.

d. Diagram E-R dla przedsięwzięcia bankowego

2. Redukcja schematu E-R do tablic:

Baza danych która odpowiada schematowi E-R może być przedstawiona przez zbiór tablic. Dla każdego zbioru elementów i relacji w bazie danych istnieje osobna tabela o nazwie nawiązującego zbioru. Każda tabela zawiera kolumny, każda z nich ma inną nazwę.

Modele E-R oraz relacyjnej bazy danych są abstrakcyjne, są logicznymi reprezentacjami przedsiębiorstw realnego świata. Ponieważ te dwa modele kierują się podobnymi zasadami, możemy przetworzyć projekt E-R w relacyjny. Przetwarzając reprezentację bazy danych z diagramu E-R w tabele, jest podstawą wyprowadzania projektu relacyjnej bazy danych z diagramu E-R. Chociaż istnieją znaczne różnice pomiędzy relacją i tablicą, nieformalnie, relacja może być uważana za tablicę wartości.

1. tablicowa reprezentacja silnie związanych elementów

Niech E będzie zbiorem silnie związanych elementów, a a₁, a₂, ..., a_n będą atrybutami opisującymi te elementy. Możemy przedstawić ten zbiór tabelą E zawierającą n różnych kolumn, każda z nich nawiązuje do jednego z atrybutów E. Każdy wiersz w tej tabeli nawiązuje do jednego elementu ze zbioru elementów E.

Przykład:

Tabela “kredyt”

Numer kredytu	Kwota
L-17	1000
L-23	2000
L-15	1500
L-14	1500
L-93	500
L-11	900
L-16	1300

E – zbiór elementów typu “kredyt”

a₁- atrybut “numer kredytu”

a₂- atrybut “kwota”

Reprezentujemy ten zbiór przez tablicę o nazwie “kredyt”, z dwoma kolumnami. Wiersz: (L-17, 1000) w tablicy “kredyt” oznacza, że kredyt numer L-17 jest na kwote $1000. Możemy dodać nowy element do bazy danych przez wstawienie wiersza do tabeli. Możemy również skasować lub modyfikować wiersze.

Prykład II:

Tabela “klient”

Nazwisko klienta	Numer pesel	Ulica	Miasto
Rogoz	321-12-3123	Main	Harrrison
Szczypta	019-28-3746	North	Rye
Piekarz	677-89-9011	Main	Harrison
Sendrowicz	244-66-8800	North	Rye
Hara	336-66-9999	Park	Pittsfiled
Kowalski	182-73-6091	Putnam	Stamford
Nowak	963-96-3963	Nassau	Princeton
Wolak	335-57-7991	Spring	Pittsfiled
Smoleń	192-83-7465	Alma	Palo Alto

2. tablicowa reprezentacja słabo związanych elementów

Niech A będzie zbiorem silnie związanych elementów, a a₁, a₂, ..., a_m będą atrybutami opisującymi te elementy. Niech B będzie zbiorem silnie związanych elementów od których A jest zależny. Niech klucz podstawowy zbioru B składa się z atrybutów b₁, b₂, ..., b_n .Możemy przedsawić zbiór A tabelą tabelą A, w której jedna kolumna zawiera jeden atrybut ze zbioru:

{a₁, a₂, ..., a_m} È {b₁, b₂, ..., b_n}

Przykład: Tabela “rata”

Numer kredytu	Numer wpłaty	Data wpłaty	Kwota wpłaty
L-17	5	10.V.1996	50
L-23	11	17.V.1996	75
L-15	22	23.V.1996	300
L-14	69	28.V.1996	500
L-93	103	3.VI.1996	900
L-17	6	7.VI.1996	50
L-11	53	7.VI.1996	125
L-93	104	13.VI.1996	200
L-17	7	17.VI.1996	100
L-16	58	18VI.1996	135

A – zbiór elementów typu “rata”

a₁- atrybut “numer wpłaty”

a₂- atrybut “data wpłaty”

a₃- atrybut “kwota wpłaty”

b₁- atrybut “numer kredytu” - podstawowy klucz zbioru “kredyt” od którego zbiór

“rata” jest zależny.

3. tablicowa reprezentacja relacji

• redundancja tablic

Rozwarzmy zbiór relacji “many to one” AB ze zbioru elementów A do zbioru elementów B. Używając naszego schematu do tworzenia tablic, dostajemy trzy tablice: A, B i AB. Jednakże, jeżeli istnieje zależność A od B (dla każdego el. a z A, istnienie el. a zależy od istnienia niektórych el. zb. B), wtedy możemy połaczyć tabele A i AB, twożąc w ten sposób jedną tabelę zawierająca unie kolumn z obu tablic.

Przykład:

Zbiór relacji “konto-filia” jest typu “many to one” z zbioru “konto” do zbioru “filia”. Podwujna linia oznacza uczestnictwo zbioru “konto” w zbiorze relacji “konto-filia” jest całkowite. Ponadto, “konto” nie może istnieć bez przynależności do poszczególnej “filii”. W tym wypadku potrzebujemy dwóch tablic:

• “konto” z atrybutami “numer konta”, “stan” i “nazwa filii”
• “filia” z atrybutami “nazwa filii” , “miasto filii” i “aktywa”

1. wielowartościowe atrybuty

Dla wielowartościowego atrybutu M, tworzymy tabelę T, zawierającą kolumnę C, która nawiązuje do M, oraz kolumny nawiązujące do podstawowego klucza zbioru elementów lub relacji, którego M jest atrybutem.

Przykład:

Dla wielowartościowego atrybutu “zależne nazwisko”, twożymy tablice o tej nazwie, z kolumnami “znazwisko”, odnoszące się do “zależne nazwisko”, będącego atrybutem “pracownika”, i z kolumną “numer pesel pracownika”, reprezentującą podstawowy klucz zbioru “pracownik”. Każdy klient zależny od

pracownika jest przedstawiony w oddzielnym wierszu w tabeli.

2. tablicowa reprezentacja generalizacji

• “konto” atrybuty: “numer konta”, “stan”
• “konto oszczędnościowe” atrybuty: “numer konta”, “stopa procentowa”
• “konto rozliczeniowo-oszczędnościowe” atrybuty: “numer konta”, “przekroczenie limitu”

- Jeżeli generalizacja jest rozłączna i kompletna – żaden element nie jest członkiem dwóch zbiorów elementów niższego poziomu, natomiast należy do zbioru elementów wyższego poziomu, oraz jeżeli każdy element w zbiorze elementów wyższego poziomu jest również członkiem jednego ze zbioru elementów niższego poziomu – wtedy jest możliwa alternatywna reprezentacja. Nie twożymy żadnej tabeli dla zbioru elementów wyższego poziomu. Zamiast tego, Dla każdego zbioru elementów niższego poziomu, stworzyć tabele zawierającą dla każdego z atrybutów z tego zbioru oraz ze zbioru elementów wyższego poziomu kolumnę.

• “konto oszczędnościowe” atrybuty: “numer konta”, “stan”, “stopa procentowa”
• “konto rozliczeniowo-oszczędnościowe” atrybuty: “numer konta”, “stan”, “przekroczenie limitu”

Relacje “konta oszczędnościowego” oraz “konta rozliczeniowo-oszczędnościowego” nawiązujące do tych tablic mają “stan” jako podstawowy klucz.

1. tablicowa reprezentacja agregacji

• “klient” atrybuty: “nazwisko”, “numer pesel”, “miasto”, “ulica”
• “kredyt” atrybuty: “numer kredytu”, “kwota”
• “kredytobiorca” atrybuty: “numer pesel pracownika”, “nazwisko pracownika”, “nr telefonu”
• “kredyt-urzędnik”: atrybuty: “numer pesel”, “nr kredytu”, “numer pesel pracownika”