FCO-IM uniciteitsconstraint

[Verwijderd]

Ik ben bezig een database te modeleren met behulp van het programma FCO-IM Casetool.
Er is een object OrderregelLeveranciersorder. Dit object is onderverdeeld in 2 labels: 1. leveranciersordernr en 2. leveranciersorderorderregel. Nu verwijst er een rol naar het object OrderregelLeveranciersorder. Het leveranciersordernr moet uniekzijn, maar het regel nr niet. Dus slechts 1 van beide labels is uniek. Maakt dat dat de rol ook uniek moet zijn of niet? Met andere woorden, moet er over die rol een uniciteitsconstraint?

Is het overigens erg als ik een paar constraints achterwegen laat (zolang ik maar een database van het model kan laten bouwen zonder errormeldingen)?

[MSalters]

Kan een rol naar meerdere regels verwijzen? Zo nee, als rol A verwijst naar regel 1, welke rol verwijst dan naar regel 2?

Ik ben zelf geen voorstander van enig DB design waarbij constraints de correctheid beinvloeden; het zijn in mijn optiek hulpmiddelen om fouten te voorkomen en te vinden.

[JaQ]

Verwijderd schreef op donderdag 30 december 2004 @ 02:31:
Ik ben bezig een database te modeleren met behulp van het programma FCO-IM Casetool.
Er is een object OrderregelLeveranciersorder. Dit object is onderverdeeld in 2 labels: 1. leveranciersordernr en 2. leveranciersorderorderregel. Nu verwijst er een rol naar het object OrderregelLeveranciersorder. Het leveranciersordernr moet uniekzijn, maar het regel nr niet. Dus slechts 1 van beide labels is uniek. Maakt dat dat de rol ook uniek moet zijn of niet? Met andere woorden, moet er over die rol een uniciteitsconstraint?

Nee die moet hier niet. De reden is dat je leveranciersordernummer niet in dit object wordt bepaald, maar in het object leveranciersorders.

Verwijderd schreef op donderdag 30 december 2004 @ 02:31:
Is het overigens erg als ik een paar constraints achterwegen laat (zolang ik maar een database van het model kan laten bouwen zonder errormeldingen)?

Als je constraints achterwege laat, dan kan je geen .igg genereren. Ben ff de naam kwijt van hoe dat ook al weer heet in FCO-IM, het is 5 jaar geleden dat ik dat pakket gebruikte op school. Bovendien gebruikt niemand in de markt NIAM (veels te lastig te modelleren, de industrie standaard is ERD)

MSalters schreef op donderdag 30 december 2004 @ 02:36:

Ik ben zelf geen voorstander van enig DB design waarbij constraints de correctheid beinvloeden; het zijn in mijn optiek hulpmiddelen om fouten te voorkomen en te vinden.

En wat denk je dan dat een primary key is? (ow ja, een constraint ), of een unique key (nog een constraint) tenminste... in FCO-IM noem je dat zo. De naam constraint kan je wat anders doen vermoeden, maar helaas pindakaas in dit geval.

Overigens ben ik wel voorstanders van constraints. Bijvoorbeeld een ARC constructie zoals dit in Oracle bestaat. Een voorbeeld is een koppeltabel waarin je een foreign key legt naar 4 andere tabellen en 1 van deze 4 kolommen mag maar gevuld zijn. Je zou dus ook 4 verschillende tussentabellen kunnen opnemen, maar waarom zou je?

[Verwijderd]

Ontzettend bedankt voor de uitleg alvast. Maar ik snap zelf nog niet zo goed wat nu een uniciteitsbeperking inhoud. Wat ik heb begrepen is dat dit soort beperking nodig is om te zorgen dat je bijvoorbeeld geen 2 leveranciers met het zelfde administratienummer hebt.

Ik heb 4 IGD's met probleemgevallen waar ik niet uit kom. Ik zal ze hieronder een voor een neerzetten. Hopelijk wil er iemand even naar kijken.

Als iemand foute of ontbrekende dingen ziet in de diagrammen die ik niet vermeld, dan zou ik je heel dankbaar zijn als je dat even laten horen
De eerste is die van de klant. http://home.wanadoo.nl/kinable/klant.JPG
1. Kan iemand mij uitleggen waarom er een uniciteitsbeperking op bijvoorbeeld het object VoorletterKlant (object 4) moet?
2. Hoe moeten de beperkingen staan bij AdresKlant (nr 10, 11)? Moet ik hier over 10 en beperking zetten EN over 11 een andere beperking, of moet ik over 10 en 11 één grote beperking zetten (dus 1 lange pijl die over zowel 10 als 11 gaat)?

De tweede is de igd van het artikel:http://home.wanadoo.nl/kinable/artikel.JPG
Ieder product uit de tegelhandel (jah het is een tegelbedrijf) is opgebouwd uit een speciale code. Tegellijm heeft zo bijvoorbeeld code 10-1500. De 10 is een uniek getal en staat voor de leverancier (leverancier 10 is in mijn geval het bedrijf Spaansen). De volgende 4 cijfers zijn de artikelcodes die de leveranciers hanteren. Het kan zijn dat verschillende leveranciers de zelfde artikelcodes hanteren voor verschillende producten. Deze laatste 4 cijfers zijn dus niet allemaal uniek (vandaar dat de leverancierscode er voor staat om het gehele 6 cijferige getal toch uniek te maken).
3. Ik vermoed dat er over de volgende nr een beperking moet komen maar weet het niet zeker: 125, 128, 129, (64+65), 80, 77, 74, 71, 68. Bij bijvoorbeeld 125 moet de gehele artikelcode uniek zijn. Maar de artikelcode zelf is opgebouwd uit een uniek gedeelte (leverancieradminnr) en uit een niet-uniek gedeelte (artikelnr). Ik heb nummers 64 en 65 tussen haakjes gezet. Dat betekent dat er 1 beperking over beide telijk moet komen en niet 2 losse!

