FCO-IM of ERD

[Verwijderd]

Hallo, bij mijn opleiding hebben we twee verschillende technieken geleerd, waarmee je een database model kan maken. Namelijk met FCO-IM en met ERD. FCO-IM vind ik opzich veel lekkerder werken en het opbouwen van relaties en tabellen gaat veel natuurlijker. Bij ERD gaat het ook wel alleen blijf ik vaak twijfelen of het wel klopt. Ik zal voor mezelf mij voors en tegens opstellen voor beide methoden:

FCO-IM:
Voordelen

• op gevoel werken( je bouwt de structuur mbv zinnen )
• gemakkelijk herkennen van fouten( en als je het niet ziet, vertelt FCO-IM het wel)
• begrijpelijk voor de gebruikers( hun verhaal vertaald door de tool

Nadelen

• Het kan te complex worden( Het ontwerp wordt een groot spinnenweb)
• Kans op copy/paste fouten die het gehele ontwerp verprutsen
• Lastig om een foutje snel te wijzigen
• Ingewikkelde dingen als overerving en recursie zijn (bijna?) onmogelijk

ERD:
Voordelen

• Snel een ontwerp gemaakt
• Overzichtelijk ontwerp
• Veel gebruikte techniek
• Ingewikkelde dingen als recursie en overerving zijn makkelijk te gebruiken

Nadelen

• Voor buitenstaander lastiger te begrijpen
• Lastiger om hiermee vanuit een idee in je hoofd gelijk een model te maken

Wat vinden jullie en welke techniek vinden jullie het beste voor het ontwerpen van de databasestructuur. Heb btw laatst nog met taal Z gewerkt, dit is nog abstracter en
wordt gebruikt om tabellen, queries en relaties mbv formules weer te geven. Werken
meer mensen hiermee in het bedrijfsleven, of is dit slechts mooie theorie.

[ Voor 4% gewijzigd door Verwijderd op 17-08-2005 22:44 ]

[NMe]

Ik had nog nooit van FCO-IM gehoord, dus ik heb even een tour gevolgd op de officiële website. Mijn eerste indruk is juist dat de diagrammen die je met FCO-IM helemaal niet leesbaar zijn voor een buitenstaander/niet-programmeur, waar een ERD dat nog wel redelijk is. Sowieso zijn de stappen die je moet nemen om tot een ERD te komen (normaliseren) veel eenvoudiger/sneller te realiseren dan de stappen die je moet doorlopen om een FCO-IM model te maken. Persoonlijk ga ik het dus bij ERD's houden voor mijn eigen projecten.

[Verwijderd]

Bij FCO-IM maak je eerst zinnen als

Er is een Topic met id 52
Er is een user met naam menno_bakker

Topic met id 52 is geplaatst door user met naam menno_bakker
Topic met id 52 heeft als content 'blaa'

etc

[whoami]

Ik heb ook nog nooit van FCO gehoord, maar als ik het zo bekijk, dan is ERD gebaseerd op een theorie, terwijl je bij FCO meer gevoelsmatig werkt ?
Dan blijf ik wel bij het ontwikkelen van ERD schema's.

[ Voor 8% gewijzigd door whoami op 17-08-2005 08:50 ]

[RedRose]

FCO-IM lijkt me helemaal niet handig zelfs om een datamodel te maken, tenzij je heel goed weet wat je ermee aan het doen bent in FCO. Het lijkt wel alsof je iterative pseudocode opbouwt, om dat vervolgens alsnog weer te gaan ombouwen naar schema's. Ik zat even na te denken of je FCO misschien kan gebruiken voor een DAL of BL, maar ja, dan kies ik liever voor UML.

[Feyd-Rautha]

FCO-IM gelijkt op het eerste gezicht zeer goed op de ORM modeleertechniek. Met ORM modeleer je op een conceptueel niveau (een niveau hoger dan logisch [erd]). Daarbij wordt het domein ook gemodeleerd door middel van zinnen (zie menno-bakker) en daarom zou deze techniek (ORM dus) beter te begrijpen zijn voor domein-experts.

Een ORM schema kan je ook mbv een algoritme perfect mappen naar een ERD schema.
In een ORM schema kun je ook bepaalde constraints enkel/veel beter weergeven dan in een ERD schema.

Volgens mij is FCO-IM dus zoals ORM waarbij je op een nog hoger niveau modeleert.

[cenix]

FCO-IM is gebaseerd op NIAM, wellicht dat andere mensen het wel iets zegt.

@menno_bakker: je kunt je FCO-IM model ook omzetten in een ERD via een tooltje genaamd FCO-IM Bridge.

[MaNdM]

Ik ken beide technieken. Op zich zou het eindresultaat hetzelfde moeten zijn, in theorie dan. Dus voor je eindresultaat zou het geen verschil mogen maken. Let wel dat ik hier niet stel dat de resultaten altijd exact gelijk zullen zijn.

ERD's kunnen ook heel erg complex worden maar dat is vooral afhankelijk van de complexiteit van de data die je in tabellen wilt proppen. Hoe meer je vast gaat leggen immers hoe meer tabellen. Bij ERD's is het echter wel zo dat het herkenbaarder is qua vormgeving, een entiteit ziet er in principe al een beetje uit als een tabel. Daarbij komt dat je na het ERD naar het LRS gaat (Logisch Relationeel Schema) en daarmee hou je als het ware de overgang van schematische weergave naar databasestructuur wat meer in zicht. Bij FCO-IM tools is dit minder zichtbaar als ik mij niet vergis. Tel daarbij op dat FCO-IM heel veel werk met zich mee brengt als je kijkt naar de shitload aan existensie postulerende feittype expressies die je nodig hebt en die je dus ook nog op zal moeten stellen. Bij ERD's heb je daar minder last van aangezien je daar werkt met noun-phrase technieken en die zijn imho net even wat sneller te gebruiken.

Wat ik dus eigenlijk probeer aan te geven is het verschil in tijd dat je nodig hebt bij beide technieken. Verder zijn ze beiden zeker geschikt voor deze taak, het is m.i. meer een kwestie van smaak en dus wat jij prettig vind moet je gebruiken. Persoonlijk geef ik de voorkeur aan ERD's.

[bloody]

lol, zit je zeker op windesheim?

maar goed, volgens mij heeft FCO-IM ook tot doel om te komen om een goed mogelijk ERD.
Wat ik altijd deed is een export naar access (VBA) maken, waar je dan de erd met een druk op de knop op het scherm zet.

Ik heb het voor de rest nog nooit in het wild bij een bedrijf gezien!

[Verwijderd]

Ik vind FCO-IM fijn werken, door het te gebruiken 'forceer' ik bijna dat mijn model goed wordt; het is handig om je model te controleren omdat je makkelijk vanuit een model terug kan gaan naar expressies, welke snel te controleren zijn. Ik heb verder geen ervaring met self-referencing e.d. van objecten, dus ik kan geen uitspraak doen over de wat 'complexere' modellen.

[Verwijderd]

Een ERD leerden wij voor het eerste op de Haagse Hogeschool ook maken aan de hand van voorbeeldformulier en geformuleerde zinnen. Ik vind een ERD echt wel makkelijker om te lezen en vooral snel uit de losse mouw te schudden voor een klein projectje.

[igmar]

Verwijderd schreef op woensdag 17 augustus 2005 @ 00:39:
FCO-IM:
Voordelen

• op gevoel werken( je bouwt de structuur mbv zinnen )
• gemakkelijk herkennen van fouten( en als je het niet ziet, vertelt FCO-IM het wel)
• begrijpelijk voor de gebruikers( hun verhaal vertaald door de tool

Nadelen
[list]
• Het kan te complex worden( Het ontwerp wordt een groot spinnenweb)

En dat is een nadeel omdat ? Sommige ontwerpen zijn nu eenmal complex, daar veranderd ERD ook niks aan.

• Kans op copy/paste fouten die het gehele ontwerp verprutsen

Da's een gebruikersprobleem, niet een van FCO.

• Lastig om een foutje snel te wijzigen

Eigenlijk nooit geen last mee gehad.

• Ingewikkelde dingen als overerving en recursie zijn (bijna?) onmogelijk

Je maakt een *db* schema, geen UML model. Databases kennen geen recursie of overerving, dat zijn dingen die in OO talen een rol spelen.

FCO is een modelleertechniek, ERD is gewoon een aanduiding voor een diagram. Neem van mij aan : 800 tabellen wil je echt niet modelleren in een ERD. FCO is wat arbeidsintensiever, maar mits goed gebruikt erg krachtig.

[Verwijderd]

igmar schreef op donderdag 18 augustus 2005 @ 12:46:

[...]
Je maakt een *db* schema, geen UML model. Databases kennen geen recursie of overerving, dat zijn dingen die in OO talen een rol spelen.

Nou als je in je erd een standaardtabel hebt en van daaruit verschillende tabbelen maakt die deze uitbreiden dan kan je overerving gebruiken. Alleen op het moment dat de daadwerkelijke sql gemaakt wordt is de keuze aan de gebruiker hoe dit geimplementeerd wordt. Ook recursie is mogelijk als je in een tabel een verwijzing hebt naar een object uit dezelfde tabel(Onee da's geen recursie). Maar er was wel iets, kan er alleen effe niet opkomen.

[Verwijderd]

• op gevoel werken( je bouwt de structuur mbv zinnen )

Door de zinnen is het goed te analyseren, en werk je juist niet 'op gevoel' maar is het juist echt goed. 'Op gevoel werken' is juist een van de nadelen van ER.

• begrijpelijk voor de gebruikers( hun verhaal vertaald door de tool)

De zinnen zorgen voor een begrijpelijk verhaal voor de eindgebruikers. Het diagram is inderdaad alleen voor de analist.

• Het kan te complex worden( Het ontwerp wordt een groot spinnenweb)

Probeer een dergelijk complex diagram eens in ER te maken. (denk hierbij dan wel aan ten minste 100 entiteiten)

• Kans op copy/paste fouten die het gehele ontwerp verprutsen

In tegenstelling tot ORM is FCO-IM geen drag'n drop tool. Copy paste is daarom niet mogelijk.
Waarom zou je eigenlijk copy-paste willen gebruiken. Het zou leiden tot extra objecten, die mogelijk extra tabellen kunnen opleveren, gewoon redundantie dus.

• Ingewikkelde dingen als overerving en recursie zijn (bijna?) onmogelijk

FCO-IM is een van de weinige modelleringstechnieken waarin recursie echt goed is te modelleren. En overerving (subtypering in FCO-IM) is ook geen enkel probleem.

Let wel, recursie is tot op heden niet mogelijk in relationele databases, maar dus wel te modelleren in FCO-IM

• Ingewikkelde dingen als recursie en overerving zijn makkelijk te gebruiken

Recursie wordt vaak verward met zelf-refererend: een FK naar zichzelf.
Recursie is dat binnen de PK (van bijv. 2 delen) een deel terugverwijst naar zichzelf. Beiden kunnen gemakkelijk in FCO-IM worden gemodelleerd. Echte recursie zoals hiervoor beschreven is binnen ER niet mogelijk.

[ Voor 3% gewijzigd door Verwijderd op 18-08-2005 16:14 ]