hey, what are the steps to make a datamodel (and the database)?? i read in one of the past posts (of nuno:)) this three steps: 1) Model the problem domain using UML and generate Classes (use Together Control Center) 2) Model the database using ORM (or simple
Extended ERD) and let Visio generate the DDL 3) Define the O/R mappings that best fit my UML model with the ORM Model. - if you want only to create a datamodel/Database (not an application)... which models of UML do you need to find the requirments for the
new model?? - if read ready about ORM's../ it soubnds great.. but did someone here have experience with ORM's?? what's better? ORM's of using ER's - what do you do here exactly ?? cause i think the attributes in the UML classes will be the same as the attributes
of the entities in the ER? thanx! Tarek
Bluemagics Weblog: "I'll always make your dark sky blue!"
"- what do you do here exactly ?? cause i think the attributes in the UML classes will be the same as the attributes of the entities in the ER?" Humm, they may not be the same. For instance if you have an attribute/property Total in the UML most probably is
a calculated field (this are called in ER as calculated fields). Its value does not end in the database. If you already have your UML model completed then use your UML model to derive the ER model. If not, and you don't careless about UML just define your
database model using ORM some other data modeling language. Now the steps required to define a ER model, or any data model for a fact I have are more or less the ones set for UML. That first find the main entities, set their data attributes and relationships.
In ORM this relationships are called facts. ORM is a great tool for data modeling as inherinhantly checks coherency errors. Enjoy, Nuno PS: If you only care for the data model use ORM. If already have an UML model with business entites that need to be persisted
or any other documentation use it to derive your ORM Model. The programers benefit of ORM is that automatically generates the DDL, that is the code required to create the database. So you choose, either you write your DDL using T-SQL or define your DDL using
ORM.
thanx nuno... i'm a starting a new project,.. en want to make the data-modelling proces this time better... :Humm, they may not be the same. For instance if you have an attribute/property Total in :the UML most probably is a calculated field (this are called
in ER as calculated fields). Its :value does not end in the database. sorry... i was totally wrong:D I will try to use ORM's.. the only problem is that are getting TOO Large:S another question. the object's in ORM source model.. do they represent a class or
entity? or only a entity with an Primary key but no other attributes?
Bluemagics Weblog: "I'll always make your dark sky blue!"
Interesting Question, I look forward to some other peoples answers, but what I typically do is not use UML for modeling a database. I don't know why but I find UML not a good tool for modeling a database or maybe I find it cumbersome. Now Yes I use UML for
modeling my application, and get my ideas for what data needs to be stored there. However then I use Visio For Enterprise Architechs, it has a complete Database Modeling tool in there separated from the UML tools. Which is actually a pretty slick tool in my
opinion. I am able to directly push it out from Visio, and set up relations and foreign keys and constraint and rules and stored procedures initial setup I still have to go in and code them. Anyway I find this more usefull for modeling a database than UML.
I can then later go back in and see how changes to the database will affect other things.
"I will try to use ORM's.. the only problem is that are getting TOO Large:S " Yes ORM as the tendency to be larger then any other Modeling Languages. As you probably have noticed ORM takes a deeper look into what is commonly called enity attributes or class
properties then UML or an ER Diagram (as exposed by SQL Server Administration Tool for instance). So if on average you have 6 attributes per entity, in a model of 10 entities you will get more or less 60 distinct objects in the diagram, wether in UML you only
get 10 Classes, and in ER you get probably a little more but not that much. Having said this, is fairly straight forward to find which are concrete business entities and what are attributes of those entities in ORM. Say a Customer and its Name, and a Customer
and their Order(s). This can be spoted if you have an Object A that participates in a fact with Object B that in turn partcipates in a fact with Object C. What basically this means is that A and B will be classes and C might be simply an attribute of B (if
it does not participate in a fact with some other object X). But if you have an Object A that particpate in a fact with Object B and B does not participate in any other facts then B is most probably an Attribute or a Value. Also Objects that are concrete business
entities usually have keys associated. "do they represent a class or entity?" The common is that Objects in ORM either represent a Table or an Attribute (they might represent a Value). Much the same way as in UML you don't think about classes when doing the
model, you think first how objects can be represented. In other words you think about Object Representations, What happens in fact is these Object Representations can become classes or value types in case of OOM or Tables and Value Types on ERM. But there
is a more or less direct translation between ORM, ER and UML where ORM is the most expressive in terms of Data Modeling so it is quite abvious a wee bit of information from ORM to ER or from ORM to UML but in the later you might get new information. In the
other side from UML to ORM you loose some information but also you might gain some (non of them is an encompassing solution for modeling the domain, some things are just easier to write on text and code) Enjoy, Nuno
Thanx nuno & BOUND4DOOM, I decided to use the database diagram as it is in visio.. cause i have 30 entities now, and an average of 5 attributes/entity.. I'm affraid to lose the view if i use ORM's. (30*5=150! I have only an A4 printer:-) and now about the problem
domain and how to analyse it.. In uml you have read the "case/story" of problem.. and then search for class candidates etc... will it also work for databases to write problem in text as a case/story? and then search candidate entities? thanx again:)
Bluemagics Weblog: "I'll always make your dark sky blue!"
"cause i have 30 entities now, and an average of 5 attributes/entity.. I'm affraid to lose the view if i use ORM's. (30*5=150! I have only an A4 printer:-)" It is a decision. But remember that usually people group the Object Representations in multiple views
each mapping to a case/story. What this basically means is that appart for certain situations you don't actually need an overall view, it is far better to look and small parts of the diagram then the overall. This is for ORM, ER Diagram or an UML Class Diagram.
"will it also work for databases to write problem in text as a case/story? and then search candidate entities? " Sure. But look, if you already have your UML Model done then you already have your entities right? So what you need is to map those Entities/Objects
to tables. If you don't have and UML Model of the Problem Domain then yes you need to decide how the business entites wil be represented in the Model. For instance. The Entity Customer, how will it be represented (which attributes should it have), is it assocaited
to an Order? and so on and so. Basically you read your use case/text and decide which are the entities that need to be represented. The ER, ORM or UML are just languages used do model entities (they don't help you finding entities required but help you search
for them. Your documentation around the problem domanin does help you finding them becouse they are there somewhere, in doupt ask the Domain Expert (Client or yourself). Nuno
I have worked a lot of my life with modelling and case tools. What I have found is that people focus too much on the theory of designing system rather that on the practical implementation. My experience has shown that where projects are driven by theories that
only a few understand, failure is inevitable. Focus on one thing when creating a diagram, (whether it be for a database or an object structure) keep it simple and understandable. Remember that a lot of different people from Business Users to Programmers will
be using these diagrams to approve/create the solution. If they don’t understand them it ain’t going to happen. I find the most useful diagrams (that most people can read and understand) are the Entity Relationship Diagram (ER, ERD) and a simple top down Functional
Decomposition (like an organisation chart). These do not describe object models but go a long way to describing the deliverable functionality and associated data structures. Often with smaller systems, this is enough. This basis can then be expanded into UML,
Data flow and all the other relevant information to detail the specific areas of the solution. I do agree that people should have a general understanding of the different methodologies and techniques and I don’t what any theoretical arguments about the different
techniques and why they are better.
> what are the steps to make a datamodel (and the database)?? i tackle this in a rather different way to nuno. 1) define my object model. my database is then automatically generated from this by my object framework (o/r mapper).
no i know where to start, by just wirting down all the requirments on paper. I have tried some options where to begin and wich steps i have to do to get a good DB.. In most cases you will get crazy by the "papernoise" of all diagrams and requirments reports
& lists.. I think the best way is to make a small solution that works, and then extend it.. it's just an iteration of the next steps step 1: analyse/define step 2: implement/design step 3: use/test when you get this done, just start again by step 1 and redefine
the requirments.. The only problem is that some times you will be unsure about the project ..if the requirments change after each iteration.
Bluemagics Weblog: "I'll always make your dark sky blue!"
Bluemagics
Participant
1955 Points
391 Posts
Datamodelling
Nov 04, 2003 04:08 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Datamodelling
Nov 04, 2003 05:04 PM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: Datamodelling
Nov 04, 2003 07:48 PM|LINK
BOUND4DOOM
Member
537 Points
109 Posts
Re: Datamodelling
Nov 04, 2003 08:21 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Datamodelling
Nov 04, 2003 11:21 PM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: Datamodelling
Nov 05, 2003 09:15 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Datamodelling
Nov 05, 2003 09:37 AM|LINK
CSamp
Member
130 Points
26 Posts
Re: Datamodelling
Nov 26, 2003 02:42 AM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Datamodelling
Nov 26, 2003 06:21 AM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: Datamodelling
Nov 26, 2003 01:55 PM|LINK