Oliopohjaiset teknologiat sovellusohjelmistojärjestelmien suunnitteluun. Liiketoimintaobjektin attribuutit

ER-kaaviot

Looginen malli

Yleisellä tavalla edustus looginen malli DB on ER-kaavioiden (Entity-Relationship - entity-relationship) rakentaminen. Tässä mallissa entiteetti määritellään erilliseksi objektiksi, jolle tietoelementit on tallennettu, ja suhde kuvaa kahden objektin välistä suhdetta.

Matkatoimistojohtajan esimerkissä on 5 pääkohdetta:

Turistit

Kupongit

Näiden objektien väliset suhteet voidaan määritellä yksinkertaisin termein:

Jokainen turisti voi ostaa yhden tai useita (useita) kuponkeja.

Jokainen kuponki vastaa maksuaan (maksuja voi olla useita, jos seteli esimerkiksi myydään luotolla).

Jokaisella kiertueella voi olla useita vuodenaikoja.

Lippu myydään yhden kiertueen kaudelle.

Nämä esineet ja suhteet voidaan esittää ER-kaavio, kuten kuvassa 2 näkyy.

Kuva 3.2. ER-kaavio matkatoimiston johtajan tietokantasovellukselle

Mallia kehitetään edelleen määrittelemällä kullekin objektille attribuutit. Objektiattribuutit ovat tiettyyn objektiin liittyviä tietoelementtejä, jotka on säilytettävä. Analysoimme laaditun tietosanakirjan, valitsemme siitä objektit ja niiden attribuutit sekä laajennamme sanakirjaa tarvittaessa. Kunkin esimerkin kohteen attribuutit on esitetty taulukossa 2.

Taulukko 3.2. Tietokantaobjektit ja -attribuutit

Huomaa, että useita kohteita puuttuu. Toiminnallisessa eritelmässä mainitut rekisteröintitiedot on jätetty pois. Kuinka ottaa se huomioon, ajattelet itse ja viimeistelet ehdotetun esimerkin. Mutta mikä vielä tärkeämpää, attribuutit, joita tarvitaan objektien yhdistämiseen toisiinsa, puuttuvat edelleen. Näitä tietoelementtejä ei esitetä ER-mallissa, koska ne eivät itse asiassa ole objektien "luonnollisia" attribuutteja. Niitä käsitellään eri tavalla ja ne otetaan huomioon relaatiomalli tiedot.

Relaatiomallille on ominaista avainten ja suhteiden käyttö. Kontekstissa on eroa suhteellinen perusta nämä termit relaatio (relaatio) ja suhde (tietoskeema). Relaatiota käsitellään järjestämättömänä, kaksiulotteisena taulukkona, jossa on toisiinsa liittymättömiä rivejä. Tietoskeema muodostetaan suhteiden (taulukoiden) välille yhteisten attribuuttien avulla, jotka ovat avaimia.

Avaimia on useita tyyppejä, ja joskus ne eroavat toisistaan ​​vain suhteessaan muihin attribuutteihin ja suhteisiin. Ensisijainen avain identifioi yksilöllisesti relaatiossa (taulukossa) olevan rivin, ja jokaisella suhteella voi olla vain yksi ensisijainen avain, vaikka useampi kuin yksi attribuutti olisi yksilöllinen. Joissakin tapauksissa tarvitaan useampi kuin yksi attribuutti suhteiden rivien tunnistamiseen. Näiden määritteiden kokoelmaa kutsutaan yhdistelmäavaimeksi. Muissa tapauksissa ensisijainen avain on luotava (luotettava) erityisesti. Esimerkiksi "Turistit" -suhteessa on järkevää lisätä yksilöllinen turistitunnus (turistikoodi) lomakkeeseen pääavain tämä suhde järjestää yhteyksiä muihin tietokantasuhteisiin.

Toinen avaintyyppi, jota kutsutaan vieraaksi avaimeksi, on olemassa vain kahden suhteen välisen dataskeeman kannalta. Ulkoinen avain relaatiossa on attribuutti, joka on ensisijainen avain (tai osa ensisijaista avainta) toisessa suhteessa. Se on hajautettu attribuutti, joka muodostaa tietoskeeman kahden tietokannan suhteen välille.

