Waar is de primaire sleutel van een tabel voor? Natuurlijke en surrogaatsleutel. Veel-op-veel relaties

• Vertaling

Ik verspreid de voortzetting van de vertaling van een reeks artikelen voor beginners.
In het heden en later - meer informatie over de verdiensten.
Begin - .

4. TABELLEN EN PRIMAIRE TOETSEN

Zoals je uit de vorige delen al weet, worden de gegevens opgeslagen in tafels, die bevatten lijnen of op een andere manier records. Eerder gaf ik een voorbeeld van een tabel met informatie over lessen. Laten we er nog eens naar kijken.

Er staan ​​6 lessen in de tabel. Alle 6 zijn verschillend, maar voor elke les worden de waarden van dezelfde velden in de tabel opgeslagen, namelijk: tutorial_id (les-ID), titel (titel) en categorie (categorie). tutorial_id – hoofdsleutel les tafels. Een primaire sleutel is een waarde die uniek is voor elke record in een tabel.
In de onderstaande klantentabel is customer_id de primaire sleutel. V deze zaak primaire sleutel is ook unieke waarde(nummer) voor elke invoer.

Primaire sleutels in het dagelijkse leven

In een database worden primaire sleutels gebruikt voor identificatie. In het leven zijn primaire sleutels overal om ons heen. Telkens wanneer u een uniek nummer tegenkomt, kan dat nummer dienen als primaire sleutel in een database (het kan, maar hoeft niet als zodanig te worden gebruikt. Alle databases zijn in staat om automatisch een unieke waarde voor elk record te genereren als een nummer dat wordt automatisch verhoogd en samen met elk nieuw record ingevoegd [zogenaamde synthetische of surrogaat primaire sleutel - approx.transl.]).

Een paar voorbeelden

• Het bestelnummer dat u ontvangt bij het kopen van een online winkel kan de primaire sleutel zijn van een tabel met bestellingen in de database van deze winkel, omdat. het is een unieke waarde.
• Nummer sociale verzekering kan de primaire sleutel zijn in een tabel in de database publieke instelling, omdat het is ook uniek zoals in het vorige voorbeeld.
• Een factuurnummer kan worden gebruikt als primaire sleutel in een databasetabel waarin facturen zijn opgeslagen die aan klanten zijn uitgegeven.
• Het numerieke klantnummer wordt vaak gebruikt als de primaire sleutel in de klantentabel.

Wat hebben deze voorbeelden gemeen? Het feit dat in alle records een unieke, niet-herhalende waarde voor elk record als primaire sleutel wordt geselecteerd. Nog een keer. De waarden van een databasetabelveld dat als primaire sleutel is geselecteerd, zijn altijd uniek.

Wat kenmerkt een primaire sleutel? Kenmerken van de primaire sleutel.

De primaire sleutel wordt gebruikt om records te identificeren.

De primaire sleutel wordt gebruikt voor: identificatie vermeldingen in de tabel zodat elke vermelding uniek is. Nog een analogie... Wanneer u de dienst belt technische hulp, vraagt ​​de operator u meestal om een ​​nummer te noemen (contract, telefoon, enz.) waarmee u in het systeem kunt worden geïdentificeerd.
Als u uw nummer bent vergeten, zal de helpdeskmedewerker u om andere informatie vragen die u uniek identificeert. Bijvoorbeeld een combinatie van je verjaardag en achternaam. Ze kunnen ook de primaire sleutel zijn, of liever hun combinatie.

De primaire sleutel is uniek.

De primaire sleutel heeft altijd een unieke waarde. Stel je voor dat de waarde ervan niet uniek is. Dan kon het niet worden gebruikt om de gegevens in de tabel te identificeren. Dit betekent dat elke waarde van de primaire sleutel maar één keer kan voorkomen in de kolom die als primaire sleutel is geselecteerd. RDBMS'en zijn ontworpen om te voorkomen dat u duplicaten invoegt in een primair sleutelveld, u krijgt een foutmelding.
Nog een voorbeeld. Stel je voor dat je een tabel hebt met velden first_name en last_name en er zijn twee records:

| voornaam | achternaam |
| vasya |pupkin |
| vasya |pupkin |

Die. er zijn twee Vasya's. U wilt een specifieke Vasya uit de tabel selecteren. Hoe je dat doet? De records zijn niet anders. Dit is waar de primaire sleutel van pas komt. We voegen een id-kolom toe (de klassieke versie van een synthetische primaire sleutel) en ...

id | voornaam | achternaam |
1 | vasya |pupkin |
2 | vasya |pupkin |

Nu is elke Vasya uniek.

Soorten primaire sleutels.

Meestal is de primaire sleutel numerieke waarde. Maar het kan ook elk ander gegevenstype zijn. Het is niet gebruikelijk om een ​​string als primaire sleutel te gebruiken (een string is een stuk tekst), maar theoretisch en praktisch is het mogelijk.
Samengestelde primaire sleutels.
Vaak bestaat de primaire sleutel uit één veld, maar het kan ook een combinatie zijn van meerdere kolommen, bijvoorbeeld twee (drie, vier ...). Maar onthoud dat de primaire sleutel altijd uniek is, wat betekent dat de combinatie van het n-de aantal velden, in dit geval 2, uniek moet zijn. Hierover vertel ik later meer.

Automatische nummering.

Het primaire sleutelveld wordt vaak, maar niet altijd, afgehandeld door de database zelf. U kunt relatief gezien de database vertellen om automatisch een unieke numerieke waarde toe te kennen aan elk record wanneer het wordt gemaakt. De database begint meestal met nummeren bij 1 en verhoogt dat nummer voor elke invoer met één. Zo'n primaire sleutel wordt auto-incrementing of auto-numbered genoemd. Auto-increment-toetsen gebruiken − goede manier om unieke primaire sleutels in te stellen. De klassieke naam voor zo'n sleutel is een surrogaat primaire sleutel [Zoals hierboven vermeld. - ca. vert.]. Deze sleutel bevat geen bruikbare informatie, met betrekking tot de entiteit (object), informatie waarover in de tabel is opgeslagen, daarom wordt het surrogaat genoemd.

