Vad betyder relationell. Grundläggande begrepp för ett algoritmiskt språk

Facebook

Nivå 1: Nivå externa modellerÄr den mest högsta nivån där varje modell har sin egen syn på data. Denna nivå definierar databasvyn 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. I själva verket återspeglar den konceptuella nivån en generaliserad domänmodell.

Fysiskt lager(Databas): Det här är själva data i filer eller sidstrukturer på externa lagringsmedier.

Datamodeller

Följande datamodeller utmärks:

1. Infologisk

2. Datum logiskt

3. Fysiskt

Databasdesignprocessen börjar med utformningen av en infologisk modell. En infologisk datamodell är en generaliserad informell beskrivning av den skapade databasen, gjord med naturligt språk, matematiska formler, tabeller, grafer och andra medel som är begripliga för alla som arbetar med utformningen av databasen.

Domän tupel

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 ändras förrän vissa förändringar i den verkliga världen kräver förändringar utanför definitionen, så att modellen fortsätter att visa ämnesområdet.

Det finns många tillvägagångssätt för att bygga denna modell: grafmodeller, semantiska nätverk, entitetsrelation och andra.

Datalogisk modell

Den infologiska modellen ska visas i en datalogisk modell som DBMS kan förstå. En 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 för 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 lägre nivåer. Undantaget är den 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ännamns system \ adress. På den första nivån (roten av trädet) ligger vår planetjord, på det andra - landet, på det tredje - regionen, på det fjärde - lokalitet, Gata, hus, lägenhet. En typisk representant är ett DBMS från IBM - IMS.

Alla instanser av denna typättling med vanligt exemplar en förfaderstyp som kallas tvillingar. En fullständig traversal ordning definieras för databasen. Uppifrån och ner och från höger till vänster.

Fysisk modell

En fysisk modell bygger på 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ändare en eller annan verktygssats för att anpassa modellen för en specifik databas.

Exempel: Speciellt för en relationsdatabas tar den redan hänsyn till:

1. Fysiska aspekter av lagring av tabeller i specifika filer.

2. Skapande av index som optimerar hastigheten på operationer med data med programmet.

3. Avrättningar olika handlingaröver data vid vissa händelser, definierade av användare som använder triggers och lagrade procedurer.

Infologiska modeller X

Fysiska modeller

För alla nivåer och för alla presentationsmetoder ämnesområde, ligger kodningen av begrepp om relationer mellan begrepp. Ett viktigt skede i utvecklingen av någon informationssystem Håller systemanalys:

Formalisering av ämnesområdet och representation av systemet som en uppsättning komponenter.

Sammansättning som grund för systemanalys kan vara funktionell (bygga en hierarki).

Men i de flesta system, när det gäller databaser, är datatyper mer statiska än hur de behandlas. Därför har sådana metoder för systemanalys som dataflödesdiagram utvecklats intensivt. Utveckling av relationsdatabaser. Stimulerade utvecklingen av tekniker för utveckling av byggdata, särskilt ER -diagram ER. Relationsdatamodellen använder direkt begreppet relation som en kartläggning. Hon är närmast konceptuell modell datapresentation. Och det ligger ofta till grund för det.

Till skillnad från grafmodellteoretikern, i relationsmodellen, implementeras relationer mellan relationer på ett implicit sätt, för vilka 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 attributfaktum måste vara närvarande i det underordnade förhållandet.

Ett sådant attribut för relationer i huvudrelationerna kommer att kallas den primära nyckeln, och i den underordnade, den sekundära nyckeln.

Framsteg i utvecklingen av programmeringsspråk som främst är associerade med datatypning och framväxten av objektorienterade språk gjorde det möjligt att närma sig analysen av komplexa system ur hierarkiska representations synvinkel, det vill säga med hjälp av objektklasser med polymorfism, arv och inkapslingsegenskaper.

UTVECKLINGEN ÄR EN BORD.

Redigera tabeller, poster ...

Ta bort det som skapades och

Redigerar.

Relationsdatabasmodell

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, som innehåller sina egna data (i form av tabeller) och sätt att arbeta och manipulera med den (i form av länkar). Relationsmodellen förutsätter tre konceptuella element: Struktur, Integritet och Databehandling. Dessa element har sina egna obligatoriska begrepp som måste förklaras för ytterligare presentation.

Tabellen betraktas som en direkt datalagring. Traditionellt i relationssystem bordet heter 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 anges för relationen, det vill säga ett eller flera attribut vars värden inte är desamma samtidigt - identifieraren kallas primär nyckel.Domän det är uppsättningen tillåtna homogena värden för detta eller det där 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 över namnen på anställda vid en institution fungera som en domän, men inte alla efternamn kan finns i tabellen).

SUMMER Kireeva 25.50 Motyleva 17.05 … …. …

Attityd

attribut

Fält KOD, NAME, SUMM är tabellattribut i rubriken.

Par KOD 5216, NAME Kireev, SUMM 25.50 är element i relationskroppen.

I relationsdatabaser, till skillnad från andra modeller, anger användaren vilken data som behövs för honom och inte hur man gör det. Av denna anledning är processen med att flytta och navigera i databasen i relationssystem automatiska 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. Således optimerar 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 för poster i tabellerna och hur de är grupperade.

Dessutom utför relationsdatabasen också funktioner i en katalog. Katalogen innehåller en beskrivning av alla objekt som utgör databasen: tabeller, index, triggers, etc. Uppenbarligen viktigt 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 själva katalogen är en uppsättning tabeller, så DBMS kan manipulera den på traditionella sätt utan att använda sig av 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 är dock i vissa fall en avvikelse från den här egenskapen tillåten. Så länge det finns en primär nyckel i relationen utesluts identiska tupler.

2. Tupler ordnas inte uppifrån och ner - det finns helt enkelt inget begrepp om ett positionsnummer i en relation. I ett förhållande utan att förlora information kan du framgångsrikt ordna tuplerna i valfri ordning.

3. Attribut ordnas inte från vänster till höger. Attribut i relationsrubriken kan placeras i valfri ordning, medan datans integritet inte kränks. Därför finns inte heller begreppet ett positionsnummer i relation till ett attribut.

4. Attributets värde består av logiskt odelbara enheter - detta följer av att värdena är hämtade från domäner, annars kan vi säga att relationer inte innehåller grupper av repetitioner. Det vill säga, de är normaliserade.

Relationssystem stöder flera typer av relationer:

1. Namngivna variabler är relationsvariabler som definieras i DBMS med hjälp av skapandeuttalanden och som regel är nödvändiga för en bekvämare presentation av information för användaren.

2. Det underliggande förhållandet är direkt viktig del DB får därför sitt eget namn vid designen.

3. En härledd relation är en som definierades genom andra, vanligtvis grundläggande, relationer med hjälp av DBMS: s medel.

4. Denna vy är faktiskt en namngiven härledd relation, och vyn uttrycks uteslutande genom DBMS -operatörer som tillämpas på namngivna relationer, så de existerar inte fysiskt i databasen.

5. Resultatet av frågor är en namngiven härledd relation som innehåller data (resultatet av en specifik fråga). Resultatet lagras inte i databasen utan existerar så länge användaren behöver det.

6. En lagrad relation är en som fysiskt upprätthå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

1 1 Ett en-till-många-förhållande är att varje element (tuppel A) vid varje tidpunkt motsvarar flera element i tuppel B
∞ Binär länk

Studenter

Lärare

Schema för klasser

∞

Studenter

Ternära förbindelser

Dataintegritet

I relationsmodeller ges frågan om dataintegritet en särskild plats. Minns att nyckeln eller potentiell nyckel detta är den minsta uppsättningen attribut, med de värden som det är möjligt att entydigt hitta den nödvändiga tupeln, betyder minimalitet att uteslutning av alla attribut från uppsättningen inte tillåter identifiering av tupeln med de återstående attributen.

Varje relation har minst en möjlig nyckel... En av dem tas som huvudnyckeln.

När du väljer primärnyckel Preferenser 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 relationens primära nyckel, 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 noga övervägas när du utformar en databas.

Om utländska nycklar. Det är värt att notera att eftersom relation C förbinder relation B och A måste det inkludera främmande nycklar som motsvarar primärnycklarna för relation A och B.

Den främmande nyckeln till ett bord bildas med hjälp av flera primära nycklar i andra tabeller.

Således, när man överväger problemet med att välja en metod för att länka ett förhållande i en databas, uppstår frågan om vad som bör vara de främmande nycklarna. Dessutom för alla främmande nyckel det är nödvändigt att lösa problemet som är förknippat med möjligheten (eller omöjligheten) att odefinierade värden visas i främmande nycklar (NULL - värden- värde attribut för saknad information). Med andra ord, kan det finnas någon tupel i ett förhållande som ingen tupel är känd för i det relaterade förhållandet?

Å andra sidan måste du tänka i förväg om vad som händer när du tar bort tupler från relationen som den främmande nyckeln hänvisar till. Det finns dock följande möjliga möjligheter:

· Drift kaskader- det vill säga att radering av tupler i en relation leder till borttagning av tupler som är relaterade till relationen. Till exempel att radera information om efternamnet på förnamnet, etc. en anställd i ett avseende resulterar i en radering av sina löner i ett annat avseende;

· Drift begränsad till - det vill säga endast de tupler för vilka det inte finns någon relaterad information i annat avseende tas bort. Inte all information raderas (inte i alla avseenden) eftersom den kan användas på andra sätt, radering av information som leder till ett intrång i dataintegriteten. Om sådan information är tillgänglig kan radering inte utföras, till exempel radering av information om namn, efternamn etc. en anställd är endast möjlig 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 huvudnyckeln för ett förhållande som refereras av någon främmande nyckel. Här har du samma alternativ som för att radera:

· Operationen är kaskad, det vill säga när den främsta nyckeln uppdateras uppdateras den främmande nyckeln i den relaterade relationen. Till exempel, uppdatering av huvudnyckeln i en relation där medarbetarinformation lagras resulterar i en uppdatering av den utländska nyckeln i relationen med löneinformation.

· Operationen är begränsad, det vill säga endast de primära nycklar som det inte finns någon annan relaterad information för uppdateras. Om sådan information är tillgänglig kan uppdateringen inte göras. Till exempel är det bara möjligt att uppdatera huvudnyckeln i en relation där information om en anställd lagras om det inte finns information om hans lön i det relaterade förhållandet.

Relationsalgebra

Den formella grunden för basen för den relationsdatabasmodellen är relationsalgebra, baserad på uppsättningsteori och med tanke på en speciell operatör över relationer, och relationsberäkning baserad på matematisk logik.

Arbete

A A A B C C

D D E

D D

A B C

D D E

F F G

Det bör noteras att relationsalgebra ä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 relationsmodell data. Varje fråga som uttrycks med ett enkelt relationellt algebrauttryck eller en enkel relationell beräkningsformel kan uttryckas med en enda operator för detta språk.

Relationsalgebra har viktig egendom- den är stängd i relation till begreppet relation. Detta innebär att uttrycket av relationsalgebra utförs över relationer relationsdatabaser data och resultaten av deras beräkning är också samband.

Huvudidén med relationsalgebra är att medlen för att manipulera relationer, betraktade som en uppsättning, är baserade på traditionella multipla operationer, kompletterade med vissa 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ämtar en relation (unary operation)

Relationsprojektion (unary operation)

Fackliga förbindelser

Korsning av relationer (binär operation)

Subtrahering av relationer

Produktrelation

Anslutande relationer

Uppdelning av relationer

Dessa operationer kan förklaras enligt följande:

· Resultatet av att välja en relation för något villkor är en relation som endast innehåller de tuplerna av den ursprungliga relationen som uppfyller detta villkor.

· När en relation projiceras på en given uppsättning av dess attribut, kommer en relation vars tupler tas från motsvarande tupler i den första relationen att erhållas.

· När du utför en kombination av två relationer, kommer en relation att erhållas som inkluderar alla tupler som ingår i minst en av de relationer som deltar i operationen.

· När man utför skärningspunkten mellan två relationer kommer en relation att erhållas som inkluderar alla tupler som ingår i båda initiala relationerna.

· När du utför operationen för 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 du utför en direkt produkt av två relationer, erhålls en relation vars tupler är en kombination av tuplerna i den första och andra relationen.

· När två relationer förenas av något villkor, bildas det resulterande sambandet av tupler som en kombination av tupler av det första och andra förhållandet som uppfyller detta villkor.

· Funktionen för relationsdivision 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 förhållandet mellan det första attributet för tuplerna för den första relationen, så att uppsättningen värden för det andra attributet sammanfaller med uppsättningen värden för det andra förhållandet .

Förutom ovanstående finns det ett antal specialoperationer som är typiska för att arbeta med databaser:

· Som ett resultat av bytet av namn är relationen en uppsättning tupler, som sammanfaller med den ursprungliga relationens kropp, men namnen på attributen har ändrats.

Därav följer att resultatet av en relationsoperation är en viss 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 verksamheten inom relationsalgebra verkligen är stängd för begreppet relation. Låt oss börja med operationen förena relationer Detta gäller emellertid lika för korsnings- och kombinationsoperationer, det vill säga i relationell algebra är resultatet av en facklig operation en relation. Om tillåtet till relationsalgebra 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 relationsalgebra ska stängas med avseende på begreppet relation, då en sådan operation sammanslagningarär meningslös. Detta leder till att begreppet uppstår relationskompatibilitet på sammanslagning: två relationer är endast kompatibla om de har samma rubriker, det vill säga att de har samma uppsättning attributnamn och samma attribut definieras i samma domän.

Förutsatt att två relationer är kompatibla när det gäller unionen, när funktionen av unionen i skärningspunkten för 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 unionen, det vill säga att de är kompatibla i allt utom attributnamn, innan du utför en operation som en anslutning, kan dessa relationer göras helt kompatibla när det gäller unionen genom att använda byta namn. .

Funktionen av den direkta produkten av två relationer väcker nya problem. I Set Theory 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 uppsättningar är det möjligt att få en direkt produkt för två relationer. Resultatet blir dock inte en attityd. Elementen i resultatet kommer inte att vara tupler, utan par av tupler. Därför används i relationsalgebra 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 tupel som bildas genom att slå ihop en tupel av den första relationen och en tupel av den andra relationen. Omedelbart uppstår ett andra problem, förknippat med att erhålla en korrekt formad rubrik för den resulterande relationen, vilket leder till behovet av att införa 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 attributnamn för dessa relationer inte överlappar varandra. Alla två relationer kan konverteras till en kompatibel form genom att ta den direkta produkten genom att tillämpa byt namn på en av dessa relationer.

Hämtningsoperationen kräver två relationer: den ursprungliga relationen, operanden och ett enkelt begränsningsvillkor. Som ett resultat av hämtningsoperationen produceras en rubrikrelation som matchar operandrelationshuvudet, och kroppen innehåller de operandrelationstubblarna som uppfyller värdena för begränsningstillståndet.

Låt oss presentera ett antal operatörer.

Låt fackföreningen beteckna fackföreningsoperationen, skär skärningsoperationen, minus subtraktionsoperationen. För att beteckna en urvalsoperation använder vi 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 provtagningsvillkor

A där C1 OCH C2 är identisk med (A där C1) skär (A där C2)

A där C1 ELLER C2 är identisk med (A där C1) förening (A där C2)

A där C1 inte C2 är identisk med (A där C1) minus (A där C2)

Med hjälp av dessa definitioner är det möjligt att implementera urvalsoperationer där urvalsvillkoret är godtyckligt booleskt uttryck sammansatt av enkla förutsättningar med logiska länkar (och, eller, inte). Funktionen för att ta projektioner, förhållandet A op till listan över attribut a1, a2,…, an kommer att vara en relation vars titel är uppsättningen attribut, a1, a2,…, an. Resultatet av kroppen kommer att bestå av tupler för vilka det i relation A finns en tupel, a1 -attributet har b1 -värdet, a2 -attributet b2 -värdet< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.

Kopplingsoperationen, ibland kallad villkorlig sammankoppling, kräver två operander, ett sammanfogningsförhållande och en tredje operand, ett enkelt villkor. Låt förhållandet A och B. anslutas. Liksom i fallet med urvalsoperationen har tillståndet för kopplingen C formen, (a komp – b) eller (en comp –op const) där A och B är namnen av attributen för relationerna A och B, konstant- bokstavligen ges konstant. Comp-op är en giltig jämförelseoperation i detta sammanhang. Sedan är resultatet av kopplingsoperationen per definition förhållandet som erhålls genom att utföra begränsningsoperationen, efter villkor C för den direkta produkten av förhållandet A och B.

