Database opzetten : Storing en werkzaamheden

Status
Niet open voor verdere reacties.

Anko66

Gebruiker
Lid geworden
10 aug 2019
Berichten
5
Hallo Allemaal ,
ik ben nieuw hier op het forum en moet mij nog heel wat inlezen
sinds kort heb ik de verantwoording van een technische dienst ,,
op het ogenblik staat de server vol met allemaal excel lijsten , hoop dubbel , maar toch ontbreekt hier en daar net de info die je moet hebben
en ben ik meer tijd kwijt voor het zoeken dan dat de storing is opgelost ,,
dus vandaar ik alles in 1 database wil hebben

had wel al begrepen alvorens je een database gaat aanmaken het beste is om een plan te maken met wat je wilt
op zich een eenvoudige database met wat keuze mogelijkheden tijdens de invoer

Hoop met jullie hulp ik wat kan bouwen , heb totaal geen ervaring met acces dus is buiten een leuke uitdaging , echt vanaf 0 iets opzetten

dit is wat ik met een database wil en mijn opzet die ik in gedachten heb , zoals jullie zien , niet teveel poespas gewoon simpel en eenvoudig
indien jullie toevoegingen hebben of ideeen , zijn natuurlijk welkom

Opzet database

1: Fabrikanten en leveranciers – namen , adres , contact persoon gegevens
2: machines : Met technische gegevens (Dropdown) met koppeling naar naam Fabrikant
Met dropdown keuze welke afdeling of locatie deze staat

3 banden : met technische gegevens (Dropdown) met koppeling naar naam Fabrikant
Met dropdown keuze welke afdeling en of locatie waar deze ligt

4:motoren : met technische gegevens (Pulldown) met koppeling naar naam Fabrikant + foto typeplaatje / motor
Met dropdownkeuze welke afdeling en of locatie waar deze ligt

5:eek:verbrengingen : met technische gegevens (Pull down) met koppeling naar naam Fabrikant + foto typeplaatje / overbrenging

6: pompen : met technische gegevens (, soort pomp Pull down) met koppeling naar naam Fabrikant + foto typeplaatje / pomp

7 Afdelingen lijst met afdelingen maar ook magazijn , werkplaats enz

8: Storingen en werkzaamheden – Pull down of het storing , periodiek onderhoud etc is
Pull down met keuze afdeling met daarbij pull down van machines
Vraag : is het mogelijk dat als je bv afdeling B kiest je alleen in de andere dropdown een lijst krijgt met alleen de machines van afdeling B ?

Als alles klaar is het beginblad maken met snelkoppelingen

Met technische gegevens bedoel ik dus echt alle info die je moet weten ,
oa type , merk enz enz ,,
moet er nog mee beginnen en dacht dus eerst alles maken en dan de koppelingen of
bij leveranciers / fabrikanten beginnen en dan bij hel volgend blad al direct koppelingen maken
ik hoor graag
mvg Anko
 
Allereerst welkom bij HelpMij :). Het opzetten van een database is, zoals je al aangeeft, een lastige klus omdat je altijd moet beginnen met het in kaart brengen van de processen die je wilt kunnen vastleggen. Die processen leiden dan tot gegevensopslag, en daar volgen dan werkwijzes uit. Jouw (redelijk lange) verhaal begint, zoals ik wel vaker zie bij beginners, niet bij het begin, maar bij het eind. :) En dat moet je natuurlijk nooit doen. Als je een huis bouwt, begin je ook niet met het dak, maar met het fundament.
Oftewel: in dit stadium praat je nog totaal niet over keuzelijsten en koppelingen. Beschrijf dus eerst eens het proces dat jullie gebruiken, en dan gaan we van daaruit verder kijken. Om je een tip te geven: beschrijf wat je wilt vastleggen, en wat de resultaten moeten zijn. Ik begrijp dat je een storingen database wilt gaan maken, en dan heb je het dus, vermoed ik, over het vastleggen van storingen. Die storingen kunnen, neem ik aan, van alles zijn: aan motoren, pompen, banden etc. Zo'n storing moet door een monteur worden verholpen, en dan praat je wellicht over monteurs die bij jullie alles doen en kunnen, maar wellicht gaat het over vakmensen die gespecialiseerd zijn. Dat onderscheid moet je in je db ook al maken. Besteed je zaken uit? Wordt niet over gerept. Worden storingen door één persoon uitgevoerd, of door meerdere personen? Wordt niet over gepraat nog.

Bedenk bijvoorbeeld een aantal User stories zoals: "de administratief medewerker moet een storing kunnen invoeren op basis van een bekende klant, en deze kunnen toewijzen aan een behandelgroep (monteurs). Deze moeten een prio kunnen geven aan de melding, en materialen en uren kunnen registreren op de melding. Vervolgens moeten ze de melding gereed kunnen melden waarna de administratief medewerker contact kan opnemen met de klant." Of: "De manager moet altijd een overzicht kunnen zien van welke monteur met welke storing bezig is.". En ga zo maar door.

Kortom: in een Functioneel Ontwerp beschrijf je eerst de huidige werkwijze, en die ga je dan vertalen naar een systeem. Dat hoeft overigens niet eens een database te zijn; nog zo'n denkfout :). Maar in dit geval lijkt mij dat een redelijke oplossing.
 
Goedeavond Octafish
Bedank voor de welkom en tekst en uitleg , zeer duidelijk !
gelukkig is het bij ons niet zo diepgaand, is een klein bedrijf met enkele afdelingen
er zijn in het bedrijf drie mensen van de technische dienst ,
Alleen de Technische Dienst vult eea in ,
er wordt wel eens , wel heel zelden een monteur ingeroepen van betreffende fabrikant ,
maar dit wordt dan weer door mij ingevoerd
dus zoals je zegt per sheet of tabel hoe je het noemt vermelden wat je dus wilt hebben
ik was dit inderdaad al ergens tegengekomen waar je deze tip gaf ,
eea heb ik al gedaan , nog niet alles maar om een voorbeeld te geven van de storingslijst is bijvoorbeeld

Datum - spreekt voor zich
Afdeling - Dropdown of pulldown , en je kan betreffende afdeling selecteren
Machine - Dropdown met lijst van machines - (zou mooi zijn als je bijvoorbeeld bij afdeling , afdeling a gekozen hebt je alleen de machines in de lijst zien welke op die afdeling staan )
Probleem klacht - een invulveld waarin je (kort) de storing omschrijft , ik noem maar wat : ketting van verdeler gebroken , of lekkende cilinder pak arm
Productie stilstand - keuze met ja / nee (klinkt raar maar bv met een kleine storing loopt soms een machine nog , denk bv aan een kleine lucht lekkage , maar moet wel verholpen worden
werktype - dropdown menu met : storing - Preventief onderhoud - planmatig onderhoud - Revisie
symptoom : invulveld waarin je beschrijft wat bv de machine niet doet - dit is handig indien het een probleem is die moeilijk uit te vinden is , en door deze notitie wellicht in de toekomst eenvoudiger terug te vinden is (wellicht overbodig omdat je ook probleem / klacht hebt (is nog een nadenkertje )
Oorzaak - tekstveld met Vermelding van de oorzaak
Gebruikte onderdelen - invulveld , aangezien wij duizenden onderdelen hebben ( vele mechanische machines , is het geen goed idee om dit allemaal in te voeren maar gewoon even invullen)
Actie - invulveld met omschrijving wat er in het kort gedaan is
Extra info : wat extra info wilt toevoegen , bv tijdens de reparatie nog iets is ontdekt wat meegepikt moet worden oid

je ziet het is niet echt allemaal zo spannend , eea deden wij nu in excel voldoet ook wel maar de voorgangers hebben zoveel excellijsten gemaakt
dat de keuze op een db toch wel makkelijker is , bv ook met vermelding van de motoren , pompen enz
was in eerste instantie begonnen met ik weet niet hoeveel lijsten te controleren met bijvoorbeeld motoren , dat ik het maar heb opgegeven , alles opnieuw noteren is sneller :)
maar zal zoals boven staande idd eens met alles gaan doen wat ik wil
kom er op terug ,,
 
Ook in een klein bedrijf maak je gebruik van processen. En die moeten dus het uitgangspunt zijn :). Daarbij maakt de inrichting veel uit voor de uiteindelijke bruikbaarheid en uitbreidbaarheid. Als je verkeerd begint, loop je later tegen (soms onoplosbare) problemen aan. Daarom moet je dus je processen goed beschreven hebben.
Daarna kun je aan de uitwerking gaan denken. En dan komen de noodzakelijke velden en keuzelijsten wel een keer aan bod. Zoals ik al zei: ik werk dus precies omgekeerd aan wat jij nu doet :D.
 
Hoi Anko,

hierbij vind je een gesimplificeerd database schema van een vergelijkbaar werkend systeem. Het zal zeker niet 100% zijn wat je nodig hebt, maar het geeft misschien een idee. Je zal bv. de veldtypes naar Access moeten aanpassen want dit systeem draait op een SQL-server, maar het principe blijft hetzelfde.

vriendelijke groeten
Noëlla
 

Bijlagen

  • ClassViewTechInterventions_Simplified.jpg
    ClassViewTechInterventions_Simplified.jpg
    110,4 KB · Weergaven: 189
Begin anders eens met een Excel document te plaatsen (met geanonimiseerde data uiteraard) van het systeem zoals je dat nu gebruikt, dan kunnen we een beter beeld schetsen van de situatie.
 
excuses voor de verlate reactie ,
Ik ben al een heel eind op weg ,,
Heb veel hier op het forum en op internet zitten lezen
had inderdaad eerst eea in excel opgezet , per tabel had ik een tabblad
daarna paar keer aangepast tot ik alles had wat makkelijk zou werken
daarna uitgestippeld hoe de structuur moest komen wat er gekoppeld moest worden enz
begonnen bij leveranciers en fabrikanten en zo tabel voor tabel gemaakt
enkele dingen zijn mooier en beter dan ik had verwacht
zo heb ik een tabel motoren , en reductors
en een tabel transportbanden waarbij de aandrijvingen weer gekoppeld zijn aan de motoren en reductoren zo zie je , mocht er iets stuk zijn,
direct wat je moet hebben zonder weer eerst te hoeven zoeken , dus ideaal :)
mooiste is dat acces als je een koppeling maakt er zelf ook nog eea aan toevoegt
bv storingen , machine 2 zie je exact alles wat met machine 2 te maken heeft ,
bedankt voor de hulp op weg :)
Anko
 
zo heb ik een tabel motoren , en reductors en een tabel transportbanden waarbij de aandrijvingen weer gekoppeld zijn aan de motoren en reductoren ...
Excuses hoeven uiteraard niet; wij zijn er toch wel :). Maar als ik je oplossing zo lees, vrees ik met grote vreze dat je de db heel slecht genormaliseerd hebt. Het zou niet nodig (zelfs heel onwenselijk) moeten zijn om per object een aparte tabel te maken. De meeste van die objecten hebben namelijk voor een groot deel dezelfde eigenschappen (merk, type, aanschafdatum, leverancier etc) en dat kun je toch veel beter in één tabel onderbrengen. Voor de objectspecifieke eigenschappen kun je dan altijd nog een tabel koppelen. Een goede database heeft zo weinig mogelijk tabellen :). Dat je jouw oplossing wel in Excel zou doen, snap ik wel, want Excel is maar een hele magere database in vergelijking met Access.
 
Hoi Anko, blij dat je eruit komt. Ik zie niet echt een probleem met je tabellenstructuur. Een goede relationele database is een evenwichtsoefening tussen theorie en praktijk. Je moet een basis hebben die wiskundig goed zit, bv. voldoende genormaliseerd is, maar ook voldoet aan de reële situatie. In onze database hebben we bv. 3 tabellen: klanten, leveranciers en transporteurs. Je zou kunnen zeggen dat zijn 3 dezelfde dingen: namen, adressen en contactgegevens. Wij hebben dat bewust in 3 verschillende tabellen gedaan omdat de UML analyse uitwees dat dit wel degelijk 3 verschillende entiteiten waren die op verschillende manier door verschillende gebruikers op verschillende plaatsen werden gebruikt. Dit vergt dus ook verschillende indexen. Door deze in drie tabellen te plaatsen vermijden we dat die ene tabel te groot en te log wordt en dat we teveel indexen op één tabel moeten leggen.
Eventueel kan je dan ook kiezen voor één tabel met 3 geïndexeerde views erop, maar ik denk niet dat dit in Access mogelijk is.
Dus hier moet je ook kijken naar het praktisch gebruik.

Succes verder
 
Eventueel kan je dan ook kiezen voor één tabel met 3 geïndexeerde views erop, maar ik denk niet dat dit in Access mogelijk is.
Dat heet in Access een query. Zou je eens naar moeten kijken :D.
Overigens ben ik het met je verhaal maar gedeeltelijk eens; Leveranciers en Klanten zijn verschillende entiteiten en doe je dus op basis daarvan in aparte tabellen. Je zet ze niet in dezelfde tabel omdat het toevallig dezelfde wezens zijn. Wat overigens best kan, als je een kleine db gebruikt. Dan is dat qua snelheid prima te behappen. Maar het entiteitsverschil zit hem er in dat je verschillende eigenschappen vastlegt, en dat verklaart dus waarom je verschillende tabellen gebruikt.

In een grote database gebruik je meestal een Postcode tabel voor de adressen. Die gebruik je dan voor alle entiteiten (klanten, leveranciers en transporteurs) waar je een adres nodig hebt. Je hebt uiteraard meerdere aanpakken voor een goede database, er is niet een ultieme wijsheid. Maar denk goed na over het doel van de db, en welke entiteiten je echt wilt vastleggen. En de Excel methode (ik heb 25 verschillende objecten, dus ik maak 25 verschillende tabellen) is op voorhand een hele slechte. Probeer die dus te vermijden, en bekijk je structuur goed voordat je op deze wijze verder gaat.
 
Excuses hoeven uiteraard niet; wij zijn er toch wel :). Maar als ik je oplossing zo lees, vrees ik met grote vreze dat je de db heel slecht genormaliseerd hebt. Het zou niet nodig (zelfs heel onwenselijk) moeten zijn om per object een aparte tabel te maken. De meeste van die objecten hebben namelijk voor een groot deel dezelfde eigenschappen (merk, type, aanschafdatum, leverancier etc) .

Misschien iets verkeerd neergezet
heb in totaal 7 Tabellen ,en 6 formulieren
ik heb 1 zogenaamde hulptabel , in deze staan diverse beschrijvingen , bv pompsoorten , motorsoorten , lagers enz enz
welke ik weer dus terug zien in de formulieren
De tabellen
1: Leveranciers en Fabrikanten
2: Motoren , pompen , Reductoren
3: Machines
4: transportbanden -aangezien er velen zijn en elk weer een apart soort aandrijving en bandtype heeft , bewust apart gezet
5 Storingen
6:Hulptabel - hierin staan afdelingen - lagers - oliekeringen - speciale onderdelen - enz
7: onderdelen
Formulieren zijn :
1: Leveranciers en Fabrikanten
2: Motoren , pompen , Reductoren
3: Machines
4: transportbanden
5 Storingen / onderhoud -
6: onderdelen - hierin lagers , keringen , speciale onderdelen voor machines enz

zou het in minder formulieren kunnen doen maar probleem is dus dat het dan on overzichtelijk is
ik had eerst in het hulptabel de onderdelen ondergebracht maar was onhandig ,
nu ze apart staan , zie je bij pompen motoren ook welke onderdelen speciaal voor die ene motor , pomp of reductor er voor revisie nodig zijn
idem voor de transportbanden , band defect je ziet het type en soort band welke erop zit , is de motor en of reductor stuk deze wordt dan weer uit het tabel motoren , reductoren geplukt
en zie je dus welke band , welke motor en gegevens heeft ,
nu zie je in 1 opslag dus in feite alles , dus bv bij machines haal je ook weer een hoop uit de hulptabel
in storingen en onderhoud zijn vele selecties verwerkt , je selecteert de afdeling , machine dus weinig te typen dan alleen de storing , en oplossing dus snel en makkelijk en kost erg weinig tijd

wat ik met excel bedoelde was dus ik had eerst eea opgezet in tabbladen van excel , tot ik precies had wad ik nodig had om het duidelijk te krijgen
wellicht zal er in de toekomst nog wel wat veranderd worden , en nu in de praktijk kom je soms nog wel wat tegen dat je denkt owja dat kan weg maar dit moet ervoor in de plaats komen
 
@NoelaG
idd , helemaal mee eens ,
dit is enkel voor de technische dienst dus klanten hebben wij niet , wel dus leveranciers en fabrikanten deze heb ik wel in 1 tabel ondergebracht
wel heb ik in mijn hulptabel een kolom met bv diverse omschrijvingen en deze als selectie terug gezet bij fabrikanten en leveranciers
zo zie je ook duidelijk wie wat is , voor mij wel duidelijk wie een fabrikant en gewoon leverancier is , maar ook ik heb wel eens een dagje vrij :)
het is dus overzichtelijk van wie , wat levert , is ook handig met enkele grondstoffen , voor de zuivering , welke ook onder de hoede van de technische dienst valt
zoals onze database nu opgezet is , is het voor iedereen duidelijk , een uitgebreide storing tik je in nog geen minuut erin , mede dankzij diverse selecties
toen was het iedere keer maar alles typen en typen in excel bestanden , nu typ je alleen de storing en oplossing in ,
gebruikte onderdelen kan je selecteren , en ok wellicht is er nog wel een onderdeel vergeten , maar is zo toegevoegd
dus op het einde van de rit is het een compleet plaatje
 
Als je eens wilt dat iemand naar de db kijkt, mag je hem altijd opsturen.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan