object georienteerd en relationeel data modelleren

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Ik ben me gaan inlezen in ORM tools. Zoals je weet kan je met een tool als nHibernate (in mijn gegevel het ADO.NET entity framework) op basis van je relationele databasemodel een mapping maken met een object model. Met het ADO.NET entity framework heb je de mogelijk om per tabel een klasse te genereren. Wat leidt tot een objectenmodel waar je Business Logica tegen aan kan schrijven. Nu ben ik aardig thuis in het realtioneel data modelleren maar nog niet in OOM / OOD.

Tot nu was het maken van een conceptueel datamodel op basis van informatie het startpunt. Om vervolgens een logisch datamodel te schrijven gevolgd door een fysiek datamodel.

Ook heb ik gelezen over hoe dit zich verhoudt tot Object Oriented Modelling. Dus over zaken als: Classes vs. Entities, Generlizations vs Categories en Relationships vs Associations.

Het is mij alleen niet duidelijk hoe modelleringsprocessen naast elkaar lopen.

1. Is het conceptueel datamodel zoals we die kennen bij het relationeel data modelleren hetzelfde als voor een objectstructuur.

Indien ja, dan snap ik dat een ORM tool een juist objectenmodelen kan genereren omdat zaken te vertalen zijn zoals Relationships -> Associations.

Indien nee, dan is je gegenereerde objectenmodel niet hetzelfde als je zou maken wanneer je zelf een conceptueel objectmodel zou schrijven. Hoe gaat met hier mee om? Wanneer start men dan met het maken van een conceptueel datamodel?

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 22:59
Een eenvoudig relationeel model kan je misschien wel makkelijk (min of meer) 1 op 1 vertalen naar een OO model, maar de vraag is dan maar of je OO model dan wel zo gemodelleerd is zoals jij het wil ?
Kan je op die manier een 'expliciet' domain model maken, dat gebruik maakt van de kracht van OO ? Wat met inheritance ? Er zijn natuurlijk wel een aantal patterns die je kan gebruiken om inheritance in een relationeel model weer te geven bv (een 3-tal), maar hoe flexibel kan je een op basis van een data-model gegeneerd object-model gaan aanpassen (in EF bv, ik weet wat het EF is, maar ik heb er nog niet mee gespeeld, ik ben momenteel meer met NHibernate bezig).

