Handleiding voor databaseontwerp. Ontwikkeling van een relationele database. Nationale Onderzoeksuniversiteit

Regering Russische Federatie

Nationale Onderzoeksuniversiteit

HOGE SCHOOL VOOR ECONOMIE

PERM-TAK

Afdeling informatietechnologie in het bedrijfsleven

Informatietechnologie op kantoorwerk

Ontwikkeling informatiesysteem bedrijven die een databasebeheersysteem gebruiken Toegang tot gegevens 2007

Educatieve en methodologische handleiding

Permanent 2011

Informatietechnologie in kantoorwerk. Ontwikkeling van een bedrijfsinformatiesysteem met behulp van het databasebeheersysteem Access 2007. Educatieve handleiding. NRU HSE PF, 2011, 40 p.

Samengesteld door: Vikentyeva Olga Leonidovna, Lebedev Valery Viktorovich.

De educatieve handleiding is samengesteld in overeenstemming met de staatsonderwijsnorm, leerplan en het concept van de discipline “Informatietechnologieën in de economie”. De handleiding is bedoeld voor studenten en docenten van de Pensioenfaculteit van de State University Higher School of Economics en bevat een reeks praktische lessen, waarin de mogelijkheden van moderne informatietechnologieën worden onthuld om systemen te creëren voor het opslaan, ophalen en presenteren van gegevens.

Recensent: universitair hoofddocent van de afdeling Informatica van het Perm Regionaal Instituut voor Pedagogische Informatietechnologieën, kandidaat voor Pedagogische Wetenschappen, corresponderend lid van de Academie voor Informatisering van Onderwijs Kushev V.O.

Les 1. Ontwerp relationele basis gegevens

In de gebruikelijke zin is een database een bestand of een reeks bestanden met een specifieke organisatie. Echter, bij het werken met conventionele systemen bestandsverwerking brengt een aantal problemen met zich mee die met name te maken hebben met de redundantie en afhankelijkheid van de daarin opgeslagen gegevens. Bij het ontwerpen van een database worden deze problemen opgelost.

De gebruiker moet deelnemen aan het databaseontwerpproces, omdat alleen hij kan bepalen welke gegevens nodig zijn voor het werk, de verbanden tussen deze gegevens kan aangeven en aandacht kan besteden aan de subtiliteiten van hun verwerking.

De informatiebehoeften van een individuele gebruiker hebben doorgaans slechts betrekking op een deel van de gegevens die in het informatiesysteem zijn opgeslagen, en de beschrijving van deze behoeften valt mogelijk niet samen met de beschrijvingen van de behoeften van andere gebruikers. Het idee van welke informatie nodig is voor werk zal anders zijn verschillende groepen gebruikers, specialisten op verschillende gebieden - het hangt af van de taken die ze uitvoeren (HR-specialisten en boekhoudkundige medewerkers, afdelingshoofden, enz. hebben verschillende gegevens nodig om hun functies uit te voeren). Deze behoeften zijn beschreven in extern niveau presentatie van gegevens (aanzichten A, B en C in figuur 1).

Externe beschrijvingen Er kunnen dus veel gegevens in de database worden opgeslagen. Ze moeten bij elkaar worden gebracht conceptuele kijk, waarbij gegevens worden beschreven op het niveau van het gehele informatiesysteem als geheel. De presentatie van deze gegevens op intern niveau wordt bepaald door de manier waarop deze worden opgeslagen extern geheugen.

Laten we een voorbeeld bekijken van een database van een informatiesysteem van een bedrijf dat goederen levert aan stadswinkels, en we zullen alleen rekening houden met de informatiebehoeften van twee werknemers van het bedrijf (in een vereenvoudigde vorm - anders zou het voorbeeld te omslachtig zijn ).

Figuur 1. Vorming van datarepresentatie

Een medewerker klantrelaties heeft de informatie uit Figuur 2 nodig om zijn taken uit te voeren.

Een medewerker die met betaalformulieren werkt, heeft andere informatie over klanten nodig (Fig. 3).

De gegevens die door individuele specialisten worden gebruikt, bevinden zich in een uniform informatiesysteem van de onderneming, in een gemeenschappelijke database voor hen. Daarom moeten de externe visies van individuele gebruikers worden geïntegreerd in een conceptuele visie; het doel van het beschrijven van gegevens op conceptueel niveau is om een zo formeel beeld van de gegevens te creëren dat elke externe visie er een subset van is. Het proces van het integreren van externe representaties elimineert dubbelzinnigheden en tegenstrijdigheden in de informatiebehoeften van individuele gebruikers. De conceptuele beschrijving die de gehele database vertegenwoordigt, moet uniek zijn.

Figuur 2. Gegevens voor de eerste werknemer

Figuur 3. Gegevens voor de tweede werknemer

In dit voorbeeld moet de conceptuele weergave alle informatie bevatten die alle werknemers nodig hebben. Tegenstrijdigheden kunnen ontstaan door het feit dat werknemers die gebruiken algemene informatie, kan het op verschillende manieren voorstellen (bijvoorbeeld: er kan een telefoonnummer in worden geschreven verschillende formaten). Al deze tegenstrijdigheden moeten worden geëlimineerd, de gegevens en de vorm van hun presentatie moeten consistent zijn.

Vervolgens wordt de conceptuele beschrijving bepaald door de volgende informatie

De gegevens beschreven door het conceptuele diagram moeten worden vastgelegd in een extern geheugen, op VRAM, ontworpen om informatie in de database op te slaan. De interne gegevensbeschrijving karakteriseert de manier waarop gegevens in het externe geheugen worden opgeslagen.

