Submit a detailed data model of the database with analysis and justification based on a specific group or department within the organization. Select one particular group or department (such as Sales or Human Resources) within the organization in your chosen scenario from Hands-On Database. Then develop and illustrate a comprehensive enterprise data model for the selected group. Articulate the operating rules within the group to allow for an application model. Assess the extent to which your data model reflects the operating rules of the organization.

Specifically, the following critical elements must be addressed:

· Data Model: For the three sections of this element, you will focus on a particular group or department within the organization (such as Sales or Customer Service).

A. Enterprise Data Model: Develop and illustrate a comprehensive enterprise data model for the selected group.

B. Operating Rules: Articulate the operating rules within the group to allow for an applicable model.

C. Rule Reflection: Assess the extent to which your data model reflects the operating rules of the organization.

Guidelines for Submission: Your paper must be submitted as a four- to six-page Microsoft Word document using appropriate modeling language and/or diagrams.

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.