In de 'domain driven design' stroming heb je veel mensen die eerst beginnen met het ontwikkelen van een object-model, en daarna pas hun DB-model gaan ontwerpen (of laten genereren op basis van het object-model).
Nu heb ik dit zelf ook nog niet gedaan (voor veel DDD'ers is het opslaan van de gegevens niet meer dan een implementatie - detail, waar ik het niet zo mee eens ben. Waar de gegevens in terecht komen is een implementatie detail, maar hoe die gegevens opgeslagen worden (datastructuur), lijkt me toch iets meer te zijn dan een implementatie-detail);
ik ga meestal mijn datamodel zelf ontwerpen, en mijn object model ook, en dan ga ik daar manueel de mappings voor maken. (Veel werk idd, maar dan ben je imho wel flexibel, en op die manier weet ik ook meer wat en waarom ik iets doe).

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Jouw antwoord bevestigd waarom er bij mij vragen naar boven zijn gekomen. Immers over beide methoden zijn bibliotheken vol boeken geschreven. Het 1 op 1 vertalen geautomatiseerd van een relationeel datamodel naar een objecten model suggereert dat het relationeel model een goed uitgangspunt is voor je objecten model. Terwijl je met het relationeel modelleren juist andere regels toepast als bij object modelleren. Immers je past relationeel modelleren toe om zijn eigen sterke punten.

De reden voor mijn vraag is misschien veroorzaakt door de naamgeving van Microsoft voor een onderdeel van het Entity Framework. Zij noemen de gegenereerde klassen verzameling een 'conceptual object model'. De naam conceptueel deed bij mij die vraag opreizen. Ik begrijp nu dat met ORM er niet altijd een model naar wens uitkomt.

Zeg ik het goed dat er eigenlijk 2 informatieanalyses gedaan moeten worden in een ideale situatie? Eentje gericht op een relationeel model en eentje gericht op een objectenmodel? Kan iemand een zo simpel mogelijk voorbeeld geven waarbij uit deze informatieanalyse een conceptueel objectmodel uitrolt wat afwijkt van het conceptueel datamodel.

edit:

is het een juiste aanpak om op je gegeneerde classes een extra laag te schrijven met Business Objecten waar je OO toepast aan de hand van de classes? Om daar weer een Business Logica laag op te schrijven.

[ Voor 8% gewijzigd door Anoniem: 141965 op 15-08-2008 11:44 . Reden: nieuw inzicht ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Een 'Entity' is een abstract begrip, die een projectie heeft naar een relationeel model (bv tabel) en code (class). Beide praten dus over hetzelfde, want anders kun je niet rederen over de data die in een tabelrow of class instance zit. Een O/R mapper zorgt er voor dat je dus in code kunt praten over een entity instance (tuple met data) die eigenlijk uit een database komt en vice versa.

Ik ga mezelf niet herhalen dus verwijs ik naar mn essay hierover van een tijdje geleden:
http://weblogs.asp.net/fb...-is-the-Domain-Model.aspx

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
EfBe schreef op vrijdag 15 augustus 2008 @ 12:42:
Een 'Entity' is een abstract begrip, die een projectie heeft naar een relationeel model (bv tabel) en code (class). Beide praten dus over hetzelfde, want anders kun je niet rederen over de data die in een tabelrow of class instance zit. Een O/R mapper zorgt er voor dat je dus in code kunt praten over een entity instance (tuple met data) die eigenlijk uit een database komt en vice versa.

Ik ga mezelf niet herhalen dus verwijs ik naar mn essay hierover van een tijdje geleden:
http://weblogs.asp.net/fb...-is-the-Domain-Model.aspx
The Ideal World Using NIAM/ORM for Classes and Databases
For most people, reality is not always in sync with what we expect to be an ideal world, and everyday software development is no exception to that. In the functional research paragraph, physical relational model metadata were used to produce mappings and classes to get to the entity class definitions for the developer to work with. A more ideal approach would be if the NIAM/ORM model could also be used to generate entity classes directly, avoiding a transformation from metadata to class definition. It would make the ultimate goal, where the design of the application is as usable as the application itself, appear to be one step closer.

When that ideal world will be a reality, or even if it will be a reality, is hard to say as a lot of the factors that influence how a software project could be made a success can be found in areas outside the world of computer science. Nevertheless, it's interesting to see what can be accomplished today, with techniques developed today, like model-driven software development.
Begrijp ik je goed wanneer ik zeg dat een NIAM model opstellen de ideale uitganssituatie is om zowel een kloppend objecten model als wel een kloppend relationeel datamodel op te stellen maar dat dit nu nog niet mogelijk is?

Heb een aantal jaren geleden een aantal colleges NIAM gevolgd waarbij we een project deden. Eens kijken of ik er nog wat van weet! Ik neem aan dat je het hebt over: Wikipedia: NIAM

Is dit NIAM model 'ideaal' om een relationeel datamodel en ene objectmodel te maken volgens hun eigen modelleringsregels? http://upload.wikimedia.o...ommons/8/89/NIAM_feit.JPG

Ik ben benieuwd!

[ Voor 8% gewijzigd door Anoniem: 141965 op 15-08-2008 21:28 . Reden: uitbreiding ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 141965 schreef op vrijdag 15 augustus 2008 @ 21:11:
[...]
Begrijp ik je goed wanneer ik zeg dat een NIAM model opstellen de ideale uitganssituatie is om zowel een kloppend objecten model als wel een kloppend relationeel datamodel op te stellen maar dat dit nu nog niet mogelijk is?
Een NIAM model of een navenant model op hetzelfde abstractieniveau beschrijft de relatie tussen attributes en entities en de relatie tussen entities onderling. Dat model kun je vertalen naar zowel tabellen als classes.

Het kan op dit moment wel, maar niet middels goede tools. Op dit moment zijn de tools er niet om op het niveau van een NIAM model een entity model te beschrijven die zowel naar classes als naar tables projecteren. De huidige tools zijn OF class beschrijvers die mappen naar tables (en dus de 2 projectieresultaten met elkaar verbinden, maar niet de entities beschrijven) of andersom, tabellen met classes verbinden, of de tabellen reverse engineren naar een NIAM niveau: het startpunt is echter niet een entity model. Je moet dus of een entity model maken en daar classes van maken en een entity model maken en daar tables van maken en die dan mappen, of een bestaand model pakken, maar vanuit 1 model beide bouwen is er gewoonweg niet.

Er is een reden voor overigens: projectie naar classes is veelal 1:1 en men wil graag in of tabels of classes denken (dus in ieder geval is 1 van beide kanten een 1:1 mapping).

Het is echter wel aan te bevelen om in ieder geval op het abstractieniveau van NIAM je tabellen te maken en het model te gebruiken voor je classmodel (dus bv inheritance die je definieert in NIAM, ook gebruikt in je classmodel).

Wellicht een iewat moeilijk verhaal allemaal, maar het is helaas complexer dan wat menigeen denkt: het gaat niet om classjes intikken en tabelletjes definieren: het gaat om WAAROM die class en die table zijn gedefinieert en waarom ze er zo uit zien en niet anders. Die reden is te vinden in het niam model, wat weer refereert naar de werkelijkheid waar het project mee te maken krijgt.

[ Voor 10% gewijzigd door EfBe op 15-08-2008 21:30 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
De visie die je hebt, leg je erg duidelijk uit. Bedankt!

Ik wilde nog een edit doen voor de duidelijkheid van het topic. Er wordt in dit topic nu twee keer ORM gebruikt. De mijne is een afkorting voor Object Relational Mapping en jij bedoelt Object Role Modelling (toch? :) ).

Ik ben geen programmeur met jaren ervaring maar vind deze onderwerpen erg interessant. Het is prettig om te lezen dat ORM en dan met name NIAM een goed vertrekpunt is om zowel een objectmodel als wel een relationeel datamodel te maken! En dat er een Nederlander verantwoordelijk is voor NIAM zoals we dat nu kennen is wel cool! :) Ik ga mij nog eens herinlezen in NIAM, dit is namelijk wel een beetje weggezakt na die jaren.

Wanneer ik een volgende aanpak zou kiezen om een relationeel en objectmodel neer te zetten, ben ik dan goed bezig?

1. probleem modelleren in een NIAM model
2. Conceptueel datamodel, Logisch datamodel en Fysiek datamodel schrijven op basis van NIAM model.
3. Objectenmodel genereren op basis van fysiek datamodel middels een Object Relational Mapping tool zoals nHibernate, ADO.NET Entity Framework of LLBLGen Pro.

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 141965 schreef op vrijdag 15 augustus 2008 @ 21:49:
De visie die je hebt, leg je erg duidelijk uit. Bedankt!

Ik wilde nog een edit doen voor de duidelijkheid van het topic. Er wordt in dit topic nu twee keer ORM gebruikt. De mijne is een afkorting voor Object Relational Mapping en jij bedoelt Object Role Modelling (toch? :) ).
Ja, object role modelling inderdaad. 'ORM' is daar de afkorting van, en het is jammer dat steeds meer mensen 'ORM' gebruiken voor o/r mapping.
Ik ben geen programmeur met jaren ervaring maar vind deze onderwerpen erg interessant. Het is prettig om te lezen dat ORM en dan met name NIAM een goed vertrekpunt is om zowel een objectmodel als wel een relationeel datamodel te maken! En dat er een Nederlander verantwoordelijk is voor NIAM zoals we dat nu kennen is wel cool! :) Ik ga mij nog eens herinlezen in NIAM, dit is namelijk wel een beetje weggezakt na die jaren.
Meerdere Nederlanders volgens mij, maar Nijssen is wel de belangrijkste, Je hoeft niet alles te gebruiken van NIAM/ORM overigens, want veel constructs zijn alleen in checkconstraints uit te drukken of validatie code, en die kun je buiten je model laten (hoeft niet natuurlijk)
Wanneer ik een volgende aanpak zou kiezen om een relationeel en objectmodel neer te zetten, ben ik dan goed bezig?

