Pytanie: Jak przed erą komputerów wyglądały bazy danych?
Odpowiedź: Dane były przechowywane w formie dokumentów papierowych składowanych w archiwach.

Pytanie: Czy po wejściu do użytku komputerów komputerowych baz danych, zaniechano składowania dokumentów w formie papierowej?
Odpowiedź: Nie.

Pytanie: Dlaczego nie zaprzestano składować dokumentów papierowych w archiwach?
Odpowiedź: Wbrew pozorom papier jest bardziej trwałym nośnikiem od różnorakich nośników komputerowych, czy to dyski twarde, pamięci FLASH, taśmy magnetyczne albo nośniki optyczne. Zauważcie, że wszystkie umowy, które podpisujecie są podpisywane na papierze i jedną kopię dostajecie Wy, a drugą przechowuje w archiwum instytucja, osoba z którą to podpisaliście umowę. Dopiero później, w niektórych przypadkach wcześniej, jest ta informacje wprowadzana do komputerowej bazy danych.

Pytanie: To w takim razie co dają nam komputerowe bazy danych?
Odpowiedź: Komputerowe bazy danych dają nam możliwość szybkiego przeszukiwania takiej bazy danych, wybierania interesujących nas informacji, pozwalają na łatwe wykonywanie obliczeń, szybkie porządkowanie danych. Kolejną zaletą jest możliwość przechowywania dużych ilości danych na małej powierzchni.

Pytanie: A czy komputerowe bazy danych mają jakieś wady?
Odpowiedź: Tak. Jedną z wad komputerowych baz danych jest ich stosunkowo mały rozmiar. Chodzi mianowicie o możliwość wykradzenia źle lub słabo zabezpieczonych danych. Kiedyś zapewne słyszeliście o wykradzeniu danych setek a nawet tysięcy klientów jakiejś firmy. Ukraść archiwum składające się tysięcy segregatorów już nie jest takie łatwe i szybkie. Jedynym wyjściem jest dobrze zabezpieczyć dostęp do takiej bazy. Polecam czytać portal niebezpiecznik.pl, który informuje czytelników o nowych zagrożeniach czyhających w Internecie, opisuje je i podpowiada jak się przed nimi uchronić lub co zrobić jeżeli padliśmy ich ofiarą. Piszą również o wyciekach danych klientów firm / instytucji, czyli kradzieży danych.

Definicja: Co to jest baza danych?
Baza danych to zbiór wzajemnie powiązanych i uporządkowanych danych z określonej dziedziny tematycznej zorganizowany w sposób ułatwiający do nich dostęp.

Definicja: Co to jest system zarządzania bazą danych?
System zarządzania bazą danych jest to program zarządzający danymi w bazie danych.

Typy SZBD: Większość obecnie spotykanych systemów działa w trybie klient – serwer, gdzie baza danych jest udostępniania klientom przez SZBD będący serwerem. Serwer bazy danych może udostępniać dane klientom bezpośrednio lub poprzez inny serwer, np. poprzez serwer WWW lub serwer aplikacji.Istnieją również SZBD bez podziału na klienta i serwer i nie muszą być współdzielone przez wielu użytkowników jednocześnie. Takim SZBD jest Microsoft Access.

Najważniejsze zadania SZBD:

• zapewnienie integralności i bezpieczeństwa danych,
• odtworzenie zawartości bazy danych po awarii,
• dostęp do danych poprzez język zapytań,
• autoryzacja dostępu do danych,

Definicja: Co to jest system bazy danych?
System bazy danych jest to baza danych i system zarządzania bazą danych.

U podstaw konstruowania bazy danych leży założenie, że użytkownik, dla którego ta baza jest przeznaczona, nie musi być specjalistą z dziedziny baz danych. Może nawet w ogóle ich nie znać. Mimo to powinien bez problemów radzić sobie z obsługą zaprojektowanej bazy danych. Aby było to możliwe, podstawą tworzonej bazy musi yć solidny projekt określający potrzeby użytkownika dotyczące gromadzenia, przechowywania, przetwarzania danych oraz definiujący czynności składające się na obsługę bazy danych.