De derde is de igd van het klantorder.http://home.wanadoo.nl/kinable/klantorder.JPG
Hier is een klein voorbeeld van een order:
1. tegellijm 12 eenheden
2. siersteen 50 eenheden.
OrderregelKlantorder is zo opgebouwd: De naam geeft aan dat het om een order voor de klanten gaat en niet voor een leverancier. Zo is er bijvoorbeeld een orderregel 612-1. Dat wil zeggen dat het om het unieke ordernummer 612 gaat, en dat je moet gaan kijken naar de 1e regel (hier staat er op de 1e regel dus tegellijm). De 4 cijferige orderregel is dus in zijn geheel uniek maar is ook weer opgebouwd uit een uniek en een niet-uniek gedeelte.
4. Ik vermoed dat er over de volgende nr een beperking moet komen: 98, 84, 87, 89,90, 91, 83, 93, 119, 95,(64+65)

Tot slot de laatste igd: Leveranciersorder:http://home.wanadoo.nl/kinable/leveranciersorder.JPG
Ook hier wordt net zoals bij klantorders gebruik gemaakt van een order nummer en een regelnr: bijvoorbeeld L1-10 (order nummer L1 is voor leverancier 10).
5. Vermoeden: 102, 101, 105, 33, 107, 108, 111, (64 + 65), (109 +110), 113, 116

De vragen zijn genummerd dus zouden jullie ook voor de duidelijkheid een nummer voor het antwoord willen zetten?
Het spijt mij dat ik het zo enorm uitgebreid vraag, maar als ik dit fout doe heb ik later een groot probleem. Ik ben al vrij ver gekomen en zou het bijzonder jammer vinden als ik door zoiets stoms zou stranden. Iedereen alvast enorm bedankt.

[JaQ]

Verwijderd schreef op donderdag 30 december 2004 @ 14:23:
Ontzettend bedankt voor de uitleg alvast. Maar ik snap zelf nog niet zo goed wat nu een uniciteitsbeperking inhoud. Wat ik heb begrepen is dat dit soort beperking nodig is om te zorgen dat je bijvoorbeeld geen 2 leveranciers met het zelfde administratienummer hebt.

Ik heb 4 IGD's met probleemgevallen waar ik niet uit kom. Ik zal ze hieronder een voor een neerzetten. Hopelijk wil er iemand even naar kijken.

Als iemand foute of ontbrekende dingen ziet in de diagrammen die ik niet vermeld, dan zou ik je heel dankbaar zijn als je dat even laten horen
De eerste is die van de klant. http://home.wanadoo.nl/kinable/klant.JPG
1. Kan iemand mij uitleggen waarom er een uniciteitsbeperking op bijvoorbeeld het object VoorletterKlant (object 4) moet?

Okay, dat heb je niet goed gemodelleerd. Voorletterklant is namelijk geen object, maar een attribuut van klant. Dat heb je dus bij alle attributen van klant verkeerd gedaan.

Een correcte niam zin zou zijn:
Klant met klantnummer 1 heeft als achternaam blaat

Klant met klantnummer 1 is een object
1 is een attribuut van dit object (het klantnummer)
blaat is ook een attribuut. (GEEN OBJECT!)

Op die eerste jpg (http://home.wanadoo.nl/kinable/klant.JPG dus) heb je al 8 objecten te veel staan. (postcode moet je uitsplitsen, net als adres en is dus wel een object)

Verwijderd schreef op donderdag 30 december 2004 @ 14:23:
2. Hoe moeten de beperkingen staan bij AdresKlant (nr 10, 11)? Moet ik hier over 10 en beperking zetten EN over 11 een andere beperking, of moet ik over 10 en 11 één grote beperking zetten (dus 1 lange pijl die over zowel 10 als 11 gaat)?

dit is 1 grote beperking (over beide rollen)

zo stop ik er eerst maar even mee, want ik merk dat je de basis van NIAM gewoon nog niet goed genoeg in je hebt zitten om deze opdracht (voor school of niet, dat maakt niet uit) succesvol af te ronden. Je maakt in ieder geval wel consequent dezelfde fout, dat spreekt dan weer wel voor je.

Stuur eens een mailtje naar Saxion Hogeschool IJsselland. Die hebben namelijk prima syllabi die dit tot in de treure behandelen (trust me, I know... alleen heette het toen nog Rijkshogeschool IJsselland). Of haal een boek (zoekterm NIAM) Verder is er een boek over FCO-IM van academic service (ISBN 9026723164 )

[Verwijderd]

Heel erg bedankt voor je antwoord. Dit is inderdaad een schoolopdracht. Mijn probleem is echter dat ik dit soort opdrachten graag erg goed wil doen, vandaar dat ik mijn probleem hier op het forum heb gezet (en nee ik gebruik het niet om mijn huiswerk voor te laten kouwen ). Ik sta er werkelijk van te kijken dat mijn diagrammen (zeker de eerste), niet goed is. Ik heb mij exact aan de uitleg van mijn schoolboek gehouden, waar bijna een identiek schema in staat als dat van mijn klant. Ik heb een maitlje gestuurd naar de hogeschool die u mij aanraadt. Ik hoop dat snel informatie van te ontvangen. Ik ga zelf ook nog op zoek naar informatie, want zo te horen is dit schoolboek nog slechter dan al bekend was. Het woord atribuut komt er niet eens in voor. Zou het mogelijk zijn dat jij mij wat op weg helpt, want gezien het feit dat ik een deadline heb, is er niet veel tijd om informatie aan te vragen en volledig te leren. Zou jij bijvoorbeeld een beperkt voorbeelddiagram kunnen maken met wat uitleg zoals hij zou moeten zijn? Ik ben bereid alles opnieuw te maken dus ik hoop dat u mij ook wilt helpen.
In ieder geval bedankt voor jou moeite.

[ Voor 19% gewijzigd door Verwijderd op 01-01-2005 15:31 ]

[Verwijderd]

Ik heb een groot gratis pdf boek gevonden dus daar ga ik mij de komende nachten mee bezig houden. Zodra mijn eerste nieuwe tabel af is zal ik hem hier laten zien.

[Verwijderd]

Ik heb jou uitleg eens vergeleken met de uitleg uit het boek dat ik heb gevonden:

Een correcte niam zin zou zijn:
Klant met klantnummer 1 heeft als achternaam blaat

Klant met klantnummer 1 is een object
1 is een attribuut van dit object (het klantnummer)
blaat is ook een attribuut. (GEEN OBJECT!)

Student:
"There is a student Jan blaat." F1: "there is a student <first name><surname>."
Jan = first name, blaat = surname

Mentorship:
"The mentor of student Jan blaat is BLC." F2:"the mentor of <student:01> is <Teacher:02>.
Jan = first name, blaat = surname O1:"student <first name><surname> O2:<teachercode>

Door dit toe te passen op mijn klant database zou je dus het volgende moeten krijgen:

Klant:
"Er is een klant 1" F1: "Er is een klant <klantnr>
1 = klantnr

NaamKlant
"Klant 1 heeft als naam Guust Flater" F2:<Klant: O1> heeft als <naam:O2>
Guust= voornaam Flater=achternaam O1:"Klant<klantnr>O2:"naam<voornaam><achternaam>"

Nu heb ik mij dus exact aan het voorbeeld uit het boek gehouden waarvan ik zeker weet dat het klopt. Het enige verschil met mijn schema is dat ik nu de labels voornaam en achternaam in 1 object: naam stop.
1. Was dit jou bedoeling? Mijn nieuwe beperkte igd is: http://home.wanadoo.nl/kinable/klantnieuw.JPG
2. Welke labels moet ik nog meer samenvoegen in 1 object? Graag ook de feitexpressies geven.
3. Waarom mag ik er niet allemaal losse objecten van maken zoals ik in mijn schema heb gedaan?
4. Staan de constraints goed? Persoonlijk vind ik het erop lijken dat er nu niet meer mensen met de zelfde voor en achternaam mogen zijn terwijl dit in de praktijk wel mag. Hoe zit dat nu in mijn schema, mogen daar wel meer mensen met de zelfde voor en achternaam zijn (als dit niet het geval is, hoe geef ik dan aan dat dat wel mag)?
5. Als het nu nog niet goed is zou ik graag een kloppen igd zien zoals jij zeker weet dat hij goed is want dan zijn mijn ideeën op. (Als laatste optie bedenk ik net, is het mogelijk dat jij bedoelt dat er 1 object: klant is, met als labels: naam, voornaam, adres, huisnummer, plaatsnaam enz.., maar dat lijkt me bijzonder onwaarschijnlijk dat je dat bedoelt omdat dat simpelweg onuitvoerbaar is).
Graag per nummer antwoord geven voor het overzicht.

[ Voor 12% gewijzigd door Verwijderd op 02-01-2005 02:51 ]

[hemaworst]

hmmm,

volgens mij moet je echt even dat boek goed doorlezen:
Welke tool gebruik je?
Casetalk.com heeft een gratis erg goede casetool: http://www.casetalk.com/php/index.php?CaseTalk
of direct:
http://www.casetalk.com/php/index.php?CaseTalk%20Download

Een gratis boek over FCO-IM:
http://www.casetalk.com/p...p?FCO-IM%20English%20Book.
Lees vooral het stuk over classificeren!!! Je classificeerd dingen steeds verkeerd.
Ook houd je je niet aan de regels van fco-im.

jouw zin

NaamKlant
"Klant 1 heeft als naam Guust Flater" F2:<Klant: O1> heeft als <naam:O2>

geeft aan dat je het niet helemaal begrijpt.
Deze zin geeft namelijk meer dan 1 feit weer(en dat mag niet in FCO-Im!).
Feit 1: Klant 1 (geidentificeerd door klantnummer 1) heeft voornaam Guust
Feit 2: Klant 1 (geidentificeerd door klantnummer 1) heeft achternaam Flater

Jouw zin is dus niet elementair. Zoek dat maarop in je boek

Nu zeg je: Maar in het boek doen ze dat ook!!!
NEE! Zij doen iets heel anders.
Bij jou word een klant geidenticificeerd door een klannummer.
Bij het boek door voornaam EN achternaam

Ik zou zeggen, lees het hoofdstuk over classificeren even, dat kost je maar een uurtje of zo.
Pas als je adat hoofdstuk snapt dan heeft het zin om verder te gaan

Om je toch op weg te helpen:


Ik heb effe een Totaliteit constraint op rol 1 toegevoegd op achternaam aangezien ik aanneem dat deze verplicht is.

als je afvraagt: waarom is achternaam geen object?
antwoord: achternaam Bush identificeerd niks. Als ik zeg "geef mij 'achternaam Bush'", dan weet je niet wat ik bedoel. Zeg ik "Geef me klant 1" dan weet je wel wat ik bedoel.
De algemene regel voor objecten: Als een stuk van de zin iets identificeerd(dus uniek!) dan is het een object.


mmm,
zie net dat ik een foutje gemaakt heb bij telefoonnummer.
Ik neem aan dat een telefoonnummer maar bij 1 klant hoort, dus dat een telefoonnummer uniek is. In dat geval moet er een UC op rol 7.
Let op! Dit ligt aan het systeem. Ik kan systemen verzinnen waarbij een telefoonnummer niet uniek is en waarbij dit dan niet het geval is


Goed, hier de conclusies die uit het diagram te trekken zijn

code:

Klant:
(No expressions available)

klantachternaam:
"Klant 1 heeft  achternaam Bush."

klanttelefoonnummer:
"Klant 1 heeft telefoonnummer 0123456789."

klantvoornaam:
"Klant 1 heeft voornaam George."




-----------------------------------------------------------------------
Business Rules
-----------------------------------------------------------------------

Klant:
"Klant is uniquely identified by klantnummer."
"Klant must have a klantachternaam."

klantachternaam:
"klantachternaam is uniquely identified by Klant."

klanttelefoonnummer:
"klanttelefoonnummer is unique on Klant."


klantvoornaam:
"klantvoornaam is uniquely identified by Klant."

[ Voor 70% gewijzigd door hemaworst op 02-01-2005 20:11 ]

[hemaworst]

Wat ik me trouwens afvraag:
Als dit voor school is dan krijg je toch wel een boek of iets dergelijks?

Nog een opmerking:
In al je diagrammen zitten heel veel fouten!
Je geeft aan dat je al ver bent gekomen, maar ik zet er grote vraagtekens erbij.

Post anders ff je zinnen die je hebt ingetypt. Dat is de basis van een goed fco-im model.
Als je de zinnen goed hebt(=elementair) dan is de rest niet zo veel.

Het omzetten naar een database heet GLR routine:
Grouperen, Lexicaliseren en Reduceren.
as je geen contraints zet dan krijg je geen goede database!
Ik weet zeker dat je model wat je nu hebt niet door de check komt?

Momenteel doe ik een Master opleiding Information Modelling
and Relational Database Design.
Hier krijg ik deze methode elke dag

Post ander ff de opdracht hier, mocht ik morgen tijd hebben dan kijk ik er ff naar.

Bovendien gebruikt niemand in de markt NIAM

TJa, helaas is dat nog zo. toch is het een elegante methode, die als je er wat geoefend in bent net zo snel is as ERD. Plus punt is dat meteen je documentatie voor enduser en voor database mensen gegenereerd wordt. Tevens kan het model met 1 druk op de knop naar ERD worden opgezet.

Nog even een bericht om aan te tonen dat NIAM niet dood is:
Microsoft heeft deze methode in Visio DB Architect ingebouwd! Bij hun heet het geen NIAM maar ORM :http://msdn.microsoft.com/theshow/episode025/default.asp

ja, oke, zelf een grote fan van orm/niam

[ Voor 27% gewijzigd door hemaworst op 02-01-2005 20:32 ]

[Verwijderd]

Hier zijn mijn feitexpressies. Hopelijk kun je er iets mee. Ik heb een heel aardige informatica leraar die dit vak eerder geeft als een hobby, maar hier krijgen wij eigenlijk geen les in en het boek behandeld even het hele gebeuren in een pagina of 15. Daarbij komt nog dat alles verschrikkelijk slecht wordt verwerkt. Als ik het boek moest geloven had ik een goede database gemaakt. Ik ben erg blij dat ik hem hier heb gepost. Wij moeten overigens het programma FCO-IM Casetool gebruiken.

Ik heb even een antwoord op een opgave uit mijn schoolboek gescant. Zou je eens kunnen kijken of dat model daar foutloos is: http://home.wanadoo.nl/kinable/antwoordboek.JPG
Ik begrijp ook nog niet helemaal wanneer ik nu een object moet maken, en wanneer het alleen maar een label moet zijn? Mijn werkwijze:
1. stel feitexpressie op.
2. geef feitexpressie een naam
3. kijk welke objecten er in de feitexpressie zitten (ik weet kennelijk niet wanneer ik nu iets een object moet noemen en wanneer een label dus als iemand dat in duidelijk nederlands zou kunnen uitleggen...)
4. geef de labels die bij de objecten horen.
edit: gezien de beperkte hoeveelheid tijd die ik nog voor deze opdracht heb, heb ik, ondanks dat ik het hele systeem nog niet snap, toch maar gelijk het eerste igd volgens jou voorbeeld proberen te maken. Bij Adres Klant wist ik echter niet of ik dit nog moest opsplitsen in: Klant 612 heeft als huinummer 12. Klant 612 heeft als straatnaam blaatstraat. http://home.wanadoo.nl/kinable/klant2.JPG. Hopelijk klopt het nu al beter dat de vorige.

code:

Feitexpressie                                         Feitexpressietype
Objecttypes
Labeltypes

Er is een klant 612.                    Klant
Objecttypes: Zit in benoeming feitexpressie.
Labeltypes: klantadminnr

Klant 612 heeft als voorletter K.               Voorletters klant
Objecttypes: Klant, VoorletterKlant
Labeltypes:  klantadminnr,klantvoorletter

Klant 612 heeft als achternaam Modvinker.           Achternaam klant
Objecttypes: Klant, AchternaamKlant
Labeltypes: klantadminnr, klantachternaam

Klant 612 woont in Schildersgracht 102.         Adres klant
Objecttypes: Klant, AdresKlant
Labeltypes: klantadminnr, klantstraatnaam, klanthuisnummer

Klant 612 heeft als woonplaats Breezand.            Woonplaats klant
Objecttypes: Klant, WoonplaatsKlant
Labeltypes: klantadminnr, klantwoonplaats

Klant 612 heeft als postcode 1783 KP.           Postcode klant
Objecttypes: Klant, PostcodeKlant
Labeltypes: klantadminnr, klantpostcode

Klant 612 heeft als telefoonnummer 0225785785.      Telnummer klant
Objecttypes: Klant, TelefoonKlant
Labeltypes:  klantadminnr, klanttelefoon

Klant 612 heeft als rekeningnummer xxx.         Rekening klant
Objecttypes: Klant, RekeningnrKlant
Labeltypes: klantadminnr, klantrekeningnr

#optioneel
#Klant 612 heeft als faxnummer xxx.         Fax klant
Objecttypes: Klant, FaxKlant
Labeltypes: klantadminnr, klantfax

#Klant 612 heeft als e-mailadres [e-mail].           Mail klant
Objecttypes: Klant, MailKlant
Labeltypes: klantadminnr, klantmail

#Klant 612 heeft als mobiel nummer 06-12345678.         Mobiel klant
Objecttypes: Klant, MobielKlant
Labeltypes: klantadminnr, klantmobiel



Leverancier database
Er is een leverancier 10.                   Leverancier
Objecttypes: Zit in benoeming feitexpressie.
Labeltypes: leverancieradminnr

Leverancier 10 heeft als voorletter K.          Voorletters leverancier
Objecttypes: Leverancier, VoorletterLeverancier
Labeltypes: leverancieradminnr, leveranciervoorletter

Leverancier 10 heeft achternaam Groot, de.          Achternaam leverancier
Objecttypes: Leverancier, AchternaamLeverancier
Labeltypes: leverancieradminnr, leverancierachternaam

Leverancier 10 heeft als vestigingsadres Simpelkade 310.    Vestigingsadres leverancier
Objecttypes: Leverancier, AdresLeverancier
Labeltypes: leverancieradminnr, leverancierstraatnaam, leveranciervestigingsnummer

Leverancier 10 heeft als vestigingsplaats AnneJozef.        Vestigingsplaats leverancier
Objecttypes: Leverancier,VestigingsplaatsLeverancier
Labeltypes: leverancieradminnr, leveranciervestigingsplaats

Leverancier 10 heeft als postcode 2073 PK.          Postcode leverancier
Objecttypes: Leverancier, PostcodeLeverancier
Labeltypes: leverancieradminnr, leverancierpostcode

Leverancier 10 heeft als telefoonnummer 0367465856. Telnummer leverancier
Objecttypes: Leverancier, TelefoonLeverancier
Labeltypes: leverancieradminnr,leveranciertelefoon

Leverancier 10 heeft als faxnummer 0367465666.      Fax leverancier
Objecttypes: Leverancier, FaxLeverancier
Labeltypes: leverancieradminnr, leverancierfax

#Leverancier 10 heeft als e-mailadres [e-mail]. Mail leverancier
Objecttypes: Leverancier, MailLeverancier
Labeltypes: leverancieradminnr, leveranciermail

#Leverancier 10 heeft als mobiel nummer 06-87654321.        Mobielnummer leverancier
Objecttypes: Leverancier, MobielLeverancier
Labeltypes: leverancieradminnr, leveranciermobiel

Leverancier 10 heeft als rekeningnummer 11.22.33.123.           Rekening leverancier
Objecttypes: Leverancier, RekeningnrLeverancier
Labeltypes: leverancieradminnr, leverancierrekeningnr


Artikel database
Er is een leverancier 10.                   Leverancier
Objecttypes: Zit in benoeming feitexpressie.
Labeltypes: leverancieradminnr

Leverancier 10 heeft artikelnummer 10-1500  .       Artikel Product code
Objecttypes: Leverancier, Artikelcode
Labeltypes: leverancieradminnr, leverancieradminnr, artikelnr

Artikel 10-1500 is het product tegellijm.               Artikelcode per product
Objecttypes: Artikelcode, Productnaam
Labeltypes: leverancieradminnr, artikelnr, artikelnaam

Artikel 10-1500 heeft als verkoopprijs 5,50.            Verkoopprijs van het artikel
Objecttypes: Artikelcode, VerkoopprijsArtikel
Labeltypes: leverancieradminnr, artikelnr, artikelverkoopprijs

Artikel 10-1500 heeft als inkoopprijs 2,00.         Inkoopprijs van het artikel
Objecttypes: Artikelcode, InkoopprijsArtikel
Labeltypes: leverancieradminnr, artikelnr, artikelinkoopprijs

#artikel 10-1500 is op voorraad Y.              Artikel op voorraad
Objecttypes: Artikelcode, StatusVoorraad
Labeltypes: leverancieradminnr, artikelnr, voorraadstatus

#Artikel 10-1500 heeft een besteltijd van 7 dagen.      Besteltijd artikel
Objecttypes: Artikelcode, BesteltijdArtikel
Labeltypes: leverancieradminnr,  artikelnr, artikelbesteltijd

#Magazijnvoorraad van artikel 10-1500 is 100 eenheden.  Magazijnvoorraad
Objecttypes: Artikelcode, MagazijnvoorraadArtikel
Labeltypes: leverancieradminnr, artikelnr, artikelvoorraad


Order database klant
Er is een order 1104.                   Klantorder
Objecttypes: Zit in benoeming feitexpressie.
Labeltypes: klantordernr

Order 1104 heeft als datum 6 januari 2001.          Orderdatum
Objecttypes: Klantorder, DatumKlantorder
Labeltypes: klantordernr, klantorderdatum

Order 612 is van klant 612.             Order klantnummer
Objecttypes: Klantorder, Klant
Labeltypes: klantordernr, klantadminnr

Order 612 bevat orderregel 612-1.               Orderregel op order
Objecttypes: Klantorder, OrderregelKlantorder
Labeltypes: klantordernr, klantordernr, klantorderorderregel

Orderregel 612-1 bevat artikelnummer 10-1500.       Artikel per orderregel
Objecttypes: OrderregelKlantorder, Artikelcode
Labeltypes: klantordernr, klantorderorderregel, leverancieradminnr, artikelnr

Orderregel 612-1 bevat artikel tegellijm #dit schrappen. Is geen elementair feit maar een afgeleid gegeven.

Orderregel 612-1 bevat 12 eenheden.         Order hoeveelheid
Objecttypes: OrderregelKlantorder, EenhedenKlantorder
Labeltypes: klantordernr, klantorderorderregel, klantordereenheden

Orderregel 612-1 bevat verkoopprijs 10 #Dit staat bij de artikeldatabase dus hoeft niet worden opgenomen.
Orderregel 612-1 bevat klanttotaalprijs 120 #dit schrappen. Is geen elementair feit maar een afgeleid gegeven.

Order 612 heeft status afgehandeld.             Orderstatus
Objecttypes: Klantorder, StatusKlantorder
Labeltypes: klantordernr,  klantorderstatus

De bestelling van orderregel 612-1 is ontvangen Y.      Status levering artikelen
Objecttypes: OrderregelKlantorder, OntvangstKlantorderartikel
Labeltypes: klanordernr, klantorderorderregel, klantorderartikelontvangst

Order database leverancier
Er is een order L1.                 Leveranciersorder
Objecttypes: Zit in benoeming feitexpressie.
Labeltypes: leveranciersordernr

Order L1 heeft als datum 6 januari 2001.            Leveranciersorder datum
Objecttypes: Leveranciersorder, DatumLeveranciersorder
Labeltypes: leveranciersordernr, leveranciersorderdatum

Order L1 is voor leverancier 10.                Order per leverancier
Objecttypes: Leveranciersorder, Leverancier
Labeltypes: leveranciersordernr, leverancieradminnr

Order L1 bevat orderregel L1-1.             Orderregel op leveranciersorder
Objecttypes: Leveranciersorder, OrderregelLeveranciersorder
Labeltypes: leveranciersordernr, leveranciersordernr, leveranciersorderorderregel

Orderregel L1-1 bevat artikelnummer 10-1500.        Inkoopartikel per orderregel
Objecttypes: OrderregelLeveranciersorder, Artikelcode
Labeltypes:leveranciersordernr, leveranciersorderorderregel, leverancieradminnr, artikelnr

Orderregel L1-1 bevat artikel tegellijm #dit schrappen. Is geen elementair feit maar een afgeleid gegeven.

Orderregel L1-1 bevat 12 eenheden   .           Inkoopartikel order hoeveelheid
Objecttypes: OrderregelLeveranciersorder, EenhedenLeveranciersorder
Labeltypes: leveranciersorderorderregel, leveranciersordereenheden

Orderregel L1-1 bevat inkoopprijs 5 #Dit staat bij de artikeldatabase dus hoeft niet worden opgenomen.
Orderregel L1-1 bevat leveranciertotaalprijs 60  #dit schrappen. Is geen elementair feit maar een afgeleid gegeven.

Orderregel L1-1 heeft afleverdatum 15-06-2005.      Leveranciers orderaflever datum
Objecttypes: OrderregelLeveranciersorder, AfleverdatumLeveranciersorder
Labeltypes: leveranciersorderorderregel, leveranciersorderafleverdatum

[ Voor 9% gewijzigd door Verwijderd op 02-01-2005 22:56 ]

[Verwijderd]

Was vorige keer ingelogd met Hemaworst

je tweede diagram lijkt al een stuk beter.
Alleen adres klopt niet. Je hebt nu staan dat straatnaam + huisnummer uniek zijn.
In Nederland hebben we 100en "kerkstraat 1"
Voor jou opdracht zou ik die UC dus gewoon weglaten.

<Moeilijke modus lekker gewoon overslaan als je dit niet snapt>
Adressen zijn trouwens best ingewikkeld om goed te modeleren, een adres is namelijk een object!
Als ik zeg "kerkstraat 12 amsterdam" dan weet je waar ik het over heb, dus een object!
Het wordt nog ingewikkelder! Als ik zeg "5543 AG 12" dan weet je ook waar ik het over heb!
Een adres kan je op 2 manieren identificeren. Eleganter zou dus zijn om generalisatie toe te passen(in dit geval 2 verschillende identifiers).
</Moeilijke modus>

Nu ik het antwoordenboek zie snap ik ook waarom je sommige dingen doet.
Is dit boek een officieel boek? Er worden namelijk dingen in gedaan die nog nooit bij ons in de les zo zijn opgelost(heb les van Guido Bakema en Jan Pieter Zwart, mede bedenkers van FCO-IM)

1: Wat doet object VoornaamLL? Ik zou die gewoon schrappen
2: Zelfde voor achternaamLL
3: Object ReisOmschrijving: Ik zou dat object ook gewoon weglaten
4: Geen Uc's Tc's etc
Voor de rest ziet het er wel okee uit.

[ Voor 217% gewijzigd door Verwijderd op 03-01-2005 11:37 ]

[Verwijderd]

mag van dokter maar 1 uur per dag computeren
heb toch niks beters te doen
dit heb ik er van gemaakt in een kwartiertje


Heb alleen de basis gedaan, De rest mag je lekker zelf doen
Ben benieuwd wanneer ik het krat bier binnen krijg

En natuurlijk de zinnen:

code:

-----------------------------------------------------------------------
Expressions / Expression types generated by CaseTalk
-----------------------------------------------------------------------

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

Expression types for analists: (No object type expressions substituted)
-----------------------------------------------------------------------

Artikel:
O4     'artikel <leverancieradminnr>-<artikelnr>'

Artikel is:
F6     "<Artikel:O4> is het <Produkt:O5>."

artikel verkoopprijs:
F8     "<Artikel:O4> heeft als verkoopprijs <SomGeld:O6>."

Klant:
F1     "Er is een klant <klantadminnr>."
O1     'klant <klantadminnr>'

klant achternaam:
F3     "<Klant:O1> heeft als achternaam <achternaam>."

klant woonplaats:
F2     "<Klant:O1> heeft als woonplaats <Plaats:O2>."

Leverancier:
O3     'leverancier <leverancieradminnr>'

Leverancier achternaam:
F4     "<Leverancier:O3> heeft achternaam <achternaam>."

leverancier verstigingplaats:
F5     "<Leverancier:O3> heeft als vestigingsplaats <Plaats:O2>."

Plaats:
O2     '<plaatsnaam>'

Produkt:
F7     "Er is een product <produktomschrijving>."
O5     'product <produktomschrijving>'

SomGeld:
O6     '<bedrag>'



Expression types for analists: (Object type expressions substituted)
-----------------------------------------------------------------------

Artikel:
O4     'artikel <leverancieradminnr>-<artikelnr>'

Artikel is:
F6     "Artikel <leverancieradminnr>-<artikelnr> is het product <produktomschrijving>."

artikel verkoopprijs:
F8     "Artikel <leverancieradminnr>-<artikelnr> heeft als verkoopprijs <bedrag>."

Klant:
F1     "Er is een klant <klantadminnr>."
O1     'klant <klantadminnr>'

klant achternaam:
F3     "Klant <klantadminnr> heeft als achternaam <achternaam>."

klant woonplaats:
F2     "Klant <klantadminnr> heeft als woonplaats <plaatsnaam>."

Leverancier:
O3     'leverancier <leverancieradminnr>'

Leverancier achternaam:
F4     "Leverancier <leverancieradminnr> heeft achternaam <achternaam>."

leverancier verstigingplaats:
F5     "Leverancier <leverancieradminnr> heeft als vestigingsplaats <plaatsnaam>."

Plaats:
O2     '<plaatsnaam>'

Produkt:
F7     "Er is een product <produktomschrijving>."
O5     'product <produktomschrijving>'

SomGeld:
O6     '<bedrag>'

Expressions for analists: (Labels substituted)
-----------------------------------------------------------------------

Artikel is:
F6     "Artikel 10-1500 is het product tegellijm."

artikel verkoopprijs:
F8     "Artikel 10-1500 heeft als verkoopprijs 5,50."

Klant:
F1     "Er is een klant 612."

klant achternaam:
F3     "Klant 612 heeft als achternaam Modvinker."

klant woonplaats:
F2     "Klant 612 heeft als woonplaats Breezand."

Leverancier achternaam:
F4     "Leverancier 10 heeft achternaam Groot."

leverancier verstigingplaats:
F5     "Leverancier 10 heeft als vestigingsplaats AnneJozef."

Produkt:
F7     "Er is een product tegellijm."

Veel plezier er mee

[ Voor 146% gewijzigd door Verwijderd op 03-01-2005 14:56 ]

[Verwijderd]

Plezier zal ik er zeker mee hebben . Er zijn echter nog steeds een paar principes die ik niet begrijp. Ik zou de volgende vragen en antwoorden graag in mijn werkstuk opnemen (hopelijk kunt u mij de antwoorden verschaffen ):
1. Waarom waren mijn eerste diagrammen met die grote hoeveelheid objecten fout?
2. Wanneer moet ik nu iets declareren als een object en wanneer als een label. Waarom kies jij er bijvoorbeeld voor om een object Somgeld te maken (waarom maak je niet alleen het label bedrag aan rol nummer 18 vast?)?
3. Hoe moet ik die straatnaam+huisnummer nu maken? Zoals mijn laatste voorbeeld met 3 rollen naast elkaar, met aan de 1e rol het object klant, de 2e rol het label straatnaam en de 3e rol het label huisnummer, levert de volgende error: The n-1 rule is not valid for Adres Klant (=de feitexpressie met die 3 rollen).

4. De zin: Er is een artikel 10-1500. Hier zie je dat het artikel van leverancier nr 10 is en dat deze leverancier het artikelnummer 1500 (verschillende leveranciers kunnen verschillende artikelen onder artikelnummer 1500 hebben) heeft genoemd. Maakt deze feitexpressie de volgende feitexpressie overbodig: Leverancier 10 heeft artikelnummer 10-1500?


Met name vraag 2 is erg belangrijk voor mij dat ik duidelijk weet in welke gevallen dat ik nu een object moet maken en in welke gevallen alleen een label. En dus ook de vraag kan beantwoorden waarom mijn grote hoeveelheid objecten in mijn 1e poging nu zo fout is. Het is dus voor mij erg belangrijk dat ik weet op welke basis van criteria ik een object of een label moet maken zodat ik in de toekomst mijn eigen diagrammen kan maken.
Ik weet bijvoorbeeld niet of ik bij de feitexpressie: Artikel 10-1500 heeft een besteltijd van 7 dagen. nu een object BesteltijdArtikel moet maken of niet en waarom dan wel/niet.

Het is overigens de bedoeling dat ik een aantal losse igd's inlever: Een igd van de klant, leverancier, artikel, order klant, order leverancier. Dat is ook de reden dat je bij mij alles in losse igd's terug ziet komen. Hier is mijn verse artikel igd: http://home.wanadoo.nl/kinable/artikel2.JPG.
Als iemand morgen in staat is mijn vragen te beantwoorden, lukt het me morgenavond nog wel om de laatste 2 igd's te maken: leveranciersorder en klantorder (de igd leverancier gaat er trouwens exact het zelfde uit zien als de klant igd).
Normaals bedankt voor jullie inzet.

[hemaworst]

1. Waarom waren mijn eerste diagrammen met die grote hoeveelheid objecten fout?

mmm ,fout is een groot woord, het kan ook zoals je hebt gedaan, maar dan krijg je voor elkaar attribuut van en object nog een object. Je moet dan veel meer akties ondernemen om een goede database te krijgen(meer objecten, dus meer uc's en vooral meer TC's)
Ik citeer uit mijn boek:
Tijdens de analyse is het soms moeilijk uit te maken of iets een object of een label is. De gegeven regel, namelijk: classificeer als objectexpressie wat een door de gebruiker zinvol geacht object in het domein identificeert. Bij twijfel maak het een object

2. Wanneer moet ik nu iets declareren als een object en wanneer als een label.

De regel die ik altijd aanhang: dingen die ik kan aanwijzen, voorstellen, aanraken, iets tastbaars is zijn veelal objecten.
Denk aan : Personen, studenten, Orders, facturen, orderregels, factuurregels, auto's, vliegtuigen, vliegtuig vluchten, kamers, verdiepingen van een gebouw, steden/dorpen
maar ook grootheden en kleuren, zoals 1 kg, 15 cm, Eur. 20,00, kleur Oranje
Als ik zeg , geef me 20 kg, dan weet je precies wat ik bedoel. zelfde over 1 cm en over de kleur Groen
Al deze voorbeelden identificeren een duidelijk object.

labels zijn de overige "invulplekken" in je zinnen.
Meestal zijn dit gewoon attributen, zoals: voornaam, achternaam, telefoonnummers etc.

Natuurlijk kan je over sommige zaken discusieren! Bij grote twijfel maak het dan een object.
Let dan wel op dat je de TC's toevoegd anders krijg je een rare database(bijvoorbeeld een tabel met alle telefoonnummers, nogal zinloos dus)

In jouw antwoordboek kan je discussieren over het object voorkeur. Wij zouden dit object weglaten(in mijn boek hebben we precies eenzelfde casus, zonder dit object). Het is echter niet fout! met de juiste TC's krijg je dezelfde database, maar je model word er zo rommelig van. Omdat je dus onnodig objecten maakt, zorg je dat je model groter word, wat meer werk betekend en meer fouten kan opleveren.

(waarom maak je niet alleen het label bedrag aan rol nummer 18 vast?)?

Omdat ik om een bedrag gaat. zie verklaring boven

3. Hoe moet ik die straatnaam+huisnummer nu maken? Zoals mijn laatste voorbeeld met 3 rollen naast elkaar, met aan de 1e rol het object klant, de 2e rol het label straatnaam en de 3e rol het label huisnummer, levert de volgende error: The n-1 rule is not valid for Adres Klant (=de feitexpressie met die 3 rollen).

Tja, als je goed kijkt heb je nu 2 feiten in 1 zin!
Feit 1: Klant straat
Feit 2: Klant Huisnummer

Je moet er dus 2 apparte feiten van maken :
klant 2323 woont op straat <straatnaam>
en
klant 4343 woont op huisnummer <huisnummer>

4. De zin: Er is een artikel 10-1500. Hier zie je dat het artikel van leverancier nr 10 is en dat deze leverancier het artikelnummer 1500 (verschillende leveranciers kunnen verschillende artikelen onder artikelnummer 1500 hebben) heeft genoemd. Maakt deze feitexpressie de volgende feitexpressie overbodig: Leverancier 10 heeft artikelnummer 10-1500?

mmm, heb je die laatste zin zelf bedacht? Ik heb zelf daar een subset constraint toegevoegd. Alle items onder Artikel(rol 14) moeten ook in Leverancier(rol 9)
Jouw zin kan dus weg denk ik(weet jouw casus niet precies)
deze is trouwens best moeilijk voor een klein opdrachtje
Ik ben heel benieuwd welke uitwerking jouw leraar heeft!
Vergeet deze niet te posten als je hem hebt, ben wel benieuwd!

[ Voor 10% gewijzigd door hemaworst op 04-01-2005 15:49 ]

[hemaworst]

en gelukt?

[Verwijderd]

Of het gelukt is mag jij beoordelen . Ik mag hopen dat deze beter zijn dan de vorige. Ik zal eerst de losse igd's posten. Als deze losse goed zijn, zal ik 1 grote igd posten met alles in verwerkt. Als je fouten ziet, wil je dan duidelijk aangeven wat er fout is, waarom hij fout is, en wat er aan gedaan moet worden om hem kloppend te maken. Hier zijn de urls:

http://home.wanadoo.nl/kinable/artikel2.JPG
http://home.wanadoo.nl/kinable/klant2.JPG
http://home.wanadoo.nl/kinable/klantorder2.JPG
http://home.wanadoo.nl/kinable/leverancier2.JPG
http://home.wanadoo.nl/kinable/leveranciersorder2.JPG

Na jou uitleg over het declareren als label of als object, denk ik dat ik bij het igd artikel2 bij de feitexpressies Artikel op voorraad, besteltijd artikel en magazijnvoorraad, ook objecten had moeten gebruiken. Bij besteltijd heb je namelijk de grootheid tijd. Wat denk jij?

Ik hoor het wel of ik het helemaal heb verprutst, alvast bedankt.

Deus