Logisch model kennis.

Een logisch model is een formeel systeem – een soort logische analyse. Alle kennis over vakgebied worden beschreven in de vorm van formules van deze calculus of gevolgtrekkingsregels. Beschrijving in de vorm van formules maakt het mogelijk om declaratieve kennis weer te geven, terwijl inferentieregels procedurele kennis opleveren. Talen voor kennisrepresentatie Booleaans type veel gebruikt in de vroege stadia van ontwikkeling intelligente systemen, maar werden al snel verdrongen (of in ieder geval grotendeels verdrongen) door talen van andere typen. Dit wordt verklaard door de omslachtigheid van de registraties op basis van klassieke logische calculus. Bij het maken van dergelijke records is het gemakkelijk om fouten te maken, en het zoeken ernaar is erg moeilijk. Het gebrek aan zichtbaarheid en leesbaarheid (vooral voor degenen wier activiteiten geen verband houden met de exacte wetenschappen) maakte het moeilijk om dit soort talen te verspreiden.

Kadermodel van kennis.

Kader(Engels frame - frame of frame), voorgesteld door M. Minsky in de jaren zeventig. als kennisstructuur voor de perceptie van ruimtelijke taferelen. Dit model heeft een diepe psychologische basis. Een frame is een abstract beeld of situatie. Een frame is ook een geformaliseerd model voor het weergeven van een afbeelding. Onderscheiden voorbeeldframes of prototypes, opgeslagen in de kennisbank, en instantieframes, die zijn gemaakt om echte situaties weer te geven op basis van binnenkomende gegevens. Het framemodel is vrij universeel, omdat je hiermee de volledige diversiteit aan kennis over de wereld kunt weergeven door: - frame-structuren, voorwerpen en concepten aanwijzen (lening, pandrecht, wissel); - frame-rollen(manager, kassier, klant); - scriptframes(faillissement, aandeelhoudersvergadering); - situatieframes(alarm, ongeval, bedrijfsmodus van apparaat), enz. Het belangrijkste voordeel van frames als model voor het representeren van kennis is het vermogen om te reflecteren conceptueel kader organisatie van het menselijk geheugen, evenals de flexibiliteit en helderheid ervan. Speciale kennisrepresentatietalen in framenetwerken FRL (Frame Representation Language) en andere maken het mogelijk om industriële ES effectief te bouwen. Frame-georiënteerde expertsystemen zoals ANALYST en MODIS zijn algemeen bekend.

Termijn semantisch betekent ‘semantisch’, en semantiek zelf is een wetenschap die relaties legt tussen symbolen en de objecten die ze aanduiden, d.w.z. de wetenschap die de betekenis van tekens bepaalt. Een semantisch netwerk is een gerichte graaf waarvan de hoekpunten concepten zijn en waarvan de bogen relaties daartussen zijn. Karakteristiek kenmerk Semantische netwerken vereisen de aanwezigheid van drie soorten relaties: - klasse - klasse-element; - eigendom - waarde; - een voorbeeld van een klasse-element. Het probleem van het vinden van een oplossing in een kennisbank zoals een semantisch netwerk komt neer op het probleem van het vinden van een fragment van het netwerk dat overeenkomt met een bepaald subnet dat overeenkomt met de gestelde vraag. Het grote voordeel van dit model is dat het aansluit bij moderne ideeën over organisatie langetermijngeheugen persoon. Het nadeel van het model is de moeilijkheid bij het zoeken naar uitvoer op het semantische netwerk. Om semantische netwerken te implementeren, zijn er speciale netwerktalen, bijvoorbeeld NET, enz. Expertsystemen die semantische netwerken gebruiken als kennisrepresentatietaal zijn algemeen bekend: PROSPECTOR, CASNET, TORUS.

Volgens de vorm van beschrijving is kennis verdeeld in:

Declaratief (feiten)- dit is kennis van de vorm “A is A”. Declaratieve kennis is onderverdeeld in objecten, objectklassen en relaties. Voorwerp is een feit dat wordt gegeven door de betekenis ervan. Objectklasse is de naam waaronder een specifieke verzameling feitenobjecten is verenigd. Relatie- verbindingen definiëren tussen objectklassen en afzonderlijke objecten, ontstaan ​​binnen het vakgebied.

Procedureel- dit is kennis van de vorm "Als A, dan B." Procedurele kennis omvat sets van regels die laten zien hoe nieuwe regels kunnen worden afgeleid onderscheidende kenmerken klassen of relaties voor objecten. De regels maken gebruik van alle soorten declaratieve kennis, evenals logische connectieven. Bij het verwerken van regels moet worden opgemerkt dat de analyse van relaties recursief is, d.w.z. één regel veroorzaakt een diepe zoektocht van iedereen mogelijke opties kennisbankobjecten.

De grens tussen declaratieve en procedurele kennis is zeer vloeiend. de ontwerper kan hetzelfde beschrijven als een relatie of als een regel.

Hoofdstuk 12

In het laatste, twaalfde hoofdstuk zullen we een traditie doorbreken die zich heeft ontwikkeld bij het onderwijzen van databases. Het is niet gebruikelijk om al te diep geïnteresseerd te raken in de aard van de weergegeven entiteiten en de semantiek van de gegevens. Er wordt geen rekening gehouden met datamodellen met twee lagen, waarbij de eerste laag opslagstructuren biedt en met gegevens in een basismodel werkt. De tweede laag werkt met datastructuren, die in de eerste laag als ondeelbaar, atomair werden beschouwd.

In voorgaande hoofdstukken werd aangenomen dat databases entiteiten opslaan die een naam en attributen hebben. Attributen hebben een type. In objectmodellen worden meer methoden aan attributen toegevoegd. Verschijnen objecttypen, en de entiteiten zelf (klassen) en hun leden kunnen niet alleen vooraf gedefinieerd zijn scalaire typen, maar ook bezwaarschriften. Dit is een zalig en heel bekend beeld voor de visie van een programmeur, enigszins gecompliceerd door de eigenschap van persistentie.

