《数据库设计艺术》- UML 数据建模

Database

Design

需积分: 4 138 浏览量更新于2024-08-01 收藏 4.1MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Database Design for Smarties.pdf" 是一本由 Robert J. Mueller 撰写的书籍，主要讨论如何使用统一建模语言（UML）进行数据建模。这本书由 Morgan Kaufmann Publishers 出版，是 Academic Press 的一个分支品牌。本书涵盖了数据库设计的基本概念、方法和最佳实践，特别是如何利用 UML 工具来提高数据库设计的效率和质量。在数据库设计领域，UML（Unified Modeling Language）是一种广泛使用的建模语言，它提供了图形化的表示方式，用于描述软件系统的结构和行为。在书中，作者可能详细介绍了如何使用 UML 类图、用例图、序列图和状态图等不同类型的图表来表示数据库中的实体、关系以及业务流程。这些工具对于理解复杂的数据关系、识别用户需求和创建高效的数据模型至关重要。数据库设计是软件开发过程中的关键步骤，它直接影响到系统的性能、可扩展性和维护性。本书可能会涵盖以下知识点： 1. **概念建模**：介绍如何使用实体-关系（E-R）模型来抽象和表示现实世界中的实体、属性和关系，这是数据库设计的基础。 2. **逻辑设计**：讲解如何将概念模型转化为关系模型，包括确定数据类型、约束条件、键和索引的设计。 3. **物理设计**：讨论如何优化数据库的物理结构，如表的分区、索引策略、存储方式等，以提高查询性能。 4. **UML在数据库设计中的应用**：详细阐述如何使用UML图（如类图、用例图）来捕捉需求和设计细节，以及如何将这些图转化为实际的数据库模式。 5. **范式理论**：解释第一范式（1NF）、第二范式（2NF）、第三范式（3NF）以及更高范式，以及它们在减少数据冗余和提高数据一致性中的作用。 6. **数据库规范化**：描述如何通过规范化过程来消除数据冗余和提高数据独立性，以及在实践中如何平衡规范化和性能之间的权衡。 7. **反规范化和维度建模**：在特定场景下，如何适当反规范化以提高查询效率，以及在数据仓库中使用的星型和雪花型模式。 8. **数据库设计的案例研究和最佳实践**：提供真实世界的例子，展示如何处理复杂的设计问题，并给出成功设计的策略。 9. **变更管理和版本控制**：讨论在数据库设计过程中如何有效地管理变更，以及使用版本控制系统（如Git）来跟踪和协同工作。 10. **性能调优**：介绍数据库性能评估和优化的方法，包括查询分析、索引优化和存储调整。此外，书中可能还包含关于数据库设计原则、数据完整性、安全性、并发控制以及与软件工程其他方面的集成等内容。读者通过阅读此书，不仅可以深化对数据库设计的理解，还能学习到如何利用 UML 更专业地进行数据建模，提升自己的数据库设计技能。

资源详情

资源推荐

has followed a tortuous path in the last three decades. Early hierarchical and flat-file

databases have developed into networked collections of pointers to relations to

objects… and mixtures of all of these together. These data models all fit within a more

slowly evolving model of database system architecture. Architectures have moved from

simple internal models to the CODASYL DBTG (Conference on Data Systems

Languages Data Base Task Group) network model of the late 1960s [CODASYL DBTG

1971] through the three-schema ANSI/SPARC (American National Standards

Institute/Standards Planning and Requirements Committee) architecture of the 1970s

[ANSI 1975] to the multitier client/server and distributed-object models of the 1980s and

1990s. And we have by no means achieved the end of history in database architecture,

though what lies beyond objects hides in the mists of the future.

The data architecture, the architectural abstraction you use to model your persistent data,

provides the second dimension to database design. Although there are other kinds of

database management systems, this book focuses on the three most popular types:

relational (RDBMS), object-relational (ORDBMS), and object-oriented (OODBMS). The

data architecture provides not only the structures (tables, classes, types, and so on) that

you use to design the database but also the language for expressing both behavior and

business rules or constraints.

Modern database design not only reflects the underlying system architecture you choose,

it derives its essence from your architectural choices. Making architectural decisions is as

much a part of a database designer's life as drawing entities and relationships or

navigating the complexities of SQL, the standardized relational database language. Thus,

