Toon posts:

[DBS] boomstructuur in database

Pagina: 1
Acties:
  • 151 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Vooraf: ik ben een newbie!

Ik ben bezig een bedrijfsproces in een database te zetten. Hiervoor gebruik ik visual webdeveloper met een sql 2005 express database. De tabellen hebben globaal de volgende indeling:

[proces] id, naam

[proces_fasen] proces, id, naam

[proces_stappen] proces, fase, id, naam

Het wordt dus een soort van boomstructuur. Wanneer ik echter de relatie wil leggen in de
tabel 'proces_stappen' kolom 'fase' met tabel 'proces_fasen' kolom 'id'
krijg ik een foutmelding. De kolom is uit de tabel fase is niet uniek.

Ik zie natuurlijk ook dat deze niet uniek hoeft te zijn, maar ik zou niet weten hoe ik dit zou moeten oplossen.

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 11-04 17:49

NMe

Quia Ego Sic Dico.

Welkom op GoT. :)

Ik ben bang dat we niet veel kunnen zeggen over dit probleem zonder te zien wat je exact doet op het moment dat het fout gaat, en bovendien wat de exacte foutmelding is. Op dit moment is het een beetje giswerk. ;)

Verder is je opzet een beetje raar. Een fase lijkt me feitelijk hetzelfde als een proces, maar dan op een wat lager niveau. Datzelfde geldt voor de relatie tussen fases en stappen. Wat dat betreft kun je dus beter één tabel maken in plaats van deze drie, die je deze opbouw geeft:
proces
id, naam, parent_id

Hierbij is parent_id een verwijzing naar het parent-proces. Stap 1 heeft bijvoorbeeld Fase 1 als parent, en Fase 1 heeft dan weer Proces 1 als parent. Proces 1 heeft geen parent, aangezien hoofdprocessen het laatste niveau zijn. Bij alles wat je in je eigen tabelstructuur in de proces-tabel zou zetten, geef je dus als parent_id NULL op. Voor meer informatie over boomstructuren in databases kun je dit eens lezen. Dit document is dan wel voor de combo MySQL/PHP bedoeld, maar zeker waardevol om te lezen. :)

Overigens is een samengesteld foreign key niet echt handig IMO. Je kan beter elke tabel een eigen id-veld geven, aangezien dat veel praktischer is bij het opzetten van relaties.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Verwijderd

Topicstarter
Hartelijk dank voor de reactie.

Aan de opzet met de parent had ik zelf ook al zitten denken, aangezien die ik hier op de forums al een aantal keren tegen ben gekomen. de fasen en stappen hebben echter andere eigenshappen die ik wil opslaan.

Is het misschien verstandig om dan deze tabel:

[id] [omschrijving] [soort] [parent] (soort is dan: proces, fase of stap)

te koppelen aan aparte tabellen met de eigenschappen?

edit

Ik zal later nog wat meer toelichten. Ik heb vanavond helaas mijn verplichtingen (kroeg) :*)

[ Voor 11% gewijzigd door Verwijderd op 04-02-2006 19:40 ]


  • Morpheus_at_work
  • Registratie: December 2000
  • Laatst online: 07-04 21:38
iedere tabel kent zijn eigen id en parent_id

in je huidige opzet ga je van een fact tabel een dimensie maken , waarin je van tabel 1 en 2 een dimensie maakt van tabel 3.

ik mis hierbij een echte fact tabel waarin je de 3 dimensie , makkelijk plat kan slaan naar 2 dimensie tabellen waarin tabel 1-2 samengevoegd worden in een proces/proces fase tabel
je maakt nu 2 dimensie tabellen om aan 1 dimensie tabel te hangen.

iets met lenzen


Verwijderd

Topicstarter
Ik moet zeggen: 'het klinkt overtuigend'. Ik moet alleen wel toegeven dat ik er niet veel van kan maken (ligt aan mij). Is de opzet die ik later aangeef wel meer in de goede richting?

Het zit namelijk zo:

Ik ben bezig met mijn afstudeeropdracht voor bedrijfseconomie. De opdracht is een AO (administratieve organisatie) handboek maken en verbetervoorstellen formuleren.

Nu wil ik als een soort hobby dit handboek gestructureerd vast gaan leggen. De meeste handboeken verdwijnen namelijk in de onderste lade en verdwijnen vervolgens onder een dikke laag stof.

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 04-01 15:49

JHS

Splitting the thaum.

Als een fase écht andere eigenschappen heeft als een proces horen ze niet in dezelfde tabel. Stel een proces heeft managers, een fase heeft kleuren en een stap heeft een tijdsduur (bijvoorbeeld), dan horen ze duidelijk in andere tabellen. Dan krijg je dus zoiets: (In de step tabel moet / hoeft geen referentie naar een proces aangezien de die afgeleid kan worden uit de fase waar hij bij hoort.

table: processes
  id
  name
  manager

table: phases
  id
  name
  color
  proces_id 
  foreign key (proces_id) references pages(id)

table: steps
  id
  name
  time
  fase_id
  foreign_key (fase_id) references fases(id)


Ik snap eerlijkgezegd niet veel van je uitleg, of eigenlijk: hoe deze database in relatie staat tot het handboek. Bestaat het handboek uit processen (die bestaan uit (...))? En zoja, waar ga je je toelichting dan laten? Hoe moet de database gebruikt worden, en door wie?

DM!


Verwijderd

Topicstarter
De opzet die jij hierboven aangeeft was mijn eerste idee en lijkt mij ook nog steeds de beste optie.

Ik loop dus alleen tegen het volgende probleem aan:
Wanneer ik de relatie wil aanmaken: foreign_key (fase_id) references fases(id)

krijg ik een error in visual web developer:
'The columns in table 'fases' do not match an exsisting primary key or UNIQUE constraint.

De database wordt in feite gebruikt voor de structuur van het handboek. De tekstuele uitleg wordt opgeslagen als tekstbestanden als een link in de database (of misschien in de database zelf). Het moet voor de medewerkers in de toekomst dan mogelijk zijn de uitleg aan te passen. Door met autorisaties te werken wil ik voorkomen dat uitleg gewijzigd wordt door onbevoegden.

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Verwijderd schreef op zondag 05 februari 2006 @ 22:37:
krijg ik een error in visual web developer:
'The columns in table 'fases' do not match an exsisting primary key or UNIQUE constraint.
Die melding is toch duidelijk/logisch? Je moet een foreign key naar een unieke kolom leggen. Hoe moet je (dbms) anders weten welke van de matchende records ie precies moet hebben?

En het lijkt me dat je parent tabel wel een primary key zou kunnen krijgen, toch? Desnoods een surrogaat key.
Pagina: 1