Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Teórico Base de Datos 1

No description
by

David Giménez

on 11 March 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Teórico Base de Datos 1

Universidad ORT Uruguay
Facultad de Ingeniería
Cátedra de Base de Datos
Teórico Bases de Datos 1
Profesor: David Giménez
drgimenez@gmail.com
TEMARIO
Módulo I
Módulo II
Módulo III
Módulo IV
•Definición de Base de Datos (BD)
•Definición de Sistema de Gestión de Base de Datos (SGBD)
•Elementos, funcionamiento, conceptos de Base de Datos
•Definición de esquema e Instancia.
•Modelado de datos: Modelo Entidad Relación (MER) y Modelo Relacional (MR)
•Definiciones y ejemplos de MER Y MR.
•Lenguajes de definición DDL y DML.
•MER: Modelo Entidad Relación.
•Diseño de BD
•Dependencias funcionales
•Otras dependencias.
•Normalización de BD.
•MR: Modelo Relacional
•Álgebra Relacional.
•Estándar SQL
•Cálculo Relacional
Objetivos del curso:
Brindar una introducción y una base conceptual a las Bases de Datos Relacionales y su funcionamiento.

Desarrollar herramientas y habilidades que le permitan al estudiante analizar problemas en los entornos de negocios y brindar soluciones innovadoras de BD, que satisfagan los requerimientos.
Aprobación del curso:
2 Parciales: Máximo 35 puntos. Mínimo 15.

2 Obligatorios: Máximo 15 puntos. Mínimo 5.
BIBLIOGRAFÍA
•Sistemas de Bases de Datos – Conceptos Fundamentales – Elmasri / Navathe. 2da a 5ta Edición.

•Introducción a los Sistemas de Bases de Datos - C. J. Date

•Fundamentos de bases de datos – Abraham Silberschatz / Mcgraw hill

•Diapositivas de la cátedra

•Material de clase
INTRODUCCIÓN
¿Qué es una Base de Datos en sentido amplio?
¿Qué Bases de Datos conocen?
¿Qué elementos de la vida cotidiana se les ocurre que pueden ser Bases de Datos?
Un libro ?
Una carta de precios ?
El cuaderno de notas de clase ?
Una planilla Excel ?
Cualquier conjunto de información lógicamente organizada, que permita ser consultada e interpretada en el futuro.
¿Qué elementos en común identifican en esas Bases de Datos?
¿Qué actividades de la vida cotidiana identifican como relacionadas con las Bases de Datos?
Transacciones bancarias
Operaciones comerciales
Compras en el supermercado
Navegar por internet
Contienen datos ordenados.
Representan información relevante de la realidad.
Dicha información es relevante para un público objetivo.
El público objetivo es de diferentes clases y poseen diferentes necesidades en relación a dicha información.
La información siempre
SERÁ CONSULTADA
objetivo final
¿Cuál es el objetivo final de cualquier fuente de información (léase Base de Datos)?
¡¡¡ SER CONSULTADO !!!
Definición de Base de Datos:
(Página 4 )
Una BD es una colección de información lógicamente organizada, que guardan entre sí una relación inherente, que corresponde con la naturaleza de la información, es decir con la realidad del negocio en el que está inmerso.

Generalmente se busca que la base de datos sea el único almacén de datos. Unificación de la información.
Características:
•Siempre representan algún aspecto de la realidad que interesa a un público objetivo.

A este aspecto de la realidad se le llama “MINI MUNDO” o “UNIVERSO DE DISCUSIÓN”.

•Los datos almacenados son lógicamente coherentes a la realidad que representan.

•El almacenamiento de datos tiene un propósito específico y un público objetivo.
Aclaraciones:
•No es correcto denominar BD a un conjunto aleatorio de datos.

•La información contenida en la BD debe ser fiel reflejo del mini mundo que representa. Su representación debe ser consistente.

•Su objetivo final es SER CONSULTADA, por lo que su diseño debe tener en cuenta este objetivo.

•En el curso nos ocupamos mayoritariamente de las Bases de Datos relacionales electrónicas (administradas por computador).

•Pero el mundo de las BD no muere allí, existen muchos otros tipos de BD.
Definición:
Sistema de Gestión de Base de Datos
(SGBD, DBMS)
(Página 5)
Es una colección de programas (software) que permite a los usuarios crear y mantener una base de datos.

Se le denomina software de propósito general que facilita los procesos de:

Definición:
De tipos de datos, estructuras, restricciones. Todo lo que es Metadatos.


Construcción:
Almacenamiento controlado de los datos.


Manipulación:
Consultas y actualizaciones sobre los datos.


Compartición:
acceso controlado y simultaneo a los datos por diversos usuarios.


Protección:
Contra mal funcionamiento del hardware o del software y control de acceso a los datos por personal no autorizado.
Aclaraciones:
•Podemos usar una BD sin un SG pero implicaría desarrollar nuestros propios software de gestión de los datos.

•Los DBMS son software muy complejo que deben poder mantener la operatividad de los datos por muchos años.
Definición: Sistema de Base de Datos (SBD)
Se denomina SBD a la combinación de base de datos y un software que lo administra y gestiona.
Objetivos de una DBMS:

Controlar redundancia de datos
. Cada elemento del mini mundo debe representarse una única vez.


Evitar inconsistencia de los datos
. Los datos al ser modificados deben pasar de un estado consistente a otro estado consistente.


Accesibilidad a los datos.
Dar las facilidades necesarias para el acceso a los datos.


Seguridad de los datos.


Integridad de los datos.


Evitar anomalías en el acceso concurrente.


Recuperación de fallos.


Información distribuida.
Entorno de un SGBD
Imagen extraida del libro “Sistemas de Bases de Datos – Conceptos Fundamentales –“ Elmasri / Navathe. 5ta Edición, página 6
Enfoque de Base de Datos
(Páginas 8 a 12)
Se mantiene un único almacén de datos.
Este se define una única vez y al mismo acceden varios usuarios.
•Naturaleza auto-descriptiva
Catálogo del DBMS
Metadatos
•Abstracción de datos
Representación conceptual de los datos
•Soporte de varias vistas de datos
Actores del enfoque de Base de Datos
•Administradores de la BD (DBA)
Responsabilidades:
Autorización para el acceso a los datos.
Responsable del desempeño.
Control de la seguridad, ataques y respuestas.
Estrategia de respaldo y recuperación.
Mejora continua.
•Diseñadores de BD
Responsabilidades:
Análisis y conceptualización del mini mundo.
Análisis de requerimientos de usuarios.
Definición y modificación del esquema de la BD.
Especificación de las restricciones de integridad.
•Usuarios finales
•Analistas de sistemas y
programadores de aplicaciones
Casuales
Principiantes o paramétricos
Sofisticados
Independientes
Evolución de los Sistemas de Bases de Datos
•Años ´60 Sistemas de archivos
•Años ´70 Desarrollo de la segunda generación de SGBD
•Años ´80 Desarrollo de la tercera generación
•Años ´90 Desarrollo de Bases de Datos Distribuidas
•Años 2000 Sistemas Federados de Bases de Datos
Primera generación de SGBD (Redes y Jerárquicos)
Separación de la descripción de los datos de su manipulación
Sistemas relacionales (optimizar accesos) standards (CODASYL)
Comercialización de modelos de 1era. Gen.: Redes y Jerárquicos.
Modelos de datos más ricos (BDOO, BD de conocimientos, BD Semánticas)
Comercialización de modelos de 2da. Generación
Arquitectura Cliente-Servidor
Interoperabilidad de Bases de Datos
Sistemas de Data Warehouses
Data Mining (Minería de Datos)
Ventajas de utilizar el enfoque de Base de Datos
•Control de la redundancia
•Restricción del acceso no autorizado
•Economías de escala
Almacenamiento persistente para los objetos del negocio
•Estructuras de almacenamiento adecuadas para procesamiento eficaz de consultas
Copia de seguridad y recuperación
•Suministro de varias interfaces de usuarios
•Representaciones de relaciones complejas entre los datos
•Implementación de restricciones de integridad
•Inferencias y acciones usando reglas
•Permite implementar estándares
•Reduce tiempo de desarrollo de aplicaciones
•Disponibilidad de la información actualizada
¿Cuándo no usar un SGDB de propósito general?
•Cuando la información que debe ser almacenada del mini mundo requiere de un tratamiento especial y específico que no es estándar en los SGDB de propósito general.

•Cuando los requerimientos son demasiado sencillos y basta con la utilización de archivos tradicionales, porque no se requiere acceso multiusuario y los datos son muy estáticos en el tiempo, lo que hace que no sea favorable la relación costo beneficio el implementar un SGDB de propósito general porque requiere inversión inicial alta y tiene costos de implementación y aprendizaje