1. probleem modelleren in een NIAM model
2. Conceptueel datamodel, Logisch datamodel en Fysiek datamodel schrijven op basis van NIAM model.
3. Objectenmodel genereren op basis van fysiek datamodel middels een Object Relational Mapping tool zoals nHibernate, ADO.NET Entity Framework of LLBLGen Pro.
Lijkt mij in ieder geval een zeer goede werkwijze. :) Je hebt dan nl. een theoretische basis voor je code: waarom zijn entity A en B in het model etc.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Ik heb even een paper snel doorgelezen over ORM en daar uit kan ik opmaken dat er een mapping algoritme bestaat om een conceptueel schema om te zetten naar een logisch genormaliseerd datamodel. Ik was nieuwsgierig naar welke normaalvorm met de mappings regels wordt bereikt.

Zijn er ook ontwikkelaars die kiezen voor een aanpak waar ze een ORM model maken. Op basis hier van een relationeel datamodel en een objectenmodel om deze vervolgens handmatig te mappen om zo best of both worlds te krijgen?

[ Voor 29% gewijzigd door Anoniem: 141965 op 16-08-2008 13:59 ]


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
@EfBe

Ik lees op een frontprage artikel van vorig jaar de volgende comment van jou.
Iedere O/R mapper (behalve iBatis) genereert zn queries on the fly zelf, er is alleen een verschil in hoe je begint:
1) reverse engineering van je datamodel tot een abstract entity model, op het niveau van NIAM/ORM, daar dan entity classes van maken, die je dan mapt of 1 of meerdere tables/views in je datamodel. LLBLGen Pro volgt dit model, Linq to Sql en Linq to Entities ook.
2) classes maken, dan mappings definieren naar tables/views en of die bestaan of niet, boeit niet zo (als ze niet bestaan worden ze aangemaakt.). Dit model wordt veel toegepast in de wat kalere o/r mappers, dus de o/r mappers met puur een runtime library. At runtime genereren ze dan een subclass (dynamic proxy) per gemapte class, of ze manipuleren na de compilatie de IL code. NHibernate o.a. gebruikt dit model
Hieruit begrijp ik dat de aanpak (conceptueel model met NIAM maken, tabellen maken en classes maken) alleen werkt met LLBLGen Pro en het Entity Framework.

