Faze projektiranja i izrade baze podataka. Faze razvoja baze podataka

Faze projektiranja baze podataka.

Teme: faze projektiranja baze podataka, projektiranje baze podataka temeljeno na modelu objektnog odnosa

Prije stvaranja baze podataka, programer mora odrediti od kojih se tablica baza podataka treba sastojati, koje podatke treba staviti u svaku tablicu i kako povezati tablice. Ovi se problemi rješavaju u fazi projektiranja baze podataka.

Kao rezultat projektiranja mora se odrediti logička struktura baze podataka, odnosno sastav relacijskih tablica, njihova struktura i međutablični odnosi.

Prije izrade baze podataka izuzetno je važno imati opis odabranog predmetno područje, ĸᴏᴛᴏᴩᴏᴇ treba pokriti stvarne objekte i procese, identificirati sve potrebne izvore informacija kako bi se zadovoljili očekivani zahtjevi korisnika i utvrditi potrebe obrade podataka.

Na temelju takvog opisa u fazi projektiranja baze podataka utvrđuje se sastav i struktura podataka o predmetnom području koji bi trebali biti u bazi i osigurati ispunjavanje potrebnih upita i zadataka korisnika. Struktura podataka predmetnog područja može se prikazati informacijsko-logičkim modelom. Na temelju ovog modela lako se može stvoriti relacijska baza podataka.

Faze projektiranja i izrade baze podataka određene su sljedećim redoslijedom:

‣‣‣ konstrukcija informacijsko-logičkog modela podataka predmetnog područja;

‣‣‣ određivanje logičke strukture relacijske baze podataka;

‣‣‣ projektiranje tablica baze podataka;

‣‣‣ stvaranje podatkovne sheme;

‣‣‣ unos podataka u tablice (izrada zapisa);

‣‣‣ izrada potrebnih obrazaca, upita, makronaredbi, modula, izvješća;

‣‣‣ razvoj korisničkog sučelja.

U procesu razvoja podatkovnog modela iznimno je važno identificirati informacijske objekte koji zadovoljavaju zahtjeve normalizacije podataka i odrediti odnose među njima. Ovaj model omogućuje stvaranje relacijske baze podataka bez dupliciranja, što osigurava jednokratni unos podataka tijekom početnog učitavanja i prilagodbi, kao i cjelovitost podataka kada se naprave promjene.

Pri razvoju modela podataka mogu se koristiti dva pristupa. U prvom pristupu prvo se utvrđuju glavni zadaci za čije se rješavanje gradi baza, utvrđuju se podatkovne potrebe zadataka te se sukladno tome određuje sastav i struktura informacijski objekti. Na drugom pristupu Odmah se postavljaju tipski objekti predmetnog područja. Najracionalnija kombinacija oba pristupa. To je zbog činjenice da na početni stadij U pravilu ne postoje iscrpne informacije o svim zadacima. Korištenje takve tehnologije je tim više opravdano jer fleksibilni alati za izradu relacijskih baza podataka omogućuju izmjene baze podataka i modificiranje njezine strukture u bilo kojoj fazi razvoja bez oštećenja prethodno unesenih podataka.

Proces identificiranja informacijskih objekata predmetnog područja koji zadovoljavaju zahtjeve normalizacije može se provesti na temelju intuitivnog ili formalnog pristupa. Teorijske osnove formalni pristup razvijeni su i cjelovito prikazani u monografijama o organizaciji baza podataka poznatog američkog znanstvenika J. Martina.

S intuitivnim pristupom lako se identificiraju informacijski objekti koji odgovaraju stvarnim objektima. Istodobno, dobiveni informacijsko-logički model, u pravilu, zahtijeva daljnje transformacije, posebice transformaciju viševrijednih odnosa između objekata. S ovim pristupom moguće su značajne pogreške ako nema dovoljno iskustva. Naknadna provjera usklađenosti sa zahtjevima normalizacije obično pokazuje iznimnu važnost razjašnjavanja informacijskih objekata.

Razmotrimo formalna pravila koja se mogu koristiti za identifikaciju informacijskih objekata.

‣‣‣ na temelju opisa predmetnog područja identificirati dokumente i njihove atribute koji će se pohraniti u bazu podataka;

‣‣‣ definirati funkcionalne ovisnosti između atributa;

‣‣‣ odabrati sve zavisne atribute i za svaki označiti sve njegove ključne atribute, tj. one o kojima ovisi;

‣‣‣ Grupirajte atribute koji jednako ovise o ključnim atributima. Rezultirajuće skupine zavisnih atributa, zajedno sa svojim ključnim atributima, tvore informacijske objekte.

Prilikom definiranja logičke strukture relacijske baze podataka temeljene na modelu, svaki informacijski objekt je adekvatno predstavljen relacijskom tablicom, a odnosi između tablica odgovaraju odnosima između informacijskih objekata.

Tijekom procesa stvaranja, tablice baze podataka koje odgovaraju informacijski objekti konstruirani model podataka. Zatim se može izraditi podatkovna shema u kojoj se bilježe postojeće logičke veze između tablica. Ove veze odgovaraju vezama informacijskih objekata. Shema podataka može specificirati parametre za održavanje cjelovitosti baze podataka ako je model podataka razvijen u skladu sa zahtjevima normalizacije. Integritet podataka znači da baza podataka ima uspostavljene i ispravno održavane odnose između zapisa različitih tablica prilikom učitavanja, dodavanja i brisanja zapisa u povezanim tablicama, kao i prilikom mijenjanja vrijednosti ključnih polja.

Nakon formiranja sheme podataka upisuju se konzistentni podaci iz dokumenata predmetnog područja.

Na temelju kreirane baze podataka generiraju se potrebni upiti, obrasci, makronaredbe, moduli, izvještaji koji vrše potrebnu obradu podataka baze i njihovu prezentaciju.

Korištenjem ugrađenih alata i alata baze podataka kreira se baza podataka korisničko sučelje, omogućujući vam upravljanje procesima unosa, pohranjivanja, obrade, ažuriranja i prezentiranja podataka baze podataka.

2 Dizajniranje baze podataka temeljene na modelu objektnog odnosa

Postoji niz tehnika za stvaranje informacijskih i logičkih modela. Jedna od trenutno najpopularnijih metoda za razvoj modela koristi ERD (Entity-Relationship Diagrams). U literaturi na ruskom jeziku ti se dijagrami nazivaju "objekt - odnos" ili "suština - veza". ERD model predložio je Peter Ping Shen Chen 1976. godine. Do danas je razvijeno nekoliko njegovih varijanti, ali sve se temelje na grafičkim dijagramima koje je predložio Chen. Dijagrami se sastoje od malog broja komponenti. Zbog jasnoće njihove prezentacije naširoko se koriste u CASE (Computer Aided Software Engineering) alatima.

Pogledajmo korištenu terminologiju i oznake.

Entitet- stvarni ili izmišljeni objekt koji je značajan za predmetno područje koje se razmatra, informacije o kojima se pohranjuju.

Svaki entitet mora imati jedinstveni identifikator. Svaki primjerak entiteta mora biti jedinstveno identificiran i odvojen od svih drugih primjeraka danog tipa (entiteta). Svaki entitet mora imati određena svojstva:

‣‣‣ imaju jedinstveno ime; Štoviše, isto tumačenje (definicija entiteta) uvijek se mora primijeniti na ovo ime. I obrnuto: isto tumačenje ne može se primijeniti na različita imena, osim ako se radi o pseudonimima;

‣‣‣ imaju jedan ili više atributa koji ili pripadaju entitetu ili ih on nasljeđuje kroz odnos;

‣‣‣ imaju jedan ili više atributa koji jedinstveno identificiraju svaki primjerak entiteta.

Subjekt mora biti neovisan ili ovisan. Znak ovisnog entiteta je prisutnost atributa naslijeđenih kroz odnos (slika 1.).

Odnos- imenovana veza između dva entiteta značajna za predmetno područje koje se razmatra. Jedan od entiteta koji sudjeluje u povezivanju je neovisan, obično se naziva nadređeni entitet, drugi je zavisan, obično se naziva podređeni entitet ili entitet potomak. Obično je svaka instanca nadređenog entiteta povezana s proizvoljnim (uključujući nula) brojem instanci podređenog entiteta. Svaka instanca entiteta djeteta pridružena je točno jednoj instanci entiteta roditelja. Međutim, instanca entiteta djeteta može postojati samo ako postoji entitet roditelj.

Vezi se daje ime, izraženo gramatičkim obratom glagola i postavljeno blizu linije veze. Svako ime odnos između dva zadana entiteta mora biti jedinstven, ali nazivi odnosa u modelu ne moraju biti jedinstveni. Svaka veza ima definiciju. Definicija odnosa se formira kombinacijom imena nadređenog entiteta, naziva odnosa, izraza stupnja povezanosti i naziva podređenog entiteta.

‣‣‣ prodavatelj može primiti naknadu za jedan ili više ugovora;

‣‣‣ ugovor mora inicirati točno jedan Prodavatelj.

Na dijagramu je veza prikazana kao segment (polilinija). Na krajevima segmenta koriste se posebni simboli (slika 2) za označavanje stupnja povezanosti. Istodobno, priroda linije - isprekidana ili čvrsta - ukazuje na obveznu prirodu veze.

