Model logic de date. Conceptul de normalizare a relațiilor

ER- diagrame

O modalitate obișnuită de a reprezenta un model de bază de date logică este construirea de diagrame ER (Entity-Relationship - entity-relationship). În acest model, o entitate este definită ca un obiect discret pentru care sunt stocate elemente de date, iar o relație descrie o relație între două obiecte.

În exemplul unui manager de agenție de turism, există 5 obiecte principale:

Turiştii

Bonuri

Relația dintre aceste obiecte poate fi definită în termeni simpli:

Fiecare turist poate cumpăra unul sau mai multe (mai multe) vouchere.

Fiecărui voucher îi corespunde plata (pot fi mai multe plăți dacă voucherul, de exemplu, este vândut pe credit).

Fiecare turneu poate avea mai multe sezoane.

Voucherul este vândut pentru un sezon dintr-un turneu.

Aceste obiecte și relații pot fi reprezentate printr-o diagramă ER, așa cum se arată în Figura 2.

Orez. 2. Diagrama ER pentru aplicația de bază de date a managerului agenției de turism

Obiecte, atribute și chei

Modelul este dezvoltat în continuare prin definirea atributelor pentru fiecare obiect. Atributele obiectului sunt elemente de date legate de un anumit obiect care trebuie să fie păstrate. Analizăm dicționarul de date compilat, selectăm obiectele și atributele acestora în el, extindem dicționarul dacă este necesar. Atributele fiecărui obiect din acest exemplu sunt prezentate în Tabelul 2.

Tabelul 2. Obiecte și atribute ale bazei de date

Un obiect	Turiştii	Bonuri	Tururi	anotimpuri	Plată
			Nume	data începutului	data plății
				Data de încheiere
	Nume de familie		informație
Atribute

Rețineți că lipsesc mai multe articole. Informații de înregistrare omise menționate în specificația funcțională. Cum să ții cont, vei gândi singur și vei modifica exemplul propus. Dar, mai important, încă nu sunt necesare atribute pentru a lega obiectele între ele. Aceste elemente de date nu sunt reprezentate în modelul ER, deoarece nu sunt, de fapt, atribute „naturale” ale obiectelor. Ele sunt tratate diferit și vor fi luate în considerare în modelul de date relaționale.

Modelul relațional se caracterizează prin utilizarea cheilor și a relațiilor. Există o diferență în contextul unei baze de date relaționale în ceea ce privește relația și relația. Relația este văzută ca un tabel bidimensional, neordonat, cu rânduri care nu au legătură. Schema de date se formează între relații (tabele) prin atribute comune, care sunt chei.

Există mai multe tipuri de chei și uneori diferă doar în ceea ce privește relația lor cu alte atribute și relații. O cheie primară identifică în mod unic un rând dintr-o relație (tabel) și fiecare relație poate avea o singură cheie primară, chiar dacă mai multe atribute sunt unice. În unele cazuri, este necesar mai mult de un atribut pentru a identifica rândurile dintr-o relație. Colecția acestor atribute se numește cheie compusă. În alte cazuri, cheia primară trebuie creată (generată) special. De exemplu, în relația „Turiști” are sens să adăugați un identificator turistic unic (cod turistic) ca cheie primară a acestei relații pentru a organiza legături cu alte relații DB.

Un alt tip de cheie, numită cheie străină, există doar în ceea ce privește schema de date dintre cele două relații. O cheie externă într-o relație este un atribut care este o cheie primară (sau o parte a unei chei primare) într-o altă relație. Este un atribut distribuit care formează schema de date între două relații din baza de date.

Pentru baza de date proiectată, să extindem atributele obiectelor cu câmpuri de cod ca chei primare și să folosim aceste coduri în relațiile bazei de date pentru a ne referi la obiectele bazei de date, după cum urmează (Tabelul 3).

Este prea devreme să considerăm finalizată schema bazei de date construită, deoarece este necesară normalizarea acesteia. Un proces cunoscut sub numele de normalizare a bazei de date relaționale este utilizat pentru a grupa atributele în moduri specifice pentru a minimiza redundanța și dependența funcțională.

Tabelul 3. Obiecte și atribute ale bazei de date cu câmpuri de cod extinse

Un obiect	Turiştii	Bonuri	Tururi	anotimpuri	Plată
Atribute	Cod turistic	Cod tur		Cod de sezon	Cod de facturare
		Cod turistic	Nume	data începutului	data plății
		Cod de sezon		Data de încheiere
	Nume de familie		informație		Cod tur

Normalizare