5. TABELLEN KOPPELEN MET BUITENLANDSE SLEUTELS

Toen ik begon met het ontwikkelen van databases, probeerde ik vaak informatie die gerelateerd leek op te slaan in één tabel. Ik zou bijvoorbeeld bestelinformatie kunnen opslaan in een klantentabel. Bestellingen zijn immers van klanten, toch? Nee. Klanten en bestellingen zijn afzonderlijke entiteiten in de database. Beiden hebben hun eigen tafel nodig. En de records in deze twee tabellen kunnen worden gekoppeld om een ​​relatie tussen hen tot stand te brengen. Databaseontwerp is een oplossing voor twee vragen:

• definiëren welke entiteiten u erin wilt opslaan
• Wat zijn de relaties tussen deze entiteiten?

Een te veel.

Klanten en bestellingen zijn verbonden (ze hebben een relatie) een te veel omdat een de klant kan hebben kavel bestellingen, maar elke specifieke bestelling (hun een stelletje) is alleen ingelijst een opdrachtgever, d.w.z. kan maar één klant hebben. Maak je geen zorgen als de dit moment begrip van dit verband is vaag. Ik zal in latere delen meer vertellen over verbindingen.

Eén ding is nu belangrijk - dat voor een een-op-veel-relatie, twee aparte tabellen. Een voor klanten, de andere voor bestellingen. Laten we een beetje oefenen door deze twee tabellen te maken.

Welke informatie gaan we opslaan? Laten we de eerste vraag oplossen.

Om te beginnen bepalen we over welke informatie bestellingen en over klanten we zullen opslaan. Om dit te doen, moeten we onszelf de vraag stellen: “Welke informatie heeft betrekking op klanten en welke informatie heeft betrekking op bestellingen?”

We zijn een klantentafel aan het ontwerpen.

Bestellingen echt van klanten zijn, maar een bestelling niet minimaal informatieblok, die verwijst naar klanten (d.w.z. dit blok kan worden onderverdeeld in kleinere: besteldatum, afleveradres van de bestelling, enz.).
De onderstaande velden zijn: minimale blokken informatie met betrekking tot klanten:

• customer_id (primaire sleutel) – klant-ID
• voornaam Naam
• achternaam - patroniem
• adres adres
• postcode- postcode
• land - land
• geboortedatum - geboortedatum
• gebruikersnaam - registratie naam gebruiker login)
• wachtwoord - wachtwoord

Laten we verder gaan met het maken van deze tabel in SQLyog (u kunt natuurlijk elk ander programma gebruiken). Het volgende is een voorbeeld van hoe een tabel in SQLyog eruit zou kunnen zien als deze er eenmaal is gemaakt. Alles grafische toepassingen voor databasebeheer hebben ongeveer dezelfde interfacestructuur. U kunt ook een tabel maken met opdrachtregel zonder een grafisch hulpprogramma te gebruiken.

Een tabel maken in SQLyog. Merk op dat het keuzevakje voor de primaire sleutel (PK) voor het veld customer_id is geselecteerd. Het veld customer_id is de primaire sleutel. Het selectievakje Auto Incr is ook ingeschakeld, wat betekent dat de database automatisch een unieke numerieke waarde vervangt, die, beginnend bij nul, elke keer met één wordt verhoogd.

Wij ontwerpen de tabel met bestellingen.
Wat zijn de minimale stukjes informatie die we nodig hebben met betrekking tot een bestelling?

• order_id (primaire sleutel) – order-ID
• order_date - datum en tijd van de bestelling
• klant - de klant die de bestelling heeft geplaatst

Hieronder staat een voorbeeldtabel in SQLyog.

Deze twee tabellen ( klanten en bestellingen) zijn gerelateerd omdat het veld klant in de volgordetabel verwijst naar de primaire sleutel ( Klanten ID) klantentafels. Zo'n verbinding heet buitenlandse sleutel relatie. U moet de externe sleutel zien als: eenvoudige kopie(kopie van de waarde) van de primaire sleutel van een andere tabel. In ons geval is de veldwaarde Klanten ID van de tafel klanten gekopieerd naar tabel bestellingen bij het invoegen van elke record. Elke bestelling is dus gekoppeld aan een klant. En elke klant kan veel bestellingen hebben, zoals hierboven vermeld.

Maak een externe-sleutelrelatie.

U vraagt ​​zich misschien af: "Hoe kan ik er zeker van zijn of hoe kan ik zien dat naar het klantveld in de besteltabel wordt verwezen door het klant_id-veld in de klanttabel." Het antwoord is simpel - je kunt dit niet doen omdat ik je nog niet heb laten zien hoe je een verbinding kunt maken.
Hieronder staat het SQLyog-venster met het venster dat ik heb gebruikt om de relatie tussen de tabellen te maken.

Creëer een externe-sleutelrelatie tussen de bestellingen en klantentabellen.

In het bovenstaande venster kunt u zien hoe het klantveld van de besteltabel aan de linkerkant is gekoppeld aan de primaire sleutel (klant_id) van de klanttabel aan de rechterkant.

Als je nu kijkt naar de gegevens die in de tabellen zouden kunnen staan, zul je zien dat de twee tabellen gerelateerd zijn.

Bestellingen worden aan klanten gekoppeld via het klantveld, dat verwijst naar de klantentabel.

In de afbeelding kunt u zien dat de cliënt Maria drie bestellingen geplaatst, klant pablo plaatste er een en de klant John- niemand.
U kunt vragen: "A wat Is dat wat al deze mensen hebben besteld?” Deze goede vraag. In de besteltabel had u wellicht de bestelde artikelen verwacht. Maar dit is een slecht ontwerpvoorbeeld. Hoe zou u meerdere producten in één item passen? Producten zijn afzonderlijke entiteiten die in een afzonderlijke tabel moeten worden opgeslagen. En relatie tussen tabellen bestellingen en goederen zal een een-op-veel relatie zijn. Ik zal hier verder over praten.

6. EEN ENTITY-KOPPELINGSDIAGRAM MAKEN

