Relationell algebra, operationer av relationalgebra. Operationer på data i nätverksdatabasmodellen
Den största skillnaden mellan dessa modellerär det i nätverksmodell en post kan vara medlem i mer än en grupprelation. Enligt denna modell namnges varje grupprelation och man skiljer på dess typ och dess instans. Typen av en grupprelation ges av dess namn och definierar egenskaper som är gemensamma för alla instanser av denna typ. En instans av en grupprelation representeras av en ägarpost och en uppsättning (eventuellt tom) av underordnade poster. Den har följande begränsning: spela in instans kan inte vara medlem i två instanser av grupprelationer av samma typ (dvs. en anställd från exemplet i paragraf ..1 kan till exempel inte arbeta på två avdelningar).
- träd (a) och (b) som visas i fig. 4.2 ersätts av en enda nätverksstruktur där den ANSTÄLLDAs inträde ingår i två grupprelationer;
- för att visa M:N-typen matas posten EMPLOYEE_CONTRACT in, som inte har några fält och endast tjänar till att länka CONTRACT- och EMPLOYEE-posterna (se fig. 4.3). Observera att denna post också kan lagras användbar information, till exempel, dela denna anställd i den totala ersättningen enligt detta avtal.
Ris. 4.3.
Varje instans av en grupprelation kännetecknas av följande egenskaper:
Sätt att beställa underordnade poster:
- slumpmässig,
- kronologisk /kö/,
- omvänd kronologisk /stack/,
- blandad.
Om en post förklaras vara underordnad i mer än en grupprelation, kan var och en av dem tilldelas sin egen ordningsmetod.
Inklusionsläge för delinspelning:
- automatiskt - det är omöjligt att lägga in en post i databasen utan att den omedelbart tilldelas en viss ägare;
- manual - låter dig lagra en underordnad post i databasen och inte omedelbart inkludera den i en instans av en grupprelation. Denna operation initieras senare av användaren.
Undantagsläge.
Det är vanligt att särskilja tre klasser av medlemskap i underordnade poster i grupprelationer:
- Fast. En underordnad post är strikt kopplad till ägarposten och kan endast exkluderas från gruppförhållandet genom att radera den. När en ägarpost raderas raderas även alla underordnade poster automatiskt. I exemplet ovan innebär fast medlemskap en grupprelation "SLUTAR" mellan posterna "CONTRACT" och "CUSTOMER" eftersom kontraktet inte kan existera utan kunden.
- Obligatorisk. Det är tillåtet att byta en underordnad post till en annan ägare, men det är omöjligt att den existerar utan en ägare. För att radera en ägarpost får den inte ha några underordnade poster med obligatoriskt medlemskap. Posterna "EMPLOYEE" och "DEPARTMENT" är relaterade till detta förhållande. Om en avdelning avvecklas måste alla dess anställda antingen flyttas över till andra avdelningar eller sägas upp.
- Frivillig. Du kan utesluta en post från en grupprelation, men behålla den i databasen utan att koppla den till en annan ägare. När en ägarpost raderas, sparas dess underordnade poster - valfria medlemmar i databasen och deltar inte längre i en grupprelation av denna typ. Ett exempel på en sådan grupprelation är "PERFORMER" mellan "PERSONAL" och "CONTRACT", eftersom det kan finnas anställda i organisationen vars verksamhet inte är relaterade till fullgörandet av några avtalsenliga skyldigheter gentemot kunder.
Operationer på data i nätverksdatabasmodellen
| Lägg till | - gör en inmatning i databasen och, beroende på inkluderingsläget, antingen inkludera den i en grupprelation, där den deklareras som en underordnad, eller inte inkludera den i någon grupprelation. |
| Inkludera i grupprelation | - associera en befintlig underordnad post med en ägarpost. |
| Växla | - koppla en befintlig underordnad post till en annan ägarpost i samma koncernförhållande. |
| Uppdatera | - ändra värdet på elementen i den tidigare hämtade posten. |
| Extrahera | - extrahera poster sekventiellt efter nyckelvärde, samt använda grupprelationer - från ägaren kan du gå till medlemsposter och från den underordnade posten till ägaren av uppsättningen. |
| Radera | - ta bort posten från databasen. Om denna post är ägaren till grupprelationen, tolkas medlemsklassen för de underordnade posterna. Nödvändiga medlemmar måste tidigare exkluderas från grupprelationen, fasta medlemmar raderas tillsammans med ägaren, valfria kommer att finnas kvar i databasen. |
| Uteslut från gruppförhållande | - bryta sambandet mellan ägarrekordet och medlemsrekordet. |
Integritetsbegränsningar
Som i hierarkisk modell endast upprätthållande av referensintegritet säkerställs (ägaren av relationen är medlem av relationen).
Fördelar och nackdelar med tidiga DBMS
Fördelar med tidiga DBMS:
- avancerade sätt att hantera data i externt minne på en låg nivå;
- förmågan att bygga manuellt effektivt tillämpade system;
- möjligheten att spara minne genom att separera delobjekt (i nätverkssystem)
Nackdelar med tidiga DBMS:
- komplexiteten i användningen;
- höga krav på kunskap om den fysiska organisationen av databasen;
- de tillämpade systemens beroende av databasens fysiska organisation;
- överbelasta logiken i tillämpade system med detaljerna för att organisera åtkomst till databasen.
Både hierarkiska och nätverksdatamodell kräver närvaro av högt kvalificerade programmerare. Och även i sådana fall är implementeringen av användarförfrågningar ofta försenad långsiktigt.
Objektorienterad DBMS
Uppkomsten av objektorienterad DBMS orsakades av behoven hos programmerare i OO-språk, som behövde medel för att lagra objekt som inte passade in random access minne dator. Viktigt var också uppgiften att spara objektens tillstånd mellan upprepade lanseringar av applikationsprogrammet. Därför är de flesta OODBMS ett bibliotek vars datahanteringsprocedurer ingår i applikationsprogrammet. Exempel på implementering av OODBMS som dedikerad server databaser är extremt sällsynta.
Det bör omedelbart noteras att den allmänt accepterade definitionen av " objektorienterad datamodell" existerar inte. Nu kan vi bara prata om ett visst "objekt" förhållningssätt till den logiska representationen av data och om olika objektorienterade sätt att implementera den.
Vi vet att varje datamodell måste inkludera tre aspekter: strukturell, holistisk och manipulativ. Låt oss se hur de implementeras baserat på objektorienterade programmeringsparadigm.
Strukturera
Strukturera objektmodell beskrivs med hjälp av tre nyckelbegrepp:
| inkapsling | - varje objekt har något internt tillstånd (lagrar en post med data inuti), såväl som en uppsättning metoder - procedurer med vilka (och endast på detta sätt) du kan komma åt data som bestämmer objektets interna tillstånd, eller ändra dem. Således kan objekt betraktas som oberoende enheter, separerade från den yttre världen; |
| arv | - innebär möjligheten att skapa nya objektklasser från objektklasser som ärver strukturen och metoderna från sina förfäder, och lägga till dem funktioner som återspeglar deras egen individualitet. Arv kan vara enkelt (en förfader) eller flera (flera förfäder); |
| polymorfism | - olika objekt kan reagera olika på samma externa händelser beroende på hur deras metoder implementeras. |
Dataintegritet
För att upprätthålla integriteten föreslår den objektorienterade metoden att du använder följande verktyg:
- automatiskt underhåll av arvsrelationer, förmågan att förklara vissa datafält och objektmetoder som "dolda", inte synliga för andra objekt; sådana fält och metoder används endast av metoder för själva objektet skapande av integritetskontrollprocedurer inom objektet
Verktyg för datamanipulation
Tyvärr saknar objektorienterad programmering vanliga datamanipuleringsverktyg som relationalgebra eller relationskalkyl. Arbetet med data utförs med ett av de objektorienterade programmeringsspråken generell mening, vanligtvis SmallTalk, C++ eller Java.
Låt oss nu sammanfatta några
Objektorienterade databaser, till skillnad från relationsdatabaser, lagrar inte poster, utan objekt. OO-metoden ger ett bättre sätt att representera den verkliga världen än relationsmodell, en naturlig representation av data. I relationsmodellen tillhör alla relationer samma nivå, vilket är det som komplicerar omvandlingen av entitetsrelationsmodellens hierarkiska relationer till relationsmodellen. OO-modellen kan betraktas i lager, på olika abstraktionsnivåer. Det är möjligt att definiera nya datatyper och operationer med dem.
Samtidigt har o.o. Modellen har också en rad nackdelar.:
- det finns inga kraftfulla icke-procedurella verktyg för att extrahera objekt från databasen. Alla frågor måste skrivas på procedurspråk, problemet med deras optimering ligger hos programmeraren;
- istället för rent deklarativt Integritetsbegränsningar(som en uttrycklig deklaration om primär och främmande nycklar relationstabeller med nyckelord PRIMÄRNYCKEL och REFERENSER) eller semi-deklarativa utlösare måste du skriva procedurkod för att säkerställa intern integritet.
Uppenbarligen är båda dessa brister förknippade med bristen på utvecklade verktyg för datamanipulation. Detta problem löses på två sätt - genom att utöka OO-språken i riktning mot datahantering (ODMG-standard), eller genom att lägga till objektegenskaper i relationell DBMS (SQL-3, samt den så kallade objektrelationella DBMS).
Relationell algebra är språket för operationer som utförs på relationer - tabellerna i en relationsdatabas. Relationella algebraoperationer låter dig skapa en annan relation baserad på en eller flera relationer utan att själva ändra de ursprungliga relationerna. Den resulterande andra relationen skrivs vanligtvis inte till databasen, utan existerar som ett resultat av exekvering av en SQL-fråga - en array, skapas av funktioner för att arbeta med databaser i programmeringsspråk. För varje operation av relationalgebra kommer dess implementering i form av frågor i SQL-språket att ges.
Tänk på hur relationalgebra fungerar. Så att du inte distraheras av innehållet i tabeller som inte finns i dina databaser, som "Produkter", "Drivers", "plommon", "päron", "te", "kaffe", Vladimirs, Sergeys, etc. vi kommer att utföra operationer på relationer (tabeller) med abstrakta data, såsom R1, R2 (namn på tabeller - relationer), etc. och A1, A2, A3 (namn på attribut - kolumner) och h15, w11, etc. (innehållet i register över databastabeller).
Prioriteter för att utföra relationella algebraoperationer (i fallande ordning på listobjekt och i ett objekt - operationer med samma prioritet):
- urval, projektion
- Kartesisk produkt, union, korsning, division
- fackförening, skillnad.
hämtningsoperation
Valoperationen arbetar på en enda relation och bestämmer den resulterande relationen R, som endast innehåller de tupler (eller rader eller poster), relationer som uppfyller det givna villkoret (predikat P ).
Sålunda är valoperationen en unär operation och skrivs enligt följande:
var P- predikat (logiskt tillstånd).
SQL-fråga
Låt oss nu se vad som händer som ett resultat av denna relationella algebraoperation och motsvarande SQL-fråga. Tabellen nedan visar en relation som denna operation fungerar på.
| R3 | |||
| A1 | A2 | A3 | A4 |
| 3 | hh | yl | Fröken |
| 4 | pp | a1 | sr |
| 1 | rr | yl | Fröken |
Vi tittar på kolumn A3 och finner att predikatet A3>"d0" är uppfyllt av posterna i den första och tredje raden av den ursprungliga relationen (eftersom numret på bokstaven y i alfabetet är större än numret på bokstaven d ). Som ett resultat får vi följande nya relation, där det finns två linjer:
| R | |||
| A1 | A2 | A3 | A4 |
| 3 | hh | yl | Fröken |
| 1 | rr | yl | Fröken |
Materialet hjälper dig att kombinera alla typer av logiska villkor för prover "Boolesk algebra (logikens algebra)" .
SQL-fråga
VÄLJ A1, A2, A3 från R1 UNION VÄLJ A1, A2, A3 från R2
Låt oss nu se vad som händer som ett resultat av att utföra denna relationella algebraoperation och motsvarande SQL-fråga. Nu ges två relationer, eftersom unionsoperationen är en binär operation:
| R1 | R2 | |||||
| A1 | A2 | A3 | A1 | A2 | A3 | |
| Z7 | aa | w11 | X8 | pp | k21 | |
| B7 | hh | h15 | Q2 | ee | h15 | |
| X8 | pp | w11 | X8 | pp | w11 | |
Vi kombinerar linjerna i den första och andra relationen och ser att den tredje linjen, som är den tredje i både den första och andra relationen, är identisk, så vi inkluderar den i den nya relationen bara en gång. Vi får följande relation:
| R | ||
| A1 | A2 | A3 |
| Z7 | aa | w11 |
| B7 | hh | h15 |
| X8 | pp | w11 |
| X8 | pp | k21 |
| Q2 | ee | h15 |
Följande är viktigt: unionsoperationen kan endast utföras när två relationer har samma antal och namn på attribut (kolumner), eller, formellt sett, är kompatibla i union.
Korsningsoperation
Resultatet av skärningspunkten mellan två uppsättningar (relationer) A och B () kommer att vara en sådan uppsättning (relation) C, som inkluderar de och endast de element som finns i både uppsättning A och uppsättning B. Operationen av skärningspunkten för relationalgebra är identisk med operationen.
SQL-fråga
VÄLJ A1, A2, A3 från R1 SKÄRSA VÄLJ A1, A2, A3 från R2
Vissa dialekter saknar SQL nyckelord KORSAS. Dess ersättning, till exempel i MySQL och andra, är INNER JOIN. Om hur det fungerar SQL-sats JOIN i allmänhet och dess varianter INNER JOIN, LEFT OUTER JOIN, HÖGER YTTRE JOIN och FULL YTTRE JOIN - i lektionen SQL JOIN - sammanfoga databastabeller .
MySQL-fråga
Låt oss nu se vad som händer som ett resultat av att utföra denna relationella algebraoperation och motsvarande SQL-fråga. Återigen ges två förhållanden R1 och R2:
| R1 | R2 | |||||
| A1 | A2 | A3 | A1 | A2 | A3 | |
| Z7 | aa | w11 | X8 | pp | k21 | |
| B7 | hh | h15 | Q2 | ee | h15 | |
| X8 | pp | w11 | X8 | pp | w11 | |
Vi tittar igenom alla poster i två avseenden, och finner att i både det första och andra avseendet finns det en rad - den som är den tredje i både det första och andra avseendet. Vi får en ny relation:
| R | ||
| A1 | A2 | A3 |
| X8 | pp | w11 |
Skillnadsoperation
Skillnaden mellan två relationer R1 och R2 () består av tupler (eller poster eller rader) som finns i relation R1 men som inte finns i relation R2. Relationer R1 och R2 måste vara kompatibla med kopplingar. Den relationella algebras skillnadsoperation är identisk med operationen.
SQL-fråga
VÄLJ A1, A2, A3 från R2 UTOM
VÄLJ A1, A2, A3 från R1
Låt oss fastställa vad som händer som ett resultat av att utföra denna relationella algebraoperation och motsvarande SQL-fråga. Återigen ges två förhållanden R1 och R2:
| R1 | R2 | |||||
| A1 | A2 | A3 | A1 | A2 | A3 | |
| Z7 | aa | w11 | X8 | pp | k21 | |
| B7 | hh | h15 | Q2 | ee | h15 | |
| X8 | pp | w11 | X8 | pp | w11 | |
Vi exkluderar raden från R2-relationen, som också är i relation till R2 - den tredje - och vi får en ny relation:
| R | ||
| A1 | A2 | A3 |
| X8 | pp | w11 |
| Q2 | ee | h15 |
Kartesisk produktdrift
Den kartesiska produktoperationen () definierar en ny relation R, som är resultatet av att sammanfoga varje tupel av relation R1 med varje tupel av relation R2.
SQL-fråga
VÄLJ * från R3, R4
Låt oss fastställa vad som händer som ett resultat av att utföra denna relationella algebraoperation och motsvarande SQL-fråga. Givet två förhållanden R3 och R4:
| R3 | R4 | |||||
| A1 | A2 | A3 | A4 | A5 | A6 | |
| 3 | hh | yl | Fröken | 3 | hh | |
| 4 | pp | a1 | sr | 4 | pp | |
| 1 | rr | yl | Fröken | |||
Den nya relationen måste innehålla alla attribut (kolumner) för de två relationerna. Först sammanfogas den första raden i R3 med var och en av de två raderna i R4, sedan den andra raden i R3, sedan den tredje. Resultatet ska bli 3 X 2 = 6 tuplar (rader). Vi får denna nya relation:
| R | |||||
| A1 | A2 | A3 | A4 | A5 | A6 |
| 3 | hh | yl | Fröken | 3 | hh |
| 3 | hh | yl | Fröken | 4 | pp |
| 4 | pp | a1 | sr | 3 | hh |
| 4 | pp | a1 | sr | 4 | pp |
| 1 | rr | yl | Fröken | 3 | hh |
| 1 | rr | yl | Fröken | 4 | pp |
Vanligtvis är databassystem utrustade med ett frågespråk som kan hjälpa sina användare att fråga instanser. Det finns två sådana typer - relationalgebra och relationskalkyl. Den första är procedur som tar relationsinstanser som input och utdata relationsexempel som output. Använder unär eller binär kalkyl för detta. Relationell algebra görs rekursivt och behandlas som relationer.
Kartesisk produkt (X)
Kombinerar information från två olika relationer till en.
Beteckningar - r Χ s,
där r och s är förhållanden och deras utdata kommer att definieras som
r Χ s = (qt | q ∈ r och t ∈ s).
Slutsats. Ställer in en relation som visar alla böcker och artiklar skrivna med en lärobok.
Byt namn på operation (ρ).
Relationen mellan relationalgebra är resultaten, men utan något namn. Genom att byta namn kan du ändra utdatavärdet, betecknat med en liten grekisk bokstav ρ .
Beteckning - ρ x(E),
där resultatet av uttrycket E lagras med namnet x.
Ytterligare operationer:
- ställ in korsningen;
- uppdrag;
- naturligt samband.
relationskalkyl
Det är ett icke-procedurmässigt frågespråk, det vill säga det talar om vad man ska göra, men förklarar inte hur man implementerar det. Relationskalkylen finns i två former:
- korrelationskalkyl för en tupel;
- filtrera variabelintervall.
Notation - T/State: Returnerar alla T-tupler som uppfyller ett villkor. Resultat. Returnerar tuplar med ett namn. TRC kan kvantifieras. Du kan använda existentiella (∃) och universella kvantifierare (∀). Slutsats. Ovanstående fråga ger samma resultat som den föregående.
Domänrelationskalkyl DRC
Filtervariabeln använder domänen för attributen istället för heltalsvärdena för tupeln (som görs i TRC som nämns ovan).
Notation - (a 1 , a 2 , a 3 , ..., a n | P (a 1 , a 2 , a 3 , ..., a n)),
där a1, a2 är attribut och P anger formler byggda med interna värden.
Slutsats. Ställer in artikeln, sidan och ämnet från TutorialsPoint-relationen, där ämnet är en databas.
Liksom TRC kan DRC också skrivas med existentiella och universella kvantifierare. DRC inkluderar även relationella algebraoperatorer. Styrkan i uttrycket för beräkning, kalkyl och korrelation av relationer mellan punkter är ekvivalent.
Variationer och scheman av relationskalkyl och algebra
ER-modellen, när den konceptualiseras i diagram, ger bra recension väsentliga relationer som är lättare att förstå. Schematiska representationer kan mappas till ett relationsschema, det vill säga de kan skapas tillsammans med varandra. Det är inte möjligt att importera alla ER-begränsningar till en relationsmodell, men en ungefärlig struktur kan genereras. Det finns flera processer och algoritmer tillgängliga för att konvertera diagram till detta system. Vissa av dem är automatiserade, medan andra skapas manuellt. ER-diagram består huvudsakligen av följande kriterier:
- entitet och dess attribut;
- en länk, som är en association mellan ovanstående värden.
Jämförelse av objekt och relationer sker på olika sätt och scheman. Till exempel är en entitet ett objekt i den verkliga världen med vissa attribut. Matchningsprocessen, algoritmen är som följer:
- skapa en tabell för varje objekt;
- attribut bör bli fält av tabeller med motsvarande datatyper;
- deklarera en primärnyckel.
En relation är en association mellan enheter. Sammanställningsprocessen är som följer:
- skapa en tabell för relationer;
- Lägg till primära nycklar alla deltagande enheter som tabellfält med sina respektive datatyper;
- om relationen har något attribut, ställ in varje attribut som ett tabellfält;
- gå med i den primära nyckeln som utgör alla de andra för de deltagande objekten;
- ange alla begränsningar för främmande nyckel.
Visningen av svaga uppsättningar och hierarkiska objekt sker enl visst system. Först och främst är det nödvändigt att förstå de väsentliga grunderna och betydelserna. En svag funktionsuppsättning är en som inte har någon primärnyckel kopplad till sig. Visningsprocessen är som följer:
- skapa en tabell för en svag uppsättning objekt;
- lägg till alla attribut till schemat som ett fält;
- ange primärnyckeln för identifiering;
- ställ in alla begränsningar för främmande nyckel.
Kartläggningen av hierarkiska objekt är baserad på en specialisering eller generalisering av språket för relationalgebra sker i form av sekventiella enheter. Algoritmen är följande:
- skapa tabeller för alla högre objekt på lägre nivå;
- lägg till primärnycklar;
- på en låg nivå, implementera alla andra attribut för objekt på lägre nivå;
- deklarera tabellens primärnycklar;
- ställ in begränsningar för främmande nyckel.
Befintliga alternativ för att beskriva, lagra, ändra information
SQL är ett programmeringsspråk för relationsdatabaser data. Den är utvecklad över algebra och korrelationskalkyl för tupler. SQL kommer som ett paket med alla större DBMS-distributioner. Innehåller både data och språk för att manipulera dem. Använder definitionsegenskaper SQL-data relationalgebra kan du designa och ändra schemat för databasen, medan egenskaperna för kontroll och justering, samt dataändringar, låter dig lagra och hämta informationen som är installerad i systemet. Använder följande uppsättning kommandon för att definiera struktur och system:
- skapar nya tabeller och vyer från DBMS.
- kastar kommandon.
- ändrar databasschemat.
- detta kommando lägger till ett attribut till ett objekt av typen sträng.
SQL är utrustad med ett Data Manipulation Language (DML). Den modifierar databasinstansen genom att infoga, uppdatera och ta bort information. DML ansvarar för att alla data ändras. SQL innehåller följande uppsättning kommandon i DML-sektionen:
- SELECT är en av grundläggande kommandon begäran. Det är analogt med projektionsoperationen för relationalgebra. Den väljer attribut baserat på villkoret som beskrivs i WHERE-satsen.
- FRÅN - Detta avsnitt tar ett namn som ett argument från vilket attributen ska väljas/projiceras. Om mer än ett namn anges, motsvarar denna artikel den kartesiska produkten.
- WHERE - Det här avsnittet definierar predikatet eller villkoren som måste uppfyllas för att kvalificera det projicerade attributet.
Det finns också kommandon:
- Föra in;
- ändrade värden;
- avlägsnande.
Skapa relations-algebrafrågor
När man konstruerar en sökning är uppgiften att hitta en struktur av operationer som leder till rätt utdata. De grundläggande operationerna för relationalgebra är enkla operationer med en eller två relationer som operander. Kombinerade sekvenseffekter avgör slutresultat. Eftersom systemet med relationalgebra i databaser är ganska enkelt kan många mellanliggande resultat erhållas innan de når den slutliga utdatan, de används också som operander som producerar ny mottagen data.
För de flesta operatörer spelar ordningen på frågorna och deras utförande ingen roll, vilket innebär att samma utdata kan uppnås genom att forma och kombinera mellanliggande data på olika sätt. I praktiken är databassökningar ganska lätta. Systemet för att utföra operationer och mellanresultat bestäms av frågeoptimeraren. När du formulerar frågor, krav måste du
välj först vilka relationer som behövs för att uppnå svaret, och specificera sedan operationer och mellanresultat. Strukturen för en relationalgebrafråga i en resultatdatabas kan representeras som ett diagram. Kravoptimerare försöker organisera utförande så effektivt som möjligt. I praktiken innebär det oftast att de försöker minimera mellanresultaten så snabbt som möjligt. Vanliga exempel på relationalgebra kommer att hjälpa till med detta.
Information om bilar av årsmodell 1996, där brister konstaterats vid besiktningen för 1999.
Först visas information om maskinerna för att förstå värdena för alla attribut i relationen. Information om inspektioner lagras i tabellen "Kontrollera" och om fel upptäcks registreras de i tabellen "Problem". Därför behövs dessa tre tabeller för att få den information som krävs.
Endast 1996 bilar är intressanta. Uppställningen bil representeras som ett värde ange attribut i maskininformationstabellraden. Det första mellanresultatet består av tuplar som representerar 1996 års varianter.
Det behövs alltså endast rader som täcker denna period. Du måste använda ett urval för att extrahera dem. Nu är det bilar och besiktningar som krävdes. Strängarna sammanfogas sedan med sammanlänkningsoperationen. De måste kopplas till det gemensamma registernumret, eftersom det är den enda gemensamma kolumnen används en naturlig sammanfogning.
För att ta reda på om några problem upptäcktes under testerna måste du associera problemraderna med testet. Efter att ha kopplat kontrollrader till bilar kan du koppla detta resultat till feltabellen. Anslutning måste bygga på ett gemensamt registreringsnummer och verifierat datum. Dessa är de enda vanliga kolumnerna i tabellerna, så en naturlig sammanfogning används.
Varianter av beräkningar utan mellanresultat
Obligatorisk information: Förarens namn för årsmodell 1995 eller äldre fordon som inte har testats för 2000. Namnet finns i tabellen "Driver". Rättsväsende beskrivs i tabellen "Besiktning och bilar i matsalsbilen". Så dessa tre tabeller behövs. Först måste du ta reda på de bilar som inte besiktigades för år 2000. Det är inte möjligt att lösa detta problem med endast de inspektioner som anges i tabellen, eftersom den innehåller data om de inspektioner som gjordes och inte om de som inte genomfördes. Detta problem löses genom att leta efter kompletterande bilar som kontrolleras före år 2000. I själva verket behövs bara deras registreringsnummer.
Det finns andra exempel förutom de som anges ovan som visar hur du kan ändra eller hitta någon information. Frågevarianter kan optimeras med speciella operationer. För att göra det så enkelt och enkelt som möjligt att söka och hitta data finns det en relationskalkylmodell.
Där informationen är säker och skyddad
Algebror lagras i filformat som innehåller poster. På den fysiska nivån är den faktiska informationen fixerad i ett elektromagnetiskt format på någon enhet. Dessa lagringsenheter kan delas in i tre kategorier:
- Primär. Denna kategori inkluderar minne som är direkt tillgängligt för CPU:n. register, snabbt minne(cache) och main (RAM) är direkt åtkomliga för centralen, eftersom de alla finns på moderkortet eller chipsetet. Denna lagring är vanligtvis mycket liten, ultrasnabb och instabil. Det krävs en stat för att upprätthålla permanent källa näring. I händelse av ett fel försvinner all data.
- Sekundär. Används för att lagra information för framtida bruk eller Reserv exemplar. Inkluderar minnesenheter som inte är en del av styrkretsen eller moderkort processor, till exempel magnetiska skivor, optiska skivor (DVD, CD, etc.), hårddiskar, flashminnen och magnetband.
- Tertiär. Används för att lagra stora mängder data. Eftersom sådana lagringsenheter är externa till datorsystemet är de långsammast när det gäller hastighet. Dessa lagringsprylar används främst för att säkerhetskopiera hela systemet. Optiska skivor och magnetband används i stor utsträckning som tertiär lagring.
Relationsalgebras speciella operationer är viktiga för frågeeffektiviteten.
Förvaringsstruktur
Datorsystemet har helt klart viss hierarki minne. CPU:n har direkt tillgång till huvudsystemet samt inbyggda register. Åtkomsttiden för huvudminnet är uppenbarligen mindre än processorhastigheten. För att minimera denna diskrepans introduceras en cache. Cache ger det mesta snabb tidåtkomst och innehåller de data som oftast får åtkomst till CPU:n.
Minnet med snabbast åtkomst är det dyraste. Stora enheter Datalagringsenheter är långsamma och billigare, men de kan lagra enorma mängder data jämfört med ett processorregister eller cache.
Magnetiska och hårddiskar är de vanligaste sekundära lagringsenheterna i modern tid datorsystem. De kallas magnetiska, de består av en metallbas. Dessa skivor placeras vertikalt på spindeln. Läs-/skrivhuvudet rör sig mellan dem och används för att magnetisera eller ta bort en sådan punkt under. Det kan kännas igen som 0 (noll) eller 1 (ett).
Hårddiskar formateras i en väldefinierad ordning för effektiv datalagring. Den har många koncentriska cirklar som kallas stigar. Varje spår är vidare uppdelat i sektorer, som vanligtvis lagrar 512 byte med data.
Filoperationer
Operationer på ett relationellt algebraspråksystem och dess databas kan grovt klassificeras i två kategorier:
- uppdatering;
- Sök.
Den första kategorin ändrar datavärden genom att infoga, ta bort eller uppdatera. Å andra sidan redigerar sökoperationer inte information, utan extraherar den efter valfri villkorlig filtrering. I båda typerna av operationer spelar urval en betydande roll. Förutom att skapa och ta bort en fil kan det finnas flera operationer som kan utföras på dem:
- Öppna - finns i ett av två läs- eller skrivlägen. I det första fallet tillåter inte operativsystemet någon att ändra data. Med andra ord, data läses bara. Filer som öppnas i läsläge kan delas mellan flera objekt. Skrivläget låter dig ändra data. Filerna kan läsas men kan inte delas.
- Close är den viktigaste operationen vad gäller operativ system, eftersom det tar bort alla lås (om i läge allmänhetens tillgång), sparar data (om modifierad) till sekundär media och frigör alla buffertar och hanterare som är associerade med filen.
- Indexering är en informationsstrukturmetod för att effektivt extrahera poster från filerna i ett system baserat på vissa attribut där systemet implementerades. Fastställs utifrån attribut.
Indexering kan vara av följande typ:
- Den primära definieras i den beställda datafilen. Informationsfilen är organiserad i ett nyckelfält.
- Det sekundära indexet genereras från ett fält som är en kandidatnyckel och har ett unikt värde i varje post, eller är inte en nyckel med dubbletter av värden.
- Klustring definieras i den beställda datafilen, i ett icke-nyckelfält.
Ett databashanteringssystem eller DBMS hänvisar till en teknik för att lagra och hämta användarinformation med maximal effektivitet tillsammans med lämpliga säkerhetsåtgärder. En detaljerad övervägande av denna fråga leder till slutsatsen att relationalgebra är ett språk av operatorer som tar relationer som argument och returnerar dem som ett resultat.
Varje operation inkluderar dataval (selektion) och de åtgärder som kommer att utföras på den valda datan. Huvudoperationerna i en relationsdatabas är databasuppdateringsoperationer och.
TILL databasuppdateringsåtgärder inkludera de operationer som infogar nya tupler, raderar onödiga, justerar värdena för attribut för befintliga tupler, nämligen: det här är operationer Sätta på, Ta bort, uppdatera.
Drift Sätta på kräver att ställa in namnet på relationen och förforma värdena för attributen för den nya tupeln. Tupelnyckeln måste anges.
Drift Radera kräver att namnet på relationen, samt identifieringen av tuppeln eller gruppen av tuplar tas bort.
Drift Uppdatera utförs för den namngivna relationen och kan uppdatera både en och flera tupler. Till exempel, om företagets ledning beslutat att höja alla anställdas löner med samma belopp, kommer flera tupler att korrigeras på en gång med en uppdateringsoperation.
Rörande bearbetningsverksamhet, sedan är de lånade från relationalgebra. Enligt E. Codds tillvägagångssätt inkluderar relationalgebra åtta operationer, varav fem är grundläggande: Prov, Projektion, Multiplikation, Union, Subtraktion.
Prov- välj från relationen endast de tupler som uppfyller det givna villkoret.
På projektioner relation till en given uppsättning av dess attribut erhålls en ny relation, skapad genom att extrahera tupler som innehåller de specificerade attributen från den ursprungliga relationen.
På multiplikation(kartesisk produkt) av två relationer, erhålls en ny relation, vars tuplar är sammanlänkningen av tuplarna i de första och andra relationerna.
Som ett resultat Föreningar två relationer erhålls en tredje, inklusive tupler som ingår i minst en relation, det vill säga innehåller alla element i de ursprungliga relationerna.
På subtraktion endast de tuplar av den första relationen som återstår efter att den andra relationen har subtraherats returneras, det vill säga alla tuplar av den andra relationen kasseras från den första relationen.
De återstående tre operationerna härleds, de kan erhållas från huvudoperationerna, de kallas ytterligare: Anslutning, Korsning, Division.
Drift Förening gäller två relationer som har ett gemensamt attribut. Resultatet av denna operation för två relationer enligt något villkor är en relation av tupler som är en kombination av de första och andra relationerna som uppfyller det specificerade villkoret.
genomskärning av två relationer är en relation som inkluderar alla tupler som ingår i båda relationerna.
Drift divisioner antar att det finns två relationer: den ena är binär (innehåller två attribut), den andra är unär (innehåller ett attribut). Resultatet är en relation som består av tupler som inkluderar värdena för det första attributet för tuplarna i den första relationen, men bara de för vilka värdeuppsättningen för det andra attributet i den första relationen matchar värdeuppsättningen av attributen för den andra relationen.
Utmärkande drag är att bearbetningsenheten i dem inte är tuplar, utan relationer: vid ingången av varje operation används en eller två relationer, och resultatet av operationerna är en ny relation.
Låt oss överväga några av de vanligaste relationalgebraoperationerna mer i detalj.
Drift En förening- två kompatibla relationer ges vid ingången, av samma dimension: A och B. Resultatet är en relation med samma struktur, som innehåller alla tupler A och alla tuplar B
genomskärning antar närvaron av två relationer av samma dimension vid ingången: A och B. Vid utgången skapas en relation med samma struktur, som endast innehåller de tuplar A som finns i B.
Division. Vid ingången av operationen används två relationer: A och B. Låt relationen A, som kallas delbar, innehålla attribut (A 1, A 2 , A 3 ,..., A n). Relation B är en divisor och innehåller en delmängd av attribut A: (A 1, A 2 , ..., A k), där k Generellt ger operationerna för relationsdatamodellen möjligheten att manipulera relationer, vilket gör att du kan uppdatera databasen, samt välja delmängder av lagrad data och presentera dem i önskad form. När man designar och arbetar med databaser är dessa åtta operationer vanligtvis inte tillräckliga. Därför läggs sådana operationer till som: byta namn på attribut, bildning av nya beräknade attribut, tilldelningsoperationer, jämförelser etc. Ändringsavvikelser
Ändringsavvikelser yttra sig i det faktum att en förändring av värdet på en given kan medföra en skanning av hela tabellen och en motsvarande förändring i vissa andra poster i tabellen. Borttagningsavvikelser bestå i att när du raderar någon data från tabellen kan annan information som inte är direkt relaterad till den raderade datan försvinna. Tilläggsavvikelser uppstår i fall där information inte kan placeras i tabellen förrän den är ofullständig, eller när en ny post infogas kräver ytterligare tabellsökning Låt det finnas en relation som lagrar information om studenter, de kurser de går och kostnaden för dessa kurser. Från denna relation tas en tupel bort som innehåller (utöver information om studenten) information om namn och kostnad för kursen som denna student går. Om informationen om kursens namn och kostnad lagrades i ett enda exemplar endast i denna tupel, kommer den oåterkalleligen att försvinna från relationen. En sådan situation kallas raderingsanomali. Att utföra en raderingsoperation resulterar i förlust av information om två enheter. Ett exempel på detta förhållande kan illustreras införande anomali. Låt oss säga att vi vill lägga till information om namn och kostnad för en viss kurs, men vi kommer inte att kunna lägga till denna information förrän inga studenter är inskrivna i kursen. Du kan bli av med båda anomalierna genom att dela upp den befintliga relationen i två, som var och en kommer att innehålla data från endast en enhet. Att då radera studentinformationen påverkar inte kursdatan. När man delar upp en relation i två uppstår också problem. Är det till exempel möjligt att anmäla en student till en kurs som ännu inte finns? Dessa problem bör lösas genom att förhandla om affärsregler. Om affärsreglerna kräver att det finns information om kursen och kostnaden vid anmälan av en student till denna kurs, då en student är anmäld till en kurs, kommer en kontroll att göras för att den obligatoriska kursen finns. Sådana kontroller kallas referensmässiga integritetsbegränsningar eller integritetsbegränsningar för främmande nyckel. Entitetsintegritet - inget primärnyckelvärde får vara null. Designstadier:
Konceptuell design – databasutvecklingsprocessen börjar med kravanalys. Designern i detta utvecklingsstadium måste hitta svar på följande frågor: vilka dataelement som ska lagras, vem och hur kommer åt dem. En modell skapas. Information oberoende av fysiska aspekter, målsubd och programmeringsspråk Boolean - den logiska strukturen för databasen skapas. För att göra detta, bestäm hur data ska grupperas logiskt. Databasens struktur i detta skede uttrycks i termer av applikationsobjekt och relationer mellan dem. Beror på mål-DBMS, redundanskontroller, normalisering. Fysiskt - den logiska strukturen i databasen omvandlas till en fysisk struktur, med hänsyn till prestandaaspekter. Dataelement i detta skede får attribut och definieras som kolumner i tabellerna för DBMS som valts för implementering av databasen. Grundläggande fil- och indexorganisationsrelationer, integritetsbegränsningar och skydd. För alla - transaktioner- odelbar efter operationer, överför databasen från ett stabilt tillstånd till ett annat. Egenskaper - atomicitet (odelbarhet), konsistens (från ett avtal till ett annat), isolering (användartransaktioner stör inte varandra), hållbarhet (resultatet måste registreras i databasen efter releasen, även om det kraschade i nästa ögonblick ). Entitetsrelationsmetod.
Entitet-relationsmodelleringsmetod ger en abstrakt modell ämnesområde med hjälp av följande grundläggande begrepp: enheter(enheter), sammankopplingar(relationer) mellan enheter och attribut(attribut) för att representera egenskaper hos enheter och relationer. Vilket fragment som helst av ämnesområdet kan representeras som uppsättning enheter, mellan vilka det finns några många kopplingar. Låt oss ge definitioner: Väsenär ett objekt som kan identifieras på något sätt som skiljer det från andra objekt. Exempel: specifik person, företag, evenemang etc. Entitetsuppsättning- en uppsättning enheter av samma typ (som har samma egenskaper). Exempel: alla människor, företag, helgdagar osv. Entitetsuppsättningar behöver inte vara osammanhängande. Till exempel, en enhet som tillhör MEN-uppsättningen tillhör också PEOPLE-uppsättningen. En entitet är faktiskt en uppsättning attribut, som beskriver egenskaperna för alla medlemmar i den givna entitetsuppsättningen. Domän redan var högre. Enhetsnyckelär ett eller flera attribut som unikt identifierar en given enhet. Förbindelseär en förening mellan flera enheter. Exempel: Tyvärr finns det inga generella regler för att avgöra vad som anses vara en enhet och vad som är en relation. I exemplet som diskuterats ovan antog vi att "leads" är en koppling. Det är dock möjligt att överväga "chef"-enheten, som har "hanterar" med "avdelning"-entiteten och "är" med "anställd"-entiteten. En relation kan också ha attribut. Till exempel, för en relation DEPARTMENT-WORKER, kan du ställa in attributet LENGTH_WORK_IN_DEPARTMENT. En enhets roll i en relation- den funktion som enheten utför i detta sammanhang. Till exempel, i en FÖRÄLDER-BARN-relation kan PERSON-enheter ha rollerna "förälder" och "barn". Att specificera roller i entitetsrelationsmodellen är valfritt och tjänar till att förtydliga relationens semantik. Relationsuppsättningär förhållandet mellan n(och n minst 2) enheter, som var och en tillhör någon uppsättning enheter. Även om begreppen "länk" och "uppsättning länkar" strängt taget är olika (den första är en del av den andra), är de ändå väldigt ofta förvirrade. När n=2, dvs. när en relation kombinerar två enheter kallas den för binär. Bevisade det n-är uppsättning anslutningar ( n>2) kan alltid ersättas av en uppsättning binära, men de förra återspeglar bättre semantiken i ämnesområdet. Antalet enheter som kan associeras genom en uppsättning relationer med en annan enhet kallas grad av anslutning. Att överväga grader är särskilt användbart för binära relationer. Följande grader av binära relationer kan finnas: Annan viktig egenskap anslutning förutom dess grad är medlemsklass de enheter den innehåller, eller kardinalitet anslutningar. "ANSTÄLLD" har obligatorisk medlemsklass(detta faktum indikeras också genom att ange intervallet för antalet möjliga förekomster av enheten i relationen, i det här falletär 1,1), och enheten "DEPARTMENT" har valfri medlemsklass(0,1). Nu detta samband vi kan beskriva hur 0,1:1,1
. Denna figur illustrerar ytterligare det faktum att flera uppsättningar av relationer kan definieras mellan två enheter. I det här fallet, av uppenbara skäl (varje kontrakt ingås med en specifik kund, och varje kund har minst ett kontrakt, annars skulle det inte vara sådant), har varje enhet en obligatorisk medlemsklass. Om existensen av en entitet x beror på existensen av en entitet y, så kallas x beroende enhet(ibland kallas entitet x "svag" och "entitet" y kallas stark). Som ett exempel, betrakta förhållandet mellan de tidigare beskrivna enheterna WORK_TEAM och CONTRACT. Arbetsgrupp skapas först efter att kontraktet har undertecknats med kunden, och upphör att existera när kontraktet har slutförts. Då är WORK_GROUP beroende av enheten KONTRAKT. En beroende enhet kommer att betecknas med en dubbel rektangel, och dess koppling till en stark enhet med en linje med en pil ( vi hade en oval för en missbrukare) Kardinaliteten av en anslutning för en stark enhet kommer alltid att vara (1,1). Medlemsklassen och graden av relation för en beroende enhet kan vara vad som helst. 12. Hierarkiska och nätverksdatamodeller. Hierarkisk modellär en uppsättning element ordnade i den ordning de är underordnade från allmänt till särskilt och bildar ett inverterat träd (graf) i struktur. De grundläggande begreppen i en hierarkisk struktur inkluderar nivå, nod och relation. Knutär en samling dataattribut som beskriver något objekt. I ett hierarkiskt träddiagram representeras noder av grafens hörn. Varje nod på en lägre nivå är ansluten till endast en nod på en högre nivå. hög nivå. Ett hierarkiskt träd har bara en vertex, som inte är underordnad någon annan vertex och är placerad på toppen - den första nivån. Beroende (slav) noder finns på andra, tredje, etc. nivåer. Antalet träd i databasen bestäms av antalet rotposter. Varje databaspost har bara en hierarkisk sökväg från rotposten. Organisationen av data i en hierarkisk DBMS definieras i termer av: element, aggregat, post (grupp), grupprelation, databas. Rotposten för varje träd måste innehålla en nyckel med ett unikt värde. Nycklar till icke-rotposter bör endast ha ett unikt värde inom en grupprelation. Varje post identifieras av en fullständig sammanlänkade nyckel, som förstås som uppsättningen nycklar för alla poster från roten längs den hierarkiska vägen. På grafisk bild grupprelationer representeras av riktade grafbågar, och posttyper representeras av hörn. För grupprelationer i en hierarkisk modell tillhandahålls den automatiskt läge inklusioner och fast medlemskap. Detta innebär att för att komma ihåg en icke-rotpost i databasen måste dess överordnade post finnas. När en överordnad post raderas, raderas alla underordnade poster automatiskt. Exempel: Ett företag består av avdelningar där anställda arbetar. Varje avdelning kan ha flera anställda, men en anställd kan inte arbeta på mer än en avdelning. Därför, för informationssystem I HR-hantering behöver du skapa en grupprelation som består av den överordnade posten DEPARTMENT (NAME_DEPARTMENT, NUMBER_EMPLOYEES) och den underordnade posten MEDARBETARE (EFTERNAMN, POSITION, LÖN). (För enkelhetens skull antas det att det bara finns två underordnade poster.) - ris a (nästa) För att automatisera redovisningen av kontrakt med kunder är det nödvändigt att skapa en annan hierarkisk struktur: kunden - kontrakt med honom - de anställda som är involverade i arbetet med kontraktet. Detta träd kommer att inkludera posterna KUND(KUNDNAMN, ADDRESS), KONTRAKT(NUMMER, DATUM, BELÖP), ENTREPRENÖR (EFTERNAMN, POSITION, AVDELNING_NAMN) - fig. b. Brister hierarkiska databaser: Fördelar: Är det enklaste nog effektiv användning minne och bra temporal prestanda för dataoperationer. Denna modell är dock praktiskt främst för att arbeta med hierarkiskt organiserad information. Dataoperationer definierade i den hierarkiska modellen: I EXTRACT-operationen kan urvalsvillkor specificeras. Alla modifieringsoperationer tillämpas endast på en "aktuell" post (som tidigare hämtats från databasen). Denna metod för datamanipulation kallas "navigering". Integritetsbegränsningar. Endast integriteten hos relationer mellan ägare och medlemmar i en grupprelation upprätthålls (ingen ättling kan existera utan en förfader). Det finns inget automatiskt underhåll av korrespondens för parade poster som ingår i olika hierarkier. De första databashanteringssystemen, som dök upp i mitten av 60-talet, gjorde det möjligt att arbeta med en hierarkisk databas. Det mest kända var det hierarkiska IMS-systemet från IBM. Andra system är också kända: PC / Focus, Team-Up, Data Edge och våra: Oka, INES, MIRIS. nätverksdatamodell. nätverksmodell- en struktur i vilken vilket element som helst kan associeras med vilket annat element som helst En nätverksdatabas består av uppsättningar poster som är sammanlänkade så att poster kan innehålla explicita länkar till andra uppsättningar poster. Således bildar postuppsättningarna ett nätverk. Relationer mellan poster kan vara godtyckliga, och dessa relationer finns explicit och lagras i databasen. Nätverksdatamodellen definieras i samma termer som den hierarkiska. Den består av många poster, som kan vara ägare eller medlemmar av grupprelationer. Förhållandet mellan ett ägarregister och ett medlemsregister är också 1:N. Den största skillnaden mellan dessa modeller är att i nätverksmodellen kan en post vara medlem mer än ett gruppförhållande. Enligt denna modell namnges varje grupprelation och man skiljer på dess typ och dess instans. Grupprelationstypen specificeras med sitt namn och definierar egenskaperna som är gemensamma för alla instanser av den givna typen. En instans av en grupprelation representeras av en ägarpost och en uppsättning (eventuellt tom) av underordnade poster. Det finns dock följande begränsning: en instans av en post kan inte vara medlem i två instanser av en grupprelation av samma typ (en anställd kan inte arbeta på två avdelningar) Hierarkisk struktur från bilden ovan. konverteras till nätverk enligt följande Träden (a) och (b) ersätts av en enda nätverksstruktur där ANSTÄLLDAREN är i två grupprelationer; för mappningen av M:N-typ anges posten EMPLOYEE_CONTRACT, som inte har några fält och endast tjänar till att länka CONTRACT- och EMPLOYEE-posterna Varje instans av en grupprelation kännetecknas av följande egenskaper: slumpmässig, kronologisk /kö/, omvänd kronologisk /stack/, blandad. Om en post förklaras vara underordnad i mer än en grupprelation, kan var och en av dem tilldelas sin egen ordningsmetod. automatiskt - det är omöjligt att lägga in en post i databasen utan att den omedelbart tilldelas en viss ägare; manual - låter dig lagra en underordnad post i databasen och inte omedelbart inkludera den i en instans av en grupprelation. Denna operation initieras senare av användaren). Fast. En underordnad post är strikt kopplad till ägarposten och kan endast exkluderas från gruppförhållandet genom att radera den. När en ägarpost raderas raderas även alla underordnade poster automatiskt. I exemplet förutsätter fast medlemskap en grupprelation "SLUTAR" mellan posterna "CONTRACT" och "CUSTOMER" eftersom kontraktet inte kan existera utan kunden. Obligatorisk. Det är tillåtet att byta en underordnad post till en annan ägare, men det är omöjligt att den existerar utan en ägare. För att radera en ägarpost får den inte ha några underordnade poster med obligatoriskt medlemskap. Posterna "EMPLOYEE" och "DEPARTMENT" är relaterade till detta förhållande. Om en avdelning avvecklas måste alla dess anställda antingen flyttas över till andra avdelningar eller sägas upp. Frivillig. Du kan utesluta en post från en grupprelation, men behålla den i databasen utan att koppla den till en annan ägare. När en ägarpost raderas lagras dess underordnade poster - valfria medlemmar - i databasen och deltar inte längre i en grupprelation av denna typ. Ett exempel på en sådan grupprelation är "UTFÖR" mellan "ANSTÄLLDA" och "KONTRAKT", eftersom det kan finnas anställda i organisationen vars verksamhet inte är relaterade till fullgörandet av några avtalsenliga förpliktelser gentemot kunder. Operationer på data. LÄGG TILL- gör en inmatning i databasen och, beroende på inkluderingsläget, antingen inkludera den i en grupprelation, där den deklareras som en underordnad, eller inte inkludera den i någon grupprelation. INKLUDERA I GRUPPERELATIONEN- associera en befintlig underordnad post med en ägarpost. VÄXLA- koppla en befintlig underordnad post till en annan ägarpost i samma koncernförhållande. UPPDATERING- ändra värdet på elementen i den tidigare hämtade posten. EXTRAHERA- extrahera poster sekventiellt efter nyckelvärde, samt använda grupprelationer - från ägaren kan du gå till medlemsposter och från den underordnade posten till ägaren av uppsättningen. RADERA- ta bort posten från databasen. Om denna post är ägaren till grupprelationen, tolkas medlemsklassen för de underordnade posterna. Nödvändiga medlemmar måste tidigare exkluderas från grupprelationen, fasta medlemmar raderas tillsammans med ägaren, valfria kommer att finnas kvar i databasen. Integritetsbegränsningar. Liksom i den hierarkiska modellen upprätthålls endast referensintegritet (ägaren av relationen är medlem av relationen). Main värdighet nätverk modell är en hög minne kostnadseffektivitet och lyhördhet. Fel- komplexiteten och stelheten i grundschemat, såväl som förståelsens komplexitet. Dessutom är integritetskontrollen försvagad i denna modell, eftersom den låter dig upprätta godtyckliga länkar mellan poster. Komplexiteten i DBMS-implementeringen, komplexiteten i dataåtkomstmekanismen och behovet av att tydligt definiera datalänkar på fysisk nivå Till de berömda nätverkssystem databashantering inkluderar: DBMS, IDMS, TOTAL, VISTA, NETWORK, SETOR, KOMPAS, etc. Om vi jämför hierarkiska databaser och nätverksdatabaser kan vi säga följande. I allmänhet ger hierarkiska modeller och nätverksmodeller tillräckligt snabb åtkomst till datan. Men eftersom informationsrepresentationens huvudstruktur i nätverksbaser har formen av ett nätverk där varje vertex (nod) kan ha en koppling med vilken som helst annan, då data i nätverksdatabas mer lika än i en hierarkisk, eftersom information kan nås från vilken nod som helst. Grafmodeller (hierarkiska och nätverksmodeller) implementeras som datamodeller i databashanteringssystem som körs på stora datorer. För personliga datorer relationsdatabaser är vanligare, även om det också finns databashanteringssystem som stödjer nätverksmodellen. Introduktion. 4
1. Databaser och DBMS 6
2. Relationsdatabaser 20
3. Operationer på relationsdatabastabeller 29
4. Utveckling av infoologiska modeller 49
5. Organisation av tillgång till data 64
6. Principer för att bygga system fokuserade på dataanalys 96
Slutsats. 106
Lista över de vanligaste förkortningarna. 107
Given handledning enligt vår mening syftar den till att systematisera och presentera metodiskt i en form tillgänglig för inledande studier och behärskning av materialet i den volym och innehåll som uppfyller kraven för programmet för kursen "Databaser". Den består av sex sammanlänkade avsnitt, där följande frågor behandlas steg för steg: Uppfattningen av den verkliga världen kan korreleras med en sekvens av olika, men ibland relaterade, fenomen. Sedan urminnes tider har människor försökt beskriva dessa fenomen (även när de inte kunde förstå dem). En sådan beskrivning kallas data. Traditionellt utförs datafångst med hjälp av specifika medel kommunikation (till exempel genom naturligt språk eller bilder) på ett specifikt medium (som sten eller papper). Typiskt fångas data (fakta, fenomen, händelser, idéer eller objekt) och deras tolkning (semantik) tillsammans, eftersom naturligt språk är tillräckligt flexibelt för att representera båda. Ett exempel skulle vara uttalandet "Pris på flygbiljetter 128". Här är "128" det givna värdet, och "Pris på flygbiljetter" är dess semantik. Ofta är data och tolkning åtskilda. Till exempel kan "Flygplansschemat" presenteras i form av en tabell (Fig. 1.1.1), i den övre delen av vilken (separat från data) deras tolkning ges. Denna uppdelning gör det svårt att arbeta med data (försök att snabbt få information från botten av tabellen). Användningen av datorer för underhåll Jag (medföljer, stödjer) och databehandling leder vanligtvis till ännu större separation av data och tolkning. Datorn sysslar främst med data som sådan. Det mesta av tolkningsinformationen är inte explicit registrerad alls (datorn "vet" inte om "21.50" är kostnaden för flygbiljetten eller tidpunkten för avgång). Varför hände det här? Finns enl åtminstone två historiska skäl till varför användningen av datorer ledde till att data separerades från tolkning. För det första hade datorer inte tillräckliga möjligheter att bearbeta texter på naturligt språk - huvudspråket för att tolka data. För det andra var kostnaden för datorminne till en början mycket hög. Minnet användes för att lagra själva data, med tolkning som traditionellt lämnats till användaren. Användaren lägger in tolkningen av data i sitt program, som "visste", till exempel, att det sjätte ingångsvärdet är associerat med tidpunkten för flygplanets ankomst och det fjärde - med tiden för dess avgång. Detta ökade programmets roll avsevärt, eftersom data, utanför tolkning, inte är något annat än en samling bitar på en lagringsenhet. Rigid beroende mellan data och program som använder dem skapar allvarliga problem med att underhålla data och gör användningen mindre flexibel.1.2. Databas koncept. DBMS-arkitektur Kraftfull aktivitet för att hitta acceptabla sätt att socialisera den ständigt växande informationsmängden ledde till skapandet i början av 60-talet av speciella mjukvarusystem kallas " Databashanteringssystem"(DBMS). DBMS – programvara, utföra skapandet av databaser, underhålla dem i fungerande skick och ge effektiv tillgång till databasdata för användare och applikationer. Huvudfunktionen hos DBMS är närvaron av procedurer för att mata in och lagra inte bara själva data utan också beskrivningar av deras struktur. Filer försedda med en beskrivning av data som lagrats i dem och kontrolleras av DBMS började kallas databanker, och sedan " Databas"(DB). Alltså, Databas(DB) - en reflektion av ämnesområdet i form av en strukturerad uppsättning data. Data som lagras i den kännetecknar sammansättningen av föremålen i ämnesområdet, deras egenskaper och relationer. DBMS bör ge åtkomst till data till alla användare, inklusive de som har liten eller ingen aning och (eller) inte vill ha någon aning om: När du utför de viktigaste av dessa funktioner bör DBMS använda olika beskrivningar data. Hur skapar du dessa beskrivningar? Naturligtvis måste ett databasprojekt börja med en analys av ämnesområdet och identifiering av kraven på det av enskilda användare (anställda i den organisation för vilken databasen skapas). Design anförtros vanligtvis en person (grupp av personer) − databasadministratör(ABD). Det kan antingen vara en särskilt engagerad anställd i organisationen, eller framtida användare databas, ganska bekant med maskindatabehandling. Ris. 1.2.1. Datamodelllager En sådan människocentrerad modell är helt oberoende av de fysiska parametrarna för datalagringsmiljön. I slutändan kan detta medium vara minnet av en person, inte en dator. 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 en förändring av någon definition i den, så att denna modell fortsätter att spegla ämnesområdet. Resten av modellerna som visas i fig. 1.2.1 är datorspecifika. Med deras hjälp tillåter DBMS program och användare att få tillgång till lagrad data endast genom deras namn, utan att oroa sig för den fysiska platsen för dessa data. Nödvändig data hittas av DBMS på externa lagringsenheter som använder fysisk datamodell. De angivna förändringarna i de fysiska och datalogiska modellerna kommer inte att märkas av befintliga användare av systemet (de kommer att vara "transparenta" för dem), precis som nya användare inte kommer att märkas. Därför tillåter dataoberoende databassystemet att utvecklas utan att störa befintliga applikationer. Tredelad arkitektur (infologisk, datalogisk och fysiska lager) gör det möjligt att tillhandahålla dataoberoende från programmen som använder dem. DBA:n kan vid behov skriva om lagrad data till andra lagringsmedier och (eller) omorganisera deras fysiska struktur, genom att endast ändra den fysiska datamodellen. DBA:n kan ansluta valfritt antal nya användare (nya applikationer) till systemet och kompletterar, vid behov, den datalogiska modellen.
UNDANTAG FRÅN GRUPPERELATION- bryta sambandet mellan ägarrekordet och medlemsrekordet.
Introduktion.
Det finns väldigt lite litteratur på ryska om ämnet DBMS. Det är inte möjligt att rekommendera en eller flera böcker som täcker innehållet i Databaskursen. Bland de bästa är C. Date's Introduction to Database Systems (Science, 1980) och The DB2 Relational DBMS Guide (Finance and Statistics, 1988), och J. Ullman's Fundamentals of Database Systems (Finance and statistics, 1983). Även om dessa böcker är något föråldrade (på engelska språket det finns redan flera kompletterade upplagor), de är värda att läsa.
Läroboken är avsedd för studenter inom alla specialiteter och utbildningsformer.
databaskoncept, DBMS-arkitektur (infologisk datamodell, datalogisk datamodell, fysisk datamodell, typer av datalogiska datamodeller, hierarkisk datalogisk modell, nätverksdatalogisk modell, datalogisk modell baserad på postningslistor, relationsdatalogisk modell, objektrelationell datalogisk modell);
relationsdatabaser (grundläggande begrepp för relationsdatabaser, datatyp, domän, relationsschema, databasschema, tuppel, relation, relationsdatabasintegritet, grundläggande egenskaper för relationsdatabasrelationer);
operationer på relationsdatabastabeller (mängdteorioperationer, normalisering av relationer i relationsdatabaser);
använda språket i ER-diagram för att bygga infologiska modeller ("entity-relationship" diagram, informationsmodellering, IDEF1X-metodik, stadier av utveckling av infologiska datamodeller);
organisation av åtkomst till data (medel för accelererad åtkomst till data, frågespråk, transaktionsbearbetning, sätt att återställa efter fel);
principer för att bygga system fokuserade på dataanalys (datalager; datamodeller som används för att bygga datalager).1. Databaser och DBMS
1.1. Data och datorer
Tolkning
Flygnummer
Dagar i veckan
Utgångspunkt
Avgångstid
Destination
Ankomst tid
flygplanstyp
Biljettpris
Data
138
2_4_7
Baku
21.12
Moskva
0.52
IL-86
115.00
57
3_6
Jerevan
7.20
Kiev
9.25
TU-154
92.00
1234
2_6
Kazan
22.40
Baku
23.50
TU-134
73.50
242
1 till 7
Kiev
14.10
Moskva
16.15
TU-154
57.00
86
2_3_5
Minsk
10.50
Sochi
13.06
IL-86
78.50
137
1_3_6
Moskva
15.17
Baku
18.44
IL-86
115.00
241
1 till 7
Moskva
9.05
Kiev
11.05
TU-154
57.00
577
1_3_5
Riga
21.53
Tallinn
22.57
AN-24
21.50
78
3_6
Sochi
18.25
Baku
20.12
TU-134
44.00
578
2_4_6
Tallinn
6.30
Riga
7.37
AN-24
21.50
Ris. 1.1.1. Data och deras tolkning.
och många andra DBMS-funktioner.
fysisk plats i minnet av data och deras beskrivningar;
sökmekanismer för de begärda uppgifterna;
problem som härrör från samtidig begäran samma data av många användare ( applikationsprogram);
sätt att skydda data från felaktiga uppdateringar och (eller) obehörig åtkomst;
hålla databaserna uppdaterade1.2.1. Infologisk datamodell
Genom att kombinera privata synpunkter på innehållet i databasen, erhållna från användarundersökningar, och dess syn på data som kan krävas i framtida applikationer, skapar DBA först en generaliserad informell beskrivning skapade bas data. Detta är en naturlig språkbeskrivning matematiska formler, tabeller, grafer och andra sätt som förstås av alla som arbetar med databasdesign kallas infologisk datamodell(Fig. 1.2.1). 
1.2.2. Datalogisk datamodell
Eftersom den angivna åtkomsten utförs med ett specifikt DBMS bör modellerna beskrivas i termer av språk för databeskrivning detta DBMS. En sådan beskrivning skapad av DBA enligt den infologiska datamodellen kallas datalogisk datamodell.1.2.3. Fysisk datamodell
Till skillnad från den infologiska datamodellen är den fysiska modellen helt beroende av det specifika DBMS. Det måste ta hänsyn till
Samma infologiska datamodell kan motsvara flera olika fysiska modeller.
begränsningar av längden på namn på databasobjekt (tabeller, kolumner, index),
användande speciella karaktärer i namn
tillåtna datatyper och deras interna representation på datalagringsenheter i en dator.