Dependențe funcționale apar atunci când valoarea unui atribut poate fi determinată din valoarea altui atribut. Un atribut care poate fi definit se numește dependent funcțional de un atribut care este determinant. Prin urmare, prin definiție, toate atributele fără cheie (fără cheie) vor depinde funcțional de cheia primară din fiecare relație (deoarece cheia primară identifică în mod unic fiecare rând). Când un atribut al unei relații nu identifică în mod unic un alt atribut, ci îl limitează la un set de valori predefinite, se numește dependență cu mai multe valori. Dependența parțială apare atunci când un atribut de relație este dependent funcțional de un singur atribut cheie compus. Dependențe tranzitive apar atunci când un atribut non-cheie este dependent funcțional de unul sau mai multe alte atribute non-cheie dintr-o relație.

Procesul de normalizare consta in construirea pas cu pas a unei baze de date in forma normala (NF).

1. Prima formă normală (1NF) este foarte simplă. Toate tabelele bazei de date trebuie să îndeplinească o singură cerință - fiecare celulă din tabele trebuie să conțină o valoare atomică, cu alte cuvinte, valoarea stocată în domeniul aplicației bazei de date nu trebuie să aibă o structură internă, ale cărei elemente pot fi solicitate de către aplicarea.

2. A doua formă normală (2NF) este creată atunci când toate dependențele parțiale sunt eliminate din relațiile bazei de date. Dacă relația nu are chei compuse, atunci acest nivel de normalizare este ușor de atins.

3. A treia formă normală (3NF) a bazei de date necesită eliminarea tuturor dependențelor tranzitive.

4. A patra formă normală (4NF) este creată atunci când toate dependențele cu mai multe valori sunt eliminate.

Baza de date din exemplul nostru este în 1NF, deoarece toate câmpurile tabelelor bazei de date sunt atomice în conținut. Baza noastră de date se află și în 2NF, deoarece am introdus artificial coduri unice pentru fiecare obiect (Cod Turistic, Cod Turistic etc.) în fiecare tabel, datorită căruia am obținut 2NF pentru fiecare dintre tabelele bazei de date și întreaga bază de date în ansamblu. . Rămâne să ne ocupăm de a treia și a patra formă normală.

Rețineți că ele există doar cu privire la diferite tipuri de dependențe de atribute DB. Există dependențe - trebuie să costați NF DB, nu există dependențe - DB este deja în NF. Dar ultima opțiune nu se găsește aproape niciodată în aplicațiile reale.

Deci, ce dependențe tranzitive și multivalorice sunt prezente în baza noastră de date exemplu a unui manager de agenție de turism?

Să analizăm atitudinea „Turiștilor”. Să luăm în considerare dependențele dintre atributele „Cod turistic”, „Nume”, „Prenume”, „Patronimic” și „Pașaport” (Fig. 3). Fiecare turist, reprezentat în raport cu combinația „Prenume-Nume-Patronimic”, are în timpul călătoriei un singur pașaport, în timp ce omonimul complet trebuie să aibă numere de pașaport diferite. Prin urmare, atributele „Prenume-Nume-Patronimic” și „Pașaport” formează o cheie compusă în raport cu turiștii.

Orez. 3. Un exemplu de dependență tranzitivă

După cum puteți vedea din figură, atributul „Pașaport” depinde în mod tranzitiv de cheia „Cod turistic”. Prin urmare, pentru a exclude această dependență tranzitivă, vom împărți cheia compusă a relației și relația însăși în 2 în relații unu-la-unu. În prima relație, să o lăsăm cu numele „Turiști”, sunt incluse atributele „Cod Turistic” și „Nume”, „Nume”, „Patronimic”. A doua relație, să o numim „Informații despre turiști”, este formată din atributele „Cod turistic” și toate atributele rămase ale relației „Turiști”: „Pașaport”, „Telefon”, „Oraș”, „Țară”, "Index". Aceste două relații noi nu mai au o relație tranzitivă și sunt în 3NF.

Nu există dependențe cu mai multe valori în baza noastră de date simplificată. De exemplu, să presupunem că pentru fiecare turist ar trebui să fie stocate mai multe telefoane de contact (acasă, serviciu, mobil etc., ceea ce este foarte tipic în practică), și nu unul, ca în exemplu. Obținem o dependență multivalorică a cheii - „Cod turistic” și atributele „Tip de telefon” și „Telefon”, în această situație cheia încetează să mai fie o cheie. Ce să fac? Problema este rezolvată și prin împărțirea schemei de relații în 2 scheme noi. Unul dintre ele ar trebui să ofere informații despre telefoane (relația „Telefoane”), iar al doilea despre turiști (relația „Turiști”), care sunt legați prin câmpul „Cod turistic”. Codul turistic va fi cheia principală pentru turiști și cheia externă pentru telefoane.