Atribut- bilo koje obilježje subjekta koje je značajno za predmetno područje koje se razmatra. Namijenjen mu je kvalificirati, identificirati, klasificirati, kvantificirati ili izraziti stanje entiteta. Atribut predstavlja vrstu karakteristika (svojstava) povezanih sa skupom stvarnih ili apstraktnih objekata (ljudi, mjesta, događaji, stanja, ideje, parovi objekata itd.) (slika 3). Instanca atributa- ovo je određena karakteristika određene instance entiteta. Instanca atributa definirana je vrstom karakteristike (na primjer, "Boja") i njezinom vrijednošću (na primjer, "ljubičasta"), koja se naziva vrijednost atributa. U ER modelu, atributi su povezani s određenim entitetima. Svaki primjerak entiteta mora imati jednu specifičnu vrijednost za svaki od svojih atributa.

Jedinstveni identifikator je atribut ili skup atributa i/ili odnosa koji jedinstveno karakteriziraju svaki primjerak danog tipa entiteta. U slučaju potpune identifikacije, instanca danog tipa entiteta u potpunosti je identificirana vlastitim ključnim atributima, inače u identifikaciji sudjeluju i atributi drugog entiteta, roditelja.

Priroda identifikacije prikazana je dijagramom na komunikacijskoj liniji (slika 4).

Svaki je atribut identificiran jedinstvenim imenom, izraženim gramatičkom imeničkom frazom koja opisuje karakteristiku koju atribut predstavlja. Atributi su predstavljeni kao popis imena unutar pridruženog bloka entiteta, pri čemu svaki atribut zauzima zaseban red. Atributi koji definiraju primarni ključ smješteni su na vrhu popisa i označeni znakom ʼʼ#ʼʼ.

Svaki entitet mora imati barem jedan mogući ključ. Ključ entiteta kandidata je jedan ili više atributa čije vrijednosti jedinstveno identificiraju svaku instancu entiteta. Kada postoji više mogućih ključeva, jedan od njih je označen kao primarni ključ, a ostali kao alternativni ključevi.

Danas je na temelju Chenova pristupa stvorena IDEF1X metodologija koja je osmišljena uzimajući u obzir zahtjeve poput jednostavnosti učenja i mogućnosti automatizacije. IDEFlX dijagrame koristi niz uobičajenih CASE alata (osobito ERwin, Design/IDEF).

Entitet u metodologiji IDEF1X obično se naziva neovisan o identifikatoru ili jednostavno neovisan ako se svaka instanca entiteta mora jedinstveno identificirati bez definiranja njegovih odnosa s drugim entitetima. Entitet se obično naziva ovisnim o identifikatoru ili jednostavno ovisnim ako nedvosmislena identifikacija instance entiteta ovisi o njegovom odnosu s drugim entitetom (slika 5).

Svaki entitet dobiva jedinstveno ime i broj, odvojen kosom crtom ʼʼ/ʼʼ i postavljen iznad bloka.

Ako je instanca entiteta djeteta jedinstveno određena svojim odnosom s roditeljskim entitetom, tada se odnos obično naziva identifikacijskim, inače - neidentifikacijskim.

Identifikacijski odnos između nadređenog entiteta i podređenog entiteta prikazan je kao puna linija. Na sl. 5: Br. 2 - ovisan entitet, Odnos 1 - identifikacijski odnos. Entitet dijete u odnosu identiteta je entitet ovisan o identifikatoru. Nadređeni entitet u odnosu identiteta mora biti i entitet neovisan i entitet ovisan o identitetu (ovo je određeno njegovim odnosima s drugim entitetima).

Isprekidana linija predstavlja neidentifikacijski odnos. Na sl. 5: Br. 4 - neovisni entitet, Odnos 2 - neidentificirajući odnos. Entitet dijete u neidentifikacijskom odnosu bit će neovisan o identifikatoru osim ako nije također entitet dijete u nekom identifikacijskom odnosu.

Odnos se može dodatno definirati određivanjem stupnja ili kardinalnosti (broj instanci entiteta djeteta koji može postojati za svaku instancu entiteta roditelja). IDEF1X izražava sljedeće moći veze:

‣‣‣ Svaka instanca nadređenog entiteta može imati nula, jednu ili više instanci entiteta djeteta povezanih s njom;

‣‣‣ Svaka instanca roditeljskog entiteta mora imati najmanje jednu instancu entiteta djeteta pridruženu sebi;

‣‣‣ Svaka instanca nadređenog entiteta mora imati najviše jednu instancu entiteta djeteta pridruženu sebi;

‣‣‣ Svaka instanca nadređenog entiteta povezana je s određenim fiksnim brojem instanci podređenog entiteta.

Snaga komunikacije je naznačena kao što je prikazano na sl. 6 (zadana snaga - N).

Rezultat je informacijsko-logički model, koji se koristi u brojnim uobičajenim CASE alatima, kao što su ERwin, Design/IDEF. S druge strane, CASE tehnologije imaju veliki potencijal u razvoju baza podataka i informacijskih sustava, naime, povećavaju produktivnost rada, poboljšavaju kvalitetu softverskih proizvoda i podržavaju jedinstven i dosljedan stil rada.

Faze projektiranja baze podataka - pojam i vrste. Klasifikacija i značajke kategorije "Faze projektiranja baze podataka" 2017., 2018.

Bit dizajna baze podataka, kao i svakog drugog procesa projektiranja, je kreiranje opisa novog sustava koji dosad nije postojao u ovom obliku, a koji je, kada je implementiran, sposoban za očekivano funkcioniranje u odgovarajućim uvjetima. Iz ovoga proizlazi da faze projektiranja baze podataka moraju dosljedno i logično odražavati bit ovog procesa.

Sadržaj dizajna baze podataka i faze

Namjera dizajna temelji se na nekoj formuliranoj društvenoj potrebi. Ova potreba ima okruženje za svoju pojavu i ciljanu publiku potrošača koji će koristiti rezultat dizajna. Posljedično, proces projektiranja baze podataka započinje proučavanjem date potrebe sa stajališta potrošača i funkcionalnog okruženja njezinog namjeravanog smještaja. Naime, prva faza je prikupljanje informacija i definiranje modela predmetnog područja sustava, kao i pogled na njega sa stajališta ciljne publike. Općenito, da bi se odredili sistemski zahtjevi, određuje se opseg aktivnosti kao i granice aplikacija baze podataka.

Zatim, dizajner, koji već ima određene ideje o tome što treba stvoriti, pojašnjava zadatke koje navodno rješava aplikacija, stvara njihov popis (osobito ako je razvoj projekta velika i složena baza podataka), pojašnjava redoslijed rješavanja probleme i provodi analizu podataka. Ovaj proces je također faza projektiranja, ali obično u strukturi dizajna ti koraci su apsorbirani od strane pozornice idejno rješenje– faza identifikacije objekata, atributa, veza.

Izrada konceptualnog (informacijskog modela) uključuje prethodno formiranje konceptualnih zahtjeva korisnika, uključujući zahtjeve za aplikacije koje se možda neće odmah implementirati, ali uzimajući u obzir koje će poboljšati funkcionalnost sustava u budućnosti. Baveći se reprezentacijama skupnih apstraktnih objekata (bez navođenja metoda fizičke pohrane) i njihovim odnosima, konceptualni model u biti odgovara modelu domene. Stoga se u literaturi prva faza projektiranja baze podataka naziva infološki dizajn.

Zatim, zasebna faza (ili dodatak prethodnoj) slijedi faza formiranja zahtjeva za radnu okolinu, gdje se procjenjuju zahtjevi za računalnim resursima koji mogu osigurati funkcioniranje sustava. Sukladno tome, što je veći obujam projektirane baze podataka, što je veća aktivnost korisnika i intenzitet zahtjeva, to su veći zahtjevi za resursima: za konfiguraciju računala, za tip i verziju. operativni sustav. Na primjer, višekorisnički način rada buduće baze podataka zahtijeva mrežna veza korištenje operativnog sustava prikladnog za multitasking.

Sljedeći korak je da projektant odabere sustav za upravljanje bazom podataka (DBMS), kao i softverske alate. Nakon toga se konceptualni model mora prenijeti u podatkovni model kompatibilan s odabranim sustavom upravljanja. Ali to često uključuje dopune i izmjene konceptualnog modela, budući da se međusobne veze između objekata koje se odražavaju u konceptualnom modelu ne mogu uvijek implementirati pomoću sredstava danog DBMS-a.

Ova okolnost određuje pojavu sljedeće faze - pojavu konceptualnog modela opskrbljenog sredstvima specifičnog DBMS-a. Ovaj korak odgovara fazi logičkog dizajna (stvaranje logičkog modela).

Konačno, posljednja faza dizajna baze podataka je fizički dizajn - faza povezivanja logičke strukture i fizičkog okruženja za pohranu.

Dakle, glavne faze projektiranja u detaljnom obliku prikazane su u sljedećim fazama:

• informacijski dizajn,
• formiranje zahtjeva za radnu okolinu
• odabir sustava upravljanja i softver DB,
• logičan dizajn,
• fizički dizajn

O ključnim će se detaljnije raspravljati u nastavku.

Infoološki dizajn

Identifikacija entiteta čini semantičku osnovu infološkog dizajna. Entitet je ovdje objekt (apstraktan ili konkretan), informacije o kojem će se akumulirati u sustavu. U infološkom modelu predmetnog područja struktura i dinamička svojstva predmetnog područja opisani su pojmovima razumljivim za korisnika koji ne ovise o specifičnoj implementaciji baze podataka. Ali pojmovi su uzeti na standardnoj ljestvici. To jest, opis se ne izražava kroz pojedinačne objekte predmetnog područja i njihove odnose, već kroz:

