imported>Douglas |
imported>Douglas |
| Linha 53: |
Linha 53: |
| =Fórum de notícas= | | =Fórum de notícas= |
|
| |
|
| *12 linguagens de programação requisitadas no mercado | | * |
| | | * |
| :[[Douglas_Prog_R | Reportagem vinculada em 2015 na internet pela revista Exame da Editora abril.]]
| |
| | |
| *EaD
| |
| | |
| :[[Douglas_EaD | Saiba como funciona o ensino a distância]]
| |
| | |
| | |
| <!--
| |
| =Ambiente de Programação=
| |
| | |
| =Modelagem de Dados=
| |
| | |
| Para se desenvolver aplicações que utilizam banco de dados relacionais, você deverá possuir os conceitos básicos sobre '''modelagem de dados'''. Não importa se sua aplicação é simples ou complexa. A correta modelagem dos seus dados tornará sua aplicação mais robusta e fácil de manter.
| |
| | |
| Nota: O ERWin foi utilizado como ferramenta para modelagem para os exemplos citados.
| |
| (Foto ERWIN)
| |
| | |
| - Qual o objetivo da modelagem de dados? Pra que modelar?
| |
| | |
| *Representar o ambiente observado.
| |
| *Documentar e normalizar.
| |
| *Fornecer processos de validação.
| |
| *Observar processos de relacionamentos entre objetos.
| |
| | |
| Modelar implica em construir modelos. Então como fazer isto?
| |
| | |
| Podemos definir as etapas envolvidas na construção de modelos em :
| |
| | |
| #Modelo conceitual
| |
| #Modelo lógico
| |
| #Modelo físico
| |
| | |
| ==Modelo conceitual==
| |
| | |
| Representa as regras de negócio sem limitações tecnológicas ou de implementação. Por isto é a etapa mais adequada para o envolvimento do usuário que não precisa ter conhecimentos técnicos.<br>
| |
| Neste modelo temos:
| |
| | |
| *Visão Geral do negócio.
| |
| *Facilitação do entendimento entre usuários e desenvolvedores.
| |
| *Possui somente as entidades e atributos principais.
| |
| *Pode conter relacionamentos n para m.
| |
| | |
| ==Modelo lógico==
| |
| | |
| Leva em conta limites impostos por algum tipo de tecnologia de banco de dados. (banco de dados hierárquico , banco de dados relacional ,etc.). <br>
| |
| | |
| Suas características são:
| |
| | |
| *Deriva do modelo conceitual e via a representação do negócio
| |
| *Possui entidades associativas em lugar de relacionamentos n:m
| |
| *Define as chaves primárias das entidades
| |
| *Normalização até a 3a. forma normal
| |
| *Adequação ao padrão de nomenclatura
| |
| *Entidades e atributos documentados | |
| | |
| ==Modelo Físico==
| |
| | |
| Leva em consideração limites impostos pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos não funcionais dos programas que acessam os dados. <br>
| |
| | |
| Características:
| |
| | |
| *Elaborado a partir do modelo lógico
| |
| *Pode variar segundo o SGBD
| |
| *Pode ter tabelas físicas
| |
| *Pode ter colunas físicas
| |
| *Precisamos definir agora entidade e atributo. O que são e o que representam?
| |
| | |
| Uma '''Entidade''' pode ser definida como qualquer coisa do mundo real, abstrata ou concreta, na qual se deseja guardar informações. Exemplos de entidades: Cliente, Produto, Contrato, Vendas.
| |
| | |
| Um atributo é tudo o que se pode relacionar como propriedade da entidade. (coluna , campo , etc,..). Exemplos de atributos: Código do Produto (Entidade Produto), Nome do Cliente (Entidade Cliente).
| |
| | |
| Nota: Chama-se Domínio o conjunto de valores possíveis do atributo.
| |
| | |
| Obs: Nenhum modelo é suficientemente claro se não for acompanhado de uma definição formal dos elementos, fazemos isto através do Dicionário de Dados . Lembre-se conceitos que podem ser triviais a quem esta modelando podem não ser para pessoas leigas no assunto. Assim o dicionário de dados tem o objetivo de deixar claro qualquer informação que seja de valia para o processo de compreensão e unificação de conceitos.
| |
| | |
| Para que fique claro vamos fazer um exercício simples: Definir uma entidade que represente as informações de uma Pessoa e descrever seus atributos.
| |
| | |
| Podemos definir a entidade '''Pessoa''' que irá representar as informações de uma pessoa. Abaixo temos a representação da entidade e de alguns de seus atributos feitos no ERWin.
| |
| | |
| {| border="1" cellpadding="5" cellspacing="0"
| |
| ! style="background: #FFC125; text-align:left; " | PESSOA: Número sequencial identificador único
| |
| |-
| |
| !style="text-align:left; color:gray" | Nome da pessoa (letras)<br> CPF da pessoa (número)<br> Data de Nascimento (data)<br>Endereco da pessoa (texto)<br>Nome do Pai (texto)<br>Nome da Mãe (texto)<br>Telefone (texto) <br>E-mail (texto)
| |
| |}
| |
| | |
| | |
| Note que na definição dos atributos está definindo a natureza do tipo de atributo. Exemplos de tipos de natureza: Texto, Número, Data, Indicador(sim/não), entre outros.
| |
| | |
| Alguns atributos são obrigatórios outros são opcionais.
| |
| | |
| ''Nome é obrigatório pois toda pessoa deve ter um nome.''
| |
| | |
| ''Telefone é opcional pois nem toda pessoa possui um telefone.''
| |
| | |
| | |
| Então podemos fazer as seguintes definições:
| |
| | |
| ;Atributo obrigatório: É aquele que para uma instância de uma entidade ou relacionamento deve possuir um valor não nulo (NOT NULL).
| |
| | |
| ;Atributo opcional: É aquele que não é obrigatório para uma instância da entidade ou relacionamento pode possuir um valor nulo (NULL).
| |
| | |
| Podemos ainda classificar os atributos como:
| |
| | |
| ;Chave Primária: É o atributo capaz de '''identificar exclusivamente''' cada ocorrência em uma entidade. Também conhecido como Primary Key (PK). Ex: Código do Cliente, Código do Produto. O símbolo # é usado para representar a chave primária em algumas notações.
| |
| | |
| ;Chave Candidata: Atributo ou grupamento de atributos que têm a propriedade de '''identificar unicamente''' uma ocorrência da entidade . Pode vir a ser uma chave Primária. A chave candidata que não é chave primária também chama-se chave Alternativa.
| |
| | |
| Características de uma Chave Primária:
| |
| | |
| *Não pode haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na Chave Primária
| |
| *A chave primária não pode ser composta por atributo opcional, ou seja, atributo que aceite nulo.
| |
| *Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada instância de um entidade.
| |
| *Não devem ser usadas chaves externas. (Atributos sobre os quais você não tem controle. Ex: CPF)
| |
| *Cada atributo identificador da chave deve possuir um tamanho reduzido
| |
| *Não deve conter informação volátil (que possa ser modificada).
| |
| | |
| Ao criar modelos geralmente temos diversas entidades cada uma com diversos atributos que podem se relacionar entre si.
| |
| | |
| O que é um relacionamento?
| |
| | |
| Um relacionamento pode ser entendido como uma associação entre instâncias de Entidades devido a regras de negócio. Normalmente ocorre entre instâncias de duas ou mais Entidades, podendo ocorrer entre instâncias da mesma Entidade (auto-relacionamento).
| |
| | |
| Por que o relacionamento é necessário?
| |
| | |
| *Quando existem várias possibilidades de relacionamento entre o par das entidades e se deseja representar apenas um
| |
| *Quando ocorrer mais de um relacionamento entre o par de entidades
| |
| *Para evitar ambiguidade
| |
| *Quando houver auto-relacionamento
| |
| | |
| Para definir o número de ocorrências de uma entidade usamos o conceito de Cardinalidade.
| |
| | |
| A Cardinalidade indica quantas ocorrências de uma Entidade participam no mínimo e no máxima do relacionamento.
| |
| | |
| Cardinalidade Mínima - define se o relacionamento entre duas entidades é obrigatório ou não.
| |
| Ex: Abaixo temos a entidade Pais e a Entidade UF.
| |
| | |
| http://www.macoratti.net/cbmd1.htm
| |
| -->
| |