Modelagem De Dados: Exercício De Modelagem Lógica

... Parte II

V1. 3 e resposta

Identificadores vs colunas de Id

• Aqui está.▶ um exemplo◀, verifique a questão em pormenor primeiro. Note que Mark é bastante capaz, mas completamente preso. então leia a minha resposta, depois olhe para o modelo de dados. (Por favor, faça isso agora, ele fornece contexto)

• A idéia é ou modelar os dados, como dados, o que estamos fazendo, e você vai acabar com uma base de dados, XOR Stick Id colunas em tudo o que se move, o que impede o exercício de modelagem e Normalização, e você vai acabar com um monte de planilhas "ligadas" um ao outro com duplicação maciça e sem desempenho.

• Por isso, remova todas as colunas do formulário [Table]Id de todas as tabelas (deixe as chaves migradas em paz, elas estão correctas), excepto As tabelas seguintes (estas são as principais , reflectidas em toda a base de dados. Note como ERwin corrigirá todas as crianças, netos, etc. tabelas:
  Party
Address
Item

Identificadores relacionais / IDEF1X

Tens estado a ler as minhas respostas, a olhar para os meus modelos de dados, e depois a adicionar identificadores ao teu modelo. É muito mais fácil do que isso. O ERwin (uma vez que implementa o IDEF1X) faz isso por si.

• Festa, Banda e pessoa. O identificador da parte é PartyId
  (ok, essa é uma chave substituta, não uma chave Natural; mas a chave Natural Lastname, FirstName,BirthDate, etc. é muito longo, se usarmos que, como chave principal, seria migrado para os filhos, netos, bisnetos, o que não é desejável, então nós adicionamosuma chave substituta curta, e tornamos essa a chave primária)

• Quando você criar os subtipos em ERwin, e indicar a Relação, ele irá automaticamente colocá - PartyId em Banda e Pessoa, como o PK; ele irá marcá-lo como "(FK)". (Nota: eu uso fonte negrito para denotar (FK) em Meus modelos.)

• É isso, estás feito. Partido:: a banda é 1: 0-1, a chave primária da banda é PartyId. Como é um subtipo, ERwin irá garantir que a relação é identificando , e portanto o PK Pai acaba no PK filho, e o filho dependente tem cantos redondos.
  • Se subtipos foram não envolvidos, seria o mesmo, exceto que a Relação não pode ser de 1::0-1, ele pode ser: 1::1-n. Nesse caso, você precisa adicionar mais um elemento para torná-lo exclusivo, como fFirstName, ou SequenceNo
  E tens de o fazer. indique ao ERwin que deseja uma relação identificadora. (Se não o fizer, então é um FK simples, e as colunas estarão abaixo da linha; a tabela será independente,; o quadrado dos cantos).
• e se, em algum momento, decidir usar essas colunas FK para formar o PK, basta carregar na relação e alterá-la de não-identificadora para identificação; as colunas serão movidas acima da linha; os cantos serão redondos.

Papel

• Agora, o próximo passo. Nós sabemos que a banda:: partido é 1:: 1; essa banda é uma criança Do Partido; que Band.PartyId é a PK perfeita (não Id coluna é necessária). O mesmo para a pessoa. Mas eles são nomes tolos, ou dito de outra forma, banda é na verdade um papel diferente para a pessoa, e eles são ambos uma festa. Por isso, queremos identificar claramente o papel.

  • Na banda, gostaríamos de chamar PartyId, BandId, para reflectir o seu papel. Edite a relação , entre o símbolo do subtipo e a criança, não a tabela. No diálogo, preencha o nome de RoleName como BandId. É isso. Acabou.

  • Assim, a seguinte mudança de ... to: {[0]} Consequentemente ... {[1]}

• Remover todas as colunas [Table]Id irá deixar as seguintes tabelas sem um PK. Por agora, adicione uma coluna Name como o PK. Você pode me dizer mais tarde o que o usuário gostaria de uma chave natural, um identificador para estas tabelas: Evento
  Género

• PartyAddress é um exemplo (ie. modelado corretamente) de tudo o que eu discuti acima. Não tinha. PartyId e AddressId juntos formam o PK. Ambas as relações identificam-se.

Identificação contra relações não identificadoras

ao ler muito sobre o assunto, parece haver muita discordância e indecisão sobre o assunto.

• Sim. Infelizmente, qualquer um com um teclado e um modem pode "publicar" hoje em dia. As pessoas postam opiniões como fatos; postam disparates sobre assuntos sobre os quais não têm noção. Isso confunde pessoas que estão tentando aprender.

• É ciência, não magia ou arte negra, não opinião.

• Ao aprender, leia apenas definições, e ouça apenas as pessoas que claramente transferem a ciência (não para quem está confuso ou trata a ciência como se fosse uma arte ou que está sujeita a opiniao). Estamos aprendendo fatos, leis da física, não opiniões sobre as leis; as leis funcionam da mesma forma para todos, em todo o planeta. Não podes aprender com alguém que pensa que um facto é uma opinião.

• Vamos começar do início.

  1. A relação é o critério de definição (torna a criança independente/dependente), e não o contrário.

  2. Uma relaçãoé sempre um FK na criança, do Pai. PK.

  3. Em uma relação identificando, que FK é o PK (ou a primeira parte do PK, onde o PK é uma chave composta). E a criança é uma tabeladependente .

  4. Numa relação que não identifica que FK é uma coluna não-PK, e a criança é independente (pode ser forçada a depender por alguma outra relação).

  5. Todos os subtipos têm relações de identificação do supertipo. Caso contrário, eles não seriam subtipos, seriam independentes do supertipo.

  6. Todas as relações 1:0-1 estão identificando.

então fiz o que achei que representava as coisas certas no meu modelo.

• pode ser por isso que acabaste por adicionar [Table]Id chaves.

quando forçar (identificar) e quando ser livre (não identificar)?

• Nunca forçar nada re modelização (base de dados e função), especialmente dados re. É o incontrolável que queremos administrar, gerir, moldar, controlar, etc. Mas para o fazermos eficazmente, temos de o compreender primeiro. Não podemos compreender nada quando o forçamos. Forçá-lo a privá-lo de se expor, e priva-nos de notar as sutilezas e sabores (porque nós "sabemos" isso). Que seja livre, mas limitada, como um cavalo num cadeado, não como um prisioneiro num estábulo.

  É por isso que o acto de colar colunas em cada a folha de cálculo impede a compreensão dos dados e, por conseguinte, qualquer modelização dos mesmos.

• Como acima, é a relação que está identificando ou Não; Não se a entidade é independente ou não, isso é uma consequência.

Fá-lo ao estilo relacional / IDEF1X / ERwin:

1. Se queres uma entidade, desenha uma entidade. Diz. A menos que seja a primeira entidade na tela, não adicione chaves.

2. Agora considere o seu Relacao. Como as Entidades que você já modelou se relacionam com esta nova entidade ? Desenhe essa relação (as relações são desenhadas de pai para filho).

3. É claro que o padrão é identificar, porque a maioria das relações em um (espere por ele) banco de dados relacional estão identificando. O PK pai é colocado no PK criança.

4. Se achas que não, quero que isto seja independente, é bom que tenhas uma boa razão. A questão-chave aqui é: esta entidade existe completamente por si só, existe fora do contexto de outras entidades independentes ? AFAIC, há cinco no teu modelo: Endereço
   Partido
   Ponto
   Evento
   Género Todas as outras entidades existem apenas no contexto de uma dessas entidades independentes. Assim desenhastes relações identificadoras, e assim todas elas são dependentes.

   • Lembremo-nos de que tínhamos um Item como independente anteriormente; então tivemos uma nova forma de Item; que fez o Item antigo, o BandItem; que tornou o BandItem dependente do Novo Item.

   • Nós tínhamos um grande identificador em ItemId, que foi carregado não só no (então) conjunto de itens, mas ao longo, em OrderItem, revisão, etc.

   • Nós mudamos o contexto do Item (criado um Item de ordem superior), e devido às relações de identificação, que foi então migrado por todo o lado, e o novo BandItem foi migrado em seu contexto.

   • O novo ItemId continua a seria um grande identificador. BandItemId é exatamente ItemId, mas desempenha um papel particular, é um subconjunto / subtipo de ItemId.

5. Então, se é uma entidade independente, vá em frente e dê - lhe um novo PK.

   • Mas nesta fase, não uma coluna Id, algo significativo que identifica a entidade. Event.Name, Customer.Code. Nenhum ser humano identifica um cliente como número 123456, não, eles pensam em "IBM", "3M", etc. Mais tarde, à medida que o modelo progride, faremos claro que temos chaves realmente boas; neste momento, com a nova entidade, nos importamos que ela tenha um identificador.

   • Excepção. Para Endereço, Festa, Item, você sabia que na V1.0 que você ia ter milhões, milhares, milhares deles; que estes foram os principais Identificadores que iria ser Migrado todo o banco de dados; que o verdadeiro PK foi muito longa, e que você precisava de um curto-Chave Substituta, conforme o PK; assim, você definir isso, desde o início, e você não tem mais argumento de mim.

     • Se você está pronto para domínios, então INT, INTor SMALLINT, SMALLINT.

     • Caso contrário Name, CHAR(30).

6. O próximo passo é terminar o PK sobre a nova entidade. Se a cardinalidade do pai é 1:: n, Ele já tem o PK do Pai, basta adicionar um elemento para tornar o PK único. Vamos ver a ordem. Já tem PartId, por isso OrderNo pode estar dentro PartyId. Basta mudar a ordem das colunas PK para (1) PartyId, (2) OrderNo.

7. A única vez que fazemos um pouco de força, é quando o número de colunas que formam o PK se torna demasiado, ou a largura total do PK se torna demasiado larga, para migrar como um FK para as crianças. Então, e só então, criamos uma chave substituta adicional do formulário [Table]Id (eles são Sempre adicional, não podemos perder o verdadeiro PK ou a singularidade, porque ele suporta outros requisitos).

   • AFAIC, that magic number is seven (magic não para muitas coisas, na verdade; mesmo este item aparece como número sete), e essa largura máxima é de 30 bytes. Isso foi feito desde o início com endereço (já altamente otimizado), Partido (caso contrário 64 bytes), Item (mais de 30 bytes).

   • Se vamos quebrar o poder relacional intrínseco, precisamos que a dor de carregar esse poder relacional em si seja realmente ruim, e por nenhuma outra razão. Nem sequer te aproximaste disso na tua modelo.

Agregado De Revisão

1. Indo com o grupo de Revisão como está. Precisamos de uma visão de Canção e de uma visão de album. E se livrar do ItemReview (que encapsula todos os itens, o que significa que estamos dobrando). Pensei que estávamos a excluir críticas para itens fora da banda.

2. Permitir que a não-Visão de banda seja sobre qualquer Banditismo, por exemplo. muda o FK do ItemReview do Item para o BandItem. Isso encapsula todos os temas em ItemReview. Livra-te da vista performática.

   Claro, pode não querer BandItem.Outros a serem revistos; isso pode ser restringido por outros meios. Mas se você quer ser rigoroso, então você precisa (1).

Cor

• O Significado, a relevância visual, não aparece em um modelo minúsculo (a maioria dos meus modelos em SO); ele só aparece em modelos maiores como o seu.

• Porque você tem feito um ótimo trabalho com V1. 3, O Professor tem um ▶maçã para ti◀. Na verdade,▶ Notação IDEF1X◀ vale a pena ler novamente o documento, está muito condensado, e disseram-me que as pessoas ganham mais valor com ele quando o lêem. depois de modelar algo. O que preciso de saber é se a hierarquia Natural e a cor fazem alguma coisa por ti.

• Isso é só terminar o nível lógico de entidade.

Você pode continuar com o nível lógico, Chave (os únicos atributos são FKs, e nós sabemos o que eles são). Mas sinta-se à vontade para começar a identificar atributos (nesse caso, mostre o nível do atributo).

Coluna Opcional

U. 1) Facultativo Os pais voltaram para o modelo. PartyAddress is shipped for Order não é Invulável.

