[LØST] Bedømme om en Person er ikke medlem eller ikke medlem

15 innlegg i emnet

Skrevet

Heisann database-eksperter!

Jeg har laget en ER-Modell over eiendeler eid av et firma.

1. Medlemmer av firmaet o.l kan låne eiendeler

2. Firmaet o.l kan låne gjenstander fra andre firma og i tillegg deres egne medlemmer.

3. nok en gang; det er kun MEDLEMMER som kan låne gjenstander.

Se litt på denne enkle oversikten:

db.jpg

Først hadde jeg en tabell: Person og to tabeller: ikke-medlem og medlem som arvet fra person og en "Lånt i fra" relasjon inn til ikke-medlemmer.

Men eiendeler kan jo også være lånt i fra medlemmer!

Det jeg tenker da er følgende:

I Tabellen Person, lage en slags bools attribut som sier om personen er medlem eller ikke-medlem.

Men husk: det er kun medlemmer som kan låne gjenstander! Så då meg ha en slags begrensning som sier at "LÅNT TIL" relasjonen kun virker på personer som har medlem = true !

Går det ann å implementere min tankegang? Er det en god løsning? Hvordan gjør jeg det? Har dere bedre løsninger?

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Refererer til min tidl. post som forklarer oppbygging av db..http://itpro.no/supportforum/index.php?s=&...st&p=468498

Jeg regner med du snakker om kolonnene 'person', 'ikke_ medlem', 'medlem' etc. i en tabell??

Mulig du har en eller annen syk database, men dette høres helt villt ut for meg, slik som du forklarer det..

Ps.: er det noen som er ikke medlem a? Enten så er du vel medlem, eller ikke medlem, altså vanlige personer som ikke har noe med firma å gjøre, er jo ikke medlemmer, men ingen vits å nevne dem i databasen da..

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Jeg gjentar:

Det er en eiendelsdatabase for en organisasjon.

Organisasjonen har medlemmer.

Disse eiendelene kan medlemmer låne av organisasjonen, men organisasjonen kan også låne GJENSTANDER FRA ANDRE organisasjoner (dvs ikke medlemmer) MEN organisasjonen kan også låne gjenstander fra sine medlemmer.

Det er bare slik oppgaven her. Jeg kan ikke endre oppgaven dessverre.

Da tenkte jeg at når jeg skal registrere en person, så må personen være medlem eller ikke medlem.

Var dette mer forståelig?

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Du kan jo legge inn hva du vil som felt i en database ?

En bolsk variabel tar akkurat like mye plass som et byte - så det er samme om du velger "0 eller 1" eller "True or False" for å skille mellom medlemmer og fremmede.

Begge deler kan faktisk leses "om hverandre" uten særlig problemer.

----------------

Normalt løses dette av 2 databaser som henter data fra hverandre - MEDLEM og TING.

Hvis du ikke har lært om slikt enda følg det du har lært.

----------------

Felt i en database, eksempel:

RecordNummer: Et unikt nummer. Dette håndteres vanligvis internt i databasen (det er ikke et vanlig felt)

Medlemsnummer: Dette pleier å være den UNIKE id-en (det eneste feltet som MÅ være forskjellig hos alle medlemmerr).

......................La ikke-medlemmer få en annen "range" på nummer enn medlemmer for å skille dem.

Etternavn:

Fornavn:

Avdeling: Du sa at dette gjaldt et firma ?

Gate/vei:

Postnr.:

Poststed:

osv.

Føy eventuelt til ett felt som skiller medlemmer fra ikke-medlemmer = STATUS

Felt i den andre databasen - TING:

RecordNummer

Varenummer

Beskrivelse

Utlån (registrer om gjenstand er utlånt til ... medlemsnummer)

Innlån (det blir litt slitsom å låne fra noen som ikke har medlemsnummer)

osv.

------------------

Det jeg satt opp med blått er 2 forslag til løsninger

Mest praktisk er det å la ikke-medlemmer få et nummer også, men i en annen nummer-range enn medlemmer. Uten dette blir det et helvete å holde styr på hva som lånes av ikke-medlemmer.

Utlån registreres kun på medlemsnummer, men det bør være mulig å få opp opplysninger om navn osv. i et vindu ?

Status-feltet er egentlig ikke nødvendig. Det holder fint med at de har forskjellig nummer-range for å skille dem.

Andre spørsmål (du løser disse selv):