• opis tipova objekata,
• ograničenja cjelovitosti povezana s opisanim tipom,
• procesi koji dovode do evolucije predmetnog područja - njegovog prijelaza u drugo stanje.

Informacijski model može se izraditi pomoću nekoliko metoda i pristupa:

1. Funkcionalni pristup temelji se na dodijeljenim zadacima. Naziva se funkcionalnom jer se koristi ako su poznate funkcije i zadaće osoba koje će uz pomoć izrađene baze podataka opsluživati ​​njihove informacijske potrebe.
2. Predmetni pristup usmjeren je na informacije o informacijama koje će biti sadržane u bazi podataka, unatoč činjenici da struktura upita možda nije definirana. U ovom slučaju istraživanje predmetnog područja usmjereno je na njegov najadekvatniji prikaz u bazi podataka u kontekstu puni spektar očekivani zahtjevi za informacijama.
3. Integrirani pristup koji koristi metodu "entitet-odnos" kombinira prednosti prethodne dvije. Metoda se svodi na dijeljenje cjelokupnog predmetnog područja na lokalne dijelove koji se zasebno modeliraju i zatim ponovno spajaju u cjelinu.

Budući da je korištenje metode "entitet-odnos" kombinirana metoda projektiranja u ovoj fazi, ona najčešće postaje prioritet.

Kada su metodički podijeljeni, lokalni prikazi trebaju, ako je moguće, uključivati ​​informacije koje bi bile dostatne za rješavanje zasebnog problema ili za zadovoljenje potreba određene skupine potencijalnih korisnika. Svako od ovih područja sadrži oko 6-7 entiteta i odgovara zasebnoj vanjskoj aplikaciji.

Ovisnost entiteta ogleda se u njihovoj podjeli na jake (baza, roditelj) i slabe (dijete). Jaka cjelina (na primjer, čitatelj u knjižnici) može sama postojati u bazi podataka, ali slaba cjelina (na primjer, pretplata ovog čitatelja) je "pripojena" na jaku i ne postoji zasebno.

Potrebno je razdvojiti koncepte “instance entiteta” (objekt karakteriziran određenim vrijednostima svojstava) i koncept “tipa entiteta” - objekt karakteriziran zajedničkim imenom i popisom svojstava.

Za svaki pojedinačni entitet odabiru se atributi (skup svojstava) koji, ovisno o kriteriju, mogu biti:

• identificiranje (sa jedinstvena vrijednost za entitete ove vrste, što ih čini potencijalnim ključevima) ili opisnim;
• s jednom ili više vrijednosti (s odgovarajućim brojem vrijednosti za instancu entiteta);
• osnovni (neovisni o drugim atributima) ili izvedeni (izračunati na temelju vrijednosti drugih atributa);
• jednostavna (nedjeljiva jednokomponentna) ili složena (sastavljena od više komponenti).

Nakon toga se specificira atribut, specificiraju se veze u lokalnom prikazu (podijeljene na izborne i obavezne) i spajaju se lokalni pogledi ako je broj lokalnih područja do 4-5, mogu se kombinirati u jednom koraku . Ako se broj povećava, binarno spajanje područja odvija se u nekoliko faza.

Tijekom ove i drugih međufaza odražava se iterativna priroda dizajna, koja se ovdje izražava u činjenici da je za uklanjanje proturječja potrebno vratiti se na fazu modeliranja lokalnih prikaza radi pojašnjenja i promjene (na primjer, promijeniti ista imena semantički različitih objekata ili koordinirati atribute cjelovitosti na istim atributima u različitim aplikacijama).

Odabir upravljačkog sustava i softvera baze podataka

Praktična implementacija informacijskog sustava ovisi o izboru sustava za upravljanje bazom podataka. Najznačajniji kriteriji u procesu odabira su sljedeći parametri:

• vrsta podatkovnog modela i njegova usklađenost s potrebama predmetnog područja,
• rezervu mogućnosti u slučaju proširenja informacijskog sustava,
• izvedbene karakteristike odabranog sustava,
• radna pouzdanost i pogodnost DBMS-a,
• alati namijenjeni osoblju za administraciju podataka,
• trošak samog DBMS-a i dodatnog softvera.

Pogreške u odabiru DBMS-a će gotovo sigurno naknadno izazvati potrebu za prilagodbom konceptualnih i logičkih modela.

Logički dizajn baze podataka

Logička struktura baze podataka mora odgovarati logičkom modelu predmetnog područja i voditi računa o povezanosti podatkovnog modela s podržanim DBMS-om. Stoga faza počinje odabirom podatkovnog modela, pri čemu je važno voditi računa o njegovoj jednostavnosti i jasnoći.

Poželjno je kada se prirodna struktura podataka podudara s modelom koji je predstavlja. Tako, na primjer, ako su podaci prikazani u obliku hijerarhijske strukture, onda je bolje odabrati hijerarhijski model. Međutim, u praksi je takav izbor često određen sustavom upravljanja bazom podataka, a ne modelom podataka. Stoga se konceptualni model zapravo prevodi u podatkovni model koji je kompatibilan s odabranim sustavom upravljanja bazom podataka.

Ovo također odražava prirodu dizajna, koja dopušta mogućnost (ili nužnost) povratka na konceptualni model kako bi se on promijenio ako se tamo reflektirani odnosi između objekata (ili atributa objekta) ne mogu implementirati pomoću odabranog DBMS-a.

Po završetku faze treba generirati sheme baze podataka obje razine arhitekture (konceptualne i vanjske), kreirane u jeziku za definiranje podataka koji podržava odabrani DBMS.

Sheme baze podataka formiraju se pomoću jednog od dva različita pristupa:

• ili korištenje pristupa odozdo prema gore, kada rad dolazi s nižih razina definiranja atributa, grupiranih u odnose koji predstavljaju objekte, na temelju odnosa koji postoje između atributa;
• ili korištenjem obrnutog pristupa odozgo prema dolje, koji se koristi kada se broj atributa značajno poveća (do stotina i tisuća).

Drugi pristup uključuje identificiranje niza entiteta visoke razine i njihovih odnosa s naknadnim detaljiziranjem do tražene razine, što se odražava, na primjer, u modelu kreiranom na temelju metode "entitet-odnos". Ali u praksi se obično kombiniraju oba pristupa.

Dizajn fizičke baze podataka

Na sljedeća faza fizičkog dizajna baze podataka, logička struktura se prikazuje u obliku skladišne ​​strukture baze podataka, odnosno povezuje se s takvim fizičkim skladišnim okruženjem u kojem će podaci biti smješteni što učinkovitije. Ovdje je shema podataka detaljno opisana, navodeći sve vrste, polja, veličine i ograničenja. Uz izradu indeksa i tablica definirani su osnovni upiti.

Konstrukcija fizičkog modela uključuje rješavanje uvelike kontradiktornih problema:

1. zadaci minimiziranja prostora za pohranu podataka,
2. ciljeve postizanja integriteta, sigurnosti i maksimalne performanse.

Drugi zadatak je u sukobu s prvim jer, na primjer:

• da bi transakcije učinkovito funkcionirale, morate rezervirati prostor na disku za privremene objekte,
• za povećanje brzine pretraživanja potrebno je izraditi indekse čiji je broj određen brojem svih mogućih kombinacija polja uključenih u pretraživanje,
• Za vraćanje podataka izradit će se sigurnosne kopije baze podataka i voditi dnevnik svih promjena.

Sve to povećava veličinu baze podataka, pa projektant traži razumnu ravnotežu u kojoj se problemi optimalno rješavaju inteligentnim smještajem podataka u memorijski prostor, ali ne nauštrb sigurnosti baze podataka, koja uključuje i zaštitu od neovlaštenog pristupa i zaštitu od neuspjeha.

Za dovršetak izrade fizičkog modela procjenjuju se njegove operativne karakteristike (brzina pretraživanja, učinkovitost izvršenja upita i potrošnja resursa, ispravnost operacija). Ponekad je ova faza, poput faza implementacije baze podataka, testiranja i optimizacije, kao i održavanja i rada, izdvojena iz neposrednog dizajna baze podataka.

Federalna agencija za obrazovanje

Državna obrazovna ustanova visokog stručnog obrazovanja

DRŽAVNO SVEUČILIŠTE AMUR

(GOUVPO "AmSU")

TEST

u disciplini "Informacijski sustavi u ekonomiji"

na temu: “Principi izgradnje i faze projektiranja baze podataka”

Izvršitelj

student grupe C – 81 N.A. Vokhmyanina

Nadzornik

Izv.prof.dr.sc. D. G. Ševko

Blagoveščensk 2010

Uvod

1. Načela izgradnje baze podataka

2. Koncepti izgradnje baze podataka

3. Faze projektiranja baze podataka

Bibliografija

UVOD

Percepcija stvarnog svijeta može se povezati s nizom različitih, iako ponekad međusobno povezanih pojava. Od davnina su ljudi pokušavali opisati ove pojave (čak i kada ih nisu mogli razumjeti). Taj se opis naziva podacima.

Tradicionalno, podaci se prikupljaju pomoću posebnih sredstava komunikacije, na primjer, korištenjem prirodnog jezika u određenom mediju.

