De eenvoudigste functionele afhankelijkheden. Functionele afhankelijkheden

Normale formulierenmethode

Docent

Volledige naam	Zou moeten	Salaris	Ervaring	Nadb	Kaf	Onderwerp	Groep	VidZan
Ivanov I.M.	Ds.					DBMS		Laboratorium
Ivanov I.M.	Ds.					Informeer		Laboratorium
Petrov M.I.	Senior leraar					DBMS		Lezing
Petrov M.I.	Senior leraar					Grafisch		Laboratorium
Sidorov N.G.	Ds.					Informeer		Lezing
Sidorov N.G.	Ds.					Grafisch		Lezing
Egorov V.V.	Ds.					PC		Lezing

Rijst. 6.4. Uitgangshouding LERAAR

Impliciete redundantie uit zich in dezelfde salarissen voor alle leraren en in dezelfde salarisbonussen voor dezelfde diensttijd. Als het salaris verandert van 500 wrijven. tot 510 roebel, dan moet deze waarde voor alle leraren worden gewijzigd. Als Sidorov wordt weggelaten, wordt de database inconsistent. Dit is een voorbeeld van een anomalie bij het bewerken van relaties met impliciete redundantie.

Het elimineren van overtolligheid bestaat uit het normaliseren van relaties.

De normale vormmethode is een klassieke methode voor het ontwerpen van relationele databases. Het is gebaseerd op het fundamentele concept van afhankelijkheid tussen attributen van een relatie.

Kenmerk B functioneel afhankelijk van attribuut A, als elke waarde van A overeenkomt met precies één waarde van B. Wiskundig gezien wordt de functionele afhankelijkheid van B van A aangegeven met de notatie A ® B. Dit betekent dat in alle tupels met dezelfde waarde van attribuut a, ATTRIBUTE B ZAL OOK DEZELFDE WAARDE HEBBEN. Attributen A en B kunnen samengesteld zijn en uit twee of meer attributen bestaan. Met betrekking tot Leraar zijn de functionele afhankelijkheden als volgt: Volledige naam ® Afdeling, Volledige naam ® Plicht, Plicht ® Salaris, etc.

Functionele onderlinge afhankelijkheid. Als er een functionele afhankelijkheid is van de vorm A ® B en B ® A, dan is er tussen A en B een één-op-één correspondentie, of functionele onderlinge afhankelijkheid. Wiskundig gezien wordt onderlinge afhankelijkheid aangeduid als A "B of B" A.

Voorbeeld. Het N-attribuut (paspoortserie en nummer) is functioneel afhankelijk van het volledige naamattribuut (achternaam, voornaam en patroniem), als wordt aangenomen dat de situatie van volledig samenvallen van achternamen, voornamen en patroniemen van twee personen is uitgesloten .

Gedeeltelijke functionele afhankelijkheid De afhankelijkheid van een niet-sleutelattribuut van een deel van een samengestelde sleutel wordt genoemd. In de Teacher-relatie is de sleutel samengesteld en bestaat uit de attributen Volledige naam, Onderwerp en Groep. Alle niet-sleutelattributen zijn functioneel afhankelijk van de sleutel, met verschillende mate van afhankelijkheid. Het Position-attribuut is bijvoorbeeld functioneel afhankelijk van het Full Name-attribuut, dat deel uitmaakt van de sleutel, d.w.z. is gedeeltelijk afhankelijk van de sleutel.

Volledige functionele afhankelijkheid – De afhankelijkheid van een niet-sleutelattribuut van de gehele samengestelde sleutel. Het ViewZan-attribuut is bijvoorbeeld volledig functioneel afhankelijk van de samengestelde sleutel.

Attribuut C is afhankelijk van attribuut A transitief (bestaat transitieve afhankelijkheid ), als voor de attributen A, B, C aan de voorwaarden A ® B en B ® C is voldaan, maar er geen omgekeerde relatie bestaat. In het voorbeeld zijn de attributen verbonden door een transitieve afhankelijkheid:

Volledige naam ® Functietitel ® Salaris

Met betrekking tot R, attribuut B hangt veel af van attribuut A als elke waarde van A overeenkomt met een reeks waarden van B die niet zijn gekoppeld aan andere attributen van R. Meerwaardige afhankelijkheden kunnen één-op-veel (1:M), veel-op-één (M) zijn :1) of veel-op-een tot veel” (M:M), respectievelijk aangeduid met: A Þ B, A Ü B en A Û B.

In het beschouwde voorbeeld is er een meerwaardige M:M-relatie tussen de attributen Volledige naam Û Vak (één leraar kan meerdere vakken geven en één vak kan door meerdere docenten worden gegeven).

Omdat de afhankelijkheid tussen attributen de oorzaak is van afwijkingen, proberen ze dergelijke relaties in verschillende relaties te verdelen. Als resultaat wordt een reeks gerelateerde relaties (tabellen) met verbindingen in de vorm 1:1, 1:M, M:1 en M:M gevormd. Relaties tussen tabellen weerspiegelen de afhankelijkheden tussen attributen van verschillende relaties.

Onderling onafhankelijke kenmerken. Er wordt gezegd dat twee of meer attributen onderling onafhankelijk zijn als geen van de attributen functioneel afhankelijk is van de andere attributen. Wiskundig gezien wordt de afwezigheid van afhankelijkheid van attribuut A van attribuut B aangeduid als A Ø® B. Als A Ø® B en B Ø® A plaatsvinden, wordt de wederzijdse onafhankelijkheid aangeduid als A Ø = B.

Afhankelijkheden tussen attributen identificeren. Het identificeren van afhankelijkheden tussen attributen is noodzakelijk om databaseontwerp uit te voeren met behulp van de normale formulierenmethode.

Voorbeeld. Laat een relatie R gegeven worden met een schema R(A1, A2, A3) van de vorm:

A1	A2	A3

Het is a priori bekend dat er functionele afhankelijkheden zijn:

A1®A2 en A2®A3.

Uit de analyse blijkt dat er ook afhankelijkheden zijn in de relatie:

A1®A3, A1A2®A3, A1A2A3®A1A2, A1A2®A2A3, enz.