- Auto-tildeling av medlemsnummer ? La programmet "spytte ut" neste ledig nummer ?

- Skal medlemsnummer til slettede medlemmer brukes på nytt ? (dropp dette, det blir mer komplisert).

- Er det noen begrensninger i hvor mange ting de kan låne ?

Oooops. Jeg må avslutte. Jeg har 250 mistenkelige ting på maskinen etter å ha sjekket opp linker i en norsk spyware-portal.

(bedriftsguiden.no sine linker til antispyware-programmer og registry-programmer)

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Jo jeg liker tankegangen din om å registrere personer med to forskjellige medlemsnummer "ranger".

Men "LÅNT TIL" feltet mitt i gjenstandstabellen må da på en måte kun fungere mot den medlems "rangen". Har dere en syntaks på det? :)

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Du kan legge opp Person tabellen din med et ID felt. En PersonID som er autogenerert som alle personer har og som er unik for hver person. Så kan du ha et felt til som viser om Personen er medlem eller ei (0 eller 1).

Du har Eiendeler og Personer. En Person kan låne mange Eiendeler men en Eiendel kan kun lånes av en Person (om gangen). Hvis vi ser vekk i fra historikk over utlån så der det slik du har det. Du har et mange til en forhold og det kan løses med å legge et felt til Eiendeler for å vise hvem som låner denne Eiendelen, f.eks. "LåntTil". Det feltet knyttes til Person.PersonID. En Eiendel har også et "LåntFra" felt som viser hvor de har fått Eiendelen fra og som også knyttes til Person.PersonID. Dette er slik du har illustrert det.

Så har du problemstillingen din om at du vil begrense utlån til kun medlemmer. Dette er noe som normalt kunne vært løst i forretningslaget i en tre-lags arkitektur men jeg forstår det slik at du vil ha det inn i databasen.

Da kan du legge til et felt, Person.MedlemID, som blir generert av applikasjonen din når det opprettes et medlem. Det kan ikke genereres automatisk av databasen siden ikke alle skal ha det. Det blir da et nummer som bare medlemmer vil ha. Det kan være et derivat av Person.PersonID (f.eks. at MedlemID er PersonID + 1000000) men trenger ikke det. Det er heller ikke noe problem om det finnes PersonID og MedlemID som er like eller om en Person har en PersonID som er det samme som en annen Person sin MedlemID. De to feltene skal nemlig aldri brukes om hverandre og kan utmerket godt overlappe.

Så tar du Eiendel.LåntTil feltet og knytter til MedlemID. Dette er i prinsippet noe av det samme som Morten58 sa.

I en relasjonsdatabase kan du normalt sette kriterier for en relasjon og bestemme at verdien som skal inn i Eiendel.LåntAv må eksistere i Person.MedlemID. Ergo er det umulig å låne en gjenstand til noen som ikke har en MedlemID, og det har bare medlemmene og dermed kan kun medlemmer låne Eiendeler.

Eiendel.LåntFra knyttes fremdeles til Person.PersonID slik at Eiendeler kan lånes fra alle registrerte personer.

Hjalp dette?

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Ska se om jeg forstod dette her

Jeg har en tabell Person ( PersonID (auto generert primærnøkkel?) , medlemsstatus ( 0 eller 1, medlem eller ikke ) )

Stemmer det?

Hang ikke helt med på det med Person.MedlemsID

Hvorfor kan ikke Eiendel.erLåntTil knyttes til medlemsstatus?

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Nei, det er akkurat det du ikke skal ha. Det var det første du foreslo og da er det nødvendig å håndtere i forretningslaget at kun medlemmer skal få låne.

Du har PersonID ja og så fjerner du medlemsstatus og innfører MedlemID. Det er en annen ID enn PersonID (men kan godt være lik, lignende, overlappende eller helt forskjellig, opp til deg).

Eiendel.LåntTil knyttes da til Person.MedlemID. Eiendel.LåntTil kan ikke knyttes til medlemsstatus siden de ikke er av samme type (det er vanskelig å bruke ett 0/1 felt til å vise hvem som har lånt noe med mindre du bare har to medlemmer).

Eksempel:

Du har tre personer:

PersonID	 MedlemID	  Navn

	   1	   100001	  Luke Skywalker

	   2				   Anakin Skywalker

	   3	   100003	  Han Solo
