8 Diseño de BD

Capítulo 8 – Diseño de base de datos
Bases de Datos
Generalidades
Cuando se crea una base de datos, es necesario considerar cuidadosamente sus componentes. Los siguientes
conceptos, ayudan al diseño:
Ciclo de Desarrollo del Sistema
Estrategia y Análisis
 Estudiar y analizar los requerimientos de la empresa. Identificar los requerimientos de información.
Incorporar las reglas del negocio y de la aplicación.
 Construir modelos del sistema. Confirmar y refinar el modelo.
Diseño
 Diseñar la base de datos. El modelo entidad-relación traduce entidades a tablas, atributos a columnas,
relaciones a claves externas (foreign keys) y reglas del negocio a restricciones (constraints).
Construcción y Documentación
 Construir el prototipo del sistema. Escribir y ejecutar los comandos para crear las tablas y proveer los
objetos para la base de datos.
 Confeccionar la documentación para el usuario, los textos para la ayuda en pantalla y manuales de operación
para soporte al usuario y operación del sistema.
Transición
 Redefinir el prototipo. Llevar una aplicación a la producción con el test de aprobación del usuario,
conversión de los datos existentes y operaciones paralelas. Realizar las modificaciones que se requieran.
Producción
 Entregarle el sistema a los usuarios. Operar el sistema en producción. Monitorear su performance, mejorarlo
y refinarlo.
Diseño de la Base de Datos
Diseñar una base relacional implica convertir un modelo en una representación de software sobre la que se pueda
trabajar. Las entidades (u objetos) percibidos por el usuario se transforman en tablas de la base de datos. Todas
las formas del diseño involucran una mezcla de reglas, juicios y sentido común. Lo mismo es válido para el
diseño relacional.
Durante la etapa de diseño, el objetivo es lograr sistemas con un diseño confiable y de alta performance, usando
los resultados de la etapa de análisis. Los siguientes factores son claves y describen en detalle por qué debe
tomarse la molestia de diseñarlo todo.
Performance
El diseño inicial de un sistema tiene un impacto enorme sobre su performance final. Generalmente este impacto
es mucho más grande que cualquier tuning o ajuste posterior.
Integración de la Aplicación
Las aplicaciones de sistemas son creadas, típicamente, por equipos de desarrolladores. Sin alguna especificación
de diseño sobre la cual trabajar, cada desarrollador puede construir su parte con su propio estilo. Un buen diseño
no sólo da una buena apariencia al producto, sino que también permite asegurar que todos los componentes de la
aplicación resultante se encuentren bien integrados entre sí.
Integración con Otros Sistemas
Con frecuencia, existen requerimientos que hacen que un sistema nuevo se integre con uno ya existente o con
sistemas que no se han construído aún. Un buen diseño extiende los beneficios de integración antes
mencionados a los sistemas corporativos o globales.
8 -1
Capítulo 8 – Diseño de base de datos
Bases de Datos
Documentación y Comunicación
Una parte importante de la tarea del diseñador es comunicarle a otros las decisiones del diseño. Esas decisiones
necesitan. Como mínimo, documentarse.
Escalabilidad
Las cuestiones de performance se deben abordar durante el diseño en lugar de hacerlo cuando el sistema se
encuentra en producción. Por ejemplo, el desarrollo de una aplicación en un ambiente pequeño y controlado no
permite testear situaciones del mundo real o grandes volúmenes de datos, factores que pueden revelar defectos o
fallas en el diseño.
Evitar “reinventar la rueda”
Muchos de los problemas con los que uno se encontrará, ya han sido encontrados por otros anteriormente. En la
medida de lo posible, utilizar soluciones existentes y exitosas.
Modelo Entidad-Relación
El modelo entidad-relación es derivado de las especificaciones del negocio o narrativas. Este modelo es una
representación gráfica de las necesidades de información y reglas del negocio.
El modelo entidad-relación separa la información requerida por la empresa de las actividades dentro de la
misma. Aunque los negocios puedan cambiar sus actividades, el tipo de información tiende a mantenerse
constante. Por lo tanto, las estructuras de datos también tienden a mantenerse constantes.
Beneficios del Modelo Entidad-Relación





