DIS Diseño de Base de Datos 2002

DISEÑO DE BASES DE DATOS
Diseño de Bases de Datos
1. CONCEPTOS SOBRE BASE DE DATOS RELACIONALES
Una base de datos relacional es percibida por el usuario como una colección de relaciones en
tablas bi-dimensionales.
Por ejemplo, la siguiente tabla relacional contiene datos de empleados:
Tabla: EMPLEADO
EMPLEADO_NRO APELLIDO NOMBRE DEPTO_CODIGO
100 LOPEZ JUAN 10

310 FERNANDEZ MARIA 15
210 BROWN JOSE 10
405 GOMEZ DANIEL 12
378 JOHNSON LUCIA 25
tabla (relación)
fila (tupla)
columna (atributo)
1.1. CLAVES PRIMARIAS (PK)
Una Clave Primaria (Primary Key) es una columna o conjunto de columnas que identifica
unívocamente a cada fila de la tabla. Cada tabla debe tener una clave primaria, la cual debe ser
única para cada tupla.
La clave primaria para la anterior tabla EMPLEADO es la columna EMPLEADO_NRO. Cada fila
de la tabla es unívocamente identificada por su valor de EMPLEADO_NRO.
Una clave primaria que consta de múltiples columnas es llamada Clave Primaria Compuesta.
Por ejemplo, la clave primaria compuesta para la tabla CUENTA consiste en una combinación
de las columnas BANCO_NRO y CUENTA_NRO. Cada fila de la tabla es unívocamente
identificada por los valores de BANCO_NRO y CUENTA_NRO.
Tabla: CUENTA
BANCO_NRO CUENTA_NRO SALDO FECHA_APERTURA
104 75760 12.000,50 21/10/1989
104 77956 100,10
105 89570 55.755,00 15/01/1985
103 55890 15.001,85 10/03/1971
105 76954 5,00 25/09/1991
Clave Primaria
Los valores de una clave primaria compuesta deben ser combinaciones únicas para cada tupla,
aunque los valores de cada columna puedan ser duplicados.
Ninguna parte de la clave primaria debe ser nula.
2
De tal modo, como EMPLEADO_NRO es la clave primaria de EMPLEADO, entonces debe ser
definido como NO NULO.
Lo propio ocurre con BANCO_NRO y CUENTA_NRO para la tabla CUENTA.
Una tabla puede tener mas de una columna o combinación de columnas que pueden servir
como claves primarias de la tabla. Cada una de ellas es llamada Clave Candidata.
Por ejemplo, para la siguiente tabla EMPLEADO las Claves Candidatas son EMPLEADO_NRO
y LIQUIDACION_CODIGO:
Tabla: EMPLEADO
EMPLEADO_ APELLIDO NOMBRE DEPTO_ LIQUIDACION_

NRO CODIGO CODIGO
100 LOPEZ JUAN 10 9710
310 FERNANDEZ MARIA 15 8730
210 BROWN JOSE 10 1157
405 GOMEZ DANIEL 12 3394
378 JOHNSON LUCIA 25 4477
Si se selecciona una clave candidata para ser Clave Primaria, por ejemplo
EMPLEADO_NUMERO, la otra clave candidata será una Clave Alternativa
(LIQUIDACION_CODIGO).
Todas las Claves Candidatas deben ser Unicas y No Nulas.
Los nombres y apellidos de personas normalmente no son claves Candidatas porque no está
garantizado que sean únicos.
1.2. CLAVES EXTERNAS (FK)
Una Clave Externa (Foreign Key) es una columna o combinación de columnas de una tabla,
que referencia a una clave primaria en la misma u otra tabla.
Por ejemplo, DEPTO_CODIGO es una FK en la siguiente tabla EMPLEADO, y referencia a los

valores de la columna DEPTO_NRO de la tabla DEPARTAMENTO:
3
Clave Primaria Clave Externa
Tabla: EMPLEADO
EMPLEADO_ APELLIDO NOMBRE DEPTO_ LIQUIDACION_

NRO CODIGO CODIGO
100 LOPEZ JUAN 10 9710
310 FERNANDEZ MARIA 15 8730
210 BROWN JOSE 10 1157
405 GOMEZ DANIEL 3394
378 JOHNSON LUCIA 25 4477
Clave Primaria
Tabla: DEPARTAMENTO
DEPTO_CODIGO DEPTO_NOMBRE
10 FINANZAS
15 OPERACIONES
12 PRODUCCION
25 VENTAS
Las FK son usadas para unir tablas.
Una FK debe concordar con un valor existente de clave primaria, o de lo contrario debe
ser NULA.
La FK DEPTO_CODIGO en la tabla EMPLEADO refiere a los valores de la PK

DEPTO_CODIGO en la tabla DEPARTAMENTO.
Clave Primaria Clave Externa Clave Primaria
EMPLEADO_ APELLIDO DEPTO_ DEPTO_ DEPTO_

NRO CODIGO CODIGO NOMBRE
100 ROJAS 10 10 FINANZAS
310 ADAMS 15 15 OPERACIONES
210 BROWN 10 20 PRODUCCION
405 GOMEZ 25 VENTAS
Tabla: EMPLEADO Tabla: DEPARTAMENTO
Si una FK es parte de una PK, entonces la FK no debe ser NULA.
Por ejemplo, en la tabla CUENTA la FK BANCO_NRO debe ser NO NULA porque es parte de
la PK..
4
Clave Primaria Clave Externa Clave Primaria
BANCO_NRO BANCO_ BANCO_NRO CUENTA_ SALDO