Suunnitellussa tietokannassa laajennamme koodikenttiä sisältävien objektien attribuutteja ensisijaisina avaimina ja käytämme näitä koodeja tietokantasuhteissa viittaamaan tietokantaobjekteihin seuraavasti (taulukko 3).

On liian aikaista pitää rakennettua tietokantaskeemaa valmiina, koska sen normalisointia tarvitaan. Attribuuttien ryhmittelyyn käytetään prosessia, joka tunnetaan nimellä relaatiotietokannan normalisointi erityisillä tavoilla redundanssin ja toiminnallisen riippuvuuden minimoimiseksi.

Taulukko 3.3. DB-objektit ja -attribuutit laajennetuilla koodikentillä

ER-kaavioita

Yleinen tapa esittää loogista tietokantamallia on rakentaa ER (Entity-Relationship) -kaavioita. Tässä mallissa entiteetti määritellään erilliseksi objektiksi, jolle tietoelementit on tallennettu, ja suhde kuvaa kahden objektin välistä suhdetta.

Matkatoimistojohtajan esimerkissä on 5 pääkohdetta:

Turistit

Kupongit

Näiden objektien väliset suhteet voidaan määritellä yksinkertaisin termein:

Jokainen turisti voi ostaa yhden tai useita (useita) kuponkeja.

Jokainen kuponki vastaa maksuaan (maksuja voi olla useita, jos seteli esimerkiksi myydään luotolla).

Jokaisella kiertueella voi olla useita vuodenaikoja.

Lippu myydään yhden kiertueen kaudelle.

Nämä objektit ja suhteet voidaan esittää ER-kaaviolla, kuten kuvassa 2 on esitetty.

Riisi. 2. ER-kaavio matkatoimistopäällikön tietokantasovellukselle

Objektit, attribuutit ja avaimet

Mallia kehitetään edelleen määrittelemällä kullekin objektille attribuutit. Objektiattribuutit ovat tiettyyn objektiin liittyviä tietoelementtejä, jotka on säilytettävä. Analysoimme laaditun tietosanakirjan, valitsemme siitä objektit ja niiden attribuutit sekä laajennamme sanakirjaa tarvittaessa. Kunkin esimerkin kohteen attribuutit on esitetty taulukossa 2.

Taulukko 2. Tietokantaobjektit ja -attribuutit

Huomaa, että useita kohteita puuttuu. Toiminnallisessa eritelmässä mainitut rekisteröintitiedot on jätetty pois. Kuinka ottaa se huomioon, ajattelet itse ja viimeistelet ehdotetun esimerkin. Mutta mikä vielä tärkeämpää, attribuutit, joita tarvitaan objektien yhdistämiseen toisiinsa, puuttuvat edelleen. Näitä tietoelementtejä ei esitetä ER-mallissa, koska ne eivät itse asiassa ole objektien "luonnollisia" attribuutteja. Niitä käsitellään eri tavalla ja ne otetaan huomioon relaatiotietomallissa.

Relaatiomallille on ominaista avainten ja suhteiden käyttö. Relaatiotietokannan kontekstissa termien relaatio ja suhde välillä on ero. Relaatiota käsitellään järjestämättömänä, kaksiulotteisena taulukkona, jossa on toisiinsa liittymättömiä rivejä. Tietoskeema muodostetaan suhteiden (taulukoiden) välille yhteisten attribuuttien avulla, jotka ovat avaimia.

Avaimia on useita tyyppejä, ja joskus ne eroavat toisistaan ​​vain suhteessaan muihin attribuutteihin ja suhteisiin. Ensisijainen avain identifioi yksilöllisesti relaatiossa (taulukossa) olevan rivin, ja jokaisella suhteella voi olla vain yksi ensisijainen avain, vaikka useampi kuin yksi attribuutti olisi yksilöllinen. Joissakin tapauksissa tarvitaan useampi kuin yksi attribuutti identifioidakseen suhteen rivejä. Näiden attribuuttien kokoelmaa kutsutaan yhdistelmäavaimeksi. Muissa tapauksissa ensisijainen avain on luotava (luotettava) erityisesti. Esimerkiksi "Turistit"-relaatiossa on järkevää lisätä yksilöllinen turistitunnus (turistikoodi) tämän suhteen ensisijaiseksi avaimeksi yhteyksien järjestämiseksi muihin tietokantasuhteisiin.