Trenutno uspješno funkcioniranje različitih tvrtki, organizacija i poduzeća jednostavno nije moguće bez razvijenog informacijskog sustava koji vam omogućuje automatizaciju prikupljanja i obrade podataka. Obično se baza podataka stvara za pohranu i pristup podacima koji sadrže informacije o određenom predmetnom području.

Baza podataka (DB)- imenovana zbirka podataka koja odražava stanje objekata i njihovih odnosa u predmetnom području koje se razmatra.

Predmetno područje obično se shvaća kao određeno područje ljudske aktivnosti ili područje stvarnog svijeta koje je predmet proučavanja za organiziranje upravljanja i automatizacije, na primjer, poduzeće, sveučilište itd.

Sustav za upravljanje bazom podataka (DBMS)- skup jezičnih i programskih alata namijenjenih stvaranju, popunjavanju, ažuriranju i brisanju baza podataka.

Programi s kojima korisnici rade s bazom podataka nazivaju se aplikacijama.

1. NAČELA KONSTRUKCIJE BAZA PODATAKA

Sljedeći osnovni zahtjevi odnose se na moderne baze podataka, a time i na DBMS na kojem su izgrađene.

1. Visoke performanse (kratko vrijeme odgovora na zahtjev).

Vrijeme odgovora je vremenski interval od trenutka slanja zahtjeva prema bazi podataka do stvarnog primitka podataka. Sličan pojam je vrijeme pristupa - vremenski interval između izdavanja naredbe za pisanje (čitanje) i stvarnog primitka podataka. Pristup se odnosi na operaciju pretraživanja, čitanja ili pisanja podataka. Često se operacije pisanja, brisanja i mijenjanja podataka nazivaju operacijama ažuriranja.

2. Jednostavno ažuriranje podataka.

3. Neovisnost podataka.

4. Dijeljenje podataka među mnogim korisnicima.

5. Sigurnost podataka - zaštita podataka od namjerne ili nenamjerne povrede povjerljivosti, iskrivljavanja ili uništenja.

6. Standardizacija izgradnje i rada baze podataka (zapravo DBMS-a).

8. Prijateljsko korisničko sučelje.

Najvažnija su prva dva kontradiktorna zahtjeva: povećane performanse zahtijeva pojednostavljenje strukture baze podataka, što pak komplicira proceduru ažuriranja podataka, povećava njihovu zalihost.

Neovisnost podataka- mogućnost promjene logičke i fizičke strukture baze podataka bez mijenjanja percepcije korisnika.

Neovisnost podataka pretpostavlja nepromjenjivost prirode pohrane podataka, softvera i hardvera. Osigurava minimalne promjene strukture baze podataka kada se promijeni strategija pristupa podacima i struktura samih izvornih podataka. To se postiže "guranjem" svih promjena u fazu konceptualnog i logičkog projektiranja s minimalnim promjenama u fazi fizičkog projektiranja.

Sigurnost podataka uključuje njihovu cjelovitost i zaštitu.

Cjelovitost podataka - otpornost pohranjenih podataka na oštećenje i uništenje povezano s greškama tehnička sredstva, sistemske greške i pogrešne radnje korisnika.

Pretpostavlja se:

1. nepostojanje netočno upisanih podataka ili dva istovjetna upisa o istoj činjenici;

2. zaštita od grešaka prilikom ažuriranja baze podataka;

3. nemogućnost brisanja (ili kaskadnog brisanja) povezanih podataka iz različitih tablica;

4. neiskrivljenje podataka pri radu u višekorisničkom načinu rada iu distribuiranim bazama podataka;

5. sigurnost podataka u slučaju kvara opreme (oporavak podataka).

Integritet osiguravaju okidači integriteta - posebni aplikacijski programi koji rade pod određenim uvjetima. Zaštita podataka od neovlaštenog pristupa uključuje ograničavanje pristupa povjerljivim podacima i može se postići:

1. uvođenje sustava zaporki;

2. dobivanje dopuštenja od administratora baze podataka (DBA);

4. formiranje tipova - tablica izvedenih iz izvornih i namijenjenih određenim korisnicima.

Zadnje tri procedure lako se izvode unutar Structured Query Language - SQL, koji se često naziva SQL2.

Standardizacija osigurava kontinuitet generacija DBMS-a i pojednostavljuje interakciju baza podataka iste generacije DBMS-a s istim i različitim modelima podataka. Standardizacija (ANSI/SPARC) je u velikoj mjeri provedena u pogledu korisničkog sučelja DBMS-a i SQL jezika. To je omogućilo uspješno rješavanje problema interakcije između različitih relacijski DBMS i korištenjem SQL jezika i korištenjem aplikacije Open DataBase Connection (ODBC). U ovom slučaju, i lokalni i daljinski pristup na podatke (tehnologija klijent/poslužitelj ili mrežna opcija).

2. KONCEPT IZGRADNJE BAZE PODATAKA

Postoje dva pristupa izgradnji baze podataka, temeljena na dva pristupa kreiranju automatiziranog sustava upravljanja (ACS).

Prvi od njih, široko korišten u 80-ima i stoga tzv klasična (tradicionalna), povezan s automatizacijom protoka dokumenata (skup dokumenata koji se kreću tijekom rada poduzeća). Izvorne i izlazne koordinate bili su dokumenti, kao što se može vidjeti iz primjera 1.

Korištena je sljedeća teza. Podaci su manje mobilni od algoritama, stoga biste trebali stvoriti univerzalnu bazu podataka koja se zatim može koristiti za bilo koji algoritam. Međutim, ubrzo je postalo jasno da je stvaranje univerzalne baze podataka problematično. Koncept integracije podataka, koji je donedavno bio dominantan, pokazao se neodrživim naglim porastom njihovog volumena. Štoviše, počele su se pojavljivati ​​aplikacije (npr. tekst, grafički urednici), temeljen na široko korištenim standardnim algoritmima.

Do 90-ih formiran je drugi, moderan pristup vezano za automatizaciju upravljanja. Uključuje inicijalnu identifikaciju standardnih aplikativnih algoritama (poslovnih algoritama u stranoj terminologiji) pod kojima se definiraju podaci, a time i baza podataka. Objektno orijentirano programiranje samo je povećalo važnost ovog pristupa.

Baza podataka može raditi u jednokorisničkom i višekorisničkom načinu rada (više korisnika povezuje se na jedno računalo preko različitih priključaka).

Oni koriste dizajn baze podataka odozdo prema gore i odozgo prema dolje. Prvi se koristi u distribuiranim bazama podataka kada se integriraju dizajnirane lokalne baze podataka, koje se mogu implementirati korištenjem razni modeli podaci. Tipičniji za centralizirane baze podataka je dizajn odozgo prema dolje.

3. FAZE DIZAJNA BAZE PODATAKA

Dizajn baze podataka odvija se u četiri faze.

Na pozornici formulacija i analiza zahtjeva Uspostavljeni su ciljevi organizacije i određeni zahtjevi za bazu podataka. Sastoje se od općih zahtjeva definiranih u odjeljku 1. i posebnih zahtjeva. Za formuliranje specifičnih zahtjeva obično se koristi tehnika intervjuiranja osoblja. različite razine upravljanje. Svi zahtjevi su dokumentirani u obliku dostupnom krajnjem korisniku i dizajneru baze podataka.

Pozornica idejno rješenje je opisati i sintetizirati zahtjevi za informacijama korisnika u početni projekt baze podataka. Izvor podataka može biti skup korisničkih dokumenata u klasičnom pristupu ili aplikativni algoritmi (poslovni algoritmi) u modernom pristupu. Rezultat ove faze je prikaz na visokoj razini (u obliku sustava tablica baze podataka) korisničkih informacijskih zahtjeva na temelju različitih pristupa.

Prvo se odabire model baze podataka. Zatim se kreira struktura baze podataka koja se popunjava podacima pomoću sustava izbornika, obrazaca na ekranu ili u načinu prikaza tablice baze podataka. Ovdje se zaštita i integritet (uključujući referentni integritet) podataka osigurava pomoću DBMS-a ili konstruiranjem okidača.

U tijeku logičan dizajn prikaz podataka na visokoj razini pretvara se u strukturu korištenog DBMS-a. Glavni cilj ove faze je eliminirati redundanciju podataka pomoću posebnih pravila normalizacije. Svrha normalizacije je minimiziranje ponavljanja podataka i mogućih strukturnih promjena u bazi podataka tijekom postupaka ažuriranja. To se postiže dijeljenjem (dekompozicijom) jedne tablice na dvije ili više i zatim korištenjem navigacijskih operacija u upitima. Imajte na umu da navigacijsko pretraživanje smanjuje performanse baze podataka, tj. povećava vrijeme odgovora na zahtjev. Rezultirajuća logička struktura baze podataka može se kvantificirati korištenjem razne karakteristike(broj pristupa logičkim zapisima, količina podataka u svakoj aplikaciji, ukupna količina podataka). Na temelju ovih procjena, logička se struktura može poboljšati kako bi se postigla veća učinkovitost.

Koraci dizajna baze podataka

Proces projektiranja uključuje sljedeće faze:

• 1. Infološki dizajn.
• 2. Određivanje zahtjeva za radnu okolinu u kojoj će informacijski sustav djelovati.
• 3. Odabir sustava za upravljanje bazom podataka (DBMS) i drugih programskih alata.
• 4. Datalogical (logički) dizajn baze podataka.
• 5. Fizički dizajn baze podataka.