Zadanie: Podaj przykłady możliwych zastosowań bazy danych.
Odpowiedź: sklepy internetowe, rejestr PESEL, rejestr pacjentów, rejestr skazanych, ewidencja uczniów szkoły, rezerwacje w hotelach, rezerwacje miejsc w samolotach, sprzedaż biletów na miejsca w kinie, katalog biblioteczny, obsługa magazynów, książka telefoniczna.

Systemy o architekturze klient – serwer to m.in.: PostgreSQL, Oracle, MySQL, Microsoft SQL Server, MariaDB.

Istnieją również SZBD bez podziału na klienta i serwer i nie muszą być współdzielone przez wielu użytkowników jednocześnie. Takim SZBD jest Microsoft Access.

Każda dziedzina, tak jak i bazy danych mają swoje fachowe określenia na konkretne elementy bazy danych. Dzisiaj się zajmiemy podstawowymi pojęciami z dziedziny baz danych.

encja – reprezentacja wyobrażonego lub rzeczywistego obiektu lub grupy obiektów, stosowana przy modelowaniu danych. Encją może być osoba, samochód, książka. Encja zawiera w sobie cechy (atrybuty) obiektu, który tworzy.

relacja – wydzielony logicznie zbiór danych, zorganizowany w formie tabeli składającej się z wierszy dzielonych na kolumny. Jest to obiekt teoretyczny i nie należy go mylić z jej graficzną reprezentacją, czy miejscem zajmowanym w pamięci komputera. W zależności od typu bazy danych wewnętrzna organizacja podziału danych na kolumny i wiersze jest różna i często umowna.

krotka – w relacyjnych bazach danych jest to jeden wiersz w tabeli, czyli jedna krotka w relacji.

atrybut – można zdefiniować jako kolumna relacji mająca identyfikator (nazwę).

dziedzina – jest zbiorem wartości, jakie może przyjąć atrybut krotki. Jeżeli kolumna ma przechowywać numer PESEL osoby to wtedy wystarczy 11 znaków tekstu, płeć – może to być wartość boolean, czyli prawda, fałsz, lub 1 znak tekstu (k,m). Należy zawsze tak dobrać dziedzinę, żeby nie „zostawało” puste miejsce.

klucz główny – wybrany minimalny zestaw atrybutów relacji, jednoznacznie definiujący każdą krotkę tej relacji. Klucz główny musi przyjmować wyłącznie wartości niepowtarzalne i nie może być wartością pustą (null). Każda relacja może mieć co najwyżej jeden klucz główny. Bardzo często klucz główny jest tworzony z tzw. autonumeracji. W ten sposób nie ma możliwości, aby klucz główny się powtórzył. Nad tym procesem czuwa system bazy danych.

klucz kandydujący – inaczej klucz potencjalny. Minimalny zestaw atrybutów relacji, jednoznacznie definiujący każdą krotkę tej relacji W relacji może znajdować się wiele kluczy kandydujących. Spośród kluczy potencjalnych wybiera się zazwyczaj jeden klucz zwany kluczem głównym. Przykładem może być numer PESEL, który się unikatowy dla każdego Polaka. W tej samej relacji może się również znaleźć atrybut z autonumeracją jako klucz główny.

klucz obcy – kombinacja jednego lub wielu atrybutów tabeli, które wyrażają się w dwóch lub większej liczbie relacji. Wykorzystuje się go utworzenia relacji pomiędzy parą tabel, gdzie w jednej tabeli ten zbiór atrybutów jest kluczem obcym, a w drugiej kluczem głównym

klucz prosty – jest to klucz, który składa się z jednej kolumny.

klucz złożony – jest to klucz, który jest kilkuelementowy (składa się z więcej niż jednej kolumny)

Aby przechowywać dane na komputerze, konieczne jest określenie formy ich przechowywania. Na potrzeby baz danych zostały zdefiniowane klasyczne techniki organizowania informacji, zwane modelami baz danych.

Modele baz danych:

• Jednorodny – model w którym wszystkie dane są umieszczone w jednej tabeli, jednym arkuszu (kostce analitycznej). Przykładem jest książka telefoniczna. Cechuje go łatwość i szybkość odczytywania danych, wadą natomiast jest duża liczba duplikatów, które mogą się pojawiać i zwiększać zużycie zasobów komputera. Dane w tym modelu nie zawsze będą łatwe do odnalezienia. Opierając się na przykładzie książki telefonicznej łatwo znaleźć numer telefonu szukając po nazwisku i imieniu, ale znalezienie nazwiska mając numer telefonu jest bardzo trudne. Książka telefoniczna zawiera dane ułożone wg nazwisk i nie jest zoptymalizowana pod kątem wyszukiwania nazwisk poprzez numer telefonu.
• Hierarchiczny – w tym modelu przechowywane dane są zorganizowane w postaci drzewa. Informacja jest zawarta w dokumentach oraz strukturze drzewa. W hierarchicznym modelu danych nie można wstawić rekordu podrzędnego, dopóki nie zostanie powiązany z nadrzędnym. Usunięcie rekordu nadrzędnego powoduje usunięcie wszystkich rekordów podrzędnych.

Model hierarchiczny

• Sieciowy – Połączenia między dokumentami tworzą sieć. Informacja jest zawarta w dokumentach oraz w przebiegu połączeń sieci. Jest to model bardzo podobny do hierarchicznego z tą różnicą, że gałęzie jednego drzewa mogą być wspólne z gałęziami innych drzew.

Model sieciowy

• Obiektowy – łączy cechy programów komputerowych tworzonych w językach programowania obiektowego z cechami aplikacji bazodanowych. Obiekt w bazie reprezentuje obiekt w świecie rzeczywistym.
• Relacyjny – w tym modelu danych informacja jest zapisywana w tabeli w formie wierszy. Tabele tworzą powiązania między sobą zwane relacjami. Rysunek z poprzednich zajęć. Ze względu na funkcjonalność relacyjny model danych jest najczęściej wykorzystywany przy projektowaniu baz danych.

Iloczyn kartezjański jest to prostolinijny układ współrzędnych o parach prostopadłych osi. Nazwa pojęcia pochodzi od łacińskiego nazwiska francuskiego matematyka i filozofa Kartezjusza.

Iloczynem kartezjańskim prostej A i prostej B będzie zbiór punktów płaszczyzny zawartej między nimi (każdy punkt należący do tej płaszczyzny). Idąc tym tokiem myślenia, jeżeli będziemy mieć dwa zbiory A i B, to iloczynem kartezjańskim tych zbiorów będzie taki zbiór C, w którym każdy element A będzie połączony z każdym elementem B.

Iloczyn kartejański zbiorów

Zdefiniujemy teraz relację. Relacją nazywamy podzbiór iloczynu kartezjańskiego. Niech podzbiorem dla naszego przykładu będą [1 – Jacek, 2 – Ewa]. Jeśli umieścimy te elementy w tabeli otrzymamy:

Podzbiór iloczynu kartezjańskiego

Dlatego w relacyjnych bazach danych relacją nazywa się tabele bazy danych, ponieważ zawartość tabeli ulega ciągłym zmianom. Kolumny to atrybuty. Mogą przechowywać wartości określonych typów, jednak wartości te mogą być modyfikowane.

W większości opracowań dotyczących baz danych pojęcie relacja odnosi się do tabeli w relacyjnej bazie danych. Problemem teorii baz danych jest stosowanie terminu relacja również do związków, które występują pomiędzy tabelami np.: relacja jeden do wielu. W efekcie przyjęcia takiego nazewnictwa, gdy chcemy powiedzieć, że pomiędzy tabelą A i tabelą B występuje związek jeden do wielu, mówimy, że pomiędzy relacją A a relacją B występuje relacja jeden do wielu. I tutaj można zauważyć, że tak nazywając table można przyjąć, że relacja jeden do wielu jest tabelą. Dlatego też tabele są nazywane relacjami, a związki między tymi tabelami to np.: związek jeden do wielu, związek jeden do jednego.

Projektując bazę danych, dzielimy dane na wiele tabel tematycznych, tak aby każda informacja została zapisana tylko raz. Aby zestawić razem dane zapisane w różnych tabelach, tworzy się między nimi połączenia zwane relacjami.

Relacja – jest to zdefiniowanie logicznego połączenia między tabelami baz danych.

Typy relacji:

• Relacja „jeden do jednego” – każdemu rekordowi z pierwszej tabeli może odpopwiadać tylko jeden rekord z drugiej tabeli i każdemu rekordowi z drugiej tabeli może odpowiadać tylko jeden rekord z pierwszej tabeli. Jest to nietypowy rodzaj relacji, ponieważ najczęściej informacje powiązane w ten sposób są przechowywane w jednej tabeli ze względu na bezpieczeństwo danych lub w celu podzielenia zbioru danych na podzbiory.

Relacja „jeden do jednego”

• Relacja „wiele do jednego” – każdemu rekordowi z pierwszej tabeli może odpowiadać najwyżej jeden rekord z drugiej tabeli, a każdemu rekordowi z drugiej tabeli może odpowiadać wiele rekordów z pierwszej tabeli. Jest to typ relacji najczęściej występujący w relacyjnych bazach danych.

Relacja „wiele do jednego”

• Relacja „wiele do wielu” – każdemu rekordowi z pierwszej tabeli może odpowiadać wiele rekordów z drugiej tabeli i każdemu z rekordów z drugiej tabeli może odpowiadać wiele rekordów z pierwszej tabeli. Aby ta relacja mogła istnieć potrzebujemy utworzyć trzecią tabelę tabelę – łącznikową.

Relacja „wiele do wielu”

Obrazy pochodzą ze strony internetowej http://www.sqlpedia.pl/relacyjne-bazy-danych-pojecia-podstawowe

Pojęcie: Integralność danych: inaczej spójność danych, jest to funkcja w SZBD, która gwarantuje, że dane nie zostaną usunięte lub zmienione w nieautoryzowany sposób. W SZBD powinny istnieć mechanizmy, które pozwolą zabezpieczyć dane przed skutkami awarii zasilania, sprzętu lub oprogramowania. Zachowanie spójności danych powinny gwarantować systemy chroniące dane również przed błędami pojawiającymi się w chwilach współbieżnego dostępu do tej samej informacji.

Pojęcie: Integralność semantyczna polega na utrzymaniu ograniczeń nakładanych na dane m.in.:

• w określonej kolumnie tabeli muszą znajdować się wyłącznie dane zgodne z typem danych kolumny, np. tylko liczby całkowite
• w kolumnie nie mogą występować braki wartości – puste miejsca NULL

Pojęcie: Integralność referencyjna polega na wprowadzeniu i utrzymaniu powiązań pomiędzy tabelami. Związki te tworzy się przez umieszczenie kolumny pełniącej rolę klucza głównego tabeli w innej tabeli, co nadaje kolumnie funkcję klucza obcego. Reguły integralności referencyjnej determinują, czy wartości klucza obcego mają odpowiadać wartościom klucza głównego (powiązanej tabeli), czy mogą przyjmować wartości NULL.

Pojęcie: Ograniczenia integralności statyczne odnoszą się do bieżącego stanu bazy danych, np. na kolumnę wiek zostało nałożone takie ograniczenie CHECK (wiek<200). Nałożenie tego ograniczenia podczas tworzenia tabeli spowoduje, że w kolumnie wiek wartość nigdy nie będzie większa niż 200 w trakcie nakładania ograniczenia i w przyszłości.

Pojęcie: Więzy integralności dynamiczne to takie, które przeciwdziałają zmianom, ponieważ związane są z przejściem bazy danych z jednego stanu w drugi. Oznacza to, że odnoszą się do bazy danych w aspekcie temporalnym. Przykładem takich więzów może być wymaganie, aby wiek pracowników nigdy nie malał. Jeżeli wiek pracownika po pewnym czasie wzrośnie, to wartość kolumny wiek nie może nigdy się zmniejszyć, ponieważ nikt nie staje się młodszy. Więzy dynamiczne nazywane są również więzami przejść.

Ochrona integralności danych polega również na zapewnieniu, że dane nie ulegną zniekształceniu podczas wykonywania na nich operacji. Spójność danych związana jest z ich dokładnością – dane dokładnie odzwierciedlają modelowaną rzeczywistość. Oznacza ona również ich prawdziwość oraz aktualizowanie, gdy zmienia się rzeczywistość modelowana w bazie danych.

