Está en la página 1de 120

DISEÑO E IMPLEMENTACIÓN

DE BASE DE DATOS

Facultad de Ciencias de la Ingeniería


Ingeniería Informática y Ciencias de la Computación

Proceso del diseño e Implementación


de una Base de Datos
Contenido:
1. Introducción
• Proceso para el Diseño e implementación de BDD
2. Análisis de Requerimientos
3. Diseño Conceptual
• Modelo Entidad – Relación
• Esquema E-R
4. Elección del DBMS
• Factores: Técnicos, Económicos, Organizacionales
5. Diseño Lógico
• Modelo Relacional
• Esquema Lógico Estándar
• Transformación de Entidades - Esquema Lógico Especifico
• Diccionario de Datos y Dominio de un Atributo
6. Diseño Físico
7. Conclusión
Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
> Proceso
Es un conjunto de actividades que consume
insumos de entrada para generar productos o
servicios de valor para el cliente
Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Modelos de procesos
• El modelo de procesos es el ordenamiento y conjunto
de actividades través del tiempo y del espacio
• Es necesario insumos para ser transformados y
producir exsumos.
Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD
• El proceso de diseño de una base de datos consiste
en definir la estructura de los datos que debe tener
la base de datos de un sistema de información
determinado.
• En el caso relacional, esta estructura será un conjunto
de esquemas de relación con sus atributos, dominios
de atributos, claves primarias, claves foráneas, etc.
• El proceso responde a una serie de preguntas
específicas para cualquier aplicación de
procesamiento de datos. ¿Cuáles son las entidades?
¿Cuáles son los atributos de cada entidad? Dónde
residen actualmente los datos?, etc..
Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD

Proceso de Diseño de Base de Datos


Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD

GESTION
COMPARTIDA

Proceso comprimido de Diseño de BDD


Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD
Proceso de Diseño de BDD - Elmasri, R., & Shamkant
B, N. 2007 Fundamentos de Sistemas de Base de Datos
Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD

MODELO ESQUEMA
DEPENDIENTE DEPENDIENTE
DISEÑO MODELO ESQUEMA
DEL SGBD DEL SGBD
(SI/NO) (SI/NO)

CONCEPTUAL E-R NO E-R NO

LOGICO
RELACIONAL NO RELACIONAL NO
ESTANDAR
LOGICO BDD
NO SQL SI
ESPECIFICO RELACIONAL
ÁRBOLES B+, ALMACENAMIENTO
FISICO ESTRUCTURAS SI Y ESTRUCTURA DE SI
DE HASH, ETC. ARCHIVOS

Relación entre Modelo y Esquema en el Proceso de Diseño de BDD


Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD
• Por todo lo anterior, por lo tanto, se debe resolver
algunas cuestiones fundamentales para poder
emplear la tecnología de las bases de datos
relacionales.
• Por ejemplo, cómo se puede decidir qué relaciones
debe tener una base de datos determinada o qué
atributos deben presentar las relaciones, qué claves
primarias y qué claves foráneas se deben declarar,
etc.
• La tarea de tomar este conjunto de decisiones recibe
el nombre de diseñar la base de datos.
Proceso del Diseño e implementación de una Bases de Datos
1. Introducción
>Proceso para el Diseño e implementación de BDD
• En resumen, el diseño de una base de datos consiste
en definir la estructura de los datos que debe tener
la base de datos de un sistema de información
determinado.
• En el caso relacional, esta estructura será un
conjunto de esquemas de relación con sus atributos,
dominios de atributos, claves primarias, claves
foráneas, etc.
Proceso del Diseño e implementación de una Bases de Datos
2. Análisis de Requisitos
• Se refiere a los requisitos funcionales de la
aplicación o sistema informático.
• Se especifican requisitos referidos a datos y
procesos.
• Técnicas de Modelado: ER, UML, SADT, Warnier-
Orr, DFD’s, Ágiles, etc.
Proceso del Diseño e implementación de una Bases de Datos
2. Análisis de Requisitos
• Los formularios y los informes presentan algunos
requisitos de datos para la base de datos.
Proceso del Diseño e implementación de una Bases de Datos
2. Análisis de Requisitos
• Los requisitos se los puede organizar en tablas
evitando de esta manera eliminar información que
puede ser valiosa para la futura BDD