U prvoj fazi programer (administrator baze podataka) kombinira privatne poglede na sadržaj baze podataka dobiven iz intervjua s korisnicima sa svojim vlastitim pogledima na podatke koji bi mogli biti potrebni u budućim aplikacijama, stvarajući generalizirani neformalni opis baze podataka. Ovaj opis je napravljen korištenjem prirodnog jezika, matematičke formule, tablice, grafikone i druge alate koji su razumljivi svim ljudima koji rade na dizajnu baze podataka. Ovaj opis predmetnog područja naziva se infološki model podataka.

Informološki model podataka je model orijentiran na čovjeka i potpuno je neovisan o fizičkim parametrima okruženja za pohranu podataka. Takav medij za pohranu podataka može biti ljudska memorija, a ne računalo. Stoga se informacijski model ne mijenja sve dok neke promjene u stvarnom svijetu ne zahtijevaju odgovarajuće izmjene kako bi ovaj model nastavio odražavati predmetno područje.

Preostali modeli, podatkovni i fizički, računalno su orijentirani. Uz njihovu pomoć, DBMS omogućuje programima i korisnicima da pristupe pohranjenim podacima samo svojim imenom, bez brige o fizičkoj lokaciji tih podataka. Potrebne podatke pronalazi DBMS na vanjskim uređajima za pohranu pomoću fizički model podataka.

Budući da se navedeni pristup provodi pomoću određenog DBMS-a, modeli moraju biti opisani u jeziku opisa podataka ovog DBMS-a. Ovaj opis se zove podatkovni model podataka.

Arhitektura na tri razine (infološka, ​​podatkovna i fizičke slojeve) omogućuje vam da osigurate neovisnost pohranjenih podataka od programa koji ih koriste. Programer može, ako je potrebno, prepisati pohranjene podatke na druge medije za pohranu ili reorganizirati njihovu fizičku strukturu mijenjajući samo fizički model podataka. DBA može povezati bilo koji broj novih korisnika (novih aplikacija) na sustav, dodajući, ako je potrebno, podatkovni logički model. Navedene fizičke promjene i datum logički modeli neće biti primjećen od strane postojećih korisnika sustava (bit će im “transparentan”), kao što ni novi korisnici neće biti primjećeni. Stoga neovisnost podataka omogućuje razvoj sustava baze podataka bez ometanja postojećih aplikacija.

Infološki (informacijsko-logički) model. Cilj faze infološkog dizajna je dobiti semantičke (konceptualne) modele koji odražavaju predmetno područje i informacijske potrebe korisnika. Stoga se ova faza naziva i semantičko modeliranje. Semantičko modeliranje je modeliranje strukture podataka na temelju značenja tih podataka.

Koncept “Predmetno područje”- osnovno u teoriji baza podataka i nema strogu definiciju. To proizlazi iz pojmova “objekt” i “subjekt”. Predmetno područje(PO)- dio stvarnog svijeta koji treba proučavati s ciljem organiziranja kontrole i, u konačnici, automatizacije. Čini se da je softvera puno fragmenti, koje karakteriziraju mnogi objekti, mnogi procesi koji koriste objekte, kao i mnogi korisnici, karakterizirani jedinstvenim pogledom na predmetno područje.

Objekt nazivaju fenomenom vanjskog svijeta. To je ili nešto što stvarno postoji - osoba, proizvod, proizvod ili proces - upis rođenja, primitak robe, proizvodnja proizvoda. Svaki objekt ima ogroman broj svojstava.

Primjeri.

Objekt " ljudski"ima svojstva: visina, ime, datum rođenja...,

objekt - " Proizvod"ima svojstva: kvalitetu, datum proizvodnje, izgled….

Među objektima postoje brojne veze. Na primjer:

• · ljudski kupuje, prodaje, proizvodi Proizvod
• · Proizvod stvoreno, kupljeno, prodano ljudski.

Artikal - model stvarnog objekta, u kojem su zabilježena samo svojstva i veze dodijeljene IS-u. Ukupnost odabranih stavki tvori objektna jezgra predmetno područje i ukupnost njihovih odnosa - struktura fragmenta stvarnosti . Da. koncept "Subject Domain" odgovara gledištu potrošača na jezgru objekta: identificira samo one objekte, svojstva objekata i veze između objekata koji su vrijedni za IS i trebaju biti pohranjeni u bazi podataka.

Sve radnje za utvrđivanje jezgre predmetnog područja provode se u fazi analize IS-a.

Objektna jezgra sustava ne ostaje konstantna tijekom životnog ciklusa IS-a: objekti nestaju i pojavljuju se, mijenjaju se njihova svojstva i odnosi. Lanci tih promjena zabilježeni tijekom vremena nazivaju se putanje predmetnog područja, i ukupnost opća svojstva putanja - semantika domene

Dostupne su brojne tehnike modeliranja domene. Jedna od trenutno najpopularnijih tehnika temelji se na korištenju grafičkih dijagrama koji uključuju mali broj heterogenih ERD (Entity-Relationship Diagrams) komponenti. U literaturi na ruskom jeziku ti se dijagrami nazivaju "objekt - odnos" ili "entitet - veza".

ERD model je predložen 1976. Peter Ping-Sheng Chen. Naknadno su mnogi autori razvili vlastite verzije takvih modela: Martin notacija, IDEF1X notacija, Barker notacija), ali svi se temelje na grafičkim dijagramima koje je predložio Chen.

Većina suvremenih pristupa dizajnu relacijskih baza podataka temelji se na korištenju varijacija ER modela.

Zapravo, sve varijante dijagrama entitet-odnos proizlaze iz iste ideje - crtež je uvijek jasniji opis teksta. Svi takvi dijagrami koriste grafički prikaz entiteta domene, njihovih svojstava (atributa) i odnosa između entiteta.

Upoznat ćemo se s ER dijagramima u Barkerovoj notaciji, što je prilično lako razumjeti glavne ideje.

Osnovni pojmovi ER dijagrama. Glavni koncepti ER modela su entitet, odnos i atribut.

Za veću izražajnost i bolje razumijevanje naziv entiteta može biti popraćen primjerima specifičnih objekata ovaj tip.

Definicija 1. Suština je stvarni ili zamislivi objekt, informacije o kojem moraju biti pohranjene i dostupne. Entiteti mogu biti ljudi, mjesta, avioni, letovi, okus, boja itd.

Svaki entitet mora imati ime izraženo imenicom u jednini. U ovom slučaju, naziv entiteta je naziv tipa, a ne neke specifične instance ovog tipa. Koncept tipa entiteta odnosi se na skup homogenih pojedinaca, objekata, događaja ili ideja koji djeluju kao cjelina.

Primjeri entiteta mogu biti klase objekata kao što su "Dobavljač", "Zaposlenik", "Faktura".

Svaki entitet u modelu prikazan je kao pravokutnik koji sadrži naziv entiteta:

Definicija 2. Instanca entiteta je specifični predstavnik datog entiteta.

Na primjer, predstavnik entiteta "Zaposlenik" može biti "Zaposlenik Ivanov".

Instance entiteta moraju biti prepoznatljiv, tj. entiteti moraju imati neka svojstva koja su jedinstvena za svaku instancu tog entiteta.

Definicija 3. Atribut entiteta je imenovana karakteristika entiteta. Njegov naziv mora biti jedinstven za određeni tip entiteta, ali može biti isti za različite tipove entiteta (na primjer, BOJA se može definirati za mnoge entitete: PAS, AUTO, BOJA, itd.). Atributi se koriste za definiranje informacija koje treba prikupljati o entitetu. Primjeri atributa za entitet CAR su VRSTA, PROIZVODNJA, REGISTRACIJSKA TABLICA, BOJA itd.

Ovdje također postoji razlika između vrste atributa i instance. Vrsta atributa COLOR ima mnogo instanci ili vrijednosti: Crvena, Plava, Banana, Bijela noć itd., ali svakoj instanci entiteta dodijeljena je samo jedna vrijednost atributa.

Ne postoji apsolutna razlika između tipova entiteta i atributa. Atribut je takav samo u odnosu na tip entiteta. U drugom kontekstu, atribut može djelovati kao nezavisan entitet. Na primjer, za tvornicu automobila boja je samo atribut proizvodnog proizvoda, ali za tvornicu boja i lakova boja je tip entiteta.

Svaki atribut ima naziv koji je jedinstven unutar entiteta. Ime atributa mora biti izraženo kao imenica u jednini (po mogućnosti s karakterizirajućim pridjevima).

Primjeri atributa entiteta “Zaposlenik” mogu biti atributi kao što su “Poslovni broj”, “Prezime”, “Ime”, “Patronim”, “Pozicija”, “Plaća” itd.

Atributi su prikazani unutar pravokutnika koji definira entitet:

Atributi se mogu klasificirati u jedan od tri razne vrste: opisno, indikativno, pomoćno.

Opisni atributi predstavljaju činjenice svojstvene svakoj instanci entiteta.

Pokazivanje atributi se koriste za davanje naziva ili oznake instancama entiteta.

Pomoćni atributi se koriste za povezivanje instance jednog entiteta s instancom drugog. Atributi podliježu strogo definiranim pravilima.

Definicija 4. Ključ entiteta - minimalni skup atributa čije se vrijednosti mogu koristiti za jedinstveno pronalaženje tražene instance entiteta. Minimalnost znači da isključivanje bilo kojeg atributa iz skupa ne dopušta identifikaciju entiteta pomoću preostalih.

Na primjer, za entitet Raspored ključ je atribut Broj_leta ili postavite: Ishodišna_točka, Vrijeme polaska I Odredište(pod uvjetom da jedan avion leti od točke do točke u bilo kojem trenutku).