Documenta los requerimientos de información de la empresa, en una forma precisa y clara.
Provee una representación gráfica de fácil comprensión para el diseño de la base de datos.
Es fácil de desarrollar y refinar.
Define claramente el alcance de los requerimientos de información.
Ofrece un ambiente de trabajo efectivo para la integración e múltiples aplicaciones, desarrollo de proyectos
y paquetes de aplicaciones ya adquiridos.
Componentes Básicos
Componente
Entidad
Atributo
Relación
Descripción
Un elemento relevante acerca del cual se
necesita conocer información.
Algo que describe o califica una entidad y
contiene información específica que se
requiere conocer acerca de ella.
Una asociación entre entidades, con un
nombre, que muestra grado y opcionalidad.
Ejemplos
Clientes, Vendedores, Pedidos
Nombre, Teléfono, Nro. De Documento,
Fecha de Nacimiento.
Pedidos y Productos, Clientes y
vendedores.
Modelo Entidad-Relación: Conceptos
Un modelo entidad-relación se compone de entidades, atributos y relaciones.
Entidades
Una entidad es algo relevante para la empresa o una categoría o conjunto discreto de datos relacionados.
Algunos ejemplos son cñientes, órdenes y empleados.
Las convenciones para representar a una identidad en el modelo son:
 Cajas con bordes redondeados de cualquier tam,año
 Nombre de la entidad singular y único
 El nombre de la entidad debe ir en mayúsculas
 Sinónimos opcionales par el nombre pueden ir con mayúsculas y encerrados entre paréntesis ( ).
8 -2
Capítulo 8 – Diseño de base de datos
Bases de Datos
Atributos
Los atributos describen las entidades y contienen información específica que se quiere conocer acerca de ella.
Por ejemplo, para la entidad cliente, los atributos serían número del cliente, número telefónico y dirección.
Si una entidad no tiene atributos relevantes desde la óptica de la empresa, entonces no está dentro del alcance de
los requerimientos del sistema y no debe aparecer en el modelo.
Cada uno de los atributos puede ser obligatorio u opcional. Este estado se denomina opcionalidad.
Las convenciones ara representar un atributo en un modelo son:
 Usar nombres singulares en minúscula
 Marcar los atributos obligatorios o valores que deben conocerse, con un asterisco “*”
 Marcar los atributos opcionales o valores que pueden conocerse, con una “o”
