 Hello and welcome to this session in which we would look at data architecture. Data architecture described the structure and interaction of the major types of sources of data, logical data assets, physical data assets, and the data management resources of the enterprise. Well, what is architecture? Let's start with that. Basically, an architecture is a blueprint of a building, a blueprint of something before you build it. Well, for the data, you need a blueprint for your database, a map. And this is what data architecture is. That map will show you how the data interact with each other, how the data interact with each other. We're going to see briefly how does it work. You're going to have to have a logical data asset or a logical data model, a physical data asset or a physical data model, and how they all interact with the data management resources of the enterprise. This is what we're going to be discussing, but specifically, I'm going to be focusing on logical data asset and physical data assets. And a good data architecture should be aligned with the business goal and objective, and should be scalable. It means it can grow as the business grows. And obviously, it has to be secure. Now, we always mention this align. For example, we talked about COVID. Well, any IT should be aligned with the business objective. No difference for the data. Data governance, data infrastructure, data architecture, they should all be aligned with the business structure. That's why we create them is to help achieve our business objective. Before we proceed any further, I have a public announcement about my company, farhatlectures.com. Farhat accounting lectures is a supplemental educational tool that's going to help you with your CPA exam preparation, as well as your accounting courses. My CPA material is aligned with your CPA review course, such as Becker, Roger, Wiley, Gleam, Miles. My accounting courses are aligned with your accounting courses, broken down by chapter and topics. My resources consist of lectures, multiple choice questions, true-false questions, as well as exercises. Go ahead, start your free trial today. No obligation, no credit card required. Let's start with the conceptual data model. Before you build a whole data infrastructure, you have to have a conceptual model. Let's assume you are building a website. The first thing you're going to do is sit down and basically say, okay, this is my home page. I want the home button here. I want my product to go here. I want my contact information here, so on and so forth. This is basically a conceptual data model. You're going to do the same thing for the database. You're going to have a high level representation of the data, providing an abstract, no details, just an abstract view of the data and its relationship. Here you're going to define the concepts and the entities and the data. We're going to see what entities are in a moment and the relationship. How does these entities relate to each other, but you're not going to be specific as far as the physical storage of the data or the technical details. Again, here, think about literally doing this on a piece of paper or on a Word document or an Excel sheet or some sort of a simple software that it's basically drawing. The purpose of this step, the conceptual model, is to provide a clear and comprehensive understanding of the data used by the organization. What does it look like? It serves as a foundation for the development of the more detailed data models, just basically a quick and dirty on a piece of paper. Now, this step is independent of any specific technology or database. So when you build this, you're not using Oracle, you're not using SAP, you're not using any database. This is basically the basis for the development of what we call the logical and the physical data. The best way to look at a conceptual data model is to look at a picture. And if I show you this picture, this is what a conceptual, a simple conceptual model looks like. Now, if I ask you, what can you derive from this picture? Well, here's what I can derive. I can derive that we have an order, a sales order, and that sales order should have customer information, and that sales order should have the product information. Now, the sales order could have other, other, other, other things that goes on it. Now, the customer, the product, the order, we call these entities, entities, and they're going to change their names later in the process. So these are entities. So we have one, two, three entities, simple database for this example. Now, once we draft this model, we can get into the logical data asset model or the logical data model, which it's an expansion of the conceptual model, but still a high level of representation of the data. Now, we're going to include attributes, data attribute, attributes, we're going to look at what's called key attributes and non key attributes. Those are terms. What is an attribute defined the uniqueness of the entity? Remember, each one of those are entity and they should have a user friendly name. For example, we could have an entity that's called customer. So this is an entity customer. Now this entity will have attributes. What are the attributes? First name, last name, address, phone number, email, date of birth, whatever you want to add for this customer. Also, we could have social security or ID for the customer. Now, this part here, see where that big dash is the upper part, we call this the key attribute. It's a key identifier unique to this entity. And the others that are below this line that are non key attributes, first name, last name, address, phone number, so on and so forth. So we have key attributes, non key attributes and this is an entity. This picture serves the blueprint for the physical data model and the data management process we're going to look at next and helps to ensure that the data is used consistently and correctly throughout the organization. So every customer will have all this information. Now, it's implemented. This model can be implemented in any database. So we're not specific to any database. We call this data agnostics when the model is still generic, you can create it in any database, it's called data agnostics. It's a little bit more complicated, harder to build than the conceptual model, but still very generic. Examples of logical data asset model, as I just showed you, we could have the model include the following data assets or we call them entities, customer, include customer information, order could be another entity, a product, could include information about product name, description price available, quantity, so on and so forth. And we're going to show you a picture of this in a moment. Also, this model defines relationship between the data assets such as, for example, a customer could have multiple orders. So one customer could have multiple orders. We want to make sure that the database allows us to do that. An order will consist of multiple product in any particular order. You could have several products and the product can be part of multiple order and any product can be part of multiple order. So the logical data asset model provides also a high level of understanding, but a little bit more detail than the conceptual framework of the type of the data the company is working with and how they relate to each other. So based on this model, the company can develop what we call the physical data model that defines the specific database tables. Now notice the entity is going to be called tables and columns and relationship needed to store and manage this data. So this is a picture of the logical data model. If you look at the first picture when I showed you, it was only a customer, nothing else was order, nothing else and product. Now what we have is we have the key attributes and the attributes and how do they relate to the order. For example, the social security or the ID, which is the, this is the key attribute becomes, it's called the foreign key. So we have two foreign keys under order, either social security or ID and product ID, then the order will have non key attributes. Now, once we have the logical data model ready, we can create the physical asset model. What is the physical asset model? It's a detailed representation of what we just did, including specific structures and format of data stored in database, databases, data warehouses and other storage system. So now we are a little bit more serious, more concrete. This is a concrete implementation of the logical asset model and provide the technical specification of the data architect. So each data asset is mapped to a specific database table with defined columns. Now the entities are going to be called tables and we're going to have columns and the relationship between the data assets are established through foreign keys and other database constraints. So the physical data asset model include information on the storage, retrieval of data, indexing strategies, backup and recovery procedures and performance optimization techniques. So once you're building the physical data assets, you have to worry about everything. So now this is a picture of the physical data asset model. Now I did this now and I'm not, you know, I'm not perfect in this, but basically this is no longer called an entity, this is called a table from a database perspective. And this is, remember, this is called the key and we have columns, first name, last name. So all what I added to this is, for example, the address has to be taxed, the name has to be taxed. I am identifying, for example, the phone number has to be integers. For example, the email has to be email formatted. The date of birth should have, you know, some sort of a date month, two-digit, day, two-digit and year, either two or four digits, whatever you want to do. So here you are being more specific. This is an example of a physical data asset model. Okay. For example, customer will have tables, not entities. The customer is the name of the table and we have columns. We have the primary key. Okay. Order, same thing. We'll have tables and columns. Product will have tables and columns, table and columns. The physical data asset model maps the data asset and the logical, and the logical asset model to specific database table with defined columns and data types. When we say defined columns and data types, for example, addresses is taxed, phone numbers are numbers. You can only use numbers. The relationship between the data assets are established to use of a foreign keys. Remember, we have foreign keys that connect those tables. In this example, in the example that we work, the customer ID column in the order is the foreign key that reference the customer ID column and the customer table. And I showed you this in the prior picture. The physical data asset model provide the technical details needed to create and implement the database table relationship and other data management and component needed to store and manage the data. And this is basically creating what we started with the data architecture of a database. This is what you need to know whether you are studying for the CPA exam, the CMA exam, CSER, or accounting information system. Now, if you are too technical, I'm not that person. I help accounting related and finance related topic, but if you want to learn more about this topic, I do have multiple choice questions that's going to help you test your knowledge, get ready for that exam. So go ahead, go to for half lectures, invest in yourself, stay safe and study hard.