Tietokannan suunnittelun vaiheet. Tietokannan luominen. Suunnittelun vaiheet

Luento 8. Tietokannan suunnittelun vaiheet

Tietokantaa on mahdotonta luoda ilman sen yksityiskohtaista kuvausta, kuten ei ole mahdollista tehdä mitään monimutkaista tuotetta ilman piirustusta ja yksityiskohtaista kuvausta sen valmistustekniikoista. Toisin sanoen tarvitsemme projektin. Projekti On yleisesti hyväksyttyä harkita jonkin laitteen luonnosta, joka muutetaan myöhemmin todellisuudeksi.

Tietokannan suunnitteluprosessi on prosessi, jossa siirrytään aihealueen tietorakenteen epävirallisesta sanallisesta kuvauksesta aihealueen esineiden formalisoituun kuvaukseen tietyn mallin mukaisesti. Suunnittelun perimmäinen tavoite on rakentaa tietty tietokanta. Ilmeisesti suunnitteluprosessi on monimutkainen ja siksi on järkevää jakaa se loogisesti suoritettuihin osiin - vaiheisiin.

Tietokannan suunnittelussa on viisi päävaihetta:

1. Tiedonkeruu ja aihealueen järjestelmäanalyysi.

2. Infologinen suunnittelu.

3. DBMS:n valitseminen.

4. Dataloginen suunnittelu.

5. Fyysinen suunnittelu.

Tiedonkeruu ja aihealueen järjestelmäanalyysi - Tämä on ensimmäinen ja tärkein vaihe tietokannan suunnittelussa. On tarpeen suorittaa yksityiskohtainen sanallinen kuvaus aihealueen kohteista ja todellisten esineiden välisistä todellisista yhteyksistä. On toivottavaa, että kuvaus määrittelee aihealueen objektien väliset suhteet.

Yleisesti ottaen aihealueen koostumuksen ja rakenteen valitsemiseen on kaksi tapaa:

· Toiminnallinen lähestymistapa – käytetään, kun tietyn henkilöryhmän tehtävät ja tehtäväryhmät, joita varten tämä tietokanta luodaan, ovat tiedossa etukäteen, ts. kuvausta varten vaadittava vähimmäismäärä verkkoalueobjekteja on selkeästi tunnistettu.

· Aiheen lähestymistapa – kun tietokanta-asiakkaiden tietotarpeita ei ole selkeästi kirjattu ja ne voivat olla moniulotteisia ja dynaamisia. Tässä tapauksessa on vaikeaa valita vähimmäismäärä verkkoalueobjekteja. Aihealueen kuvaus sisältää sellaisia esineitä ja suhteita, jotka ovat sille tyypillisimpiä ja oleellisimpia. Samalla tietokanta muuttuu aihekohtaiseksi ja soveltuu monien ongelmien ratkaisemiseen (mikä tuntuu houkuttelevimmalta). Aihealueen kattavan kattavuuden vaikeus ja käyttäjien tarpeiden määrittelemisen mahdottomuus johtaa kuitenkin liian monimutkaiseen tietokantasuunnitteluun, joka on tehoton joissakin tehtävissä.

Järjestelmäanalyysin tulisi päättyä yksityiskohtaiseen kuvaukseen tietokantaan tallennettavista aihealueen objekteista, tämän tietokannan avulla ratkaistavien tehtävien muotoilusta sekä lyhyt kuvaus niiden ratkaisemiseen liittyvistä algoritmeista ja kuvaus tulos- ja syöttöasiakirjoista tietokannan kanssa työskennellessä.

Infologinen suunnittelu – osittain formalisoitu kuvaus aihealueen objekteista tietyllä semanttisella mallilla.

Miksi tietomallia tarvitaan ja mitä hyötyä siitä on suunnittelijoille? Tosiasia on, että suunnitteluprosessi on pitkä ja vaatii keskustelua asiakkaan ja aiheen asiantuntijoiden kanssa. Lisäksi vakavia yritystietojärjestelmiä kehitettäessä tietokantaprojekti on perusta, jolle koko järjestelmä rakentuu, ja lainanantomahdollisuuden ratkaisevat usein pankkien asiantuntijat hyvin tehdyn infologisen tietokantaprojektin perusteella. Näin ollen tietomalliin tulisi sisältyä sellainen formalisoitu kuvaus aihealueesta, joka on helposti tietokantaasiantuntijoidenkin havaittavissa. Kuvauksen tulee olla niin laaja, että tietokantaprojektin kehityksen syvyyttä ja oikeellisuutta voidaan arvioida.

Nykyään eniten käytetty malli on Chenin "Ensity-Relationship" -malli ( Kokonaisuussuhde ), siitä tuli tietomallinnuksen tosiasiallinen standardi, ja sitä kutsuttiin ER – malli.

DBMS:n valitseminen suoritetaan tietokannan erilaisten vaatimusten ja vastaavasti DBMS:n ominaisuuksien perusteella sekä kehittäjien olemassa olevan kokemuksen perusteella.

Dataloginen suunnittelu tietokannasta on kuvaus hyväksytyn dataloogisen tietomallin mukaisesti. Relaatiotietokannoissa dataloginen tai looginen suunnittelu johtaa tietokantaskeeman kehittämiseen, ts. joukko suhdekaavioita, jotka mallintavat riittävästi aihealueen objekteja ja objektien välisiä semanttisia suhteita. Kaavan oikeellisuuden analysoinnin perustana ovat tietokantamääritteiden väliset toiminnalliset riippuvuudet. Joissakin tapauksissa suhdeattribuuttien välillä voi esiintyä ei-toivottuja riippuvuuksia, jotka aiheuttavat sivuvaikutuksia ja poikkeavuuksia tietokannan muokkaamisen yhteydessä. Alla muutos ymmärtää uusien tietojen syöttäminen tietokantaan, tietojen poistaminen tietokannasta sekä joidenkin määritteiden arvojen päivittäminen. Mahdollisten poikkeavuuksien poistamiseksi on tarkoitus normalisoida tietokantasuhteet.

Looginen suunnitteluvaihe ei ole vain suhdekaavion suunnittelua. Tämän vaiheen tuloksena on pääsääntöisesti hankittava seuraavat tuloksena olevat asiakirjat:

· Tietokannan käsitteellisen skeeman kuvaus valitun DBMS:n kannalta.

· Kuvaus ulkoisista malleista valitun DBMS:n mukaan.

· Kuvaus deklaratiivisista säännöistä tietokannan eheyden ylläpitämiseksi.

· Menettelyjen kehittäminen tietokannan semanttisen eheyden ylläpitämiseksi.

Fyysinen suunnittelu koostuu tietokannan loogisen rakenteen ja fyysisen tallennusympäristön yhdistämisestä datan sijoittamiseksi tehokkaimmin, ts. kartoitetaan tietokannan looginen rakenne tallennusrakenteeseen. Kysymys tallennettujen tietojen sijoittamisesta muistitilaan, tehokkaiden menetelmien valitsemiseen "fyysisen" tietokannan eri osien käyttämiseen on ratkaistu, ongelmia ratkaistaanvarmistaa tietojen turvallisuus.Loogisessa tietomallissa olevat rajoitukset on toteutettu erilaisilla DBMS-työkaluilla, esimerkiksi indekseillä, deklaratiivisilla eheysrajoitteilla, triggereillä ja tallennettuilla proseduureilla. Tässäkin tapauksessa loogisen mallinnuksen tasolla tehdyt päätökset määrittelevät joitain rajoja, joiden sisällä fyysistä tietomallia voidaan kehittää. Samoin näiden rajojen sisällä voidaan tehdä erilaisia päätöksiä. Esimerkiksi loogisen tietomallin sisältämät suhteet on muunnettava taulukoiksi, mutta jokaiseen taulukkoon voidaan valinnaisesti ilmoittaa erilaisia indeksejä tietojen käsittelyn nopeuttamiseksi.

sitä paitsi , Rinvoidaan käyttää suorituskyvyn parantamiseen. Tämän seurauksena tietokanta voi sijaita useilla verkon tietokoneilla. Toisaalta moniprosessorijärjestelmien etuja voidaan hyödyntää.

Tietojen turvallisuuden ja turvallisuuden takaamiseksi ratkaistaan vikojen jälkeisiä palautuksia, tietojen varmuuskopiointia, suojausjärjestelmien asettamista valitun suojauspolitiikan mukaisiksi jne..

On huomattava, että jotkin nykyaikaiset relaatiotietokantajärjestelmät käyttävät pääasiassa fyysisiä rakenteita ja pääsymenetelmiä, jotka perustuvat tiedostosuunnittelutekniikkaan, mikä eliminoi olennaisesti fyysisen suunnittelun ongelman.