Toinen avaintyyppi, jota kutsutaan vieraaksi avaimeksi, on olemassa vain kahden suhteen välisen dataskeeman kannalta. Vieras avain relaatiossa on attribuutti, joka on ensisijainen avain (tai osa ensisijaista avainta) toisessa suhteessa. Se on hajautettu attribuutti, joka muodostaa tietoskeeman kahden tietokannan suhteen välille.

Suunnitellun tietokannan osalta laajennamme koodikenttiä sisältävien objektien attribuutteja ensisijaisina avaimina ja käytämme näitä koodeja tietokantasuhteissa viittaamaan tietokantaobjekteihin seuraavasti (taulukko 3).

On liian aikaista pitää rakennettua tietokantaskeemaa valmiina, koska sen normalisointia tarvitaan. Relaatiotietokannan normalisointina tunnettua prosessia käytetään attribuuttien ryhmittelyyn erityisillä tavoilla redundanssin ja toiminnallisen riippuvuuden minimoimiseksi.

Taulukko 3. DB-objektit ja -attribuutit laajennetuilla koodikentillä

Normalisointi

Toiminnallisia riippuvuuksia esiintyy, kun yhden attribuutin arvo voidaan määrittää toisen attribuutin arvosta. Määritettävissä olevan attribuutin sanotaan olevan toiminnallisesti riippuvainen määritteestä, joka on determinantti. Siksi määritelmän mukaan kaikki ei-avaimet (ilman avainta) määritteet riippuvat toiminnallisesti ensisijaisesta avaimesta kaikissa suhteissa (koska ensisijainen avain yksilöi jokaisen rivin yksilöllisesti). Kun suhteen yksi attribuutti ei määritä yksiselitteisesti toista attribuuttia, vaan rajoittaa sen ennalta määritettyjen arvojen joukkoon, sitä kutsutaan moniarvoiseksi riippuvuudeksi. Osittainen riippuvuus syntyy, kun relaatioattribuutti on toiminnallisesti riippuvainen yhdestä yhdistelmäavaimen attribuutista. Transitiivisia riippuvuuksia esiintyy, kun ei-avainattribuutti on toiminnallisesti riippuvainen yhdestä tai useammasta suhteen ei-avainattribuutista.

Normalisointiprosessi koostuu tietokannan vaiheittaisesta rakentamisesta normaali muoto(NF).

1. Ensimmäinen normaalimuoto (1NF) on hyvin yksinkertainen. Kaikkien tietokantataulukoiden on täytettävä yksi vaatimus - taulukoiden jokaisen solun tulee sisältää atomiarvo, toisin sanoen tietokantasovelluksen toimialueen sisällä tallennetulla arvolla ei saa olla sisäistä rakennetta, jonka elementtejä voi vaatia sovellus.

2. Toinen normaalimuoto (2NF) luodaan, kun kaikki osittaiset riippuvuudet poistetaan tietokantasuhteista. Jos suhteessa ei ole yhdistelmäavaimia, tämä normalisointitaso saavutetaan helposti.

3. Tietokannan kolmas normaalimuoto (3NF) edellyttää kaikkien transitiivisten riippuvuuksien poistamista.

4. Neljäs normaalimuoto (4NF) luodaan, kun kaikki moniarvoiset riippuvuudet poistetaan.

Esimerkkimme tietokanta on 1NF-muodossa, koska tietokantataulukoiden kaikki kentät ovat sisällöltään atomisia. Tietokantamme on myös 2NF-muodossa, koska lisäsimme jokaiseen taulukkoon keinotekoisesti ainutlaatuisia koodeja jokaiselle kohteelle (turistikoodi, matkakoodi jne.), minkä ansiosta saavutimme 2NF jokaiselle tietokantataulukolle ja koko tietokannalle kokonaisuutena. On vielä käsiteltävä kolmatta ja neljättä normaalimuotoa.