In de relatie is er geen functionele afhankelijkheid van attribuut A1 van attribuut A2 en van attribuut A3, d.w.z.

A2 Ø® A1, A3 Ø® A1.

De afwezigheid van afhankelijkheid van A1 van A2 wordt verklaard door het feit dat dezelfde waarde van attribuut A2 (21) overeenkomt met verschillende waarden van attribuut A1 (12 en 17).

Alle bestaande functionele afhankelijkheden in een relatie zijn dat ook volledige set functionele afhankelijkheden , wat we aangeven met F + . De volledige reeks functionele afhankelijkheden kan worden afgeleid op basis van acht gevolgtrekkingsaxioma's: reflectiviteit, voltooiing, transitiviteit, uitbreiding, voortzetting, pseudotransitiviteit, vereniging en ontbinding.

Voor de relatie Leraar kunt u de volgende functionele afhankelijkheden afleiden:

Volledige naam ® Salaris

Volledige naam ® Plicht

Volledige naam ® Ervaring

Volledige naam ® Nadb

Volledige naam ® Kaf

Ervaring® Nadb

Schuld® Salaris

Salaris® Duty

Volledige naam Onderwerp Group® Salaris

Rijst. 6.5. Afhankelijkheden tussen attributen.

Er wordt aangenomen dat één leraar in één groep één type les kan geven (colleges of laboratoriumwerk). Volledige naam – uniek. Er is een afhankelijkheid Volledige Naam ® Ervaring, maar de omgekeerde bewering is niet waar, omdat Verschillende leraren hebben dezelfde ervaring. Wat betreft andere afhankelijkheden is de redenering vergelijkbaar. Er ontstaat een één-op-één relatie tussen functie en salaris.

Eén leraar in één groep in verschillende vakken kan verschillende soorten lessen geven. De definitie van het soort beroep gaat gepaard met de aanduiding van de volledige naam, het onderwerp en de groep. Petrov M.I. in de 256e groep geeft hij lezingen en laboratoriumlessen, maar geeft hij ook lezingen over DBMS en laboratoriumwerk over graphics.

De afhankelijkheden tussen de attributen Naam, Onderwerp en Groep worden niet weergegeven, omdat ze vormen een samengestelde sleutel en worden niet in aanmerking genomen in het normalisatieproces van de relatie (tabel).

Normale vormen. Het proces van het ontwerpen van databases met behulp van normale vormen is iteratief en bestaat uit het sequentieel overbrengen van relaties van de eerste normaalvorm naar normaalvormen van hogere orde. Elk volgend formulier beperkt een bepaald type functionele afhankelijkheid, elimineert corresponderende afwijkingen bij het uitvoeren van bewerkingen op databaserelaties en behoudt de eigenschappen van eerdere formulieren.

De volgende reeks normaalvormen wordt onderscheiden:

° Eerste normaalvorm (1NF);

° Tweede normaalvorm (2NF);

° Derde normaalvorm (3NF);

° Versterkte derde normaalvorm, of Boyce-Codd normaalvorm (BCNF);

° Vierde normaalvorm (4NF);

° Vijfde normaalvorm (5NF).

Eerste normaalvorm Een relatie is in 1NF als alle attributen eenvoudig zijn (een enkele waarde hebben). De oorspronkelijke relatie is zo opgebouwd dat deze in 1NF staat.

De transformatie van een relatie naar de volgende normaalvorm wordt uitgevoerd met behulp van de ‘lossless decomposition’-methode, d.w.z. zoekopdrachten (gegevensbemonstering per voorwaarde) naar de oorspronkelijke relatie en naar de relaties verkregen als resultaat van decompositie moeten hetzelfde resultaat opleveren.

De belangrijkste bewerking van de ontledingsmethode is de projectiebewerking.

Voorbeeld. Laat de relatie R(A,B,C,D,E,...) een functionele afhankelijkheid C ® D hebben. Ontleding van de relatie R in twee nieuwe relaties R1(A, B,C,E,...) en R2(C,D) zal de functionele afhankelijkheid van de attributen elimineren en de relatie R overbrengen naar de volgende normaalvorm. Relatie R2 is een projectie van relatie R op attributen C en D.

De oorspronkelijke relatie Leraar heeft een samengestelde sleutel Volledige naam, onderwerp, groep en zit in 1NF. De attributen Ervaring, Nadb, Caf, Plicht, Salaris zijn functioneel afhankelijk van een deel van de samengestelde sleutel: het attribuut Volledige naam. Deze gedeeltelijke afhankelijkheid leidt tot expliciete en impliciete gegevensredundantie, wat problemen veroorzaakt bij het bewerken van gegevens. Een deel van de redundantie wordt geëlimineerd door de relatie naar 2NF om te zetten.

Tweede normaalvorm. Een relatie is in 2NF als deze in 1NF is en elk niet-sleutelattribuut volledig functioneel afhankelijk is van de primaire sleutel (samengesteld).

Om gedeeltelijke afhankelijkheid te elimineren, is het noodzakelijk om de projectiebewerking te gebruiken, waarbij de oorspronkelijke relatie als volgt in verschillende relaties wordt uitgebreid:

° Construeer een projectie zonder attributen die gedeeltelijk afhankelijk zijn van de primaire sleutel;

° Construeer projecties op delen van een samengestelde primaire sleutel en attributen die van deze delen afhankelijk zijn.

Laten we de Leraarrelatie vertalen naar 2NF. Als resultaat verkrijgen we twee relaties R1 en R2.

Volledige naam	Onderwerp	Groep	VidZan
Ivanov I.M.	DBMS		Laboratorium
Ivanov I.M.	Informeer		Laboratorium
Petrov M.I.	DBMS		Lezing
Petrov M.I.	Grafisch		Laboratorium
Sidorov N.G.	Informeer		Lezing
Sidorov N.G.	Grafisch		Lezing
Egorov V.V.	PC		Lezing

Rijst. 6.6. Databaserelaties LERAREN in 2 SF

