标签: database-theory

当数据库开始一个事务时，在该事务中执行的所有语句都是孤立的和原子的（一致和持久的）。这些几乎是交易的定义。

维基百科指出，有一些数据库通过锁定行并在事务提交之前不解锁它们来确保事务保持隔离。

我的问题是：完全依赖锁的数据库如何保证一致性？如果在事务中间发生断电，则可能会有部分数据写入该行。

即使对于像 SQL Server 这样使用临时数据库来执行所有事务的数据库，如果在数据库将事务提交到磁盘时发生断电，会发生什么？

数据是否已损坏或数据库是否正确处理？

在参考互联网和教科书时，我遇到了两种规范化程序。即。

类型 1。范式仅基于主键。

在这种类型中，

-> 2NF 不允许部分依赖于主键。

-> 3NF 不允许对主键的传递依赖。

类型 2。基于所有候选键的更通用的范式

在这种类型中，

考虑了所有候选键的部分依赖和传递依赖。

在我提到的大多数网站中，我找到了仅基于第一种类型的教程和注释。但是 Navathe 和 Elmasri 的教科书“数据库系统基础”描述了这两种类型。甚至维基百科关于 2NF 的页面也分别提到了基于第二种类型的“2NF 和候选键”。

参见2NF 和候选键 - Wiki

但是教科书和维基都没有提到关于哪种类型更好或哪种类型实际上更受欢迎的任何内容。

当没有提到类型时应该遵循哪种类型？希望你明白我的问题。

请帮我解决这些家伙。

在我的Databases演讲中，老师提到SQL不仅仅是一种数据定义语言（DDL）、数据操作语言（DML）和视图定义语言（VDL），还是一种存储定义语言（SDL）。最后的用法没有任何进一步的解释或示例。

在 Internet 上搜索有关使用 SQL 作为 SDL 的额外信息不会产生任何相关结果。谁能举一个使用 SQL 作为存储定义语言的例子？

编辑：

像 MySQL 这样的规范会SET storage_engine=MYISAM;算作存储定义吗？它并没有真正涉及到数据存储，而是如何将存放。

这个问题是关于教学的：当我学习数据库时，我们谈到索引就像镇图书馆的卡片目录。我们至少有一个作者索引，一个标题索引，然后杜威十进制数是这本书的访问路径，就像数据库中的整个记录​​。

图书？什么，纸上谈兵？抽屉里的索引卡？

年轻人真的不知道我在说什么，那么我们现在如何最好地解释它？

（随意享受我的草坪，请认清预科学校的草地和人造草坪的区别，好吗？）

在我的数据库设计课程中，我们学习了关系代数和关系微积分。我可以看到关系代数在哪里有用，因为它与 SQL 密切相关。

我们的教授说，在一些 RDMBS 中，关系微积分被用作 SQL 的替代品，其中大部分已不再存在。关系微积分还有实际用途，还是大部分是理论性的？

查看名称数据操作语言 (DML)我会假设，所有包含的语句实际上都是用于操作数据。

据我所知该SELECT语句只能用于查询数据，不能更改它。（INSERT ... SELECT这里不考虑。）

所以是SELECTDML 的一部分，如果是，为什么？

假设我有一张学生表，其中包含他们的 ID 和成绩：

-----------------
| id  |  grade  |
-----------------
|  1  |    83   |
|  2  |    94   |
|  3  |    92   |
|  4  |    78   |

我如何编写引用最高分的学生的元组关系微积分公式？

我的尝试：

从 SQL 的角度考虑，我会编写一个查询，该查询对表与自身进行笛卡尔乘积，取比其他等级低的每个等级，然后从原始表中减去。但是，在元组关系演算中，不可能在子查询中构建子表，这就是我被卡住的原因。

但是，我在这个方向尝试了一些东西：

{ <id> | ? grade1 ? students (id, grade) ? ? grade2 ? students (id, grade2) ? grade1 > grade2}

我相信这会让我获得较低的成绩，但是我如何从原始学生表中减去所有这些？我不允许将此语句插入到另一个 TRC 查询中。在此先感谢您的帮助！

假设有实体称为singulars，实体称为relationships。

singulars组成一个relationships实体正好需要两个。

那对单数不能relationships以任何顺序在中的其他地方重复。

建模它的一种方法可能是这样的：

+----------------+
|relationships   |         +----------+
+----------------+         |singulars |
|id              |         +----------+
|singular_id_1   <---------+id        |
|singular_id_2   <---+     |attribute1|
|pair_description|         |attribute2|
|pair_date       |         |          |
|                |         +----------+
+----------------+

使用这种模式，有必要检查两个外键字段relationships是否存在singulars，它可能在任一侧。顺序无关紧要，但它是在模式中定义的......所以查询最终会得到许多AND/OR组和案例。

扩展这种方法可以为每对存储两条记录，并在singular_id_[n]两侧交换。虽然这解决了一些查询的复杂性，但它会引入额外的复杂性使其不可行。

使用中间表似乎是一种潜在的解决方案：

+----------------+       +-----------------------+
|relationships   |       |singulars_relationships|        +----------+
+----------------+       +-----------------------+        |singulars |
|id              <-------+relationship_id        |        +----------+
|pair_description|       |singular_id            +-------->id        |
|pair_date       |       |                       |        |attribute1|
| …

我遇到了 1 个查询，它是

Select * from R Natural Outer Join S

哪里R=(A,B)有元组{(1,2),(1,2),(3,4)}和S=(B,C)有元组{(2,5),(2,5),(4,6),(7,10)}。

为了实现这一点，我创建了 2 个名为R和 的关系S。

create table R
(
A number(5),
B number(5)
)

create table S
(
B number(5),
C number(5)
)

我在其中插入了提供的元组。

现在在实现这个时，我开始知道我使用的数据库工具（Oracle）不支持“自然外连接”，所以我使用了以下查询

select *
from R
natural full outer join S

输出

2 1 5
2 1 5
2 1 5
2 1 5
4 3 6
7   10

现在来回答我的问题

1. “自然外连接”与“自然全外连接”相同吗？
2. 这里的记录匹配是如何进行的？

因为在任何表中都没有定义主键，所以我认为它应该进行交叉连接并显示 16 …

如果数据库要保存大量例如音乐会的门票，我是否应该为每场音乐会制作一张新表，然后保留一张将场地与音乐会连接起来的表？

我希望每场音乐会的每张票 ID 从 1 开始，而不是每张票的总和。

或者我应该把它们放在一张桌子上，并有 2 个单独的列用于（票号）和（该事件的票号）？