《中国电子商务》期刊简介
一、期刊名称
《中国电子商务》
二、刊号
国内标准刊号：CN11-4440/F
国际标准连续出版物号：ISSN1009-4067
三、主管单位
国家工业与信息化部
四、主办单位
中国电子企业协会
五、办刊宗旨
《中国电子商务》以传播信息化理念、报道经济前沿、倡导信息创新、促进经济发展为办刊宗旨，大力普及电子商务知识，弘扬科学精神，传播科学思想，倡导科学方法。
六、刊登内容
《中国电子商务》是广大经济和信息化领域的管理人员、科教工作者、高校师生、信息化技术人员发布学术文章的重要理论阵地，是获取精神陶冶、知识滋养和科技经济信息的重要渠道。本刊主要刊登我国当前信息化有关的科技、经济、教育、管理等方面具有一定学术和应用价值的学术文献和反映各学科、各领域的新成果、新技术、新工艺、新产品等方面的论述文章。
七、主要栏目
1. 经济管理研究：国际经贸、物流论坛、商业研究、物流平台、供应链管理、资本运营、区域经济、投资分析、产业经济、网络营销、企业管理、经营管理、营销策略、品牌战略、市场调研、人力资源、企业文化、财务审计、财经论坛、学术研究、管理科学。
2. 信息化研究：信息技术与安全、通讯技术、网络技术、自动识别技术与应用、电子商务、支付与结算、供应链管理、数据库与数据库管理、案例分析。
3. 科技研究：科技项目、科技政策 、科技成果、科学普及、技术市场、科技新品、实用科技、科学实践等、机电一体化、电气自动化。
4. 教育教学研究：教学研究、教育生活、课程与教学、教育信息化、职教时空、教学园地、信息化教学等。
5. 工程技术研究：建筑工程、生物工程、医学工程、环境科学、矿业工程、市政建设、水利工程、交通工程等。
八、读者对象
经济领域和信息化领域的管理人员、科技企业科研开发人员、高等院校师生、信息化技术科研人员，社会各界关注经济发展和信息化发展的各界人士。
联系方式 TEL：010-63309185
Email:
Some of the material presented in this article was excerpted with permission from
The Data Model Resource Book: A Library of Logical Data Models and Data Warehouse Designs published by John Wiley and Sons and authored by Len
Silverston, W. H. Inmon and Kent Graziano.
The Concept
The age of the data modeler as artisan is passing. Organizations can no longer afford the labor or time required for handcrafting data models from scratch. In response to these constraints, the age of the data modeler as engineer is dawning. Engineers build new products using proven components and materials. In data modeling, the analogue to a component is a \data model is a generic or template data model that can be used as a building block to jump-start development of the corporate data model, logical data model or data
warehouse data model.
Resistance to the use of universal data models is usually based on the belief that a
particular organization has unique needs or the dreaded \syndrome. This article describes the application of universal data models to several disparate organizations. It demonstrates that the same basic models, with minor
customization, can be successfully applied in each example.
One Size Fits All?
The belief that a particular organization is unique because of its missions, goals, policies, values, functions, processes and rules can be very strong. After all, some businesses sell to people and others sell to other organizations. Some deal with products and others deal with services. Each industry has its own set of business issues, and each organization within an industry varies as much as the differences
between the personalities of various individuals.
People and Organizations
A subject data area that is common to most enterprises involves the people and organizations that are part of conducting business. There is an important need to track the names, addresses, contact numbers and various relationships and interactions between the parties conducting business. Enterprises need to track information about customers, distributors, agents and suppliers as well as the internal organizations and people within the enterprise. This type of information is critical throughout all aspects of business including sales, marketing, customer service, purchasing, shipping, invoicing, budgeting, accounting and human
resources.
Enterprises spend significant effort and time defining the most effective ways to model this type of information. The data model may lead to sub-optimal solutions if careful analysis is not conducted. For example, many data models depict separate entities for each type of party that exists in an enterprise. There may be entities for
CUSTOMER, SUPPLIER, INTERNAL ORGANIZATION, BROKER, EMPLOYEE,
INVESTOR and any other role that a person or organization may play in the
enterprise.
There are problems with modeling the information this way. What if a person or organization plays more than one role in the organization? For instance, what if an organization supplies products and/or services to our organization and also buys products from us? Does this mean that we maintain their name, addresses, contact numbers and other organizational information in both the CUSTOMER and SUPPLIER entities? Under this scenario, if a name or address changes, the information needs to be changed in two places. Furthermore, does the organization play other roles such as an agent of the company or a distributor of products? Each time an organization's role is modeled as a separate entity, there is a potential for redundant
and inconsistent information.
The same argument applies to people. Should we have a separate EMPLOYEE entity as well as a CONTRACTOR entity? What if a contractor becomes an employee of the enterprise or vice versa? The person's name, demographics and contact information
may still be the same. The only thing that has changed is the nature of the
relationship between the parties.
It only makes sense to refer to pre-defined templates or universal data models when modeling common data structures. Universal data models can point out the most effective means to maintain this information and assure that subtle, yet
important, data integrity issues are not overlooked.
People and Organization Information
Figures 1, 2, 3 and 4 depict universal data models for the people and organizations involved in conducting business. These data models include information concerning the relationships between each person and organization as well as their associated
contact information.
Before beginning our discussion of these models, let's clarify some data modeling conventions. Entities are represented using rounded-edge rectangular boxes. Sub-types are represented by showing boxes within the larger box. For example, in Figure 1, ORGANIZATION and PERSON are both represented as sub-types of PARTY.
The lines between entities define relationships. The dashed section of each line represents that a relationship is optional. For example, in Figure 1, a PARTY does not necessarily have an associated PARTY DEFINITION. The part of the line closest to PARTY DEFINITION is solid, and this represents a mandatory relationship. Therefore, each PARTY DEFINITION must be associated with a related PARTY. The small crossed line across the PARTY DEFINITION to PARTY relationship specifies that the key to PARTY (party_id) is included as part of the key to PARTY DEFINITION. The \one-to-many (1:M) relationship. For example, Each PARTY may be defined by one or more PARTY DEFINITIONs. Vice versa, each PARTY DEFINITION must be used to define one and only one PARTY since the line from PARTY DEFINITION to PARTY
does not end with a \
Now let's discuss the data models. Figure 1 identifies a super-type named PARTY, with two sub-types, PERSON and ORGANIZATION. Information about a person or organization is maintained independent of their roles or relationships. This leads to a much more stable and normalized data structure since information about various people and organizations is only stored once. The same information can then be
associated with each of the party's roles.
The reason that PERSON and ORGANIZATION are both sub-typed into a PARTY entity is that there is common information related to both people and organizations such as their credit rating, credit limit, address, phone number, fax number or
e-mail address. Additionally, organizations and people can serve in similar roles. Both people and organizations may be buyers, sellers, members or parties to a contract. Parties may be classified into various categories (i.e., industry codes, minority classifications) using the PARTY DEFINITION which stores each category
into which parties may belong.
Figure 2 depicts that each PARTY may be involved in one or more PARTY RELATIONSHIPs. PARTY RELATIONSHIP is used to define the relationship between
two parties. An occurrence of a PARTY RELATIONSHIP may be between two organizations, such as a customer relationship to an internal company. The relationship may be between a person and an organization--for example, an employee of an internal company. Finally, the relationship may be between two people. An example of this is the relationship between a purchasing agent and their preferred supplier representative. The PARTY RELATIONSHIP TYPE defines the possible types of relationships. Possible instances of PARTY RELATIONSHIP TYPE are
\
representative.\example, one role of the relationship may be \same relationship may be \RELATIONSHIP STATUS TYPE entities allow each PARTY RELATIONSHIP to be prioritized (high, medium, low) and defined via a status (active, inactive). By distinguishing whether information should be associated with the PARTY or the PARTY RELATIONSHIP, we can avoid data anomalies. For example, many data models associate a status with a PARTY. This does not account for the fact that three sales representatives may have three distinct relationships with the same party. Each sales representative may want to record a different status for their relationship
with the party. If the status were stored with the PARTY, then the sales representatives would have to override each other's information. In actuality, there
《中国电子商务》期刊介绍
