Voorbeeld van databaseontwerp. Veldformaat - bepaalt hoe gegevens worden opgemaakt in cellen die bij het veld horen

Stuur uw goede werk naar de kennisbank is eenvoudig. Gebruik onderstaand formulier

Studenten, promovendi en jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Geplaatst op http://www.allbest.ru/

INVaan het eten

interfaceprogramma gebruikerssysteem

Tegenwoordig zijn er honderden miljoenen personal computers in de wereld actief. Wetenschappers, economen en politici zijn van mening dat aan het begin van het derde millennium:

Het aantal computers in de wereld zal gelijk zijn aan het aantal inwoners van ontwikkelde landen.

De meeste van deze computers zullen worden opgenomen in mondiale informatienetwerken.

alle informatie die de mensheid aan het begin van het derde millennium heeft verzameld, zal in computervorm (binair) worden vertaald, en alle informatie zal worden voorbereid met de hulp (of met de deelname) van computers; alle informatie wordt voor onbepaalde tijd opgeslagen in computernetwerken;

een volwaardig lid van de samenleving van het derde millennium zal elke dag met behulp van computers moeten communiceren met lokale, regionale of mondiale netwerken.

Met een dergelijke automatisering van bijna alle sectoren van menselijke activiteit rijst de vraag naar het creëren van programma's die het creëren van dergelijke databases mogelijk maken. Daarom is dit programma ontwikkeld, waarmee u een database kunt maken waarin informatie over de voortgang van schoolkinderen wordt opgeslagen.

1. Database en presentatiemethoden

Een database (DB) is informatie die wordt gepresenteerd in de vorm van tweedimensionale tabellen. De database bevat veel rijen, die elk overeenkomen met een object. Voor elk object worden bepaalde onafhankelijke posities gebruikt, die velden worden genoemd. Laten we ons zo'n database voorstellen die rijen en kolommen bevat (het eenvoudigste geval). Elke regel, ook wel record genoemd, komt overeen met een specifiek object. Elke kolom bevat de waarden van de bijbehorende objectgegevens.

Een database kan niet uit één tabel bestaan, maar uit twee, drie of meer. Aanvullende informatie over een object kan in aanvullende tabellen worden opgeslagen.

Een van de krachtige kenmerken van de database is dat informatie kan worden georganiseerd volgens de door de gebruiker gespecificeerde criteria. In Pascal wordt de database geleverd als een lijst met termen in de vorm: database_predicaat_naam (record_fields). Databasenamen worden beschreven in de sectie. Databaserecords zijn toegankelijk via een basispredikaat. pascal biedt heel wat hulpmiddelen om met dergelijke databases te werken: laden, schrijven, toevoegen, enz.

Een database is een georganiseerde structuur die is ontworpen om informatie op te slaan. Moderne databases slaan niet alleen gegevens op, maar ook informatie.

Deze stelling kan eenvoudig worden verklaard als we bijvoorbeeld naar de database kijken grote bank. Het bevat alle nodige informatie over klanten, hun adressen, kredietgeschiedenis, status van zichtrekeningen, financiële transacties, enz. Toegang tot deze database is voor een voldoende aantal beschikbaar grote hoeveelheid bankmedewerkers, maar onder hen is er nauwelijks iemand die toegang heeft tot de hele database en er tegelijkertijd eigenhandig willekeurige wijzigingen in kan aanbrengen. Naast gegevens bevat de database methoden en hulpmiddelen waarmee elke medewerker alleen kan werken met de gegevens die binnen zijn/haar competentie vallen. Door de interactie van de gegevens in de database met de methoden die specifieke medewerkers ter beschikking staan, ontstaat informatie die zij consumeren en op basis waarvan zij, binnen hun eigen competentie, gegevens invoeren en bewerken. Nauw verwant aan het concept van een database is het concept databasebeheersystemen. Dit is complex software, bedoeld om een ​​structuur te creëren nieuwe basis, het vullen met inhoud, het bewerken van inhoud en het visualiseren van informatie. Onder visualisatie van informatie database verwijst naar de selectie van weergegeven gegevens in overeenstemming met een bepaald criterium, de volgorde ervan, het ontwerp en de daaropvolgende levering aan uitvoerapparaten of verzending via communicatiekanalen. Er zijn veel databasebeheersystemen in de wereld. Hoewel ze met verschillende objecten verschillend kunnen werken en de gebruiker verschillende functies en kenmerken kunnen bieden, vertrouwen de meeste DBMS'en op één enkele, gevestigde reeks kernconcepten. Dit geeft ons de mogelijkheid om één systeem te overwegen en de concepten, technieken en methoden ervan te generaliseren naar de hele klasse van DBMS. Als dergelijk trainingsobject zullen we kiezen voor het Pascal 7.0 DBMS, inbegrepen in het Pascal 7.0-pakket.

2. Eigenschappen van databasevelden

Databasevelden definiëren niet alleen de structuur van de database; ze bepalen ook de groepseigenschappen van de gegevens die naar de cellen worden geschreven die bij elk van de velden horen. Hieronder vindt u de belangrijkste eigenschappen van databasetabelvelden, waarbij u Pascal 7.0 DBMS als voorbeeld gebruikt.

Veldnaam - bepaalt hoe toegang moet worden verkregen tot de gegevens van dit veld tijdens automatische bewerkingen met de database (standaard worden veldnamen gebruikt als tabelkolomkoppen).

Veldtype - bepaalt het type gegevens dat in dit veld kan worden opgenomen.

Veldgrootte - bepaalt de maximale lengte (in tekens) van gegevens die in dit veld kunnen worden geplaatst.

Veldformaat - bepaalt hoe gegevens worden opgemaakt in cellen die bij het veld horen.

Invoermasker - definieert de vorm waarin gegevens in het veld worden ingevoerd (automatiseringstool voor gegevensinvoer).

Handtekening - definieert de tabelkolomkop voor een bepaald veld (als er geen handtekening is opgegeven, wordt de eigenschap Veldnaam gebruikt als kolomkop).

De standaardwaarde is de waarde die automatisch in de veldcellen wordt ingevoerd (automatiseringstool voor gegevensinvoer).

Voorwaarde op waarde - een beperking die wordt gebruikt om de juistheid van de gegevensinvoer te controleren (een hulpmiddel voor invoerautomatisering dat in de regel wordt gebruikt voor gegevens die numeriek type, valutatype of datumtype).

Foutmelding is een tekstbericht dat automatisch wordt weergegeven wanneer u probeert onjuiste gegevens in een veld in te voeren.

