A former student asks:
.. I took your class last
spring and am currently in talks with some companies for a junior database
position. I find it a little challenging
when it comes to talking about exactly what I learned in your class as we
covered a lot of much valuable information. If you have any input for a quick
way to describe all of the information I learned that would be very helpful.
EVEREST REPONDS:
ReplyDeleteWhat I have begun to realize is that we are not modeling data. So it is a little misleading to call it "Advance database design."
Some people distinguish database design from data modeling. Database design is at a much later stage physical design when implementing a database in a particular DBMS. Data modeling is much more of what we are about.
But that too is misleading since we are not modeling data we are modeling some part of the world of interest to a community of users, i.e., we are modeling the business. In particular, we are modeling the "things and events" in the users world (as opposed to the business or operational processes). So we might think of ORM as a better, more comprehensive way of modeling the business than the traditional ER/Relational modeling.
In ERel modeling, we start with only the major entities, then immediately build a table for each entity to contain all its attributes. To do so means we have already determined the characteristics of the relationship of the attribute "object" to the entity. We jump into tables prematurely I call that "Table Think."
ORM is distinguished by modeling in the following sequence:
1. Objects (not trying to distinguish entities from attributes at the outset)
2. Relationships among objects (including all the "attribute" relationships)
3. Relationship characteristics, in particular, multiplicity/exclusivity)
Only then are we ready to put attributes into entity tables. This stems from a fundamental understanding of what is meant by "attribute." AN ATTRIBUTE IS AN OBJECT PLAYING A ROLE IN A RELATIONSHIP WITH SOME (OTHER) OBJECT. Furthermore, since we have defined all the functional dependencies in 2 and 3 above, we can be assured that the resulting table diagram is fully normalized. The good news is that with the use of an ORM modeling tool, we can build the tables automatically from an ORM diagram. Thus, we never have to worry about normalization.
In the course you learned, not only about ERel and ORM but also:
- How to model using subtype/supertype constructs (useful in ERel and ORM modeling)
- How to conduct data modeling project meetings to elicit data requirements from the users.
- How to document and present a data model diagram to people so they can understand it.