Ontwerpfasen van de database. Databasebeheersystemen. Fase II. Objectanalyse

Vertaling van een serie van 15 artikelen over database design.
De informatie is bedoeld voor beginners.
Hielp mij. Misschien helpt dat iemand anders om de leemtes op te vullen.

Handleiding voor databaseontwerp.

1. Inleiding.

Als u uw eigen databases gaat maken, is het een goed idee om u aan de ontwerpregels voor databases te houden, omdat dit de integriteit op lange termijn en het onderhoudsgemak van uw gegevens garandeert. Deze gids vertelt u wat databases zijn en hoe u een database ontwerpt die aan de ontwerpregels voldoet. relationele databases gegevens.

Databases zijn programma's waarmee u grote volumes kunt opslaan en ontvangen gerelateerde informatie... Databases bestaan ​​uit: tafels, die bevatten informatie... Wanneer u een database maakt, moet u nadenken over welke tafels je moet creëren en wat? verbindingen bestaan ​​tussen de informatie in de tabellen. Met andere woorden, u moet nadenken over het project uw databank. Goed project databases, zoals eerder vermeld, zorgen voor gegevensintegriteit en onderhoudsgemak.

De database is gemaakt om er informatie in op te slaan en indien nodig te verkrijgen. Dit betekent dat we moeten kunnen plaatsen, invoegen ( INSERT) informatie in de database en we willen informatie uit de database kunnen halen ( KIES).
De database-querytaal is voor dit doel uitgevonden en kreeg de naam Structured Query Language of SQL. Bewerkingen voor het invoegen van gegevens (INSERT) en hun selectie (SELECT) maken deel uit van deze taal. Hieronder ziet u een voorbeeld van een gegevensophaalquery en het resultaat ervan.

SQL is een belangrijk onderwerp voor het vertellen van verhalen en valt buiten het bestek van deze tutorial. Dit artikel is strikt gericht op presenteren database ontwerpproces... Later, in een aparte tutorial, zal ik de basis van SQL behandelen.

Het relationele model.

In deze tutorial laat ik je zien hoe je een relationeel datamodel maakt. Een relationeel model is een model dat beschrijft hoe gegevens in tabellen moeten worden georganiseerd en hoe relaties tussen die tabellen kunnen worden gedefinieerd.

De regels van het relationele model bepalen 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, meer precies, een entiteit-relatiediagram, zoals in de afbeelding (voorbeeld uit MySQL Workbench).

Voorbeelden.

In de tutorial heb ik een aantal toepassingen als voorbeeld gebruikt.

RDBMS.

Het RDBMS dat ik heb gebruikt om de voorbeeldtabellen te maken, is MySQL. MySQL is het meest populaire RDBMS en is gratis.

Hulpprogramma voor databasebeheer.

Na het installeren van MySQL krijg je alleen de interface opdrachtregel om te communiceren met MySQL. Persoonlijk geef ik de voorkeur aan een grafische interface voor het beheren van mijn databases. Ik gebruik SQLyog veel. het gratis hulpprogramma met een grafische interface. Afbeeldingen van tafels in deze handleiding vandaar genomen.

Visuele modellering.

Er is een uitstekende gratis app MySQL-werkbank. Hiermee kunt u uw database grafisch ontwerpen. De schema's in de handleiding worden in dit programma getoond.

Ontwerp onafhankelijk van RDBMS.

Het is belangrijk om te weten dat hoewel deze tutorial voorbeelden biedt voor MySQL, het databaseontwerp onafhankelijk is van het RDBMS. Dit betekent dat de informatie van toepassing is op relationele databases in het algemeen, niet alleen op MySQL. Je kunt kennis uit deze tutorial toepassen op elke relationele database zoals Mysql, Postgresql, Microsoft Access, Microsoft SQL of Oracle.

In het volgende deel zal ik het kort hebben over de evolutie van databases. U zult ontdekken waar de databases vandaan komen en relationeel model gegevens.

2. Geschiedenis.

In de jaren 70 en 80, toen computerwetenschappers nog bruine smokings droegen en grote glazen met vierkante randen, werden gegevens ongestructureerd opgeslagen in bestanden die Tekstdocument met gegevens gescheiden (meestal) door komma's of tabs.

Zo zagen IT-professionals eruit in de jaren 70. (Bill Gates staat linksonder).

Tekstbestanden worden vandaag de dag nog steeds gebruikt om kleine hoeveelheden eenvoudige informatie op te slaan. Door komma's gescheiden waarden (CSV) - door komma's gescheiden waarden zijn erg populair en worden tegenwoordig breed ondersteund door verschillende software en besturingssystemen. Microsoft Excel Is een van de voorbeelden van programma's die met CSV-bestanden kunnen werken. De gegevens die in zo'n bestand zijn opgeslagen, kunnen door een computerprogramma worden uitgelezen.

Hierboven ziet u een voorbeeld van hoe zo'n bestand eruit zou kunnen zien. Leesprogramma van dit bestand, moet worden gemeld dat de gegevens door komma's worden gescheiden. Als het programma de categorie wil selecteren en weergeven waarin de les zich bevindt "Zelfstudie database ontwerpen", dan moet het regel voor regel worden gelezen totdat er woorden zijn gevonden "Zelfstudie database ontwerpen" en dan moet ze het volgende woord na de komma lezen om de categorie weer te geven Software.

Database tabellen.

Een bestand regel voor regel lezen is niet erg efficiënt. In een relationele database worden gegevens opgeslagen in tabellen. Onderstaande tabel bevat dezelfde gegevens als het bestand. Elke regel of "record" bevat één les. Elke kolom bevat een leseigenschap. V in dit geval dit is de titel en de categorie.

Een computerprogramma kan in de kolom tutorial_id van deze tabel zoeken naar de 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 ontworpen om zeer snel gegevens uit specifieke rijen, kolommen en meerdere tabellen tegelijk te kunnen ophalen.

De geschiedenis van het relationele model.

Het relationele databasemodel is in de jaren 70 uitgevonden door Edgar Codd, een Britse wetenschapper. Hij wilde gebreken overwinnen netwerkmodel databases en hiërarchisch model... En daarin was hij zeer succesvol. Het relationele databasemodel wordt tegenwoordig algemeen aanvaard en wordt beschouwd als een krachtig model voor: efficiënte organisatie gegevens.

Er is tegenwoordig een breed scala aan databasebeheersystemen beschikbaar: van kleine desktopapplicaties tot multifunctioneel serversystemen met sterk geoptimaliseerde zoekmethoden. Hier zijn enkele van de meest bekende systemen relationeel databasebeheer (RDBMS):

- Orakel- voornamelijk gebruikt voor professionele, grote toepassingen.
- Microsoft SQL server- RDBMS Microsoft... Alleen beschikbaar voor besturingssysteem Ramen.
- Mysql Is een zeer populaire open source RDBMS. Het wordt veel gebruikt door zowel professionals als beginners. Wat is er nog meer nodig?! Het is gratis.
- IBM- heeft een aantal RDBMS, de meest bekende is DB2.
- Microsoft Access- RDBMS, dat zowel op kantoor als 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 iets uitleggen over de kenmerken van relationele databases.

3. Kenmerken van relationele databases.

Relationele databases zijn ontworpen voor: snel opslaan en het ontvangen van grote hoeveelheden informatie. Hieronder volgen 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", de primaire sleutel. Vaak, hoofdsleutel het is een automatisch oplopend (automatisch oplopend) getal (1,2,3,4, etc.). Gegevens in verschillende tabellen kunnen met sleutels aan elkaar worden gekoppeld. Primaire sleutelwaarden uit de ene tabel kunnen worden toegevoegd aan rijen (records) van een andere tabel, waardoor die records aan elkaar worden gekoppeld.

Gebruik makend van gestructureerde taal queries (SQL), gegevens van verschillende tafels die met een sleutel zijn verbonden, kunnen in één keer worden geselecteerd. U kunt bijvoorbeeld een query maken die alle bestellingen uit de tabel met bestellingen selecteert die behoren tot de gebruiker met id 3 (Mike) uit de tabel met gebruikers. We zullen verder praten over sleutels, in de volgende delen.

De id-kolom in deze tabel is de primaire sleutel. Elke record heeft een unieke primaire sleutel, vaak een nummer. De kolom gebruikersgroep is een externe sleutel. Zoals de naam al doet vermoeden, verwijst het blijkbaar naar een tabel die gebruikersgroepen bevat.

Geen gegevensredundantie.

In een databaseontwerp dat is gebouwd met behulp van de regels van het relationele datamodel, wordt elk stukje informatie, zoals een gebruikersnaam, op slechts één plaats opgeslagen. Dit elimineert de noodzaak om met gegevens op meerdere locaties te werken. Het dupliceren van gegevens wordt gegevensredundantie genoemd en moet bij een goed databaseontwerp worden vermeden.

Invoerbeperking.

Met behulp van een relationele database kunt u definiëren wat voor soort gegevens in een kolom mogen worden opgeslagen. U kunt een veld maken dat gehele getallen, decimalen, kleine stukken tekst, grote stukken tekst, datums, enz. bevat.

Wanneer u een databasetabel maakt, geeft u voor elke kolom een ​​gegevenstype op. Varchar is bijvoorbeeld een gegevenstype voor kleine stukjes tekst met Maximaal nummer tekens gelijk aan 255, en int zijn getallen.

Naast gegevenstypen kunt u met een RDBMS de gegevens die u kunt invoeren verder beperken. Beperk bijvoorbeeld de lengte of dwing de uniciteit van de waarde van records in deze kolom... De laatste beperking wordt vaak gebruikt voor velden die gebruikersregistratienamen (logins) of adressen bevatten E-mail.

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

Een adres (tekst) invoeren in het veld waar u een cijfer verwacht
- invoeren van de index van de regio met de lengte van dezelfde index in honderd tekens
- gebruikers met dezelfde naam maken
- gebruikers maken met hetzelfde e-mailadres
- gewicht (nummer) invoeren in het veld verjaardag (datum)