In relatie R1 is de primaire sleutel samengesteld Volledige naam, onderwerp, groep, met betrekking tot R2 is de sleutel Volledige naam Als gevolg hiervan wordt een duidelijke redundantie van gegevens over leraren geëlimineerd. Er is nog steeds sprake van impliciete duplicatie van gegevens in R2.

Voor verdere verbetering zullen we de relaties omzetten naar 3NF.

Een relationele database bevat zowel structurele als semantische informatie. De structuur van een database wordt bepaald door het aantal en het type relaties die het bevat, en de één-op-veel-relaties die bestaan tussen de tupels van deze relaties. Het semantische deel beschrijft de reeks functionele afhankelijkheden die bestaan tussen de attributen van deze relaties. Laten we functionele afhankelijkheid definiëren.

Definitie: Als twee attributen X en Y van een bepaalde relatie worden gegeven, dan wordt gezegd dat Y functioneel afhankelijk is van X als op enig moment elke waarde van X overeenkomt met precies één waarde van Y. De functionele afhankelijkheid wordt aangegeven met X -> Y. Merk op dat X en Y niet alleen afzonderlijke attributen kunnen vertegenwoordigen, maar ook groepen die bestaan uit verschillende attributen van één relatie. We kunnen zeggen dat functionele afhankelijkheden één-op-veel-relaties zijn die binnen een relatie bestaan.

2e normale vorm (2NF) relatie. Bepaling van volledige functionele afhankelijkheid en 2NF.

Kenmerken van relaties in 2NF. Algoritme voor reductie tot 2NF. De stelling van Heath. Voorbeelden.Concept

volledige functionele afhankelijkheid. Definitie: niet-sleutelattribuut volledig functioneel afhankelijk

Definitie: van een samengestelde sleutel als deze functioneel afhankelijk is van de gehele sleutel als geheel, maar niet functioneel afhankelijk is van de samenstellende attributen ervan. overmatige functionele afhankelijkheid

- een afhankelijkheid die informatie bevat die kan worden verkregen op basis van andere in de database beschikbare afhankelijkheden.

2NF - tweede normaalvorm. Definitie van de tweede normaalvorm: er is een relatie 2NF

, als het zich in 1NF bevindt en elk niet-sleutelattribuut functioneel volledig afhankelijk is van de sleutel.

Een databaseschema dat geen redundante functionele afhankelijkheden heeft, wordt als correct beschouwd. Anders moet je je toevlucht nemen tot de procedure van ontbinding (ontleding) van de bestaande reeks relaties. In dit geval bevat de gegenereerde set een groter aantal relaties, die projecties zijn van de relaties van de originele set. (De projectiebewerking wordt beschreven in het gedeelte over relationele algebra.) Het omkeerbare, stapsgewijze proces van het vervangen van een gegeven reeks relaties door een ander schema, waarbij overtollige functionele afhankelijkheden worden geëlimineerd, wordt normalisatie genoemd.

De omkeerbaarheidsvoorwaarde vereist dat de ontleding de gelijkwaardigheid van circuits behoudt wanneer het ene circuit door het andere wordt vervangen, d.w.z. in de resulterende relaties:

1) eerder ontbrekende tupels mogen niet verschijnen;

2) de relaties van het nieuwe schema moeten voldoen aan de oorspronkelijke reeks functionele afhankelijkheden.

De stelling van Heath

Laat de relatie gegeven worden. Als R

3e normaalvorm (3NF) relatie.

Definitie van transitieve afhankelijkheid en 3NF. Algoritme voor reductie tot 3NF Boyce-Codd Normal Form (BCNF). Kenmerken van relaties in 3NF en in NFBC. Voorbeelden.

Functionele afhankelijkheid.

Een attribuut B is functioneel afhankelijk van een attribuut A als één waarde van A precies één waarde van B bepaalt. Als voor een gegeven relatie alle attributen functioneel afhankelijk zijn van één attribuut, dan is dit attribuut dat ook potentiële eenvoudige sleutel,

als de waarden binnen de relatie uniek zijn. Eén van de potentiële sleutels wordt aangewezen als relatiesleutel. In een relatie is het soms mogelijk om een set van verschillende attributen te identificeren waarvan alle andere attributen functioneel afhankelijk zijn. Als de waarden ervan uniek zijn in het aggregaat binnen een relatie, dan is dit aggregaat dat ook ,

superkey relatie Als attribuut B functioneel afhankelijk is van een supersleutel, maar er geen functionele afhankelijkheid is van enige subset van de supersleutel, dan volledige functionele afhankelijkheid

Binnen van de superkey. Als alle attributen van één relatie functioneel afhankelijk zijn van een bepaalde supersleutel, maar er geen functionele afhankelijkheid is van een subset van die supersleutel, dan is de supersleutel .

potentiële sleutel Samengestelde sleutel

relaties worden geselecteerd uit potentiële sleutels. Houd er rekening mee dat de termijn functionele afhankelijkheid komt overeen met het concept van functie in de wiskunde. Als niet-sleutel

het attribuut afhankelijk is van de gehele samengestelde sleutel en niet van de onderdelen ervan, dan spreken ze van de volledige functionele afhankelijkheid van het attribuut van de samengestelde sleutel.

Als attribuut A afhankelijk is van attribuut B, en B afhankelijk is van attribuut C, maar er geen omgekeerde afhankelijkheid is, dan wordt gezegd dat attribuut C transitief afhankelijk is van A.

Soorten relaties in relationele databases

Records van verschillende databaserelaties zijn feitelijk aan elkaar gekoppeld, maar het is gebruikelijk om over het koppelen van deze relaties te spreken. Bij het koppelen worden koppelingen tot stand gebracht tussen tupels van de ene relatie en tupels van een andere relatie die tot dezelfde database behoren.

In totaal worden vier soorten relaties (links) ondersteund: “één op één”, “veel op één”, “één op veel”, “veel op veel”.

Een-op-veel-relatie Houding X gerelateerd aan houding U Houding“één-op-veel”, als elk tupel van gerelateerd aan houding komt overeen met verschillende tupels uit . In dit geval wordt aangegeven welk veld X Houding van referenties veld X gerelateerd aan houding.