• Una estrategia para dividir la información en tablas


es observar primero los datos individuales y
determinar de qué trata cada uno (aplicar
abstracción)
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual

Basado en los textos:


Batini, C.; Ceri, S.; Navathe, S.B. Conceptual Database Design: An Entity-Relationship Approach.
Reading, Massachusetts: Addison Wesley.
Teorey, T.J. Database Modeling & Design. The Fundamental Principles (3ª ed.). San Francisco: Morgan
Kaufmann Publishers, Inc.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
• Una vez recopilados y analizados todos los
requisitos, el siguiente paso es diseñar un esquema
conceptual para la base de datos, mediante un
modelo de datos conceptual de alto nivel. Este paso
se denomina diseño conceptual.
• Por medio de un modelo de datos de alto nivel
podemos obtener un esquema.
• El esquema conceptual es una descripción concisa
de los requisitos de datos por parte de los usuarios e
incluye descripciones detalladas de los tipos de
entidades, relaciones y restricciones; se expresan
utilizando los conceptos proporcionados por el
modelo de datos de alto nivel.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
¿Por qué esforzarse en realizar un esquema
conceptual?
> Se obtiene una estructura de la información de la
futura BDD
> Es independiente de la tecnología que hay que
emplear (No depende del DBMS)
> No se tiene en cuenta todavía qué tipo de base de
datos se utilizará –relacional, orientada a objetos,
jerárquica, etc.; en consecuencia, tampoco se
tiene en cuenta con qué DBMS ni con qué
lenguaje concreto se implementará la base de
datos.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
¿Por qué esforzarse en realizar un esquema
conceptual?
> Nos permite concentrarnos únicamente en la
problemática de la estructuración de la
información, sin tener que preocuparnos al
mismo tiempo de resolver cuestiones
tecnológicas
> El resultado de la etapa del diseño conceptual se
expresa mediante algún modelo de datos de alto
nivel, en nuestro caso el modelo Entidad-
Relación (E-R [entity-relationship]) descrito en
un esquema E-R.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
> El origen del modelo ER se encuentra en trabajos
efectuados por Peter Chen en 1976.
Posteriormente, muchos otros autores han
descrito variantes y/o extensiones de este
modelo.
> Un modelo de datos tiene en cuenta tres aspectos
o características de los datos: la estructura, la
manipulación y la integridad.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• La estructura, que debe permitir representar la
información que nos interesa del mundo real.
• La manipulación, a la que da apoyo mediante las
operaciones de actualización y consulta de los datos.
• La integridad, que es facilitada mediante el
establecimiento de reglas de integridad; es decir,
condiciones que los datos deben cumplir.
> Sin embargo, el modelo E-R habitualmente se
utiliza para reflejar aspectos de la estructura de
los datos y de su integridad, pero NO de su
manipulación
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> Entidad es un objeto del mundo real que
podemos distinguir del resto de objetos y del que
nos interesan algunas propiedades. Ej: Empleado,
producto, factura, etc.
> Los atributos son las propiedades de los objetos
que nos interesan. Sobre una entidad empleado
nos puede interesar, por ejemplo, tener
registrados su DNI, nombre, apellido y sueldo
como atributos.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> Para cada atributo hay un conjunto de valores
permitidos, llamado dominio de ese atributo.
> Cada uno de los atributos de una entidad toma
valores de un cierto dominio o conjunto de
valores.
> Los valores de los dominios deben ser atómicos;
es decir, no deben poder ser descompuestos.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> Todos los atributos tienen que ser univaluados.
Un atributo es univaluado si tiene un único valor
para cada ocurrencia de una entidad.
> Por ejemplo, el atributo sueldo de la entidad
empleado, toma valores del dominio de los reales
y únicamente toma un valor para cada empleado
concreto; por lo tanto, ningún empleado puede
tener más de un valor para el sueldo.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> Una Entidad debe ser distinguible del resto de
objetos del mundo real.
> Esto hace que para toda entidad sea posible
encontrar un conjunto de atributos que permitan
identificarla. Este conjunto de atributos forma
una clave de la entidad.
> Una determinada entidad puede tener más de una
clave; es decir, puede tener varias claves
candidatas.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> El diseñador elige una clave primaria entre todas
las claves candidatas. La clave primaria se
subraya para distinguirla del resto de las claves.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> Se define relación (o interrelación en varios
textos) como una asociación entre entidades.
> Las relaciones se representan en los diagramas
del modelo E-R
mediante un rombo.
> Junto al rombo se indica
el nombre de la interrelación
con letras mayúsculas
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
Entidad Atributo Relación
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Construcciones básicas: Entidades, atributos y
relaciones
> Las relaciones pueden tener también atributos.
Los atributos de las relaciones, tienen un cierto
dominio, deben tomar valores atómicos y deben
ser univaluados.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Grado de las relaciones
> Una relación puede asociar dos o más entidades.
El número de entidades que asocia una relación
es el grado de la relación.
> La relación evaluación
asocia la entidad estudiante y la
entidad asignatura; es decir,
asocia dos entidades.
> Las relaciones de grado dos se denominan
también interrelaciones binarias.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Grado de las relaciones
> Todas las interrelaciones de grado mayor que dos
se denominan, en conjunto, relaciones n-arias.
> Así pues, una relación n-aria puede tener grado
tres y ser una relación ternaria, puede tener
grado cuatro y ser una relación cuaternaria, etc.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones
> La conectividad de una relación expresa el tipo
de correspondencia que se establece entre las
ocurrencias de entidades asociadas con la
relación.
> En el caso de las relaciones binarias, expresa el
número de ocurrencias de una de las entidades
con las que una ocurrencia de la otra entidad
puede estar asociada según la relación.

