我有一个类似下面的If语句块,它没有错误 - PLS-00103:遇到以下其中一个时遇到符号"SELECT"....
Begin
If (select count(*) from Table1) > 0 then
dbms_output.put_line('Test');
end if;
end;
我有类似的Case语句,工作正常
select
case
when (select count(*) from Table1) > 0
then 2
else
1
end
from dual
从我在Oracle Documentation中读到的if和when何时支持布尔表达式,任何想法是否在If条件中支持子查询.
注意:语句已经简化,我真的不会得到整个表的计数,所以请不要优化建议
我希望这不会被认为是一个太愚蠢的问题。我对数据库规范化的概念有点困惑，它似乎表明，如果特定字段/列中有任何类型的可预测或重复数据，那么最好创建一个新表并通过外部 ID 链接，这真的是吗？每种情况都需要吗？
例如，诸如“性别”、“业务类型”（没有严格的功能目的，只是信息）、“称呼”（先生、夫人等）等字段，所有这些都将在整个表格中重复，这似乎有点过头了，对我来说有点麻烦为这些创建一个新表？它还意味着我在检索数据时必须使用更多的 JOIN。
在什么时候有必要对重复数据使用单独的表，或者对所有数据都这样做是最佳实践？
我的查询包括拥有和计数或全部。这些在 RA/DRC/TRC 中如何表示？我是否必须进一步简化我的 SQL 查询？这是一个简化的示例：
empl(employee (primary key), city)
managers(employee (primary key), manager (foreign key of employee))
如果我要找到 X 市所有员工的经理（来自任何城市）的所有员工..我需要使用having/count。不知道在 RA/DRC/TRC 中这将如何完成。
我知道这样的查询的需要可能没有意义，但假设对于这个问题的目的来说这是合理的。
谢谢
sql database relational-algebra relational-database relational-division
我无法理解如何识别函数依赖项中的键.我一直在看例子,例如:
给定ABCD关系,找到所有不包括超密钥的密钥
A -> BC, C -> D, CD -> AB.
这给出了密钥C和A.我认为接近这个问题的方式是BC和D都依赖于A和C,AB依赖于CD,这意味着它们都是密钥,但是因为CD是一个超级密钥(C是一个也是一个密钥的子集),CD不被认为是一个最小的超级密钥.
但是,在另一个例子中,
ABCDE
AB ? CD
E ? A
D ? A
这里唯一的关键显然是BE.为什么这是真的,任何人都可以澄清找到这些问题的关键步骤吗？
谢谢.
relational-database relation functional-dependencies candidate-key
我正在研究数据库概念,有3个概念我不明白.典型的封面,无关的功能依赖和封闭.我阅读了关于规范封面的定义,但我不了解它与3NF和BCNF的关系.规范覆盖的定义似乎是没有无关的属性,无关的属性意味着不改变函数依赖集的闭包的属性,而闭包是F所隐含的所有函数依赖的集合,一组函数依赖.
但所有这些都有点模糊,我既喜欢直观的定义,也喜欢如何计算
功能依赖我相信我理解它是什么,就像我们在表中有这些属性时表中的PK一样.
在数据库细化方面有一个相当广泛的答案- F(外来属性)的最小覆盖,但我发现很难阅读所有的集定义和代数,我宁愿用简单的英语定义.
例如,具有模式U = {A,B,C,D,E,F,G}和功能依赖性
AB→C
B→E
CF→D
C→A
B→F
CE→F
CD→B
B→C
闭包A +,B +,C +,D +,E +,F +是这样计算的吗？
A + = A.
B + = BCDEF
C + = A.
D + = D.
E + = E
F + = F.
？如果我没有弄错,那么BCDEFG是1NF/2NF中的超级密钥("全密钥"),但它是否最小(3NF)？
在闭包和规范封面的帮助下,还应该做些什么来将这个例子标准化为1NF,2NF和3NF？规范封面与最小封面相同吗？
我lösningen直到detta talsåharBCDEFG angetts som"prima attribut"och som"ickeprima"attribut men resonemanget saknas.
谢谢你的帮助
database-design canonical-form relational-database database-schema functional-dependencies
我已经在各种数据库中看到了这个,但我将使用最新的例子.在AdventurWorks2012数据库中,有
和
我试图理解为什么你可以将这些设置放在一个表而不是两个表中的概念.很抱歉我对此类设置缺乏了解.我想确保当我创建新表时,我想知道这种类型的设计,它将如何工作类似于我可能合并使用Header和Detail捕获数据输入到表中的原因.
例如
希望我的问题很明确.
======================
编辑了通过我对@Szymon的响应使用Header/Detail设置的详细示例
在上面的示例中,将其布局为Header/Detail设置.提交记录时,它会生成一个ID,因此我的Header Table将如下所示:
标题表
1,'11/13/13',11,2013,'000001',0,10.00,'11/12/13','President','Chuck','11/12/13'
然后在我的详细信息表中它也会生成一个ID但是使用前一个记录作为FK,它看起来像这样...... 1(新ID),1(先前的标题表的FK),2(作为服务产品1) ,2(作为服务产品2),2(作为服务产品3),2(作为服务产品4),2(作为服务产品5)
细节表
1,1,2.00,2.00,2.00,2.00,2.00
==================================================
再次修订:提供更好的跟进示例.
WKS_Header表:( PK是WKS_Header_ID)
WKS_Header_ID [int] IDENTITY(1,1) NOT NULL,
Company_ID [varchar](6) NOT NULL,
Current_Date [DateTime] NOT NULL,
Current_Month [int] NOT NULL,
Current_Fiscal_Year [int] NOT NULL,
Revision_Number [int] NOT NULL,
Worksheet_ID [varchar] (13) NOT NULL,
Total_Amt [money] NOT NULL,
Certification_Date [DateTime] NOT NULL,
Certification_Officer [varchar] (50) NOT …因此，作为我作业的一部分，我必须证明与两个属性的任何关系都符合 BCNF。
根据我的理解，如果对于一个关系我们有第三范式并且一个非关键属性在功能上决定了关键属性，那么它就违反了 BCNF。
假设我的关系由两个属性 A1,A2 组成
场景1（只有一个函数依赖）
A1 -> A2 (so A1 is the key, and A2 does not FD A1 : so no violation)
同样适用于
A2 -> A1
但如果
A1->A2 and A2->A1
这里的key可以是A1，A2。另一个非关键属性在功能上决定了关键。
我读到一篇声明“BCNF 中至少有一个简单候选键的关系 R 也在 4NF 中”
我不认为这总是正确的，但我无法证明这一点。
有人可以帮忙吗？
我知道，INNER JOIN用于引用的键，而INTERSECT不是。但是afaik在某些情况下，两者都可以做相同的事情。那么，以下两个表达式之间是否存在差异（性能或其他方面）？如果有，哪个更好？
表达式1：
SELECT id FROM customers
INNER JOIN orders ON customers.id = orders.customerID;
表达式2：
SELECT id FROM customers
INTERSECT
SELECT customerID FROM orders
请有人解释一下为什么 .join() 的行为如下：
input = [1, 0, 5, 3, 4, 12, 19]
a = " ".join(str(input))
print(a)
结果是：
[ 1 , 0 , 5 , 3 , 4 , 1 2 , 1 9 ]
不仅还有一个列表，而且还多了一个空间。怎么会？当我使用 map() 时它可以工作：
a = " ".join(list(map(str, input)))
但我想知道我正在使用的 .join 方法有什么问题。