Behoud van gegevensintegriteit.

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

Toekenning van rechten.

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

Gestructureerde Query-taal (SQL).

Om bepaalde bewerkingen op de database uit te voeren, zoals het opslaan, ophalen en wijzigen van gegevens, wordt een gestructureerde querytaal (SQL) gebruikt. SQL is relatief eenvoudig te begrijpen en maakt het mogelijk incl. 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 me concentreren op het ontwerpen van databases.

Hoe u uw database ontwerpt, heeft een directe invloed op de query's die u moet uitvoeren om gegevens uit de database te krijgen. Dit is nog een reden waarom je moet nadenken over wat je basis zou moeten zijn. Met een goed ontworpen database kunnen uw zoekopdrachten schoner 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 kunnen worden gemigreerd naar een ander RDBMS.

Zoals eerder vermeld, is het ontwerpen van een database een kwestie van gegevens identificeren, aan elkaar koppelen en de resultaten van een oplossing plaatsen. dit probleem op papier (of in computerprogramma). Ontwerp de database onafhankelijk van het RDBMS dat u wilt gebruiken om deze te maken.

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

Basistaken van databaseontwerp

Belangrijkste doelen:

• Zorgen voor opslag in de database van alle benodigde informatie.
• De mogelijkheid bieden om gegevens te verkrijgen voor alle noodzakelijke verzoeken.
• Het verminderen van gegevensredundantie en duplicatie.
• Zorgen voor de integriteit van gegevens (juistheid van hun inhoud): opheffing van tegenstrijdigheden in de inhoud van gegevens, opheffing van hun verlies, enz.

De belangrijkste fasen van databaseontwerp

Conceptueel (infologisch) ontwerp- een semantisch model bouwen gebied, dat is informatiemodel het hoogste abstractieniveau. Een dergelijk model wordt gemaakt zonder zich te concentreren op een specifiek DBMS en datamodel. De termen "semantisch model", " conceptueel model" en " infologisch model"Zijn synoniem. Bovendien kunnen in deze context de woorden "databasemodel" en "domeinmodel" (bijvoorbeeld "conceptueel databasemodel" en "conceptueel domeinmodel") gelijkelijk worden gebruikt, aangezien een dergelijk model zowel een afbeelding van de werkelijkheid is als een afbeelding een geprojecteerde database voor deze realiteit.

Het specifieke type en de inhoud van het conceptuele model van de database wordt bepaald door het daarvoor gekozen formele apparaat. Grafische notaties vergelijkbaar met ER-diagrammen worden vaak gebruikt.

Meestal omvat het conceptuele databasemodel:

• Omschrijving informatie objecten, of concepten van het vakgebied en verbanden daartussen.
• een beschrijving van integriteitsbeperkingen, d.w.z. benodigdheden voor aanvaardbare waarden gegevens en de koppelingen daartussen.

Logisch (datalogisch) ontwerp- het creëren van een databaseschema op basis van een specifiek datamodel, bijvoorbeeld een relationeel datamodel. Voor een relationeel datamodel is een datalogisch model een set relatieschema's, die meestal primaire sleutels specificeren, evenals "relaties" tussen relaties, die refererende sleutels zijn.

Het conceptuele model omzetten naar logisch model, wordt in de regel uitgevoerd volgens formele regels. Deze fase kan grotendeels worden geautomatiseerd.

Op het podium logisch ontwerp er wordt rekening gehouden met de bijzonderheden specifiek model gegevens, maar er wordt mogelijk geen rekening gehouden met de bijzonderheden van een bepaald DBMS.

Fysiek ontwerp

Fysiek ontwerp- het creëren van een databaseschema voor een specifiek DBMS. De bijzonderheden van een bepaald DBMS kunnen beperkingen omvatten voor de naamgeving van database-objecten, beperkingen voor de ondersteunde gegevenstypen, enz. Bovendien omvat de specificiteit van een specifiek DBMS in fysiek ontwerp de keuze van oplossingen met betrekking tot: fysieke omgeving gegevensopslag (selectie van beheermethoden) schijf geheugen, het verdelen van de database op bestanden en apparaten, methoden voor gegevenstoegang), het maken van indexen, enz.

Normalisatie

Bij het ontwerpen van relationele databases wordt meestal zogenaamde normalisatie gedaan.

Entiteit-relatiemodellen

Het entiteit-relatiemodel (eng. "Entiteit-Relatiemodel" ), of het ER-model voorgesteld door P. Chen in 1976, is de meest bekende vertegenwoordiger van de klasse van semantische (conceptuele, infologische) modellen van het domein. Het ER-model wordt meestal in grafische vorm weergegeven, met behulp van de originele notatie van P. Chen, genaamd ER-diagram, of het gebruik van andere grafische notaties ( Kraaienpoot, Informatie-engineering en etc.).

De belangrijkste voordelen van ER-modellen:

• zichtbaarheid;
• modellen stellen u in staat databases te ontwerpen met grote hoeveelheid objecten en attributen;
• ER-modellen zijn in veel systemen geïmplementeerd computerondersteund ontwerp databases (bijvoorbeeld ERWin).

De belangrijkste elementen van ER-modellen:

• objecten (entiteiten);
• object attributen;
• verbindingen tussen objecten.

Een entiteit is een domeinobject dat attributen heeft.

De relatie tussen entiteiten wordt gekenmerkt door:

• communicatietype (1: 1, 1: N, N: M);
• klasse van toebehoren. De klasse kan verplicht of optioneel zijn. Als elke instantie van een entiteit deelneemt aan een relatie, is de lidmaatschapsklasse vereist, anders is deze optioneel.

Semantische modellen

Semantisch model (conceptueel model, infologisch model) - een domeinmodel dat is ontworpen om de semantiek van het domein hoog niveau abstractie. Dit betekent dat de noodzaak om 'low-level'-concepten te gebruiken die verband houden met de specifieke kenmerken van de fysieke presentatie en opslag van gegevens, is geëlimineerd of geminimaliseerd.

Datum KJ Inleiding tot databasesystemen. - 8e druk. - M.: "Williams", 2006:

Semantische modellering is het onderwerp geweest van intensief onderzoek sinds het einde van de jaren zeventig. Het belangrijkste motief achter dergelijke studies (d.w.z. het probleem dat de onderzoekers probeerden op te lossen) was het volgende feit. Het punt is dat databasesystemen meestal zeer beperkte kennis hebben over de betekenis van de gegevens die ze opslaan. Vaker wel dan niet, laten ze alleen manipulatie van bepaalde eenvoudige gegevenstypen toe en definiëren ze enkele van de eenvoudigste integriteitsbeperkingen die aan deze gegevens worden opgelegd. Elke meer complexe interpretatie wordt overgelaten aan de gebruiker. Het zou echter geweldig zijn als systemen een iets rijkere kennisbasis zouden hebben en een iets slimmere reactie op gebruikersverzoeken, en complexere (d.w.z. hogere) gebruikersinterfaces zouden ondersteunen.
[…]
Ideeën voor semantische modellering kunnen nuttig zijn als hulpmiddel voor het ontwerpen van databases, zelfs als ze niet rechtstreeks door het DBMS worden ondersteund.

De bekendste vertegenwoordiger van de klasse van semantische modellen is het entiteit-relatiemodel (ER-model).

Literatuur

• Datum CJ Inleiding tot databasesystemen. - 8e druk. - M.: "Williams", 2006. - 1328 d. - ISBN 0-321-19784-4
• Kogalovsky M.R. Geavanceerde technologieën informatie Systemen... - M.: DMK Pers; IT Co., 2003 .-- 288 p. - ISBN 5-279-02276-4
• Kogalovsky M.R. Encyclopedie van databasetechnologieën. - M.: Financiën en statistiek, 2002. - 800 p. - ISBN 5-279-02276-4
• SD Kuznetsov Basisprincipes van databases. - 2e druk. - M.: Internet Universiteit Informatie technologieën; BINOMIAAL. Kennislaboratorium, 2007. - 484 p. - ISBN 978-5-94774-736-2
• Connolly T., Begg K. Gegevensbestand. Ontwerp, implementatie en onderhoud. Theorie en praktijk = databasesystemen: een praktische benadering van ontwerp, implementatie en beheer. - 3e druk. - M.: "Williams", 2003. - 1436 d. - ISBN 0-201-70857-4
• Garcia-Molina G., Ullman J., Widom J. Database systemen. Cursus voltooien... - M.: "Williams", 2003. - 1088 d. - ISBN 5-8459-0384-X

zie ook

• Ontwerpmethoden

Links

• Entiteit-relatiemodel - een stap naar een uniforme kijk op data - Citforum
• Het relationele model uitbreiden om de semantiek beter weer te geven - Citforum
• Een beginnershandleiding voor het ontwerpen van websitedatabases
• Een methode voor het ontwerpen van de logische structuur van een relationele database zonder tabellen te normaliseren

Notities (bewerken)

Wikimedia Stichting. 2010.

Zie wat "Database Design" is in andere woordenboeken:

De databasebeheerder is de persoon die verantwoordelijk is voor de ontwikkeling van vereisten voor de database, het ontwerp, de implementatie, efficiënt gebruik en ondersteuning, inclusief management rekeningen databasegebruikers en bescherming tegen ongeautoriseerde ... ... Wikipedia

- (Engelse database refactoring) is een eenvoudige wijziging in het databaseschema, die bijdraagt ​​aan de verbetering van het ontwerp met behoud van de functionele en informatieve semantiek. Met andere woorden, het gevolg van database-refactoring kan niet zijn ... ... Wikipedia

ONTWERP- een van de vormen van anticiperende reflectie op de werkelijkheid, het proces van het creëren van een prototype (prototype) van het vermeende object, fenomeen of proces door middel van specifiek. methoden. P. is een specifieke vorm van manifestatie van prognostische. besturingsfuncties, ... ... Russische sociologische encyclopedie

