博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
ER数据模型简介
阅读量:2504 次
发布时间:2019-05-11

本文共 9754 字,大约阅读时间需要 32 分钟。

The Entity-Relationship Data Model, also called ER, is one of the various you can use to reason about your data.

实体关系数据模型 (也称为ER )是可用于推理的各种之一。

In particular, it’s a conceptual data model, as it’s not linked to any particular implementation. That’s a task left to the logic data model.

特别是,它是一个概念数据模型 ,因为它没有链接到任何特定的实现。 这是逻辑数据模型的任务。

The ER Data Model is so general, so high level, that it can be implemented by a variety of completely different kinds of databases.

ER数据模型是如此通用,如此高级,以至于可以通过各种完全不同的数据库来实现。

It is great because you don’t think about the implementation details, but instead you only think about your data and how it’s organized. And while doing so, you are forced to analyze the problem in ways that you didn’t think about before.

很棒是因为您无需考虑实现细节,而只考虑数据及其组织方式 。 在这样做的同时,您不得不以以前从未想到的方式来分析问题。

I find ER diagrams great at helping you analyze a scenario where data is involved.

我发现ER图非常有助于您分析涉及数据的场景。

The ER Model gives you the tools to represent, using a graphical notation, all the data you need to model, the relations between the different kind of data, and the information associated with it.

ER模型为您提供了使用图形表示法表示需要建模的所有数据,不同类型的数据之间的关系以及与之关联的信息的工具。

There are 2 items that compose an ER Model:

组成ER模型的项目有2个:

  • the entities

    实体

  • the relations

    关系

Entities are types of data, like items or people, that have common properties.

实体是具有共同属性的数据类型,例如项或人。

Relations are the relations between entities.

关系是实体之间的关系。

Let me give you an example, let’s talk about books and their authors. We have 2 entities:

让我举一个例子,让我们谈谈书籍及其作者。 我们有2个实体

  • book

  • author

    作者

A particular book is an instance of the book entity.

特定书籍是书籍实体的实例。

Since we have 2 entities, we have 2 relations between them. One is the relation between a single book, and the authors entity. One is the relation between a single author, and the books entity. If we think about it, wre have:

由于我们有2个实体,因此它们之间有2个关系 。 一个是单本书与作者实体之间的关系。 一种是单个作者与图书实体之间的关系。 如果我们考虑一下,有:

  • a book has an author

    一本书有一位作者
  • an author can write many different books

    作者可以写很多不同的书

实体的视觉符号 (The visual notation for entities)

Given this simple example, we can start introducing the visual notation that will help us create the ER Data Model of our scenario.

给出了这个简单的示例,我们可以开始引入视觉符号,这将帮助我们创建场景的ER数据模型。

Note: There are many different ways to draw ER diagrams. I will use the one that, in my opinion, is more visual and makes more sense.

注意:有许多种绘制ER图的方法。 在我看来 ,我将使用一种更直观,更有意义的工具。

Entities are represented as rectangles, with some text in them to identify them:

实体以矩形表示,其中包含一些文本以标识它们:

Entities

关系的视觉符号 (The visual notation for relations)

The relation between entities is represented, in its most basic form, using a line that connects two relations, and a diamond with some text in it to identify the type of relation:

实体之间的关系以最基本的形式使用连接两个关系的线表示,并在菱形中添加一些文本以标识关系的类型:

Relation example

Note that I did not create 2 relations “book has author” and “author wrote book”. I made a single relation “authored” between a Book and an Author.

注意,我没有创建“书有作者”和“作者写书”这两个关系。 我在书和作者之间建立了一个“作者”关系。

基数 (Cardinalities)

Once we have a relation, we must now indicate the numbers involved. At the moment, we have many questions:

建立关系后,我们现在必须指出涉及的数字。 目前,我们有很多问题:

  • How many authors does can a book have?

    一本书可以有多少作者?
  • Can an author write multiple books?

    作者可以写多本书吗?
  • Does an author need to write at least one book to be called author?

    作者需要写至少一本书才能称为作者吗?
  • Can a book be written by multiple authors?

    一本书可以由多位作者撰写吗?
  • Can a book exist without at least an author?

    一本书至少可以没有作者存在吗?

All those are good questions to ask, and in this case I think the answers are pretty obvious. And when the answer is not obvious, you can think about the problem and add your own constrains.

