10. februar 2003 - 14:50Der er
11 kommentarer og 2 løsninger
Afhængige poster i dynamisk database
Jeg arbejder i øjeblikket med et projekt, hvor jeg har brug for en meget dynamisk database, da der ikke er koncensus om, hvad der egentlig skal registreres i databasen. Ergo er det meget nødvendigt, at det bliver muligt at udvide db'en dynamisk - her har jeg dog et problem.
Det er ikke noget problem med "alm." dynamik. Jeg har f.eks. følgende tabeller:
Person - id (primærnøgle) - navn - adresse - postnr
PersonStamdataTyper - id (primærnøgle) - beskrivelse
PersonStamdata - id - typeId (fremmednøgle til PersonStamdataType) - personId (fremmednøgle til Person) - entry
Som det fremgår af de 3 tabeller, er det muligt at udvide tabellen med en vilkårlig PersonStamdataType (som f.eks. tlf.nr.). Samtidig med, at det ikke behøves at være samtlige personer, som man registrerer posten for.
MEN samtidig har jeg statisk sat postnr. ind i Person-tabellen. Denne refererer naturligvis over i en traditionel postnr/by tabel. Sådanne afhængige data ville jeg meget gerne også kunne registrere i en dynamisk db. Men hvordan skulle databasen strikkes sammen, så man kan registrere sådanne afhængige/ens data uden redundans?!?
Problemstillingen vedr. den statiske adresse attribut er lidt den samme... for denne kunne jeg også godt tænke mig, at man kunne presse ind i en dynamisk db struktur!
Du har fat i det rigtige. Du skal have en stam tabel hvor hver overordnet enhed ar defineret unikt. derefter skal du have en attribut tabel, hvor hver atribut f.eks. postnr er beskrevet, tilsidst skal du have en relationstabel mellem stamdata og attribut, med atributtens value som ekstra information
For hver atrribut jan du definere en valid-value tabel
Valid-Value - id.attribut (pst, - Value-entry (4000,5000... - Value-beskrivelse ("Roskilde","Odense",... (- sort hvis værdierne skal præsenteres i en bestem rækkefølge) (- defaultvalue hvis en af værdierne skal indsættes som default)
Valid-Value tbaellen kan bruges til at lave dropdown lister og validere input
Statisk/dynamisk er ikke lige ord jeg plejer at bruge om databaser :)
Jeg synes du skal kigge på brugen af null-værdier.
eks postnr i tabellen Person Hvis en person har postnr SKAL den være i tabellen postnr, ellers skal feltværdien være Null. På den måde kan bruger af din database registrere kunder i Tyskland og Australien. Et notatfelt til at uddybe persondata kunne gøre databasen 'dynamisk'.
Det vil dog blive noget besværligt at udvikle en sådan database senere, især for en anden end dig.
Forstår vist ikke helt spørgsmålet, f.eks. som "nih" ordene "dynamisk" og "statisk". For mig er en statisk database en base, hvor brugeren ikke kan ændre data, f.eks. en varekatalog.
Til dit egentlige spørgsmål: Hvis det du ønsker er et system, hvor forskelige databaser bruger nogle fælles data (stamdata) er det meget nemt. Du laver blot en database, som kun består af tabeller med dine "stamdata". Databasen lægges centralt, så alle har adgang til den.
I de enkelte baser bruger du "Sammenkæde" med tabellerne i den centrale base. Kig under Filer/Hent externe data.
Jeg har været væk fra projektet i nogle dage og har brugt noget af tiden på at tænke over indlæggene...
For det første virker det som om, at første mand på posten havde det bedste bud på min problemstilling. Jeg kan se, at vores tabelstruktur er stort set identisk - dog med den forskel, at jeg har adresse, navn og postnr i persontabellen. Jeg går ud fra, at du ville holde disse poster i PersonStamdataTyper (for at holde sig til min oprindelige navngivning).
Her vil du - som jeg forstår det - knytte en tabel, som kan bruges til validering. Dette tabel kunne se ud, som følgende
Validering - postnr. - by - typeId (fremmednøgle til PersonStamdataTyper)
Man kunne evt. give nogle mere sigende navne såsom "validering", "kriterie1", "kriterie2" og bibeholde typeid. Således ville man evt. kunne bruge tabellen til validering af andre stamdatatyper end postnr/by (uden at jeg dog kan komme i tanke om noget sigende eksempel). Dermed ville man også komme udenom brugen af "by" som naturligvis er et reserveret ord i sql...
>> arnvig Er denne "implementation" rigtigt forstået ud fra din oprindelige tankegang??
>> alle Kommentarer udbedes - også forslag til den generiske navngivning af attributter i valideringstabellen
Med det nævnte design har jeg dermed afskåret mig fra at bruge null-værdier, som redskab til at styre, om der skal indtastes data eller ej. Dette kunne alternativt klares med en boolean attribut i PersonStamdataTyper, som i den ovenliggende applikation kan bruges til at gennemtrumfe indtastning vha. logik. Kommentarer udbedes!
Vedr. dynamisk/statisk... Når jeg skriver dynamisk database, henviser jeg til strukturen på databasen og dermed mulighed for at opbygge et design, som kan håndtere et endnu ikke fastlagt mængde af data. Vel at mærke uden at skulle ændre i atributter eller tabeller (antal såvel som navne)...
It-dyret: Du har forstået konceptet. Indtastet eller ej, kan implementeres med et indikator felt, en boolean, som indeholder "0" hvis værdien ikke er der eller "1" hvis den er. Men det er en performance tung løsning, hvis ikke din DBMS selv kan håndtere det.
Jeg kan tilføje at fra og med Access 2000 kan man omdøbe tabeller og felter uden at skulle lave foresp. formulare og rapporter om.
i VBA kan du henvise til dine feleter vha. indexet af feletet
rs.fields(1).value = xx
istedet for rs!feltnavn
mvh Niels
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