Do tworzenia modelu graficznego schematu bazy danych wykorzystywane są diagramy związków encji, z których najpopularniejsze są diagramy ERD (ang. Entity Relationship Diagram). Pozwalają ona na modelowanie struktur danych oraz związków zachodzących między tymi strukturami. Nadają się szczególnie do modelowania relacyjnych baz danych, ponieważ umożliwiają prawie bezpośrednie przekształcenie diagramu w schemat relacyjny.

• zbiorów encji,
• atrybutów encji
• związków zachodzących między encjami.

Encja to reprezentacja obiektu przechowywanego w bazie danych.

Graficzna reprezentacja encji

Atrybut opisuje encję. Może on być liczbą, tekstem lub wartością logiczną

Atrybut encji Klient

Związek jest to powiązanie między dwiema lub kilkoma encjami. Każdy związek ma dwa końce, do których są przypisane następujące atrybuty:

• nazwa,
• stopień związku
• uczestnictwo lub opcjonalność związku. Atrybut ten określa, czy związek jest opcjonalny, czy wymagany

Graficzna reprezentacja związków zachodzących między encjami

Graficzna reprezentacja opcjonalności związku

Diagramy ERD spotyka się w wielu różnych notacjach, np. Martina, Bachmana, Chena, IDEFIX. Istnieje wiele narzędzi wspomagających rysowanie diagramów ERD, ale jedynie w przypadku narzędzi klasy CASE (ang. Computer Aided Software Engineering) można mówić o określonej notacji.

Prosty przykład diagramu ERD w notacji Martina dla księgarni internetowej.

Pierwszą zasadą jest nawyk minimalizacji rozmiaru danych przechowywanych w bazie danych. Zrealizowanie tego punktu polega, najprościej mówiąc, na redukowaniu zbędnych danych oraz zapewnieniu ich integralności. Przechowywanie tych samych danych w jednym miejscu, w jednym rekordzie minimalizuje szanse, że jakaś wersja tej danej będzie niepoprawna. A jeśli nawet w trakcie jej użytkowania dojdzie do tego, że któraś wartość zostanie niepoprawnie wprowadzona, zostanie ona wyświetlona we wszystkich miejscach w ten sam sposób, przez co łatwiejsze będzie wychwycenie błędu.

Drugim aspektem, na który warto zwrócić uwagę, jest rozłożenie większych zbiorów danych na mniejsze, powiązane ze sobą elementy. Podział na mniejsze tabele, a następnie relacyjne ich połączenie sprawi, że nie usuniemy przez przypadek danej, którą uważaliśmy za niepotrzebną, a która – jak się okazuje – ma powiązania z innym elementem. Jeśli cała baza danych podzielona jest na mniejsze części, to jeśli zajdzie potrzeba przywrócenia jakiegoś jej elementu, nie trzeba będzie przywracać całej bazy danych, a wystarczy kawałek, w którym znajduje się ten element.  Dodatkowo, aby zapewnić lepszą integralność danych niezbędne jest zdefiniowanie, jaki typ danych chcemy przechowywać w danej kolumnie. Chodzi o to, żeby uniemożliwić wpisanie litery tam, gdzie jakaś wartość przyjmuje tylko liczbową postać, co uczyni już na starcie bazę danych bardziej poprawną, a to z kolei podniesie jej integralność.

Wiemy już, jakie cechy powinien posiadać dobry projekt, a więc zajmijmy się przez chwilę tabelami i określaniem pól, z których się ona składa. Zacznijmy od tego, że tabela jest zbiorem informacji na jeden określony temat. Dzięki tej cesze jesteśmy w stanie przetwarzać jedno zagadnienie niezależnie od danych dotyczących innych zagadnień. Na przykład, jeśli wyobrazimy sobie bazę danych sklepu, to adresy klientów przechowywalibyśmy w innej tabeli, niż informacje na temat zamówień. W ten sposób możliwe jest usunięcie konkretnego zamówienia, zachowując dane o kliencie nie zmienione. Jeśli właśnie w taki sposób określimy tabele, to w następnym kroku możemy zabrać się za określanie pól w tabeli. Pole zawiera więc jedną daną dotyczącą tego zagadnienia, któremu poświęcona jest tabela. Dobrym nawykiem podczas definiowania pól jest pamiętanie o tym, aby:

• przechowywać informacje w możliwie najmniejszych jednostkach logicznych (np. imię i nazwisko jako osobne pola, a nie jako jedno pole – nazwa użytkownika),
• nie należy tworzyć pól zawierających dane pośrednie lub obliczone (dane, które są wynikiem wyrażenia, uzyskuje się za pomocą kwerend, ale nie przechowuje się bezpośrednio w bazie danych – jest to zły nawyk),
• każde pole powinno być powiązane bezpośrednio z zagadnieniem, którego dotyczy tabela.

Po zakończeniu określania zawartości kolumn w każdej tabeli możemy przystąpić do wyboru klucza podstawowego.
Klucz podstawowy służy do powiązania informacji przechowywanych w różnych tabelach. Na przykład, aby powiązać klienta ze wszystkimi jego zamówieniami, każda tabela w bazie danych musi zawierać pole lub zbiór pól, które jednoznacznie określają każdy wiersz w tej tabeli (po to, żeby np. określić jednoznacznie danego klienta lub konkretne zamówienie). Kluczem podstawowym nie mogą być duplikujące się wartości, takie jak imiona czy nazwiska, ponieważ takie dane mogą się powtórzyć. Unikatowym natomiast może być numer produktu czy zamówienia. Zazwyczaj rolę klucza podstawowego odgrywa dowolny unikatowy numer, a służy on wyłącznie do identyfikowania danego produktu czy zamówienia. Numer ten zostaje określony raz i nigdy się nie zmienia dla danego produktu, co sprawia, że jednoznacznie go określa.

Kiedy wszystko wydaje się już praktycznie gotowe, oznacza to, że przyszedł czas na udoskonalanie projektu. W tym kroku będziemy sprawdzać, jak sprawują się jego poszczególne elementy. Uzupełniamy tabele o przykładowe dane, a na ich podstawie wykonujemy próbne operacje, tworzymy kwerendy, dodajemy nowe rekordy itp. Dzięki temu będziemy w stanie zlokalizować potencjalne problemy. Może okazać się, że w tabelach występują zduplikowane dane, że istnieje niepotrzebna tabela lub zastosowaliśmy złą relację do ich połączenia. Przed nami dokładne sprawdzenie projektu pod kątem wszelkich błędów. Warto stworzyć robocze wersje raportów czy formularzy i sprawdzić, czy generują one odpowiednie dane. Wychodząc z założenia, że nie myli się jedynie ten kto nic nie robi, prawdopodobnie w naszym projekcie nie unikniemy początkowych błędów. Ażeby zmaksymalizować funkcjonalność bazy danych, warto odpowiedzieć sobie na szereg pytań, które mogą wydać się trywialne, ale kto wie, czy nie zaoszczędzą nam wiele czasu przy wyszukiwaniu usterki, kiedy po wdrożeniu aplikacji okaże się, że jednak coś nie działa. Warto również wrócić do początkowego szkicu z kartki papieru i sprawdzić, na ile odpowiada on obecnemu projektowi. Przykładowe pytania mogą wyglądać np. tak:

• Czy nie zapomniałem jakiejś kolumny? Jeśli tak, to czy jestem w stanie ją wrzucić do już istniejącej tabeli? Jeśli tak, to świetnie, a jeśli nie – to trzeba będzie dodać nową tabelę i na nowo przeanalizować jej powiązania z innymi tabelami.
• A może któraś kolumna jest zbędna? Jeśli tak, to po jej usunięciu zaoszczędzimy trochę cennego miejsca.
• Czy przypadkiem informacji zawartych w tej kolumnie nie mogę obliczyć na podstawie innych tabel? Jeśli tak, po co je duplikować? Zazwyczaj lepiej jest obliczać te wartości, stosując np. kwerendy (jeśli to tylko możliwe), niż tworzyć nową kolumnę.
• Czy wszystkie informacje rozbiłem na najmniejsze, użyteczne części? Wiadomo przecież, że nie ma sensu rozbijać np. nazwy produktu „Wąż od pralki” na trzy kolumny: „Wąż” „od” „pralki” albo na węża i pralkę, bo to jedynie skomplikuje naszą bazę danych. Jeśli ten aspekt jest dopracowany, możemy śmiało tworzyć raporty, sortować i wyszukiwać.
• Czy wszystkie kolumny danej tabeli rzeczywiście zawierają informacje dotyczące dokładnie tematu tej tabeli? Jeśli nie, to dla porządku oraz uniknięcia problemów w przyszłości należy taką kolumnę przenieść do innej tabeli.