Om koppelingen tot stand te brengen, beschikt het DBMS over een koppelingsontwerpmodus. Om het DBMS correct te laten werken met een gekoppelde database, moeten de koppelingen voldoen aan voorwaarden die de integriteit van de database beschermen. Er worden beperkingen ingesteld op de eigenschappen van de velden die worden gekoppeld. In dit geval betreft Houding(aan de “één” kant) verbindingsveld . In dit geval wordt aangegeven welk veld moet unieke waarden hebben, en het veld referenties veld X gerelateerd aan houding mag geen waarden bevatten die niet zijn opgenomen in . In dit geval wordt aangegeven welk veld. Veld . In dit geval wordt aangegeven welk veld genaamd primaire sleutel , en het veld referenties veld – vreemde sleutel . In dit opzicht is de houding Houding, waarin de primaire sleutel zich bevindt, wordt aangeroepen voornaamste houding en de verhouding gerelateerd aan houding, die de externe sleutel bevat, wordt aangeroepen ondergeschikte houding .

Voorbeeld van een-op-veel-relaties:

relatie “Orders” (ondergeschikt) en relatie “Producten” (hoofd);

de relatie “Orders” (ondergeschikt) en de relatie “Klanten” (master).

Wat betreft BESTELLINGEN vreemde sleutels voor communicatie met de relatie PRODUCTEN en KLANTEN: Product_order en Klant_order. In de relatie PRODUCTEN en KLANTEN primaire sleutels Product_code en Klant_code, waarnaar externe sleutels verwijzen.

Eén-op-één communicatie

Indien verschuldigd één-op-veel extern sleutel y alleen unieke waarden bevat, dan is dit een één-op-één-relatietype - elk record in gerelateerd aan houding komt overeen met één vermelding in Houding en elke binnenkomst Houding komt overeen met maximaal één inzending gerelateerd aan houding. In dit geval is de externe sleutel y niet, zoals . In dit geval wordt aangegeven welk veld, de primaire sleutel van de relatie, sinds in het veld . In dit geval wordt aangegeven welk veld er kunnen waarden zijn die er niet in staan referenties veld. En in het veld referenties veld waarden die niet in het veld staan . In dit geval wordt aangegeven welk veld, dat kan niet zo zijn. In een relatie Houding En gerelateerd aan houding er kan een ander aantal tupels zijn.

Veel-op-één-relatie

Gedefinieerd als een één-op-veel-relatie, maar de relatie Houding En gerelateerd aan houding in de definitie wisselen ze van plaats.

Veel-op-veel-relatie

Gevestigd tussen twee relaties Houding En Eh, als er in elk van hen een is primaire sleutel verbinding met de derde relatie MET, waarin zich bevinden twee vreemde sleutels één-op-veel-relaties tussen Houding En MET en één-op-veel daartussen MET En U. Een-op-veel-relatie MET een bindmiddel genoemd . Met betrekking tot MET u moet een samengestelde sleutel toewijzen (geen eenvoudige sleutel). Deze samengestelde sleutel moet de externe sleutels van twee relaties bevatten (of meer als paren zoals Houding En Eh, doorgelinkt MET, er zijn er meerdere).

Er zijn twee basisvereisten (beperkingen) vastgesteld om de integriteit te behouden. Integriteitsbeperkingen per entiteit En via koppelingen moet worden ondersteund door een relationeel DBMS.

Eerst integriteit van entiteiten . Een domeinobject (of entiteit in een domeinmodel) in relationele databases komt overeen met relatietupels. Concreet is de vereiste dat elke tupel van elke relatie te onderscheiden is van elke andere tupel van dezelfde relatie. Met andere woorden: elke relatie moet een sleutel hebben. Aan deze vereiste wordt automatisch voldaan als de basiseigenschappen van relaties in het systeem niet worden geschonden.

Om te voldoen integriteit per entiteit het is voldoende om te garanderen dat er in geen enkele relatie tupels met dezelfde sleutelwaarde zijn.

Seconde een vereiste wordt een vereiste genoemd referentiële integriteit en is iets complexer. Het is duidelijk dat complexe domeinmodelentiteiten in een relationele database worden weergegeven als meerdere tupels van meerdere gerelateerde relaties.

De referentiële integriteitsvereiste, of refererende sleutelvereiste, is dat er voor elke refererende sleutelwaarde van een ondergeschikte relatie een tupel moet zijn in de hoofdrelatie met die primaire sleutelwaarde, anders moet de refererende sleutelwaarde ongedefinieerd zijn (niet naar iets verwijzen). ). Voor het voorbeeld van relaties tussen medewerker- en afdelingsrelatierecords betekent dit dat als voor een medewerker in de medewerkersrelatie het afdelingsnummer is opgegeven in het afdelingsveld, deze afdeling ook moet bestaan in de afdelingsrelatie.

Bij het bijwerken van de slaaf relatie (nieuwe tupels invoegen of de waarde van de externe sleutel in bestaande tupels wijzigen), hoeft het DBMS er alleen voor te zorgen dat onjuiste externe sleutelwaarden niet verschijnen (die waarden die niet in het primaire sleutelveld van de hoofdrelatie staan) . Bij een tupel verwijderen van een hoofdrelatie als ernaar wordt verwezen door een ondergeschikte relatie, beschikt het DBMS over verschillende van de volgende technieken, die elk de referentiële integriteit behouden.

1) Het is verboden om een tupel te verwijderen waarnaar wordt verwezen (dat wil zeggen, u moet eerst de verwijzende tupels verwijderen of hun externe sleutelwaarden dienovereenkomstig wijzigen).

2) Wanneer een tupel waarnaar wordt verwezen wordt verwijderd, wordt de waarde van de externe sleutel in alle verwijzende tupels automatisch ongedefinieerd.

3) Er wordt een cascadeverwijdering gecreëerd, die erin bestaat dat wanneer een tupel uit de hoofdrelatie wordt verwijderd, alle verwijzende tupels automatisch uit de ondergeschikte relatie worden verwijderd.

