MODELAGEM DE DADOS ATRAVÉS DO MODELO ENTIDADE-RELACIONAMENTO
Para visualizar melhor essa aula, gire seu celular para a posição horizontal
Nesta webaula, você irá aprender a estabelecer os relacionamentos entre as tabelas e suas cardinalidades, entrando realmente na parte prática de modelar um banco de dados.
MODELO DE ENTIDADE
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.
Para visualizar melhor essa aula, gire seu celular para a posição horizontal
MODELAGEM 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.
Para visualizar melhor essa aula, gire seu celular para a posição horizontal
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, IDEF1X, James Martin (com o famoso Pé de Galinha) e a notação UML.
Clique nas palavras em destaque
X
Peter Chen
X
James Martin
Para visualizar melhor essa aula, gire seu celular para a posição horizontal
TABELA
O modelo relacional é um conceito matemático conhecido como relação, no qual dois conjuntos numéricos possuem seus termos relacionados entre si. No modelo conceitual, um conjunto é chamado de entidade, já no modelo lógico é chamado de tabela.
Cada tabela é definida com um conjunto de atributos que descrevem suas características particulares, esses atributos também são conhecidos como campos.
Cada linha de uma tabela representa um conjunto de campos e são conhecidos como registros ou tuplas. Uma tabela pode ter milhares de registros (milhares de linhas), quem limita a quantidade de linhas de uma tabela é o SGBD.
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”.
De acordo com Coronel e Rob (2011), as tabelas possuem algumas características. Explore a galeria para conhecê-las:
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).
ENTIDADE
Cada tabela que representa uma entidade do modelo conceitual pode ser classificada em: Entidade Forte ou Entidade Fraca. Conforme Cougo (1997), esta distinção se dá com a análise de existência de duas condições básicas: dependência de existência ou dependência de identificador. Uma entidade é fraca se um desses dois tipos de dependência existir no relacionamento entre duas entidades.
Korth, Silberschatz e Sudarshan (2012) e Navathe e Ramez (2005) classificam as entidades em alguns tipos:
ENTIDADES FORTES
Entidades Fortes
Aluno, Curso, Cliente, Empresa, Paciente. Na análise de requisitos é facilmente encontrada, visto que são substantivos fortes e significativos.
é uma tabela autônoma que não depende de outra para sua existência.
ENTIDADES FRACAS OU DEPENDENTES
é uma tabela que necessita de outra para realmente existir e somente existe por causa da Entidade Forte.
Entidades Fracas ou Dependentes
A tabela Dependente só há porque existe a tabela Funcionário, pois, para que exista um dependente cadastrado, é preciso que tenha um funcionário que “possui” esse dependente. Se não existisse a tabela Funcionário, certamente não existiria a tabela Dependente.
ENTIDADES AGREGADAS
é criada quando temos um conjunto de campos que se repetem em mais de uma entidade.
Entidades Agregadas
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.
ENTIDADES SUBORDINADAS
representa uma especialização em que uma entidade supertipo possui várias entidades subordinadas que são especializadas com atributos específicos.
Entidades Subordinadas
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 estariam os campos específicos de cada tipo de cliente.
RELACIONAMENTO
ENTIDADES AGREGADAS
Cada tabela que representa uma entidade do modelo conceitual pode ser classificada em: Entidade Forte ou Entidade Fraca. Conforme Cougo (1997), esta distinção se dá pela análise de existência de duas condições básicas: dependência de existência ou dependência de identificador. Uma entidade é fraca se um desses dois tipos de dependência existir no relacionamento entre duas entidades.
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.
Quando temos um relacionamento entre duas entidades, 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).
O grau de relacionamento é a quantidade de entidades que estão ligadas ao relacionamento e pode ser de vários tipos. Clique nas abas para conhecê-los:
é um relacionamento acima de quatro tabelas envolvidas. Este tipo de relacionamento é o menos aconselhável visto que a possibilidade de redundâncias no banco pode ser maior.
EXEMPLIFICAÇÃO
CARDINALIDADE
A cardinalidade atribui um valor específico ao relacionamento, expressando a faixa de ocorrências permitidas (mínimas e máximas) entre as tabelas e, de acordo com Coronel e Rob (2011), pode ser de vários tipos.
AUTORRELACIONADA
O Autorrelacionamento é um tipo de relacionamento unário, envolvendo somente uma tabela. Nele os elementos de uma entidade se relacionam a outros elementos dessa mesma entidade, conforme pode ser observado na figura, com a tabela Funcionário. Todo funcionário possui um chefe ou superior que, por sua vez, também é um funcionário e que supervisiona vários empregados.
UM-PARA-UM
A cardinalidade Um-para-Um (1 para 1) tem como características que cada tabela terá somente uma única ocorrência da outra tabela, por exemplo, em uma agência de empregos um Candidato pode cadastrar somente um Currículo e o Currículo pertence somente a um Candidato
UM PARA MUITOS (1 .. N)
Na cardinalidade Um-para-muitos (1 para N) ou Muitos-para-um (N para 1), uma das entidades pode referenciar várias unidades da outra, porém, do outro lado só pode ser referenciada uma única vez. Por exemplo, o Funcionário precisa informar a Cidade de seu nascimento e ele só pode indicar uma única Cidade. Mas a mesma Cidade pode ser referenciada várias vezes por outros Funcionários. Conforme a figura, devemos ler da seguinte forma: Do lado direito: Um Funcionário pode estar associado a no mínimo 1 e no máximo 1 Cidade. Do lado esquerdo: Uma cidade possui no mínimo 1 funcionário e no máximo N.
MUITOS-PARA-MUITOS (N PARA N)
No relacionamento Muitos-para-muitos (N para N), cada entidade, de ambos os lados, pode referenciar múltiplas ocorrências. O relacionamento resultante da cardinalidade N para N geralmente é um verbo, por exemplo: atender, consultar, realizar, entre outros. Por exemplo: um Aluno pode cursar vários Cursos e o mesmo Curso pode possuir vários Alunos. De acordo com a figura, devemos ler da seguinte forma: Do lado direito: em um curso podem cursar 0 ou N alunos. Do lado esquerdo: Um aluno pode cursar 1 ou N cursos.
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.
Para visualizar melhor essa aula, gire seu celular para a posição horizontal