Figura 1 prezintă modelul logic al bazei de date a rezidențelor studențești.

Figura 1 - model logic

Un model logic (datalogic) este un model de bază de date care nu este legat de un anumit SGBD. În ea se disting obiectele principale ale bazei de date și se determină conexiunile dintre aceste obiecte. Uneori sunt definite tipurile de date ale obiectelor individuale. Acest model este construit folosind metoda Entity Relationship.

2.2 Entități

Această bază de date conține 16 entități. Să analizăm fiecare dintre ele și conexiunile dintre ele.

Esenta Form_ob contine doua atribute: Nom_fo- numărul ordinal al formei de studiu, și Form_ob- forma de antrenament, dintre care prima este cheia. Această esență conține opțiunile posibile pentru formele de formare (bugetar și contractual).

Esenta stare contine si doua atribute: Nom_st- numărul de serie al stării (atributul cheii) și stare- numele statutului. Statutul poate lua două semnificații: student și student absolvent.

Esenta Facultate conţine informaţii despre facultăţi. Primul atribut (cheie) Nom_fak- numărul ordinal al facultății, al doilea atribut Facultate- denumirea prescurtată a facultății.

Esenta Specialitate conţine informaţii despre specialităţile universităţii. Ca atribute - numărul de serie și denumirea digitală a specialității.

Esenta Cameră conține numărul de camere și numărul de locuri libere din acestea. Deoarece, conform condiției, nu ar trebui să existe încăperi neocupate și există doar 3 locuri în cameră, va fi necesar să se stabilească o restricție corespunzătoare privind introducerea datelor.

Esenta Tarife conține numărul de serie al tarifului, criteriile care determină costul - numărul de statut și numărul formei de studiu și costul tarifului în sine.

Esenta grup contine numarul grupei care determina criteriile - numarul facultatii si numarul specialitatii, precum si cursul.

De fapt Personal_dan conține informații despre datele personale ale elevului. Numărul său de identificare a studentului, numele de familie, prenumele, patronimul, numărul și seria pașaportului, data nașterii, locul nașterii, locul de înregistrare și locul de reședință.

Esenta Student contine numarul carnetului de student, numarul ratei de plata pentru cazare in pensiune, data admiterii la universitate si data absolvirii facultatii.

Esenta Schimbări conține informații despre schimbările care au avut loc în timpul studiilor. Ca atribute, contine numarul schimbarii, denumirea facultatii, numarul specialitatii, numarul cursului, numarul grupei, numarul formei de studiu si numarul statutului.

Esenta Stud_piept servește la legarea entităților Studentși Schimbări... Conține numărul modificării, numărul de identificare a studentului și data la care a avut loc schimbarea.

Esenta Stud_group este și un liant al entităților Studentși grup... Acesta conține numărul de identificare a studentului, numărul grupului și informații despre expulzarea și reintegrarea elevului.

O altă entitate de legătură este Studio_camera... Este destinat stocării numărului de relocare a studenților, numărul de legitimație de student, numărul camerei și datele de check-in și check-out.

Arhiva- o entitate pentru stocarea studenților gay. Conține numărul de intrare, numărul de identificare a studentului și data de plecare.

De fapt Neplata contine seria de neplata, numarul cardului de student al studentului care nu a platit cazarea, precum si luna si anul in care acesta nu a platit.

De fapt Părinţi furnizează informații despre părinții studentului, cum ar fi numele tatălui și al mamei și starea căsătoriei acestora, cărora li se poate cere să plătească beneficii suplimentare pentru studenți.

• familiarizați-vă cu tehnologia de construire a unui model logic în ERWin,
• explorarea metodelor de determinare a atributelor cheie ale entităților,
• stăpânește metoda de verificare a adecvării modelului logic,
• explorați tipurile de relații dintre entități.

Primul pas în crearea unui model de bază de date logică este construirea unei diagrame ERD (Entity Relationship Diagram). Diagramele ERD sunt alcătuite din trei părți: entități, atribute și relații. Entitățile sunt substantive, atributele sunt adjective sau modificatori, relațiile sunt verbe.

Diagrama ERD vă permite să priviți întregul sistem și să aflați cerințele pentru dezvoltarea acestuia în ceea ce privește stocarea informațiilor.