Verplicht veld - een eigenschap die bepaalt of dit veld ingevuld moet worden bij het invullen van de database.

Lege regels - een eigenschap die de invoer van lege tekenreeksgegevens mogelijk maakt (deze verschilt van de eigenschap Verplicht veld doordat deze niet van toepassing is op alle gegevenstypen, maar alleen op sommige, bijvoorbeeld tekst).

Geïndexeerd veld - als een veld deze eigenschap heeft, worden alle handelingen met betrekking tot het zoeken of sorteren van records op de waarde die in dit veld is opgeslagen aanzienlijk versneld. Bovendien kunt u er voor geïndexeerde velden voor zorgen dat de waarde in records wordt gecontroleerd op duplicaten van dit veld, waardoor u gegevensduplicatie automatisch kunt elimineren.

Omdat verschillende velden gegevens kunnen bevatten verschillende soorten, dan kunnen de eigenschappen van de velden variëren, afhankelijk van het gegevenstype. De lijst met bovenstaande veldeigenschappen verwijst bijvoorbeeld voornamelijk naar teksttypevelden.

Velden van andere typen kunnen deze eigenschappen wel of niet hebben, maar kunnen er hun eigen eigenschappen aan toevoegen. Voor gegevens die reële getallen vertegenwoordigen, is het aantal decimalen bijvoorbeeld een belangrijke eigenschap. Aan de andere kant zijn de meeste van de bovenstaande eigenschappen betekenisloos voor velden die worden gebruikt om afbeeldingen, geluidsopnamen, videoclips en andere OLE-objecten op te slaan.

3 . Tseof en taken

Bij het maken van dit programma zijn de volgende doelen gesteld:

· Schrijf een programma waarmee je informatie over parkeerterreinen kunt verwerken, sorteren en wijzigen.

Bij het maken van dit programma waren er ook de volgende taken:

· Dit programma moet een eenvoudige en handige gebruikersinterface hebben.

· Dit programma zou een laag verbruik van hulpbronnen moeten hebben.

4. Ontwikkeling van systeemmenu's