Det finns en viktig specialfall anslutningar, naturlig anslutning. En kopplingsoperation kallas en naturlig sammanfogningsoperation om sammanfogningsvillkoren är (a = b) där a och b är attribut för olika sammanslutningsoperander. Detta fall är viktigt eftersom det är särskilt vanligt i praktiken och det finns effektiva implementeringsalgoritmer för det i ett DBMS. Den naturliga kopplingsoperationen tillämpas på ett par 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 i förbindelserna A och B. Sedan är den naturliga föreningen resultatet av föreningen av A och B som projiceras på a. Funktionen av den naturliga kopplingen ingår inte direkt i uppsättningen operationer för relationella algebra, men det har mycket viktig praktisk betydelse.

Relationsfördelningen 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 antar att attribut b1 för relation A och attribut b1 av relation B definieras på samma domän. Låt oss kalla uppsättningen attribut (aj) ett sammansatt attribut a, och uppsättningen (bj) med ett sammansatt attribut b. Efter det kommer vi att prata om relationsdivisionen av den binära relationen A (a, b) med den unära relationen B (b).

Resultatet av att dividera A med B är en unary relation C (a), som består av sådana tuplar v att i relation A finns det tupler som i mängden värden (w) inkluderar mängden värden av b i förhållande till B.

Eftersom division är den svåraste operationen, låt oss förklara det med ett exempel. Låt det finnas två relationer i studenternas databas: STUDENTER (HELT NAMN, NUMMER) och NAMN (HELT NAMN), och den eniga relationen NAMN innehåller alla efternamn som institutets studenter har. Efter att ha utfört operationen för relationell uppdelning av relationen STUDENTER med relationens NAMN, kommer en unary relation att erhållas som innehåller antalet studentkort som tillhör studenter med alla efternamn som är möjliga på detta institut.

Relationsnotation

Antag att det finns en databas med strukturen STUDENTER (nummer, namn, stipendium, gruppkod) och relationen GRUPP (gr_nom, gr_col, gr gammal). Antag att du måste ta reda på namn och antal elever. biljetter för studenter som är chef för grupper med fler än 25. I relationsalgebra måste du ta följande åtgärder för en förfrågan 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 den tidigare operationen på attributet studentnamn, studentnummer.

Här, steg för steg, formuleras sekvensen för körning av en fråga i databasen, som var och en motsvarar en relationsoperation. Om vi formulerar samma fråga med relationskalkylen får vi 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 bildning. 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 relationerna STUDENTER och GRUPPER. Båda metoderna som beaktas 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 relationsberäkning är begreppen för en variabel med ett visst intervall av dess värde och begreppet en välformad formel baserad på variabler och specialerbjudanden. Funktioner. Vad är variabelns omfattning? Tupelberäkningen och domänberäkningen, det vill säga längs eller tvärs, skiljer sig åt. I tuple calculus är variabla domäner databasrelationer, d.v.s. acceptabelt värde varje variabel är en tupel av någon relation. I beräkningen av domäner är definitionsdomänerna för variabler domänerna på vilka attributen för databasrelationer definieras, det vill säga att det giltiga värdet för varje variabel är värdet för varje variabel.

Byte

Heltal

Sträng

Röding

Kommandot RANGE används för att definiera tupler. Till exempel, för att definiera en STUDENT -variabel vars omfattning är STUDENTS, måste du använda konstruktionen RANGE STUDENT IS STUDENTS. Av denna definition följer att när som helst den variabla studenten representerar en tuppel av STUDENTS -förhållandet. När du använder tupelvariabler i formler kan du referera till attributvärdena för variablerna. För att till exempel referera till värdet på STUD_NAME -attributet för STUDENT -variabeln måste du använda konstruktionen STUDENT.STUD_NAME.

Korrekt konstruerade formler tjänar till att uttrycka villkor som ställs på tupelvariabler. Sådana formler är baserade på enkla jämförelser, som är operationer för att jämföra värdena för attribut för variabler och bokstavligen specificerade konstanter. Till exempel konstruktionen STUDENT.STUD_NOM = 123456. Är en enkel jämförelse. Mer svårt alternativ sammansatta formler är med hjälp av logiska kopplingar 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, är EXIST (existentiell kvantifierare) var (F) och FORALL (för alla tupler) var (F) konstruktioner 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 gratis. Detta innebär att om värdet "sant" för vissa uppsättningar värden av lediga variabler vid beräkning av formler erhålls, kan dessa värden inkluderas i den resulterande relationen. Om kvantifieraren används vid konstruktion av formler, är variablerna bundna. Vid beräkning av värdet på en sådan välformad formel används inte ett enda värde för den associerade variabeln, utan hela dess definitionsdomän.

1) EXISTS 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å tar formeln för den aktuella tupeln för STUD1 -variabeln värdet sant endast om det i hela relationen studenter är en sådan tupel associerad med STUD2 -variabeln att värdet på dess STUD_STIP -attribut uppfyller villkoren för intern jämförelse. Korrekt konstruerad formel nr 2 för den konstruerade tupeln STUD 1 tar på sig värdet true om värdet för STUD.STYP -attributet för alla tupler relaterar STUDENTER till variabeln STUD 2 uppfyller det interna villkoret.

Sålunda tillhandahåller välformulerade formler ett sätt att uttrycka ett urvalsvillkor från en databasrelation. För att kunna använda relationskalkylen för verkligt arbete med databasen krävs ytterligare en komponent som definierar uppsättningen och kolumnnamnen på den resulterande relationen. Denna komponent kallas mållista.

Mållista ser ut som:

· Var.attr - namnet på en ledig variabel, attr är namnet på relationsattributet som variabeln var definieras på.

· Var som motsvarar en relation från en lista, Var.attr1, Var.attr1… Var.attr№ innehåller 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 fall där koden i formeln använder flera fria variabler med samma omfattning. I domänberäkning är domäner inte domäner utan domäner. När det gäller DB -STUDENTERNA I GRUPPEN kan vi prata om domänen variabler NAME(Domänvärden är giltiga namn eller NOM STUD). (Domänvärdena är giltiga studentnummer).

Huvudskillnaden mellan beräkningen av domäner och kalkylen för tupler är närvaron av ytterligare en uppsättning predikat som gör att man kan uttrycka de så kallade medlemsvillkoren. Om R är en n-ary-relation med attribut (a1, a2, ... an), har medlemsvillkoret 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 true eller false för något argument. En relation kan ses som ett predikat med argument som är attribut för den aktuella relationen. Om den givna specifika uppsättningen tupler finns i relationen, kommer predikatet att returnera sant, annars blir det falskt.

I alla andra avseenden ser formler och uttryck för domänberäkning ut som formler och uttryck för tuppelberäkning. Relationell domännotation är kärnan i de flesta formulärbaserade språkfrågor.

Liknande information.

Som regel kan alla webbapplikationer delas in i två huvuddelar: front-end, där all information på webbplatsen visas, och back-end, där denna information genereras och placeras. I denna artikel kommer vi att prata om vad relationsdatabaser är och hur man utformar dem.

Databasen lagrar poster på ett särskilt organiserat sätt så att information enkelt kan hittas och hämtas. Varje databas består av en eller flera tabeller. Ett kalkylblad består av rader och kolumner. Alla rader har samma kolumner och varje kolumn innehåller data. I allmänhet, för en bättre förståelse, låt oss definiera att tabellerna i databasen liknar dem som du såg i Excel.

Tabelldata kan infogas, återställas, uppdateras och raderas. För paketet med dessa operationer skapades en särskild förkortning CRUD (Create-Read-Update-Delete).

Relationsdatabaser är databaser där all information lagras i tabeller som är förbundna med varandra genom speciella relationer. Dessa relationer gör att vi kan hämta och kombinera data från en eller flera tabeller med en enda fråga.

Men allt detta är bara ord. För att verkligen förstå vad relationsdatabaser är måste du öva mer. Låt oss börja och se vilka data vi har att arbeta med.

Steg 1. Förbered data

För att vi ska ha något att arbeta med skrev jag frågan "#databaser" på Twitter och bildade en tabell med 10 poster:

bord 1

