**第一范式：数据库表中的字段都是单一属性的，不可再分。
第二范式：非主键信息不是由整个主键函数来决定时，即违法第二范式
信用卡号，学籍号 主键---->卡现金
第三范式：存在非主键属性 传递依赖 即违法第三范式
StudentNo CardNo UserID 职位
021101 001 Operator 操作员**Em primeiro lugar, o paradigma de design de banco de dados e sua importância e
paradigma de design inadequado banco de dados é um banco de dados projetado para atender às especificações necessárias, padronização e otimização da estrutura da tabela de banco de dados para otimizar os dados é organizado em uma forma de tabela, para tornar os dados mais claros, mais concisos . Na prática, um banco de dados é geralmente dividido em duas ou mais tabelas e o relacionamento entre as tabelas é definido para atingir o isolamento dos dados. Adicionar, excluir e modificar um campo só precisa ser feito em uma tabela, e então pode ser passado através do relacionamento definido Para as demais tabelas do banco de dados (muito semelhante ao significado da ideia hierárquica). Dessa forma, podemos eliminar muitas oportunidades de erros ou dados inúteis e reduzir a carga de trabalho necessária para atualizar as informações.
Atualmente, existem principalmente seis paradigmas: o primeiro paradigma, o segundo paradigma, o terceiro paradigma, o paradigma BC, o quarto paradigma e o quinto paradigma. Aquele que atende aos requisitos mínimos é chamado de Primeira Forma Normal, ou 1NF para breve. Com base no primeiro paradigma, o segundo paradigma, ou 2NF para breve, pode ainda satisfazer alguns requisitos. E assim por diante
As coisas costumam ser multifacetadas e o paradigma de design também trará alguns problemas: a operação é difícil, porque várias tabelas precisam ser contatadas para obter os dados necessários e, quanto maior o desempenho do paradigma, pior. Portanto, é necessário pesar os prós e os contras para usar o alto paradigma, geralmente, no projeto, basta usar o terceiro paradigma, que tem bom desempenho e conveniente gerenciamento de dados.
Em segundo lugar, vamos dar um exemplo para introduzir três paradigmas de design de banco de dados
Descrição: Exemplos de um "sistema de taxas de quarto escolar", o "Formulário de Informações do Aluno", "a máquina para cima e para baixo registra a tabela do aluno" parte do campo
1. A primeira
definição normal do formulário 1NF : os campos na tabela do banco de dados são todos atributos únicos e não podem ser divididos.
Simplificando, cada atributo é um item atômico e indivisível.
1NF é a condição mínima que o modelo relacional deve ter.Se o design do banco de dados não pode atender a primeira forma normal, ele não é chamado de banco de dados relacional. Ou seja, desde que seja um banco de dados relacional, deve atender à primeira forma normal.
Vejamos primeiro uma tabela 1-1 que não atende a 1NF.
CardNo StudentNo StudentName Sex Department CardCash UserLevel Time
001 021101 Xiao Ming Nan Education College, Departamento de Psicologia, Classe 1, Operador 100 2011/10/03, 09:00
A razão pela qual esta tabela não está em conformidade com 1NF é que os campos Departamento e Horário podem ser subdivididos, portanto, devem ser alterados para Tabela 1-2:
CardNo StudentNo StudentName Sex Academy Classe principal CardCash UserID UserLevel Data Hora
001 021101 Departamento de Psicologia, Xiao Ming Male Education College 1 Operador 100 2011/10/03 09:00
2. A segunda
definição 2NF da forma normal : não há dependência funcional parcial de campos não-chave em qualquer campo-chave candidato na tabela do banco de dados, que está em conformidade com a segunda forma normal.
"Nota: O que é uma dependência funcional, consulte a Baidu Encyclopedia ( http://baike.baidu.com/view/40008.htm ) para obter detalhes .
Se o valor de um determinado campo A em uma tabela é determinado pelo valor de outro campo ou grupo de campos B, diz-se que a função A depende de B. 》
2NF pode reduzir a exceção de inserção, exclusão de exceção e modificação de exceção.
Simplificando, por um lado, a segunda forma normal deve satisfazer a primeira forma normal, caso contrário, não há necessidade de falar sobre a segunda forma normal.
Por outro lado, quando as informações da chave não primária em uma tabela não são determinadas por toda a função da chave primária, ou seja, quando há uma parte que depende da tabela que não é a chave primária ou a parte que depende da chave primária, geralmente viola 2NF.
Vejamos a tabela 1-2 acima que satisfaz 1NF
CardNo StudentNo StudentName Sex Academy Classe principal CardCash UserID UserLevel Data Hora
001 021101 Departamento de Psicologia, Xiao Ming Nan Education College 1 100 Operator Operator 2011/10/03 09:00
Vemos que nesta tabela, StudentName, Sex, Academy, Major, class, CardCash, UserID, Date, Time podem ser determinados por CardNo e StudentNo. Portanto, você pode usar a combinação de CardNo e StudentNo como a chave primária.
No entanto, descobrimos que o CardCash não depende totalmente do CardNo e do StudentNo. O CardCash pode ser determinado apenas pelo CardNo, porque um cartão deve ter o valor no cartão. Isso causou dependência parcial. Quando isso acontece, a segunda forma normal não é satisfeita.
mudar para:
Vejamos outro exemplo, o formulário de embarque e registro de embarque, será mais óbvio. Tabela 2-1
CardNo StudentNo StudentName Sex Department Turma principal OnDate OnTime OffDate OffTime ConsumeTime ConsumeMoney
001 0211 Departamento de Psicologia, Xiao Ming Nan Education College 1 2011/10/14 09:00 2011/10/14 10:00 1 2
Vemos que nesta tabela, StudentName, Sex, Department, Major e class são diretamente dependentes de StudentNo, não dependentes de outros campos na tabela, este design não está em conformidade com as informações de chave não primária 2NF não são de toda a função da chave primária Ao decidir.
Podemos otimizar 1-2 e 2-1 para:
3-1
Aluno Sem CardNo ID do usuário UserLevel Data Hora
021101 001 Operador 2011/10/03 09:00
3-2
CardNo CardCash
001 98
3-3
CardNo OnDate OnTime OffDate OffTime ConsumeTime ConsumeMoney
001 2011/10/14 09:00 2011/10/14 10:00 1 2
3-4
StudentNo StudentName Sex Academy Major class
021101 Departamento de Psicologia, Xiao Ming Nan Education College 1
3. A
definição 3NF da terceira forma normal : Com base na segunda forma normal, se não houver dependência da função de transferência de campos não-chave em qualquer campo-chave candidato na tabela de dados, ela está em conformidade com 3NF.
Vejamos a Tabela 3-1 otimizada no exemplo acima
Aluno Sem Cartão Sem ID do
usuário Nível do usuário Data Hora 021101 001 Operador Operador 2011/10/03 09:00
Na tabela, um UserID pode determinar um UserLevel. Desta forma, UserID depende de StudentNo e CardNo, e UserLevel depende de UserID, o que leva à dependência transitiva.3NF é eliminar essa dependência.
Otimizamos 3-1 para obter:
4-1
Aluno Sem Cartão Sem ID do usuário Data Hora
021101 001 Operador 2011/10/03 09:00
4-2
ID do usuário Operador de nível de usuário
Operador
Vimos que a terceira regra de forma normal procura eliminar atributos que não dependem diretamente da chave primária da tabela formada pela primeira forma normal e pela segunda forma normal. Criamos uma nova tabela para todas as informações não associadas à chave primária da tabela. Cada nova tabela contém informações da tabela de origem e da chave primária da qual dependem.
Terceiro, a
padronização do design do banco de dados de resumo nos permite uma melhor adaptação às mudanças, para que você possa alterar as regras de negócios, requisitos e dados sem a necessidade de reconfigurar todo o sistema