Ut2 apuntes diseno_de_bbdd_parte_i_diseno_conceptual

UT2 Diseño de Bases de Datos GBD 17/18
IES Francisco de Goya Laura Sanz
UT 2 - Diseño De Bases de Datos - Parte I
UT 2 - Diseño De Bases de Datos - Parte I........................................................1
1. Diseño de bases de Bases de Datos.................................................................1
2. Diseño conceptual..............................................................................................1
2.1. El Modelo Entidad Relación (ER)................................................................2
2.1.1. Notación................................................................................................2
2.1.2. Construcción.........................................................................................7
1. Diseño de bases de Bases de Datos
Podría formularse el diseño de una base de datos como un proceso cuyo objetivo
es el de definir y construir la estructura lógica y física de una base de datos, de
forma que se satisfagan las necesidades de información de los usuarios y de un
conjunto de aplicaciones en el contexto de una organización, cumpliendo con
requisitos tales como la facilidad de uso, de productividad y rendimiento (como
tiempo de procesamiento y capacidad de almacenamiento físico), etc.
Por ejemplo, el diseño de una base de datos consistiría en tratar de averiguar qué
datos están implicados en el proceso de facturación de una empresa que vende
vehículos agrícolas y bajo qué condiciones se utilizan dichos datos.
En este proceso, iterativo, se identifican las fases siguientes:
1. Recolección de requisitos y análisis.
2. Diseño conceptual.
3. Elección de un sistema gestor de base de datos (Y con ello, del tipo de
modelo de datos. En el tema que nos ocupa, se presupone el modelo relacio-
nal.)
4. Diseño lógico.
5. Diseño físico.
6. Implementación. Incluye la carga y migración de los datos.
2. Diseño conceptual
En primer lugar, debemos averiguar qué es lo que se espera que diseñemos. Por
ello, es necesario inicialmente la fase de análisis y recolección de requisitos. Para
la recolección de requisitos, han de identificarse los usuarios y aplicaciones que
forman parte del sistema de información de la empresa, así como la prioridad de
1

cada cual en el uso de la información. Se entrevistará a los usuarios, se estudiará
la documentación recogida en la empresa, y se observará el procedimiento
operativo actual (tipos y frecuencia de las transacciones, flujo de información,
etc.). Los resultados de esta fase (en definitiva, los requisitos: exigencias de
rendimiento, experiencia y nivel de formación de los usuarios, y otras condiciones
de uso en general de la base de datos.), expresados mayoritariamente en forma
textual, son la entrada de la fase de diseño conceptual.
Una vez ya conocido el qué se desea, en la siguiente fase, la de diseño
conceptual, se trata de obtener una especificación de alto nivel, llamada
“esquema conceptual”, que lo represente de la forma más completa y precisa, de
forma que:
 Queden plasmados claramente la estructura y semántica de la base de da-
tos.
 Sea una descripción estable del contenido de la base de datos, que no
debe ser modificada en fases posteriores.
 Facilite la comprensión y comunicación entre usuarios, analistas y diseña-
dores.
Convendría que el esquema conceptual estuviera expresado en un modelo de
datos de alto nivel, que se caracterice por su expresividad, sencillez, minimalidad,
por su carácter formal y por asociarse a una representación diagramática
(notación gráfica), fácil de interpretar. Existen varios modelos de datos de alto
nivel, aunque ninguno posee todas estas cualidades a la vez. El modelo de uso
más habitual, es el modelo Entidad/Relación extendido (EER), que se describe
a continuación. 1
Por otro lado, aparte de la construcción del esquema conceptual, de los requisitos
recogidos previamente pueden identificarse las transacciones que tendrán lugar
con mayor frecuencia en el sistema (dado que se sabe qué uso harán los distintos
usuarios y aplicaciones de la base de datos). Es importante especificar también
claramente estas transacciones, ya que serán de utilidad en fases posteriores del
diseño (sobretodo, en el diseño físico).
2.1. El Modelo Entidad Relación (ER)
2.1.1. Notación
Los elementos del modelo E/R extendido son
1
Estos diagramas fueron propuestos por Peter Chen a mediados de los años 70. También se de-
nominan diagramas Entidad-Interrelación en otras fuentas bibliográficas, o en inglés Entity-rela-
tionship.
2

 Entidad. Una entidad (o instancia de entidad) se refiere a un elemento exis-
tente en el mundo real, ya sea un objeto físico, concepto o ser vivo. Cada enti-
dad (o tipo de entidad) posee una serie de características que la describen, lla-
madas atributos. Uno de los atributos destaca por ser el identificador o clave.
Es decir, el identificador es un atributo que se caracteriza porque su valor es
único entre todas las instancias del mismo tipo de entidad. Un tipo de una enti-
dad es, por lo tanto, el esquema que describe un conjunto de instancias que
comparten la misma estructura. Una entidad se representa gráficamente me-
diante un rectángulo que contienen un nombre en su interior.
 Entidad débil. Según la semántica del mundo que se modela, existen enti-