Näin ollen on selvää, että mallinnuksen ja tietokannan kehittämisen jokaisessa vaiheessa tehdyt päätökset vaikuttavat seuraaviin vaiheisiin. Siksi oikeiden päätösten tekemisellä on erityinen rooli mallintamisen alkuvaiheessa.

Kontrollikysymykset

1. Mikä on projekti?

2. Mitkä tietokannan suunnittelun vaiheet yleensä erotetaan?

3. Mikä on järjestelmäanalyysin tarkoitus?

4. Mitä lähestymistapoja voidaan käyttää aihealueen järjestelmäanalyysissä?

5. Mikä on tiedon suunnitteluvaihe?

6. Mitä eroa on suunnittelun infologisella ja datalogisella vaiheella?

7. Mitä asiakirjoja ja malleja tulee hankkia, kun datatieteen suunnitteluvaihetta suoritetaan?

8. Kerro fyysisen suunnittelun tulokset.

Tehtävät itsenäiseen työhön

Lue malliverkkotunnuksen kuvaus huolellisesti ja määritä, mitkä pääkohdat on määritelty kuvauksessa ja mitkä eivät. Tehdä johtopäätös.

Esimerkki "Kirjasto"-projektin aihealueen kuvauksesta

Oletetaan, että sinun on kehitettävä tietojärjestelmä, joka automatisoi kirjojen vastaanottamisen ja luovuttamisen kirjanpidon kirjastossa. Järjestelmän on tarjottava tilat järjestelmäluettelon ylläpitämiseksi, joka kuvastaa luetteloa tietoalueista, joille kirjastossa on kirjoja. Kirjaston sisällä systemaattisen luettelon tietoalueilla voi olla yksilöllinen sisäinen numero ja koko nimi. Jokainen kirja voi sisältää tietoa useilta tietoalueilta. Jokainen kirjaston kirja voi olla useana kappaleena. Jokaiselle kirjastoon tallennetulle kirjalle on ominaista seuraavat parametrit:

· ainutlaatuinen salaus;

· Nimi;

· julkaisupaikka (kaupunki);

· kustantamo;

· julkaisuvuosi;

· sivujen määrä;

· kirjan hinta;

· kirjan kappalemäärä kirjastossa.

Kirjoilla voi olla sama nimi, mutta ne eroavat ainutlaatuisesta ISBN-numerostaan.

Kirjasto ylläpitää lukijakorttia.

Seuraavat tiedot syötetään kunkin lukijan korttihakemistoon:

· Koko nimi;

· kotiosoite;

· Syntymäaika.

Jokaiselle lukijalle annetaan yksilöllinen kirjastokorttinumero. Yhdelle lukijalle mahtuu kerrallaan enintään 5 kirjaa. Lukijalla ei saa olla hallussaan enempää kuin yksi kopio samannimisestä kirjasta kerrallaan.

Jokainen kirjaston kirja voi olla useana kappaleena. Jokaisella esiintymällä on seuraavat ominaisuudet:

· ainutlaatuinen varastonumero;

· kirjan salaus, joka vastaa kirjan kuvauksen ainutlaatuista salausta;

· sijainti kirjastossa.

Jos lukijalle annetaan kopio kirjasta, kirjasto säilyttää erityisliitteen, johon on merkittävä seuraavat tiedot:

· kirjan ottaneen lukijan lipun numero;

· kirjan julkaisupäivämäärä;

· palautuspäivä.

Anna seuraavat rajoitukset järjestelmän tiedoille:

2. Kirjastossa tulee olla vähintään 17-vuotiaita rekisteröityneitä lukijoita.

3. Kirjasto sisältää kirjoja, jotka on julkaistu vuodesta 1960 kuluvaan vuoteen.

4. Kuhunkin lukijaan mahtuu enintään 5 kirjaa.

5. Kirjastoon ilmoittautuessaan jokaisen lukijan tulee antaa puhelinnumero yhteydenpitoa varten: se voi olla työ tai koti.

6. Jokainen tietoalue voi sisältää viittauksia moniin kirjoihin, mutta jokainen kirja voi liittyä eri tietoalueisiin.

Seuraavien käyttäjäryhmien tulee työskennellä tämän tietojärjestelmän kanssa:

· kirjastonhoitajat;

· lukijat;

· kirjaston hallinto,

Järjestelmän kanssa työskennellessään kirjastonhoitajan tulee pystyä ratkaisemaan seuraavat tehtävät:

1. Ota vastaan uusia kirjoja ja rekisteröi ne kirjastoon.

2. Ottaa kirjat yhteen tai useampaan tietoalueeseen.

3. Luettelokirjat, eli anna uusille kirjoille uudet inventaarionumerot ja kirjaston hyllyille sijoittamalla muista jokaisen kappaleen sijainti.

4. Suorita lisäluettelointi, jos kirjastossa jo olevasta kirjasta on vastaanotettu useita kopioita, mutta kirjaa koskevia tietoja ei ole kirjattu aiheluetteloon ja jokaiselle uudelle kopiolle on annettu uusi liitenumero ja paikka kirjaston hylly on määritetty sille.

5. Kirjoita pois vanhat ja tarpeettomat kirjat. Vain kirjoja saa kopioida, jos lukijalla ei ole niistä ainuttakaan kopiota. Poistot tehdään erityisen poistolain mukaisesti, jonka kirjaston hallinto hyväksyy.

6. Pidä kirjaa lukijoille luovutetuista kirjoista, tässä tapauksessa oletetaan kahta toimintatapaa: kirjojen myöntäminen lukijalle ja häneltä palautettujen kirjojen vastaanottaminen takaisin kirjastoon. Kirjoja myönnettäessä kirjataan, milloin ja mikä kappale kirjasta on myönnetty tietylle lukijalle ja mihin mennessä lukijan on palautettava tämä kirjan kappale. Kirjoja liikkeelle laskettaessa ilmaiskappaleen saatavuus ja sen määrä voidaan määrittää annetulla yksilöllisellä kirjakoodilla tai varastonumero voidaan tietää etukäteen. Kirjojen lukemisen "historiaa" ei tarvitse ylläpitää, eli sen on heijastettava vain kirjaston nykytilaa. Lukijan palauttamaa kirjaa vastaanotettaessa tarkistetaan palautetun kirjan varastonumero ja se sijoitetaan vanhalle paikalleen kirjaston hyllylle.

7. Kirjaa pois lukijan kadonneet kirjat kirjaston hallinnon allekirjoittaman erityisen poisto- tai korvausasiakirjan mukaisesti.

8. Sulje lukijan tilaus eli tuhoa häntä koskevat tiedot, jos lukija haluaa kirjautua ulos kirjastosta eikä ole sen velallinen, eli hänellä ei ole yhtään kirjaston kirjaa.

Lukijan pitäisi pystyä ratkaisemaan seuraavat ongelmat:

1. Tarkastele järjestelmäluetteloa, eli luetteloa kaikista tietoalueista, joiden kirjoja kirjastossa on.

2. Hanki täydellinen luettelo kirjastossa olevista kirjoista valitulle tietoalueelle.

3. Hanki valitulle kirjalle ilmaisen kirjan inventaarionumero tai viesti, että kirjasta ei ole ilmaisia kopioita. Jos kirjasta ei ole saatavilla kopioita, lukijan pitäisi pystyä saamaan selville tämän kirjan kopion seuraavan odotetun palautuksen päivämäärä. Lukija ei voi saada tietoa siitä, kenellä on tällä hetkellä tämän kirjan kopioita käsissään (tarvittavan kirjan haltijoiden henkilökohtaisen turvallisuuden varmistamiseksi).

Kirjaston hallinnon tulee saada tietoa kirjaston velallisista lukijoista, jotka eivät palauttaneet lainattuja kirjoja ajoissa; tiedot kirjoista, jotka eivät ole suosittuja, eli ei yhtäkään kappaletta

jotka eivät ole lukijoiden käsissä; tiedot tietyn kirjan kustannuksista, jotta voidaan selvittää mahdollisuus korvata kadonneen kirjan kustannukset tai mahdollisuus korvata se toisella kirjalla; tiedot suosituimmista kirjoista, eli niistä, joiden kaikki kopiot ovat lukijoiden käsissä.