Huomaa, että ne ovat olemassa vain suhteellisesti erilaisia ​​tyyppejä tietokantamääritteiden riippuvuudet. On riippuvuuksia - sinun täytyy maksaa NF-tietokannasta, ei ole riippuvuuksia - tietokanta on jo NF:ssä. Mutta viimeinen vaihtoehto ei käytännössä koskaan esiinny todellisissa sovelluksissa.

Joten mitä transitiivisia ja moniarvoisia riippuvuuksia esiintyy esimerkissämme matkatoimiston johtajan tietokannasta?

Analysoidaanpa "turistien" asennetta. Tarkastellaanpa attribuuttien ”Turistitunnus”, ”Sukunimi”, ”Etunimi”, ”Isännimi” ja ”Passi” välisiä riippuvuuksia (kuva 3). Jokaisella turistilla, jota edustaa suhteessa yhdistelmä "Sukunimi - Etunimi - Isänimi", on vain yksi passi matkan ajaksi, kun taas täydellä kaimalla on oltava eri passinumerot. Siksi attribuutit "Sukunimi - Etunimi - Isännimi" ja "Passi" muodostavat yhdistelmäavaimen turisteille.

Riisi. 3. Esimerkki transitiivisesta riippuvuudesta

Kuten kuvasta näkyy, "Passi"-attribuutti riippuu transitiivisesti "Turistin koodi"-avaimesta. Siksi tämän transitiivisen riippuvuuden eliminoimiseksi jaamme suhteen yhdistelmäavaimen ja itse suhteen 2:ksi yksi-yhteen-suhteiden mukaan. Ensimmäinen relaatio, jätetään se nimellä "Turistit", sisältää attribuutit "Turistikoodi" ja "Sukunimi", "Etunimi", "Isännimi". Toinen suhde, jota kutsutaan nimellä "Tiedot turisteista", muodostuu attribuuteista "Turistikoodi" ja kaikista muista "Turistit"-relaation määritteistä: "Passi", "Puhelin", "Kaupunki", "Maa", "Indeksi". Näillä kahdella uudella suhteella ei ole enää transitiivista riippuvuutta ja ne ovat 3NF:ssä.

Yksinkertaistetussa tietokannassamme ei ole moniarvoisia riippuvuuksia. Oletetaan esimerkiksi, että jokaista turistia kohden useita yhteystiedot(koti, työ, matkapuhelin jne., mikä on hyvin tyypillistä käytännössä), eikä yksi, kuten esimerkissä. Saamme moniarvoisen riippuvuuden avaimesta - "Turistikoodi" ja attribuutit "Puhelintyyppi" ja "Puhelin" tässä tilanteessa avain lakkaa olemasta avain. Mitä tehdä? Ongelma ratkaistaan ​​myös jakamalla relaatioskeema kahdeksi uudeksi skeemaksi. Yhden niistä tulee edustaa tietoja puhelimista ("Puhelimet" -suhde) ja toisen turisteista ("Turistit" -suhde), joihin otetaan yhteyttä "Turistikoodi"-kentän avulla. "Turistikoodi" suhteessa "Turisteihin" on ensisijainen avain ja "Puhelin" suhteen se on ulkoinen avain.

Liiketoimintaobjektin attribuutit sisältävät liiketoimintaobjekteihin liittyviä tietoja. Tallennettu attribuutti edustaa tietokantataulukon saraketta tai tietokantanäkymän saraketta. Ei-pysyvän attribuutin arvo on olemassa vain muistissa, koska attribuuttiin liittyviä tietoja ei ole tallennettu tietokantaan.

Tallennetulla liiketoimintaobjektilla voi olla sekä tallennettuja että tallentamattomia määritteitä. Liiketoimintaobjektin tallennetut attribuutit liitetään tietokantataulukon tai -näkymän sarakkeisiin. Kaikki ei-pysyvien liiketoimintaobjektien attribuutit ovat ei-pysyviä määritteitä.