Eerder hebt u geleerd hoe records uit verschillende tabellen aan elkaar zijn gerelateerd in relationele databases. Voordat u tabellen maakt en koppelt, is het belangrijk dat u nadenkt over: entiteiten die op uw systeem bestaan ​​(waarvoor u een database aanmaakt) en beslissen hoe deze entiteiten zouden gecontacteerd samen. Bij het ontwerpen van databases worden entiteiten en hun relaties meestal gegeven in entiteit-relatiediagram (ERD). Deze grafiek is het resultaat van het databaseontwerpproces.

Essenties.

Je vraagt ​​je misschien af ​​wat een entiteit precies is. Nou... het is een "ding" in het systeem. Daar. Mijn moeder wilde altijd dat ik lerares zou worden omdat ik heel goed kan uitleggen.

In de context database-ontwerp essentie is iets dat verdient uw eigen tabel in uw databasemodel. Wanneer u een database ontwerpt, moet u deze definiëren entiteiten op het systeem waarvoor u de database aanmaakt. Het is meer een kwestie van dialoog met de klant of met jezelf om erachter te komen met welke data jouw systeem gaat werken.

Laten we als voorbeeld een online winkel nemen. Online winkel verkoopt producten. Product zou een voor de hand liggende entiteit kunnen worden in het online winkelsysteem. Producten besteldklanten. Hier zijn we bij u en zagen nog twee voor de hand liggende entiteiten: bestellingen en klanten.

De bestelling wordt betaald door de klant... dat is interessant. Gaan we een aparte tabel maken voor betalingen in de database van onze online winkel? Kan zijn. Maar zijn betalingen de minimale informatie die van toepassing is op bestellingen? Dit is ook mogelijk.

Als u het niet zeker weet, bedenk dan wat voor soort betalingsgegevens u wilt opslaan. Misschien wil je houden betalingsmiddel of betaaldatum. Maar dit zijn nog steeds de minimale stukjes informatie die relevant kunnen zijn voor: volgorde. U kunt de verwoording veranderen. Betaalmethode - betaalmethode bestellen. Betaaldatum - de betaaldatum van de bestelling. Dus ik zie geen noodzaak om te maken betalingen in een aparte tabel, hoewel u conceptueel betalingen als een entiteit zou kunnen onderscheiden, omdat je zou betalingen kunnen zien als een container met informatie (betalingswijze, datum van betaling).

Laten we niet te academisch zijn.

Zoals u kunt zien, is er een verschil tussen een entiteit en een tabel in de database zelf, d.w.z. het is niet hetzelfde. Sectorspecialisten informatie technologieën kan ZEER academisch en pedant zijn over dit onderwerp. Ik ben niet zo'n specialist. Dit verschil hangt af van uw standpunt over uw gegevens, uw informatie. Als je kijkt naar datamodellering in termen van: software, dan kun je eindigen met veel entiteiten die niet rechtstreeks naar de database kunnen worden overgebracht. V deze handleiding we kijken strikt naar gegevens in termen van databases en in onze kleine wereld entiteit is een tabel.

Wacht even, je bent heel dicht bij het behalen van je doctoraat in databases.

Zoals je kunt zien, is het bepalen van welke entiteiten je systeem heeft een beetje een intellectueel proces dat enige ervaring vereist en vaak onderhevig is aan verandering, herziening, nadenken, maar het is natuurlijk geen rocket science.

Een entiteit-relatiediagram kan behoorlijk groot zijn als je eraan werkt complexe applicatie. Sommige grafieken kunnen honderden of zelfs duizenden tabellen bevatten.

Verbindingen.

De tweede stap bij het ontwerpen van een database is het kiezen van de relaties tussen de entiteiten in uw systeem. Het is nu misschien een beetje moeilijk te begrijpen, maar nogmaals, dit is geen rocket science. Met enige ervaring en heroverweging van het verrichte werk, voltooit u het volgende databasemodel op de juiste of bijna correcte manier.

Dus. Ik vertelde je over verbinding een te veel en ik zal je meer vertellen over verbindingen in latere delen van deze gids, dus daar zal ik voorlopig niet meer bij stilstaan. Onthoud alleen dat beslissen welke relaties uw entiteiten zullen hebben, een belangrijk onderdeel is. database-ontwerp en deze verbindingen worden weergegeven in het diagram entiteit relatie.

tafels

In een relationele database is informatie georganiseerd in relationele tabellen, verdeeld in rijen en kolommen, op het snijpunt waarvan gegevenswaarden staan.

Tafel - het is een regelmatige structuur die bestaat uit een eindige reeks records van hetzelfde type.

De tabel geeft het type van het echte object (entiteit) weer. Rijen komen overeen met een objectinstantie, een specifieke gebeurtenis of fenomeen. De kolommen komen overeen met de attributen (kenmerken, kenmerken, parameters) van het object, de gebeurtenis, het fenomeen. Elke tafel heeft unieke naam in de database, waarin de inhoud wordt beschreven.

Elke kolom in een tabel heeft zijn eigen naam, die meestal als kolomkop dient. Alle kolommen in dezelfde tabel moeten unieke namen hebben, maar u mag dezelfde naam geven aan kolommen in verschillende tabellen. V relationeel model Deze relatiekenmerken zijn niet geordend, d.w.z. velden zijn altijd toegankelijk op naam, niet op locatie. Echter, in SQL-taal tabelkolommen kunnen worden geïndexeerd en de kolommen worden in volgorde van links naar rechts bekeken (hun volgorde wordt bepaald wanneer de tabel wordt gemaakt).

Elke tabel heeft altijd minimaal 1 kolom. De ANSI/ISO-standaard specificeert geen maximum geldig nummer kolommen in een tabel, maar bijna alle commerciële DBMS hebben deze limiet. In Firebird is deze limiet 32.767 kolommen.

