Alegere chei primare
Last Updated: Mar 03 2015 12:19, Started by
sinterklaas
, Feb 26 2015 21:36
·
0
#1
Posted 26 February 2015 - 21:36
Am tabela :
MECIURI_JUCATORI {idMeci, idJucator, minutIntrare, minutIesire, post, minutCartonasGalben, minutGolMarcat} Ce cheie primara ar avea tabela in cazul in care : 1. - un singur jucator poate primi, intr-un meci, un singur cartonas galben - un jucator poate marca, intr-un meci, zero sau mai multe goluri 2 . - un jucator poate primi, intr-un meci, unul sau doua cartonase galbene - un jucator poate marca, intr-un meci, zero sau mai multe goluri Pe langa intrebarea de baza, conditiile de la 1 sau 2 trebuie indeplinite concomitent sau separat ? Initial, am considerat cheie primara la 1. idMeci, IdJucator,minutCartonasGalben iar la 2.idMeci, idJucator.. Ce parere aveti ? Multumesc ! |
#2
Posted 26 February 2015 - 21:51
Din moment ce perechea {idMeci, idJucator} e unica in tabel, o poti folosi drept cheie primara.
Golurile marcate n-au ce cauta in acel tabel. Asemenea si cartonasele. |
#3
Posted 26 February 2015 - 22:00
Tabela nu este creata de mine, din pacate..este o problema careia nu-i dau de cap .. spre exemplu, mai am una insa aceasta are raspuns:
COMENZI_AGENTI {idAgent, numeAgent, eMailAgent, nrComanda, dataComanda,idClient, numeClient, eMailClient,idProdus, denProdus, um, cantitateComandata,pretUnitar, discountProdus, totalComanda} Care este cheia primara a tabelei COMENZI_AGENTI in urmatoarele situatii: 3.1. - numarul comenzii este unic la nivel national - un produs apare o singura data intr-o comanda Raspuns corect: d. (nrComanda, idProdus) 3.2 - numarul comenzii este unic la nivel national - un produs poate aparea de mai multe ori intr-o aceeasi comanda 3.3. - numarul comenzii este unic la nivel agent de vanzari - un produs apare o singura data intr-o comanda Cerintele sunt incurcate oarecum, fapt pentru care parca ma invart in cerc.. la 3.2 cheia primara, functie de cerinta, nu este {nrComanda, denProdus} ? Edit: La 3.1 e logic fiindca specifica faptul ca numarul comenzii si produsul sunt unice, ceea ce le fac sa fie o cheie primara compusa... insa la 3.2 daca produsul poate aparea de mai multe ori, nu ar mai putea fi cheie primara.. corect? Edited by sinterklaas, 26 February 2015 - 22:07. |
#4
Posted 26 February 2015 - 22:29
Deseori se adauga un id (autonumber/guid) ce are doar rolul de a identifica o inregistrare in tabel.
|
#5
Posted 26 February 2015 - 23:22
dani.user, on 26 februarie 2015 - 22:29, said:
Deseori se adauga un id (autonumber/guid) ce are doar rolul de a identifica o inregistrare in tabel. In cazul acesta, daca am cerinta( tot legata de ultima tabele postata) : - numarul comenzii este unic la nivel de data calendaristica (zi de vanzari) - un produs apare o singura data intr-o comanda , cheia primara o reprezinta {nrComanda; dataComanda} ? |
#6
Posted 03 March 2015 - 12:19
sinterklaas, on 26 februarie 2015 - 21:36, said:
Am tabela : MECIURI_JUCATORI {idMeci, idJucator, minutIntrare, minutIesire, post, minutCartonasGalben, minutGolMarcat} Ce cheie primara ar avea tabela in cazul in care : 1. - un singur jucator poate primi, intr-un meci, un singur cartonas galben - un jucator poate marca, intr-un meci, zero sau mai multe goluri 2 . - un jucator poate primi, intr-un meci, unul sau doua cartonase galbene - un jucator poate marca, intr-un meci, zero sau mai multe goluri Pe langa intrebarea de baza, conditiile de la 1 sau 2 trebuie indeplinite concomitent sau separat ? Initial, am considerat cheie primara la 1. idMeci, IdJucator,minutCartonasGalben iar la 2.idMeci, idJucator.. Ce parere aveti ? Multumesc ! Eu in primul rand as normaliza baza ta de date, separand tabelele si nu as tine toate coloanele alea intr-un singur tabel.. Pe urma in tabele separate, unul pentru meci si unul pentru jucatori, as pune ca si cheie primara ID_Meci in tabela cu meciuri si ID_Jucator in tabela cu jucatori, pe urma poti folosi JOIN pentru a uni tabelele si a obtine datele dorite. |
Anunturi
Bun venit pe Forumul Softpedia!
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users