Diagramele ERD pot fi subdivizate în piese separate corespunzătoare sarcinilor individuale rezolvate de sistemul proiectat. Acest lucru vă permite să vizualizați sistemul în termeni de funcționalitate, făcând procesul de proiectare gestionabil.

diagrame ERD

După cum știți, componenta principală a bazelor de date relaționale este un tabel. Tabelul este folosit pentru a structura și stoca informații. În bazele de date relaționale, fiecare celulă dintr-un tabel conține o valoare. În plus, în cadrul aceleiași baze de date, există relații între tabele, fiecare dintre ele specificând partajarea datelor din tabel.

O diagramă ERD reprezintă grafic structura de date a sistemului informațional proiectat. Entitățile sunt afișate folosind dreptunghiuri care conțin un nume. Se obișnuiește să se exprime nume cu substantive la singular, relații - folosind linii care leagă entitățile individuale. O relație indică faptul că datele de la o entitate sunt referite sau legate de date de la alta.

Orez.6.1. Un exemplu de diagramă ERD,

Definirea entităților și atributelor

O entitate este un subiect, loc, lucru, eveniment sau concept care conține informații. Mai precis, o entitate este o colecție (unire) de obiecte numite instanțe. În exemplul prezentat în fig. În exemplul 6.1, entitatea CLIENT reprezintă toți clienții posibili. Fiecare instanță a unei entități are un set de caracteristici. Deci, fiecare client poate avea un nume, adresă, număr de telefon etc. În modelul logic, toate aceste caracteristici sunt numite atribute ale entității.

În fig. 6.2 prezintă o diagramă ERD care include atributele entității.

Orez. 6.2. ERD-diagramă cu atribute

Relații logice

Relațiile logice sunt relații între entități. Ele sunt definite de verbe care arată modul în care o entitate se raportează la alta.

Câteva exemple de relații:

• echipa include mulți jucători,
• avionul transportă mulți pasageri,
• vânzătorul vinde multe produse.

În toate aceste cazuri, relațiile reflectă o interacțiune unu-la-mulți între două entități. Aceasta înseamnă că o instanță a primei entități interacționează cu mai multe instanțe ale altei entități. Relațiile sunt afișate prin linii care leagă două entități cu un punct la un capăt și un verb deasupra liniei.

Pe lângă relația unu-la-mulți, există un alt tip de relație - mulți-la-mulți. Acest tip de relație descrie o situație în care instanțe de entitate pot interacționa cu mai multe instanțe ale altor entități. Relațiile multi-la-multe sunt utilizate în etapele inițiale de proiectare. Acest tip de relație este afișat ca o linie continuă cu puncte la ambele capete.

O relație multi-la-mulți poate să nu ia în considerare anumite constrângeri ale sistemului și, prin urmare, poate fi înlocuită cu unul-la-mulți atunci când proiectul este revizuit ulterior.

Verificarea adecvării modelului logic

Dacă relațiile dintre entități au fost corect stabilite, atunci puteți face propoziții care le descriu. De exemplu, conform modelului prezentat în fig. 6.3, puteți face următoarele propoziții:

Avionul transportă pasageri. Mulți pasageri sunt transportați cu un singur avion.

Elaborarea unor astfel de propuneri vă permite să verificați conformitatea modelului rezultat cu cerințele și limitările sistemului creat.

Orez. 6.3.Un exemplu de model logic cu o relație

Model de date bazat pe chei

Fiecare entitate conține o linie orizontală care împarte atributele în două grupuri. Atributele de deasupra liniei sunt numite cheie primară. Cheia primară este pentru identificarea unică a unei instanțe de entitate.

Selectarea unei chei primare

La crearea unei entități, este necesar să selectați un grup de atribute care pot deveni potențial cheie primară (chei potențiale), apoi selectați atributele pentru includerea în cheia primară, urmând următoarele recomandări:

Cheia primară trebuie aleasă în așa fel încât valorile atributelor incluse în ea să poată identifica cu exactitate instanța entității. Niciunul dintre atributele cheii primare nu trebuie să fie nul. Valorile atributelor cheii primare nu ar trebui să se schimbe. Dacă valoarea sa schimbat, atunci aceasta este deja o instanță diferită a entității.

Atunci când alegeți o cheie primară, puteți adăuga un atribut suplimentar entității și o puteți transforma într-o cheie. Deci, pentru a determina cheia primară, sunt adesea folosite numere unice, care pot fi generate automat de sistem atunci când o instanță de entitate este adăugată la baza de date. Utilizarea numerelor unice facilitează procesul de indexare și căutare în baza de date.