Entitet može imati nekoliko različitih ključeva.

Ključni atributi prikazani su podvučeni na dijagramu:

Definicija 5. Veza - ovo je neka vrsta asocijacije između dva entiteta. Jedan entitet može biti povezan s drugim entitetom ili sa samim sobom. Odnosi omogućuju jednom entitetu da pronađe druge entitete koji su mu povezani.

Ako je svrha baze podataka samo pohranjivanje pojedinačnih, nepovezanih podataka, tada bi njezina struktura mogla biti vrlo jednostavna. Međutim, jedan od glavnih zahtjeva za organiziranje baze podataka je osigurati mogućnost pronalaženja nekih entiteta prema vrijednostima drugih, za što je potrebno uspostaviti određene veze među njima. A budući da prave baze podataka često sadrže stotine ili čak tisuće entiteta, teoretski se između njih može uspostaviti više od milijun veza. Prisutnost takvog mnoštva veza određuje složenost informacijskih modela.

Na primjer, veze između entiteta mogu se izraziti sljedećim frazama - “JEDAN ZAPOSLENIK može imati više DJECE”, “Svaki ZAPOSLENIK mora biti upisan na točno jedan ODJEL”.

Grafički, odnos je prikazan linijom koja povezuje dva entiteta:

Svaka karika ima dva kraja i jedno ili dva imena. Ime se obično izražava u neodređenom glagolskom obliku: “imati”, “pripadati” itd. Svaki naziv odnosi se na svoj kraj veze. Ponekad se imena ne pišu jer su očita.

Svaka veza može imati jedno od sljedećeg vrste komunikacije :

Vrsta komunikacije jedan na jedan znači da je jedna instanca prvog entiteta (lijevo) povezana s jednom instancom drugog entiteta (desno). Odnos jedan-na-jedan najčešće ukazuje na to da zapravo imamo samo jedan entitet, netočno podijeljen na dva.

Vrsta komunikacije jedan-prema-više znači da je jedna instanca prvog entiteta (lijevo) povezana s nekoliko instanci drugog entiteta (desno). Ovo je najčešće korištena vrsta komunikacije. Lijevi entitet (na strani "jedan") se zove roditeljski , desno (sa strane "mnogo") - podružnica . (vidi sl. grafička slika komunikacije)

Vrsta komunikacije mnogi prema mnogima znači da svaka instanca prvog entiteta može biti povezana s višestrukim instancama drugog entiteta, a svaka instanca drugog entiteta može biti povezana s višestrukim instancama prvog entiteta. Vrsta odnosa više-prema-više je privremeni vrsta komunikacije prihvatljiva u ranim fazama razvoja modela. U budućnosti se ova vrsta odnosa mora zamijeniti s dva odnosa jedan prema više stvaranjem posrednog entiteta.

Svaka veza može imati jednu od dvije modalitete komunikacije :

Modalitet" Možda mogu biti povezani s jednom ili više instanci drugog entiteta, ili možda nije u vezi niti jedan primjerak.

Modalitet" morati " znači da instanca jednog entiteta mora biti povezan s najmanje jednim instanca drugog entiteta.

Komunikacija može imati drugačiji modalitet s raznih krajeva.

Opisana grafička sintaksa dopušta definitivno pročitajte dijagrame koristeći sljedeću strukturu izraza:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Svaki link se može čitati s lijeva na desno ili s desna na lijevo. Na primjer, odnos prikazan na gornjoj slici 4 glasi ovako:

S lijeva na desno: "svaki zaposlenik može imati više djece."

S desna na lijevo: "Svako dijete mora pripadati točno jednom zaposleniku."

Normalni oblici ER sklopova. Kao u dijagramima relacijskih baza podataka, ER dijagrami uvode koncept normalnih formi, a njihovo značenje blisko odgovara značenju relacijskih normalnih formi. Dat ćemo samo vrlo kratke i neformalne definicije prva tri normalna oblika.

U prvo normalno obliku ER dijagrama, eliminiraju se dupli atributi ili grupe atributa, tj. identificiraju se implicitni entiteti "prerušeni" u atribute.

U drugo normalno obliku, atributi koji ovise samo o dijelu jedinstvenog identifikatora (ključ entiteta) su eliminirani. Ovaj dio jedinstvenog identifikatora identificira pojedinačni entitet.

U treći normalan Obrazac eliminira atribute koji ovise o atributima koji nisu uključeni u jedinstveni identifikator (ključ entiteta). Ovi atributi su osnova jednog entiteta.

Ako su entiteti ispravno definirani, rezultirajuće tablice će odmah biti u 3NF. Glavna prednost metode je u tome što se model gradi uzastopnim usavršavanjem početnih dijagrama.

Dobivanje relacijske sheme iz ER sheme:

Korak 1. Svaki jednostavni entitet pretvara se u tablicu. Jednostavan entitet je entitet koji nije podtip i nema podtipove. Naziv entiteta postaje naziv tablice.

Korak 2. Svaki atribut postaje mogući stupac s istim imenom; može se odabrati precizniji format. Stupci koji odgovaraju izbornim atributima mogu sadržavati nulte vrijednosti; stupci koji odgovaraju potrebnim atributima ne mogu.

3. korak Komponente jedinstvenog identifikatora entiteta postaju primarni ključ tablice. Ako postoji nekoliko mogućih jedinstvenih identifikatora, odabire se onaj koji se najčešće koristi. Ako jedinstveni identifikator uključuje odnose, kopija jedinstvenog identifikatora entiteta na krajnjem kraju odnosa dodaje se broju stupaca primarnog ključa (ovaj se proces može nastaviti rekurzivno). Ovi su stupci imenovani korištenjem naziva krajnjih odnosa i/ili naziva entiteta.

Korak 4. Odnosi više-na-jedan (i jedan-na-jedan) postaju strani ključevi. one. Izrađuje se kopija jedinstvenog identifikatora s "jednog" kraja odnosa, a odgovarajući stupci čine strani ključ. Neobavezni odnosi odgovaraju stupcima s mogućnošću NULL; obvezni odnosi - za stupce koji ne dopuštaju nulte vrijednosti.

Korak 5. Indeksi se kreiraju na temelju primarnog ključa (jedinstvenog indeksa), stranih ključeva i onih atributa na kojima se primarno trebaju temeljiti upiti.

Korak 6. Ako su u konceptualnoj shemi postojali podtipovi, tada su moguća dva načina:

• · sve podvrste u jednoj tablici
• · za svaki podtip - posebna tablica (b)

Metoda (a) stvara tablicu za najudaljeniji supertip, a pogledi se mogu kreirati za podtipove. U tablicu se dodaje barem jedan stupac koji sadrži kod TYPE; postaje dio primarnog ključa.

Pri korištenju metode (b), za svaki podtip prve razine (za niže - poglede), nadtip se ponovno kreira korištenjem prikaza UNION (zajednički stupci - stupci nadtipa - odabiru se iz svih tablica podtipova).

Korak 7 Postoje dva načina rada s ekskluzivnim odnosima:

• · opće domene
• · eksplicitni strani ključevi (b)

Ako su svi preostali strani ključevi u istoj domeni, tj. imaju zajednički format (metoda(a)), tada se stvaraju dva stupca: identifikator odnosa i identifikator entiteta. Stupac ID veze koristi se za razlikovanje veza obuhvaćenih lukom isključenja. Stupac identifikatora entiteta koristi se za pohranu jedinstvenih vrijednosti identifikatora entiteta na udaljenom kraju odgovarajućeg odnosa.

Ako rezultirajući strani ključevi ne pripadaju istoj domeni, tada se stvaraju eksplicitni stupci stranih ključeva za svaki odnos pokriven lukom isključenja; svi ovi stupci mogu sadržavati nulte vrijednosti.

Primjer razvoja jednostavnog ER modela. Kada razvijamo ER modele, moramo dobiti sljedeće informacije o predmetnom području:

• 1. Popis entiteta domene.
• 2. Popis atributa entiteta.
• 3. Opis odnosa između entiteta.

ER dijagrami su prikladni jer je proces identifikacije entiteta, atributa i odnosa iterativan. Nakon što smo razvili prvu približnu verziju dijagrama, dorađujemo ih intervjuiranjem stručnjaka za predmet. Ujedno, dokumentacija u koju se bilježe rezultati razgovora su sami ER dijagrami.

Pretpostavimo da smo suočeni sa zadatkom razvoja informacijski sustav po narudžbi nekog trgovačkog poduzeća na veliko. Prije svega, moramo proučiti predmetno područje i procese koji se u njemu odvijaju. Da bismo to učinili, intervjuiramo zaposlenike tvrtke, čitamo dokumentaciju, proučavamo narudžbenice, fakture itd.

Na primjer, tijekom razgovora s voditeljem prodaje pokazalo se da on (voditelj) vjeruje da bi sustav koji se dizajnira trebao obavljati sljedeće radnje:

• · Pohranjujte informacije o kupcima.
• · Ispis računa za puštenu robu.
• · Pratiti raspoloživost robe u skladištu.

Odaberimo sve imenice u ovim rečenicama - to će biti potencijalni kandidati za entitete i atribute i analizirajmo ih (nejasne termine označit ćemo upitnikom):