Het systeemmenu of hoofdmenu moet gemakkelijke gebruikersinteractie met het programma bieden. Het menu moet opties bevatten voor het opslaan, bekijken, invoeren van nieuwe gegevens, enz. De gebruiker hoeft alleen maar op de `enter'-knop te drukken. Er zijn zes items in het menu van dit programma:

1 - Bestanden maken

2 - Een vermelding toevoegen

3 - Recordcorrectie

4 - Bekijk een record uit een bestand

5 - Een vermelding verwijderen

6 - Afsluiten

1 - Maak een nieuw bestand aan - Gemaakt nieuw bestand met een naam die is opgegeven door de programmagebruiker

2 - De inhoud van het bestand bekijken - eerder gemaakte records worden één voor één op het scherm weergegeven in de vorm van:

Achternaam van de eigenaar:

Eigenaars naam:

auto maken:

schaalmodel:

lichaamstype:

nummer van de auto:

regio:

jaar van uitgifte:

kleur:

3 - Een item toevoegen - Creëren nieuwe invoer en het bestand dat het aan het einde van het item toevoegt.

4 - Zoeken op wijknummer - Hiermee kunt u informatie over een vakantieganger vinden op basis van het wijknummer waarop de vakantieganger is geregistreerd.

5 - Verlaat het programma - verlaat het programma

Conclusie

Dankzij het verrichte werk kan elke gebruiker eenvoudig grote hoeveelheden informatie creëren, verwerken, sorteren en selecties maken op basis van bepaalde criteria.

Het gebruik van een dergelijk programma in de moderne wereld vergemakkelijkt de menselijke activiteit enorm.

Geplaatst op Allbest.ru

Soortgelijke documenten

Definitie benodigde modules programma's, databasebestandsstructuren. Beschrijving van programmaontwikkeling, debuggen en testen. Ontwikkeling van de Organizer.exe applicatie, menu en gebruikershandleiding. Algoritme voor het verwerken van gebeurtenissen in het hoofdmenu (schema's).

cursuswerk, toegevoegd op 2/11/2014


Kenmerken van het ontwerpen van een programma in C++ voor het verwerken van gegevens uit databasetabellen. De belangrijkste functies van het programma, het creëren van een conceptueel databasemodel en klassendiagram, het ontwikkelen van een gebruikersinterface en databasequery's.

cursuswerk, toegevoegd op 06/08/2012


Het selecteren van de samenstelling van hardware en software voor systeemontwikkeling. Beschrijving van invoer- en uitvoergegevens. Een databasemodel selecteren. Ontwikkeling van een subsysteem voor het vullen van de database en het genereren van rapporten. Ontwikkeling van gebruikersinterfaces, systeemtesten.

cursuswerk, toegevoegd op 12/04/2014


Stadia van het maken en ontwikkelen van databases. Een domeinmodel bouwen. Ontwikkeling van datalogische en fysieke datamodellen, methoden voor het verwerken van gegevens over de medewerkers van de organisatie. Het ontwerpen van gebruikersapplicaties. Een knopformulier maken.

cursuswerk, toegevoegd op 14-02-2011


Opstellen van een conceptueel datamodeldiagram. Ontwikkeling van relationele databasestructuur en gebruikersinterface. Kenmerken van de belangrijkste fasen van databaseontwerp. Methoden voor het implementeren van query's en rapporten. Bijzonderheden van de gebruikershandleiding.

cursuswerk, toegevoegd op 18-12-2010


Het proces van het ontwikkelen van een database voor het opslaan en verwerken van informatie. Sleutels, indexen, triggers, opgeslagen procedures. Ontwikkeling gebruikersomgeving en databanken. Basishulpmiddelen voor het ontwikkelen van client- en serveronderdelen.

proefschrift, toegevoegd op 18-05-2013


Fasen van databaseontwerp, het definiëren van doelen en tabelinhoud. Gegevens toevoegen en andere databaseobjecten maken. Datalogisch model: structurering, normalisatie, dataschema's. De volgorde en principes van het creëren van een gebruikersinterface.

cursuswerk, toegevoegd op 26-03-2013


Ontwikkelingstechnologie voor gebruikersinterfaces in Delphi-omgeving. Creatie van tabellen, menu's, formulieren voor het invoeren en bewerken van gegevens. Principes van menu-organisatie als onderdeel van de gebruikersinterface. Implementatie van sorteren, filteren, berekeningen in de tabel.

cursuswerk, toegevoegd op 13-11-2012


Basisregels voor het ontwerpen van gebruikersinterfaces. Creatie van een database met behulp van de ontwikkelde modellen. Modulecodering softwaresysteem met als doel een prototype te maken. Het primaire venster wanneer het programma start. Bescherming tegen informatieverlies.

laboratoriumwerk, toegevoegd 13-06-2014


Beschrijving van het ontwikkelingsvakgebied. Kenmerken van het opslaan van informatie over auto's en eigenaren. Beschrijving van de databasestructuur. Hoofdtabellen: auto's, eigenaren, soorten werkzaamheden, reserveonderdelen, bestellingen, diensten. Instructies voor de programmeur en gebruiker.

In het stadium van formulering en analyse van vereisten de doelen van de organisatie worden vastgesteld, de eisen aan de database worden bepaald. Ze bestaan ​​uit Algemene vereisten, hierboven gedefinieerd, en specifieke vereisten. Voor het formuleren van specifieke eisen wordt veelal gebruik gemaakt van de techniek van het interviewen van personeel op diverse managementniveaus. Alle vereisten worden gedocumenteerd in een vorm die toegankelijk is voor de eindgebruiker en de databaseontwerper.

De conceptuele ontwerpfase bestaat uit beschrijving en synthese informatie eisen gebruikers in het oorspronkelijke databaseproject. De brongegevens kunnen een set gebruikersdocumenten zijn (Fig. 3.3) met de klassieke aanpak of toepassingsalgoritmen (bedrijfsalgoritmen) met moderne aanpak. Het resultaat van deze fase is een weergave op hoog niveau (in de vorm van een systeem van databasetabellen) van de gebruikersinformatiebehoeften op basis van verschillende benaderingen.

Eerst wordt het databasemodel geselecteerd. Vervolgens wordt met behulp van YaDM een databasestructuur gecreëerd, die wordt gevuld met gegevens met behulp van YaDM-opdrachten, menusystemen, scherm vormen of in de weergavemodus van de databasetabel. Hierbij wordt de bescherming en integriteit (inclusief referentiële integriteit) van gegevens gewaarborgd door middel van een DBMS of door het construeren van triggers.

Bezig logisch ontwerp de weergave op hoog niveau van de gegevens wordt omgezet in de structuur van het gebruikte DBMS. Het belangrijkste doel van deze fase is het elimineren van gegevensredundantie met behulp van speciale normalisatieregels.

Het doel van normalisatie is het minimaliseren van gegevensherhaling en mogelijke structurele veranderingen in de database tijdens updateprocedures. Dit wordt bereikt door één tabel in twee of meer te verdelen (ontleden) en vervolgens navigatiebewerkingen in query's te gebruiken. Ontvangen logische structuur Een database kan worden gekwantificeerd aan de hand van verschillende kenmerken (aantal toegangen tot logische records, gegevensvolume in elke toepassing, totaal gegevensvolume). Op basis van deze schattingen logische structuur kan worden verbeterd om een ​​grotere efficiëntie te bereiken.

De databasebeheerprocedure verdient een speciale discussie. Het is het gemakkelijkst in de modus voor één gebruiker. In de modus voor meerdere gebruikers en in gedistribueerde databases wordt de procedure veel ingewikkelder. Als meerdere gebruikers gelijktijdig toegang hebben zonder speciale maatregelen te nemen, kan dat mogelijk zijn integriteitsschending. Om dit fenomeen te elimineren, gebruikt u een transactiesysteem en een vergrendelingsmodus voor tabellen of individuele records.

Transactie- het proces van het wijzigen van een bestand, record of database veroorzaakt door de verzending van een enkel invoerbericht.

In de fysieke ontwerpfase worden problemen met betrekking tot de systeemprestaties opgelost opslag structuren gegevens en toegangsmethoden.

De interactie tussen de ontwerpfasen en het woordenboeksysteem moet afzonderlijk worden beschouwd. Ontwerpprocedures kunnen onafhankelijk worden gebruikt bij afwezigheid van een woordenboeksysteem. Het woordenboeksysteem zelf kan worden beschouwd als een onderdeel van ontwerpautomatisering.

Ontwerptools en evaluatiecriteria worden in alle ontwikkelingsfasen gebruikt. Momenteel is de onzekerheid bij de selectie van criteria het grootst zwak punt op het gebied van databaseontwerp. Dit komt door de moeilijkheid van beschrijving en identificatie groot nummer alternatieve oplossingen.

De situatie is eenvoudiger als er met kwantitatieve criteria wordt gewerkt, zoals de reactietijd op een verzoek, de kosten van wijzigingen, de kosten van het geheugen, de tijd om te creëren en de kosten van een reorganisatie. De moeilijkheid kan worden veroorzaakt doordat de criteria elkaar tegenspreken.

Tegelijkertijd zijn het er veel optimaliteitscriteria, dit zijn onmeetbare eigenschappen die moeilijk kwantitatief of als een objectieve functie uit te drukken zijn.

Kwaliteitscriteria kunnen onder meer zijn: flexibiliteit, aanpassingsvermogen, toegankelijkheid voor nieuwe gebruikers, compatibiliteit met andere systemen, vermogen om te converteren naar een andere computeromgeving, vermogen om te worden hersteld, vermogen om te distribueren en uit te breiden.

Het ontwerpproces is lang en arbeidsintensief en duurt doorgaans enkele maanden. De belangrijkste hulpbronnen van de databaseontwerper zijn zijn eigen intuïtie en ervaring, waardoor de kwaliteit van de oplossing in veel gevallen laag kan zijn.

De belangrijkste redenen voor de lage efficiëntie van de ontworpen databases kunnen zijn:

• onvoldoende diepgaande analyse van vereisten (initiële ontwerpfasen), inclusief hun semantiek en datarelaties;
• de lange duur van het structureringsproces, waardoor dit proces vervelend en moeilijk handmatig uit te voeren is.

In deze omstandigheden worden vraagstukken op het gebied van ontwikkelingsautomatisering van het allergrootste belang.

Belangrijkste fasen van databaseontwikkeling

Fase 1. Verduidelijking van taken

In de eerste fase wordt een lijst samengesteld van alle hoofdtaken die in principe door deze applicatie zouden moeten worden opgelost, inclusief de taken die vandaag niet nodig zijn, maar in de toekomst kunnen verschijnen. Met ‘kerntaken’ worden de functies bedoeld die in de aanvraagformulieren of -rapporten moeten worden weergegeven.

Fase 2. Volgorde van taken

Om de applicatie logisch en handig te laten werken, kunt u de hoofdtaken het beste in thematische groepen indelen en vervolgens de taken van elke groep zo rangschikken dat ze zijn gerangschikt in de volgorde waarin ze zijn voltooid. Het kan gebeuren dat sommige taken hiermee verband houden verschillende groepen of dat de uitvoering van een taak vooraf moet gaan aan de uitvoering van een andere taak die tot een andere groep behoort.

Fase 3: Gegevensanalyse

Na het maken van een lijst met taken, het meest belangrijke fase is het samenstellen van een gedetailleerde lijst van alle gegevens die nodig zijn om elk probleem op te lossen. Sommige gegevens zijn nodig als initiële gegevens en zullen niet veranderen. Andere gegevens worden gecontroleerd en gewijzigd naarmate de taak vordert. Sommige gegevensitems kunnen worden verwijderd of toegevoegd. Ten slotte zullen sommige gegevens worden verkregen door middel van berekeningen: hun output zal deel uitmaken van het probleem, maar ze zullen niet in de database worden ingevoerd.

Fase 4. Het definiëren van de datastructuur

Na een voorlopige analyse van alle noodzakelijke gegevenselementen, moet u deze in objecten organiseren en de objecten correleren met tabellen en databasequery's. Relationele toegangsdatabases gebruiken een proces dat normalisatie wordt genoemd om de meest efficiënte en flexibele manier te creëren om gegevens op te slaan.

Fase 5. Ontwikkeling van applicatie-indeling en gebruikersinterface

Nadat u de structuur van de toepassingstabellen hebt gespecificeerd, kunt u in Microsoft Access eenvoudig de lay-out ervan maken met behulp van formulieren en deze aan elkaar koppelen met behulp van eenvoudige macro's of procedures voor het afhandelen van gebeurtenissen. Het is gemakkelijk om een ​​voorlopige werkindeling aan de klant te demonstreren en zijn goedkeuring te verkrijgen, zelfs vóór de gedetailleerde implementatie van de applicatietaken.

Fase 6. Maak een applicatie

Voor zeer eenvoudige taken is de gemaakte lay-out bijna een complete applicatie. Vaak moet u echter procedures schrijven waarmee u de oplossing van alle taken die in het project worden beschreven volledig kunt automatiseren. Daarom moet u speciale verbindingsvormen maken die de overgang van de ene taak naar de andere mogelijk maken.

Fase 7. Testen en verbeteren

Na voltooiing van de werkzaamheden aan individuele onderdelen toepassing, is het noodzakelijk om de werking van de toepassing in elk van de mogelijke modi te controleren. Het is noodzakelijk om de werking van de macro's te controleren met behulp van de stapsgewijze foutopsporingsmodus, waarin één specifiek macrocommando wordt uitgevoerd. Gebruik makend van Visuele basis Voor applicaties beschikt u over een verscheidenheid aan foutopsporingstools om de applicatie te testen en fouten te identificeren en op te lossen.

Omdat er stand-alone onderdelen van de applicatie worden ontwikkeld, is het raadzaam deze aan de klant te overhandigen, zodat deze de werking ervan kan controleren en advies kan krijgen over de noodzaak om bepaalde wijzigingen door te voeren. Nadat de klant kennis heeft gemaakt met de werking van de applicatie, heeft hij vrijwel altijd vragen extra aanbiedingen voor verbetering, hoe grondig de voorstudie van het project ook was. Gebruikers merken vaak dat sommige dingen die ze zeiden erg belangrijk en noodzakelijk waren tijdens het stellen van doelen, in werkelijkheid geen significante rol spelen in het proces. praktisch gebruik toepassingen. Het identificeren van noodzakelijke veranderingen in de vroege stadia van applicatieontwikkeling kan de tijd voor latere herbewerking aanzienlijk verkorten.

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

Handleiding voor databaseontwerp.

1. Inleiding.

SQL is een belangrijk onderwerp en valt buiten het bestek van deze tutorial. Dit artikel is strikt gericht op presenteren databaseontwerpproces. Ik zal de basisprincipes van SQL later in een aparte tutorial bespreken.

Relationeel model.

Reglement 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 van MySQL Workbench).

Voorbeelden.

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 het installeren van MySQL krijgt u 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 geweldige gratis MySQL-applicatie Werkbank. Hiermee kunt u uw database grafisch ontwerpen. De diagramafbeeldingen in de handleiding zijn in dit programma gemaakt.

Ontwerp onafhankelijk van RDBMS.

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.

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 erg populair en worden tegenwoordig breed ondersteund door verschillende software en besturingssystemen. Microsoft Excel 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. Het programma dat dit bestand leest, moet ervan op de hoogte worden gesteld dat de gegevens door komma's worden gescheiden. 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 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.

Tegenwoordig is er een ruime keuze aan databasebeheersystemen beschikbaar: van kleine desktopapplicaties tot multifunctioneel serversystemen met sterk geoptimaliseerde zoekmethoden. Hier zijn enkele van de beroemdste relationele databasebeheersystemen (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. Wordt veel gebruikt door zowel professionals als beginners. Wat is er nog meer nodig?! Het is gratis.
- IBM– heeft een aantal RDBMS's, waarvan DB2 de bekendste is.
- Microsoft Access– 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.

Sleutels gebruiken.

Met behulp van Structured Query Language (SQL) kunnen gegevens uit verschillende tabellen die met elkaar verbonden zijn door een sleutel in één keer worden opgehaald. 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 gebruikersgroepkolom is een externe sleutel. Afgaande op de naam verwijst het blijkbaar naar een tabel die gebruikersgroepen bevat.

Geen gegevensredundantie.

Invoerbeperking.

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 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. 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 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.

Toewijzing van rechten.

Gestructureerde querytaal (SQL).

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.

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.

1. DATABASE-ONTWERP

1.1. Relationele database en zijn structuur

Een database (DB) is een verzameling informatie over objecten, processen, gebeurtenissen of verschijnselen die verband houden met een bepaald vakgebied, onderwerp of taak, georganiseerd volgens bepaalde regels en bijgehouden in het computergeheugen. Het is zo georganiseerd dat het voorziet informatiebehoeften gebruikers, evenals gemakkelijke opslag van deze verzameling gegevens, zowel als geheel als voor elk deel ervan.

Relationele database is een reeks onderling verbonden tabellen, die elk informatie bevatten over objecten van een bepaald type. Elke rij van de tabel bevat gegevens over één object (bijvoorbeeld een auto, een computer, een klant) en de kolommen van de tabel bevatten verschillende kenmerken deze objecten zijn attributen (bijvoorbeeld motornummer, processormerk, telefoonnummers van bedrijven of klanten).

Rijen in een tabel worden records genoemd. Alle tabelrecords hebben dezelfde structuur: ze bestaan ​​uit velden (data-elementen) waarin de attributen van het object zijn opgeslagen (Fig. 1). Elk veld van het record bevat één kenmerk van het object en vertegenwoordigt een bepaald gegevenstype (bijvoorbeeld tekst reeks, nummer, datum). Een primaire sleutel wordt gebruikt om records te identificeren. Hoofdsleutel is een reeks tabelvelden waarvan de combinatie van waarden elke record in de tabel op unieke wijze identificeert.

Rijst. 1. Namen van objecten in de tabel

Om met gegevens te werken, worden databasebeheersystemen (DBMS) gebruikt. Belangrijkste functies van het DBMS:

– datadefinitie (beschrijving van de databasestructuur);

– gegevensverwerking;

– Gegevensbeheer.

Het ontwikkelen van de databasestructuur is de belangrijkste taak die moet worden opgelost bij het ontwerpen van een database. De structuur van een database (de set, vorm en relaties van de tabellen) is een van de belangrijkste ontwerpbeslissingen bij het maken van applicaties met behulp van een database. De databasestructuur die door de ontwikkelaar is gemaakt, wordt beschreven in de DBMS-gegevensdefinitietaal.

Met elk DBMS kunt u de volgende bewerkingen met gegevens uitvoeren:

– records aan tabellen toevoegen;

– records uit de tabel verwijderen;

– het bijwerken van de waarden van sommige velden in een of meer records in databasetabellen;

– zoeken naar een of meer records die aan een bepaalde voorwaarde voldoen.

Om deze bewerkingen uit te voeren, wordt een querymechanisme gebruikt. Het resultaat van het uitvoeren van query's is een reeks records die zijn geselecteerd op basis van bepaalde criteria, of wijzigingen in tabellen. Zoekopdrachten naar de database worden gevormd in een speciaal voor dit doel gemaakte taal, genaamd

“gestructureerde querytaal” (SQL – Structured Query Language).

Gegevensbeheer heeft doorgaans betrekking op het beschermen van gegevens tegen ongeoorloofde toegang, het ondersteunen van gegevensverwerking door meerdere gebruikers en het waarborgen van gegevensintegriteit en -consistentie.

1.2. Stadia van het ontwerpen van een relationele database

De belangrijkste reden dat databaseontwerp moeilijk is, is dat objecten echte wereld en de relaties daartussen hoeven geen structuur te hebben die consistent is met het relationele datamodel, en in de regel ook niet. Bij het ontwerpen moet de ontwikkelaar een representatie bedenken voor echte objecten en hun relaties in termen van tabellen, velden, attributen, records, enz., dat wil zeggen in termen van abstracties van het relationele gegevensmodel. Daarom binnen in deze context de term ‘ontwerp’ kan zowel worden opgevat als een proces, waarvan het resultaat een project is, als als een proces, waarvan het resultaat een projectie is.

Het ontwikkelen van een effectieve database omvat verschillende stappen. Het databaseontwikkelingsproces begint met een analyse van de vereisten. De ontwerper moet in deze ontwikkelingsfase antwoorden vinden op de volgende vragen: welke gegevenselementen moeten worden opgeslagen, wie krijgt er toegang toe en hoe.

In de tweede fase wordt de logische structuur van de database gecreëerd. Om dit te doen, bepaalt u hoe de gegevens logisch worden gegroepeerd. De structuur van de database wordt in dit stadium uitgedrukt in termen van applicatieobjecten en de relaties daartussen.

In de laatste (derde) fase wordt de logische structuur van de database omgezet in een fysieke structuur, rekening houdend met prestatieaspecten. Gegevenselementen ontvangen in dit stadium attributen en worden gedefinieerd als kolommen in de tabellen van het DBMS dat is gekozen voor de implementatie van de database.

Laten we eens kijken naar de toepassing van het concept van relationele databases in de praktijk. Laten we ons de activiteiten van een reisorganisatie voorstellen. Het is duidelijk dat het voor de werking ervan noodzakelijk is om een ​​bepaalde reeks informatie op te slaan en te volgen over de klanten van een bepaald reisbureau (toeristen), over de rondleidingen die hun worden aangeboden, over de registratie en betaling van vouchers. Dit kan in een gewoon papieren notitieboekje worden gedaan, maar na verloop van tijd zal het zoeken naar de benodigde gegevens en financiële rapportages een tamelijk routineuze, tijdrovende klus worden.

1.2.1. Vereisten definiëren

Vereisten voor een databasetoepassing worden doorgaans ontwikkeld via enquêtes en gesprekken met eindgebruikers. Dit is een iteratief proces waarbij ontwikkelaars de structuur van gebruikersdialogen, zoekcriteria voor documenten en mogelijke gebruikersreacties bepalen.

Een algemene techniek voor het definiëren en documenteren van databasevereisten is het samenstellen van een datadictionary. Data dictionary lijsten en definieert individuele elementen gegevens die in de database moeten worden opgeslagen. Een eerste schets van een datawoordenboek voor een manager van een reisbureau wordt weergegeven in Tabel 1.

tafel 1

Gegevenswoordenboek voor database-applicatie voor reisbureaumanagers

Een woordenboek samenstellen – goede manier om te beginnen met het definiëren van uw databasevereisten. Maar één woordenboek is niet voldoende om de structuur van de database te definiëren, aangezien de datadictionary niet beschrijft hoe elementen met elkaar in verband staan, hoe gegevens worden gecreëerd, bijgewerkt en geselecteerd, wie de database zal gebruiken en hoe.

Vereist functionele specificatie, met informatie over het aantal gelijktijdige gebruikers, hoe vaak records worden ingevoegd en bijgewerkt, en hoe informatie uit de database wordt opgehaald.

De functionele beschrijving van een databaseapplicatie voor een reisbureaumanager kan bijvoorbeeld de volgende vereisten bevatten:

De applicatie zal gebruikt worden door het hoofd van het reisbureau, 2 verkoopmanagers, een accountant, een kassier en 2 kantoormedewerkers van het reisbureau - in totaal 7 gebruikers. Er wordt vanuit gegaan dat er niet meer dan 3 medewerkers gelijktijdig met de database zullen werken. Om te kunnen werken hoeft het boekhoudpersoneel alleen toegang te hebben tot de reisbetalingsgegevens.

Alle gebruikers kunnen op elk moment informatie aan de database toevoegen. Wanneer informatie wordt toegevoegd of gewijzigd, moeten de gebruiker die de wijziging heeft aangebracht en de datum en het tijdstip van de wijziging worden vastgelegd.

Eén van de kantoormedewerkers wordt aangesteld als systeembeheerder. Alleen hij mag gebruikersaccounts onderhouden.

De functiespecificatie en datadictionary worden doorgaans gelijktijdig ontwikkeld, omdat deze documenten elkaar informatief aanvullen.

Een belangrijk onderdeel van de behoefteanalyse is het anticiperen op de behoeften van gebruikers, aangezien zij niet altijd in staat zijn hun eigen vereisten voor het systeem volledig en duidelijk uit te leggen. In de praktijk dient een functionele beschrijving het systeem zo volledig en gedetailleerd mogelijk weer te geven.

1.2.2. Logisch model

ER-diagrammen

Een gebruikelijke manier om een ​​logisch databasemodel weer te geven is door ER-diagrammen (Entity-Relationship) te bouwen. In dit model wordt een entiteit gedefinieerd als een afzonderlijk object waarvoor gegevenselementen worden opgeslagen, en beschrijft een relatie de relatie tussen twee objecten.

IN In het voorbeeld van een manager van een reisbureau zijn er vijf hoofdobjecten:

Toeristen

Rondleidingen

Vouchers

Seizoenen

Betalingen

De relaties tussen deze objecten kunnen in eenvoudige termen worden gedefinieerd:

Elke toerist kan één of meerdere (veel) vouchers kopen.

Elke voucher komt overeen met de betaling ervan (betaling

Objecten, attributen en sleutels

Het model wordt verder ontwikkeld door attributen voor elk object te definiëren. Objectattributen zijn gegevenselementen die verband houden met een specifiek object en die moeten worden opgeslagen. We analyseren de samengestelde datadictionary, selecteren daarin objecten en hun attributen en breiden de dictionary indien nodig uit. De attributen voor elk object in het voorbeeld worden weergegeven in Tabel 2.

Houd er rekening mee dat er een aantal items ontbreken. Registratiegegevens vermeld in de functionele specificatie zijn weggelaten. Hoe u er rekening mee kunt houden, denkt u zelf na en maakt u het voorgestelde voorbeeld af. Maar belangrijker nog: de attributen die nodig zijn om objecten met elkaar te verbinden ontbreken nog steeds. Deze gegevenselementen zijn niet weergegeven in het ER-model.

zijn in feite geen ‘natuurlijke’ eigenschappen van objecten. Ze worden op een andere manier verwerkt en er zal rekening mee worden gehouden in het relationele datamodel.

Het relationele model wordt gekenmerkt door het gebruik van sleutels en relaties. Er is een verschil in de context van een relationele database tussen de termen relatie en relatie. Een relatie wordt behandeld als een ongeordende, tweedimensionale tabel met niet-gerelateerde rijen. Het gegevensschema wordt gevormd tussen relaties (tabellen) via gemeenschappelijke attributen, die sleutels zijn.

Er zijn verschillende soorten sleutels, en soms verschillen ze alleen in termen van hun relatie tot andere attributen en relaties. Een primaire sleutel identificeert op unieke wijze een rij in een relatie (tabel), en elke relatie kan slechts één primaire sleutel hebben, zelfs als meer dan één attribuut uniek is. In sommige gevallen is meer dan één attribuut vereist om rijen in een relatie te identificeren. De set van deze attributen wordt genoemd samengestelde sleutel. In andere gevallen moet de primaire sleutel speciaal worden aangemaakt (gegenereerd). In de relatie 'Toeristen' is het bijvoorbeeld zinvol om toe te voegen unieke identificatie toerist (toeristencode) als de primaire sleutel van deze relatie om verbindingen met andere databaserelaties te organiseren.

Een ander type sleutel, een externe sleutel genoemd, bestaat alleen in termen van het gegevensschema tussen twee relaties. Een externe sleutel in een relatie is een attribuut dat de primaire sleutel (of een deel van een primaire sleutel) is in een andere relatie. Dit is een gedistribueerd attribuut dat een gegevensschema vormt tussen twee relaties in de database.

Voor de ontworpen database zullen we de attributen van objecten met codevelden als primaire sleutels uitbreiden en deze codes in databaserelaties gebruiken om als volgt naar databaseobjecten te verwijzen (Tabel 3).

Het is te vroeg om het geconstrueerde databaseschema als voltooid te beschouwen, aangezien normalisatie ervan vereist is. Een proces dat bekend staat als relationele databasenormalisatie wordt gebruikt om attributen te groeperen op bijzondere manieren om redundantie en functionele afhankelijkheid te minimaliseren.

Normalisatie

Functionele afhankelijkheden ontstaan ​​wanneer de waarde van één attribuut kan worden bepaald op basis van de waarde van een ander attribuut. Een attribuut dat kan worden gedefinieerd, wordt aangeroepen functioneel afhankelijk van het attribuut dat de determinant is. Daarom zullen per definitie alle niet-sleutelkenmerken (zonder sleutel) functioneel afhankelijk zijn van de primaire sleutel in elke relatie (aangezien de primaire sleutel elke rij uniek identificeert). Wanneer een attribuut van een relatie niet op unieke wijze een ander attribuut definieert, maar dit beperkt tot een reeks vooraf gedefinieerde waarden, wordt dit een meerwaardige afhankelijkheid genoemd. Een gedeeltelijke afhankelijkheid treedt op wanneer een relatieattribuut functioneel afhankelijk is van één attribuut van een samengestelde sleutel. Transitieve afhankelijkheden worden waargenomen wanneer een niet-sleutelattribuut functioneel afhankelijk is van een of meer andere niet-sleutelkenmerken in een relatie.

Het normalisatieproces bestaat uit stap voor stap opbouwen DB in normale vorm (NF).

Eerst normale vorm(1NF) is heel eenvoudig. Alle databasetabellen moeten aan één enkele vereiste voldoen: elke cel in de tabellen moet een atomaire waarde bevatten, met andere woorden: de opgeslagen waarde binnen het domein van de databasetoepassing mag geen interne structuur hebben waarvan de elementen mogelijk vereist zijn door de database. sollicitatie.

De tweede normaalvorm (2NF) ontstaat wanneer alle gedeeltelijke afhankelijkheden uit de databaserelaties worden verwijderd. Als er geen samengestelde sleutels in de relatie zijn, wordt dit niveau van normalisatie gemakkelijk bereikt.

De derde normale vorm (3NF) van de database vereist het verwijderen van alle transitieve afhankelijkheden.

De vierde normaalvorm (4NF) wordt gecreëerd wanneer alle meerwaardige afhankelijkheden worden verwijderd.

De database van ons voorbeeld bevindt zich in 1NF, omdat alle velden van de databasetabellen een atomaire inhoud hebben. Onze database bevindt zich ook in 2NF, omdat we deze kunstmatig in elke tabel hebben geïntroduceerd unieke codes voor elk object (Toeristencode, Reiscode, enz.), waardoor we 2NF behaalden voor elk van de databasetabellen en de gehele database als geheel. Rest ons nog de derde en vierde normaalvorm te behandelen.

Merk op dat ze alleen relatief bestaan verschillende types afhankelijkheden van databasekenmerken. Er zijn afhankelijkheden - u moet de NF-database betalen, er zijn geen afhankelijkheden - de database bevindt zich al in NF. Maar de laatste optie wordt in echte toepassingen vrijwel nooit gevonden.

Welke transitieve en meerwaardige afhankelijkheden zijn aanwezig in ons voorbeeld van een database voor reisbureaumanagers?

Laten we de houding van "toeristen" analyseren. Laten we eens kijken naar de afhankelijkheden tussen de attributen "Toeristencode", "Achternaam", "Voornaam", "Patroniem" en "Paspoort" (Fig. 3). Elke toerist, vertegenwoordigd door de combinatie “Achternaam – Voornaam – Patroniem”, heeft slechts één paspoort voor de duur van de reis, terwijl volledige naamgenoten moeten beschikken over verschillende nummers paspoorten. Daarom vormen de attributen “Achternaam – Voornaam – Patroniem” en “Paspoort” een samengestelde sleutel in de relatie toeristen.

Samengestelde sleutel

Rijst. 3. Voorbeeld van transitieve afhankelijkheid

Zoals uit de figuur blijkt, is het attribuut ‘Paspoort’ transitief afhankelijk van de sleutel ‘Toeristencode’. Om deze transitieve afhankelijkheid te elimineren, splitsen we daarom de samengestelde sleutel van de relatie en de relatie zelf in 2 volgens één-op-één-relaties. De eerste relatie, laten we het bij de naam “Toeristen” laten, omvat de attributen “Toeristencode” en “Achternaam”, “Voornaam”, “Patroniem”. De tweede relatie, laten we het “Informatie over toeristen” noemen, wordt gevormd door de attributen “Toeristencode” en alle overige attributen van de relatie “Toeristen”: “Paspoort”, “Telefoon”, “Stad”, “Land”, "Inhoudsopgave". Deze twee nieuwe relaties hebben niet langer een transitieve afhankelijkheid en bevinden zich in 3NF.

Er zijn geen meerwaardige afhankelijkheden in onze vereenvoudigde database. Laten we bijvoorbeeld aannemen dat voor elke toerist meerdere contactnummers moeten worden opgeslagen (thuis, werk, mobiele telefoon, enz., wat in de praktijk heel gebruikelijk is), en niet slechts één, zoals in het voorbeeld. We krijgen een meerwaardige afhankelijkheid van de sleutel: "Toeristencode" en de attributen "Telefoontype" en "Telefoon" in deze situatie is de sleutel niet langer een sleutel. Wat moeten we doen? Het probleem wordt ook opgelost door het relatieschema op te splitsen in 2 nieuwe schema's. Eén ervan moet informatie bevatten over telefoons (de relatie 'Telefoons'), en de tweede over toeristen (de relatie 'Toeristen'), die gecontacteerd worden via het veld 'Toeristencode'. “Toeristencode” in relatie tot “Toeristen” zal de primaire sleutel zijn, en in relatie tot “Telefoons” zal dit de externe sleutel zijn.

1.2.3. Fysiek model

Het fysieke datamodel is afhankelijk van het geselecteerde DBMS. Als u bijvoorbeeld van plan bent een Oracle DBMS te gebruiken, zal de fysieke database bestaan ​​uit gegevensbestanden, tabelgebieden, rollback-segmenten, tabellen en kolommen

en indexen.

IN Deze handleiding behandelt de creatie fysiek model DB met behulp van Microsoft Access DBMS en databaseserver Microsoft-gegevens SQL Server 2005 Express-editie.

1.3. Een database maken in Microsoft Access DBMS

1.3.1. Tafels

Om een ​​tabel in Microsoft Access DBMS te maken, gebruiken we de ontwerpmodus (Fig. 4).

Rijst. 4. Ontwerpmodus selecteren

Rijst. 5. Volle lijst tabelvelden

In het venster “Tabel1: tabel” dat verschijnt, moet u de namen van de velden definiëren, die de koppen in deze tabel zullen worden. Laten we de volgende veldnamen invoeren (Fig. 5).

Basistaken voor het ontwerpen van databases

Belangrijkste doelen:

• Ervoor zorgen dat alle benodigde informatie in de database wordt opgeslagen.
• Zorgen voor de mogelijkheid om gegevens te verkrijgen voor alle noodzakelijke verzoeken.
• Verminder gegevensredundantie en duplicatie.
• Waarborgen van de gegevensintegriteit (juistheid van hun inhoud): het elimineren van tegenstrijdigheden in de gegevensinhoud, het elimineren van hun verlies, enz.

Basisfasen van databaseontwerp

Conceptueel (infologisch) ontwerp- het bouwen van een semantisch model van het vakgebied informatie model 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’ in gelijke mate worden gebruikt (bijvoorbeeld ‘conceptueel databasemodel’ en ‘conceptueel domeinmodel’), aangezien een dergelijk model zowel een beeld is van de werkelijkheid als een beeldontwerpdatabase voor deze realiteit.

Het specifieke type en de inhoud van het conceptuele databasemodel wordt bepaald door het formele apparaat dat daarvoor wordt gekozen. Grafische notaties die lijken op ER-diagrammen worden vaak gebruikt.

Meestal omvat het conceptuele databasemodel:

• beschrijving informatie objecten, of concepten van het vakgebied en verbindingen daartussen.
• beschrijving van integriteitsbeperkingen, d.w.z. vereisten voor acceptabele gegevenswaarden en relaties 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 reeks relatiediagrammen, waarin doorgaans primaire sleutels worden gespecificeerd, evenals "koppelingen" tussen de relaties, die externe sleutels zijn.

Een conceptueel model omzetten naar logisch model wordt in de regel volgens formele regels uitgevoerd. Deze fase kan grotendeels worden geautomatiseerd.

In de logische ontwerpfase wordt rekening gehouden met de specifieke kenmerken van een specifiek datamodel, maar mogelijk wordt er geen rekening gehouden met de specifieke kenmerken van een specifiek DBMS.

Fysiek ontwerp

Fysiek ontwerp- het creëren van een databaseschema voor een specifiek DBMS. De specifieke kenmerken van een bepaald DBMS kunnen beperkingen omvatten op de naamgeving van databaseobjecten, beperkingen op ondersteunde gegevenstypen, enz. Bovendien omvatten de specifieke kenmerken van een bepaald DBMS tijdens het fysieke ontwerp de keuze van oplossingen die hiermee verband houden fysieke omgeving gegevensopslag (keuze van beheermethoden schijf geheugen, het verdelen van de database in bestanden en apparaten, methoden voor gegevenstoegang), het maken van indexen, enz.

Normalisatie

Bij het ontwerpen van relationele databases wordt meestal iets gedaan dat normalisatie wordt genoemd.

Entiteitsrelatiemodellen

Entiteit-relatiemodel “Entiteit-relatiemodel” ), of het ER-model, voorgesteld door P. Chen in 1976, is de bekendste vertegenwoordiger van de klasse van semantische (conceptuele, infologische) modellen van het vakgebied. Het ER-model wordt meestal weergegeven in grafische vorm, met behulp van de originele notatie van P. Chen, genaamd ER-diagram, of met behulp van andere grafische notaties ( Kraaienpoot, Informatietechniek en etc.).

De belangrijkste voordelen van ER-modellen:

• zichtbaarheid;
• Met modellen kunt u databases ontwerpen grote hoeveelheid objecten en attributen;
• ER-modellen worden geïmplementeerd in veel computerondersteunde databaseontwerpsystemen (bijvoorbeeld ERWin).

Basiselementen van ER-modellen:

• objecten (entiteiten);
• objectattributen;
• verbindingen tussen objecten.

Een entiteit is een domeinobject dat attributen heeft.

De relatie tussen entiteiten wordt gekenmerkt door:

• verbindingstype (1:1, 1:N, N:M);
• lidmaatschap klasse. Een klasse kan verplicht of optioneel zijn. Als elke entiteitsinstantie betrokken is bij een relatie, is de lidmaatschapsklasse verplicht, anders is deze optioneel.

Semantische modellen

Semantisch model (conceptueel model, infologisch model) is een model van een vakgebied dat is ontworpen om de semantiek van een vakgebied in de werkelijkheid weer te geven. hoog niveau abstracties. Dit betekent dat de noodzaak om concepten op laag niveau te gebruiken die verband houden met de specifieke fysieke representatie en opslag van gegevens wordt geëlimineerd of geminimaliseerd.

Datum K. J. Inleiding tot databasesystemen. - 8e druk. - M.: “Williams”, 2006:

Semantische modellering is sinds eind jaren zeventig het onderwerp van intensief onderzoek. De belangrijkste motivatie voor dergelijk onderzoek (dat wil zeggen het probleem dat de onderzoekers probeerden op te lossen) was het volgende feit. Feit is dat databasesystemen doorgaans een zeer beperkte kennis hebben over de betekenis van de daarin opgeslagen gegevens. Meestal staan ​​ze u alleen toe de gegevens van bepaalde personen te manipuleren eenvoudige soorten en enkele eenvoudige integriteitsbeperkingen definiëren die aan deze gegevens worden opgelegd. Elke complexere interpretatie is de verantwoordelijkheid van de gebruiker. Het zou echter geweldig zijn als systemen wat meer kennis en intelligentie zouden kunnen hebben in het reageren op vragen van gebruikers, en ook meer complexe (dat wil zeggen, hogere) gebruikersinterfaces zouden kunnen ondersteunen.
[…]
Ideeën voor semantische modellering kunnen nuttig zijn als hulpmiddel voor databaseontwerp, zelfs als ze niet rechtstreeks door het DBMS worden ondersteund.

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

Literatuur

• Datum K.J. Inleiding tot databasesystemen. - 8e druk. - M.: “Williams”, 2006. - 1328 p. - ISBN 0-321-19784-4
• Kogalovsky M.R. Veelbelovende technologieën informatie Systemen. - M.: DMK Pers; IT-bedrijf, 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
• Kuznetsov S.D. Basisbeginselen van databases. - 2e druk. - M.: Internetuniversiteit Informatie technologieën; BINOMIAAL. Kennislaboratorium, 2007. - 484 p. - ISBN 978-5-94774-736-2
• Connolly T., Begg K. Database. Ontwerp, implementatie en ondersteuning. Theorie en praktijk = Databasesystemen: een praktische benadering van ontwerp, implementatie en beheer. - 3e druk. - M.: “Williams”, 2003. - 1436 p. - ISBN 0-201-70857-4
• Garcia-Molina G., Ullman J., Widom J. Databasesystemen. Volledige cursus. - M.: “Williams”, 2003. - 1088 p. - ISBN 5-8459-0384-X

zie ook

• Ontwerpmethoden

Koppelingen

• Het entiteit-relatiemodel is een stap in de richting van een uniform beeld van gegevens - Citforum
• Het relationele model uitbreiden om de semantiek beter weer te geven - Citforum
• Een gids voor het ontwerpen van websitedatabases "voor beginners"
• Een methode voor het ontwerpen van de logische structuur van een relationele database zonder tabelnormalisatie

Opmerkingen

Wikimedia Stichting. 2010.

Zie wat “Database Design” is in andere woordenboeken:

Databasebeheerder is een persoon die verantwoordelijk is voor het ontwikkelen van vereisten voor een database, het ontwerp, de implementatie ervan, 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 het ontwerp helpt verbeteren met behoud van de functionele en informatieve semantiek. Met andere woorden: de consequentie van het herstructureren van databases kan niet... ... Wikipedia zijn

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

Het "DB"-verzoek wordt hierheen geleid; zie ook andere betekenissen. Een database die in een objectieve vorm wordt gepresenteerd, is een verzameling onafhankelijke materialen (artikelen, berekeningen, voorschriften, rechterlijke uitspraken en ander soortgelijk materiaal), ... ... Wikipedia