⑴ 利用oracle数据库管理系统解释关系，实体，实体型，实体集，主码，域，属性，候选码，外码
答：实体：客观存在并可以相互区分的事物叫实体。
实体型：
具有相同属性的实体具有相同的特征和性质，
用实体名及其属性名集合来抽象
和刻画同类实体称为实体型。
实体集：同型实体的集合称为实体集。
属性：实体所具有的某一特性，一个实体可由若干个属性来刻画。
码：唯一标识实体的属性集称为码。
域：
属性的取值范围。
⑵ 数据库中的实体解释
就数据库而言，实体往往指某类事物的集合，把每一类数据对象的个体称为实体，数据库实体可以是具体的人事物，也可以是抽象的概念、联系。
E-R称为实体-联系图，是描述概念世界、建立概念模型的实用工具。数据库的设计过程是先使用E-R图描述组织模式，再进一步转换成任何一种DBMS支持的数据模型。
E-R图的三要素为实体、属性和联系，分别用矩形框、椭圆形和菱形框表示。
(2)数据库虚实体扩展阅读：
实体的相关术语：
1、实体属性：
将食物的特性称为实体属性，每个实体都具有多个属性，几多个属性才能描述一个实体。实体属性值是实体属性的具体化表示，属性值的集合表示一个实体。
2、实体属性值：
实体属性值是实体属性的具体化表示，属性值的集合表示一个实体。
3、实体类型：
用实体名及实体所有属性的集合表示一种实体类型，他剪真实体型通常一个实体型表示一类试题。因此通过实体型可以区分不同类型的失误。
⑶ 数据库里面“实体”的定义是什么
在数据库里边，所谓“实体”就是E-R模型。具体关系如下：
E-R模型的构成成分是实体集、属性和联系集，其表示如下列步骤：
（1） 实体集用矩形框表示，矩形框内填写实体的名称。
（2） 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。
（3） 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1—1、1—N或M—N。
(3)数据库虚实体扩展阅读：
实体的相关术语：
1、实体属性：
将事物的特性称为实体属性，每个实体都具有多个属性，几多个属性才能描述一个实体。实体属性值是实体属性的具体化表示，属性值的集合表示一个实体。
2、实体属性值：
实体属性值是实体属性的具体化表示，属性值的集合表示一个实体。
3、实体类型：
用实体名及实体所有属性的集合表示一种实体类型，通常一个实体型表示一类试题。因此通过实体型可以区分不同类型的事物。
⑷ 数据库中 弱实体 是什么
依赖联系 ：在现实世界中，有些实体对一另一些实体有很强的依赖关系，即一个实体的存在必须以另一实体的存在为前提。前者就称为"弱实体"，如在人事管理系统中，职工子女的信息就是以职工的存在为前提的，子女实体是弱实体，子女与职工的联系是一种依赖联系。在ER图中用双线框表示弱实体。用箭头表示依赖联系。
⑸ 数据库有哪些类型，EXCEL数据库属于哪种类型
数据库发展30年
一、网状数据库
最早出现的是网状DBMS。网状模型中以记录为数据的存储单位。记录包含若干数据项。网状数据库的数据项可以是多值的和复合的数据。每个记录有一个惟一地标识它的内部标识符，称为码（DatabaseKey,DBK），它在一个记录存入数据库时由DBMS自动赋予。DBK可以看作记录的逻辑地址，可作记录的替身，或用于寻找记录。网状数据库是导航式（Navigation）数据库，用户在操作数据库时不但说明要做什么，还要说明怎么做。例如在查找语句中不但要说明查找的对象，而且要规定存取路径。
世界上第一个网状数据库管理系统也是第一个DBMS是美国通用电气公司Bachman等人在1964年开发成功的IDS（IntegratedDataStore）。IDS奠定了网状数据库的基础，并在当时得到了广泛的发行和应用。1971年，美国CODASYL（，数据系统委员会）中的DBTG（DataBaseTaskGroup，数据库任务组）提出了一个着名的DBTG报告，对网状数据模型和语言进行了定义，并在1978年和1981年又做了修改和补充。因此网状数据模型又称为CODASYL模型或DBTG模型。1984年美国国家标准协会（ANSI）提出了一个网状定义语言（NetworkDefinitionLanguage，NDL）的推荐标准。在70年代，曾经出现过大量的网状数据库的DBMS产品。比较着名的有Cullinet软件公司的IDMS，Honeywell公司的IDSII，Univac公司（后来并入Unisys公司）的DMS1100，HP公司的IMAGE等。网状数据库模型对于层次和非层次结构的事物都能比较自然的模拟，在关系数据库出现之前网状DBMS要比层次DBMS用得普遍。在数据库发展史上，网状数据库占有重要地位。
二、层次数据库
层次型数据库管理系统是紧随网络型数据库而出现的。现实世界中很多事物是按层次组织起来的。层次数据模型的提出，首先是为了模拟这种按层次组织起来的事物。层次数据库也是按记录来存取数据的。层次数据模型中最基本的数据关系是基本层次关系，它代表两个记录型之间一对多的关系，也叫做双亲子女关系（PCR）。数据库中有且仅有一个记录型无双亲，称为根节点。其他记录型有且仅有一个双亲。在层次模型中从一个节点到其双亲的映射是惟一的，所以对每一个记录型（除根节点外）只需要指出它的双亲，就可以表示出层次模型的整体结构。层次模型是树状的。
最着名最典型的层次数据库系统是IBM公司的IMS（Information Management System），这是IBM公司研制的最早的大型数据库系统程序产品。从60年代末产生起，如今已经发展到IMSV6，提供群集、N路数据共享、消息队列共享等先进特性的支持。这个具有30年历史的数据库产品在如今的WWW应用连接、商务智能应用中扮演着新的角色。
三、关系数据库
关系模型的建立
网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但是在数据独立性和抽象级别上仍有很大欠缺。用户在对这两种数据库进行存取时，仍然需要明确数据的存储结构，指出存取路径。而后来出现的关系数据库较好地解决了这些问题。关系数据库理论出现于60年代末到70年代初。1970年，IBM的研究员E.F.Codd博士发表《大型共享数据银行的关系模型》一文提出了关系模型的概念。后来Codd又陆续发表多篇文章，奠定了关系数据库的基础。关系模型有严格的数学基础，抽象级别比较高，而且简单清晰，便于理解和使用。但是当时也有人认为关系模型是理想化的数据模型，用来实现DBMS是不现实的，尤其担心关系数据库的性能难以接受，更有人视其为当时正在进行中的网状数据库规范化工作的严重威胁。为了促进对问题的理解，1974年ACM牵头组织了一次研讨会，会上开展了一场分别以Codd和Bachman为首的支持和反对关系数据库两派之间的辩论。这次着名的辩论推动了关系数据库的发展，使其最终成为现代数据库产品的主流。
关系数据模型提供了关系操作的特点和功能要求，但不对DBMS的语言给出具体的语法要求。对关系数据库的操作是高度非过程化的，用户不需要指出特殊的存取路径，路径的选择由DBMS的优化机制来完成。Codd在70年代初期的论文论述了范式理论和衡量关系系统的12条标准，用数学理论奠定了关系数据库的基础。Codd博士也以其对关系数据库的卓越贡献获得了1983年ACM图灵奖。
关系数据模型是以集合论中的关系概念为基础发展起来的。关系模型中无论是实体还是实体间的联系均由单一的结构类型--关系来表示。在实际的关系数据库中的关系也称表。一个关系数据库就是由若干个表组成。
SQL语言的产生和发展
1974年，IBM的Ray Boyce和Don Chamberlin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地提出了SQL（Structured Query Language）语言。SQL语言的功能包括查询、操纵、定义和控制，是一个综合的、通用的关系数据库语言，同时又是一种高度非过程化的语言，只要求用户指出做什么而不需要指出怎么做。SQL集成实现了数据库生命周期中的全部操作。自产生之日起，SQL语言便成了检验关系数据库的试金石，而SQL语言标准的每一次变更都指导着关系数据库产品的发展方向。
在SQL语言取得进展的同时，IBM研究中心于1973年开始着手SystemR项目。其目标是论证一个全功能关系DBMS的可行性。该项目结束于1979年，完成了第一个实现SQL的DBMS。1986年，ANSI把SQL作为关系数据库语言的美国标准，同年公布了标准SQL文本。目前SQL标准有3个版本。基本SQL定义是ANSIX3135-89，"Database Language - SQL with Integrity Enhancement"[ANS89]，一般叫做SQL-89。SQL-89定义了模式定义、数据操作和事务处理。SQL-89和随后的ANSIX3168-1989,"DatabaseLanguage-EmbeddedSQL"构成了第一代SQL标准。ANSIX3135-1992[ANS92]描述了一种增强功能的SQL，现在叫做SQL-92标准。SQL-92包括模式操作，动态创建和SQL语句动态执行、网络环境支持等增强特性。在完成SQL-92标准后，ANSI和ISO即开始合作开发SQL3标准。SQL3的主要特点在于抽象数据类型的支持，为新一代对象关系数据库提供了标准。
第二部分 主流关系数据库软件介绍
Codd的关系数据库理论把关系系统分为表式系统、（最小）关系系统、关系上完备的系统、全关系系统4个级别。目前尚没有一个数据库系统是完全关系系统。真正称做关系系统的应该至少是关系上完备的系统。现代的主流关系数据库产品都是关系上完备的。
一、IBM的DB2 / DB2 universal database
作为关系数据库领域的开拓者和领航人，IBM于1980年开始提供集成的数据库服务器--System/38，随后是SQL/DSforVSE和VM，其初始版本与SystemR研究原型密切相关。DB2forMVSV1在1983年推出。该版本的目标是提供这一新方案所承诺的简单性，数据不相关性和用户生产率。DB2以后的版本的重点是改进其性能、可靠性和容量，以满足广泛的关键业务的行业需求。1988年DB2forMVS提供了强大的在线事务处理（OLTP）支持，1989年和1993年分别以远程工作单元和分布式工作单元实现了分布式数据库支持。最近推出的DB2UniversalDatabase6.1则是通用数据库的典范，是第一个具备网上功能的多媒体关系数据库管理系统，支持包括Linux在内的一系列平台。其主要新功能包括：
1）提供了JavaStoredProcereBuilder支持服务器端的存储过程快速开发。
2）支持与目录服务器通讯的标准LDAP。
3）增强的转换及迁移工具。
4）扩展的DB2通用数据库控制中心，可在更多的平台下采用相同的图形工具完成管理工作。
5）提高了电子商务性能，提供多种电子商务整合方案。
6）具有强大的XML支持能力。
二、Informix的历史 ／ InformixIDS2000
Informix在1980年成立，目的是为Unix等开放操作系统提供专业的关系型数据库产品。公司的名称Informix便是取自Information和Unix的结合。
Informix第一个真正支持SQL语言的关系数据库产品是InformixSE（StandardEngine）。InformixSE的特点是简单、轻便、适应性强。它的装机量非常之大，尤其是在当时的微机Unix环境下，成为主要的数据库产品。它也是第一个被移植到Linux上的商业数据库产品。
在90年代初，联机事务处理成为关系数据库越来越主要的应用，同时，Client/Server结构日渐兴起。为了满足基于Client/Server环境下联机事务处理的需要，Informix在其数据库产品中引入了Client/Server的概念，将应用对数据库的请求与数据库对请求的处理分割开来，推出了Informix-OnLine，OnLine的一个特点是数据的管理的重大改变，即数据表不再是单个的文件，而是数据库空间和逻辑设备。逻辑设备不仅可以建立在文件系统之上，还可以是硬盘的分区和裸设备。由此提高了数据的安全性。
1993年，为了克服多进程系统性能的局限性，Informix使用多线程机制重新改写数据库核心，次年初，Informix推出了采用被称为"动态可伸缩结构"（DSA）的InformixDynamicServer。除了应用线程机制以外，Informix在数据库核心中引入了虚处理器的概念，每个虚处理器就是一个Informix数据库服务器进程。在DynamicServer中，多条线程可以在虚处理器缓冲池中并行执行，而每个虚处理机又被实际的多处理机调度执行。更重要的是：为了执行高效性和多功能的调谐，Informix将虚处理器根据不同的处理任务进行了分类。每一类被优化以完成一种特定的功能。
到90年代后期，随着Internet的兴起，电子文档、图片、视频、空间信息、Internet/Web等应用潮水般涌入IT行业，而关系数据库所管理的数据类型仍停留在数字、字符串、日期等六七十年代的水平上，其处理能力便显得力不从心了。1992年，着名的数据库学者、Ingres的创始人加州大学伯克利分校的MichaelStonebraker教授提出对象关系数据库模型，从而找到了一条解决问题的有效途径。
1995年，Stonebraker及其研发组织的加入了Informix，使之在数据库发展方向上有了一个新的突破：1996年Informix推出了通用数据选件（Universal Data Option）。这是一个对象关系模型的数据库服务器；它与其他厂商中间件的解决方案不同，从关系数据库服务器内部的各个环节对数据库进行面向对象的扩充；将关系数据库的各种机制抽象化、通用化。UniversalDataOption采用了DynamicServer的所有底层技术，如DSA结构和并行处理，同时允许用户在数据库中建立复杂的数据类型及用户自定义的数据类型，同时可对这些数据类型定义各种操作和运算以实现对象的封装。在定义操作和运算时可以采用数据库过程语言、C语言，它们经注册后成为服务器的一部分。
1999年，Informix进一步将Universal Data Option进行了优化，为用户自定义数据类型和操作过程提供了完整的工具环境。同时在传统事务处理的性能超过了以往的Dynamic Server。新的数据库核心便被命名为IDS.2000。它的目标定位于下世纪基于Internet的复杂数据库应用。
事实上，Internet的普及从Web开始。Web应用以简便和图文并茂见长。但充斥整个系统的HTML文件又将我们不知不觉地带回了文件系统的时代。采用数据库管理Internet信息遇到的第一个挑战就是复杂信息的管理问题，Internet的出现将"数据"的概念在实际应用中扩大了。为此，自1995年起，Informix便着手进行新一代数据库系统的设计。作为专业的数据库厂商，Informix首先针对Internet应用中数据类型的多样化，采用对象技术对关系数据库体系进行了扩展。与众不同之处在于，Informix并非将新的数据类型写死在数据库核心中，而是将数据库系统中各个环节充分地抽象化，使用户有能力定义和描述自己需要管理的数据类型，将可管理的数据类型扩展到无限，同时适应了未来应用发展的需要。这就是Informix今年新推出的数据库服务器--InformixDynamicServer.2000（简称IDS.2000）。
在IDS.2000中，Informix的另一重大贡献在于抽象化数据库的访问方法（索引机制和查询优化）并将其中接口开放。这样，用户便可以自己定义对复杂对象的全新的索引机制，并融入整个数据库服务器。在IDS.2000中，所有用户自定义的数据类型、操作、索引机制都将被系统与其内置的类型、操作和索引机制同等对待。IDS.2000将所有数据库操作纳入标准数据库SQL的范畴，在形式上与传统关系数据库完全兼容，但适应了"数据"概念拓展的需求，成为真正的通用数据库。Informix在IDS.2000之上增加了一系列核心扩展模块，构成了面向Internet的多功能数据库服务器Informix Internet Foundation.2000。
INFORMIX主要产品分为三大部分：
数据库服务器(数据库核心)
应用开发工具
网络数据库互联产品
数据库服务器有两种，作用都是提供数据操作和管理：
SE：完全基于UNIX操作系统，主要针对非多媒体的较少用户数的应用
ONLINE：针对大量用户的联机事务处理和多媒体应用环境
应用开发工具是用以开发应用程序必要的环境和工具，主要也有两个系列：
4GL：INFORMIX传统的基于字符界面的开发工具，该系列的主要产品有五个，他们是I-SQL、4GL RDS、4GL C COMPILER、4GL ID和ESQL/C；
NewEra：INFORMIX最新提供的具有事件驱动能力、面向对象的基于各种图形界面的开发工具。
INFORMIX的网络数据库互联产品：提供给用户基于多种工业标准的应用程序接口，通过它可以和其它遵守这些工业标准的数据库联接。
三、Sybase的历史 ／ Sybase ASE
Sybase公司成立于1984年，公司名称"Sybase"取自"system"和"database"相结合的含义。Sybase公司的创始人之一Bob Epstein是Ingres大学版（与System/R同时期的关系数据库模型产品）的主要设计人员。公司的第一个关系数据库产品是1987年5月推出的SybaseSQLServer1.0。
Sybase首先提出了Client/Server数据库体系结构的思想，并率先在自己的SybaseSQLServer中实现。在此之前，计算机信息一般都存储在单一的主机计算机中，最终用户一般都通过字符终端管理和访问主机，绝大多数的处理都由主机完成，终端主要完成输入和简单的显示功能。这种主机/终端模式的软硬件费用相当高，中小型企业一般都无法实施。在70年代末和80年代初，IT业发生了两件产生深远影响的事件：PC机和局域网络的迅速普及。PC机比终端的功能要强得多，局域网的速度也比主机终端之间的连接速度快得多，而且与主机系统相比，它们的费用也低得多，与此同时，工作站和小型机也飞速发展，在许多方面可以取代主机的功能，这些为实施Client/Server体系结构提供了硬件的基础。
在Client/Server体系结构中，服务器提供数据的存储和管理等功能，客户端运行相应的应用，通过网络可获得服务器的服务，使用服务器上的数据库资源。客户机和服务器通过网络连结成为一个互相协作的系统。Client/Server体系结构将原来运行在主机系统上的大型数据库系统进行适当的划分，在客户机和服务器之间进行合理的分配，在Sybase SQL Server中，将数据库和应用划分为以下几个逻辑功能：用户接口（User Interface）、表示逻辑（Presentation Logic）、事务逻辑（Transaction Logic）、数据存取（Data Access）。Sybase的设计思想是将事务逻辑和数据存取放在服务器一侧处理，而把用户接口、表示逻辑放在客户机上处理。
Client/Server体系结构把硬件和软件合理的配置和设计，极大地推动了当时联机企业信息系统的实现。与主机/终端模式相比，Client/Server体系结构可以更好地实现数据服务和应用程序的共享，并且系统容易扩充，更加灵活，简化了企业信息系统的开发。当信息系统的规模扩大或需求改变时，不必重新设计而可以在原有的基础上进行扩充和调整，从而保护了企业在硬件和软件上的已有的投资。
“Client/Server体系结构"很快成为企业信息建设的主要模式，对数据库乃至IT业的发展产生了深远的影响。
1989年，Sybase发布了OpenClient/OpenServer，这一产品为不同的数据源和几百种工具和应用提供了一致的开放的接口，为实现异构环境下系统的可互操作提供了非常有效的手段。
1992年11月，Sybase发布了SQLServer10.0和一系列的新产品（在此之前，SQLServer相继推出了2.0、4.2、4.8、4.9等版本），将SQLServer从一个Client/Server系统推进到支持企业级的计算环境。Sybase将此产品系列叫做System10。它是根据能支持企业级数据库（运行Sybase和其他厂商的数据库系统）来设计的。
SybaseSQLServer10.0是System10的核心。与4.9版相比，增加了许多新的特点和功能：修改过的Transact-SQL完全符合ANSI-89SQL标准以及ANSI-92入口级SQL标准，此外还增强了对游标的控制，允许应用程序按行取数据，也允许整个数据双向滚动。此外，还引入了阀值管理器。1995年，Sybase推出了SybaseSQLServer11.0。除了继续对联机事务提供强有力的支持之外，Sybase在11.0中增加了不少新功能以支持联机分析处理和决策支持系统。
为了适应现在和未来不断变化的应用需求，Sybase在1997年4月发布了适应性体系结构（Adaptive Component Architecture , ACA）。ACA是一种3层结构：包括客户端、中间层和服务器。每一层都提供了组件的运行环境，ACA结构可以按照应用需求方便地对系统的每一层进行配置，适应未来的发展要求。与ACA体系结构相适应，Sybase将SQLServer重新命名为Adaptive Server Enterprise，版本号为11.5。在ACA结构中，提出了两种组件的概念：逻辑组件和数据组件。逻辑组件是实现应用逻辑的组件，可以用Java、C/C++、Power Builder等语言来开发，可遵循目前流行的组件标准，如Corba、ActiveX和JavaBean等。而数据组件可实现对不同类型数据的存储和访问。数据组件由Adaptive Server Enterprise11.5（简称ASE11.5）提供。这些数据组件不仅可以完成传统的关系型数据的存储，而且可以支持各种复杂数据类型，用户可以根据用户需要存储的数据类型安装相应的数据存储组件，例如地理空间、时间序列、多媒体/图像、文本数据等。它代表了Sybase在解决复杂数据类型、多维数据类型和对象数据类型等方面的技术策略。
ASE11.5显着增强了对数据仓库和OLAP的支持，引入了逻辑进程管理器允许用户选择对象的运行优先级。
Sybase在1998年推出了ASE11.9.2。这一版本最大的特点是引入了两种新型的锁机制来保证系统的并发性和性能：数据页锁和数据行锁，提供了更精细的粒度控制。另外在查询优化方面也得到了改进。
----进入1999年，随着Internet的广泛使用，为了帮助企业建立企业门户应用，Sybase提出了"OpenDoor"计划，其中一个重要的组成部分就是推出了最新的面向企业门户的ASE12.0。为了满足企业门户的要求，ASE12.0在生产率、可用性和集成性方面做了显着的增强。
ASE12提供了对Java和XML良好的支持，通过完全支持分布事务处理的业界标准X/Open的XA接口标准和微软的DTC标准保证分布事务的完整性，内置高效的事务管理器（TransactionManager）可以支持分布事务的高吞吐量。
ASE12采用了群集（cluster）技术减少意外停机时间。不但支持两个服务器之间的失败转移（failover），还可支持自动的客户端的失败转移。
----ASE12提供了对ACE和Kerberos安全模式的支持，用户可以通过ACE和Kerberos提供更加安全和加密的网络通信；ASE12还提供了联机索引重建功能，在索引重建时，表中的数据仍可被访问。
在查询优化方面，ASE12引入了一种新的称为"Merge Join"的算法，可以显着提高多表连接查询的速度；通过executeimmediate语句可以执行动态SQL语句；用户可以定义永久和完整的查询方案，从而可以进行更有效的性能优化。此外，ASE12与其他Sybase产品（例如Sybase Enterprise Application Server和Sybase Enterprise Event Broker）一起提供对一个完整的标准Internet接口的支持。
⑹ 数据库中如下图叫做什么图，这些箭头虚线实线的都是什么意思
实线是正折 虚线是反折 箭头是折的方向!
⑺ 数据库中的实表、虚表、临时表的定义
实表是基本关系，又称基本表或者基表，是实际存储数据的逻辑表示，临时表是查询表，查询结果对应的结果，视图表是虚表有基本表或其他的表导出的表，不对应实际存储的数据。
⑻ 数据库中的实体,实体型,实体集解析
一、数据库设计过程
数据库技术是信息资源管理最有效的手段。
数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数据库设计的各阶段：
A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。
B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。
C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。
D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
1. 需求分析阶段
需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。
需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。
2. 概念结构设计阶段
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。
概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。
概念模型特点：
(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。
(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。
概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
2.1 第零步——初始化工程
这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。
2.2 第一步——定义实体
实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有 “代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。
2.3 第二步——定义联系
IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。
2.4 第三步——定义码
通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。
2.5 第四步——定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。
2.6 第五步——定义其他对象和规则
定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。
3. 逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
表内的每一行都应该被唯一的标识(有唯一键)。
表内不应该存储依赖于其他键的非键信息。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
5. 数据库实施阶段
运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 ，(Data Definition Language(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)
●Create (新增有关数据库结构的东西，属DDL)
●Drop (删除有关数据库结构的东西，属DDL)
●Alter (更改结构，属DDL)
6. 数据库运行和维护阶段
在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。
7. 建模工具的使用
为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。
ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用 ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。
二、数据库设计技巧
1. 设计数据库之前(需求分析阶段)
1) 理解客户需求，包括用户未来需求变化。
2) 了解企业业务类型，可以在开发阶段节约大量的时间。
3) 重视输入(要记录的数据)、输出(报表、查询、视图)。
4) 创建数据字典和ER 图表
数据字典(Data Dictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系
数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构]
数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结构]，平均流量，高峰期流量
数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式
处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
2. 表和字段的设计(数据库逻辑设计)
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
4) 表名、报表名和查询名的命名规范
(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。用 sp_company 标识存储过程，用 udf_ (或者类似的标记)标识自定义编写的函数。
字段设计原则：
1) 每个表中都应该添加的3 个有用的字段。
dRecordCreationDate，在SQL Server 下默认为GETDATE()
sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
nRecordVersion，记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因
时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。
2) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
3) 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名
对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用 _N 后缀;字符类型：_C 后缀;日期类型：_D 后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
假设有两个表：
Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
这样从数据库中选出全部数据的 SQL 语句可以写成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在没有这些前缀的情况下则写成这个样子(用别名来区分)：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。
5) 选择数字类型和文本类型的长度应尽量充足
假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
6) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。
7) 提防大小写混用的对象名和特殊字符
采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。
8) 小心保留词
要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用 DESC 作为说明字段名。后果可想而知!DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用，但得到的却是一大堆毫无用处的信息。
9) 保持字段名和类型的一致性
在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，就别在表2里把名字改成 “ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID，则为了可读性，在表2做关联时可以命名为 ABC_ID。
10) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
3. 选择键和索引(数据库逻辑设计)
参考：《SQL优化-索引》一文
4. 数据完整性设计(数据库逻辑设计)
1) 完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除;受限删除;置空值
父表中插入数据：受限插入;递归插入
父表中更新数据：级联更新;受限更新;置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：
NOT NULL;CHECK;触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键) 的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
6) 分布式数据系统
对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记，在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。
7) 关系
如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
8) 给数据保有和恢复制定计划
考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。
9) 用存储过程让系统做重活
提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语(或者其他任何语言)而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的 数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
三、数据库命名规范
1. 实体(表)的命名
1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4 个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推)
对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
举例：
定义的缩写 Sales: Sal 销售;
Order: Ord 订单;
Detail: Dtl 明细;
则销售订单明细表命名为：Sal_Ord_Dtl;
2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。
举例：
定义的缩写 Material Ma 物品;
物品表名为：Material, 而不是 Ma.
但是字段物品编码则是：Ma_ID;而不是Material_ID
3) 所有的存储值列表的表前面加上前缀Z
目的是将这些值列表类排序在数据库最后。
4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表
5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。
举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object;
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
2. 属性(列)的命名
1) 采用有意义的列名
表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;
A、如果是数据库自动生成的编码，统一命名为：ID
B、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名，即“XXXX_ID”
C、如果键是数字类型，你可以用_NO 作为后缀;
D、如果是字符类型则可以采用_CODE 后缀
E、对列名应该采用标准的前缀和后缀。
举例：销售订单的编号字段命名：Sal_Ord_ID;如果还存在一个数据库生成的自动编号，则命名为：ID。
2) 所有的属性加上有关类型的后缀
注意，如果还需要其它的后缀，都放在类型后缀之前。
注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。
3) 采用前缀命名
给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。
3. 视图的命名
1) 视图以V作为前缀，其他命名规则和表的命名类似;
2) 命名应尽量体现各视图的功能。
4. 触发器的命名(尽量不使用)
触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存储过程名
存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。
6. 变量名
变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。
7. 命名中其他注意事项
1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。
2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。
3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。
⑼ 在数据库中什么叫内嵌实体、什么是实体，实例、关系分别要具体的定义
实体是 something of significance to the business usually a noun and can be listed ,an object exists and distinguished from other objects
实例是实体的具体的例子。
关系是用来连接实体的。