NOMBRE NRO
104 CITY 104 75760 12.000,50
150 PROVINCIA 104 77956 100,10
103 ROBERTS 150 89570 55.775,00
105 NACION 103 33347 15.001,85
105 76954 5,00
Tabla: BANCO Tabla: CUENTA
1.3. INTEGRIDAD DE LOS DATOS
La integridad de los datos se refiere a la exactitud y consistencia de los datos.
Las restricciones de integridad de los datos aseguran que los usuarios realicen solamente
operaciones que mantengan a la base de datos en estado consistente.
Tipo de restricción: Significado:
Integridad de Entidades Ninguna parte de una Clave Primaria puede ser NULA.
Integridad Referencial Una Clave Externa debe concordar con un valor de Clave
Primaria existente o de lo contrario ser NULA.
Integridad de Columnas Una columna debe contener solo valores consistentes con el
formato de datos definido para la misma.
Integridad de Definiciones Los datos almacenados en una base de datos deben cumplir
del Usuario los requerimientos de la organización.
Los requerimientos de la organización (las “reglas del negocio”) pueden determinar también
el correcto estado de la base de datos. Tales requerimientos son llamados Restricciones de
Integridad de Datos Definidas por los Usuarios.
Por ejemplo, una organización puede tener las siguientes restricciones de integridad de datos
definidas por los usuarios:
- Un empleado jerárquico no debe percibir horas extras.
- Una comisión por ventas no puede exceder el 50% del salario básico.
5
2. DISEÑO DE BASE DE DATOS
El Diseño de Base de Datos es realizado durante la etapa de DISEÑO dentro del ciclo de
desarrollo de un sistema, en forma paralela con el diseño de la aplicación, y a partir de las
definiciones producidas en el Diccionario de Datos como resultado de la etapa de ANALISIS del
sistema.
El diseño de la base de datos es realizado en dos grandes actividades, cada una de las cuales
incluye distintos pasos:
ACTIVIDAD 1.
Mapeo del Modelo DER a tablas relacionales para producir un diseño inicial.
Pasos:
1.1. Mapeo de cada entidad simple en una tabla.
1.2. Mapeo de los atributos en las columnas de la tabla y documentación de datos ejemplo.
1.3. Mapeo de los identificadores únicos en claves primarias.
1.4. Mapeo de las relaciones en claves externas.
1.5 Mapeo de Relaciones Excluyentes.
1.6 Mapeo de Subtipos y Supertipos
1.7. Normalización de las tablas.
ACTIVIDAD 2.
Refinamiento del diseño inicial para producir un completo diseño de la base de datos.
Pasos:
2.1. Definición de las restricciones de integridad referencial.
2.2. Diseño de índices.
2.3. Establecimiento de vistas.
2.4. Desnormalización del diseño de la base de datos.
2.5. Planificación del uso del espacio físico.
En resumen, la etapa de diseño de base de datos a partir del modelo DER produce
especificaciones de diseño para base de datos relacional incluyendo definición de tablas
relacionales, índices, vistas y espacios físicos.
6
ACTIVIDAD 1: Mapeo del DER a tablas relacionales para producir un diseño inicial.
Cada relación se documenta mediante una Tabla.
Tabla: EMPLEADO
COLUM EMPL_ APELLI NOM- PUESTO INGRE SUEL- SALA- SUPER DEPTO
NA NRO DO BRE SO DO RIO VISOR _NRO
TIPO
CLAVE PK FK1 FK2
NULO/
UNICO NN,U NN NN NN NN
DATOS 7369 ARIAS MARIA CADETE 17/12/80 800 100 7902 20
EJEM- 7902 SMITH DANIEL ANALISTA 03/12/81 3.000 80 7566 50
PLO 7521 REY JULIO VENDEDOR 22/02/81 1.250 7698 30
7698 DIAZ RAUL GERENTE 01/05/81 2.850 50 7839 30
7839 RUIZ DANIEL PRESIDENTE 12/11/81 5.000 10
• Los tipos de clave válidos son PK para Clave Primaria y FK para Clave Externa.
• Se utilizan números para distinguir entre múltiples FK en una misma tabla, por ejemplo FK1
y FK2.
• Una columna definida como NO NULA se indica con NN.
• Una columna definida como UNICA se indica con U.
• Toda columna PK simple debe indicarse como NN,U.
Para ejemplificar los pasos de la ACTIVIDAD 1 se utilizará el siguiente DER:
ALISTAMIENTO
*fecha de inscripción
o
fecha de finalización
o
calificación
para para
inscripto tomado
en por
ESTUDIANTE CURSO
#*número #*código
*apellido *nombre
o
*nombre precio
o o
teléfono duración
dictado por
docente en
INSTRUCTOR
#*código
*apellido
*nombre
o
teléfono
7
Paso 1.1: Mapeo de cada Entidad simple en una Tabla:
Crear una Tabla para cada Entidad Simple (no subtipos ni supertipos) , llamándola con idéntico
nombre.
Tabla: INSTRUCTOR
COLUM-
NA
TIPO
INSTRUCTOR CLAVE
NULO/
UNICO
DATOS
EJEM-
PLO
Paso 1.2.: Mapeo de los atributos en las columnas de la tabla y documentación de datos
ejemplo.
Mapear cada atributo en una columna de la Tabla de la Entidad, indicando a los atributos
mandatorios como NO NULOS (NN).
Documentar filas con datos ejemplo en la Tabla.
Tabla: INSTRUCTOR
COLUM- CODI APELLI NOM TELE
NA GO DO BRE FONO
TIPO
INSTRUCTOR CLAVE
#*código NULO/
*apellido UNICO NN NN NN
*nombre DATOS 10 ROSAS JUAN 292251
ºteléfono EJEM- 81 PEREZ MARIA 564891
PLO 73 RIVAS LUCIA 312291
95 RIOS DANTE 839221
301 ALVEZ LUCAS 533166
• Los nombres de columna deben ser fácilmente referenciables a los nombres de los
atributos.
8
Paso 1.3.: Mapeo de los identificadores únicos en claves primarias.
Mapear el/los atributo/s que son parte del Identificador Unico (IU) de la Entidad como Clave
Primaria (PK), indicándolo en la/s columna/s correspondiente/s.
Tabla: INSTRUCTOR
COLUM- CODI APELLI NOM TELE
NA GO DO BRE FONO
TIPO
INSTRUCTOR CLAVE PK
#*código NULO/
*apellido UNICO NN,U NN NN
*nombre DATOS 10 ROSAS JUAN 292251
ºteléfono EJEM- 81 PEREZ MARIA 564891
PLO 73 RIVAS LUCIA 312291
95 RIOS DANTE 839221
301 ALVEZ LUCAS 533166
• Todas las columnas indicadas como PK también deben ser NN y U.
Si en el IU de una Entidad está incluida una o más relaciones, se deben adicionar a la tabla las
columnas de Clave Externa e indicarlas como parte de la Clave Primaria.
ALISTAMIENTO CURSO
*fecha inscripción para #*código
ºfecha finalización *nombe
ºcalificación tomado ºprecio
por ºduración
para
inscripto en Tabla: ALISTAMIENTO

