Tool om relaties binnen een db weer te geven

[Yucon]

Ik zoek een tool om tabellen in een database weer te geven. Wat ik graag wil

- weergave op basis van een losse datafile waar de structuur in staat
- ondersteuning voor grote databases van enkele duizenden tabellen
- inclusief weergave van de sleutelverwijzingen. Dus niet alleen een lijntje maar concreet welke velden gekoppeld zijn

De wens om een databasestructuur te tonen is niet uniek. Internet staat er vol van en ik heb al een aantal dingen gevonden, maar allemaal net niet.

Bijvoorbeeld:
https://sualeh.github.io/SchemaCrawler/diagramming.html
https://www.mysql.com/products/workbench/design/
https://github.com/ondras/wwwsqldesigner

Deze tools zijn heel handig maar ze doen toch niet wat ik wil. Plaatje voor het idee:



- wat betreft filosofie zijn ze gebouwd om iets op een denkbeeldig stuk papier te printen. Ik zoek iets 'virtueels', kortom op een manier dat je als het ware door de structuur heen kan browsen, doorzoomen etc. De structuur erg groot en je hebt weliswaar altijd een subset nodig.. maar wel steeds in wisselende combinaties waarvan vooraf moeilijk in te schatten is waar de grens loopt.

- er zitten helaas geen referentiele sleutels in de tabellen. Alles zit in de code _{laten we die discussie even parkeren want dat gaat niet veranderen}. M'n vraag is dus ook database onafhankelijk want we moeten uiteindelijk toch een databestand op gaan bouwen waar die structuur wel in zit.