Het "DB"-verzoek wordt hier omgeleid; zie ook andere betekenissen. Een database gepresenteerd in een objectieve vorm, een reeks onafhankelijke materialen (artikelen, berekeningen, verordeningen, rechterlijke uitspraken en ander soortgelijk materiaal), ... ... Wikipedia

Thema's: stadia van database-ontwerp, database-ontwerp gebaseerd op een model van het type object-relatie.

Voordat een database wordt gemaakt, moet de ontwikkelaar bepalen uit welke tabellen de database moet bestaan, welke gegevens in elke tabel moeten worden geplaatst en hoe de tabellen moeten worden gekoppeld. Deze problemen worden aangepakt in de fase van het databaseontwerp.

Als resultaat van het ontwerp moet de logische structuur van de database worden bepaald, dat wil zeggen, de samenstelling van relationele tabellen, hun structuur en intertabelkoppelingen.

Alvorens een database aan te maken, is het noodzakelijk om een ​​beschrijving te hebben van het geselecteerde onderwerpgebied, dat echte objecten en processen moet omvatten, alle noodzakelijke informatiebronnen moet bepalen om aan de verwachte gebruikersbehoeften te voldoen en de behoeften aan gegevensverwerking moet bepalen.

Op basis van een dergelijke beschrijving wordt in de ontwerpfase van de database de samenstelling en datastructuur van het vakgebied bepaald, die in de database moet staan ​​en de vervulling van de benodigde vragen en gebruikerstaken moet garanderen. De datastructuur van het vakgebied kan worden weergegeven door een informatie-logisch model. Op basis van dit model kan eenvoudig een relationele database worden gemaakt.

De fasen van het ontwerpen en maken van een database worden bepaald door de volgende volgorde:

Het bouwen van een informatie-logisch datamodel van het vakgebied;

Bepalen van de logische opbouw van een relationele database;

Database tabelontwerp;

Maken van gegevensschema's;

Gegevens invoeren in tabellen (records maken);

Ontwikkeling van de benodigde formulieren, aanvragen, macro's, modules, rapporten;

Ontwikkeling van gebruikersinterface.

Bij het ontwikkelen van een datamodel is het noodzakelijk informatieobjecten te selecteren die voldoen aan de eisen van datanormalisatie en de relaties daartussen te bepalen. Met dit model kunt u een relationele database maken zonder duplicatie, die eenmalige gegevensinvoer biedt tijdens het eerste laden en aanpassingen, evenals gegevensintegriteit wanneer wijzigingen worden aangebracht.

Bij het ontwikkelen van een datamodel kunnen twee benaderingen worden gevolgd. In de eerste benadering eerst worden de hoofdtaken bepaald, voor de oplossing waarvan de basis wordt gebouwd, worden de behoeften van de taken in data in kaart gebracht en op basis daarvan wordt de samenstelling en structuur van informatieobjecten bepaald. Met de tweede benadering de typische objecten van het onderwerpgebied worden onmiddellijk geïnstalleerd. De meest rationele combinatie van beide benaderingen. Dit komt door het feit dat er in de beginfase in de regel geen uitgebreide informatie over alle taken is. Het gebruik van deze technologie is des te meer gerechtvaardigd omdat flexibele middelen voor het creëren van relationele databases het mogelijk maken om in elk ontwikkelingsstadium wijzigingen aan te brengen in de database en de structuur ervan te wijzigen zonder afbreuk te doen aan de eerder ingevoerde gegevens.

Het proces van het identificeren van informatie-objecten van het vakgebied die voldoen aan de eisen van normalisatie kan worden uitgevoerd op basis van een intuïtieve of formele benadering. De theoretische grondslagen van de formele benadering zijn ontwikkeld en volledig beschreven in de monografieën over de organisatie van databases van de beroemde Amerikaanse wetenschapper J. Martin.

Met een intuïtieve benadering kunnen informatieobjecten die overeenkomen met echte objecten gemakkelijk worden geïdentificeerd. Het resulterende informatie-logische model vereist echter in de regel verdere transformaties, met name de transformatie van meerwaardige verbindingen tussen objecten. Met deze aanpak zijn grote fouten mogelijk als er niet genoeg ervaring is. Daaropvolgende verificatie van het voldoen aan de normalisatie-eisen geeft meestal de noodzaak aan om de informatie-objecten te verfijnen.

Overweeg de formele regels die kunnen worden gebruikt om informatie-objecten te markeren:

Identificeer op basis van de beschrijving van het onderwerpgebied documenten en hun attributen die in de database moeten worden opgeslagen;

Bepaal functionele afhankelijkheden tussen attributen;

Selecteer alle afhankelijke attributen en specificeer voor elk al zijn belangrijkste attributen, dat wil zeggen, die waarvan het afhankelijk is;

Groepeer attributen die even afhankelijk zijn van sleutelattributen. De resulterende afhankelijke attribuutgroepen vormen samen met hun belangrijkste attributen informatieobjecten.

Bij het definiëren van de logische structuur van een relationele database op basis van het model, wordt elk informatieobject adequaat weergegeven door een relationele tabel en komen de relaties tussen de tabellen overeen met de relaties tussen de informatieobjecten.

Tijdens het creatieproces worden eerst de databasetabellen geconstrueerd die overeenkomen met de informatieobjecten van het geconstrueerde datamodel. Verder kan een dataschema worden gemaakt, waarin de bestaande logische relaties tussen de tabellen worden vastgelegd. Deze links komen overeen met de links van informatieobjecten. Het gegevensschema kan worden geconfigureerd om de integriteit van de database te behouden als het gegevensmodel is ontworpen om te voldoen aan de normalisatievereisten. Gegevensintegriteit betekent dat de database relaties tussen records van verschillende tabellen heeft vastgesteld en correct heeft onderhouden bij het laden, toevoegen en verwijderen van records in gerelateerde tabellen, evenals bij het wijzigen van de waarden van sleutelvelden.

Na de vorming van het dataschema wordt de invoer van consistente gegevens uit de documenten van het vakgebied uitgevoerd.

Op basis van de aangemaakte database, vereiste vragen, formulieren, macro's, modules, rapporten die de vereiste verwerking van databasegegevens en hun presentatie uitvoeren.

Met ingebouwde tools en databasetools, a gebruikersomgeving, waarmee u de processen voor het invoeren, opslaan, verwerken, bijwerken en presenteren van database-informatie kunt beheren.

Een database ontwerpen op basis van een object-relatiemodel

Er is hele regel methoden voor het maken van informatie-logische modellen. Een van de momenteel meest populaire modelleringstechnieken maakt gebruik van ERD (Entity-Relationship Diagrams). In de Russischtalige literatuur worden deze diagrammen "object - relatie" of "entiteit - relatie" genoemd. Het ERD-model werd in 1976 voorgesteld door Peter Ping Sheng Chen. Tot op heden zijn er verschillende versies ontwikkeld, maar ze zijn allemaal gebaseerd op grafische diagrammen voorgesteld door Chen. Diagrammen zijn opgebouwd uit een klein aantal componenten. Vanwege hun heldere presentatie worden ze veel gebruikt in CASE-tools (Computer Aided Software Engineering).

Denk aan de gebruikte terminologie en notatie.

Entiteit- een echt of denkbeeldig object dat essentieel is voor het beschouwde onderwerpgebied, waarover informatie moet worden opgeslagen.

Elke entiteit moet een unieke identificatie hebben. Elke instantie van een entiteit moet uniek worden geïdentificeerd en onderscheiden van alle andere instanties van dit type(entiteiten).

Elke entiteit moet enkele eigenschappen hebben:

Hebben unieke naam; bovendien moet op deze naam altijd dezelfde interpretatie (definitie van de entiteit) worden toegepast. Omgekeerd kan dezelfde interpretatie niet worden toegepast op verschillende namen, tenzij het aliassen zijn;

Een of meer attributen hebben die ofwel tot een entiteit behoren of er door een relatie door worden geërfd;

Een of meer kenmerken hebben die elk exemplaar van een entiteit op unieke wijze identificeren.

Een entiteit kan onafhankelijk of afhankelijk zijn. Een teken van een afhankelijke entiteit is de aanwezigheid van attributen die zijn geërfd via een relatie (Fig. 1).

Elke entiteit kan een willekeurig aantal relaties hebben met andere entiteiten in het model.

Relatie- een benoemde associatie tussen twee entiteiten die van belang is voor het domein in kwestie. Een van de entiteiten die deelnemen aan de relatie is onafhankelijk, de bovenliggende entiteit genoemd, de andere is afhankelijk, de onderliggende of afstammelende entiteit. In de regel is elke instantie van de bovenliggende entiteit gekoppeld aan een willekeurig (inclusief nul) aantal instanties van de onderliggende entiteit. Elke instantie van een onderliggende entiteit is gekoppeld aan precies één instantie van een bovenliggende entiteit. Een instantie van een onderliggende entiteit kan dus alleen bestaan ​​als de bovenliggende entiteit bestaat.

De link krijgt een naam die wordt uitgedrukt door de grammaticale draai van het werkwoord en wordt in de buurt van de link geplaatst.

De naam van elke relatie tussen deze twee entiteiten moet uniek zijn, maar de relatienamen in het model hoeven niet uniek te zijn. Elke obligatie heeft een definitie. De definitie van een relatie wordt gevormd door de naam van de bovenliggende entiteit, de naam van de relatie, de uitdrukking van de mate van verwantschap en de naam van de afstammelende entiteit te combineren.

De relatie van een verkoper tot een contract kan bijvoorbeeld als volgt worden gedefinieerd:

De Verkoper kan een vergoeding ontvangen voor een of meer Contracten;

Het contract moet worden gestart door precies één Verkoper.

In het diagram wordt de verbinding weergegeven door een lijnstuk (onderbroken lijn). De uiteinden van het segment met behulp van speciale aanduidingen (Fig. 2) geven de mate van verbinding aan. Bovendien geeft de aard van de lijn - onderbroken of vast, de verplichte verbinding aan.