Nota: La Conectividad es denominada también como Cardinalidad


Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones binarias
> Conectividad uno a uno (1:1)

Según los requisitos de los usuarios de esta BD, una nota pertenece al
mismo tiempo a un estudiante, a una asignatura y a un semestre
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones binarias
> Conectividad uno a muchos (1:N)

DEPARTAMENTO

Esto significa que un empleado es asignado a una Departamento, pero


que, en cambio, un departamento puede tener uno o más empleados
asignados.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones binarias
> Conectividad muchos a muchos: (M:N)

Un estudiante puede ser evaluado de varias asignaturas y, al mismo


tiempo, que una asignatura puede tener varios estudiantes por evaluar
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones binarias
Nota Especial: Es muy habitual que las relaciones
binarias M:N y todas las n-arias tengan atributos.
> En cambio, las relaciones binarias 1:1 y 1:N no
tienen por qué tenerlos.
> Siempre se pueden asignar estos atributos a la
entidad del lado N, en el caso de las 1:N; y a
cualquiera de las dos entidades interrelacionadas
en el caso de las 1:1.
> Este cambio de situación del atributo se puede
hacer porque no origina un atributo multivaluado.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Ejercicios: Diseñar el diagrama Entidad Relación
1. Tenemos una universidad, en la que hay varios
cursos. Cada curso está dirigido por un profesor, el
cual puede dirigir varios cursos. Los cursos son
limitados, por lo que sólo se permite que un
alumno se matricule en un curso.
2. Hay varios cursos. Cada curso está dirigido por un
profesor. Un curso está compuesto por varias
asignaturas. Cada una de ellas tiene un número de
créditos. Los alumnos se matriculan de las
asignaturas que quieren. Por último el alumno
recibe una nota para cada asignatura, al final del
curso
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> Las interrelaciones n-arias, igual que las binarias,
pueden tener diferentes tipos de conectividad.
> En este subapartado analizaremos primero el
caso particular de las interrelaciones ternarias.

> Las interrelaciones ternarias pueden tener cuatro


tipos de conectividad: M:N:P, M:M:1, N:1:1 y
1:1:1.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> Consideremos una relación que denominamos
clase y que asocia las entidades asignatura, aula y
hora-semanal. Esta relación permite registrar
clases presenciales.
> Se puede hacer clase si una asignatura
determinada se imparte en un aula determinada y
a una hora de la semana determinada.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> El resultado del ejemplo anterior sería la
siguiente relación:
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> ¿Cómo decidir qué entidad se conecta con “uno”
o con “muchos?