Dan heb je nog tools zoals gephi (https://gephi.org/) die met name gericht zijn op het tonen van een netwerkstructuur. Dit lijkt heel geschikt. Waar dit nu weer op vast loopt is dat ik niet alleen de relatie tussen twee tabellen wil tonen maar de manier hoe de sleutels aan elkaar gekoppeld zijn. Je kunt dus tussen twee objecten twee lijntjes parallel aan elkaar hebben lopen.

De reden dat ik dit graag wil is omdat we bij het maken van technische ontwerpen voor rapporten te veel tijd kwijt zijn om dit soort relaties te bepalen. Heeft iemand een goede suggestie wat geschikt zou zijn?

[P_Tingen]

In wat voor omgeving moet het draaien? Ik kan me nml voorstellen dat het een stuk eenvoudiger is wanneer je tool aansluit bij de database waar het op moet draaien. Zo zou je bv alleen al het metaschema in kunnen lezen als tool en db bij elkaar passen. Scheelt je in ieder geval alweer een stap. Daarnaast: als je dan uitbreidingen maakt, kan die tool wellicht ook de tabellen voor je toevoegen.

Dat zeggende heb ik niet direct een oplossing voor je. Wij hebben op het werk wel eens gewerkt met yEd (https://www.yworks.com/products/yed). Dit is een gratis tool die er best goed uitziet en waarmee je - als ik me goed herinner - ook op verschillende niveaus van abstractie schema's kan maken en daarbij inderdaad kan 'doorklikken' naar lagere niveaus. Ik hou hier wel even een slag om de arm omdat het al een paar jaar geleden is dat we er mee aan de slag waren en ik er toen ook al niet heel uitgebreid mee gestoeid heb. Ik heb het toen voornamelijk als veredelde tekentool gebruikt.

[Yucon]

@P_Tingen Het gaat om sql server met daarop dynamics ax.. Dat yEd ziet op het eerste gezicht wel interessant uit.. ga ik morgen eens mee aan de slag.

[Will_M]

Aangezien je "Dynamics AX" al noemt ga ik er vanuit dat je van MS SQL gebruik maakt (SQL is er in vele varianten)? Is de standaard Reporting Services geen afdoende optie voor je?

[Yucon]

@wimmel_1

dat klopt. We gebruiken SSRS trouwens ook, maar dit is niet waar het probleem zit Waar het om gaat is dat bij AX de sleutels in de code zitten. Als je een spec voor het bouwen van een rapport of query wil definieren is het steeds behoorlijk wat zoekwerk om de juiste referenties boven water te krijgen. Je hebt bijvoorbeeld dit soort documentatie: https://msdn.microsoft.com/en-us/library/inventtable.aspx. Het is wat onhandig om steeds uit een lap tekst iets te halen wat je grafisch veel handiger inzichtelijk zou kunnen maken. En los daarvan zie ik mensen steeds opnieuw hetzelfde opzoeken en dat is behoorlijk inefficient.

Daarnaast is er iets fundamentelers. In de 15 jaar dat dit werk doe zie ik twee bewegingen. Het ene is dat functionele mensen brakke, technisch niet concrete ontwerpen over de schutting gooien en het de programmeur maar uit laten zoeken. Het andere is dat programmeurs eisen dat functionele collega's de complete query zo ongeveer in tekstvorm uitschrijven. Welke van de stromingen de overhand heeft hangt een beetje van het bedrijf af, maar beide vind ik niet optimaal omdat het aan een van de twee kanten niet efficient is.

Wat naar mijn mening wel werkt is dit; functionele (key)users/consultants/applicatiebeheerders met enige technische affiniteit definieren het rapport. Daarmee maken ze ook al de vertaalslag van schermen naar tabellen incl sleutelverwijzigingen, groeperingen etc. Dat kun je prima van zo iemand verwachten en een programmeur kan met dit in de hand relatief snel het rapport bouwen omdat de omschrijving 100% duidelijk is.

Om dit te laten werken moet je wel een methode hebben om het die functionele mensen zonder veel zoekwerk heel duidelijk de referenties te laten vinden. Enerzijds omdat die sleutels het voor de programmeur veel makkelijker maken en bijvoorbeeld het verschil tussen inner en outer joins belangrijk is voor een heldere rapportdefinitie. Maar ook omdat het veel te makkelijk is een bepaalde connectie over het hoofd te zien wat weer vragen of rework oplevert.

Het gekke vind ik dat men het eigenlijk wel normaal lijkt te vinden dat het relatief veel werk kost om duidelijk inzicht in tabelrelaties te krijgen. Volgens mij is daar veel verbetering mogelijk.

[Will_M]

Best grappig eigenlijk. Vanwege zo'n gelijksoortig "issue" heb ik afgelopen week wat discussie/overleg gehad met een aantal mensen op m'n werk waarbij ik een aantal database's (beperkt) open ga stellen voor een benadering vanuit Splunk

[Yucon]

wimmel_1 schreef op zondag 3 december 2017 @ 20:02:
Best grappig eigenlijk. Vanwege zo'n gelijksoortig "issue" heb ik afgelopen week wat discussie gehad met een aantal mensen op m'n werk waarbij ik een aantal database's (beperkt) open ga stellen voor een benadering vanuit Splunk

Interessant. Het is soms wat lastig door de marketing-PR op zo'n site heen te prikken. Maar begrijp ik goed dat je big data-achtige technieken wil gebruiken voor ehm "niet-big-data"?

edit: ik loop al langer met het idee rond dat er best wat technieken moeten zijn om matches te herkennen, op basis van overeenkomsten van reeksen in kolommen. Je zou zelfs een scriptje kunnen schrijven om dit allemaal door te bladeren op zoek naar matches maar volgens mij is dat een nogal stevige aanslag op je db. Al kan ik me best voorstellen dat er slimmere oplossingen op te bedenken zijn.

[ Voor 26% gewijzigd door Yucon op 03-12-2017 20:15 ]

[Will_M]

Yucon schreef op zondag 3 december 2017 @ 20:05:
[...]

Interessant. Het is soms wat lastig door de marketing-PR op zo'n site heen te prikken. Maar begrijp ik goed dat je big data-achtige technieken wil gebruiken voor ehm "niet-big-data"?

edit: ik loop al langer met het idee rond dat er best wat technieken moeten zijn om matches te herkennen, op basis van overeenkomsten van reeksen in kolommen. Je zou zelfs een scriptje kunnen schrijven om dit allemaal door te bladeren op zoek naar matches maar volgens mij is dat een nogal stevige aanslag op je db. Al kan ik me best voorstellen dat er slimmere oplossingen op te bedenken zijn.

Big Data = Net zo groot als het totaal aan data wat je zélf aanlevert, toch? Nou heb ik wel t voordeel dat we bij m'n werkgever alle *AAS diensten aanbieden aan zowat de hele wereld maar... Ja: 't Komt er feitelijk op neer dat ik "Big-Data-Analyses" wil gaan gebruiken voor wat minder grote data

[Boeryepes]

Erwin? Vroeger veel mee gewerkt, weet niet of het aan al je eisen voldoet.

https://erwin.com/products/data-modeler/