•Cuando requisitos críticos como la respuesta en tiempo real inmediata son esenciales y lo SGDB de propósito general no puede ofrecer debido a los sobrecostos (overhead) en las trasformación de las consultas entre los diferentes niveles.
Arquitectura de 3 niveles de un SGDB
(Páginas 31, 32)
Imagen extraida del libro “Sistemas de Bases de Datos – Conceptos Fundamentales –“ Elmasri / Navathe. 5ta Edición, página 31.
Arquitectura de 3 niveles
Nivel Externo
Es la porción de información almacenada en la BD que cada usuario requiere. Para diferentes usuarios puede ser diferente información y en diferentes formas
Nivel Conceptual
Es el nivel ideológico de las entidades que el negocio necesita representar del mini mundo que se almacenará en la BD. Oculta los detalles del almacenamiento físico de esa información, y se concentra en describir las entidades, tipos de datos, las relaciones entre las entidades, las operaciones de los usuarios y las restricciones de los datos.

Este nivel tiene un esquema conceptual que se describe con un Modelo da Datos.
Nivel Interno
Tiene un esquema interno que describe la estructura del almacenamiento físico de la información en la BD, describe el almacenamiento y las rutas de acceso a los datos
Aclaraciones:
•La mayoría de los SGDB no separan completa y explícitamente las tres capas. Puede existir cierto solapamiento entre ellas.

•Observe que los tres niveles son solo descripciones de los datos. Los datos propiamente dichos solo están almacenados en el la capa física. Una solicitud que se genera en la capa externa debe ser “trasformada” al esquema utilizado en la capa interna y “trasformada” una vez más a la capa física. Este proceso se denomina “mapeado” y puede insumir bastante tiempo.
Importante:
Esta arquitectura de tres niveles es lo que permite la
independencia de los datos
, que puede definirse como la capacidad de cambiar el esquema utilizado en un nivel sin que el resto de los niveles se vean afectados.
Independencia lógica de datos
Independencia física de datos
Es la capacidad de cambiar el esquema conceptual sin necesidad de cambiar el esquema externo (utilizado por los programas de aplicaciones).
Es la capacidad de cambiar el esquema físico (de almacenamiento) sin tener que cambiar el esquema conceptual ni el externo
¿Cuál es más sencillo de lograr?
La independencia física de los datos existe en la mayoría de las bases de datos y en los entornos de archivos donde a los usuarios se les oculta la ubicación exacta de los datos en el disco.

La independencia lógica de los datos es mucho más difícil de conseguir, porque implica que los cambios lógicos en las entidades, relaciones, etc no deberían afectar a los programas de aplicación. Un requisito mucho más estricto.
Modelo de Datos, Esquema e Instancia de un BD
(Página 27 a 30)
Un Modelo de Datos es una colección de conceptos que se pueden utilizar para describir la estructura de una BD y que permite esa abstracción.

Entiéndase estructura de la BD como colección de entidades, tipos de datos, relaciones, acciones, operaciones que son parte del mini mundo a almacenar.
Todo modelo de datos está conformado por:

La descripción de las estructuras llamada
Esquema de la BD
La colección de datos almacenados llamado
Instancia de un BD
En un momento dado cada estructura del esquema de la BD tiene su conjunto actual de instancias. Esto es cada estructura tiene su conjunto de datos que instancian el concepto que representan.

El DBMS es parte responsable de que la BD pase de un estado consistente a otro estado consistente después de aplicar cada operación que modifique la instancia.
Lenguajes de definición para una BD
(Páginas 33, 34)
DDL: Data definition language (Lenguaje de definición de datos)

DML: Data manipulation language (Lenguaje de manipulación de datos)
El DDL es usado para la definición del esquema de la BD. Consiste en un listado de comandos que permiten indicarle al SGBD lo que queremos que se almacene del esquema de la BD en el catálogo del sistema. El SGDB posee un compilador DDL (interprete de comandos) que permite traducir los comandos en operaciones.
En ocasiones el DDL se utiliza para la definición de ambos esquemas, el conceptual y el interno.

En otras ocasiones se utiliza un lenguaje independiente para el físico denominado
SDL: storage definition lenguaje: lenguaje de definición de almacenamiento.