所有这些都是很好的问题,在这种情况下,我认为答案非常明显。 当答案不明显时,您可以考虑问题并添加自己的约束。

There are various ways to visually indicate cardinalities on a diagram. Some prefer changing the shape of the line when it links to an entity.

有多种方法可以在图表上直观地指示基数。 有些人更喜欢在链接到实体时更改线的形状。

I do prefer numbers, which make things clearer:

我更喜欢数字,这使事情更清楚:

Cardinality example

The numbers above mean this: a book can be authored by 1 or more authors. n means any number of elements.

上面的数字表示这:一本书可以由1个或更多的作者创作。 n表示任意数量的元素。

And an author can have authored from 0 books (maybe it’s writing one now) to an infinite number of books.

一个作者可以创作0本书(也许现在正在写一本书)到无数本书。

The first is called a zero-to-many relationship. The second is a one-to-many relationship.

第一个称为零对多关系 。 第二个是一对多关系

We can also have:

我们还可以:

  • one-to-one relationships

    一对一关系

  • many-to-many relationships

    多对多关系

  • zero-to-one relationships

    零对一关系

属性 (Attributes)

Each entity can have one or more attributes.

每个实体可以具有一个或多个属性。

Let’s say we’ll use the above relationship in a bookstore. Each author has a name, a bio, a website URL.

假设我们将在书店中使用上述关系。 每个作者都有一个名称,个人简介和网站URL。

Each book has a title, a publisher, a year of publication, an ISBN. The publisher could be an entity as well, if we want. But we can also define it as an attribute of a book.

每本书都有标题,出版商,出版年份和ISBN。 如果我们愿意,发布者也可以是实体。 但是我们也可以将其定义为书的属性。

This is how we can represent the above information:

这就是我们可以表示上述信息的方式:

Attributes example

标识符属性 (Identifier attributes)

Entities must be identified by a unique key. The book entity can be uniquely identified by the ISBN attribute. Every book has a single ISBN (considering that we don’t represent a single copy of a book, but a book “title”).

实体必须由唯一的密钥标识。 图书实体可以由ISBN属性唯一标识。 每本书都有一个ISBN(考虑到我们不代表一本书的单个副本,而是代表书的“书名”)。

We identify the primary key attributes by underlying them:

我们通过将它们作为基础来识别主键属性:

Key

Author, on the other hand, has no unique identifier at the moment. Two authors can have the same name.

另一方面,作者目前没有唯一标识符。 两位作者可以使用相同的名字。

We must therefore add a unique key attribute. For example an id attribute:

因此,我们必须添加唯一的键属性。 例如id属性:

id attribute

Identifier attributes can span over multiple attributes.

标识符属性可以跨越多个属性。

For example, the passport ID and the author country uniquely identify the person, and could replace the id attribute we added:

例如,护照ID和作者所在国家/地区可以唯一标识此人,并且可以替换我们添加的id属性:

multiple attributes key

Which one to choose? It’s a matter of what makes more sense in your application. If we are modeling a bookstore, we can’t expect to have the country and passport id of all book authors. We’ll therefore use a random id we’ll choose and associate with each author.

选择哪一个? 这是什么在您的应用程序中更有意义的问题。 如果我们正在为书店建模,就不能期望拥有所有图书作者的国家/地区和护照ID。 因此,我们将使用一个随机id我们将选择该id并将其与每个作者相关联。

关系属性 (Relation attributes)

Attributes are not unique to entities. Relations can have attributes, as well.

属性不是实体唯一的。 关系也可以具有属性。

Consider we need to model a library. In addition to the book and author entities, we now introduce the reader entity, a person that borrows the book to read it. We take its name and id card number when they borrow it:

考虑我们需要对一个库进行建模。 除了书籍和作者实体之外,我们现在介绍读者实体 ,这是借用这本书来阅读的人。 我们在借用时会使用其名称和身份证号:

relation without attribute

But we still miss information. We need to know when the person borrowed the book, and the date they return it, so we can store the information about all the history of a particular book in our library. This information does not belong to either the book or reader entities; it belongs to the relation:

但是我们仍然错过信息。 我们需要知道该人何时借书以及他们归还书的日期,因此我们可以将有关特定书的所有历史的信息存储在我们的图书馆中。 此信息既不属于书籍也不属于读者实体; 它属于以下关系:

relation attributes

弱实体 (Weak entities)

We talked about primary keys above, and how the help uniquely identify an entity.

我们在上面讨论了主键,以及帮助如何唯一地标识实体。