COLUM FECHA_ FECHA_ CALIFI CURSO_ ESTUD_
NA INSCRI FINAL CACION COD NRO
ESTUDIANTE TIPO
#*numero CLAVE PK,FK1 PK,FK2
*apellido NULO/
*nombre UNICO NN NN,U1 NN,U1
ºteléfono DATOS 20/07/91 29/07/91 344 47593
EJEM- 05/09/91 401 15402
PLO 14/06/91 28/06/91 A 717 51394
08/05/91 28/06/91 B 717 94572
05/05/91 21/05/91 A 401 51394
• Las Claves Primarias compuestas deben ser valores de combinaciones únicos, por lo tanto
se indicará con U1 en cada columna.
9
Paso 1.4.: Mapeo de las relaciones en claves externas.
Para relaciones M:1, adicionar la PK de la Entidad UNO de la relación a la tabla de la Entidad

MUCHOS de la relación.
CURSO dictado INSTRUCTOR

#*código por #*número
*nombre *apellido
*precio docente *nombre
*duración en ºteléfono
Tabla: CURSO
COLUMNA CURSO_COD NOMBRE PRECIO DURACION INSTR_NUM
TIPO CLAVE PK FK
NULO/UNICO NN.U NN NN NN
DATOS 344 SQL 500 5 81
EJEMPLO 974 DISEÑO BD 600 6 73
401 DBA 400 3 95
717 DER 400 3 73
659 CASE 800 7 301
• Para las relaciones debe ser, las columnas FK se indican como NN.
• Si la PK de una Tabla comprende Claves Externas, las columnas FK correspondientes a la

relación deben haber sido adicionadas tal como se indicó en el Paso 1.3.
Para relaciones 1:1 mandatorias, se adiciona la única FK en la Tabla correspondiente a la

Entidad mandatoria y se indica NO NULA para imponer dicha condición.
COMPUTADORA MOTHERBOARD
#*número de serie integrada por #*código
*tipo de gabinete *procesador
*marca incorporada *mhz
en *coprocesador
Tabla: COMPUTADORA Tabla: MOTHERBOARD

COLU SERIE GABIN MARC MB_ COLU MB_ PRO NHZ COPR
MNA _NRO ETE A COD MNA COD CES OCES
TIPO TIPO
CLAV PK FK CLAV PK
E E
NULO/ NULO/
UNICO NN,U NN NN NN,U UNICO NN,U NN NN NN
DATO 1045 H HP 4579 DATO 9978 486 66 N
EJEM 0437 T HP 8731 EJEM 4517 386 40 S
PLO 1458 T CP 4773 PLO 4773 486 66 N
1223 MT EP 9978 4579 586 133 N
1088 MT IBM 4517 8731 486 33 S
10
• La FK para relaciones 1:1 mandatorias siempre debe ser UNICA (U), pero no permite
valores NULOS (NN)
Si una relacion 1:1 es opcional en ambas direcciones, adicionar la FK indistintamente en una

de las Tablas.
DARSENA ocupada por BARCO

#*número #*matricula
*tamaño amarrado en #*pais
*nombre
ºtipo
Tabla: DARSENA Tabla: BARCO

COLUM DARS_ TAMA- COLUM MATRI PAIS NOMB TIPO DARS_
NA NUM ÑO NA CULA RE NUM
TIPO TIPO
CLAVE PK CLAVE PK PK FK
NULO/ NULO/
UNICO NN,U NN UNICO NN,U1 NN,U1 NN U
DATOS 344 100 DATOS 134X89 BRASIL REY CRUCE 554
EJEM 075 1000 EJEM 044557 CHILE ANDES CRUCE 570
PLO 554 500 PLO TH4088 EEUU SUN CARGA 075
341 80 YL9984 EEUU MOON YACHT 344
570 600 345CI9 ARGEN SONIA YACHT 341
Para relaciones recursivas 1:M, adicionar una columna FK a la única Tabla. Esta FK hace
referencia a los valores de la columna PK.
supervisor de
EMPLEADO
#*número
*apellido
*nombre supervisado por
Tabla: EMPLEADO
COLUMNA EMPL_NRO APELLIDO NOMBRE SUPERV_NRO
TIPO CLAVE PK FK
NULO/UNICO NN, U NN NN
DATOS 7450 GONZALEZ MARIA
EJEMPLO 5579 DIAZ DANIEL 7450
6714 MERLO JUAN 5579
9451 RUIZ JOSE 7450
3040 SMITH ESTEBAN 9451
• La columna FK hace referencia a una fila (registro) de la misma Tabla.
• El nombre de la columna FK debe reflejar la relación.
11
• Una FK recursiva nunca debe ser NO NUL A (NN).
Para relaciones recursivas 1:1, adicionar una FK UNICA (U) a la tabla. Esta FK debe hacer
referencia a los valores de la columna PK.
conyuge de
PERSONA
#*documento nro.
*apellido casado con
*nombre
Tabla: PERSONA
COLUMNA PERS_DOCNRO APELLIDO NOMBRE CONY_DOCNRO
TIPO CLAVE PK FK
NULO/UNICO NN,U NN NN U
DATOS 12345337 RODRIGUEZ DANIEL
EJEMPLO 23456723 DOMINGUEZ JUAN 06758497
06758497 SMITH MIRTA 23456723
11908974 ROBLES JUANA 09099876
09099876 JOHNSON RAUL 11908974
• La combinación de columnas PK y FK siempre debe ser única a fin de asegurar la relación

1:1. Para garantizarlo se requiere que tanto PK como FK sean UNICO (U).
Paso 1.5: Mapeo de Relaciones Excluyentes.
Las relaciones excluyentes, representadas por arcos, son una multiple alternativa de Clave
Externa. Puede elegirse entre dos formas distintas de diseño para mapear los arcos en Claves
externas:
- Diseño Explícito de Arcos
- Diseño Genérico de Arcos.
12
El Diseño Explícito de Arcos crea una columna de Clave Externa por cada relación incluida en
el arco:
poseida por PERSONA

CUENTA #*documento
#*número poseedor de
#*tipo
poseida por SOCIEDAD
#*código
poseedor de
poseida por
EMPRESA
poseedor de # *número
Tabla: CUENTA
COLUMNA CTA_NRO TIPO PERS_DOC SOC_COD EMPR_NUM
TIPO CLAVE PK PK FK1 FK2 FK3
NULO/UNICO NN,U1 NN,U1
DATOS 1024 1 12330045
EJEMPLO 0512 2 B4431
0977 2 22545323
1031 1 10844
2371 2 54101
• El Diseño Explícito de Arcos soporta múltiples FK con diferentes formatos . Por ejemplo,
PERS_DOC, SOC_COD y EMPR_NUM tienen distinto formato de columna.
• El software de aplicación debe controlar que la relación sea exclusiva entre las FK.
El Diseño Genérico de Arcos crea una sola columna FK y una columna para codificar las
relaciones del arco. Dado que las relaciones son exclusivas, solo un valor de FK existirá en
cada registro de la tabla.
poseida por PERSONA

CUENTA #*número
#*número poseedor de
#*tipo
poseida por SOCIEDAD
#*número
poseedor de
poseida por
EMPRESA
poseedor de # *número
13
Tabla: CUENTA
COLUMNA CTA_NRO TIPO POSE_NUM POSE_TIPO
TIPO CLAVE PK PK FK
NULO/UNICO NN,U1 NN,U1 NN NN
DATOS 1024 1 12330 P
EJEMPLO 0512 2 44431 S
0977 2 22545 P
1031 1 10844 E
2371 2 54101 E
• Si las relaciones bajo el arco son mandatorias, ambas columnas adicionadas deben ser NO
NULO (NN).
• Las FK deben compartir el mismo formato para todas las tablas referenciadas.
• El control de exclusividad de las relaciones es realizado automaticamente.
Paso 1.6: Mapeo de Subtipos y Supertipos
El mapeo de Subtipos y Supertipos a Tablas puede realizarse en tres formas distintas:
- Diseño en Tabla Simple
- Diseño en Tablas Separadas
- Implementación por diseño de arcos (paso 1.5)
Diseño en Tabla Simple:
Se mapean los subtipos en la misma tabla que el supertipo. La misma tabla contendrá
instancias para todos los subtipos.
A TABLA
B A
Se utiliza una sola tabla para el diseño cuando los subtipos tienen pocos atributos específicos y
relaciones.
El diseño se realiza cumpliendo los siguientes pasos :
1. Crear una Tabla para el Supertipo.
14
2. Crear una columna TIPO para identificar cual Subtipo pertenece cada fila.
3. Crear una columna para cada atributo de los Subtipos.
4. Crear columnas FK para cada relación del Supertipo.
5. Crear columnas FK para cada relación de los Subtipos.
EMPLEADO #*número
*apellido
*nombre
EMPLEADO EMPLEADO
MENSUALIZADO JORNALIZADO
*salario *valor hora normal
*valor hora extra
miembro de
asignado a
compuesto por compuesto por
DEPARTAMENTO AGREMIACION
#*código #*número
Tabla: EMPLEADO
COLUM EMP_ APELLID NOMB EMP_ MENS_ JOR_ JOR_ JOR_ DPTO_
NA NUM O RE TIPO SALAR VALHN VALHE AGRE COD
M
TIPO
CLAVE PK FK1 FK2
NULO/
DATOS 4579 LOPEZ DANIEL M 500 40
EJEM 6631 SMITH JUANA M 600 35
PLO 1190 DIAZ RAUL M 400 40
370 ROBLE DIANA M 1.000 30
800 GOMEZ JULIA M 2.000 35
7147 ROCA JOSE J 8,50 12,75 201 35
6794 SANTO JUAN J 6,75 11,50 150 30
941 DENIS RAUL J 12,00 18,00 201 45
1020 CAMPO ROSA J 9,50 16,15 201 30
3560 REY DINO J 10,50 15,75 180 45
Las columnas de la Tabla EMPLEADO se derivan de los atributos y relaciones del Supertipo y
de todos sus Subtipos.
15
TIPO DE ENTIDAD COLUMNAS PARA COLUMNAS FK PARA

ATRIBUTOS RELACIONES
Supertipo EMP_NUM, APELLIDO DPTO_COD
NOMBRE
Subtipo MENS_SALAR, JOR_VALHN, JOR_AGREM

JOR_VALHE
• El diseño de Subtipos en Tabla simple requiere que una nueva columna TIPO sea creada
para identificar cada fila del Subtipo. La columna EMP_TIPO fue adicionada a la Tabla
EMPLEADO para este propósito.
Las ventajas de este tipo de diseño son:
El acceso a los Supertipos es directo.
Los Subtipos pueden ser accedidos y modificados usando vistas.
Como desventajas pueden señalarse:
Requerimiento de NO NULO (NN) del Subtipo no pueden ser forzados a nivel de la base de
datos.
La lógica de las aplicaciones deberá referirse a diferentes conjuntos de atibutos dependiendo

del TIPO.
Diseño en Tablas Separadas:
Se mapean los Subtipos en Tablas separadas, una por cada Subtipo. Cada Tabla contiene
solamente instancias del Subtipo al cual pertenece.
A TABLA
B B
TABLA
C
Pasos para el diseño:
1. Crear una Tabla para cada Subtipo.
16
2. En cada Tabla de Subtipo, crear columnas para sus atributos.
3. En cada Tabla de subtipo, crear columnas para los atributos del Supertipo.
4. En cada Tabla de Subtipo, crear columnas FK para sus relaciones.
5. En cada Tabla de Subtipo, crear columnas FK para las relaciones del Supertipo.
EMPLEADO #*número
*apellido
*nombre
EMPLEADO EMPLEADO
MENSUALIZADO JORNALIZADO
*salario *valor hora normal
*valor hora extra
miembro de
asignado a
compuesto por compuesto por
DEPARTAMENTO AGREMIACION
#*código #*número
Tabla: EMPLEADO_MENSUALIZADO
COLUM EMP_ APELLI NOMB MENS_ DPTO_
NA NUM DO RE SALAR COD
TIPO
CLAVE PK FK
NULO/
DATOS 4579 LOPEZ DANIEL 500 40
EJEM 6631 SMITH JUANA 600 35
PLO 1190 DIAZ RAUL 400 40
370 ROBLE DIANA 1.000 30
800 GOMEZ JULIA 2.000 35
17
Tabla: EMPLEADO_JORNALIZADO
COLUM EMP_ APELLI NOMB JOR_ JOR_ JOR_ DPTO_
NA NUM DO RE VALHN VALHE AGREN COD
TIPO
CLAVE PK FK1 FK2
NULO/
UNICO NN,U NN NN NN NN NN NN
DATOS 7147 ROCA JOSE 8,50 12,75 201 35
EJEM 6794 SANTO JUAN 6,75 11,50 150 30
PLO 941 DENIS RAUL 12,00 18,00 201 45
1020 CAMPO ROSA 9,50 16,15 201 30
3560 REY DINO 10,50 15,75 180 45
Usar un diseño de Subtipos en Tablas separadas cuando haya muchos atributos específicos de
subtipo o relaciones.
Sus ventajas son:
La opcionalidad de los atributos de los Subtipos puede forzarse a nivel de la base de datos.
La lógica de las aplicaciones no requiere controles por Subtipos.
Y sus desventajas:
El acceso al Supertipo requiere del operador UNION o de una vista con el operador UNION.
El código de los programas de aplicación debe ser específico sobre la Tabla individual del
Subtipo.
El mantenimiento de Identificadores Unicos cruzados a través de Subtipos es dificultoso de