In het relationele datamodel RMDR wordt het concept van een tuple gebruikt om een ​​relatierij aan te duiden. Een tuple vertegenwoordigen op fysiek niveau is een databasetabelrij. Tabelrijen hebben geen namen en een specifieke volgorde. De tabel kan een willekeurig aantal rijen bevatten. Het is volkomen acceptabel om een ​​tabel te hebben met nul rijen. Zo'n tabel wordt leeg genoemd. Een lege tabel behoudt de structuur die wordt gedefinieerd door zijn kolommen, hij bevat alleen geen gegevens. In de regel zijn er geen beperkingen voor het aantal rijen in een tabel, en in veel DBMS wordt de grootte van tabellen alleen beperkt door vrije ruimte. schijfruimte computer. Andere DBMS hebben: maximale limiet, maar het is erg hoog - ongeveer twee miljard lijnen, en soms meer.

Laten we de structuur van een van de tabellen duidelijker illustreren trainingsbasis gegevens (zie bijlage A). Op afb. Tabel 1.1 toont de structuur van de Abonneetabel met informatie over abonnees van woningcorporaties en gemeentelijke diensten.

Rijst. 1.1. Structurele relationele tabel Abonent

Elke horizontale rij van deze tabel vertegenwoordigt een afzonderlijke fysieke entiteit - één abonnee. De twaalf rijen van de tabel vertegenwoordigen samen alle abonnees. Alle gegevens in een bepaalde regel van de tabel zijn een set attribuutwaarden van een bepaalde abonnee, die door deze regel wordt beschreven.

Elke verticale kolom van de tabel vertegenwoordigt een reeks waarden voor een bepaald kenmerk van een object. De kolom AccountCD bevat bijvoorbeeld unieke abonneerekeningnummers. De kolom Telefoon bevat telefoonnummers van abonnees.

Op het snijpunt van elke rij met elke kolom van de tabel is er precies één gegevenswaarde. In de rij die de abonnee V.S. Konyukhov vertegenwoordigt, bevat de Fio-kolom bijvoorbeeld de waarde "V.S. Konyukhov". De kolom AccountCD van dezelfde regel bevat de waarde "015527", het nummer van het persoonlijke account van de abonnee met de naam Konyukhov V.S.

Alle waarden in dezelfde kolom zijn gegevens van hetzelfde type. De Fio-kolom bevat bijvoorbeeld alleen woorden, terwijl de StreetCD-kolom gehele getallen bevat die straat-ID's vertegenwoordigen. In het relationele datamodel, de totale set van waarden waarvan werkelijke waarden voor bepaalde attributen (kolommen), heet domein. Het domein van de Fio-kolom is bijvoorbeeld de verzameling achternamen, voornamen en patroniemen (volledige namen) van abonnees. Elke kolom is altijd gedefinieerd op hetzelfde domein.

In relationele databases wordt een domein gedefinieerd door ten minste een onderliggend gegevenstype te specificeren waarnaar de domeinleden verwijzen, en vaak ook een willekeurig type. booleaanse uitdrukking toegepast op elementen van dat gegevenstype (domeinbeperkingen).

De trainingsdatabase definieert: volgende domeinen:

§ Booleaans (Booleaans): KLEIN. Velden die op dit domein zijn gedefinieerd, kunnen alleen gehele waarden hebben die gelijk zijn aan 0 of 1. Dit wordt bereikt door een controlevoorwaarde (CHECK) in het domein op te leggen op de waarden die door dit domein worden geaccepteerd.

§ Geld (Geld): NUMERIEK (15,2). Het domein is ontworpen om velden te definiëren in tabellen waarin geldbedragen zijn opgeslagen.

§ PKField (PK-veld): INTEGER. Het domein is bedoeld om de primaire en externe sleutels van tabellen te definiëren. De verplichte gegevensbeperking (NIET NULL) is niet opgelegd aan dit domein. Het wordt opgelegd wanneer de primaire sleutel van de tabel wordt gedeclareerd. Dit wordt gedaan zodat het mogelijk is om een ​​externe sleutel op dit domein te definiëren zonder de NOT NULL-voorwaarde.

§ TMaand (Maand): SMALLINT. Het domein is bedoeld voor het definiëren van velden met maandnummers in tabellen. Integer-waarden in zo'n veld kunnen in het bereik 1...12 liggen.

§ TYear (Jaar): SMALLINT. Het domein is bedoeld om velden te definiëren die het jaarnummer bevatten. Integer-waarden kunnen in het bereik 1990...2100 liggen.

Omdat rijen in een relationele tabel niet geordend zijn, kunt u een rij niet selecteren op nummer in de tabel. Er is geen "eerste", "laatste" of "dertiende" rij in de tabel. Hoe kunt u dan een specifieke lijn in de tabel specificeren, bijvoorbeeld een lijn voor een abonnee met de volledige naam Aksenov S.A.?

belangrijk element gegevens zo'n element wordt aangeroepen waarmee het mogelijk is om de waarden van andere data-elementen te bepalen.

In een relationele database heeft elke tabel 1 of meer kolommen, waarvan de waarden in alle rijen verschillend zijn. Deze kolom(men) wordt de primaire sleutel van de tabel genoemd.

hoofdsleutel - is een attribuut of groep attributen die elke rij in een tabel op unieke wijze identificeert.

Laten we terugkeren naar de overweging van de Abonent-tabel van de voorbeelddatabase (Fig. 1.1). Op het eerste gezicht kunnen zowel de AccountCD-kolom als de Fio-kolom dienen als de primaire sleutel van de Abonent-tabel. Als er echter 2 abonnees met dezelfde volledige naam zijn geregistreerd, kan de Fio-kolom niet langer de rol van primaire sleutel spelen. In de praktijk, identifiers zoals uniek nummer persoonlijke account van de abonnee (AccountCD in de tabel Abonnee), straatidentificatie (StreetCD in de tabel Straat), enz.

Als de tabel geen velden heeft waarvan de waarden uniek zijn, wordt voor het maken van een primaire sleutel meestal een extra veld ingevoerd, waarvan de waarden naar eigen goeddunken door het DBMS kunnen worden verwijderd.

Als de primaire sleutel een combinatie van kolommen is, wordt zo'n primaire sleutel genoemd composiet.

Secundaire toetsen zijn ingesteld op velden die vaak worden gebruikt bij het zoeken of sorteren van gegevens. In tegenstelling tot primaire sleutels kunnen velden voor secundaire sleutels niet-unieke waarden bevatten.

Er worden drie hoofdklassen van entiteiten gedefinieerd:

1) hengel is een zelfstandige entiteit. De namen zijn in een rechthoek geplaatst.

2) associatief Een veel-op-veel relatie tussen twee of meer entiteiten. Verenigingen worden behandeld als een volledige entiteit. Ze kunnen deelnemen aan andere verenigingen en beschikken over een aantal attributen.

A. Benamingen (die een entiteit aanduiden) zijn veel-op-een of een-op-een relaties tussen twee entiteiten. Het verschilt van het kenmerk doordat het niet afhankelijk is van de aanwijzende entiteit.

3) Kenmerk:(kenmerk) - een veel-op-een of een-op-een relatie tussen twee entiteiten. Het is een bijzonder geval van een vereniging. Het enige doel van een kenmerk is om een ​​andere entiteit te beschrijven of te verduidelijken. Het bestaan ​​van een kenmerk hangt volledig af van de entiteit die wordt gekarakteriseerd.

Een sleutel of een potentiële sleutel is slechts een set attributen, door de waarden waarvan men op unieke wijze de vereiste instantie van een entiteit kan vinden.

Minimaliteit betekent dat lexicaal, uit de set van een attribuut, het niet mogelijk is de entiteit te identificeren aan de hand van de overige.

Een van de sleutels wordt als primaire sleutel genomen en de rest wordt alternatief genoemd. Mogelijk wordt een sleutel die uit één attribuut bestaat eenvoudig genoemd. Het is niet toegestaan ​​dat de primaire sleutel van de kernentiteit geen bepaalde waarde, anders ontstaat er een tegenstrijdige situatie - een kopie van de kernentiteit die geen individualiteit heeft en bijgevolg niet bestaat, zal verschijnen. Om dezelfde redenen is het noodzakelijk om de uniciteit van de primaire sleutel te waarborgen.

Als entiteit C entiteiten A en B koppelt, moet deze externe sleutels bevatten die overeenkomen met de primaire sleutels van entiteiten A en B.

Voor elke externe sleutel moeten drie vragen worden beantwoord:

1) Kan een extra externe sleutel ongedefinieerde waarden aannemen (null-waarden), kortom, kan er een entiteitsinstantie zijn waarvoor de door de externe sleutel gespecificeerde doelentiteit bekend is.

2) Wat moet er gebeuren als u probeert de doelentiteit waarnaar wordt verwezen door de externe sleutel te verwijderen.

Er zijn drie mogelijke oplossingen dit onderwerp:

Cascadering

Beperking

Instellen op een specifieke waarde

3) Wat moet er gebeuren bij het bijwerken van de primaire sleutel van een doelentiteit waarnaar wordt verwezen door een externe sleutel.

Voor elke externe sleutel in een databaseontwerp is het dus noodzakelijk om niet alleen het veld of de combinatie van velden waaruit deze externe sleutel bestaat, te specialiseren, maar ook de antwoorden op de bovenstaande vragen.

Gegevenstypen en domeinen.

Het relationele datamodel kenmerkt zich door een eenvoudige datastructuur en gebruiksvriendelijke presentatie.

Het relationele model is ontworpen om gegevens te ordenen in de vorm van tweedimensionale tabellen. De relationele tabel is tweedimensionale array en heeft de volgende eigenschappen::

1) Elk element van de tabel is één gegevenselement

2) Alle kolommen in een tabel zijn homogeen - alle elementen in een kolom hebben hetzelfde gegevenstype en dezelfde lengte

3) Elke kolom heeft een unieke naam

4) Er zijn geen identieke rijen in de tabel

5) De volgorde van de rij kolommen kan willekeurig zijn

Gegevenstypen

Alle gegevens die bij het programmeren worden gebruikt, hebben hun eigen gegevenstypen. Het relationele model vereist dat de gebruikte datatypes eenvoudig zijn.

Over het algemeen vallen gegevenstypen in drie groepen uiteen:

1) Eenvoudige gegevenstypen

2) Gestructureerde typen gegevens

3) referentiegegevenstypen:

Eenvoudige (atomaire) datatypes hebben geen interne structuur. Dit type gegevens wordt scalair genoemd. Deze omvatten logische, numerieke, string-gegevenstypen. Het concept van atomiciteit is nogal relatief. Dus, snaartype gegevens kunnen worden bekeken als: eendimensionale matrix karakters, en hele type gegevens als een set bits. Het enige belangrijke hier is dat bij het overschakelen naar dergelijke laag niveau semantiek gaat verloren, dat wil zeggen, de betekenis van de gegevens.

Het structureren van gegevenstypen is bedoeld om complexe gegevensstructuren te definiëren die zijn opgebouwd uit samenstellende elementen, die op hun beurt een interne structuur kunnen hebben (arrays, records, structuren).

Het referentiegegevenstype is bedoeld om de mogelijkheid te bieden om naar andere gegevens te verwijzen. Dit gegevenstype is bedoeld voor proceduretalen die geheugengebieden hebben voor het opslaan van gegevens.

Voor een relationeel datamodel is het type data dat wordt gebruikt niet zo belangrijk. De eis dat het gegevenstype eenvoudig moet zijn, moet zo worden begrepen dat relationele bewerkingen geen rekening hoeven te houden met de interne structuur van de gegevens.

Domein porno.ru

In het relationele datamodel is het concept van een datatype nauw verwant aan het concept van een domein, dat kan worden gezien als een verfijning van een datatype.

domein - semantisch begrip. Het kan worden gezien als een subset van waarden van een bepaald gegevenstype.

Domeineigenschappen:

1) het domein heeft een unieke naam binnen de database

2) het domein is gedefinieerd op sommige eenvoudig type data of op een ander domein

3) een domein kan een logische voorwaarde hebben die het mogelijk maakt een subset van gegevens te beschrijven die geldig is voor een bepaald domein.

4) het domein draagt ​​een semantische lading