In geavanceerde relationele DBMS'en kunt u voor elke individuele situatie een methode kiezen om de referentiële integriteit te behouden. Om een beslissing te nemen, is het noodzakelijk om de vereisten van een specifiek vakgebied te analyseren.

Ontwerp van relationele databases. Normalisatie.

Het concept van normalisatie

Er zal worden gekeken naar de klassieke benadering, waarbij het hele ontwerpproces wordt uitgevoerd in termen van een relationeel datamodel door middel van de methode van opeenvolgende benaderingen van een bevredigende reeks relatieschema's.

Het uitgangspunt is de representatie van het vakgebied in de vorm van een of meer relaties, en bij elke ontwerpstap wordt het initiële relatiesschema omgezet in een bepaalde set die betere eigenschappen heeft.

Het ontwerpproces is een proces normalisatie van relatiepatronen , relaties tot stand brengen "normale vormen" Bovendien heeft elke volgende normaalvorm betere eigenschappen dan de vorige. In werkelijkheid wordt het normalisatieproces uitgevoerd door de ontbinding van relaties, volgens bepaalde regels, die hieronder zullen worden besproken. Het is de ontbinding die de relatie naar de volgende normaalvorm brengt.

Elke normaalvorm komt overeen met een bepaalde reeks beperkingen, en een relatie heeft een bepaalde normale vorm als deze voldoet aan de inherente reeks beperkingen.

De eis van de eerste normaalvorm is een algemene basisvereiste van het klassieke relationele datamodel. Een belangrijke beperking van de eerste normaalvorm is dat de attributen van een relatie atomair zijn, dat wil zeggen dat de attributen zelf geen relaties zijn en niet verder verdeeld zijn (zoals atomen).

In de theorie van relationele databases zijn theoretisch 7 normaalvormen bekend, hier wordt de volgende reeks van 6 normaalvormen benadrukt:

· eerste normaalvorm (1NF);

· tweede normaalvorm (2NF);

· derde normaalvorm (3NF);

Boyce-Codd normale vorm (BCNF);

· vierde normaalvorm (4NF);

· vijfde normaalvorm, of projectie-overgangsnormaalvorm (5NF of PJ/NF).

De eerste drie normaalvormen zijn van praktisch belang.

Basiseigenschappen van normaalvormen

Het ontwerpproces is gebaseerd op een methode om een relatie gevonden in een vorige normaalvorm op te splitsen in twee of meer relaties die voldoen aan de eisen van de volgende normaalvorm.

De belangrijkste normale vormen van relaties in de praktijk zijn gebaseerd op het concept van functionele afhankelijkheid, fundamenteel in de theorie van relationele databases. Dit concept werd besproken in lezing nr. 4. Laten we de definities verduidelijken door ze uit te breiden naar sets velden.

Lezing 3. Algemene concepten en definities. Classificatie van functies. Functielimiet. Oneindig kleine en oneindig grote functies. Basisstellingen over oneindig kleine functies.

Functie

Bij het oplossen van diverse problemen heb je meestal te maken met constante en variabele hoeveelheden.

Definitie

Een constante grootheid is een grootheid die in het algemeen of in een bepaald proces dezelfde waarde behoudt: in het laatste geval wordt het een parameter genoemd.

Een variabele grootheid is een grootheid die verschillende numerieke waarden kan aannemen.

Concept van functie

Bij het bestuderen van verschillende verschijnselen hebben we meestal te maken met een reeks variabele grootheden die zodanig met elkaar verbonden zijn dat de waarden van sommige grootheden (onafhankelijke variabelen) de waarden van andere (afhankelijke variabelen en functies) volledig bepalen.

Definitie