Cheia primară aleasă la crearea modelului logic poate fi nereușită pentru accesul eficient la baza de date și trebuie schimbată în timpul proiectării modelului fizic.

O cheie potențială care nu a devenit cheia primară se numește cheie alternativă. ERWin vă permite să selectați atributele cheilor alternative, iar în mod implicit, în viitor, la generarea unei scheme de bază de date, va fi generat un index unic pentru aceste atribute. Când creați o cheie alternativă, simbolurile (AK) apar pe diagramă de lângă atribut.

Atributele implicate în indecșii non-unici se numesc intrări de inversare. Intrările inverse sunt un atribut sau un grup de atribute care nu identifică în mod unic o instanță, dar sunt adesea folosite pentru a se referi la instanțe de entitate. ERWin generează un index neunic pentru fiecare intrare de inversare.

Când se stabilește o relație între două entități, cheile străine sunt generate automat în entitatea copil. Relația formează o referință la atributele cheii primare din entitatea copil, iar aceste atribute formează cheia externă în entitatea copil. Atributele cheii străine sunt identificate prin caractere (FK) după numele lor.

Exemplu

Să luăm în considerare procesul de construire a unui model logic folosind exemplul unei baze de date studenți a sistemului „Serviciul de ocupare a forței de muncă în cadrul Universității”. Primul pas este definirea entităților și atributelor. Baza de date va stoca înregistrări despre studenți, prin urmare, entitatea va fi un student.

Tabelul 6.1.Atributele entității „Student”.

Atribut	Descriere
Număr	Număr unic pentru identificarea utilizatorului
NUMELE COMPLET.	Numele, numele și patronimul utilizatorului
Parola	Parola de acces la sistem
Vârstă	Vârsta studentului
Podea	Genul elevului
Caracteristică	Câmp de memorare cu caracteristici generale ale utilizatorului
E-mail	Adrese de email
Telefon	Numerele de telefon ale studenților (acasă, serviciu)
experienţă	Specialități și experiență de lucru a studenților în fiecare dintre ele
Specialitate	Specialitate dobândită de un student la absolvire
Specializare	Direcția specialității în care este pregătit studentul
Limbă străină	Lista limbilor străine și nivelul de competență al acestora
Testare	Lista probelor și notele de promovare a acestora
Revizuirea expertului	Lista de subiecte cu evaluări de experți pentru fiecare dintre ele
Notele examenului	Lista disciplinelor promovate cu note

Lista rezultată conține atribute care nu pot fi definite ca un singur câmp de bază de date. Astfel de atribute necesită definiții suplimentare și ar trebui considerate ca entități, constând, la rândul lor, din atribute. Acestea includ: experiență de muncă, o limbă străină, testare, evaluare peer, note la examen. Să le definim atributele.

Tabelul 6.2.Atributele entității „Experiență de lucru”.

Tabelul 6.3.Atributele entității de limbă străină

Tabelul 6.4.Atributele entității de testare

Tabelul 6.5.Atribute ale entității de judecată expert

Atribut	Descriere
Disciplina	Numele disciplinei în care studentul a fost evaluat
NUMELE COMPLET. profesor	NUMELE COMPLET. profesorul care a notat elevul
Nota	Evaluarea de specialitate a profesorului
Atribut		Descriere
Lucru		Numele materiei pentru care a fost promovat examenul
Nota		Scorul rezultat

Să compunem o diagramă ERD, definind tipurile de atribute și stabilind relațiile dintre entități (Fig. 6.4). Toate entitățile vor fi dependente de entitatea „Student”. Relațiile vor fi unul la mai mulți.

Orez. 6.4.ERD-diagrama DB de elevi

Diagrama rezultată își afișează numele lângă relație, care arată relația dintre entități. Când se stabilește o relație între entități, cheia primară este migrată la entitatea copil.

Următorul pas în construirea unui model logic este definirea atributelor cheie și a tipurilor de atribute.

Tabelul 6.7.Tipuri de atribute

Atribut	Un fel
Caracteristică
Specialitate
Specializare
Loc de munca
Nivel de competență
Nume
Descriere
Disciplina
NUMELE COMPLET. profesor