Some entities depend on other entities for their existence, and are called weak entities.

一些实体的存在依赖于其他实体,因此称为弱实体

Suppose we need to model orders for an online shop.

假设我们需要为在线商店的订单建模。

For each order, we’ll store the order id, which starts from 1 and increases over time, the date and time it was placed, and the information about the customer, so we know who to bill and where to ship it.

对于每个订单,我们将存储从1开始并随时间增加的订单ID,下订单的日期和时间以及有关客户的信息,因此我们知道向谁付款以及在哪里发货。

Then we also need to know what they ordered. We create a weak entity “ordered item”, which represents each item in the cart at the time of checkout.

然后,我们还需要知道他们订购了什么。 我们创建一个弱实体“订购商品”,该商品代表结帐时购物车中的每个商品。

weak entity

This entity will store the item price at the moment of checkout (so when we change the price of the products on sale, it will not affect the orders already placed), the quantity of items that were ordered, and the options chosen. Say we sell t-shirts, therefore we need to store the color and size of the t-shirt ordered.

该实体将在结帐时存储商品价格(因此,当我们更改销售商品的价格时,它不会影响已经下达的订单),已订购商品的数量以及选择的选项。 假设我们出售T恤,因此我们需要存储订购的T恤的颜色和尺寸。

It is a weak entity because an ordered item entity cannot exist without an order entity.

它是一个弱实体,因为没有订单实体就无法存在订购商品实体。

递归关系 (Recursive relations)

An entity can have a recursive relation with itself. Suppose we have a person entity. We can model the parent-child relationship in this way:

实体可以与自己具有递归关系。 假设我们有一个人实体。 我们可以通过以下方式对父子关系进行建模:

recursive relation

A person can have from 0 to n children, a children has 2 parents (considering the simplest scenario).

一个人可以有0到n个孩子,一个孩子有2个父母(考虑最简单的情况)。

ISA关系 (ISA relations)

ISA stands for IS-A, and it’s a way to model generalizations in the ER model.

ISA代表IS-A,它是在ER模型中建模概括的一种方法。

We use it to group similar entities under a common umbrella. For example an author and a reader, in the case of the books and library example, can be generalized using a person entity.

我们使用它来将相似的实体归为一类。 例如,在书籍和图书馆示例的情况下,可以使用人员实体来概括作者和读者。

They both have a name, so we an extract the name up to the person entity, and just manage the peculiarities of being an author or reader in the corresponding entity:

他们都有名字,所以我们提取名字直到个人实体,然后管理相应实体中作为作者或读者的特殊性:

isa relation

非二元关系 (Non-binary relations)

Not every relationship is strictly binary. Let’s take a lesson scenario.

并非每个关系都是严格的二进制关系。 让我们来上一课。

A lesson takes place in a room of the school today at 10:00, with a teacher, talking to a class about physics.

今天10:00在学校一间教室里和一位老师一起上了一堂关于物理课的课程。

So, a lesson is given at a particular time of a day, it involves a subject, a teacher, a class, and a room.

因此,在一天的特定时间上一堂课,它涉及一个主题,一个老师,一个班级和一个房间。

We can model it in this way:

我们可以通过以下方式对其进行建模:

non-binary relation

翻译自:

转载地址:http://lmqgb.baihongyu.com/

你可能感兴趣的文章
在CentOS下安装Redis
查看>>
dockfile构建自己的tomcat
查看>>
Swift 必备开发库 (高级篇)
查看>>
【转】使用Cocoapods创建私有podspec
查看>>
YTU 2411: 谁去参加竞赛?【简单循环】
查看>>
可能的出栈序列问题
查看>>
vector--C++ STL 学习
查看>>
蜕变成蝶~Linux设备驱动之异步通知和异步I/O
查看>>
代码面试之链表
查看>>
jquery简单开始
查看>>
Android:日常学习笔记(6)——探究活动(4)
查看>>
白话插件框架原理
查看>>
Using Bytecode Outline to View Java bytecode in Eclipse
查看>>
overflow: hidden用法,不仅仅是隐藏溢出
查看>>
javaweb编程思想
查看>>
Linux中cd test和cd /test以及类似命令的区别
查看>>
[BS-26] UIView、pop和Core Animation区别
查看>>
dubbo_rpc原理
查看>>
Java设计模式之《模板模式》及使用场景
查看>>
Linux编程入门
查看>>