• · Kupac
• · Dostavnica jasan je kandidat za entitet.
• · Proizvod- jasan kandidat za entitet
• · (?)Skladište- Općenito, koliko skladišta tvrtka ima? Ako ih bude nekoliko, onda će to biti kandidat za novi subjekt.
• · (?) Dostupnost proizvoda- ovo je najvjerojatnije atribut, ali atribut kojeg entiteta?

Odmah se pojavljuje očita veza između entiteta - "kupci mogu kupiti mnogo dobara" i "roba se mogu prodati mnogim kupcima". Prva verzija dijagrama izgleda ovako:

Nakon što smo postavili dodatna pitanja voditelju, saznali smo da tvrtka ima nekoliko skladišta. Štoviše, svaki se proizvod može skladištiti u nekoliko skladišta i prodavati iz bilo kojeg skladišta.

Gdje trebam smjestiti entitete “Faktura” i “Skladište” i na što ih trebam povezati? Zapitajmo se, kako su ti entiteti povezani međusobno i sa entitetima „Kupac“ i „Proizvod“?

• · Kupci kupuju robu i dobivaju račune koji sadrže podatke o količini i cijeni kupljene robe.
• · Svaki kupac može dobiti više računa.
• · Svaki račun mora biti izdan jednom kupcu.
• · Svaki račun mora sadržavati više roba (nema praznih računa). Svaki se proizvod pak može prodati više kupaca putem nekoliko faktura.
• · Osim toga, svaki račun mora biti izdan iz određenog skladišta, a mnoge fakture mogu se izdati iz bilo kojeg skladišta.

Dakle, nakon pojašnjenja, dijagram će izgledati ovako:

infološki atribut informacijski prikaz

Vrijeme je da razmislimo o atributima entiteta. U razgovoru sa zaposlenicima tvrtke doznali smo sljedeće:

• · Svaki kupac je pravna osoba i ima naziv, adresu i bankovne podatke.
• · Svaki proizvod ima naziv, cijenu, a karakteriziran je i mjernim jedinicama.
• · Svaki račun ima jedinstveni broj, datum izdavanja, popis robe s količinama i cijenama, kao i ukupni iznos iznad glave. Faktura se izdaje sa određenog skladišta i određenom kupcu.
• · Svako skladište ima svoje ime.

Zapišimo opet sve imenice koje će biti potencijalni atributi i analizirajmo ih:

• · Pravna osoba - termin je retorički, ne radimo sa pojedinaca. Ne obraćamo pažnju.
• · Ime kupca
• · Adresa- jasna karakteristika kupca.
• · Bankovni podaci- jasna karakteristika kupca.
• · Naziv proizvoda
• · (?) Cijena proizvoda- čini se da je to karakteristika proizvoda. Razlikuje li se ova karakteristika od cijene na računu?
• · Mjerna jedinica- jasna karakteristika proizvoda.
• · Broj fakture- jasna jedinstvena karakteristika fakture.
• · Datum fakture- jasna karakteristika fakture.
• · (?)Popis robe u fakturi- popis ne može biti atribut. Vjerojatno trebate odvojiti ovaj popis u zasebnu cjelinu.
• · (?) Količina robe na računu- ovo je očita karakteristika, ali karakteristika čega? Ovo je karakteristika ne samo “proizvoda”, već i “proizvoda na računu”.
• · (?)Cijena robe na računu- opet, ovo ne bi trebao biti samo opis proizvoda, već opis proizvoda na računu. Ali cijena proizvoda je već viđena gore - je li to ista stvar?
• · Iznos fakture- jasna karakteristika fakture. Ova karakteristika nije neovisna. Iznos računa jednak je zbroju troškova svih roba uključenih u račun.
• · Naziv skladišta- jasna karakteristika skladišta.

Tijekom dodatnog razgovora s voditeljem, bilo je moguće razjasniti razne pojmove cijene Pokazalo se da svaki proizvod ima određenu trenutnu cijenu. Ovo je cijena po kojoj se proizvod prodaje u trenutku. Naravno, ova se cijena može promijeniti tijekom vremena. Cijena istog proizvoda na različitim računima izdanim u različita vremena, može biti drugačiji. Stoga postoji dvije cijene- cijenu robe na računu i aktualnu cijenu robe.

S novim konceptom "Popis robe na fakturi" sve je sasvim jasno.

Entiteti "Faktura" i "Proizvod" međusobno su povezani odnosom tipa mnogi prema mnogima. Takva bi veza, kao što smo ranije primijetili, trebala biti podijeliti u dva odnosa jedan prema više. Ovo zahtijeva dodatni suština.

Ovaj entitet će biti entitet "Popis robe na fakturi". Njegovu vezu s entitetima „Račun“ i „Proizvod“ karakteriziraju sljedeći izrazi

- “svaki račun mora imati više unosa iz popisa robe na računu”,

• - „svaki unos iz popisa robe na računu mora biti uključen u točno jedan račun“,
• - "svaki proizvod može biti uključen u više zapisa iz popisa robe na računu",
• - “svaki unos iz popisa robe na računu mora biti povezan s točno jednim proizvodom.”

Atributi "Količina robe na računu" i "Cijena robe na računu" su atributi entiteta "Popis robe na računu".

Isto ćemo učiniti s vezom koja povezuje entitete “Skladište” i “Proizvod”. Predstavimo se dodatni entitet "Artikl na skladištu". Atribut ovog entiteta bit će "Količina robe na skladištu". Tako će proizvod biti naveden u svakom skladištu i njegova količina u svakom skladištu bit će drugačija.

Sada sve ovo možete staviti u dijagram:

Konceptualni i fizički ER modeli. Primjer ER dijagrama razvijen iznad je primjer konceptualni dijagram. To znači da dijagram ne uzima u obzir značajke određenog DBMS-a. Iz ovog konceptualnog dijagrama možete konstruirati fizički dijagram, koji će već uzeti u obzir takve značajke DBMS-a kao što su dopušteni tipovi i nazivi polja i tablica, ograničenja integriteta itd. Fizička verzija gornjeg dijagrama može izgledati, na primjer, ovako:

U ovom dijagramu svaki entitet predstavlja tablicu baze podataka, svaki atribut postaje stupac odgovarajuće tablice. Imajte na umu da su se u mnogim tablicama, na primjer, "CUST_DETAIL" i "PROD_IN_SKLAD", koje odgovaraju entitetima "Zapis popisa faktura" i "Stavka na skladištu", pojavili novi atributi koji nisu bili u konceptualnom modelu - to su ključni atributi nadređenih tablica, migrirao u podređene tablice kako bi se osigurali odnosi između tablica pomoću stranih ključeva.

Dobivene tablice su u 3NF.

Dijagrami entiteta i odnosa omogućuju vam korištenje vizualnih grafički simboli modelirati entitete i njihove odnose.

razlikovati pojmovni I fizički ER dijagrami. Konceptualni dijagrami ne uzimaju u obzir specifične značajke specifičnih DBMS-ova. Fizički dijagrami izgrađeni su na konceptualnim dijagramima i predstavljaju prototip određene baze podataka. Entiteti definirani u konceptualnom dijagramu postaju tablice, atributi postaju stupci tablice (uzimajući u obzir tipove podataka i nazive stupaca koji su dopušteni za dati DBMS), veze se implementiraju putem migracija ključni atributi nadređenih entiteta i stvaranje stranih ključeva.

Složeniji elementi ER modela. Usredotočili smo se samo na najosnovnije i najočiglednije koncepte ER modela podataka. Složeniji elementi modela uključuju sljedeće:

· Podtipovi i nadtipovi entiteta. Kao iu programskim jezicima s razvijenim sustavima tipova (na primjer, u objektno orijentiranim programskim jezicima), uvodi se mogućnost nasljeđivanja tipa entiteta na temelju jednog ili više supertipova.

Entitet se može podijeliti u dva ili više međusobno isključivih podtipova, od kojih svaki uključuje zajedničke atribute i/ili odnose. Ovi zajednički atributi i/ili odnosi se jednom izričito definiraju visoka razina. Podtipovi mogu definirati vlastite atribute i/ili odnose. U principu, podtipiziranje se može nastaviti još dugo niske razine, ali iskustvo pokazuje da su u većini slučajeva dovoljne dvije ili tri razine.

Entitet na temelju kojeg se definiraju podtipovi naziva se supertip. Podtipovi moraju činiti kompletan skup, tj. svaka instanca nadtipa mora pripadati nekom podtipu. Ponekad je za cjelovitost potrebno definirati dodatni podtip OSTALI.

Primjer: Supertip ZRAKOPLOVA

Kako bi ovo trebao čitati? Od supertipa: AVION, koji mora biti AVION, HELIKOPTER, KLIKER ZA PTICE ili DRUGI AVION. Iz podtipa: HELIKOPTER, koji pripada vrsti ZRAKOPLOVICA. Od podvrste, koja je ujedno i nadvrsta: AVION, koji pripada vrsti AVIONA i mora biti JEDRILICA ili MOTORNI AVION.

Ponekad je zgodno imati dvije ili više različitih podvrsta entiteta. Na primjer, bit OSOBE može se podijeliti na podtipove na temelju profesionalnih karakteristika (PROGRAMER, MLJEKARICA, itd.), ili možda na temelju spola (MUŠKARAC, ŽENA).

