数据库维护与管理手册（标准版）

数据库维护与管理手册（标准版）第1章数据库基础概念1.1数据库概述数据库（Database）是存储和管理大量结构化数据的系统，通常用于支持组织的业务运作和信息管理。根据IEEE（美国电气与电子工程师协会）的定义，数据库是“一组相关数据的集合，通过系统化的结构化方式组织，以便高效地检索、更新和管理”。在计算机科学中，数据库是信息处理的核心组成部分，其设计与管理直接影响系统的性能、安全性和可扩展性。数据库技术起源于20世纪60年代，由IBM公司开发的IMS系统被认为是现代数据库系统的雏形。传统的文件系统在数据存储和管理方面存在诸多问题，如数据冗余、数据不一致、数据难以共享等，而数据库系统通过规范化设计解决了这些问题。数据库技术已成为信息时代的基础支撑技术，广泛应用于金融、医疗、教育、电子商务等多个领域。1.2数据库系统组成数据库系统（DBMS）由数据库、数据库管理系统（DBMS）、应用程序、用户接口和操作系统等多个部分组成。数据库管理系统负责数据的存储、管理、检索和安全性控制，是系统的核心组件。数据库系统通常包括数据定义语言（DDL）和数据操作语言（DML），用于定义数据结构和操作数据。数据库系统还包含事务处理机制，确保数据在并发操作下的完整性与一致性。数据库系统通过索引、视图、存储过程等技术提高数据查询效率和系统性能。1.3数据模型与规范化数据模型是描述数据结构及其关系的抽象表示，常见的数据模型包括层次模型、网络模型、关系模型和对象模型。关系模型由E.F.Codd于1970年提出，其核心思想是将数据组织为二维表格，通过关系代数进行操作，具有良好的规范化特性。数据库的规范化（Normalization）旨在消除数据冗余，减少数据不一致，提高数据的完整性和一致性。通常分为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和第四范式（4NF）等，每种范式都有特定的约束条件。例如，第三范式要求每个表中的列都依赖于主键，而非其他列，从而避免了插入和删除异常。1.4数据库的生命周期数据库的生命周期通常包括需求分析、设计、实施、运行维护和退役五个阶段。需求分析阶段需要与业务部门沟通，明确数据需求和功能要求。设计阶段根据需求制定数据结构和逻辑模型，包括ER图（实体关系图）和关系模式设计。实施阶段包括数据库安装、配置、数据迁移和用户培训等。运行维护阶段涉及日常维护、性能优化、安全管理和用户支持，是数据库长期稳定运行的关键环节。第2章数据库设计与实现2.1数据库设计原则数据库设计应遵循ACID（原子性、一致性、隔离性、持久性）原则，确保数据在事务处理中完整性与可靠性。设计应遵循规范化原则，通过范式（Normalization）减少数据冗余，提升数据一致性。应采用分层设计原则，将数据模型划分为逻辑模型、物理模型和实现模型，便于系统开发与维护。建议采用模块化设计，将数据库划分为多个独立模块，提高系统的可扩展性和可维护性。设计过程中应考虑数据安全与权限管理，遵循最小权限原则，确保不同用户访问数据的合法性与安全性。2.2数据库结构设计数据库结构设计应采用ER图（实体-关系图）进行建模，明确实体之间的关系与属性。应使用规范化技术，如第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等，确保数据的完整性与一致性。设计时应考虑数据的可查询性与可维护性，合理划分表结构，避免冗余字段。应采用规范化与非规范化相结合的方式，根据实际业务需求选择适当的范式级别。数据结构设计应结合业务流程，确保数据能够准确反映业务逻辑，提升系统运行效率。2.3数据库的物理存储物理存储涉及数据库的存储结构、索引设计与存储引擎选择。应采用B+树索引结构，提升查询效率，减少I/O操作次数。存储引擎的选择应依据性能、扩展性与兼容性，如InnoDB（支持事务与行锁）或MyISAM（支持全文索引）。应合理规划存储空间，采用分区（Partitioning）技术，提高数据管理效率与系统性能。物理存储设计需考虑数据的存储位置、页面大小、缓存策略等，以优化数据库性能。2.4数据库的实现工具数据库的实现通常使用SQLServer、Oracle、MySQL等主流数据库管理系统（DBMS）。应选择支持事务处理、高可用性与扩展性的数据库系统，如MySQL的InnoDB引擎或PostgreSQL的PostgreSQL。实现过程中应使用ERD工具（如MySQLWorkbench、Visio）进行数据库设计与建模。数据库的部署可采用分层架构，包括开发层、测试层、生产层，确保系统稳定运行。实现工具应支持版本控制与持续集成，如Git与GitHub，以提高开发效率与代码管理能力。第3章数据库维护与管理3.1数据库日常维护数据库日常维护包括定期的系统监控、日志分析和性能检查，以确保数据库运行稳定。根据《数据库系统概念》（ISBN:978-0-13-335064-7），数据库维护应包括对系统资源（如CPU、内存、磁盘I/O）的持续监控，以及时发现并处理潜在问题。日常维护还应包括对数据库表、索引、视图和存储过程的定期检查，确保其完整性与一致性。例如，使用SQL语句执行`CHECKTABLE`或`ANALYZETABLE`命令，可以提升查询性能。数据库管理员需定期清理无用数据，避免数据冗余和存储空间浪费。根据《数据库系统导论》（ISBN:978-7-115-41442-4），定期执行`PURGE`或`TRUNCATE`操作，有助于保持数据库的高效运行。对于分布式数据库系统，日常维护还应包括节点间的数据同步与故障转移机制的检查，确保高可用性。建议采用自动化工具进行日常维护，如使用监控工具（如Zabbix、Prometheus）或数据库管理工具（如MySQLWorkbench、OracleEnterpriseManager），以提高维护效率。3.2数据库性能优化数据库性能优化的核心在于减少查询延迟和提升响应速度。根据《高性能数据库设计》（ISBN:978-0-321-93614-3），优化查询语句、索引结构和执行计划是提升性能的关键。通过添加合适的索引（如B-tree、哈希索引）可以显著加快数据检索速度，但需避免过度索引导致写入性能下降。根据《数据库系统概论》（ISBN:978-7-04-004237-3），索引的合理设计需权衡查询与更新的平衡。优化查询语句时，应避免使用全表扫描（FullTableScan），改用索引字段的局部扫描。根据《数据库优化技术》（ISBN:978-7-121-15510-2），使用`EXPLN`语句分析查询执行计划，有助于识别性能瓶颈。对于大规模数据量，可采用分页查询、缓存机制（如Redis）或读写分离策略，以降低数据库负载。根据《分布式数据库系统》（ISBN:978-7-04-004237-3），读写分离能有效提升系统吞吐量。建议定期进行数据库性能调优，如通过负载均衡、资源分配调整、查询缓存策略等手段，维持数据库的稳定运行。3.3数据库备份与恢复数据库备份是保障数据安全的重要手段，应根据业务需求制定备份策略。根据《数据库系统开发与管理》（ISBN:978-7-115-41442-4），备份策略应包括全量备份、增量备份和差异备份，以实现数据的完整性和一致性。备份数据应存储在安全、隔离的环境，如异地备份或加密存储，防止数据泄露或损坏。根据《数据安全与备份技术》（ISBN:978-7-121-15510-2），建议采用RD1、RD5或RD6等存储方案，提高备份数据的可靠性。数据恢复应遵循“先备份再恢复”的原则，确保在数据丢失或损坏时能够快速恢复。根据《数据库恢复技术》（ISBN:978-7-121-15510-2），恢复操作应通过备份文件或增量备份数据进行，避免数据重复或丢失。对于频繁更新的数据库，可采用增量备份和版本控制，确保数据的可追溯性。根据《数据库管理与恢复》（ISBN:978-7-121-15510-2），版本控制工具（如Git）可辅助实现数据的版本管理与恢复。建议定期测试备份与恢复流程，确保备份数据的可用性，避免因备份失败导致业务中断。3.4数据库安全与权限管理数据库安全的核心在于防止未授权访问和数据泄露。根据《数据库安全与管理》（ISBN:978-7-115-41442-4），应通过用户权限管理、角色分配和访问控制（ACL）来实现安全防护。用户权限应遵循最小权限原则，仅授予必要的访问权限。根据《数据库安全实践》（ISBN:978-7-121-15510-2），权限管理应结合SQL语句的权限控制（如GRANT和REVOKE）进行精细化管理。数据库应配置强密码策略，定期更换密码，并启用多因素认证（MFA）。根据《网络安全与数据库安全》（ISBN:978-7-121-15510-2），密码复杂度、长度和有效期应符合行业标准。数据库日志记录和审计功能是安全的重要保障，可追踪操作行为，防止恶意行为。根据《数据库审计与安全》（ISBN:978-7-121-15510-2），日志记录应包含用户、时间、操作内容等信息，便于事后审计。应定期进行安全漏洞扫描和渗透测试，及时修补安全漏洞，确保数据库系统符合最新的安全标准（如ISO27001、NIST）。第4章数据库监控与分析4.1数据库监控工具数据库监控工具主要用于实时跟踪数据库的运行状态，如连接数、查询延迟、事务处理等关键指标。常用工具包括OracleEnterpriseManager、MySQLWorkbench、SQLServerManagementStudio（SSMS）等，这些工具能够提供详细的性能报告和告警机制。通过监控工具可以识别数据库的瓶颈，例如高并发时的锁争用、资源耗尽等问题。例如，根据IEEETransactionsonSoftwareEngineering的研究，监控工具能有效识别出数据库在高负载下的性能下降原因。现代监控工具通常支持多维度数据采集，如CPU使用率、内存占用、磁盘I/O、网络延迟等，帮助运维人员全面掌握数据库的运行状况。部分工具还具备自动化告警功能，当检测到异常指标时，会自动发送通知，例如邮件、短信或系统内告警，确保问题能及时处理。监控数据的存储和分析也是重要环节，如使用Prometheus+Grafana进行可视化，可直观展示数据库的性能趋势和异常波动。4.2数据库性能分析数据库性能分析主要通过执行计划（ExecutionPlan）和查询日志来评估查询效率。根据DB2的官方文档，执行计划能揭示查询中涉及的表、索引、函数等，从而判断查询是否优化。优化数据库性能的关键在于减少锁竞争、提升索引效率、合理设计查询语句。例如，使用EXPLN命令可以查看查询的执行路径，帮助识别全表扫描或重复查询等问题。通过性能分析工具，如Oracle的SQLTrace、MySQL的SlowQueryLog，可以记录慢查询和资源消耗情况，为后续优化提供依据。数据库性能分析还涉及负载均衡和资源分配，如通过负载均衡器分散请求，避免单一数据库节点过载。实际应用中，性能分析需结合历史数据和实时监控，定期进行性能评估，确保数据库持续稳定运行。4.3数据库日志管理数据库日志是记录数据库操作的重要文件，包括事务日志（RedoLog）、二进制日志（Binlog）和系统日志。根据DBABestPractices，日志文件应定期归档和清理，防止占用过多存储空间。日志管理需遵循一定的策略，如设置日志文件大小上限、定期备份日志、使用日志归档工具（如Oracle’sLogMiner、MySQL’sBinlogDump）等。在故障恢复和数据恢复过程中，日志是关键依据。例如，使用MySQL的Binlog可以实现数据的点对点恢复，确保数据一致性。日志管理还涉及日志的存储位置和访问权限，应确保日志文件的安全性和可追溯性，避免因日志丢失导致的数据丢失或业务中断。一些数据库系统提供日志分析工具，如PostgreSQL的pg_logfile，可帮助管理员分析日志内容，发现潜在问题。4.4数据库容量规划数据库容量规划需考虑存储、CPU、内存、网络等资源的使用情况，根据业务增长预测未来需求。例如，根据IBM的数据库容量规划指南，容量规划应结合业务增长率和数据增长趋势进行动态调整。存储容量规划需考虑数据量增长、数据保留策略、备份频率等因素。例如，使用RD10或SSD存储可提升存储性能，减少I/O等待时间。内存规划需根据数据库的内存使用模式进行分配，如使用内存池（MemoryPool）技术，合理分配内存资源，避免内存不足导致的性能下降。网络容量规划需考虑数据库的连接数、数据传输量和延迟，确保网络带宽足够支持高并发访问。例如，使用负载均衡和CDN可有效缓解网络压力。容量规划应结合实际业务需求和未来扩展计划，定期进行容量评估和调整，确保数据库系统能够满足业务增长的需求。第5章数据库故障处理与恢复5.1数据库常见故障类型数据库常见故障类型主要包括系统崩溃、数据丢失、事务不一致、锁冲突、连接超时、索引失效、日志损坏、SQL语句错误等。根据《数据库系统概念》（Korthetal.,2018）所述，系统崩溃通常由硬件故障或软件异常引起，而数据丢失则可能源于磁盘损坏或日志文件损坏。常见的事务故障包括脏读、不可重复读、幻读等，这些属于ACID特性中的问题。《数据库系统导论》（Korthetal.,2018）指出，幻读是由于未正确使用锁机制导致的，需通过行级锁或事务隔离级别来避免。锁冲突是多用户并发操作时的常见问题，可能导致数据不一致或操作阻塞。根据《数据库系统实现》（Korthetal.,2018），锁冲突通常发生在共享锁与排他锁的使用不当时，需通过合理的锁粒度和事务控制来减少冲突。日志损坏是数据库恢复的重要问题，尤其是重做日志（RedoLog）和回滚日志（UndoLog）的损坏，可能导致数据无法恢复。《数据库恢复技术》（Korthetal.,2018）指出，日志文件是数据库恢复的核心依据，必须确保日志的完整性与一致性。数据库的异常关闭或意外断电可能导致数据不一致，此时需通过事务回滚或备份恢复。根据《数据库系统管理》（Korthetal.,2018），数据库的恢复策略应包括自动备份、增量备份和全量备份，以确保数据安全。5.2故障处理流程故障处理流程通常包括故障发现、初步分析、定位问题、隔离影响、恢复数据、验证修复、总结经验等步骤。根据《数据库系统管理》（Korthetal.,2018），故障处理应遵循“快速响应、准确定位、有效修复、持续改进”的原则。在故障处理过程中，应优先排查系统日志、监控工具和数据库日志，以确定问题根源。例如，使用数据库的慢查询日志（SlowQueryLog）或性能监控工具（如MySQL的PerformanceSchema）来定位性能瓶颈。针对不同类型的故障，应采用不同的处理方式。例如，对于事务故障，可使用事务回滚或重试机制；对于数据丢失，需通过备份恢复或数据重建。故障处理应确保业务连续性，避免对正常业务造成影响。根据《数据库系统管理》（Korthetal.,2018），处理故障时应优先恢复关键业务数据，再处理非关键数据。处理完成后，应进行故障复盘，分析原因并制定改进措施，防止类似问题再次发生。5.3数据库恢复策略数据库恢复策略主要包括备份策略、日志恢复、数据恢复、事务恢复等。根据《数据库恢复技术》（Korthetal.,2018），备份策略应遵循“定期备份、增量备份、全量备份”原则，确保数据的可恢复性。日志恢复是数据库恢复的核心方法之一，包括重做日志（RedoLog）和回滚日志（UndoLog）的恢复。根据《数据库系统导论》（Korthetal.,2018），日志记录了所有事务的修改操作，是恢复数据的重要依据。数据恢复通常分为全量恢复和增量恢复。全量恢复是基于完整备份的数据恢复，而增量恢复则基于备份后的数据变化进行恢复。根据《数据库系统管理》（Korthetal.,2018），增量恢复可以减少恢复时间，提高恢复效率。事务恢复涉及事务的提交与回滚，确保事务的ACID特性。根据《数据库系统导论》（Korthetal.,2018），事务恢复可通过重做日志（RedoLog）实现，确保事务在发生故障时能够恢复到一致状态。恢复策略应结合业务需求，制定合理的恢复时间目标（RTO）和恢复点目标（RPO），确保在最短时间内恢复数据并维持业务连续性。5.4故障应急响应机制故障应急响应机制应包含预案制定、响应流程、资源调配、沟通协调、事后分析等环节。根据《数据库系统管理》（Korthetal.,2018），应急预案应覆盖各种常见故障场景，并明确各角色的职责。应急响应流程通常包括故障发现、确认、上报、处理、验证、总结等阶段。根据《数据库系统管理》（Korthetal.,2018），在故障发生后，应立即启动应急响应，避免问题扩大。应急响应机制需配备专门的应急团队，包括数据库管理员（DBA）、系统管理员、备份专家等。根据《数据库系统管理》（Korthetal.,2018），应急团队应具备快速响应和解决问题的能力。在应急响应过程中，应保持与业务部门、IT支持团队的沟通，确保信息透明，避免信息不对称。根据《数据库系统管理》（Korthetal.,2018），沟通应遵循“快速、准确、清晰”的原则。应急响应后，应进行总结分析，评估响应效果，优化应急预案，提升整体故障处理能力。根据《数据库系统管理》（Korthetal.,2018），定期演练和复盘是提升应急响应能力的重要手段。第6章数据库的扩展与高可用6.1数据库扩展方法数据库扩展通常采用横向扩展（HorizontalScaling）和纵向扩展（VerticalScaling）两种方式。横向扩展是指增加更多节点，通过负载均衡技术实现资源的横向分布，如采用MySQLCluster或OracleRAC等分布式数据库系统。纵向扩展则通过提升单节点的硬件配置（如CPU、内存、存储）来增强性能。在横向扩展中，通常采用主从复制（Master-SlaveReplication）或主主复制（Master-MasterReplication）模式。主从复制通过读写分离实现读操作的高并发，而主主复制则适用于需要多节点协同处理的场景，如金融交易系统。采用分片（Sharding）技术是横向扩展的常见手段，根据业务规则将数据划分到不同的物理节点上，例如基于用户ID、订单ID或时间戳进行分片。分片可以提升查询性能，但需注意数据一致性与故障转移问题。在扩展过程中，需考虑数据一致性机制，如使用MySQL的GTID（事务ID）或Oracle的RedoLog，确保在扩展节点间数据同步的可靠性。横向扩展时，应结合负载均衡（LoadBalancing）技术，如Nginx或HAProxy，将请求分发到不同的节点，避免单点故障，提升系统的可用性与性能。6.2高可用性架构设计高可用性（HighAvailability,HA）是数据库系统的核心目标之一，通常通过冗余设计、故障转移（Failover）和自动恢复（AutoRecovery）实现。例如，采用Oracle的RAC（RealApplicationClusters）或MySQL的GaleraCluster，实现多节点协同工作。在高可用架构中，通常需要配置多个节点，每个节点承担不同的职责，如主节点处理写操作，从节点处理读操作，或作为备用节点在主节点故障时接管服务。为确保高可用性，需设计合理的故障转移策略，如使用心跳检测（HeartbeatDetection）和自动切换（AutomaticSwitching），在检测到主节点故障时，快速切换到备用节点，避免服务中断。高可用架构还需考虑数据一致性，如采用分布式事务（DistributedTransactions）或两阶段提交（Two-PhaseCommit）机制，确保在节点故障时数据不会丢失或损坏。高可用性设计还需考虑网络延迟与容错，如使用分布式存储（如Ceph、HDFS）或数据复制（DataReplication）技术，确保在节点故障时仍能访问数据。6.3数据库集群管理数据库集群（DatabaseCluster）通常由多个节点组成，每个节点负责一部分数据和事务处理。集群管理涉及节点的启动、停止、故障转移、负载均衡等操作。在集群管理中，常用工具包括集群管理软件（如Corosync、MCR、Keepalived）和监控工具（如Prometheus、Zabbix）。这些工具可实现节点状态的实时监控与自动管理。集群管理需遵循一定的策略，如节点间通信协议（如IPMI、SSH）、数据同步机制（如Raft、Paxos）、以及集群的选举机制（如Quorum）。这些机制确保集群在故障时能够快速恢复。集群管理需定期进行健康检查与日志分析，及时发现并处理潜在问题，如节点宕机、数据不一致等，以保障集群的稳定运行。集群管理还涉及性能调优，如调整节点数量、优化网络配置、调整数据库参数等，以确保集群在高负载下仍能保持良好的性能。6.4数据库的横向扩展横向扩展（HorizontalScaling）是通过增加服务器节点来提升系统性能与可用性，常见于大规模数据处理场景。例如，采用Kubernetes集群管理数据库节点，实现弹性伸缩。在横向扩展中，通常采用容器化技术（如Docker、Kubernetes）部署数据库实例，通过自动化调度（AutoScaling）动态调整节点数量，以适应流量波动。横向扩展需考虑数据一致性与网络延迟问题，如使用分布式锁（DistributedLock）或一致性哈希（ConsistentHashing）技术，确保数据在多个节点间同步。横向扩展还涉及数据备份与恢复策略，如定期进行数据备份（如RMAN、AWSS3），并在节点故障时快速恢复数据，避免服务中断。横向扩展需结合负载均衡与监控工具，如Prometheus+Grafana，实时监控节点状态与性能指标，确保系统稳定运行。第7章数据库的版本管理与升级7.1数据库版本控制数据库版本控制是确保数据库在不同版本之间迁移和更新时保持一致性的关键手段，通常采用版本号（VersionNumber）进行标识，如MySQL的版本号格式为“5.7.30”或PostgreSQL的“13.2”。采用版本控制工具如Git，可以实现对数据库对象、表结构、存储过程等的版本跟踪，支持回滚、分支管理与合并操作，符合ISO/IEC20000标准中的变更管理要求。数据库版本控制需遵循变更管理流程，确保每次更新前进行兼容性检查，避免因版本不兼容导致的数据丢失或服务中断。企业级数据库通常采用主从复制（Master-SlaveReplication）或读写分离（Read-WriteSplitting）策略，以保障版本升级时的高可用性与数据一致性。依据《数据库系统概念》（DatabaseSystemConcepts）中的描述，版本控制应结合生命周期管理，定期进行版本审计与回滚测试，确保版本更新的可控性与可追溯性。7.2数据库升级流程数据库升级通常包括规划、准备、实施、验证与回滚等阶段，需遵循“最小化停机时间”原则，避免对业务造成影响。在升级前，应进行环境兼容性测试，包括系统配置、依赖库、存储引擎等，确保升级后的数据库能够正常运行。升级过程中，应使用增量迁移（IncrementalMigration）或全量迁移（FullMigration）方式，根据数据库类型（如Oracle、MySQL、SQLServer）选择合适的迁移工具。升级后需进行性能调优与功能验证，确保新版本的稳定性与性能满足业务需求，符合《数据库性能优化指南》中的标准。依据《数据库迁移与升级最佳实践》（DatabaseMigrationandUpgradeBestPractices），升级应记录日志并进行版本对比，确保升级过程可追溯。7.3数据库迁移与兼容性数据库迁移涉及从一个版本迁移到另一个版本，需考虑数据类型、索引、存储引擎等差异，迁移前应进行数据一致性检查。为提升迁移效率，可采用数据泵（DataPump）或导出导入工具（如SQLServer的BULKINSERT），确保迁移过程中数据完整性与一致性。为保证兼容性，应遵循数据库厂商的兼容性文档，如MySQL的官方兼容性矩阵或PostgreSQL的版本兼容性说明。在迁移过程中，需验证新版本的配置参数（如字符集、排序规则、日志级别）是否与旧版本一致，避免因配置差异导致功能异常。依据《数据库迁移技术白皮书》（DatabaseMigrationTechnologyWhitePaper），迁移前应进行数据备份与测试环境验证，确保迁移后系统稳定运行。7.4数据库的版本回滚数据库版本回滚是指在版本升级失败或出现严重问题时，将数据库恢复到之前稳定版本的操作，通常通过版本号回退实现。回滚操作需在版本更新前进行，确保回滚后的数据库状态与升级前一致，避免数据丢失或服务中断。回滚过程中，应使用版本控制工具（如Git）进行历史版本的恢复，同时记录回滚日志，便于后续审计与问题排查。依据《数据库系统可靠性管理》（DatabaseSystemReliabilityManagement），回滚应遵循“最小化影响”原则，优先恢复关键业务数据，再逐步恢复其他数据。在回滚后，需重新进行性能测试与功能验证，确保系统恢复到稳定状态，符合《数据库系统可靠性标准》中的要求。第8章数据库的文档与培训8.1数据库文档编写规范数据库文档应遵循统一的命名规范与格式标准，如《GB/T18826-2016数据库系统术语》中所规定的术语定义，确保文档内容的准确性和可读性。文档应包含数据库结构图、数据字典、操作手册、维护记录等关键内容，符合《ISO/IEC20000-1:2018质量管理体》中关于信息系统的文档管理要求。文档编写需采用标准化工具，如ER/Studio、SQLDeveloper等，确保数据结构与逻辑关系的清晰表达，避免歧义。文档应定期更新，反映数据库的变更情况，如《数据库系统概念》（ISBN978