implementar.
Paso 1.7 : Normalización de las Tablas
Primera Forma Normal (1FN):

La Tabla no debe contener grupos repetitivos.
Segunda Forma Normal (2FN):

La tabla debe estar en 1FN. Toda columna NO CLAVE deber estar dependiendo de todas las
partes de la Clave Primaria.
Tercera Forma Normal (3FN):

La tabla debe estar en 2FN. Ninguna columna NO CLAVE debe ser funcionalmente
dependiente de otra columna NO CLAVE.
• La normalización minimiza la redundancia de datos.
• La redundancia de datos causa problemas de integridad. Las transacciones de actualización

y eliminación pueden no ser consistentemente realizadas sobre todas las copias de los
datos, causando inconsistencias en los mismos.
• La normalización ayuda a descubrir entidades “ocultas”, relaciones y Tablas.
18
• La 3FN es una meta aceptada para eliminar la redundancia en el diseño de bases de datos.
Reconocimiento de datos desnormalizados
Los datos desnormalizados no cumplen con las reglas de normalización. Por ejemplo el
siguiente conjunto de datos:
Tabla: PEDIDO
PEDIDO FECHA CLI_ CLI_NO PROVIN ITEM_ ITEM_ CANTI- PRECIO
_NRO NRO MBRE CIA CODIGO DESCR DAD
2301 23/06 101 Perez BS.AS. 3876 red 3 35.00
4011 raqueta 6 65,00
9132 pelotax 3 8 4,75
2302 25/06 107 Sports STA.FE 5796 pelotax 6 4 5,00
2303 26/06 110 Diaz CORD 4011 raqueta 2 65,00

3141 funda 2 10,00
Contiene grupos repetitivos de ITEM_CODIGO, ITEM_DESCR, CANTIDAD y PRECIO.

No cumple con la Primera Forma Normal.
Conversión a Primera Forma Normal
1. Se eliminan los grupos repetitivos de la Tabla base.
2. Se crean nuevas Tablas con la PK de la Tabla base y el grupo repetitivo.
Por ejemplo, sobre la anterior Tabla desnormalizada:
Se eliminan los grupos repetitivos de ITEM_CODIGO, ITEM_DESCR, CANTIDAD y PRECIO.

La PK de la Tabla remanente (PEDIDO) es PEDIDO_NRO. Se crea una nueva Tabla llamada
PEDIDO_ITEM con PEDIDO_NRO y el grupo repetitivo.
Tabla: PEDIDO
PEDIDO FECHA CLI_ CLI_NO PROVIN
_NRO NRO MBRE CIA
PK
2301 23/06 101 Perez BS.AS.
2302 25/06 107 Sports STA.FE
2303 26/06 110 Diaz CORD
19
Tabla: PEDIDO_ITEM
PEDIDO ITEM_ ITEM_ CANTI- PRECIO
_NRO CODIGO DESCR DAD
PK,FK PK
2301 3876 red 3 35.00
2301 4011 raqueta 6 65,00
2301 9132 pelotax 3 8 4,75
2302 5796 pelotax 6 4 5,00
2303 4011 raqueta 2 65,00
2303 3141 funda 2 10,00
Conversión a Segunda Forma Normal
1. Determinar cuales columna NO CLAVE no dependen de la totalidad de la Clave Primaria de

la tabla.
2. Eliminar esas columnas de la Tabla base.
3. Crear una segunda Tabla con esas columnas y la/s columna/s de la PK de las cuales
dependen.
Por ejemplo, la anterior Tabla PEDIDO_ITEM no está en 2FN dado que PRECIO e
ITEM_DESCR dependen de ITEM_CODIGO pero no de PEDIDO_NRO.
Para convertir la Tabla a 2FN se remueven las columnas parcialmente dependientes, creando
una Tabla ITEM con esas columnas y las de PK de las cuales dependen.
Tabla: PEDIDO_ITEM Tabla: ITEM

PEDIDO ITEM_ CANTI- ITEM_ ITEM_ PRECIO
_NRO CODIGO DAD CODIGO DESCR
PK,FK PK,FK PK
2301 3876 3 3876 red 35.00
2301 4011 6 4011 raqueta 65,00
2301 9132 8 9132 pelotax 3 4,75
2302 5796 4 5796 pelotax 6 5,00
2303 4011 2 3141 funda 10,00
2303 3141 2
Conversión a Tercera Forma Normal
1. Determinar cuales columnas son dependientes de otra columna NO CLAVE.
2. Remover esas columnas de la Tabla base.
3. Crear una segunda Tabla con esas columnas y la columna NO CLAVE de la cual dependen.
Por ejemplo, la Tabla PEDIDO resultante de la 1FN no esta en 3FN porque CLI_NOMBRE y
PROVINCIA dependen de CLI_NRO, el cual no es PK.. Se crea la Tabla CLIENTE.
20
Tabla: PEDIDO Tabla: CLIENTE

PEDIDO FECHA CLI_ CLI_ CLI_NO PROVIN
_NRO NRO NRO MBRE CIA
PK FK PK
2301 23/06 101 101 Perez BS.AS.
2302 25/06 107 107 Sports STA.FE
2303 26/06 110 110 Diaz CORD
• Ninguna columna NO CLAVE puede ser funcionalmente dependiente de otra columna NO

