❶ oracle 会话连接数什么意思
连接数据库采用会话的模式。会话连接数是说的是最多可以支持同时多少个连接连到数据库。因为数据库系统也会管理进程的。
❷ 什么是数据库连接连接和会话之间有什么关系
原理上和网站的一个session差不多，只是session是把key放在cookie里面，数据库连接是把key放在客户端的library的内存里（比如.Net Sql Client)。对MS SQL来说，这个连接的协议叫TDS，底下可以走多种传输层协议，比如tcpip，也可以named pipe。而MySQL就又有自己的协议。当然在拿到key之前，先要走个authentication过程，比如Windows Authentication或者Sql authentication，过了authentication才会产生一个session key。如果是启用SSL的话那么整个连接上的数据流还会被加密，防止信息泄露或者中间人攻击。
❸ windows自带性能监控器问题
你要滴在任务管理器里全部都有 ALT +DEL+ CTRL
Windows 性能监视器工具
如果需要在一台计算机上监视多个 Report Server 实例，可以同时或单独监视这些实例。选择要包括的实例是计数器添加过程的一部分。有关使用 Windows 附带的性能工具的更多信息，请参见微软 Windows 产品文档。
若要访问性能工具
• 从“开始”菜单上选择“运行”。
• 在“打开”文本框中输入“perfmon”，然后单击“确定”。
• 在性能监视器工具中，在左侧窗格里选择 System Monitor 对象，然后右击“性能”图表。
• 选择“添加计数器”。
现在，可以开始选择这些对象和要监视的计数器了。
ASP.NET 应用程序性能计数器
有关 ASP.NET 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 ASP.NET 应用程序（包括 Reporting Services）性能的重要计数器。
性能对象 计数器 实例 描述
Processor（处理器）
% Processor Time（处理器时间百分比）
__Total
“% Processor Time”监视运行 Web 服务器的计算机的 CPU 利用率。低 CPU 利用率或者无法最大化 CPU 利用率（无论客户端负载为多少）都表明 Web 应用程序中存在对资源的争用或锁定。
Process（进程）
% Processor Time（处理器时间百分比）
aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）
由 ASP.NET 工作进程所使用的处理器时间所占的百分比。在将标准负载情况下的性能与先前捕获的基准进行对比时，如果此计数器的值出现下降，则说明降低了对处理器的需求，因此也提高了伸缩性。
Process（进程）
Working Set（工作集）
aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）
由 ASP.NET 主动使用的内存数量。虽然应用程序开发人员对应用程序使用的内存数量拥有最大的控制权，但系统管理员也可通过调整会话的超时期限来显着影响这一点。
Process（进程）
Private Bytes（专有字节）
aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）
Private Bytes 是当前分配给该进程且不能由其他进程共享的内存数量（以字节计）。不时出现的尖峰表明某些地方存在瓶颈，会导致工作进程继续持有不再需要的内存。如果此计数器突然下降为接近 0 的值，则可能表示 ASP.NET 应用程序由于无法预料的问题进行了重启。为了验证这一点，请监视“ASP.NET Application Restarts”计数器。
ASP.NET Applications（ASP.NET 应用程序）
Requests/ Sec（每秒的请求数）
__Total
允许您检验请求的处理速度是否于发送速度相适应。如果每秒请求数的数值低于每秒产生的请求数，则会出现排队现象。这通常意味着已经超过了最大请求速度。
ASP.NET Applications（ASP.NET 应用程序）
Errors Total（总错误数）
__Total
在执行 HTTP 请求期间发生的错误总数。包括任何分析器、编译或运行时错误。此计数器是“Errors During Compilation”（编译错误数）、“Errors During Preprocessing”（预处理错误数）和“Errors During Execution”（执行错误数）计数器的总和。运转正常的 Web 服务器不应产生任何错误。如果错误发生在 ASP.NET Web 应用程序中，它们的存在可能会让实际的吞吐量结果产生偏差。
ASP.NET
Request Execution Time（请求执行时间）
显示了呈现所请求页面并将其传送给用户所需的时间（以毫秒计）。跟踪此计数器通常要比跟踪页面呈现时间效果更好。此计数器可以更全面地衡量从开始到结束的整个请求时间。在与基准进行对比时，如果此计数器的平均值较低，则说明应用程序的伸缩性和性能均得到了改善。
ASP.NET
Application Restarts（应用程序重新启动）
应用程序在 Web 服务器生存期间发生重新启动的次数。每次发生 Application_OnEnd 事件时，应用程序的重新启动次数都会增加。应用程序进行重新启动的原因可能是：更改了 Web.config 文件、更改了存储在应用程序的 \bin 目录下的程序集、或者 Web Forms 页面中发生了太多的更改。如果此计数器的值出现意料之外的增加，说明某些不可预知的问题导致 Web 应用程序被关闭。在这种情况下，应该认真调查问题原因。
ASP.NET
Requests Queued（排队的请求数）
在队列中等待服务的请求数。如果此数字随着客户端负载的增加而呈现线性的增长，则说明 Web 服务器计算机已经达到了它能够处理的并发请求极限。此计数器的默认最大值为 5,000。您可以在计算机的 Machine.config 文件中更改此设置。
ASP.NET
Worker Process Restarts（工作进程重新启动）
工作进程在服务器计算机上重新启动的次数。如果出现意料之外的故障或者被有意回收，则工作进程会重新启动。如果此计数器的值出现意料之外的增加，应认真调查问题原因。
除了上表中介绍的这些核心监视要素之外，在您试图诊断 ASP.NET 应用程序具有的特定性能问题时，下表中的性能计数器也可对您有所帮助。
性能对象 计数器 实例 描述
ASP.NET Applications（ASP.NET 应用程序）
Pipeline Instance Count（管线实例计数）
__Total
指定 ASP.NET 应用程序的活动请求管线实例的数量。由于只有一个执行线程可以在管线实例内运行，所以此数值反映了为特定应用程序处理的并发请求的最大数量。大多数情况下，在存在负载的情况下此数值较低为佳，这表明处理器得到了很好的利用。
.NET CLR Exceptions（.NET CLR 异常）
# of Exceps Thrown（引发的异常数）
显示应用程序中引发的异常数。如果此数值出现意料之外的增加，说明可能存在性能问题。如果仅仅存在异常，则并不需要担心，因为异常对于某些代码路径来说是正常工作的一部分。例如，HttpResponse.Redirect 方法通过引发一个不可捕获的异常 ThreadAbortException 来完成工作。同样，对 ASP.NET 应用程序跟踪此计数器也更加有用。使用“Errors Total”计数器确定该异常是否将导致应用程序出现意料之外的错误。
System（系统）
Context Switches/ sec（每秒的上下文切换次数）
测量 Web 服务器计算机上所有处理器切换线程上下文的速度。如果此计数器的值很高，可能表示对锁的争用频繁发生，或者在线程的用户模式和内核模式之间切换频繁。使用采样优化程序和其他工具执行进一步调查可证实上述猜测。
Reporting Services 性能计数器
Reporting Services 包括一组它自己的性能计数器，用于收集有关报告处理和资源消耗方面的信息。可通过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。
MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器，这些处理过程通常通过在线交互式报告浏览操作而引发。这些计数器在 ASP.NET 停止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器，并描述了它们的目的。
性能对象：RS Web Service
计数器 描述
Active Sessions（活动会话数）
活动会话的数量。此计数器反映了尚未过期的所有浏览器会话总数。这并不是同时处理的请求数，而是存储在 ReportServerTempDB 数据库中的会话数量。
Cache Hits/Sec（每秒缓存命中次数）
每秒从目录中取得的报告请求的数量。如果此值增加，而“Memory Cache Hits”的值不增加，则说明报告数据没有被重新处理，但是页面被重新呈现。将此计数器与 Memory Cache Hits/Sec 计数器一同使用，可以确定用于缓存、磁盘或内存的资源是否充足。
Cache Misses/Sec（每秒缓存未命中数）
每秒未能从目录中（与内存中相对）返回报告的请求数量。将此计数器与 Memory Cache Misses/Sec 计数器一同使用，可以确定用于缓存、磁盘或内存的资源是否充足。
First Session Requests/Sec（每秒的首次会话请求数）
每秒中从 Report Server 缓存中启动的新的用户会话数量。
Memory Cache Hits/Sec（每秒内存缓存命中数）
每秒中从内存中的缓存里取得报告的次数。内存中缓存是 Reporting Services 缓存的一部分，用于在内存或临时文件中保存已呈现过的报告。这样可以为请求提供最佳的性能，因为无需执行任何处理工作。如果使用内存中缓存，报告服务器将不会通过查询 SQL Server 来获得缓存的内容。
Memory Cache Misses/Sec（每秒内存缓存未命中数）
每秒中未能从内存中的缓存里取得报告的次数。
Next Session Requests/Sec（每秒的下一次会话请求）
每秒在现有会话中请求打开报告的次数。
Report Requests（报告请求）
当前处于活动状态并且将由 Report Server 进行处理的报告数量。
Reports Executed/Sec（每秒执行的报告数）
每秒成功执行的报告的数量。此计数器提供了有关报告处理量的统计信息。综合使用此计数器和 Request/Sec，比较可从缓存中返回的报告请求的执行情况。
Requests/Sec（每秒的请求数）
每秒向 Report Server 发出的请求数。此计数器跟踪由 Report Server 处理的所有类型的请求。
Total Cache Hits（缓存命中总数）
自服务启动以来，从缓存中获得报告的请求总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。
Total Cache Misses（总的缓存未命中数）
自服务启动以来，不能从缓存中获得报告的总次数。此计数器在 ASP.NET 停止该 Web 服务后被重设。可使用此计数器确定磁盘空间和内存是否充足。
Total Memory Cache Hits（总的内存缓存命中数）
自服务启动以来，从内存中缓存里返回的已缓存报告的总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。内存中缓存是在 CPU 内存中存储报告的那部分缓存。如果使用内存中缓存，报告服务器将不会通过查询 SQL Server 来获得缓存的内容。
Total Memory Cache Misses（总的缓存未命中数）
自服务启动以来，针对内存中缓存的缓存未命中总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。
Total Processing Failures（处理故障总数）
自服务启动以来，发生的所有报告处理故障的总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。处理故障可能来自报告处理器，也可能来自任何扩展。
Total Reports Executed（执行的报告总数）
自服务启动以来得到成功执行的报告的总数。
Total Requests（总请求数）
自服务启动以来，向 Report Server 发送的所有请求的总数。
RS Windows Service 性能对象包括一组用于跟踪报告处理过程的计数器，这些处理过程是通过预定操作而引发的。预定操作可能包括订阅和交付、报告执行快照以及报告历史。微软的工作负载中并不包含任何预定操作或交付操作，此处列出这些性能计数器仅是便于您进行参考。
可使用此性能对象监视 Report Server Windows 服务。如果您准备在一个横向伸缩配置中运行 Report Server，那么这些计数器应用于所选的服务器，而不是应用于横向伸缩配置整体。这些计数器在应用程序域回收之时将被重设。下表列出了可用于监视预定和交付操作的计数器，并描述了它们的目的。
性能对象：RS Windows Service
计数器 描述
Cache Flushes/Sec(每秒缓存刷新次数)
每秒刷新缓存的次数。
Cache Hits/Sec（每秒缓存命中数）
每秒获取到缓存报告的请求数量。
Cache Misses/Sec（每秒缓存未命中数）
每秒未能从缓存中获得报告的请求的数量。
Delivers/Sec（每秒交付数）
每秒从各种交付扩展交付的报告的数量。
Events/Sec（每秒事件数）
每秒处理的事件数量。被监视的事件，包括 SnapshotUpdated 和 TimedSubscription。
Memory Cache Hits/Sec（每秒内存缓存命中数）
每秒中从内存中的缓存里取得报告的次数。
Memory Cache Misses/Sec（每秒内存缓存未命中数）
每秒中未能从内存中的缓存里取得报告的次数。
Report Requests（报告请求数）
当前处于活动状态并且将由 Report Server 进行处理的报告数量。可使用此计数器评估缓存策略。向特定呈现扩展提交的请求数。请求的数量可能比执行的报告数量多许多。
Reports Executed/Sec（每秒执行的报告数）
每秒成功执行的报告的数量。
Snapshot Updates/Sec（每秒快照更新数）
每秒报告执行快照的预定更新数量。
Total App Domain Recycles（应用程序域回收总数）
自服务启动以来回收的应用程序域总数。
Total Cache Flushes（缓存刷新总数）
自服务启动以来，Report Server 的缓存更新总数。
Total Cache Hits（缓存命中总数）
自服务启动以来，从缓存中获得报告的请求总数。
Total Cache Misses（总的缓存未命中数）
自服务启动以来，不能从缓存中获得报告的总次数。
可使用此计数器确定是否需要更多磁盘空间或内存。
Total Deliveries（总交付数）
由 Scheling and Delivery Processor 交付的报告总数（对于所有交付扩展）。
Total Events（总事件数）
自服务启动以来发生的事件的总数。
Total Memory Cache Hits（总的内存缓存命中数）
自服务启动以来，从内存中缓存里返回的已缓存报告的总数。
Total Memory Cache Misses（总的缓存未命中数）
自服务启动以来，针对内存中缓存的缓存未命中总数。
Total Processing Failures（处理故障总数）
自服务启动以来，发生的所有报告处理故障的总数。处理故障可能来自报告处理器，也可能来自任何扩展。
Total Rejected Threads（被拒绝的线程总数）
拒绝执行异步处理后在同一线程中作为同步过程在以后进行处理的数据处理线程总数。
Total Report Executions（报告执行总数）
已执行报告的总数。
Total Requests（请求总数）
自服务启动以来得到成功执行的报告的总数。
Total Snapshot Updates（快照更新总数）
自服务启动以来，报告执行快照进行更新的总数。
如果您打算排除 Reporting Services 存在的性能问题，记录以下性能计数器通常很有帮助：ASP.NET、ASP.NET Applications、Process、System、Memory、Physical Disks、.NET Exceptions、.NET Memory、.NET Loading、.NET CLR Locks and Threads 以及 .NET CLR Data。
可选的 Reporting Services 性能计数器
以下列出了一些适用于 RS Web Service 但在默认情况下并未安装的性能计数器。但是，在执行性能优化工作时，可以通过这些计数器来改善您洞察性能的能力。为实现这个目的，请在命令提示符中执行以下语句：
installutil.exe /u ReportingServicesLibrary.dll
然后再执行：
installutil.exe ReportingServicesLibrary.dll
为了成功执行该语句，您可能首先需要修改您的路径，在路径中包含 Microsoft .NET Framework 的安装目录。在路径修改完毕后，请从包含 ReportingServicesLibrary.dll 文件的目录下执行先前语句。默认情况下，该文件安装在 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.instance\Reporting Services\ReportServer\bin 目录下。这些计数器没有进行彻底的本地化。
Active Database Connections（活动数据库连接）
某个时间处于活动状态的数据库连接的数量。只统计指向 Report Server 目录的连接。
Active Datasource Connections（活动数据源连接）
某个时间处于活动状态的数据库连接的数量。只统计由当前运行的报告打开的数据源连接。
Active Threads（活动线程）
当前处于活动状态的线程数量。在 Web 服务中，它包含一些为请求提供服务的线程。在交付服务中，它包含工作线程以及维护和轮询线程。
Byte count（字节计数）
对于上一次请求，在呈现当前报告时向客户端返回的字节数量。这与对应的执行日志条目相类似。
Row Count（行计数）
对于上一次请求，由当前报告返回的行的数量。这与对应的执行日志条目相类似。
Time in Compression（压缩时间）
对于上一次请求，在快照和 PDF 报告压缩上花费的时间（以毫秒计）。
Time in data source access（数据源访问时间）
对于上一次请求，在获取报告的数据源信息上花费的时间（以毫秒计）。其中包括执行查询和取回结果所需的时间。这与对应的执行日志条目相类似。
Time in database（数据库时间）
对于上一次请求，在获取 Report Server 目录信息上花费的时间（以毫秒计）。
Time in processing（处理时间）
对于上一次请求，在报告处理上花费的时间（以毫秒计）。这与对应的执行日志条目相类似。
Time in rendering（呈现时间）
对于上一次请求，在呈现报告上花费的时间（以毫秒计）。这与对应的执行日志条目相类似。
❹ 数据库的基本功能是什么
网络不仅仅为我们提供了一个相互通信的途径，而且还是一个有史以来人类最丰富的信息资源库，还是一庞大的，可供人们相互交流思想的自由论坛，还是一场当代高技术与商贸相结合的电子商务革命。
Internr主要可以帮助网上用户实现以下基本功能：
（1）收发电子邮件
收发电子邮件是Internet最基本且使用很广泛的服务之一，人们使用Internr电子邮件系统可方便、快捷、经济地与世界各地联网的用户收发邮件。普通国际邮件一般要一周左右才能送达，而电子邮件则在转瞬间完成邮件发送，价格约为普通邮件的1/10～1/5，由于多用途的邮件协议（MIME），使用电子邮件系统可以发送多媒体信息（包括图像、文本文件、声音等）。电子邮件提高了人们对信息的利用速度和利用水平，从而使电子邮件成为最受人欢迎的通信方式，它正在逐渐取代传统的邮政系统，在Internr用户较多的国家，传统的邮政系统已经受到严重的冲击。
（2）网络文件传输服务
在Internr发展早期，网络中许多文件信息特别是电脑共享自由软件，是以匿名网络文件传输（Aobryroods，FTP），在网络中进行传递的，它对Internr的发展起了很重要的作用，就是现在，网络文件传输服务在Internr信息传输中仍是不可缺少的。
人们使用网络文件传输服务可以下载各种实用软件、数据、文件等，对信息共享、传送、交流具有十分重要的意义。
（3）网络信息资源检索
Internr作为一个有史以来人类最大最丰富的信息知识空间，目前它的信息量近乎是无限的。它的信息资源主要存放在世界各地的网络服务器中，它的信息内容极其广泛，包括艺术、建筑、文学、商业投资、国际贸易、经济、教育、联机图书馆数据库、娱乐、电影、音乐、时实新闻、杂志、报纸、体育、游戏、政治、军事、法律、科学、技术、环境、宗教等，五花八门，应有尽有。
目前，Internr的资源以WWW超文本信息内容最为丰富，WWW检索工具的访问使用率最高。主要的WWW检索引擎有：Yahoo、AltaVista、BigBook公司、EXeife、Infoseek、Lyeos公司、WebnCrawler，上述检索引擎一般向用户提供两种检索方式，即目录检索和关键词检索。
总之，只要你需要信息，就可以直接进行网络检索，获取信息，为我所用。
（4）Internr网络新闻
在Internr中，还有一个世界范围的自由论坛，即网络新闻。它利用Internr网络通信系统进行网络新闻传输。网络新闻是免费的，它包括8000多个专题，涉及的内容极其丰富，任何一个人都可以从中找到自己感兴趣的题目，并与世界各地互不相识的人们进行问题讨论和思想交流。
通过网络新闻，你可以向世界各地素不相识的人们提问，并陈述自己的观点和意见。如果你经常阅读网络新闻，你将从中获取许多有益的帮助，它将成为你的良师益友。
除了网络新闻USENET外，读者还可以通过www网址：http://www.cnn.com浏览Internr多媒体新闻，它是由美国有线新闻网络CNN在Internr上建立的WWW新闻站点，CNN是世界上最大的从事电视新闻的公司。读者通过该站点不仅可以浏览CNN发布的世界各地新闻内容，还可以获取有关天气、运动、科技、保健、娱乐等信息内容，包括北京地区四天内的天气预报。
❺ SQL 请问SQL高手，系统中的这几个数据库都是做什么用的
数据：计算机中用来描述事物的记录
数据模型：是一种对客观事物抽象化的表现形式。数据模型应该真实、易于理解、便于实现
建模：对客观事物加以抽象，提取主要特征，归纳成一个简单清晰的轮廓，使复杂问题变得易于处理
数据模型三要素：数据结构、数据操作、完整性约束
数据结构描述静态特征，按数据结构可以把数据模型分为层次模型、网状模型、关系模型
数据操作描述动态特征，数据操作主要分为更新（插入、删除、修改）、检索两大类，统称增、删、改、查
完整性约束确保数据的正确性、有效性、相容性
数据库：简称DB(database)，是由数据库管理系统管理的数据的聚集
数据库管理系统:简称DBMS(DataBase Management System)是专门用于建立和管理数据库的一套软件，介于应用程序和操作系统之间。属于系统软件
数据库系统：简称DBS（DataBase System)。数据库、DBMS、应用程序和软件系统统称数据库系统
关系：关系就是一张二维表
关系模型：数据以关系的形式表示，就是以二维表的形式表示数据模型
属性：关系的标题栏中各列的名字
模式：关系的名称和关系的属性集
元组：二维表的所有行统称为元组，元组的各个分量对应于关系的各个属性。一个元组表示一个对象
域：关系的每个属性的取值范围
关系的实例：给定关系中元组的集合称为该关系的“实例”。一个给定的关系模式，可以有许多关系实例。
关系型数据库管理系统：简称RDBMS(Relationg DataBase Management System)，采用关系数据模型的数据库管理系统。
数据库系统的体系结构的三层结构和两层映象：从数据库管理的角度出发，数据库系统的体系可分三层，外模式、模式、内模式。两层映象是，外模式/模式映象、模式/内模式映象
外模式：又称用户模式，相当于SQL中的视图（VIEW)模式，是数据库用户可以看见和使用的局部数据的逻辑结构和特征描述，是与某应用有关的数据的逻辑表示
模式：分为概念模式、逻辑模式，是所有数据库用户的公共数据视图，是数据库中全部数据的逻辑结构和特征的描述，一个数据库只有一个模式
外模式/模式映象：把局部逻辑结构描述与全局逻辑结构描述联系起来。一个模式可以与多个外模式对应联系。例如，SQL SERVER中一个关系模式上可以建立多个满足不同用户要求的视图VIEW。这种映象可以保证数据与应用程序之间的逻辑独立性，即改变模式，不影响外模式，则与外模式相关的应用程序无序修改
内模式：由称为存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。内模式描述记录的存储方式、索引的组织方式、数据是否压缩、是否加密等，不涉及硬件设备。
模式/内模式映象：把全局逻辑结构描述与物理结构描述联系起来。一个模式只有一个内模式。这种映象保证了数据与程序之间的物理独立性，当内模式修改时，由于模式未变，所以无需修改程序。
DBMS的体系结构（组成）：查询处理程序、存储管理程序、事务管理程序、客户/服务器程序体系结构
查询处理程序：负责查询处理，它的一个重要任务是“优化”查询。
事务管理程序：保证多个事务并发执行
存储管理程序：既管理磁盘上的数据文件又管理存放数据文件部分内容的内存数据缓冲区
客户/服务器程序体系结构：大多数DBMS程序采用这种程序体系结构，把整个DBMS程序系统划分为两部分，DBMS核心部分属于服务器程序，客户程序主要用于与用户相互配合并将查询或其他命令传送给服务器程序的查询接口。
数据库设计
数据库设计的步骤：需求分析、概念设计、逻辑设计、物理设计
需求分析和概念设计阶段的工作与具体数据库管理系统无关，这一阶段的工作独立于数据库管理系统
逻辑设计和物理设计阶段的共组与具体采用何种数据库管理系统相关。
需求分析阶段：应用领域的调查、定义信息与应用、定义操作任务、定义数据项、预测未来改变，结果产生相关文档
概念设计阶段：也称为建模
任务：数据库概念模式（模式）设计、事务设计
概念模式设计的工具：E/R图。对于面向对象的数据库则可采用面向对象定义语言ODL
E/R图：称为实体-联系模型
E/R图的组成：实体集（矩形）、属性（椭圆）、联系（菱形）
联系的类型：一对一、一对多、多对多。用线条和箭头表示不同的联系。箭头指向的一方代表“一”
键码属性的表示：下划线
联系中的角色：即一个实体集内部实体之间的联系
多向联系：多个实体集之间发生的一个联系
多向联系转化为双向联系的方法：将多向联系转换成实体集，然后在原来与之联系的实体集和新的实体集之间建立新的双向联系
E/R图中的子类的表示方法和继承：如果实体集B是实体集A的子类，则它们之间用一个标有isa的三角形和两根线条建立特殊的联系。三角形的尖端指向超类（父类），子类实体集上只需标出子类特有的属性，继承父类的所有属性。
ODL对象定义语言：是用面向对象的术语来说明数据库结构的一种推荐的标准语言，主要用途是书写面向对象数据库的设计
对象：是某种可研究，可观察的实体，例如：一个人、一门课程、一本书等等
类：具有相似特性的对象可以归为一类
ODL描述的三种特性：属性（Attribute)、联系（Relationship)、方法(Method)
ODL书写规则：
interface 类名1{
attribute 数据类型1 属性名1；
attribute 数据类型2 属性名2；
.
.
.
relationship [Set]<类名2> 联系名1
inverse 类名2::联系名2；
.
.
}
说明：
关键字interface、attribute、relationship、<set>、inverse
常用数据类型有string（字符串）、integer（整型）、float（浮点型）、enum（枚举型）
[]中的set为任选项，当类1与类2的联系是一对一时，不需要使用set，当类1与类2的联系是一对多时必须使用set
inverse表示在类2中联系名2所表示的联系与类1中联系名1所表示的联系是多对一的对应联系
ODL例一：用ODL描述制片公司与电影，假如制片公司部名称不重复。因为，一个制片公司可以制作多部影片，而一部影片只能由一个公司制作发行，所以制片公司与影片的关系是一对多的关系。
interface studio{
attribute string studioname;
attribute string address;
attribute string phone;
relationship set<movie> make
inverse movie::madeby;
}
interface movie{
attribute string movietitle;
attribute integer length;
attribute enum incolor ;
attribute integer year;
relationship set studio madeby
inverse studio::make;
}
ODL例二：用ODL描述学生与课程，一名学生可以选择多门课程来学习，一门课程可以被多名学生选修。
interface student{
attribute string sname;
attribute string address;
attribute enum gender ;
attribute integer age;
relationship set<course> choice
inverse course::choisedby;
}
interface course{
attribute string ctitle;
attribute integer credit;
relationship set<student> choisedby
inverse student::choice;
}
ODL例三：用ODL描述校长与学校的关系，一名校长只能管理一所学校，一所学校只能设一名校长。
interface chairman{
attribute string chname;
attribute enum gender ;
attribute integer age;
attribute string phone;
relationship set university manage
inverse university::leadby;
}
interface university{
attribute string unnmae;
attribute string addr;
relationship set chairman leadby
inverse chairman::manage;
}
ODL子类描述方法：自类继承父类的所有属性和联系。子类可以有自己的特殊属性和联系。子类中属性和联系的描述方法与上述例子相同。
interface 子类名:基类名
ODL子类描述例：硕士研究生类是学生的一个子类。每名硕士研究生有若干名导师，一名导师可以带多名硕士研究生。
interface student{
attribute string sname;
attribute string address;
attribute enum gender ;
attribute integer age;
}
interface master:student{
attribute string special;
relationship set<advisor> direct
inverse advisor::directedby;
}
interface advisor{
attribute string name;
attribute string address;
}
逻辑设计阶段：把概念设计阶段产生的数据库概念模式变换为数据库逻辑模式。数据库逻辑模式依赖于逻辑数据模型和数据库管理系统。目前做流行的数据库管理系统都是关系型逻辑数据模型。所以，本教程知讨论如何把概念模式转变为关系模型
逻辑设计阶段的步骤：
1.概念模式转变为关系模型
2.对关系模型进行规范化和优化
3.适应DBMS限制条件的修改
4.对性能、存储空间等的优化
1.概念模式转变为关系模型
E/R图转变为关系模型的方法：
1.一个实体集转变为一个关系模式，这个关系模式包含实体集所有的简单属性和复合属性的简单子属性。实体集的名称可以用作为关系模式的名称，用下划线来表示关系的键码
2.一个联系转变为一个关系模式，一般情况下用联系名作为关系名，用联系的实体集的键码和联系本身的属性作为此关系模式的属性集。
E/R图转变为关系模型实例：
实例一：一个班级只能有一个班长，而且必须有一个班长，E/R图如下：
学生与班级的联系是一对一的联系(1:1)。学生实体集的键码是学号。班级实体集的键码是班号。这个E/R图可以转变为如下的关系模型
学生（学号，姓名，性别，出生日期）
班级（班号，名称，地点）
班长（学号，班号，注册）
联系反映的是具有某学号的学生担任具有某班号班级的班长。这种转变方法是常用的方法。
如果想减少查询时使用连接操作的次数，提高查询效率，以上E/R图也可以转变为如下关系模型
学生（学号，姓名，性别，出生日期，班号）
班级（班号，名称，地点）
学生关系模式中的“班号”是外键码。这种关系模式中，由于学生关系中记录了所有学生的学号，但不是每个学生都担任班长（按教科书上的术语叫做不是全参与），因此不是每个元组的班号属性都有数据，即应该允许班号为空。否则，学生实体集必须是全参与，即每个学生都是班长。
实例二：一个影片公司可以制作多部影片，但是一部影片只能归一个制片公司所有。假如公司不重名，影片也不重名，则公司名称是制片公司实体集的键码，影片名是影片实体集的键码。
影片公司与影片的联系是1对多的联系（1：N)。这个E/R图可以转变为以下关系模型
影片公司（公司名称，地点）
影片（影片名，片长）
制作（公司名称，影片名）
同样，假如影片公司是全参与，即每个影片公司至少制作了一部电影，则可以转变为以下关系模型
影片公司（公司名称，地点，影片名）
影片（影片名，片长）
其中，影片公司关系中的影片名是外键码
实例三：学生与课程之间的联系是“选修”。一个学生可以选多门课程，一门课程可以被多名学生选修，所以它们之间的“选修”联系是多对多(N:M)
上述E/R图可以转变为以下关系模型
学生（学号，姓名）
课程（课程号，课程名）
选修（学号，课程号，成绩）
选修关系中的学号和课程号是外键码
2.对关系模型进行规范化和优化
为什麽要把关系模型规范化：为了有效地消除关系中存在的数据冗余和更新异常等现象
基本概念
函数依赖：如果关系R的两个元组在属性A1，A2，...An上一致，则它们的另一个属性B上也一致，那末，我们就说在关系R中属性B函数地依赖于属性A1，A2，...An或者说属性A1，A2，...An函数决定属性B。
关系的键码：
如果一个或多个属性的集合满足如下条件，则称该集合为关系R的键码（key):
1.这些属性函数决定该关系的所有其它属性。
2.的任何真子集都不能函数决定R的所有其它属性。
关系的超键码：包含键码的属性集称为超键码，是“键码的超集”的简称
函数依赖规则：分解/合并规则、传递规则、平凡依赖规则
平凡依赖：对于函数依赖A1，A2，...An->B，如果B是A中的某一个，我们称这种依赖是平凡依赖
非平凡依赖：对于函数依赖A1，A2，...An->B，如后B中至少有一个不在A中，我们称这种依赖是非平凡依赖
完全非平凡依赖：对于函数依赖A1，A2，...An->B，B中没有一个在A中，我们称这种依赖是完全非平凡依赖
主属性：键码所在的属性
非主属性：键码以外的属性
封闭集（闭包）对于给定的函数依赖集S，属性集A函数决定的属性集合就是属性集A在依赖集S下的封闭集
范式就是符合某一种级别的关系模式的集合。
规范化通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化
1范式（1NF)，如果一个关系模式R的所有属性都是不可分割的基本数据项，则这个关系属于1NF
2范式(2NF),若关系模式R属于1NF，且每个非主属性都完全依赖于键码，则R属于2NF
3范式（3NF),若关系模式R属于1NF，且每个非主属性都不传递依赖于键码，则R属于3NF
BC范式（BCNF),若关系模式属于1NF，且R的每个非平凡依赖的决定因素都包含键码，则R属于BCNF
规范化分解原则：无损连接、保持依赖
无损连接：当对关系模式R进行分解时，R的元组将分别在相应属性集进行投影而产生新的关系，如果对新的关系进行自然连接得到的元组的集合与原关系完全一致，则称为无损连接
保持依赖：如果分解后的总的函数依赖集与原函数依赖集保持一致，则称为保持依赖。
模式分解的两个规则：公共属性共享、相关属性合一
公共属性共享：保留公共属性，进行自然连接是分解后的模式实现无损连接的必要条件
相关属性合一：把以函数依赖的形式联系在一起的相关属性放在一个模式中，从而使原有的函数依赖得以保持，这是分解后的模式实现保持依赖的充分条件
模式分解的三种方法
一、部分依赖归子集；完全依赖随键码——用于建立2NF
例：关系R(A,B,C,D,E,F,G)上存在函数依赖,A->BCD,E->F,AE->G,AE->BCD,AE->F
分析以上依赖可以看出，AE是键码（AE->BCD)。因为AE是键码，A是主属性，A->BCD，所以BCD是部分依赖于AE
根据部分依赖归子集的方法，因为A是AE的真子集，所以A与BCD归在一起构成一个关系模式。R1(A,B,C,D)
同理对于AE->F，有E->F所以AE->F是部分依赖，非主属性F所依赖的真子集是E，所以E和F可以归在一个关系模式中R2(E,F)
AE->G是完全函数依赖，完全依赖随键码，所以AEG归在一个关系模式中R3(A,E,G)
因此R(A,B,C,D,E,F,G)可以分解为符合2NF的关系模式如下:
R1(A,B,C,D)
R2(E,F)
R3(A,E,G)
二、基本依赖为基础，中间属性做桥梁——用于建立3NF
例：关系R(A,B,C,D,E)上存在函数依赖,AB->C,C->D,D->E
显然中间桥梁是C->D，他构成了传递依赖链，因此，R可以分解为R1(A,B,C),R2(C,D)。分解后在R1，R2中都不存在传递依赖。
三、找违例自成一体，舍其右全集归一；若发现仍有违例，再回首如法炮制——用于建立BCNF
BCNF违例：违背BC范式的函数依赖称为BC范式违例
例：关系R(A,B,C,D,E)的键码是AB,有函数依赖AB->CDE,ABC->E,C->D
分析上述三个函数依赖可以看出，C->D是BCNF违例。因为它的决定因素不包含键码。我们作如下分解
违例自成一体，即CD构成一个关系模式R1(C,D)
舍其右全集归一，即从R的属性中取掉C->D的右边的属性D，其左边的属性C与其他所有属性构成一个新的关系R2(A,B,C,E)
新的关系模式如下：
R1(C,D)
R2(A,B,C,E)
注意：以BCNF违例为基础进行模式分解，最终得到的属于BCNF的关系模式都能实现无损连接，但未必能保持函数依赖
逻辑设计例一：假如有关系模式R(A,B,C,D)和函数依赖集S=。
（1）找出所有BCNF违例。
（2）如果该关系模式不是BCNF，则将它分解为BCNF
（3）找出所有的违背3NF的依赖
（4）如果该关系不是3NF，则将它分解为3NF
步骤一：找出R在S上的所有非平凡依赖，首先计算封闭集
单属性封闭集：A+=A,B+=BCD,C+=C,D+=D
双属性封闭集：AB+=ABCD,AC+=AC,AD+=AD,BC+=BCD,BD+=BCD,CD+=CD
三属性封闭集：ABC+=ABCD,ABD+=ABCD,BCD+=BCD,ACD+=ACD
四属性封闭集：ABCD+=ABCD
步骤二：根据计算所得的封闭集，找出键码和超键码
键码：AB
超键码：ABC,ABD,ABCD
步骤三：找出所有的非平凡函数依赖
B->C,B->D,AB->C,AB->D,BC->D,BD->C,ABC->D,ABD->C
其中，AB->C,AB->D,ABC->D,ABD->C不是BCNF违例，因为前两个依赖的决定因素本身就是键码，而后两个依赖的决定因素包含键码。所以，B->C,B->D,BC->D,BD->C是BCNF违例，因为它们的决定因素都不包含键码。实际上可以看出R不是2NF，因为存在部分函数依赖：ABC->D,ABD->C,AB->C,AB->D,B->C,B->D
步骤四：进行BCNF规范。BCNF违例自成一体。从以上BCNF违例中选择B->C自成一体
R1(B,C)
舍其右全集归一，即舍去B->C的右边属性C，所以得到
R2(A,B,D)
但是在R2中还存在BCNF违例B->D，因此B->D自成一体，得到R21(B,D),舍其右全集归一得到R22(A,B)
最后得到的关系模式是：R1(B,C),R21(B,D),R22(A,B)
通过关系模式分解，把一个非2NF的关系模式归范成一个BCNF。代价是，在实际操作中增加了连接操作。
（3）B->C,B->D，B不是键码也不是超键码，而C,D都是键码以外的属性，即是非主属性。所以R不是3NF。
逻辑设计例二：有关系R(A,B,C,D)和函数依赖集S=
（1）找出所有BCNF违例。
（2）如果该关系模式不是BCNF，则将它分解为BCNF
（3）找出所有的违背3NF的依赖
（4）如果该关系不是3NF，则将它分解为3NF
步骤一：找出R在S上的所有非平凡依赖，首先计算封闭集
单属性封闭集：A+=ABCD,B+=ABCD,C+=ABCD,D+=ABCD
双属性封闭集：AB+=ABCD,AC+=ABCD,AD+=ABCD,BC+=ABCD,BD+=ABCD,CD+=ABCD
三属性封闭集：ABC+=ABCD,ABD+=ABCD,BCD+=ABCD,ACD+=ABCD
四属性封闭集：ABCD+=ABCD
步骤二：找出所有非平凡函数依赖
A->B,A->C,A->D,B->A,B->C,B->D,C->A,C->B,C->D,D->A,D->B,D->C
AB->C,AB->D,AC->B,AC->D,AD->B,AD->C,BC->A,BC->D,BD->A,BD->C,CD->A,CD->B
ABC->D,ABD->C,BCD->A,ACD->B
步骤三：找出键码和超键码
键码：A,B,C,D
超键码：AB,AC,AD,BC,BD,CD,ABC,ABD,BCD,ACD,ABCD
根据以上结果分析，R是3NF也是BCNF
3NF要求不存在每个非主属性对于键码的部分依赖或传递依赖
练习：对于
1.R(A,B,C,D)和函数依赖集S=
2.R(A,B,C,D,E)和函数依赖集S=
3.R(A,B,C,D,E)和函数依赖集S=
（1）找出所有BCNF违例。
（2）如果该关系模式不是BCNF，则将它分解为BCNF
物理设计阶段：任务是在数据库逻辑设计的基础上，为每个关系模式选择合适的存储结构和存取路径
物理设计阶段步骤：
（1）分析影响数据库物理设计的因素；
（2）为关系模?
请参考
❻ 什么是SQL会话
会话（SESSION）：当你连接到数据库用户时就建立了会话。相当于处理SQL语句的一个平台。
连接到数据库用户开始到退出数据库结束会话就是会话的一个生命周期。