?
?
?
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> ¿Cómo decidir qué entidad se conecta con “uno”
o con “muchos?
Es necesario preguntarse si,
dadas un Aula y una Hora-
Semanal, se puede hacer clase
de sólo una o bien de muchas
1 asignaturas en aquellas aula y
hora. La respuesta sería que sólo
se puede hacer clase de una
asignatura en una misma aula
y hora. Esto nos indica que la
entidad asignatura se conecta
con “uno”.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> ¿Cómo decidir qué entidad se conecta con “uno”
o con “muchos?
Una vez fijadas una
asignatura y un aula, es
posible que se haga clase de
1 aquella asignatura en
aquella aula, en varias
N horas de la semana;
entonces, la entidad hora-
semana se conecta con
“muchos”
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> ¿Cómo decidir qué entidad se conecta con “uno”
o con “muchos?
Fijadas una asignatura y
una hora de la semana,
sólo se puede hacer una
1 clase de aquella asignatura a
aquella hora en una aula.
N La entidad aula se conecta
1 con “uno”
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> ¿Cómo decidir qué entidad se conecta con “uno”
o con “muchos?

La conectividad
1 resultante, de este
N modo, es N:1:1.
1
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Conectividad de las relaciones n-arias
> Una interrelación n-aria puede tener n + 1 tipos
de conectividad, teniendo en cuenta que cada una
de las n entidades puede estar conectada con
“uno” o con “muchos” en la relación.
> En el caso de las ternarias (n=3) tiene 4 tipos de
conectividad (n+1 M:N:P, M:M:1, N:1:1 y 1:1:1)
> Para decidir si una de las entidades se conecta
con “uno” o con “muchos”, es necesario
preguntarse si, fijadas ocurrencias concretas de
las otras n – 1 entidades, es posible conectar sólo
una o bien muchas ocurrencias de la primera
entidad:
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Relaciones recursivas
> De acuerdo a [Korth/Silberschatz] “Son aquellas
que se dan cuando los conjuntos de entidades de
una relación no son distintos; es decir, el mismo
conjunto de entidades participa en una relación
mas de una vez con diferentes papeles.”
> Según [Elmasri/Navathe] “Una relación recursiva
se da cuando el mismo tipo de entidades
participa más de una vez con diferentes
papeles”
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Relaciones recursivas binarias
> Las relaciones binarias recursivas pueden tener
conectividad 1:1, 1:N o M:N, como todas las
binarias.

La relación “Casado/a”
tiene conectividad 1:1
porque un esposo está
casado con una sola esposa.
Y una esposa está casada
con un solo esposo
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Relaciones recursivas binarias
> Las relaciones binarias recursivas pueden tener
conectividad 1:1, 1:N o M:N, como todas las
binarias.

La relación “Dirige” tiene


conectividad 1:N porque
un Doctor puede ser jefe de
varios doctores. Y un
Doctor es subalterno de un
Médico que dirige al
personal médico.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Relaciones recursivas binarias
> Las relaciones binarias recursivas pueden tener
conectividad 1:1, 1:N o M:N, como todas las
binarias.
Conectividad M:N. Es común este tipo
de estructura cuando se trata de un
catálogo de materiales o de otro tipo de
objetos que demuestra la composición
(parte constitutiva) y descomposición de
los componentes, por ejemplo, un
repuesto está formado por varios
repuestos y un repuesto puede ser a su
vez componente de varios repuestos.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Relaciones recursivas ternarias

• La relación Casado/a permite tener constancia no sólo de las bodas


vigentes, sino de todas las bodas realizadas en un cierto periodo de tiempo.
• Esta relación es recursiva y ternaria. Una ocurrencia de la relación asocia a
una persona que es el esposo, a otra que es la esposa y la fecha de su boda.
La conectividad es N:1:1.
• Al lado de la entidad boda le corresponde una N, porque se podría dar el
caso de que hubiese, en fechas diferentes, más de una boda entre las
mismas personas.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Ejercicios: Diseñar el esquema Entidad Relación
1. Una cuenta contable puede estar formada de varias
cuentas, denominadas “subcuentas”. Cada cuenta
es parte de una sola cuenta del nivel superior.
2. En un taller existen varias bodegas que administran
y almacenan repuestos según su tipo y que son
despachados a medida que se realizan los trabajos.
Un repuesto puede estar formado por varios
repuestos y un repuesto puede ser a su vez
componente de varios repuestos
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Ejercicios: Diseñar el diagrama Entidad Relación
3. En un sistema informático de administración
estudiantil se requiere registrar información de
estudiantes, materias tomadas por los
estudiantes y del profesor con las materias
asignadas y adicional a esto se requiere
registrar la nota final. Realizar el esquema
entidad – relación.
Proceso del Diseño e implementación de una Bases de Datos
3. Diseño Conceptual
> Modelo Entidad – Relación E-R
• Deber: Realizar los siguientes ejercicios:
> Elmasri, R., & Shamkant B,
Fundamentos de Sistemas de Base de Datos.
» 3.16, página 80
» 3.21, página 81
Proceso del Diseño e implementación de una Bases de Datos
4. Elección del DBMS
• Para que un DBMS pueda implementar un modelo
de datos necesita apoyarse en un lenguaje de
programación que gestione dicho modelo.
• El lenguaje aceptado por todos los sistemas de bases
de datos comerciales es el SQL (Structured Query
Language).
• Es importante indicar que cada DBMS incorpora su
propio SQL que recoge, dependiendo de cada
sistema, lo más significativo del estándar.
Proceso del Diseño e implementación de una Bases de Datos
4. Elección del DBMS
• Se crearon ciertas propiedades para los DBMS
denominadas (ACID):
> Atomicity (Atomicidad): Transacción se realiza
SI O NO [se ejecuta todo o nada]
> Consistency (Consistencia): Se respetan las
reglas del DBMS [de un estado consistente a
otro]
> Isolation (Aislamiento): Transacciones unitarias.
Varias transacciones concurrentes pero sus
efectos deben ser de una manera independiente.
> Durability (Durabilidad): Los datos deben ser
persistentes ante emergencias. Los cambios que
se realicen se conservan.
Proceso del Diseño e implementación de una Bases de Datos
4. Elección del DBMS
• Consideraciones para elegir un DBMS:

> Factores Técnicos


> Factores Económicos
> Políticas de la organización
Proceso del Diseño e implementación de una Bases de Datos
4. Elección del DBMS
> Factores Técnicos
• Tipo de DBMS (Relacionales, Orientados a Objetos,
Objetos Relacionales)
• Estructuras de almacenamiento y acceso
• Disponibilidad de herramientas de desarrollo
• Soporte del gestor de bases de datos
• Carga de transacciones que va a soportar esa base de
datos
• Especificaciones de los recursos de HW y SW
• Sistema operativo donde se planea implementar
Proceso del Diseño e implementación de una Bases de Datos
4. Elección del DBMS
> Factores Económicos
• Costo de Adquisición
• Costo de Mantenimiento
• Costo de Adquisición de HW
• Costo de Integración con Sistemas de Información
• Costo de Personal (Recurso Humano)
• Costo de Operación (independiente del DBMS),
entrega y soporte de los servicios y aplicaciones.
Asegurar que cumplan con los niveles de
disponibilidad acordados.
Proceso del Diseño e implementación de una Bases de Datos
4. Elección del DBMS
> Políticas de la organización
• Cultura organizacional
• Familiaridad con el Sistema
• Disponibilidad de servicios con el proveedor
• Políticas, Leyes y Normativa (Gubernamental,
Organizacional)
• Demostraciones, Benchmark (Obtener la mejor
relación costo/beneficio para la empresa)
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Partiremos del resultado de la etapa del diseño
conceptual expresado mediante el modelo E-R y
veremos cómo se puede transformar en una
estructura de datos del modelo relacional.
• Los principios del modelo de datos relacional fueron
establecidos por E.F. Codd en los años 1969 y 1970.
• De todos modos, hasta la década de los ochenta no se
empezaron a comercializar los primeros DBMS
relacionales con rendimientos aceptables.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• En este apartado nos vamos a centrar en definir los
elementos básicos del modelo
• Objetivos del modelo de datos relacional:
> Facilitar que la base de datos sea percibida o
vista por el usuario como una estructura lógica
que consiste en un conjunto de relaciones.
> Conseguir que esta estructura lógica con la que
se percibe la base de datos sea simple y
uniforme, con el fin de proporcionar simplicidad
y uniformidad
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Cada entidad del modelo E-R se transforma en una
relación (tabla) del modelo relacional.
• Los atributos de la entidad serán atributos
(columnas) de la relación.
• La clave primaria (PRIMARY KEY) de la entidad
será la clave primaria de la relación.
• Las Filas se conocen en el modelo relacional como
tuplas
• El modelo relacional es un modelo de datos y, como
tal, tiene en cuenta la estructura, la manipulación y
la integridad.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Las entidades, cuando se traducen al modelo
relacional, se denominan también tablas.

