Uma pessoa a crescer para o cargo de gerente de projetos, princípios de design de banco de dados para compreender, apesar de um monte de coisas são relativamente fortes material teórico, quando chegarmos a uma nova demanda, nós descobrimos depois que a demanda do início ao fim, ele vídeos fluxograma começa -> Diagramas de casos -> design de banco de dados -> a fase de desenvolvimento -> codificação -> teste -> no projeto da linha, um projeto até agora ainda concluída.
Aqui nós são apenas exemplos desta peça de design de banco de dados são discutidas. exemplo mencionado, todos nós sabemos que o primeiro paradigma, o segundo paradigma, o terceiro paradigma. Mas nós entendemos o significado profundo desses paradigmas fazer? Ao usar esses paradigmas, eles usam o que é bom? Aqui vamos dar estas questões juntos, lado a lado para ler o seguinte artigo.
Paradigma : nome em Inglês é forma normal, que é resumida após a EFCodd Britânica (ancestrais banco de dados relacional) modelo de banco de dados relacional proposto na década de 1970, o paradigma é a base da teoria de banco de dados de relacionamento, mas também em nossa estrutura de banco de dados processo de design a seguir as regras e métodos de orientação. Banco de dados paradigma de design é necessário para especificações de design de banco de dados se encontram. Somente através da compreensão do paradigma de design de banco de dados, a fim de projetar eficiente, elegante e bancos de dados, ou pode ser um erro de projeto no banco de dados atualmente traçou um total de oito tipos de paradigma, seguido por :. 1NF, 2NF, 3NF, BCNF, 4FN, 5NF, DKNF, 6NF. Conheça os requisitos mínimos chamados primeiro paradigma, referido 1NF. Além disso satisfazer alguns requisitos com base do primeiro paradigma para o segundo paradigma, refere 2NF. Descansar e assim por diante. Vulgarmente utilizado imediatamente antes de os três paradigmas, a saber: um primeiro paradigma (1FN), um segundo paradigma (2NF), um terceiro paradigma (3NF). Aqui está uma breve introdução destes três paradigmas.
◆ primeiro paradigma (1NF): enfatizou que as colunas atômicas, ou seja, colunas não ser subdividida em várias outras colunas.
Considere esta tabela: [contato] (nome, sexo, telefone)
, se o cenário atual, há um telefone de contato de telefone de casa e de negócios, então este projeto da estrutura da tabela não é atingido 1NF. Nós apenas precisamos de cumprir com a divisão de coluna 1NF (telefone), a saber: [contato] (nome, sexo, telefone residencial, telefone comercial). 1NF boa discriminação, mas 2NF e 3NF é fácil confundir.
◆ um segundo paradigma (2NF): Em primeiro lugar, para satisfazer é 1FN, também precisam de incluir duas partes: primeiro, a mesa deve ter uma chave primária, a segunda não está contido na chave mestra deve ser inteiramente dependentes da chave primário, e não pode confiar no uma porção da chave primária.
Considere um Detalhes do pedido: OrderDetail [] (OrderID, ProductID, UnitPrice, Discount , Quantidade, ProductName).
Porque sabemos que a ordem pode ser encomendado em uma variedade de produtos, não é o suficiente para ser apenas uma chave primária OrderID, a chave primária deve ser (OrderID, ProductID). Evidente a partir do desconto (descontos), Quantidade (quantidade) é completamente dependente (dependente) para a chave principal (OderID, ProductID), e PreçoUnitário, ProductName só depende da ProductID. mesa para OrderDetail não satisfaz a 2NF. O projeto não atende aos dados redundantes propenso 2NF.
[] Tabela pode ser dividida em OrderDetail OrderDetail [] (OrderID, ProductID, descontos, Quantidade ) , e [produto] (ProductID, UnitPrice, ProductName) para eliminar a tabela Pedidos originais UnitPrice, ProductName repetido situação.
◆ terceira forma normal (3NF): Em primeiro lugar, 2NF, coluna chave não primário adicional deve ser directamente dependentes da chave principal, não pode contar com a presença de transferência. Isto é, não existem: Um caso de coluna de chave não primário depende da chave não primário colunas B, chave não primário coluna B é dependente da chave primária.
Considere um formulário de pedido] [Ordem (CódigoDaEncomenda, DataDaEncomenda, CustomerID, CustomerName , CustomerAddr, CustomerCity) é a chave primária (OrderID).
Em que DataDaEncomenda, Cliente, CustomerName, CustomerAddr, CustomerCity outra coluna de chave não primário são inteiramente dependentes da chave principal (NúmeroDoPedido), de modo que o cumprimento 2NF. Mas o problema é CustomerName, CustomerAddr, CustomerCity é diretamente dependente o CódigoDoCliente (colunas de chave não sejam principais), ao invés de diretamente dependentes da chave primária, que é passado através de apenas dependente da chave primária, por isso não atender 3NF.
Por deliberação do [] [Ordem Ordem] (CódigoDaEncomenda, DataDaEncomenda, CustomerID)] e [cliente (Cliente, CustomerName, CustomerAddr, CustomerCity ) para alcançar 3NF.
Q: Como segunda e terceira diferença paradigma paradigma?
O segundo paradigma: a coluna de chave não primário é dependente da chave principal (incluindo um indirectamente na chave primária por uma coluna), se existe dependência é um segundo paradigma;
terceiro paradigma: a coluna de chave não primário é um directamente dependentes da chave primário, não o tipo de passagem relação de dependência. Se isso está em linha com o terceiro paradigma;
Q: Quais são os benefícios existe paradigma?
Paradigma para evitar redundância de dados, reduzindo o espaço de banco de dados, reduzir problemas para manter a integridade dos dados.
范式再给我们带来的上面的好处时，同时也伴随着一些不好的地方：按照范式的规范设计出来的表，等级越高的范式设计出来的表越多。如第一范式可能设计 出来的表可能只有一张表而已，再按照第二范式去设计这张表时就可能出来两张或更多张表，如果再按第三范式或更高的范式去设计这张表会出现更多比第二范式多 的表。表的数量越多，当我们去查询一些数据，必然要去多表中去查询数据，这样查询的时间要比在一张表中查询中所用的时间要高很多。
也就是说我们所用的范式越高，对数据操作的性能越低。所以我们在利用范式设计表的时候，要根据具体的需求再去权衡是否使用更高范式去设计表。在一般的项目中，我们用的最多也就是第三范式，第三范式也就可以满足我们的项目需求，性能好而且方便管理数据；
当我们的业务所涉及的表非常多，经常会有多表发生关系，并且我们对表的操作要时间上要尽量的快，这时可以考虑我们使用“反范式”。反范式，故名思义，跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。也就是用空间来换取时间,把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联；
如我们现在要对一个 学校的课程表进行操作，现在有两张表，一张是学生信息student（a_id,a_name,a_adress,b_id）表，一张是课程表 subject(b_id,b_subject)，现在我们需要一个这样的信息，把选择每个课程的的课程名称和学生姓名输出来：
SQL语句为：select B.b_id,B.b_subject,A_a_name from student A ,subject B;
当上面的数据量不多时，我们这样去查询没有问题；当我们的两张表的数据都是在百万级的时候，我们去查上面的信息， 问题出现了，这个查询动不动就是几百毫秒，甚至更慢，这样的查询效率根本不能满足我们对于网页速度的要求（一般不能超过100毫秒），怎么办？当然要反范式，在课程表里面添加冗余字段——学生姓名，这样我们就可以通过下面的查询达到同样的目的：
SQL语句为：select b_id,b_subject,a_name from subject B;
将两个查询放在一起查看执行计划，就会发现，第一个查询开销占了92%，而第二个才8%，也就是说，第二个查询比起第一个查询，效率上优化了10倍以上，成果显著啊。
总结：
当我们开始着手一个项目后，范式的应用是这样的变化的：
第三范式数据库的设计—–>当数据量越来越大，达到百万级时，经常要对一些多表数据进行大范围高频率进行操作——->范式数据库的设计———->网站的数据量再持续增长———->范式和反范式的数据库设计
当我们的数据量非常大，目前除了对数据库的设计改动外，还可以通过对数据层进行缓存处理。如现在使用效果显著的Memcached ,一个分布式的缓存系统，我们将数据库信息以实体类的方式和图片文件等保存在Memcached里面，只要是可序列化的数据，经过装箱和拆箱，都可以保存 到Memcached中并随时可以快速的访问到这些对象，Memcached可以解决大量数据的缓存并保持多台Web Server得到的缓存数据是一致的。
如果大家对上面的数据库的范式及反范式有好的见解，欢迎留言一起讨论。
转载来自：http://accpchf.iteye.com/blog/1120765
