PB教务管理系统(开题报告+任务书+英文文献翻译)
英文文献2 —译文
对数据库建模的一种宏观方法
道格拉斯 M.科莱恩
信息系统操作管理UNC 威里姆顿
威里姆顿,NC 28403-5611 美国
察里恩.里格
信息系统和决策学,南佛罗里达大学
5700 北迈阿密,萨拉索塔 FL 34243-2197
摘要
    一种新的数据建模过程在一次关于传统标准化建模过程的弱点的演讲中被提出。当前的方法一般是开始时做一个粗略的系统，然后把这个系统通过标准化正常化处理从而检查系统功能的好坏。在这次演讲中提出的方法则更加注重数据个体以及他们之间的比较，在比较的过程中检查他们各自属性对系统功能的影响。我们说，这种宏观方法应该是更加直接更加灵活的建模方法，对于一些特殊的应用更加具体生动。我们以这种方法出现在关系数据建模中作为讨论的结束。
关键字：数据模型；关系模型；建模过程
1.介绍
关系数据库今天是许多信息系统的基础。与其它数据库的形式比较比如层次结构的, 网状结构的还是面向对象结构的数据库，关系数据库占据着绝大多数的市场份额。许多现在的系统严重依赖于关系数据库作为其数据库以及为企业提供广泛的资源。
由于许多功能被放置在数据库内部，现在对于大型的系统关系数据库是根本。数据库必须支持许多不同的应用, 因此数据必须是非常灵活的。由于虚假的数据进入系统后会对其他数据库操作造成影响，所以数据完整性必须被放在一个很重要地位。 要将现有数据库进行替换或者增加新系统时，数据库必须要对不能预见的问题能够做出反映。总的来说，不完善的数据库会导致不完善的系统。
当编程走向了了商业化进入了市场，开发设计则会更加迎合市场的需求。（科伊和贝克•克帕拉尼2004）尽管画传统的标准化流程图不是一门真正意义上的科学，但是任何一个好的开发者必须要查阅很多的资料图片才能进行开发。很遗憾，关系数据建模不是确切的科学，我们无法声称我们提出的方法将会更好的进行数据建模。
我们试图指出基于正常化的设计方法的缺点, 并且提出宏观方法的优势所在。首先我们先回顾一些关系数据建模的目标。其次我们看看传统的建模方法的以及其缺点，然后我们会在演讲中提出宏观方法进行描述论证。
2.关系数据模型的目标
在这个部分, 我们回顾一些关系数据库模型的目标。令人惊奇的，今天推动关系数据模型创作的动力依然存在，尽管技术在前进。
程序数据独立
   关系数据模型的一个主要目标是要考虑到数据的独立性。传统上, 这意味, 程序员不需要知道物理存储器机制和物理存储器模型而写程序, 即, 节目不需要知道物理数据模型。
程序数据独立概念可能延伸到离散数据设计的概念。今天的系统共同分享数据库, 如此逻辑模型是方便的同时可能会出现一些问题。逻辑数据模型需要灵活, 并且要更好的支持新系统或未遇见到的问题。特别要提出的是, 数据库模型不应该强加限制给应用程序。
数据完整性
今天的数据库经常担当“综合系统”的角色，换句话说, 它是和系统最紧密的, 通过它分享数据, 硬件和操作系统平台, 和应用程序。所以数据完整性是非常重要的。错误或无效的数据可能导致系统的崩溃。所以在众所周知的插入，更新，删除时应减少异常的数据。简而言之, 数据的内部一贯性被维护。
3.对数据库建模的传统方法
很清楚的一点是当准备不足时一个程序的开发对某个公司而言，从长远看将会损害公司的利益。这有一些来自信息技术专家的引证。
（1）“我们无法把记录输入到表中，因此我们删除了所有的关系。”
（2）“我们投入了一切在一张功能完善的表中，那样做更加简单。”
（3）“我们将速度正常化。”
    每个上述情况都可归因于粗略不完善的数据库建模。所有的上述情况，虽然适应它们当时的开发环境，但是这样将会导致肮脏数据的产生，导致易崩溃的系统。那为什么上述情况还很流行在软件产业界呢？所以我提出数据建模的当前过程是有缺陷的。这一个典型的过程为传统标准化数据建模。
（1） 指定系统/应用/程序的要求。
（2） 为系统指定形式和报告。
（3） 满足3NF要求。
第三步先不介入数据模型的变换过程。变换数据模型第一范式, 例如, 所有第一范式侵害被辨认和被去除。一旦所有第一范式侵害被去除，模型被认为以第一范式, 并且模型开始寻找第二范式侵害。模型连续地被采取通过正常形式, 停止在第三范式, 以下部分指出这种方法缺点。
数据库设计从程序设计开始。多数数据库设计的动力是唯一的应用要求。这不可避免的导致了数据库设计的偏差。使用建筑做比喻，房子在盖之前是要先有图纸和基础设计的，基础设计则认为只是盖一所房子而已。但是数据库通常被认为要支持多个系统，更加准确的比喻是基础建设只考虑了支持一所房子，但在以后会不会有在原有的房子上加盖房子这没被考虑到。有经验的项目负责人紧紧处理他们的项目范围, 因此数据库设计被描述成对本项目的具体需要。人们认为系统是项目的焦点，数据库一般只是支持技术，我们没必要花太多的时间和精力在数据库上面。这是反语，数据库的设计更加重要。
从形式和报告上驱动数据库的设计。许多专家和课本作者建议将形式和报告作为开发数据模型的必要条件。这一定会是一个好起点, 形式和报告将必须最终被存放在数据库属性的表单中。
设置属性
   从属性以来入手进行检查，将会去除不合理的地方。经典症状是重覆的属性，然而就没有这些问题吗？
•二个实体应该被结合吗?
•一个递归关系应该被使用吗？
•怎样的名字对一个实体来说是个好名字？
•越来越多的关系会增加模型的灵活性吗？
宽松图示法
一些开发者容易混淆建模的图表，结果导致了最终系统的失败。所有知名的一般侵害可能很容易用图解法表示在UML 或E-R 图中，要清楚的是一个图示法不能等效于塑造数据。使用宽松示图的发法容易发现粗劣的模型的不足。                                  图 1
4．对数据库建模的宏观方法
在这个部分, 我们提出一种宏观的方法对数据库建模，焦点在塑造数据而不是创造数据库支持应用。总之, 方法倾向集中于实体, 而不是属性。它应该注意到, 在一个特殊系统开发项目里塑造的过程不被看作是支持的活动。相反, 数据建模过程应该是值得的事业本身的活动, 并且意味支持多个系统。
过程
强力鉴别，典型实体: 通过标准系统的努力的分析, 对系统中典型实体应该被辨认出来。典型实体的名词出现在其他的文献中，辨认实体不是问题，但是辨认典型实体就不太容易了。强力的鉴别将是设计中一个很重要的地步。典型的实体会889

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>