• Se pretendeu modelar que o endereço de envio é opcional, então precisa de uma entidade Ordership Address, que é uma criança de ordem, e a cardinalidade é 1: 0-1.

  • as Nulls (colunas opcionais) são como um cancro que recolhe por todo o corpo, as FKs Nullable (progenitoras opcionais) são o cancro da garganta num órfão antes dos cinco anos de idade.
    .
Isso é o básico. método para lidar com qualquer coluna opcional, não limitado a um que é um FK (pai opcional), como aqui.

Menor

M. 11) estes estavam correctos em V1. 2
Revisão::: Comentário 1:: 0-1
Membro da banda:: Comment is 1: 0-n

M. 12) evento::a pessoa é n:: n (e as colunas não aparecerão ao nível lógico)

V1.4 e resposta

U. 8) (Se fizer isto primeiro, o restante seguirá facilmente.) Erwin Limitation. Parabéns, você produziu um modelo que atingiu as limitações da capacidade de ERwin na modelagem lógica. Para ser claro, este não é realmente um limite, na medida em que se resolve no modelo físico, e é claro que não é uma limitação em bases de dados IDEF1X ou relacionais. Mas agora, na lógica, interfere com a tua aprendizagem e progresso.

• Em BandItem queremos que o PK seja, BandId). Mas ERwin não o permitirá porque diz que um subtipo PK deve ser o SUPERTYPE PK e nada mais que . Na verdade, enquanto o SUPERTYPE PK for o principal identificador, outra relação de identificação é aceitável. Para trabalhar em torno disto:
  • largue o símbolo do subtipo
  • criar dois itens identificadores de relações:: soalho e Item::BandItem

