Federaal Agentschap voor Onderwijs
Rijksonderwijsinstelling voor hoger beroepsonderwijs
Staatsuniversiteit Tsjeljabinsk
cursus werk
Ontwikkeling van databasetoepassingen
Domeinanalyse
Beschrijving van het vakgebied en functies van de op te lossen taken
In het cursuswerk worden, in overeenstemming met de opdracht, de activiteiten van de verkoopafdeling van de Russian Food-onderneming geautomatiseerd.
Het onderwerp van het gebied van automatisering zijn enkele functies van de verkoopafdeling. De verkoopafdeling heeft voor drie maanden een plan voor het vrijgeven van gereed product opgesteld. Volgens dit plan produceren de winkels producten, maar de daadwerkelijke output hangt van veel factoren af en kan afwijken van de geplande. De verkoopafdeling ontvangt ook winkelfacturen, die de werkelijke output van producten en hun levering aan bepaalde magazijnen weergeven.
De taak van de verkoopafdeling is het analyseren van de uitvoering van het plan voor de levering van producten aan magazijnen. Om dit te doen, moet u geplande en werkelijke gegevens voor een bepaalde periode voor een bepaald magazijn selecteren en de afwijking van het feit van het plan analyseren.
Het bedrijf heeft 3 werkplaatsen waar producten worden vervaardigd. Het assortiment vervaardigde producten staat in de tabel.
Tafel 1.
Aantal werkplaatsNaam werkplaatsProductnaamMinimale opbrengst Prijs per eenheid melk 3,5% doos 50 stuks650,00 roebel. crèmedoos 50 stuks1 200,00 roebel. gekookte worstverpakking 50 stuks2 500,00 rub.2 worst rookworstverpakking 50 stuks3 400,00 rub. worstenpak van 50 stuks1 200,00 roebel. ingeblikte snoekbaars doos 50 blikken 670,00 roebel 3 viskaviaar zwarte doos 50 blikken 5 400,00 roebel. rode kaviaardoos 50 blikken 5 370,00 roebel. De producten die door de werkplaatsen worden geproduceerd, worden geleverd aan magazijnen Tafel 2. Magazijn nr. Magazijn naam1 Magazijn nr. 12 Magazijn nr. 23 Magazijn nr. 3 Lijst van invoer (primaire) documenten. Als primaire documenten voor het oplossen van dit probleem worden de volgende gebruikt: plattegrond van de winkel winkel factuur lijst WerkplaatsnummerWinkelfactuurnummer Datum van levering specificatie winkelfactuur WinkelnummerWinkelfactuurnummerProductcodeAantal Beperking van het onderwerpgebied. Bij het ontwikkelen van een cursusproject zijn de volgende beperkingen toegestaan: het eindproduct wordt toegewezen aan één magazijn van afgewerkte producten en kan door meerdere werkplaatsen worden geproduceerd. het eindproduct heeft slechts één maateenheid. één winkel kan meerdere soorten producten produceren. Eén magazijn kan meerdere soorten afgewerkte producten opslaan. de productie van afgewerkte producten door de winkel wordt maandelijks gepland. hetzelfde product kan worden gepland voor release in verschillende maanden. de factuur van de werkplaats voor de levering van afgewerkte producten aan het magazijn kan meerdere artikelen bevatten, het nummer is uniek voor slechts één werkplaats. Formulering van het probleem Organisatorische en economische essentie van het takencomplex. Een van de belangrijkste problemen bij de onderneming is de discrepantie tussen de geplande hoeveelheid output, die wordt gevormd in overeenstemming met de aanvragen van kopers, en de werkelijke hoeveelheid producten die door de winkels naar de magazijnen wordt verzonden. Om dit probleem op te lossen is het noodzakelijk om tijdig (spoedig) informatie te krijgen over de aanwezigheid, tekort of overschot aan producten in magazijnen in relatie tot het plan. Het overschot wordt opgeslagen in het magazijn, de houdbaarheid ervan kan worden overschreden en er ontstaan illiquide activa. Beschrijving van uitvoerinformatie De outputinformatie wordt gepresenteerd in de vorm van een rapportageformulier. Analyse van de uitvoering van het plan voor de levering van producten aan het magazijn _________________ MaandProductnaamMaateenheidHoeveelheidOverschotPlanFact Om dit formulier te verkrijgen, worden de gegevens van primaire documenten gebruikt: product lijst; lijst van magazijnen; lijst met werkplaatsen; plan voor de productie van producten door werkplaatsen; lijst met winkelfacturen; Beschrijving van invoergegevens. De invoerinformatie is verdeeld in voorwaardelijk constante (mappen), die de waarden voor een lange periode behouden en voortdurend veranderen, dat wil zeggen operationele boekhoudinformatie. Voorwaardelijk permanente informatie omvat: lijst van vervaardigde producten; lijst van producerende winkels; lijst van magazijnen; naslagwerk van meeteenheden. Operationele boekhoudinformatie omvat: plan voor de productie van producten door werkplaatsen; lijst met winkelfacturen; specificatie van de winkelfactuur. Laten we primaire documenten presenteren met details in Tabel 3: Artikelnr. Naam van het document Details 1 Lijst van vervaardigde producten 1. Productcode 2. Productnaam. 3.Code van de maateenheid. 4.Prijs. 5. Magazijnnummer 3 Lijst met magazijnen 1. Magazijncode. 2.Naam van het magazijn.2Lijst van werkplaatsen1.Code van de werkplaats. 2.Naam van de werkplaats.4Directory van maateenheden1.Code van de maateenheid. 2. Naam van de meeteenheid 5 Plan voor de productie van producten door werkplaatsen 1. Werkplaatsnummer. 2. Maand van uitgave. 3.Productcode. 4.Aantal6Lijst met winkelfacturen1.Winkelnummer. 2. Winkelfactuurnummer. 3. Datum van levering.7 Specificatie winkelfactuur1. Winkelnummer. 2. Winkelfactuurnummer. 3.Productcode. 4. Hoeveelheid. Database-ontwerp Selectie van informatie-objecten Een van de moeilijkste fasen in het database-ontwerpproces is de ontwikkeling van tabellen, aangezien de resultaten die de database moet opleveren (rapporten, uitvoerformulieren, enz.) niet altijd een volledig beeld geven van de structuur van de tabel. Informatie in de tabel mag niet worden gedupliceerd. Er mag geen herhaling tussen de tabellen zijn. Wanneer bepaalde informatie in slechts één tabel is opgeslagen, hoeft deze slechts op één plaats te worden gewijzigd. Dit maakt het werk efficiënter en elimineert ook de mogelijkheid van niet-overeenkomende informatie in verschillende tabellen. Elke tabel moet informatie over slechts één onderwerp bevatten. Informatie over elk onderwerp wordt veel gemakkelijker verwerkt als ze zijn opgenomen in tabellen die onafhankelijk van elkaar zijn. Elke tabel bevat informatie over een afzonderlijk onderwerp en elk veld in de tabel bevat afzonderlijke informatie over het onderwerp van de tabel Om een gegevensverbinding uit verschillende tabellen te implementeren, moet elke tabel een veld of een reeks velden bevatten die de individuele waarde van elke record in de tabel bepalen. Zo'n veld of set van velden wordt een primaire sleutel genoemd. Nadat u gegevens over tabellen hebt verdeeld en sleutelvelden hebt gedefinieerd, moet u relaties tussen tabellen definiëren. Tabel 4 Informatie objecten Informatie obektSootvetstvuyuschy dokumentRekvizityKlyuchIzdeliyaSpisok geproduceerd izdeliyKod izdeliyaDa Naam izdeliyaKod eenheid izmereniyaTsena aantal skladaTsehaSpisok tsehovNomer tsehaDa Naam tsehaSkladySpisok skladovNomer skladDaNaimenovanie skladaEdinitsa izmereniyaSpravochnik unit izmereniyaKod units Unit izmereniyaDa Naam izmereniyaPlan vypuskaPlan lossingsmiddelen tsehamiNomer tsehaDaNomer mesyatsaDa code izdeliyaDa KolichestvoTsehovye nakladnyeSpisok winkel nakladnyhNomer tsehaDa aantal gilde nakladnoyDa Date sdachiSpetsifikatsii Specification gilde nakladnoyNomer tsehaDaNomer winkel afleverbonJa ProductcodeJa AantalMaandVoor het object "Releaseplan"MaandnummerJaNaam maand Informatie-logische modellering en bepaling van verbanden tussen informatie-objecten Een informatie-logisch model is een datamodel dat een onderwerpgebied weergeeft in de vorm van een set informatie-objecten en structurele relaties daartussen. Ons informatie-logisch model ziet er als volgt uit: Figuur 1. infologisch model Als resultaat van de ontwikkeling van de database zijn 8 informatieobjecten verkregen. Laten we het type verbinding definiëren in elk paar van deze inf. voorwerpen. Maateenheid - Product Het type relatie is 1-op-veel, aangezien verschillende producten kunnen worden gemeten met één maateenheid, maar elk product wordt momenteel gemeten met één maateenheid. De verbinding tussen deze objecten is gebaseerd op het attribuut Code van de maateenheid. Magazijnen - Product Het type relatie is 1-op-veel, aangezien meerdere artikelen van gereed product in één magazijn kunnen worden opgeslagen. Communicatie - op vereiste magazijnnummer. Producten - Releaseplan Het type relatie is 1-op-veel omdat één artikel kan worden gepland voor vrijgave in verschillende maanden, maar elke geplande hoeveelheid van toepassing is op slechts één artikel in een bepaalde maand. Communicatie per attribuut Productcode. Maand - Releaseplan Relatietype 1-op-veel, elke maand wordt er een product release plan opgesteld. Contactpersoon op attribuut Maandnummer. Workshops - Releaseplan Communicatietype 1- tot veel, één winkel is gepland om in verschillende maanden te verschijnen. Communicatie per attribuut Werkplaatsnummer. Workshops - Workshop facturen Workshops - Specificaties Relatietype 1-op-veel, één winkel geeft veel facturen uit. Communicatie per attribuut Werkplaatsnummer. Winkelfacturen - Specificaties Relatietype 1-op-veel, één winkelfactuur kan meerdere stuklijsten voor een product bevatten. Communicatie per detail - Winkelfactuurnummer en winkelnummer. Product specificaties Relatietype 1-op-veel, hetzelfde artikel wordt meer dan eens geproduceerd, maar een gegeven hoeveelheid die wordt vrijgegeven verwijst naar slechts één artikel. Communicatie per attribuut Productcode. De logische structuur van de database De logische opbouw van de relationele database is een adequate weerspiegeling van het verkregen informatie-logische model van het vakgebied. Het canonieke model vereist geen extra transformaties. Elk gegevensmodelinformatieobject wordt toegewezen aan een overeenkomstige relationele tabel. De structuur van een relationele tabel wordt bepaald door de attribuutsamenstelling van het corresponderende informatieobject, waarbij elke kolom (veld) overeenkomt met een van de attributen. Sleutelkenmerken vormen een unieke sleutel van een relationele tabel. Voor elke kolom van de tabel worden het type, de gegevensgrootte en andere eigenschappen opgegeven. De topologie van het dataschemaproject valt praktisch samen met de topologie van het informatie-logisch model. Als onderdeel van dit cursuswerk ziet de logische structuur van de database er als volgt uit (Fig. 2): Fig. 2. De logische structuur van de database Database-implementatie in Microsoft Access Om de ontworpen database te implementeren, zullen we een van de meest populaire databasebeheersystemen voor het Windows-besturingssysteem Microsoft Access gebruiken. Dit DBMS is opgenomen in het wijdverbreide geïntegreerde pakket van Microsoft Office en is volledig compatibel met de programma's van dit pakket. Het grote voordeel van MS Access is de beschikbaarheid van hulpmiddelen voor het ontwikkelen van informatiesystemen voor gebruikers met verschillende kwalificaties: van beginners tot professionals. MS Access DBMS is gericht op het werken met de volgende objecten: Tabellen zijn het belangrijkste element van elke relationele database, ontworpen om gegevens te definiëren en op te slaan; Query's dienen als bronnen voor het bouwen van andere query's, formulieren en rapporten. Met query's kunt u gegevens wijzigen en analyseren. Het meest voorkomende type query, een selectiequery, is een set regels waarmee gegevens uit een of meer gerelateerde tabellen worden geselecteerd. De resultaten van de query voor de selectie worden gepresenteerd in de vorm van een virtuele tabel. Formulieren - een object dat voornamelijk is ontworpen om gegevens in te voeren, op het scherm weer te geven of de werking van een toepassing te regelen. Het is mogelijk om formulieren te gebruiken om gebruikerseisen voor de presentatie van gegevens uit query's of tabellen te implementeren, formulieren kunnen ook worden afgedrukt. Rapporten zijn een hulpmiddel voor het organiseren van gegevensuitvoer voor afdrukken. Met behulp van het rapport is het mogelijk om de benodigde informatie in de gewenste vorm weer te geven. U kunt een voorbeeld van het rapport bekijken voordat u het afdrukt. Gegevensbronnen voor rapporten zijn tabellen en query's; Macro's - een object dat een gestructureerde beschrijving is van een of meer acties die MS Access moet uitvoeren als reactie op een specifieke gebeurtenis. Modules zijn objecten die programma's bevatten die zijn geschreven in de taal Visual Basic for Applications (VBA). Als onderdeel van de taak is het niet nodig om macro's en modules in de ontworpen database te maken. Alle MS Access-objecten worden in één bestand op schijf geplaatst. MS Access heeft een interface met meerdere vensters, maar kan slechts één database tegelijk verwerken. Om een nieuwe database aan te maken, moet u MS Access starten, de modus "Nieuwe database" selecteren, de naam van de database invoeren en de locatie op de schijf selecteren. De tabellen van de ontworpen database zijn informatie-objecten, de velden van de tabellen zijn de details van informatie-objecten. Om de invoerinformatie in te vullen, moet een gebruikersinterface worden ontworpen - formulieren: formulier "Producten" - voor het bewerken van de tabel "Producten"; formulier "Productieplan" - om het plan te corrigeren voor het aantal vervaardigde producten; het formulier "Winkelfacturen" verbindt de tabel "Winkelfacturen" en de tabel "Specificaties van winkelfacturen" afhankelijk van de "Winkelfacturen". Om het rapport "Analyse van de implementatie van het plan voor de levering van producten aan het magazijn" te implementeren, volstaat het om één zoekopdracht uit te voeren om de maand (tabel "Maand"), productnaam (tabel "Producten"), maateenheid (tabel "Maateenheid"), hoeveelheid volgens plan ( tabel "Productieplan"), hoeveelheden achteraf (tabel "Specificaties"), met toevoeging van de kolom "overschot" met de aftrekformule . Tabel maken en gegevensschema verkoop van applicatiedatabases Er zijn verschillende modi voor het maken van tabellen (tabelmodus, ontwerper, tabelwizard, tabellen importeren, linken naar tabellen uit andere databases). De meest veelzijdige manier om een tafel te maken, is door de ontwerpmodus te gebruiken. Om in deze modus een tabel te maken, moet u de tabelvelden definiëren. Elk veld wordt gekenmerkt door een naam, gegevenstype en eigenschappen. De veldnaam mag geen speciale tekens bevatten. Microsoft Access ondersteunt de volgende gegevenstypen: Tekst - wordt gebruikt om alfanumerieke informatie op te slaan. De veldlengte mag niet langer zijn dan 255 tekens; MEMO-veld - ontworpen om alfanumerieke informatie tot 65535 tekens lang op te slaan; Numeriek - gebruikt voor numerieke gegevens die betrokken zijn bij berekeningen; Datum / tijd - datum en (of) tijd in het bereik van 100 tot 9999; Monetair - gebruikt voor geldwaarden en numerieke gegevens die worden gebruikt in wiskundige berekeningen, uitgevoerd met een nauwkeurigheid tot 15 cijfers in het geheel en tot 4 cijfers in het fractionele deel; Teller - dient om unieke opeenvolgend stijgende of willekeurige getallen te genereren die automatisch in het veld worden ingevoerd bij het toevoegen van elk nieuw record aan de tabel. Waarden van velden van het type Teller kunnen niet worden gewijzigd; Boolean - ontworpen voor booleaanse waarden (Ja/Nee, Waar/Onwaar). Logische veldlengte - 1 bit; Een OLE-objectveld is elk object in binair formaat (Word-document, Excel-spreadsheet, tekening, geluidsopname) gekoppeld aan of ingebed in een MS Access-tabel. De grootte van een dergelijk veld mag niet groter zijn dan 1 GB; Lookup Wizard - maakt een veld dat een keuze biedt uit waarden uit een lijst, of uit een keuzelijst met invoervak met een set constante waarden of waarden uit een andere tabel. Als u deze optie selecteert in de lijst in een cel, wordt een opzoekwizard gestart die het veldtype bepaalt. Veldeigenschappen worden ingesteld onder aan het tabelontwerpvenster op het tabblad Algemeen. De lijst met eigenschappen is voor elk gegevenstype anders. Laten we er een paar bekijken: Veldgrootte - beperkt de veldlengte tot een bepaald aantal tekens; Formaat - specificeert het formaat voor datums en getallen; Aantal decimalen - voor monetaire en numerieke velden stelt u het aantal decimalen in; Invoermasker - voor tekstvelden en datumvelden, definieert de sjabloon volgens welke gegevens in het veld worden ingevoerd; Geïndexeerd veld - hiermee kunt u een index maken die het zoeken versnelt en de tabel op dit veld sorteert. Een index is een interne servicetabel die uit twee kolommen bestaat: de waarde van het geïndexeerde veld en het tabelnummer. U kunt de volgende eigenschappen voor indexen instellen: a) "Ja (overeenkomsten zijn toegestaan)" - er wordt een index gemaakt die overeenkomende veldwaarden bevat, b) "Ja (overeenkomsten zijn niet toegestaan)" - er wordt een index gemaakt op basis van een unieke veldwaarde, c) "Nee ' - index is niet gemaakt Een tabel in MS Access bevat meestal een primaire sleutel. Om een sleutel te maken, moet u een veld in de constructor selecteren en het toewijzen als een sleutel via het contextmenu. VeldGegevenstypeVeldgroottePrimaire sleutelEenheidscodeNumeriek Lang geheel getalJa EenheidsnaamTekst50 Tabel "Producten" VeldGegevenstypeVeldgroottePrimaire sleutel ItemCodeNumeriek lang geheel getalJa ItemnaamTekst100EenheidscodeNumeriekLang geheel getalPrijs Monetair-magazijnnummerNumeriekByte Tabel "Magazijnen" VeldGegevenstypeVeldgroottePrimaire sleutelMagazijnnummerNumeriek ByteJa MagazijnnaamTekst20 Maandtabel VeldGegevenstypeVeldgroottePrimaire sleutelMaandnummerNumeriek geheel getalJa(geen overeenkomsten toegestaan)Maandnaam Tekst20 Tafel "Werkplaats" VeldGegevenstypeVeldgroottePrimaire sleutelWinkelnummerNumeriek ByteJa WinkelnaamTekst30 Tabel vrijgeven VeldGegevenstypeVeldgroottePrimaire sleutelWinkelnummerNumeriekByteJaMaandNummerNumeriekIntegerJaOnderdeelCodeNumeriek LangIntegerJaHoeveelheidNumeriekReal(16) Tabel "Winkelfacturen" VeldGegevenstypeVeldgroottePrimaire sleutelWinkelnummerNumeriekByteJa WinkelfactuurnummerNumeriekLang geheel getalJa LeveringsdatumDatum\tijd- Tabel "Specificaties" VeldGegevenstypeVeldgroottePrimaire sleutelWinkelnummerNumeriekBytejaWinkelfactuurnummerNumeriekLang geheel getaljaOnderdeelcodeNumeriek lang geheel getaljaHoeveelheidNumeriekReal (16) Maak een gegevensschema in Microsoft Access: Afb.3. Gegevensschema De gebruikersinterface bouwen Formulieren zijn het belangrijkste middel om een gebruikersinterface te creëren die de handigste manier biedt om gegevens te presenteren, te bekijken, te bewerken en de voortgang van een toepassing te controleren. De belangrijkste functies van formulieren zijn gegevensinvoer, informatie-uitvoer en -bewerking, voortgangscontrole van toepassingen, uitvoer van berichten en afdrukken van informatie. Er zijn de volgende soorten formulieren: Normaal - geeft één record van de gegevensbron weer; Meerdere pagina's - ontworpen om te werken met een gegevensbron met een groot aantal velden; Lint - toont verschillende records van de gegevensbron, handig voor een klein aantal velden; Pop-up - wordt op de voorgrond van het scherm weergegeven en stelt u in staat om met andere formulieren te werken; Exclusief - staat niet toe om over te schakelen naar andere vormen totdat deze is gesloten; Een subformulier is een goede manier om gegevens weer te geven die zich aan de 'veel'-kant van een een-op-veel-relatie bevinden en die zijn ingebed in het hoofdformulier en er altijd van afhankelijk zijn. Structureel bestaat het formulier uit drie secties - koptekst, notitie en gegevensgebied. Formuliersecties bevatten besturingselementen. Elk besturingselement kan op een formulier worden geplaatst met behulp van de toolbox, die wordt weergegeven in de ontwerper van het formulier. Meest gebruikte elementen: (inscriptie) - dient om permanente inscripties in de vorm te maken; (veld) - een element dat de waarde uit de gegevensbron laat zien; (combo box) - ontworpen om te worden gemaakt in de vorm van vervolgkeuzelijsten; (knop) - ontworpen om opdrachtknoppen in de vorm te maken die bepaalde acties uitvoeren; (checkbox) - een element waarmee u de waarde van een parameter kunt in- of uitschakelen; (subformulier) - dient om een subformulier in te sluiten in het hoofdformulier. Het is handiger om een formulier te maken met de wizard. De eerste stap is het selecteren van de gegevensbron en velden voor het formulier. De tweede stap is het specificeren van het uiterlijk van het ontworpen formulier. De derde stap is het kiezen van de stijl van het formulier (achtergrondafbeelding voor het formulier, lettertype-indeling en kleurenschema). De laatste stap is het invoeren van de naam van het formulier waaronder het in de database wordt opgeslagen. Het formulier dat met de wizard is gemaakt, moet worden voltooid in de ontwerpmodus. Voeg de nodige inscripties, knoppen, subformulieren toe. Als onderdeel van het cursuswerk zijn de volgende formulieren gemaakt: Rijst. 4. Producten. Afb.5. Vrijgaveplan. Het formulier "werkplaatsfacturen" bevat een subformulier "Specificaties" Afb.6. Facturen winkelen. Rapportimplementatie Voordat u een rapport maakt, moet u een query maken. Query's zijn een essentieel hulpmiddel in elk databasebeheersysteem. Doel van verzoeken - in de beschrijving van soorten verzoeken. Query's kunnen zowel in de Query Wizard-modus (dan moet u het type query selecteren) als in de Query Builder worden gemaakt. Er zijn vier soorten query's in Microsoft Access: eenvoudige selectiequery's geven gegevens uit een of meer tabellen weer in de vorm van een tabel; het toevoegen van een parameter (selectievoorwaarde) is toegestaan; kruisvragen verzamelen gegevens uit een of meer tabellen in een spreadsheetachtig formaat en worden gebruikt om de gegevens te analyseren; het toevoegen van een parameter (selectievoorwaarde) is toegestaan; wijzigingsverzoeken worden gebruikt om nieuwe tabellen te maken op basis van de resultaten van een query en om wijzigingen aan te brengen (toevoegen, verwijderen) aan de gegevens van bestaande tabellen; het toevoegen van een parameter (selectievoorwaarde) is toegestaan; een query om te zoeken naar records die niet overeenkomen met een record in de ondergeschikte tabel. Door query's te gebruiken in de Query Wizard-modus (door een query-overzichtsrapport te selecteren), is het mogelijk om een berekening (som, gemiddelde, min, max) uit te voeren met behulp van de geselecteerde gegevens. Om het rapport "Analyse van de uitvoering van het plan voor de levering van producten aan magazijn nr. ___" te implementeren, volstaat het om één zoekopdracht uit te voeren om de maand (tabel "Maand"), productnaam (tabel "Producten" te selecteren) ), maateenheid (tabel "Maateenheid"), hoeveelheid per plan (tabel "Plan van vrijgave"), hoeveelheid achteraf (tabel "Specificaties"), met toevoeging van de kolom "overschot" met de aftrekformule , evenals met de selectie van het magazijnnummer (tabel "magazijnen") met de selectievoorwaarde zonder dit magazijn in de resulterende tabel weer te geven. Voor dit rapport is de query gemaakt met behulp van de constructor: Afb.8. Vraag resultaat aan. Aan de hand van de verschillende hoeveelheden goederen uit de specificatie is te zien dat snoekbaars in blik zowel in juli als in september twee keer aan het magazijn is geleverd. Rapportage Rapporten zijn de beste manier om informatie uit een database te presenteren in de vorm van een afgedrukt document. Ze bieden voldoende mogelijkheden voor het groeperen en berekenen van subtotalen en eindtotalen voor grote datasets. De rapporten kunnen worden gebruikt om prachtig ontworpen facturen, inkooporders, adresetiketten, presentatiematerialen en andere documenten te maken die u nodig hebt om uw bedrijf succesvol te runnen. Het rapport bevat de volgende gebieden: titel - wordt slechts één keer weergegeven aan het begin van het rapport; kop- en voettekst - herhaald op elk blad van het rapport, gebruikt om permanente of periodieke informatie weer te geven (rapportdatum, paginanummers, enz.); kopjes en opmerkingen voor groepen - worden weergegeven bij het groeperen in het rapport aan het begin en aan het einde van elke groep. U kunt maximaal tien groeperingsniveaus in een rapport maken; gegevensgebied - gebruikt om informatieve regels van het rapport in te voeren; rapportnotitie - ontworpen om samenvattende informatie over het rapport als geheel weer te geven, eenmaal afgedrukt aan het einde van het rapport. Het maken van een rapport, evenals formulieren, is handiger om uit te voeren met behulp van een wizard. Nadat u een rapport hebt gemaakt, kunt u de structuur ervan wijzigen in de ontwerpweergave (corrigeren en opmaken van kolomkoppen voor rapporten, velden toevoegen of verwijderen, enz.). Als resultaat van de uitvoering van het rapport werd de gedrukte vorm verkregen. Analyse van de implementatie van het plan voor de levering van producten aan magazijn nr. 1, 2, 3 - Fig. 10-12. Het veld "winkelfactuurnummer" is toegevoegd om duidelijk te maken dat het product twee keer per maand op twee verschillende facturen in het magazijn kan worden afgeleverd. Afb.9. Rapportontwerper Afb.10. Analyse van de implementatie van het plan voor de levering van producten aan magazijn nr. 1 Afb.11. Analyse van de uitvoering van het plan voor de levering van producten aan magazijn nr. 2 Afb.12. Analyse van de implementatie van het plan voor de levering van producten aan magazijn nr. 3 Bibliografie Tarasov V.L. Werken met databases in de Access-omgeving, Tutorial / Nizhny State University, Nizhny Novgorod, 2005. Shekhtman V.E. Databases, SQL Educatief-methodisch handboek over de disciplines "Databases", "Databases en expertsystemen", "Moderne SQL-programmeertechnologie". / - NFI KemSU, Novokoeznetsk, 2006. Andreev V.A., Tupikina EN, Databasebeheersystemen (Microsoft Access), richtlijnen / FESCO, Vladivostok, 2003. Veiskas D., Effectief werken met ACCESS, leerboek / St. Petersburg, 1996. Homonenko A.F., Tsygankov VM, Maltsev M.G. Databases, leerboek voor middelbare scholen / Ed. prof. AD Homonenko.- St. Petersburg: CROWN print, 2002.
Zoals hierboven vermeld, plaatst het juiste gebruik van gespecialiseerde componenten ze qua prestaties bijna op hetzelfde niveau als API-aanroepen van het geselecteerde DBMS. Naar mijn mening is het gebruik van de API gerechtvaardigd in het zeldzame geval dat de mogelijkheden van zelfs specifieke componenten voor ontwikkeling niet voldoende zijn, hoewel dit uiterst onwaarschijnlijk is, of als dergelijke componenten niet beschikbaar zijn voor het platform in ontwikkeling (Sun Solaris) . Databasequery's maken. Zodra we onze datatoegangsstrategie hebben gekozen en de applicatiearchitectuur hebben bepaald, kunnen we bekijken hoe we deze gaan gebruiken. De hoofdregel is dat hoe minder data je van de server vraagt, hoe sneller je applicatie draait. Natuurlijk is het niet rationeel om de server om minder gegevens te vragen dan de gebruiker in één keer wil zien, dus de eerste vraag zou moeten zijn "welke gegevens zijn nodig voor elke module van het systeem?" Ontwikkelaars die migreren vanuit desktopdatabases moeten de tabelgeoriënteerde weergave van databases overwinnen. InterBase bevat zeker tabellen. Maar bij het ontwerpen van een programma zie je ze niet, je ziet alleen het resultaat van het uitvoeren van de SQL-query. U kunt natuurlijk een query schrijven die alle records van een tabel retourneert (tenminste die zichtbaar zijn voor een bepaalde transactie):
KIES * VANUIT SOME_TABLE
Maar in de meeste gevallen levert een dergelijke query aanzienlijk meer gegevens op dan nodig is voor een optimale gebruikersinterface en verwerking van bedrijfsprocessen. Zo'n query gebruikt trouwens niet zulke handige InterBase/Firebird-functies als de mogelijkheid om de resulterende dataset samen te voegen (JOIN) en te sorteren (ORDER BY).
Vraag minder data aan - krijg meer snelheid. Mogelijk hebt u niet alle kolommen van een tabel nodig om bepaalde taken in een programma uit te voeren. In feite moet u het "*"-teken niet vaak gebruiken in geselecteerde zoekopdrachten, het is beter om een directe opsomming van velden te gebruiken. Deze methode is gebaseerd op het feit dat zelfs als ik alle kolommen van de tabel nodig heb, ik niet de kolommen van de tabel nodig heb die in de toekomst zullen worden toegevoegd wanneer ik dit deel van het programma voltooi. Het definiëren van specifieke kolommen in de query zorgt ervoor dat ik alleen de kolommen krijg die ik in de query heb gedeclareerd, zelfs als de tabelstructuur verder evolueert. Evenzo, zelfs als de gebruiker echt alle records uit de tabel nodig heeft, zonder uitzondering, hoeft hij ze niet allemaal tegelijk te zien. Het kan voor een gebruiker erg onhandig zijn om te zoeken naar velden in het midden van een dataraster in een tabel met een bovengemiddeld aantal records. Laten we zeggen dat als u meer dan 100 records in uw tabel heeft, u al zou moeten nadenken over het ontwerp van uw toepassing.
Waar komt het allemaal op neer? Hier is het ding: hoe minder gegevens u opvraagt en verzendt, hoe sneller uw toepassing zal werken, zelfs op langzamere netwerken. Hier zijn enkele toepassingsmethoden die u kunt gebruiken om de hoeveelheid SELECT-gegevens te verminderen.
Bied de gebruiker goede hulpmiddelen om de records te vinden waarin hij geïnteresseerd is. Als de lijst te groot is om op een enkele, ononderbroken manier te worden weergegeven, verdeel deze dan in logische tabbladen op basis van de eerste letters "A" tot en met "Z". Als de lijsten in dit geval te lang zijn, moet u de gebruiker krachtige tools voor gegevensfiltering bieden om de resulterende reeks records te verfijnen als gevolg van het toepassen van het filter. Om het ophalen van gegevens in een toepassing te implementeren, kunt u de methoden gebruiken die worden gebruikt om webpagina's te doorzoeken. Wanneer een gebruiker een set records te zien krijgt, zelfs als deze relatief klein is, is het voldoende om een of twee sleutelvelden te gebruiken om een queryfilter te vormen. Laat de applicatie een apart venster of een deel van het venster hebben waar de gebruiker alle gegevens voor het record kan zien als hij heeft gevonden wat hij zocht. Probeer waar mogelijk ook table joins (JOIN) in query's te gebruiken in plaats van opzoekvelden op formulieren. Hoewel het mogelijk is om de uitvoering van de TDataset te optimaliseren. Lookup, zelfs deze verbeterde methode zal niet sneller werken dan het samenvoegen van tabellen (JOIN) - je kunt de werking van de ongewijzigde methode helemaal niet noemen.
Laten we een eenvoudige databasetoepassing maken die informatie weergeeft uit de tabel Toeristen en de tabelinvoer Toeristeninfo die is gekoppeld aan het huidige record in de tabel Toeristen uit een Microsoft Access-database.
Om dit te doen, zullen we een lege Windows-toepassing maken. Uiterlijk van de omgeving
ontwikkeling is weergegeven in figuur 39.
Rijst. 39. Lege app
Afbeelding 39 markeert de componentgroep Gegevens, die componenten bevat voor toegang tot en manipulatie van gegevens.
De binding van de databasegegevens aan het formulier wordt uitgevoerd door de component "Binding Source". Laten we het overzetten naar het formulier. Nadat deze op het formulier is geplaatst, heeft de ontwikkelomgeving de volgende vorm (Fig. 40).
Rijst. 40. Het onderdeel Bindende bron op het formulier
Het onderdeel is niet-visueel, dus het wordt weergegeven in een extra paneel. De belangrijkste eigenschap van de component is de eigenschap DataSource, die verwijst naar de gegevensbron. Standaard is de eigenschap leeg, dus u moet de waarde ervan vormen. Wanneer deze eigenschap is geselecteerd, verschijnt het volgende venster in het eigenschappenvenster (Fig. 41).
Rijst. 41. Lijst met gegevensbronnen
De lijst is momenteel leeg, dus u moet een nieuwe gegevensbron maken door de opdracht "Projectgegevensbron toevoegen" te selecteren om een nieuwe gegevensbron te maken en er verbinding mee te maken. Het volgende dialoogvenster verschijnt (Afb. 42).
Rijst. 42. Lijst met gegevensbronnen
Dit dialoogvenster biedt de volgende selectie van gegevensbronnen:
Gegevensbestand - Gegevensbestand;
Service - Service, dit is een service die gegevens levert. Meestal is dit een webservice;
Object - Een object voor het selecteren van een object dat gegevens en objecten genereert om ermee te werken.
In ons geval moet u het item "Database" selecteren. Het keuzevenster voor de dataverbinding verschijnt (Afb. 43).
Rijst. 43. Een dataverbinding selecteren
Het doel van dit dialoogvenster is om een verbindingsreeks te maken die de verbindingsparameters voor de ADO-engine beschrijft, zoals het type database, de locatie, gebruikersnamen, beveiligingsfuncties, enzovoort.
De vervolgkeuzelijst van het dialoogvenster bevat alle eerder gemaakte verbindingen. Als de vereiste verbinding niet in de lijst staat, moet de knop "Nieuwe verbinding" worden gebruikt. Als u op de knop drukt, verschijnt het volgende dialoogvenster (Afb. 44).
Dit dialoogvenster selecteert het type gegevensbron (in dit geval Microsoft Access), de naam van de database (in dit geval de naam en locatie van het databasebestand), de gebruikersnaam en het wachtwoord die worden gebruikt om verbinding te maken met de database. Met de knop "Geavanceerd" kunt u een groot aantal parameters instellen die betrekking hebben op verschillende onderdelen van de ADO-engine. Door gebruik te maken van de knop "Verbinding testen" zorgt u ervoor dat de ingevoerde parameters correct zijn en dat de verbinding werkt.
Rijst. 44. Maak een nieuwe verbinding
De laatste stap van het dialoogvenster is de selectie van die tabellen of andere databaseobjecten die nodig zijn in deze gegevensbron. Het selectievenster wordt weergegeven in Afbeelding 45.
Rijst. 45. De gewenste tabellen selecteren
In dit venster zijn de tabellen "Toeristen" en "Informatie over toeristen" geselecteerd. Aangezien er geen andere objecten dan tabellen in de database zijn gemaakt, worden in Afbeelding 45 alleen tabellen weergegeven. Hiermee is het maken van de gegevensbron voltooid. Nadat u op de knop "Voltooien" naast de component BindingSource hebt geklikt, verschijnt de DataSet-component op het formulier.
Nu moeten de hierboven verbonden gegevens op het formulier worden weergegeven. De eenvoudigste manier om gegevens weer te geven, is door de component DataGridView uit de componentgroep Gegevens te gebruiken. Het onderdeel is visueel en ziet er zo uit op het formulier (afb. 46).
Rijst. 46. DataGridView-component
Het componentinstellingenvenster verschijnt onmiddellijk, dat de mogelijkheden voor gegevensbewerking bepaalt: "Bewerken inschakelen" ("Toevoegen inschakelen"), "Bewerken inschakelen" ("Bewerken inschakelen"), "Verwijderen inschakelen" ("Verwijderen inschakelen"); de mogelijkheid om de volgorde van kolommen te wijzigen: "Schakel de mogelijkheid in om de volgorde van kolommen te wijzigen" ("Enable Column Reordering"); evenals de mogelijkheid om in de bovenliggende container te pinnen.
Om ervoor te zorgen dat het onderdeel gegevens kan weergeven, moet u de gegevensbron selecteren in de vervolgkeuzelijst. Het selecteren van de vervolgkeuzelijst leidt tot het verschijnen van het volgende dialoogvenster (Fig. 47).
Rijst. 47. Een gegevensbron selecteren voor de DataGridView
In dit geval hebben we de tabel "Toeristen" als gegevensbron gekozen. Deze keuze verandert de schermvorm als volgt (Fig. 48).
Rijst. 48. De component DataGridView geeft de structuur van de tabel weer
De afbeelding laat zien dat er nog een BindingSource-component en een TableAdapter-component is die werkt met de tabel "Tourists". Houd er rekening mee dat in ontwerptijd of tijdens ontwikkeling de gegevens uit de tabel niet worden weergegeven.
Nu moet u gegevens uit de gerelateerde tabel "Toeristeninformatie" weergeven. Laten we hiervoor een andere DataGridView-component op het formulier plaatsen en het volgende als de gegevensbron selecteren (Fig. 49).
Rijst. 49. Een gegevensbron selecteren voor de tweede DataGridView
De gegevensbron is hier niet de tabel "Toeristeninformatie" zelf, maar de koppeling (Bindende bron) tussen de tabellen "Toeristen" en "Toeristeninformatie". Deze selectie zorgt ervoor dat alleen die rijen in de VVV-tabel die gerelateerd zijn aan de huidige rij in de Toeristen-tabel worden geselecteerd uit de VVV-tabel. Het zorgt er ook voor dat gerelateerde gegevens correct worden bijgewerkt en verwijderd. De werking van de resulterende applicatie wordt getoond in figuur 50.
Rijst. 50. Database-applicatie in actie
Navigeren door gegevens met de pijltjestoetsen is onhandig. Om de gegevensnavigatie te vereenvoudigen, is er een BindingNavigator-component. Laten we het op het formulier plaatsen (Fig. 51).
Rijst. 51. De component BindingNavigator op het formulier
Met dit onderdeel kunt u navigeren tussen tabelinvoeren, tabelrijen toevoegen en verwijderen. De functies en het uiterlijk van de component kunnen worden aangepast omdat het een ToolStripContainer-menubalk is.
De eigenschap die de tabel definieert waar doorheen moet worden genavigeerd, is de eigenschap BindingSource. Stel de waarde van deze eigenschap in op "touristsBindingSource". In bedrijf ziet het onderdeel er als volgt uit (afb. 52).
Rijst. 52. De component BindingNavigator aan het werk
Het bewerken van gegevens in de cellen van de DataGridView-component met de juiste instellingen is mogelijk, maar onhandig en niet rationeel. Met name is het moeilijk om ingevoerde waarden te controleren op fouten. Daarom zullen we voor de tabel "Toeristen" een schermformulier maken waarmee u gegevens in TextBox-componenten kunt weergeven en bewerken. Om dit te doen, plaatsen we als volgt een container van het type Paneel op het formulier en drie TextBox-componenten erop (Fig. 53).
Rijst. 53. Schermpaneel voor het bewerken van records van de tabel "Toeristen"
Nu moet u de TextBox-componenten binden aan de overeenkomstige velden van de tabel "Toeristen". Gebruik hiervoor de eigenschap van de groep DataBindings - Geavanceerd, weergegeven in Afbeelding 54.
Rijst. 54. "DataBindings - Geavanceerd" eigenschap
Als u deze eigenschap selecteert, verschijnt het dialoogvenster dat wordt weergegeven in Afbeelding 55. Met dit dialoogvenster kunt u niet alleen gegevens binden, maar ook een gebeurtenis instellen waarin de gegevens worden bijgewerkt, evenals gegevensopmaak wanneer ze worden weergegeven.
Selecteer voor de bovenste TextBox-component in de vervolgkeuzelijst Binding de gegevensbron "touristsBmdmgSource" en het bronveld - "Achternaam". Voor de middelste en onderste componenten van de TextBox zullen we dezelfde gegevensbron en respectievelijk de velden "Voornaam" en "Patroniem" selecteren.
De ontwikkelde applicatie in werking ziet er als volgt uit (Fig. 56).
Rijst. 55. Dialoogvenster voor de eigenschap "DataBindings - Geavanceerd"
Rijst. 56. Gegevens binden aan visuele componenten
Wanneer er echter wijzigingen worden aangebracht, blijven alle nieuwe gegevens alleen op het formulier staan. Ze worden niet opgeslagen in de database en wanneer de toepassing opnieuw wordt aangeroepen, zullen ze natuurlijk afwezig zijn. Dit komt omdat de gegevens zijn geladen in een DataSet-object, dat een in-memory kopie van de tabel is. Op deze kopie worden alle handelingen uitgevoerd. Om ervoor te zorgen dat de wijzigingen in de database worden weergegeven, moet u de methode Update van de klasse TableAdapter uitvoeren. In de applicatie die wordt ontwikkeld, is het dus noodzakelijk om de knop "Update" te plaatsen en de volgende programmacode naar de Click-gebeurtenishandler te schrijven:
toeristenTableAdapteGUpdate(bDTur_firmDataSet); tourist_informationTableAdapter.Update(bDTur_firmDataSet);
Deze code werkt de informatie bij in de tabellen "Toeristen" en "Toeristeninformatie" die door de gegevensbron worden geleverd. Houd er rekening mee dat deze methode overbelast is en dat u met de varianten ervan zowel een enkele tabelrij als een groep rijen kunt bijwerken.
30.04.2009 Alexey Kovjazin
Relationele databases zijn doorgedrongen in bijna alle informatiesystemen en lijken het meest gevestigde gebied van IT te zijn geworden, waar weinig kan worden uitgevonden, maar de echte stand van zaken is verre van ideaal.
Relationele databases worden tegenwoordig in bijna alle toepassingen gebruikt, van ingebed in mobiele en speciale apparaten, webgebaseerde toepassingen en eindigend met bedrijfsbeheersystemen. De penetratie van databases in allerlei soorten applicaties versnelt en ontwikkelaars krijgen steeds meer gebruiksvriendelijke tools en benaderingen. Je zou de indruk kunnen krijgen dat ontwikkelaars van databaseapplicaties de meest "welvarende" laag programmeurs zijn die de tools voor alles hebben, maar dit is verre van het geval. Embarcadero Technologies, die in 2008 de CodeGear-ontwikkeltools-business van Borland overnam, combineerde professionele applicatie-ontwikkeling en ontwerptools, ontwikkeltools en databasebeheertools om zowel applicatie- als databaseproblemen te elimineren.
Chaotisch database-ontwerp
Er is een gevestigde overtuiging in de moderne softwareontwikkelingsindustrie dat het onmogelijk is om de vereisten voor een product te bepalen voordat een project wordt gestart, en daarom moet de ontwikkeling worden aangepast aan hun constante verandering. Als gevolg hiervan zijn processen verschenen die gebaseerd zijn op iteraties, rekening houdend met veranderende vereisten, en is het herstructureren van broncode een integraal onderdeel geworden van softwareontwikkeling. En wat gebeurt er bij het iteratief ontwikkelen van databases? Veranderende vereisten dwingen je om het databaseschema aan te passen, en meestal gebeurt dit op een ondoorzichtige manier, zonder het grote geheel en de afhankelijkheden te analyseren. Tabellen, velden, externe sleutels en beperkingen worden willekeurig gemaakt en gewijzigd, niemand bewaakt de referentiële integriteit en niemand kan met zekerheid zeggen hoe de database bij iteratie N verschilt van zijn toestand bij iteratie N-1.
In feite wordt de ontwikkeling van databases tegenwoordig uitgevoerd door een "patch" -methode, zoals in de dagen van de dominantie van het "waterval" -proces - aan het begin van het project wordt een bepaald model van de database "getekend", op basis van op dit moment bekende deelvereisten wordt een fysieke database gegenereerd en wordt het model vergeten door rechtstreeks wijzigingen in de database aan te brengen. De nadelen van deze aanpak liggen voor de hand: de uitwisseling van kennis en begrip van het totaalbeeld is moeilijk, en de veranderingen zijn ondoorzichtig, kunnen aanleiding geven tot tegenstrijdigheden in de logica en het schema van de database, die geheim blijven totdat het softwaresysteem is in gebruik genomen, wat tot zeer grote verliezen leidt. Moderne ontwikkelaars van databasetoepassingen hebben tools nodig die zijn afgestemd op iteratieve databaseontwikkeling.
De eerste en belangrijkste voorwaarde voor een dergelijke fitness is de beschikbaarheid van volwaardige kansen reverse engineering(reverse engineering, het creëren van een databasemodel op basis van de analyse van het fysieke schema) en directe engineering(forward engineering; het maken en wijzigen van het fysieke schema van de database op basis van het model). In de praktijk betekent dit dat u met behulp van een ontwerptool het schema van een bestaande database kunt analyseren, er een databasemodel van kunt maken, het model kunt wijzigen en onmiddellijk wijzigingen kunt toepassen die het databaseschema echt correct en consistent moeten veranderen, en niet bederven of verwarren.
De iteratieve benadering dwingt ons ook om submodellen te creëren die bij een bepaalde iteratie horen. Het scheiden van entiteiten en hun attributen in een submodel helpt bij het scheiden van verantwoordelijkheden tussen verschillende ontwikkelaars en tussen verschillende iteraties, terwijl tegelijkertijd de algehele integriteit van het model wordt gegarandeerd. Natuurlijk moet je ook twee modellen kunnen vergelijken, en niet in de vorm van SQL-scripts, maar op het niveau van entiteiten en attributen, om de wijzigingen die tijdens iteratie zijn aangebracht en hun impact op het hele model te zien en volledig te begrijpen.
Applicatieontwikkelaars werken zelden alleen, dus hebben ze samenwerkingstools nodig, maar als dat oké is aan de kant van de applicatieontwikkeling, wordt databasesamenwerking meestal niet ondersteund op toolniveau. Samenwerking impliceert noodzakelijkerwijs een versiebeheersysteem: alle versies van de modellen en het fysieke schema van de database moeten worden opgeslagen in een enkele repository, waardoor het vanaf het allereerste begin van het ontwikkelingsproces mogelijk is om schema's terug te draaien en te vergelijken.
Databaseontwikkeling is net zo belangrijk als applicatieontwikkeling, dus het is een strategische ontwikkeling om het databaseontwikkelingsproces te voorzien van versiecontrole en vereistenbeheertools, evenals het expliciet koppelen van databasemodellering en wijzigingsstappen aan iteraties en veranderende softwareprojectvereisten. Om deze problemen op te lossen en het moderne iteratieve database-ontwikkelingsproces te ondersteunen, biedt Embarcadero ER / Studio - een ontwerp-, analyse-, reverse en forward engineering-tool waarmee u versies van modellen kunt beheren op basis van uw eigen repository. De tool Change Manager kan worden gebruikt om metadatawijzigingen in fysieke databases te controleren.
Codefragmentatie
Het meest bekende probleem dat de ontwikkeling van databaseapplicaties enorm vertraagt, is de noodzaak om verschillende tools te gebruiken om de applicatiecode en de SQL-code in de database te debuggen.
Laten we een eenvoudig voorbeeld bekijken. Stel dat u in Delphi een applicatie ontwikkelt die een opgeslagen procedure aanroept in een Oracle DBMS. Met behulp van Delphi-tools kan de applicatieontwikkelaar in de foutopsporingsmodus doorlopen totdat de SQL-query wordt aangeroepen, de parameters bekijken die zijn doorgegeven aan de opgeslagen procedure en het resultaat dat de procedure zal terugkeren. Maar wat gebeurt er binnen de procedure wanneer deze wordt uitgevoerd op de databaseserver? Dit kan niet worden bepaald vanuit de ontwikkelomgeving van onze applicatie - hiervoor moet u een applicatie voor SQL-ontwikkeling downloaden, die de mogelijkheid heeft om opgeslagen procedures te debuggen, en ook SQL-queryplannen, statistieken over hun uitvoering laat zien, waarmee u kunt bekijken en het databaseschema wijzigen. U kunt echter geen parameters van de applicatie-ontwikkelomgeving doorgeven aan de SQL-ontwikkelomgeving, en u moet ze handmatig kopiëren door van het ene venster naar het andere over te schakelen. Het is ook onmogelijk om de gedetailleerde resultaten van de uitvoering van SQL-code te zien, zoals het queryplan, uitvoeringsstatistieken, enzovoort, in het programma voor het ontwerpen van toepassingen. De komst van cross-language debugging-technologie maakte het mogelijk om deze problemen op te lossen.
Het eerste Embarcadero-product dat debugging in meerdere talen ondersteunt, is RapidSQL Developer (voorheen PowerSQL), waarvan het visuele deel is gebaseerd op Eclipse-technologie en u daarom in staat stelt te integreren in elke daarop gebaseerde ontwikkelomgeving (inclusief natuurlijk JBuilder) en dynamische cross-debugging uitvoeren - taal debugging. Nu, op het moment dat een opgeslagen procedure op de server wordt uitgevoerd, schakelt de ontwikkelaar automatisch over naar een volwaardige SQL-code debugging-omgeving binnen dezelfde tool, die in staat is om zowel reguliere SQL-query's als opgeslagen procedures te debuggen. De ontwikkelaar ziet de daadwerkelijke invoerparameters van query's en opgeslagen procedures en krijgt de mogelijkheid om stap voor stap de SQL-code te debuggen. Het integreren van RapidSQL Developer in Eclipse-compatibele ontwikkelingstools is de eerste stap in de integratie van applicatie- en database-ontwikkeling, en is de volgende stap om vergelijkbare mogelijkheden te bieden voor Delphi, C++ Builder en andere applicatie-ontwikkelingstools van Embarcadero.
Database-applicaties voor meerdere platforms
Een bijzondere uitdaging voor ontwikkelaars is het ontwikkelen van databaseapplicaties die met meerdere DBMS'en moeten werken. Banken en verzekeraars hebben bijvoorbeeld meestal meerdere grote kantoren en veel kleine filialen. De meeste bedrijfsprocessen met betrekking tot de invoer van operationele informatie en de dagelijkse workflow zijn hetzelfde in het hoofdkantoor en in de filialen, maar de schaal is anders. De natuurlijke wens om te besparen op de kosten van licenties voor een industrieel DBMS voor gebruik in filialen leidt tot het idee dat het goed zou zijn om een ander DBMS te kiezen zonder de applicatie te wijzigen.
Ervaren databaseontwikkelaars zijn zich terdege bewust van de essentie van de problemen die zich hier voordoen: het verschil in gegevenstypen en SQL-dialecten, het ontbreken van mechanismen voor migratie en replicatie tussen verschillende DBMS, de complexiteit van migratieverificatie maken het schrijven en bedienen van applicaties voor verschillende DBMS een nachtmerrie. Aan de kant van de applicatie-ontwikkelingstools proberen ze dit probleem op te lossen door het creëren van bibliotheken voor gegevenstoegang (dbExpress in Delphi en C++ Builder, ADO en ADO.Net van Microsoft), die ook zijn gebaseerd op gemeenschappelijke architectuurprincipes en toegangsmethoden. zoals door het gebruik van talrijke object-relationele "wrappers" (Object Relation Mapping, ORM) over de relationele logica en databasestructuur, het genereren van broncode voor het werken met gegevens op basis van de analyse van het databaseschema en het gebruik van het "adapters"-mechanisme om de protocol van een bepaald DBMS. Een van de meest populaire ORM's zijn Hibernate voor Java en ActiveRecord in RubyOnRails, die een objectgeoriënteerde interface bieden voor de gegevens die zijn opgeslagen in het DBMS. Voor Delphi is er een soortgelijk project tiOPF, voor C# - NHibernate.
Natuurlijk kan het gebruik van dergelijke universele bibliotheken en sets van componenten het aantal routinehandelingen in het proces van multiplatform-databaseontwikkeling aanzienlijk verminderen. Dit is echter niet genoeg als het gaat om applicaties die complexere databases gebruiken die actief gebruikmaken van de logica die is ingebed in opgeslagen procedures en triggers - voor de implementatie, debuggen en testen zijn afzonderlijke tools vereist, soms totaal verschillend voor verschillende DBMS. Voor het ontwikkelen van platformonafhankelijke database-applicaties biedt Embarcadero de RapidSQL-tool.
Alle databaseproducten van Embarcadero zijn gebaseerd op meerdere platforms en gebaseerd op het Thunderbolt-databaseschema en de analyse-engine voor statistieken. Elke ondersteunde DBMS en elke specifieke versie van de DBMS heeft overeenkomstige codetakken in de Thunderbolt-kern, waarmee u het databaseschema zo nauwkeurig mogelijk kunt toewijzen aan de interne weergave in deze kernel en, belangrijker nog, correcte conversies kunt uitvoeren tussen de weergave en echte databanken. Dankzij de Thunderbolt-kernel kunt u met RapidSQL hoogwaardige SQL-code ontwikkelen voor alle ondersteunde platforms (Oracle, MS SQL, Sybase en verschillende varianten van IBM DB2), en ER / Studio kan nauwkeurige reverse- en forward-engineering van databases uitvoeren schema's.
Of u nu een applicatie voor twee of meer platforms ontwikkelt, of een bestaande applicatie van het ene platform naar het andere migreert, RapidSQL biedt alle tools die u nodig hebt om schema's, gebruikers en machtigingen tussen verschillende DBMS'en te migreren. Natuurlijk converteert RapidSQL PL/SQL-procedures niet automatisch naar T-SQL - hiervoor is nog steeds een programmeur nodig, maar de tool biedt een enkel venster voor ontwikkeling op meerdere platforms, uniforme editors voor schema-objecten, gebruikers en hun rechten, en SQL-foutopsporing op alle ondersteunde platforms. Volgens RapidSQL-gebruikers wordt hierdoor tot 70% van de tijd die wordt besteed aan migratie tussen verschillende DBMS bespaard.
Wijzigingen in gegevens en schema
Migratie van het ene DBMS naar het andere is onmogelijk zonder de verificatie ervan. Wie en hoe kan garanderen dat de gegevens die van het ene DBMS naar het andere worden overgedragen, werkelijk identiek zijn? Verschillende clientbibliotheken, verschillende gegevenstypen en verschillende coderingen maken het proces van gegevensvergelijking een niet-triviale taak.
In de echte wereld houdt de implementatie van de applicatie en de database daar niet op - er wordt onderhoud gepleegd, nieuwe versies van de uitvoerbare bestanden van de applicatie en patches voor de database verschijnen. Hoe weet u zeker dat alle noodzakelijke updates zijn toegepast op de database en dat de gehele softwaresuite correct werkt?
Embarcadero heeft een Change Manager-tool ontwikkeld voor het vergelijken van gegevens, schema's en databaseconfiguraties. De vergelijking vindt plaats binnen één of meerdere DBMS, met automatische controle van de correspondentie tussen datatypes en de vorming van SQL-scripts van verschillen, die direct kunnen worden toegepast om de databases in een identieke toestand te brengen. De metadata-vergelijkingsmodule biedt een vergelijking van databaseschema's zowel tussen live databases als tussen een database en een SQL-script en genereert een metadata-verschilscript. Deze functionaliteit kan niet alleen worden gebruikt om databases te vergelijken met de benchmark, maar ook om een regelmatig database-updateproces te organiseren en om te controleren op ongeoorloofde wijzigingen, bijvoorbeeld in afgelegen vestigingen van een grote organisatie. De situatie is vergelijkbaar met configuratiebestanden - Change Manager vergelijkt configuratiebestanden en stelt u in staat ervoor te zorgen dat de configuratie van geïmplementeerde applicaties voldoet aan de vereisten voor deze software.
Prestaties van databasetoepassingen
Hoe vaak zien we applicaties die geweldig werken op kleine testdatavolumes, maar onaanvaardbaar traag worden op echte volumes. Fouten in vereisten, onvoldoende testen in de vroege stadia, haast om een project op te leveren zijn allemaal bekende oorzaken van slechte applicatie-ontwikkeling. Theoretici van softwareontwikkeling stellen in dit geval voor om zelfverbetering en een fundamentele verbetering van de kwaliteit van programma's te bewerkstelligen, maar alle beoefenaars weten dat het soms onmogelijk is om een project economisch of, in sommige gevallen, politiek te herschrijven, en de taak van het het optimaliseren van prestaties moet op welke manier dan ook worden opgelost.
De belangrijkste oorzaak van prestatieproblemen in databasetoepassingen ligt in niet-geoptimaliseerde SQL-query's en opgeslagen procedures. Optimizers van moderne databases zijn behoorlijk krachtig, maar ze hebben ook bepaalde beperkingen, en om goede prestaties te bereiken, moet u correct SQL-query's samenstellen, extra indexen maken (of verwijderen), de database in bepaalde gevallen denormaliseren, een deel van de logica van triggers en opgeslagen procedures.
Tijdens de ontwikkelingsfase kan query-optimalisatie worden uitgevoerd met RapidSQL, dat een SQL Profiler-module bevat die plannen kan analyseren en hints kan genereren om de prestaties van SQL-query's te verbeteren. Maar wat als het probleem zich al tijdens de operatie voordoet en niet is gelokaliseerd in een specifieke SQL-query? Als de prestaties op bepaalde momenten van de dag afnemen, of, erger nog, het probleem zich voordoet op een externe kopie van het systeem, terwijl alles in orde is op de hoofdserver? Voor dergelijke gevallen is DBOptimizer een databaseprofileringstool voor Oracle, Microsoft SQL Server, Sybase en IBM DB2.
Wanneer u de profileringsmodus start, verzamelt DBOptimizer informatie over de database en runtime-omgeving, inclusief informatie over de CPU-belasting en andere parameters van het besturingssysteem, en schrijft deze informatie naar de profileringssessie. Het resultaat is een lijst met query's die op een bepaald tijdsinterval worden uitgevoerd, gesorteerd op verbruikte resources. Voor elke problematische query kunt u het plan, de uitvoeringsstatistieken en andere details bekijken. Bovendien toont DBOptimizer ook hints-aanbevelingen voor het verbeteren van de query met betrekking tot specifieke DBMS.
Gereedschapskist
Alle genoemde tools, hoewel ze helpen om problemen het hoofd te bieden, worden gebruikt in verschillende stadia van de levenscyclus van databaseontwikkeling. Het is nogal onhandig en duur om een dozijn applicaties te hebben voor alle gelegenheden die nodig zijn (of niet nodig zijn) tijdens het ontwerpen, ontwikkelen, migreren, optimaliseren en onderhouden van databases.
Emdacadero All-Access, uitgebracht in februari 2009, is een veelzijdige toolkit met essentiële tools voor alle fasen van de ontwikkeling van databasetoepassingen, van ER/Studio tot DBOptimizer, van Delphi en C++Builder tot DBArtisan. De beste manier om All-Access te beschrijven, is door het te vergelijken met de gereedschapskist die elke ijverige eigenaar in huis heeft. Misschien worden niet alle gereedschappen elke dag gebruikt, maar een verstelbare sleutel moet altijd bij de hand zijn in geval van lekkage.
All-Access dwingt databaseprogrammeurs of databasearchitecten niet tot rollen, maar biedt een universele set tools die geschikt zijn voor alle rollen in het ontwikkelingsproces van databasetoepassingen, van architect tot tester; biedt alle leden van het ontwikkelteam tools voor alle stadia van database-ontwikkeling, evenals een reeks zeer gespecialiseerde tools voor het optimaliseren van databases (DBOptimizer) en applicaties (JOptimizer), waardoor u knelpunten kunt "uitbreiden". Het pakket ondersteunt meerdere DBMS, wat kostenbesparingen oplevert.
De technische verschillen tussen objectgeoriënteerde en relationele databasetechnologieën hebben geleid tot een cultuurverschil dat de datamanagementgemeenschap nog steeds scheidt van de ontwikkelingsgemeenschap. Wat hier verder mee te doen?
