Matemaatikud on liiga laisad, et võhiku keeles seletada, mis on reaalarv. Võhikul on raske matemaatiku kirjutatud ikoone lugeda, sest nende tähendus pole talle selge. Selle tulemusena tekib lõhe teooria ja praktika vahel. Teoreetiliselt on matemaatikud hästi teadlikud sellest, mis tüüpi objektid on ja millised on atribuudid, kuid praktikasse minnes näeme, et vähesed praktikud mõistavad, mis need on. Intuitiivseid mõisteid on palju, kuid igaüks neist sarnaneb rohkem religioosse dogmaga kui teadmistega. Selles artiklis püüdsin ületada lõhet matemaatikute ja rakendusteadlaste vahel, selgitades hulgateooria põhitõdesid. selge keel, pole keerulisi ikoone. Näiteks, kas olete tuttav atribuudi määratlusega? Ma kannatasin selle ise välja, sest ma ei leidnud sellele ametlikku definitsiooni. Ja alles siis saatis Igor Katrichek mulle lingi E. Kindleri raamatule "Modelling Languages" (1979, tõlgitud 1985), mis defineerib atribuuti:

Selles artiklis annan oma, rohkem üldine määratlus atribuut, et saaksite seda hõlpsasti ette kujutada.

Viimases artiklis rääkisin sellest, et mitmed objektid, millest mõtleme tervikuna, on meie mõtetes olemas, kuid me ei tunne neid otseselt ära. Matemaatikud mõistsid seda ja tegid selle selgeks, tutvustades selle jaoks komplekti kontseptsiooni. Tuletasin ka meelde, et kontseptsioon trobikond ja kontseptsioon objekt- aksioomid, mis ei ole tuletatavad teistest mõistetest. Samas on objekti mõiste meile tuttav ja meil on nendega töötamiseks piisavalt kogemusi, kuid komplektiga tutvume instituudis matemaatika põhitõdesid õppides ja selle ideega. need pole nii ilmsed. Neile, kes otsivad võimalust õppida komplekti selgemalt esindama, olen öelnud, kust me leiame hea pilt kujundusvaates. Selles artiklis jätkan lugu komplektide kohta ja räägin teile, mida tüüp Ja atribuut hulgateooria seisukohalt. Ja mis kõige tähtsam, ma räägin teile, kuidas need kontseptsioonid kajastuvad meie loodud mudelites.

Komplektid matemaatikas ja füüsikas

Me tajume maailma kas ruumi või ajana, kuid me ei suuda ette kujutada mõlemat korraga. See seab meie kasutatavale keelele ja loodud mudelitele omad piirangud.

Näiteks matemaatilist hulka ei eksisteeri ajas, nagu ka tehteid sellega. See tähendab, et ei saa öelda, et komplekti koostis ajas muutuks.

Minu jaoks tundub see intuitiivse ja mitteilmse nõudena, kuid ilma selleta ei saa me komplektoperatsioone ega võrdlusi teha. See tähendab, et kui tahame kirjeldada liivaterade kogumit liivahunnikus, siis on meil selleks kaks võimalust: iga uue liivaterade koostise jaoks tutvustada uut komplekti või arvestada liiva ajaliste osade komplekti. terad uuritavas hunnikus. Liivatera ajalist osa mõistetakse ajalisena A Olen osa liivaterast, millel on atribuut: algus ja lõpp, simuleerides selle liivatera olemasolu hunnikus. Seda ajaliste osade komplekti nimetatakse ka 4D-paradigmas tehtud 4D esituseks. Sellest ajakomplektist saab teada liivaterade koostise konkreetsel hetkel O viil: valige ainult need liivaterade ajalised osad, mis on "asjakohased" Sel hetkel aeg, st need, mis ilmusid hunnikusse varem ja lahkusid valitud ajahetkest hiljem.

Nii modelleeritakse tõeliste "füüsiliste" komplektide koostist. Kuid praeguse artikli jaoks on selline esitus üsna keeruline ja ma pöördun tagasi tavapärase ajas "külmutatud" lihtsate hulkade, st nende, mis eksisteerivad "ajast väljaspool", juurde.

Komplekti koostise määramine

Komplekt on palju kui tervik, kus palju on komplekti kompositsioon. Mõelge komplekti koostise määramise viisidele. Nagu me teame, saab komplekti koostist määrata kahel viisil:

1. Mõnest komplektist valitud objektide otsene loendamine.
2. Reeglid mõnest komplektist valitud objektide tuvastamiseks.

Oletame näiteks, et ruumis on teiste objektide hulgas kaks objekti: valge plaat ja roheline marker.