• · Veze više-na-više. Ponekad je potrebno povezati entitete na način da postoji više instanci entiteta na oba kraja veze (na primjer, svi članovi zadruge zajednički posjeduju imovinu zadruge). Da bi se to postiglo, uvodi se vrsta odnosa "više-prema-više".
• · Odredivi stupnjevi veze. Ponekad je korisno definirati mogući broj instanci entiteta koji sudjeluju u određenom odnosu (na primjer, zaposlenik smije sudjelovati u najviše tri projekta istovremeno). Da bi se izrazilo ovo semantičko ograničenje, dopušteno je na kraju veze naznačiti njezin maksimalni ili obvezni stupanj.
• · Kaskadno brisanje instanci entiteta. Neki su odnosi toliko jaki (u slučaju odnosa jedan-prema-više, naravno) da kada izbrišete instancu referentnog entiteta (koja odgovara jednom kraju odnosa), morate također izbrisati sve instance entiteta koje odgovaraju mnogi prekidaju vezu. Odgovarajući zahtjev za "kaskadno brisanje" može se formulirati prilikom definiranja entiteta.
• · Domene. Kao u slučaju relacijski model podataka, korisno je moći odrediti potencijalno važeći skup vrijednosti za atribut entiteta (domene).

Najispravnije intuitivno tumačenje pojma domene je razumijevanje domene kao dopuštenog potencijalnog skupa vrijednosti danog tipa. Na primjer, domena "Imena" definirana je na osnovnom tipu nizova znakova, ali njegove vrijednosti mogu uključivati ​​samo nizove koji mogu predstavljati ime (konkretno, takvi nizovi ne mogu započeti mekim znakom).

Također treba napomenuti semantičko opterećenje koncepta domene: podaci se smatraju usporedivima samo ako pripadaju istoj domeni. U našem primjeru, vrijednosti domene "Gap Numbers" i "Group Numbers" su cijelog tipa, ali nisu usporedive.

Ovi i drugi složeniji elementi podatkovnog modela Entity-Relationship čine ga znatno moćnijim, ali ga u isto vrijeme donekle otežavaju za korištenje.

Koraci dizajna baze podataka

Sve suptilnosti izgradnje informacijskog modela određenog predmetnog područja ljudske aktivnosti slijede jedan cilj - dobiti dobru bazu podataka. Objasnimo pojam – dobra baza podataka i formuliramo zahtjeve koje takva baza mora zadovoljiti:

1. Baza podataka mora zadovoljiti informacijske potrebe korisnika (organizacija) te po strukturi i sadržaju odgovarati zadacima koji se rješavaju;

2. Baza podataka mora osigurati tražene podatke u prihvatljivom vremenu, tj. zadovoljiti zahtjeve izvedbe;

3. Baza podataka treba se lako proširiti kada se predmetno područje reorganizira;

4. Baza podataka bi se trebala lako mijenjati kada se promijeni softversko i hardversko okruženje;

5. Ispravni podaci učitani u bazu moraju ostati točni (podatke je potrebno provjeriti da li su točni prilikom unosa).

Razmotrimo glavne faze dizajna (Sl. 3.5):

Prva faza. Planiranje razvoja baze podataka. U ovoj fazi bit će istaknut najučinkovitiji način provedbe faza životni ciklus sustava.

Druga faza. Određivanje zahtjeva sustava. Određuje se opseg i granice primjene baze podataka, prikupljaju i analiziraju zahtjevi korisnika.

Treća faza. Projektiranje konceptualnog modela baze podataka. Proces stvaranja baze podataka započinje definiranjem konceptualnog modela koji predstavlja objekte i njihove odnose bez navođenja načina na koji su fizički pohranjeni. Napori u ovoj fazi trebali bi biti usmjereni na strukturiranje podataka i utvrđivanje odnosa među njima. Ovaj se proces može podijeliti na nekoliko pod-koraka:

a) Pojašnjenje problema. Čak i prije početka rada na specifična primjena Programer obično ima neku ideju o tome što će razviti. U drugim slučajevima, kada se razvija mala osobna baza podataka, takvi prikazi mogu biti prilično potpuni. U drugim slučajevima, kada se razvija velika prilagođena baza podataka, može biti vrlo malo takvih pogleda ili će oni najvjerojatnije biti površni. Očito je prerano započeti razvoj odmah definiranjem tablica, polja i odnosa među njima. Ovaj bi pristup mogao rezultirati potpunim redizajnom velikog dijela aplikacije. Stoga biste trebali potrošiti neko vrijeme na sastavljanje popisa svih glavnih zadataka koje bi ova aplikacija u načelu trebala riješiti, uključujući i one koji bi se mogli pojaviti u budućnosti.

Riža. 3.5. Dijagram dizajna baze podataka

b) Pojašnjenje redoslijeda zadataka. Da bi aplikacija radila logično i praktično, najbolje je organizirati glavne zadatke u grupe, a zatim organizirati zadatke svake grupe tako da budu raspoređeni redoslijedom kojim su dovršeni. Grupiranje i grafički prikaz redoslijeda u kojem se izvode pomoći će odrediti prirodni redoslijed zadataka.

c) Analiza podataka. Nakon utvrđivanja popisa zadataka, potrebno je za svaki zadatak izraditi detaljan popis podataka potrebnih za njegovo rješavanje. Nakon faze analize podataka, možete početi razvijati konceptualni model, tj. na isticanje objekata, atributa i odnosa.

Četvrta faza. Konstrukcija logičkog modela. Izgradnja logičkog modela počinje odabirom podatkovnog modela. Prilikom odabira modela važnu ulogu njegova jednostavnost, jasnoća i usporedba prirodne strukture podataka s modelom koji ih predstavlja igraju važnu ulogu. Na primjer, ako je hijerarhijska struktura svojstvena samim podacima, tada bi bilo bolje odabrati hijerarhijski model. Ali često je ovaj izbor određen uspjehom (ili dostupnošću) jednog ili drugog DBMS-a. To jest, programer bira DBMS, a ne model podataka. Stoga se u ovoj fazi konceptualni model prevodi u podatkovni model kompatibilan s odabranim DBMS-om. Moguće je da će se odnosi između objekata ili nekih atributa objekata prikazanih u konceptualnom modelu naknadno pokazati neostvarivima od strane odabranog DBMS-a. To će zahtijevati promjenu konceptualnog modela. Poziva se verzija konceptualnog modela koju može pružiti određeni DBMS logički model. Proces definiranja konceptualnih i logičkih modela ponekad se naziva definicija strukture podataka.

Peta faza. Konstrukcija fizičkog modela. Fizički model definira raspored podataka, metode pristupa i tehnike indeksiranja. U fazi fizičkog dizajna, postajemo vezani za određeni DBMS i detaljnije opisujemo podatkovnu shemu, navodeći tipove, veličine polja i ograničenja. Osim dizajniranja tablica i indeksa, ova faza uključuje i definiranje osnovnih upita.

Prilikom konstruiranja fizičkog modela potrebno je riješiti dva međusobno suprotna problema. Prvi je minimiziranje prostora za pohranu podataka, a drugi je postizanje maksimalnih performansi, integriteta i sigurnosti podataka. Na primjer, da bi se osigurala velika brzina pretraživanja, potrebno je izraditi indekse, a njihov broj će biti određen svim mogućim kombinacijama polja koja sudjeluju u pretraživanju; Oporavak podataka zahtijeva bilježenje svih promjena i kreiranje sigurnosne kopije DB; Za učinkovit rad transakcije zahtijevaju rezerviranje prostora na disku za privremene objekte itd., što dovodi do povećanja (ponekad značajnog) veličine baze podataka.

Šesta faza. Evaluacija fizičkog modela. U ovoj fazi provodi se procjena učinka. Ovdje možete provjeriti učinkovitost izvršavanja upita, brzinu pretraživanja, ispravnost i jednostavnost izvođenja operacija baze podataka, cjelovitost podataka i učinkovitost računalnih resursa. Ako karakteristike performansi nisu zadovoljavajuće, moguće je vratiti se na reviziju fizičkih i logičkih modela podataka, izbor DBMS-a i tipa računala.

Sedma faza. Implementacija baze podataka. Ako je izvedba zadovoljavajuća, možete prijeći na stvaranje izgleda aplikacije, to jest skupa osnovnih tablica, upita, obrazaca i izvješća. Ovaj preliminarni mockup može se demonstrirati kupcu i dobiti odobrenje prije detaljne implementacije aplikacije.

Osma faza. Testiranje i optimizacija. Obavezna faza je testiranje i optimizacija razvijene aplikacije.

Deveta faza, finale. Održavanje i rad. Budući da nije moguće identificirati i ukloniti sve greške u fazi testiranja, faza održavanja je normalna za baze podataka.

Postoje dva glavna pristupa dizajnu podatkovne sheme: odozgo prema dolje i odozdo prema gore. Pristupom odozdo prema gore rad počinje na nižoj razini - razini definiranja atributa, koji se na temelju analize odnosa koji među njima postoje grupiraju u odnose koji predstavljaju objekte i veze među njima. Proces normalizacije tablica za relacijski podatkovni model tipičan je primjer ovog pristupa. Ovaj je pristup prikladan za projektiranje relativno malih baza podataka. Kada se broj atributa poveća na nekoliko stotina ili čak tisuća, pristup odozgo prema dolje je prikladnija strategija dizajna. Ovaj pristup počinje definiranjem nekoliko entiteta visoke razine i odnosa između njih. Ti se objekti zatim detaljiziraju do potrebne razine. Primjer ovog pristupa dizajnu je korištenje modela entitet-odnos. U praksi se ti pristupi obično kombiniraju. U ovom slučaju možemo govoriti o mješovitom pristupu dizajnu.