Nu willen wij (een vriend en ik) bekend geraken met deze aanpak. Hiermee valt nHibernate wat mij betreft af. Blijven er 2 over! Wat zijn de verschillen tussen het Entity Framework van Microsoft en nHibernate? Zeg jij, ondanks je relatie met nHibernate, ga lekker aan de slag met het Entity framework om hier mee te leren? Of lopen wij dan snel tegen tekortkomingen aan?

De reden voor deze vraag is natuurlijk dat je voor het 1 wel moet betalen en voor het ander niet!

[ Voor 4% gewijzigd door Anoniem: 141965 op 16-08-2008 21:59 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Ik heb niks met nHibernate hoor ;)

Als je met een microsoft framework wilt gaan werken, dan is linq to sql denk ik simpeler om mee te beginnen, het entity framework heeft nl. een designer die dingen nogal erg complex maakt en eigenlijk een draak is om mee te werken. Het entity framework kan wel meer (inheritance over meerdere tables), maar dat is lang niet altijd nodig.

Ik vind het altijd fijn als mensen mij geld geven natuurlijk, maar omdat je twijfelt kun je eerst met het entity framework of linq to sql wat gaan spelen, en je kunt onze demo install ernaast leggen en kijken wat je dan meer hebt of minder. het gaat ook om waarvoor je het gebruikt natuurlijk, is het een hobby/gratis/opensource project dan is het uitgeven van geld aan een tool niet echt een topprioriteit.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
EfBe schreef op zondag 17 augustus 2008 @ 10:41:
Ik heb niks met nHibernate hoor ;)
Ik bedoel natuurlijk LLBGen Pro :).
EfBe schreef op zondag 17 augustus 2008 @ 10:41:
Als je met een microsoft framework wilt gaan werken, dan is linq to sql denk ik simpeler om mee te beginnen, het entity framework heeft nl. een designer die dingen nogal erg complex maakt en eigenlijk een draak is om mee te werken. Het entity framework kan wel meer (inheritance over meerdere tables), maar dat is lang niet altijd nodig.

Ik vind het altijd fijn als mensen mij geld geven natuurlijk, maar omdat je twijfelt kun je eerst met het entity framework of linq to sql wat gaan spelen, en je kunt onze demo install ernaast leggen en kijken wat je dan meer hebt of minder. het gaat ook om waarvoor je het gebruikt natuurlijk, is het een hobby/gratis/opensource project dan is het uitgeven van geld aan een tool niet echt een topprioriteit.
Ik ga eens wat meer lezen hierover.

Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Ik ben nog eens Scott Gu zijn introductie tutorials door gaan lezen. En ben nog wat op internet gaan kijken om ervaringen van mensen te vinden met LINQ te SQL.

Ik kwam op het volgende blog terrecht.

http://cs.rthand.com/blog...-to-SQL-showstoppers.aspx

Nu kan ik niet goed beoordelen of LINQ to SQL een n-tier applicatie ontwikkelen slecht ondersteund. Een praktisch probleem vind ik wel dat je niet eenvoudig je LINQ classes kan syncrhoniseren met je database. Dit is een must have vind ik. Ik wil namelijk samen met een vriend een project doen en dan moet de mapping eenvoudig gedaan kunnen worden. Ik geloof dat er in het Entity Framework er wel een Update Model From Database zit.

Ik las dat het een reden van het bestaan van LINQ tot SQL en het Entity Framework zou zijn dat het LINQ tot SQL project in handen is van het C# team en niet van het data programabillity team en dat daardoor het Entity Framework zou bestaan :S

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 141965 schreef op zondag 17 augustus 2008 @ 14:37:
Ik ben nog eens Scott Gu zijn introductie tutorials door gaan lezen. En ben nog wat op internet gaan kijken om ervaringen van mensen te vinden met LINQ te SQL.

Ik kwam op het volgende blog terrecht.

http://cs.rthand.com/blog...-to-SQL-showstoppers.aspx

Nu kan ik niet goed beoordelen of LINQ to SQL een n-tier applicatie ontwikkelen slecht ondersteund. Een praktisch probleem vind ik wel dat je niet eenvoudig je LINQ classes kan syncrhoniseren met je database. Dit is een must have vind ik. Ik wil namelijk samen met een vriend een project doen en dan moet de mapping eenvoudig gedaan kunnen worden. Ik geloof dat er in het Entity Framework er wel een Update Model From Database zit.
Update model in het EF is ook maar brak hoor: het heeft geen settings om veel dingen automatisch te doen en laat je project bv in een state achter waarbij je nog steeds veel met de hand moet opruimen of opnieuw moet mappen. LLBLGen Pro ondersteunt wel een volledige model refresh (ook voor linq to sql)
Ik las dat het een reden van het bestaan van LINQ tot SQL en het Entity Framework zou zijn dat het LINQ tot SQL project in handen is van het C# team en niet van het data programabillity team en dat daardoor het Entity Framework zou bestaan :S
Klopt. Linq to Sql is eigenlijk ontstaan als testimplementatie voor linq naar een database met dezelfde mensen als waar objectspaces door gemaakt is. Het EF is ontstaan uit de behoefte om een generiek platform te hebben voor veel data-oriented services. Nu is linq to sql ondergebracht bij het ADO.NET team (die ook het EF beheert) dus men gaat er in het algemeen van uit dat wat je nu ziet van linq to sql dat daar niet veel aan zal veranderen.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Je bedoelt dat er niet doorontwikkeld zal worden voor LINQ to SQL en dat EF het gene is waar men wel verder mee zal gaan?

Als de tijd rijp is zal ik eens een demo versie downloaden van LLBGen Pro.

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 141965 schreef op maandag 18 augustus 2008 @ 10:04:
Je bedoelt dat er niet doorontwikkeld zal worden voor LINQ to SQL en dat EF het gene is waar men wel verder mee zal gaan?
Dat is wat men verwacht ja. Matt Warren, een van de 4 main developers van Linq to Sql werkt bv al heel lang niet meer aan Linq to Sql, en er waren fundamentele wijzigingen beloofd voor SP1 van vs.net 2008, maar daarvan is niets terecht gekomen: de code is gefixed op sommige plaatsen om wat bugs te verwijderen, maar er is geen toekomstvisie.

IMHO een domme zet, want het EF moet eerst nog maar van de grond komen terwijl linq to sql best wel veel gebruikt wordt.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
In onderstaande blogs is te lezen hoe met Inheritance om te gaan in Linq to SQL en hoe hier mee om te gaan in het Entity Framework.

http://blogs.microsoft.co...q-to-sql-inheritance.aspx

http://weblogs.asp.net/ze...-in-entity-framework.aspx

Uit de blogs is op te maken dat het op dit gebied uitgebreider en dus krachtiger zou zijn. Ik vind, ben nog overvaren met OR/Mappers dat, inheritance mogelijk zo goed als mogelijk zouden moeten werken in een dergelijke tool om zo goed mogelijk echte wereld Entities te kunnen definieeren.

Het is alleen nog een beetje lastig om te beoordelen hoe goed Entity framework hier in is...

Hoe goed implementeerd Llblgen bijboorbeeld inheritance? En is de implementatie hiervan goed te gebruiken als in gebruikersvriendelijkheid?

edit:

Antwoord van de site
Full entity type inheritance
LLBLGen Pro supports three types of inheritance:
  • Complete hierarchy mapped onto a single table. In LLBLGen Pro this is called TargetPerEntityHierarchy. This is the inheritance type which is very easy to implement and therefore supported by most O/R mappers.
  • Every type in a hierarchy mapped onto its own table, no discriminator column. In LLBLGen Pro this is called TargetPerEntity. This inheritance type is hard to implement, most O/R mappers fall back to option 3.
  • Every type in a hierarchy mapped onto its own table, with discriminator column in root type. Similar to option 2, and because LLBLGen Pro doesn't need a discriminator column for option 2, this type is supported but the discriminator column is ignored / not required.
The LLBLGen Pro designer can find inheritance hierarchies automatically.
Duidelijk dus...over het geautomatiseerd vinden van inheritance hierarchien. Ik neem aan dat dit valt of staat met de kwaliteit van het relationele datamodel toch?

Over LINQ trouwens en LLBGenPro. Linq to Sql templates is wat anders dan LINQ Support toch?

