one-to-one relation?

[Sjlosi]

In de database die ik in FP 8.5 ga opzetten komt een adressenbestand (het staat nu in een stand alone bestand), gekoppeld aan een aantal verschillende tabellen , zoals (ook al als stand alone bestanden aanwezig) fondsen, medewerkers, donateurs (hiervoor kocht ik de applicatie van FP, maar wil eerst het maken van een database verder doorgronden.).

Vraag: Ik wil het adressenbestand als een soort spin in een web gebruiken voor al deze tabellen. Hoe doe ik dat? Ik las over one to one relations. Is dat de methode? Hoe maak ik die? als ik in het grafiek een relatie leg wordt het altijd one to many of many to many. (In het leerboek staat dat het simpel is.) en hoe verbind ik het reeds bestaande adressenbestand aan de div. losse bestanden.

Bij voorbaat dank voor uw advies.

Sjlosi

[rickel]

Door een unieke sleutel (nummer) toe te kennen aan je bestand Relatie.

In de andere bestanden kan je ook een Relatienr toekennen. Via menu Bestand (File) te kiezen voor optie Definieren -> Database kan je kiezen voor Relaties. Hier koppel je als het ware de sleutels aan elkaar. Je kunt meer gegevens hierover vinden in de Help Functies of via Zelfstudie. Zelfstudie vind je terug in de directory (map) FileMaker Pro!

[Sjlosi]

dank je. Dit lijkt duidelijk, maar wat is dan het verschil met one to many?

Sjlosi

[AvD]

Een "one to one" relatie is een relatie van een heel bijzonder type, namelijk een SelfJoin. Die heeft zijn nut in heel specifieke gevallen en is in al de andere totaal overbodig. Dat hangt dus allemaal af van de functionele analyse getoetst aan de praktische werkinstrumenten die FileMaker biedt. Ben je echt zeker dat je een SelfJoin nodig hebt?

[JeanWM]

als ik in het grafiek een relatie leg wordt het altijd one to many of many to many.

 

Ik zou mij niet teveel zorgen maken over de one to one of de many to many zoals die getoond wordt in het relatiediagram.

Het is geen echt ERD, enkel een grafische voorstelling van verbindingen.

 

De meeste relaties zijn inderdaad many to many.

 

Je ziet de crow's-foot indicatoren, die geven de cardinality (Nederlands woord voor dit ? ) weer van de relatie, of geeft simpelweg een antwoord op de vraag: hoeveel X-en hebben een relatie met hoeveel Y-s.

 

Cardinality geeft aanduiding of de relatie een one to one, one to many, many to one of many to many is.

 

FileMaker geeft die informatie gebaseerd op een 'educated guess'.

 

Als een veld gedefinieerd is met gebruikmaking van een serial number, auto-entry optie, heeft unique validation of is een global, dan zal FileMaker da veld voorstellen als een 'one' in de relatie, voor het overige zal het bijna altijd een many zijn.

 

Die indicatoren in de grafiek geven dus geen echte praktische aanduiding, zij maken geen speciale relatie of dwingen iets binnen FileMaker.

Het is enkel een visuele aanduiding.

[Joris Aarts]

Hallo,

 

Als je het goed doet, dan zie je in het relatiediagram wel degelijk dat het een 1-1 relatie betreft. Er mag in feite geen kraaiepootje meer staan, want dan is het geen één op één meer. Zoals Jean zei: FileMaker kijkt naar de veldopties unieke waarde, serial number of global. Voor een 1-1 moet de optie 'unieke waarde' in feite geactiveerd zijn.

 

Ze zijn vrij zeldzaam, die 1-1's en je kan je afvragen of je de hele boel er niet alleen maar complexer mee maakt. Maar er zijn redenen om het te overwegen.

Voorbeeldje: een contacts database bevat alle contacts van klanten, maar bevat ook de personeelsleden van het eigen bedrijf. Da's handig: één enkel adressenbestand voor mailings. Maar voor die personeelsleden hebben we nog 50 extra velden nodig die overbodig zijn voor klanten: salaris, functie, ervaring, noem maar op... Om de 'gewone' contacts-tabel niet te vervuilen met die 50 velden die maar nodig zijn voor een minderheid, zou je enkel die extra velden in een aparte 'personeels'-tabel kunnen onderbrengen. De primary key (unieke sleutel) in de personeelstabel is dan net zoals in de contacts tabel de contactID. Het is het zeldzame geval waarbij je twee primary keys verbindt in een relatie.

 

In andere systemen (Access) wordt wel eens gepleit voor 1-1 relaties omwille van de security: je kan in ons voorbeeld de personeelstabel strenger beveiligen dan de contacts tabel. Maar FileMaker geeft ons de mogelijkheid om eenvoudig op veld-niveau te beveiligen, dus daar is de noodzaak minder groot.

 

@AvD: Wat een 1-1 relatie met een selfjoin te maken heeft, begrijp ik niet goed.

 

Groeten,

Joris

