database-developmentdiagrams
I've been handed the ER diagram for a quite complex database.
Complex to me at least, 849 tables. One of the architects says to understand the code, you need to understand the database and relationships.
Now I am basically a Java programmer hence not too familiar with this
How do I start? Should I start from something basic like USER or ORDER and see which relationships they have with other tables around them?
Any tips or tutorials would help a lot
I'm not sure of the names of the diagrams, but generally know what you're talking about.
At the Tech School I first went to and the CIS dept of the University in the business school (where I took one DB class) we used crows foot notation, which makes a lot more sense to me.
In the CS dept, I was taught by a very experienced DB prof who used the diamonds for his ER diagrams - but he didn't care if we used some other notation for our assignments (we didn't do a lot of diagramming in that class, not nearly as much as in the CIS class at least)
In practice, having a number next to the diamond is well and good, but totally pointless. What you prefer probably comes down to who first taught you. I'd reckon if you say ES Queue Ell you probably use crows foot ER diagrams. If you say Sequel, you probably use the diamonds. And if you just call it a database, you probably don't use diagrams.
Also, datatypes aren't supposed to be captured at this level of database design. In my CIS classes at least, once we got to that point, we'd write the table structure out in a text file. Then it's just 2 steps away from an SQL create statement.
MS Visio can turn your diagrams into databases (and vice versa) so that method of diagramming ought to capture the info you want, although I've found it to be fairly cumbersome to use and I much prefer to just use Dia.
UML: Sequence Diagram Tutorial
The data is included as the parameters within the messages. For example the instance buyersBank of the Bank class takes an accountNumber and returns the balance for the buyersBank instance.
Update:
I have highlighed the key points from the OMG specification. pg 491-494
<messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument>[‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’
Examples of syntax:
mymessage(14, - , 3.14, “hello”) // second argument is undefined v=mymsg(16, variab):96 // this is a reply message carrying the return value 96 assigning it to v mymsg(myint=16) // the input parameter ‘myint’ is given the argument value 16
Where:
v = attribute mymessage = signal-or-operation-name (16,vairab) = arguments :96 = return value
Note:
Visual Studio 2010 Ultimate will auto-generate sequence diagrams. You can reverse engineer existing methods by right-clicking and selecting auto-generate sequence diagram.
Best Answer
An ER Diagram is out there to visualize a design, which was made to accomplish a certain job. Understand what the job is first, then ask questions to the diagram.
"How is an order stored?", "How do I retrieve user information", "How can I tell which user ordered a certain product between these intervals and with these options?". Such questions might help you understand the design. If there is a requirements analysis documentation, it will help you a lot with coming up with these questions. You can explore how certain requirements are handled.
I suspect that a database with 849 tables is highly normalized so most of those tables might be lookup tables which does not have much effect on the relationships of the entities. Try to focus on the parent tables holding keys to those lookup tables.