Designers Must Do the Modeling {2}

by Asim K

In his article Designers Must Do the Modeling, which was published in IEEE Software , Volume 15 Issue 2, Brian Lawrence enunciates on the fact that designers for database, or any other project, must do the modeling. Lawrence defines the stepping stone as figuring out the customer’s problem rather than figuring out requirements for the project. In his logical breakdown, Lawrence cites ERD models as only an output of the requirements process which will dictate database  design later on in the process. He pursues this opinion with another, saying that producing the ERD diagram (or whichever type of diagram you may be working with) has the benefit of allowing ourselves to understand the customer’s problem better so we can design better solutions. Because the designers have to produce the requirements model, Lawrence embraces the not-so-popular opinion that the designers themselves are the owners of the model.  Citing a quote by Dwight Eisenhower, the author embraces the planning process over the actual plan. To further reinforce this statement, Lawrence says that managers must help persuade designers to understand that they must model requirements – no matter if the designers see it as their duty or not. Similar to the statement of “Learning by Doing”, Brian Lawrence embraces a brilliant model in saying that it is during the planning phase that we learn the most, not in the implementation of the plan. Personally, I agree with this worldview because I have experienced the  same euphoria myself. When I was younger, around 11 or 12, years old I would sit down to learn HTML as a hobby (yes, HTML was my hobby). Although my websites churned out to look like absolute trash and functioned on a pretty depressing level, in the process of research, working with clients, figuring out bells and whistles, I was able to generate a more holistic understanding  of what I was learning and still retain that knowledge today. On these terms, I agree that the designers – the individuals who actually work with the client to figure out their problems and solve them – are the people who should create the requirements needed for their projects; in our case: a databaase. Lawrence, B. (1998). Designers must do the modeling. Software, IEEE, 15(2). Retrieved from http://0-ieeexplore.ieee.org.opac.library.csupomona.edu/stamp/stamp.jsp?tp=&arnumber=663782.

ER or UML? {4}

by Andrew H
For this weeks blog I read an academic journal by James Suleiman and Monica Garfield called, “Conceptual Data Modeling in the Introductory Database Course: Is it Time for UML?.” The article talks about what type of data modeling schools are using for their introductory database courses. The answer has proven to be E-R modeling even though the article states that UML could possibly be the better style. The authors say, that a lot of programs use Object-Oriented (OO) methodology which embraces UML, therefore UML would be a good approach to teach as most students are already accustomed to it after a few programming courses. They believe as a result that there should be further discussion and teachers should press for teaching the UML way that way everything is more uniform and students can get a more comprehensive understanding of the material. read more...

UML Diagram for Rookie {1}

by Jamal A
A picture worth a thousand words, but it worth way more than that when creating a UML Diagram. UML is a graphical modeling language, and it represents a class as a rectangle with the class name inside. I usually think of it as a box full of stuff.  The author in this article, talks about how UML class diagrams are very good for interconnecting the overall structure of classes and the dependencies between them.  However, In a UML class diagram it is somewhat easier to see whether one class inherits from another class, or it just simply holds the reference to another class.  According to the article, “Diagrams make certain dependency structures visible. We can see dependency cycles, and determine how best to break them. We can see when abstract classes depend upon concrete classes, and determine a strategy for rerouting such dependencies”. Next, the authors Robert C. Martin talks about the associations between classes that are most often represent instance variables that hold references to other objects. read more...

Basics of An ER Diagram {Comments Off on Basics of An ER Diagram}

by Jamal A
The article I read talks about how important it is to create an ER Diagram, and how it should be
the starting point for software development projects. According to the article, “The very first step to
create an ER Diagram is to identify the nouns (entities)”.  For example: Company, Employee, and Project.
The article explained how ER Diagram “transmits a lot of information with a very short notation”.
There are some important signs to remember when creating an ER Diagram, For example:
Zero through Many (crow’s feet, O), One through Many (crow’s feet, dash), One and Only
One (dash, dash), Zero or One (dash, O). These are some of the symbols used when creating an ER Diagram.
The article also over viewed the three relationship types and explained how they are used.
These are: One to Many, Many to Many, and One to One. It went in further detail about these relationships
and explained which the most common relationship types are. read more...

Modeling the Extension of an ER Diagram {Comments Off on Modeling the Extension of an ER Diagram}

by Ahlyzik M

When solving a design issue with the business rules, Entity relationship diagrams are used to consolidate given objects in the business process. The author discusses the concepts of the deeper level of taxonomy in database design, otherwise known as an Enhanced Entity Relationship diagram. The weaker entities are known as a subtype which is to indicate that the entity is an extension of the main entity called the super type. This is the design standard used when categorizing a group of individuals or entities in a hierarchical fashion. Disjoint constraints are used to identify whether the entity can be a member of one or more subtypes in the super-subtype relationship. read more...

Importance of Data Modeling {1}

by Peter C

According to Data Modeling isn’t Dead article, it said that data modeling is very important. In the early 1980s, data modeling was very important because it was used for most project development. In order to create a business, data modeling was necessary because it was used as an outline. Just to start the company, it will need entities, relationship, and primary key. The best way to start a data modeling will be to create an entity relationship diagram. That will let the people see how the company is supposed to be run.  This is the most important model because it will show a complete picture of the operation. However, this is very time consuming which is why not every enterprise will use it. Not a lot of company would want to spend a ton of money on using this model which gives data modeling a bad name. read more...