Attribuut- elk kenmerk van een entiteit dat van belang is voor het beschouwde vakgebied. Het is bedoeld om de toestand van een entiteit te kwalificeren, identificeren, classificeren, kwantificeren of uitdrukken. Een attribuut vertegenwoordigt een type kenmerken (eigenschappen) die zijn gekoppeld aan een reeks echte of abstracte objecten (mensen, plaatsen, gebeurtenissen, toestanden, ideeën, paren objecten, enz.) (Fig. 3).

Attribuutinstantie Is een specifiek kenmerk van een specifieke instantie van een entiteit. Een attribuutinstantie wordt bepaald door het type kenmerk (bijvoorbeeld 'Kleur') en de waarde ervan (bijvoorbeeld 'paars'), de waarde van het kenmerk genoemd. In het ER-model zijn attributen gekoppeld aan specifieke entiteiten. Elke instantie van een entiteit moet één specifieke waarde hebben voor elk van zijn attributen.

Het attribuut kan ofwel zijn: verplicht of optioneel... Verplicht betekent dat het attribuut geen null-waarden kan aannemen. Een attribuut kan ofwel beschrijvend zijn (dat wil zeggen een reguliere entiteitsdescriptor) of deel uitmaken van een unieke identifier (primaire sleutel).

Unieke identificator Is een attribuut of een set attributen en/of relaties die elk exemplaar van een bepaald entiteitstype op unieke wijze karakteriseren. Indien volledig geïdentificeerd, wordt een instantie van een bepaald entiteitstype volledig geïdentificeerd door zijn eigen sleutelattributen, in anders attributen van een andere entiteit, de ouder, zijn ook betrokken bij identificatie.

De aard van de identificatie wordt weergegeven in het diagram op de communicatielijn (Fig. 4).

Elk kenmerk wordt geïdentificeerd door een unieke zelfstandig naamwoord-zin die het kenmerk beschrijft dat door het kenmerk wordt vertegenwoordigd. Attributen worden weergegeven als een lijst met namen binnen het bijbehorende entiteitsblok, met elk attribuut op een aparte regel. De attributen die de primaire sleutel definiëren, worden bovenaan de lijst geplaatst en zijn gemarkeerd met een "#"-teken.

Elke entiteit moet ten minste één mogelijke sleutel hebben. Een mogelijke entiteitssleutel is een of meer attributen waarvan de waarden elke entiteitsinstantie op unieke wijze identificeren. Als er meerdere mogelijke sleutels zijn, wordt een ervan aangewezen als de primaire sleutel en de andere als alternatieve sleutels.

Momenteel is op basis van Chen's benadering de IDEF1X-methodologie ontwikkeld, die is ontwikkeld rekening houdend met eisen als leergemak en de mogelijkheid van automatisering. IDEFlX-diagrammen worden gebruikt door een aantal veelgebruikte CASE-tools (met name ERwin, Design / IDEF).

Een entiteit in de IDEF1X-methodologie wordt onafhankelijk van identifiers genoemd, of gewoon onafhankelijk, als elk exemplaar van een entiteit uniek kan worden geïdentificeerd zonder de relaties met andere entiteiten te definiëren. Een entiteit wordt identifier-afhankelijk of eenvoudigweg afhankelijk genoemd als de unieke identificatie van een entiteitsinstantie afhangt van de relatie met een andere entiteit (Figuur 5).

Elke entiteit krijgt een unieke naam en nummer toegewezen, gescheiden door een schuine streep "/" en boven het blok geplaatst.

Als een instantie van een onderliggende entiteit op unieke wijze wordt bepaald door de relatie met de bovenliggende entiteit, wordt de relatie identificerend genoemd, anders is deze niet-identificerend.

De identificerende relatie tussen de bovenliggende entiteit en de onderliggende entiteit wordt weergegeven met een ononderbroken lijn. In afb. 5: #2 is een afhankelijke entiteit, Link 1 is een identificerende relatie. Een onderliggende entiteit in een identificerende relatie is een identifier-afhankelijke entiteit. Een moederentiteit in een identificerende relatie kan een onafhankelijke of een identifier-afhankelijke entiteit zijn (dit wordt bepaald door haar relaties met andere entiteiten).

De stippellijn geeft een niet-identificerende relatie weer. In afb. 5: # 4 is een onafhankelijke entiteit, Link 2 is een niet-identificerende link. Een afstammelende entiteit in een niet-identificerende relatie zal onafhankelijk zijn van de identifier als het niet ook een afstammelende entiteit is in een identificerende relatie.

De relatie kan verder worden gedefinieerd door de graad of kardinaliteit te specificeren (het aantal instanties van de onderliggende entiteit dat kan bestaan ​​voor elke instantie van de bovenliggende entiteit).

De volgende kardinaliteiten kunnen worden uitgedrukt in IDEF1X:

Elke instantie van een bovenliggende entiteit kan nul, een of meer onderliggende entiteitinstanties hebben;

Elke instantie van een bovenliggende entiteit moet ten minste één gekoppelde instantie van een onderliggende entiteit hebben;

Elke instantie van een bovenliggende entiteit moet maximaal één gekoppelde instantie van een onderliggende entiteit hebben;

Elke instantie van een bovenliggende entiteit is gekoppeld aan een vast aantal onderliggende entiteitinstanties.

Het communicatievermogen wordt aangegeven zoals weergegeven in Fig. 6 (standaard vermogen) - N).

Attributen worden weergegeven als een lijst met namen binnen het entiteitsblok. De attributen die de primaire sleutel definiëren, worden bovenaan de lijst geplaatst en van andere attributen gescheiden door een horizontale balk (Figuur 7).

Het resultaat is een informatie-logisch model dat wordt gebruikt door een aantal gangbare CASE-tools, zoals ERwin, Design / IDEF. Op hun beurt hebben CASE-technologieën een groot potentieel bij de ontwikkeling van databases en informatiesystemen, namelijk het verhogen van de arbeidsproductiviteit, het verbeteren van de kwaliteit softwareproducten, ondersteuning voor een uniforme en consistente werkstijl.

Entiteiten kunnen ook een externe sleutel hebben. Bij een identificerende relatie worden ze gebruikt als een deel of een hele primaire sleutel, bij een niet-identificerende relatie dienen ze als niet-sleutelattributen. In de lijst met attributen wordt de refererende sleutel aangegeven met de letters FK tussen haakjes.

Het proces van het ontwerpen van een database is een opeenvolging van overgangen van een informele verbale beschrijving van de informatiestructuur van een vakgebied naar een geformaliseerde beschrijving van softwareobjecten in termen van een bepaald model. In het algemeen zijn de volgende ontwerpfasen te onderscheiden:

L. Systeemanalyse en verbale beschrijving van software-informatieobjecten... Er zijn twee manieren om de samenstelling en structuur van het onderwerpgebied te kiezen:

· Functionele benadering. Het implementeert het principe van beweging "van taken" en wordt gebruikt wanneer de functies van een bepaalde groep personen en complexen van taken bekend zijn, voor het voldoen aan de informatiebehoeften waarvan een database wordt gecreëerd. In dit geval kunt u duidelijk de noodzakelijke minimale set objecten te beschrijven.

· Onderwerp benadering. De informatiebehoeften van toekomstige gebruikers liggen niet vast. Het is onmogelijk om de vereiste minimale set objecten te selecteren die beschreven moeten worden. In dit geval omvat de beschrijving van de software de objecten en relaties die er het meest kenmerkend en essentieel voor zijn. De ontworpen database wordt een onderwerpdatabase genoemd en kan worden gebruikt voor een verscheidenheid aan verschillende, vooraf niet-gedefinieerde taken. Deze aanpak lijkt de meest veelbelovende, maar kan leiden tot redundantie van de taak of gebruikersbehoeften, en anderzijds houdt het rekening met de mogelijkheid om nieuwe applicaties te bouwen.

II. Ontwerpen van een infologisch softwaremodel. De taak van de infologische ontwerpfase: het verkrijgen van semantische (semantische) datamodellen (bijvoorbeeld in termen van ER-modellen), het weergeven van de informatie-inhoud van een specifieke software. Eerst wordt het benodigde deel van de software uit de gepercipieerde werkelijkheid gehaald, zijn grenzen bepaald en vindt de abstractie plaats van onbeduidende delen voor een specifieke toepassing van de database. Hierdoor worden objecten, hun eigenschappen en verbindingen bepaald, wat essentieel zal zijn voor toekomstige gebruikers van het systeem.

III. Datalogisch of logisch databaseontwerp, d.w.z. beschrijving van de database in termen van het geaccepteerde datalogische datamodel (bijvoorbeeld relationeel). De taak van de logische ontwerpfase is om de gegevens die in de vorige fase zijn geselecteerd, te ordenen in de vorm die wordt geaccepteerd in het geselecteerde specifieke DBMS, met behulp van de typen en gegevensmodellen. Aanbevelingen over de keuze van methoden voor gegevenstoegang worden gegeven.

NS. Fysiek ontwerp van de database, d.w.z. selectie van effectieve databaseplaatsing op externe media om de meest efficiënte werking van de applicatie te garanderen. De taak van de fysieke ontwerpfase is het kiezen van een rationele gegevensopslagstructuur. en methoden voor toegang ertoe, gebaseerd op het arsenaal aan tools en methoden die een specifiek DBMS aan de ontwikkelaar biedt.

Bij het ontwerpen van een database worden twee hoofdproblemen opgelost:

Hoe domeinobjecten toewijzen aan abstracte gegevensmodelobjecten? Dit probleem wordt het logische databaseontwerpprobleem genoemd.

Hoe zorgt u voor een efficiënte uitvoering van databasequery's, d.w.z. hoe, rekening houdend met de eigenaardigheden van een specifiek DBMS, de gegevens in extern geheugen, welke aanvullende structuren (bijvoorbeeld indexen) zijn vereist, enz.? Dit probleem wordt het fysieke databaseontwerpprobleem genoemd.