[Sjlosi]

Hartelijk dank voor jullie steun! Het is echt fijn, hiermee en The missing manual - blijft dit een fantastische uitdaging.

(even voorstellen - ik ben net 65 geworden en dit is een nieuwe wereld voor mij)

Deze beschrijving ondersteunt mijn keuze voor de 1 op 1 relatie!

Bij de database die ik aan het opzetten ben - gaat het vlgs. mij om zo een situatie.

We zijn bezig een hospice op te richten (d.i. een woon-huis waar mensen hun laatste levensfase in een bijna thuis situatie kunnen doorbrengen). Er is sprake van donateurs, vrijwilligers, patienten, zorgondersteuning (artsen, instellingen enz.). In de toekomst zullen er post- dan wel emailzendingen naar allen gaan. Daarnaast hebben verschillende groepen ook verschillende aanvullende 'attributen' en lay-outs nodig. (Wat donateurs betreft heb ik de amerikaanse (zucht) applicatie aangeschaft. Dat moet nog wel wat aangepast worden, dus daarvoor kijk ik al uitgebreid achter de schermen. Bijv. tussenvoegsels bij namen (van de enz.) en initialen staan er niet in. Groet, Sjlosi

[AvD]

@Joris

 

Er staat ergens*: "A self-join is a relationship in which both match fields are defined in the same table."

Heb je nu niet de ultieme one to one wanneer je in je Self-Join links en rechts hetzelfde match field aanduidt? En dat is toch een van de zeldzame gevallen waar een one to one echt zinvol is. Of geef ik daar al jaren de verkeerde naam aan? Paniek alom!

 

-----

* FM help

[JeanWM]

Ik denk het niet André...

 

A one-to-one (1:1) relationship is when at most one instance of an entity A is associated with one instance of entity B.

 

Er wordt nergens gezegd wáár A of B zijn of moeten/mogen zijn...

En een Self-Join is bijna een uniek ding voor de FileMaker wereld.

[AvD]

Jean, bedoel je dan dat entity A en entity B niet dezelfde mogen zijn?

[Peter Wagemans]

Jean:

Je ziet de crow's-foot indicatoren, die geven de cardinality (Nederlands woord voor dit ?)

Bisdom?

[Rony Rabijns]

Cardinality is de vertaling van belangrijkheid

[JeanWM]

... bedoel je dan dat entity A en entity B niet dezelfde mogen zijn?

 

Neen, want we gaan een stapje verder, waar we de classificatie hebben;

 

Relationships are classified by their degree, connectivity, cardinality, direction, type, and existence.

 

Daarin hebben we:

 

The degree of a relationship is the number of entities associated with the relationship. The n-ary relationship is the general form for degree n. Special cases are the binary, and ternary ,where the degree is 2, and 3, respectively.

 

Daaruit volgt:

 

Binary relationships, the association between two entities is the most common type in the real world. A recursive binary relationship occurs when an entity is related to itself. An example might be "some employees are married to other employees".

 

A en B kunnen/mogen (moeten soms) perfect dezelfde zijn....

[JeanWM]

Cardinality is de vertaling van belangrijkheid

 

Misschien Rony, maar hier dacht ik eerder aan cardinality in de vorm van:

 

[Data modeling]

Cardinality indicates the number of instances (one or many) of an entity in relation to another entity.

[WJ]

Even simpel.

 

one to one - 1 tot 1

one to many - 1 tot meer

many to many - meer tot meer

 

heeft niks te maken met tabellen maar met de ondelinge verhuiding van records via Primary en Foreign keys

 

One to One

 

als 1 specifiek record maar naar 1 record linked en visa versa dan spreek je van 1 tot 1 relatie

 

Onet to many (bijna iedere relatie)

 

als 1 record naar meerder records verwijzed en die records maar naar dat ene record dan spreek je van 1 tot meer

 

Voorbeeld:

1 factuur bestaad uit drie factuurregels

 

2 tabellen Factuur en Factuurregels

 

Het record in de tabel factuur heeft een relatie met meerdere factuurregels. Die specifieke factuurregels hebben een relatie naar die ENE factuur.

 

Many to Many gebruik je minder vaak . Een many tot many relatie in een ERD diagram vertaal je vaak in twee one to many relaties.

 

Voorbeeld

1 bericht heeft meerder ontvangers de ontvangers hebben meerder berichten ontvangen.

 

In filemaker los je many tot many vaak met multikeys op.

 

Groet,

 

WJ

[Sjlosi]

dankje wel ik ben daar uit gekomen.

NU een andere vraag, misschien heel eenvoudig. en ook uit nieuwsgierigheid

Ik heb een TO gemaakt voor het adressenfondsenbestandje. fondsen:adresbestand. als ik het bronbestand adresbestand tegelijk open heb, en ik typ iets in het fondsen:adresbestand zie ik de nieuwe tekst niet verschijnen (wel als ik uit het fondsen:adresbestand ben) hoe zit dat?

Sjlosi