Data modeling

Data Modeling Concepts Everyone Should Know {4}

by Willen L
In this article, the author states that people that work with anything related to databases are often asked by their organization to take on the job of data modeling even though it does not specify it on their job description. With that said, he gives us some basic data modeling concepts everyone working with databases should know.  He states that data modeling begins with understanding the requirements and to use this knowledge as a blueprint to build a physical database. He states that it is important to understand and build a well-designed data model in order to increase value to the organization by minimizing redundancy, maximize data integrity, increase stability, enhanced data sharing, consistency, more timely access to data, and better usability. Without a good data model you will run the risk of missing some important data that can be a disadvantage for the business. He states that it is important to think of “what” is of interest instead of “how”. He leaves off with 3 basic tips that everyone should know. First think conceptual – focus on business issues and terms. Second, think structure, how something is done is not as important as processes being done to. Last, think relational, the way things are related to one another. read more...

The Importance of Data Modeling {1}

by Antonio M
This author talks about the importance of data modeling. He first goes on to say how each table in a data
model expresses meaning. He also says how “the best models reduce the data items within the covered subject area into obvious arrangements. The author talks about how most of the time DBMS can have tools that make quick definitions of tables. Even though this can be a good thing often developers can misuse the data elements to mean something else which can make users even more confused. He further emphasize how data modeling is really important and should always be documented other wise most of the meaning of a database can be inside the code. When it is inside the code it can be harder to refer back to in the future. He goes on to show how if you dont model correctly the first time more time can be spent on post-implementation and trying to solve problems. In conclusion he says that the only time data modeling should not be used is when the developer making the database will be the only person maintaining it. read more...

Understand the Data in Data Modeling {4}

by Penny P
In the article that I read, it said that when you start working on data modeling you’re eventually working on something that will lead to database design. Before data modeling become popular, some people saw data administration and information groups as obstacles because it slowed down development. However, companies soon came to the conclusion that database models can actually serve as framework for new applications to be designed. New applications get created for different tasks while the old ones get integrated with the new. read more...

Data Modeling and Universal Patterns {Comments Off on Data Modeling and Universal Patterns}

by Wendy O

The article that I read appears to be a summary of a book “The Data Model Resource Book, Volume 3: Universal Patterns for Data Modeling.” The article helps define the differences between reusable data models and patterns. Patterns are described to be the core templates that are independent to any particular application. They mainly provide the underlying structure so that modelers can reuse these to build any model. Most commonly used to extend and develop just about any type of data model. read more...

The Imperfections of Data Modeling {1}

by Joey L
The article mainly focuses on how limited data modeling can be for designing databases.  Most often, modelers assume that the knowledge around data modeling is all that is needed to prosper a successful database.  In actuality, a successful database design does not encompass completely from data modeling.  The author suggests that one of the areas where data modeling is insufficient, involves the use of code tables.  Examples of code tables include: “County Code, Product Category, Customer Type and so on.” Many of these tables are unnecessary to implement a database.  Some of the code tables have nothing to do with the database design and should be left out until the system or database goes live and running.   Similarly, indicators such as flags and switches are commonly used in database designs with values like “yes” or “no”, though the representational scheme only embodies design rather than purely representing data.  Another issue that is related to data modeling tools involves specifying if columns are null or not null in data models.  Many ER Tools do not address the requirement; they ask users if an attribute is nullable or not nullable but cannot record if a column must be null under special conditions.  This limits how precisely data from the data model can be in a database design. read more...

Wanted: Database Models {Comments Off on Wanted: Database Models}

by James C

The topic of data modeling has always been hard for students to grasp. Even though the there are many techniques on data modeling, no one standardized method has been agreed on by educational institutions. In order for developers to understand the connections between entities and their relationships they first must study the entity relationship (ER) modeling technique. Despite the effectiveness of this technique, though, many developers, as seen through their work, are still having trouble using, learning, and integrating with it. To add to this dilemma, many developers are also having additional issues with combining the object-oriented approach with the entity relationship modeling technique. This article sheds some light on the subject of which modeling technique is more effective, the UML or ER modeling technique. The debate between the better of the two are is not answered, but rather explored. Both methods having similar issues, like dealing with multi-valued attributes, for example. One real issue that did arise in the end was that database designers and system analysts are in constant disagreement. Both systems analysts and database designers are both comfortable with different ideas. SA’s are at ease with object-oriented programming methods. Database designers are more structured and mathematically centered. read more...

Time to move on to something…better {1}

by Stephen O

When is it time for something new? When is a good time to trade up? Is it similar to buying a smart phone? Waiting for the new model later that year? Is it when the industry chooses a standard like Blue Ray or VHS? On the other hand, is it like buying a car and it no longer can perform reliably the duties we purchased it for? When is it time for us to transition to the next generation of Data Modeling?  In the article “Toward a Next Generation Data Modeling Facility: Neither the Entity-Relationship Model nor UML Meet the Need” the author went about explaining why perhaps it is time to move on towards the next generation of Data Modeling.  They defined five wanted characteristics of a Data model. read more...

Data Modeling the First Step of Database Design {Comments Off on Data Modeling the First Step of Database Design}

by Tuyen H
In the Article “Why you want to be good at data modeling,” (Schumacher, 2011) Robin Schumacher writes about how important of Data Modeling in the design phase of Database. According to his article, many big projects cost many years to complete because of Data modeling and design are not taking serious in overall system development as they should be. Therefore, as database designers, the designers should take carefully first data modeling as the first step instead of physical design. He also recommends that if you carefully work on data modeling step, your physical design and implementation will much more easier. Moreover, a good data modeling will help you on the maintenance later. In conclusion, there are many data modeling tools to help us in data modeling such as Entity Relationship Model and MySQL Workbench, so choose your tools and take seriously on the first step of database design. read more...