But I suspect that many developers really don’t care about the first two, and the first is useful only in system-level architectural/rough design documents. This approach also has the advantage of providing a documented record of the db from the design through to the schema.įootnote: I cannot help but add that I do not see how a db can be designed and created without first having that essential bird’s eye view of the E-R - I actually do prefer to start with a conceptual model, then work my way down to logical and physical models. We have found it to be quicker, and easier, to create the text scripts first and then run them in the DBW to create the schema, rather than use DBW directly from the EAR model. Schema: created from the SQL scripts via Database Workbench (DBW). Text processor for the documentation (not necessarily a WP), and for creating the SQL scripts. Tools: any simple drawing tool for the E-R diagram.
#Youtube videos using toad data modeler with inheritance code#
I cannot stress how important an E-R diagram is: the whole of the db structure is there and displayed succinctly, the relationships being the links which form the logical structure which eventually forms the foreign key structure of a relational db.ĭata sources: the original data can come from vaious places: Excel spreadheets are common, various type of files, and even program code of an app containing SQL queries. The diagram is used as a map including 1:m, optional, mandatory participation but no attributes. including 1:m, optional, mandatory participation.Į_R diagram: this is a must! This is a most useful piece of documentation you could ever have for a database: a bird’s eye view of every entity, and its relationship and participation within the whole db. Outline: a brief one paragraph statement of the nature of the db, its purpose and its objectives.ĮAR Model: always used: Entity-Attributes-Relationships stated in English and normalised to at least 3NF – Lists of Entities, Attributes, and Relationships, eg. It has much improved since I first used it back in Version 4, but I still think it has a long way to go.Īs providers of customized databases for SMEs we use the following approach – which always uses modelling. On my current project we’ve been mandated to use Erwin 7.3. At the end of the project I was starting to play with Oracle’s SQL Developer, which looked promising. Most developers work from the DDL or describe or PL/SQL Developer or TOAD because they know that the model could be out of date.Īs to tool … I’ve used Nastec’s DesignAid (this was back in 1984), System Architect, Erwin (around V4), and Oracle Designer, and on my last project I wrote my own transformation tool to convert logical model diagrams in Oracle Designer to a set of DDL scripts because I thought the Designer transformation was lacking in many areas. No attempt has been made to change the computerize to natural language, no attempt has been made to normalize the resulting models, and supertypes/subtypes? Yeah, right. Most of these logical models are, IMHO, next-to-worthless, since they’re nothing more than the physical model with a “logical” label applied to them. Those models were then reverse-engineered into logical models. On this contract we inherited a bunch of nothing and had to reverse-engineer physical models - and there are MANY of them, because each little application has been defined in production with its own schema, if not its own instance. On other contracts we created logical models (well, changes to THE logical model), transformed them to physical models, then ran those results through the DBAs for storage clause adjustments and the like. I’m assuming a broad definition of model here: not just the diagrams and pictures, but also the narrative descriptions that go with them. Some choose to skip data modeling entirely, or to do only the physical modeling (often reverse-engineering a model from the database so there is a “”picture”” of the database).ĭo data architects create physical models? logical models? conceptual models?Do SQL users and developers work from a data model?What do you recommend?As an aside, if you do data modeling, what tool(s) do you prefer? In some cases, the models fall out of use to the point that they become obsolete. Data modeling is an important part of defining the database initially.īut many users and developers ignore the models when they actually construct their SQL queries and applications, preferring to look at the actual database - either the DDL or a “”describe”” command. Data modeling generally comes in three “”tiers”” or levels - conceptual, logical and physical data models.
0 kommentar(er)
