Modelagem de Dados 2 Modelos de Bancos de
Modelagem de Dados 2. Modelos de Bancos de Dados © Márcio Moreira – 2018 – www. teraits. com/pitagoras/marcio/
Modelagem de Dados 2. Modelos de Bancos de Dados 1º Encontro: Modelos de Bancos de Dados
Por que precisamos de modelagem?
Como funciona a modelagem?
Os 3 níveis de modelagem
Análise de Requisitos & Modelo Conceitual Análise de Requisitos • O processo de inicialização de um banco de dados de sucesso começa no procedimento de levantamento e de análise de requisitos, de acordo com Coronel e Rob (2011). Assim, nesta etapa, são levantadas as necessidades do cliente. Modelo Conceitual • Assim que os requisitos do software forem levantados, o próximo passo é a modelagem conceitual. Não contém detalhes sobre como será representado em meio físico; representa as informações no nível da realidade do que será modelado. Navathe e Ramez (2005) afirmam que a modelagem conceitual é uma descrição concisa das informações que o software deverá possuir, de acordo com seus requisitos. É uma representação do que precisa ser realizado (não é a solução do problema). • Segundo Coronel e Rob (2011), o modelo conceitual traz algumas vantagens importantes: fornece a visão de nível macro, de forma simplificada e independente de hardware e de software, não sendo necessária a realização de adaptações em função de determinado SGBD ou equipamento que serão adotados posteriormente.
Modelo Lógico Modelo Conceitual • O modelo lógico do banco de dados é a etapa em que mapeamos o conceito de modelos de entidade e relacionamentos com o foco na criação do banco de dados. Nesta etapa as entidades são transformadas em tabelas para armazenar as informações, são estabelecidos os relacionamentos, decididas as regras e determinados os de tipos de dados para cada campo da tabela, como descrevem Korth, Silberschatz e Sudarshan (2012). • O modelo lógico se transforma em um modelo mais abstrato (conceitual) para um modelo com mais detalhes de implementação, ou seja, mais próximo do que será de fato implementado. Cougo (1997) define como modelo lógico de dados aquele em que os objetos, suas características e seus relacionamentos sejam representados de acordo com as regras de implementação e limites impostos por alguma tecnologias de determinado SGBD.
Modelo Físico • Na última fase do projeto de banco de dados é realizada a modelagem física. Navathe e Ramez (2005) afirmam que é justamente nesta fase que são determinadas as estruturas de armazenamento interno, as chaves (ou índices) e estabelecidos os diversos caminhos de acessos a base de dados. Esse modelo descreve o detalhamento ao nível do SGBD, nível físico de criação dos componentes do banco de dados.
Exemplo de Requisitos Uma escola de ensino fundamental bilíngue necessita de um software para seu gerenciamento acadêmico. Após algumas entrevistas, o analista de sistemas levantou os seguintes requisitos essenciais para o projeto de banco de dados: A escola possui diversos departamentos (são grandes áreas de conhecimento: matemática, estudo da linguagem, etc. ) Um departamento pode oferecer diversas disciplinas, mas a disciplina irá pertencer somente a um departamento Um aluno pode estar matriculado em um único curso Uma mesma disciplina pode constar no currículo de diversos cursos Todo professor pertence a um departamento e o mesmo poderá lecionar em diversas disciplinas
Modelo Conceitual
Modelo Lógico Simplificado LECIONA
Modelo Físico Implementado no Access
Comentário As primeiras etapas da modelagem do banco de dados (conceitual e lógica) são de grande relevância para atender às necessidades do cliente, enquanto a última etapa, de modelagem física, está voltada diretamente ao SGBD escolhido para ser utilizado na criação do banco de dados. Cada etapa possui a sua importância, mas projetar um banco de dados é vital para o sucesso do software que está sendo desenvolvido.
Teoria & Prática em Modelagem de Dados
Modelagem da Escola Implemente no EA o Modelo da Escola (PK Racionalizada) 1/2 » o o o » » Alunos: id. Aluno Matricula Nome Email id. Curso INT PK INT VARCHAR(60) VARCHAR(40) INT FK o o id. Curriculo INT id. Disciplina INT id. Curso INT Carga. Horaria INT o o » Curriculos: PK FK FK Cursos: id. Curso Sigla id. Departamento INT PK VARCHAR(60) CHAR(4) INT FK Disciplinas: o o o id. Disciplina Ementa Sigla id. Departamento INT PK VARCHAR(60) VARCHAR(MAX) CHAR(4) INT FK
Modelagem da Escola Implemente no EA o Modelo da Escola (PK Racionalizada) 2/2 » o id. Departamento o Departamento » » Departamentos: o id. Prof. Disciplina o id. Professor o o o o INT PK VARCHAR(60) » Profs. Disciplinas: INT INT PK FK FK Professores: id. Professor Nome Nascimento Admissao Formacao Foto id. Departamento INT PK VARCHAR(60) DATE VARCHAR(60) IMAGE INT FK View: Pitágoras o Pacote: 4º Encontro (18/3/2021) § Diagrama: Data Modeling
Modelagem de Dados 2. Modelos de Bancos de Dados 2º Encontro: Modelagem usando Entidade-Relacionamento
Modelo de Entidade - Relacionamento O Modelo de Entidade - Relacionamentos (ou MER) foi desenvolvido para aperfeiçoar o projeto do banco de dados, permitindo a especificação do modelo conceitual, conforme afirmam Korth, Silberschatz e Sudarshan (2012). É o modelo mais utilizado pelos Sistemas Gerenciadores de Banco de Dados e foi elaborado por Edgar F. Codd em 1970 mas foi a partir de 1987 que começou a ser adotado pelas empresas de desenvolvimento de software.
Modelo Relacional O modelo lógico, ou seja, o modelo relacional de um banco de dados é criado a partir do levantamento de requisitos e do modelo conceitual. O processo de mapeamento dos dados entre os modelos (conceitual-lógico) é chamado de modelagem relacional. A abordagem relacional, segundo Abreu e Machado (2009), parte do princípio que as informações em uma base de dados podem ser consideradas como relações matemáticas e que devem ser representadas em formas de tabelas.
Modelo Relacional Representação Gráfica A representação gráfica da modelagem relacional é a forma de representação dos componentes do modelo lógico de um banco de dados. Esta representação é uma parte muito importante da compreensão do esquema do banco de dados. Uma representação simples e intuitiva é fundamental para o entendimento e comunicação das pessoas envolvidas na criação do modelo do banco de dados. De acordo com Korth, Silberschatz e Sudarshan (2012), existe uma série de notações alternativas para a realização da modelagem, sendo que as mais utilizadas são as de Peter Chen, IDEF 1 X, James Martin (com o famoso Pé de Galinha) e a notação UML.
Tabela Um banco de dados é formado por um conjunto de tabelas que estão relacionadas entre si. Cada tabela do banco de dados deve ter um nome único e significativo, por exemplo: uma tabela que guarda informações de automóveis, pode ter como nome “automóvel” e não “Tabela_A”.
Características das Tabelas Coronel e Rob (2011), as tabelas possuem algumas características: A tabela é vista como uma estrutura composta de linhas e colunas (bidimensional). Cada linha ou registro representa uma única ocorrência da entidade no interior do conjunto da entidade. Cada coluna da tabela representa um atributo e possui nome diferente (dos demais atributos da mesma tabela). Cada intersecção entre linha e coluna representa um único valor (é o dado da tabela). Todos os valores em uma coluna devem possuir o mesmo formato. A ordem das coluna e das linhas é insignificante para um SGBD. Cada tabela deve representar um atributo ou uma combinação de atributos que identifique exclusivamente cada linha (chamado de chave, que será estudado mais adiante).
Tipos de Entidades Korth, Silberschatz e Sudarshan (2012) e Navathe e Ramez (2005): Entidades Fortes Entidades Fracas ou Dependentes » É uma tabela autônoma que não depende de outra para sua existência. Exemplos: » o Aluno, Curso, Cliente, Empresa, Paciente. o Na análise de requisitos é facilmente encontrada, visto que são substantivos fortes e significativos. » » É uma tabela que necessita de outra para realmente existir e somente existe por causa da Entidade Forte. Exemplos: o Dependentes de Funcionários. Se o funcionário existe pode ter dependentes. Se ele não existe, logo não há dependentes Entidades Agregadas » É criada quando temos um conjunto de Entidades Subordinadas » » campos que se repetem em mais de uma entidade. Exemplo: o Aluno e Professor possuem em comum dados do endereço; para evitar repetições, podemos criar uma nova entidade agregada chamada Endereço para guardar os endereços. » Representa uma especialização em que uma entidade supertipo possui várias entidades subordinadas que são especializadas com atributos específicos. Exemplo: o Podemos ter dois tipos de clientes: Pessoa Física e Pessoa Jurídica. Ambos têm campos em comum que ficariam na entidade supertipo Cliente e, nas entidades Pessoa Física e Pessoa Jurídica, somente
Relacionamentos Conceito & Grau do Relacionamento ou Cardinalidade » » » As entidades podem ser conectadas. Essa conexão entre as entidades é chamada de relacionamento. Um relacionamento descreve uma associação entre entidades como afirma Coronel e Rob (2011). Os relacionamentos envolvendo tabelas fracas resultam em uma tabela associativa e que deve ser representada por meio de um losango com bordas duplas. » Num relacionamento, o número de ocorrências de uma entidade que está associada, com ocorrências de outra entidade, determina o grau de relacionamento ou cardinalidade entre as tabelas, como afirma Abreu e Machado (2009). Unário • A entidade se relaciona com ela mesma • Ex: Chefe - Subordinado Binário • Uma entidade se relaciona com outra • Ex: Professor - Disciplina Ternário • Relacionamento entre 3 entidades Quaternário • Relacionamento entre 4 entidades N-ário • Relacionamento entre n entidades • Pode gerar redundância
Cardinalidades dos Relacionamentos Auto relacionamento Um-para-Um (1 para 1) » » » É um tipo de relacionamento unário Nele os elementos de uma entidade se relacionam a outros elementos dessa mesma entidade Ex: Funcionário possui um chefe ou superior que, por sua vez, também é um funcionário e que supervisiona vários empregados » É um tipo relacionamento binário Tem como características que cada tabela terá somente uma única ocorrência da outra tabela Ex: Em uma agência de empregos um Candidato pode cadastrar somente um Currículo e o Currículo pertence somente a um Candidato
Cardinalidades dos Relacionamentos Um-para-n (1 para n ou n para 1) Muitos-para-Muitos (n para n) » » Uma entidade pode referenciar várias unidades da outra. Porém, do outro lado só pode ser referenciada uma única vez Ex: O Funcionário precisa informar a Cidade de seu nascimento e ele só pode indicar uma única Cidade. Mas, essa Cidade pode ser referenciada várias vezes por outros Funcionários Na figura lemos: o Em Cidade: Uma Cidade tem no mínimo 1 e no o máximo n Funcionários Em Funcionário: Um Funcionário pode ter mínimo 1 e no máximo 1 Cidade » » Cada entidade envolvida pode referenciar múltiplas ocorrências. O relacionamento resultante geralmente é um verbo, por exemplo: atender, consultar, realizar, entre outros Ex: Um Aluno pode cursar vários Cursos e o mesmo Curso pode possuir vários Alunos Na figura lemos: o o Em Aluno: Um Aluno pode cursar 1 ou n cursos Em Curso: Um Curso podem cursar 0 ou n alunos A definição da cardinalidade é de fundamental importância para o sucesso do banco de dados. Após realizar uma modelagem de um banco de dados, considere sempre mostrar o diagrama para seus colegas, pois a opinião deles pode levantar problemas que na hora de modelar foram esquecidos. E, claro, o cliente deverá sempre ser consultado nos casos em que a cardinalidade for muito duvidosa.
Teoria & Prática em Modelagem de Dados
CHAR x VARCHAR até uns 16 caracteres (estáticos) x VARCHAR: ≤ 16 e dinâmicos CHAR(n) VARCHAR(n) » » Aloca “n” caracteres no campo » » Se n = 10 então Aloca 10 caracteres para o campo » Após uma edição: » » Char (10): Var. Char: Dados do Campo (Atributo) 1 2 3 4 5 6 7 8 9 10 #Car Dados do Campo 5 t o Tamanho máximo: n (número de caracteres) (fica na estrutura da tabela) o Tamanho atual: x (x caracteres) (campo de 4 bytes) o Espaço para os dados (campo) » o Incluiu a palavra teste o Campo: “teste “ e s t e Cria uma estrutura dinâmica: Após uma edição: o Onde incluímos a palavra: teste o Usando n = 10 o Estrutura: § § § Tamanho máximo: 10 Tamanho atual: 5 Espaço para os dado: teste
Modelagem de Endereços Tabela de CEPs resultante » CEPs: o o o o » CEP id. Localidade id. Bairro. Inicial id. Bairro. Final Tipo. Logradouro Nome. Logradouro Lado. Numero CHAR(8) PK INT FK ou Nulo CHAR(36) Se Nulo => Não usa o Tipo do Logradouro VARCHAR(100) CHAR(1) A=Ambos, P=Par, I=Ímpar, D=Direito e E=Esquerdo Considerando o uso do modelo: o Pais > Estados > Localidades > Bairros > CEPs o Monta-se a tabela de CEPs para o Brasil utilizando os dados obtidos Correios
Modelagem de Pessoas » Pessoas: o id. Pessoa INT PK o Tipo. Pessoa CHAR(1) » F=Física, J=Jurídica Pessoas. Fisicas: o o o id. Pessoa INT PK / FK Nome VARCHAR(100) Apelido VARCHAR(50) Data. Nascimento DATE CPF CHAR(11) RG CHAR(18) Orgao. Exp. RG CHAR(18) Data. Emi. RG DATE Nome. Social VARCHAR(50) Sexo CHAR(1) M/F Genero CHAR(18) » Pessoas. Juridicas: o o o o id. Pessoa INT PF / FK Razao. Social VARCHAR(100) Nome. Fantasia VARCHAR(50) Data. Abertura DATE CNPJ CHAR(15) Inscricao. Estadual CHAR(18) Inscricao. Municipal CHAR(18)
Modelagem de Pessoas Telefones & E-Mails » o id. Tipo. Fone o Tipo. Fone » » Tipos. Fones: CHAR(1) PK CHAR(20) o o id. Pesosa. Fone id. Pessoa Telefone id. Tipo. Fone o id. Tipo. Email o Tipo. Email » Pessoas. Fones: INT PK INT FK CHAR(18) CHAR(1) FK Tipos. Emails: CHAR(1) PK CHAR(20) Pessoas. Emails: o o id. Pessoa. Email id. Pessoa Email id. Tipo. Email INT PK INT FK VARCHAR(60) CHAR(1) FK
Modelagem de Pessoas Endereços » Tipos. Endereços: o o » id. Tipo. Endereco CHAR(1) PK CHAR(20) Pessoas. Enderecos: o o o id. Pesosa. Endereco id. Pessoa CEP Pais Estado id. Localidade id. Bairro Tipo. Logradouro Nome. Logradouro Numero Complemento id. Tipo. Endereco INT PK INT FK CHAR(8) FK CHAR(2) INT FK CHAR(36) VARCHAR(100) CHAR(6) CHAR(36) CHAR(1) FK
Modelagem Pessoas Final
Ajustes de Exibição do Exemplo » Definindo o Diagrama Default (padrão) para quando o EA for aberto: o Abra o diagrama desejado o Layout > Manage > Set as Model Default » Visualização limpa de DERs: o o Clique com o botão direito do mouse numa área limpa (branca) do Diagrama Em Elements desmarque a opção Operations Em Connectors Marque a opção Supress All Connector Labels Em Connection Notation seleciona Information Engineering o Após isso: o Marque todos os elementos usando Control + A o Ajuste o tamanho de todos os elementos usando Alt + z
Modelagem de Dados 2. Modelos de Bancos de Dados 3º Encontro: Diagrama Entidade-Relacionamento
Objetivo & Modelagem Física O Diagrama de Entidade-Relacionamento tem como objetivo a preparação para a implementação física do banco de dados no Sistema Gerenciador de Banco de Dados. Sendo assim, agora, você entrará de fato no processo de modelagem de dados, criando os diagramas de entidaderelacionamentos. A fase de modelagem física requer a aplicação de comandos para a criação das tabelas e campos dependendo diretamente da modelagem lógica. É de fundamental importância ter o projeto lógico (o mais correto possível) para a criação física do banco de dados.
Modelo Lógico – Relacional » O modelo de dados lógico ou relacional trabalha com esquemas compostos de tabelas. » Para que uma tabela realmente exista, é necessário que possua diversas propriedades, que nada mais são do que os seus atributos ou campos. » Cada campo, por sua vez, possui uma descrição de seu tipo de dado e tem as seguintes características: o o Contém todas as tabelas e os relacionamentos entre elas. Descrição de todos os atributos de cada tabela. Identificação de um atributo chave para cada tabela. Determinação de relacionamentos por meio de chaves.
Definições Korth, Silberschatz e Sudarshan (2012) afirmam sobre modelo relacional: Relação • O termo relação é designado para se referir a uma tabela Tupla • Para a linha é utilizado o termo tupla, referindo-se a uma determinada linha da tabela Atributo • O atributo é conhecido como a coluna de uma tabela Instância de Relação • O termo instância de relação é designado a um determinado conjunto de tuplas ou a um determinado número de registros (algumas linhas selecionadas de uma tabela)
Chave de Tabela PK Em um determinado banco de dados existe uma tabela de clientes com centenas de registros cadastrados. Será que existe a possibilidade de procurar um determinado cliente pelo seu nome e aparecer mais de um registro como resultado? Há possibilidades de duplicidade de nomes em uma tabela? Se a possibilidade de repetição existe, como garantir que o cliente certo seja encontrado? Para solucionar esse dilema, no banco de dados relacional, há a necessidade de estabelecer um ou mais campos para ser uma chave de identificação do registro armazenado. Alguns valores do registro até poderão ser repetidos, como duas ou mais pessoas com exatamente o mesmo nome, mas, obrigatoriamente, deve haver um campo na tabela que nunca se repete. Este campo será o campo chave da tabela.
Tipos de Chaves Chave Primária » Coronel e Rob (2011) explicam que uma chave consiste em um ou mais atributos que determinam a existência de outros. Elas são utilizadas para estabelecer os relacionamentos entre as tabelas e para estabelecer a integridade referencial dos dados. Os tipos de chaves em uma tabela podem ser: Chave Concatenada ou Composta Chave Substituta ou Surrogada Chave Secundária Chave Estrangeira
Chave Primária PK: Primary Key » Um dos fundamentos primordiais de um banco de dados é que em cada tabela exista uma chave primária, que também é conhecida como Primary Key (ou somente PK). » Devemos escolher um dos campos da tabela para ser a chave primária. Na figura foi escolhido o campo CPF como chave primária, pois temos certeza que uma pessoa não pode ter o CPF igual ao de outra pessoa. » Na forma textual, a chave primária deve sempre ficar em evidência, em negrito, sublinhada e com sinal # na sua frente. Observe como ficaria a tabela Cliente da figura, Cliente (#CPF, Nome, RG, Dt Nasc, Cidade). A ordem dos campos não prejudica em nada os campos das tabelas, porém, para fins didáticos e para facilitar a identificação, nos exemplos, a chave primária ficará sempre como o primeiro campo da tabela.
Chave Composta » A figura mostra o uso do RG, como esse número pode se repetir dependendo do órgão expedidor, não seria uma boa escolha para a chave primária. » Assim, caso quiséssemos realmente usar o RG, deveríamos solicitar também o órgão expedidor do documento, essas duas informações em conjunto não se repetem, e é justamente esse o conceito de chave concatenada ou composta. Um ou mais campos que juntos não podem repetir. » A forma textual da tabela Cliente demonstrada na figura ficaria da seguinte forma: Cliente (#RG, # Órgão Expedidor, Nome, CPF, DT Nasc).
Chave Surrogada Surrogate Key = Chave Substituta » A chave substituta ou surrogada e que também é conhecida como Surrogate Key é uma chave primária criada exclusivamente para impedir que os registros da tabela venham a repetir e que não tenha um campo para ser a chave primária. Este tipo de chave, é um campo criado de valor inteiro e ele tem um autoincremento. » A cada registro adicionado na tabela, o campo recebe um incremento e assim sucessivamente (o próprio SGBD se encarrega do incremento). Este tipo de campo nunca pode ser alterado e também nunca pode ser reaproveitado, em casos em que o registro for apagado, não há como reaproveitar o valor de uma chave substituta. » A forma textual da tabela Encomenda: Encomenda (#Código, Encomenda, Quantidade, Preço Unitário).
Chave Secundária Secondary Key (Index Key) » De acordo com Coronel e Rob (2011), a chave secundária é uma chave utilizada para fins de recuperação de informação. » É uma chave que auxilia na recuperação de um registro caso, por exemplo, um paciente de um consultório tenha o CPF como chave primária mas não tem acesso ao número. » Com a chave secundária, podemos usar algum mecanismo de busca utilizando o campo do sobrenome ou a data de nascimento para realizar uma pesquisa no banco de dados.
Chave Estrangeira FK: Foreign Key » Korth, Silberschatz e Sudarshan (2012) descrevem a Chave Estrangeira (também conhecida como Foreign Key – FK) como sendo uma chave primária de outra tabela. É com esta chave que ocorrem os relacionamentos entre as tabelas de um banco de dados. » Com o relacionamento entre as tabelas Cliente e Cidade, teremos a seguinte forma textual entre as duas tabelas: Cidade (#Cod. Cidade, Cidade) Cliente (#CPF, Nome, DT Nasc, &Cod. Cidade) » »
Integridade Referencial » Segundo Coronel e Rob (2011), a integridade referencial tem como exigência básica a sua existência em uma outra tabela, como chave primária. Estabelecer a integridade referencial é justamente garantir que, ao relacionar uma tabela com outra, haverá a garantia de que a chave estrangeira tenha sido cadastrada (primeiramente) como chave primária de outra tabela que compõe o relacionamento. E, para estabelecer a integridade referencial precisamos seguir alguns passos. Clique nos botões para conhecê-los: 1º Passo: Observar no diagrama os relacionamentos. Procure por cardinalidades do tipo N nas tabelas. 2º Passo: Existe um ou mais cardinalidades do tipo N? Se sim, haverá chaves estrangeiras. Podem haver vários Ns nas tabelas e, consequentemente, várias chaves estrangeiras. 3º Passo: A tabela do lado 1 deverá receber novos campos, para criar o relacionamento. Insira a chave primária da tabela correspondente ao relacionamento do lado N.
Notações Peter Chen » Para representar as cardinalidades no modelo gráfico de um Diagrama de Entidade-Relacionamentos, podemos utilizar diversas notações. Uma notação gráfica é a forma de como algo é criado, desenhado ou projetado, são os padrões que deverão ser adotados no desenvolvimento de algo. Cougo (1997) descreve algumas notações. » Peter Chen: o Na figura podemos observar um relacionamento 1 para N sendo representado em três notações diferentes.
Notações Bachman ou Setas » A notação de Bachman é utilizada em muitos softwares para a criação de modelos lógicos de um banco de dados. Este modelo sofreu algumas alterações e se transformou na notação de Setas, adotada por vários softwares.
Notações James Martin » A notação de James Martin e seu famoso diagrama de “Pé de Galinha” também é muito popular entre as ferramentas de criação de modelos gráficos de esquemas de banco de dados.
Modelo Entidade – Relacionamento 1º Passo: Identificar as Tabelas
Modelo Entidade – Relacionamento 2º Passo: Identificar Relacionamentos e Cardinalidades
Modelo Entidade – Relacionamento 4º Passo: Criar o modelo textual com os campos de cada tabela
Modelo Entidade – Relacionamento 5º Passo: Achar as chaves primárias
Modelo Entidade – Relacionamento 6º Passo: Inserir as FKs das tabelas que estão relacionadas e possuem o N
Vídeo de Encerramento » Essa unidade trouxe subsídios para o início do processo de modelagem de dados. Aprendemos sobre os modelos de banco dados conceitual e físico para conseguir criar os modelos de entidade-relacionamentos, conceitos muito importantes para sua atuação como profissional da área. » https: //s 3. amazonaws. com/cm-klscontent/201802/INTERATIVAS_2_0/MODELAGEM_DE_DADOS/U 2/S 3/index. html
Teoria & Prática em Modelagem de Dados
Auto Incremento no EA Modelo Chave Substituta (Surrogate Key) » Crie as relações: » o Cores(#id. Cor, Cor) o Marcas(#id. Marca, Marca) Na área de detalhes do atributo: o Defina o Auto. Num (auto incremento) como True (verdadeito) o Os atributos id. Cor e id. Marca são PK e devem ter auto incremento » No EA: o Inclua o atributo chave com o tipo INT e marque-o como PK o Note que o Not Null será setado automaticamente » Detalhes do Auto Incremento: o Star. Num: Número inicial (padrão 1) o Increment: Incremento (padrão 1) o Nor. For. Rep: Permite replicação (padrão não)
Chave Estrangeira (FK) no EA Modelo Chave Substituta (Surrogate Key) » Crie a relação: o Carros(#id. Carro, Placa, &id. Cor, &id. Marca) o Note que os atributos id. Cor e id. Marca são Chaves Estrangeiras (Foreign Keys: FK) » No EA: o Depois de modelar a tabela filha com os mesmos atributos da tabela pai, faça a Associação da tabela filha com a pai o Ao fazer a Associação o EA vai mostrar a tabela pai e a filha com os atributos de associação (PK na pai e FK na filha) o Nas propriedades do relacionamento ajuste o necessário, especialmente a Cardinalidade (1 pai para x filhos)
Notações no EA » No EA: o Na área livre do DER clique com o botão direito do mouse, selecione Propriedades, Conectores o Marque: Supress All Conector Labels (suprimir todos os rótulos dos conectores) o A notação do James Martin (Pé de Galinha ou IE: Information Engineering é padrão) o o o Se quiser tirar os nomes das operações, em Propriedades, selecione: Elementos e desmarque Operações (Compartimentos) Notação IE do DER sem operações: Notação IDEF 1 X (Integration DEFinition) de Peter Chen no DER sem operações:
Exercício Modele o Diagrama abaixo incluindo a relação Filme – Atua – Ator Filme. Ator(#&id. Filme, #&Cod. Ator)
Referências Autores Título Local Ano Claudia Werlich Fundamentos de bancos de dados Pitágoras 2018 Claudia Werlich Modelos de banco de dados Pitágoras 2018 Márcio Moreira Planejamento Estratégico & Gestão de Performance Pitágoras 2011 OMG Business Process Model and Notation – BPMN: Version 2. 0 OAT 2011 OMG UML - Unified Modeling Language OMG 2017 Sparx Systems Enterprise Architect User Guide Sparx 2014
Obrigado! Siga-nos nas redes sociais Tera & Márcio Moreira
- Slides: 62