1. Nendest kahest elemendist koosnevat komplekti A saab täpsustada loendamisega: valge plaat on osa komplektist A ja roheline marker on osa komplektist A. Miski muu ruumis ei kuulu komplekti A.
2. Saate teha teisiti. Võimalik liimida plaadile ja markerile kollane kleebis ja veenduge, et ruumis poleks muid kleebiseid. Siis saame öelda, et need ja ainult need esemed selles ruumis, millel on kollane kleebis, kuuluvad komplekti A.

Esimene viis koostise määramiseks on loendus
Teine võimalus on määrata tuvastamise tingimus.

Viimase artikli arutelu käigus mõistsin, et mitte kõik ei mõista selgelt nende kahe komplekti koostise määramise viisi erinevust. Seetõttu räägin teile neist lähemalt.

Esimene viis põhineb väidete seerial:

Plaat kuulub komplekti A
Marker on osa komplektist A
Keegi teine ​​ei kuulu komplekti A

Teine viis on avaldus predikaatides:

See ja ainult see ese ruumis, millel on kollane kleebis, kuulub komplekti A.

Kompositsiooni kirjeldamise esimesel viisil võivad osaleda kõik objektide mudelid. Teisel objektimudelite kirjeldamisel peab neil olema üks ühine atribuut, mille väärtus määrab, kas objekt on komplektis või mitte. See tähendab, et kui objektimudelites puuduvad ühised atribuudid, on identifitseerimistingimuste konstrueerimine võimatu.

Arutelul pakuti välja, et atribuudiks tuleks teha ka loenduse abil hulka sisenemine: “on osa hulgast A”. Seega on nendel objektidel, mis kuuluvad hulka A, selle atribuudi väärtus "jah". Seejärel tehti selle atribuudi põhjal ettepanek teha sama komplekti A kompositsioonile valimise märk: need objektid, mille väärtus on "jah", kaasatakse komplekti A. Käesoleva leiutise autor ei märganud, et nende kahe väite loogilise järelduse tulemusena saame kaks tautoloogiat:

Hulga A koostis sisaldab neid ja ainult neid objekte, mis kuuluvad komplekti A Ja

Objekt on hulga A liige siis ja ainult siis, kui ta on hulga A liige.

Need ilmselged väited ei sisalda infot konkreetsete objektide ega hulga A kohta. Kui ma võtan plaadi, siis selle väite põhjal ei ole võimalik kindlaks teha, kas see kuulub hulka A või mitte.

Seetõttu on loendus ja reegel põhimõtteliselt kaks erinevatel viisidel hulga koostise kirjeldusi ja matemaatikas on need loetletud kahe põhilise ja täiesti erineva hulga koostise defineerimise viisina.

Muide, omal ajal käis pikalt vaidlus selle üle, mis funktsioon on. See vaidlus tekkis seetõttu, et nad ei suutnud otsustada, milliseid tuvastamisreegleid õigeks pidada ja milliseid mitte. Selle tulemusena võeti vastu Dirichlet’ idee, et kõiki reegleid peetakse õigeks. Seetõttu ei püüa ma kõiki reegleid klassifitseerida, vaid käsitlen vaid mõnda, mida me selles kontekstis vajame.

Õpikutes nimetatakse identifitseerimisreeglit sageli valikureegliks. Mõiste "valikureegel" on eksitav, kuna see viitab mingisugusele valikutoimingule. Ja see on vihje, et komplekti saab täiendada. Aga ei ole. Komplekt on kindla koostisega. Seetõttu on parem rääkida mitte valikust, vaid tuvastamisest. Me ei vali elemente hulka, vaid tuvastame need komplekti elementidena.

Alamhulga koostise määramine

Vaatame, kuidas me määrame paljude Aafrika elevantide koostise. Lugesin selleks kokku neli erinevat viisi.

1. Saate neid määratleda loenduse abil.
2. Võite kleepida elevantidele kleebise ja öelda, et neid elevante, millel on kleebis, peetakse aafriklasteks. See on komplekti koostise määratlus atribuudi kaudu. Kleebise olemasolu või puudumine loetakse atribuudiks.
3. Kompositsiooni saab määrata kahe komplekti ristumiskoha kaudu: elevantide kogum ja Aafrikas elavate loomade kogum.
4. Saate tutvustada tüübi "Aafrika elevandid" kontseptsiooni.

Kasutades oma töös OWL-i, saame alamhulga määramiseks rakendada kolme ülalkirjeldatud meetodit:

1. Loetlege selgesõnaliselt alamhulka kuuluvad objektid,
2. Määratlege identifitseerimisreegel mis tahes tingimuste kaudu mis tahes atribuutide jaoks erinevate toimingutega: alates atribuudi väärtuse omamisest kuni selle väärtuse viimiseni teatud vahemikku
3. Määrake toimingud teiste hulgaga: näiteks sisaldab komplekt A ainult neid objekte, mis kuuluvad komplekti B ja ei sisaldu komplektis C.