Een bepaald domein D, wat 'leeftijd van de werknemer' betekent, kan bijvoorbeeld worden beschreven als een deelverzameling van de reeks natuurlijke getallen

D=(nϵN: n 18 en n ≤ 60)

Het verschil tussen het domein van het concept van een deelverzameling ligt juist in het feit dat het domein de semantiek van een bepaalde gebied. Er kunnen verschillende domeinen zijn die overeenkomen als een subset, maar verschillende betekenissen hebben. De domeinen "deelgewicht" en "beschikbare hoeveelheid" kunnen bijvoorbeeld op dezelfde manier worden beschreven als een reeks niet-negatieve gehele getallen, maar de betekenis van deze domeinen zal anders zijn en het zullen verschillende domeinen zijn. De belangrijkste betekenis van een domein is dat domeinen vergelijkingen beperken. Het is logisch niet correct om waarden van verschillende domeinen te vergelijken, ook al zijn ze van hetzelfde type. Het is syntactisch correct om een ​​lijst te retourneren van alle onderdelen waarvan het onderdeelgewicht groter is dan de beschikbare hoeveelheid die niet overeenkomt met de betekenis van de begrippen hoeveelheid en gewicht.

5. Relaties en hun eigenschappen, attributen en tupels.
Het concept van relatie is een fundamenteel concept van het relationele datamodel. Relatiekenmerk:<Имя_атрибута: Имя_домена>. Attribuutnamen moeten uniek zijn binnen een relatie. Vaak zijn de attribuutnamen hetzelfde als de bijbehorende domeinnamen. Een relatie R gedefinieerd op de verzameling domeinen D 1 , D 2 ,… D n bestaat uit twee delen: een header en een body. De relatiekop bevat een vast aantal relatieattributen.

(,,…)

Het lichaam van een relatie bevat een reeks relatie-tupels. Elk tupel van relaties is een set paren van de vorm

<Имя_атрибута: Значение_атрибута>

(,,… ).

De waarde Val i hoort bij het attribuut A i Di. waarde is geschreven:

R( ,,…).

Het aantal attributen in een relatie wordt de graad of ariteit van de relatie genoemd. Het aantal tupels van een relatie wordt de kardinaliteit van de relatie genoemd. De kop van de relatie beschrijft het cartesiaanse product van domeinen waarop de relatie is gedefinieerd. De titel is statisch. Het verandert niet tijdens het werken met de database. Als attributen worden gewijzigd, toegevoegd of verwijderd uit een relatie, is het resultaat een andere relatie. Het lichaam van de relatie is een verzameling cartages, dat wil zeggen een subset van het cartesiaanse product van domeinen, en is een relatie in de wiskundige zin van het woord. De hoofdtekst van een relatie kan veranderen tijdens het werken met de database, dat wil zeggen, tupels kunnen veranderen, worden toegevoegd, enzovoort.

Een relationele database is een verzameling relaties. Een relationeel databaseschema is een set relatieheaders die in een database zijn opgenomen.

Hoewel elke relatie kan worden weergegeven als een tabel, is de relatie geen tabel. Dit zijn nauwe maar niet corresponderende concepten. De termen waarop het relationele gegevensmodel werkt, hebben overeenkomstige "tabel"-synoniemen.

Relatie eigenschappen

Relatie-eigenschappen zijn de belangrijkste verschillen tussen relaties.

1) Met betrekking tot niet-identieke kaarten.

Het lichaam van een relatie is een set van cartages en kan, zoals elke set, geen niet te onderscheiden elementen bevatten. Tabellen kunnen, in tegenstelling tot relaties, identieke rijen bevatten.

2) Carteges worden niet geordend (van boven naar beneden) omdat de relatie-body een set is.

Dezelfde relatie kan niet worden afgebeeld verschillende tafels, waarin de regels gaan naar andere volgorde:

3) Attributen zijn niet van links naar rechts geordend. Aangezien elk attribuut een unieke naam heeft binnen een relatie, maakt de volgorde van de attributen niet uit. Dezelfde relatie kan worden weergegeven door verschillende tabellen waarin de kolommen in een andere volgorde staan.

4) Alle attribuutwaarden zijn atomair.

Uit de relatie-eigenschappen volgt dat niet elke tabel relaties kan definiëren. Om dit te doen, moet ze hebben eenvoudige structuur, niet bevatten identieke lijnen, moet elk van de kolommen gegevens van slechts één type bevatten en moeten alle gebruikte gegevenstypen eenvoudig zijn.

Probleem logisch ontwerp relationele database datamining bestaat uit het nemen van een weloverwogen beslissing over uit welke relaties de database moet bestaan ​​en welke attributen die relaties moeten hebben.

Het relationele datamodel vangt twee Basis benodigdheden integriteit die in een relationeel DBMS moet worden ondersteund.

1) De vereiste van entiteitsintegriteit, dat wil zeggen dat elke tuple van een relatie te onderscheiden moet zijn van elke andere tuple van deze relatie, dat wil zeggen dat elke relatie een primaire sleutel moet bevatten.

2) De eis van referentiële integriteit (foreign key integrity-vereiste) is dat voor elke referentiële sleutelwaarde in de relatie waarnaar wordt verwezen, . Er moet een tuple zijn met dezelfde waarde voor de primaire sleutel, of de waarde van de externe sleutel moet null zijn.

Dit zijn elektronische opslagplaatsen van informatie, waartoe de toegang wordt uitgevoerd met behulp van een of meer computers. Meestal worden databases gemaakt om gegevens op te slaan en te openen die informatie bevatten over een bepaald vakgebied, dat wil zeggen een bepaald gebied van menselijke activiteit of een deel van de echte wereld.

DBMS is software voor het maken, vullen, bijwerken en verwijderen van een database.

De eenheid van informatie die in de database is opgeslagen, is een tabel. Elke tabel is een verzameling rijen en kolommen, waarbij de rijen overeenkomen met een objectinstantie, een specifieke gebeurtenis of fenomeen, en de kolommen overeenkomen met de attributen (kenmerken, kenmerken, parameters) van het object, de gebeurtenis of het fenomeen. Elke rij bevat informatie over een specifieke gebeurtenis.