fullständiga namn	Användarnamn	följande_användarnamn
Boris Hadjur	_DreamLead	Scootmedia, MetiersInternet
Gunnar svalander	GunnarSvalander	klout, zillow
GE Software	GEsoftware	DayJobDoc, byosko
Adrian burch	adrianburch	CindyCrawford, Arjantim
Andy Ryder	AndyRyder5	MichaelDell, Yahoo
Andy Ryder	AndyRyder5	MichaelDell, Yahoo
Brett Englebert	Brett_Englebert
Brett Englebert	Brett_Englebert	RealSkipBayless, stephenasmith
Nimbus datasystem	NimbusData	dellock6, rohitkilam
SSWUG.ORG	SSWUGorg	drsql, steam_games

Först och främst, låt oss ta itu med kolumnerna:

Detta är riktiga data. Du kan hitta och uppdatera dem om du vill.

Bra. Nu finns alla våra data på ett ställe. Gör det det enkelt för oss att söka efter dem? Inte riktigt. Detta bord är långt ifrån idealiskt. För det första har vi i vissa kolumner dubblettposter: till exempel i x "användarnamn" och "följande_användarnamn". Även följande_användarkolumn bryter mot reglerna för relationsmodeller, sedan den innehåller mer än 1 värde i cellerna (poster separeras med kommatecken).

Dessutom stöter vi på dubbletter i rader.

Dubblettdata är verkligen ett problem eftersom de gör CRUD -processen svår. Till exempel, när du söker igenom en given tabell, kommer det att ta ytterligare tid att bearbeta dubbletter. Om användaren dessutom uppdaterar tweeten måste vi skriva över alla dubbletter.

Lösningen på detta problem är att dela upp tabell 1 i flera tabeller. Låt oss ta itu med det första problemet, vilket eliminerar dubbletter av kolumner.

Steg 2. Bli av med dubbletter av kolumner

Som nämnts ovan innehåller kolumnerna "användarnamn" och "efteranvändarnamn" dubblettdata. De kom till för att jag ville visa sambandet mellan tweets och användare. Låt oss förbättra vår databasstruktur genom att dela den befintliga tabellen i två: i en kommer vi att lagra information och i den andra - förhållandet mellan poster.

Eftersom @Brett_Englebert prenumererar på @RealSkipBayless kommer vi att visa det i följande tabell enligt följande: placera namnet @Brett_Englebert i kolumnen "from_user" och @RealSkipBayless i "to_user." Låt oss se hur "följande" tabell kommer att se ut efter delning Tabeller 1:

Tabell 2. nedan

från_användare	till_användare
_DreamLead	Scootmedia
_DreamLead	MetiersInternet
GunnarSvalander	klout
GunnarSvalander	zillow
GEsoftware	DayJobDoc
GEsoftware	byosko
adrianburch	CindyCrawford
adrianburch	Arjantim
AndyRyder	MichaelDell
AndyRyder	Yahoo
Brett_Englebert	RealSkipBayless
Brett_Englebert	stephenasmith
NimbusData	dellock6
NimbusData	rohitkilam
SSWUGorg	drsql
SSWUGorg	steam_games

Tabell 3.användare

fullständiga namn	Användarnamn	text	skapad vid
Boris Hadjur	_DreamLead	Vad tycker du om #e -post #kampanjer #trafik i #USA? Är det en bra marknad nuförtiden? har du #databaser?	Tis, 12 feb 2013 08:43:09 +0000
Gunnar svalander	GunnarSvalander	Bill Gates pratar databaser, gratis programvara på Reddit http://t.co/ShX4hZlA #billgates #databaser	Tis, 12 feb 2013 07:31:06 +0000
GE Software	GEsoftware	RT @KirkDBorne: Läsningar i #databaser: utmärkt läslista, många kategorier: http://t.co/S6RBUNxq via @rxin Fascinerande.	Tis, 12 feb 2013 07:30:24 +0000
Adrian burch	adrianburch	RT @tisakovich: @NimbusData på @Barclays Big Data -konferensen i San Francisco idag, pratar #virtualisering, #databaser och #flashminne.	Tis, 12 feb 2013 06:58:22 +0000
Andy Ryder	AndyRyder5	http://t.co/D3KOJIvF artikel om Madden 2013 som använder AI för att framkalla superskålen # databaser # bus311	Tis, 12 feb 2013 05:29:41 +0000
Andy Ryder	AndyRyder5	http://t.co/rBhBXjma en artikel om sekretessinställningar och facebook #databaser # bus311	Tis, 12 feb 2013 05:24:17 +0000
Brett Englebert	Brett_Englebert	# BUS311 University of Minnesota NCFPD skapar # databaser för att förhindra "matbedrägeri". http://t.co/0LsAbKqJ	Tis, 12 feb 2013 01:49:19 +0000
Brett Englebert	Brett_Englebert	# BUS311 -företag kan skydda sina # databaser för produktion, men hur är det med deras backupfiler? http://t.co/okJjV3Bm	Tis, 12 feb 2013 01:31:52 +0000
Nimbus datasystem	NimbusData	@NimbusData VD @tisakovich @BarclaysOnline Big Data -konferens i San Francisco idag, pratar #virtualisering, #databaser och #flashminne	Mån, 11 feb 2013 23:15:05 +0000
SSWUG.ORG	SSWUGorg	Glöm inte att registrera dig för vår GRATIS expo i fredags: #Databaser, #BI och #Sharepoint: Vad du behöver veta! http://t.co/Ijrqrz29	Mån, 11 feb 2013 22:15:37 +0000

Bättre nu. Nu i tabellen "användare" (tabell 3) lagrar vi bara information om tweets, och i följande tabell (tabell 2) - användarberoendet.

Grundaren av relationsdatabassteorin, Edgar Codd, skulle kalla denna process (borttagning av dubbletter från tabellkolumner) en första normal form av databasen.

Steg 3. Ta bort repetitioner från strängar

Nu ska vi åtgärda andra problem, nämligen att bli av med dubbletter i raderna i "användare" -tabellen. Eftersom användare @ AndyRyder5 och @Brett_Englebert har lagt ut flera tweets vardera, finns deras namn i tabellen "användare" ( Tabell 3) dupliceras i kolumnen fullnamn. Detta problem löses också genom att dela upp "användare" -tabellen.

Eftersom texten på tweeten och tiden den skapades är unika data, kommer vi att lägga dem i samma tabell. Vi måste också ange förhållandet mellan tweets och användare. För detta skapade jag en speciell kolumn som heter användarnamn.

Tabell 4. tweet

Användarnamn	text	skapad vid
_DreamLead	Vad tycker du om #e -post #kampanjer #trafik i #USA? Är det en bra marknad nuförtiden? har du #databaser?	Tis, 12 feb 2013 08:43:09 +0000
GunnarSvalander	Bill Gates pratar databaser, gratis programvara på Reddit http://t.co/ShX4hZlA #billgates #databaser	Tis, 12 feb 2013 07:31:06 +0000
GEsoftware	RT @KirkDBorne: Läsningar i #databaser: utmärkt läslista, många kategorier: http://t.co/S6RBUNxq via @rxin Fascinerande.	Tis, 12 feb 2013 07:30:24 +0000
adrianburch	RT @tisakovich: @NimbusData på @Barclays Big Data -konferensen i San Francisco idag, pratar #virtualisering, #databaser och #flashminne.	Tis, 12 feb 2013 06:58:22 +0000
AndyRyder5	http://t.co/D3KOJIvF artikel om Madden 2013 som använder AI för att framkalla superskålen # databaser # bus311	Tis, 12 feb 2013 05:29:41 +0000
AndyRyder5	http://t.co/rBhBXjma en artikel om sekretessinställningar och facebook #databaser # bus311	Tis, 12 feb 2013 05:24:17 +0000
Brett_Englebert	# BUS311 University of Minnesota NCFPD skapar # databaser för att förhindra "matbedrägeri". http://t.co/0LsAbKqJ	Tis, 12 feb 2013 01:49:19 +0000
Brett_Englebert	# BUS311 -företag kan skydda sina # databaser för produktion, men hur är det med deras backupfiler? http://t.co/okJjV3Bm	Tis, 12 feb 2013 01:31:52 +0000
NimbusData	@NimbusData VD @tisakovich @BarclaysOnline Big Data -konferens i San Francisco idag, pratar #virtualisering, #databaser och #flashminne	Mån, 11 feb 2013 23:15:05 +0000
SSWUGorg	Glöm inte att registrera dig för vår GRATIS expo i fredags: #Databaser, #BI och #Sharepoint: Vad du behöver veta! http://t.co/Ijrqrz29	Mån, 11 feb 2013 22:15:37 +0000

Tabell 5. användare

