[Notas] design de banco de dados MySQL python (básico)

[Notas] design de banco de dados MySQL python (básico) 

Alguns projeto conceitual básico de bancos de dados e outras notas

 

• banco de dados relacional construído sobre a base do modelo ER, precisamos gerente de produto de planejamento design, modelo extraído e o relacionamento para desenvolver uma estrutura de tabela, que é o primeiro passo para o início do projeto
• Há muitos banco de dados de software de design em desenvolvimento, como o designer de energia comumente usado, desinger db, estes software pode ver visualmente os relacionamentos entre entidades e entidade
• design de banco de dados, pode ser feito por design de banco de dados pessoal especializado, isso poderia ser feito pelos membros da equipe de desenvolvimento, o gerente geral para conduzir os membros da equipe do projeto para completar

 

três paradigmas

• Depois de uma pesquisa e um resumo da utilização em questão, para o projeto de banco de dados fez uma série de especificações, que são chamados de paradigma (Normal Form)
• Atualmente, existem oito tipos de paradigma discernível, o paradigma geralmente podem estar sujeitos a 3
• ◆ primeiro paradigma (1NF) : enfatizou que as colunas atômicas , ou seja, colunas não ser subdivididos em vários outros coluna, a coluna não pode ser dividida .

  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) : Primeira 1FN, que compreende ainda duas partes, uma tabela deve ter uma chave primária ; o segundo está não contido na chave primária deve ser completamente dependente da chave primária , mas não pode contar apenas com uma parte da chave principal.

  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, um OrderID (número de ordem) não é distinguir exclusivamente cada registro, ele simplesmente não é suficiente para se tornar uma chave primária OrderID, ProductID empatia. chave primária deve ser (OrderID, ProductID). Evidente a partir do desconto (descontos), Quantidade (quantidade) é completamente dependente (dependente) a chave primária (OderID, ProductID), e PreçoUnitário, ProductName só depende da ProductID, isto dependente apenas da parte da chave principal. mesa para OrderDetail não satisfaz a 2NF. O projeto não atende aos dados redundantes propenso 2NF.

  [] Tabela pode OrderDetail dividido em [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) 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 [] Order [] Order (CódigoDaEncomenda, DataDaEncomenda, CustomerID) e [] cliente (Cliente, CustomerName, CustomerAddr, CustomerCity ) para alcançar 3NF. * Conceito (2NF), e um terceiro paradigma (3NF) um segundo paradigma pode ser facilmente confundida, distingui-las ponto chave é, 2NF: coluna chave não primário é inteiramente dependente da chave primária, ou dependente da parte da chave principal; 3NF: coluna chave não primário ele é directamente dependente da chave primária, ou dependem directamente sobre a coluna de chave não primário.

 

modelo ER

• E representa a entrada, entidade entidade de projecto definida como uma classe, especifique o que o objeto é descrito, uma entidade é convertida em uma tabela no banco de dados
• Relação R representa uma relação, a relação entre a descrição das regras correspondentes duas entidades, incluindo o tipo de relação compreende um, um-para-muitos
• A relação de dados também é necessário por um campo armazenado numa tabela

 

1. A entidade A para a entidade B é de 1 a 1:

Isto é, uma ficha Uma tabela de ficha correspondente a um quadro B, criar um campo de chave primária, é armazenado na outra tabela de Tabela A ou B. Tabela

Exemplo: a cidade tem uma equipe, uma equipe que corresponde a uma cidade.

2. A entidade A para a entidade B é mais do que um par :

Uma tabela que é uma tabela de dados que correspondem a uma pluralidade de dados B, A tem de ser a tabela de chave primária como um B chave estrangeira da tabela. Criar um campo, os valores de chave primária armazenada na Tabela A Tabela B.

Exemplo: uma classe que corresponde a uma pluralidade de alunos.

3. A entidade B a entidade A muitos- : 

Tabela C requer um intermediário sua relação com o correspondente (exige uma tabela para mapear a sua relação). Neste caso, A, a tabela B não precisa de outras chaves estrangeiras. Basta ter a sua própria chave primária na linha, assim como uma tabela separada. I.e. novo C uma tabela, a tabela tem apenas dois campos, um para o valor primário Uma chave é armazenada, de um valor de chave primária para B é armazenado.

Por exemplo: a relação entre alunos e disciplinas eletivas, um estudante pode selecionar várias disciplinas eletivas, e cada eletiva e pode ser mais do que os estudantes podem escolher.

 

lápide

• Para dados importantes, não quer remover fisicamente, uma vez removidos, os dados podem não ser recuperados
• Excluir Programa: coluna Set isDelete é pouco, mostrando uma lápide, o valor padrão é 0
• Para dados não-críticos podem ser fisicamente eliminado
• A importância dos dados, para determinar o desenvolvimento real

exemplo:

• Projetar duas tabelas: classe de mesa, os alunos assistem
• aulas de mesa de classe
  • Eu iria
  • nome
  • isdelete
• Alunos assistem estudantes
  • Eu iria
  • nome
  • aniversário
  • gênero
  • clsid
  • isdelete

 

 

--------fim----------