És az adatok
A relációs adatbázis olyan kapcsolatok gyűjteménye, amely tartalmazza az adatbázisban tárolt összes információt. Azonban a felhasználók észlelhetnek egy olyan adatbázist, mint a táblák gyűjteménye.
1. Minden tábla azonos típusú vonalakból áll, és egyedi névvel rendelkezik.
2. A karakterláncok meghatározott számú mezőt (oszlopokat) és értékeket tartalmaznak (több mező és duplikált csoport nem megengedett). Más szavakkal, a táblázat minden egyes pozíciójában egy sor és egy oszlop metszéspontjában mindig pontosan egy érték vagy semmi.
3. Az asztal sorai szükségképpen különböznek egymástól legalább egy értékkel, ami lehetővé teszi egy ilyen táblázat bármely sorának egyedi azonosítását.
4. A táblázat oszlopai egyedileg vannak kijelölve, és mindegyikben homogén adatértékeket (dátumok, vezetéknevek, egész számok vagy pénzösszegek) helyeznek el.
6. A táblákon végzett műveletek végrehajtásakor a sorok és oszlopok bármely sorrendben feldolgozhatók, függetlenül azok információtartalmától. Ezt megkönnyíti az asztalnevek és oszlopok jelenléte, valamint a vonalainak vagy vonalainak bármelyik vonalának kijelölése (például a "Paris" célállomással és legfeljebb 12 órás érkezési idővel).
Relációs adatok manipulálása
Egy relációs adatmodellt javasolva az EF Codd létrehozott egy eszközt a kapcsolatokhoz - a relációs algebra - való kényelmes munkavégzéshez. Ennek az algebranak az egyes műveletei operandusként egy vagy több táblázatot (kapcsolatokat) használnak, és ennek eredményeképpen új táblázatot hoznak létre. lehetővé teszi a "vágás" vagy "ragasztás" az asztalra.
Ábra. 3.3. A relációs algebra egyes műveletei
Az adatok manipuláció nyelveit hozták létre, amelyek lehetővé teszik a relációs algebra összes műveletének és szinte bármely kombinációjának végrehajtását. Ezek közül a leggyakoribbak az SQL (Structured Query Language-structured query language) és a QBE (Quere-By-Example -query by model). Mindkettő nagyon magas szintű nyelvekre utal, amelyeken keresztül a felhasználó meghatározza, hogy milyen adatokat szerezni, anélkül, hogy meghatározná őket.
Egyetlen lekérdezést használva bármelyik ilyen nyelv esetében bármelyik táblázatot egy ideiglenes táblahoz csatlakoztathatod, és kivághatod a szükséges sorokat és oszlopokat (kiválasztás és vetítés).
33. Adatmodellek. Az adatbázis tervezésének és univerzális arányának céljai. Normalizáció, funkcionális és többértékű függőségek.
Az egyes adatbázisok kombinálhatják az összes olyan adatot, amelyek egy vagy több alkalmazás megoldásához szükségesek, vagy bármilyen témához kapcsolódó adatok (például finanszírozás, diákok, tanárok, szakácsok stb.). Az előbbieket általában alkalmazás-adatbázisoknak nevezzük, míg a másodikakat "objektum adatbázisoknak" nevezzük (a szervezet objektumával, nem pedig információs alkalmazásával). (Az első összehasonlítható az anyagi, technikai és rekreációs alapokkal, az utóbbi pedig zöldség- és cipőalapokkal.)
Az objektum adatbázisok támogatják az aktuális és a jövőbeli alkalmazásokat, mivel az adatelemek egy csoportja magában foglalja az alkalmazott adatbázisok adatelemeit. Ennek eredményeképpen az objektumadatok létrehozzák az informatizált, változó és ismeretlen lekérdezések és alkalmazások feldolgozásának alapját (olyan alkalmazások, amelyeknél az adatigényeket nem lehet előre meghatározni). Az ilyen rugalmasság és alkalmazkodóképesség lehetővé teszi, hogy meglehetősen stabil információs rendszereket hozzanak létre tárgy adatbázisok alapján, azaz Olyan rendszerek, amelyekben a legtöbben megváltoztathatók anélkül, hogy felülírnák a régi alkalmazásokat.
A jelenlegi és előrelátható alkalmazások adatbázisának ugyanazon felépítésén alapulva jelentősen felgyorsítható egy igen hatékony információs rendszer létrehozása, pl. egy olyan rendszer, amelynek szerkezete figyelembe veszi az adatokhoz való hozzáférés legáltalánosabb módjait. De mivel az ilyen információs rendszerek alkalmazásainak száma nő, az alkalmazás adatbázisainak száma gyorsan növekszik, az adatok megkettőzésének szintje jelentősen megnő és a karbantartás költsége nő.
Így a tervezett megközelítések mindegyike befolyásolja a tervezést különböző irányban. A rugalmasság és a hatékonyság elérésének vágya egy olyan tervezési módszertan kialakulásához vezetett, amely mind a tárgyi, mind az alkalmazott megközelítést alkalmazza. Általánosságban elmondható, hogy a tárgyi megközelítés az eredeti információs struktúra felépítésére szolgál, és - az adatfeldolgozás hatékonyságának javítása érdekében - javítására szolgál.
A fő célja az adatbázis-tervező - ez csökkenti a redundanciát a tárolt adatok, és következésképpen a megtakarítási memóriahasználat, a költségek csökkentése több redundáns példányban a frissítési művelet és megszüntetése a lehetőségét, hogy egy konfliktus tárolás miatt különböző helyeken információt ugyanazon obekte.Tak úgynevezett A "tiszta" DB projekt ("Minden tény egy helyen") a kapcsolat normalizálásának módszerével hozható létre.
A tábla ezen változata nem kapcsolódik, hiszen a legtöbb sor nem atomi. Csak a Dish, View, Recept mezők értékei (bár nagyok), a részek és a dátum atomok. A többi mezőben a táblázatok plusz. Annak érdekében, hogy az ilyen adatok kapcsolatba kerüljenek, újra össze kell állítani a táblázatot. A legegyszerűbb módja egy egyszerű beillesztési folyamat. Az ilyen konverzió azonban nagy mennyiségű redundáns adatot eredményez.
A táblázat egy érvényes kapcsolat egy példánya. Ezt nevezzük a tervezett adatbázis egyetemes viszonyának. Az egyetemes kapcsolat magában foglalja az összes érdekeltséget, és tartalmazhat minden olyan adatot, amelyet a jövőben az adatbázisba kell helyezni. Kisméretű adatbázisok esetén (beleértve a 15 attribútumot is), egy univerzális kapcsolatot lehet kiindulási pontként használni az adatbázis tervezésében.
A normalizálás egy táblázatot kettő vagy több részre osztja, jobb tulajdonságokkal, amikor az adatok szerepelnek, módosíthatók vagy törölhetők. A normalizálás végső célja az, hogy olyan adatbázis-projektet kapjunk, amelyben minden tény csak egy helyen jelenik meg, azaz az információ redundanciája kizárt. Ez nem annyira a memória megtakarításának célja, hogy megszüntesse a tárolt adatok esetleges következetlenségét. Minden tábla egy relációs adatbázis megfelel annak a feltételnek, amely szerint azon a helyen, a kereszteződésekben a minden sorban és oszlopban az asztal mindig egyetlen atomi értéket, és soha nem lehet beállítani ezeket az értékeket. Bármelyik tábla, amely ezt a feltételt kielégíti, normalizálódik. Valójában nem normális táblázatok, azaz táblázatok tartalmazó ismétlődő csoportokat nem is engedélyezettek egy relációs BD.Vsyakaya normalizált tábla automatikusan tekinthető az első alkalom szokásos formában asztal, sokraschenno1NF. Így szigorúan a "normalizált" és az "1NF-ben található" kifejezés ugyanazt jelenti. A gyakorlatban azonban a „normalizált” gyakran használják szűkebb értelemben - a „teljesen normalizált”, ami azt jelenti, hogy a projekt nem sért alapelveket normalizatsii.Teper mellett 1NF lehet azonosítani, további szintek normalizálódása Másrészt pedig normál forma (2NF), harmadik normál forma (3NF) stb. Lényegében, az asztal az 2NF ha az 1NF és kielégíti, ezenkívül néhány további feltétel, amelynek lényege az alábbiakban ismertetünk. A táblázat 3NF-ben van, ha 2NF-ben van, és emellett egy további feltételnek is megfelel.
Így minden normál forma bizonyos értelemben korlátozottabb, de kedvezőbb, mint az előző. Ez annak a ténynek köszönhető, hogy az "(N + 1) - normális formája" nem rendelkezik az "N-edik rendes" formában sajátos vonásokkal. Az (N + 1) -es normál formában az N-edik normál formára vonatkozó további feltétel általános értelme ezeknek a vonzó tulajdonságoknak a megszüntetése.
A normalizáció elmélete egy vagy másik kapcsolat jelenlétén alapul, amely a tábla mezei között található. Kétfajta ilyen függőség definiálható: funkcionális és többértékű.
Függőségi függőség. Field a táblázatban funkcionálisan függ A mező ugyanabban a táblában, és csak abban az esetben, ha az adott időpontban az egyes különböző mezőértékekkel A, ott van szükség, csak egy a különböző értékek terén B. megjegyzés, hogy itt azt feltételezzük, hogy a mező A és B vegyületek lehetnek. Például a Dish táblában a Dish and View mezők funkcionálisan függenek a BL kulcstól, a 3. ábrán a Vendors táblában. 4.3 Az Ország mező funkcionálisan függ az összetett kulcstól (Vendor, City). Az utóbbi függés azonban nem funkcionálisan teljes, hiszen az ország funkcionálisan függ a kulcstól - a városi mezőtől - a teljes funkcionális függőségtől. A B mező komplett funkcionális függőséget mutat az A összetett mezőtől, ha funkcionálisan függ az A-tól, és nem függ az A mező bármely részhalmazától funkcionálisan.