dades dependientes de otras. La dependencia puede darse en existencia o en
identificación. En primer lugar, la existencia de una entidad (instancia) depende
de otra, si en el momento en que se elimina esta última, no tiene sentido preser-
var la primera. En este caso, se habla de debilidad en existencia. Se denomina
entidad débil a la entidad dependiente y entidad fuerte a aquella de la que de-
pende. En segundo lugar, una entidad débil en identidad es aquella que requie-
re de otra entidad para ser identificada. Es decir, por sí misma la entidad débil
no cuenta con un identificador (o se trata de un identificador parcial referido a la
entidad fuerte). Por lo general, se cumple que si una entidad es débil en identifi-
cación, también lo es en existencia, pero no a la inversa. Se representa con un
doble rectángulo que contiene un nombre en su interior.
 Relación. Una relación (o una instancia de relación) define una asociación
que se puede dar entre instancias de entidades pertenecientes a n tipos de enti-
dades. Un tipo de relación se define por un nombre y por los n tipos de entida-
des que participan en ella, además de por su cardinalidad y correspondencia.
Se representa gráficamente mediante un rombo con un nombre en su interior.
ENTIDAD 1 ENTIDAD 2RELACIÓN
3
Persona
Oficina
Trabaja
Persona

 Relación débil. Aquella relación en la que una (o más) de las entidades
participantes sea débil. Se representa mediante un rombo con un nombre en su
interior y con un indicativo del tipo de debilidad que afecta a la entidad débil: “E”
para existencial e “I” para debilidad de identidad.
 Relación recursiva. Se trata de un tipo de relación en el que interviene un
único tipo de entidad. Varias instancias de un mismo tipo de entidad pueden es-
tar relacionadas entre sí. Cada instancia desempeña un papel o rol determinado
en la relación. Por ejemplo, dos entidades de tipo “persona” puede estar asocia-
dos mediante la relación “progenitor”. Una de ellas desempeñará el papel de
padre o madre y la otra el de hijo o hija.
ENTIDAD 1 RELACIÓN
 Cardinalidad. Especifica el número máximo de instancias de una relación
en las que puede intervenir una instancia de una entidad. Se denota por dos ca-
racteres separados por “:”, indicando el tipo de asociación: uno a uno, uno a
varios, varios a uno, ó varios a varios. Aunque no todos los autores están de
acuerdo, los caracteres permitidos son únicamente 1 y un carácter del alfabeto,
p.ej. N.
En la figura, un departamento concreto, por ejemplo, el de ventas, puede tener
un número ilimitado de empleados, mientras que cada empleado sólo puede
trabajar en exclusiva para uno de los departamentos de la empresa.
En definitiva, las cardinalidades posibles son: (0,1) (1,1) (0,N) (1,N) (N,M).
4
Es_parte_de
(I)
N:1
Traba
ja
Empleado Departamento
Es_parte_de
(E)

 Correspondencia o participación. Número mínimo y máximo de ocurren-
cias o instancias de una entidad que pueden intervenir en una relación por cada
ocurrencia de otra entidad. Se denota:
En la figura, una persona puede o no trabajar en una oficina. Además puede
estar pluriempleado y trabajar en varias oficinas a la vez. Una oficina no tiene
sentido si no hay al menos una persona trabajando en ella y, de hecho, lo más
normal es que se ubiquen en ella varias personas a la vez. Una
correspondencia mínima de 1 (como es el caso de oficina respecto a persona)
puede ser indicativo de debilidad en existencia.
 Grado de una relación. Lo constituye el número de tipos de entidades que
participan en la relación. Por ejemplo, la relación “matrimonio” es de grado dos,
es decir, es una relación binaria. A una relación de grado tres se la califica como
relación ternaria, y así sucesivamente. Ejemplo de una relación ternaria:
ENTIDAD 1 ENTIDAD 2RELACIÓN
ENTIDAD 3
 Especialización y generalización. Puede ser total o parcial, y exclusiva o
no. Se representa por un triángulo boca abajo.
o Una especialización es inclusiva, si una ocurrencia del supertipo
puede parecer en más de un subtipo. Representación:
HABITACIÓN
DOBLE INDIVIDUAL
5
(0,M)(1,N)
Trabaj
a
Persona Oficina