Om de in de database opgeslagen entiteiten niet te verwarren met hun prototypes in het onderwerpgebied, zullen we deze laatste concepten (concepten) van dit gebied noemen. Het blijkt dat databases doorgaans slechts twee soorten concepten vertegenwoordigen. Dit zijn in de regel concepten met één soort attributen, die we verplichte attributen zullen noemen, en soms semi-gestructureerde concepten die optionele attributen toestaan.

We zullen proberen het model van een representatief concept uit te breiden door attributen van staat, hulpbronnen en betekenissen te introduceren. In dit geval zal ontdekt worden dat concepten met verplichte en optionele attributen gesloten systemen beschrijven. Staatsattributen zijn, zoals je zou verwachten, kenmerkend voor dynamische objecten. Hulpbronattributen maken het mogelijk de uitwisseling van energie, materiaal en energie te beschrijven informatie-entiteiten en daarmee open systemen te modelleren.

Laten we overwegen om sommige datamodellen in andere te modelleren (emulatie), en de voordelen, nadelen en toepassingsgebieden van deze aanpak te ontdekken, evenals de daarmee samenhangende veranderingen in de datasemantiek.

Er zal veel aandacht worden besteed aan de attributen van betekenissen, waarvan de implementatie het volume van de semantiek die in de database is opgeslagen aanzienlijk kan vergroten. We zullen zintuigen classificeren en hun implementatie beschrijven met behulp van preprocessors in conventionele DBMS's, en ook eenvoudige wijzigingen voorstellen die in het DBMS moeten worden aangebracht om met zintuigen te kunnen werken.

Er zijn vakgebieden waarin de aard van gegevens het gebruik van niet-klassieke logica bij het redeneren vereist – modale logica van geloof, kennis, enz. In het bijzonder kunnen temporele gegevens worden beschouwd als speciaal systeem betekenissen, wat misschien het gebruik van modale temporele logica vereist.

Het inbedden van deductieve systemen in conventionele DBMS's maakt het mogelijk, samen met tabellen en objectmodellen gebruik aanvullende deductieve modellen gebaseerd op klassieke logica en misschien modale logica.

Hoe ver moet je gaan om je database te verzadigen met semantiek? Het hangt allemaal af van de vraag of die er is noodzakelijke informatie, hoeveel semantiek er nodig is, wat het DBMS heeft gebruikt en de extra beschikbare versies zullen toestaan software, wat gebruik geeft externe bronnen semantiek, bijvoorbeeld ontologieën, en over de mogelijkheden van de tweede laag van het DBMS.

In voorgaande hoofdstukken werd aangenomen dat de waarden die in de database waren opgeslagen atomair waren. Vanuit het oogpunt van het weergegeven bedrijfsmodel kunnen ze zo complex zijn als gewenst, maar binnen het raamwerk van het gebruikte datamodel is het onmogelijk om met hun componenten te werken. Databases maken al lang gebruik van modellen die we tweelagen zullen noemen. De rol van de eerste laag wordt vervuld door elk datamodel waarvoor dataopslagstructuren zijn georganiseerd. De tweede laag werkt met de gegevens die de eerste laag biedt, maar de gegevens daarin worden niet als atomair beschouwd, maar op een bepaalde manier georganiseerd. Bijna alle DBMS'en in de tweede laag gebruiken reguliere expressies en/of verschillende soorten XML-gegevens. Het is duidelijk dat de tweede laag geen directe invloed heeft op de dataopslagstructuren, maar eigen eisen kan stellen aan de organisatie ervan.

Tweede uitbreidingsmogelijkheid reguliere modellen gegevens worden geassocieerd met het opslaan van aanvullende gegevenssemantiek. U kunt rekening houden met de eigenaardigheden van het gebruik van attributen en hun variëteiten benadrukken - variëteiten. We zullen verder opmerken dat entiteiten met gewone (verplichte) attributen gesloten en statische objecten definiëren. Entiteiten met andere soorten attributen kunnen open en dynamisch zijn.

De studie van datasemantiek in databases wordt belemmerd door een gebrek aan duidelijkheid over de essentie van het onderwerp, het ontbreken van uniforme erkende benaderingen en terminologische verwarring. Bepaalde moeilijkheden worden veroorzaakt door de toename van het aantal vakgebieden waarmee gewerkt moet worden, en de onvermijdelijke versterking van de rol van het taalkundige aspect.

Het is nuttig om de ervaring te lenen van die kennisgebieden waarin de semantiek al heel lang wordt bestudeerd. Dit zijn taalkunde, de studie van natuurlijke talen (NL), en de theorie van programmeertalen.

Laten we allereerst de discrepantie opmerken tussen sommige termen in de taalkunde en de informatica. Taalkundigen onderscheiden twee contrasterende soorten elementen van de semantiek: betekenissen en zintuigen. De betekenis van een taalkundig teken wordt opgevat als iets stabiels dat eerst kan worden vastgesteld, ontdekt en vervolgens bekend. De betekenis moet voortdurend worden gezocht, vastgesteld en ontrafeld. In de informatica is de term ‘betekenis’ al bezet. Door te zeggen “een variabele heeft een waarde” bedoelen we niet de semantiek van deze variabele, maar de toewijzing daaraan van een specifieke data-instantie, of de aanduiding, of de creatie van een instantie van een variabele die dit data-element bevat. Daarom zullen we de elementen van de semantiek altijd betekenissen noemen, en we zullen de ‘stabiliteit’ of ‘contextualiteit’ of ‘variabiliteit’ van betekenissen definiëren door de classificatie van betekenissen of door er aanvullende eigenschappen in te introduceren.

