2.1.2. Objectkenmerken

Een attribuut is een waarde die een object in zijn klasse karakteriseert. Voorbeelden van attributen: categorie, saldo, krediet (attributen van objecten van de rekeningklasse); naam, leeftijd, gewicht (attributen van objecten van de persoonsklasse), enz.

De attributen variëren permanente attributen(constanten) en variabele attributen. Constante attributen karakteriseren een object in zijn klasse (bijvoorbeeld rekeningnummer, categorie, naam van een persoon, enz.). Huidige waarden van attribuutvariabelen karakteriseren de stroom staat object (bijvoorbeeld rekeningsaldo, leeftijd van persoon, enz.); Door de waarden van deze attributen te veranderen, veranderen we de toestand van het object.

De attributen staan ​​vermeld in het tweede deel van de rechthoek die de klasse voorstelt (zie figuur 2.1). Soms wordt het type attributen aangegeven (elk attribuut heeft immers een bepaalde waarde) en de initiële waarde van variabele attributen (de set initiële waarden van deze attributen specificeert de initiële staat van het object).

Opgemerkt moet worden dat wanneer we het hebben over objecten en hun klassen, we niet een objectgeoriënteerde programmeertaal bedoelen. Dit blijkt vooral uit het feit dat in dit stadium ontwikkeling softwaresysteem Alleen die attributen die in werkelijkheid zinvol zijn, moeten in aanmerking worden genomen (alle attributen van objecten van de accountklasse - figuur 2.1 - hebben deze eigenschap). Attributen worden geassocieerd met features algehele implementatie. Als u bijvoorbeeld weet dat u een database gaat gebruiken waarin elk object een unieke identificatie heeft, mag u deze identificatie in dit stadium niet opnemen in de attributen van het object. Feit is dat we door het introduceren van dergelijke attributen de mogelijkheden om het systeem te implementeren beperken. Door dus een unieke object-ID als attribuut in de database te introduceren, weigeren we aan het begin van het ontwerp DBMS'en te gebruiken die een dergelijke identificatie niet ondersteunen.

Wiskundigen zijn te lui om in lekentaal uit te leggen wat een reëel getal is. Het is voor de gemiddelde persoon moeilijk om symbolen te lezen die door een wiskundige zijn geschreven, omdat hun betekenis hem niet duidelijk is. Het gevolg is dat er een kloof ontstaat tussen theorie en praktijk. In theorie weten wiskundigen heel goed wat voor soort objecten zijn en wat hun attributen zijn, maar in de praktijk zien we dat maar weinig beoefenaars begrijpen wat ze zijn. Er zijn veel intuïtieve concepten, maar elk daarvan lijkt meer op religieus dogma dan op kennis. In dit artikel heb ik geprobeerd de kloof tussen wiskundigen en toegepaste wetenschappers te overbruggen door de basisprincipes van de verzamelingenleer uit te leggen in eenvoudige taal, geen ingewikkelde iconen. Bent u bijvoorbeeld bekend met de definitie van attribuut? Ik heb er zelf onder geleden, omdat ik er geen formele definitie van kon vinden. En pas toen stuurde Igor Katrichek me een link naar het boek “Modeling Languages” van E. Kindler (1979, vertaald in 1985), waarin de definitie van een attribuut wordt gegeven:

In dit artikel zal ik mijn, meer geven algemene definitie attribuut zodat u het zich gemakkelijk kunt voorstellen.

In het laatste artikel heb ik gesproken over het feit dat verschillende objecten, die we als een geheel beschouwen, in onze geest bestaan, maar niet expliciet door ons worden herkend. Wiskundigen beseften dit en maakten het expliciet door het concept van verzameling te introduceren. Ik herinnerde me ook dat het concept veel en concept voorwerp- axioma's die niet uit andere concepten kunnen worden afgeleid. Tegelijkertijd is het concept van een object ons bekend en hebben we voldoende ervaring om ermee te werken, maar we maken kennis met een set op het instituut bij het bestuderen van de grondbeginselen van de wiskunde, en het idee ervan is niet zo vanzelfsprekend. Voor degenen die op zoek zijn naar een mogelijkheid om te leren hoe ze een verzameling duidelijker kunnen weergeven, heb ik je verteld waar we deze kunnen vinden goed beeld– bij de presentatie van structuren. In dit artikel ga ik verder met het verhaal over sets, en vertel ik je wat type En attribuut vanuit het oogpunt van de verzamelingenleer. En het allerbelangrijkste: ik zal je vertellen hoe deze concepten worden weerspiegeld in de modellen die we bouwen.

Sets in wiskunde en natuurkunde

We nemen de wereld waar als ruimte of als tijd, maar we kunnen ons niet beide tegelijkertijd voorstellen. Dit legt zijn beperkingen op de taal die we gebruiken en de modellen die we bouwen.

