The underlying part of all of these, however, is the concept of a data model. So it's important to know what a data model is, what goes into and how to make it before you could start to think what is the best data format for you or maybe how to change your existing data format. So the first question when asking about a conceptual data model is what are we really trying to keep track of?

Now this might seem a little simplistic, but it really does capture the essence of what we're after. Think, technology aside, from a purely logical view, what are you looking to keep track of, measure, record, or otherwise track? In data modeling terminology, we call this typically an entity, and then around an entity are things such as attributes. These are characteristics or measurements that describe what your entity is. 

Now the concept of an entity as a comp and just in the ether is a little abstract. So let's pull it back down to earth. Let's take a customer, for example. Most businesses, if not every business, has a customer. This is your base-level entity. Now there's many attributes about the customer that describes it. Maybe it's a high-level attribute, such as, is it an individual, a business, or a government entity? Perhaps there are things such as names. Perhaps there's things such as salutations. And maybe there's internal tracking numbers that describe this customer, such as a customer number or a last sale date that you are keeping track of, but doesn't have much meaning outside of your organization. The point is, when building a data model is to keep track of what the thing you're keeping track of and then how do you describe it.

So once you have your entity defined, and honestly in many cases there's more than one entity type, we need to think about how they relate to each other, aka a relationship. Sticking with the sales application, maybe the customer is linking with a product. Now the product itself has its own complete list of attributes that describe the product and the relationship, in this case, might be a sale. In other words, when a customer purchases a product, a sale relationship is generated between the two of them. And don't think that there's only one type of relationship between these entities. Perhaps the customer has a product on their wishlist, or maybe they've purchased a product twice and that now needs to be represented with a different type of relationship. Or maybe a sale is its own entity that has transaction details and then that links to the customer and the product. There's a lot of ways this can expand, but for simplicity reasons, just think a relationship is how two entities relate to each other.

Lectures

Introduction - Data Sources and Formats - CSV - XML - JSON - Specialized Data Formats - Databases - Exchanging Data Across Applications - Applying What we Have Learnt - Sales Data for an Online