fullständiga namn	Användarnamn
Boris Hadjur	_DreamLead
Gunnar svalander	GunnarSvalander
GE Software	GEsoftware
Adrian burch	adrianburch
Andy Ryder	AndyRyder5
Brett Englebert	Brett_Englebert
Nimbus datasystem	NimbusData
SSWUG.ORG	SSWUGorg

Efter delning i användartabellen ( Tabell 5) vi har unika (icke-upprepande) strängar.

Denna process för att ta bort dubbletter från strängar kallas andra normalformstvång.

Steg 4. Slå samman tabeller baserade på nycklar

Så som ett resultat av våra handlingar delades tabell 1 in i 3 delar: följande (tabell 2), tweets (tabell 4), användare (tabell 5). Alla dubbletter har eliminerats. För att vi lätt ska kunna extrahera data från denna struktur i framtiden måste vi ansluta oberoende tabeller med speciella relationer som ger oss information om vilken användare som tillhör vilken tweet och vem som prenumererar på vem.

För att skapa länkar mellan poster måste vi ange en unik identifierare som kallas primärnyckeln.

Generellt sett har vi redan gjort detta i tabellerna 4 och 5. I tabellen "användare" är huvudnyckeln kolumnen "användarnamn", eftersom användarnamnet måste vara ett unikt värde och inte kan upprepas. I tabellen "tweets" använder vi den här nyckeln för att indikera förhållandet mellan en användare och en tweet. Kolumnen "användarnamn" i tabellen "tweets" kallas en främmande nyckel.

Om du någonsin har arbetat med databaser kanske du undrar: kan vi använda kolumnen "användarnamn" som huvudnyckel?

Å ena sidan kan detta förenkla sökprocessen, eftersom vi inte använder några numeriska ID. Å andra sidan, vad händer om användaren vill ändra sitt användarnamn? Detta kan leda till ett stort antal problem. För att inte hamna i en liknande situation är det bättre att använda numeriska ID. Allt beror på ditt system. Om du ger dina användare möjlighet att ändra inloggningar är det bättre att använda ett automatiskt ökat numeriskt ID-fält som huvudnyckel. Annars är kolumnen "användarnamn" bra för den här rollen. Jag lämnar det som det är.

Låt oss ta en titt på tweets -tabellen (tabell 4). Huvudnyckeln måste vara unik för varje rad. Vilken kolumn i den här tabellen kan vi välja för den här rollen? Kolumnen ”created_at” fungerar inte, eftersom i princip kan två olika användare publicera ett inlägg samtidigt. Det är samma historia med kolumnen "text": två olika användare kan twittra med texten "Hej världen". Kolumnen "användarnamn" i denna tabell är en främmande nyckel för att indikera förhållandet mellan användaren och tweeten. Så eftersom alla möjliga alternativ inte passar oss är den bästa lösningen att lägga till en id -kolumn, som kommer att vara huvudnyckeln för denna tabell.

Tabell 6.tweets med id -kolumn

ID	Användarnamn	text	skapad vid
1	_DreamLead	Vad tycker du om #e -post #kampanjer #trafik i #USA? Är det en bra marknad nuförtiden? har du #databaser?	Tis, 12 feb 2013 08:43:09 +0000
2	GunnarSvalander	Bill Gates pratar databaser, gratis programvara på Reddit http://t.co/ShX4hZlA #billgates #databaser	Tis, 12 feb 2013 07:31:06 +0000
3	GEsoftware	RT @KirkDBorne: Läsningar i #databaser: utmärkt läslista, många kategorier: http://t.co/S6RBUNxq via @rxin Fascinerande.	Tis, 12 feb 2013 07:30:24 +0000
4	adrianburch	RT @tisakovich: @NimbusData på @Barclays Big Data -konferensen i San Francisco idag, pratar #virtualisering, #databaser och #flashminne.	Tis, 12 feb 2013 06:58:22 +0000
5	AndyRyder5	http://t.co/D3KOJIvF artikel om Madden 2013 som använder AI för att framkalla superskålen # databaser # bus311	Tis, 12 feb 2013 05:29:41 +0000
6	AndyRyder5	http://t.co/rBhBXjma en artikel om sekretessinställningar och facebook #databaser # bus311	Tis, 12 feb 2013 05:24:17 +0000
7	Brett_Englebert	# BUS311 University of Minnesota NCFPD skapar # databaser för att förhindra "matbedrägeri". http://t.co/0LsAbKqJ	Tis, 12 feb 2013 01:49:19 +0000
8	Brett_Englebert	# BUS311 -företag kan skydda sina # databaser för produktion, men hur är det med deras backupfiler? http://t.co/okJjV3Bm	Tis, 12 feb 2013 01:31:52 +0000
9	NimbusData	@NimbusData VD @tisakovich @BarclaysOnline Big Data -konferens i San Francisco idag, pratar #virtualisering, #databaser och #flashminne	Mån, 11 feb 2013 23:15:05 +0000
10	SSWUGorg	Glöm inte att registrera dig för vår GRATIS expo i fredags: #Databaser, #BI och #Sharepoint: Vad du behöver veta! http://t.co/Ijrqrz29	Mån, 11 feb 2013 22:15:37 +0000

Vi kan göra samma sak med följande tabell, sedan ingen befintlig kolumn kvalificerar sig som en primär nyckel. Kolumnerna "från_användare" och "till_användare" är främmande nycklar och anger sambandet mellan användarabonnemang.

Så, vid denna tidpunkt har vi redan gjort mycket. Vi blev av med dubblettinformation i kolumner och rader och valde lämpliga kolumner för våra tabeller som primära och främmande nycklar för att indikera beroenden mellan data. Denna process kallas normalisering och är utformad för att anpassa dina bord till relationsmodellen. Tack vare normaliseringen kan vi enklare implementera CRUD -operationer.

Nedan kan du se ett diagram över våra tabeller och förhållandena mellan dem:

Databashanteringssystem

Nu när vi har en relationsdatabas, hur kan vi implementera den? För att göra detta kan vi använda databashanteringssystem (DBMS). Det finns en hel rad liknande program, både betalda och gratis. De betalade inkluderar Oracle Database, IBM DB2 och Microsoft SQL Server. Gratis: MySQL, SQLite och PostgreSQL.

Oftast använder olika företag MySQL. Twitter i den meningen är inget undantag.

SQLite används oftare i utvecklingen av applikationer för iOS och Android, där olika typer av konfidentiell information lagras. Google Chrome -webbläsare använder SQLite för att lagra webbhistorik, cookies, bilder ...

PostgreSQL används mindre ofta. Det finns ett användbart PostGIS -tillägg för det, vilket gör detta DBMS bekvämt för lagring av geografisk platsdata. Till exempel använder OpenStreetMap -tjänsten PostgreSQL.

Structured Query Language (SQL)

När du väl har valt rätt DBMS för dig och installerat det, skulle nästa steg vara att skapa tabeller och hantera data. För detta kan vi använda ett speciellt SQL -språk.

Skapande av utvecklingsdatabasen:

SKAPA DATABASE -utveckling;

Skapa tabellen Användare:

SKAPA TABELL -användare (fullnamn VARCHAR (100), användarnamn VARCHAR (100));

När vi skapar fält måste vi ange typen av lagrad information och dess storlek. Kolumnerna "fullnamn" och "användarnamn" kommer att vara av typen VARCHAR, som används för att lagra teckensträngar. Storleken är 100 tecken. Du hittar en lista över alla typer.

Lägga till en post:

INSERT INTO users (full_name, username) VALUES ("Boris Hadjur", "_DreamLead");

Hämtar alla poster för användare _DreamLead:

Registrera uppdatering:

Ta bort inlägg:

SQL liknar mycket mänskligt språk (engelska). Varje SQL DBMS har ett antal egna särdrag och skillnader, men i allmänhet liknar alla SQL -varianter varandra.

Resultat

I den här lektionen analyserade vi processen för att skapa en relationsdatabas, tog en dataset och distribuerade den över tabeller, enligt relationsmodellen. Vi sprang också snabbt igenom det befintliga DBMS- och SQL -språket.

Relationsdatabas - grundläggande begrepp

Ofta, när man talar om en databas, menar de bara någon form av automatiserat datalager. Denna uppfattning är inte helt korrekt. Varför detta är så kommer att visas nedan.