Să selectăm pentru fiecare entitate atributele cheie care definesc în mod unic entitatea. Pentru entitatea „Student”, acesta va fi un număr unic, pentru entitatea „Experiență de muncă”, toate domeniile sunt cheie, deoarece în diferite specialități un student poate avea experiență de lucru diferită în diferite companii. Esența „Testului” este determinată de nume, deoarece un elev poate avea o singură notă pentru un test. Evaluarea pentru examen este determinată doar de numele subiectului, evaluarea expertului depinde de profesorul care a făcut-o, prin urmare, ca atribute cheie, vom alege „Disciplina” și „Numele complet. profesor ". Pentru entitatea „Limbă străină”, nivelul de competență depinde doar de numele limbii, prin urmare, acesta va fi atributul cheie.

Obținem o nouă diagramă prezentată în Fig. 6.5, unde toate atributele cheie vor fi deasupra barei orizontale din cadrul care reprezintă entitatea.

Orez. 6.5.Diagrama ERD a bazei de date studenți cu atribute cheie

Întrebări de control

1. Care sunt părțile principale ale diagramei ERD?
2. Scopul diagramei ERD.
3. Care este componenta principală a bazelor de date relaționale?
4. Cum se numește entitate?
5. Formulați principiul denumirii entităților.
6. Ce arată relația dintre entități?
7. Care sunt tipurile de relații logice.
8. Cum sunt afișate relațiile logice?
9. Descrieți mecanismul de verificare a adecvării modelului logic.
10. Ce se numește cheie primară?
11. Care sunt principiile după care se formează cheia primară?
12. Ce se numește o cheie alternativă?
13. Ce se numește intrare inversă?
14. Când sunt generate cheile străine?

1. Tema, scopul lucrării.
2. ERD-diagrama serviciului DB Angajare cu atribute si chei.
3. Concluzii asupra muncii

adnotare

Acest curs descrie proiectarea bazei de date a spitalului central al orașului și implementarea acesteia în Oracle Datebase. A fost prezentată tematica, au fost dezvoltate modele de date conceptuale, logice și fizice. Tabelele, interogările, rapoartele necesare au fost create cu ajutorul Oracle Datebase. Termenul hârtie este format din.

Introducere 3

1.Zona specifică 4

2.Modelul conceptual 5

3.Modelul bazei de date logice 7

4 Modelul de organizare a datelor fizice 9

5 Implementarea bazelor de date în Oracle 9

6. Crearea tabelelor 10

7. Crearea de interogări 16

8.Concluzie 27

Referințe 28

Introducere

O bază de date este un depozit unic, încăpător, de diferite date și descrieri ale structurilor acestora, care, după ce a fost definită separat și independent de aplicații, este utilizată simultan de multe aplicații.

Pe lângă date, baza de date poate conține instrumente care permit fiecărui utilizator să opereze doar cu datele care sunt de competența sa. Ca urmare a interacțiunii datelor conținute în baza de date cu metodele disponibile anumitor utilizatori, se formează informații pe care aceștia le consumă și pe baza cărora, în limita propriei competențe, introduc și editează date.

Scopul acestei lucrări de curs este dezvoltarea și implementarea unei baze de date pentru spitalul central care să asigure stocarea, acumularea și furnizarea de informații despre activitățile spitalului. Baza de date creată este destinată în principal automatizării activităților principalelor secții ale spitalului.

Domeniul subiectului

Tematica face parte dintr-un sistem real care prezintă interes pentru acest studiu. La proiectarea sistemelor informatice automatizate, tematica este afișată prin modele de date de mai multe niveluri. Numărul de niveluri depinde de complexitatea sarcinilor de rezolvat, dar în orice caz include niveluri conceptuale și logice.

În această lucrare de curs, tematica este activitatea spitalului central, care tratează pacienții. Structura organizatorică a spitalului este formată din două secții: primirea și camera de urgență. În registru se fac programări, se eliberează trimiteri, pacienții sunt repartizați în secții și se înregistrează numărul de polițe de asigurare. Secția de admitere, la rândul său, ține evidența internărilor și externărilor, diagnosticele pacienților și istoricul medical.

Baza de date este destinată stocării datelor despre pacienți, cazarea acestora, medicamentele prescrise și despre medicii curant.

Model conceptual

Prima fază a procesului de proiectare a bazei de date este crearea unui model conceptual de date pentru partea analizată a întreprinderii.