Tämä hyvin pieni esimerkki osoittaa, että ennen kehityksen aloittamista on oltava tarkka käsitys siitä, mitä järjestelmässämme tulisi tehdä, mitkä käyttäjät työskentelevät siinä, mitä tehtäviä kukin käyttäjä ratkaisee. Ja tämä on oikein, koska kun rakennamme rakennusta, oletamme myös etukäteen; mihin tarkoituksiin se on tarkoitettu, missä ilmastossa se seisoo, millä maaperällä, ja tästä riippuen suunnittelijat voivat tarjota meille tämän tai toisen projektin. Mutta valitettavasti hyvin usein tietokantojen suhteen uskotaan, että kaikki voidaan määrittää myöhemmin, kun järjestelmäprojekti on jo luotu. Selkeiden tavoitteiden puuttuminen tietokannan luomiselle voi tehdä tyhjäksi kaikki kehittäjien ponnistelut, ja tietokantaprojekti osoittautuu "huonoksi", hankalaksi eikä vastaa todellisuudessa mallinnettua objektia tai tehtäviä, jotka tulisi ratkaista käyttämällä tämä tietokanta.

Tietokannan suunnittelun, kuten minkä tahansa muun suunnitteluprosessin, ydin on luoda kuvaus uudesta järjestelmästä, jota ei ole aiemmin ollut tässä muodossa ja joka toteutettuaan pystyy odotetusti toimimaan asianmukaisissa olosuhteissa. Tästä seuraa, että tietokannan suunnittelun vaiheiden on johdonmukaisesti ja loogisesti heijastettava tämän prosessin olemusta.

Tietokannan suunnittelun ja vaiheistuksen sisältö

Suunnittelun tarkoitus perustuu johonkin muotoiltuun sosiaaliseen tarpeeseen. Tällä tarpeella on ympäristö sen esiintymiselle ja kuluttajien kohderyhmä, joka käyttää suunnittelutulosta. Näin ollen tietokannan suunnitteluprosessi alkaa tietyn tarpeen tutkimisesta kuluttajien ja sen sijoittelun toiminnallisen ympäristön näkökulmasta. Eli ensimmäinen vaihe on tiedon kerääminen ja mallin määrittely järjestelmän aihealueesta sekä tarkastelu sitä kohdeyleisön näkökulmasta. Yleensä järjestelmävaatimusten määrittämiseksi määritetään toimintojen laajuus sekä tietokantasovellusten rajat.

Seuraavaksi suunnittelija, jolla on jo tiettyjä ideoita siitä, mitä hänen on luotava, selventää sovelluksen oletettavasti ratkaisemia tehtäviä, luo niistä luettelon (varsinkin jos projektikehitys on suuri ja monimutkainen tietokanta), selventää ratkaisujen järjestystä. ongelmia ja suorittaa data-analyysin. Tällainen prosessi on myös lavastettu suunnittelutyö, mutta yleensä suunnittelurakenteessa nämä vaiheet imeytyvät konseptisuunnitteluvaiheeseen - objektien, attribuuttien ja yhteyksien tunnistamisen vaiheeseen.

Konseptuaalisen (tietomallin) luomiseen kuuluu alustavasti käsitteellisten käyttäjävaatimusten muodostaminen, mukaan lukien vaatimukset sovelluksille, jotka eivät välttämättä ole heti toteutettavissa, mutta joiden huomioon ottaminen parantaa järjestelmän toimivuutta tulevaisuudessa. Käsitteellinen malli, joka käsittelee joukko-abstraktioobjektien esityksiä (ilman fyysisiä tallennusmenetelmiä) ja niiden suhteita, vastaa olennaisesti toimialuemallia. Siksi kirjallisuudessa tietokannan suunnittelun ensimmäistä vaihetta kutsutaan infologiseksi suunnitteluksi.

Seuraavaksi erillinen vaihe (tai lisäys edelliseen) seuraa toimintaympäristön vaatimusten muodostusvaihetta, jossa arvioidaan järjestelmän toiminnan varmistamiseen kykenevien laskentaresurssien vaatimuksia. Vastaavasti, mitä suurempi suunnitellun tietokannan volyymi, sitä korkeampi on käyttäjän aktiivisuus ja pyyntöjen intensiteetti, sitä korkeammat resurssit ovat: tietokoneen kokoonpanolle, käyttöjärjestelmän tyypille ja versiolle. Esimerkiksi tulevan tietokannan monen käyttäjän toiminta edellyttää verkkoyhteyttä, jossa käytetään moniajoon soveltuvaa käyttöjärjestelmää.

Seuraava askel on suunnittelijan valita tietokannan hallintajärjestelmä (DBMS) sekä ohjelmistotyökalut. Tämän jälkeen käsitteellinen malli on siirrettävä valitun hallintajärjestelmän kanssa yhteensopivaan tietomalliin. Mutta usein tämä edellyttää muutosten tekemistä käsitteelliseen malliin, koska käsitteelliseen malliin heijastuvia objektien välisiä yhteyksiä ei aina voida toteuttaa tietyn DBMS:n keinoin.

Tämä seikka määrää seuraavan vaiheen syntymisen - tietyn DBMS:n välineillä varustetun käsitteellisen mallin syntymisen. Tämä vaihe vastaa loogisen suunnittelun vaihetta (loogisen mallin luomista).

Lopuksi tietokannan suunnittelun viimeinen vaihe on fyysinen suunnittelu - vaihe, jossa looginen rakenne ja fyysinen tallennusympäristö yhdistetään.

Näin ollen suunnittelun päävaiheet yksityiskohtaisessa muodossa esitetään seuraavissa vaiheissa:

tietosuunnittelu,
toimintaympäristön vaatimusten muodostus
ohjausjärjestelmän ja tietokantaohjelmiston valinta,
looginen suunnittelu,
fyysinen suunnittelu

Keskeisimmistä käsitellään tarkemmin alla.

Infologinen suunnittelu

Entiteettien tunnistaminen muodostaa infologisen suunnittelun semanttisen perustan. Entiteetti on tässä objekti (abstrakti tai konkreettinen), josta tietoa kertyy järjestelmään. Aihealueen infologisessa mallissa aihealueen rakenne ja dynaamiset ominaisuudet on kuvattu käyttäjäystävällisin termein, jotka eivät riipu tietokannan erityisestä toteutuksesta. Mutta termit otetaan vakiomittakaavassa. Eli kuvausta ei ilmaista aihealueen yksittäisten kohteiden ja niiden suhteiden kautta, vaan:

kuvaus objektityypeistä,
kuvattuun tyyppiin liittyvät eheysrajoitukset,
prosessit, jotka johtavat aihealueen kehitykseen - sen siirtymiseen toiseen tilaan.

Tietomalli voidaan luoda useilla menetelmillä ja lähestymistavoilla:

Toiminnallinen lähestymistapa perustuu annettuihin tehtäviin. Sitä kutsutaan toiminnalliseksi, koska sitä käytetään, jos tunnetaan suunnitellun tietokannan avulla heidän tietotarpeitaan palvelevien henkilöiden toiminnot ja tehtävät.
Aihelähestymistapa keskittyy tietoihin tietokannan sisältämistä tiedoista huolimatta siitä, että kyselyrakennetta ei ehkä ole määritelty. Tässä tapauksessa aihealueen tutkimus keskittyy sen asianmukaisimpaan näyttöön tietokannassa kaikkien odotettujen tietopyyntöjen yhteydessä.
Integroitu lähestymistapa, jossa käytetään "entity-relationship" -menetelmää, yhdistää kahden edellisen edut. Menetelmä perustuu koko aihealueen jakamiseen paikallisiin osiin, jotka mallinnetaan erikseen ja yhdistetään sitten uudelleen kokonaiseksi alueeksi.

Koska "entity-relationship" -menetelmän käyttö on tässä vaiheessa yhdistetty suunnittelumenetelmä, siitä tulee useimmiten prioriteetti.

Metodisesti jaettuna paikalliset edustukset tulisi mahdollisuuksien mukaan sisältää tietoa, joka riittäisi ratkaisemaan erillinen ongelma tai vastaamaan tietyn potentiaalisen ryhmän pyyntöihin. Jokainen näistä alueista sisältää noin 6-7 entiteettiä ja vastaa erillistä ulkoista sovellusta.

Entiteettien riippuvuus näkyy niiden jakautumisessa vahvoihin (perus, emo) ja heikkoihin (lapsi). Vahva kokonaisuus (esimerkiksi lukija kirjastossa) voi olla tietokannassa yksinään, mutta heikko entiteetti (esimerkiksi tämän lukijan tilaus) on "liitetty" vahvaan, eikä sitä ole olemassa erikseen.

On tarpeen erottaa käsitteet "entiteettiinstanssi" (objekti, jolle on ominaista tietyt ominaisuusarvot) ja "entiteettityypin" käsite - objekti, jolle on tunnusomaista yleinen nimi ja ominaisuusluettelo.

