class-diagramdatabaseuml
I have an assignment for developing a hotel reservation system!
One of tasks is to develop UML class diagram! However, in the task description it is written
"Class diagram should represent your database"
I am a bit confused about the rules, notations and etc… because I can't find any official UML class diagrams specifically for databases!
Could you help me please?
My favorite answer is as what the first sentence in this thread suggested. Use an Adjacency List to maintain the hierarchy and use Nested Sets to query the hierarchy.
The problem up until now has been that the coversion method from an Adjacecy List to Nested Sets has been frightfully slow because most people use the extreme RBAR method known as a "Push Stack" to do the conversion and has been considered to be way to expensive to reach the Nirvana of the simplicity of maintenance by the Adjacency List and the awesome performance of Nested Sets. As a result, most people end up having to settle for one or the other especially if there are more than, say, a lousy 100,000 nodes or so. Using the push stack method can take a whole day to do the conversion on what MLM'ers would consider to be a small million node hierarchy.
I thought I'd give Celko a bit of competition by coming up with a method to convert an Adjacency List to Nested sets at speeds that just seem impossible. Here's the performance of the push stack method on my i5 laptop.
Duration for 1,000 Nodes = 00:00:00:870
Duration for 10,000 Nodes = 00:01:01:783 (70 times slower instead of just 10)
Duration for 100,000 Nodes = 00:49:59:730 (3,446 times slower instead of just 100)
Duration for 1,000,000 Nodes = 'Didn't even try this'
And here's the duration for the new method (with the push stack method in parenthesis).
Duration for 1,000 Nodes = 00:00:00:053 (compared to 00:00:00:870)
Duration for 10,000 Nodes = 00:00:00:323 (compared to 00:01:01:783)
Duration for 100,000 Nodes = 00:00:03:867 (compared to 00:49:59:730)
Duration for 1,000,000 Nodes = 00:00:54:283 (compared to something like 2 days!!!)
Yes, that's correct. 1 million nodes converted in less than a minute and 100,000 nodes in under 4 seconds.
You can read about the new method and get a copy of the code at the following URL. http://www.sqlservercentral.com/articles/Hierarchy/94040/
I also developed a "pre-aggregated" hierarchy using similar methods. MLM'ers and people making bills of materials will be particularly interested in this article. http://www.sqlservercentral.com/articles/T-SQL/94570/
If you do stop by to take a look at either article, jump into the "Join the discussion" link and let me know what you think.
Use-case diagram is usually used for representing the business of the project, indicate who(actor) are going to utilize the system and what services(cases) does program provide?
The class-diagram is used for specifying the whole system structure, but there no code and exact behavior will be provided by the class, generally developers don't specify the exact behavior with each module in-detail.
for example, consider a simple login module. in use-case diagram, we just mention that user logins into the system.
In class diagram we specify the possible base classes are needed, in other word we apply the architecture (we are planning) basis.
In sequence diagram we focus more on what is going on each method(while this is not necessary).
In fact UMl is used for representing the system as abstract, not the exact(in-detail) functionality.
for example I pass the above class-diagram to a developer, and tell him about the detail login process as a separated document.
Best Answer
Yes, the latest UML standards threw off the data diagram. Nowadays Entity Relationship Diagram is NOT the part of UML. But the Class diagram still is there in UML and it will be enough.
Simply make a usual class diagram. The only difference is that you shouldn't use n-to-m dependencies, instead make a new class between the ends and you'll have n-to-1 and 1-to-m dependencies instead. Such class diagram can be realized in a database. For better understanding in every class you can set an attribute id to be used in the DB later.
The other thing for such class diagram is that you need not to describe any methods - they don't belong to DB tables. But in the reality you need them - so, I'd create one easier diagram - with instantiable classes and without methods, and the other, more thorough - that one will include also abstract classes, interfaces and methods.
Also, on the first one you needn't put classes that belong to the UI - classes, that show your data and edit them.