In databasetermen worden de kolommen van een tabel velden genoemd en de rijen records.

Er kunnen relaties bestaan ​​tussen afzonderlijke databasetabellen, dat wil zeggen dat informatie in de vorige tabel kan worden toegevoegd aan een andere. Databases, tussen aparte tabellen waarvan er koppelingen zijn, worden relationeel genoemd. Dezelfde tabel kan master zijn van de ene databasetabel en kind van een andere.

Relatietabellen werken samen in een hoofd-kindrelatie. Dezelfde tabel kan de master zijn van de ene databasetabel en het kind van een andere.

Een voorwerp is iets dat bestaat en is te onderscheiden, met een reeks eigenschappen. Het verschil tussen het ene object en het andere object wordt bepaald door specifieke eigenschapswaarden.

Essence - reflectie van een object in het geheugen van een persoon of een computer.

Attribuut - een specifieke waarde van een van de eigenschappen van de entiteit.

Veld is een enkelvoudig invoerelement dat een bepaalde attribuutwaarde opslaat.

Communicatie veld: – is het veld waarmee twee tabellen zijn gerelateerd.

Primaire en secundaire sleutels

Elke databasetabel kan een primaire sleutel hebben - dit is een veld of een reeks velden die een record op unieke wijze identificeert.

De waarde van de primaire sleutel in de databasetabel moet uniek zijn, dat wil zeggen dat er geen twee of meer records in de tabel mogen zijn met dezelfde primaire sleutelwaarde.

Primaire sleutels maken het gemakkelijk om relaties tussen tabellen tot stand te brengen. Omdat de primaire sleutel uniek moet zijn, kunnen niet alle velden in de tabel ervoor worden gebruikt.

Als de tabel geen velden heeft waarvan de waarden uniek zijn, wordt er voor het maken van een primaire sleutel meestal een extra numeriek veld ingevoegd, over de waarden waarover het DBMS naar eigen goeddunken kan beschikken.

Secundaire sleutels worden per veld ingesteld, dat vaak wordt gebruikt bij het zoeken of sorteren van gegevens: indexen die zijn gebouwd op secundaire sleutels helpen het systeem de benodigde waarden die in de overeenkomstige velden zijn opgeslagen veel sneller te vinden.

In tegenstelling tot primaire sleutels kunnen velden voor secundaire sleutels niet-unieke informatie bevatten.

Relationele relaties tussen tabellen

Een op een. Er is sprake van een één-op-één-relatie wanneer één record in de bovenliggende tabel overeenkomt met één record in de onderliggende tabel.

Deze relatie komt veel minder vaak voor dan de een-op-veel-relatie en wordt gebruikt als u niet wilt dat de databasetabel uit de secundaire tabel opzwelt. Een één-op-één relatie resulteert in een read gerelateerde informatie in verschillende tabellen moet u verschillende leesbewerkingen uitvoeren, wat de ontvangst van de benodigde informatie vertraagt. Bovendien kunnen databases die tabellen bevatten met een één-op-één-relatie niet als volledig genormaliseerd worden beschouwd.

Net als een één-op-veel-relatie kan een één-op-één-relatie rigide of niet-rigide zijn.

Een primaire sleutel is een uniek kenmerk voor elk record in een tabel. Access ondersteunt twee typen primaire sleutels: enkelvoudig en samengesteld.

Vorm eenvoudige sleutel een van de reeds bestaande velden van de tabel kan optreden, als er geen lege en dubbele waarden in dit veld staan. Voorbeelden van dergelijke velden kunnen machinenummers, inventarisnummers, identificatiecodes zijn. Een samengestelde sleutel is opgebouwd als een combinatie van twee of meer gegevenselementen. Voor de tabel Medewerkers is het bijvoorbeeld theoretisch mogelijk om een ​​combinatie van twee velden, Achternaam en Voornaam, als primaire sleutel te gebruiken. Het is echter goed mogelijk dat er een andere medewerker in het bedrijf verschijnt met dezelfde voor- en achternaam als iemand die al in dienst is.

Het is duidelijk dat er nogal strenge eisen worden gesteld aan het veld (velden) dat claimt de primaire sleutel te zijn. Daarom is het gebruikelijk om een ​​speciaal veld te maken van een identificatieveld dat de functies van een sleutel vervult (bijvoorbeeld klantcode, bestelcode). Met de toevoeging van elk nieuw record in de tabel in dit veld is ingevuld speciale betekenis(meestal numeriek) die de invoer op unieke wijze identificeert. V Toegang tot applicatie dergelijke nummering kan worden georganiseerd dankzij het gegevenstype Teller, dat een nummer toewijst aan elk nieuw record, waardoor een reeks getallen wordt gegenereerd met een stap van 1 (of willekeurig).

Er zijn basisregels die worden geaccepteerd voor sleutels in Access:

Voor het gemak wordt het sleutelveld meestal als eerste vermeld in de tabelstructuur;

Als de tabel een primaire sleutel heeft, Toegang tot programma blokkeert automatisch de invoer van dubbele waarden in dit veld, of null-waarden(leeg);

Access sorteert tabelrecords automatisch op primaire sleutel;

Het primaire sleutelveld is een index die het sorteren en zoeken naar records versnelt.

Ga als volgt te werk om een ​​tabel in te stellen op een primaire sleutel en deze te voltooien in de ontwerpweergave:

Selecteer in de ontwerpmodus het veld dat de rol van de primaire sleutel zal spelen;

Klik op de knop Sleutelveld op de Table Builder-werkbalk of selecteer de hoofdmenuopdracht Bewerken - Sleutelveld (er verschijnt een sleutelsymbool naast de naam van het geselecteerde veld);

Na het specificeren van sleutelveld de tabel moet worden opgeslagen, waarvoor u op de knop Opslaan op de werkbalk van de tabelontwerper moet klikken en in het geopende venster de naam van de tabel moet invoeren en op de knop OK moet klikken.