Kullekin yksittäiselle entiteetille valitaan attribuutit (joukko ominaisuuksia), jotka voivat kriteerin mukaan olla:

tunnistava (ainutlaatuinen arvo tämän tyyppisille entiteeteille, mikä tekee niistä mahdollisia avaimia) tai kuvaava;
yksiarvoinen tai moniarvoinen (asianmukaisella määrällä arvoja entiteettiinstanssille);
perus (muista attribuuteista riippumaton) tai johdettu (laskettu muiden attribuuttien arvojen perusteella);
yksinkertainen (jakamaton yksikomponenttinen) tai komposiitti (yhdistetty useista komponenteista).

Tämän jälkeen määritetään attribuutti, määritetään yhteydet paikallisnäkymässä (jaetaan valinnaisiin ja pakollisiin) ja paikallisnäkymät yhdistetään. Jos paikallisalueita on enintään 4-5, ne voidaan yhdistää yhdessä vaiheessa . Jos määrä kasvaa, alueiden binäärinen yhdistäminen tapahtuu useassa vaiheessa.

Tämän ja muiden välivaiheiden aikana heijastuu suunnittelun iteratiivisuus, joka ilmenee tässä siinä, että ristiriitojen eliminoimiseksi on palattava paikallisrepresentaatioiden mallintamisen vaiheeseen selkeyttä ja muutosta varten (esim. samat semanttisesti erilaisten objektien nimet tai koordinoida eheysattribuutteja samoilla attribuutilla eri sovelluksissa).

Ohjausjärjestelmän ja tietokantaohjelmiston valinta

Tietojärjestelmän käytännön toteutus riippuu tietokannan hallintajärjestelmän valinnasta. Valintaprosessin tärkeimmät kriteerit ovat seuraavat parametrit:

tietomallin tyyppi ja sen vastaavuus aihealueen tarpeisiin,
mahdollisuuksien reservi tietojärjestelmän laajentamisen yhteydessä,
valitun järjestelmän suorituskykyominaisuudet,
DBMS:n toimintavarmuus ja käyttömukavuus,
tietohallintohenkilöstölle suunnatut työkalut,
itse DBMS:n ja lisäohjelmistojen kustannukset.

Virheet DBMS:n valinnassa aiheuttavat lähes varmasti myöhemmin tarpeen muuttaa käsitteellisiä ja loogisia malleja.

Looginen tietokannan suunnittelu

Tietokannan loogisen rakenteen tulee vastata aihealueen loogista mallia ja ottaa huomioon tietomallin yhteys tuettuun DBMS:ään. Siksi vaihe alkaa tietomallin valinnalla, jossa on tärkeää ottaa huomioon sen yksinkertaisuus ja selkeys.

On suositeltavaa, kun luonnollinen tietorakenne osuu yhteen sitä edustavan mallin kanssa. Joten esimerkiksi jos tiedot esitetään hierarkkisen rakenteen muodossa, on parempi valita hierarkkinen malli. Käytännössä tällainen valinta määräytyy kuitenkin usein tietokannan hallintajärjestelmän eikä tietomallin perusteella. Siksi käsitteellinen malli itse asiassa käännetään tietomalliksi, joka on yhteensopiva valitun tietokannan hallintajärjestelmän kanssa.

Tämä heijastaa myös suunnittelun luonnetta, joka mahdollistaa mahdollisuuden (tai tarpeen) palata käsitteelliseen malliin sen muuttamiseksi, jos siellä heijastuneita objektien (tai objektiattribuuttien) välisiä suhteita ei voida toteuttaa valitulla DBMS:llä.

Vaiheen päätyttyä tulee luoda molempien arkkitehtuurin tasojen (käsitteellinen ja ulkoinen) tietokantaskeemat, jotka on luotava valitun DBMS:n tukemalla tiedonmäärityskielellä.

Tietokantakaaviot muodostetaan käyttämällä yhtä kahdesta eri lähestymistavasta:

tai käyttämällä alhaalta ylös -lähestymistapaa, kun työ tulee attribuuttien määrittelyn alemmista tasoista, jotka on ryhmitelty objekteja edustaviin suhteisiin attribuuttien välisten suhteiden perusteella;
tai käyttämällä käänteistä ylhäältä alas -lähestymistapaa, jota käytetään, kun attribuuttien määrä kasvaa merkittävästi (jopa satoihin ja tuhansiin).

Toinen lähestymistapa sisältää useiden korkean tason entiteettien ja niiden suhteiden tunnistamisen ja myöhemmän yksityiskohdan vaaditulle tasolle, mikä heijastuu esimerkiksi "entity-relationship" -menetelmällä luotuun malliin. Mutta käytännössä molemmat lähestymistavat yleensä yhdistetään.

Fyysisen tietokannan suunnittelu

Tietokannan fyysisen suunnittelun seuraavassa vaiheessa looginen rakenne esitetään tietokannan tallennusrakenteen muodossa, eli se on linkitetty fyysiseen tallennusympäristöön, johon tiedot sijoitetaan mahdollisimman tehokkaasti. Tässä tietoskeema on kuvattu yksityiskohtaisesti, ja siinä ilmoitetaan kaikki tyypit, kentät, koot ja rajoitukset. Indeksien ja taulukoiden kehittämisen lisäksi määritellään peruskyselyt.

Fyysisen mallin rakentamiseen kuuluu pitkälti ristiriitaisten ongelmien ratkaiseminen:

tehtävät tietojen tallennustilan minimoimiseksi,
haasteita eheyden, turvallisuuden ja parhaan mahdollisen suorituskyvyn saavuttamiseksi.

Toinen tehtävä on ristiriidassa ensimmäisen kanssa, koska esimerkiksi:

Jotta tapahtumat toimisivat tehokkaasti, sinun on varattava levytilaa väliaikaisille kohteille,
hakunopeuden lisäämiseksi sinun on luotava indeksit, joiden lukumäärä määräytyy kaikkien mahdollisten hakuun osallistuvien kenttien yhdistelmien lukumäärän mukaan,
Tietojen palauttamiseksi luodaan tietokannan varmuuskopiot ja kaikista muutoksista pidetään lokia.

Kaikki tämä kasvattaa tietokannan kokoa, joten suunnittelija etsii järkevää tasapainoa, jossa ongelmat ratkaistaan optimaalisesti sijoittamalla tiedot älykkäästi muistitilaan, mutta ei tietokannan turvallisuuden kustannuksella, joka sisältää sekä suojauksen luvattomalta käytöltä että suojauksen. epäonnistumisista.

Fyysisen mallin luomisen viimeistelemiseksi arvioidaan sen toiminnalliset ominaisuudet (haun nopeus, kyselyn suorittamisen tehokkuus ja resurssien kulutus, toimintojen oikeellisuus). Joskus tämä vaihe, kuten tietokannan toteutus-, testaus- ja optimointivaiheet sekä ylläpito ja käyttö, viedään tietokannan välittömän suunnittelun ulkopuolelle.

Käännös 15 artikkelin sarjasta tietokannan suunnittelusta.
Tiedot on tarkoitettu aloittelijoille.
Auttoi minua. Ehkä se auttaa jotakuta toista täyttämään aukot.

Tietokannan suunnitteluopas.

1. Esittely.

Jos aiot rakentaa omia tietokantoja, kannattaa noudattaa tietokannan suunnitteluohjeita, sillä näin varmistetaan tietojesi pitkäaikainen eheys ja helppohoitoisuus. Tämä opas kertoo, mitä tietokannat ovat ja kuinka suunnitella tietokanta, joka noudattaa relaatiotietokannan suunnittelun sääntöjä.

Tietokannat ovat ohjelmia, joiden avulla voit tallentaa ja hakea suuria määriä asiaan liittyvää tietoa. Tietokannat koostuvat mm taulukoita, jotka sisältävät tiedot. Kun luot tietokantaa, sinun on mietittävä mitä taulukoita sinun täytyy luoda ja mitä viestintää taulukoissa olevien tietojen välillä. Toisin sanoen, sinun on mietittävä hanke tietokantaasi. Hieno projekti tietokanta, kuten aiemmin mainittiin, varmistaa tietojen eheyden ja helpon ylläpidon.

Tietokanta luodaan tallentamaan siihen tietoja ja hakemaan näitä tietoja tarvittaessa. Tämä tarkoittaa, että meidän on voitava sijoittaa, lisätä ( LISÄÄ) tiedot tietokantaan ja haluamme pystyä hakemaan tietoa tietokannasta ( VALITSE).
Näitä tarkoituksia varten keksittiin tietokantakyselykieli, jota kutsuttiin Strukturoitu kyselykieli tai SQL. Tietojen lisääminen (INSERT) ja valinta (SELECT) ovat osa tätä kieltä. Alla on esimerkki tiedonhakupyynnöstä ja sen tuloksesta.