Un model conceptual este un model de domeniu. Componentele modelului sunt obiecte și relații. Modelul conceptual servește ca mijloc de comunicare între diferiți utilizatori și, prin urmare, este dezvoltat fără a ține cont de particularitățile prezentării fizice a datelor. La proiectarea unui model conceptual, toate eforturile dezvoltatorului ar trebui să fie îndreptate în principal către structurarea datelor și identificarea relațiilor dintre acestea, fără a lua în considerare caracteristicile de implementare și problemele de eficiență a procesării. Proiectarea modelului conceptual se bazează pe analiza sarcinilor de prelucrare a datelor rezolvate în această întreprindere. Modelul conceptual include descrieri ale obiectelor și interrelațiile lor care sunt de interes în domeniul subiectului luat în considerare. Relațiile dintre obiecte fac parte din modelul conceptual și trebuie afișate în baza de date. Relația poate cuprinde orice număr de obiecte. Pe de altă parte, fiecare obiect poate participa la orice număr de link-uri. Odată cu aceasta, există relații între atributele unui obiect. Există relații de tipul: „unu la unu”, „unu la mulți”, „mulți la mulți”.

Cel mai popular model de design conceptual este modelul entitate-relație (ER-model), se referă la modele semantice.

Elementele principale ale modelului sunt entitățile, relațiile dintre acestea și proprietățile (atributele) acestora.

O entitate este o clasă de obiecte de același tip, informații despre care trebuie luate în considerare în model.

Fiecare entitate trebuie să aibă un substantiv la singular. Fiecare entitate din model este reprezentată ca un dreptunghi cu un nume.

Atributul este o caracteristică (parametru) a unei anumite entități.

Domeniul este un set de valori (sfera definiției atributelor).

Entitățile se disting prin atribute cheie - o cheie de entitate este unul sau mai multe atribute care definesc în mod unic o entitate dată.

Un set de entități pentru spitalul central (atributele entităților sunt indicate între paranteze, atributele cheie sunt subliniate):

PACIENTII ( Codul pacientului, nume, prenume, data nașterii, numărul poliței de asigurare, codul sucursalei);

TRATAMENT ( Codul pacientului, diagnostic, data externarii, cod medic, cost);

RAMURI ( Codul filialei, numele departamentului, numărul secțiilor);

SURSA DE VENIT ( codul pacientului, data admiterii, codul camerei);

CAMERE ( Codul camerei, numărul de locuri, codul filialei);

MEDICII(Cod medic, prenume, nume, data nașterii, numărul dosarului personal, codul filialei);

O diagramă entitate-relație pentru un spital raional este prezentată în Figura 1.

Model de bază de date logic

Versiunea modelului conceptual care poate fi furnizată de un anumit SGBD se numește model logic. Procesul de construire a unui model de bază de date logică ar trebui să se bazeze pe un model de date specific (relațional, de rețea, ierarhic), care este determinat de tipul de sistem informațional SGBD destinat implementării. În cazul nostru, baza de date este creată în mediul Oracle și va fi o bază de date relațională.

Modelul relațional se caracterizează prin simplitatea structurii datelor, prezentarea tabelară ușor de utilizat și capacitatea de a utiliza aparatul formal al algebrei relaționale și calculului relațional pentru a manipula datele.

În modelele de date relaționale, obiectele și relațiile dintre ele sunt reprezentate folosind tabele. Fiecare tabel reprezintă un obiect și este format din rânduri și coloane. Un tabel dintr-un model relațional se numește relație.

Atribut (câmp) - orice coloană din tabel.

Tuplurile (înregistrările) sunt rânduri de tabel.

Tabelele sunt legate între ele folosind câmpuri cheie.

O cheie este un câmp care identifică în mod unic o înregistrare dintr-un tabel. Cheia poate fi simplă (constă dintr-un câmp) sau complexă (conține mai multe câmpuri).

În bazele de date relaționale, proiectarea logică duce la proiectarea schemei de date, care este prezentată în Figura 2.

Fig. 2.
4. Model de organizare fizică a datelor

Modelul fizic de date descrie modul în care datele sunt stocate într-un computer, oferind informații despre structura înregistrărilor, ordonarea acestora și căile de acces existente.

Modelul fizic descrie tipurile, identificatorii și lățimea de biți a câmpurilor. Modelul fizic de date reflectă locația fizică a datelor pe suportul mașinii, adică ce fișier, ce obiecte, cu ce atribute conține și ce tipuri de aceste atribute sunt.

© 2015-2019 site
Toate drepturile aparțin autorilor lor. Acest site nu pretinde autor, dar oferă o utilizare gratuită.
Data creării paginii: 26-04-2016

Un model de date logic este o descriere a obiectelor din domeniul subiectului, atributele lor și relațiile dintre ele, în măsura în care acestea sunt supuse stocării directe în baza de date a sistemului.