Het is al lang bekend dat betekenissen en zintuigen buitentalige entiteiten zijn. In het bijzonder voor vertaling van één natuurlijke taal in een ander NL kan een speciale functietaal worden gemaakt om de semantiek weer te geven, waarin zinnen worden vertaald brontaal. En al vanuit deze tussentaal wordt de vertaling naar het tweede NL uitgevoerd. We transformeren de stelling over de buitentalige aard van betekenissen voor databases in een enigszins verzachte vorm als een statement over de mogelijkheid om gegevens en betekenissen te scheiden.

Laten we bij programmeertalen aandacht besteden aan de mogelijkheid om verschillende soorten semantiek te onderscheiden: operationeel (beschreven in termen van de overgang van toestanden van een abstracte machine), denotationeel (de taal gebruikt wiskundige structuren, waarmee u de mogelijkheid kunt vaststellen om taalconstructies te berekenen met behulp van gespecialiseerde functies), deductief (hiermee kunt u de eigenschappen van programma's bewijzen, vooral hun juistheid), translationeel (gebruikt vertaalregels in een taal waarvan de semantiek bekend is), gebaseerd op beslissingstabellen enz.

Laten we terugkeren naar de databaseterminologie. Er bestaat een ongefundeerde maar hardnekkige traditie om sommige modellen en databases als semantisch te bestempelen (en we zijn hier niet zonder zonde). Het entiteit-relatiemodel wordt dus als een semantisch model beschouwd, blijkbaar in vergelijking met tabellarische modellen gegevens. Semantiek, die doorgaans beperkt is, bestaat echter in elk datamodel. Daarom merkte E. Codd al in 1988 op dat “het label ‘semantisch’ niet in absolute zin geïnterpreteerd mag worden.” In dezelfde tabeldatabases wordt de semantiek met name bepaald door sleutels en integriteitsbeperkingen. Databases met declaratieve talen implementeren altijd operationele semantiek, bijvoorbeeld weergegeven door SQL-uitvoeringsplannen. We moeten het dus alleen hebben over de meer of mindere verzadiging van modellen en databases met semantiek.

Hoe kunnen we semantische elementen die in de database zijn opgeslagen, scheiden van gewone gegevens? Volgens een heel eenvoudig criterium: semantische elementen, ook wel betekenissen genoemd, zijn actief. Gegevens zijn altijd passief.

Laten we uitleggen wat er werd gezegd eenvoudig voorbeeld. Stel dat u alle records uit de tabel moet selecteren, bijvoorbeeld: met de SELECT-instructie* VAN emp. Het is duidelijk dat het DBMS eerst het bestaan ​​van de emp-tabel moet controleren aan de hand van het woordenboek en eventueel moet bepalen of dit het geval is huidige gebruiker noodzakelijke rechten naar deze tafel. Als de tabel niet bestaat of niet toegankelijk is, geeft u een foutmelding. Stel anders de lijst met emp-kolommen in en begin pas daarna met het ophalen van gegevens. Hoeveel wordt er gedaan dat niet direct is vermeld! Dit alles zorgt voor de activiteit die metadata heeft.

Nog een voorbeeld. Laten we een rij invoegen in een tabel met primaire sleutel. Omdat de beperking 'primaire sleutel' actief is, zal het DBMS eerst de uniciteit van de ingevoerde sleutelwaarde controleren, en alleen als aan deze voorwaarde is voldaan zal het doen wat het moet doen: het record invoeren.

Merk op dat de activiteit van betekenissen datamodellen vergt met betekenissen die verder gaan dan de gebruikelijke puur algebraïsche datamodellen.

In de volgende paragrafen zullen we proberen de vraag te beantwoorden welke betekenissen, naast de hierboven genoemde, in databases kunnen worden opgeslagen en hoe dit te doen. Maar laten we eerst verduidelijken welke soorten entiteiten in databases kunnen worden opgeslagen.

Databaseontwerp maakt gebruik van semantische modellering om te creëren conceptueel model vakgebied en weerspiegeling van de specificaties ervan in de omgeving van een specifiek DBMS. Vaak verschilt het resulterende conceptuele databaseschema echter aanzienlijk van het oorspronkelijke conceptuele model.
In de jaren '70 relationeel model data ontstonden als antwoord op de behoefte aan een eenvoudig DBMS dat overeenkomt met het ontwikkelingsniveau computertechnologie van zijn tijd. Relationele database- dit is een reeks relaties die alle informatie bevatten die in de database moet worden opgeslagen; gebruikers kunnen zo'n database als een verzameling tabellen beschouwen. Tegenwoordig is het gemak van ontwerp en bediening van databases veel belangrijker, en wat ooit eenvoudig, wiskundig rigoureus en logisch leek, wordt als ongemakkelijk ervaren. Semantische uitbreiding van het relationele model
De meeste gegevens die tijdens activiteiten van bijvoorbeeld een onderneming ontstaan, worden gepresenteerd in de vorm van elektronische en papieren documenten. Vanuit het oogpunt van het manipuleren van deze gegevens zijn alle aspecten van de bedrijfsactiviteit ofwel documentstroom, ofwel kunnen ze er formeel toe worden teruggebracht. Tegenwoordig wordt de dominante positie ingenomen door relationele DBMS die bieden handige manier informatie opslaan in de vorm van tabellen De datastructuur van de meeste echte documenten kan worden weergegeven als een willekeurige hiërarchische boom met horizontale verbindingen. Documenten worden volledig opgeslagen in één cel van een relationele databasetabel of zijn verdeeld in vele tabellen, en enkele tabellen uit verschillende documenten verenigen. In een relationele database hebben we echter al te maken met andere documenten, dus het algoritme voor het verwerken van een echt document kan niet de basis van het algoritme worden programmacode opgeslagen procedure. Echte documenten verschijnen pas weer op applicatieniveau. Hier hebben we in feite niet te maken met weergave, maar met het herontwerp van documenten en daarmee de documentstroom. Zoals bekend was het doel van de relationele benadering om de beperkingen te overwinnen vroege systemen- hiërarchisch en netwerk. Het relationele model is voldoende voor het modelleren van domeinen, maar het ontwerpen van een basis in termen van relaties is vaak erg lastig. De behoefte van ontwerpers aan handiger en krachtige middelen domeinrepresentaties aanleiding gaven semantische modellering Het belangrijkste doel van onderzoek op dit gebied is om DBMS’en ‘intelligenter’ te maken, waarbij ze de kenmerken van toepassingsgebied. Als het DBMS is gebaseerd op een datamodel dat consistenter is met de semantiek van het vakgebied, zullen de databases die op basis daarvan worden gebouwd consistenter zijn echte systemen, en het databaseontwerp zal aanzienlijk worden vereenvoudigd. Semantische modellering is een modellering van de datastructuur op basis van de betekenis van deze gegevens. Gebruikt als hulpmiddel voor semantische modellering verschillende opties diagrammen entiteit-relatie (ER - Entiteit-relatie). Eerste optie entiteit-relatiemodellen werd in 1976 voorgesteld door Peter Ping-Sheng Chen. Vervolgens ontwikkelden veel auteurs hun eigen versies van vergelijkbare modellen (Martin-notatie, IDEF1X-notatie, Barker-notatie, enz.). Bovendien kunnen verschillende softwaretools die dezelfde notatie implementeren, in feite allemaal verschillen varianten van entiteit-relatiediagrammen komen voort uit één idee - een tekening is altijd duidelijker dan een tekstbeschrijving. Al dergelijke diagrammen gebruiken grafisch beeld entiteiten van het onderwerpgebied, hun eigenschappen (attributen) en relaties tussen entiteiten. Basisconcepten van ER-diagrammen(dicht bij de notatie van Barker) Definitie 1. Essence- dit is een klasse van objecten van hetzelfde type, waarvan informatie in het model in aanmerking moet worden genomen. Elke entiteit moet een naam hebben die wordt uitgedrukt door een enkelvoudig zelfstandig naamwoord. Voorbeelden van entiteiten kunnen klassen van objecten zijn als "Leverancier". “Werknemer”, “Factuur”. Elke entiteit in het model wordt weergegeven als een rechthoek met de naam: Definitie 2. Entiteitsinstantie- dit is een specifieke vertegenwoordiger van een bepaalde entiteit. Een vertegenwoordiger van de entiteit 'Werknemer' kan bijvoorbeeld 'Werknemer Ivanov' zijn. Instanties van entiteiten moeten te onderscheiden zijn, d.w.z. entiteiten moeten een aantal eigenschappen hebben die uniek zijn voor elk exemplaar van die entiteit.Definitie 3. Entiteitskenmerk- dit is een benoemd kenmerk, dat een eigenschap is van de entiteit. De naam van het attribuut moet worden uitgedrukt als een enkelvoudig zelfstandig naamwoord (mogelijk met kenmerkende bijvoeglijke naamwoorden). Personeelsnummer", "Achternaam", "Voornaam", "Patroniem", "Functie", "Salaris", etc. Attributen worden weergegeven in een rechthoek die de entiteit definieert: Definitie 4. Entiteitssleutel is een niet-redundante set attributen, waarvan de waarden samen uniek zijn voor elk exemplaar van een entiteit. Niet-redundantie ligt in het feit dat het verwijderen van een attribuut uit een sleutel de uniciteit ervan schendt. Een entiteit kan verschillende sleutels hebben. Sleutelattributen worden in het diagram onderstreept weergegeven: Definitie 5. Verbinding- dit is een associatie tussen twee entiteiten. Eén entiteit kan verbonden zijn met een andere entiteit of met zichzelf. Relaties stellen een entiteit in staat andere entiteiten te vinden die ermee verbonden zijn. Verbindingen tussen entiteiten kunnen bijvoorbeeld worden uitgedrukt door de volgende zinsneden: “Een WERKNEMER kan meerdere KINDEREN hebben”, “elke WERKNEMER. moet precies in één afdeling worden vermeld."Grafisch wordt een verbinding weergegeven door een lijn die twee entiteiten verbindt: elke verbinding heeft twee uiteinden en een of twee namen. De naam wordt meestal uitgedrukt in een onbepaalde verbale vorm: “hebben”, “erbij horen”, enz. Elke naam verwijst naar het eigen uiteinde van de verbinding. Soms zijn de namen niet geschreven vanwege hun voor de hand liggende. Elke verbinding kan er een hebben volgende typen aansluitingen: Eén-op-één communicatie betekent dat één exemplaar van de eerste entiteit (links) is gekoppeld aan één exemplaar van de tweede entiteit (rechts). Een één-op-één-relatie geeft meestal aan dat we eigenlijk maar één entiteit hebben, die ten onrechte in tweeën is verdeeld. Een-op-veel-relatie betekent dat één exemplaar van de eerste entiteit (links) is gekoppeld aan meerdere exemplaren van de tweede entiteit (rechts). Dit is de meest gebruikte vorm van communicatie. De linker entiteit (aan de ‘één’-kant) wordt de ouder genoemd, de rechter (aan de ‘veel’-kant) wordt het kind genoemd. Veel-op-veel-relatie betekent dat elk exemplaar van de eerste entiteit kan worden geassocieerd met meerdere exemplaren van de tweede entiteit, en dat elk exemplaar van de tweede entiteit kan worden geassocieerd met meerdere exemplaren van de eerste entiteit. Het veel-op-veel-relatietype is een tijdelijk type relatie, aanvaardbaar in de vroege stadia van modelontwikkeling. In de toekomst moet dit type relatie worden vervangen door twee één-op-veel-relaties, door een tussenliggende entiteit te creëren. Elke relatie kan één of twee hebben communicatiemodaliteiten:De modaliteit "kan" betekent dat een instantie van een entiteit kan worden geassocieerd met een of meer instanties van een andere entiteit, of dat deze niet kan worden geassocieerd met een instantie ten minste één instantie van een andere entiteit. Een relatie kan verschillende modaliteiten hebben aan verschillende uiteinden. ENTITEIT 2. Elke relatie kan van links naar rechts en van rechts naar links worden gelezen. Bijvoorbeeld,
Van links naar rechts: "elke werknemer kan meerdere kinderen hebben."
Van rechts naar links: “Elk kind moet tot precies één medewerker behoren.” Ontwikkeling van een eenvoudig ER-model Bij het ontwikkelen van ER-modellen moeten we deze verkrijgen de volgende informatie over het vakgebied: *Lijst van entiteiten van het vakgebied.
*Lijst met entiteitskenmerken.
*Beschrijving van relaties tussen entiteiten. ER-diagrammen zijn handig omdat het proces voor het identificeren van entiteiten, attributen en relaties iteratief is. Nadat we de eerste benaderende versie van de diagrammen hebben ontwikkeld, verfijnen we deze door vakdeskundigen te interviewen. In dit geval zijn de documentatie waarin de resultaten van de gesprekken worden vastgelegd de ER-diagrammen zelf. Het ontworpen systeem moet bijvoorbeeld de volgende acties uitvoeren: Informatie over klanten opslaan.
Facturen afdrukken voor vrijgegeven goederen.
Controleer de beschikbaarheid van goederen in het magazijn. Laten we alle zelfstandige naamwoorden in deze zinnen markeren - dit zijn potentiële kandidaten voor entiteiten en attributen, en deze analyseren (we zullen onduidelijke termen markeren met een vraagteken): Koper is een voor de hand liggende kandidaat voor een item. entiteit.
De factuur is een duidelijke kandidaat voor een entiteit.
Product is een duidelijke kandidaat voor entiteit
(?)Magazijn - hoeveel magazijnen heeft het bedrijf in het algemeen? Als er meerdere zijn, is het een kandidaat voor een nieuwe entiteit.
(?) Beschikbaarheid van een product is hoogstwaarschijnlijk een attribuut, maar een attribuut van welke entiteit?
Er ontstaat onmiddellijk een voor de hand liggend verband tussen de entiteiten: ‘kopers kunnen veel goederen kopen’ en ‘goederen kunnen aan veel kopers worden verkocht’. De eerste versie van het diagram ziet er als volgt uit: Waar moeten we de entiteiten “Factuur” en “Magazijn” plaatsen en waar moeten we ze aan koppelen? Laten we ons afvragen hoe deze entiteiten zich tot elkaar en tot de entiteiten “Koper” en “Product” verhouden? Kopers kopen goederen en ontvangen facturen met gegevens over de hoeveelheid en prijs van de gekochte goederen. Elke koper kan meerdere facturen ontvangen. Elke factuur moet aan één koper worden uitgereikt. Elke factuur moet meerdere goederen bevatten (er zijn geen lege facturen). Elk product kan op zijn beurt via verschillende facturen aan meerdere kopers worden verkocht. Bovendien moet elke factuur vanuit een specifiek magazijn worden uitgegeven en kunnen veel facturen vanuit elk magazijn worden uitgegeven. Na verfijning zal het diagram er dus als volgt uitzien: Het is tijd om na te denken over entiteitsattributen: Elke klant is dat rechtspersoon en heeft een naam, adres en bankgegevens.
Elk product heeft een naam, prijs en wordt ook gekenmerkt door meeteenheden.
Elke factuur heeft uniek nummer, datum van uitgifte, goederenlijst met hoeveelheden en prijzen, evenals het totale bedrag van de factuur. De factuur wordt verzonden vanuit een specifiek magazijn en naar een specifieke koper.
Elk magazijn heeft zijn eigen naam. Laten we opnieuw alle zelfstandige naamwoorden opschrijven die potentiële attributen zijn en deze analyseren: Juridische entiteit is een retorische term, waar we niet mee werken. individuen. Wij letten niet op.
De naam van de koper is een duidelijk kenmerk van de koper.
Het adres is een duidelijk kenmerk van de koper.
Bankgegevens zijn een duidelijk kenmerk van de koper.
De naam van het product is een duidelijk kenmerk van het product.
(?) De prijs van het product - het lijkt erop dat dit een kenmerk van het product is. Verschilt dit kenmerk van de prijs op de factuur?
Een meeteenheid is een duidelijk kenmerk van een product.
Het factuurnummer is een duidelijk uniek kenmerk van de factuur.
De factuurdatum is een duidelijk kenmerk van de factuur.
(?) Lijst met goederen op de factuur - de lijst kan geen attribuut zijn. Waarschijnlijk moet u deze lijst in een afzonderlijke entiteit opsplitsen.
(?) De hoeveelheid goederen op de factuur is een voor de hand liggend kenmerk, maar een kenmerk van wat? Dit is niet alleen een kenmerk van een “product”, maar van een “product op de factuur”.
(?) De prijs van het product op de factuur - nogmaals, dit moet niet alleen een kenmerk van het product zijn, maar een kenmerk van het product op de factuur. Maar de prijs van het product is hierboven al gezien: is dit hetzelfde?
Het factuurbedrag is een expliciet kenmerk van de factuur. Dit kenmerk is niet onafhankelijk. Het bedrag van de factuur is gelijk aan de som van de kosten van alle goederen die op de factuur zijn vermeld.
De naam van het magazijn is een duidelijk kenmerk van het magazijn. Met het opkomende concept van “Lijst van goederen op de factuur” is alles vrij duidelijk. De entiteiten "Factuur" en "Product" zijn aan elkaar gerelateerd door een veel-op-veel-relatie. Een dergelijke relatie moet, zoals we eerder hebben opgemerkt, worden opgesplitst in twee één-op-veel-relaties. Hiervoor is een extra entiteit nodig. Deze entiteit is de entiteit 'Lijst met goederen op de factuur'. De verbinding met de entiteiten "Factuur" en "Product" wordt gekenmerkt door de volgende zinnen - "elke factuur moet verschillende vermeldingen uit de lijst met goederen op de factuur bevatten", "elke vermelding uit de lijst met goederen op de factuur moet worden opgenomen op precies één factuur”, “elk product kan worden opgenomen in verschillende vermeldingen uit de goederenlijst op de factuur”, “elke vermelding uit de goederenlijst op de factuur moet aan precies één product zijn gekoppeld.” De attributen “Aantal goederen op de factuur” en “Prijs van de goederen op de factuur” zijn attributen van de entiteit “Lijst met goederen op de factuur”. We zullen hetzelfde doen met de verbinding die de entiteiten “Magazijn” en “Magazijn” verbindt. Product". Laten we even voorstellen extra entiteit"Artikel op voorraad." Het kenmerk van deze entiteit is 'Aantal goederen op voorraad'. Het product zal dus in elk magazijn worden vermeld en de hoeveelheid in elk magazijn zal anders zijn. Nu kunt u dit allemaal in het diagram invoeren: Conceptuele en fysieke ER-modellen Het hierboven ontwikkelde voorbeeld van een ER-diagram is een voorbeeld van een conceptueel diagram. Dit betekent dat het diagram geen rekening houdt met de kenmerken van een bepaald DBMS. Volgens dit conceptdiagram u kunt een fysiek diagram bouwen dat al rekening houdt met kenmerken van het DBMS, zoals acceptabele typen en namen van velden en tabellen, integriteitsbeperkingen, enz. De gegeven fysieke versie van het diagram kan er bijvoorbeeld als volgt uitzien: In dit diagram vertegenwoordigt elke entiteit een databasetabel, elk attribuut wordt een kolom van de overeenkomstige tabel. Houd er rekening mee dat in veel tabellen, bijvoorbeeld "CUST_DETAIL" en "PROD_IN_SKLAD", die overeenkomen met de entiteiten "Factuurlijstrecord" en "Artikel in magazijn", nieuwe attributen zijn verschenen die niet in het conceptuele model stonden - dit zijn de sleutel attributen van de bovenliggende tabellen, gemigreerd naar onderliggende tabellen om relaties tussen tabellen te verschaffen via externe sleutels. Het echte middel voor gegevensmodellering is dus niet de formele methode voor het normaliseren van relaties, maar de zogenaamde semantische modellering -relatiediagrammen worden gebruikt als hulpmiddel voor semantische modellering (ER - Entiteit-relatiediagrammen) waarmee u visueel kunt gebruiken grafische symbolen voor het modelleren van entiteiten en hun relaties. Entiteiten gedefinieerd in een conceptueel diagram worden tabellen, attributen worden tabelkolommen (rekening houdend met de gegevenstypen en kolomnamen die zijn toegestaan ​​voor een bepaald DBMS), relaties worden geïmplementeerd door sleutelkenmerken van bovenliggende entiteiten te migreren en externe sleutels te maken Het belangrijkste voordeel van de methode is dat het model is opgebouwd volgens de methode van opeenvolgende verfijningen van de initiële diagrammen. Complexere aspecten van de diagramconstructie, zoals subtypen, rollen, exclusieve links, niet-overdraagbare links, identificerende links, enz. werden niet overwogen.

De behoefte van databaseontwerpers aan handigere en krachtigere tools voor domeinmodellering heeft aanleiding gegeven tot de richting van semantische datamodellen. Gegeven dat elk ontwikkeld semantisch datamodel, net als een relationeel model, structurele, manipulatieve en integrale delen omvat, is het belangrijkste doel van semantische modellen het bieden van de mogelijkheid om de semantiek van data tot uitdrukking te brengen.

Voordat we kort ingaan op de kenmerken van algemene semantische modellen, kijken we eerst naar hun mogelijke toepassingen.

In de praktijk wordt semantische modellering meestal gebruikt in de eerste fase van het databaseontwerp. Bovendien in termen semantisch model er wordt een conceptueel databaseschema geproduceerd, dat vervolgens handmatig wordt omgezet in een relationeel (of een ander) schema. Dit proces wordt uitgevoerd onder controle van methoden waarin alle stadia van een dergelijke transformatie vrij duidelijk zijn gespecificeerd.

Minder vaak geïmplementeerd is de geautomatiseerde compilatie van een conceptueel schema in een relationeel schema. Er zijn twee benaderingen bekend: een benadering gebaseerd op de expliciete presentatie van een conceptueel diagram als initiële informatie voor compilatie, en een benadering gericht op het bouwen van geïntegreerde ontwerpsystemen met geautomatiseerde creatie van een conceptueel diagram op basis van interviews met domeinexperts. In beide gevallen is het resultaat een relationeel databaseschema in de derde normaalvorm.

Ten slotte is de derde mogelijkheid, die nog niet verder is gegaan dan onderzoeks- en experimentele projecten, het directe werken met de database in een semantisch model, d.w.z. DBMS gebaseerd op semantische datamodellen. In dit geval worden opnieuw twee opties overwogen: het verschaffen van een gebruikersinterface gebaseerd op een semantisch datamodel met automatische toewijzing van constructies aan een relationeel datamodel, en directe implementatie van een DBMS gebaseerd op een semantisch datamodel. Het dichtst bij de tweede benadering liggen moderne objectgeoriënteerde DBMS'en, waarvan de datamodellen in veel opzichten dicht bij semantische modellen liggen.

Semantisch model Entiteit-relatie (Entiteit-relatie)

Een van de meest populaire semantische datamodellen is het Entity-Relationship-model (vaak afgekort het ER-model genoemd).

De meeste moderne benaderingen van databaseontwerp (voornamelijk relationeel) zijn gebaseerd op het gebruik van variaties op het ER-model. Het model werd in 1976 door Chen voorgesteld. Domeinmodellering is gebaseerd op het gebruik van grafische diagrammen die een klein aantal heterogene componenten bevatten. Vanwege de helderheid van de presentatie van conceptuele databasediagrammen zijn ER-modellen wijdverspreid geworden in CASE-systemen die computerondersteund ontwerp ondersteunen relationele databases gegevens.

Het ER-model is niet een van de datamodellen die in bestaande datadefinitietalen worden gebruikt, hoewel het nauw verwant is aan sommige daarvan. Het dient om te rechtvaardigen welk type informatie in het databasesysteem moet worden opgeslagen. Het objectrelatiemodel vervult de functies van het modelleren van objecten uit de echte wereld waarbij databasesystemen zouden moeten worden gebruikt.

De term ‘object’ leent zich niet voor een alomvattende definitie. Het volstaat te zeggen dat een object iets bestaands en te onderscheiden is, dat wil zeggen dat we het ene object van het andere kunnen onderscheiden. Elke stoel is bijvoorbeeld een object. De objecten zijn dat ook specifieke persoon en een auto. Elke mier kan als een object worden beschouwd als er een manier is om hem van andere mieren te onderscheiden. Anders zien we de mier niet als een object. Objecten kunnen ook concepten op een hoger niveau zijn, zoals spin, knaagdier, baviaan en plant in een biologische database. Als we niet te streng zijn, kunnen begrippen als liefde en haat ook als objecten worden geclassificeerd.

De groep van alle vergelijkbare objecten vormt een verzameling objecten. Objectsets kunnen dus allemaal mensen zijn, alle auto's, alle dieren, alle emoties.

De term "soortgelijke objecten" is niet precies gedefinieerd, en het is mogelijk om een ​​oneindig aantal verschillende eigenschappen vast te stellen die een reeks objecten zullen definiëren. Een van belangrijkste punten bij het ontwerpen van een model uit de echte wereld is wat relevant is voor een bepaalde database de selectie van sets objecten.

Attributen en sleutels

Objecten hebben eigenschappen die attributen worden genoemd en die een waarde uit het waardedomein van een bepaald attribuut associëren met elk object in de verzameling objecten. Normaal gesproken bestaat het domein van een attribuut uit een reeks gehele getallen, reële getallen of tekenreeksen, maar we sluiten andere waardetypen niet uit. We kunnen bijvoorbeeld zeggen dat de objecten in de objectenset People attributen hebben zoals naam (een tekenreeks), hoogte (een reëel getal), enz.

Het selecteren van geschikte attributen voor sets objecten is het tweede belangrijke punt bij het ontwerpen van een model uit de echte wereld. Een attribuut of een reeks attributen waarvan de waarden elk object in een reeks objecten op unieke wijze identificeren, wordt de sleutel van die reeks objecten genoemd. In principe heeft elke set objecten een sleutel, omdat we de hypothese hebben aanvaard dat elk object te onderscheiden is van de rest. Maar als we voor een set objecten een verzameling attributen hebben gekozen die geen sleutel bevat, dan zal het onmogelijk zijn om het ene object in de set van het andere te onderscheiden. Vaak wordt als attribuut een willekeurig gekozen volgnummer opgegeven dat als sleutel dient. In een reeks objecten die alleen Amerikaanse staatsburgers omvat, kan bijvoorbeeld een enkel attribuut met de naam 'sofinummer' als sleutel worden gebruikt.

Er kunnen gevallen zijn waarin objecten in een set niet verschillen in attributen, maar in hun relatie met objecten van een ander type. Het belangrijkste type "ingebouwde" relatie (door de gebruiker gedefinieerde relaties zullen later worden beschreven) is de "is"-relatie. We zeggen dat A B is en schrijven 'A is B' als de verzameling objecten B een generalisatie is van de verzameling objecten A, of, op equivalente wijze, A een speciaal soort B is.

Beschouw een autodatabase met een set BRAND-objecten met de attributen TYPE en MODEL. Een object in de BRANDS-set is bijvoorbeeld “Datsun-280”. We kunnen ook een set CARS-objecten met een SERIAL-NUMBER-attribuut overwegen, die als de sleutel van deze set kan worden beschouwd. Het is echter waarschijnlijk dat de twee soorten auto's hetzelfde gebruiken serienummers. Om de objecten in de CARS-set uniek te maken, hebben we een relatie nodig tussen de CARS- en BRANDS-sets, die representeert dat elke auto een specifiek merk heeft. Vervolgens wordt elk exemplaar uit de set CARS-objecten uniek geïdentificeerd door het SERIENUMMER en het TYPE-attribuut van het bijbehorende object uit de set BRANDS.

Een relatie tussen sets objecten is eenvoudigweg een geordende lijst van sets objecten. Een bepaalde set objecten kan meerdere keren in deze lijst voorkomen. Als er een REL-verbinding bestaat tussen sets objecten E 1, E 2, ..., E k, dan wordt aangenomen dat er een set tupels met dimensie k is, waarvan de naam REL is. We noemen zo'n set een set van verbindingen. Elk tupel (e 1, e 2, ..., e k) in de verzameling REL impliceert dat de objecten e 1, e 2, ..., e k, waarbij ei tot de verzameling E i behoort, in een REL-relatie staan ​​met elkaar als groep. Het meest voorkomende geval is ongetwijfeld wanneer k=2, maar soms bestaan ​​lijsten uit drie of meer sets objecten.

Laten we zeggen dat we een set objecten PEOPLE hebben en een relatie IS-MOTHER waarvan de lijst met sets objecten PEOPLE, PEOPLE is. We nemen aan dat de verzameling IS-MOEDER-koppelingen alle paren (pi,pj) omvat, zodat persoon pi de moeder is van persoon pj.

§ 1. Concept en basismodellen van vertaling

Een vertaalmodel is een theoretisch construct, een algoritme dat de activiteiten van een vertaler in het vertaalproces beschrijft.

Belangrijkste modellen:

transformationeel-semantisch

denotatief-situationeel

communicatief

Transformationeel-semantisch:

twee is de transformatie van een variant van modelobjecten en structuren van één taal in

objecten en structuren van een ander volgens bepaalde regels , d.w.z. gebruik van verschillende soorten

correspondenties en transformaties, zonder verwijzing naar de buitentalige realiteit (L.S. Barkhudarov).

transformatie volgens de regels van intralinguale transformaties van 1) structuren van de vreemde taal om directe vertaling in de TL te garanderen; of 2) woord-voor-woord vertaling in PL Met