Identificadores Unicos
Un identificador único (UID) es cualquier combinación de atributos, relaciones o ambos, que sirven para
distinguir cada ocurrencia de una entidad. Cada una de esas ocurrencias debe ser identificable unívocamente.
 Marcar cada atributo que es parte del UID con un signo numeral “#”.
 Marcar los identificadores únicos con un signo numeral entre paréntesis “(#)”.
Relaciones
Cada entidad debe tener una relación que represente los requerimientos de información y reglas del negocio. La
relación es una asociación bidireccional entre dos entidades, o entre una entidad y sí misma.
Cuando una tabla tiene una relación consigo misma, esa relación se define como recursiva.
Cada dirección de la relación contiene
 Nombre, por ejemplo, enseñado por o asignado a.
 Opcionalidad, o bien puede estar o bien debe estar.
 Grado o cardinalidad, puede ser uno y solo uno, o uno a muchos.
Relaciones: Sintaxis
entidad origen {puede estar | debe estar } nombre de la relación {uno y sólo uno | uno o más } entidad destino
Convenciones para la Diagramación de Relaciones
Símbolo
Línea punteada
Línea Sólida
Pata de gallo
Línea simple
Descripción
Elemento indicando opcionalidad. “puede estar”
Elemento indicando obligatoriedad. “debe estar”
Elemento indicador de grado “uno o más”
Elemento indicador de grado “uno y sólo uno”
Identificador Unico a lo largo de la Relación
Una entidad puede estar identificada de manera unívoca a lo largo de toda la relación.
Usar una barra de UID para indicar que una relación es parte del identificador único de la entidad. La relación
incluída en un UID debe ser mandatoria y de uno y sólo uno en la dirección que participa en la UID.
Ejemplo
Cuando se ordenan ítems, se obtiene un número de orden y un ítem con una línea e número de ítem única. Pero
cuando se ingresa otra orden, ese ítem ya deja de ser único. Por lo tanto, el ítem es definido unívocamente por su
atributo número y por el número de orden específico con el cual el ítem se relaciona.
Número de Orden
100
100
100
101
101
Número de Item
Número de Producto
209
399
876
630
297
1
2
3
1
2
8 -3
Capítulo 8 – Diseño de base de datos
Bases de Datos
Relaciones Recursivas
Una relación entre una entidad y sí misma se denomina relación recursiva. Esto se representa con un “rulo”, es
decir una flecha curva que tiene origen y destino en la misma tabla.
Tipos de Relación
Tipo
Uno-a-uno
Muchos-a-uno
Muchos-a-muchos
Descripción
Grado de uno y sólo uno en ambas direcciones. Esos tipos no son frecuentes y en
realidad puede tratarse de la misma entidad o de un atriburo de la entidad.
Grado de uno o más en un sentido y grado de uno y sólo uno en el sentido contrario.
Es muy común.
Grado de uno o más en ambos sentidos. Muy común. Se resuelven con una entidad
intersección.
Normalización
Antes de diseñar la base de datos, se normaliza el modelo de datos para eliminar los problemas de redundancia
de datos. Modificar el modelo de datos para que pueda soportar diferentes requerimientos funcionales y diseños
alternativos, normalizando el esquema de los datos antes de crear la base de datos.
Beneficios de la Normalización



Minimiza la redundancia de datos
Reduce los problemas de integridad
Identifica entidades, relaciones y tablas faltantes.
Formas Normales
Forma
Primera (1FN)
Segunda (2FN)
Tercera
(3FN)
Descripción
Los atributos no deben tener estructuras repetitivas o agrupamientos.
Un atributo debe depender de la totalidad del identificador único de su identidad.
Ningún atributo que no pertenezca al identificador único puede depender de otro
atributo que no pertenezca al identificador único.
Claves y Restricciones de Identidad (Constraints)
Aseguran que la base de datos conserve siempre un estado consistente y correcto al aplicar restricciones de
integridad a los datos. El servidor de la base de datos o el software de aplicación deben garantizar el
cumplimiento de todos los datos. Las claves corresponden a las restricciones de integridad. Los tres tipos de
claves son: primary key (claves primarias), unique key (claves únicas) y foreign key (claves externas)
Tipo de Restricción de Identidad
Entidad
Referencial
Columna
Definido por el Usuario
Descripción
Ningún componente de una primary key puede ser NULL y el valor de
la misma deber ser único.
Los valores de las foreign key deben corresponderse con el de una
primary key o debe ser NULL.
Los valores en una columna deben ser del tipo definido para dicha
columna
Los valores deben ser compatibles con las reglas del negocio.
Ejemplos de Restricciones de Integridad definidas por el usuario



Un empleado del departamento de finanzas no puede tener un cargo de programador
La comisión de un vendedor no puede exceder el 50% de su sueldo base.
Los clientes pueden tener solamente una calificador de crédito Excelente, Buena o Mala
8 -4
Capítulo 8 – Diseño de base de datos
Bases de Datos
Claves Primarias
Cada fila en una tabla es unívocamente identificada por una columna o conjunto de ellas denominado primary
key (PK). La primary key se define para no permitir que los valores sean duplicados ni NULL.
Una primary key que se encuentra formada por varias columnas se denomina una primary key compuesta o
primary key mixta. Las columnas de una primary key compuesta deben ser únicas en combinación, aunque las
columnas, individualmente puedan tener duplicados. Ninguna componente de una primary key puede contener
valores nulos.
Claves Candidatas
Una tabla puede tener varias claves candidatas. Una clave candidata es una columna o combinación de éstas que
puede servir como la primary key para la tabla.
Seleccionar una clave candidata para que sea la primary key de la tabla. Las otras candidatas se convierten en
claves alternativas o claves únicas. Ellas deben ser UNIQUE (UK) y NOT NULL.
Foreign Keys
Una foreign key (FK) es una columna o combinación de ellas de una tabla que hacen referencia a una primary
key o unique key en la misma tabla o en otra. Las foreign keys se basan en valores de los datos y son puramente
lógicas, no son punteros físicos. El valor de una foreign key debe coincidir con el de la primary key o unique key
relacionada o bien puede ser NULL. Si una foreign key es parte de una primary key, no puede contener un valor
nulo porque el valor de ninguna parte de una PK puede ser NULL.
Ejemplo
En la tabla S_ITEM, el campo ORD_ID no puede contener un valor nulo porque es parte de la PK.
Foreign Key
ORD_ID
100
100
101
101
ITEM_ID
1
2
1
3
Tabla S_ITEM
Primary Key
PRODUCT_ID
10011
10013
30421
41010
....
Primary Key
ID
100
101
102
CUSTOMER_ID
204
205
206
Tabla S_ORD
DATE_ORDERED
31/08/92
31/08/92
01/09/92
....
Diseño de la Base de Datos
La etapa de diseño de la base de datos produce las especificaciones para una base de datos relacional, incluyendo
las definiciones de las tablas, índices, vistas y espacio de almacenamiento.
Llevar el Modelo Entidad-Relación a un Cuadro de Instancias de Tablas.
1.
2.
3.
4.
Llevar las entidades simples a tablas.
Llevar los atributos a columnas. Definir con claridad los nombres de las columnas y sus tipos de datos
genéricos; por ejemplo, caracter, número o fecha.
Llevar los identificadores únicos a primary key. Asegurarse de incluir todas las foreign key que son
componentes de la primary key.
Llevar las relaciones a foreign keys.
8 -5
Capítulo 8 – Diseño de base de datos
Bases de Datos
Cuadro de Instancias
1
Tabla S_CUSTOMER
2
Nombre Columna ID
3
Tipo de Clave
PK
NN/UK
NN,U
4
Sales_rep_id
Region_id
FK1
FK2
Tabla de la FK
S_EMP
S_REGION
Columna de la FK
ID
ID
CHAR CHAR
NUM
NUM
25
7
7
Tipo de dato
NUM
Longitud Máxima 7
Name
Phone
Address
NN
20
Símbolos Usados para Documentar el Cuadro de Instancias de Tablas
Símbolo
PK
FK
FK1, FK2
FK1, FK1
NN
U
U1, U1
Definición
Columna perteneciente a la Primary Key
Columna perteneciente a la Foreign Key
Dos Foreign Key dentro de la misma tabla
Dos columnas dentro de la misma foreign key compuesta
Columna no nula
Columna con calores únicos
Dos columnas cuyo valor combinado es único
Guías



Los nombres de las tablas deben ser simples para poder saber sobre qué identidad trata o representa.
Algunas veces se usa el nombre de una entidad en plural, porque la tabla contendrá un conjunto de filas. Es
conveniente ser coherente al respecto y no mezclar en el diseño plurales y singulares.
Los nombres de las columnas deben ubicarse con facilidad en el modelo entidad-relación. Los nombres de
columnas cortos reducen el tiempo requerido para interpretar el comando SQL.
Deben desarrollarse convenciones y standares propios para los nombres de los objetos.
Requerimientos Adicionales




Diseñar los índices, éstos son los objetos que permiten un acceso rápido y directo a las filas. Se pueden crear
índices para claves alternativas, foreign keys y columnas que son usadas con frecuencia en las condiciones
de búsqueda.
Establecer las definiciones de vistas, las cuales son tablas lógicas basadas en una o más tablas o vistas. Las
vistas pueden restringir acceso, proveer una mejor presentación de la información y pueden contener una
consulta compleja predefinida.
Planificar el espacio físico de almacenamiento, es decir, la cantidad de espacio requerido para almacenar los
datos de las tablas en la base de datos.
Redefinir las restricciones de integridad.
8 -6