 | |
#11
 
| |||
| |||
|
Re: is ER modelling a waste of time? -
12-05-2003
, 01:23 PM
|
I agree with both Jawn and dataman. But, I can tell you that sometimes, what seems to be something that can easily be designed directly as a relational schema (skipping the ERD), can come back to bite you. The ERD helps you see relationships in the data that you may miss otherwise. In our case, we missed that there was a specialization/generalization. We had to rebuild. It is cheaper to do it right the first time than to go back and rebuild after you found that something doesn't work the way you need it to. Coming at it from a non-relational bias ... :-) |
There are two types of relations. There is the relationship of an
attribute to its entity - which MUST (in relational dbs) enforce
cascading deletes, referential integrity etc etc, and a relationship
between entities. Enforcing integrity here is likely to be (but not
always) a mistake, eg making a db demand a valid entry in the "is spouse
of" field :-)
In short, the table(s) making up an entity view MUST have enforced
integrity, links between entities may or may not require integrity, or
indeed may require non-integrity.
Quote:
|
"John" <?> wrote in message news:3fcee2f7$0$14053$fa0fcedb (AT) lovejoy (DOT) zen.co.uk... I was taught about ER modelling at University but found it to be a pointless abstraction, preferring to just write down the schema directly. What does the group think of ER modelling as a design approach, and what alternatives do you use? John Cheers, |
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett
#12
| |||
| |||
|
|
"dataman" <dataman (AT) ev1 (DOT) net> wrote in message news:vsv181b4k0269 (AT) corp (DOT) supernews.com... "John" <?> wrote: I was taught about ER modelling at University but found it to be a pointless abstraction, preferring to just write down the schema directly. What does the group think of ER modelling as a design approach, and what alternatives do you use? John I don't view it as a waste of time. I've not found a better way to identify dependencies in data than logical data modeling. You may have confused logical data modeling with database design. " They're really two different things. " Maybe that's the issue. The data modelling bit seems plausible to me, and I am happy enough drawing the diagram. I am also happy enough designing a database, it's just that when I am doing E/R modelling, I find myself trying to second guess the abstraction in order to ensure that the eventual relations are sensibly defined. When I'm using it in that fashion, it does seem pointless. Date (IDS), for example, sees the E/R model as a "set of informal concepts", while "relations are formal objects, and the relational model is a formal system". He also (sensibly) suggests that when Codd constructed the relational model, the "useful semantic concepts" he was using were "basically ... those of the E/R model". This view seems to support my belief that E/R modelling is fundamentally informal, something which questions its very status as a *model*. Perhaps I just have problems with informal / wooly / subjective things. I suspect that's why I'm a computer scientist rather than an artist! John Lots of folks do find documentation pointless. In fact some found it so |
Then, make the business folks sit next to the programmer so nothing ever
need writing. If you subscribe to this camp (XP) then you're right. Documenting
the business semantics in a data or process is a wholehearted waste of time.
I don't subscribe to that camp and I believe that documentation in the form
of data (and process) models adds value to the organization and as I am responsible
for maintaining those rules benefit daily from that documentation.
#13
| |||
| |||
|
|
"John" <?> wrote I was taught about ER modelling at University but found it to be a pointless abstraction, preferring to just write down the schema directly. Me too. An ER drawing is not a complete database design like a ground plan is not a complete building design. A database design include many aspects (integrity constraints, derivation rules) that an ER drawing can not express. What does the group think of ER modelling as a design approach, and what alternatives do you use? I create the logical database design using written Tutorial D. You can accompain the logical database design with one or several ER pictures for clarification purposes, but the ER pictures are only pictures. A picture is only one part of a physical data model using a tool like ERwin. |
you choose to enter it). That includes integrity constraints and derivation
rules.
#14
| |||
| |||
|
|
You can accompain the logical database design with one or several ER pictures for clarification purposes, but the ER pictures are only pictures. A picture is only one part of a physical data model using a tool like ERwin. You also have all of the associated meta data for that data model (assuming you choose to enter it). That includes integrity constraints and derivation rules. |
Is the language relationally complete?
Regards
Alfredo
#15
| |||
| |||
|
|
"dataman" <dataman (AT) ev1 (DOT) net> wrote You can accompain the logical database design with one or several ER pictures for clarification purposes, but the ER pictures are only pictures. A picture is only one part of a physical data model using a tool like ERwin. You also have all of the associated meta data for that data model (assuming you choose to enter it). That includes integrity constraints and derivation rules. Using which language? Is the language relationally complete? Regards Alfredo |
From Oracle 9i to MS Access. Perhaps some investigation into the functionality
provided by today's data modeling tools would be beneficial.
http://www3.ca.com/Solutions/Product.asp?ID=260
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.