Een variabele grootheid y wordt een (enkelwaardige) functie van een variabele grootheid x genoemd als ze zodanig aan elkaar gerelateerd zijn dat elke waarde van x in kwestie overeenkomt met een enkele, goed gedefinieerde waarde van de grootheid y (geformuleerd door N.I.

Aanduiding y=f(x) (1)

X– onafhankelijke variabele of argument;

j– afhankelijke variabele (functie);

F– kenmerkend voor de functie.

De verzameling van alle waarden van de onafhankelijke variabele waarvoor de functie is gedefinieerd, wordt het definitiedomein of het bestaansdomein van deze functie genoemd. Het domein van de definitie van een functie kan zijn: een segment, een half interval, een interval of de gehele numerieke as.

Elke straalwaarde komt overeen met een cirkelgebiedwaarde. Oppervlakte is een functie van de straal, gedefinieerd over een oneindig interval

2. Functie (2). Functie gedefinieerd bij

Om het gedrag van een functie te visualiseren, construeert u een functiegrafiek.

Definitie

Functie grafiek y=f(x) wordt een reeks punten genoemd M(x,y) vliegtuig OXY, waarvan de coördinaten gerelateerd zijn door deze functionele afhankelijkheid. Of de grafiek van een functie is een lijn waarvan de vergelijking een gelijkheid is die de functie definieert.

De grafiek van functie (2) is bijvoorbeeld een halve cirkel met straal 2 met het middelpunt in de oorsprong.

De eenvoudigste functionele afhankelijkheden

Laten we eens kijken naar een paar eenvoudige functionele afhankelijkheden

Directe functionele afhankelijkheid

Definitie

Twee variabelen worden direct proportioneel genoemd als wanneer een van hen in een bepaalde verhouding verandert, de andere in dezelfde verhouding verandert.

y=kx, Waar k– evenredigheidscoëfficiënt.

Grafiek van een functie

Lineaire afhankelijkheid

Definitie

Twee variabele hoeveelheden zijn gerelateerd aan een lineaire relatie, als , waar enkele constante hoeveelheden zijn.

Grafiek van een functie

Omgekeerd proportioneel verband

Definitie

Twee variabelen worden omgekeerd evenredig genoemd als wanneer een van hen in een bepaalde verhouding verandert, de andere in de tegenovergestelde verhouding verandert.

Kwadratische afhankelijkheid

De kwadratische afhankelijkheid heeft in het eenvoudigste geval de vorm, waarbij k een constante waarde is. De grafiek van een functie is een parabool.

Sinusoïdale afhankelijkheid.

Bij het bestuderen van periodieke verschijnselen speelt de sinusoïdale afhankelijkheid een belangrijke rol

- de functie wordt een harmonische genoemd.

A– amplitude;

Frequentie;

Initiële fase.

De functie is periodiek met periode. Functiewaarden op punten X En x+T, verschillend per periode, zijn hetzelfde.

De functie kan worden teruggebracht tot de vorm , Waar . Vanaf hier krijgen we dat de harmonische grafiek een vervormde sinusoïde is met amplitude A en periode T, verschoven langs de OX-as met de hoeveelheid

Methoden voor het opgeven van een functie

Meestal worden drie manieren overwogen om een functie te specificeren: analytisch, tabellarisch en grafisch.

Analytische methode voor het specificeren van een functie

Als een functie wordt uitgedrukt met behulp van een formule, wordt deze analytisch gespecificeerd.

Bijvoorbeeld

Als de functie y=f(x) wordt gegeven door een formule en vervolgens het kenmerk ervan F geeft de reeks acties aan die in een bepaalde volgorde moeten worden uitgevoerd op basis van de waarde van het argument X om de corresponderende functiewaarde te verkrijgen.

Voorbeeld . Er worden drie acties uitgevoerd op de argumentwaarde.

Tabellarische methode voor het specificeren van een functie

Deze methode brengt de correspondentie tussen variabelen tot stand met behulp van een tabel. Als we de analytische uitdrukking van een functie kennen, kunnen we deze functie weergeven voor de argumentwaarden die ons interesseren met behulp van een tabel.

Is het mogelijk om van een tabellaire functietoewijzing naar een analytische uitdrukking te gaan?

Merk op dat de tabel niet alle waarden van de functie geeft, en dat tussenliggende waarden van de functie slechts bij benadering kunnen worden gevonden. Dit is de zgn interpolatie functies. Daarom is het in het algemene geval onmogelijk om een exacte analytische uitdrukking voor een functie te vinden met behulp van tabelgegevens. Het is echter altijd mogelijk om een formule te construeren, en meer dan één, die, voor de waarden van het argument dat beschikbaar is in de tabel, de overeenkomstige tabelwaarden van de functie zal opleveren. Dit soort formule wordt interpolatie genoemd.

Grafische manier om een functie te specificeren

Analytische en tabellarische methoden geven geen duidelijk beeld van de functie.

De grafische methode voor het specificeren van een functie kent dit nadeel niet. y=f(x), wanneer de overeenkomst tussen het argument X en functie j instellen met behulp van een schema.

Het concept van een impliciete functie

Een functie wordt expliciet genoemd als deze wordt gegeven door een formule waarvan de rechterkant niet de afhankelijke variabele bevat.

Functie j uit betoog X wordt impliciet genoemd als het door de vergelijking wordt gegeven

F(x,y)=0(1) onopgelost met betrekking tot de afhankelijke variabele.

Concept van inverse functie

Laat de functie gegeven worden y=f(x)(1). Door de waarden van het argument x op te geven, verkrijgen we de waarden van de functie j.

Het is mogelijk, gezien j betoog, en . In dit geval wordt aangegeven welk veld– functie, waarden instellen j en waarden krijgen X. In dit geval zal vergelijking (1) bepalend zijn X, als een impliciete functie van j. Deze laatste functie wordt aangeroepen achteruit met betrekking tot deze functie j.

Ervan uitgaande dat vergelijking (1) wordt opgelost met betrekking tot X, we verkrijgen een expliciete uitdrukking voor de inverse functie

(2), waarbij de functie voor alle geldige waarden is j voldoet aan de voorwaarde

De informatie had altijd voldoende dynamische interesse. De ontwikkeling van programmeertalen, relationele databases en informatietechnologieën heeft de inhoud en structuur van de belangstelling radicaal veranderd. Er heeft zich een bepaald strikt ideeënsysteem ontwikkeld. Formalisering, exacte wiskunde en binaire relaties zijn een succesvol en zich snel ontwikkelend kennis- en ervaringsgebied geworden.

De natuurlijke wereld van informatie heeft haar dynamiek niet veranderd en is door de ontwikkeling van inhoud en structuur naar nieuwe hoogten gestegen. Het heeft gladde vormen en er is niets in de natuur "rechthoekig". Informatie leent zich uiteraard voor formalisering, maar er is sprake van dynamiek; niet alleen de gegevens en algoritmen voor de verwerking ervan veranderen, maar ook de taken zelf en hun toepassingsgebieden veranderen.

Informatie > formalisering >> gegevens

Informatie verandert in een informatiestructuur, een database...) zoals de programmeur het ziet. Er is geen garantie dat deze visie juist is, maar als zijn programma het probleem oplost, dan zijn de gegevens zo goed mogelijk gepresenteerd.

De vraag hoe correct de informatie werd geformaliseerd is een kwestie van tijd. Tot nu toe was het concept van dynamiek (zelfaanpassing aan veranderende gebruiksomstandigheden) slechts een programmeerdroom.

Functionele afhankelijkheid: “juiste oplossing = programma (programmeur)” en voorwaarde: “continue uitvoering van de taak” zijn in de meeste gevallen geldig, maar alleen samen. Maar dit is niet de wiskundige basis die wordt gebruikt om databases te maken.

Een directe verklaring: de natuurlijke en continue dynamiek van informatie en probleemoplossende algoritmen is altijd reëel. En dit zijn binaire relaties + strikte wiskunde + nauwkeurige formele constructies, + ...

en databanken

Hoe gegevens worden opgeslagen, is lange tijd onbelangrijk geweest: of het nu RAM is of een extern apparaat. De hardwarecomponent heeft een gestaag ontwikkelingstempo bereikt en biedt goede kwaliteit in grote volumes.

De belangrijkste opslagopties, verschillend in opties voor gegevensgebruik:

bestanden;
databases.

Het eerste wordt aan de programmeur overgelaten (wat te schrijven, in welk formaat, hoe het te doen, hoe te lezen...), het tweede brengt onmiddellijk de behoefte met zich mee om een eenvoudige functionele afhankelijkheid te begrijpen.

