Vad betyder relationell. Funktioner, struktur och termer relaterade till relationsmodellen
V relationsdatabaser ah data lagras som tabeller med rader och kolumner. Varje tabell har sin egen fördefinierade uppsättning namngivna fält. Kolumner i tabeller i en relationsdatabas kan innehålla skalärdata av en fast typ, som siffror, strängar eller datum. Tabeller i en relationsdatabas kan länkas i en en-till-en- eller en-till-många-relation. Antalet rader med poster i tabellen är obegränsat, och varje post motsvarar en separat enhet.
Relationsdatabaser är nu dominerande. Hierarkiska strukturer och nätverksstrukturer för databaser är ett minne blott och ger vika för relationsdatabaser, under vilka de flesta moderna DBMS är byggda (MS SQL Server, MS Access, InterBase, FoxPro, PostgreSQL, Paradox och andra).
Detaljer
Relationsmodellen fokuserar på att organisera data i form av tvådimensionella tabeller. Varje relationstabell är tvådimensionell array och har följande egenskaper:
- Varje tabellelement är ett dataelement
- Varje kolumn har sitt eget unika namn
- Det finns inga identiska rader i tabellen
- Alla kolumner i en tabell är homogena, det vill säga alla element i en kolumn är av samma typ
- Ordningen på rader och kolumner kan vara godtycklig
Relationell DBMS fokuserad på implementering av operativa databehandlingssystem är mindre effektiva i uppgifter analytisk bearbetningän flerdimensionella databaser. Detta beror för det första på förekomsten av ganska strikta begränsningar som införs av den befintliga implementeringen av SQL-språket. Ett exempel på en sådan begränsning i den verkliga världen är antagandet att data i en relationsdatabas är oordnad (eller mer exakt, slumpmässigt ordnad). Samtidigt kräver deras beställning ytterligare tid som läggs på sortering varje gång databasen öppnas. V analytiska system datainmatning och hämtning sker i stora portioner. I sin tur förblir uppgifterna oförändrade efter att de kommit in i databasen lång period tid. Och här är det mer effektivt att lagra data i form av delvis denormaliserade tabeller, där, för att öka prestandan, inte bara granulära utan även förberäknade aggregerade värden kan lagras. Och för navigering och provtagning kan specialiserade adresserings- och indexeringsmetoder baserade på antagandet om låg variabilitet och låg mobilitet för data i databasen användas. Det här sättet att organisera data kallas ibland förberäknad, och understryker därigenom dess skillnad från den normaliserade relationella metoden, som involverar dynamisk beräkning. av olika slag totaler (aggregering) och upprätta länkar mellan attribut från olika tabeller (join-operationer).
Huvudsakliga nackdelar
Förutom den låga effektiviteten, som nämndes tidigare, inkluderar nackdelarna med traditionella relationella DBMS det faktum att som den huvudsakliga och ofta den enda mekanismen som ger snabbsökning och hämta individuella rader i en tabell (eller i tabeller länkade genom främmande nycklar), vanligtvis används olika modifieringar av index baserade på B-träd. Denna lösning visar sig vara effektiv endast vid behandling av små grupper av poster och hög intensitet av datamodifiering i databaser.
Relationella DBMS:er kanske aldrig lämnar scenen, men dagarna för deras regeringstid är definitivt räknade, säger Paul Creel, som publicerade en artikel om det i InfoWorld i september 2011. Han citerar analytikern Robin Blore, som hävdar att arkitekturen för relationella DBMS:er är moraliskt föråldrad, eftersom den skapades i en tidigare era och inte uppfyller moderna krav.
Relationella DBMS dominerar fortfarande system för bearbetning av finansiella transaktioner, men idag tar företag i allt högre grad nya NoSQL-arkitektur DBMS - horisontellt skalbara, distribuerade och utvecklade i öppen källa... Exempel på sådana system är Hadoop, MapReduce och VoltDB. Forresters analytiker uppskattar att cirka 75 % av data i företag antingen är semistrukturerad information (XML, E-post och EDI), eller ostrukturerad (text, bilder, ljud och video), och endast 5% av denna data lagras i relations-DBMS, och resten lagras i databaser av andra typer eller i form av filer, och kan inte bearbetas av relationssystem.
Enligt Blores uppfattning kan relationsdatabaser "dö utan att någon märker det", till exempel om Oracle helt enkelt ersätter SQL med NoSQL i sin databas. Analytikern tror att en sådan mekanism kan vara en av de befintliga kolumnära DBMS:erna.
RELATIONSDATABAS OCH DESS FUNKTIONER. TYPER AV RELATIONER MELLAN RELATIONSTABELLER
Relationsdatabas är en samling sammankopplade tabeller, som var och en innehåller information om objekt av en viss typ. Tabellraden innehåller data om ett objekt (till exempel produkt, kund), och tabellkolumnerna beskriver olika egenskaper dessa objekt - attribut (till exempel namn, produktkod, kundinformation). Poster, det vill säga rader i en tabell, har samma struktur - de består av fält som lagrar ett objekts attribut. Varje fält, det vill säga en kolumn, beskriver endast en egenskap hos ett objekt och har en strikt definierad datatyp. Alla poster har samma fält, bara de visar olika informationsegenskaper för objektet.
I en relationsdatabas måste varje tabell ha en primärnyckel — ett fält eller en kombination av fält som unikt identifierar varje rad i tabellen. Om en nyckel består av flera fält kallas den för en sammansatt nyckel. Nyckeln måste vara unik och unikt identifiera posten. Nyckelvärdet kan användas för att hitta en enskild post. Nycklar används också för att organisera information i databasen.
Relationsdatabastabeller måste uppfylla kraven för relationsnormalisering. Normalisering av relationer är en formell apparat av begränsningar för bildandet av tabeller, vilket eliminerar dubbelarbete, säkerställer konsistensen hos de som lagras i databasen och minskar arbetskostnaderna för att underhålla databasen.
Låt tabellen Student skapas som innehåller följande fält: gruppnummer, fullständigt namn, studentnummer, födelsedatum, specialblandning, fakultetsnamn. En sådan organisation av informationslagring kommer att ha ett antal nackdelar:
- duplicering av information (namnet på specialiteten och fakulteten upprepas för varje student), därför kommer volymen av databasen att öka;
- proceduren för att uppdatera informationen i tabellen är svår på grund av behovet av att redigera var och en tabellposter.
Tabellnormalisering är avsedd att åtgärda dessa brister. Det finns tre normala relationsformer.
Första normalformen. En relationstabell reduceras till den första normala formen om och endast om ingen av dess rader innehåller mer än ett värde i något av dess fält och inget av dess nyckelfält är tomt. Så om det krävs att information från elevtabellen ska erhållas genom studentens namn, bör fältet Fullständigt namn delas in i delarna Efternamn, Namn och Patronym.
Andra normalformen... En relationstabell anges i andra normalform om den uppfyller kraven för den första normalformen och alla dess fält som inte ingår i primärnyckeln är fullt funktionellt relaterade till primärnyckeln. För att få tabellen till den andra normala formen är det nödvändigt att bestämma fältens funktionella beroende. Fältens funktionella beroende är ett beroende, när i informationsobjektets instans endast ett värde av det beskrivande attributet motsvarar ett visst värde av nyckelattributet.
Tredje normalformen. En tabell är i tredje normalform om den uppfyller kraven för andra normalform, inget av dess icke-nyckelfält är funktionellt beroende av något annat icke-nyckelfält. Till exempel i elevtabellen (gruppnummer, fullständigt namn, betygsboksnummer, Födelsedatum, Headman) tre fält - postboksnummer, gruppnummer, Headman är i transitiv relation. Gruppnumret beror på betygsbokens nummer och rektorn beror på gruppnumret. För att eliminera det transitiva beroendet är det nödvändigt att överföra en del av fälten i elevtabellen till en annan tabell, Group. Tabellerna kommer att ha följande form: Student (gruppnummer, fullständigt namn, betygsboknummer, födelsedatum), Grupp (gruppnummer, rektor).
Följande operationer är möjliga på relationstabeller:
- Sammankoppling av tabeller med samma struktur. Resultat – totalt tabell: först den första, sedan den andra (sammansättning).
- Skärning av tabeller med samma struktur. Resultat – de poster väljs som finns i båda tabellerna.
- Subtraktion av tabeller med samma struktur. Resultat - de poster väljs ut som inte finns i den subtraherade.
- Prov (horisontell delmängd). Resultat - poster väljs ut som uppfyller vissa villkor.
- Projektion (vertikal delmängd). Resultatet är en relation som innehåller några av fälten från de ursprungliga tabellerna.
- Kartesisk produkt av två tabeller De resulterande tabellposterna erhålls genom att kombinera varje post i den första tabellen med varje post i den andra tabellen.
Relationstabeller kan relateras till varandra, därför kan data hämtas från flera tabeller samtidigt. Tabellerna är sammanlänkade för att i slutändan minska storleken på databasen. Relationen mellan varje tabellpar anges om de har samma kolumner.
Det finns följande typer informationslänkar:
- en till en;
- en till många;
- många-till-många.
En-till-en kommunikation antar att ett attribut i den första tabellen matchar endast ett attribut i den andra tabellen, och vice versa.
En-till-många-relation antar att ett attribut i den första tabellen motsvarar flera attribut i den andra tabellen.
Många-till-många relation antar att ett attribut i den första tabellen motsvarar flera attribut i den andra tabellen, och vice versa.
Nivå 1: Nivå externa modellerÄr den mest högsta nivån där varje modell har sin egen syn på datan. Denna nivå definierar databasens synvinkel för enskilda applikationer.
Konceptuell nivå: Den centrala styrlänken, där databasen presenteras här i den mest allmänna formen, som förenar data som används av alla applikationer. Faktum är att den konceptuella nivån speglar en generaliserad domänmodell.
Fysiskt lager(Databas): Dessa är själva data som finns i filer eller i sidstrukturer som finns på externa lagringsmedia.
Datamodeller
Följande datamodeller särskiljs:
1. Infologisk
2. Datum logiskt
3. Fysiskt
Databasdesignprocessen börjar med designen av en infologisk modell. En infologisk datamodell är en generaliserad informell beskrivning av den skapade databasen, gjord med hjälp av naturligt språk, matematiska formler, tabeller, grafer och andra sätt som är begripliga för alla som arbetar med utformningen av databasen.
Domän tuppel
Den infologiska modellen visar den verkliga världen i ett mänskligt läsbart koncept som är helt oberoende av datalagringsmiljön. Därför bör den infologiska modellen inte förändras förrän vissa förändringar i den verkliga världen kräver förändringar utanför definitionen, så att denna modell fortsätter att visa ämnesområdet.
Det finns många sätt att bygga denna modell: grafmodeller, semantiska nätverk, entitetsrelationer och andra.
Datalogisk modell
Den infologiska modellen bör visas i en datalogisk modell som DBMS kan förstå. Datalogisk modell är en formell beskrivning av en infologisk modell på DBMS-språket.
Hierarkisk modell
Denna modell är en samling relaterade element som bildar en hierarkisk struktur. De grundläggande begreppen i en hierarki är nivå, nod och relation.
kommunikationsnivå
En nod är en samling dataattribut som beskriver ett objekt. Varje nod är länkad till en nod med mer än hög nivå och med valfritt antal noder på lägre nivå. Undantaget är noden på högsta nivån. Antalet träd i databasen bestäms av antalet trädrötter. Det finns bara en sökväg från rotposten till varje databaspost. Ett enkelt exempel kan fungera som Internet-domännamnssystem \ adress. På den första nivån (trädets rot) ligger vår planet jorden, på den andra - landet, på den tredje - regionen, på den fjärde - lokalitet, Gata, hus, lägenhet. En typisk representant är ett DBMS från IBM - IMS.
Alla instanser av denna typättling med gemensam kopia en förfadertyp som kallas tvillingar. En fullständig genomgångsordning definieras för databasen. Uppifrån och ner och från höger till vänster.
Fysisk modell
En fysisk modell byggs på basis av den datalogiska modellen. Den fysiska organisationen av data har stor inverkan på databasens prestanda. DBMS-utvecklare försöker skapa de mest produktiva fysiska datamodellerna och erbjuder användarna en eller annan verktygslåda för att anpassa modellen för en specifik databas.
Exempel: Särskilt för en relationsdatabas tar den redan hänsyn till:
1. Fysiska aspekter av att lagra tabeller i specifika filer.
2. Skapande av index som optimerar hastigheten för dataoperationer med applikationen.
3. Avrättningar olika handlingaröver data vid vissa händelser, definierade av användare med hjälp av triggers och lagrade procedurer.
Infologiska modeller XFör alla nivåer och för alla presentationssätt ämnesområde, ligger kodningen av begrepp om relationer mellan begrepp. Ett nyckelskede i utvecklingen av någon informationssystem Håller systemanalys:
Formalisering av ämnesområdet och representation av systemet som en uppsättning komponenter.
Komposition som bas för systemanalys kan vara funktionell (bygga en hierarki).
Men i de flesta system, när det kommer till databaser, är datatyperna mer statiska än hur de behandlas. Därför har sådana metoder för systemanalys som datadiagrammet utvecklats intensivt. Utveckling av relationsdatabaser. Stimulerade utvecklingen av byggnadsdatautvecklingstekniker i synnerhet ER-diagram ER. Den relationella datamodellen använder direkt begreppet en relation som en kartläggning. Hon är närmast konceptuell modell datapresentation. Och det ligger ofta bakom det.
Till skillnad från grafmodellteoretikern, i relationsmodellen, implementeras relationer mellan relationer på ett implicit sätt, för vilket nycklarna till relationer används. Till exempel implementeras relationer av en hierarkisk typ av mekanismen för primära och främmande nycklar, när attributfaktumet måste finnas i den underordnade relationen.
Ett sådant attribut av relationer i huvudrelationerna kommer att kallas primärnyckeln, och i den underordnade, sekundärnyckeln.
Framsteg i utvecklingen av programmeringsspråk associerade främst med datatypning och framväxten av objektorienterade språk har gjort det möjligt att närma sig analysen av komplexa system ur hierarkiska representationers synvinkel, det vill säga med hjälp av objektklasser med polymorfism, nedärvning och inkapslingsegenskaper.
FÖRHÅLLET ÄR ETT TABELL.
Ta bort det som skapades och
Redigering.
Relationell databasmodell
Relationsdatamodeller är för närvarande de mest populära på grund av denna typ av datapresentation.
En relationsmodell kan ses som en speciell metod för att presentera data, innehållande sin egen data (i form av tabeller) och sätt att arbeta och manipulera med den (i form av länkar). Relationsmodellen antar tre konceptuella element: Struktur, Integritet och Databehandling. Dessa element har sina egna obligatoriska begrepp som behöver förklaras för vidare presentation.
Tabellen betraktas som ett direkt datalager. Traditionellt i relationssystem bordet kallas attityd. Tabellraden kallas av en tupel och kolumnen attribut... I det här fallet har attributen unika namn (inom relationen).
Antalet tupler i tabellen kallas kardinalnummer... Antal attribut grad. En unik identifierare sätts för relationen, det vill säga ett eller flera attribut, vars värden inte är samma samtidigt - identifieraren kallas primärnyckel.Domän det är uppsättningen av tillåtna homogena värden för det här eller det attributet. Således kan en domän betraktas som en namngiven uppsättning data, och de ingående delarna av denna uppsättning är logiskt odelbara enheter (till exempel kan en lista med namnen på anställda på en institution fungera som en domän, men inte alla efternamn kan finnas med i tabellen).
SUMMAAttityd
attribut
Fälten KOD, NAME, SUMM är tabellattribut som finns i rubriken.
Par KOD 5216, NAMN Kireev, SUMM 25.50 är delar av relationskroppen.
I relationsdatabaser, till skillnad från andra modeller, specificerar användaren vilken data som behövs för honom och inte hur man gör det. Av denna anledning är processen att flytta och navigera genom databasen i relationssystem automatisk, och denna uppgift i DBMS utförs av optimerare. Hans jobb är att göra det mesta effektivt sätt hämta data från databasen på begäran. Alltså, optimeraren för åtminstone ska kunna avgöra från vilka tabeller data hämtas, hur mycket information som finns i dessa tabeller och vad som är den fysiska ordningen på poster i tabellerna och hur de är grupperade.
Dessutom utför relationsdatabasen också funktionerna i en katalog. Katalogen innehåller en beskrivning av alla objekt som utgör databasen: tabeller, index, triggers, etc. Uppenbarligen avgörande för rätt arbete hela systemet, en sådan komponent som en optimerare. Optimeraren använder informationen som lagras i katalogen. Ett intressant faktum är att katalogen i sig är en uppsättning tabeller, så DBMS kan manipulera den på traditionella sätt, utan att tillgripa några speciella knep och metoder.
Domäner och relationer
Grundläggande definitioner: Domäner, typer av relationer, predikat.
En relation har ett antal grundläggande egenskaper:
1. I det mest allmänna fallet finns det inga vanliga tupler i relationer - detta följer av själva definitionen av relationer. För vissa DBMS tillåts dock i vissa fall en avvikelse från den här egenskapen. Så länge relationen har en primärnyckel utesluts identiska tupler.
2. Tuplar är inte ordnade uppifrån och ned - det finns helt enkelt inget koncept för ett positionsnummer i relationen. I ett förhållande utan att förlora information kan du framgångsrikt ordna tuplarna i valfri ordning.
3. Attributen är inte ordnade från vänster till höger. Attribut i rubriken för relationer kan placeras i valfri ordning, medan integriteten för data inte kränks. Därför existerar inte heller begreppet positionsnummer i förhållande till ett attribut.
4. Värdet av attribut består av logiskt odelbara enheter - detta följer av det faktum att värdena är hämtade från domäner, annars kan vi säga att relationer inte innehåller grupper av upprepningar. Det vill säga att de är normaliserade.
Relationssystem stödjer flera typer av relationer:
1. Namngivna variabler är relationsvariabler som definieras i DBMS med hjälp av skapande uttalanden och är som regel nödvändiga för en mer bekväm presentation av information för användaren.
2. Den underliggande relationen är direkt viktig del DB får därför ett eget namn när de designar.
3. En härledd relation är en som definierades genom andra, vanligtvis grundläggande, relationer med hjälp av DBMS.
4. Denna vy är faktiskt en namngiven härledd relation, och åsikten uttrycks uteslutande genom DBMS-operatorer som tillämpas på namngivna relationer, så de existerar inte fysiskt i databasen.
5. Resultatet av frågor är en icke namngiven härledd relation som innehåller data (resultatet av en specifik fråga). Resultatet lagras inte i databasen utan finns kvar så länge användaren behöver det.
6. En lagrad relation är en som fysiskt bibehålls i minnet av en relation. Lagrade relationer inkluderar oftast en relationsbas. Baserat på ovanstående kan du definiera en relationsdatabas som en uppsättning relationer relaterade till varandra.
Kommunikation i det här fallet det är sammanslutningen av två eller flera relationer.
| KOD | ADRES |
∞ Binär länk
| Studenter |
| Lärare |
| Tidtabell för klasser |
| ∞ |
| ∞ |
| ∞ |
| Studenter |
Ternära förbindelser
Dataintegritet
I relationsmodeller ges frågan om dataintegritet en särskild plats. Kom ihåg att nyckeln eller potentiell nyckel detta är den minsta uppsättningen av attribut, med vars värden det är möjligt att entydigt hitta den erforderliga tupeln, minimalitet betyder att uteslutningen av något attribut från uppsättningen inte tillåter att identifiera tupeln med de återstående attributen.
Varje relation har minst en möjlig nyckel... En av dem tas som primärnyckel.
När man väljer primärnyckel Företräde bör ges till icke-sammansatta nycklar eller nycklar som består av en minimal uppsättning attribut. Det är också oönskat att använda nycklar med långa textvärden(Det är att föredra att använda heltalsattribut som nycklar). Så för att identifiera en anställd kan du använda antingen ett unikt personalnummer, eller ett passnummer, eller en uppsättning efternamn, patronymnamn och avdelningsnummer. Det är inte tillåtet att primärnyckeln för relationen, det vill säga alla attribut som deltar i primärnyckeln, tar odefinierade värden. I detta fall kommer en motsägelsefull situation att uppstå ( kollision): Det icke-unika elementet i primärnyckeln visas. Därför bör detta övervägas noggrant när du utformar en databas.
Om främmande nycklar. Det är värt att notera att eftersom relation C förbinder relation B och A, måste den inkludera främmande nycklar som motsvarar primärnycklarna för relation A och B.
Den främmande nyckeln för en tabell bildas med hjälp av flera primärnycklar för andra tabeller.
När man överväger problemet med att välja en metod för att länka en relation i en databas, uppstår alltså frågan om vad som ska vara främmande nycklar. Dessutom för alla främmande nyckel det är nödvändigt att lösa problemet i samband med möjligheten (eller omöjligheten) att uppträda i främmande nycklar av odefinierade värden (NULL - värden - värde attribut för saknad information). Med andra ord, kan det finnas någon tupel i en relation som ingen tupel är känd för i den relaterade relationen?
Däremot måste du i förväg tänka på vad som händer när du tar bort tupler från relationen som den främmande nyckeln syftar på. Det finns dock följande möjliga möjligheter:
· Drift kaskader- det vill säga att radering av tupler i en relation leder till att tupler relaterade till relationen raderas. Till exempel att radera information om förnamnets efternamn osv. en anställd leder i ett avseende till strykning av hans lön i ett annat avseende;
· Drift begränsad till - det vill säga endast de tuplar för vilka det inte finns någon relaterad information i annat avseende raderas. Inte all information raderas (inte i alla avseenden) eftersom den kan användas på andra sätt, radering av information som leder till ett brott mot dataintegriteten. Om sådan information finns tillgänglig kan raderingen inte genomföras, till exempel radering av uppgifter om namn, efternamn etc. en anställd är möjlig endast om det inte finns någon information i den relaterade relationen om hans lön.
Det är nödvändigt att tillhandahålla tekniken för vad som kommer att hända när ett försök görs att uppdatera primärnyckeln för en relation som refereras av någon främmande nyckel. Här har du samma alternativ som för att radera:
· Operationen är kaskadkopplad, det vill säga när primärnyckeln uppdateras uppdateras den främmande nyckeln i den relaterade relationen. Till exempel, uppdatering av primärnyckeln i en relation där anställd information lagras resulterar i en uppdatering av den främmande nyckeln i relationen med löneinformation.
· Operationen är begränsad, det vill säga endast de primärnycklar för vilka det inte finns någon annan relaterad information uppdateras. Om sådan information finns tillgänglig kan uppdateringen inte göras. Till exempel är uppdatering av primärnyckeln i en relation där information om en anställd lagras endast möjlig om det inte finns någon information om hans lön i den relaterade relationen.
Relationell algebra
Den formella grunden för basen för relationsdatabasmodellen är relationalgebra, baserad på mängdteori och med hänsyn till en speciell operator framför relationer, och relationskalkyl baserad på matematisk logik.
| Arbete |
| A A A B C C | D D E |
| D D |
| A |
| A B C | D D E | F F G |
Det bör noteras att relationalgebra är mycket kraftfull - komplexa frågor till databasen kan uttryckas med ett enda uttryck. Det är av denna anledning som dessa mekanismer ingår i den relationella datamodellen. Alla frågor som uttrycks med ett enstaka algebrauttryck, eller en enskild relationskalkylformel, kan uttryckas med en enda operator för detta språk.
Relationell algebra har viktig egendom– den är stängd i förhållande till relationsbegreppet. Detta innebär att ett relationellt algebrauttryck exekveras över relationsdatabasrelationer, och resultaten av deras beräkning är också relationer.
Huvudidén med relationalgebra är att sätten att manipulera relationer, betraktade som en uppsättning, är baserade på traditionella flera operationer, kompletterade med några specifika operationer för databasen.
Låt oss beskriva en variant av algebra som föreslogs av KODDOM. Verksamheten består av 8 huvudoperatörer:
Hämta en relation (unär operation)
Relationsprojektion (unär operation)
Fackliga relationer
Skärning av relationer (binär operation)
Subtraktion av relationer
Produktförhållande
Förbindande relationer
Fördelning av relationer
Dessa operationer kan förklaras på följande sätt:
· Resultatet av att välja en relation för något villkor är en relation som bara inkluderar de tuplar av den ursprungliga relationen som uppfyller detta villkor.
· När en relation projiceras på en given uppsättning av dess attribut, erhålls en relation vars tuplar är hämtade från motsvarande tuplar i den första relationen.
· När man utför operationen att kombinera två relationer erhålls en relation som inkluderar alla tupler som ingår i minst en av relationerna som deltar i operationen.
· När man utför operationen att skära två relationer, kommer en relation att erhållas som inkluderar alla tupler som ingår i båda initiala relationerna.
· När man utför operationen att subtrahera två relationer kommer en relation att erhållas som inkluderar alla tupler som ingår i den första relationen, förutom de som också ingår i den andra relationen.
· När man utför en direkt produkt av två relationer erhålls en relation vars tuplar är en kombination av tuplarna i den första och andra relationen.
· När två relationer förenas av något villkor, bildas den resulterande relationen av tupler som en kombination av tupler av de första och andra relationerna som uppfyller detta villkor.
· Funktionen av relationell division har två operander - binära (bestående av två attribut) och unära (bestående av ett attribut) relationer. Resultatet av operationen är en relation som består av tupler inklusive relationen mellan det första attributet av tuplarna i den första relationen, så att uppsättningen av värden för det andra attributet sammanfaller med uppsättningen av värden för den andra relationen .
Utöver ovanstående finns det ett antal speciella operationer som är typiska för att arbeta med databaser:
· Som ett resultat av omdöpningsoperationen är relationen en uppsättning tupler, som sammanfaller med kroppen av den ursprungliga relationen, men namnen på attributen har ändrats.
Det följer att resultatet av en relationsoperation är någon relation, då är det möjligt att bilda relationsuttryck där, istället för den initiala relationen (operand), ett kapslat relationsuttryck kommer att användas. Detta beror på det faktum att den relationella algebras operationer verkligen är stängda för begreppet en relation. Låt oss börja med operationen förenande relationer, dock gäller detta lika för operationerna av skärning och kombination, det vill säga i relationalgebra är resultatet av en facklig operation en relation. Om man medges till relationalgebra möjlighet sammanslagningar godtyckliga två relationer med olika uppsättningar av attribut, då blir resultatet av en sådan operation många, men många olika typer av tupler, det vill säga generellt sett inte en relation. Om vi utgår från kravet att relationalgebra ska vara stängd med avseende på begreppet en relation, då en sådan operation sammanslagningarär meningslöst. Detta leder till uppkomsten av konceptet relationskompatibilitet på sammanslagning: två relationer är endast kompatibla om de har samma rubriker, det vill säga de har samma uppsättning attributnamn och samma attribut är definierade i samma domän.
Förutsatt att två relationer är kompatibla när det gäller förening, när operationen av union av skärningspunkten av subtraktion vanligtvis utförs på dem, är resultatet av operationen en relation med en korrekt definierad titel som sammanfaller med titeln på var och en av relationerna - operander. Om två relationer inte är helt kompatibla när det gäller förening, det vill säga de är kompatibla i allt utom attributnamn, kan dessa relationer göras helt kompatibla när det gäller förening innan du utför en operation som en anslutning genom att använda operationen Rename .
Funktionen av den direkta produkten av två relationer väcker nya problem. I mängdteori kan den direkta produkten erhållas för alla uppsättningar. Elementen i resultatuppsättningen kommer att vara par som består av elementen i den första och andra uppsättningen. Eftersom relationer är mängder är det möjligt att erhålla en direkt produkt för vilka två relationer som helst. Resultatet blir dock inte en attityd. Delarna i resultatet kommer inte att vara tupler, utan par av tupler. Därför, i relationalgebra, används en speciell form av operationen att ta en direkt produkt - en utökad direkt produkt av relationer. När man tar den utökade direkta produkten av två relationer, är elementet i den resulterande relationen en tuppel som bildas genom att slå samman en tupel av den första relationen och en tupel av den andra relationen. Omedelbart uppstår ett andra problem, associerat med att erhålla en korrekt utformad rubrik för den resulterande relationen, vilket leder till behovet av att introducera begreppet kompatibilitet av relationer, genom att ta en utökad direkt produkt.
Två relationer är kompatibla för att ta en direkt produkt endast om uppsättningen av attributnamn för dessa relationer inte överlappar varandra. Vilka två relationer som helst kan konverteras till en kompatibel form genom att ta den direkta produkten genom att använda rename-operationen på en av dessa relationer.
Hämtningsoperationen kräver två relationer: den ursprungliga relationen, operanden och ett enkelt villkor. Som ett resultat av hämtningsoperationen produceras en rubrikrelation som matchar operandrelationshuvudet, och kroppen innehåller de operandrelationstupler som uppfyller värdena för begränsningsvillkoret.
Låt oss presentera ett antal operatörer.
Låt union beteckna unionsoperationen, skär skärningsoperationen, minus subtraktionsoperationen. För att beteckna en urvalsoperation kommer vi att använda konstruktionen A där B, där A är operandrelationen, och B är ett enkelt jämförelsevillkor. Låt C1 och C2 vara två enkla samplingsvillkor
A där C1 OCH C2 är identiska med (A där C1) skär varandra (A där C2)
A där C1 ELLER C2 är identisk med (A där C1) union (A där C2)
A där C1 inte C2 är identisk med (A där C1) minus (A där C2)
Genom att använda dessa definitioner är det möjligt att implementera urvalsoperationer där urvalsvillkoret är godtyckligt booleskt uttryck sammansatt av enkla förhållanden använder logiska kopplingar (och, eller, inte). Operationen att ta projektioner av relationen A op till listan med attribut a1, a2,... an kommer att vara en relation vars titel är uppsättningen av attribut, a1, a2,..., an. Resultatets kropp kommer att bestå av tuplar för vilka det i relation A finns en tupel, a1-attributet har b1-värdet, a2-attributet b2-värdet< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.
Sammanfogningsoperationen, ibland kallad villkorlig sammanfogning, kräver två operander, en sammankopplingsbar relation och en tredje operand, ett enkelt villkor. Låt relationen A och B vara sammankopplade. Liksom i fallet med urvalsoperationen har kopplingsvillkoret C formen (a comp –op b) eller (a comp –op const) där A och B är namnen på attribut för relationerna A och B, konst- bokstavligen given konstant. Comp-op är en giltig jämförelseoperation i detta sammanhang. Sedan, per definition, är resultatet av sammanfogningsoperationen den relation som erhålls genom att utföra tvångsoperationen, av villkor C av den direkta produkten av förhållandet A och B.
Det finns en viktig specialfall förbindelser, naturlig koppling. En kopplingsoperation kallas en naturlig kopplingsoperation om kopplingsvillkoren är (a = b) där a och b är attribut för olika kopplingsoperander. Det här fallet är viktigt eftersom det är särskilt vanligt i praktiken och det finns effektiva implementeringsalgoritmer för det i ett DBMS. Den naturliga kopplingen tillämpas på ett par av relationer A och B som delar ett gemensamt attribut P, det vill säga ett attribut med samma namn och definierat på samma domän. Låt ab beteckna föreningen av rubrikerna för relationerna A och B. Då är den naturliga föreningen resultatet av föreningen av A och B projicerad på a. Funktionen av den naturliga sammanfogningen ingår inte direkt i uppsättningen av operationer för relationell algebra, men det har mycket viktig praktisk betydelse.
Fördelningen av relationer behöver mer detaljerad förklaring för det är svårt att förstå. Låt två relationer A (a1, a2, .., an, b1, b2, ..., bm) ges
B (b1, b2,..., bn) Vi kommer att anta att attribut b1 för relation A och attribut b1 för relation B är definierade på samma domän. Låt oss kalla mängden attribut (aj) för ett sammansatt attribut a, och mängden (bj) med ett sammansatt attribut b. Efter det kommer vi att prata om den relationella uppdelningen av den binära relationen A (a, b) med den enära relationen B (b).
Resultatet av att dividera A med B är ett enärt förhållande C (a), bestående av sådana tupler v att det i relation A finns tupler
Eftersom division är den svåraste operationen, låt oss förklara det med ett exempel. Låt det finnas två relationer i DB för studenter: STUDENTER (FULLSTÄNDIGT NAMN, NUMMER) och NAMN (FULLSTÄNDIGT NAMN), och den unära relationen NAMN innehåller alla efternamn som institutets studenter har. Sedan, efter att ha utfört operationen med relationell uppdelning av relationen STUDENTER av relationen NAMN, kommer en unär relation att erhållas som innehåller numren på studentkort som tillhör studenter med alla efternamn som är möjliga på detta institut.
Relationskalkyl
Anta att det finns en databas med strukturen STUDENTER (nummer, namn, stipendium, gruppkod), och relationen GROUP (gr_nom, gr_col, gr old) Låt oss anta att du behöver ta reda på namn och antal elever. biljetter för studenter som är chefer för grupper med fler än 25 personer. I relationalgebra behöver du ta följande åtgärder för en begäran som denna:
1. Utför anslutning av relationer STUDENTER och GRUPPER, enligt villkoret "student_number = gr_star";
2. Begränsa det resulterande förhållandet med villkoret gr_col> 25.
3. Projicera resultatet av föregående operation på attributet student_name, student_number.
Här formuleras steg för steg sekvensen för exekvering av en fråga i databasen, som var och en motsvarar en relationsoperation. Om vi formulerar samma fråga med hjälp av relationskalkylen, så skulle vi få en formel som kan läsas: Ge STUD_NAME och STUD_NUMBER för sådana elever så att en sådan grupp GR_STAR och värdet GR_COL> 25 samexisterar. I den andra formuleringen angav vi endast egenskaperna hos det resulterande förhållandet, men sa inget om metoden för dess bildande. I detta fall måste DBMS själv bestämma vilken typ av operationer och i vilken ordning det är nödvändigt att utföra på relationerna STUDENTER och GRUPPER. Båda metoderna i exemplet är faktiskt likvärdiga och det finns inte särskilt komplexa omvandlingar från en till en annan.
De grundläggande begreppen för relationskalkyl är begreppen för en variabel med ett visst intervall av dess värde, och begreppet en välformad formel baserad på variabler och specialiteter. Funktioner. Vad är omfattningen av en variabel Det finns tupelkalkyl och domänkalkyl, det vill säga längs eller tvärs över. I tupelkalkyl är variabla domäner databasrelationer, d.v.s. acceptabelt värde varje variabel är en tupel av någon relation. I domänkalkylen är definitionsdomänerna för variabler de domäner på vilka attributen för databasrelationer definieras, det vill säga det giltiga värdet för varje variabel är värdet för varje variabel.
| Byte | Heltal | Sträng | Röding | |
| M | ||||
| | N | |||
| K | ||||
Kommandot RANGE används för att definiera tupler. Till exempel, för att definiera en variabel STUDENT vars omfattning är STUDENT, måste du använda konstruktionen RANGE STUDENT IS STUDENT. Av denna definition följer att variabeln student vid varje tidpunkt representerar en tupel av relationen STUDENTER. När du använder tupelvariabler i formler kan du referera till variablernas attributvärden. Till exempel, för att referera till värdet på STUD_NAME-attributet för STUDENT-variabeln, använd STUDENT.STUD_NAME-konstruktionen.
Korrekt konstruerade formler tjänar till att uttrycka villkor som åläggs tupelvariabler. Sådana formler är baserade på enkla jämförelser, som är operationer för att jämföra värdena för variablers attribut och bokstavligen specificerade konstanter. Till exempel är konstruktionen STUDENT.STUD_NOM = 123456. Är en enkel jämförelse. Mer svårt alternativ sammansatta formler är med hjälp av logiska samband OCH, ELLER, INTE, OM... DÅ. Slutligen är det tillåtet att bygga välformade formler med hjälp av kvantifierare. Om F är en välformad formel där variabeln var deltar, så är konstruktionerna EXIST (existentiell kvantifierare) var (F) och FORALL (för alla tupler) var (F) korrekta.
Variabler som ingår i välformade formler kan vara fria eller bundna. Alla variabler som ingår i deras sammansättning under konstruktionen som inte använde kvantifierare är fria. Detta betyder att om värdet "true" erhålls för någon uppsättning värden av fria tupelvariabler vid beräkning av formler, så kan dessa värden inkluderas i den resulterande relationen. Om kvantifieraren används i konstruktionen av formler, är variablerna bundna. Vid beräkning av värdet av en sådan välformad formel används inte ett enda värde av den associerade variabeln, utan hela dess definitionsdomän.
1) FINNS STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)
2) FORALL STUD2 (STUD.1STUD_STYP> STUD2.STUD_STIP)
Låt STUD1 och STUD2 vara två tupelvariabler definierade för elevrelationen, då antar formeln för den aktuella tupeln av STUD1-variabeln värdet true endast om det i hela relationen elever finns en sådan tupel associerad med STUD2-variabeln som värdet på dess STUD_STIP-attribut uppfyller det interna jämförelsevillkoret. Korrekt konstruerad formel nr 2 för den konstruerade tuppeln STUD 1 antar värdet true om för alla tuplar relationen STUDENTER associerad med variabeln STUD 2 värdet på STUD.STYP-attributet uppfyller det interna villkoret.
Sålunda tillhandahåller välformade formler ett sätt att uttrycka ett urvalsvillkor från en databasrelation. För att kunna använda relationskalkylen för riktigt arbete med databasen krävs ytterligare en komponent som definierar mängden och kolumnnamnen för den resulterande relationen. Denna komponent kallas mållista.
Mållista ser ut som:
· Var.attr - namnet på en fri variabel, attr är namnet på relationsattributet som variabeln var definieras på.
· Var som är ekvivalent med en relation från en lista, Var.attr1, Var.attr1… Var.attr№ inkluderar namnen på alla attribut för den definierande relationen.
· Nytt_namn = var.attr; det nya namnet på motsvarande attribut för den resulterande relationen.
Det senare alternativet krävs i de fall där koden i formeln använder flera fria variabler med samma omfattning. I domänkalkyl är domäner inte domäner utan domäner. När det gäller DB-ELEVERNA I GRUPPEN kan vi prata om domänen variabler NAME(Domänvärden är giltiga namn eller NOM STUD). (Domänvärden är giltiga studentnummer).
Huvudskillnaden mellan kalkylen för domäner och kalkylen för tupler är närvaron av ytterligare en uppsättning predikat som tillåter en att uttrycka de så kallade medlemsvillkoren. Om R är en n-är relation med attribut (a1, a2,... an), så har medlemskapsvillkoret formen R (ai1: Vi1, ai2: Vi2,... aim: Vim) där (m)<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.
Ett predikat är en logisk funktion som returnerar sant eller falskt för något argument. En relation kan ses som ett predikat med argument som är attribut för relationen i fråga. Om den givna specifika uppsättningen av tupler finns i relationen, kommer predikatet att returnera sant, annars kommer det att vara falskt.
I alla andra avseenden ser formler och uttryck för domänkalkyl ut som formler och uttryck för tupelkalkyl. Relationell domännotation är kärnan i de flesta formulärbaserade språkfrågor.
Liknande information.
Relationsdatabas - grundläggande begrepp
När man talar om en databas menar de ofta bara någon form av automatiserat datalager. Denna uppfattning är inte helt korrekt. Varför det är så kommer att visas nedan.
Faktum är att i ordets snäva mening är en databas en viss uppsättning data som behövs för arbetet (faktiska data). Data är dock en abstraktion; ingen har någonsin sett "bara data"; de uppstår inte och existerar inte av sig själva. Data är en reflektion av objekt i den verkliga världen. Anta att du till exempel vill lagra information om delar som tas emot på lagret. Hur kommer ett verkligt objekt - en del - att visas i databasen? För att svara på denna fråga måste du veta vilka tecken eller sidor av delen som är relevanta, nödvändiga för arbete. Bland dem kan vara namnet på delen, dess vikt, dimensioner, färg, tillverkningsdatum, material från vilket den är tillverkad, etc. I traditionell terminologi kallas objekt från den verkliga världen, information om vilka lagras i databasen, enheter (låt detta ord inte skrämma läsaren - detta är en allmänt accepterad term), och deras faktiska tecken kallas attribut.
Varje egenskap hos ett visst objekt är värdet på attributet. Till exempel har motordelen ett viktattributvärde på 50, vilket återspeglar det faktum att denna motor väger 50 kilo.
Det skulle vara ett misstag att tro att endast fysiska objekt återspeglas i databasen. Hon kan ta till sig information om abstraktioner, processer, fenomen - det vill säga om allt som en person möter i sin verksamhet. Till exempel kan en databas lagra information om beställningar för leverans av delar till ett lager (även om det inte är ett fysiskt objekt, utan en process). Attributen för "order"-enheten kommer att vara namnet på den levererade delen, antalet delar, namnet på leverantören, leveranstiden och så vidare.
Objekt i den verkliga världen är förbundna med varandra genom många komplexa beroenden som måste beaktas i informationsaktiviteter. Till exempel levereras delar till lagret av deras tillverkare. Därför måste attributet "tillverkarens namn" inkluderas i antalet attribut för delen. Detta är dock inte tillräckligt, eftersom du kan behöva ytterligare information om tillverkaren av en viss del - hans adress, telefonnummer, etc. Det innebär att databasen inte bara ska innehålla information om delar och inköpsorder, utan även information om deras tillverkare. Dessutom bör databasen återspegla förhållandet mellan delar och tillverkare (varje del tillverkas av en specifik tillverkare) och mellan beställningar och delar (varje beställning utfärdas för en specifik del). Observera att endast relevanta, meningsfulla länkar behöver lagras i databasen.
En databas är alltså i ordets breda bemärkelse en samling beskrivningar av objekt i den verkliga världen och kopplingar mellan dem som är relevanta för ett specifikt tillämpningsområde. I det följande kommer vi att utgå från denna definition och förfina den under presentationen.
Relationsdatamodell
Så vi fick en uppfattning om vad som lagras i databasen. Nu måste du förstå hur entiteter, attribut och relationer mappas till datastrukturer. Detta bestäms av datamodellen.
Traditionellt klassificeras alla DBMS enligt den datamodell som ligger till grund för dem. Det är vanligt att särskilja hierarkiska, nätverks- och relationsdatamodeller. Ibland läggs en datamodell baserad på inverterade listor till dem. Följaktligen talar man om hierarkisk, nätverks-, relations-DBMS eller DBMS baserad på inverterade listor.
När det gäller prevalens och popularitet är relationella DBMS ur konkurrens idag. De har blivit en de facto industriell standard, och därför kommer en inhemsk användare att behöva möta i sin praktik just med ett relationellt DBMS. Låt oss ta en snabb titt på relationsdatamodellen utan att gå in på dess detaljer.
Den utvecklades av Codd redan 1969-70 på basis av den matematiska teorin om relationer och bygger på ett system av begrepp, varav de viktigaste är tabell, relation, rad, kolumn, primärnyckel, främmande nyckel.
En relationsdatabas är en där all data presenteras för användaren i form av rektangulära tabeller med datavärden, och alla operationer på databasen reduceras till att manipulera tabeller. Tabellen består av rader och kolumner och har ett namn som är unikt i databasen. Tabellen speglar typen av objekt i den verkliga världen (entitet), och var och en av dess linjer är ett specifikt objekt. Till exempel innehåller deltabellen information om alla delar lagrade i lagret, och dess rader är uppsättningar av attributvärden för specifika delar. Varje kolumn i en tabell är en samling värden för ett specifikt attribut för ett objekt. Till exempel är materialkolumnen en uppsättning värden "Stål", "Tin", "Zink", "Nickel" och så vidare. Kolumnen Kvantitet innehåller icke-negativa heltal. Värdena i kolumnen Vikt är reella tal lika med vikten av delen i kilogram.
Dessa värden visas inte ur tomma luften. De väljs från uppsättningen av alla möjliga värden för ett attribut för ett objekt, som kallas en domän. Så, värdena i materialkolumnen väljs från uppsättningen namn på alla möjliga material - plast, trä, metaller etc. I kolumnen Material är det därför i grunden omöjligt att ett värde visas som inte finns i motsvarande domän, till exempel "vatten" eller "sand".
Varje kolumn har ett namn, som vanligtvis skrivs överst i tabellen ( Ris. 1). Det måste vara unikt i tabellen, men olika tabeller kan ha kolumner med samma namn. Alla tabeller måste ha minst en kolumn; kolumnerna är ordnade i tabellen efter namnordningen när den skapades. Till skillnad från kolumner har rader inga namn; deras ordning i tabellen är inte definierad, och antalet är inte logiskt begränsat.
Figur 1. Grundläggande begrepp för databasen.
Eftersom raderna i tabellen inte är ordnade är det omöjligt att välja en rad efter dess position - det finns ingen "första", "andra", "sista" bland dem. Varje tabell har en eller flera kolumner, vars värden unikt identifierar var och en av dess rader. En sådan kolumn (eller kombination av kolumner) kallas en primärnyckel. I tabellen Part är den primära nyckeln kolumnen Part Number. I vårt exempel har varje del i lagret ett enda nummer, med vilket den nödvändiga informationen extraheras från deltabellen. Därför är den primära nyckeln i denna tabell kolumnen Part Number. Värdena i denna kolumn kan inte dupliceras - deltabellen ska inte innehålla rader som har samma värde i kolumnen Artikelnummer. Om en tabell uppfyller detta krav kallas det en relation.
Relationen mellan tabeller är en väsentlig del av den relationella datamodellen. Det stöds av främmande nycklar. Tänk på ett exempel där databasen lagrar information om vanliga anställda (tabellen Employee) och chefer (chefstabellen) i någon organisation ( Ris. 2). Den primära nyckeln i tabellen Arbetsledare är kolumnen Nummer (till exempel personalnummer). Kolumnen Efternamn kan inte fungera som en primärnyckel, eftersom två chefer med samma efternamn kan arbeta i samma organisation. Varje anställd är underställd en enda chef, vilket bör återspeglas i databasen. Medarbetartabellen innehåller chefsnummerkolumnen, och värdena i denna kolumn väljs från Nummerkolumnen i chefstabellen (se Ris. 2). Kolumnen Arbetsledarenummer är en främmande nyckel i tabellen Anställd.
Figur 2. Relation mellan databastabeller.
Tabeller kan inte lagras och bearbetas om databasen inte innehåller "data om data", till exempel deskriptorer för tabeller, kolumner och så vidare. De brukar kallas metadata. Metadata presenteras också i tabellform och lagras i en dataordbok.
Förutom tabeller kan databasen lagra andra objekt som visningar, rapporter, vyer och till och med applikationer som fungerar med databasen.
Det räcker inte för användarna av informationssystemet att databasen bara återspeglar objekt från den verkliga världen. Det är viktigt att en sådan reflektion är entydig och konsekvent. I det här fallet sägs databasen uppfylla integritetsvillkoret.
För att garantera att data är korrekta och ömsesidiga överensstämmer databasen med vissa begränsningar, som kallas dataintegritetsbegränsningar.
Det finns flera typer av integritetsbegränsningar. Det krävs till exempel att värdena i en tabellkolumn endast väljs från motsvarande domän. I praktiken beaktas också mer komplexa integritetsbegränsningar, såsom referensintegritet. Dess kärna ligger i det faktum att en främmande nyckel inte kan vara en pekare till en obefintlig rad i en tabell. Integritetsbegränsningar implementeras med hjälp av specialverktyg, som kommer att diskuteras i Sec.Databasserver .
SQL-språk
Data i datorform är i sig inte av intresse för användaren om det inte finns några möjligheter att komma åt dem. Dataåtkomst utförs i form av databasfrågor, som är formulerade i ett standardfrågespråk. Idag, för de flesta DBMS, är detta språk SQL.
Uppkomsten och utvecklingen av detta språk som ett sätt att beskriva tillgång till en databas är förknippad med skapandet av teorin om relationsdatabaser. Prototyp SQL-språk uppstod 1970 som en del av System / R-forskningsprojektet, på vilket arbete utfördes i Santa Teresa-laboratoriet i IBM-företaget. SQL är nu standarden för gränssnitt med. Dess popularitet är så stor att utvecklare av icke-relationell DBMS (till exempel Adabas) förser sina system med SQL-gränssnitt.
SQL-språket har en officiell standard - ANSI / ISO. De flesta DBMS-utvecklare följer denna standard, men utökar den ofta för att implementera nya databehandlingsmöjligheter. Nya datahanteringsmekanismer ska beskrivas i Sec.Databasserver , kan endast användas genom speciella SQL-satser som i allmänhet inte ingår i språkstandarden.
SQL är inte ett traditionellt programmeringsspråk. Det skrivs inte program på den, utan frågor till databasen. Därför är SQL ett deklarativt språk. Det betyder att den kan användas för att formulera vad som behöver erhållas, men den kan inte ange hur det ska göras. I synnerhet, till skillnad från procedurprogrammeringsspråk (C, Pascal, Ada), saknar SQL-språket sådana operatorer som om-då-annat, för, medan, etc.
Vi kommer inte att gå in i detalj om språkets syntax. Låt oss beröra det endast i den utsträckning som är nödvändig för att förstå enkla exempel. Med deras hjälp kommer de mest intressanta databehandlingsmekanismerna att illustreras.
En SQL-fråga består av en eller flera satser, den ena efter den andra, separerade med semikolon. Tabell 1 nedan listar de viktigaste operatörerna som ingår i ANSI / ISO SQL-standarden.
Tabell 1. Grundläggande operatorer för SQL-språket.
SQL-frågor använder namn som unikt identifierar databasobjekt. Detta är i synnerhet namnet på tabellen (Detalj), namnet på kolumnen (Namn), såväl som namnen på andra objekt i databasen som tillhör ytterligare typer (till exempel namnen på procedurer och regler) , som kommer att diskuteras i Sec.Databasserver ... Tillsammans med enkla namn används även komplexa namn - till exempel definierar det kvalificerade kolumnnamnet namnet på kolumnen och namnet på tabellen som den tillhör (Part.Weight). För enkelhetens skull kommer namnen i exemplen att skrivas på ryska, även om detta i praktiken inte rekommenderas.
Varje kolumn i en tabell lagrar data av vissa typer. Det finns grundläggande datatyper - strängar av tecken med fast längd, heltal och reella tal, och ytterligare datatyper - strängar av tecken med variabel längd, valutaenheter, datum och tid, logiska data (två värden - "TRUE" och " FALSK"). I SQL kan du använda numeriska, sträng-, tecken- och datum- och tidskonstanter.
Låt oss titta på några exempel.
Frågan "bestäm antalet delar i lager för alla typer av delar" implementeras enligt följande:
VÄLJ namn, kvantitet
FRÅN Del;
Resultatet av frågan blir en tabell med två kolumner - Namn och Kvantitet, som är hämtade från den ursprungliga deltabellen. I grund och botten låter den här frågan dig få en vertikal projektion av den ursprungliga tabellen (mer strikt, en vertikal delmängd av uppsättningen tabellrader). Från alla rader i deltabellen bildas rader som inkluderar värden hämtade från två kolumner - Namn och Kvantitet.
Frågan "vilka delar gjorda av stål finns i lager?", Formulerad i SQL, ser ut så här:
FRÅN Del
WHERE Material = "Stål";
Resultatet av denna fråga blir också en tabell som endast innehåller de rader i källtabellen som har värdet "Stål" i kolumnen Material. Den här frågan låter dig få en horisontell projektion av deltabellen (en asterisk i SELECT-satsen betyder att du väljer alla kolumner från tabellen).
Begäran "för att bestämma namnet och mängden av delar i lagret, som är gjorda av plast och väger mindre än fem kilogram" kommer att skrivas enligt följande:
VÄLJ namn, kvantitet
FRÅN Del
WHERE Material = "Plast"
OCH Vikt< 5;
Frågeresultatet är en tabell med två kolumner - Namn, Kvantitet, som innehåller namn och antal delar gjorda av plast och som väger mindre än 5 kg. I själva verket är valoperationen operationen att först bilda en horisontell projektion (hitta alla rader i deltabellen, för vilka Material = "Plast" och Vikt< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).
Index är ett av verktygen som ger snabb åtkomst till tabeller. Ett index är en databasstruktur som är en pekare till en specifik rad i en tabell. Databasindexet används på samma sätt som indexindexet i en bok. Den innehåller värden tagna från en eller flera kolumner i en viss tabellrad och en länk till den raden. Värdena i indexet är ordnade, vilket gör att DBMS kan utföra snabba sökningar i tabellen.
Låt oss anta att en fråga till Warehouse-databasen är formulerad:
VÄLJ Namn Kvantitet, Material
FRÅN Del
WHERE Number = "T145-A8";
Om det inte finns några index för den här tabellen måste DBMS se hela tabelldetaljen för att kunna köra den här frågan, sekventiellt välja rader från den och kontrollera urvalsvillkoren för var och en av dem. För stora tabeller kommer en sådan fråga att ta mycket lång tid.
Om indexet tidigare skapats i kolumnen Tabellnummerdel, kommer söktiden i tabellen att reduceras till ett minimum. Indexet kommer att innehålla värden från nummerkolumnen och en länk till raden med detta värde i deltabellen. När en fråga körs, kommer DBMS först att hitta värdet "T145-A8" i indexet (och kommer att göra det snabbt, eftersom indexet är beställt och dess rader är små), och sedan, genom referens i indexet, kommer det att bestämma den fysiska platsen för den önskade raden.
Indexet skapas med SQL CREATE INDEX-satsen. I det här exemplet, operatören
SKAPA UNIKT INDEX Delindex
ON-del (nummer);
kommer att skapa ett index som heter Part Index i kolumnen Part Table Number.
För en användare av ett DBMS är det inte enskilda SQL-satser som är av intresse, utan en viss sekvens av dem, bildade som en helhet och vettiga ur hans synvinkel. Varje sådan sekvens av SQL-satser implementerar en specifik åtgärd på databasen. Det utförs i flera steg, varvid vissa operationer utförs på databastabellerna. Så i banksystemet utförs överföringen av ett visst belopp från ett korttidskonto till ett långsiktigt i flera operationer. Bland dem - uttag av ett belopp från ett korttidskonto, kreditering till ett långtidskonto.
Om ett fel inträffar under utförandet av denna åtgärd, till exempel när den första operationen är klar, men den andra inte är det, kommer pengarna att gå förlorade. Därför måste alla åtgärder på databasen utföras helt eller inte alls. Denna åtgärd kallas en transaktion.
Transaktionsbearbetning är beroende av loggen, som används för att återställa transaktioner och återställa tillståndet för databasen. Mer information om transaktioner kommer att diskuteras i Sec.Transaktionshantering .
För att avsluta vår diskussion om SQL-språket, låt oss återigen betona att det är ett frågespråk. Det är omöjligt att skriva något komplext applikationsprogram på den som fungerar med en databas. För detta ändamål i modernt DBMS den fjärde generationens språk (Forth Generation Language - 4GL) används, som har både de grundläggande funktionerna för tredje generationens procedurspråk (3GL), såsom C, Pascal, Ada, och förmågan att bädda in SQL-satser i programmet text, samt styr användargränssnittet (meny, formulär, användarinmatning, etc.). Idag är 4GL en av de facto-standarderna för utvecklingsverktyg för databasapplikationer.
Relationsmodell
Relationsdatabasmodellen föreslogs 1969 av E.F. Codd (E.F. Codd). För lite introduktionsinformation om relationsdatabaser, se översiktsartikeln " DB och DBMS"2. Eftersom det nu är relationsdatabaser som är dominerande, i denna artikel (liksom i artiklar" Beskrivning av data”, “Databehandling"och" Databasdesign”2) de viktigaste begreppen i relationsmodellen undersöks i detalj.
Omedelbart noterar vi att teorin om relationsdatabaser ursprungligen formulerades i ett rigoröst matematiskt språk, och det är rigorösa, formellt definierade matematiska begrepp som bäst beskriver sakers väsen. Samtidigt är det i de flesta fall möjligt, utan större skada, att offra terminologins stränghet till förmån för presentationens transparens, vilket vi kommer att försöka göra.
Grundtanken bakom relationsmodellen är följande. Databasen består av ett antal oordnade tabeller(i det enklaste fallet - från en tabell). Tabeller kan manipuleras genom icke-procedurella (deklarativa) operationer - förfrågningar, vars resultat också är tabeller.
Ofta ordet "relationell" ( relationella) i termen "relationsmodell" tolkas utifrån det faktum att relationer upprättas i en relationsdatabas ( relatera) mellan borden. Denna förklaring är bekväm, men inte korrekt. I Codds ursprungliga termsystem, kommunikationsvillkoren ( relationer), attribut ( attribut) och tuplar ( tupler) användes där de flesta av oss använder de mer välbekanta termerna tabeller, kolumner (fält) och rader (poster).
När du bygger en infoologisk modell av ämnesområdet (se " DB och DBMS”, “Databasdesign”2) sticker ut enheter(objekt), de beskrivs egenskaper a (egenskaper, attribut) som är betydelsefulla för modelleringsändamål, och relationer mellan enheter etableras. Vid övergångsstadiet från en infologisk till en datalogisk relationsmodell dyker tabeller upp. Vanligtvis representeras varje enhet av en tabell. Varje rad i tabellen (en post) motsvarar en instans av entiteten, och varje fält beskriver någon egenskap (attribut).
Till exempel, om vi behöver lagra information om personer, inklusive efternamnet på var och en, förnamn, patronym, TIN, bosättningsland och födelsedatum, då är enheten exakt personen, och de angivna uppgifterna är attribut. Själva enheten blir naturligtvis namnet på tabellen.
Tabell "Person"
Relationsmodellen kräver att varje rad i tabellen är unik, d.v.s. så att två linjer skiljer sig åt i värdet av minst ett attribut.
Den traditionella tabellformen är användbar när du behöver presentera själva data. Om du, som i exemplet ovan, bara är intresserad av strukturera- fältnamn, då ur synvinkel av tydlighet, användarvänlighet i diagram och spara utrymme, är det bekvämare att skildra det enligt följande:
Nycklar
Nyckel tabellerär ett fält eller en grupp av fält som innehåller värden som är unika i den här tabellen... Nyckeln identifierar unikt motsvarande rad i tabellen. Om en nyckel består av ett fält kallas den ofta enkel om av flera - sammansatt... I exemplet ovan är nyckeln TIN-fältet (vi anser att det är känt att TIN är unika inom landet).
Låt oss titta på ett exempel på en tabell med en sammansatt nyckel. Det är inte ovanligt att väderprognossajter presenterar information på följande sätt: för varje datum anges den prognostiserade temperaturen på natten, på morgonen, på eftermiddagen och på kvällen. För att lagra den angivna informationen kan du använda en tabell i följande formulär:
I den här tabellen är varken datumfältet, tidpunkten eller temperaturen nycklar - värden kan upprepas i vart och ett av dessa fält. Men kombinationen av fälten Datum + Tid på dagen är unik och definierar unikt en tabellrad. Detta är den sammansatta nyckeln.
Ofta finns det en situation där valet av nyckel inte är entydigt. Låt oss gå tillbaka till det första exemplet. Antag att det, förutom efternamn, förnamn, patronym, TIN, födelsedatum, krävs att det civila passets serie och nummer samt det utländska passets serie och nummer lagras. Tabellen kommer att se ut så här.
Det finns så många som tre nycklar att välja mellan i den här tabellen. En av dem är enkel (TIN), de andra två är sammansatta (serie + civilpassnummer och serie + utländskt passnummer). I en sådan situation väljer utvecklaren den mest bekväma nyckeln ur synvinkeln att organisera databasen (i allmänhet nyckeln, vars sökning tar minst tid). Den valda nyckeln i detta fall kallas ofta master, eller primär, en nyckel och andra kombinationer av kolumner från vilka en nyckel kan göras är möjlig, eller alternativa, nycklar. Observera att det alltid finns minst en möjlig nyckel i tabellen, eftersom rader inte kan upprepas och därför är kombinationen av alla kolumner garanterat en möjlig nyckel.
Vid visning av tabeller är det vanligt att markera tabellernas primärnycklar. Till exempel är relevanta fält ofta understrukna. Och Microsoft Access markerar nyckelfält i fetstil.
Ännu oftare än med tvetydighet i valet av en nyckel, ställs utvecklare inför avsaknaden av en nyckel bland de data som behöver lagras. Ett liknande faktum kan konstateras i processen för att analysera ämnesområdet. Till exempel, om du behöver lagra en enkel lista över personer - förnamn, efternamn, patronymer och födelsedatum, så finns det ingen nyckel i denna uppsättning attribut alls - en situation är tänkbar när två olika personer har samma data helt och hållet. I det här fallet måste du artificiellt ange ytterligare ett fält, till exempel en unik persons nummer. En sådan nyckel kallas ibland i litteraturen surrogat... Ofta införs också en surrogatnyckel av effektivitetsskäl. Om till exempel en tabell har en lång sammansatt nyckel, introducerar utvecklare ofta en extra kort numerisk surrogatnyckel och gör den till den primära. Ofta görs detta även om det finns en enkel nyckel med en "obekväm" (ineffektiv för sökning) datatyp, till exempel en sträng. Sådana operationer är inte längre relaterade till teori, men de är ganska vanliga i praktiken.
Den uppmärksamma läsaren kommer förmodligen att märka att nyckeln nästan alltid kan utökas (om den inte inkluderar alla fält i tabellen) genom att inkludera redundanta fält. Formellt kommer en sådan nyckel att förbli en nyckel, men ur praktisk synvinkel är det bara ett begreppsspel. Sådana nycklar anses inte heller möjliga, eftersom det alltid är nödvändigt att sträva efter att minimera nyckelns längd (komplexitet).
Normala former, normalisering
Inte varje tabell som vi kan rita på papper eller i Word kan vara en relationsdatabastabell. Och inte alla tabeller som kan användas i en relationsdatabas är korrekta när det gäller kravet på relationsmodellen.
I början, kräver att alla data i en kolumn är av samma typ(för typer, se“Beskrivning av data”2). Ur denna synvinkel är exemplet nedan inte ens vettigt att diskutera:
För det andra, kräver att tabellen tilldelas en primärnyckel.
Dessa krav är nödvändiga men inte tillräckliga. Teorin om relationsdatabaser introducerar begreppet så kallade "normala former" - krav på att organisera data i tabeller. Normala former numreras sekventiellt när kraven blir strängare. I en korrekt utformad databas är tabeller i minst tredje normalform. Följaktligen kommer vi att överväga de tre första normala formerna. Kom ihåg att vi har att göra med tabeller som uppfyller de två grundläggande kraven formulerade ovan.
Första normala formen (1NF)
Den första normalformen anger att all data i tabellen måste vara atomär(odelbar). Listan över motsvarande atomdatatyper bestäms av DBMS. 1NF-kravet är helt naturligt. Det betyder att varje fält i varje post endast ska innehålla ett värde, inte en matris eller någon annan datastruktur. Låt oss ge ett meningsfullt exempel på en tabell som inte finns i 1NF. Anta att vi har betygslistor för elever i ett visst ämne.
Eftersom värdet på utvärderingsfältet inte är atomärt uppfyller tabellen inte kraven i 1NF.
Ett möjligt sätt att presentera betygslistan finns skrivet i riktlinjerna för artikeln "DB design" 2.
Andra normala formen (2NF)
En tabell sägs vara i andra normalform om den är i 1NF och varje icke-nyckelkolumn är helt beroende av primärnyckeln. Med andra ord måste värdet för varje fält helt bestämmas av värdet på primärnyckeln. Det är viktigt att notera att beroende av primärnyckeln förstås just som beroende av nyckeln som helhet, och inte av dess individuella komponent (i fallet med en sammansatt nyckel). Här är ett exempel på en tabell som inte finns i 2NF. För att göra detta, låt oss gå tillbaka till väderprognosexemplet och lägga till ytterligare en kolumn i tabellen - tidpunkten för soluppgången (detta är ett helt rimligt exempel, den här typen av information ges ofta på väderprognoswebbplatser).
Som vi minns har den här tabellen en sammansatt nyckel Datum + tid på dagen. Temperaturfältet är helt beroende av primärnyckeln - det är inga problem med det. Men Soluppgångsfältet beror bara på Datumfältet Tiden på dygnet påverkar inte naturligt soluppgångstiden.
Här är det lämpligt att ställa frågan: vad är den praktiska innebörden av 2NF? Vad är användningen av dessa begränsningar? Det visar sig - stort. Låt oss säga att i exemplet ovan ignorerar utvecklaren 2NF-kraven. Först den så kallade redundans- lagring av onödiga data. När allt kommer omkring, om soluppgångstiden redan är lagrad för en post med ett givet datum, bör den för alla andra poster med ett givet datum vara densamma och generellt sett finns det ingen anledning att lagra den.
Låt oss vara uppmärksamma på orden "borde vara". Varom icke? Faktum är att på databasnivå kontrolleras detta inte på något sätt - nyckeln i tabellen är sammansatt, datumen kan vara desamma (och kommer troligen att vara i betydelsen). Och inga formella restriktioner (och vår uppfattning att "det här kan inte vara" inte gäller för sådana) förbjuder inte att specificera olika soluppgångstider för samma datum.
Tredje normalformen (3NF)
En tabell sägs vara i 3NF om den matchar 2NF och alla icke-nyckelkolumner är ömsesidigt oberoende.
Det är bekvämt att förstå kolumnernas ömsesidiga beroende på följande sätt: kolumner är ömsesidigt beroende om du inte kan ändra en av dem utan att ändra den andra.
Låt oss ge ett exempel på en tabell som inte finns i 3NF. Tänk på ett exempel på en enkel adressbok för att lagra hemtelefonnummer för personer som kanske bor i olika regioner i landet.
I den här tabellen finns det ett samband mellan icke-nyckelkolumner Stad och Stadskod, därför är tabellen inte i 3NF.
Observera att utvecklaren bestämmer förekomsten av ovanstående beroende genom att analysera ämnesområdet - en sådan kollision kan inte ses med några formella metoder. När du ändrar egenskaperna för ämnesområdet kan beroendet mellan kolumnerna försvinna. Till exempel, om olika koder skrivs in inom samma stad (som 495 och 499 i Moskva), upphör motsvarande kolumner att vara relaterade när det gäller brott mot kraven i 3NF.
I teorin om relationsdatabaser betraktas även former av högre ordningar - den normala formen av Boyes - Codd, 4NF, 5NF och ännu högre. Dessa formulär är inte av stor praktisk betydelse, och utvecklare stannar som regel alltid vid 3NF.
Databasnormalisering
Normalisering är processen att konvertera databastabeller till en vald normal form. Normalisering till 2NF handlar som regel om nedbrytning - att dela upp en tabell i flera. Normalisering till 3NF kan vanligtvis göras genom att ta bort beroende (beräknade) kolumner. I vissa fall, när man normaliserar till 3NF, måste man också utföra nedbrytning.
Multi-table databaser, relationer mellan tabeller, främmande nycklar
I praktiken är entabellsdatabaser ganska sällsynta, eftersom ur synvinkeln att modellera en domändatabas betyder närvaron av en tabell närvaron av en enhet. I sin tur innebär närvaron av flera enheter vanligtvis närvaron av relationer mellan dem.
Utan att ha för avsikt att designa en komplett databas, överväg ett exempel som låter dig demonstrera relationer i flerbordsdatabaser.
Anta att vi har att göra med en skola där det finns elever grupperade efter årskurs och lärare som undervisar i vissa ämnen. Vi särskiljer omedelbart fyra enheter: studenter, lärare, klasser och ämnen. Dessa enheter ger oss redan fyra tabeller.
Därefter måste vi lösa frågan om entitetsattribut - vilken typ av information vi kommer att lagra. Eftersom vårt exempel endast är för demonstrationsändamål kommer vi att försöka minimera mängden lagrad information. Vi kommer överens om att lagra efternamn och förnamn för varje elev, för klassen - parallellsiffran och bokstaven som identifierar klassen inuti parallellen, för läraren - efternamn, förnamn och patronym, för ämnet - endast dens namn.
Nu måste vi ta itu med den primära nyckelfrågan. Tabellerna för elever och lärare har i princip ingen nyckel, så vi kommer att ange en surrogatnumerisk nyckel i dem - ett nummer. Klass- och objekttabeller har i allmänhet nycklar. I klasstabellen är nyckeln sammansatt, den bildas av attributen Parallell Number + Letter, och i tabellen över objekt består en enkel nyckel av ett enda fält - namnet på objektet. Kom ihåg att när vi pratade om nycklar nämnde vi att surrogatnycklar ofta läggs till av effektivitetsskäl, för att försöka bli av med sammansatta nycklar eller nyckelfält av obekväma typer, som strängar. Detta är vad vi kommer att göra. Låt oss lägga till en numerisk surrogatnyckel till var och en av tabellerna.
Som ett resultat kommer vi att få följande uppsättning tabeller som motsvarar de beskrivna enheterna.
När vi förstår vilket ämnesområde vi har att göra med, vet vi att våra enheter inte existerar av sig själva - de är förbundna med några av de relationer som vi beskrev ovan. Men hur kopplar man ihop dem tekniskt? Du kan inte göra utan att introducera ytterligare fält och till och med ytterligare tabeller. Låt oss ta itu med relationerna mellan enheter i ordning.
För att tilldela en elev till en viss klass kommer vi att lägga till ett ytterligare fält Klassnummer i tabellen "Student". (Det är tydligt att dess typ helt måste sammanfalla med typen av fältet Klassnummer i tabellen "Klass".) Nu kan vi länka tabellerna "Student" och "Klass" med de sammanfallande värdena i fälten Klassnummer (vi har inte av misstag namngett dessa fält på samma sätt, i praktiken görs detta ofta för att enkelt navigera i de bindande fälten). Observera att en post i "Klass"-tabellen kan motsvara många poster i "Student"-tabellen (och i praktiken överensstämmer det med största sannolikhet - det är svårt att föreställa sig en klass med en elev). Sådana tabeller sägs vara relaterade av relationen " en till många”. Och fältet Klassnummer i tabellen "Student" anropas främmande nyckel... Som du kan se är syftet med främmande nycklar att länka tabeller. Observera att den främmande nyckeln alltid refererar till den primära nyckeln i den relaterade tabellen (dvs. den främmande nyckeln är på "många"-sidan). Den associerade primärnyckeln anropas förälderäven om denna term är mindre vanligt förekommande.
Låt oss illustrera vad som har sagts med ett schema i stil med Microsoft Access (för mer information om Access Data Scheme, se artikeln "Beskrivning av data" 2).
Låt oss nu tänka på lärare och ämnen. Genom att analysera ämnesområdet (detta är det enda sättet - trots allt kan det verkliga tillståndet inte extraheras från den formella modellen själv), märker vi att typen av koppling mellan enheterna "lärare" och "ämne" skiljer sig från den diskuterats ovan. Trots allt kan inte bara ett ämne undervisas av många lärare, utan en lärare kan undervisa i många ämnen. Det finns alltså ett samband mellan dessa enheter " många till många”. Det räcker inte längre att införa ytterligare fält (prova det!). Många-till-många-relationer löses alltid genom att införa en extra tabell. Vi kommer nämligen att organisera tabellen "Lärare-ämne", som har följande struktur:
Tabell "Lärare-ämne"
Denna tabell har en sammansatt nyckel bildad av två av dess fält. Både "Lärare"-tabellen och "Ämne"-tabellen är relaterade till denna tabell i en en-till-många-relation (naturligtvis är "många" i båda fallen på "Lärare-Ämne"-sidan). Följaktligen finns det två främmande nycklar i tabellen "Lärare-Ämne" (båda är en del av en sammansatt primärnyckel, vilket inte är förbjudet) som tjänar till att länka till motsvarande tabeller.
I praktiken, förutom de betraktade "en-till-många"- och "många-till-många"-relationerna, finns det också relationen " en till en”. Ur teoretisk synvinkel är ett sådant förhållande inte av intresse, eftersom två tabeller, sammankopplade av ett en-till-en-förhållande, alltid enkelt kan kombineras till en. Men i riktiga databaser används en en-till-en-relation för att optimera databehandlingen. Låt oss illustrera vad som har sagts med ett exempel.
Låt oss säga att vi lagrar mycket olika information om människor - uppgifterna i deras olika dokument, telefonnummer, adresser, etc. Troligtvis kommer de flesta av dessa uppgifter att användas mycket sällan. Och ofta behöver vi bara ett efternamn, namn, patronym och telefonnummer. Då är det vettigt att organisera de två tabellerna och länka dem i en en-till-en relation. Lagra ofta använd information i en (liten) tabell och resten i en annan. Naturligtvis har tabeller i en en-till-en-relation samma primärnyckel.
Integritetsregler
Relationsmodellen definierar två allmänna regler för databasintegritet: objektintegritet och referensintegritet.
Integritetsregel objekt väldigt enkelt. den kräver att primärnycklar för tabeller inte innehåller nollvärden.
Regel för referensintegritet kräver att främmande nycklar inte innehåller värden som inte är förenliga med överordnade nycklar... För att återgå till exemplet ovan måste vi till exempel kräva att eleverna endast tillhör den klass vars nummer anges i tabellen "Klasser".
De flesta DBMS:er vet hur man övervakar dataintegritet (naturligtvis kräver detta lämpliga ansträngningar från utvecklaren vid beskrivningen av datastrukturer). I synnerhet används mekanismer för att upprätthålla referensintegritet kaskad operationer. Cascading innebär i synnerhet att när en post raderas från en "förälder"-tabell, länkad till en annan tabell i en en-till-många-relation, raderas alla relaterade poster automatiskt från "många"-tabellen (av DBMS själv, utan användaringripande). Och detta är naturligt, eftersom sådana skivor "hänger i luften", de är inte längre kopplade till någonting.
Indexering
Indexering är oerhört viktigt ur praktisk tillämpningssynpunkt, men valfritt ur ren teorisynpunkt. Huvudsyftet med indexering är att optimera (påskynda) sökning (och följaktligen vissa andra operationer med databasen). Indexering kräver i alla fall ytterligare resurser (på fysisk nivå skapas oftast speciella indexfiler). Operationer relaterade till datamodifiering, indexering kan till och med sakta ner, därför är index vanligtvis sällan modifierade tabeller, som ofta genomsöks.
Indexfilen är mycket lik indexet för en vanlig bok. För varje indexvärde lagras en lista med tabellrader som innehåller det givna värdet. Följaktligen behöver du inte titta igenom hela tabellen för att söka - du behöver bara titta i indexet. Ändring av poster kan dock kräva att indexet återskapas. Och detta tar extra tid.
Det är förstås inte tal om att undervisa i relationsdatabasteori som en del av en grundläggande datavetenskaplig kurs! Ändå är den här artikeln mycket viktig för vårt uppslagsverk, eftersom vi i det här fallet har att göra med material som inte kan presenteras fullt ut på lektionerna, men läraren måste äga det. Varför?
För det första eftersom ett antal begrepp studeras just inom ramen för grundkursen. Detta är både en tabellvy av data och tabellnycklar. Och vi vet alla att det är mycket svårt att korrekt och korrekt ange bara några begrepp utan att presentera den allmänna bilden.
För det andra, att utföra enkla databasfrågor med barn (det relevanta materialet presenteras i artikeln "Databehandling" 2), är det nödvändigt att ta itu med tabeller som är korrekta ur relationsteorinsynpunkt. Det finns ingen anledning att förklara för eleverna att dessa tabeller är korrekta, men "om... så skulle tabellen vara fel", men det är oacceptabelt att använda dåliga exempel.
I en specialiserad datavetenskapskurs kan situationen vara fundamentalt annorlunda. Den viktigaste och extremt produktiva arbetsformen i specialiserade klasser är design. Inom ramen för utbildningsprojekt är det möjligt och nödvändigt att utveckla enkla databaser och här kan man inte klara sig utan grunderna för den angivna teorin. Följande måste dock beaktas:
De domäner som ska modelleras bör inte vara för stora;
Eleverna bör vara mycket bekanta med dem (i denna mening är "Skola"-projektet, som är ganska tråkigt för alla, inte det sämsta valet!);
Det är naivt att förvänta sig att eleverna efter att ha lyssnat på teorins grunder kommer att kunna designa något själva. Varje steg måste tas med dem och ange detaljerade skäl för deras handlingar.