• El esquema de la relación consiste en un nombre de


relación R y un conjunto de atributos:
R(A1, A2, ..., An)
• Ejemplo: Empleado(DNI, nombre, apellido, sueldo)
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Las interrelaciones, en cambio, cuando se
transforman, pueden dar lugar a claves foráneas
(FOREING KEY) de alguna relación ya obtenida o
pueden dar lugar a una nueva relación.
• En el caso de las interrelaciones, es necesario tener
en cuenta su grado y su conectividad para poder
decidir cuál es la transformación adecuada:
> Las interrelaciones binarias 1:1 y 1:N dan lugar
a claves foráneas.
> Las interrelaciones binarias M:N y todas las
n-arias se traducen en nuevas relaciones o
tablas.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico estándar Elmasri, R., & Shamkant B, N. 2007 Fundamentos
de Sistemas de Base de Datos 5 ed. Pearson.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico estándar
> El esquema de la relación consiste en un nombre
de relación R y un conjunto de atributos:
R(A1, A2, ..., An)
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico estándar (mediante Tablas)
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
1. Cada entidad genera una relación/tabla.
2. Los mapeos m…n generan una tabla.
3. Los mapeos 1…n se expresan con la repetición
del lado 1 en el lado n (clave foránea).
4. Para las entidades m…n que generaron una
tabla, la clave primaria está formada por las
claves de los lados m…n.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Nota: Los nombres de atributos de los ejemplos
del esquema relacional presentado a continuación
NO cumplen con los estándares y buenas
prácticas para el Diseño de Bases de Datos.
> En clase se presentó ejemplos de modelos y
estandarización para la declaración de tablas,
atributos, claves primarias, claves foráneas, etc.
> Así mismo en clase se especificó el proceso de
transformación a través de tablas.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación binaria 1:1
Sólo será
necesario
añadir a
cualquiera de
estas dos
relaciones
una clave
foránea que
referencie a la
otra relación.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación binaria 1:1
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación binaria 1:N
Es necesario
añadir en la
relación
correspondiente
a la entidad del
lado N, una clave
foránea que
referencie la otra
relación.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación binaria 1:N
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación binaria M:N Una interrelación
M:N se transforma
en una relación
(Tabla). Su clave
primaria
estará formada por
los atributos de la
clave primaria de
las dos entidades
interrelacionadas.
Los atributos de la
interrelación serán
atributos de la
nueva Tabla.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación binaria M:N
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria M:N:P
Cuando la conectividad de la
interrelación es M:N:P, la
relación (Tabla) que se
obtiene de su transformación
tiene como clave primaria
todos los atributos
que forman las claves
primarias de las tres
entidades interrelacionadas.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria M:N:P
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria M:N:1

La relación (tabla) que se obtiene


de su transformación tiene como
clave primaria todos los atributos
que forman las claves primarias
de las dos entidades de los lados
de la interrelación etiquetados
con M y con N.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria M:N:1
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria N:1:1
La relación (tabla) que se
consigue de su transformación
tiene como clave primaria los
atributos que forman la clave
primaria de la entidad del lado
N y los atributos que forman la
clave primaria de cualquiera
de las dos entidades que están
conectadas con 1.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria N:1:1
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria 1:1:1

La relación (Tabla) que


se obtiene de su
transformación tiene
como clave primaria los
atributos que forman la
clave primaria de dos
entidades cualesquiera
de las tres
interrelacionadas.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria 1:1:1
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria 1:1:1
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación ternaria 1:1:1
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación n-aria
» En todos los casos, la transformación de una
interrelación n-aria consistirá en la obtención
de una nueva relación (tabla) que contiene
todos los atributos que forman las claves
primarias de las n entidades interrelacionadas
y todos los atributos de la interrelación.
» Podemos distinguir los 2 casos:
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación n-aria
1. Si todas las entidades están conectadas con
“muchos”, la clave primaria de la nueva
relación estará formada por todos los
atributos que forman las claves de las n
entidades interrelacionadas.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación n-aria
2. Si una o más entidades están conectadas
con “uno”, la clave primaria de la nueva
relación estará formada por las claves de
n – 1 de las entidades interrelacionadas,
con la condición de que la entidad, cuya
clave no se ha incluido, debe ser una de las
que está conectada con “uno”.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación Recursiva 1:1 o 1:N
Originan una clave foránea que
se pone en la relación
correspondiente a una de las
entidades interrelacionadas. Esta
clave foránea deberá referenciar
a la misma relación para que
refleje una interrelación entre
una ocurrencia de persona y otra
ocurrencia de persona. Así,
obtendremos:
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación Recursiva 1:1 o 1:N
PERSONA (código-per, ..., código-conyuge)
donde {código-conyuge} referencia PERSONA
y código-conyuge admite valores nulos
La clave foránea {código-conyuge} referencia
la relación PERSONA a la que pertenece.

DOCTOR (código-doctor, ..., código-Subalterno)


donde {código-Subalterno} referencia DOCTOR
y código-Subalterno admite valores nulos
La clave foránea {código-subalterno}
referencia la relación DOCTOR a la que
pertenece.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación Recursiva M:N

Las interrelaciones M:N se traducen en


nuevas relaciones que tienen como clave
primaria las claves de las entidades
interrelacionadas.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación Recursiva M:N
REPUESTO (código-repuesto, ...,)
PARTE (código-repuesto, código-repuestoparte)
donde {código-repuesto} referencia REPUESTO
y {código-repuestoparte }referencia a REPUESTO
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación Recursiva n-aria N:1:1

Las interrelaciones N:1:1 originan siempre una nueva relación


que contiene, además de los atributos de la interrelación, todos
los atributos que forman la clave primaria de las tres entidades
interrelacionadas.
Proceso del Diseño e implementación de una Bases de Datos
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades
> Relación
PERSONA Recursiva n-aria N:1:1
(código-per,...)
BODA (código-boda, FechaBoda,…..)
CASADO/A (código-per, código-boda, código_conyuge)
donde {código-per} referencia PERSONA,
{código-boda} referencia a BODA y
{código-conyuge}referencia a PERSONA
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
A. REALIZAR EL MODELO ENTIDAD – RELACION
B. TRANSFORMAR EL MODELO E-R AL MODELO
RELACIONAL
DESCRIPCIÓN DEL NEGOCIO:
Este negocio se dedica a la adquisición y expendio
de medicamentos, implementos de aseo personal,
suplementos vitamínicos, entre otros. El negocio
sigue el siguiente proceso:
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
1. El jefe de ventas se contacta con un determinado
proveedor y se acuerda una visita.
2. El proveedor contacta a un visitador de medicinas
para que acuda al negocio y solicita al jefe de
ventas información específica de los productos que
no tiene en stock y le presenta una revista de
nuevos productos vigentes en el mercado.
3. El jefe de ventas bajo un previo análisis determina
la cantidad de productos que debe adquirir del
proveedor y si es necesario realiza un pedido de los
nuevos productos..
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
4. El proveedor realiza la entrega de productos, estos
son revisados por el jefe de ventas el mismo que
verifica que se esté cumpliendo el pedido
realizado.
5. Se ingresan los productos al sistema y se procede a
la venta de los diferentes productos hacia los
clientes.
6. En lo referente a la venta (facturación), aquí se
registran toda la información correspondiente a los
clientes, cajeros y productos que se han vendido.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
7. El jefe de ventas es el jefe de los cajeros y los
cajeros son dirigidos por el jefe de ventas.
8. Por la afluencia de clientes el jefe de ventas puede
ocupar un punto de venta y facturar a los clientes.
La Base de Datos almacenará:
• Los productos que son abastecidos por los
proveedores.
• Los cajeros que han prestado y prestan servicios a la
empresa.
• Los clientes que adquieren los diferentes productos.
• Las transacciones de venta realizadas día a día por el
negocio.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Transformación de las Entidades - Ejercicio
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
A. Esquema Entidad-Relación
> Modelo Relacional
• Transformación de las Entidades - Integración
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico B. Esquema Relacional (Conjuntos)
> Modelo Relacional
• Transformación de las Entidades
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico B. Esquema Relacional (Tablas)
> Modelo Relacional
• Transformación de las Entidades
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico específico
> Fases
1. Diseño lógico estándar (Esquema
Relacional: Conjuntos o Tablas)
2. Diseño lógico específico (Se elige el
DBMS)
3. Conjunto de sentencias DDL (Create, Alter,
Drop, Rename, Truncate) del DBMS elegido
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico específico
> Tipos de Datos:
» Según el DBMS, estos pueden variar
» Básicos: Numéricos, caracteres, fechas
» Datos complejos: imágenes, sonidos
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico específico
> Sentencias SQL: Create Table
CREATE TABLE nombre_tabla
(
nombrecolumna1 tipodato1,
nombrecolumna2 tipodato2,
nombrecolumna3 tipodato3,
……..
nombrecolumnaN tipodatoN,
PRIMARY KEY (nombrecolumna_clave),
FOREIGN KEY (nombrecolumna_clave)
REFERENCES
TABLA2 (nombrecolumna_clave_tabla2)
)
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico específico (Script SQL para Oracle)