In het geval van relationele databases is het moeilijk om een ​​algemeen recept voor fysiek ontwerp te geven. Ook hier hangt veel af van het gebruikte DBMS. Daarom zullen we ons beperken tot de kwesties van logisch ontwerp van relationele databases, die essentieel zijn bij het gebruik van een relationeel DBMS.

Bovendien zullen we het niet hebben over een zeer belangrijk aspect van ontwerp - het definiëren van integriteitsbeperkingen (met uitzondering van de primaire sleutelbeperking). Het punt is dat bij het gebruik van een DBMS met ontwikkelde mechanismen van integriteitsbeperkingen (bijvoorbeeld SQL-georiënteerde systemen), het moeilijk is om een ​​algemene benadering voor te stellen voor het definiëren van integriteitsbeperkingen. Deze beperkingen kunnen zeer algemeen zijn, en hun formulering behoort tot nu toe tot het gebied van kunst in plaats van techniek. Het meest dat in de literatuur over deze kwestie wordt gesuggereerd, is de automatische consistentiecontrole van een reeks integriteitsbeperkingen.

uit welke relaties moet de database bestaan ​​en

welke attributen moeten deze relaties hebben?

Er zijn drie hoofdbenaderingen voor het ontwerpen van databases:

1. verzameling van informatie over de objecten van het probleem dat wordt opgelost in één tabel en de daaropvolgende decompositie in verschillende onderling verbonden tabellen op basis van normalisatieprocedures ( klassieke methode);

2. overgang van het semantische (infologische) model van de tweede fase met behulp van CASE-tools naar een kant-en-klaar databaseschema of zelfs een kant-en-klaar toegepast informatiesysteem (IS);

3. het structureren van informatie voor gebruik in IS bij het uitvoeren van een systeemanalyse op basis van een reeks praktische regels en aanbevelingen.

Eerst zal een klassieke benadering worden overwogen, waarbij het gehele ontwerpproces wordt uitgevoerd in termen van een relationeel datamodel door de methode van opeenvolgende benaderingen tot een bevredigende set van relatieschema's. Het uitgangspunt is de weergave van de software in de vorm van een of meerdere relaties, en bij elke ontwerpstap wordt een bepaalde set relatieschema's met betere eigenschappen geproduceerd. Het ontwerpproces is een proces van normalisering van relatieschema's, waarbij elke volgende normaalvorm betere eigenschappen heeft dan de vorige.

In de theorie van relationele databases wordt meestal de volgende reeks normaalvormen onderscheiden:

eerste normaalvorm (1NF);

tweede normaalvorm (2NF);

derde normaalvorm (3NF);

Boyes-Codd normale vorm (BCNF)

vierde normaalvorm (4NF);

vijfde normaalvorm (5NF of PJ / NF).

Basiseigenschappen van normaalvormen:

elke volgende normaalvorm is in zekere zin beter dan de vorige;

bij het verplaatsen naar de volgende normaalvorm blijven de eigenschappen van de vorige normaaleigenschappen behouden.

Het ontwerpproces is gebaseerd op de normalisatiemethode, de ontleding van een relatie in de vorige normaalvorm 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 een fundamenteel concept in de theorie van relationele databases functionele afhankelijkheid... Voor een verdere presentatie hebben we verschillende definities nodig.

Definitie 1. Functionele afhankelijkheid

Met betrekking tot R hangt het Y-attribuut functioneel af van het X-attribuut (X en Y kunnen samengesteld zijn) als en slechts als elke X-waarde precies één Y-waarde heeft: R.X -> R.Y.

definitie 2 . Volledige functionele afhankelijkheid

Een functionele afhankelijkheid R.X -> R.Y wordt compleet genoemd als het attribuut Y niet functioneel afhankelijk is van een exacte subset van X.

Definitie 3. Transitieve functionele afhankelijkheid

De functionele afhankelijkheid R.X -> R.Y wordt transitief genoemd als er een zodanig attribuut Z is dat er functionele afhankelijkheden R.X -> R.Z en R.Z -> R.Y zijn en er geen functionele afhankelijkheid R.Z - / -> R.X.

Definitie 4. Niet-sleutelattribuut

Een niet-sleutelattribuut is elk attribuut van een relatie dat geen deel uitmaakt van de primaire sleutel (in het bijzonder de primaire).

Definitie 5 . Wederzijds onafhankelijke attributen

Twee of meer attributen zijn onderling onafhankelijk als geen van deze attributen functioneel afhankelijk is van de andere.

Voor zover de eerste normaalvormvereiste is een basisvereiste van het klassieke relationele model gegevens, gaan we ervan uit dat de initiële set relaties al aan deze vereiste voldoet, d.w.z. alle attributen zijn atomair. Als de tabel samengestelde attributen bevat, kunt u deze converteren naar 1NF met behulp van normalisatie-algoritme voorgesteld door E. Codd:

beginnend bij de originele tabel, wordt de primaire sleutel genomen en toegevoegd aan elke ondergeschikte tabel (samengesteld attribuut);

de primaire sleutel van elke uitgebreide tabel bestaat uit de primaire sleutel van de ondergeschikte tabel en de toegevoegde primaire primaire sleutel;

daarna worden alle moeilijke attributen uit de bovenliggende tabel verwijderd en wordt deze procedure herhaald voor elk van de ondergeschikte tabellen;

de voorwaarde voor het einde van het algoritme is de atomiciteit van alle attributen.

Voorbeeld 5.1 Beschouw als vakgebied een bepaalde organisatie die enkele projecten uitvoert. We beschrijven het domeinmodel met de volgende informele tekst:

De medewerkers van de organisatie voeren projecten uit.

Projecten bestaan ​​uit meerdere taken.

Elke medewerker kan deelnemen aan één of meerdere projecten, of tijdelijk niet deelnemen aan projecten.

Aan elk project kunnen meerdere medewerkers werken, of het project kan tijdelijk worden opgeschort, dan is er geen medewerker meer mee bezig.

Aan elke taak in het project werkt precies één medewerker.

Elke medewerker staat op één afdeling.

Elke medewerker heeft een telefoonnummer op de afdeling van de medewerker.

In de loop van de aanvullende verduidelijking met welke gegevens rekening moet worden gehouden, werd het volgende duidelijk:

Van elke medewerker moet een personeelsnummer worden opgeslagen. Het personeelsnummer is uniek voor elke medewerker.

Elke afdeling heeft uniek nummer.

Elk project heeft een nummer. Het projectnummer is uniek.

Elke taak uit het project heeft een nummer dat uniek is binnen het project.

Laten we ons een relatiediagram voorstellen (alle informatie in één tabel):

WERKNEMERS-AFDELINGEN-PROJECTEN

(SOTR_NUMBER, SOTR_ZARP, DT_NUMBER, PRO_NUMBER, SOTR_SET)

Hoofdsleutel:

SOTR_NUMBER, PRO_NUMBER

Functionele afhankelijkheden:

SOTR_NUMBER -> SOTR_ZARP

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

COPY_NUMBER, PRO_NUMBER -> COPY_SET

Zoals u kunt zien, hoewel de primaire sleutel het samengestelde kenmerk SOTR_NUMBER, PRO_NUMBER is, zijn de kenmerken SOTR_ZARP en DTD_NUMBER functioneel afhankelijk van het deel van de primaire sleutel, het kenmerk SOTR_NUMBER. Als gevolg hiervan kunnen we in de relatie WERKNEMER-AFDELINGEN-PROJECTEN geen tuple invoegen die een werknemer beschrijft die nog geen project uitvoert (de primaire sleutel mag geen ongedefinieerde waarde bevatten). Bij het verwijderen van een tuple vernietigen we niet alleen de connectie van deze medewerker met dit project, maar verliezen we ook de informatie dat hij op een bepaalde afdeling werkt. Bij het overplaatsen van een medewerker naar een andere afdeling, zijn we genoodzaakt om alle tuples die deze medewerker beschrijven aan te passen, anders krijgen we een inconsistent resultaat. Dergelijke onaangename verschijnselen worden genoemd afwijkingen relatie schema's. Ze worden geëlimineerd door normalisatie.

Definitie 6 . Tweede normaalvorm(deze definitie gaat ervan uit dat de enige sleutel van de relatie de primaire sleutel is)

Een relatie R is in tweede normaalvorm (2NF) als en slechts als het in 1NF is, en elk niet-sleutelattribuut is volledig afhankelijk van de primaire sleutel.

U kunt de relatie WERKNEMER-AFDELING-PROJECTEN als volgt opsplitsen in twee relaties WERKNEMER-AFDELINGEN en WERKNEMER-PROJECTEN:

AFDELING WERKNEMERS (SOTR_NUMBER, SOTR_ZARP, DEPARTMENT_NUMBER)

Hoofdsleutel:

SOTR_NUMBER

Functionele afhankelijkheden:

SOTR_NUMBER -> SOTR_ZARP

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENT_NUMBER -> SOTR_ZARP

Hoofdsleutel:

SOTR_NUMBER, PRO_NUMBER

Functionele afhankelijkheden:

COPY_NUMBER, PRO_NUMBER -> COPT_DEFINED

Elk van deze twee relaties is in 2NF, en de hierboven vermelde anomalieën zijn geëlimineerd (het is gemakkelijk te verifiëren dat alle gespecificeerde bewerkingen zonder problemen worden uitgevoerd).

Denk nog eens aan de WERKNEMER-AFDELING relatie in 2NF. Merk op dat de functionele afhankelijkheid SOTR_NUMBER -> SOTR_ZARP transitief is; het is een gevolg van de functionele afhankelijkheden SOTR_NUMBER -> DT_NUMBER en DT_NUMBER -> SOTR_ZARP. Met andere woorden, het salaris van een werknemer is eigenlijk geen kenmerk van de werknemer, maar van de afdeling waar hij werkt (dit is geen heel natuurlijke veronderstelling, maar voldoende voor een voorbeeld).