met als doel een idiomatische, competente vertaling in TL te verkrijgen (O.I. Brodovich, A.D. Schweitzer)

Vertalen:

Vóór de uitvinding van de mode in 1350 na Christus waren kleermakers niet nodig: kleding "aanpakte" de vorm van het lichaam niet.

Muggen worden twee keer zo sterk aangetrokken door de kleur blauw als door welke andere kleur dan ook.

Rassen van modellen gebouwd op verschillende

theorieën 1) Generatieve grammatica: taaltheorie

postuleert dat een persoon een bepaald taalvermogen heeft, bestaande uit kennis basisstructuren taal en regels voor hun transformatie naar oppervlakkige.

Voor Engelse taal gekenmerkt door 6 nucleaire/basisstructuren: NV

Er (zijn) N (D) N is N

bij het construeren van zogenaamde spraakuitingen. kernzinnen worden getransformeerd (getransformeerd) in oppervlakkige zinnen door

transformatie syntactische structuuréén zin:

John stuurde Bill een brief. ↔ De brief werd door John naar Bill gestuurd.

of verbindingen van verschillende kerncentrales met mogelijke weglating van elementen of gebruik van vervangende woorden

Nadat hij een brief naar Bill had gestuurd, ging John naar huis.

Schema van een vertaalmodel gebouwd op basis van generatieve grammatica