Anakin er ikke medlem (han har blitt ond og holder seg mest for seg selv) men Luke og Han er medlemmer. Her har jeg bare satt MedlemID til det samme som PersonID-en + 100000 for å vise tydeligere hvor jeg bruker hva. Så har du Eiendelene dine:
EiendelID	 LåntTil	  LåntFra	 Navn

		1	  100001			2	 Lyssabel

		2	  100003			2	 Dødsstjernetegninger

		3						1	 Hånd

		4	  100001			3	 Blaster

Her er Eiendel 1 og 4 (Lyssabel og Blaster) lånt ut til Luke mens Han har lånt tegningene til dødsstjernen. Både lyssabelen og tegningene er lånt fra Anakin (ikke sikkert at han er klar over det dog), en hånd er lånt fra Luke (ingen har lånt den videre dog, mulig de ikke vet hvor den er) og blasteren er opprinnelig lånt fra Han Solo.

Anakin kan ikke låne noe siden han har ikke en medlem ID og i relasjonene dine kan du spesifisere at LåntTil kan kun ha verdier som allerede eksisterer i MedlemID.

Bedre?

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Ja jeg skjønner tegninga her, helt klart :)

Men det med primærnøkkel og fremmednøkkel, er jo det som binder dette sammen.

Jeg ser ikke helt hva du vil ha som primærnøkkel

foreign key erLantTil REFERENCES person(medlemsID) , dette du mener?

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Jepp. Person.PersonID er primærnøkkel i Person tabellen og Eiendel.EiendelID er primærnøkkel i Eiendeltabellen.

Person.MedlemID blir en nøkkel men ikke en primærnøkkel. Den blir det som vi kaller en index

CREATE UNIQUE INDEX unique_medlemID ON Person (MedlemID)
Unique sikrer at ikke to personer kan få samme medlemsnummer. Eiendel.LåntTil blir da en fremmednøkkel (fremmednøkler trenger ikke å knyttes til primærnøkler, bare unike nøkler) slik som du sa:
foreign key erLantTil REFERENCES person(medlemsID)

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

create table eiendel (

eiendel_ID int,

navn varchar (30),

beskrivelse varhchar (30),

kjennetegn varchar (30),

erLantTil int,

erLantFra int,

primary key (eiendel_ID),

foreign key erLantTil REFERENCES person(medlemID)

foreign key erLantFra REFERENCES person(personID),
create table person (

personID int,

medlemsID int,

navn varchar(30),

adresse varchar(30),

unique(medlemsID),

primary key (personID)

);

Jeg blir glad hvis dette er riktig! :)

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Ser nokså riktig ut herfra. Jeg har ikke testet det men det ser greit ut. Du kan jo sette PersonID og EiendelID til auto_increment med det er bare for enkelhets skyld, det er ikke nødvendig for å løse oppgaven din. PersonID og EiendelID bør derimot settes til NOT NULL for å sikre at de verdiene alltid er fylt ut.

Forøvrig er 30 tegn til beskrivelse og adresse nesten alltid for kort og kan godt være det på navn og.

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Ja, skal fikse på det litt sånn småtteri :)

men unique(medlemsID), er rett syntaks? :)

Det visste jeg faktiskt ikke at fremmednøkler ikke nødvendigvis måtte referere til en primærnøkkel :)

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

UNIQUE (MedlemsID) skal kunne fungere ja (forutsatt at du bruker mySQL som jeg tror du gjør).

Du kan og legge på en unik indeks i ettertid med CREATE UNIQUE INDEX som vist ovenfor.

Du kan også spesifisere unik indeks rett på kolonnen:

create table person (

personID int  NOT NULL AUTO_INCREMENT PRIMARY KEY,

medlemsID int UNIQUE,

navn varchar(30),

adresse varchar(30)

) 

ENGINE=InnoDB;

Husk forresten å bruk InnoDB tabelltypen i mySQL hvis du vil ha støtte for fremmednøkler. myISAM tabellen støtter de ikke.

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Skrevet

Men da ser det ut som vi har funnet en løsning her :)

Takker så mye for hjelpen.

Jeg kommer nok tilbake med flere spørsmål :)

0

Del dette innlegget


Lenke til innlegg
Del på andre sider

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!


Start en konto

Logg inn

Har du allerede en konto? Logg inn her.


Logg inn nå

  • Hvem er aktive   0 medlemmer

    Ingen innloggede medlemmer aktive