Als gevolg hiervan kunnen we informatie die het salaris van een afdeling kenmerkt, pas in de database invoeren als er minimaal één medewerker op deze afdeling verschijnt (de primaire sleutel mag geen ongedefinieerde waarde bevatten). Als we de tuple verwijderen die de laatste medewerker van deze afdeling beschrijft, verliezen we informatie over het salaris van de afdeling. Om het salaris van een afdeling op een consistente manier te veranderen, zullen we eerst alle tupels moeten vinden die de medewerkers van deze afdeling beschrijven. Die. er zijn nog steeds afwijkingen in de AFDELING WERKNEMER. Ze kunnen worden geëlimineerd door verdere normalisatie.

Definitie 7. Derde normaalvorm(De definitie wordt gegeven in de veronderstelling dat er een enkele sleutel bestaat.)

Een relatie R is in derde normaalvorm (3NF) als en slechts als het in 2NF is en elk niet-sleutelattribuut niet transitief afhankelijk is van de primaire sleutel.

U kunt de relatie WERKNEMER-AFDELINGEN ontleden in twee relaties WERKNEMER en AFDELINGEN:

WERKNEMERS (COLLEGE_NUMBER, DEPARTMENT_NUMBER)

Hoofdsleutel:

SOTR_NUMBER

Functionele afhankelijkheden:

COPY_NUMBER -> DEPARTURE_NUMBER

DEPARTMENTS (DEPARTMENT_NUMBER, SOTR_ZARP)

Hoofdsleutel:

DET_NUMBER

Functionele afhankelijkheden:

DEPARTMENT_NUMBER -> SOTR_ZARP

Elk van deze twee verhoudingen is op 3NF en vrij van duidelijke afwijkingen.

Als we afzien van de beperking dat een relatie een enkele sleutel heeft, dan neemt de definitie van 3NF de volgende vorm aan:

Definitie 7 *

Een relatie R is in de derde normaalvorm (3NF) als en slechts als het in 2NF is, en elk niet-sleutelattribuut is niet transitief afhankelijk van een sleutel R.

In de praktijk is de derde normaalvorm van relatiediagrammen in de meeste gevallen voldoende, en het proces van het ontwerpen van een relationele database eindigt meestal met het converteren naar de derde normaalvorm..

Soms is het echter nuttig om door te gaan met het normalisatieproces.

Voorbeeld 5.2 Beschouw het volgende voorbeeld van een relatiediagram:

WERKNEMERS-PROJECTS (SOTR_NUMBER, SATR_NAME, PRO_NUMBER, SOTR_SIGNED)

Mogelijke sleutels:

SOTR_NUMBER, PRO_NUMBER

SOLD_NAME, PRO_NUMBER

Functionele afhankelijkheden:

COP_NUMBER -> COP_NAME

SOTR_NUMBER -> PRO_NUMBER

COPY_NAME -> COPY_NUMBER

SOLD_NAME -> PRO_NUMBER

COPY_NUMBER, PRO_NUMBER -> COPT_DEFINED

COPY_NAME, PRO_NUMBER -> COPY_DEFINED

In dit voorbeeld gaan we ervan uit dat de identiteit van de werknemer volledig wordt bepaald door zowel zijn nummer als naam (dit is weer geen erg realistische veronderstelling, maar voldoende voor een voorbeeld).

Volgens de definitie van 7 * is de relatie WERKNEMER-PROJECTEN in 3NF. Het feit dat er functionele afhankelijkheden zijn van relatieattributen op een attribuut dat deel uitmaakt van de primaire sleutel leidt echter tot anomalieën. Om bijvoorbeeld de naam van een werknemer met een bepaald nummer op een consistente manier te wijzigen, moeten we alle tuples wijzigen die zijn nummer bevatten.

Definitie 8. Bepalend

Een determinant is elk attribuut waarvan een ander attribuut volledig functioneel afhangt.

Definitie 9 . Boyes-Codd normaalvorm

De R-relatie is in Boyes-Codd Normal Form (BCNF) als en slechts als elke determinant een mogelijke sleutel is.

Voor de relatie WERKNEMER-PROJECTEN wordt uiteraard niet aan deze eis voldaan. Je kunt het ontleden naar de relaties WERKNEMERS en WERKNEMER-PROJECTEN:

WERKNEMERS (COPY_NUMBER, COPY_NAME)

Mogelijke sleutels:

SOTR_NUMBER

Functionele afhankelijkheden:

COP_NUMBER -> COP_NAME

COPY_NAME -> COPY_NUMBER

WERKNEMERS-PROJECTEN (SOTR_NUMBER, PRO_NUMBER, SOTR_SIGNED)

Mogelijke sleutel:

SOTR_NUMBER, PRO_NUMBER

Functionele afhankelijkheden:

COPY_NUMBER, PRO_NUMBER -> COPT_DEFINED

Een alternatieve decompositie is mogelijk als u SOTR_NAME als basis kiest. In beide gevallen bevinden de resulterende WERKNEMER- en PROJECTWERKNEMER-relaties zich in BCNF en vertonen ze niet de opgemerkte afwijkingen.

Voorbeeld 5.3 Beschouw een voorbeeld van het volgende relatiediagram:

PROJECTEN (PRO_NUMBER, PRO_SOTR, PRO_SPECIFIED)

De relatie PROJECTEN bevat projectnummers, voor elk project een lijst van medewerkers die het project kunnen uitvoeren en een lijst met taken die het project voor ogen heeft. Medewerkers kunnen deelnemen aan meerdere projecten en verschillende projecten kunnen dezelfde taken bevatten.

Elke tupel van een relatie verbindt een project met een medewerker die deelneemt aan dit project, en de taak die de medewerker uitvoert in het kader van dit project (we gaan ervan uit dat elke medewerker die deelneemt aan het project alle taken uitvoert die door dit project worden voorzien). Vanwege de hierboven geformuleerde voorwaarden is de enige mogelijke relatiesleutel het samengestelde attribuut PRO_NUMBER, PRO_SOTR, PRO_DASED, en er zijn geen andere determinanten. Daarom is de relatie PROJECTEN in BCNF. Maar tegelijkertijd heeft het nadelen: als bijvoorbeeld een medewerker zich bij dit project aansluit, is het nodig om net zoveel tuples in de PROJECTS-relatie in te voeren als er taken zijn.

Definitie 10 . Afhankelijkheden met meerdere waarden

Met betrekking tot R (A, B, C) is er een meerwaardige afhankelijkheid RA -> -> RB als en alleen als de reeks waarden van B die overeenkomt met een paar waarden van A en C alleen afhangt van A en is niet afhankelijk van C.

Met betrekking tot PROJECTEN zijn er de volgende twee ambigue afhankelijkheden:

PRO_NUMBER -> -> PRO_SOTR

PRO_NUMBER -> -> PRO_SPECIFIED

Het is gemakkelijk aan te tonen dat er in het algemene geval met betrekking tot R (A, B, C) een meerwaardige afhankelijkheid R.A -> -> R.B is dan en slechts dan als er een meerwaardige afhankelijkheid R.A -> R.C. is.

Verdere normalisatie van relaties vergelijkbaar met de relatie PROJECTEN is gebaseerd op de volgende stelling:

Stelling van Fagin

Verhouding R (A, B, C) kan verliesloos worden geprojecteerd in de verhoudingen R1 (A, B) en R2 (A, C) als en alleen als er MVD A -> -> B | C.

Onder verliesvrije projectie wordt een dergelijke methode van ontbinding van een relatie verstaan, waarbij de oorspronkelijke relatie volledig en zonder redundantie wordt hersteld door de natuurlijke combinatie van de verkregen relaties.

Definitie 11 . Vierde normaalvorm

Een relatie R is in de vierde normaalvorm (4NF) dan en slechts dan als, in het geval van een meerwaardige afhankelijkheid A -> -> B, alle andere attributen van R functioneel afhankelijk zijn van A.

In ons voorbeeld kunnen we de relatie PROJECTEN ontleden in twee relaties PROJECTEN-MEDEWERKERS en PROJECTEN-TAKEN:

PROJECTEN-WERKNEMERS (PRO_NUMBER, PRO_SOTR)

PROJECTS-VACATURES (PRO_NUMBER, PRO_SDAN)

Beide relaties zijn in 4NF en zijn vrij van opgemerkte anomalieën.

In alle tot nu toe beschouwde normalisaties werd één relatie in tweeën ontleed. Soms kan dit niet, maar ontleding in meer relaties, die elk de beste eigenschappen hebben.

Voorbeeld 5.4 Denk bijvoorbeeld aan de relatie

WERKNEMERS-AFDELINGEN-PROJECTS (COP_NUMBER, DEPARTMENT_NUMBER, PRO_NUMBER)

Stel dat dezelfde medewerker op meerdere afdelingen kan werken en op elke afdeling aan meerdere projecten kan werken. De primaire sleutel van deze relatie is de volledige set van attributen; er zijn geen functionele en meerwaardige afhankelijkheden.

Daarom is de verhouding 4NF. Er kunnen echter anomalieën in voorkomen, die kunnen worden geëlimineerd door ontleding in drie relaties.

Definitie 12. Verbindingsafhankelijkheid

De relatie R (X, Y, ..., Z) voldoet aan de verbindingsafhankelijkheid * (X, Y, ..., Z) dan en slechts dan als R zonder verlies wordt hersteld door zijn projecties te verbinden met X, Y, .. ., Z.

Definitie 13 . Vijfde normaalvorm

Een relatie R is in vijfde normaalvorm (projectie-join normaalvorm - PJ / NF) als en slechts als enige join-afhankelijkheid in R volgt uit het bestaan ​​van een mogelijke sleutel in R.

Laten we de volgende namen van samengestelde attributen introduceren:

CO = (COP_NUMBER, DEP_NUMBER)