CLAVE.
• Todos los atributos NO CLAVE son dependientes de la Clave Primaria, de toda la Clave
Primaria y de nada más que la Clave Primaria.
ACTIVIDAD 2. Refinamiento del diseño inicial para producir un completo diseño de la

base de datos.
Paso 2.1: Definición de las restricciones de integridad referencial.
Un valor de la columna de Clave Externa (FK) debe corresponderse con un valor existente en
columna de Clave Primaria (PK) o sino debe ser NULO.
Las restricciones de integridad referencial se usan para especificar como mantener la

integridad referencial de las Tablas.
Restricción de borrado: Qué sucede si una fila conteniendo una Clave Primaria referenciada es
borrada?
Restricción de actualización: Qué sucede si una Clave Primaria referenciada es modificada?.
Las especificaciones de restricción de borrado definen que deberá suceder si una fila que
contiene un Clave Primaria referenciada es borrada.
Opciones: CASCADA, RESTRINGIDO o NULIFICACION (solo si NULOs son permitidos).
Por ejemplo, considerando las siguientes Tablas EMPLEADO y DEPARTAMENTO, qué

deberá suceder si un DPTO_NRO en el cual trabajan los empleados es borrado de la Tabla
DEPARTAMENTO?
21
Tabla: EMPLEADO Tabla: DEPARTAMENTO

COLUM- EMPL_ EMP_APE DPTO_ COLUM- DPTO_ DPTO_
NA NRO LLIDO NRO NA NRO NOMBRE
TIPO TIPO
CLAVE PK FK CLAVE PK
NULO/ NULO/
UNICO NN,U NN UNICO NN,U NN
DATOS 100 SMITH 10 DATOS 10 Contable
EJEMPLO 310 GOMEZ 30 EJEMPLO 20 Desarrollo
210 DIAZ 20 30 Ventas
405 BLANCO 40 Finanzas
378 PEREZ 50 50 Operacion
OPCION EXPLICACION DE LA RESTRICCION
CASCADA El borrado deberá ser en cascada sobre los

empleados que concuerden. Las filas de
EMPLEADO que concuerden también deberán
ser borradas.
RESTRINGIDO El borrado deberá ser restringido sólamente a

DEPARTAMENTOs sin empleados.
NULIFICACION La Clave Externa deberá ser nulificada (válido

sólamente para FKs que permiten NULOs)
cuando la PK referenciada es borrada.
Las especificaciones de restricción de actualización definen qué deberá suceder cuando

una Clave Primaria referenciada es modificada. (Esto es válido sólo si la PK es modificable).
Opciones: CASCADA, RESTRINGIDO o NULIFICACION (sólo si NULOs son permitidos).
Tomando el mismo ejemplo anterior, qué deberá suceder si un DPTO_NRO en el cual trabajan
los empleados es cambiado por otro DPTO_NRO?
OPCION EXPLICACION DE LA RESTRICCION
CASCADA La modificación deberá ser en cascada sobre

los empleados que concuerden. Las filas de
EMPLEADO que concuerden también deberán
ser modificadas reflejando el nuevo valor de
PK.
RESTRINGIDO La modificación deberá ser restringida

sólamente a DEPARTAMENTOs sin
empleados.
NULIFICACION La Clave Externa deberá ser nulificada (válido

sólamente para FKs que permiten NULOs)
cuando la PK referenciada es modificada por
un nuevo valor de PK.
22
Paso 2.2: Diseño de Indices
Un índice está asociado con una sola tabla física y contiene los valores de una o más columnas
de esa tabla.
Diseño de base de datos - Tabla relacional:
Tabla: CURSO
COLUMNA CURSO_COD NOMBRE PRECIO DURACION INSTR_COD
TIPO CLAVE PK FK
NULO/UNICO NN.U NN NN NN NN
DATOS 344 SQL 500 5 81
EJEMPLO 974 DISEÑO BD 600 6 73
401 DBA 400 3 95
717 DER 400 3 73
659 CASE 800 7 301
Representación física:
Tabla: CURSO
RECNO CURSO_COD NOMBRE PRECIO DURACION INSTR_COD
1010 344 SQL 500 5 81
1011 974 DISEÑO BD 600 6 73
1012 401 DBA 400 3 95
1013 717 DER 400 3 73
1014 659 CASE 800 7 301
I_CURSOS_1 Indice I_CURSOS_2 Indice

(Unico) (No Unico)
CURSO_COD RECNO INSTR_COD RECNO
344 1010 73 1011
401 1012 73 1013
659 1014 81 1010
717 1013 95 1012
974 1011 301 1014
El uso de índices mejora significativamente el tiempo de acceso a los datos, proporcionando

rápido acceso a los registros, evitando revisar toda la Tabla. También facilitan la unión de
tablas.
Un índice concatenado es un índice creado de un grupo de columnas de una sola Tabla. Una
Clave Compuesta se mapea mediante un índice concatenado.
23
Por ejemplo:
Tabla de diseño:
Tabla: ALISTAMIENTO
COLUM FECHA_ FECHA_ CALIFI CURSO_ ESTUD_
NA INSCRI FINAL CACION COD NRO
TIPO
CLAVE PK,FK1 PK,FK2
NULO/
UNICO NN NN,U1 NN,U1
DATOS 20/07/91 29/07/91 344 47593
EJEM- 05/09/91 401 15402
PLO 14/06/91 28/06/91 A 717 51394
08/05/91 28/06/91 B 717 94572
05/05/91 21/05/91 A 401 51394
Tabla física:
Tabla: ALISTAMIENTO
RECNO FECHA_ FECHA_ CALIFI CURSO_ ESTUD_
INSCRI FINAL CACION COD NRO
5011 20/07/91 29/07/91 344 47593
5012 05/09/91 401 15402
5015 14/06/91 28/06/91 A 717 51394
5013 08/05/91 28/06/91 B 717 94572
5014 05/05/91 21/05/91 A 401 51394
I_ALISTAMIENTO_1 Indice
(Unico)
CURSO_ ESTUD_ RECNO
COD NRO
344 47593 5011
401 15402 5012
401 51394 5014
717 51394 5015
717 94572 5013
Se usan índices para implementar claves y soportar los requerimientos de acceso de las
aplicaciones.
Construir índices para:
• Claves Primarias (índices únicos)
• Claves Externas (generalmente índices no-únicos)
Considerar índices para:
• Claves Alternativas (índices únicos)
• Columnas no-clave críticas para ubicar registros.
• Claves de búsqueda
24
Además:
• Los índices adicionan almacenamiento y actualización.
• Un índice único referencia una columna o un conjunto de columnas que tienen valores
únicos en la Tabla.
• Un índice no-único referencia un columna o un conjunto de columnas que son no-únicas en