Voordelen en

Nadelen vereisen een minimale betrokkenheid van een model van buitentalige kennis om taalkundige structuren te interpreteren

stelt je in staat de hele diversiteit van taal terug te brengen tot een paar basisstructuren.

stelt je in staat om twee talen naar een semantische “gemene deler” te brengen

in de fase van de IT-analyse helpen ze dubbelzinnigheid weg te nemen, omdat nucleaire structuren ondubbelzinnig zijn maak de semantische structuur duidelijk

slechte werknemer (waarom persoon of proces?)

televisiezender prijs (onderwerp of object van actie?) het fundament van de school (proces of object?)

in de synthesefase stellen ze ons in staat problemen te overwinnen zoals:

1) afwezigheid van een overeenkomstige morfologische vorm in de TL (gerundium -Zijn aanpak van de militaire operatie lijkt laks te zijn. ← Het leek erop dat hij de militaire operatie uitvoerde. Het lijkt erop dat hij de militaire operatie niet duidelijk leidde.

2) onvermogen om de afgeleide betekenis van een woord op een morfologische manier over te brengen ( de huurverhoging, onruststoker)

3) verschillen in lexicale compatibiliteit ( Ze sprak over de verspilling van menselijke hulpbronnen).

4) om de onderwerp-rematische indeling te behouden of wanneer een Russische zin begint met een meewerkend voorwerp ( Amerikanen zijn ertoe gebracht te geloven dat...) enz.

