Answer:
A.
The Enterprise Data Model
An Enterprise Data Model is an integrated view of the data produced and consumed across an entire organization. It incorporates an appropriate industry perspective. An Enterprise Data Model (EDM) represents a single integrated definition of data, unbiased of any system or application. It is independent of “how” the data is physically sourced, stored, processed or accessed. The model unites, formalizes and represents the things important to an organization, as well as the rules governing them
A method of organization is a way of grouping things into an orderly structure. An ESAM provides the structure for organizing an EDM by business subjects rather than by applications or data systems. Enterprise data systems are also organized by the ESAM, providing an orderly structure for their design, use, management, and planning. The process to create the ESAM is also important. It provides an opportunity to “sell” the value of enterprise-integrated data, as well as uncover many of the organization’s core data integration issues.
The enterprise data model benefits that Modern Analytics’ provides result from our fully automated modeling platform, which allows us to run thousands of models simultaneously and deliver results exponentially faster than possible with traditional predictive analytics techniques. We enable enterprises to more effectively identify strategic business investments, improve daily operations, increase productivity, and predict changes to the current and future marketplace.
Empower your executives to be proactive rather than reactive
Optimize both short- and long-term business operations
Accurately forecast sales and new customer acquisition
Build longer-lasting customer and supply chain relationships
Gain an edge in allocating resources and spending your dollars efficiently.
B) Operating Rules:
Conceptual modeling makes it easier to capture and validate the operating rules
at a high level, from which you consciously can make informed choices about how to
implement the rules. Designing at a lower level makes it easy to misconstrue or even miss
some rules, and often means you commit too early to some implementation strategy.
Without a conceptual model of your business, the task of maintaining or evolving
your database application can be a nightmare. If your technical designer leaves,
somebody else has to wade through low level documentation to understand the
application, and if you decide to port the application to a new platform, the re-
engineering task can be daunting. A conceptual model provides a readily understandable
structure, to which you may apply different mapping algorithms to implement it in
whatever kind of system you like.
According to the operating rules Group,operating rules are each one of the following kinds:
Term — The application of a single definition to a word or phrase
Fact — The attribution of something to describe a thing: a role it plays, or some other descriptor.
Derivation — An attribute that is derived from other attributes or system variables.
Constraint — A condition that determines what values an attribute or relationship can or must have.
The Group further organized rules, saying that Term, Fact, and Derivation were examples of “structural assertions”, and Constraint is also called an “action assertion”.
Terms and facts are the primary constituents of data models, along with the results of derivations (derived attributes). The definitions of terms and the logic behind derivations are documented
behind the scenes, typically in the repository of the CASE tool used to draw the model. Only some constraints can be shown, however. The remainder must be displayed or described using a different
technique. This article will discuss the terms, facts, and derivations that can be shown. The next article will talk about the constraints that can and cannot be shown.
C. Rule Reflection:
A conceptual entity contains a primary key representing its unique identity in business terms. Although a conceptual entity may represent multiple logical entities, the key remains realistic at the root level. A key validates business rules; as entity concepts are related and keys are inherited, they must continue to work correctly.
Additional attributes are included for business significance and/or enterprise data integration. Enterprise data integration is generally defined in terms of the keys and relationships. If a relationship does not work and/or a key is not being inherited correctly, there’s probably an incorrect assumption about the business rules.