SQL on iso aihe, eikä se kuulu tämän opetusohjelman soveltamisalaan. Tämä artikkeli keskittyy tiukasti esittelyyn tietokannan suunnitteluprosessi. Kerron SQL:n perusteista myöhemmin erillisessä opetusohjelmassa.

Suhdemalli.

Tässä opetusohjelmassa näytän sinulle, kuinka luodaan relaatiotietomalli. Relaatiomalli on malli, joka kuvaa, kuinka tiedot järjestetään taulukoihin ja kuinka näiden taulukoiden väliset suhteet määritetään.

Relaatiomallin säännöt määräävät, kuinka tiedot tulee järjestää taulukoihin ja miten taulukot liittyvät toisiinsa. Loppujen lopuksi tulos voidaan esittää tietokantakaaviona tai tarkemmin kokonaisuus-suhdekaaviona, kuten kuvassa (Esimerkki otettu MySQL Workbenchistä).

Esimerkkejä.

Käytin useita sovelluksia esimerkkeinä oppaassa.

RDBMS.

RDBMS, jota käytin esimerkkitaulukoiden luomiseen, oli MySQL. MySQL on suosituin RDBMS ja se on ilmainen.

Tietokannan hallintaohjelma.

MySQL:n asentamisen jälkeen saat vain komentoriviliittymän MySQL:n kanssa vuorovaikutukseen. Henkilökohtaisesti pidän parempana graafista käyttöliittymää tietokantojeni hallintaan. Käytän SQLyogia usein. Tämä on ilmainen GUI-apuohjelma. Tämän oppaan taulukkokuvat on otettu sieltä.

Visuaalinen mallinnus.

Siellä on erinomainen ilmainen sovellus nimeltä MySQL Workbench. Sen avulla voit suunnitella tietokantasi graafisesti. Käsikirjan kaaviokuvat on tehty tällä ohjelmalla.

RDBMS:stä riippumaton suunnittelu.

On tärkeää tietää, että vaikka tämä opetusohjelma sisältää esimerkkejä MySQL:stä, tietokannan suunnittelu on riippumaton RDBMS:stä. Tämä tarkoittaa, että tiedot koskevat relaatiotietokantoja yleensä, ei vain MySQL:ää. Voit soveltaa tämän opetusohjelman tietoja mihin tahansa relaatiotietokantoihin, kuten Mysql, Postgresql, Microsoft Access, Microsoft Sql tai Oracle.

Seuraavassa osassa puhun lyhyesti tietokantojen kehityksestä. Opit mistä tietokannat ja relaatiotietomalli ovat peräisin.

2. Historia.

70- ja 80-luvuilla, kun tietojenkäsittelytieteilijät käyttivät vielä ruskeita smokkia ja laseja, joissa oli suuret, neliömäiset kehykset, tiedot tallennettiin jäsentelemättä tiedostoihin, jotka olivat tekstidokumentteja, joiden tiedot erotettiin (yleensä) pilkuilla tai sarkaimeilla.

Tältä tietotekniikan ammattilaiset näyttivät 70-luvulla. (Vasemmalla alhaalla on Bill Gates).

Tekstitiedostoja käytetään edelleen pienten määrien yksinkertaisen tiedon tallentamiseen. Pilkuilla erotetut arvot (CSV) - Pilkuilla erotetut arvot ovat erittäin suosittuja, ja useat ohjelmistot ja käyttöjärjestelmät tukevat niitä nykyään laajasti. Microsoft Excel on yksi esimerkki ohjelmista, jotka voivat toimia CSV-tiedostojen kanssa. Tällaiseen tiedostoon tallennetut tiedot voidaan lukea tietokoneohjelmalla.

Yllä on esimerkki siitä, miltä tällainen tiedosto voi näyttää. Tätä tiedostoa lukevalle ohjelmalle on ilmoitettava, että tiedot on erotettu pilkuilla. Jos ohjelma haluaa valita ja näyttää luokan, jossa oppitunti sijaitsee "Tietokannan suunnittelun opetusohjelma", hänen on luettava rivi riviltä, kunnes sanat löytyvät "Tietokannan suunnittelun opetusohjelma" ja sitten hänen on luettava pilkkua seuraava sana voidakseen päätellä luokan Ohjelmisto.

Tietokantataulukot.

Tiedoston lukeminen rivi riviltä ei ole kovin tehokasta. Relaatiotietokannassa tiedot tallennetaan taulukoihin. Alla oleva taulukko sisältää samat tiedot kuin tiedosto. Jokainen rivi tai "merkintä" sisältää yhden oppitunnin. Jokainen sarake sisältää jonkin oppitunnin ominaisuuden. Tässä tapauksessa tämä on otsikko ja sen luokka.

Tietokoneohjelma voisi etsiä tietyn taulukon tutorial_id-sarakkeesta tiettyä tutorial_id-tunnusta löytääkseen nopeasti sitä vastaavan otsikon ja luokan. Tämä on paljon nopeampaa kuin tiedostojen etsiminen rivi riviltä, aivan kuten ohjelma tekee tekstitiedostossa.

Nykyaikaiset relaatiotietokannat on suunniteltu mahdollistamaan tietojen hakeminen tietyistä riveistä, sarakkeista ja useista taulukoista kerrallaan erittäin nopeasti.

Suhdemallin historia.

Relaatiotietokantamallin keksi 70-luvulla brittiläinen tiedemies Edgar Codd. Hän halusi voittaa verkkotietokantamallin ja hierarkkisen mallin puutteet. Ja hän menestyi tässä erittäin hyvin. Relaatiotietokantamalli on nykyään laajalti hyväksytty ja sitä pidetään tehokkaana mallina tietojen tehokkaaseen järjestämiseen.

Nykyään on saatavilla laaja valikoima tietokannan hallintajärjestelmiä pienistä työpöytäsovelluksista monipuolisiin palvelinjärjestelmiin, joissa on erittäin optimoituja hakumenetelmiä. Tässä on joitain tunnetuimmista relaatiotietokannan hallintajärjestelmistä (RDBMS):

- Oraakkeli– käytetään ensisijaisesti ammattimaisiin, suuriin sovelluksiin.
- Microsoft SQL -palvelin– RDBMS Microsoftilta. Saatavilla vain Windows-käyttöjärjestelmälle.
- mysql on erittäin suosittu avoimen lähdekoodin RDBMS. Laajalti käytössä sekä ammattilaisten että aloittelijoiden keskuudessa. Mitä muuta tarvitaan?! Se on ilmainen.
- IBM– sisältää useita RDBMS-järjestelmiä, joista tunnetuin on DB2.
- Microsoft Access– RDBMS, jota käytetään toimistossa ja kotona. Itse asiassa se on enemmän kuin pelkkä tietokanta. MS Accessin avulla voit luoda tietokantoja käyttöliittymällä.
Seuraavassa osassa kerron sinulle jotain relaatiotietokantojen ominaisuuksista.

3. Relaatiotietokantojen ominaisuudet.

Relaatiotietokannat on suunniteltu tallentamaan ja hakemaan nopeasti suuria tietomääriä. Alla on joitain relaatiotietokantojen ja relaatiotietomallin ominaisuuksia.

Avainten käyttö.

Jokainen taulukon tietorivi tunnistetaan ainutlaatuisella "avaimella", jota kutsutaan ensisijaiseksi avaimeksi. Usein ensisijainen avain on automaattisesti kasvava (automaattisesti kasvava) numero (1,2,3,4 jne.). Eri taulukoiden tiedot voidaan linkittää toisiinsa avaimilla. Yhden taulukon perusavainarvot voidaan lisätä toisen taulukon riveihin (tietueisiin), jolloin tietueet voidaan linkittää toisiinsa.

Käyttämällä Structured Query Language (SQL) -kieltä, tiedot eri taulukoista, jotka liittyvät avaimeen, voidaan hakea yhdellä kertaa. Voit esimerkiksi luoda kyselyn, joka valitsee tilaustaulukosta kaikki tilaukset, jotka kuuluvat käyttäjätunnukseen 3 (Mike) käyttäjätaulukosta. Puhumme avaimista tarkemmin seuraavissa osissa.

Tämän taulukon id-sarake on ensisijainen avain. Jokaisella tietueella on yksilöllinen ensisijainen avain, usein numero. Käyttäjäryhmäsarake on vierasavain. Nimestään päätellen se viittaa ilmeisesti taulukkoon, joka sisältää käyttäjäryhmiä.