2) Onderdeel

analyse: de betekenis van alle woorden in alle talen kan worden beschreven met behulp van dezelfde beperkte set van enkele tientallen elementen – semantische primitieven, overeenkomend met de betekenis van de woorden,

vermoedelijk voorkomend in welke taal dan ook en de conceptuele basis ervan vormen (bijvoorbeeld ‘ik’, ‘jij’, ‘iemand’, ‘iets’, ‘mensen’, ‘denken’, ‘spreken’, ‘weten’, ‘voelen’, ‘willen’)

Semes zijn onderverdeeld in drie typen: algemeen, differentieel en aanvullend. Algemene semes zijn die componenten die alle lexicaal-semantische varianten van één woord of synoniemen van één synoniemreeks verenigen (bijvoorbeeld geven in alle betekenissen is laten+hebben); differentieel - die componenten, cat. ervoor zorgen dat de geneesmiddelen in kwestie in verschillende synonieme series worden opgenomen ( geven – “gratis”, kopen “nemen voor geld”); aanvullend – die betekeniselementen die niet essentieel zijn voor de betekenis van het logische object, die vaak dienen als basis voor metaforische/metonymische overdracht.

Schema van een model gebaseerd op componententheorie

Voor- en nadelen van het model

stelt u in staat rekening te houden met verschillen in de componentstructuur van woorden en configuraties van semantische velden in twee talen bij het kiezen van de juiste TL-eenheid

