Mod BD UD2 Deseño Conceptual
Sumario
- 1 Fases de deseño de bases de datos
- 2 Modelo entidade-relación
- 3 Modelo E-R ampliado
- 4 Referencias e créditos
Fases de deseño de bases de datos
Modelo e esquema
Modelar é definir un mundo abstracto e teórico tal que as conclusións que se poidan sacar del, coinciden coas manifestacións aparentes do mundo real.
Modelo é o instrumento que se aplica a unha parcela do mundo real denominada universo do discurso (UD) para obter unha estrutura de datos á que se chama esquema, é dicir, é o conxunto de conceptos, regras e convencións que permiten describir unha parcela do mundo real.
É importante distinguir entre modelo (instrumento) e esquema (resultado de aplicar o instrumento).
Deseño de bases de datos
O deseño dunha base de datos debe ser un proceso no que se van seguindo unha serie de etapas que van dende a definición do UD ata a creación do esquema da base de datos para poder introducir datos nela, pasando pola elección do modelo de datos utilizado polo SXBD empregado para o seu manexo.
A creación dunha base de datos sen un deseño previo conducirá a continuas modificacións e dará lugar a perdas de tempo, inconsistencias e redundancias de datos.
O deseño dunha base de datos iníciase identificando e caracterizando ben os límites do problema que se pretende solucionar, e determinando os datos que interveñen no problema e a forma na que poden ser medidos, é dicir, definindo o universo do discurso (UD), que é a visión ou definición dun mundo abstracto e teórico que o deseñador ten do mundo real.
Distínguense tres fases no deseño de bases de datos:
- deseño conceptual
- deseño lóxico
- deseño físico.
A seguinte gráfica mostra as fases e os esquemas correspondentes.
Móstrase na seguinte gráfica o resultado de cada fase do deseño.
Resultado de cada fases de deseño
Na fase de deseño lóxico o modelo de datos empregado pola gran maioría dos sistemas xestores de bases de datos é o modelo Relacional.
Partindo dos requirimentos do sistema, obtense o esquema conceptual representado mediante un diagrama Entidade-Relación seguindo as normas do modelo Entidade-Relación.
A continuación, aplícanse as regras de transformación e normalización para obter o esquema Relacional seguindo as normas do modelo Relacional.
Por último, este esquema serve de base para crear o esquema físico da base de datos Relacional empregando as sentenzas de definición de datos (DDL ou LDD) da linguaxe SQL ou empregando ferramentas gráficas propias do SXBDR seleccionado (MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, etc.).
Fase 1. Deseño conceptual
Esta fase empeza coa identificación do problema que a aplicación ou sistema debe resolver, así como das características que a aplicación debería ter tanto dende o punto de vista estático (necesidades de información) como dinámico (operacións sobre a información).
Así pois, realizaranse as actividades necesarias para recoller o que os usuarios esperan obter do sistema e os usos que estes pretenden darlle.
Entre estas activades sóense incluír as seguintes:
- Identificar as áreas de aplicación principais e os grupos de usuarios que utilizarán o sistema de Base de Datos.
- Recompilar a documentación existente relativa ás aplicacións actuais (en caso de que existan), así como outros tipos de documentos coma manuais das regras do negocio, informes, normativas, etc.
- Realizar entrevistas a usuarios para establecer as súas prioridades, coma preferencias, importancia que lle dan ás aplicacións e aos datos, etc.
- Estudar a contorna de operación do sistema actual e os plans de aproveitamento da información.
O resultado destas actividades produce especificacións de requisitos informais, normalmente escritas nunha linguaxe funcional, que soen ser ambiguas e estar pouco ou nada estruturadas. A continuación, hai que representar eses requisitos informais mediante unha descrición formal e completa do Sistema de Información a modelar, pero independente dos criterios de representación empregados polos Sistemas Xestores de Bases de Datos.
O resultado desta fase é a creación dun esquema conceptual, que represente de forma gráfica os requirimentos obtidos, empregando un modelo de datos conceptual de alto nivel.
O modelo máis utilizado é o modelo Entidade-Relación (MER), que representa os requirimentos como entidades, atributos e relacións que vinculan ás entidades, mediante unha gráfica que se coñece co nome de diagrama Entidade-Relación. Un exemplo de diagrama Entidade-Relación pode verse na gráfica anterior.
O emprego do modelo facilitaranos unha documentación para consultar, manter ou ampliar a aplicación. Outra vantaxe é que facilitará unha forma clara de ver o proceso na súa totalidade, posto que se trata dunha representación gráfica. Este modelo, ao non estar orientado a ningún tipo de sistema físico concreto (sistema operativo ou SXBD) e non ter unha orientación informática, servirá para explicar ao usuario, ou cliente, como funciona o proceso e especificar que é exactamente o que vai obter, facilitando a comprensión e recollida de datos. Co modelo, o deseñador dedicarase exclusivamente a observar a información que necesita. En sistemas de tamaño entre medio e grande, pode que a observación do gráfico permita ver aos clientes ou aos deseñadores, carencias ou erros na comprensión do problema, que signifiquen cambios nos requirimentos, dando lugar a un proceso cíclico e con realimentación, tal e como se representa no gráfico das fases do deseño.
Resumindo, as principais características desta fase son:
- É un proceso dirixido completamente aos datos.
- Salienta a compresión dos requirimentos de información do sistema.
- Proporciona mecanismos para unha mellor comunicación entre usuarios, analistas, deseñadores e programadores durante todas as fase do deseño.
- Proporcionará as bases para deseñar unha base de datos do sistema, correcta, consistente, compatible e flexible.
No desenvolvemento, o analista deberá contestar as seguintes preguntas:
- Cal é a información principal (tipo de información e frecuencia de uso)?
- Cales son os obxectos de interese?
- Cales son os detalles que caracterizan a estes obxectos?
- Como están relacionados os obxectos?
No desenvolvemento deberase ter en conta unha serie de factores:
- Traballo interactivo cos usuarios.
- Seguimento dunha metodoloxía (pasos para o seu desenvolvemento).
- Estudo tanto da estrutura da información coma da integridade da mesma.
- Emprego de diagramas para representar o modelo conceptual.
- Construción dun dicionario de datos.
O uso dun modelado favorece os seguintes aspectos:
- Un correcto deseño da base de datos que asegure a ausencia de conflitos entre requisitos de diferentes usuarios.
- Determinación da tecnoloxía óptima para o desenvolvemento da base de datos.
- Previsión dos posibles cambios no futuro.
- Comprensión dos datos no sistema final antes da súa implementación.
- Visión global do sistema e das necesidades reais de información.
- Xeración de documentación para revisar ou manter a aplicación.
- Migración dunha base de datos a outra.
Podes atopar máis información na web de w3schools sobre a fase de deseño conceptual.
Fase 2. Deseño lóxico
Esta fase consiste en aplicar as regras de transformación sobre o modelo conceptual obtido na fase anterior, e representado mediante o diagrama Entidade-Relación, e obter o modelo de datos lóxico utilizado polo SXBD que se vai utilizar para crear a base de datos.
O modelo lóxico de datos empregado pola maioría dos SXBD actuais é o modelo relacional.
Para estes casos, a fase de deseño lóxico produce como resultado un esquema relacional, que representa as táboas que se utilizarán na base de datos, e as relacións que existen entre elas; este diagrama pode estar acompañado dun dicionario de datos.
O modelo lóxico relacional debe ser refinado mediante un proceso de normalización para evitar repeticións, anomalías, ou perdas de información, procurando obter a maior eficiencia e optimización de funcionamento. Os grafos relacionais e os diagramas relacionais son exemplos de esquemas relacionais.
- O grafo relacional representa as relacións do modelo relacional, e os enlaces que existen entre elas. Por exemplo:
- O diagrama relacional representa as táboas do esquema da base de datos e as relacións que hai entre elas. Exemplo de diagrama relacional feito co asistente de SQLServer:
Outro dos modelos de datos empregados polos SXBD é o modelo orientado a obxectos.
Este modelo de datos é unha extensión do paradigma de programación orientado a obxectos e, por tanto, adopta conceptos como: clase, método, atributo, obxecto, instancia, polimorfirmo, herdanza, encapsulamento, etc.
Deseñouse para integralo directamente con aplicacións desenvolvidas en linguaxes orientadas a obxectos, e baséase en que trata conxuntamente datos e procesos que os manexan utilizando entidades chamadas obxectos "instanciados" dunha clase.
Se o SXBD utiliza o modelo de datos orientado a obxectos, a fase de deseño lóxico produce como resultado os diagramas de clases e de obxectos. Existen distintas notacións para crear esquemas orientados a obxectos, pero o máis estendido é UML (Linguaxe Unificada de Modelado).
Un diagrama de clases en UML é un tipo de diagrama de estrutura estática que describe a un sistema mostrando as clases do sistema, os seus atributos, operacións ou métodos e as relacións entre elas.
Un diagrama de obxectos en UML é un gráfico de instancias dun diagrama de clases incluíndo obxectos e datos; é dicir, é unha foto do estado do sistema nun punto de tempo determinado da execución do sistema. Os diagramas de clases e de obxectos comparten notacións e símbolos.
Exemplo de diagramas de clase que non ten despregados os métodos:
Podes atopar máis información na web de w3schools sobre a fase de deseño lóxico.
Fase 3. Deseño Físico
Esta fase consiste na creación da base de datos física empregando as linguaxes e ferramentas propias do SXBD elixido. Unha vez creada a base de datos, xa se pode empezar coa carga e o manexo de datos.
No caso de elixir un SXBD baseado no modelo relacional (SXBDR), a linguaxe utilizada para a creación do esquema da base de datos será SQL (Structured Query Laguage ou Linguaxe estruturada de consultas).
Podes atopar máis información na web de w3schools sobre a fase de deseño físico.
Outras fases
Cabe considerar outras fases a maiores das tres descritas, xa que non é algo igualmente definido por todos os autores.
En primeirísima fase, hai autores que consideran anterior a fase de deseño conceptual a de análise de requisitos. Isto é, a descrición da información a xestionar e os seus procesos, así coma información do volume de datos, volatilidade, normas de validación, xestor de implantación, etc..
Algúnha das técnicas para a elicitación de requisitos son as entrevistas con usuarios e expertos, e a lectura de documentación.
E na parte final, en ocasións se consideran outras dúas fases:
- A de carga de datos e probas: Carga inicial e probas de verificación e validación dos requisitos do sistema (tratar de violar as regras de integridade, comportamiento ante valores límite dos tipos de dato, tempos de respuesta en consultas frecuentes e en consultas complejas, etc.)
- A de operación: posta en marcha e tarefas de mantemento e monitorización
En todo caso, polo consenso que xeneran as tres fases anteriormente descritas, déixase un resumo das mesmas na imaxe que acompaña este texto.
Modelo entidade-relación
O modelo entidade-Relacion (MER) é o modelo de datos conceptual de alto nivel máis estendido nas metodoloxías de deseño de Base de Datos (BD) e ferramentas software de deseño (tipo CASE). Foi proposto por Peter P. Chen no ano 1976, quen estableceu que "o MER pode ser empregado como unha base para a vista unificada dos datos", adoptando "o enfoque máis natural do mundo real que consiste en entidades e relacións".
O MER, debido a súa difusión e interese, recibiu aportacións e extensións de numerosos autores, polo que actualmente non se pode considerar que exista un único MER senón unha familia de modelos.
A clave do seu éxito radica en que é o modelo que mellor reflicte dunha forma sinxela e intuitiva os datos e a semántica dos sistemas que modela. En esencia este modelo describe as entidades que representan os obxectos que interveñen no problema e as relacións entre esas entidades. Todo isto plásmase nun esquema gráfico que ten por obxecto, por unha banda, axudar ao programador durante a codificación, e por outra axudar ao usuario a comprender o problema e o funcionamento do programa.
Os elementos principais do modelo Entidade-Relación son:
- entidades
- relación
- atributos
- dominios
Entidades
Pódese definir entidade como unha representación de “calquera obxecto do mundo real con existencia propia, sobre o cal queremos ter información nunha base de datos”. Unha entidade pode ser un obxecto con existencia física (unha persoa, unha casa, unha película,..) ou con existencia abstracta ou conceptual (unha viaxe, un posto de traballo, un proxecto,...).
Segundo a norma ANSI (1977), é: ”Unha persoa, lugar, cousa, concepto ou suceso, real ou abstracto, de interese para a empresa”.
Un conxunto de entidades enténdese como a totalidade das entidades do mesmo tipo que comparten as mesmas propiedades ou atributos.
Unha entidade descríbese polo seu nome e a lista de nomes dos seus atributos. Represéntase graficamente por medio dun rectángulo co nome da entidade no interior.
Exemplos de entidades: PELICULA, CLIENTE, PROVEDOR, ARTIGO. Recoméndase elixir nomes (normalmente en sigular) que comuniquen, ata onde sexa posible, o significado de cada entidade.
As ocorrencias ou instancias dunha entidade son realizacións concretas da entidade.
Todas as ocorrencias dunha entidade deben ter as mesmas características (atributos), non pudendo existir dúas ocorrencias iguais. Por exemplo:
- Ocorrencias da entidade PELICULA: “A Esmorga”, “O lapis do Carpinteiro”,...
- Ocorrencias da entidade DIRECTOR: “Ignacio Vilar”, “Antón Reixa”,...
Na entidade PELICULA, “A esmorga” sería unha ocorrencia, ou unha instancia, concreta; ou na entidade DIRECTOR unha ocorrencia sería “Ignacio Vilar” correspondendo o mesmo a unha instancia única xa que só existe un director chamado Ignacio Vilar con existencia propia.
Co obxectivo de simplificar e facilitar a lectura dos moitas veces utilizarase entidade como sinónimo de tipo de entidade ou conxunto de entidades.
Atributos
Recibe o nome de atributo cada unha das propiedades ou características que ten unha entidade ou unha relación, con relevancia para o universo do discurso que se está a modelar.
Os atributos permiten describir unha entidade ou relación, podendo a mesma entidade ou relación posuír diferentes atributos segundo o contexto a modelar. No caso das persoas, os atributos poden ser características como o nome e os apelidos, a data e lugar de nacemento, pero ao modelar un empregado poden interesar outros atributos, como a categoría profesional, a antigüidade, etc.
A representación gráfica dun atributo consiste nun circulo etiquetado, ou unha elipse, co seu nome e unido á entidade ou relación cunha liña. A posición da etiqueta depende da notación empregada.
Por exemplo, para ilustrar a representación gráfica de atributos de entidades, pódese utilizar o caso no que para cada PELICULA interese gardar información do seu título, xénero, nacionalidade, e ano de rodaxe; e que para cada DIRECTOR interese gardar información do seu nome, nacionalidade, e data de nacemento.
Representación coa notación de Piattini:
Representación do diagrama coa notación de Chen:
Dominio
Asociado ao concepto de atributo xorde o concepto de Dominio (Values Set), que permite establecer as restricións sobre os valores a tomar polos atributos, definindo e limitando o conxunto de valores válidos para un atributo.
Por exemplo, o dominio que chamaremos nomes para o atributo nome da entidade SOCIO, será unha cadea dun máximo de 35 carácteres alfabéticos e espazos; para o atributo nacionalidade, os posibles valores poderían ser inglesa, francesa e estadounidense, configurando o dominio ao que chamaremos nacionalidadesPosibles. Os dominios non soen representarse no modelo Entidade-Relación.
Tipos de atributos
Os atributos poden ser de diferentes tipos e a representación gráfica varía segundo a notación, como se mostra na táboa seguinte:
Pódense clasificar os tipos de atributos en base aos requisitos do sistema segundo a súa funcionalidade, a constitución ou carácter, a opcionalidade, a cardinalidade ou o tratamento.
Segundo a súa funcionalidade;
- Atributo Identificador Candidato (AIC): Atributo ou conxunto de atributos que son identificadores. Defínese o concepto atributo identificador como aquel atributo que permite identificar univocamente cada ocorrencia da entidade do resto de ocorrencias, é dicir, para cada ocorrencia da entidade, o atributo toma un valor diferente. Un atributo identificador pode estar formado por varios atributos, neste caso debe ser mínimo (combinación de valores única), é dicir, se eliminamos un ou máis dos atributos individuais que o compoñen, o resultante deixa de ser identificador das ocorrencias, polo que, non pode ser a súa vez identificador.
- Atributo Identificador Principal (AIP): O atributo (ou conxunto mínimo de atributos) que se elixe para ser o medio de identificación principal das ocorrencias dunha entidade, en caso de que existira máis dun atributo identificador candidato. Toda entidade debe ter un atributo identificador (non pode ser un atributo opcional). Por outra banda, as relacións non dispoñen de atributos identificadores. O AIP denomínase tamén clave primaria.
- Atributo Identificador Alternativo (AIA): Atributos identificadores candidatos que non son elixidos coma identificadores principais, sempre que exista máis dun atributo candidato.
- Atributo descritor: Caracteriza unha ocorrencia pero non a distingue do resto de ocorrencias do tipo de entidade, é dicir, son aqueles que non son atributos identificadores.
Por exemplo, o atributo DNI ou NSS (número da seguridade social) son atributos identificadores candidatos (AIC) nas entidades DIRECTOR e CLIENTE que teñen información de persoas como ocorrencias. Unha vez seleccionado o DNI como atributo identificador principal (AIP), o NSS pasa a ser atributo identificador alternativo (AIA). O resto de atributos, como nome ou idade, serán clasificados coma atributos descritores.
Segundo a constitución ou carácter:
- Atributo simple: Aqueles atributos non divisibles ou atómicos.
- Atributo composto: Poden dividirse noutros atributos ou subatributos con significado propio. Por exemplo, o atributo data podería estar formado polos atributos día, mes e ano, ou o atributo enderezo que a súa vez podería estar formado por codigoPostal, rua, portal, numero e andar.
Segundo a opcionalidade:
- Atributo opcional: Aquel que pode que non tome ningún valor do dominio ao que está asociado. No deseño de BD Relacionais, os SXBD empregan a marca NULL para identificar estes valores. O valor NULL empregarase cando se descoñece o valor dese atributo para algunha ocorrencia ou a ocorrencia non ten ningún valor aplicable para ese atributo. Situacións posibles que poden acontecer:
- O valor existe pero falta
- Non se sabe se o valor existe ou non
- A entidade non pode ter un valor aplicable para o atributo
- Atributo obrigatorio: Necesariamente deben tomar un valor do dominio para cada ocorrencia do atributo. A maioría dos atributos das entidades serán obrigatorios.
Por exemplo, na entidade PELICULA, o atributo anoRodaxe podería declararse coma opcional, para poder almacenar aquelas películas das que se descoñecen ese dato ou porque ese dato non está dispoñible xa que a rodaxe non rematou. E posiblemente o máis lóxico sería que o atributo título fóra obrigatorio.
Segundo a cardinalidade: monovaluados ou multivaluados
- Atributo monovaluado ou univaluado: Aqueles que toman un único valor para cada ocorrencia. Por exemplo, o atributo título na entidade PELICULA.
- Atributo multivaluado: Aqueles que para unha mesma ocorrencia pode tomar varios valores. Para estes atributos pódense definir un límite superior e inferior de valores por ocorrencia.
Por exemplo, na entidade PELICULA, o atributo nacionalidade podería ser un atributo multivaluado, xa que unha película pode ser producida por máis dun país, podendo limitar os seus valores entre unha e catro nacionalidades.
Representación do diagrama coa notación de Piattini:
Representación do diagrama coa notación de Chen:
Outro exemplo de atributo multivaluado pode ser a data de compra do visionado dunha película na relación compra_visionado existente entre as entidades PELICULA e SOCIO, xa que un mesmo cliente pode comprar a mesma película varias veces en datas diferentes.
Pero... qué son as relacións? Veremlo no seguinte punto en detalle.
Segundo o tratamento:
- Atributo almacenado: O seu valor é introducido por un usuario, e non se deriva do contido doutros atributos.
- Atributo derivado: O seu valor pódese calcular a partir doutra información existente (atributos, entidades e relacións). Son información redundante e non se adoitan almacenar. Algúns autores consideran os atributos derivados como parte do modelo Entidade-Relación estendido.
Por exemplo, o número de películas dun director calcularase contando o número de ocorrencias da entidade PELICULA relacionadas con cada DIRECTOR (rodadas por el), sendo polo tanto un atributo derivado da entidade DIRECTOR.
Relacións
Xa anticipamos o concepto de relación nos exemplos anteriores. Unha relación representa unha asociación, conexión, vínculo ou correspondencia entre unha ou máis entidades, non estando permitido no modelo asociar dúas relacións. A notación para representar unha relación entre entidades consiste nun rombo co nome da relación no interior, unido mediante liñas coas entidades que asocia.
En xeral, os nomes das relacións son verbos que describen a relación entre as ocorrencias de entidades. Exemplos de nomes de relacións: roda, vende, pertence ou posúe.
Do mesmo modo que ocorre coas entidades, unha relación é unha abstracción que representa un conxunto de ocorrencias da relación representada, distinguindo deste xeito, entre relación e instancia ou ocorrencia dunha relación. Por exemplo, a relación roda entre as entidades DIRECTOR e PELICULA, concrétase nas diferentes rodaxes das películas dirixidas polos directores. Unha instancia ou ocorrencia da relación podería ser “Antón Reixa - roda - O lapis do Carpinteiro”.
Entre dúas entidades tamén poderán existir máis dun tipo de relación. Por exemplo, pódese ter a relación compraVisionado para representar os visionados das películas comprados polos diferentes clientes. Por outra banda, pódese ter a relación comenta que representará os comentarios feitos polos clientes sobre as diferentes películas.
Grao dunha relación
O grao dunha relación é o número de entidades que participan na relación. Existen diversas posibilidades:
- Unarias ou reflexivas: asocia unha ocorrencia dunha entidade con outras ocorrencias da mesma entidade, sendo o seu grao igual a un. Exemplo de relación reflexiva entre unha película e as súas secuelas (obra literaria ou cinematográfica que continúa unha historia xa desenvolvida noutra anterior), que tamén son películas:
- Binarias: a relación asocia dúas entidades distintas, neste caso o grao será dous.
- N-arias: a relación asocia máis de dúas entidades distintas, correspondendo o grao “n” ao número de entidades diferentes asociadas (ternarias, cuaternarias, etc.).
O recomendable é utilizar relacións de grao dous como máximo, pero para reflectir certas restricións do sistema que modelemos pode ser necesario empregar máis de dous tipos de entidades. Por exemplo, empregar a relación ternaria actúa que permite relacionar un actor cos personaxes que interpreta nunha película específica.
Nalgúns casos é posible descompoñer unha relación “n-aria” en varias binarias pero noutros casos non é posible esta transformación, xa que se perdería parte da información a modelar. Por exemplo, ao substituír a relación actúa anterior polas dúas binarias interpreta e ten, poderíase obter máis información sobre: personaxes interpretados por actores, actores que participan en películas, e personaxes que aparecen en películas, pero non se poderían coñecer aos personaxes que interpreta un actor nunha película determinada.
Papel ou rol
Toda entidade que participa nunha relación realiza unha función, ou rol, específico na mesma. O rol indícase dando un nome a liña que une cada entidade coa relación.
Por exemplo, no seguinte gráfico, toda ocorrencia da entidade DIRECTOR que participa na relación roda realiza a función de realizador na mesma. Toda ocorrencia da entidade PELICULA que participa na relación roda ten o rol de ser dirixida por.
Outro exemplo pode ser o seguinte gráfico, correspondente a unha relación reflexiva, no que se ve que o rol é moi necesario para recoller a semántica das entidades participantes na relación reflexiva, xa que:
- Unha instancia de PELICULA xoga o rol de precuela (obra cinematográfica na que a súa historia precede á dunha obra inicial e central).
- Outra instancia distinta de PELICULA xoga o papel de secuela dunha película orixinal.
Tipos de relacións ou correspondencias
[EN 2002 ] “O número máximo de relacións nas que pode participar unha mesma entidade” [MPM 1999] “Número máximo de instancias dun tipo de entidade que poden estar relacionadas cunha instancia doutro tipo de entidade”
O tipo de correspondencia posibilitará definir as restricións sobre o número de ocorrencias, permitindo definir o número máximo de ocorrencias dunha entidade que poden estar relacionadas cunha ocorrencia doutra entidade que participa na relación.
No caso das relacións binarias, existen tres tipos distintos de correspondencia, dependendo do número de ocorrencias da primeira entidade e da segunda que participan na relación.
Supoñendo unha relación binaria entre as entidades E1 e E2, distinguimos os seguintes tipos de correspondencia posibles:
- Tipo 1:1 (un a un). Cada ocorrencia de E1 relaciónase como máximo cunha soa ocorrencia de E2 e viceversa. Por exemplo, un empregado dirixe só un departamento e un departamento é dirixido só por un empregado.
- Tipo 1:N (un a varios). Cada ocorrencia de E1 relaciónase como máximo con varias ocorrencias de E2, pero unha ocorrencia de E2 pode relacionarse como máximo cunha soa de E1. Por exemplo, unha película (1) ten varias copias de visionado (máximo N non especificado), pero unha copia de visionado só pode ser dunha película.
- Tipo N:M (varios a varios). Cada ocorrencia de E1 relaciónase como máximo con varias ocorrencias de E2 e viceversa. Por exemplo, un director roda varias (N) películas, e unha película pode ser dirixida por varios (M) directores.
Ao falar do número máximo de ocorrencias a relacionarse cunha dada, non implica que cada ocorrencia teña que relacionarse con outra necesariamente.
A notación para representar os tipos de correspondencia é ao lado do rombo que representa a relación entre as entidades, mediante unha etiqueta cos valores da correspondencia,como se indica na figura:
Por outra banda, dependendo da notación, cando hai máis dunha ocorrencia nunha relación(N), a liña de unión represéntase rematada cunha frecha (notación de Piattini) ou cunha dobre liña (notación de Chen). Dada a arbitrariedade da representación e que as metodoloxías poden utilizar representacións gráficas invertidas, o mellor modo de aclarar a súa lectura é aplicar unha lenda explicativa co sentido da mesma. Na seguinte gráfica poden verse os mesmos tipos nas dúas notacións.
No caso das relacións n-arias, o procedemento é o mesmo, sendo preciso utilizar un tipo de correspondencia cun carácter ou díxito por cada entidade participante. Os tipos de correspondencia posibles serán 1:1:1, 1:1:N, 1:N:M e N:M:P.
É preciso aclarar, que os dous primeiros tipos de correspondencia son transformables en dúas relacións binarias sen perda de semántica, sendo esta opción a máis correcta dende o punto de vista do Deseño.
No seguinte exemplo, a relación ternaria actúa permite obter as personaxes interpretadas por un actor nunha película determinada:
A transformación da relación ternaria actúa en dúas binarias como se mostra na figura, non sería unha proposta correcta, porque suporía unha perda de semántica, xa que permite obter os actores que actúan nunha película, os personaxes que son interpretados por un actor, pero non hai forma de obter as películas nas que o actor interpretou eses personaxes.
Restricións estruturais de deseño sobre tipos de relacións
Estas restricións permiten limitar as posibles combinacións de entidades que poden participar nas relacións, distinguindo os seguintes tipos de restricións:
- Tipo de Correspondencia ou Razón de Cardinalidade, xa explicada nas características das relacións.
- Razón de Participación e Cardinalidade que se explicarán no modelo Entidade-Relación Estendido (MERE), que son as regras que atenden aos requisitos do sistema a modelar.
Claves
Tipos de interrelacións: cardinalidade, participación e roles
- Cardinalidade: que pode ser:
- 1 a 1 (uno a uno): unha instancia da entidade A relaciónase con unha e so unha instancia da entidade B.
- 1 a N: (un a moitos): unha instancia da entidad A relaciónase cunha ou màs instancias da entidade B.
- N a M: (moitos a moitos): unha instancia da entidade A relaciónase cunha òu màis instancias da entidad B e unha instancia da entidade B relaciónase con unha ou màis instancias da entidade B.
- Opcionalidade: a participación obrigatoria ou opcional na entidad da relaciòn.
- Lenda: é unha expresión que escribe o rol de cada entidade na relaciòn.
- Propiedades das relacións
Cardinalidade
Participación obrigatoria ou opcional
Roles de cada entidade na relación
dependencia por existencia e por identificación
restricións entre interrelacións
Modelo E-R ampliado
Os conceptos básicos de E-R poden modelar a maioría das características das bases de datos. Con todo, tienen limitacións semánticas polo que algúns aspectos dunha base de datos poden expresarse de xeito máis axeitado mediante certas extensións do modelo E-R básico.
Esas características extendidas son:
- especialización
- xeneralización
- conxuntos de entidades de nivel máis alto e máis baixo
- herdanza de atributos
- agregación
- categorías
Veremos a continuación algunhas das máis relevantes.
Xeneralización
É unha relación contida que existe entre o conxunto de nivel máis alto (superclase) e un ou máis conxuntos de entidades de nivel máis baixo (subclase).
A xeneralización permite que as entidades de nivel máis baixo herden os atributos da entidade xeneralizadora de máis alto nivel. A entidade xeral chámase superentidade e as outras subentidades.
Exemplo. Podense xeneralizar por exemplo os tipos profesor e estudiante obtendo o supertipo persona.
Exemplo 1. Xeneralización da entidade vehículo
Partimos das entidades Coche e Camión; poderemos xeneralizalas na entidad Vehículo como se amosa na figura da dereita.
Tanto Coche coma Camión serán aora subclases da superclase xeneralizada Vehículo.
- Exemplo de xeneralización a entidade vehículo
Entidades Coche e Camión
Xeneralización de Coche e Camión con entidade vehículo
Especialización
Coñécese como especialización o proceso polo que se definen as diferentes subclases dunha superclase. Acontece cando partimos dunha entidade que podemos dividir en subentidades para detallar atributos que varían nas mesmas. Comparten clave coa superentidade e os atributos da superclase hérdanse nas subclases.
Exemplo. No caso do tipo empleado, pódense obter os subtipos secretario/a, técnico/a e enxeñeiro/a.
Exemplo 1 - Médico e especialistas
Temos a superclase Médico e as subclases Ciruxán, Pediatra, Oftalmólogo, Xinecólogo, Dermatólogo; podemos dicir que Ciruxán e Pediatra son tipos de Médico.
Diferenzas entre a xeneralización da especialización e representación da xerarquía
Principalmente:
- a xeneralización permite abstraer un tipo de entidade de nivel superior (supertipo) a partir de varios tipos de entidade (subtipos); nestes casos os atributos comúns e relacións dos subtipos asígnanse o supertipo
- a especialización é a operación inversa á xeneralización; nela un supertipo descomponse en un ou varios subtipos, os cales herdan todos os atributos e relacións do supertipo, ademáis de ter os seus propios
As diferenzas entre os dous enfoques pódense caracterizar mediante o seu punto de partida:
- a xeneralización ten un deseño ascendente, onde varios conxuntos de entidades se sintetizan nun conxunto de entidades de nivel máis alto baseado en características comúns.
- a especialización ten un deseño descendente: é un refinamento a partir dun conxunto de entidades inicial en sucesivos niveis
| Xeneralización | Énfase nas similitudes | Cada instancia do supertipo é tamén unha instancia dalgún dos subtipos | A superentidade normalmente ten unha clave principal distinta das subentidades |
|---|---|---|---|
| Especialización | Énfase nas diferenzas | Algunha instancia do supertipo pode non ser instancia de ningún subtipo | A superentidade normalmente NON ten unha clave principal distinta das subentidades |
A representación das xerarquías realízase mediante un triángulo invertido, coa base paralela ó rectángulo que representa o supertipo e conectando a éste e aos subtipos. Se a división en subtipos ven determinada en función dos valores dun atributo discriminante, este representaraase asociado ó triángulo que representa a relación.
Representaraase no triángulo:
- cunha letra d os subtipos que sexan disxuntos
- cun círculo ou una O se os subtipos poden solaparse
- cunha dobre liña entre o supertipo e o triángulo a presenza dunha xerarquía total
Representación de xerarquías
Os subtipos non poden solaparse: pode ser técnico ou contable
Os subtipos poden solaparse: pode ser xerente e enxeñeiro
Só pode ser asalariado ou subcontrado: non cabe outra posibilidade
Agregación
É un concepto de abstracción para construir obxectos compostos a partir dos seus obxectos compoñentes.
Permite combinar entidades entre as que existe unha interrelación e formar unha entidade de máis alto nivel; é útil cando a entidade de máis alto nivel tense que interrelacionar con outra entidade.
Xurde da limitación que existe no modelado de Entidade Relación; neste non resulta posible expresar relacións entre relaciónes. Isto é, non permite expresar as relacións entre relacións dun modelo E-R no caso de que unha relación A queira unirse cunha entidad calquiera para formar outra relación.
A agregación é una abstracción a través cal as relacións trátanse como entidades de nivel máis alto.
Exemplo 1 de agregación - relación traballa-en
Queremos rexistrar os directores para as tarefas realizadas por un empregado nuhna sucursal; isto é, desexamos rexistrar directores por combinacións (empregado, sucursal, traballo). Debe asumirse que existe unha entidade director.
Considere o conxunto de relacións traballa-en (que relaciona os conxuntos de entidades empregado, sucursal e traballo) como un conxunto de entidades de nivel más alto denominado traballa-en.
Tal conxunto de entidades trátase do mesmo xeito que cualquiera outro conxunto de entidades. Porén, unhna alternativa é crear unha relación cuaternaria dirixe entre empregado, sucursal, traballo e director. Algunhas combinacións empregado – sucursal – traballo pode ser que non teñan director. A solución será a da imaxe da esquerda.
Utilizando agregación, pódese crear unha relación binaria dirixe entre traballa-en e director para representar quén dirixe as tarefas. A solución será a imaxe da dereita:
- ER con relacións redundantes e EER Extendido con agregación
Diagrama_E-R con relacions_redundantes
Diagrama E-R extendido con agregación
Exemplo 2 de agregación - relación está-casado-con
Considere os obxectos Home e Muller. Pódese definir a relación Está-casado-con: a esta relación denomínaselle conxunto de obxectos agregado. Neste exemplo a este agregado podemos chamalo Matrimonio.
Así modelado, cómo poderíamos engadir a información do aniversario de bodas? A relación Aniversario conecta as parellas de casados co seu aniversario de bodas. E outra relación Reside-en conéctaos co seu enderezo de residencia. Pooderíamos así ir agregando máis relaciones entre elas, mediante a agregación.
Nota. Desde fai moitos anos xa en España e cada vez máis en moitos países do mundo, o matrimonio tamén é posible entre dúas personas do mesmo sexo. Nada cambia no escenario modelado agás que sería unha relación reflexiva dunha persona con outra, en lugar de entre un home e unha muller.
Exemplo 3 de agregación - relación entrevista
Queremos almacenar información sobre o proceso de selección dunha empresa de captación de talento:
- as entrevistas que unha empresa organiza son entre solicitantes de emprego e diferentes empresas.
- algunhas entrevistas dan lugar a ofertas de emprego e outras non.
A agregación convirte nun só obxecto unha relación. Se se elimina a entidade agregada elimínanse ademáis as entidades que a forman.
Exemplo 4 de agregación - relación partidos
Queremos xestionar os partidos dun deporte. Cada partido:
- ten lugar entre dous equipos
- un equipo xoga na casa e outro xoga fora
- ten un resultado
- ten un árbitro
Queremos poder coñecer:
- Que equipos xogaron entre si e con que resultado
- Quen arbitrou cada partido.
Pódse ver modelo E/R básico na figura da esquerda.
Cambian os requisitos: será preciso incluir as empresas que publicitan os seus productos nun partido.
Para iso introducimos un tipo de entidade Empresas e un tipo de relación Anuncia.
Anuncia debería relacionar Empresas con Partidos, pero non existe esta entidade...
Unha primeira posibilade: unha nova entidade ternaria entre Equipos e Empresas, pero esto daría lugar a redundancia nos atributos de Partido.
Mellor solución: unha agregación Chamadas Partidos, que se tratará como un tipo de entidade e que pode relacionarse con Empresas. Pódese ver na figura da dereita
- Xestión de partidos
Xestión de partidos con ER
Xestión de partidos tras cambio de requisitos con ER extendido con agregación