Modelul logic este construit în mai multe etape cu o abordare graduală a opțiunii optime pentru condițiile date. Eficacitatea unui astfel de model depinde de cât de aproape reflectă domeniul studiat. Tematica cuprinde obiecte (documente, conturi, operațiuni asupra acestora etc.), precum și caracteristicile acestor obiecte, proprietățile lor, interacțiunea și influența reciprocă.

Astfel, la construirea unui model logic de date, în primul rând sunt identificate acele obiecte care prezintă interes pentru utilizatorii bazei de date proiectate. Apoi, pentru fiecare obiect, sunt formulate caracteristici și proprietăți care descriu în mod adecvat obiectul dat. Aceste caracteristici vor fi reflectate în continuare în baza de date ca câmpuri corespunzătoare.

Modelul logic de date este construit folosind una dintre cele trei abordări pentru crearea bazelor de date. Se disting următoarele tipuri de modele de baze de date logice:

Ierarhic;

Reţea;

Relațional.

Modelul ierarhic este o structură arborescentă care exprimă legăturile de subordonare ale nivelului inferior la nivelul superior. Acest lucru face mai ușor să găsiți informații dacă interogările au aceeași structură.

Modelul de rețea diferă de cel precedent și prin prezența legăturilor orizontale. Acest lucru complică atât modelul, cât și baza de date în sine și mijloacele de gestionare.

Modelul relațional reprezintă informațiile stocate sub formă de tabele, peste care pot fi efectuate operații logice (operații de algebră relațională). În acest moment, acest tip de model este cel mai răspândit. Acest lucru se datorează ușurinței relative de implementare, definiției clare a relației dintre obiecte, ușurinței schimbării structurii bazei de date.

Descrierea utilizatorilor și a grupurilor de utilizatori ale sistemului

Sistemul de informare și referință dezvoltat poate fi utilizat atât de personalul cinematografului, cât și de către vizitatori. Un angajat al cinematografului poate oferi editarea informațiilor disponibile despre filmele disponibile, poate modifica programul de funcționare al cinematografului, poate include filme nou primite în repertoriul cinematografului; iar vizitatorul poate vizualiza informații despre programul de deschidere al cinematografului, prețurile biletelor, filmele de astăzi.

Model de domeniu

Unul dintre cele mai convenabile instrumente pentru reprezentarea unificată a datelor, independent de software-ul care îl implementează, este modelul entitate-relație (ER-model). Modelul entitate-relație se bazează pe câteva informații semantice importante despre lumea reală și este conceput pentru a reprezenta în mod logic datele. Definește valorile datelor în contextul relației lor cu alte date. Categoriile „esență” și „conexiune” sunt declarate fundamentale și sunt separate în stadiul realizării reprezentărilor specifice unui anumit domeniu.

Fiecare entitate aparține unei anumite clase, cu alte cuvinte, corespunde unui anumit tip. Există relații între entități pe care utilizatorul le atribuie unei anumite clase (tip). Astfel, o clasă de entități și o clasă de relații definesc seturi de obiecte specifice și relații între ele. O entitate poate aparține mai multor clase.

Colecția de entități și clase de relații formează nivelul superior al modelului.

Entitățile și relațiile sunt descrise prin atributele lor caracteristice. Printre atributele unei entități sau ale unei relații, se distinge o sublistă, ale cărei valori de atribute identifică în mod unic entitatea sau relația în cadrul tipului. Entitățile, relațiile și atributele formează nivelul inferior al modelului.

Este important ca toate modelele de date existente (ierarhice, de rețea, relaționale, obiect) să poată fi generate din modelul entitate-relație, de aceea este cel mai general.

Modelul entitate-relație este prezentat în Anexa E.

O bază de date relațională constă din tabele normalizate. În procesul de încărcare și ajustare a bazei de date, pentru a obține informații despre interogări și rapoarte de ieșire, precum și pentru a rezolva majoritatea sarcinilor, este necesar să accesați simultan mai multe tabele interconectate. Relația dintre tabelele bazei de date este stabilită prin relații relaționale.

Legăturile definite în schema de date sunt utilizate automat la dezvoltarea formularelor multitabulare, interogărilor, rapoartelor, simplificând foarte mult procesul de proiectare a acestora.

Produsul software este reprezentat de proiectul Cinema, care are 4 tabele interconectate:

Bilety - informații despre biletele vândute;

Filme - informații despre toate filmele disponibile în cinema;

Seansy - informații despre ora ședințelor și costul biletelor pentru aceste ședințe;

Astăzi - informații despre filmele care vor fi difuzate astăzi.