Informatikai állások
Ma fogunk beszélni részletesen a táblázatok Access.
Emlékezzünk arra, hogy már tudjuk, a táblákat.
1. (Key)
Minden bejegyzés a táblázatokban vannak számlálva. Erre a célra egy speciális területen (ez jobb, ha nem a legelső hívást és id). Az a fajta ezen a területen - számláló. Counter minden új rekord automatikusan ad egy új sorszámot. Ez a szám nem lehet törölni, nem tudja megváltoztatni (csak próbálja meg!).
Ha kivesszük a táblázat bejegyzés (pl Id = 12 - egy kiskutya Teddy, amikor megbetegedett, és nem tudott részt venni a kiállításon), akkor, ha visszanyeri, és újra hozzá Teddy a táblázatban, Id ő lesz mások 1 több, mint az utolsó rekord a táblázatban.
Ez biztosítja, hogy az azonosítók egy táblázatban minden esetben nem egyezik. Ellenkező esetben, akkor megszűnik a azonosítójával!
Ennek következtében lehetetlen, hogy megfeleljen a szám azonosítók lakások, kiállítási nomerki kutyák; Bejegyzéseket szerint rendezve Id nem feltétlenül kell menni ábécé sorrendben, dátum és idő emelkedő. Más szóval, Id szállítására nincs értelmes értelme. Ők csak akkor van szükség, hogy kapcsolatot teremtsen a rekordok a táblázatokban.
2. elnevezési szabályai
Nevei táblák és mezők a táblázatokban (és a nevét lekérdezések, űrlapok, jelentések és makrók) angol nyelven írt, szóköz nélkül (a aláhúzás dog_age vagy minden szó nagybetűvel DogAge). Mielőtt a nevét a táblázat kerül előtag TB ... Tehát, bejegyzéseket válnak olvasható (például tbDog.BirthDate), és nincsenek problémák a kódolási cirill.
Azt kell mondanom, hogy a hozzáférés nem szabad írni cirill nevek és terek. Ahhoz, hogy a neveket terek nem „terjed ki”, akkor automatikusan belép őket szögletes zárójelben ilyen :. [Dog Show] [Fontos tudnivalók 1]. De úgy néz ki szakszerűtlen és nehéz vizuális észlelés neveket.
3. A kapcsolatok táblák között
Két alapvető típusa a táblák közötti kapcsolatok: a "one-to-many" és a "sok-sok". Ne feledje, a példában az előző leckét?
kutyatulajdonosok, kutyafajták
Csak egy tulajdonos minden kutyát, de az egyik tulajdonos lehet több kutya
minden bíró felveti az értékelés több kutya, és minden kutya megkapja az értékelés több bíró
Táblázat (tbDog) hozzon létre egy további mező PersonId és írjon a tulajdonos minden kutya Id
hozzon létre további táblázatok tbMark (becslés), és felsorolja párban: Mit becslést tesz egy ilyen bíró ilyen kutya
Illusztráció "one-to-many" kommunikáció:
Illusztráció „sok-sok” kommunikáció:
4. Tervezési mód
Tervező nézetben kérjük a nevét és típusát területeken. A típusú mezőkkel van szükség annak érdekében, hogy Kapcsolódás a lekérdezések helyesen alkalmazta a beépített funkciókat (valamint az Excel). Ne felejtsük el, példa 2 + 3 = 5, ha a szám, és # 147, # 2 148; + 147 # 3 # 148; = # 147; # 148;, 23 ha ezen a vonalon. Egy másik példa: a beépített funkció ideiglenes változók Hónap (12.04.05) = 4 nem teljesülnek, ha a dátum került rögzítésre vonalon.
Függetlenül van ez a fajta, mint Lookup Wizard. Ami azt illeti, nem egy típust. Mester teszi a legegyszerűbb típusú kapcsolat a két tábla között, „egy a többhöz”. Más szóval, ez lehetővé teszi, hogy helyettesítse egy asztalnál értéket egy másik. A varázsló helyettesítések kényelmes, például tbDog helyettesítő értékek a táblázatból kőzetek. Úgy fog kinézni:
Ez így van a mester cellája be egy kis legördülő listák, ahonnan kiválaszthatja a kívánt értéket. Fontos megérteni, hogy ebben az esetben a kapcsolat a táblák révén jön létre az azonosítót. Csak mester elfedi a technikai oldala.
Szintén az utolsó leckét van egy kis érinti az tervezése adatbázissémákat. Ma fogunk összpontosítani őket, és több szigorú definícióját.
Tervezésekor ezek az áramkörök is kell tartani három szabály:
1. szabály: 1. Normal Form
Az 1. normál forma minden cellában az információ legkisebb egysége.
Nem tud felvenni több értéket vesszőkkel elválasztva. Ha logikusan ez a megoldás merül fel, akkor van dolgunk kommunikáció „sok-sok”, és a szabályok szerint meg kell kezdeni egy külön táblázat (mint a kutyák esetében becslések).
Mi az oka ennek a követelménynek?
A válasz egyszerű: az a tény, hogy a táblázatot, majd feldolgozni a kérést!
Sokkal könnyebben megadhat egy keresési feltételt tbMark.Exterior> 5, mint keresni egy hosszú sorban # 147; 5, 4, 6 „bejegyzés bele a kívánt substring majd fogást a hibát.
Ugyanez vonatkozik a hosszú kompozit értékeket, például Lang. Ha a vezetéknév, keresztnév és apai rögzíti az egyes sejtekben, akkor könnyen a lekérdezések képes megjeleníteni a feladattól függően:
- eredetű, neve és apai,
- Csak a nevét,
- vezetéknevét kezdőbetűi,
- középső neve, stb
A kérések nem lehet nehéz, hogy a válogatott azok az olvasók, akik ezen a héten lejár, ha a visszatérési dátum van írva az egy cellában:
Szintén nem lesz nehéz kiválasztani egy adatbázisból az összes lakosok Moszkva:
Kivételt képeznek azok az információk, amelyek nyilvánvalóan nem kíván keresni. Szóval az elmúlt például nincs sok értelme, hogy a lakás számát külön mezőben, mivel nem valószínű, hogy valaki kell, hogy megjelenjen az összes rendelkezésre álló adatbázis lakói a 50. lakás.
Amellett, hogy 1NF kell mondani még egy fontos dolog: ahogy már tudod, Access lehetővé teszi, hogy hozzon létre lekérdezések és számítások: a születési dátum határozza meg a kor a név és apai tenni a kezdőbetűi, stb Ezért csak az eredeti adatokat (dátum, költség egységnyi áru) fel kell tüntetni a táblázat celláit, és ne írjon azon, hogy lehet kiszámítani funkciókat.
2. szabály: a helyi tárolás
Az elv az adatok tárolására helyben, ha az érték bármely területén rendszeresen ismétlődő, meg kell állni egy külön táblázatban, és a helyszínen, hogy nekik egy linket.
Ne feledje, a példa a kőzetek? A táblázat a kutyák rendszeresen ismétlődő nevek kőzetek. Ne írjon hússzor „spániel” hozunk létre egy külön táblázatot a köveket, és a táblázat csak azt jelzi, Id kutyák. (By the way, milyen kapcsolat lesz?)
Így
a) akkor mentse magát a felesleges munka (nem kell kitölteni egy csomó alkalommal ugyanaz);
b) ha azt szeretné, hogy a változások, ahhoz, hogy szerkeszteni egy területen, hanem néhány tíz vagy akár több száz rekordokat.
Ez a szabály nem feltétlenül felel meg csak egy esetben: ha az ismétlés, de nem rendszeresen. Például nem sok értelme létrehozni egy külön táblázatot vezetéknevű, nevek és apai, bár előfordul, hogy megismételjük.
3. szabály: SZÖVETSÉGE táblázatok
Sokat beszélgettünk arról, hogy mit kell osztani a táblázat több (annak érdekében, hogy eleget tegyenek az első két elv: 1NF és tárolás ellenében). Most itt az ideje, hogy beszéljünk, hogy mikor kell kombinálni több táblát egy.
Ha lefordítjuk az első két elv a hétköznapi nyelvet, akkor (néhány durvulási) azt mondják: az egyik egység - egy egységes táblázat. Táblázat kutyáknak, az asztalon a tulajdonosok, a táblázat az értékelésre, egy asztal a sziklák, stb
Vannak azonban olyan esetek, amikor több szervezet kell hozni egy egységes táblázat! Mik ezekben az esetekben? Ez amikor több szervezet közel azonos adatokat séma (a készlet területen a táblázatban).
Például a show kutyák részt nem csak a tulajdonosok a kutyák, hanem tagjai a tanácsadó testület (a bíró). Létre kell hozni egy külön táblázatot tbExpert bírók, de ez sokkal kényelmesebb, hogy írjon, és azokat, és a tulajdonosok egy táblázatban tbPerson (be megkülönböztetni csak egy további IsExpert mező).
Így nem csak létrehozni extra táblázatokat, hanem menteni magát, hogy írjon néhány extra kérések (pl olyan kérelmet, amelyet a névre, a név és apai eredetű teszi a monogramja). Az ilyen kérelmet kellene reprodukálni az egyes táblázatokban.
Tehát a harmadik elv az alábbiak szerint történik:
Ha több vállalkozás majdnem azonos adatáramkörökön kell őket össze egy táblázatban.
Ne félj, hogy a tábla lesz túl hosszú. Adatbázisok jól működik, nagyon hosszú asztal (magam dolgoztam az adatbázist Access, ami valamivel több, mint 1 millió lemezt, míg Access megbirkózik vele!) A diákok a különböző csoportok, tanfolyamok és osztályok, termékek, különböző típusú könyvek a különböző műfajok - mindegyiket lehet és kell egyesíteni egy asztalnál (tbStudent, tbGoods, tbBook sorrendben) egy speciális területen (poyami) -labels: előadó, műfaj, stb
Sorolja ismét tervezési elveket:
1. 1NF: minden cellában az információ legkisebb egysége.
2. Helyi tárolás: ha az értékek egy bizonyos területen, rendszeresen ismétlődő, meg kell állni egy külön táblázatban, és az azt követő link.
3. kombinálása táblázatokat, ha több szervezet közel azonos adatokat rendszernek, ezért kombinálni kell egy táblába.
És ne feledkezzünk meg a szabályokat, hogy beszéltünk korábban:
1. Minden táblázatban az első mező - az azonosító típusát számláló.
2. elnevezési szabályok vonatkoznak: angol, szóköz nélkül (mindegyik szó nagybetűvel), + előtag tb ...
3. Két típusú kapcsolat: egy-sok (nem hozza létre a kapcsolatot), sok-sok (ami egy további táblázatot).
Most jön gyakorolni.
1. feladat Select bármely három az öt javasolt következő feladatokat, és az adatbázis séma adatlistákat. Rendszereket készít papíron (nem feltétlenül teszi őket Access) és hozza magával a saját.
1. Hollywood
Ikonikus hollywoodi filmek.
- van két egység: az emberek tbPerson és filmek tbFilm;
- tbPerson táblázatban felsorolt szereplők és rendezők;
- Minden film csak az egyik rendező, de az egyik rendező tud lőni több filmet;
- minden film lő több szereplők, és egy színész jár több filmben.
2. Cool Magazin
Matematika tanár az iskolában, hogy a diákok védjegyek munkájukat az osztályteremben. Minden lecke középpontjában egy új témát.
3. Mobilszolgáltató
A mobilszolgáltató fenntart egy adatbázist tájékoztatást nyújt előfizetőinek.
4. Lovas Club
A lovaglás szerelmesei rögzítik az osztályok egy lovarda. Attól függően, hogy a szint a képzés, akkor vegyenek részt a bizonyos ló. Lovak magán, mindegyik a jogos tulajdonos.
5. auto hálózat
Külföldi autók árulják kereskedők hálózatban.
2. feladat Vizsgáljuk típusú mezők Access és telepíti a megfelelő: