[Databases] Modeleren met Visio: ORM Source Model

[Verwijderd]

Tot nu toe hebben we alle databases opgezet doormiddel van het direct inkloppen van de database vanuit een analyse dus zonder ERD of wat dan ook. Nou ben ik daar zelf niet bepaald een voorstander van en omdat ik een groot voorstander ben van ORM (lijkt op NIAM) heb ik de analyse eens in een Visio ORM Source model gestopt met alle constraints, voorbeelden, etc.

Hiermee wil ik dan een Logisch en Fysiek database schema genereren (met eventuele kleine aanpassingen zoals de SP's omzetten naar triggers) om deze daarna aan LLBLGen Pro te voeden (ook nieuw voor ons). Tot nu toe hebben we altijd ID's als PK gebruikt voor al onze tabellen, inclusief een aantal koppeltabellen indien dat nodig is. Nu is het zo dat Visio "objectified facttypes" omzet naar tabellen waarvan de primary key opgebouwd is uit soms wel 2 tot 3 Foreign Keys met extra info. Bijvoorbeeld:

Tabel Projectlid
PK: Persoon (FK), Project(FK), Datum

Op zich geen probleem, ook al is het wel een raar gezicht: het barst van die constructies. Mijn vraag is of dit goed gaat werken met een O/R Mapper zoals bovengenoemde.

Graag geen discussie over het wel of niet gebruiken van ORM.

Mijn excuses voor de lange post

[EfBe]

Die samengestelde PK's zijn geen probleem.

Volgens mij kun je objectified relations wel voorzien van een uniek attribute zodat deze als de PK wordt gebruikt ipv de attributes in de relation.

Zelf zie ik het voordeel niet zo van een artificial PK voor een objectified relation wanneer de attributes in de PK an sig een goede PK vormen: het is immers zo dat wanneer in bv jouw voorbeeld persoon A niet meer op project P werkt maar op project Q, de entity A|P|datum niet meer bestaan kan, want A is niet meer verbonden met P. Dus een nieuwe entity moet worden aangemaakt: A|Q|datum.

Dan een extra attribute toevoegen puur voor de PK lijkt me dan overbodig, temeer omdat de PKs van persoon en project niet wijzigen.

[Verwijderd]

EfBe schreef op woensdag 04 juli 2007 @ 13:36:
Volgens mij kun je objectified relations wel voorzien van een uniek attribute zodat deze als de PK wordt gebruikt ipv de attributes in de relation.

Dat kun je inderdaad proberen te forceren door in de object type list achter de objectnaam een ID in te vullen, maar de rest van de interface blokkeert dit (zover ik heb gezien). Het genereren van een Logisch schema aan de hand van een ORM model in Visio werkt dan ook niet meer. Nu kan dat ook zijn omdat de predicaten nogal wat ã ç á en andere zut bevat (dat schijnt hij ook niet leuk te vinden) dus helemaal zeker weten doe ik het niet.

In onze databases wordt bijna nooit wat verwijderd overigens; omwille van het bijhouden van een historie. Het kan dus zo zijn dat iemand in een project wordt gezet, eruit gaat en daarna weer erin gezet wordt. Vandaar dat de datum deel uitmaakt van de PK. OM aan te geven waneer de persoon niet meer tot het project behoord, heeft de objectified relation een value die dat aangeeft. Daarnaast kan een persoon deel uitmaken van meerdere projecten.

Maar goed, ik zie dat je de maker bent van llblgen pro, dus het stelt me erg gerust dat het dus allemaal geen probleem zal vormen Bedankt voor je antwoord!

[EfBe]

Voor het gebruiken van soft-deletes (het niet verwijderen van records maar ze als 'delete' markeren zodat ze in de table blijven staan) zou ik toch een archive catalog / schema gebruiken en een trigger. Dus wanneer je een record verwijderd, dat de delete trigger deze eerst copieert naar de archive catalog, zodat je daar je historie data hebt en je werkset voor je applicatie gewoon klein blijft. Anders loop je tegen het fenomeen aan dat je table miljoenen rows bevat maar je effectieve werkset maar, zeg 20.000 rows bevat, wat het geheel trager maakt (en de queries complexer). je historie overzichten kun je dan op je archive catalog draaien.

[Verwijderd]

Bedankt voor de tip!