[ Voor 40% gewijzigd door Anoniem: 141965 op 19-08-2008 00:56 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 141965 schreef op dinsdag 19 augustus 2008 @ 00:03:
Duidelijk dus...over het geautomatiseerd vinden van inheritance hierarchien. Ik neem aan dat dit valt of staat met de kwaliteit van het relationele datamodel toch?
Ja, je moet FK constraints hebben tussen PK's, dus Employee's PK heeft een FK naar Person's PK, zoals je ook zou doen wanneer je een NIAM model met inheritance zou converteren naar tables.
Over LINQ trouwens en LLBGenPro. Linq to Sql templates is wat anders dan LINQ Support toch?
Ja, Linq support is dat je via linq constructies (dus var q = from c in md.Customers select c; ) kunt queryen, wat bij llblgen pro kan en linq to sql templates is dat je de designer gebruikt om linq to sql code te genereren (dus de classes en de mapping file).

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Heb je met het gebruik van de templates nog steeds evenveel functionaliteit onder de motorkop als wanneer je gewoon tegen 'LLBGen Pro entities' zou aan programmeren?

http://blogs.microsoft.co...q-to-sql-inheritance.aspx


In dit voorbeeld wordt met een een discriminator kolom bepaald to welke klasse een record behoort. In het voorbeeld bestaan er voor sales mensen en programmeurs 'eigen' kolommen in de tabel Person. Er worden 2 klassen gedefinieerd SalesPerson en Programmer welke eigenschappen van de Person class overerven. Kan dit ook herkend worden door LLBGenPro?

[ Voor 16% gewijzigd door Anoniem: 141965 op 19-08-2008 09:55 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 141965 schreef op dinsdag 19 augustus 2008 @ 09:53:
Heb je met het gebruik van de templates nog steeds evenveel functionaliteit onder de motorkop als wanneer je gewoon tegen 'LLBGen Pro entities' zou aan programmeren?

http://blogs.microsoft.co...q-to-sql-inheritance.aspx


In dit voorbeeld wordt met een een discriminator kolom bepaald to welke klasse een record behoort. In het voorbeeld bestaan er voor sales mensen en programmeurs 'eigen' kolommen in de tabel Person. Er worden 2 klassen gedefinieerd SalesPerson en Programmer welke eigenschappen van de Person class overerven. Kan dit ook herkend worden door LLBGenPro?
Nee, en dat kan linq to sql ook niet. Je moet zelf aangeven welke discriminator column je wilt gebruiken EN welke value aangeeft welk type het is. Zie niam hierarchy flattening naar single table. Inheritance in databases is een puur semantische zaak: code interpreteert data in een database en gaat op basis van de interpretatieresultaten conclusies trekken bv: dit is een row van type X. De inheritance zelf is dus niet in een relationeel model te modelleren.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 141965

Topicstarter
Bieden OR/M tools een oplossing voor het volgende? Stel ik maak een aantal standaard modules welke gebruik maken van een database. Zoals een gastenboek, een foto album en een mededelingen functie. Voor iedere module zorg ik voor een mapping tussen tabellen en entiteiten. Het gastenboek project bevat bijvoorbeeld alleen een mapping naar de gastenboek tabellen. Wanneer ik nu een custom applicatie wil maken, welke natuurlijk zijn eigen probleemdomein met entiteiten heeft, dan wil ik eenvoudig bestaande fotoalbum functionaliteit kunnen inzetten. Of ik heb een generiek stukje membership geschreven wat ik in alle sites wil gebruiken. Doordat de modules opzich zelf staande projecten zijn, zit de bijhorende entiteiten/tabellen mapping ook in die projecten. Kan je de losstaande entiteit modellen bij elkaar bekend maken? Immers op de database zijn de tabellen voor members aanwezig naast de custom tabellen. Het lijkt me niet de bedoeling om het fotoalbum opnieuw als entiteit te definieeren in het custom project terwijl dit al gedaan is in het eigen fotoalbum project? Ik kan zelf geen antwoord vinden op deze vraag en ik zou graag een aantal handige generieke modules willen schrijven. Let op: ik bedoel dus wanneer er een relatie bestaat tussen tabellen die niet bij elkaar horen in een standaard module.

edit:

Het gaat me dus om wanneer het probleemdomein van de custom applicatie een relatie heeft met de toepassing van de generieke module. Een gastenboek zal, wanneer de bezoeker niet een rol speelt in het domein, eenvoudiger te implenteren dan wanneer het probleemdomein wel mengt met de generieke module. Wanneer je tegen de relationele database aan zou programmeren dan heb je gewoon alle tabellen to je beschikking.

[ Voor 13% gewijzigd door Anoniem: 141965 op 19-08-2008 15:01 ]

Pagina: 1