Regarding "Types of Data" - don't gloss over that too fast. Some of the distinctions here are vitally important to grasp when it comes to managing data.
@@datastrategypros Without seeing the complete list you put forth, I will just make a couple of observations. Transaction data is about an event occurring at a point in time (or a span of time).Generally, once the event has happened the information about it should not be changed, or at least pending updates must be given special scrutiny. This is something auditors are very sensitive about, at least a formal audit trail must be maintained for all changes to event data, if they are allowed at all. Also transaction files will grow endlessly, since having happened, an event cannot be cancelled (deleted) which again necessitates special controls and audit trails to be implemented. That is why accountants insist on separate files for sales (an event) and returns (also an event). A transaction file is different from a file of objects which persist in time, such as employees in a company, or products. Employees come and go (insert and delete), and the information of such object types will change over time, but the total number does not grow endlessly. Master date or reference data is primarily used to ensure quality control over data, recorded in other files. Think of these being part of a controlled vocabulary. An example might be states in the USA or provinces in Canada, to ensure the correct spelling, full name, and abbreviation(s), etc. USPS two character state/provincial codes. Data fields which use these data need to be defined with SQL referential integrity checks against the master reference data. Whenever we define an entity/object about which we collect data, it is important to understand and properly represent the behaviour of that object in our data models, and to understand the population of each object. Furthermore, whenever we think about an attribute of an entity, it is itself another object type with its own population of instances, i.e., a value domain. Interesting that in fact modelling we do not differentiate entities and attributes as is done in relational modeling. In fact, in fact modeling, we never think about "tables" or relations, since that is what gets us into trouble and necessitates the invocation of the rules of normalization. Such rules are unnecessary in fact modeling. The reason is that all functional dependencies are explicitly declared in fact modeling. Hence, the system has all the information necessary to enable the generation of tables for implementation in a relational/SQL database, and they are guaranteed to be fully normalized. There's a quick look at a couple of things, just to whet your appetite. What other types of data were on your list?-gord.e.
Hi, thank you for sharing this video. If you know where to buy a new DAMA-DMBOK2 Revised Edition paper or online, please help me by sharing the link. Thank you.
You're very welcome, Purnima! You can purchase the DMBOK v2 Revised as a hardcopy from Amazon (amzn.to/32oK8hH) or as an ebook from DAMA's publisher (technicspub.com/dmbok/).
Hi, I am trying to give the exam. It keeps saying I needs to satisfy conditions before I can attempt the exam. Does anybody have any insights on this ?
Love it, thanks for sharing... this will help some talent that have no idea where to start exercise towards cdmp certification
Thanks for the encouragement!
I really liked this! Great content 👌
Thank you, Salih! We'd love to have you join for one of our upcoming events on these topics: www.datastrategypros.com/events
Question: Does the DMBOKv2 cover anything on recent privacy laws? Gdpr, ccpa, hippa, biometrics etc?
Good question, unfortunately it really does not
I love it 😊 hallo from Kabul city
Hello Yama!!
Regarding "Types of Data" - don't gloss over that too fast. Some of the distinctions here are vitally important to grasp when it comes to managing data.
Interesting point, Gordon! I'd be curious to hear more of your perspective on types of data.
@@datastrategypros Without seeing the complete list you put forth, I will just make a couple of observations.
Transaction data is about an event occurring at a point in time (or a span of time).Generally, once the event has happened the information about it should not be changed, or at least pending updates must be given special scrutiny. This is something auditors are very sensitive about, at least a formal audit trail must be maintained for all changes to event data, if they are allowed at all.
Also transaction files will grow endlessly, since having happened, an event cannot be cancelled (deleted) which again necessitates special controls and audit trails to be implemented. That is why accountants insist on separate files for sales (an event) and returns (also an event). A transaction file is different from a file of objects which persist in time, such as employees in a company, or products. Employees come and go (insert and delete), and the information of such object types will change over time, but the total number does not grow endlessly.
Master date or reference data is primarily used to ensure quality control over data, recorded in other files. Think of these being part of a controlled vocabulary. An example might be states in the USA or provinces in Canada, to ensure the correct spelling, full name, and abbreviation(s), etc. USPS two character state/provincial codes. Data fields which use these data need to be defined with SQL referential integrity checks against the master reference data.
Whenever we define an entity/object about which we collect data, it is important to understand and properly represent the behaviour of that object in our data models, and to understand the population of each object. Furthermore, whenever we think about an attribute of an entity, it is itself another object type with its own population of instances, i.e., a value domain. Interesting that in fact modelling we do not differentiate entities and attributes as is done in relational modeling. In fact, in fact modeling, we never think about "tables" or relations, since that is what gets us into trouble and necessitates the invocation of the rules of normalization. Such rules are unnecessary in fact modeling. The reason is that all functional dependencies are explicitly declared in fact modeling. Hence, the system has all the information necessary to enable the generation of tables for implementation in a relational/SQL database, and they are guaranteed to be fully normalized.
There's a quick look at a couple of things, just to whet your appetite. What other types of data were on your list?-gord.e.
@@GordonEverestGlad to find such a distinguished professor in a UA-cam comment section.
Hi, thank you for sharing this video. If you know where to buy a new DAMA-DMBOK2 Revised Edition paper or online, please help me by sharing the link. Thank you.
You're very welcome, Purnima! You can purchase the DMBOK v2 Revised as a hardcopy from Amazon (amzn.to/32oK8hH) or as an ebook from DAMA's publisher (technicspub.com/dmbok/).
@@datastrategypros thank you.
Question: If I buy the print edition + pdf bundle from the official website, do they ship me a physical book? Or do I need to print the pages at home?
Is CDMP Fundamentals exam same as the Associate one?
Yeah, Data Management Fundamentals is the name of the exam and Associate is the name of the credential you receive if you pass.
Hi, I am trying to give the exam. It keeps saying I needs to satisfy conditions before I can attempt the exam. Does anybody have any insights on this ?
Are you using Chrome? Did you install the Honorlock browser extension?
@ I did, and did the practice exams as well.