SDL: storage definition lenguaje (lenguaje de definición de almacenamiento)
VDL: view definition lenguaje (lenguaje de definición de vistas)
Así también para la definición del esquema externo existen un lenguaje denominado VDL: view definition lenguaje: lenguaje de definición de vistas que especifica las vistas de usuarios y su mapeo al esquema conceptual. Pero de nuevo muchas veces se utiliza el DDL para ambas tareas. En los SGBD actuales se utiliza SQL como lenguaje VDL.
El DML es el lenguaje utilizado para realizar cambios en las instancias de la BD, esto es realizar las operaciones de recuperación, inserción, actualización y eliminación de los datos almacenados.
En la actualidad los DBMS integran todos estos lenguajes y se ven como un único compendio de comandos que permiten realizar todas estas operaciones.

El lenguaje de DB relaciones SQL es un buen ejemplo de esto, incluye DDL, VDL y DML. Inicialmente incluía SDL pero se ha eliminado para mantener el lenguaje a nivel conceptual y externo únicamente.
Estructura esquemática de un DBMS (SGBD)
(Páginas 36 a 38)
MER: MODELO ENTIDAD RELACIÓN
CLASE 2: Capítulo III
Definición:
Es un modelo conceptual y se utiliza para la definición de datos, sus relaciones y algunas restricciones.
ER se basa en la definición de
Entidades
como elementos relevantes del mini mundo del que se quiere almacenar información, indicando para cada uno sus
Atributos
que lo caracterizan, las
Relaciones
y
Restricciones
que guardan estas entidades entre sí.
Conceptos:
Es un aspecto de la realidad a representar que cobra importancia para el negocio en el cual está inmersa la BD, por lo que se representa en el mini mundo.
Puede ser un objeto de la realidad con una existencia física, como una persona, un auto, un libro, etc. O puede ser un elemento conceptual como una empresa, un trabajo, etc.
REPRESENTACIÓN:
(Páginas 55 a 59)
Cada entidad esta descripta por propiedades particulares, las cuales llamamos
ATRIBUTOS
(Páginas 55 a 59)
Estos atributos dan información sobre aspectos y características particulares de cada entidad. Por lo que cada instancia de una entidad estará definida por valores diferentes en sus atributos.
REPRESENTACIÓN:
Tipos de Atributos:
•Simples (o atómicos) y Compuestos (o estructurados)

•Monovalor y Multivalor (multivaluados)

•Almacenado y Derivado
Atributos Simples (o atómicos)
Los atributos simples tienen un significado independiente, y sus valores son atómicos en relación a la información que representan para el mini mundo.
Atributos Compuestos (o estructurados)
Los Atributos Compuestos por el contrario se pueden dividir en partes más pequeñas de la información que almacenan para dar datos más básicos. Podríamos decir que un atributo compuesto está formado o agrupa a varios atributos simples
REPRESENTACIÓN:
Atributos Mono-Valor
Un atributo es mono valor cuando para una entidad en particular solo posee un único valor de su dominio.
Atributos Multi-Valor
Mientras que es Multivalor cuando para una entidad en particular puede aplicársele más de una valor de su dominio
REPRESENTACIÓN:
Existen atributos que guardan cierta relación directa. Por ejemplo fecha de nacimiento y edad de la entidad persona. El atributo fecha de nacimiento podría almacenarse, siendo entonces un atributo almacenado, mientras que a partir de este y la fecha actual podría calcularse, derivarse el atributo edad, el cual sería un atributo derivado
Atributos Almacenados y Derivados
Valor NULL de los atributos
Representa dos casos:

Cuando la información de un atributo no es aplicable a la entidad a la que pertenece.

Por ejemplo el atributo Apto de una dirección no es aplicable a las personas que viven en casas.

Cuando el valor del atributo es desconocido para la instancia de la entidad representada.

Esto es cuando por ejemplo se desconoce el teléfono de una persona, se deja en NULL el atributo correspondiente
(Página 61 a 65)
Son asociaciones que existen entre las diferentes entidades.

Podemos decir que dos entidades están relacionadas cuando sus conceptos lo están en la realidad del mini mundo representada.
La asociación puede existir entre al menos dos o más entidades.