De regels voor het beschrijven van gegevens worden bepaald door de geselecteerde datamodel(V in dit geval alleen het relationele model wordt in beschouwing genomen (het meest voorkomende momenteel).

Als we de beschrijving van gegevens over klanten van een bedrijf dat zich bezighoudt met het leveren van goederen aan stadswinkels uit het bovenstaande voorbeeld nemen, weergegeven in figuur 4, dan kunnen de gegevens die in deze tabel worden beschreven niet in deze vorm worden gepresenteerd in een relationele database, aangezien dat niet het geval is. alle waarden zijn atomair (componenten van de regels "Eigenaar" en "Adres" bestaan uit verschillende waarden, d.w.z. de waarden van deze attributen worden vervangen door andere relaties, daardoor ontcijferd in de relatie die de eigenaar beschrijft, de velden " Adres” en “Paspoort” zijn ook niet atomair, daarom wordt er een hiërarchie opgebouwd;

Bij het ontwerpen van een database kunnen ze worden gebruikt verschillende oplossingen, maar er zijn basisvereisten waarmee tijdens het werkproces rekening moet worden gehouden: het geheel van relaties moet zorgen voor minimale redundantie bij de presentatie van informatie; manipulatie van gegevens en aanpassing van relaties mogen niet leiden tot schending van de gegevensintegriteit, dubbelzinnigheid en verlies van informatie; de herstructurering van de reeks relaties bij het toevoegen van nieuwe attributen aan de database moet minimaal zijn.

Figuur 4. Algemene presentatie van gegevens

De beschrijving van echte objecten en de relaties daartussen is grotendeels subjectief, maar er zijn er zeker algemene regels, in het bijzonder, normalisatie regels. Normalisatie beschermt de gegevensintegriteit door gegevensduplicatie te elimineren. Als gevolg hiervan kan een representatie van gegevens over een enkel object worden opgesplitst in verschillende kleinere gerelateerde tabellen (verliesvrije decompositie). De beperkingen die in acht moeten worden genomen bij het ontwerpen van een relationele database zijn vrij talrijk. Het voldoen aan beperkingen bij het definiëren van specifieke relaties in de database houdt verband met de implementatie normale vormen. Normale vormen zijn opeenvolgend genummerd, beginnend bij de eerste. Hoe groter het getal van de normaalvorm waaraan de database voldoet, des te meer beperkingen er moeten worden nageleefd op de gegevens die in de database zijn opgeslagen. Het is mogelijk om typisch voor relationele DBMS beperkingen introduceren extra setje beperkingen, wat zal leiden tot een toename van het aantal normaalvormen.

Een slecht ontworpen database kan alle informatie in één tabel opslaan. Voor het hierboven beschreven voorbeeld zou een dergelijke tabel de volgende kolommen kunnen bevatten:

De onderdelen Straat en Huisadres zijn hernoemd om te voldoen aan de vereiste dat kolomnamen uniek moeten zijn (naamgevingsregels variëren per DBMS).

Wat zijn de nadelen van dit idee?

Eerste normaalvorm vereist dat er op elk snijpunt van een rij en een kolom één enkele waarde is die ondeelbaar moet zijn (atomiciteitseis). Bovendien mag een relationele tabel geen dubbele rijen of groepen gegevens bevatten.

Er is voldaan aan de atomiciteitseis - de samengestelde kolommen "Adres" en "Eigenaar" (en voor de eigenaar "Adres" en "Paspoort") zijn verdeeld in componenten die zijn opgenomen in de algemene tabel. Maar één winkel kan meerdere eigenaren hebben, en één persoon kan meerdere winkels bezitten. Dit betekent dat de tabel alle rijen moet bevatten die “combinaties” van winkels en hun eigenaren vertegenwoordigen, d.w.z. groepen gegevens worden op verschillende regels herhaald (gegevens over de winkel worden verschillende keren herhaald - voor elk van de eigenaren, en de gegevens van de eigenaar worden herhaald voor elk van zijn winkels). Een dergelijke weergave van gegevens leidt tot enorme redundantie en tot het feit dat het geheugen op het VRAM inefficiënt wordt gebruikt. Bovendien kan het dupliceren van informatie tot problemen leiden bij de verwerking ervan: om wijzigingen aan te brengen in de informatie over een winkel (bijvoorbeeld als de bankrekening verandert), moet u deze gegevens wijzigen in verschillende records die overeenkomen met verschillende eigenaren.

Wanneer u bepaalt welke tabellen in de database moeten worden opgenomen en welke informatie daarin moet worden opgeslagen, moet u overwegen volgende regel: elke tabel beschrijft een object, onafhankelijk bestaand, met zijn eigen eigenschappen. De constructie van een database zou moeten beginnen met het creëren van een representatie van elk object in de vorm van rijen met de attributen ervan in de corresponderende tabel; het definiëren van modellen van objectrelaties. In het beschouwde voorbeeld zou de database feitelijk twee typen informatie over objecten moeten opslaan: over winkels en over hun eigenaren. Deze informatie moet in twee verschillende tabellen (Winkels en Eigenaren) worden geplaatst met de volgende kolommen:

"Winkels"

"Eigenaren"

Elke rij van de tabel "Winkels" beschrijft een exemplaar van het overeenkomstige object (één winkel). En elke rij van de tabel 'Eigenaren' bevat informatie over één winkeleigenaar.

Bij het werken met informatie die in een database is opgeslagen, moet het DBMS rijen van elkaar kunnen onderscheiden. Een attribuut of een set attributen die een string op unieke wijze identificeert, is het attribuut primaire sleutel.

Wat kan worden gekozen als de primaire sleutel voor de hierboven beschreven tabellen?

Sleutel een relatie is zo'n set attributen dat elke combinatie van hun waarden in slechts één rij van de relatie voorkomt en geen enkele subset van deze attributen heeft deze eigenschap. De sleutel identificeert dus op unieke wijze een rij en maakt het mogelijk dat deze wordt geselecteerd uit de gehele reeks rijen in de relatie.

Laten we een sleutel definiëren voor de tabel "Winkels".

Als u het kenmerk Winkelnaam als sleutel selecteert, voldoet dit dan aan de opgegeven vereiste? Nee, als er in één stad meerdere winkels zijn dezelfde namen gelegen in verschillende onderdelen steden. Om de ondubbelzinnigheid te garanderen, moet u de naam van de winkel aanvullen met het adres (bij de naam van de winkel en het adres kunt u ondubbelzinnig selecteren de gewenste lijn in de tabel), dan zal de relatiesleutel samengesteld zijn.

Met een simpele sleutel, identificeren de juiste winkel, mag een bankrekeningnummer zijn (als elke winkel één betaalrekeningnummer heeft en elke betaalrekening bij één winkel hoort). De sleutel kan ook een belastingidentificatienummer zijn ( identificatienummer) winkel.

Laten we het attribuut “TIN” als primaire sleutel selecteren. Verder zal dit attribuut worden gebruikt om verbindingen tussen de tabellen “Winkels” en “Eigenaren” te organiseren (deze verbindingen moeten de echte relaties tussen winkels en hun eigenaren weerspiegelen).

Laten we beslissen over de sleutels voor de tabel 'Eigenaars'.

Als we zouden kunnen aannemen dat er geen naamgenoten zijn onder de winkeleigenaren, dan zouden we het attribuut ‘Achternaam’ van de betreffende relatie als sleutel kunnen selecteren. Maar helaas kunnen winkeleigenaren niet alleen naamgenoten zijn, maar ook complete handlangers (onwaarschijnlijk, maar heel goed mogelijk). Daarom kunt u de paspoortgegevens van de eigenaar als sleutel selecteren, d.w.z. gebruik een samengestelde sleutel om deze te identificeren, inclusief de attributen “Reeks” en “Nummer”. We beschouwen deze sleutel als de primaire sleutel. Met zijn hulp zullen we een verbinding tot stand brengen tussen de eigenaar en zijn winkels.

Primaire sleutels zorgen niet alleen voor ondubbelzinnigheid bij het zoeken naar informatie (ze zijn uniek), maar stellen u ook in staat gegevens in twee tabellen te koppelen.

Laten we het type relatie tussen de tabellen 'Winkels' en 'Eigenaren' definiëren.

Als we ervan uitgaan dat één persoon meerdere winkels kan bezitten, maar elke winkel één eigenaar heeft, creëren we een één-op-veel-relatie tussen deze tabellen. Om een dergelijke verbinding in de database te organiseren, zou het mogelijk zijn om in de rij van de tabel “Winkels” informatie over de winkel op te nemen vreemde sleutel, waarmee de eigenaar van de winkel wordt geïdentificeerd, d.w.z. zijn paspoortgegevens – de attributen “Serie” en “Nummer”. In dit geval is het onmogelijk om een verbinding tot stand te brengen door de “TIN”-sleutel, die winkels identificeert, als externe sleutel op te nemen in de tabel “Eigenaars”, aangezien in dit geval informatie over de eigenaar voor elke winkel zou moeten worden gedupliceerd. .

Als we ervan uitgaan dat één persoon slechts één winkel kan bezitten, maar dat elke winkel meerdere eigenaren kan hebben, krijgen we een één-op-veel-relatie, maar in dit geval vreemde sleutel(winkelbelastingidentificatienummer) zou moeten worden opgenomen in de tabel met informatie over de eigenaren.

In werkelijkheid kan elke persoon de eigenaar zijn van meerdere winkels en kan elke winkel meerdere eigenaren hebben. Er moet dus een veel-op-veel-relatie tot stand worden gebracht tussen de tabellen 'Winkels' en 'Eigenaars', voor de organisatie waarvan een speciale tabel bestaat. is gemaakt die de relaties tussen winkels en eigenaren beschrijft:

"Winkel-eigenaren"

TIN

Serie

Nummer

Met deze tabel kunt u alle eigenaren vinden met behulp van het kenmerk 'TIN' van een winkel (via de gegevens van hun paspoorten) en met behulp van een samengesteld kenmerk dat de kenmerken 'Serie' en 'Nummer' van het paspoort van de eigenaar bevat. vind in de database alle winkels die hij bezit.

Om dit te doen, moet u, nadat u de tabel “Winkels-Eigenaars” heeft gemaakt, een-op-veel-relaties tot stand brengen tussen de tabel “Winkels” en de tabel “Winkels-Eigenaars”, evenals tussen de “Eigenaren” en “Winkels-Eigenaars”. tafels:

TIN Serie Nummer

"Winkel-eigenaren"

Gevestigde verbindingen helpen DBMS de integriteit en consistentie van informatie te behouden. U kunt bijvoorbeeld regels instellen voor het bijwerken van informatie in gerelateerde tabellen bij het bijwerken van informatie in de hoofdtabel (wanneer een winkel bijvoorbeeld wordt geliquideerd, moet informatie daarover uit de database worden verwijderd en overgebracht naar het archief, en niet alleen de rij uit de tabel “Winkels”, maar alle informatie in de bijbehorende tabellen die betrekking hebben op deze winkel).

Voor het gemak van gebruikers en om zoekopdrachten te versnellen, ondersteunen DBMS'en de mogelijkheid om niet alleen op unieke sleutels te zoeken. In de tabel vindt u bijvoorbeeld alle winkels met dezelfde naam of alle winkels van dezelfde eigenaar.

Datanormalisatie leidde tot het partitioneren van tabellen, waarbij de relaties tussen primaire sleutel en buitenlandse sleutel in kleinere tabellen werden verdeeld. Het resultaat van normalisatie is een vermindering van de gegevensredundantie: het is niet langer nodig om gegevens over elke eigenaar voor elke winkel te dupliceren.

Tweede normaalvorm vereist dat elke niet-sleutelkolom afhankelijk is van de primaire sleutel (en van de gehele sleutel, niet van de afzonderlijke componenten). Een relatie bevindt zich in de tweede normaalvorm als deze overeenkomt met de eerste normaalvorm en geen onvolledige bevat functionele afhankelijkheden. Een onvolledige functionele afhankelijkheid wordt gedefinieerd door twee voorwaarden: de sleutel van de relatie definieert functioneel een niet-sleutelattribuut, en een deel van de sleutel definieert functioneel hetzelfde niet-sleutelattribuut.

Een relatie die niet overeenkomt met de tweede normaalvorm wordt gekenmerkt door redundantie van opgeslagen gegevens.

In het beschouwde voorbeeld zijn de set relatieattributen en de sleutelkeuze zo gemaakt dat de tabellen overeenkomen met de tweede normaalvorm. Als deze correspondentie niet zou bestaan, zou het, om tabellen terug te brengen tot de tweede normale vorm, nodig zijn om de herhaalde informatie (een deel van de sleutel en de niet-sleutelattributen die deze definieert) in een aparte tabel te scheiden.

Bijvoorbeeld: in de database is het nodig om informatie op te slaan over goederen die aan winkels worden geleverd. Deze informatie omvat de attributen “Naam”, “Code” en “Prijs” van het product, evenals de “Aantal” van het geleverde product. Als u deze informatie opneemt in de tabel "Benodigdheden" in volgende optreden:

"Benodigdheden"

(hier identificeert “TIN” de winkel waaraan de levering heeft plaatsgevonden (dit is een externe sleutel die wordt gebruikt om een één-op-veel-relatie te creëren tussen de tabel “Winkels” en deze tabel), “Naam” is de naam van het product , “Code” is de unieke code (producten met verschillende kenmerken en daarom kunnen verschillende prijzen dezelfde naam hebben, maar de codes zullen verschillend zijn), “Prijs” is de verkoopprijs van het product, “Hoeveelheid” is de hoeveelheid van het geleverde product), dan kan er redundantie ontstaan.

Om een regel te definiëren die de levering van goederen aan een specifieke winkel vertegenwoordigt, kunt u een samengestelde sleutel opgeven die de attributen “TIN” en “Code” bevat. Deze informatie maakt het mogelijk om de prijs van het product en de geleverde hoeveelheid te bepalen deze winkel en bereken ook de totale kosten van de goederen. Als we aannemen dat het product tegen dezelfde prijs aan alle winkels wordt geleverd en dat de prijs in de loop van de tijd niet verandert, wordt het niet-sleutelkenmerk 'Prijs' niet alleen bepaald door de samengestelde sleutel 'TIN' + 'Code', maar ook zijn deel - het attribuut “Code” " Zo wordt dezelfde prijs herhaald in alle rijen van de tabel, die informatie bevatten over het aanbod van hetzelfde product. Dit leidt tot redundantie. De naam van het product wordt ook bepaald door de code. Daarom kan informatie die alleen betrekking heeft op het product en niet afhankelijk is van de winkel, in een aparte tabel worden geplaatst:

Hier kunt u via het sleutelveld “Code” de gegevens uit de tabel “Aanbod” koppelen aan de gegevens uit de tabel “Producten”

Door de reductie naar de tweede normaalvorm werd dus overtolligheid geëlimineerd door nieuwe tabellen te scheiden: de tabel “Aanbod” is verdeeld in twee tabellen “Aanbod” en “Goederen”, waartussen een relatie tot stand wordt gebracht.

Derde normaalvorm verhoogt de vereisten verder: de relatie komt overeen met de tweede normaalvorm en er zijn geen transitieve functionele afhankelijkheden tussen de attributen ervan (geen enkele niet-sleutelkolom mag afhankelijk zijn van een andere niet-sleutelkolom, deze kan alleen afhankelijk zijn van de primaire sleutel).

In het onderhavige voorbeeld zou er sprake zijn van een discrepantie met de derde normaalvorm als aan de volgende voorwaarde wordt voldaan: alle goederen met dezelfde naam hebben dezelfde prijs (de naam wordt bepaald door de code, en de prijs door de naam van de product). In dit geval zou er sprake zijn van redundantie, aangezien de prijs voor een bepaalde productnaam net zo vaak zou worden herhaald als er verschillende codes voor dit product worden gebruikt.

Het zou mogelijk zijn om van redundantie af te komen door de tabel “Producten” in twee tabellen te verdelen (de ene zou de attributen “Code” en “Naam” bevatten, en de tweede “Naam” en “Prijs”).

In het onderhavige voorbeeld is de situatie echter anders: goederen wel verschillende codes Als hun kenmerken verschillend zijn, moeten de prijzen daarom verschillend zijn.

Vierde normaalvorm verbiedt onafhankelijke één-op-veel-relaties tussen sleutel- en niet-sleutelkolommen. Simpel gezegd: heterogene informatie kan niet in één tabel worden geplaatst, d.w.z. gegevens waartussen geen direct verband bestaat.

Deze regel is te zien in het volgende voorbeeld. De medewerker klantrelaties is van plan informatie over familieleden van winkeleigenaren te gebruiken bij de uitvoering van zijn taken. Deze informatie mag niet worden opgenomen in de tabel Eigenaren, omdat het moeilijk is om te bepalen hoeveel ruimte er moet worden gereserveerd in de tabelrijen die overeenkomen met specifieke mensen, om gegevens over hen op te slaan burgerlijke staat, – de een is misschien alleenstaand, de ander is misschien vader van veel kinderen. Informatie over gezinsleden moet in een aparte tabel worden geplaatst, waarbij elke rij informatie over één gezinslid bevat, inclusief een externe sleutel die de winkeleigenaar identificeert om een verbinding met de tabel 'Eigenaren' te organiseren.

Vijfde normaalvorm voltooit meestal het normalisatieproces. In dit stadium zijn alle tabellen verdeeld in minimale delen om redundantie daarin te elimineren. Elk stukje niet-sleutelgegevens in tabellen mag slechts één keer voorkomen. Dit elimineert problemen met het bijwerken van informatie in de database: alle wijzigingen in niet-essentiële informatie hoeven slechts één keer te worden aangebracht, wat de mogelijkheid biedt om de gegevensintegriteit te beheren.

Het databaseontwerpproces is zeer belangrijke fase bij de ontwikkeling van informatiesystemen. Het is de kwaliteit van het ontwerp die voor een groot deel de effectiviteit van het gebruik van de database bepaalt.

Momenteel veel gebruikt speciale middelen, het faciliteren van het proces van het ontwikkelen van informatiesystemen (CASE-tools - Computer-Aided Software/System Engineering).

Vragen voor zelfbeheersing:

1. Wat is een databank?

2. Wat is externe gegevensrepresentatie?

3. Wat is de essentie van de conceptuele representatie van data?

4. Wat is een datamodel?

5. Wat is normalisatie?

6. Wat is een relatiesleutel?

7. Welke sleutel wordt een externe sleutel genoemd?

8. Welke verbindingen kunnen in de database worden georganiseerd?

9. Wat is de essentie van elk van de vijf normaalvormen?

Opdracht voor zelfstandig werk:

Ontwerp de databases van een klantenservicebedrijf. Drie medewerkers van het bedrijf hebben de database nodig. De eerste behandelt de boekhouding van de door het bedrijf geleverde diensten en behoeften de volgende informatie:

De tweede medewerker verzamelt informatie over de artiesten en is geïnteresseerd in:

De derde medewerker werkt met klanten en het is voor hem belangrijk om dit te weten.

Het ontwerpen van databases van informatiesystemen is een nogal arbeidsintensieve taak. Het wordt uitgevoerd op basis van formalisering van structuur en processen vakgebied, informatie waarover in de database zou moeten worden opgeslagen. Er zijn conceptuele en schematisch-structurele ontwerpen.

Het conceptuele ontwerp van een IS-database is grotendeels een heuristisch proces. De geschiktheid van het informationologische model van het vakgebied dat binnen het kader ervan is opgebouwd, wordt experimenteel geverifieerd tijdens het functioneren van de IS.

Laten we de fasen op een rij zetten conceptueel ontwerp :

· het vakgebied bestuderen om er een algemeen idee van te krijgen;

· identificatie en analyse van de functies en taken van de ontwikkelde IS;

· bepaling van de belangrijkste objecten-entiteiten van het vakgebied en de relaties daartussen;

· geformaliseerde vertegenwoordiging van het vakgebied.

Bij het ontwerpen van een relationeel databaseschema kunnen de volgende procedures worden onderscheiden:

· het definiëren van een lijst met tabellen en de relaties daartussen;

· het bepalen van de lijst met velden, veldtypen en sleutelvelden van elke tabel (tabelschema), het tot stand brengen van verbindingen tussen tabellen via externe sleutels;

· het opzetten van indexering voor velden in tabellen;

· ontwikkeling van lijsten (woordenboeken) voor velden met enumeratieve gegevens;

· het vaststellen van integriteitsbeperkingen voor tabellen en relaties;

· normalisatie van tabellen, aanpassing van de lijst met tabellen en relaties.

Databaseontwerp wordt uitgevoerd op de fysieke en logische niveaus. Ontwerp aan fysiek niveau geïmplementeerd met behulp van DBMS en vaak geautomatiseerd.

Logisch ontwerp bestaat uit het bepalen van het aantal en de structuur van tabellen, het ontwikkelen van databasequery's, het rapporteren van documenten, het maken van formulieren voor het invoeren en bewerken van gegevens in de database, enz.

Een van belangrijkste taken logisch ontwerp DB is gegevensstructurering. Er wordt onderscheid gemaakt tussen: benadert voor het ontwerpen van datastructuren:

· het combineren van informatie over entiteitsobjecten binnen één tabel (één relatie) met daaropvolgende ontleding in verschillende onderling gerelateerde tabellen op basis van de procedure voor het normaliseren van relaties;

· het formuleren van kennis over het systeem (het bepalen van de soorten brondata en relaties) en eisen voor dataverwerking, het verkrijgen van een kant-en-klaar databaseschema of zelfs een kant-en-klaar applicatie-informatiesysteem met behulp van het CASE-systeem;

· implementatie systeem analyse en ontwikkeling van structurele modellen.

De eerste benadering is klassiek.

Het ontwerpproces begint met het identificeren van entiteitsobjecten, waarvan informatie in de database wordt opgeslagen, en het definiëren van hun attributen. De geselecteerde attributen worden gecombineerd in één tabel (relatie).

Volledige informatie over de essentie (tabel) geeft redundantie (herhaling), Þ transformatie is vereist, d.w.z. ontbinding, d.w.z. opsplitsen in verschillende tabellen, d.w.z. normalisatie.

Þ De resulterende verhouding is onderhevig aan normalisatie. De normalisatieprocedure is iteratief en bestaat uit de opeenvolgende overdracht van relaties van de eerste normaalvorm naar normale vormen van een hogere orde.

De volgende reeks normaalvormen wordt onderscheiden:

· eerste normaalvorm (1NF);

· tweede normaalvorm (2NF=1NF+iets);

· derde normaalvorm (ZNF=2NF+iets);

· verbeterde derde normale vorm, of Boyce-Codd normale vorm (BCNF);

· vierde normaalvorm (4NF);

· vijfde normaalvorm (5NF).

(Vereisten voor 2NF)

correleert alleen met de primaire sleutel. Þ Alle gegevens worden slechts op één plaats in de database opgeslagen. Þ De gedupliceerde gegevens worden naar een andere tabel verplaatst en in plaats daarvan worden externe sleutels gebruikt.

(Vereisten voor 3NF)

Elk niet-sleutelveld mag niet afhankelijk zijn van een ander niet-sleutelveld (bijvoorbeeld een relatie tussen docent en afdeling, of een relatie tussen vak en afdeling). Om dit te voorkomen, moet u het vakgebied tot in detail kennen. Þ We verwijderen de “faculteit” uit het “Schema” als daar een “Specialiteit” aanwezig is.

3NF biedt declaratieve referentialiteit (gegevens uit directory's).

(Vereisten voor 4NF)

Met normalisatie kunt u informatieredundantie elimineren, wat leidt tot afwijkingen in de gegevensverwerking.

Tegelijkertijd moet onderscheid worden gemaakt tussen niet-redundante en redundante gegevensduplicatie. De aanwezigheid van de eerste in databases is toegestaan. Hier zijn voorbeelden van beide duplicatieopties.

Een voorbeeld van niet-redundante gegevensduplicatie is de “PHONES”-relatie (Fig. 5.6). Stel dat er in één kamer maar één telefoon is geïnstalleerd, dan zijn de telefoonnummers van medewerkers die zich in dezelfde kamer bevinden hetzelfde. Het telefoonnummer 24212 komt meerdere keren voor. Dit is duplicatie. Het nummer is echter voor elke medewerker uniek en als een van de nummers wordt verwijderd, gaat de informatie verloren over welk nummer kan worden gebruikt om een bepaalde medewerker te bereiken. Dit is de essentie van niet-redundantie.

Rijst. 5.6. Niet-redundante gegevensduplicatie

Overmatige duplicatie van gegevens vindt plaats in de relatie “ROOMS”, waaraan het attribuut “Room Number” is toegevoegd (Fig. 5.7).

Rijst. 5.7. Overmatige gegevensduplicatie

Medewerkers Belkin, Sinitsyn en Medvedev zitten in dezelfde kamer en hebben dus dezelfde nummers. Dat wil zeggen, het telefoonnummer van Sinitsyn en Medvedev is te vinden in de stoet met informatie over Belkin. Dit is de redundantie van gegevensduplicatie.

Overmatige duplicatie van gegevens leidt tot problemen bij het verwerken van relatie-tuples, door E. Codd “relation update anomalies” genoemd.

Afwijkingen- dergelijke situaties in databasetabellen die tot tegenstrijdigheden in de database leiden of de gegevensverwerking aanzienlijk bemoeilijken.

Er zijn drie hoofdtypen afwijkingen:

· wijziging (bewerken) afwijkingen;

· verwijderingsafwijkingen;

· toevoegingsafwijkingen.

Wijzigingsafwijkingen manifesteren zich in het feit dat een verandering in de waarde van een attribuut een herziening van de gehele tabel met zich mee kan brengen met een overeenkomstige verandering in de waarden van dit attribuut in andere tabelrecords.

Als u het telefoonnummer in kamer 325 (Fig. 5.7) wilt wijzigen, moet u dus de volledige tabel "ROOMS" herzien en de waarden van het attribuut "Phone Number" wijzigen in de records waarin dit nummer voorkomt.

Anomalieën bij het verwijderen manifesteren zich in het feit dat wanneer een attribuutwaarde wordt verwijderd, andere informatie die niet direct verband houdt met de verwijderde waarde, zal verdwijnen.

Het verwijderen van een record over werknemer Volkov (bijvoorbeeld vanwege ontslag) leidt dus tot het verdwijnen van informatie over het telefoonnummer dat in kamer 320 is geïnstalleerd (zie figuur 5.7).

Toevoegingsafwijkingen manifesteren zich in het feit dat het onmogelijk is een record aan een tabel toe te voegen totdat de waarden van al zijn attributen bekend zijn, en ook in het feit dat het invoegen nieuwe invoer vereist een herziening van de gehele tabel.

In de tabel “KAMERS” (zie Fig. 5.7) is het bijvoorbeeld onmogelijk om informatie weer te geven over een kamer waarin een telefoon is geïnstalleerd totdat er geen medewerker in is geplaatst (op voorwaarde dat het veld “Naam” het belangrijkste veld is). .

Wanneer u informatie over een nieuwe medewerker aan de tabel toevoegt, moet u bovendien de tabel controleren op inconsistenties die kunnen ontstaan wanneer foutieve invoer telefoon- of kamernummers. Voorbeeld van een tegenstrijdigheid: medewerkers bevinden zich in dezelfde kamer, maar hebben dat wel gedaan verschillende nummers telefoons.

Een manier om excessieve duplicatie te elimineren en anomalieën te neutraliseren is decompositie, dat wil zeggen het splitsen van de oorspronkelijke relatie (tabel). De ontleding moet omkeerbaar zijn, dat wil zeggen uitgevoerd zonder verlies van informatie

Relationeel model gegevens (RMD) van een bepaald vakgebied zijn een reeks relaties die in de loop van de tijd veranderen. Wanneer u een informatiesysteem maakt, kunt u met een reeks relaties gegevens over objecten in het onderwerpgebied opslaan en de verbindingen daartussen modelleren.

Een relationele database is een datawarehouse dat een set tweedimensionale tabellen bevat. De gegevens in de tabellen moeten aan de volgende principes voldoen.

1. Attribuutwaarden (kolom, veld) moeten atomair zijn (met andere woorden, elke waarde op het snijpunt van een rij en een kolom mag niet in verschillende waarden worden verdeeld).

2. De waarden van elk veld moeten van hetzelfde type zijn.

3. Elke vermelding in de tabel is uniek.

4. Elk veld heeft een unieke naam.

5. De volgorde van velden en records in de tabel is niet belangrijk

Houding is een essentieel concept en is een tweedimensionale tabel die enkele gegevens bevat.

Essentie is een object elk aard, waarvan gegevens zijn opgeslagen in een database. Entiteitsgegevens worden opgeslagen in een relatie.

Attributen zijn eigenschappen die een entiteit karakteriseren. In de tabelstructuur heeft elk attribuut een naam en komt overeen met de kop van een bepaalde tabelkolom.

Relatiesleutel is de verzameling attributen die elk van de tupels van de relatie op unieke wijze identificeert.

Sleutels worden meestal gebruikt om de volgende doeleinden te bereiken:

Eliminatie van dubbele waarden in sleutelvelden;

Records bestellen. Het is mogelijk om de waarden van alle sleutelvelden in oplopende of aflopende volgorde te ordenen, evenals een gemengde volgorde (voor sommigen - oplopend en voor anderen - afnemend);

Tabel die organisaties koppelt.

Het concept van een externe sleutel is belangrijk. Een externe sleutel kan worden gedefinieerd als een reeks attributen van een enkele relatie R2, waarvan de waarden moeten overeenkomen met de waarden mogelijke sleutel andere houding R1.

Op relaties kan een systeem van bewerkingen worden toegepast, waardoor de ene uit de andere kan worden afgeleid. Het resultaat van een zoekopdracht naar een relationele database kan bijvoorbeeld een nieuwe relatie zijn, berekend op basis van bestaande relaties. Daarom is het mogelijk om de verwerkte gegevens op te splitsen in opgeslagen en berekende delen. De belangrijkste eenheid van gegevensverwerking in relationele databases is de relatie, en niet de individuele tupels (records).

Het ontwerpen van databases van informatiesystemen is een nogal arbeidsintensieve taak. Het wordt uitgevoerd op basis van het formaliseren van de structuur en processen van het vakgebied, waarvan informatie in de database zou moeten worden opgeslagen. Onderscheiden conceptueel en circuit- structureel ontwerp.

Laten we de stadia van conceptueel ontwerp opsommen:

Het bestuderen van het vakgebied om te vormen algemeen idee over haar;

Identificatie en analyse van functies en taken van de ontwikkelde IS;

Bepaling van de belangrijkste objecten-entiteiten van het vakgebied en de relaties daartussen;

Geformaliseerde vertegenwoordiging van het vakgebied.

Bij het ontwerpen van een relationeel databaseschema kunt u onderscheid maken volgende procedures :

Het bepalen van de lijst met tabellen en de relaties daartussen;

Het bepalen van de lijst met velden, veldtypen en sleutelvelden van elke tabel (tabelschema), het tot stand brengen van relaties tussen tabellen via externe sleutels;

Indexering voor velden in tabellen tot stand brengen;

Ontwikkeling van lijsten (woordenboeken) voor velden met enumeratieve gegevens;

Het vaststellen van integriteitsbeperkingen voor tabellen en relaties;

Normalisatie van tabellen, aanpassing van de lijst met tabellen en relaties.

Databaseontwerp wordt uitgevoerd op fysiek en logisch niveau. Ontwerp op fysiek niveau wordt geïmplementeerd met behulp van DBMS en is vaak geautomatiseerd.

Een van de belangrijkste taken van het ontwerpen van logische databases is het structureren van gegevens. Er worden de volgende benaderingen voor het ontwerpen van datastructuren onderscheiden:

Het combineren van informatie over entiteitsobjecten binnen één tabel (één relatie) met daaropvolgende ontleding in verschillende onderling gerelateerde tabellen op basis van de relatienormalisatieprocedure;

Het formuleren van kennis over het systeem (het bepalen van de soorten brondata en relaties) en eisen voor dataverwerking, het verkrijgen van een kant-en-klaar databaseschema of zelfs een kant-en-klaar applicatie-informatiesysteem met behulp van een CASE-systeem;

Het uitvoeren van systeemanalyses en het ontwikkelen van structuurmodellen.

Vertaling van een serie van 15 artikelen over databaseontwerp.
De informatie is bedoeld voor beginners.
Heeft mij geholpen. Misschien helpt het iemand anders om de gaten op te vullen.

Handleiding voor databaseontwerp.

1. Inleiding.

Als je gaat creëren eigen bases gegevens, is het een goed idee om de richtlijnen voor databaseontwerp te volgen om de integriteit op de lange termijn en het onderhoudsgemak van uw gegevens te garanderen. In deze handleiding leest u wat databases zijn en hoe u een database ontwerpt die de regels van relationeel databaseontwerp volgt.

Databases zijn programma's waarmee u grote hoeveelheden gegevens kunt opslaan en ophalen gerelateerde informatie. Databases bestaan uit tafels, die bevatten informatie. Wanneer u een database maakt, moet u nadenken over wat tafels je moet creëren en wat communicatie bestaan tussen de informatie in de tabellen. Met andere woorden: je moet erover nadenken project uw databank. Leuk project database, zoals eerder vermeld, zal de gegevensintegriteit en het onderhoudsgemak garanderen.

Er wordt een database gemaakt om informatie daarin op te slaan en deze informatie op te halen wanneer dat nodig is. Dit betekent dat we moeten kunnen plaatsen, invoegen ( INVOEGEN) informatie in de database en we willen informatie uit de database kunnen ophalen ( SELECTEER).
Voor deze doeleinden werd een databasequerytaal uitgevonden, genaamd Gestructureerde querytaal of SQL. De bewerkingen van het invoegen van gegevens (INSERT) en het selecteren ervan (SELECT) maken deel uit van deze taal. Hieronder ziet u een voorbeeld van een verzoek om gegevens op te halen en het resultaat ervan.

SQL is een belangrijk onderwerp en valt buiten het bestek van deze tutorial. Dit artikel is strikt gericht op presenteren databaseontwerpproces. Later, binnen aparte handleiding, behandel ik de basisprincipes van SQL.

Relationeel model.

In deze zelfstudie laat ik u zien hoe u een relationeel gegevensmodel maakt. Het relationele model is een model dat beschrijft hoe gegevens in tabellen moeten worden georganiseerd en hoe relaties tussen die tabellen kunnen worden gedefinieerd.

Regels relationeel model dicteren hoe informatie in tabellen moet worden georganiseerd en hoe tabellen zich tot elkaar verhouden. Uiteindelijk kan het resultaat worden gepresenteerd in de vorm van een databasediagram of, preciezer gezegd, een entiteit-relatiediagram, zoals in de figuur (voorbeeld overgenomen uit MySQL-werkbank).

Voorbeelden.

Ik heb een aantal toepassingen als voorbeeld in de handleiding gebruikt.

RDBMS.

Het RDBMS dat ik gebruikte om de voorbeeldtabellen te maken was MySQL. MySQL is het populairste RDBMS en is gratis.

Hulpprogramma voor databasebeheer.

Na MySQL-installaties je krijgt alleen de interface opdrachtregel om te communiceren met MySQL. Persoonlijk geef ik de voorkeur aan een GUI om mijn databases te beheren. Ik gebruik vaak SQLyog. Dit gratis hulpprogramma Met grafische interface. Afbeeldingen van tafels in deze handleiding vandaar genomen.

Visuele modellering.

Er is een uitstekende gratis applicatie MySQL-werkbank. Hiermee kunt u uw database grafisch ontwerpen. De diagramafbeeldingen in de handleiding zijn in dit programma gemaakt.

Ontwerp onafhankelijk van RDBMS.

Het is belangrijk om te weten dat, hoewel deze handleiding voorbeelden geeft voor MySQL, het databaseontwerp onafhankelijk is van RDBMS. Dit betekent dat de informatie van toepassing is op relationele databases in het algemeen, en niet alleen op MySQL. U kunt de kennis uit deze tutorial toepassen op alle relationele databases zoals Mysql, Postgresql, Microsoft-toegang, Microsoft SQL of Oracle.

In het volgende deel zal ik het kort hebben over de evolutie van databases. Je leert waar databases en het relationele datamodel vandaan komen.

2. Geschiedenis.

In de jaren zeventig en tachtig, toen computerwetenschappers nog bruine smokings en brillen met grote, vierkante monturen droegen, werden gegevens ongestructureerd opgeslagen in bestanden die tekstdocument met gegevens gescheiden door (meestal) komma's of tabs.

Zo zagen IT-professionals er in de jaren zeventig uit. (Linksonder staat Bill Gates).

Tekstbestanden worden nog steeds gebruikt om kleine hoeveelheden eenvoudige informatie op te slaan. Door komma's gescheiden waarden (CSV) - door komma's gescheiden waarden zijn tegenwoordig erg populair en worden breed ondersteund door verschillende software en besturingssystemen. MicrosoftExcel is een voorbeeld van programma's die met CSV-bestanden kunnen werken. Gegevens die in zo’n bestand zijn opgeslagen, kunnen door een computerprogramma worden gelezen.

Hierboven ziet u een voorbeeld van hoe zo'n bestand eruit zou kunnen zien. Programma lezen dit bestand, moet worden gewaarschuwd dat de gegevens worden gescheiden door komma's. Als het programma de categorie waarin de les zich bevindt wil selecteren en weergeven "Databaseontwerp-tutorial", dan moet ze regel voor regel lezen totdat de woorden zijn gevonden "Databaseontwerp-tutorial" en dan zal ze het woord na de komma moeten lezen om de categorie af te leiden Software.

Databasetabellen.

Een bestand regel voor regel lezen is niet erg efficiënt. In een relationele database worden gegevens opgeslagen in tabellen. De onderstaande tabel bevat dezelfde gegevens als het bestand. Elke regel of “invoer” bevat één les. Elke kolom bevat een eigenschap van de les. In dit geval is dit de titel en de categorie ervan.

Een computerprogramma zou in de tutorial_id-kolom van een bepaalde tabel kunnen zoeken naar een specifieke tutorial_id om snel de bijbehorende titel en categorie te vinden. Dit is veel sneller dan het bestand regel voor regel doorzoeken, net zoals een programma dat doet in een tekstbestand.

Moderne relationele databases zijn zo ontworpen dat gegevens zeer snel uit specifieke rijen, kolommen en meerdere tabellen tegelijk kunnen worden opgehaald.

Geschiedenis van het relationele model.

Het relationele databasemodel werd in de jaren zeventig uitgevonden door Edgar Codd, een Britse wetenschapper. Hij wilde zijn tekortkomingen overwinnen netwerkmodel databanken en hiërarchisch model. En daarin was hij zeer succesvol. Het relationele databasemodel wordt nu universeel geaccepteerd en overwogen krachtig model voor een efficiënte gegevensorganisatie.

Vandaag beschikbaar ruime keuze databasebeheersystemen: van kleine desktopapplicaties tot multifunctionele applicaties serversystemen met sterk geoptimaliseerde zoekmethoden. Hier zijn enkele van de meesten bekende systemen relationeel databasebeheer (RDBMS):

- Orakel– voornamelijk gebruikt voor professionele, grote toepassingen.
- MicrosoftSQL server– RDBMS Microsoft. Alleen beschikbaar voor besturingssysteem Ramen.
- mysql– een zeer populair RDBMS met open source broncode. Wordt veel gebruikt door zowel professionals als beginners. Wat heb je nog meer nodig?! Het is gratis.
- IBM– heeft een aantal RDBMS's, waarvan DB2 de bekendste is.
- Microsoft-toegang– RDBMS, dat op kantoor en thuis wordt gebruikt. In feite is het meer dan alleen een database. Met MS Access kunt u databases maken met een gebruikersinterface.
In het volgende deel zal ik je iets vertellen over de kenmerken van relationele databases.

3. Kenmerken van relationele databases.

Relationele databases zijn ontworpen voor snel opslaan en ontvangen grote volumes informatie. Hieronder staan enkele kenmerken van relationele databases en het relationele datamodel.

Sleutels gebruiken.

Elke rij met gegevens in een tabel wordt geïdentificeerd door een unieke ‘sleutel’, een zogenaamde primaire sleutel. Vaak is de primaire sleutel een automatisch oplopend (automatisch oplopend) getal (1,2,3,4, etc.). Gegevens in verschillende tabellen kunnen met behulp van sleutels aan elkaar worden gekoppeld. De primaire sleutelwaarden van de ene tabel kunnen worden toegevoegd aan de rijen (records) van een andere tabel, waardoor die records aan elkaar worden gekoppeld.

Gebruiken gestructureerde taal queries (SQL) kunnen gegevens uit verschillende tabellen die door een sleutel met elkaar verbonden zijn, in één keer worden geselecteerd. U kunt bijvoorbeeld een query maken die alle bestellingen uit de bestellingentabel selecteert die horen bij gebruikers-ID 3 (Mike) uit de gebruikerstabel. In de volgende delen zullen we verder over sleutels praten.

De id-kolom in deze tabel is de primaire sleutel. Elke record heeft een unieke primaire sleutel, vaak een nummer. De kolom gebruikersgroep is vreemde sleutel. Afgaande op de naam verwijst het blijkbaar naar een tabel die gebruikersgroepen bevat.

Geen gegevensredundantie.

In een databaseontwerp dat de regels van het relationele datamodel volgt, wordt elk stukje informatie, zoals de naam van een gebruiker, slechts op één plaats opgeslagen. Dit elimineert de noodzaak om op meerdere plaatsen met gegevens te werken. Dubbele gegevens worden gegevensredundantie genoemd en moeten worden vermeden goed project databases.

Invoerbeperking.

Met behulp van een relationele database kunt u bepalen welke gegevens in een kolom mogen worden opgeslagen. U kunt een veld maken dat gehele getallen bevat, decimale getallen, kleine stukjes tekst, grote stukjes tekst, datums, enz.

Wanneer u een databasetabel maakt, geeft u voor elke kolom een gegevenstype op. Varchar is bijvoorbeeld een gegevenstype voor kleine stukjes tekst met maximaal aantal tekens gelijk aan 255, en ints zijn getallen.

Naast de gegevenstypen kunt u met RDBMS de gegevens die u kunt invoeren verder beperken. Beperk bijvoorbeeld de lengte of forceer de uniciteit van de waarde van records deze kolom. Laatste beperking vaak gebruikt voor velden die bevatten registratie namen gebruikers (logins) of adressen e-mail.

Deze beperkingen geven u controle over de integriteit van uw gegevens en voorkomen situaties als de volgende:

Een adres (tekst) invoeren in het veld waar u een nummer verwacht te zien
- het invoeren van een regio-index met een lengte van dezelfde index van honderd tekens
- gebruikers aanmaken met dezelfde naam
- gebruikers aanmaken met hetzelfde e-mailadres
- voer het gewicht (getal) in het verjaardagsveld (datum) in

Behoud van de gegevensintegriteit.

Door veldeigenschappen aan te passen, tabellen te koppelen en beperkingen te configureren, kunt u de betrouwbaarheid van uw gegevens vergroten.

Toewijzing van rechten.

De meeste RDBMS'en bieden instellingen voor toegangsrechten waarmee u specifieke rechten kunt toewijzen bepaalde gebruikers. Sommige acties die voor de gebruiker kunnen worden toegestaan of geweigerd: SELECT, INSERT, DELETE, ALTER, CREATE, etc. Dit zijn bewerkingen die kunnen worden uitgevoerd met behulp van Structured Query Language (SQL).

Gestructureerde querytaal (SQL).

Om bepaalde bewerkingen op de database uit te voeren, zoals het opslaan van gegevens, het ophalen ervan en het wijzigen ervan, wordt een gestructureerde querytaal (SQL) gebruikt. SQL is relatief eenvoudig te begrijpen en maakt het mogelijk... en gestapelde selecties, zoals het ophalen van gerelateerde gegevens uit meerdere tabellen met behulp van SQL-instructie MEEDOEN. Zoals eerder vermeld, wordt SQL in deze tutorial niet besproken. Ik zal mij concentreren op databaseontwerp.

De manier waarop u uw database ontwerpt, heeft een directe invloed op de query's die u moet uitvoeren om gegevens uit de database op te halen. Dit is nog een reden waarom je moet nadenken over wat je basis zou moeten zijn. Met een goed ontworpen database kunnen uw zoekopdrachten overzichtelijker en eenvoudiger zijn.

Draagbaarheid.

Het relationele datamodel is standaard. Door de regels van het relationele datamodel te volgen, kunt u er zeker van zijn dat uw gegevens relatief eenvoudig naar een ander RDBMS kunnen worden overgebracht.

Zoals eerder vermeld, is databaseontwerp een kwestie van het identificeren van gegevens, het relateren ervan en het opslaan van de resultaten van de beslissing. deze kwestie op papier (of computerprogramma). Ontwerp een database die onafhankelijk is van het RDBMS dat u wilt gebruiken om deze te maken.

In het volgende deel gaan we dieper in op primaire sleutels.

Annotatie: Deze lezing vormt het begin van een reeks van vier lezingen over relationeel databaseontwerp. In deze lezing zullen we het hebben over het normaliseren van relatiediagrammen, waarbij we alleen rekening houden met functionele afhankelijkheden tussen relatieattributen. Deze "eerste stappen" van normalisatie resulteren in een databaseontwerp waarin alle relatievariabelen de normale Boyce-Codd-vorm hebben, wat over het algemeen als bevredigend wordt beschouwd voor de meeste toepassingen.

Invoering

Bij het ontwerpen van een database worden twee hoofdproblemen opgelost.

Hoe kunnen we domeinobjecten in abstracte objecten van het datamodel in kaart brengen, zodat deze mapping niet in tegenspraak is met de semantiek van het domein en, indien mogelijk, de beste is (effectief, handig, etc.)? Dit probleem wordt vaak het probleem genoemd logisch ontwerp databases.
Hoe kan de efficiëntie van het uitvoeren van zoekopdrachten naar een database worden gegarandeerd, dat wil zeggen: hoe moeten, rekening houdend met de kenmerken van een bepaald DBMS, gegevens in het externe geheugen worden gerangschikt, welke aanvullende structuren (bijvoorbeeld indexen) moeten worden gemaakt, enz.? Dit probleem wordt gewoonlijk het fysieke databaseontwerpprobleem genoemd.

In het geval van relationele databases is het moeilijk om algemene recepten voor fysiek ontwerp te bieden. Hier hangt te veel af van het gebruikte DBMS. Daarom zullen we ons beperken tot vragen van logische aard relationeel databaseontwerp, die essentieel zijn bij het gebruik van relationele DBMS.

Bovendien zullen we elkaar niet erg aanraken belangrijk aspect ontwerp - het definiëren van integriteitsbeperkingen algemeen beeld(met uitzondering van beperkingen opgelegd door functionele en meerwaardige afhankelijkheden , evenals afhankelijkheden van projectie/join). Feit is dat het bij gebruik van een DBMS met ontwikkelde i(bijvoorbeeld SQL-georiënteerde systemen) moeilijk is om een universele benadering te bieden voor het definiëren van integriteitsbeperkingen. Deze beperkingen kunnen willekeurig complexe vormen aannemen, en de formulering ervan is nog steeds eerder een kwestie van kunst dan van techniek. Het meeste dat hierover in de literatuur wordt gesuggereerd is automatische controle consistentie van een reeks integriteitsbeperkingen.

Dus in deze en de volgende lezing gaan we ervan uit dat het probleem van het ontwerpen van een relationele database het nemen van weloverwogen beslissingen is over de relaties waaruit de database zou moeten bestaan en welke attributen die relaties zouden moeten hebben.

In deze en de volgende lezingen wordt de klassieke benadering onderzocht, waarbij het hele databaseontwerpproces wordt uitgevoerd in termen van een relationeel datamodel door middel van de methode van opeenvolgende benaderingen van een bevredigende reeks relatiepatronen. Het uitgangspunt is de representatie vakgebied in de vorm van een of meer relaties, en bij elke ontwerpstap wordt een bepaalde reeks relatieschema's geproduceerd die "verbeterde" eigenschappen hebben. Het ontwerpproces is normalisatie proces relatieschema's, met elke volgende normale vorm heeft in zekere zin eigenschappen die beter zijn dan de vorige.

Elke normaalvorm is verbonden met een bepaalde reeks beperkingen, en een relatie heeft een bepaalde normale vorm als deze voldoet aan de inherente reeks beperkingen. Een voorbeeld hiervan is een beperking eerste normaalvorm– de waarden van alle relatieattributen zijn atomair 1 Denk daar eens aan uit lezing 2 atomiciteit waarde wordt geïnterpreteerd in de zin dat de waarde wordt getypt, en deze waarde kan alleen worden gemanipuleerd met behulp van bewerkingen van het overeenkomstige gegevenstype.. Sinds de eis eerste normaalvorm een basisvereiste is van het klassieke relationele datamodel, gaan we ervan uit dat de initiële set relaties al aan deze vereiste voldoet.

IN relationele databasetheorieën valt meestal op volgende reeks normale vormen: