Tekintsünk egy egyszerű példát, amely a legtöbb olvasó számára ismerős lehet: egy EGYETEM adatbázist hallgatókra, tárgyakra és eredményekre vontakozó információk karbantartására egy egyetemi környezetben. Az 1.2. ábra bemutatja az adatbázis szerkezetét és néhány példa adatot egy ilyen adatbázishoz. Az adatbázist öt állományba (fájlba) szervezzük, melyek mindegyike azonos típusú adatrekordokat tárol.^[1] A HALLGATÓ állomány az egyes diákokra, a TÁRGY állomány az egyes tárgyakra, a KURZUS állomány a tárgyak egyes kurzusaira vonatkozó adatokat tárolja, az INDEXSOR állomány azokat az eredményeket tárolja, amelyeket a hallgatók a különféle, általuk már teljesített kurzusokból elértek, míg az ELŐFELTÉTEL állomány az egyes tárgyak előfeltételeit tárolja.

1.2. ábra - Egy adatbázis, amely hallgatókról és tárgyakról tárol információkat.

Egy adatbázis definiálásához az egyes rekordokban tárolandó, különböző típusú adatelemek definiálásával meg kell adnunk az egyes állományok rekordjainak a szerkezetét. Az 1.2. ábrán minden egyes HALLGATÓ rekord tartalmazza a hallgató nevét, hallgatói azonosítóját, évfolyamát (1, 2, és így tovább) és szakját (PTI a programtervező informatikus szakon, GI a gazdaságinformatikus szakon, stb.) reprezentáló adatokat; minden egyes TÁRGY rekord tartalmazza a tárgynevet, tárgykódot, a kreditszámot és a tanszéket (amelyik a tárgyat hirdeti) reprezentáló adatot; és így tovább. Egy rekordon belül meg kell adnunk egy adattípust is minden egyes adatelemhez. Például megadhatjuk, hogy a HALLGATÓ neve egy alfabetikus karaktersorozat, a HALLGATÓ hallgatói azonosítója egy egész szám, az INDEXSOR érdemjegye pedig szintén egy egész szám (az {1, 2, 3, 4, 5} halmazból). Használhatunk egy kódolási sémát is egy adatelem értékének a reprezentálására. Például az 1.2. ábrán 1-es érték reprezentálja egy elsőéves, 2-es egy másodéves, 3-as egy harmadéves, 4-es egy negyedéves, 5-ös pedig egy ötödéves HALLGATÓ évfolyamát.

Az EGYETEM adatbázis elkészítésekor az egyes hallgatókat, tárgyakat, kurzusokat, indexsor-bejegyzéseket és előfeltételeket egy-egy rekordként tároljuk a megfelelő állományban. Megjegyzendő, hogy a különféle állományokban lévő rekordok kapcsolatban állhatnak egymással. Például a Kovácsra vonatkozó rekord a HALLGATÓ állományban két rekordhoz kapcsolódik az INDEXSOR állományban, amelyek megadják Kovács eredményeit két kurzusból. Hasonlóan, minden egyes rekord az ELŐFELTÉTEL állományban két tárgy rekordhoz kapcsolódik: az egyik a tárgyat reprezentálóhoz, a másik az előfeltételt reprezentálóhoz. A legtöbb közepes vagy nagy méretű adatbázis sokféle típusú rekordot tartalmaz, és számos kapcsolat létezik bennük a rekordok között.

Az adatbázis manipulációja a lekérdezést és a frissítést foglalja magában. Lekérdezésekre példák a következők:

A frissítési példák a következőket foglalják magukba:

Ezeket az informális lekérdezéseket és frissítéseket a DBMS lekérdező nyelvében pontosan definiálni kell, mielőtt végrehajthatnánk őket.

Ezen a ponton célszerű az adatbázist egy nagyobb egység, egy szervezeten belüli információs rendszer részeként leírni. Egy vállalaton belül az Információtechnológia osztály tervezi meg és tartja karban az információs rendszert, amely különféle számítógépekből, tárolóeszközökből, alkalmazói szoftverekből és adatbázisokból áll. Egy létező adatbázishoz egy új alkalmazás tervezése, vagy egy új adatbázis tervezése a követelménydefiníciónak és analízisnek nevezett fázissal indul. Ezeket a követelményeket részletesen dokumentálják, majd átalakítják egy koncepcionális tervvé , amelyet számítógépes eszközökkel lehet reprezentálni és kezelni, ezáltal könnyen karbantartható és módosítható lesz, valamint könnyen át lehet alakítani egy adatbázis-implementációvá. A 3. fejezetben bemutatunk egy modellt, amely ezt a célt szolgálja, és amelyet egyed-kapcsolat modellnek nevezünk. A tervet ezután átalakítják logikai tervvé , amelyet egy kereskedelmi DBMS-ben implementált adatmodellel lehet kifejezni. Ebben a jegyzetben az 5. fejezettől kezdődően a relációsnak nevezett adatmodellre helyezzük a hangsúlyt. Jelenleg ez a legnépszerűbb megközelítése az adatbázisok tervezésének és implementálásának a (relációs) DBMS-ek körében. Az utolsó fázis a fizikai tervezés , amelynek során további specifikációkat adnak az adatbázis tárolására és elérésére vonatkozóan. Az adatbázistervet implementálják, feltöltik tényleges adatokkal, és folyamatosan karbantartják, hogy híven tükrözze a minivilág állapotát.