this book begins with architecture before getting to the issue at hand… design.

System Architectures

A system architecture is an abstract structure of the objects and relationships that make

up a system. Database system architectures reveal the objects that make up a

data-centric software system. Such objects include applications components and their

views of data, the database layers (often called the server architecture), and the

middleware (software that connects clients to servers, adding value as needed) that

establishes connections between the application and the database. Each architecture

contains such objects and the relationships between them. Architectural differences often

center in such relationships.

Studying the history and theory of system architecture pays large rewards to the

database designer. In the course of this book, I introduce the architectural features that

have influenced my own design practice. By the end of this chapter, you will be able to

recognize the basic architectural elements in your own design efforts. You can further

þÿu( PDF ˆýO\]å^à Šfu(rHg,^úzË PDFhttp://www.fineprint.com

hone your design sense by pursuing more detailed studies of system architecture in other

sources.

The Three-Schema Architecture

The most influential early effort to create a standard system architecture was the

ANSI/SPARC architecture [ANSI 1975; Date 1977]. ANSI/SPARC divided

database-centric systems into three models: the internal, conceptual, and external, as

Figure 2-1 shows. A schema is a description of the model (a metamodel). Each schema

has structures and relationships that reflect its role. The goal was to make the three

schemas independent of one another. The architecture results in systems resistant to

changes to physical or conceptual structures. Instead of having to rebuild your entire

system for every change to a storage structure, you would just change the structure

without affecting the systems that used it. This concept, data independence, was critical

to the early years of database management and design, and it is still critical today. It

underlies everything that database designers do.

For example, consider what an accounting system would be like without data

independence. Every time an application developer wanted to access the general ledger,

he or she would need to program the code to access the data on disk, specifying the disk

sectors and hardware storage formats, looking for and using indexes, adapting to

"optimal" storage structures that are different for each kind of data element, coding the

logic and navigational access to subset the data, and coding the sorting routines to order

it (again using the indexes and intermediate storage facilities if the data could not fit

entirely in memory. Now a database engineer comes along and redoes the whole mess.

That leaves the application programmer the Herculean task of reworking the whole

accounting system to handle the new structures. Without the layers of encapsulation and

independence that a database management system provides, programming for large

databases would be impossible.

Note

Lack of data independence is at least one reason for the existence

of the Year 2000 problem. Programs would store dates in files

using two-byte storage representation and would propagate that

throughout the code, then use tricky coding techniques based

onthe storage representation to achieve wonders of optimized

programming (and completely unmaintainable programs).

þÿu( PDF ˆýO\]å^à Šfu(rHg,^úzË PDFhttp://www.fineprint.com

methods of the classes. In an objectrelational database, it contains the relational

structures as well as the extended type or class definitions, including the class or type

methods that represent object behavior. The database management system provides a

query and data manipulation language, such as the SELECT, INSERT, UPDATE, and

DELETE statements of SQL.

The internal model has the structure of storage and retrieval. It represents the "real"

structure of the database, including indexes, storage representations, field orders,

character sets, and so on. The internal schema supports the conceptual schema by

implementing the high-level conceptual structures in lower-level storage structures. It

supplies additional structures such as indexes to manage access to the data. The

mapping between the conceptual and internal models insulates the conceptual model

from any changes in storage. New indexes, changed storage structures, or differing

storage orders of fields do not affect the higherlevel models. This is the concept of

physical data independence. Usually, database management systems extend the data

definition language to enable database administrators to manage the internal model and

schema.

The external model is really a series of views of the different applications or users that

use the data. Each user maps its data to the data in the conceptual schema. The view

might use only a portion of the total data model. This mapping shows you how different

applications will make use of the data. Programming languages generally provide the

management tools for managing the external model and its schema. For example, the

facilities in C++ for building class structures and allocating memory at runtime give you

the basis for your C++ external models.

This three-level schema greatly influences database design. Dividing the conceptual from

the internal schema separates machine and operating system dependencies from the

abstract model of the data. This separation frees you from worrying about access paths,

file structures, or physical optimization when you are designing your logical data model.

Separating the conceptual schema from the external schemas establishes the

many-to-one relationship between them. No application need access all of the data in the

database. The conceptual schema, on the other hand, logically supports all the different

applications and their datarelated needs.

For example, say Holmes PLC (Sherlock Holmes's investigative agency, a running

example throughout this book) was designing its database back in 1965, probably with

the intention of writing a COBOL system from scratch using standard access path

technology such as ISAM (Indexed Sequential Access Method, a very old programming

interface for indexed file lookup). The first pass would build an application that accessed

hierarchically structured files, with each query procedure needing to decide which primary

þÿu( PDF ˆýO\]å^à Šfu(rHg,^úzË PDFhttp://www.fineprint.com

or secondary index to use to retrieve the file data. The next pass, adding another

application, would need to decide whether the original files and their access methods

were adequate or would need extension, and the original program would need

modification to accommodate the changes. At some point, the changes might prove

dramatically incompatible, requiring a complete rewrite of all the existing applications.

Shall I drag in Year 2000 problems due to conflicting storage designs for dates?

In 1998, Holmes PLC would design a conceptual data model after doing a thorough

analysis of the systems it will support. Data architects would build that conceptual model

in a database management system using the appropriate data model. Eventually, the

database administrator would take over and structure the internal model, adding indexes

where appropriate, clustering and partitioning the data, and so on. That optimization

would not end with the first system but would continue throughout the long process of

adding systems to the business. Depending on the design quality of the conceptual

schema, you would need no changes to the existing systems to add a new one. In no

case would changes in the internal design require changes.

Data independence comes from the fundamental design concept of coupling, the degree

of interdependence between modules in a system [Yourdon and Constantine 1979;

Fenton and Pfleeger 1997]. By separating the three models and their schemas, the

ANSI/SPARC architecture changes the degree of coupling from the highest level of

coupling (content coupling) to a much lower level of coupling (data coupling through

parameters). Thus, by using this architecture, you achieve a better system design by

reducing the overall coupling in your system.

Despite its age and venerability, this way of looking at the world still has major value in

today's design methods. As a consultant in the database world, I have seen over and over

the tendency to throw away all the advantages of this architecture. An example is a

company I worked with that made a highly sophisticated layout tool for manufacturing

plants. A performance analysis seemed to indicate that the problem lay in inefficient

database queries. The (inexperienced) database programmer decided to store the data in

flat files instead to speed up access. The result: a system that tied its fundamental data

structures directly into physical file storage. Should the application change slightly, or

should the data files grow beyond their current size, the company would have to

completely redo their data access subroutines to accommodate new file data structures.

Note

As a sidelight, the problem here was using a relational database

for a situation that required navigational access. Replacing the

relational design with an object-oriented design was a better

solution. The engineers in this small company had no exposure to

OO technology and barely any to relational database technology.

þÿu( PDF ˆýO\]å^à Šfu(rHg,^úzË PDFhttp://www.fineprint.com

剩余463页未读，继续阅读

mxmcool

粉丝: 2
资源: 10

《数据库设计艺术》- UML 数据建模

MK.Joe.Celkos.Trees.and.Hierarchies.in.SQL.for.Smarties

Database Modeling and Design.5th.2011

秒达开源多功能中文工具箱源码：自部署 全开源 轻量级跨平台 GPT级支持+高效UI+Docker

双极 AMI 的加扰以及 B8ZS 和 HDB3 加扰simulink.rar

C项目开发资源.docx

基于ssm的在线购物系统的设计与实现设计与实现.docx

python-对Excel数据处理做可视化分析.zip

logisim-hust-20200118.zip

springboot小说阅读平台的设计毕业论文.docx

混合动力汽车动态规划算法理论油耗计算与视频教学，使用matlab编写快速计算程序，整个工程结构模块化，可以快速改为串联，并联，混

OS20单缸发动机模型3D图纸 STP格式.zip

labelimg制作VOC数据集并用yolov5训练目标检测模型

全球与中国飞机管道市场现状及未来发展趋势（2024版）.docx

ssm+mysql的企业人事管理系统（源码+lw+ppt）

茶铺门店小程序.zip

jsp通讯录信息系统课程设计源码

前向和后向快速潮流求解MATLAB程序.rar

springboot基于推荐算法的在线课程推荐系统设计与实现毕业论文.docx

键合图附加模块库 BG V.2.1.rar

丹尼尔·哈伊夫勒_宏观肌肉模型simulink.rar

最新资源

秒达开源多功能中文工具箱源码：自部署全开源轻量级跨平台 GPT级支持+高效UI+Docker