Perustietotyyppitietojen lisäksi tuote tallentaa liiketoimintaobjektin attribuutteihin liittyviä metatietoja. Attribuutilla voi esimerkiksi olla verkkotunnus, mukautettu luokka tai oletusarvo; voit määrittää, että attribuutti on pakollinen attribuutti.

Ominaisuusrajoitukset

Ennen kuin muutat määritettä, voit tarkistaa, onko sen luonut järjestelmä vai joku sivustollasi. Järjestelmän luomilla määritteillä on enemmän rajoituksia muutoksille kuin käyttäjän luomilla määritteillä. Järjestelmän luomaa attribuuttia ei voi poistaa.

Integrointiskenaarioissa liiketoimintaobjektin tiedot voidaan saada ulkoisista liiketoimintaohjelmista. Attribuuttien muutosten rajoittamista voidaan käyttää estämään ulkoisia tietoja korvaamasta määritteen arvoa.

Jotkut rajoitukset riippuvat siitä, onko tekstihaku objekti tai hae tietotyypin mukaan. Muutoksia säätelevät säännöt riippuvat määritteestä. Esimerkiksi joillakin tietotyypeillä on aseta arvo pituuden, mittakaavan, päivämäärien tai kokonaislukujen mukaan. Huomautus-kentän tiedot ovat normaaleja ALN-tietoja, eikä tämä kenttä sisällä rajoitettuja arvoja.

Voit hallita määriterajoituksia seuraavasti:

• Näytä nykyisen objektin attribuuttien rajoitukset
• Rajoita objektin attribuutteja
• Poista objektin attribuuttien rajoitukset

2.1.2. Objektin attribuutit

Attribuutti on arvo, joka kuvaa luokkansa objektia. Esimerkkejä attribuuteista: luokka, saldo, luotto (tililuokan objektien attribuutit); nimi, ikä, paino (henkilöluokan esineiden ominaisuudet) jne.

Ominaisuudet vaihtelevat pysyviä ominaisuuksia(vakiot) ja muuttuvat attribuutit. Vakioattribuutit kuvaavat kohdetta sen luokassa (esim. tilinumero, luokka, henkilön nimi jne.). Attribuuttimuuttujien nykyiset arvot kuvaavat nykyistä osavaltio esine (esimerkiksi tilin saldo, henkilön ikä jne.); Muuttamalla näiden attribuuttien arvoja muutamme kohteen tilaa.

Attribuutit on lueteltu luokkaa edustavan suorakulmion toisessa osassa (katso kuva 2.1). Joskus ilmoitetaan attribuuttien tyyppi (jokainen attribuutti on tietty arvo) ja muuttujan attribuuttien alkuarvo (joukko alkuarvot nämä attribuutit määritetään objektin alkutilan mukaan).

On huomattava, että kun puhumme objekteista ja niiden luokista, emme tarkoita mitään olio-ohjelmointikieltä. Tämä näkyy erityisesti siinä, että tässä vaiheessa Ohjelmistojärjestelmää kehitettäessä tulee ottaa huomioon vain ne attribuutit, joilla on todellisuudessa järkeä (kaikilla tililuokan objektien attribuutilla - kuva 2.1 - on tämä ominaisuus). Attribuutit liittyvät ominaisuuksiin yleinen toteutus. Jos esimerkiksi tiedät, että käytät tietokantaa, jossa jokaisella objektilla on yksilöllinen tunniste, sinun ei pitäisi tässä vaiheessa sisällyttää tätä tunnistetta objektin attribuutteihin. Tosiasia on, että ottamalla käyttöön tällaisia ​​attribuutteja rajoitamme järjestelmän toteuttamismahdollisuuksia. Siten ottamalla käyttöön tietokannassa olevan objektin yksilöllisen tunnisteen attribuuttina, kieltäydymme suunnittelun alussa käyttämästä DBMS-järjestelmiä, jotka eivät tue tällaista tunnistetta.