SP = (SOTR_NUMBER, PRO_NUMBER)

OP = (DT_NUMBER, PRO_NUMBER)

Stel dat er een verbindingsafhankelijkheid is met betrekking tot WERKNEMERS-AFDELINGEN-PROJECTEN:

* (CO, SP, OP)

Het is gemakkelijk aan te tonen aan de hand van voorbeelden dat er problemen kunnen ontstaan ​​bij het invoegen en verwijderen van tuples. Ze kunnen worden geëlimineerd door de oorspronkelijke relatie op te splitsen in drie nieuwe relaties:

WERKNEMERS VAN DE AFDELING (COPY_NUMBER, DEPARTMENT_NUMBER)

WERKNEMERS-PROJECTS (SOTR_NUMBER, PRO_NUMBER)

DEPARTMENTS-PROJECTS (DEPARTMENT_NUMBER, PRO_NUMBER)

De vijfde normaalvorm is de laatste normaalvorm die kan worden verkregen door ontleding. De voorwaarden zijn nogal triviaal, en in de praktijk wordt 5NF niet gebruikt. Merk op dat de verbindingsafhankelijkheid een veralgemening is van zowel meerwaardige afhankelijkheid als functionele afhankelijkheid.

Opmerking ... Als de relatie niet genormaliseerd is, ontstaan ​​er problemen. redundantie, mogelijke inconsistentie (bijwerkingsafwijkingen), opnameafwijkingen, verwijderingsafwijkingen.

Door de principes te volgen die in dit artikel worden beschreven, kunt u een database maken die werkt zoals verwacht en kan worden aangepast om in de toekomst aan nieuwe vereisten te voldoen. We zullen de basisprincipes behandelen: database-ontwerp, evenals manieren om het te optimaliseren.

Database ontwerpproces

Naar behoren gestructureerde basis gegevens:

• Helpt besparen schijfruimte door onnodige gegevens uit te sluiten;
• Handhaaft de nauwkeurigheid en integriteit van gegevens;
• Biedt gemakkelijke toegang tot gegevens.

Databaseontwikkeling omvat de volgende fasen:

1. Het analyseren van de eisen of het definiëren van het doel van de database;
2. Organisatie van gegevens in tabellen;
3. Indicatie van primaire sleutels en analyse van relaties;
4. Normalisatie van tabellen.

Overweeg elk database-ontwerpfase meer gedetailleerd. Merk op dat deze tutorial zich richt op het relationele databasemodel van Edgar Codd, geschreven in SQL-taal (niet hiërarchisch, netwerk- of objectmodel).

Vereistenanalyse: het doel van de database definiëren

Als u bijvoorbeeld een database maakt voor een openbare bibliotheek, moet u overwegen hoe zowel lezers als bibliothecarissen toegang moeten krijgen tot de database.

Er zijn verschillende manieren om informatie te verzamelen voordat u een database aanmaakt:

• Mensen interviewen die het zullen gebruiken;
• Analyse van zakelijke formulieren zoals facturen, planningen, enquêtes;
• Overweging van alles bestaande systemen gegevens ( inclusief fysieke en digitale bestanden).

Begin met het verzamelen van bestaande gegevens die in de database moeten worden opgenomen. Definieer vervolgens de soorten gegevens die u wilt opslaan. Evenals objecten die deze gegevens beschrijven. Bijvoorbeeld:

Klanten

• Adres;
• Plaats, staat, postcode;
• E-mailadres.

Goederen

• Naam;
• Prijs;
• Hoeveelheid in voorraad;
• Aantal op bestelling.

Bestellingen

• Bestelnummer;
• Verkoop vertegenwoordiger;
• Datum;
• Product;
• Hoeveelheid;
• Prijs;
• Prijs.

Bij het ontwerpen van een relationele database wordt deze informatie later onderdeel van de datadictionary, waarin de databasetabellen en -velden worden beschreven. Breek de informatie op in de kleinst mogelijke stukjes. Overweeg bijvoorbeeld om het postadres en de staat te scheiden, zodat u mensen kunt filteren op de staat waarin ze wonen.

Nadat u hebt besloten welke gegevens in de database worden opgenomen, waar deze gegevens vandaan komen en hoe deze worden gebruikt, kunt u beginnen met het plannen van de eigenlijke database.

Databasestructuur: bouwstenen

De volgende stap is het visualiseren van de database. Om dit te doen, moet u precies weten hoe relationele databases zijn gestructureerd. Binnen de database zijn gerelateerde gegevens gegroepeerd in tabellen, die elk bestaan ​​uit rijen en kolommen.

Als u lijsten met gegevens naar tabellen wilt converteren, begint u met het maken van een tabel voor elk type object, zoals producten, verkopen, klanten en bestellingen. Hier is een voorbeeld:

Elke rij in de tabel wordt een record genoemd. Records bevatten informatie over iets of iemand, zoals een specifieke klant. kolommen (ook wel velden of attributen genoemd) informatie van hetzelfde type bevatten die voor elk record wordt weergegeven, bijvoorbeeld de adressen van alle klanten die in de tabel worden vermeld.

Om consistentie tussen records te garanderen bij het ontwerpen van uw databasemodel, wijst u voor elke kolom een ​​geschikt gegevenstype toe. TOT gewone types gegevens omvatten:

• CHAR - specifieke lengte van de tekst;
• VARCHAR - tekst van verschillende lengtes;
• TEKST - grote hoeveelheid tekst;
• INT - positief of negatief geheel getal;
• FLOAT, DOUBLE - getallen met drijvende komma;
• BLOB is binaire gegevens.

Sommige DBMS'en bieden ook het gegevenstype Autonummering, dat automatisch een uniek nummer op elke rij genereert.

V visuele presentatie DB elke tabel wordt weergegeven door een blok in het diagram. De kop van elk blok moet aangeven wat de gegevens in die tabel beschrijven, en de kenmerken moeten hieronder worden vermeld:

Bij ontwerp van informatiedatabase je moet beslissen welke attributen zullen dienen als de primaire sleutel voor elke tabel, indien aanwezig. Hoofdsleutel ( PK) Is een unieke identificatie voor van dit object... Met zijn hulp kunt u de gegevens van een specifieke klant selecteren, zelfs als u alleen deze waarde kent.

Attributen die als primaire sleutels zijn geselecteerd, moeten uniek en onveranderbaar zijn en mogen niet NULL zijn ( ze kunnen niet leeg zijn). Om deze reden zijn bestelnummers en gebruikersnamen geschikte primaire sleutels, maar telefoonnummers of adressen niet. U kunt ook meerdere velden tegelijk gebruiken als primaire sleutel ( dit wordt een samengestelde sleutel genoemd).

Als het tijd is om de eigenlijke DB te maken, implementeert u zowel de logische als de fysieke structuur via de datadefinitietaal die door uw DBMS wordt ondersteund.

Het is ook noodzakelijk om de grootte van de database in te schatten om ervoor te zorgen dat het vereiste prestatieniveau kan worden behaald en dat u voldoende opslagruimte hebt.

Relaties creëren tussen entiteiten

Nu de gegevens zijn geconverteerd naar tabellen, moeten we de relaties ertussen analyseren. De complexiteit van een database wordt bepaald door het aantal elementen dat interageert tussen twee gekoppelde tabellen... Door de complexiteit te bepalen, kunt u ervoor zorgen dat u uw gegevens op de meest efficiënte manier in tabellen verdeelt.

Elk object kan met een ander worden verbonden met behulp van een van de drie soorten koppelingen:

Eén-op-één communicatie

Wanneer er slechts één exemplaar van object A is voor elk exemplaar van object B, wordt er gezegd dat ze een één-op-één relatie hebben ( vaak aangeduid als 1: 1). U kunt dit type relatie in het ER-diagram aangeven met een lijn met aan elk uiteinde een streepje:

Wanneer u uw databases ontwerpt en ontwikkelt en u geen reden hebt om deze gegevens te delen, geeft een 1: 1-relatie meestal aan dat het beter is om deze tabellen in één te combineren.

Maar onder bepaalde omstandigheden is het beter om tabellen te maken met 1:1 relaties. Als er een veld is met optionele gegevens, bijvoorbeeld "beschrijving", dat voor veel records niet is ingevuld, kunt u alle beschrijvingen naar een aparte tabel verplaatsen, met uitzondering van lege velden en het verbeteren van de databaseprestaties.

Om ervoor te zorgen dat de gegevens correct correleren, moet u opnemen: minstens, één identieke kolom in elke tabel. Dit zal hoogstwaarschijnlijk de primaire sleutel zijn.

Een-op-veel relatie

Deze relaties treden op wanneer een record in de ene tabel is gekoppeld aan meerdere records in een andere. Een klant kan bijvoorbeeld veel bestellingen plaatsen, of de lezer kan meerdere boeken tegelijk uit de bibliotheek halen. Een-op-veel (1:M)-relaties worden aangeduid met de zogenaamde kraaienpootmarkering, zoals in dit voorbeeld:

Om een ​​1: M-relatie te implementeren, voegt u de primaire sleutel uit de "één" tabel als attribuut toe aan een andere tabel. Wanneer een primaire sleutel op deze manier in een andere tabel wordt gespecificeerd, wordt dit een externe sleutel genoemd. De tabel aan de "1"-kant van de relatie is de bovenliggende tabel voor de onderliggende tabel aan de andere kant.

Veel-op-veel relatie

Wanneer meerdere tabelobjecten aan meerdere andere objecten kunnen worden gekoppeld. Ze zeggen dat ze een band hebben" veel te veel» ( M: Nee). Bijvoorbeeld in het geval van studenten en cursussen, aangezien een student veel cursussen kan volgen en elke cursus door veel studenten kan worden gevolgd.

In het ER-diagram worden deze relaties weergegeven met de volgende regels:

Bij het ontwerpen van een databasestructuur is het onmogelijk om dit soort relaties te implementeren. In plaats daarvan moet je ze opsplitsen in twee een-op-veel-relaties.