De snelheid van het ophalen en schrijven van informatie bij het werken met bestanden (van een redelijke omvang, niet astronomisch) is erg snel, maar de snelheid van soortgelijke bewerkingen met een database kan soms merkbaar traag zijn.

Persoonlijke ervaring en collectieve wijsheid

Door de geschiedenis heen zijn er pogingen geweest om deze grenzen te overschrijden, maar tot op de dag van vandaag zijn relationele databases de baas. Er is een groot theoretisch potentieel opgebouwd, de toepassingspraktijk is uitgebreid en de ontwikkelaars zijn hooggekwalificeerd.

Databaseontwikkelaars leggen het concept van functionele afhankelijkheid op aan de programmeur, ook al is hij niet van plan de rijke wiskundige en logische ervaring te gebruiken bij het construeren van complexe informatiestructuren, de processen om ermee te werken, het ophalen en vastleggen van informatie.

Zelfs in het eenvoudigste geval is de programmeur afhankelijk van de databaselogica waarmee hij wil werken. Er is geen wens om de canons te volgen, je kunt bestanden gebruiken, je krijgt veel bestanden en veel persoonlijke ervaring. Er zal veel persoonlijke tijd worden besteed en het probleem zal over een lange periode worden opgelost.

Hoe complex voorbeelden van functionele afhankelijkheid ook lijken, het is helemaal niet nodig om in de diepten van betekenis en logica te duiken. Vaak moet worden erkend dat de collectieve geest erin is geslaagd uitstekende databases van verschillende omvang en functionaliteit te creëren:

solide orakel;
veeleisende MS SQL Server;
populaire MySQL.

Uitstekende relationele databases met een goede reputatie, eenvoudig in gebruik, snel in de juiste handen. Het gebruik ervan bespaart tijd en elimineert de noodzaak om nog meer vellen met hulpcode te schrijven.

Programmeer- en datafuncties

Programmeren heeft lange tijd de ziekte gehad om voortdurend iets te herschrijven, het werk van voorgangers te herhalen, om op de een of andere manier iets aan te passen aan veranderde informatie, een taak of de omstandigheden van het gebruik ervan.

Het probleem met functionele afhankelijkheid is dat een fout, net als bij programmeren, erg kostbaar kan zijn. De taak is zelden eenvoudig. Meestal wordt tijdens het formaliseren van informatie een complexe weergave van de gegevens verkregen. Meestal worden hun elementen geïsoleerd, vervolgens worden ze door sleutels aan bepaalde relaties gekoppeld, waarna algoritmen voor het vormen van tabellen, query's en algoritmen voor het ophalen van informatie worden aangepast.

Vaak is de binding aan de codering van groot belang. Niet alle databases bieden mobiele oplossingen; je kunt vaak tegenkomen hoe een perfect geconfigureerde MySQL, waarop een tiental databases zijn gebaseerd, die perfect en stabiel werkt, de ontwikkelaar dwingt om de elfde database vergelijkbaar te maken met de databases die al bestaan.

Er zijn momenten waarop gedeelde hosting de functionaliteit van PHP beperkt en dit heeft invloed op de programmering van databasetoegang.

In moderne programmering is de verantwoordelijkheid voor het algoritme van een programma gelijk aan de verantwoordelijkheid voor het creëren van een datamodel. Alles zou moeten werken, maar je moet niet altijd in de jungle van de theorie duiken.

DB: eenvoudige gegevensafhankelijkheid

Allereerst is het concept van een database zowel een database, zowel een managementsysteem (bijvoorbeeld MySQL) als een bepaalde informatiestructuur die taakgegevens en de verbindingen daartussen weerspiegelt. Eén MySQL-database ‘bewaart’ zoveel informatiestructuren als u wilt voor verschillende toepassingsgebieden. Eén Oracle-database kan de informatieprocessen van een groot bedrijf of een grote bank ondersteunen en beveiligingsproblemen en gegevensintegriteit op het hoogste niveau controleren, gelegen op veel computers op verschillende afstanden, in verschillende instrumentele omgevingen.

Het wordt algemeen aanvaard dat de relatie fundamenteel is in het relationele model. Een elementaire relatie is een reeks kolommen met namen en rijen met waarden. Klassiek "rechthoek"(tabel) - eenvoudig en effectief vooruitgang boeken. De complexiteit en functionele afhankelijkheden van een database beginnen wanneer "rechthoeken" relaties met elkaar beginnen aan te gaan.

De naam van elke kolom in elke tabel moet uniek zijn binnen de context van de taak. Dezelfde gegevens kunnen niet in twee tabellen staan. Ken de betekenis van de concepten:

“entiteiten definiëren”;
“elimineer overtolligheid”;
“relaties herstellen”;
“om de authenticiteit te garanderen.”

Een elementaire noodzaak voor het gebruik van een database en het bouwen van een datamodel voor een specifieke taak.

Schending van een van deze concepten betekent een lage efficiëntie van het algoritme, trage gegevensbemonstering, gegevensverlies en andere problemen.

Functionele afhankelijkheid: logica en betekenis

Je hoeft niet te lezen over tupels van relaties, over het feit dat een functie een correspondentie is tussen een reeks argumenten en een reeks waarden, en dat een functie niet alleen een formule of een grafiek is, maar kan worden gespecificeerd door een reeks waarden - een tabel.

Het is niet nodig, maar het kan geen kwaad om een functionele afhankelijkheid als volgt te beschouwen:

F(x1, x2, …, xN) = (y1, y2, …, yN).

Maar het is absoluut noodzakelijk om te begrijpen dat de invoer een tabel is, en de uitvoer ook een tabel of een specifieke oplossing. Doorgaans legt een functionele afhankelijkheid de logica vast van relaties tussen tabellen, query's, privileges, triggers, opgeslagen procedures en andere aspecten (componenten) van de database.

Meestal worden tabellen naar elkaar geconverteerd en vervolgens naar het resultaat. Maar het gebruik van functionele afhankelijkheid beperkt zich niet alleen tot dit idee. De programmeur bouwt zelf zijn eigen representatie van het databeeld, de informatiestructuur... het maakt niet uit hoe je het noemt, maar als het op een specifieke database werkt, moet het gebouwd worden volgens zijn logica, rekening houden met zijn betekenis en het dialect van de gebruikte taal, meestal SQL.