la Tabla.
Paso 2.3. : Establecimiento de vistas
El establecimiento de vistas contribuye con los requerimientos de acceso de las aplicaciones.
Las vistas pueden ser usadas para:
• restringir accesos.
• presentar Tablas a los usuarios en distintas formas.
• producir prototipos rápidamente
• chequer el ingreso de datos
Una vista puede ser considerada como una ventana predefinida sobre la base de datos. No
tiene datos propios y refleja información desde otras Tablas. Es consultada como si fuese una
Tabla.
Una vista puede restringir lo que el usuario ve. Por ejemplo, un vista debe ser usada para
restringir a los usuarios la visión de los sueldos de la Tabla EMPLEADO:
Tabla base Vista

EMP_ APELLI- DEPTO_ SUELDO EMP_ APELLI- DPTO_
NRO DO NRO NRO DO NRO
101 SMITH 30 5.010 101 SMITH 30
50 LOPEZ 10 25.000 50 LOPEZ 10
210 DIAZ 20 5.500 210 DIAZ 20
443 BLANCO 30 4.000 443 BLANCO 30
501 JONES 40 1.500 501 JONES 40
Una vista puede ser usada para presentar datos normalizados en forma desnormalizada.
Por ejemplo, siguiendo las reglas de normalización, las Tablas PEDIDO y CLIENTE estan
separadas:
25
Pedido Cliente
PED_NUM PED_ PED_CLI_ CLI_NRO APELLIDO NOMBRE
FECHA NRO
10145 10/06/1991 111 111 SMITH JUAN
27444 07/08/1991 550 342 DIAZ DANIEL
32157 08/09/1991 342 550 ROZAS MARTA
43010 30/07/1991 111 375 BLANCO JOSE
98710 10/05/1991 375
Una vista definida a través de ambas Tablas será usada para pre-juntar las Tablas de tal modo
que el usuario solo verá una sola Tabla:
Vista
PED_NUM PED_ CLI_NRO APELLIDO NOMBRE
FECHA
10145 10/06/1991 111 SMITH JUAN
27444 07/08/1991 550 DIAZ DANIEL
32157 08/09/1991 342 ROZAS MARTA
43010 30/07/1991 111 SMITH JUAN
98710 10/05/1991 375 BLANCO JOSE
Paso 2.4.: Desnormalización del diseño de la base de datos.
Siempre debe partirse de Tablas en Tercera Forma Normal (3FN).
La desnormalización puede ser una solución por transacciones con requerimientos de

performance tales como alta frecuencia y rápido tiempo de respuesta.
Se deben considerar todas las otras opciones antes que la desnormalización, especialmente el
cambio o la adición a la estructura de los índices.
Es extremadamente riesgoso desnormalizar innecesariamente ya que esto puede causar

problemas de inconsistencia en los datos.
La combinación de Tablas es la forma más común de desnormalización. Por ejemplo

considerar las Tablas CUENTA y BANCO:
Tabla: CUENTA Tabla: BANCO

COLUM CTA_ SALDO BANCO_ COLUM BANCO_ BANCO_
NA NRO NRO NA NRO NOMBRE
TIPO TIPO
CLAVE PK PK,FK CLAVE PK
NULO/ NULO/
UNICO NN,U1 NN NN,U1 UNICO NN,U NN
DATOS 04157 100,00 301 DATOS 301 CITY
EJEMPLO 75731 2.500,00 410 EJEMPLO 410 RIO
61134 9.791,00 301 501 NACION
94174 3.740,00 501 257 LLOYDS
53109 5.940,00 410 380 CREDITO
26
Si un alto volumen de consultas de CUENTAs siempre acceden al nombre del banco, una
combinación de Tablas puede hacer que la redundancia de datos sea valiosa. La Tabla
CUENTA y la Tabla BANCO se combinan sobre BANCO_NRO:
Tabla: CUENTA
COLUM CTA_ SALDO BANCO_ BANCO_
NA NRO NRO NOMBRE
TIPO
CLAVE PK PK
NULO/
UNICO NN,U1 NN,U NN,U NN
DATOS 04157 100,00 301 CITY
EJEMPLO 75731 2.500,00 410 RIO
61134 9.791,00 301 CITY
94174 3.740,00 501 NACION
53109 5.940,00 410 RIO
Otra forma de desnormalizacion se refiere al uso de vectores.

Un vector es un arreglo unidimensional con un número fijo de valores (un grupo repetitivo de un
tamaño definido). Un vector de datos se representa como un conjunto de filas o como un
conjunto de columnas:
Diseño de Tabla en Modo Columna (3FN):
MODELO MES CANTIDAD

COUPE ENE 1000
COUPE FEB 1106
COUPE MAR 1020
COUPE ABR 1026
COUPE MAY 999
COUPE JUN 1435
COUPE JULI 1278
COUPE AGO 1698
COUPE SET 920
COUPE OCT 978
COUPE NOV 989
COUPE DIC 886
. . .
. . .
. . .
Diseño de Tabla en Modo Fila:
MODELO ENE FEB MAR ABR MAY JUN JUL AGO SET OCT NOV DIC
Coupe 1000 1106 1020 1026 999 1435 1278 1698 920 978 989 886
Sedan 850 978 1000 1004 699 1336 1267 1765 940 995 766 823
Cabriolet 948 674 888 893 1000 1547 1449 1020 950 673 975 345
Van 1205 999 1016 1005 1001 1200 1030 1864 999 1040 897 745
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Elegir el diseño de Tabla para vector de datos basándose en los requerimientos de acceso
funcional.
27
Ventajas del Diseño de Tabla en Modo Columna:
• Las funciones que actuan por columnas (SUMA, PROMEDIO, etc.) facilitan su utilización
• Los cambios en la longitud del vector pueden ser fácilmente implementados.
Ventajas del Diseño de Tabla en Modo Fila:
• Menor requerimiento de espacio de almacenamiento
• Los reportes de salida que muestran todos los valores horizontalmente son fáciles de
producir.
Se debe considerar el almacenamiento de datos derivados a la luz de los requerimientos de