I ordets snäva bemärkelse är en databas en viss uppsättning data som är nödvändiga för arbete (faktiska data). Men data är en abstraktion; ingen har någonsin sett "bara data"; de uppstår inte och existerar inte av sig själva. Data återspeglar 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 besvara 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 den verkliga världens objekt, information om vilken 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 funktion i ett visst objekt är attributets värde. 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 reflekteras 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 order 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 av 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" ingå 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 betyder 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 produceras 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.

Således, i ordets vida bemärkelse, är en databas en uppsättning beskrivningar av objekt i den verkliga världen och kopplingarna mellan dem, 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 enheter, attribut och relationer mappas till datastrukturer. Detta bestäms av datamodellen.

Traditionellt klassificeras alla DBMS enligt datamodellen som ligger till grund för dem. Det är vanligt att skilja hierarkiska, nätverks- och relationsdatamodeller. Ibland läggs en datamodell baserad på inverterade listor till dem. Följaktligen talar man om hierarkiska, nätverks-, relationella DBMS eller DBMS baserat på inverterade listor.

När det gäller prevalens och popularitet är relationsdatabaser inte konkurrenterna idag. De har blivit en de facto industriell standard, och därför måste en inhemsk användare möta i sin praxis just med ett relationellt DBMS. Låt oss ta en snabb titt på relationsdatamodellen utan att gå in på detaljerna.

Den utvecklades av Codd 1969-70 på grundval av den matematiska relationsteorin och är baserad på ett system av begrepp, av vilka de viktigaste är tabell, relation, rad, kolumn, primär nyckel, 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 i databasen reduceras till manipuleringstabeller. Tabellen består av rader och kolumner och har ett namn som är unikt i databasen. Tabellen återspeglar typen av objekt i den verkliga världen (enhet), och var och en av dess rader är ett specifikt objekt. Exempelvis innehåller tabellen Del information om alla delar som lagras 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 visst attribut för ett objekt. Till exempel är materialkolumnen en uppsättning värden "Stål", "Tenn", "Zink", "Nickel" och så vidare. Kolumnen Antal innehåller icke-negativa heltal. Värdena i kolumnen Vikt är reella tal lika med vikten av delen i kilogram.

Dessa värden dyker inte upp ur 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. Därför är det i materialkolumnen 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 högst upp i tabellen ( Ris. 1). Det måste vara unikt i tabellen, men olika tabeller kan ha kolumner med samma namn. Varje tabell måste ha minst en kolumn; kolumnerna är ordnade i tabellen enligt deras namnordning när den skapades. Till skillnad från kolumner har rader inte namn; deras ordning i tabellen är inte definierad, och antalet är inte logiskt begränsat.

Figur 1. Grundläggande begrepp i 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 deltabellen är kolumnen artikelnummer den primära nyckeln. I vårt exempel har varje del på lagret ett enda nummer, genom vilket den nödvändiga informationen extraheras från tabellen Part. Därför är den här nyckeln i denna tabell kolumnen Artikelnummer. Värdena i den här kolumnen kan inte dupliceras - tabellen Part bör inte innehålla rader som har samma värde i kolumnen Artikelnummer. Om en tabell uppfyller detta krav kallas det en relation.

Tabellernas relation är en väsentlig del av relationsdatamodellen. Det stöds av utländska nycklar. Tänk på ett exempel där databasen lagrar information om vanliga anställda (tabellen anställda) och chefer (chefstabellen) i någon organisation ( Ris. 2). Huvudnyckeln i övervakningstabellen är kolumnen nummer (till exempel personalnummer). Kolumnen Efternamn kan inte fungera som en primär nyckel, eftersom två chefer med samma efternamn kan arbeta i samma organisation. Varje anställd är underordnad en enda chef, vilket bör återspeglas i databasen. Medarbetartabellen innehåller kolumnen Manager Number och värdena i denna kolumn väljs från kolumnen Number i Manager -tabellen (se Ris. 2). Kolumnen Handledarnummer är en främmande nyckel i tabellen Anställda.

Figur 2. Förhållande 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 kallas vanligtvis metadata. Metadata presenteras också i tabellform och lagras i en dataordlista.

Förutom tabeller kan databasen lagra andra objekt som skärmar, rapporter, vyer och till och med program som fungerar med databasen.

Det räcker inte för användarna av informationssystemet att databasen helt enkelt å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 uppgifterna är korrekta och ömsesidiga konsekventa, åläggs vissa begränsningar för databasen, 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, till exempel referensintegritet. Dess väsen 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 Sek.Databaserver .

SQL -språk

I sig är data i datorform inte av intresse för användaren om det inte finns några sätt att komma åt dem. Datatillgång 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 åtkomst till en databas är associerat med skapandet av teorin om relationsdatabaser. SQL har sitt ursprung 1970 som en del av System / R -forskningsprojektet vid IBM: s Santa Teresa -lab. SQL är nu standarden för gränssnitt med. Dess popularitet är så stor att utvecklare av icke-relationellt 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 som beskrivs i Sek.Databaserver , 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. Inte program skrivs på den, utan frågor till databasen. Därför är SQL ett deklarativt språk. Det betyder att det kan användas för att formulera vad som behöver erhållas, men det 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 operatörer som if-then-else, for, while, etc.

Vi kommer inte att gå in på detaljer om språkets syntax. Låt oss bara beröra det 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, en efter en, separerade med semikolon. Tabell 1 nedan listar de viktigaste operatörerna som ingår i ANSI / ISO SQL -standarden.

Tabell 1. Grundläggande operatörer för SQL -språket.

SQL -frågor använder namn som unikt identifierar databasobjekt. I synnerhet är detta namnet på tabellen (detalj), namnet på kolumnen (namn), liksom namnen på andra objekt i databasen som tillhör ytterligare typer (till exempel namnen på procedurer och regler) , som kommer att diskuteras i Sek.Databaserver ... Förutom enkla namn används också komplexa namn - till exempel definierar det kvalificerade kolumnnamnet kolumnens namn och namnet på tabellen som den tillhör (Part.Weight). För enkelhetens skull, i exemplen, kommer namnen 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 - teckensträngar med fast längd, heltal och reella tal, och ytterligare datatyper - strängar med 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ämma antalet delar i lager för alla typer av delar" implementeras enligt följande:

VÄLJ Namn, Antal

FRÅN Del;

Resultatet av frågan blir en tabell med två kolumner - Namn och Mängd, som är hämtade från den ursprungliga Deltabellen. I grund och botten tillåter denna fråga dig att få en vertikal projicering av det ursprungliga bordet (mer strikt, en vertikal delmängd av uppsättningen tabellrader). Från alla rader i Part -tabellen bildas rader som innehåller värden från två kolumner - Namn och Antal.

Frågan "vilka delar av stål finns i lager?", Formulerad i SQL, ser ut så här:

FRÅN Del

VAR Material = "Stål";

Resultatet av denna fråga blir också en tabell som endast innehåller de raderna i källtabellen som har värdet "Stål" i kolumnen Material. Med den här frågan kan du få en horisontell projektion av Part -tabellen (en asterisk i en SELECT -sats betyder att du väljer alla kolumner från tabellen).

Begäran "att bestämma namn och mängd delar på lagret, som är tillverkade av plast och väger mindre än fem kilo" kommer att skrivas enligt följande:

VÄLJ Namn, Antal

FRÅN Del

VAR Material = "Plast"

OCH Vikt< 5;