Er kan worden gesteld dat de eigenschappen van de functionele afhankelijkheden van een database toegankelijk zijn via het dialect van de gebruikte SQL-taal. Maar het is veel belangrijker om te begrijpen: na alle wisselvalligheden van de ontwikkeling zijn er niet veel databases bewaard gebleven, maar er zijn ook veel dialecten van deze taal en kenmerken van interne structuren in de databases.

Over het goede oude Excel

Toen de computer zich van de positieve kant liet zien, werd de wereld meteen verdeeld in programmeurs en gebruikers. In de regel gebruiken de eersten:

PHP, Perl, JavaScript, C++, Delphi.
MySQL, Oracle, Visual FoxPro.

Woord.
Excel.

Sommige gebruikers slagen erin om zelf databases in Word te maken (zonder de hulp van programmeurs) - dit is echte onzin.

Gebruikerservaring in Excel om databases te maken is praktisch en interessant. Het belangrijkste is dat Excel zelf functioneel, kleurrijk en praktisch is.

Het tabellarische idee definieerde het concept van functionele afhankelijkheid op een duidelijke en toegankelijke manier, maar elke database heeft nuances. Elk heeft zijn eigen ‘gezicht’, maar iedereen, van Excel tot Oracle, manipuleert eenvoudige vierkanten, dat wil zeggen tabellen.

Als je bedenkt dat Excel helemaal geen database is, maar dat veel gebruikers (geen programmeurs) het op die manier gebruiken, en Oracle de meest complexe en krachtige prestatie is van een groot team van ontwikkelaars op het gebied van databases, dan wordt het vanzelfsprekend om geef toe dat een database een representatie is van een specifieke programmeur (team) over een specifiek probleem en de oplossing ervan.

Wat functionele afhankelijkheid is, waarmee, waar, waarom... is alleen duidelijk voor de auteur of een team van hen.

Over waar relationele relaties naartoe gaan

Wetenschappelijke en technologische vooruitgang is een zeer pijnlijke procedure, en soms wreed. Als je je herinnert hoe databases begonnen, wat *.dbf is, hoe ze cybernetica stigmatiseerden, vervolgens verliefd werden op de informatica en obstakels begonnen te creëren voor de beweging van geavanceerde technologieën op landniveau, wordt het duidelijk waarom relationele databases zo zijn vasthoudend en goed. Waarom de klassieke stijl van programmeren vandaag de dag nog steeds voortleeft, en objectgeoriënteerd programmeren eenvoudigweg wordt gewaardeerd, maar nog niet regeert.

Hoe mooi ook functionele afhankelijkheid in de context van de wiskunde:

Dit is geen binaire relatie, of beter gezegd, het is een reden om het idee van het tot stand brengen van relaties tussen meerdere attributen te heroverwegen, door “één-op-veel”, “veel-op-één”, “veel-op-één” te onderzoeken. -veel' of 'veel in het algemeen en sommige in het bijzonder'-relaties.

Je kunt een grote verscheidenheid aan relatie-opties bedenken. Het is wiskunde met logica, en het is rigoureus! Informatie is zijn eigen wiskunde, speciaal. Daarin kun je alleen over formaliteit praten met een heel groot minpunt.

Je kunt het werk van de HR-afdeling formaliseren, een geautomatiseerd controlesysteem schrijven voor de olieproductie of de productie van melk, brood, een selectie maken in de enorme database van Google, Yandex of Rambler, maar het resultaat zal altijd statisch en hetzelfde zijn op elk moment!

Als functionele afhankelijkheid = strikte logica en wiskunde = de basis voor databases, over wat voor soort dynamiek kunnen we dan praten? Elke oplossing zal formeel zijn, elk formeel datamodel + strikt algoritme = exacte en ondubbelzinnige oplossing. De informatie en reikwijdte van elk programma verandert voortdurend.

De selectie van de zoekmachine voor dezelfde zoekterm kan niet na een uur of twee hetzelfde zijn, en zeker om de dag - als de zoekterm behoort tot een informatiegebied waarin het aantal sites, bronnen, kennis en andere elementen veranderen voortdurend.

Zelfs als het programma puur wiskundig is en de database niet eens aan dynamiek denkt, alles is altijd lijnen. En de snaar heeft een lengte. En het kan niet eindeloos zijn. Het kan niet eens een variabele zijn, alleen een voorwaardelijke variabele. Elke database met zijn wiskundig en binair bureaucratisch apparaat legt onder andere veel formaliteiten op, en dit is de snelheid + kwaliteit van het bemonsteren en verwerken van informatie.

En als bepaalde velden in de database cijfers zijn, vooral echte, dan worden de volgende beperkingen toegevoegd: de capaciteit van het aantal cijfers, de aanwezigheid van de letter "e", weergaveformaat - kortom, overal en altijd hebben we belangrijke database functionele afhankelijkheidseigenschappen: reeksen van voorwaardelijk variabele lengte met veel binaire formaliteiten en strikte wiskundige beperkingen.

Als je de toon verandert en luistert naar de hartslag van de dynamiek, kan alles in objecten worden geschilderd. In een eerste benadering is de naam van een kolom in een tabel een object, een lijst met namen is ook een object, kortom een tabel is een headerobject en daarin de namen van de kolommen in de header. En misschien is er helemaal geen hoed...

Maar er kunnen rijen in de tabel voorkomen. En er kunnen waarden in de string staan. En waarom zouden het er altijd evenveel moeten zijn? Volledige vierkante tafel- dit is iets bijzonders, en in de meeste gevallen een privézaak.

Als u alle constructies in de database als objecten weergeeft, hoeft u wellicht geen strikte binaire relaties op te bouwen. Dit heeft een natuurlijke en reële betekenis, al was het maar omdat het, volgens objectieve (zeker niet wiskundige) logica, de dynamiek van informatie en de omgeving weerspiegelt waarin problemen bestaan.