acceso funcional y de las capacidades del software desarrollado.
Por ejemplo, un gerente general de ventas tiene 200 vendedores regionales a su cargo.
Frecuentemente consulta la cuota total de ventas y las ventas por dia para cada región. Las
cuotas de venta se establecen cuatrimestralmente. Las ventas diarias son actualizadas
semanalmente. Mantener datos de cuotas de venta y ventas por dia por región pueden ser
deseable:
Tabla: VENTAS_VENDEDOR
COLUMNA VENDED_N APELLIDO NOMBRE VENTAS_ VENTAS_ REGION_
RO CUOTA POR_DIA NRO
CLAVE
TIPO PK FK
NULO/
UNICO NN,U NN NN NN NN NN
DATOS 110 SMITH DANIEL 500.000 10.000 50
EJEMPLO 250 GONZALEZ MARIA 700.000 350.000 35
310 DIAZ JUAN 1.200.000 500.000 40
400 BLANCO JOSE 650.000 250.000 37
550 RUIZ RAUL 800.000 420.000 40
Tabla: REGION
COLUMNA REGION_NRO VENTAS_ VENTAS_POR_
CUOTA DIA
CLAVE TIPO PK
NULO/UNICO NN,U
DATOS 20 2.000.000 750.500
EJEMPLO 50 1.500.000 600.250
35 700.000 350.000
40 2.000.000 920.000
37 1.300.000 250.000
Datos sumarios derivados
28
Paso2.5. Planificación del uso del espacio físico.
En este paso, el Diseñador trabaja junto con el Administrador de Base de Datos para planificar
la disposición física de las Tablas e Indices de la base de datos.
Algunas consideraciones sobre este punto son:
• Por cada tabla e índice, estimar la cantidad de espacio de disco requerido.
• Decidir sobre la disposición de Tablas e Indices en distintos dispositivos lógicos y físicos.
• Definir los parámetros de ubicación de almacenamiento basándose en las estimaciones de

actualización y crecimiento de los datos.
Concluido el diseño, este se implementa a través de la CONSTRUCCION DE LA BASE DE

DATOS, en la cual se crean tablas físicas de la base de datos relacional.
29

DIS Diseño de Base de Datos 2002

Cargado por

Información del documento

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

DIS Diseño de Base de Datos 2002

Cargado por

Copyright:

Formatos disponibles

DISEÑO DE BASES DE DATOS

Diseño de Bases de Datos

1. CONCEPTOS SOBRE BASE DE DATOS RELACIONALES

Por ejemplo, la siguiente tabla relacional contiene datos de empleados:

EMPLEADO_NRO APELLIDO NOMBRE DEPTO_CODIGO

100 LOPEZ JUAN 10

1.1. CLAVES PRIMARIAS (PK)

EMPLEADO_ APELLIDO NOMBRE DEPTO_ LIQUIDACION_

Todas las Claves Candidatas deben ser Unicas y No Nulas.

1.2. CLAVES EXTERNAS (FK)

Por ejemplo, DEPTO_CODIGO es una FK en la siguiente tabla EMPLEADO, y referencia a los

Clave Primaria Clave Externa

EMPLEADO_ APELLIDO NOMBRE DEPTO_ LIQUIDACION_

Las FK son usadas para unir tablas.

La FK DEPTO_CODIGO en la tabla EMPLEADO refiere a los valores de la PK

Clave Primaria Clave Externa Clave Primaria

EMPLEADO_ APELLIDO DEPTO_ DEPTO_ DEPTO_

Tabla: EMPLEADO Tabla: DEPARTAMENTO

Si una FK es parte de una PK, entonces la FK no debe ser NULA.

Clave Primaria Clave Externa Clave Primaria

BANCO_NRO BANCO_ BANCO_NRO CUENTA_ SALDO

Tabla: BANCO Tabla: CUENTA

1.3. INTEGRIDAD DE LOS DATOS

La integridad de los datos se refiere a la exactitud y consistencia de los datos.

Tipo de restricción: Significado:

- Un empleado jerárquico no debe percibir horas extras.

2. DISEÑO DE BASE DE DATOS

1.1. Mapeo de cada entidad simple en una tabla.

1.3. Mapeo de los identificadores únicos en claves primarias.

1.4. Mapeo de las relaciones en claves externas.

1.5 Mapeo de Relaciones Excluyentes.

1.6 Mapeo de Subtipos y Supertipos

1.7. Normalización de las tablas.

2.1. Definición de las restricciones de integridad referencial.

2.2. Diseño de índices.

2.3. Establecimiento de vistas.

2.4. Desnormalización del diseño de la base de datos.

2.5. Planificación del uso del espacio físico.

Cada relación se documenta mediante una Tabla.

• Una columna definida como NO NULA se indica con NN.

• Una columna definida como UNICA se indica con U.

• Toda columna PK simple debe indicarse como NN,U.

Para ejemplificar los pasos de la ACTIVIDAD 1 se utilizará el siguiente DER:

Paso 1.1: Mapeo de cada Entidad simple en una Tabla:

Documentar filas con datos ejemplo en la Tabla.

Paso 1.3.: Mapeo de los identificadores únicos en claves primarias.

• Todas las columnas indicadas como PK también deben ser NN y U.

inscripto en Tabla: ALISTAMIENTO

Paso 1.4.: Mapeo de las relaciones en claves externas.

Para relaciones M:1, adicionar la PK de la Entidad UNO de la relación a la tabla de la Entidad

CURSO dictado INSTRUCTOR

• Si la PK de una Tabla comprende Claves Externas, las columnas FK correspondientes a la

Para relaciones 1:1 mandatorias, se adiciona la única FK en la Tabla correspondiente a la

Tabla: COMPUTADORA Tabla: MOTHERBOARD

Si una relacion 1:1 es opcional en ambas direcciones, adicionar la FK indistintamente en una

DARSENA ocupada por BARCO

Tabla: DARSENA Tabla: BARCO

• La columna FK hace referencia a una fila (registro) de la misma Tabla.

• El nombre de la columna FK debe reflejar la relación.

• Una FK recursiva nunca debe ser NO NUL A (NN).

• La combinación de columnas PK y FK siempre debe ser única a fin de asegurar la relación

Paso 1.5: Mapeo de Relaciones Excluyentes.

- Diseño Explícito de Arcos

- Diseño Genérico de Arcos.