Frågeresultatet är en tabell med två kolumner - Namn, Kvantitet, som innehåller namn och antal delar av plast som väger mindre än 5 kg. Faktum är att urvalsoperationen är att först bilda ett horisontellt projektion (hitta alla rader i delbordet, för vilket 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 hämtade 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 Antal, Material

FRÅN Del

WHERE Number = "T145-A8";

Om det inte finns några index för den här tabellen, för att kunna utföra denna fråga, måste DBMS visa hela tabelldetaljen, radvis välja rader från den och kontrollera urvalsvillkoret för var och en av dem. För stora bord kommer en sådan fråga att ta mycket lång tid.

Om indexet tidigare skapades i kolumnen Table Number Part, reduceras söktiden i tabellen till ett minimum. Indexet innehåller värden från kolumnen Tal och en länk till raden med detta värde i tabellen Del. När en fråga utförs hittar DBMS först värdet "T145-A8" i indexet (och gör det snabbt, eftersom indexet är ordnat och dess rader är små), och sedan, genom referens i indexet, kommer det att bestäm den fysiska platsen för den önskade raden.

Indexet skapas med SQL CREATE INDEX -satsen. I det här exemplet, operatören

SKAPA UNIK INDEX Delindex

PÅ del (nummer);

skapar ett index som heter Part Index i kolumnen Part Table Number.

För en användare av ett DBMS är det inte individuella SQL -satser som är av intresse, utan en viss sekvens av dem, bildade som en enda helhet och vettig ur hans synvinkel. Varje sådan sekvens av SQL -satser implementerar en specifik åtgärd på databasen. Det utförs i flera steg, var och en av dem utför vissa operationer på databastabellerna. Så i banksystemet utförs överföring av ett visst belopp från ett korttidskonto till ett långsiktigt konto i flera operationer. Bland dem-uttag av ett belopp från ett kortfristigt konto, kreditering till ett långsiktigt konto.

Om ett fel uppstår 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.

Transaktionsbehandling är beroende av loggen, som används för att rulla tillbaka transaktioner och återställa databasens tillstånd. Mer information om transaktioner kommer att diskuteras i Sek.Transaktionshantering .

För att avsluta vår diskussion om SQL, låt oss än en gång betona att det är ett frågespråk. Det är omöjligt att skriva något komplext applikationsprogram på det som fungerar med en databas. För detta ändamål använder moderna DBMS fjärde generationens språk (Forth Generation Language - 4GL), som har både de grundläggande funktionerna i tredje generationens procedurspråk (3GL), såsom C, Pascal, Ada och möjligheten att bädda in SQL -satser i programtexten, liksom användargränssnittskontroller (menyer, formulär, användarinmatning, etc.). Idag är 4GL en av de facto -standarderna för utvecklingsverktyg för databasapplikationer.

En datamodell är en samling av datastrukturer och operationer för deras behandling. Med hjälp av datamodellen kan du visualisera objekts struktur och relationerna mellan dem. Datamodellernas terminologi kännetecknas av begreppen "dataelement" och "bindande regler". En datapost beskriver alla datauppsättningar, och bindningsreglerna bestämmer algoritmerna för förhållandet mellan dataobjekt. Hittills har många olika datamodeller utvecklats, men i praktiken används tre huvudsakliga. Tilldela hierarkiska, nätverks- och relationsdatamodeller. Följaktligen talar de om hierarkiska, nätverks- och relationella DBMS.

О Hierarkisk datamodell. Hierarkiskt organiserade data är mycket vanliga i vardagen. Exempelvis är strukturen för en lärosäte en hierarkisk struktur på flera nivåer. En hierarkisk (trädliknande) databas består av en ordnad uppsättning element. I denna modell ger de ursprungliga elementen upphov till andra element, och dessa element ger i sin tur upphov till nästa element. Varje barn har bara en förälder.

Organisationsscheman, materiallistor, innehållsförteckning i böcker, projektplaner och många andra datasamlingar kan presenteras på ett hierarkiskt sätt. Integriteten i länkarna mellan förfäder och ättlingar bibehålls automatiskt. Grundregel: ingen ättling kan existera utan sin förälder.

Den största nackdelen med denna modell är behovet av att använda den hierarki som lades till grund för databasen under designen. Behovet av konstant datarekonstruktion (och ofta omöjligheten av denna omorganisation) ledde till skapandet av en mer allmän modell - nätverk.

О Nätverksdatamodell. Det nätverksansatta sättet att organisera data är en förlängning av det hierarkiska tillvägagångssättet. Denna modell skiljer sig från den hierakiska genom att varje genererat element kan ha mer än ett överordnat element. ■

Eftersom nätverksdatabasen direkt kan representera alla typer av relationer som är inneboende i data från motsvarande organisation kan dessa data navigeras, utforskas och frågas på alla möjliga sätt, det vill säga att nätverksmodellen inte är ansluten med bara en hierarki. För att skapa en fråga till en nätverksdatabas är det dock nödvändigt att fördjupa sig i dess struktur (för att ha ett diagram över denna databas till hands) och att utveckla en mekanism för att navigera i databasen, vilket är en betydande nackdel med detta databasmodell.

Om relationsdatamodellen. Grundtanken bakom en relationsdatamodell är att representera valfri datamängd som en tvådimensionell tabell. I sitt enklaste fall beskriver en relationsmodell en enda tvådimensionell tabell, men oftast beskriver denna modell strukturen och relationerna mellan flera olika tabeller.

Relationsdatamodell

Så, syftet med informationssystemet är att bearbeta data handla om objekt den verkliga världen, med hänsyn tagen anslutningar mellan föremål. I DB -teorin kallas data ofta attribut och objekt - enheter. Objekt, attribut och anslutning är grundläggande begrepp för I.S.

Ett objekt(eller enhet) är något som finns och märkbar, det vill säga ett objekt kan kallas det "något" för vilket det finns ett namn och ett sätt att skilja ett liknande objekt från ett annat. Till exempel är varje skola ett objekt. Objekt är också en person, en klass på en skola, ett företag, en legering, en kemisk förening etc. Objekt kan inte bara vara materiella objekt, utan också mer abstrakta begrepp som speglar den verkliga världen. Till exempel evenemang, regioner, konstverk; böcker (inte som tryckta produkter, utan som verk), teaterföreställningar, filmer; rättsliga normer, filosofiska teorier etc.

Attribut(eller given)- detta är en indikator som kännetecknar ett visst objekt och tar ett visst numeriskt, textmässigt eller annat värde för en specifik förekomst av objektet. Informationssystemet fungerar med uppsättningar objekt utformade i förhållande till ett visst ämnesområde, med hjälp av specifika attributvärden(data) för vissa objekt. Låt oss till exempel ta klasser i en skola som en samling objekt. Antalet elever i en klass är givet, vilket tar ett numeriskt värde (en klass har 28, en annan har 32). Klassens namn är en given som har en textmässig betydelse (den ena har 10A, den andra har 9B, etc.).

Utvecklingen av relationsdatabaser började i slutet av 1960 -talet, när de första artiklarna dök upp och diskuterar; möjligheten att använda i utformningen av databaser de vanliga och naturliga sätten att presentera data - de så kallade tabelldatalogiska modellerna.

Grundaren av teorin om relationsdatabaser anses vara en anställd vid IBM -företaget Dr. E. Codd, som publicerade artikeln 6 (juni 1970 artikeln En relationsmodell för data för stora delade databanker(Relationsdatamodell för stora kollektiva databanker). Denna artikel var den första som använde termen "relationsdatamodell." Teorin om relationsdatabaser, utvecklad på 70 -talet i USA av Dr. E. Codd, har en kraftfull matematisk grund som beskriver reglerna för att effektivt organisera data. Den teoretiska grund som utvecklats av E. Codd blev grunden för utvecklingen av teorin om databasdesign.

E. Codd, som är matematiker av utbildning, föreslog att man använder apparat för uppsättningsteori (förening, korsning, skillnad, kartesisk produkt) för databehandling. Han bevisade att varje uppsättning data kan representeras i form av tvådimensionella tabeller av ett speciellt slag, kända i matematik som "relationer".

Relationellt en sådan databas övervägs, där all data presenteras för användaren i form av rektangulära tabeller med datavärden, och alla operationer i databasen reduceras till manipuleringstabeller.

Bordet består av kolumner (fält) och rader (poster); har ett unikt namn i databasen. tabell speglar Objekttyp den riktiga världen (väsen), och var och en av henne string är ett specifikt objekt. Varje kolumn i en tabell är en samling värden för ett specifikt attribut för ett objekt. Värdena väljs från uppsättningen av alla möjliga värden för objektattributet, som kallas domän.

I sin mest allmänna form definieras en domän genom att specificera någon grundläggande datatyp, som elementen i domänen tillhör, och ett godtyckligt logiskt uttryck som tillämpas på dataelementen. Om resultatet vid en utvärdering av ett logiskt tillstånd för ett dataobjekt är "sant" tillhör domänen. I det enklaste fallet definieras en domän som en giltig uppsättning värden av samma typ. Till exempel utgör uppsättningen av födelsedatum för alla anställda "Födelsedatum", och namnen på alla anställda utgör "Anställdas namndomän". Födelsedatumets domän har en datatyp för att lagra information om tidpunkter och medarbetarnamnens domän måste vara en teckendatatyp.

Om två värden kommer från samma domän kan du jämföra de två värdena. Om två värden till exempel är från födelsedatumets domän kan du jämföra dem för att avgöra vilken anställd som är äldre. Om värdena tas från olika domäner är deras jämförelse inte tillåten, eftersom det med all sannolikhet inte är meningsfullt. Till exempel kommer inget definitivt ut av att jämföra namn och födelsedatum för en anställd.

Varje kolumn (fält) har ett namn, som vanligtvis skrivs högst upp i tabellen. När du utformar tabeller inom ett specifikt DBMS är det möjligt att välja för varje fält dess sorts, det vill säga definiera en uppsättning regler för att visa den, samt definiera de operationer som kan utföras på data som lagras i detta fält. Uppsättningarna av typer kan skilja sig åt för olika DBMS.

Fältnamnet måste vara unikt i tabellen, men olika tabeller kan ha fält med samma namn. Varje tabell måste ha minst ett fält. fälten är ordnade i tabellen i enlighet med deras namnordning när den skapades. Till skillnad från fält har strängar inte namn; deras ordning i tabellen är inte definierad, och antalet är inte logiskt begränsat.

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 primärnyckel... Ett artificiellt fält introduceras ofta för att nummerera posterna i tabellen. Ett sådant fält kan till exempel vara dess ordinal, vilket kan säkerställa det unika med varje post i tabellen. Nyckeln måste ha följande egenskaper.

Unikhet. När som helst har inga två olika typer av relationen samma värde för kombinationen av attributen som ingår i nyckeln. Det vill säga att det inte kan finnas två rader i tabellen som har samma identifikationsnummer eller passnummer.

Minimalitet. Inget av attributen som ingår i nyckeln kan uteslutas från nyckeln utan att kränka det unika. Det betyder att det inte är nödvändigt att skapa en nyckel som innehåller både passnummer och identifikationsnummer. Det är tillräckligt att använda något av dessa attribut för att identifiera tuppeln unikt. Du bör inte heller inkludera ett icke-unikt attribut i nyckeln, det vill säga det är förbjudet att använda en kombination av ett identifieringsnummer och en anställds namn som nyckel. Genom att utesluta medarbetarnamnet från nyckeln kan du fortfarande identifiera varje rad unikt.

Varje relation har minst en möjlig nyckel, eftersom helheten av alla dess attribut uppfyller det unika villkoret - detta följer av själva definitionen av relationen.

En av de möjliga knapparna väljs slumpmässigt in som huvudnyckel. De återstående möjliga nycklarna, om sådana finns, tas som alternativa nycklar. Till exempel, om du väljer ett identifikationsnummer som huvudnyckel, kommer passnumret att vara en alternativ nyckel.

Tabellernas relation är en väsentlig del av relationsdatamodellen. Hon får stöd utländska nycklar.

När man beskriver en relationsdatabasmodell används ofta olika termer för samma koncept, beroende på beskrivningsnivån (teori eller praktik) och systemet (Access, SQL Server, dBase). Tabell 2.3 sammanfattar de använda termerna.

Tabell 2.3. Databasterminologi

Databassteori ____________ Relationsdatabaser _________ SQL Server __________

Relationstabell

Tuple Record Row

Attributfält _______________ Kolumn

Relationsdatabaser

Relationsdatabasär en uppsättning relationer som innehåller all information som måste lagras i databasen. Det vill säga, databasen representerar den uppsättning tabeller som krävs för att lagra all data. Relationella databastabeller är logiskt relaterade till varandra. Designkrav för en relationsdatabas kan sammanfattas i några regler.

О Varje tabell har ett unikt namn i databasen och består av rader av samma typ.

О Varje tabell består av ett fast antal kolumner och värden. Mer än ett värde kan inte lagras i en kolumn i en rad. Om det till exempel finns en tabell med information om författaren, publiceringsdatum, upplagan etc., kan kolumnen med författarens namn inte innehålla mer än ett efternamn. Om boken är skriven av två eller flera författare måste du använda ytterligare tabeller.

О Det kommer aldrig att finnas två rader i tabellen som duplicerar varandra. Rader måste skilja sig åt med minst ett värde för att unikt kunna identifiera vilken rad som helst i tabellen.

О Varje kolumn tilldelas ett namn som är unikt i tabellen; en specifik datatyp ställs in för det så att homogena värden (datum, efternamn, telefonnummer, summor etc.) placeras i denna kolumn.

О Databasens fullständiga informationsinnehåll representeras i form av tydliga värden för själva datan, och denna metod för presentation är den enda. Till exempel är förhållandet mellan tabeller baserat på data som lagras i motsvarande kolumner, och inte på grundval av några pekare som artificiellt definierar relationer.

О När du behandlar data kan du fritt hänvisa till vilken rad eller kolumn som helst i tabellen. De värden som lagras i tabellen föreskriver inga begränsningar för den ordning i vilken informationen nås. Kolumnbeskrivning,

RELATIONELL DATABAS OCH DESS FUNKTIONER. TYPER AV RELATIONER MELLAN RELATIONELLA TABELLER

Relationsdatabas är en samling sammankopplade tabeller, som var och en innehåller information om objekt av en viss typ. En tabellrad innehåller data om ett objekt (till exempel en produkt, en kund) och tabellkolumnerna beskriver olika egenskaper hos 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 attributen för ett objekt. 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är nyckel - 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 en sammansatt nyckel. Nyckeln måste vara unik och identifiera posten på ett unikt sätt. Nyckelvärdet kan användas för att hitta en enda post. Nycklar används också för att organisera information i databasen.

Relationella databastabeller måste uppfylla kraven för normalisering av förhållanden. Normalisering av relationer är en formell apparat för begränsningar av 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, studentstudentnummer, födelsedatum, specialblandning, fakultetsnamn. En sådan organisation av informationslagring kommer att ha ett antal nackdelar:

dubbel information (namnet på specialiteten och fakulteten upprepas för varje student), därför kommer databasvolymen att öka;
proceduren för att uppdatera information i tabellen är svår på grund av behovet av att redigera varje tabellposter.

Tabellnormalisering är avsedd att åtgärda dessa brister. Det finns tre normala former av relation.

Första normala formen. 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 från studenttabellen för att få information med elevens namn, bör fältet Fullständigt namn delas in i efternamn, namn, patronymiska delar.

Andra normala formen... En relationstabell anges i den andra normala formen om den uppfyller kraven i den första normala formen 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 det funktionella beroendet av fälten. Fältens funktionella beroende är ett beroende, när i informationsobjektet endast ett värde av det beskrivande attributet motsvarar ett visst värde för nyckelattributet.

Tredje normalform. En tabell är i tredje normalform om den uppfyller kraven för den andra normala formen, inget av dess icke-nyckelfält är funktionellt beroende av något annat icke-nyckelfält. Till exempel i elevtabellen (antal grupper, fullständigt namn, antal betygsböcker, födelsedatum, Starosta) har tre fält - Antal betygsböcker, antal grupper, Starosta ett transitivt förhållande. Gruppnumret beror på betygsboknumret och chefen beror på gruppnumret. För att eliminera det transitiva beroendet är det nödvändigt att överföra en del av fälten i studenttabellen till en annan tabell, Grupp. Tabellerna har följande form: Student (gruppnummer, fullständigt namn, betygsboknummer, födelsedatum), grupp (gruppnummer, chef).

Följande operationer är möjliga på relationella tabeller:

Sammankoppling av tabeller med samma struktur. Resultatet är en vanlig tabell: först den första, sedan den andra (sammanfogning).
Korsning av tabeller med samma struktur. Resultat - de poster är markerade som finns i båda tabellerna.
Subtrahering av tabeller med samma struktur. Resultat - de poster som väljs ut som inte finns i det subtraherade.
Prov (horisontell delmängd). Resultat - poster väljs 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 Posterna i den resulterande tabellen 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 databasens storlek. Förhållandet mellan varje tabellpar tillhandahålls om de har samma kolumner.

Det finns följande typer av 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 förhållanden antar att ett attribut i den första tabellen motsvarar flera attribut i den andra tabellen, och vice versa.

Vad betyder relationell. Grundläggande begrepp för ett algoritmiskt språk

Steg 1. Förbered data

Steg 2. Bli av med dubbletter av kolumner

Steg 3. Ta bort repetitioner från strängar

Steg 4. Slå samman tabeller baserade på nycklar

Databashanteringssystem

Structured Query Language (SQL)

Resultat

Populära artiklar

Senaste artiklarna

Avsnitt

Sidor

Särskilda projekt

Kontakter