Las relaciones pueden tener sus propios atributos tal cual las entidades.
REPRESENTACIÓN:
Grado de una relación
Es el número de entidades participantes en la relación. En el caso de anterior "Trabaja Para" tiene grado dos.
Las relaciones de
grado dos
se denominan
Relaciones Binarias
y las de
grado tres Relaciones Ternarias
. En si las relaciones pueden ser de cualquier grado, pero lo más común es que sean binarias
Roles en una relación
Cada entidad que participa en una relación lo hace en función de un rol o papel que cumple en la misma.

La indicación de roles ayuda a entender mejor la relación.

Por ejemplo en la relación "Trabaja Para" la entidad Empresa cumple el rol de empleador mientras que la entidad empleado cumple justamente el rol de empleado o contratado.
Relaciones Recursivas o Autor-Relaciones
Cuando en una relación binaria las dos entidades participantes son la misma entidad se le denomina Relación Recursiva.

Aquí el uso de los roles es esencial para lograr comprender el papel que juega la entidad en cada ocurrencia dentro de la relación.
RESTRICCIONES
(Página 65 a 67)
Son imposiciones de comportamiento para los datos almacenados.

Estas reglas que deben seguir los datos son derivadas del estudio y análisis previo que debe hacerse del mini mundo a representar.

Existen restricciones para atributos como las de dominio y las de clave como para relaciones como son las de cordialidad y de participación.
RESTRICCIONES SOBRE ATRIBUTOS
Atributo Clave (Atributo Determinante) o Restricción de unicidad
Cada entidad tiene habitualmente un atributo (o varios) que permiten identificar inequívocamente cada instancia de la entidad.

Esto significa que esos atributos tienen un valor diferente para cada instancia y nunca se repiten.

Dicho atributo se denomina Atributo Clave o Atributo Determinante dela entidad.
Por ejemplo:
Para la entidad “Persona” y considerando la realidad uruguaya, podríamos pensar como atributo clave la “Cédula de Identidad”, porque permite identificar inequívocamente a cada persona.

Pero no podríamos utilizar el atributo “Nombre” (aun si se tratara de una tributo compuesto de dos nombres y dos apellidos) porque puede darse el caso de que dos personas posean el mismo nombre.
REPRESENTACIÓN
Restricción de Dominio. Valores de los atributos
Cada atributo simple de las entidades está asociado a un conjunto de valores que encajan conceptualmente a la realidad que el atributo representa.

A este conjunto de valores se le denomina dominio del atributo.
Esta restricción no se representa en los diagramas ER estándar, generalmente se definen mediante el tipo de dato utilizado en el atributo que están disponibles en la mayoría de los lenguajes de programación.
RESTRICCIONES SOBRE RELACIONES
Restricción: Razón de Cardinalidad
La Razón de Cardinalidad limita el número máximo de instancias de una relación en las que una entidad puede participar.

Los valores que pueden usarse son:
1 para indicar que solo puede participar una única vez
N (o M) que indica que puede participar cualquier número de veces.
Por ejemplo
en la relación “Trabaja Para” entre Empresa y Empleado, podríamos decir que si nuestra realidad indica que
un Empleado solo puede trabajar en una Empresa
la
Razón de Cardinalidad
que modela esa realidad es
1:N
que indica que 1 Empresa puede relacionarse (emplear) a N cantidad de Empleados, mientras que un empleado (instancia de entidad Empleado) solo puede asociarse (trabajar) a una única empresa.
Los posibles valores para la Razón de Cardinalidad son: 1:1, 1:N, N:M.
Por Ejemplo
si pensamos en una relación que llamaremos “Gerencia” y decimos que representa que
cada departamento de una empresa solo puede tener una persona encargada y un encargado solo puede serlo de un departamento.


Esta relación asociaría a la entidad Departamento con la entidad Empleado y su Razón de Cardinalidad sería de 1:1 ya que como se dijo un Departamento solo puede tener un gerente y empleado solo puede dirigir un departamento.
Por ejemplo
si pensamos en una relación de “Trabaja En” que
modela los empleados que trabajan en cada proyecto
y decimos que
en un proyecto pueden trabajar varios empleados y que cada empleado puede trabajar en varios proyectos
entonces la
Razón de Cardinalidad
de esta relación sería
N:M
.

Restricción: Razón de Participación y Dependencia de Existencia o Cardinalidad Mínima.
Esta restricción especifica si la existencia de una entidad depende de estar asociada con otra entidad a través de una relación.