Et näha, kas suudame neljandat tüüpi identifitseerimist objektitüübiga rakendada, vaatame seda lähemalt.

Alamhulga modelleerimine tüübiga

"Aafrika elevandi" tüübi määramiseks vajame:

1. Objektide rühm, millest valime alamtüübi objektid. IN sel juhul sellel rühmal on nimi – see on rühm elevante.
2. Unikaalne omadus, mis eristab teatud tüüpi objekte rühma teistest objektidest: nad elavad Aafrikas.
3. Objektide ainulaadne nimi seda tüüpi

Võite teha teisiti ja võtta Aafrikas elavad loomad rühmana. Siis on ainulaadne omadus, mis eristab Aafrika elevante teistest Aafrika loomadest, et need loomad on elevandid.

Kokkuvõttes on tüübi määratluse andmiseks vaja:

1. Määrake objektide liig.
2. Täpsustage eristavad tunnused(diferentsiaalomadused) antud tüüpi objektide rühmaobjektidest.
3. Määrake seda tüüpi objektide nimed

Lisaks saate määrata:

• Põhjused, miks seda tüüpi objektid nõudsid (seda tüüpi objektide erinevad funktsionaalsed omadused
• Kasutage seda tüüpi objektide kasutuselevõttu
• Termini ajalugu

Sama tüüpi objektid erinevad teistest superkomplekti objektidest mõne ainulaadse omaduse poolest. Seda ainulaadset omadust saab modelleerida mis tahes atribuutide mis tahes tingimuste abil. Kuid samal ajal ei ole vaja, et kõigi atribuutide kõik väärtused ühtiksid või et kõigi sama tüüpi objektide atribuutide koostis oleks sama.

Teades, mis on tüüp, võib arvata, et neljas alamhulga viis on sama, mis teine. Kuid tüübi määramiseks peame lisaks määrama vähemalt spetsialiseeritud nime ja valikuna muud tüüpi atribuudid, näiteks näitama seda tüüpi objekti valimise põhjused, termini ajalugu , ja nii edasi. Seda ei saa teha teise meetodi abil. Seetõttu erineb neljas meetod teisest ja seda pole mulle teadaolevates modelleerimisstandardites veel rakendatud.

Mõiste tüüp

Niisiis, hulga teooria osas:

Tüüp on viis eraldada alamhulk superhulgast ja anda selle alamhulga objektidele uus nimi

Kui superkomplekti pole, peetakse tüüpi aksiomaatiliseks, mittetuletatavaks. Nagu ma varem ütlesin, on objekti mõiste ja hulga mõiste mittetuletatavad mõisted, kuna te ei saa nende jaoks määrata objektide superhulka.

Objektitüübi ja objektikomplekti erinevus

Artikli aruteludest sain aru, et on inimesi, kes usuvad, et objektide tüüp ja objektide kogum on kas seotud mõisted või üks ja seesama. Püüan selgitada, miks see nii ei ole. Tüüp on nii objektide tuvastamise reegel kui ka nende objektide nimi. See tähendab, et tüüp teenindab nii komplektist alamhulga spetsialiseerumist (või valikut) kui ka annab spetsialiseerunud objektidele uue nime.

Iga tüüp määrab hulga koostise, kuid mitte iga hulk ei vasta tüübile, mis määrab selle koostise, näiteks kui me räägime hulgast, mille koostise annab selle elementide loendamine, või kui me räägime hulgast mille elementidel ei ole oma nime.

On selge, et hulka määratlev reegel ei ole hulk ise.

Mulle tundub, et öeldust selgub, mille poolest erineb mõiste "objektitüüp" mõistest "objektide kogum".

Sama tüüpi objektide modelleerimine

Sageli modelleeritakse IS-is sama tüüpi objekte sama atribuutide komplekti sisaldavate mudelite abil. Nüüd näete seda see piirangüleliigne, kuna sama tüüpi objektidel võib olla erinevad komplektid atribuudid. See piirang on tingitud tehnilised omadused teostused, kuid mitte nõuded ainevaldkond.

IS-is täiendatakse sama tüüpi objektide loendit. See viitab modelleeritavate komplektide muutuvale koostisele. Siiski ei ole. IS-is registreeritud objektide loetelu ei ole komplekti ammendav loetelu. See tähendab, et IS ei salvesta kõigi komplekti elementide mudeleid, vaid ainult neid, mis on hetkel registreeritud. Seega, kui esitame päringu, on selle tähendus järgmine: andke mulle kõik seda tüüpi objektid, mis on praegu IS-is registreeritud.

Objekti elutsükkel

Lisaks sellele, et objektile saab omistada teatud tüüpi objektide puhul on veel kaks punkti, mida ei tohiks unustada:

1. Klassifitseerimine (objekti määramine teatud objektide klassi või tüüpi) on alati subjektiivne. Sama objekt võib erinevatest vaatenurkadest erinev välja näha. Kui ehitame laiendatava domeenimudeli, mille kasutamine eeldab erinevate huvigruppide kohalolekut, siis peaks olema võimalik modelleerida konteksti ja erinevaid vaatenurki. Samal ajal saab erinevatest vaatepunktidest sama objekti määrata erinevatele tüüpidele.
2. Objekti elutsükli arvestamine hõlmab mitte ainult objekti muutuste arvessevõtmist, vaid ka selle objekti tajumise muutuste arvessevõtmist, kuna koos sünteesi ja analüüsi protsessiga toimub ka objektistamise ja objektistamise protsess. deobjektiivsus.

Objektistamise ja deobjektifikatsiooni protsess näeb välja järgmine:

Objektistamine

Omades aimu tüüpidest, püüame leida seda tüüpi objekte meid ümbritsevast maailmast. Leitud objektid kipuvad olema kõige laiemat tüüpi. Näiteks kui me räägime ettevõtte kohta, siis esimese sammuna võivad leitud objektid olla seotud toimingute, funktsioonide ja objektidega. Või kui räägime taimedest, siis jagame need esmalt puudeks, rohuks ja põõsasteks. Järgmisena täpsustatakse objekti tüüpi, testides erinevaid hüpoteese. Täpsustusprotsessis püüame leida tüüpi, mis räägiks meile objekti kohta piisavalt, et neid teadmisi saaks praktikas efektiivselt kasutada (püüame leida kitsamat tüüpi, millele antud objekti omistada). Täiustamise käigus omandab objektimudel uusi detaile. Paralleelselt kasutame oma teadmisi selle objekti kohta praktikas. Kui nende teadmiste rakendamine on edukas, loetakse objekt õigesti saadud ja õigesti klassifitseerituks (objekti tüüp on õigesti valitud).

Deobjektiivsus

Kõik aga muutub: muutuvad ettekujutused meid ümbritsevast maailmast, ilmuvad uued teadmised jne. Selle tulemusena selgub, et objektmudel ei rahulda enam kasulikkuse nõuet. Ja siis ka kitsas spetsialiseerumine objektist saab iseenda vaenlane. Objekt klassifitseeritakse ümber (taotlusest on saanud nõudmine) ja mõnikord hävitatakse see täielikult, kuna hävis eeter ehk kalorikogus. Ja siis algab tsükkel otsast peale: objektide valik, nende kohta teadmiste täpsustamine jne.

Näited praktikast:

Objektiivsus:

Las klient tuleb kandideerima. Kuni päringu täitmiseni saame selle tüüpi teada vaid teatud tõenäosusega. Seetõttu registreeritakse kõigepealt kõige laiema tüübi rakendus. Seejärel, kui üksikasjad on selgunud ja selle täitmise käigus, omandab rakendusmudel uued atribuudid. Mõne aja pärast saab selgeks, mis tüüpi rakendustele see rakendus kuulub ja toimub selle lõplik klassifitseerimine.

Deobjektiivsus:

Laske meil olla tüüpiline stsenaarium Internetist teabe otsimine. Olgu öeldud, et alati, kui on vaja leida vajalik info, kasuta sellist ja sellist otsingumootorit – otsinguprogrammi vajalikku teavet. Oletame, et kasutasime seda programmi mitu korda, tehes iga kord otsingutoimingu. Selliseid operatsioone oli selle programmi töötamise ajal palju ja kõik need liigitati "infootsingu" tüüpi operatsioonideks. Mõne aja pärast selgub, et otsingumootori programm täidab spioonifunktsioone, "liites" kasutaja andmed selle teabe vastu huvi tundvate isikutega. Ja siis selgub, et need toimingud, mida see otsingumootor kasutas, liigitatakse nüüd teabeotsingu operatsioonidest ümber andmeedastustoiminguteks. huvitatud isikud. Kuid võib juhtuda, et saame selle programmi kohta midagi rohkem teada ja siis peame uuesti läbi mõtlema muud operatsioonid, milles ta osales.

Nõuded modelleerijale modelleerimistüüpide jaoks

Sõnastame nõuded modelleerijale, mis on mõeldud tüüpide modelleerimiseks:

1. Tuleb osata modelleerida sama tüüpi objekte, mille atribuutide koostis ei ühti
2. Tuleb osata modelleerida reegleid, mis eristavad objekte ühte tüüpi
3. Vajadus modelleerida muid tüüpi atribuute: seda tüüpi objektide nimed, selle nime ajalugu jne.
4. Peab oskama modelleerida erinevad punktid vaade samale objektile
5. Peab oskama modelleerida eluring objektiks
6. Tuleb osata modelleerida, kuidas meie ettekujutus objektist aja jooksul muutub.

Kuidas saab IT-tööstus neid nõudeid rakendada ilma andmebaasistruktuurile viitamata? Kuidas andmestruktuurile viitamata võtta arvesse erinevaid vaatenurki, lisada uut tüüpi objekte, täpsustada objektide tüüpe, vajadusel objekte ümber klassifitseerida?

Objekti modelleerimine OWL-iga

OWL-is on üks piirang: selles ei erine objektide komplekt ja tüüp. Seetõttu on meil piiratud funktsionaalsus objektitüüpide modelleerimiseks. See funktsionaalsus on aga palju laiem kui see, mida teised modelleerimismeetodid meile pakuvad, kuna meil on järgmised võimalused:

• Uue objektide komplekti lisamine OWL-i ei erine uue objekti lisamisest.
• Võib nõuda, et kui objekti tüüp on teada, siis koostatakse objektimudel etteantud teadaolevate atribuutidega. Samal ajal saab pärast loomist atribuute nii lisada kui eemaldada. Näide: taotlusmudeli loomisel võime nõuda atribuutide väärtuste täpsustamist (taotluse number, taotluse kuupäev, taotleja, adressaat). Peate lihtsalt meeles pidama, et need OWL-i atribuudid eksisteerivad objektitüüpidest eraldi. Ja ühte atribuuti saab kasutada erinevate kogumite objektide modelleerimisel. See põhimõtteline erinevus levinud programmeerimiskeeltest, kus atribuut eksisteerib ainult ühte tüüpi objektides. Teine atribuut teisest tüübist, isegi kui selle nimi on sama, oleks teine ​​atribuut.
• Võite nõuda vastupidist: modelleeritava objekti alamhulga määramiseks objektimudeli atribuutide ja selle superhulka kuulumise põhjal. Selleks kirjutatakse reeglisse, et kui teatud superhulka kuuluva objekti mudel sisaldab selliseid ja selliseid atribuute ja nende väärtused vastavad teatud reeglitele, siis määratakse objekt automaatselt teatud alamhulga. Nii et reeglite abil rakendatakse nn "pardi klassifikatsiooni". Näiteks kui piletimudelil on atribuudi väärtus " Telefoninumber”, ja „Ühendus” on atribuudi „Teostatud töö tüüp” väärtus, siis klassifitseeritakse päring automaatselt telefoninumbri ühendamise päringuks.

Hulgi jagamine alamhulkadeks

Olgu objekte kogum. Ja olgu ülesandeks jagada see komplekt seitsmeks alamhulgaks, millest igaühele on määratud oma värv: “punased objektid”, kollased objektid. Jne.

Hulga jagamist alamhulkadeks saab teha erineval viisil.

1. Saate jagada hulga mittekattuvateks alamhulkadeks, jaotades objektid alamhulkadeks, loendades need. Looge seitse alamhulka ja loetlege igasse alamhulka kuuluvad objektid.
2. Iga alamhulga jaoks saate välja mõelda oma alamtüübi. Seejärel saab kogu komplekti jagada seitsmeks alamhulgaks, võttes kasutusele seitse alamtüüpi: “Punaste objektide tüüp”, “Kollaste objektide tüüp” jne. Iga objekti saab määrata ühele loetletud tüüpidest ja öelda näiteks nii : objekt kuulub punaste objektide tüüpi.
3. Superkomplekti saab jagada atribuudi ja selle väärtuste abil. Näiteks võite sisestada atribuudi "Värv" ja selle seitse väärtust: "Punane", "Kollane" jne. Seejärel muutub värvi nimi objekti omadussõnaks ja kõlab järgmiselt: punane objekt, kollane objekt jne.

Esimene viis OWL-is realiseeritakse seitsme erineva klassi loomisega ja nendesse kuuluvate objektide täpsustamisega.

Teist viisi saab rakendada kolmel erineval viisil:

1. Luues eraldi alamhulgad, mida ühendab üks tüüp, kuid tüüpe endid, nagu ma varem ütlesin, ei modelleerita. See meetod ei erine loendusmeetodist.
2. Kasutades teatmeteost "Värviliste objektide tüübid", mille väärtusteks on objektide modelleerimise tüübid: "Punased objektid", "kollased objektid" jne.
3. Kasutades atribuuti nimega "objekti tüüp", mille väärtused on teksti kujul: "Punaste objektide tüüp", "Kollaste objektide tüüp" jne.

Kolmas viis hulga alamhulkadeks jagamiseks IS-is on modelleeritud kahel viisil:

1. Kasutades teatmeteost "Värvid", mille väärtusteks on objektid, mis modelleerivad atribuutide väärtusi: punane, kollane jne.
2. Kasutades atribuuti nimega "Värv", mille väärtused on teksti kujul: "punane", "kollane" jne.

On näha, et tüüpide ja atribuutide abil eraldamist modelleeritakse mõlemal juhul ühtemoodi, kuid on erinevad nimed. Tõepoolest, atribuudi väärtuse omamine OWL-is on modelleeritud kolmikuna:

#objekt #atribuut #väärtus

Klassi liikmeskond on järgmine:

#objekt rdf:tüüp #klass

See tähendab, et võime öelda, et klassi kuulumist väljendatakse lihtsalt standardis määratletud spetsiaalse teenuseatribuudi abil - rdf:type.

Atribuudi mõiste

Sõnastame avalduse:

Atribuut on viis objektide hulga jagamiseks alamhulkadeks. Sellisel juhul vastab iga atribuudi väärtus teatud alamhulgale, mille objektidel on sellise väärtusega atribuut.

Alamhulkade modelleerimine atribuudiga

Kõigil kolmel varem loetletud alamhulga modelleerimismeetodil on eelised ja puudused, olenevalt kontekstist ja valitud rakendusest.

Kui alamhulka on vähe, saate valida mis tahes loetletud alamhulkadeks jagamise meetodi ja mis tahes rakenduse.

Kui alamhulka on palju (limiidis lõpmatult, näiteks kui iga hulk rühmitab sama pikkusega objekte), jääb formaalselt alles:

1. kolmas viis tüübi modelleerimiseks ja
2. teine ​​viis atribuudi modelleerimiseks.

Küll aga kirjutasin varem, et igale tüübile tuleb panna nimi. Kui alamhulka on palju (lõpmatult), siis on igaühele nime andmine ebareaalne. Seetõttu me seda jaotust tüüpidega ei modelleeri. Modelleerime selle jaotuse ainult atribuudiga, mille vahemik on üks tavahulkadest: hulk reaalarvud, ajaskaalat modelleeriv hulk, naturaalarvude hulk, lõpliku pikkusega stringide hulk jne. Kas tunnete ära andmetüübid?

Saate lugeda selle kohta, kuidas funktsiooni alamhulkade komplektis tutvustatakse, mitte ainult selle kohta.

kirjeldav atribuudid esindavad iga objekti kirjeldusele omaseid fakte. Näide - tõeväärtuslik funktsioon digitaalse vooluringi element.

Kui kirjeldava atribuudi väärtus muutub, näitab see, et objekti eksemplari see aspekt on muutunud, kuid objekt on jäänud samaks.

Osutades atribuute kasutatakse eksemplari nimetamiseks või määramiseks.

Osutusatribuute kasutatakse objekti identifikaatoritena.

Abistav atribuute kasutatakse ühe objekti eksemplari seostamiseks teise objekti eksemplariga. Näiteks objekti "Microcircuit" eksemplar koos "Elektriskeem" eksemplariga.

Kui abiatribuudi väärtus muutub, näitab see, et nüüd on objekti teised eksemplarid omavahel seotud.

Atribuutide kirjeldus

Kirjeldavate atribuutide puhul täpsustab kirjeldus tegeliku tunnuse, mis on atribuudina võetud.

Sel juhul antakse kirjeldus järgmiselt:

Kõigi võimalike väärtuste loend, mida atribuut võib võtta;

Reegli sõnastus, mis määrab, millised väärtused on lubatud;

Võimalike väärtuste vahemiku määramine.

Määrava atribuudi väärtuste kirjeldus määrab tähise vormi ja selle, mil määral saab seda atribuuti identifikaatorina kasutada.

Abiatribuudi kirjeldus peab sisaldama atribuudiga määratletud tegeliku seose kirjeldust.

Atribuutide reeglid

Kuna mis tahes teabemudel, mille oleme moodustanud, ei tohiks sisaldada teabevigu (vigu). Selleks peab ta püüdlema relatsioonimudeli poole, s.t. kõik infomudeli andmete vahelised seosed peavad vastama relatsioonialgebra reeglitele.

1. atribuudi reegel

Ühel objekti eksemplaril on igal ajahetkel iga atribuudi jaoks üks väärtus.

2. atribuudi reegel

Atribuudil ei tohi olla sisemist struktuuri. Kõik atribuudid on lihtsad.

3. atribuudi reegel

Kui objektil on liitidentifikaator, st. identifikaator, mis koosneb rohkem kui ühest atribuudist, siis peab iga atribuut, mis ei sisaldu liitidentifikaatoris, iseloomustama kogu objekti, mitte selle osa.

Sidemed objektide vahel

Ühendused on abstraktsioon suhetest, mis esinevad süstemaatiliselt erinevate asjade vahel pärismaailmas.

Teabemudeli iga link on määratletud nimepaariga, mis kirjeldab linki iga osaleva üksuse vaatenurgast.

Näide: skeem sisaldab elemente – elemendid on skeemi osa.

Suhet kujutatakse graafiliselt seotud elementide vahelise joonega.

Näide: võtke majandusobjekt:

Otsesed suhted jagunevad:

Tingimusteta ühendused

Tingimuslikud lingid

Tingimusteta ühenduste hulgas eristatakse 3 põhilist tüüpi ühendust. Need on ühendused:

"Üks ühele" – seos, kus ühe objekti üks eksemplar on seotud teise objekti ühe eksemplariga

"Üks-mitmele" - suhe, milles mõne objekti üks eksemplar on seotud teise objekti ühe või mitme eksemplariga, samas kui teise objekti iga eksemplar on seotud ainult esimese objekti ühe eksemplariga.

Paljud-mitmele on suhe, kus objekti üks eksemplar on seotud teise objekti ühe või mitme eksemplariga ja teise objekti iga eksemplar on seotud esimese ühe või mitme eksemplariga.

Seoste seose 2. tüüp on tingimuslikud ühendused.

Tingimuslikul suhtel võivad olla objektieksemplarid, mis suhtes ei osale.

H näiteks:

Kõik ühendused vajavad kirjeldust. Kirjeldus sisaldab:

Lingi ID

Suhtenimede sõnastamine osalevate üksuste järgi

Ühenduse tüüp (selle paljusus ja tingimuslikkus)

Teatis selle kohta, kuidas ühendus vormistati (miks me seda ühendust tutvustame)

Seose formaliseerimine (selle definitsioon) seisneb suhete loomises objekti eksemplaride vahel. Seda tehakse abivahendite abil.

Kui objektil on abiatribuudid, siis öeldakse, et suhe on formaliseeritud.

Üks-mitmele seose vormistamiseks on "paljude" poolele seatud abiatribuut.

Kui meil on palju-mitmele suhe, siis selleks, et mitte rikkuda 3. atribuudireeglit, luuakse abiobjekt (assotsiatiivne), mis sisaldab viiteid iga osaleva eksemplari identifikaatorile.

Nimetatakse linke, mis tekivad muude objektidevaheliste linkide olemasolu tõttu kompositsioonilineühendused.

Kui infomudelites on pärilikkus olemas, siis on olemas alatüübid ja supertüübid.

Supertüüp on lähteobjekt.

Alamtüüp on tuletatud objekt.

ER diagrammid

Loogiline mudel

levinud viis esindus loogiline mudel Andmebaas on ER-diagrammide (Entity-Relationship - entity-relationship) konstruktsioon. Selles mudelis määratletakse olem kui diskreetne olem, mille jaoks salvestatakse andmeelemendid, ja seos kirjeldab kahe olemi vahelist suhet.

Reisibüroojuhi näites on 5 peamist objekti:

Turistid

Vautšerid

Nende üksuste vahelist suhet saab määratleda lihtsate sõnadega:

Iga turist saab osta ühe või mitu (mitu) vautšerit.

Iga vautšer vastab tema maksele (võib olla mitu makset, kui vautšer näiteks müüakse laenuga).

Igal tuuril võib olla mitu hooaega.

Voucherit müüakse ühe tuuri üheks hooajaks.

Neid objekte ja suhteid saab kujutada ER diagramm, nagu on näidatud joonisel 2.

Joonis 3.2. ER diagramm reisibüroo DB rakenduse jaoks

Mudelit arendatakse edasi, määratledes iga objekti jaoks atribuudid. Objekti atribuudid on konkreetse objektiga seotud andmeelemendid, mis tuleb salvestada. Analüüsime koostatud andmesõnastikku, valime selles olevad objektid ja nende atribuudid ning vajadusel laiendame sõnastikku. Selle näite iga objekti atribuudid on esitatud tabelis 2.

Tabel 3.2. Andmebaasi objektid ja atribuudid

Pange tähele, et mitu elementi on puudu. Väljas mainitud registreerimisteave funktsionaalne spetsifikatsioon. Kuidas seda arvesse võtta, mõtlete ise ja viimistlete pakutud näite. Kuid mis veelgi olulisem, atribuudid, mis on vajalikud objektide omavaheliseks sidumiseks, on endiselt puudu. Need andmeelemendid ei ole ER mudelis esindatud, kuna need ei ole tegelikult objektide "loomulikud" atribuudid. Neid käsitletakse erinevalt ja neid võetakse arvesse relatsiooniandmete mudelis.

relatsiooniline mudel mida iseloomustab võtmete ja suhete kasutamine. Kontekstis on erinevus suhteline alus andmeterminid seos (suhe) ja seos (andmeskeem). Seost käsitletakse kui järjestamata kahemõõtmelist tabelit, millel on mitteseotud read. Andmeskeem moodustatakse suhete (tabelite) vahel ühiste atribuutide kaudu, milleks on võtmed.

Võtmeid on mitut tüüpi ja need erinevad mõnikord ainult oma seose poolest teiste atribuutide ja suhetega. Esmane võti identifitseerib unikaalselt rea relatsioonis (tabelis) ja igal seosel võib olla ainult üks primaarvõti, isegi kui kordumatud on rohkem kui üks atribuut. Mõnel juhul on relatsiooni ridade tuvastamiseks vaja rohkem kui ühte atribuuti. Nende atribuutide kombinatsiooni nimetatakse liitvõtmeks. Muudel juhtudel tuleb primaarvõti spetsiaalselt luua (genereerida). Näiteks relatsioonis “Turistid” on mõttekas lisada selle seose esmaseks võtmeks unikaalne turistitunnus (turistikood), et korraldada seoseid teiste andmebaasisuhetega.

Teist tüüpi võti, mida nimetatakse võõrvõtmeks, eksisteerib ainult kahe seose vahelise andmeskeemi osas. Väline võti relatsioonis on atribuut, mis on primaarvõti (või osa primaarvõtmest) teises relatsioonis. See on hajutatud atribuut, mis moodustab andmeskeemi kahe andmebaasi seose vahel.

Projekteeritava andmebaasi jaoks laiendame objektide atribuute koodiväljadega as esmased võtmed ja kasutage neid koode DB seostes DB objektidele viitamiseks järgmiselt (tabel 3).

Konstrueeritud andmebaasi skeemi lõpetatuks lugeda on liiga vara, kuna selle normaliseerimine on vajalik. Atribuutide rühmitamiseks kasutatakse protsessi, mida nimetatakse relatsioonilise andmebaasi normaliseerimiseks erilistel viisidel liiasuse ja funktsionaalse sõltuvuse minimeerimiseks.

Tabel 3.3. Laiendatud koodiväljadega andmebaasi objektid ja atribuudid

2.1.2. Objekti atribuudid

Atribuut on väärtus, mis iseloomustab objekti selle klassis. Näited atribuutidest: kategooria, saldo, krediit (kontoklassi objektide atribuudid); nimi, vanus, kaal (isikuklassi esemete atribuudid) jne.

Atribuudid erinevad püsivad atribuudid(pidev) ja muutuvad atribuudid. Konstantsed atribuudid iseloomustavad objekti selle klassis (näiteks kontonumber, kategooria, isiku nimi jne). Muutuvate atribuutide praegused väärtused iseloomustavad voolu olek objekt (näiteks kontojääk, isiku vanus vms); nende atribuutide väärtusi muutes muudame objekti olekut.

Atribuudid on loetletud klassi tähistava ristküliku teises osas (vt joonis 2.1). Mõnikord määratakse atribuutide tüüp (lõppude lõpuks on iga atribuut teatud väärtus) ja muutujaatribuutide algväärtus (nende atribuutide algväärtuste komplekt määrab objekti algoleku).

Tuleb märkida, et kui me räägime objektidest ja nende klassidest, ei pea me silmas ühtegi objektorienteeritud programmeerimiskeelt. See väljendub eelkõige selles, et see etapp Tarkvarasüsteemi arendamisel tuleks arvesse võtta ainult tegelikkuses mõttekaid atribuute (seda omadust omavad kõik kontoklassi objektide atribuudid - joonis 2.1). Atribuudid on seotud funktsioonidega ühine rakendamine. Näiteks kui on teada, et kasutatakse andmebaasi, milles igal objektil on kordumatu identifikaator, siis ei tohiks seda identifikaatorit selles etapis objekti atribuutide hulka lisada. Fakt on see, et selliste atribuutide kasutuselevõtuga piirame süsteemi juurutamise võimalusi. Seega, lisades atribuudina andmebaasis oleva objekti kordumatu identifikaatori, keeldume juba disaini alguses kasutamast DBMS-i, mis sellist identifikaatorit ei toeta.