Ostatnim etapem weryfikacji poprawności projektu bazy danych jest sprawdzenie, czy umożliwia ona wszystkie podstawowe funkcje:

• projektowanie rekordów:
  • nazwa pola,
  • długość pola,
  • rodzaj pola (tekstowe, liczbowe, logiczne),
• edycja (dopisywanie, usuwanie, poprawianie rekordów),
• sortowanie,
• wyszukiwanie i selekcja danych,
• tworzenie zapytań,
• tworzenie raportów,
• drukowanie.

Planowanie bazy danych, niezależnie od jej rozmiaru i złożoności, składa się następujących podstawowych kroków:

• zbieraniu informacji,
• identyfikowanie obiektów,
• określaniu informacji dla każdego obiektu,
• tworzeniu relacji między obiektami

Zbieranie informacji. Przed utworzeniem bazy danych, trzeba wiedzieć czego oczekuje się od bazy danych i jakie zadania ma wykonywać. Jeżeli baza danych ma zastąpić przesył informacji w formie papierowej należy rozpocząć od rozmowy ze wszystkimi osobami zaangażowanymi w ten przepływ. na tym etapie trzeba spróbować określić problemy, ograniczenia i wąskie gardła. Należy również zebrać kopie dokumentów jakie uczestniczą w przesyle informacji papierowej.

Identyfikowanie obiektów. W procesie zbierania informacji musimy określić jakie obiekty, podmioty będą zarządzane przez bazę danych. Obiekt może być materialny taki jak osoba czy produkt, ale również może być niematerialny jak na przykład transakcja biznesowa, dział firmy lub okres listy płac. Dla każdego obiektu będzie tworzona odpowiednia tabela.

Określanie danych dla każdego obiektu. Jak już mamy dane odnośnie jakie obiekty trzeba zawrzeć w bazie danych to na tym etapie określamy jakie atrybuty będzie mieć każdy z obiektów (encji). Dla pracownika możemy określić na przykład: identyfikator, imię, nazwisko, data urodzenia, adres, stanowisko.

Tworzenie relacji między obiektami. Ostatnim z etapów planowania bazy danych jest ustanowienie powiązań pomiędzy poszczególnymi obiektami (encjami).

Narzędzia CASE (ang. Computer Aided Software Engineering) są wykorzystywane podczas projektowania różnego rodzaju oprogramowania, najczęściej wspomagają proces jego wytwarzania.

Narzędzia te pozwalają tworzyć modele graficzne odpowiadające konstrukcjom programistycznym. Wykorzystywane są tutaj edytory notacji graficznych, które dają możliwości tworzenia diagramów oraz powiązań pomiędzy poszczególnymi elementami. Bardziej zaawansowane edytory umożliwiają przetwarzanie informacji udostępnianie danych do aplikacji zewnętrznych, na przykład kodów w Visual Basicu, SQL-u.

Narzędzia CASE mogą być stosowane do generowania kodu na podstawie zaprojektowanego modelu danych, można również za ich pomocą, na podstawie analizy kodu źródłowego odtworzyć projekt i specyfikację bazy danych

Przykładem takiego narzędzia jest program DBDesigner4. Jest to narzędzie do wizualnego projektowania, modelowania i tworzenia baz danych. Program został stworzony z myślą o bazie MySQL, ale również obsługuje inne np.: Oracle, SQLite, MS SQL. Jest rozpowrzechniany jako open source i jest dostępny na stronie http://fabforce.eu/dbdesigner4/

Program DBDesigner4 jest już niewspierany. Następcą tego programu jest MySQL Workbench