Esta restricción marca el número mínimo de instancias de relación en las que puede participar cada entidad.
Dos tipos de Participación:
Total
denominada Dependencia de Existencia
Parcial
Los valores pueden ser:
1 si existe
Participación Total
.
0 si existe
Participación Parcial
Por ejemplo
si tenemos una relación “Pertenece A” que asocia a la entidad Departamento y a la entidad Empleado, indicando a que departamentos pertenece cada empleado y decimos que
todo empleado debe pertenecer a algún departamento de la empresa
, estamos frente a una
Participación Total
porque
cada instancia de empleado debe estar asociado al menos a una instancia de Departamento para poder existir
,
tenemos entonces una Dependencia de Existencia
.
Por Ejemplo
si consideramos la
relación “Gerencia”
de más arriba,
la Participación es Parcial
porque no todos los empleados serán gerentes y la realidad podría indicarnos que no todos los departamentos tendrán gerente.
RESTRICCIONES DE INTEGRIDAD SEMÁNTICA O NO ESTRUCTURALES
Son restricciones que surgen del análisis de la realidad y que no pueden implementarse de forma estructural, sino que deben ser programadas en la aplicación que trabaje con el modelo de datos usado en la BD.
Por ejemplo
una restricción de este tipo puede ser: “El salario de un empleado no puede exceder el de su supervisor” o “Un empleado no puede trabajar más de 40 horas a la semana”.
En el curso nosotros la escribiremos en lenguaje natural y en notación formal basada en la lógica proposicional de predicados de primero orden.
ENTIDADES DÉBILES
(Página 67 y 68)
Las

Entidades Débiles
son entidades que
carecen de un atributo clave
que identifique cada instancia en forma autónoma. En contraposición las entidades que si poseen este atributo clave se denominan Entidades Fuertes.
Las Entidades Débiles
necesitan estar asociadas a una Entidad fuerte mediante una relación para poder lograr la identificación de cada instancia mediante la combinación con la información de la entidad fuerte. La participación en dicha relación del lado de la entidad débil es total por lo que
existe una Dependencia de Existencia
respecto a la entidad fuerte.
Dependencia de Existencia

Dependencia de Identificación.
Existen dos dependencias:
IMPORTANTE:
Todas las relaciones que enmarquen a una entidad débil tendrán una dependencia de existencia del lado de la entidad débil, porque tiene una dependencia de identidad respecto de la entidad fuerte.

Por ejemplo la entidad “Licencia de Conducir” no puede existir sino está relacionada a una entidad “Persona”, por lo que existe una Dependencia de Existencia, según lo que marca la realidad modelada, pero la entidad “Licencia de Conducir” posee su propio atributo clave, “NroLicencia“ por lo que no constituye una entidad débil.
No todas las Dependencias de Existencia enmarcaran la participación de una entidad débil.
Clave Parcial
Las Entidades Débiles poseen lo que se denomina Clave Parcial que es un atributo o conjunto de atributos mínimo que permiten identificar a cada instancia de la Entidad Débil una vez asociada a su entidad fuerte.

Esto es discriminar a cada instancia de las entidades débiles asociadas a una instancia de la entidad fuerte. Por este motivo a estos atributos también se les llama Discriminante.

REPRESENTACIÓN:
ACLARACIONES:
Puede existir anidamiento entre entidades débiles hasta cualquier nivel.

Una Entidad Débil puede ser la Entidad Fuerte de otra Entidad Débil que depende de ella.

Una Entidad Débil puede tener más de una Entidad Fuerte para poder identificarse, que es en el caso de las relaciones múltiples.
RESUMEN DE NOTACIÓN Y MEJORES PRÁCTICAS
(Página 69 a 72)
En los diagramas ER se hace hincapié en la representación de los esquemas, más que de las instancias. Esto es más útil en el diseño de bases de datos porque el esquema de una base de datos rara vez cambia, mientras que el contenido de los conjuntos de entidades cambia con frecuencia. Además, normalmente es más fácil visualizar el esquema que la extensión de una base de datos, porque es mucho más pequeño.
RESUMEN
Las Entidad aparecen en rectángulos.

Las Relaciones se muestran en rombos conectados a las Entidades participantes mediante líneas rectas.

Los atributos se muestran en óvalos, y cada uno está conectado a su Entidad o Relación a la que pertenece mediante una línea recta.

Los atributos simples que componen un atributo compuesto se conectan con el óvalo que representa el atributo compuesto.

Los atributos multivalor se muestran con óvalos dobles.