Bij broer of zus vergeleken met broer, zus is er geen seme “geslacht”

Bij tekenen (niet-technisch) is er, vergeleken met tekenen, geen sprake van een “potlood”

Schoonzus, schoonzus (zus van man/vrouw) – schoonzus

verklaart gevallen waarin de betekenis van de oorspronkelijke eenheid wordt gespecificeerd vanwege het verschil in de configuratie van semantische velden

paars – elke kleur tussen rood en blauw: vertaald violet, lila, lila.

MAAR! onthult niet het mechanisme van syntactische en lexico-syntactische transformaties

3) Semantisch model “betekenis↔tekst”

probeert de patronen van transformatie van betekenis in tekst te weerspiegelen en vice versa.

De diepe structuur van een taal is niet alleen een diepe syntaxis (zoals in Chomsky), maar ook een diepe woordenschat.

Diepe woordenschat omvat alleen onafhankelijke (primaire woorden), en

de rest wordt geïnterpreteerd in termen van lexicale functies, die in twee categorieën vallen: gelijkwaardige vervangingen(synoniemen, “geef-ontvangst”-conversies, syntactische derivaten) en semantische parameters,enkele elementaire betekenissen van het trefwoord uitdrukken:

Oper1 ( typische situatie, opteller van het onderwerp in de rol van het onderwerp) – stel een vraag, zet een stap;

Oper2 (bevestiger van een object als subject) – aangevallen worden, gestraft worden.

Inctp – begin (opvlammen, stijgen), Fin – einde (gevestigd, weggetrokken),

Mag - hoge graad – (blunder, hete brunette).