Als de primaire sleutel niet is gedefinieerd, verschijnt er een waarschuwing wanneer u de ontwerpmodus verlaat en wordt u gevraagd een sleutelveld te maken voordat de tabel wordt gesloten.

17. Soorten verbindingen en hun implementatie. Referentiële integriteit en de handhaving ervan.

In een relationele database vermijden relaties gegevensredundantie. Als u bijvoorbeeld een database maakt die informatie over boeken bevat, krijgt u mogelijk een tabel met de naam 'Boeken' waarin de details van elk boek zijn opgeslagen, zoals de titel, publicatiedatum en uitgever. Daarnaast zijn er Extra informatie informatie over de uitgever die u mogelijk wilt behouden, zoals het telefoonnummer, adres en postcode. Bewaar je ze in een tabel met boeken, dan wordt het telefoonnummer van de uitgever herhaald voor elk door hem uitgegeven boek.

Een meer correcte optie is om informatie over uitgevers in een aparte tabel "Uitgevers" te plaatsen. In dit geval bevat de tabel "Boeken" koppelingen naar de records van de tabel "Uitgevers".

Om de synchronisatie te behouden, moet de gegevensintegriteit worden gehandhaafd tussen de tabellen Boeken en Uitgevers. Relaties met gegevensintegriteit zorgen ervoor dat gegevens in de ene tabel overeenkomen met gegevens in een andere. Elk boek in de tabel Boeken is bijvoorbeeld gekoppeld aan een specifieke uitgever in de tabel Uitgevers. U kunt geen boek toevoegen aan een tabel voor een uitgever die niet in de database staat.

Soorten relaties tussen tabellen

Communicatie vindt plaats door gegevens in sleutelkolommen te matchen; meestal zijn dit kolommen die in beide tabellen dezelfde naam hebben. In de meeste gevallen wordt de primaire sleutel van de ene tabel, die een unieke id voor elke rij bevat, toegewezen aan de externe sleutel van een andere tabel. Elk van de titels op de markt kan bijvoorbeeld worden gekoppeld aan de verkoopvolumes door een kolom "Edition_ID" te maken in de tabel Boeken (primaire sleutel) en een kolom "Edition_ID" in de tabel "Sales" (buitenlandse sleutel).

Er zijn drie soorten relaties tussen tabellen. Het type relatie dat wordt gemaakt, hangt af van hoe de bijbehorende kolommen zijn gedefinieerd.

Een-op-veel relaties

Een een-op-veel-relatie is de meest voorkomende relatie. Met zo'n relatie kan elke rij van tabel A overeenkomen met veel rijen van tabel B, maar elke rij van tabel B kan overeenkomen met slechts één rij van tabel A. Er wordt bijvoorbeeld een één-op-veel-relatie tot stand gebracht tussen de tabellen "Uitgevers" en "Boeken": elk van de uitgevers kan veel boeken uitgeven, maar elk boek wordt door slechts één uitgever uitgegeven.

Er wordt een één-op-veel-relatie gemaakt wanneer slechts één van de gekoppelde kolommen een unieke beperking heeft of de primaire sleutel is.

In Microsoft Access wordt de zijde van een een-op-veel-relatie waarmee de primaire sleutel overeenkomt, aangeduid met het sleutelsymbool. De kant van de relatie waarmee de refererende sleutel overeenkomt, wordt aangegeven met het oneindigheidsteken.

Veel-op-veel relaties

Bij het tot stand brengen van een veel-op-veel-relatie kan elke rij van tabel A overeenkomen met vele rijen van tabel B en vice versa. Een dergelijke relatie wordt gemaakt met behulp van een derde tabel, een join genaamd, waarvan de primaire sleutel bestaat uit externe sleutels die zijn gekoppeld aan de tabellen A en B. Er wordt bijvoorbeeld een veel-op-veel-relatie tot stand gebracht tussen de tabellen "Auteurs" en "Boeken" met behulp van relaties een een-op-veel-relatie tussen elk van deze tabellen en de BookAuthors-tabel. De primaire sleutel van de tabel BookAuthors is een combinatie van de kolommen AuthorID (de primaire sleutel van de tabel Auteurs) en BookID (de primaire sleutel van de tabel Titels).

Een-op-een relaties

Bij het tot stand brengen van een één-op-één-relatie kan elke rij van tabel A overeenkomen met slechts één rij van tabel B en vice versa. Er wordt een één-op-één-relatie gemaakt wanneer beide gerelateerde kolommen primaire sleutels zijn of unieke beperkingen hebben.

Dit soort relaties wordt zelden gebruikt, omdat in een dergelijke situatie de gerelateerde gegevens meestal in dezelfde tabel kunnen worden opgeslagen. U kunt in de volgende gevallen gebruik maken van een één-op-één relatie.

Een tabel splitsen die te veel kolommen bevat.

Om een ​​deel van de tabel te isoleren om veiligheidsredenen.

Om gegevens over kortdurend gebruik op te slaan, is de eenvoudigste manier om deze te verwijderen, de tabel leeg te maken.

Voor het opslaan van gegevens die alleen relevant zijn voor een subset van de hoofdtabel.

In Microsoft Access wordt de zijde van een één-op-één-relatie waarmee de primaire sleutel overeenkomt, aangeduid met een sleutelsymbool. De zijde van de relatie waarmee de refererende sleutel correspondeert, wordt ook aangegeven door het sleutelsymbool.

Relaties tussen tabellen maken

Bij het leggen van een relatie tussen tabellen hoeven gerelateerde velden niet dezelfde naam te hebben. Ze moeten echter hetzelfde gegevenstype hebben, tenzij het veld dat de primaire sleutel is van het type "Teller" is. Een veld van het type "Teller" kan alleen worden gekoppeld aan een veld van het type "Numeriek" als de eigenschap FieldSize (veldgrootte) van elk van hen op dezelfde waarde is ingesteld. U kunt bijvoorbeeld kolommen van het type Count en Numeric koppelen als de eigenschap FieldSize van elk is ingesteld op Long Integer. Zelfs als beide gekoppelde kolommen van het type Numeriek zijn, moet de waarde van de eigenschap FieldSize voor beide velden hetzelfde zijn.