Ei tietojen redundanssia.

Relaatiotietomallin sääntöjä noudattavassa tietokantasuunnittelussa jokainen tieto, kuten käyttäjän nimi, tallennetaan vain yhteen paikkaan. Tämä poistaa tarpeen käsitellä tietoja useissa paikoissa. Kaksinkertaista dataa kutsutaan datan redundanssiksi, ja sitä tulee välttää hyvässä tietokannan suunnittelussa.

Syöttörajoitus.

Relaatiotietokannan avulla voit määrittää, millaisia tietoja sarakkeeseen voidaan tallentaa. Voit luoda kentän, joka sisältää kokonaislukuja, desimaalilukuja, pieniä tekstinpätkiä, suuria tekstiä, päivämääriä jne.

Kun luot tietokantataulukon, annat jokaiselle sarakkeelle tietotyypin. Esimerkiksi varchar on tietotyyppi pienille tekstikappaleille, joissa on enintään 255 merkkiä, ja int on numero.

Tietotyyppien lisäksi RDBMS mahdollistaa syötettävien tietojen rajoittamisen. Voit esimerkiksi rajoittaa tietyn sarakkeen tietueiden pituutta tai pakottaa niiden yksilöllisen arvon. Viimeistä rajoitusta käytetään usein kenttiin, jotka sisältävät käyttäjänimiä tai sähköpostiosoitteita.

Nämä rajoitukset antavat sinulle mahdollisuuden hallita tietojesi eheyttä ja estää seuraavat tilanteet:

Kirjoita osoite (teksti) kenttään, jossa odotat näkeväsi numeron
- syötetään alueindeksi, jonka saman indeksin pituus on sata merkkiä
- luodaan käyttäjiä samalla nimellä
- käyttäjien luominen samalla sähköpostiosoitteella
- kirjoita paino (numero) syntymäpäiväkenttään (päivämäärä)

Tietojen eheyden säilyttäminen.

Säätämällä kentän ominaisuuksia, linkittämällä taulukoita ja määrittämällä rajoituksia voit lisätä tietojesi luotettavuutta.

Oikeuksien luovutus.

Useimmat RDBMS:t tarjoavat käyttöoikeusasetuksia, joiden avulla voit määrittää tietyt oikeudet tietyille käyttäjille. Joitakin toimintoja, jotka voidaan sallia tai kieltää käyttäjältä: SELECT, INSERT, DELETE, ALTER, CREATE jne. Nämä ovat toimintoja, jotka voidaan suorittaa SQL (Structured Query Language) avulla.

Structured Query Language (SQL).

Tiettyjen toimintojen suorittamiseen tietokannassa, kuten tietojen tallentamiseen, hakemiseen, muuttamiseen, käytetään strukturoitua kyselykieltä (SQL). SQL on suhteellisen helppo ymmärtää ja mahdollistaa... ja pinotut valinnat, kuten vastaavien tietojen hakeminen useista taulukoista SQL JOIN -käskyn avulla. Kuten aiemmin mainittiin, SQL:ää ei käsitellä tässä opetusohjelmassa. Keskityn tietokannan suunnitteluun.

Tapa, jolla suunnittelet tietokannan, vaikuttaa suoraan kyselyihin, jotka sinun on suoritettava tietojen hakemiseksi tietokannasta. Tämä on toinen syy, miksi sinun on mietittävä, mikä perustasi tulisi olla. Hyvin suunnitellun tietokannan avulla kyselysi voivat olla selkeämpiä ja yksinkertaisempia.

Siirrettävyys.

Relaatiotietomalli on vakio. Noudattamalla relaatiotietomallin sääntöjä voit olla varma, että tietosi voidaan siirtää toiseen RDBMS:ään suhteellisen helposti.

Kuten aiemmin todettiin, tietokannan suunnittelussa on kyse tietojen tunnistamisesta, yhdistämisestä ja tämän kysymyksen tulosten kirjaamisesta paperille (tai tietokoneohjelmaan). Suunnittele tietokanta, joka on riippumaton RDBMS:stä, jota aiot käyttää sen luomiseen.

Seuraavassa osassa tarkastellaan lähemmin ensisijaisia avaimia.

Tietokannan suunnittelun ja vaiheistuksen sisältö

Lopuksi tietokannan suunnittelun viimeinen vaihe on fyysinen suunnittelu - vaihe, jossa looginen rakenne ja fyysinen tallennusympäristö yhdistetään.

Näin ollen suunnittelun päävaiheet yksityiskohtaisessa muodossa esitetään seuraavissa vaiheissa:

tietosuunnittelu,
toimintaympäristön vaatimusten muodostus
ohjausjärjestelmän ja tietokantaohjelmiston valinta,
looginen suunnittelu,
fyysinen suunnittelu

Keskeisimmistä käsitellään tarkemmin alla.

Infologinen suunnittelu

kuvaus objektityypeistä,
kuvattuun tyyppiin liittyvät eheysrajoitukset,
prosessit, jotka johtavat aihealueen kehitykseen - sen siirtymiseen toiseen tilaan.

Tietomalli voidaan luoda useilla menetelmillä ja lähestymistavoilla:

Toiminnallinen lähestymistapa perustuu annettuihin tehtäviin. Sitä kutsutaan toiminnalliseksi, koska sitä käytetään, jos tunnetaan suunnitellun tietokannan avulla heidän tietotarpeitaan palvelevien henkilöiden toiminnot ja tehtävät.
Aihelähestymistapa keskittyy tietoihin tietokannan sisältämistä tiedoista huolimatta siitä, että kyselyrakennetta ei ehkä ole määritelty. Tässä tapauksessa aihealueen tutkimus keskittyy sen asianmukaisimpaan näyttöön tietokannassa kaikkien odotettujen tietopyyntöjen yhteydessä.
Integroitu lähestymistapa, jossa käytetään "entity-relationship" -menetelmää, yhdistää kahden edellisen edut. Menetelmä perustuu koko aihealueen jakamiseen paikallisiin osiin, jotka mallinnetaan erikseen ja yhdistetään sitten uudelleen kokonaiseksi alueeksi.

Koska "entity-relationship" -menetelmän käyttö on tässä vaiheessa yhdistetty suunnittelumenetelmä, siitä tulee useimmiten prioriteetti.

On tarpeen erottaa käsitteet "entiteettiinstanssi" (objekti, jolle on ominaista tietyt ominaisuusarvot) ja "entiteettityypin" käsite - objekti, jolle on tunnusomaista yleinen nimi ja ominaisuusluettelo.

Kullekin yksittäiselle entiteetille valitaan attribuutit (joukko ominaisuuksia), jotka voivat kriteerin mukaan olla:

tunnistava (ainutlaatuinen arvo tämän tyyppisille entiteeteille, mikä tekee niistä mahdollisia avaimia) tai kuvaava;
yksiarvoinen tai moniarvoinen (asianmukaisella määrällä arvoja entiteettiinstanssille);
perus (muista attribuuteista riippumaton) tai johdettu (laskettu muiden attribuuttien arvojen perusteella);
yksinkertainen (jakamaton yksikomponenttinen) tai komposiitti (yhdistetty useista komponenteista).

Ohjausjärjestelmän ja tietokantaohjelmiston valinta

Tietojärjestelmän käytännön toteutus riippuu tietokannan hallintajärjestelmän valinnasta. Valintaprosessin tärkeimmät kriteerit ovat seuraavat parametrit:

tietomallin tyyppi ja sen vastaavuus aihealueen tarpeisiin,
mahdollisuuksien reservi tietojärjestelmän laajentamisen yhteydessä,
valitun järjestelmän suorituskykyominaisuudet,
DBMS:n toimintavarmuus ja käyttömukavuus,
tietohallintohenkilöstölle suunnatut työkalut,
itse DBMS:n ja lisäohjelmistojen kustannukset.

Virheet DBMS:n valinnassa aiheuttavat lähes varmasti myöhemmin tarpeen muuttaa käsitteellisiä ja loogisia malleja.

Looginen tietokannan suunnittelu

Vaiheen päätyttyä tulee luoda molempien arkkitehtuurin tasojen (käsitteellinen ja ulkoinen) tietokantaskeemat, jotka on luotava valitun DBMS:n tukemalla tiedonmäärityskielellä.

Tietokantakaaviot muodostetaan käyttämällä yhtä kahdesta eri lähestymistavasta:

tai käyttämällä alhaalta ylös -lähestymistapaa, kun työ tulee attribuuttien määrittelyn alemmista tasoista, jotka on ryhmitelty objekteja edustaviin suhteisiin attribuuttien välisten suhteiden perusteella;
tai käyttämällä käänteistä ylhäältä alas -lähestymistapaa, jota käytetään, kun attribuuttien määrä kasvaa merkittävästi (jopa satoihin ja tuhansiin).

Fyysisen tietokannan suunnittelu

Fyysisen mallin rakentamiseen kuuluu pitkälti ristiriitaisten ongelmien ratkaiseminen:

tehtävät tietojen tallennustilan minimoimiseksi,
haasteita eheyden, turvallisuuden ja parhaan mahdollisen suorituskyvyn saavuttamiseksi.

Toinen tehtävä on ristiriidassa ensimmäisen kanssa, koska esimerkiksi:

Jotta tapahtumat toimisivat tehokkaasti, sinun on varattava levytilaa väliaikaisille kohteille,
hakunopeuden lisäämiseksi sinun on luotava indeksit, joiden lukumäärä määräytyy kaikkien mahdollisten hakuun osallistuvien kenttien yhdistelmien lukumäärän mukaan,
Tietojen palauttamiseksi luodaan tietokannan varmuuskopiot ja kaikista muutoksista pidetään lokia.

Suunnitteluprosessi sisältää seuraavat vaiheet.

Infologinen suunnittelu.

Tietojärjestelmän toimintaympäristön vaatimusten määrittäminen.

Tietokannan hallintajärjestelmän (DBMS) ja muiden ohjelmistotyökalujen valinta.

Looginen tietokannan suunnittelu.

Tietokannan fyysinen suunnittelu.

1.1. Infologinen suunnittelu.

Tietojärjestelmien suunnitteluprosessi on melko monimutkainen tehtävä. Se alkaa rakentamalla infologinen tietomalli, eli kokonaisuuksien tunnistaminen.

Tietopohjainen verkkoalueen (ohjelmiston) malli on kuvaus ohjelmiston rakenteesta ja dynamiikasta, käyttäjien tietotarpeiden luonteesta käyttäjälle ymmärrettävin ja tietokannan toteutuksesta riippumattomin termein. Tämä kuvaus ei ilmaista yksittäisten ohjelmistoobjektien ja niiden välisten yhteyksien avulla, vaan niiden tyypeillä, niihin liittyvillä eheysrajoitteilla ja prosesseilla, jotka johtavat aihealueen siirtymiseen tilasta toiseen.

Tällä hetkellä suunnittelussa käytetään Entity-Relationship (ER-method) -menetelmää, joka on yhdistelmä aihe- ja sovellettavia menetelmiä ja jossa on kummankin edut.

Tietojen suunnitteluvaihe alkaa ohjelmiston mallintamisesta. Suunnittelija jakaa sen useisiin paikallisiin alueisiin, joista jokainen sisältää (ihanteellisesti) riittävän informaation täyttämään erillisen tulevaisuuden käyttäjäryhmän tarpeet tai ratkaisemaan erillisen tehtävän (alitehtävän). Jokainen paikallinen edustus mallinnetaan erikseen, sitten ne yhdistetään.

Paikallisen edustuksen valinta riippuu ohjelmiston mittakaavasta. Tyypillisesti se on jaettu paikallisiin alueisiin siten, että jokainen niistä vastaa erillistä ulkoista sovellusta ja sisältää 6-7 entiteettiä.

Essence– tämä on objekti, josta tietoa kerääntyy järjestelmään. Entiteetit ovat olemassa fyysisesti olemassa olevina (esim. TYÖNTEKIJÄ tai AUTO ) ja abstrakteja (esim. KOE tai DIAGNOOSI ).

Entiteetit luokitellaan luokkaan, entiteettityyppiin ja ilmentymiin. Kokonaisuuksia on kolme pääluokkaa: sauva, assosiatiivista Ja ominaisuus, sekä assosiatiivisten entiteettien alaluokka – nimitykset.

Core Essence (ydin ) on itsenäinen kokonaisuus, joka ei ole yhdistys, nimitys tai ominaisuus. Tällaisilla kokonaisuuksilla on itsenäinen olemassaolo, vaikka ne voivat nimetä muita kokonaisuuksia.

Assosiatiivinen kokonaisuus (yhdistys ) on monesta moneen -suhde kahden tai useamman entiteetin tai kokonaisuuden esiintymän välillä. Yhdistykset katsotaan täysivaltaisiksi kokonaisuuksiksi, ne voivat: osallistua muihin yhdistyksiin ja nimityksiin samalla tavalla kuin ydinkokonaisuudet; on ominaisuuksia, ts. niillä ei ole vain joukko keskeisiä attribuutteja, jotka ovat välttämättömiä suhteiden ilmaisemiseksi, vaan myös useita muita suhteita kuvaavia attribuutteja.

Ominainen kokonaisuus ( ominaisuus ) on "monet yhteen" tai "yksi yhteen" -suhde kahden entiteetin välillä (erityistapaus assosiaatiosta). Ainoa kohde tarkasteltavan aihealueen ominaisuudet tarkoittaa jonkin muun kokonaisuuden kuvaamista tai selventämistä. Niiden tarve syntyy siitä syystä, että todellisen maailman kokonaisuuksilla on joskus moniarvoisia ominaisuuksia.

Esimerkiksi miehellä voi olla useita vaimoja, kirjalla voi olla useita uusintapainoksen ominaisuuksia (korjattu, laajennettu jne.).

Ominaisuuden olemassaolo riippuu täysin karakterisoitavasta kokonaisuudesta: naiset menettävät asemansa vaimona, jos heidän miehensä kuolee.

Nimeävä kokonaisuus ( nimitys ) on useat yhteen tai yksi yhteen -suhde kahden entiteetin ja on erilainen ominaisuudesta, koska se ei riipu nimetystä kokonaisuudesta. Merkintöjä käytetään suurten tekstiattribuuttien toistuvien arvojen tallentamiseen: opiskelijoiden opiskelemien tieteenalojen "kodifioijat", organisaatioiden ja niiden osastojen nimet, tavaraluettelot jne.

Pääsääntöisesti nimitykset ei oteta huomioon täysivaltaisina kokonaisuuksina, vaikka tämä ei johtaisi virheeseen. Nimitykset ja ominaisuudet eivät ole täysin itsenäisiä kokonaisuuksia, koska ne edellyttävät jonkin muun kokonaisuuden olemassaoloa, joka "nimetään" tai "karakterisoidaan". Ne edustavat kuitenkin edelleen kokonaisuuden erikoistapauksia ja voivat luonnollisesti olla ominaisuuksia, voivat osallistua yhdistyksiin, nimityksiin ja niillä on omat (alemman tason) ominaispiirteensä. Korostamme myös, että kaikki ominaisuuden esiintymät on liitettävä johonkin luonnehditun kokonaisuuden esiintymään. On kuitenkin sallittua, että joillain luonnehditun kokonaisuuden esiintymillä ei ole suhteita.

Entiteettityyppi ominaista nimi ja luettelo ominaisuuksista, ja kopio– tietyt omaisuuden arvot.

Entiteettityypit voidaan luokitella vahva Ja heikko . Vahvat kokonaisuudet ovat olemassa yksinään, ja heikkojen entiteettien olemassaolo riippuu vahvojen olemassaolosta.

Esimerkiksi kirjaston lukija on vahva kokonaisuus ja lukijan tilaus heikko kokonaisuus, joka riippuu vastaavan lukijan läsnäolosta.

Heikkoja kokonaisuuksia kutsutaan alaiset (tytäryritykset) ja vahvimmat - perus (pää, vanhempi).

Jokaiselle entiteetille valitaan ominaisuudet (attribuutit).

On:

Tunnistavat ja kuvaavat attribuutit. Tunnistemääritteillä on ainutlaatuinen merkitys tietyn tyyppisille entiteeteille ja ne ovat mahdolliset avaimet. Niiden avulla voit tunnistaa yksilöllisesti kokonaisuuden esiintymät. Yksi ensisijainen avain (PC) valitaan mahdollisista avaimista. Potentiaalinen avain valitaan yleensä PC:ksi, jota käytetään tietueilmentymien käsiksi useammin. Lisäksi PC:ssä on oltava vähimmäismäärä tunnistamiseen vaadittavia määritteitä. Loput attribuutit ovat kuvailevia ja sisältävät entiteetin kannalta kiinnostavia ominaisuuksia.