Een wiskundige verzameling bestaat bijvoorbeeld niet in de tijd, net als bewerkingen daarop. Dit betekent dat er niet kan worden gezegd dat de samenstelling van de set in de loop van de tijd verandert.

Dit lijkt mij een contra-intuïtieve en niet voor de hand liggende vereiste, maar zonder deze vereiste zullen we geen bewerkingen op sets kunnen uitvoeren en vergelijkingen kunnen maken. Dit betekent dat als we een reeks zandkorrels in een hoop zand willen beschrijven, we dit op twee manieren kunnen doen: voor elke nieuwe samenstelling van zandkorrels introduceren we een nieuwe reeks, of beschouwen we de reeks tijdelijke delen. zandkorrels in de te bestuderen hoop. Het tijdelijke deel van een zandkorrel verwijst naar de tijd A Ik maak deel uit van een zandkorrel die een attribuut heeft: begin en einde, en modelleert de aanwezigheid van deze zandkorrel in de hoop. Deze reeks tijdelijke delen wordt ook wel een 4D-representatie genoemd, gemaakt in het 4D-paradigma. Uit deze set kan tijdelijk de samenstelling van zandkorrels op een bepaald moment worden afgeleid O e plak: selecteer alleen die tijdelijke delen van zandkorrels die “actueel” zijn op dit moment dat wil zeggen de gegevens die eerder in de heap verschenen en later de heap verlieten dan het geselecteerde tijdstip.

Dit is hoe de samenstelling van echte ‘fysieke’ sets wordt gemodelleerd. Maar voor het huidige artikel zal een dergelijke representatie behoorlijk complex zijn, en ik zal terugkeren naar de gebruikelijke representatie van eenvoudige verzamelingen die “bevroren” zijn in de tijd, dat wil zeggen verzamelingen die “buiten de tijd” bestaan.

Het bepalen van de samenstelling van een set

Een set is veel, als geheel opgevat, waarbij veel de samenstelling van een set is. Laten we manieren bekijken om de samenstelling van een set te bepalen. Zoals we weten, kan de samenstelling van een set op twee manieren worden gespecificeerd:

1. Directe opsomming van objecten geselecteerd uit een set.
2. Regels voor het identificeren van objecten die uit een set zijn geselecteerd.

Stel dat er onder andere twee objecten in de kamer zijn: een wit bord en een groene markering.

1. Een set A bestaande uit deze twee elementen kan worden gespecificeerd door opsomming: het witte bord maakt deel uit van set A en de groene marker maakt deel uit van set A. Niets anders in de kamer maakt deel uit van set A.
2. Je kunt het anders doen. Kan op een bord en stift worden geplakt gele sticker en zorg ervoor dat er geen andere stickers in de kamer zijn. Dan kunnen we zeggen dat alleen die objecten in een bepaalde kamer die een gele sticker hebben, deel uitmaken van set A.

De eerste manier om de samenstelling te bepalen is door opsommen
De tweede methode is het instellen van de identificatievoorwaarde.

Tijdens de bespreking van het laatste artikel realiseerde ik me dat niet iedereen duidelijk het verschil begrijpt tussen deze twee manieren om de samenstelling van een set te bepalen. Daarom zal ik je meer over hen vertellen.

De eerste methode is gebaseerd op een reeks uitspraken:

Het bord maakt deel uit van set A
De stift maakt deel uit van set A
Niemand anders maakt deel uit van set A

De tweede manier is een verklaring in predikaten:

Dat en alleen dat voorwerp in de kamer met een gele sticker zit in set A.

De eerste methode om de compositie te beschrijven kan elk objectmodel omvatten. Bij de tweede beschrijvingsmethode moeten objectmodellen één gemeenschappelijk attribuut hebben, waarvan de waarde bepaalt of het object al dan niet in de set wordt opgenomen. Dat wil zeggen: als objectmodellen geen gemeenschappelijke kenmerken hebben, is het onmogelijk identificatievoorwaarden te construeren.

In de discussie werd voorgesteld om van de opname in de set, met behulp van een opsomming, ook een attribuut te maken: “deel van de set A.” De objecten die in set A zijn opgenomen, hebben dus de waarde van dit attribuut “ja”. Vervolgens werd voorgesteld om op basis van dit attribuut een teken te maken voor selectie in dezelfde set A: de objecten die de waarde “ja” hebben, worden opgenomen in de set A. De auteur van dit idee merkte dat niet omdat als resultaat van de logische conclusie uit deze twee uitspraken krijgen we twee tautologieën:

Set A omvat die en alleen die objecten die in set A zijn opgenomen En

Een object is opgenomen in set A als en slechts als het is opgenomen in set A.

Deze voor de hand liggende uitspraken bevatten noch informatie over specifieke objecten, noch over de verzameling A. Als ik een bord neem, dan zal het op basis van deze verklaring niet mogelijk zijn om te bepalen of deze tot de verzameling A behoort of niet.