Los nombres de los atributos clave aparecen subrayados.

Los atributos derivados se muestran con óvalos de línea punteada.
Las Entidades Débiles se distinguen porque se colocan en rectángulos de borde doble y porque las relaciones que los identifican aparecen en rombos dobles.

La clave parcial del tipo de entidad débil se subraya con una línea punteada.

La Razón de Cardinalidad de cada relación binaria se especifica adjuntando 1, M o N a cada borde participante.

La Restricción de Participación se especifica mediante una línea sencilla o un 0 para la Participación Parcial y con líneas dobles o un 1 para la Participación Total (Dependencia de Existencia).

Mostrar los nombres de papel o rol para las Auto-Relaciones es esencial porque una misma Entidad puede desempeñar dos roles diferentes.
RESUMEN
BUENAS PRÁCTICAS
Optaremos por nombres en singular para las Entidades, en lugar de nombres plurales.

Los nombres de las entidades y de las Relaciones se escriben en mayúsculas

Los nombres de los Atributos se escriben con la primera letra en mayúscula, y los nombres de los papeles en minúsculas.

Como práctica general, dada una descripción narrativa de los requisitos de la base de datos, los nombres que aparecen en la narrativa tienden a ser nombres de Entidades, y los verbos tienden a indicar nombres de Relaciones.

Elección de nombres de relación binaria para que el diagrama ER del esquema se pueda leer de izquierda a derecha y de arriba abajo.
EJEMPLO DE MER
Supongamos que tenemos el siguiente diagrama ER de la base de datos Empresa.
Notar que el diagrama está diseñado para poder leerse de izquierda a derecha y de arriba abajo. Excepto por un detalle. Cuál?
Imagen extraída del libro “Sistemas de Bases de Datos – Conceptos Fundamentales –“ Elmasri / Navathe. 5ta Edición.
página 73.
Que información puede leer del diagrama y traducirla en requerimientos?
RELACIONES MÚLTIPLES
(Páginas 75 a 78)
Son relaciones N-Áreas, es decir que involucran a más de dos Entidades.

Son difíciles de manejar y de extraer de la realidad y dependen mucho de la realidad que se está representando.

En ocasiones una relación ternaria podemos representarla como tres relaciones binarias, pero no siempre representanla misma información

Veamos un ejemplo
La realidad nos indica que un Equipo de trabajo es asignado a un Proyecto determinado y está integrado por determinados técnicos.
Si la realidad indica que los equipos se fijan de acuerdo al proyecto al que van a trabajar, y sus integrantes varían dependiendo de cada proyecto, entonces...

CUAL ES LA REPRESENTACIÓN CORRECTA?

Pero si por el contrario, la realidad indicara que los técnicos asignados a un equipo de trabajo son independientes del proyecto asignado para ese equipo, es decir que los equipos se conforman antes y en forma independiente del proyecto que se le asigne, entonces con la representación anterior estamos generando redundancia en el almacenamiento:

Por ejemplo, nos dicen dos veces que el equipo A trabaja sobre el proyecto X, y si el mismo equipo comienza a trabajar sobre el proyecto Z nos dirá dos veces que los técnicos 1 y 2 pertenecen a ese equipo, porque necesitaremos agregar múltiples registros, uno para cada una de los técnicos integrantes del equipo.

El resultado de asociar un elemento de un conjunto (Entidad) con un elemento de otro conjunto (entidad) da como resultado un elemento en el conjunto de la relación que los tiene a ambos, y esta combinación de elementos no puede repetirse o dejaría de ser función.
IMPORTANTE:
Veamos un ejemplo:
Si la realidad nos dice que tenemos PROFESORES y ALUMNOS y que los alumnos son evaluados una única vez por cada profesor, entonces la representación siguiente sería correcta:
Se utilizarán estas dos siglas de forma indistintas en este trabajo.
NOTA:

A lo largo de este trabajo, se indicará entre paréntesis para cada tema, las páginas del libro "Sistemas de Bases de Datos" – Conceptos Fundamentales – (Elmasri / Navathe) que pueden ser consultadas para profundizar el conocimiento, ya que el objetivo del mismo es servir como guía de estudio.
(Páginas 13 a 15)
(Página 20)
(Páginas 15 a 20)
Universidad ORT Uruguay
Facultad de Ingeniería
Cátedra de Base de Datos
Profesor: David Giménez
drgimenez@gmail.com
Full transcript