Yhdistetyt ja yksinkertaiset attribuutit. Yksinkertainen attribuutti koostuu yhdestä komponentista, sen arvo on jakamaton. Yhdistelmäattribuutti on yhdistelmä useista komponenteista, jotka mahdollisesti kuuluvat eri tietotyyppeihin (esimerkiksi koko nimi tai osoite). Päätös siitä, käytetäänkö yhdistelmäattribuuttia vai jaetaanko se osiin, riippuu siitä, kuinka se käsitellään ja millä tavalla käyttäjä esittää kyseisen attribuutin.

Yksi- ja moniarvoiset attribuutit(voi olla yksi tai useita arvoja kullekin entiteettiinstanssille, vastaavasti).

Perus- ja johdetut attribuutit. Päämääritteen arvo on riippumaton muista attribuuteista. Johdetun attribuutin arvo lasketaan muiden attribuuttien arvojen perusteella (esimerkiksi opiskelijan ikä lasketaan hänen syntymäajan ja nykyisen päivämäärän perusteella).

Erittely attribuutti koostuu hänen otsikoita, ohjeet tietotyyppi Ja eheysrajoitusten kuvaukset– arvojoukko (tai verkkoalue), jonka tietty attribuutti voi ottaa.

Seuraavaksi suoritetaan yhteyksien määrittely paikallisen edustuksen sisällä. Yhteyksillä voi olla erilaisia merkityksellisiä merkityksiä (semantiikkaa). "Entity-entity", "entiteetti-attribuutti" ja "attribuutti-attribuutti" -suhteet erotetaan toisistaan attribuuttien välisillä suhteilla, jotka luonnehtivat samaa entiteettiä tai samaa entiteetti-entiteetti -suhdetta.

Jokainen yhteys luonnehdittu nimi, velvollisuus, tyyppi Ja tutkinnon. Erottaa valinnainen Ja pakollinen viestintää. Jos äskettäin luotu yhden tyyppinen objekti liittyy välttämättä toisen tyyppiseen objektiin, näiden objektityyppien välillä on pakollinen yhteys (merkitty kaksoisviivalla). Muuten yhteys on valinnainen.

Tekijä: tyyppi On olemassa useita suhteita: yksi-yhteen (1:1), yksi-moneen (1:n) ja useista moneen (m:n). Kuvassa on ER-kaavio, joka sisältää erilaisia liitäntöjä. 1. Huomaa, että vaaditut liitännät kuvassa 1. 1 on korostettu kaksoisviivalla.

Tutkinto suhde määräytyy tämän suhteen kattamien entiteettien lukumäärän mukaan. Esimerkki binäärisuhteesta on yhteys osaston ja siinä työskentelevien työntekijöiden välillä. Esimerkki kolmiosaisesta suhteesta on suhde koe entiteettien välillä KURI , OPISKELIJA , OPETTAJA . Viimeisestä esimerkistä on selvää, että yhteydellä voi myös olla attribuutteja (tässä tapauksessa se on päivämäärä Ja Arvosana ). Esimerkki ER-kaaviosta, joka ilmaisee entiteettejä, niiden attribuutteja ja suhteita, on esitetty kuvassa. 2.

Tehdyt suunnittelupäätökset voidaan kuvata SQL-kieleen perustuvalla tietomallinnuskielellä (IML), jonka avulla voit antaa kätevän ja täydellisen kuvauksen mistä tahansa kokonaisuudesta ja siten koko tietokannasta. Esimerkiksi:

LUO PÖYTÄ ASTIAT *(Ydinkokonaisuus)

ENSISIJAINEN AVAIN (BL)

KENTÄT (BL koko, lautasen teksti 60, näytä teksti 7)

RAJOITUKSET (1. Astia-kentän arvojen on oltava

ainutlaatuinen; rikkomuksen sattuessa peruuttaminen

viestit "Tällainen ruokalaji on jo olemassa."

2. Tyyppi-kentän arvojen on kuuluttava

setti: alkupala, keitto, pääruoka, jälkiruoka,

Juoda; jos rikkomus tapahtuu, näytä viesti

"Voit syödä vain alkupalaa, keittoa, kuumaa,

Jälkiruoka, juoma");

LUO PÖYTÄ Kokoonpano *(Linkit ruoat ja tuotteet)

ENSISIJAINEN AVAIN (BL, PR)

ULKOINEN AVAIN (BL Dish

NULL-arvot EIVÄT OLE SALLITUJA

POISTAMINEN ASTIANKASKADEISTA

PÄIVITYS Dish.BL CASCADES)

ULKOMAINEN AVAIN (PALKINNAT Tuotteet

NULL-arvot EIVÄT OLE SALLITUJA

POISTAMINEN TUOTTEISTA RAJOITETTU.

PÄIVITYS Tuotteet.PR CASCADIZED)

KENTÄT (BL-kokonaisluku, PR-kokonaisluku, painokokonaisluku)

RAJOITUKSET (1. BL- ja PR-kenttien arvojen on kuuluttava

joukko arvoja vastaavista taulukon kentistä

Astiat ja tuotteet; jos rikkomus tapahtuu, näytä viesti

"Tällaista ruokaa ei ole" tai "Tällaista tuotetta ei ole."

2. Paino-kentän arvon on oltava välillä 0,1 - 500 g);

Tällainen kuvaus ei kuitenkaan ole kovin selkeä. Paremman havainnollistavuuden saavuttamiseksi on suositeltavaa täydentää projektia tietomallinnuskielillä "Entity-relationship" tai "Table-relationship"

ER-kaavioissa "Entity-relationship" olemus on kuvattu (kuva 2) merkittyjä suorakulmioita, yhdistykset – merkitty timanteilla tai kuusikulmiot, attribuutteja – merkityt soikeat, A viestintää heidän välillään - suuntaamattomat kylkiluut(geometrisia muotoja yhdistävät viivat), jonka yläpuolella voidaan ilmoittaa yhteysaste (1 tai kirjain, joka korvaa sanan "monet") ja tarvittava selitys.

Tietomallinnuskielellä "Table-link" (kuva 3) on kuvattu kaikki entiteetit yksisarakkeiset taulukot otsikoineen, joka koostuu nimi Ja entiteettityyppi. Taulukon rivit ovat luettelo entiteettiattribuuteista, ja ne, jotka muodostavat ensisijaisen avaimen, sijaitsevat lähellä ja niitä ympäröi kehys. Entiteettien väliset suhteet ilmaistaan nuolilla, jotka on suunnattu ensisijaisista avaimista tai niiden komponenteista.

(ydin)

(yhdistys)

(ominainen)

Kun paikalliset näkymät on luotu, ne yhdistetään. Jos paikallisia alueita on vähän (enintään viisi), ne yhdistetään yhdessä vaiheessa. Muuten binääriliitos suoritetaan yleensä useassa vaiheessa.

Yhdistettynä suunnittelija voi muodostaa rakenteita, jotka on johdettu paikallisissa esityksissä käytetyistä. Tällä lähestymistavalla voitaisiin saavuttaa seuraavat tavoitteet:

yhdistämällä hajanaisia ajatuksia saman kohteen eri ominaisuuksista yhdeksi kokonaisuudeksi;

järjestelmäongelmien ratkaisemiseen sopivien abstraktien käsitteiden käyttöönotto, niiden yhteyden luominen mallissa käytettyihin tiettyihin käsitteisiin;

samankaltaisten esineiden luokkien ja alaluokkien muodostaminen (esimerkiksi luokka "tuote" ja yrityksessä valmistettujen tuotetyyppien alaluokat).

Yhdistämisvaiheessa on tarpeen tunnistaa ja poistaa kaikki ristiriidat. Esimerkiksi semanttisesti erilaisten objektien tai suhteiden samat nimet tai epäjohdonmukaiset eheysrajoitukset samoilla määritteillä eri sovelluksissa. Ristiriitojen poistaminen edellyttää palaamista paikallisrepresentaatioiden mallintamisen vaiheeseen, jotta niihin voidaan tehdä asianmukaisia muutoksia.

Yhdistelmän valmistuttua suunnittelutulokset edustavat aihealueen käsitteellistä informaatiomallia. Paikallisesitysten mallit ovat ulkoisia informaatiomalleja.

TOIMINTAHUONEEN VAATIMUSTEN MÄÄRITTÄMINEN

TILANNE.

Tässä vaiheessa arvioidaan järjestelmän toiminnan edellyttämien laskentaresurssien vaatimukset, määritetään tietyn tietokoneen tyyppi ja kokoonpano sekä valitaan käyttöjärjestelmän tyyppi ja versio. Laskentaresurssien määrä riippuu suunnitellun tietokannan odotetusta määrästä ja niiden käytön intensiteetistä. Jos tietokanta toimii monen käyttäjän tilassa, sen on oltava yhteydessä verkkoon ja siinä on oltava asianmukainen moniajokäyttöjärjestelmä.