数据模型评估标准：提升行业实践质量

5星 · 超过95%的资源需积分: 9 16 浏览量更新于2024-07-19 收藏 7.97MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

as being an entity where the column headings represent the pieces of information that may

be recorded for each entity. Each spreadsheet row containing the actual values represents

an entity instance. The entity Customer may have multiple customer instances with the

names Bob, Joe, Jane, and so forth. The entity Account can have instances of Bob’s

checking account, Bob’s savings account, Joe’s brokerage

account, and so on.

Entities may be described at conceptual, logical, and physical levels of detail. The

conceptual means the high level business solution to a business process or application

effort frequently defining scope and important terminology, the logical means the detailed

business solution to a business process or application effort, and the physical means the

detailed technical solution to an application effort.

For an entity to be relevant at a conceptual level, it must be both basic and critical to the

business. What is basic and critical depends very much on the scope. At a universal level,

there are certain concepts common to most companies such as Customer, Product, and

Employee. Making the scope slightly narrower, a given industry may have certain unique

concepts. Campaign, for example, will be a valid concept for the advertising industry but

perhaps not for all other industries. In the publishing industry, Author, Title, and Order

are conceptual entities, shown as names within rectangles:

Entities described at a logical level represent the business in more detail than at the

conceptual level. Frequently, a conceptual entity represents many logical data model

entities. Logical entities contain properties, often called “attributes,” which we will

discuss in the next section. Here are three logical entities based upon the previous

conceptual entities:

At a physical level, the entities correspond to technology-specific objects such as database

tables in a relational database management system (RDBMS) or collections in the NoSQL

database MongoDB. The physical level is similar to the logical level but may include

compromises that were needed to make up for deficiencies in technology, often related to

performance or storage.

Below are physical entities based upon the previous logical entities. The physical entities

also contain database-specific information such as the format and length of an attribute

(Author Last Name is 50 characters) and whether the attribute is required to have a value

(Author Tax Identifier is not null and therefore required to have a value, but Author

Birth Date is null and therefore not required to have a value).

In an RDBMS, these physical entities become database tables or views. In NoSQL

databases, these physical entities become transformed depending on the underlying

technology. For example, in MongoDB, a document-based database, these entities become

collections. The general term “structure” will be used to refer to the underlying database

components independent of whether the database is a RDBMS or NoSQL solution.

Attributes

An attribute is an individual piece of information whose values identify, describe, or

measure instances of an entity. The attribute Claim Number identifies each claim. The

attribute Student Last Name describes the student. The attribute Gross Sales Amount

measures the monetary value of a transaction.

As with entities, attributes can be described at conceptual, logical, and physical levels. An

attribute at the conceptual level must be a concept both basic and critical to the business.

We do not usually think of attributes as concepts, but depending on the business need, they

can be. When I worked for a telecommunications company, Phone Number was an

attribute that was so important to the business that it was represented on a number of

conceptual data models.

An attribute on a logical data model represents a business property. Each attribute shown

contributes to the business solution and is independent of any technology including

software and hardware. For example, Author Last Name is an attribute because it has

business significance regardless of whether records are kept in a paper file or within the

fastest database out there. An attribute on a physical data model represents a database

column. The attribute Author Last Name might be represented as the column

AUTH_LAST_NM within the RDBMS table AUTH or represented as the field name

AuthorLastName within the MongoDB collection LibraryCardCatalog.

Domains

The complete set of all possible values that an attribute can be assigned is called a domain.

A domain involves a set of validation criteria that can be applied to more than one

attribute. For example, the domain Date, which contains all possible valid dates, can be

assigned to any of these attributes:

● Employee Hire Date

● Order Entry Date

● Claim Submit Date

● Course Start Date

An attribute must never contain values outside of its assigned domain. The domain values

are defined by specifying the actual list of values or a set of rules. Employee Gender

Code, for example, may be limited to the domain of female and male. Employee Hire

Date may initially be assigned the rule that its domain contain only valid dates, for

example. Therefore, this may include values such as:

● February 15th, 2005

● 25 January 1910

● 20150410

● March 10th, 2050

Because Employee Hire Date is limited to valid dates, it does not include February

30th, for example. An attribute may restrict a domain with additional rules. For example,

by restricting the Employee Hire Date domain to dates earlier than today’s date, we

would eliminate March 10th, 2050. By restricting Employee Hire Date to

YYYYMMDD (that is, year, month, and day concatenated), we would eliminate all the

examples given except for 20150410. Another way of refining this set of values is to

restrict the domain of Employee Hire Date to dates that fall on a Monday, Tuesday,

Wednesday, Thursday, or Friday (that is, the typical workweek).

There are three basic domain types:

● Format domains specify the standard types of data one can have in a database. For

example, Integer, Character(30), and Date are all format domains.

● List domains are similar to a drop-down list. They contain a finite set of values

from which to choose. List domains are refinements of format domains. The format

domain for Order Status Code might be Character(10). This domain can be further

defined through a list domain of possible values {Open, Shipped, Closed,

Returned}.

● Range domains allow all values that are between a minimum and maximum value.

For example, Order Delivery Date must be between today’s date and three months

in the future. As with list domains, range domains are a refined version of a format

domain.

Relationships