Om dit te doen, moet u een nieuwe entiteit tussen deze twee tabellen maken. Als er een M:N-relatie is tussen verkoop en producten, kun je dit noemen nieuw object « verkochte_producten”Omdat het gegevens voor elke verkoop zal bevatten. Zowel de verkooptabel als de producttabel zullen een 1: M relatie hebben met sold_products. Dit soort tussenobject in verschillende modellen een koppelingstabel, associatief object of koppelingstabel genoemd.

Elk record in de relatietabel komt overeen met twee entiteiten uit aangrenzende tabellen. Een tabel met koppelingen tussen studenten en cursussen kan er bijvoorbeeld als volgt uitzien:

Is het verplicht of niet?

Een andere manier om relaties te analyseren is om te overwegen aan welke kant van een relatie de andere moet bestaan. De optionele zijde kan worden gemarkeerd met een cirkel op de lijn. Een land moet bijvoorbeeld bestaan ​​om een ​​vertegenwoordiger in de Verenigde Naties te hebben, en niet andersom:

Twee objecten kunnen van elkaar afhankelijk zijn ( de een kan niet zonder de ander).

recursieve links

Soms verwijst een tabel bij het ontwerpen van een database naar zichzelf. Een werknemerstabel kan bijvoorbeeld een managerkenmerk hebben dat verwijst naar een andere persoon in dezelfde tabel. Dit wordt recursieve koppeling genoemd.

Extra aansluitingen

Overbodige verbindingen zijn verbindingen die meer dan eens worden uitgedrukt. In de regel is het mogelijk om een ​​van deze links te verwijderen zonder er een te verliezen belangrijke gegevens... Als het object "studenten" bijvoorbeeld een directe relatie heeft met een ander object genaamd "docenten", maar ook een indirecte relatie heeft met docenten via "items", moet u de link tussen "studenten" en "docenten" verwijderen. Omdat de enige manier waaraan leerlingen zijn toegewezen docenten zijn onderwerpen.

Database normalisatie

Na het voorlopige ontwerp van de database kunnen normalisatieregels worden toegepast om ervoor te zorgen dat de tabellen correct worden gestructureerd.

Tegelijkertijd hoeven niet alle databases te worden genormaliseerd. Over het algemeen zijn databases met realtime transactieverwerking ( OLTP) moet worden genormaliseerd.

Databases met interactieve analytische verwerking (OLAP), die gegevensanalyse eenvoudiger en sneller maken, efficiënter kunnen zijn met een zekere mate van denormalisatie. Het belangrijkste criterium hierbij is de snelheid van berekeningen. Elke vorm of niveau van normalisatie bevat regels die verband houden met de lagere vormen.

De eerste vorm van normalisatie

De eerste vorm van normalisatie ( afgekort 1NF) stelt dat tijdens logisch database-ontwerp elke cel in een tabel kan maar één waarde hebben, geen lijst met waarden. Daarom komt een tabel zoals hieronder niet overeen met 1NF:

U kunt in de verleiding komen om deze beperking te omzeilen door de gegevens in extra kolommen te verdelen. Maar ook dit is tegen de regels: een tafel met groepjes herhalen of strak gerelateerde attributen komt niet overeen met de eerste vorm van normalisatie. De onderstaande tabel komt bijvoorbeeld niet overeen met 1NF:

Verdeel de gegevens in plaats daarvan tijdens het fysieke ontwerp van de database in meerdere tabellen of records totdat elke cel slechts één waarde bevat en er geen extra kolommen zijn. Dergelijke gegevens worden beschouwd als uitgesplitst tot in de kleinste nuttige maat... De bovenstaande tabel kan creëren: extra tafel « Verkoopdetails», Die overeenkomen met specifieke producten met verkoop. "Sales" zal een 1: M-relatie hebben met " Verkoopdetails».

Tweede vorm van normalisatie

De tweede vorm van normalisatie ( 2NF) bepaalt dat elk van de attributen volledig afhankelijk moet zijn van de primaire sleutel. Elk attribuut moet direct afhankelijk zijn van de gehele primaire sleutel, en niet indirect via een ander attribuut.

Het attribuut "leeftijd" hangt bijvoorbeeld af van de "verjaardag", die op zijn beurt weer afhangt van de "student-ID", heeft een gedeeltelijke functionele afhankelijkheid... De tabel met deze attributen komt niet overeen met het tweede normalisatieformulier.

Bovendien schendt een tabel met een primaire sleutel bestaande uit meerdere velden de tweede vorm van normalisatie als een of meer velden niet afhankelijk zijn van elk onderdeel van de sleutel.

Een tabel met deze velden komt dus niet overeen met het tweede normalisatieformulier, aangezien het kenmerk "productnaam" afhankelijk is van de product-ID, maar niet van het bestelnummer:

• Bestelnummer (primaire sleutel);
• Product-ID (primaire sleutel);
• Productnaam.

De derde vorm van normalisatie

De derde vorm van normalisatie ( 3NF) : elke niet-sleutelkolom moet onafhankelijk zijn van elke andere kolom. Ik dik relationeel database-ontwerp een verandering in een waarde in een niet-sleutelkolom veroorzaakt een verandering in een andere waarde, deze tabel komt niet overeen met de derde vorm van normalisatie.

Volgens 3NF kun je geen afgeleide gegevens opslaan in de tabel, zoals de kolom Belasting, die in het onderstaande voorbeeld direct afhankelijk is van totale prijs volgorde:

Op een gegeven moment werden aangeboden aanvullende formulieren normalisatie. Inclusief de Boyce-Codd-vorm van normalisatie, de vierde tot zesde vormen en domeinsleutelnormalisatie, maar de eerste drie zijn de meest voorkomende.

Multidimensionale gegevens

Sommige gebruikers hebben mogelijk toegang nodig tot verschillende secties van hetzelfde gegevenstype, vooral in databases OLAP-gegevens... Ze willen bijvoorbeeld de verkoop per klant, land en maand weten. In deze situatie kunt u het beste een centrale tabel maken waarnaar kan worden verwezen door de klant-, land- en maandtabellen. Bijvoorbeeld:

Regels voor gegevensintegriteit

Ook met behulp van hulpprogramma's voor databaseontwerp het is noodzakelijk om de database te configureren, rekening houdend met de mogelijkheid om de gegevens te controleren op naleving van bepaalde regels. Veel DBMS'en, zoals Microsoft Access, dwingen sommige van deze regels automatisch af.

De integriteitsregel stelt dat de primaire sleutel nooit NULL kan zijn. Als de sleutel meerdere kolommen heeft, kan geen van deze NULL zijn. Anders kan het record dubbelzinnig worden geïdentificeerd.

De regel voor linkintegriteit vereist dat elke externe sleutel die in één tabel wordt vermeld, moet worden toegewezen aan één primaire sleutel in de tabel waarnaar deze verwijst. Als de primaire sleutel wordt gewijzigd of verwijderd, moeten deze wijzigingen worden doorgevoerd in alle objecten waarnaar wordt verwezen door deze sleutel in de database.

Integriteitsregels voor bedrijfslogica zorgen ervoor dat gegevens voldoen aan bepaalde logische parameters. De vergadertijden moeten bijvoorbeeld binnen de standaard kantooruren vallen.

Indexen en weergaven toevoegen

Een index is een gesorteerde kopie van een of meer kolommen met waarden in oplopende of aflopende volgorde. Door een index toe te voegen, kunt u records sneller vinden. In plaats van voor elke zoekopdracht opnieuw te sorteren, heeft het systeem toegang tot de records in de volgorde die wordt aangegeven door de index.

Hoewel indexen het ophalen van gegevens versnellen, kunnen ze het toevoegen, bijwerken en verwijderen van gegevens vertragen, omdat de index opnieuw moet worden opgebouwd wanneer een record wordt gewijzigd.

Een view is een opgeslagen verzoek om gegevens. Weergaven kunnen gegevens uit meerdere tabellen bevatten of een gedeelte van een tabel weergeven.

Uitgebreide eigenschappen

Na ontwerp van databasemodel U kunt uw database verfijnen met geavanceerde eigenschappen zoals helptekst, invoermaskers en opmaakregels die van toepassing zijn op een specifiek schema, weergave of kolom. Het voordeel van deze methode is dat, aangezien deze regels in de database zelf zijn opgeslagen, de presentatie van de gegevens consistent zal zijn in de verschillende programma's die toegang hebben tot de gegevens.

SQL en UML

Uniforme modelleringstaal ( UML) Is een ander visuele manier uitdrukkingen ingewikkelde systemen gemaakt in een objectgeoriënteerde taal. Sommige van de concepten die in deze tutorial worden genoemd, staan ​​in de UML onder verschillende namen bekend. Een object in de UML staat bijvoorbeeld bekend als een klasse.

UML wordt nu niet zo vaak gebruikt. Het wordt tegenwoordig academisch en in communicatie met ontwikkelaars gebruikt. software en hun klanten.

Databasebeheersystemen

De structuur van de ontworpen database hangt af van het DBMS dat u gebruikt. Enkele van de meest voorkomende:

• Oracle-database;
• MijnSQL;
• Microsoft SQL Server
• PostgreSQL;
• IBM DB2.

Een geschikt databasebeheersysteem kan worden geselecteerd op basis van de kosten, het geïnstalleerde besturingssysteem, de beschikbaarheid verschillende functies enzovoort.

Vertaling van het artikel " Zelfstudie over databasestructuur en -ontwerp»Vriendelijk projectteam

In het eerste artikel in de serie "Gegevens in WordPress" gaf ik een overzicht van het gebruik van relationele databases in WordPress: welke tabellen worden gebruikt en welke gegevens ...

Om vertrouwelijke gegevens te beschermen, introduceerde MySQL 5.7 de mogelijkheid om gegevens te coderen met behulp van de InnoDB-engine. In dit artikel leg ik de principes van database-encryptie uit, ...