• As relações que tivemos de fazer sem identificação podem agora ser Identificacao.

• ERwin vai agora resolver o PKs migrado como FKs, sem duplicação.

• Sim, manda os papéis de volta.

Mas há um problema básico na própria revisão. Com um PK de Revisor, um revisor só será permitido uma revisão. É claro, você quer uma revisão por revisor por banda/BandItem, mas isso está escondido mais abaixo no subtipo. Basicamente, o uso do subtipo-supertipo aqui é muito restritivo. É bom entender, nessa fase inicial, mas agora temos de ir mais além.
• em vez do grupo de revisão, crie duas tabelas de Revisão, uma revisão de banda e uma revisão de Item.
• as relações serão pessoais:: visão de banda e Banda::visão de banda, e pessoa::visão de banda e BandItem: visão de banda
• então cada um de eles terão classificação de crianças %, % comentário, %Comentração.

M. 13) ordem: Ordership address is 1: 0-1, correct. Endereço::: Ordem 1:: 0-n, correcto Por conseguinte, o endereço de envio deve ser em PartyAddress:: OrderShipAddress 1:: 0-n

M. 14) O Pagamento permite actualmente apenas um pagamento por ordem, que pode ser o que necessita, mas a relação é 1::1-n. Se necessitar de mais, adicione então um SequenceNo ao PK.

Go for V1.5. Incluir alguns atributos. A melhor maneira de identificá-los é iniciar um modelo de função (e agora trabalhar o modelo de Dados lado a lado com ele) ou, pelo menos, trabalhar através de todas as funções para todas as telas.