A relationship between entities indicates that the instances of those entities may be related

in some meaningful way. Each relationship may define rules around when and how many

instances are related. Relationships are depicted as a line between the two entities.

However, some kinds of modeling allow more than two, and these have different

depictions. If the two entities are Employee and Department, the relationship can capture

the rules “Each Employee must work for one Department” and “Each Department may

contain one or many Employees.”

In a relationship between two entities, cardinality captures how many instances from one

entity participate in the relationship with instances of the other entity. It is represented by

the symbols that appear on each end of a relationship line. Cardinality specifies one kind

of data rule that can be enforced. Without cardinality, the most we can say about a

relationship is that two entities are connected in some way through a rule. For example,

Employee and Department have some kind of relationship, but we may not know more

than this. Note that the same two entities may be related in more than one way; for

example each Department may contain one or many Employees, but there could be a

separate relationship capturing the Employee who manages that Department.

For cardinality, we can choose any combination of zero, one, or many. Many (some people

read it as more) means any number greater than zero. Specifying zero or one allows us to

capture whether or not an entity instance is required in a relationship. Specifying one or

many allows us to capture how many of a particular instance participates in a given

relationship.

Because our diagramming approach has only three cardinality symbols, we can’t specify

an exact number

[1]

(other than through documentation), as in “A Car contains four Tires.”

We can only say, “A Car may contain many Tires.” Each of the cardinality symbols is

illustrated here with Author and Title:

The business rules in this example are:

● Each Author may write one or many Titles.

● Each Title must be written by one Author.

The small vertical line means one. (Looks like a 1, doesn’t it?) The circle means zero.

(Looks like a zero too!) The zero implies optionality and does not exclude the value one,

so in the above example an author can write just one title, too.

The triangle with a line through the middle means many. Some people call the many

Identifying relationship Non-identifying relationship

symbol a crow’s foot. Relationship lines are frequently labeled to clarify the relationship

and express the rule that the relationship represents. A data model is a communication

tool, and if you think of the entities as nouns, the relationship label is a present tense verb.

Therefore, we are just reading this sentence:

● Each Author may write one or many Titles.

Having a zero in the cardinality makes us use optional-sounding words such as may or can

when reading the relationship. Without the zero, we use mandatory-sounding terms such

as must or have to. So instead of being redundant and saying:

● Each Author may write zero, one, or many Titles.

We take out the word zero because it is expressed using the word may, which implies the

zero:

● Each Author may write one or many Titles.

Every relationship has a parent and a child. The parent entity appears on the one side of

the relationship, and the child appears on the many side of the relationship. In this

example, the parent entity is Author and the child entity is Title. When I read a

relationship, I start with the entity on the one side of the relationship (the parent entity)

first. “Each Author may write one or many Titles.” I then read the relationship from the

many side: “Each Title must be written by one Author.”

I also always use the word each in reading a relationship, starting with the parent side. The

reason for the word each is that you want to specify, on average, how many instances of

one entity relate to an entity instance from the other entity.

There are two types of relationships, identifying and non-identifying. An identifying

relationship is shown with a solid line and means that the entity on the many side (the

child) is always going to be a dependent entity to the entity on the one side (the parent).

The dotted line means that the entity on the many side (the child) is not dependent on the

entity on the one side (the parent). Here are both types of relationships:

Independent entities are displayed as rectangles with sharp corners. Dependent entities,

such as Title under the identifying relationship example, are displayed as rectangles with

rounded corners. An independent entity is an entity where each occurrence (instance) can

be found using only attributes that it owns. For instance, Title under the non-identifying

relationship example can be found by an ISBN (International Standard Book Number),

which is an attribute that belongs to Title. A dependent entity such as Title under the

identifying relationship example can only be found by using at least one attribute from a

different entity such as Author Tax ID from Author.

剩余183页未读，继续阅读

winkup2019

粉丝: 0
资源: 2

数据模型评估标准：提升行业实践质量

Introduction to Scorecard for FICO Model Builder 英文

A Model for Data Quality Assessment .pdf

scorecard怎么看变量IV和缺失值，请提供代码，以导入数据，变量为表内所有变量

scorecard怎么看变量IV和缺失值，请提供代码，以导入数据，变量为age和gender

scorecard分箱

详细介绍下Balanced Scorecard模型

svm支持向量机matlab代码关于心脏病的

怎么用scorecard库来看IV值

scorecard里面woebin函数用什么参数实现最小分箱数为3

scorecard怎么看变量IV和缺失值，请提供代码

我现在要用pycharm的socrecard库建立一个模型，数据也有了，请协助我从头开始建立，我是一个不会python的人

kaggle/上学生考试成绩的数据集叫什么名字

bp神经网络python代码

使用评分卡建立中小微企业信用风险的评估模型，给出相应MATLAB代码

如何用R语言写评分表

python中lift评分

已知某班n个学生成绩单，求每个学生总分 要求： 1. 设计成绩单数据类型 2. 求n个学生，每个人的总分。（提示：函数实现）

怎么做详细的组织绩效评估

sc.woebin()函数

sql函数 SPLIT_STR

最新资源

已知某班n个学生成绩单，求每个学生总分要求： 1. 设计成绩单数据类型 2. 求n个学生，每个人的总分。（提示：函数实现）