o Una especialización exclusiva si una ocurrencia sólo puede perte-
necer a un subtipo. Representación:
VEHICULO
AUTOBÚS MOTOCICLETA
o Una especialización es total cuando forzosamente cada ocurrencia o
instancia del supertipo debe corresponderse con una ocurrencia o
instancia de uno o varios subtipos (según sea exclusiva o no). Una
especialización parcial se da cuando puedan existir ocurrencias o
instancias del supertipo que no se correspondan con ninguna ocu-
rrencia o instancia de los subtipos. Se representa una especializa-
ción total mediante un pequeño círculo por encima del triángulo in-
vertido (y sin él en caso de ser parcial). Así, por ejemplo, una espe-
cialización total y exclusiva tendría finalmente esta representación:
 Tipos de atributos. Un atributo debe tomar un valor en una instancia de
una entidad (o de relación). Existen diversos tipos de atributos en función de los
valores que aceptan: atributo simple, atributo compuesto, atributo multivalua-
do, atributo almacenado, atributo derivado. Los atributos simples son el caso
ordinario, en el que sólo puede tomarse un único valor indivisible. Por ejemplo,
el color de ojos de una persona es simplemente un color. El valor de un atributo
compuesto consiste en la concatenación de valores simples o atómicos. Por
ejemplo, el atributo “dirección” está compuesto al menos por la calle y el núme-
ro. A un atributo multivaluado se le asignan múltiples valores. Por ejemplo, un
coche puede estar pintado no sólo con un color. Por otro lado, los atributos al-
macenados son el caso normal, en el que cada instancia de una entidad contie-
nen o “almacena” el valor de cada uno de sus atributos. Por el contrario, los
atributos derivados o calculados son aquellos cuyo valor se obtiene en un mo-
mento puntual (en la consulta) a partir de los valores de otros atributos (de la
misma entidad u otras) y no permanece almacenado. Un valor especial, el valor
6
DNI Pasaporte

nulo, representa situaciones en las que el valor de un atributo es desconocido o
no es aplicable.
o Atributo ordinario.
o Atributo que forma parte del identificador.
o Atributo que forma parte de un identificador alternativo.
o Atributo multivaluado.
o Atributo opcional.
o Atributo compuesto.
 Dominios. Cada atributo de un tipo de entidad está asociado a un conjunto
de valores, que le pueden ser asignados, llamado dominio. Por ejemplo, en una
entidad que represente a un empleado el dominio se corresponde con cualquier
número entero positivo entre 16 y 65 años.
El diagrama entidad relación extendido proviene del diagrama entidad relación.
Las diferencias entre ambos son de notación y, sobretodo, en que en el extendido
se incorporan las relaciones de generalización y especialización.
2.1.2. Construcción
Dado que los requisitos suelen venir documentados en forma textual, la
construcción del esquema conceptual (diagrama E/R) podría comenzar a partir de
un análisis lingüístico de manera que:
 Los nombres comunes den pie a entidades o atributos.
 Los nombres propios den lugar a instancias u ocurrencias de entidades o
relaciones.
 Los verbos sean el origen de relaciones, con la excepción de los verbos
“ser” y “tener”. El verbo “ser” puede dar lugar a jerarquías. El verbo “tener” pue-
de representar atributos o relaciones con entidades débiles.
Otra heurística consistiría en la categorización de objetos:
7
Fecha
Día
Mes
Año

 Cualquier objeto al que se le asignen propiedades, da lugar a una entidad.
 Un objeto que posea un valor se tratará probablemente de un atributo.
 Si un objeto (o dato) hace posible seleccionar una entidad mediante la refe-
rencia a un atributo de otra entidad, entonces, estamos ante una relación.
Para la construcción de un esquema conceptual, pueden asimismo adoptarse
distintas estrategias:
 Estrategia descendente. Se parte de unas pocas entidades muy
abstractas, para ir, a medida que se van especificando sus atributos,
especializándolas en subclases y relaciones. Ésta es la estrategia que
utilizaremos en clase.
 Estrategia ascendente. Se parte de un conjunto de atributos, que
inicialmente se combinan en entidades y relaciones. Se irán añadiendo
nuevas entidades y relaciones, a medida que se va aplicando combinación
y generalización de entidades. Otra modalidad de estrategia ascendente,
consiste en partir de unas pocas entidades muy concretas, que sean muy
evidentes, para ir añadiendo otras, las que estén más próximas.
 Estrategia mixta. Una o varias partes del esquema puede construirse con
una estrategia ascendente, mientras otra(s) parte(s) pueden generarse
aplicando una estrategia descendente.
8

Ut2 apuntes diseno_de_bbdd_parte_i_diseno_conceptual

Recomendados

Recomendados

Más contenido relacionado

Similar a Ut2 apuntes diseno_de_bbdd_parte_i_diseno_conceptual

Similar a Ut2 apuntes diseno_de_bbdd_parte_i_diseno_conceptual (20)

Último

Último (20)

Ut2 apuntes diseno_de_bbdd_parte_i_diseno_conceptual