Início / dba / Perguntas / 9155
Accepted
johannes
Asked: 2011-12-15 05:50:34 +0800 CST

Como expressar essa restrição em um esquema de banco de dados?

  • 772

Eu tenho as seguintes dependências funcionais que estão no BCNF:

a,b -> c
a -> d
b -> d

Com a restrição adicional, que no ae bdevem ser combinados com a c, onde ae btêm ds diferentes.

Exemplo:

a | d   b | d   a | b | c
-----   -----   ---------
1 | 3   5 | 3   1 | 5 | 6
2 | 4           2 | 5 | 7

A primeira linha a,b,cé permitida ( 1->3, 5->3), mas a segunda linha é proibida, pois ( 2->4, 5->3) 4 != 3.

Essa restrição adicional pode ter dois efeitos em meus dados. Para cada um a,b,c, existem duas maneiras redundantes de determinar o d. Pode haver dados que violam a restrição. Como meu esquema pode refletir essa restrição adicional?

relational-theory constraint

3 respostas

  1. Em poucas palavras, introduza dna terceira tabela para permitir restrições de chave estrangeira de baunilha, por exemplo, sintaxe Transitional SQL-92:

    CREATE TABLE T1
(
 a INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, d)
);

CREATE TABLE T2
(
 b INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (b, d)
);

CREATE TABLE T3
(
 a INTEGER NOT NULL,
 b INTEGER NOT NULL, 
 c INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, b, c),
 FOREIGN KEY (a, d) REFERENCES T1 (a, d), 
 FOREIGN KEY (b, d) REFERENCES T2 (b, d)
);
    • 4

  2. " Então a sua resposta é "não é possível"? "

    Muitas coisas são possíveis. Em seu caso muito particular, parece-me que a aplicação de sua restrição 'adicional' pode ser alcançada mantendo a tabela única do banco de dados (4 colunas). Isso garantirá que qualquer a, b combinado sempre corresponderá ao mesmo d (porque só pode haver um único d). O preço que você paga é que não há mais uma maneira "natural" (ou seja, uma consequência imediata da própria estrutura lógica do próprio banco de dados) que aplicará seus FDs a->d e b->d "automaticamente" .

    É um fato bem conhecido que o processo clássico de normalização por decomposição, às vezes requer que certos DFs sejam restabelecidos como uma restrição de banco de dados, porque no projeto decomposto a regra não pode mais ser declarada como um DF. Seu caso particular parece ser um desses, onde você tem a escolha entre um projeto que aplica "automaticamente" a->d e b->d, mas onde você tem que fazer um esforço extra para impor sua restrição adicional, ou um projeto que "automaticamente" impõe sua restrição adicional, mas onde você tem que fazer trabalho extra para impor [as restrições correspondentes a] seus DFs a->d e b->d.

    Tendo TODAS as restrições que você mencionou impostas apenas pela estrutura do banco de dados, é possível, no seu caso particular, usar a solução do onedaywhen. No entanto, (a) isso é apenas uma solução para casos particulares, como o seu exemplo, (b) o preço que você paga é maior redundância e, portanto, complexidade adicional na atualização de seu banco de dados (e certas atualizações podem ser impossíveis de alcançar !!!) , e (c) ainda permanece um fato que nem todas as restrições de banco de dados concebíveis são expressáveis ​​como um DF.

    (Desculpe por postar uma segunda resposta. Meu login do Stackoverflow não me permite comentar aqui.)

    • 3
  3. Best Answer

    Em poucas palavras, crie um ASSERTIONpara garantir que em nenhum momento a regra de negócios seja violada, por exemplo, sintaxe SQL-92 padrão completa:

    CREATE TABLE T1
(
 a INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, d)
);

CREATE TABLE T2
(
 b INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (b, d)
);

CREATE TABLE T3
(
 a INTEGER NOT NULL,
 b INTEGER NOT NULL, 
 c INTEGER NOT NULL, 
 UNIQUE (a, b, c)
);

CREATE ASSERTION no_a_and_b_should_be_combined_with_a_c_where_a_and_b_have_different_ds
   CHECK (
          NOT EXISTS (
                      SELECT *
                        FROM T3
                       WHERE NOT EXISTS (
                                         SELECT T1.d
                                           FROM T1
                                          WHERE T1.a = T3.a 
                                         INTERSECT        
                                         SELECT T2.d
                                           FROM T2
                                          WHERE T3.b = T3.b 
                                        )
                     )
         );

    A má notícia é que nenhum produto SQL comercial (ou não?) oferece suporte a arquivos CREATE ASSERTION.

    A maioria dos produtos SQL de força industrial oferece suporte a gatilhos: pode-se implementar o acima em um gatilho em cada tabela aplicável . O MS Access é o único produto comercial que conheço que oferece suporte a subconsultas em CHECKrestrições, mas não o considero de força industrial. Existem outras soluções alternativas, por exemplo, forçar os usuários a atualizar tabelas apenas por meio de procedimentos armazenados que podem ser mostrados para nunca deixar o banco de dados em um estado ilegal.

    • 3

relate perguntas