Conjunto de sentencias
DDL (Create, Alter, Drop,
Rename, Truncate) del
DBMS elegido
Proceso del Diseño e implementación de una Bases de Datos

5. Diseño Lógico
> Modelo Relacional
> Diccionario de Datos
• El diccionario de datos (almacena metadatos acerca
de la estructura de la base de datos) inicia
considerando el diseño integral de la base de datos,
es decir, el Diseño conceptual (modelo entidad-
relación) y Diseño lógico (modelo relacional).
• Con la utilización de herramientas CASE (Computer
Aided Software Engineering) es posible Diseñar los
modelos a base de esquemas y generación de scripts
para posteriormente cargar en el SGBD o DBMS.
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
> Diccionario de Datos
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
> Diccionario de Datos
Las descripciones deben ser gestionados por medio
de herramientas CASE disponibles
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
> Dominio de un atributo
» Para cada atributo hay un conjunto de
valores permitidos, llamado dominio de ese
atributo.
» Especifica un conjunto de valores que son
válidos a ingresar sobre una columna
específica para una tabla de la base de datos.
» Esta integridad se verifica a través:
1. Del tipo de los datos a introducir
(numérico, alfanumérico, alfabético,
etc.).
2. De una validación de los valores de
datos que se ingresan (una vez revisado funciones).
Proceso del Diseño e implementación de una Bases de Datos
5. Diseño Lógico
> Modelo Relacional
> Dominio de un atributo: 1. Tipo de Datos
Proceso del Diseño e implementación de una Bases de Datos
6. Diseño Físico

Análisis de Requisitos

DISEÑO CONCEPTUAL
NORMALIZACION

DISEÑO LÓGICO

DISEÑO FISICO

Proceso del Diseño de Base de datos Miguel, A., Piattini, M., Marcos, E
Proceso del Diseño e implementación de una Bases de Datos
6. Diseño Físico
Los objetivos principales que persigue el Diseño físico
de la base de datos son:
• Gestionar los metadatos (el diccionario de datos)
• Optimizar tiempos de respuesta
• Minimizar espacio de almacenamiento para los
ficheros físicos de la Base de Datos
• Optimizar rendimiento de transacciones (throughput)
• Proporcionar procedimientos óptimos de
recuperación e integridad de la BD
• Asegurarse que los requisitos y criterios de seguridad
y confidencialidad se cumplen
Proceso del Diseño e implementación de una Bases de Datos
6. Diseño Físico

Esquema lógico específico Estructura interna (Esquema


Enterno)
Objetivos de Diseño Físico
Especificaciones para el
Almacenamiento y recuperación
tunning de la BD
Recursos de máquina disponibles
Supervisión del Rendimiento
DISEÑO
Recursos de software disponibles FISICO Estructuras de
Información sobre las APP que utilizarán Almacenamiento
la Base de Datos
Normas de seguridad.
Requisitos de rendimiento
Procedimientos de
Políticas de seguridad de datos recuperación e integridad

Entradas (Insumos) y Salidas (Exumos) del Proceso de Diseño Físico de Bases de Datos
Proceso del Diseño e implementación de una Bases de Datos
7. Conclusión

La verdadera
innovación
comienza en
el diseño
Tim Brown.