Proceso Del Diseño e Implementación de Una Base de Datos - 2

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
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.
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..
1. Introducción
Proceso de Diseño de Base de Datos

1. Introducción
GESTION
COMPARTIDA
Proceso comprimido de Diseño de BDD

1. Introducción
Proceso de Diseño de BDD - Elmasri, R., & Shamkant
B, N. 2007 Fundamentos de Sistemas de Base de Datos
1. Introducción
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

1. Introducción
• 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.
1. Introducción
• 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.
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.
• Los formularios y los informes presentan algunos
requisitos de datos para la base de datos.
• 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)
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.
• 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.
¿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.
¿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.
> 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.
• 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
• Construcciones básicas: Entidades, atributos y
relaciones
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.
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.
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.
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.
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.
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
relaciones
Entidad Atributo Relación
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.
• 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.
• 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.
• 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

• 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
> 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.
> 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
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.
• 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
• 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.
> 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.
> El resultado del ejemplo anterior sería la
siguiente relación:
> ¿Cómo decidir qué entidad se conecta con “uno”
o con “muchos?
?
?
?
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”.
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”
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”
o con “muchos?
La conectividad
1 resultante, de este
N modo, es N:1:1.
1
> 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:
• 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”
• 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
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.
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.
• 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.
• 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
• 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.
• 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
• 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.
• 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.
• Consideraciones para elegir un DBMS:
> Factores Técnicos

> Factores Económicos
> Políticas de la organización
> 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
> 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.
> 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)
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.
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
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.
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)
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.
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.
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)
5. Diseño Lógico
> Modelo Relacional
• Esquema lógico estándar (mediante Tablas)
5. Diseño Lógico
> Modelo Relacional
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.
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> 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.
Nota: Considerar las especificaciones de la dispositiva 71
5. Diseño Lógico
> Modelo Relacional
> Relación binaria 1:1
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> Relación binaria 1:N
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> Relación binaria M:N
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> Relación ternaria M:N:P
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> Relación ternaria M:N:1
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> Relación ternaria N:1:1
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
> 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:
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> 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”.
5. Diseño Lógico
> Modelo Relacional
> 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:
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> 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
5. Diseño Lógico
> Modelo Relacional
> 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.
5. Diseño Lógico
> Modelo Relacional
> 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
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:
5. Diseño Lógico
> Modelo Relacional
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..
5. Diseño Lógico
> Modelo Relacional
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.
5. Diseño Lógico
> Modelo Relacional
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.
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
A. Esquema Entidad-Relación
> Modelo Relacional
• Transformación de las Entidades - Integración
5. Diseño Lógico B. Esquema Relacional (Conjuntos)
> Modelo Relacional
5. Diseño Lógico B. Esquema Relacional (Tablas)
> Modelo Relacional
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
5. Diseño Lógico
> Modelo Relacional
> Tipos de Datos:
» Según el DBMS, estos pueden variar
» Básicos: Numéricos, caracteres, fechas
» Datos complejos: imágenes, sonidos
5. Diseño Lógico
> Modelo Relacional
> Sentencias SQL: Create Table
CREATE TABLE nombre_tabla
(
nombrecolumna1 tipodato1,
……..
nombrecolumnaN tipodatoN,
PRIMARY KEY (nombrecolumna_clave),
FOREIGN KEY (nombrecolumna_clave)
REFERENCES
TABLA2 (nombrecolumna_clave_tabla2)
)
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
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.
5. Diseño Lógico
> Modelo Relacional
5. Diseño Lógico
> Modelo Relacional
Las descripciones deben ser gestionados por medio
de herramientas CASE disponibles
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).
5. Diseño Lógico
> Modelo Relacional
> Dominio de un atributo: 1. Tipo 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
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
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
7. Conclusión
La verdadera
innovación
comienza en
el diseño
Tim Brown.

Proceso Del Diseño e Implementación de Una Base de Datos - 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proceso Del Diseño e Implementación de Una Base de Datos - 2

Cargado por

Copyright:

Formatos disponibles

DISEÑO E IMPLEMENTACIÓN

Facultad de Ciencias de la Ingeniería

Proceso del diseño e Implementación

Proceso de Diseño de Base de Datos

Proceso comprimido de Diseño de BDD

CONCEPTUAL E-R NO E-R NO

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

• Una estrategia para dividir la información en tablas

Basado en los textos:

Nota: La Conectividad es denominada también como Cardinalidad

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

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

> Las interrelaciones ternarias pueden tener cuatro

La relación “Dirige” tiene

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

> Factores Técnicos

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

La relación (tabla) que se obtiene

La relación (Tabla) que

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

Las interrelaciones M:N se traducen en

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

Esquema lógico específico Estructura interna (Esquema

También podría gustarte