Daarom zijn opsomming en regel twee fundamentele twee verschillende manieren beschrijvingen van de samenstelling van een set, en in de wiskunde worden ze aangegeven als twee belangrijke en totaal verschillende manieren om de samenstelling van een set te bepalen.

Trouwens, er was ooit een lang debat over de definitie van wat een functie is. Dit geschil ontstond omdat ze niet konden beslissen welke identificatieregels als correct werden beschouwd en welke niet. Als gevolg hiervan werd het idee van Dirichlet aanvaard dat alle regels als correct zouden worden beschouwd. Daarom zal ik niet proberen alle regels te classificeren, maar slechts enkele regels bespreken die we in deze context nodig hebben.

In leerboeken wordt de identificatieregel vaak de selectieregel genoemd. De term "selectieregel" is misleidend omdat deze een soort selectieoperatie impliceert. En dit is een hint dat de set mogelijk aangevuld wordt. Maar dat is niet waar. De set heeft een vaste samenstelling. Daarom is het beter om niet over selectie te praten, maar over identificatie. We selecteren geen elementen in een set, we identificeren ze als elementen van de set.

Het bepalen van de samenstelling van een deelverzameling

Laten we eens kijken hoe we de samenstelling van veel Afrikaanse olifanten bepalen. Ik telde vier verschillende manieren om dit te doen.

1. Je kunt ze definiëren door opsomming.
2. Je kunt een sticker op olifanten plakken en zeggen dat de olifanten met een sticker als Afrikaans worden beschouwd. Dit is het bepalen van de samenstelling van een set via een attribuut. Het attribuut wordt beschouwd als de aan- of afwezigheid van een sticker.
3. Je kunt de compositie bepalen door de kruising van twee sets: de set olifanten en de set dieren die in Afrika leven.
4. Je kunt een concept introduceren als ‘Afrikaanse olifanten’.

Door OWL in ons werk te gebruiken, hebben we de mogelijkheid om de drie hierboven beschreven methoden te implementeren voor het specificeren van een subset:

1. Vermeld expliciet de objecten die in de subset zijn opgenomen,
2. Definieer een identificatieregel via voorwaarden voor alle attributen, met verschillende bewerkingen: van het feit dat je de waarde van een attribuut bezit tot het feit dat deze waarde binnen een bepaald bereik valt
3. Specificeer bewerkingen op andere sets: set A bevat bijvoorbeeld alleen die objecten die zijn opgenomen in set B en niet zijn opgenomen in set C.

Laten we, om te begrijpen of we de vierde identificatiemethode met behulp van een objecttype kunnen implementeren, deze eens nader bekijken.

Een subset modelleren met behulp van een type

Om het type “Afrikaanse olifant” te bepalen hebben we nodig:

1. Een groep objecten waaruit we objecten selecteren voor een subtype. IN in dit geval Deze groep heeft een naam: dit is een groep olifanten.
2. Een uniek bezit waarin objecten van dit type zich onderscheiden van andere objecten uit de groep: ze wonen in Afrika.
3. Unieke naam voor objecten van dit type

Je kunt het anders doen en dieren die in Afrika leven als groep nemen. De unieke eigenschap die Afrikaanse olifanten onderscheidt van andere Afrikaanse dieren is dat deze dieren olifanten zijn.

Om een ​​type te definiëren heeft u in totaal het volgende nodig:

1. Geef een superset van objecten op.
2. Specificeer onderscheidende kenmerken(differentiële eigenschappen) van objecten van een bepaald type uit objecten van een groep.
3. Geef de naam op van objecten van dit type

Daarnaast kunt u opgeven:

• De redenen waarom er vraag naar dit soort objecten kwam (differentiële functionele eigenschappen van objecten van dit type
• De voordelen van het introduceren van dit type object
• Geschiedenis van de term

Objecten van hetzelfde type verschillen van andere objecten van de superset door een unieke eigenschap. Deze unieke eigenschap kan worden gemodelleerd via alle voorwaarden voor alle attributen. Maar het is niet nodig dat alle waarden van alle attributen samenvallen, of dat de samenstelling van attributen voor alle objecten van hetzelfde type hetzelfde is.

Als je weet wat een type is, zou je kunnen denken dat de vierde methode voor het identificeren van subsets samenvalt met de tweede. Om een ​​type te definiëren, moeten we echter bovendien minimaal een gespecialiseerde naam opgeven en, als optie, andere attributen van het type aangeven, bijvoorbeeld de redenen aangeven voor het selecteren van dit type object, de geschiedenis van de termijn, enz. Met de tweede methode is dit niet mogelijk. Daarom verschilt de vierde methode van de tweede en is deze nog niet geïmplementeerd in de modelleringsstandaarden die ik ken.

Concepttype

Dus vanuit het oogpunt van de verzamelingenleer:

Een type is een manier om een ​​subset uit een superset te selecteren en een nieuwe naam toe te kennen aan de objecten van deze subset

Als er geen superset is, wordt het type als axiomatisch en niet-afleidbaar beschouwd. Zoals ik eerder zei, zijn het concept van een object en het concept van een verzameling niet-afleidbare concepten, omdat er geen superset van objecten aan kan worden gegeven.

Verschil tussen objecttype en objectset

Uit de discussies over het artikel realiseerde ik me dat er mensen zijn die geloven dat het type objecten en de reeks objecten dat ook zijn gerelateerde concepten, of een en dezelfde. Ik zal proberen uit te leggen waarom dit niet zo is. Een type is zowel een regel voor het identificeren van objecten als een naam voor die objecten. Dat wil zeggen, het type dient tegelijkertijd om een ​​subset uit een set te specialiseren (of te selecteren), en geeft een nieuwe naam aan gespecialiseerde objecten.

Elk type bepaalt de samenstelling van een set, maar niet elke set komt overeen met een type dat de samenstelling ervan bepaalt, bijvoorbeeld als we het hebben over een set waarvan de samenstelling wordt gegeven door de elementen ervan op te sommen, of als we het hebben over een set waarvan de elementen dat wel doen. geen eigen naam hebben.

Het is duidelijk dat de regel die een verzameling definieert niet de verzameling zelf is.

Het lijkt mij dat uit alles wat er is gezegd duidelijk is hoe het concept van “type objecten” verschilt van het concept van “een reeks objecten”.

Modellering van soortgelijke objecten

Vaak worden in IS objecten van hetzelfde type gemodelleerd met behulp van modellen die dezelfde set attributen bevatten. Nu kun je dat zien deze beperking overbodig, omdat objecten van hetzelfde type dit kunnen hebben verschillende setjes attributen. Deze beperking wordt veroorzaakt technische kenmerken implementaties, maar geen vereisten vakgebied.

In de IS groeit de lijst met objecten van hetzelfde type. Dit suggereert de variabele samenstelling van de sets die we modelleren. Dit is echter niet waar. De lijst met objecten die in het IP-adres zijn geregistreerd, is geen uitputtende lijst van de set. Dat wil zeggen dat de IS niet de modellen van alle elementen van de set opslaat, maar alleen de modellen die momenteel zijn geregistreerd. Wanneer we een verzoek doen, betekent dit daarom: geef mij alle objecten van dit type die momenteel in de IS zijn geregistreerd.

Levenscyclus van objecten

Naast het feit dat een object geclassificeerd kan worden als een bepaald type objecten, zijn er nog twee punten die niet mogen worden vergeten:

1. Classificatie (een object toewijzen aan een bepaalde klasse of type object) is altijd subjectief. Hetzelfde object kan er vanuit verschillende gezichtspunten anders uitzien. Als we een uitbreidbaar domeinmodel bouwen, waarvan het gebruik de aanwezigheid van verschillende belanghebbenden impliceert, dan moet het mogelijk zijn om de context en verschillende gezichtspunten te modelleren. Bovendien kan hetzelfde object vanuit verschillende gezichtspunten in verschillende typen worden geclassificeerd.
2. Rekening houden met de levenscyclus van een object houdt niet alleen in dat we rekening houden met veranderingen in het object, maar ook dat we rekening houden met veranderingen in onze perceptie van dit object, aangezien er naast het proces van synthese en analyse een proces van objectivering en ontbinding plaatsvindt. -objectivering.

Het proces van objectivering en deobjectificatie ziet er als volgt uit:

Objectivering

Omdat we een idee hebben van de typen, proberen we objecten van deze typen te vinden in de wereld om ons heen. De gevonden objecten zijn meestal van de breedste typen. Bijvoorbeeld als waar we het over hebben over de onderneming, dan kunnen de gevonden objecten in de eerste stap betrekking hebben op operaties, functies en objecten. Of als we het over planten hebben, verdelen we ze eerst in bomen, gras en struiken. Vervolgens wordt het type object verduidelijkt door verschillende hypothesen te testen. Tijdens het verduidelijkingsproces proberen we een type te vinden dat ons voldoende over het object vertelt, zodat deze kennis effectief in de praktijk kan worden gebruikt (we proberen een beperkter type te vinden waaraan dit object kan worden toegeschreven). Tijdens het verfijningsproces krijgt het objectmodel nieuwe details. Tegelijkertijd gebruiken we onze kennis over dit object in de praktijk. Als de toepassing van deze kennis succesvol is, wordt het object als correct verkregen en correct geclassificeerd beschouwd (het objecttype is correct gekozen).

Deobjectificatie

Alles verandert echter: ideeën over de wereld om ons heen veranderen, er verschijnt nieuwe kennis, enz. Als gevolg hiervan blijkt dat het model van het object niet langer voldoet aan de eis van nut. En dan ook smalle specialisatie het object wordt zijn eigen vijand. Het object is onderhevig aan herclassificatie (de toepassing is een vraag geworden) en soms wordt het volledig vernietigd, net zoals ether of calorieën werden vernietigd. En dan begint de cyclus opnieuw: het selecteren van objecten, het verduidelijken van de kennis erover, enz.

Casestudies:

Objectivering:

Laat de opdrachtgever een aanvraag komen indienen. Totdat de order is uitgevoerd, kunnen we het type ervan alleen met een zekere mate van waarschijnlijkheid kennen. Daarom wordt de toepassing van het breedste type eerst geregistreerd. Naarmate de details worden verduidelijkt en tijdens het proces van de uitvoering ervan, krijgt het applicatiemodel nieuwe attributen. Na enige tijd wordt duidelijk tot welk type applicatie deze applicatie behoort en vindt de definitieve classificatie plaats.

Deobjectificatie:

Laten we hebben typisch scenario zoeken naar informatie op internet. Laat het zeggen dat wanneer u de nodige informatie moet vinden, u een bepaalde zoekmachine moet gebruiken - een zoekprogramma noodzakelijke informatie. Laten we dit programma vele malen gebruiken, telkens wanneer we een zoekactie uitvoeren. Er waren veel van dergelijke operaties tijdens de werking van dit programma, en ze werden allemaal geclassificeerd als operaties van het type "informatie zoeken". Na enige tijd blijkt dat het zoekmachineprogramma spionagefuncties uitvoert, waarbij gegevens over de gebruiker worden "lekken" naar personen die in deze informatie geïnteresseerd zijn. En dan blijkt dat de bewerkingen die deze zoekmachine gebruikte nu opnieuw zullen worden geclassificeerd van bewerkingen voor het ophalen van informatie naar bewerkingen voor gegevensoverdracht. geïnteresseerde partijen. Maar het kan heel goed gebeuren dat we iets meer over dit programma te weten komen en dat we dan andere operaties waaraan het deelnam, moeten heroverwegen.

Vereisten voor een modelleur modelleertypen

Laten we de vereisten formuleren voor een modeler die is ontworpen om typen te modelleren:

1. Het is noodzakelijk om objecten van hetzelfde type te kunnen modelleren, waarvan de samenstelling van de attributen niet overeenkomt
2. U moet regels kunnen modelleren die objecten in één type onderscheiden
3. De noodzaak om andere attributen van een type te modelleren: de naam van objecten van een bepaald type, de geschiedenis van deze naam, enz.
4. Moet kunnen modelleren verschillende punten zicht op hetzelfde object
5. Moet kunnen modelleren levenscyclus voorwerp
6. Het is noodzakelijk om veranderingen in ons begrip van een object in de loop van de tijd te kunnen modelleren.

Hoe kan de IT-industrie deze vereisten implementeren zonder toevlucht te nemen tot de databasestructuur? Hoe, zonder naar de datastructuur te verwijzen, rekening houden met verschillende gezichtspunten, nieuwe typen objecten toevoegen, het type objecten verduidelijken, objecten indien nodig opnieuw classificeren?

Objecten modelleren met OWL

Er is één beperking aanwezig in OWL: het maakt geen onderscheid tussen de set en het type objecten. Hierdoor hebben we beperkte functionaliteit voor het modelleren van objecttypen. Deze functionaliteit is echter veel breder dan wat andere modelleringsmethoden ons bieden, omdat we de volgende mogelijkheden hebben:

• Het toevoegen van een nieuwe set objecten aan OWL verschilt niet van het toevoegen van een nieuw object.
• Er kan worden geëist dat als het type van een object bekend is, er een model van het object wordt gemaakt met gegeven, eerder bekende attributen. Bovendien kunnen na het aanmaken attributen worden toegevoegd of verwijderd. Voorbeeld: bij het maken van een aanvraagmodel kunnen wij eisen dat attribuutwaarden worden opgegeven (aanvraagnummer, aanvraagdatum, aanvrager, geadresseerde). U hoeft alleen maar te onthouden dat deze attributen in OWL afzonderlijk van objecttypen bestaan. En één attribuut kan worden gebruikt bij het modelleren van objecten uit verschillende sets. Dit fundamenteel verschil uit gangbare programmeertalen, waarbij een attribuut slechts binnen één type object bestaat. Een ander attribuut van een ander type, zelfs met dezelfde naam, zal een ander attribuut zijn.
• U kunt het tegenovergestelde vereisen: een subset van het gemodelleerde object bepalen op basis van de attributen van het objectmodel en zijn lidmaatschap in de superset. Om dit te doen, zal de regel schrijven dat als het model van een object dat tot een bepaalde superset behoort, zulke en die attributen bevat en hun waarden aan bepaalde regels voldoen, het object automatisch aan een bepaalde subset zal worden toegewezen. Dus met behulp van regels zal de zogenaamde "eendclassificatie" worden geïmplementeerd. Als het aanvraagmodel bijvoorbeeld de attribuutwaarde ' Telefoonnummer”, en “Verbinding” de waarde is van het attribuut “Type uitgevoerd werk”, dan wordt de applicatie automatisch geclassificeerd als een applicatie voor het koppelen van een telefoonnummer.

Een set opdelen in subsets

Laat er een reeks objecten zijn. En laat het nu de taak zijn om deze set in zeven subsets te verdelen, die elk een eigen kleur krijgen: “rode objecten”, gele objecten.” Enz.

Het opdelen van een set in subsets kan op verschillende manieren.

1. U kunt een verzameling in onsamenhangende deelverzamelingen verdelen door objecten in deelverzamelingen te verdelen door ze op te sommen. Maak zeven subsets en noteer de objecten die bij elke subset horen.
2. Voor elke subset kun je je eigen subtype bedenken. Vervolgens kan de hele set in zeven subsets worden verdeeld door zeven subtypen te introduceren: 'Type rode objecten', 'Type gele objecten', enz. Elk object kan worden toegeschreven aan een van de genoemde typen en bijvoorbeeld zo zeggen : het object behoort tot het type rode objecten.
3. U kunt een superset scheiden met behulp van een attribuut en zijn waarden. U kunt bijvoorbeeld het attribuut “Kleur” en de zeven waarden ervan invoeren: “Rood”, “Geel”, enz. Dan wordt de naam van de kleur een bijvoeglijk naamwoord voor het object en klinkt als volgt: rood object, geel object, enz.

De eerste methode in OWL wordt geïmplementeerd door zeven verschillende klassen te maken en de objecten te specificeren die daarbij horen.

De tweede methode kan op drie verschillende manieren worden geïmplementeerd:

1. Door afzonderlijke subsets te creëren, verenigd door één type, maar de typen zelf worden, zoals ik al eerder zei, niet gemodelleerd. Deze methode verschilt niet van de opsommingsscheidingsmethode.
2. Met behulp van het naslagwerk "Soorten gekleurde objecten", waarvan de waarden objecten zijn die de typen modelleren: "Rode objecten", "gele objecten", enz.
3. Met behulp van een attribuut met de naam “objecttype”, waarvan de waarden in tekstvorm zijn: “Type rode objecten”, “Type gele objecten”, enz.

De derde manier om een ​​set in subsets te verdelen in een IS wordt op twee manieren gemodelleerd:

1. Met behulp van de map "Kleuren", waarvan de waarden objecten zijn die attribuutwaarden modelleren: rood, geel, enz.
2. Met behulp van een attribuut met de naam “Kleur”, waarvan de waarden in tekstvorm zijn: “rood”, “geel”, enz.

Het is duidelijk dat de scheiding met behulp van typen en attributen in twee gevallen op dezelfde manier is gemodelleerd, maar dat is wel het geval verschillende namen. Het eigendom van een attribuutwaarde in OWL wordt gemodelleerd door het volgende triplet:

#object #kenmerk #waarde

Het lidmaatschap van de klas is als volgt:

#object rdf:type #klasse

Dat wil zeggen, we kunnen zeggen dat klasselidmaatschap eenvoudigweg wordt uitgedrukt met behulp van een speciaal serviceattribuut dat is gedefinieerd in de standaard - rdf:type.

Kenmerkconcept

Laten we de stelling formuleren:

Een attribuut is een manier om een ​​set objecten in subsets te verdelen. In dit geval komt elke attribuutwaarde overeen met een specifieke subset, waarvan de objecten een attribuut met die waarde hebben.

Subsets modelleren met behulp van een attribuut

Elk van de drie eerder genoemde subset-modelleringsmethoden heeft zijn eigen voor- en nadelen, afhankelijk van de context en de gekozen implementatiemethode.

Als er weinig subsets zijn, kunt u een van de vermelde methoden voor het opdelen in subsets en elke implementatie kiezen.

Als er veel subsets zijn (in de limiet oneindig, bijvoorbeeld wanneer elk van de sets objecten van dezelfde lengte groepeert), dan blijft formeel het volgende over:

1. derde manier om type en
2. de tweede manier om het attribuut te modelleren.

Ik schreef echter eerder dat elk type een naam moet krijgen. Als er veel subsets zijn (oneindig), dan is het onrealistisch om aan elk ervan een naam te geven. Daarom modelleren we deze verdeling niet met behulp van typen. We modelleren deze verdeling alleen met behulp van een attribuut waarvan het waardenbereik een van de gemeenschappelijke sets zal zijn: set echte cijfers, een set die een tijdlijn modelleert, een set natuurlijke getallen, een set reeksen met een eindige lengte, enz. Herken jij de datatypen?

U kunt lezen hoe u een functie op een reeks deelverzamelingen introduceert, en niet alleen daarover

ER-diagrammen

Logisch model

Op een algemene manier inzendingen logisch model DB is de constructie van ER-diagrammen (Entiteit-relatie - entiteit-relatie). In dit model wordt een entiteit gedefinieerd als een afzonderlijk object waarvoor gegevenselementen worden opgeslagen, en beschrijft een relatie de relatie tussen twee objecten.

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

Toeristen

Vouchers

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

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

Elke voucher komt overeen met de betaling ervan (er kunnen meerdere betalingen plaatsvinden als de voucher bijvoorbeeld op krediet wordt verkocht).

Elke tour kan meerdere seizoenen hebben.

Het ticket wordt verkocht voor één seizoen van één tour.

Deze objecten en relaties kunnen worden weergegeven ER-diagram, zoals weergegeven in figuur 2.

Figuur 3.2. ER-diagram voor database-applicatie voor reisbureaumanagers

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

Tabel 3.2. Databaseobjecten en attributen

Houd er rekening mee dat er een aantal items ontbreken. Weggelaten registratie-informatie vermeld in functionele specificatie. Hoe u er rekening mee kunt houden, denkt u zelf na en maakt u het voorgestelde voorbeeld af. Maar belangrijker nog: de attributen die nodig zijn om objecten met elkaar te verbinden ontbreken nog steeds. Deze data-elementen worden niet weergegeven in het ER-model, omdat ze in feite geen ‘natuurlijke’ attributen van objecten zijn. Ze worden op een andere manier verwerkt en er zal rekening mee worden gehouden in het relationele datamodel.

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

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

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

Voor de ontworpen database zullen we de objectattributen uitbreiden met codevelden as primaire sleutels en gebruik deze codes in databaserelaties om als volgt naar databaseobjecten te verwijzen (tabel 3).

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

Tabel 3.3. DB-objecten en attributen met uitgebreide codevelden

Kenmerken van bedrijfsobjecten bevatten gegevens die zijn gekoppeld aan bedrijfsobjecten. Het opgeslagen attribuut vertegenwoordigt een databasetabelkolom of een databaseweergavekolom. De waarde van een niet-persistent attribuut bestaat alleen in het geheugen, omdat de gegevens die aan het attribuut zijn gekoppeld, niet in de database zijn opgeslagen.

Een opgeslagen bedrijfsobject kan zowel opgeslagen als niet-opgeslagen attributen hebben. Opgeslagen attributen van een bedrijfsobject worden gekoppeld aan kolommen in een databasetabel of -weergave. Alle attributen van niet-persistente bedrijfsobjecten zijn niet-persistente attributen.

Naast basisgegevenstype-informatie slaat het product aanvullende metagegevens op die verband houden met bedrijfsobjectkenmerken. Een attribuut kan bijvoorbeeld een domein, een aangepaste klasse of een standaardwaarde hebben; u kunt opgeven dat een attribuut een vereist attribuut is.

Kenmerkbeperkingen

Voordat u een attribuut wijzigt, kunt u controleren of het door het systeem is aangemaakt of door iemand op uw locatie. Door het systeem gegenereerde attributen hebben meer beperkingen op wijzigingen dan door gebruikers gemaakte attributen. Een door het systeem gegenereerd attribuut kan niet worden verwijderd.

In integratiescenario's kunnen gegevens voor een bedrijfsobject worden verkregen uit externe bedrijfsprogramma's. Het beperken van attribuutwijzigingen kan worden gebruikt om te voorkomen dat externe gegevens de attribuutwaarde overschrijven.

Sommige beperkingen zijn afhankelijk van of tekst zoeken object of zoek op gegevenstype. De regels voor wijzigingen zijn afhankelijk van het attribuut. Sommige gegevenstypen hebben bijvoorbeeld ingestelde waarde op lengte, schaal, datums of gehele getallen. De gegevens in het veld Opmerking zijn normale ALN-gegevens en dit veld bevat geen beperkte waarden.

Om kenmerkbeperkingen te beheren, kunt u het volgende doen:

• Bekijk beperkingen op attributen van het huidige object
• Beperk objectkenmerken
• Verwijder beperkingen op objectkenmerken

Beschrijvend attributen vertegenwoordigen feiten die inherent zijn aan elke beschrijving van een object. Voorbeeld - logische functie digitaal circuitelement.

Als de waarde van een beschrijvend attribuut verandert, geeft dit aan dat dat aspect van de objectinstantie is veranderd, maar dat het object hetzelfde blijft.

Wijzend attributen worden gebruikt om een ​​naam of aanduiding voor een exemplaar op te geven.

Aanwijsattributen worden gebruikt als objectidentificatoren.

Extra attributen worden gebruikt om een ​​exemplaar van het ene object te associëren met een exemplaar van een ander object. Bijvoorbeeld een exemplaar van het object ‘Microcircuit’ met een exemplaar van ‘Elektrisch schakelschema’.

Als de waarde van het hulpattribuut verandert, geeft dit aan dat andere instanties van het object nu gerelateerd zijn.

Beschrijving van attributen

Bij beschrijvende attributen specificeert de beschrijving het daadwerkelijke kenmerk dat als attribuut wordt geabstraheerd.

In dit geval wordt de beschrijving gegeven als:

Het opsommen van alle mogelijke waarden die het attribuut kan aannemen;

Het formuleren van een regel die bepaalt welke waarden toegestaan ​​zijn;

Het bereik van mogelijke waarden bepalen.

De beschrijving van de waarden van een indicatief attribuut bepaalt de vorm van de indicatie en de mate waarin het attribuut als identificatie kan worden gebruikt.

De beschrijving van een hulpattribuut moet een beschrijving bevatten van de daadwerkelijke relatie die door het attribuut wordt gedefinieerd.

Kenmerkregels

Sinds enige informatie model, door ons gegenereerd, mag geen informatiefouten (fouten) bevatten. Om dit te doen moet het ernaar streven een relationeel model te zijn, d.w.z. alle relaties tussen informatiemodelgegevens moeten voldoen aan de regels van relationele algebra.

1e attribuutregel

Eén objectinstantie heeft op elk moment één enkele waarde voor elk attribuut.

2e attribuutregel

Het attribuut mag geen interne structuur hebben. Alle attributen zijn eenvoudig.

3e attribuutregel

Als het object een samengestelde identificatie heeft, d.w.z. identifier die uit meer dan één attribuut bestaat, dan moet elk attribuut dat niet in de samengestelde identifier is opgenomen het gehele object karakteriseren, en niet een deel ervan.

Relaties tussen objecten

Verbindingen is een abstractie van een reeks relaties die systematisch ontstaan ​​tussen verschillende soorten objecten in de echte wereld.

Elke relatie in het informatiemodel wordt gespecificeerd door een paar namen die de relatie beschrijven vanuit het perspectief van elk deelnemend object.

Voorbeeld: een diagram bevat elementen - de elementen maken deel uit van het diagram.

De relatie wordt grafisch weergegeven door een lijn tussen gerelateerde elementen.

Voorbeeld: laten we een economisch object nemen:

Directe relaties zijn onderverdeeld in:

Onvoorwaardelijke verbindingen

Voorwaardelijke verbindingen

Onder de onvoorwaardelijke verbindingen zijn er drie fundamentele typen verbindingen. Dit zijn de aansluitingen:

Eén-op-één is een relatie waarbij één exemplaar van het ene object wordt geassocieerd met één exemplaar van een ander object.

Eén-op-veel is een relatie waarbij één exemplaar van een object is gekoppeld aan een of meer exemplaren van een ander object, en elke instantie van het andere object is gekoppeld aan slechts één exemplaar van het eerste object.

Veel-op-veel is een relatie waarin één exemplaar van een object wordt geassocieerd met een of meer exemplaren van een ander object, en elke instantie van een ander object wordt geassocieerd met een of meer exemplaren van het eerste.

2e type relatieverbinding – voorwaardelijke verbindingen.

Een voorwaardelijke verbinding kan exemplaren van een object hebben die niet deelnemen aan de verbinding.

N Bijvoorbeeld:

Alle verbindingen vereisen beschrijving. Beschrijving omvat:

Communicatie-ID

Formulering van relatienamen in termen van deelnemende objecten

Type verbinding (de pluraliteit en conditionaliteit ervan)

Verklaring over hoe de verbinding is geformaliseerd (waarom we deze verbinding introduceren)

Het formaliseren van een verbinding (de definitie ervan) bestaat uit het tot stand brengen van verbindingen tussen instanties van een object. Dit gebeurt met behulp van hulpmiddelen.

Als een object hulpattributen heeft, wordt de relatie geformaliseerd genoemd.

Om de één-op-veel-relatie te formaliseren, wordt het hulpattribuut aan de veel-kant gezet.

Als we een veel-op-veel-relatie hebben, maken we, om de derde attribuutregel niet te schenden, een hulpobject (associatief) dat verwijzingen bevat naar de identificatie van elke deelnemende instantie.

Relaties die ontstaan ​​door de aanwezigheid van andere verbindingen tussen objecten worden genoemd compositorisch verbindingen.

Als er sprake is van overerving in informatiemodellen, dan zijn er subtypes en supertypes.

Een supertype is een ouderobject.

Een subtype is een onderliggend object.