Diseño de base de datos

Ciclo de vida
 Las etapas del proceso de desarrollo de
software
• Cualquier sistema de información va pasando por una serie de fases a lo largo de su vida. Su
• ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:
• - Planificación
• - Análisis
• - Diseño
• - Implementación
• - Pruebas
• - Instalación o despliegue
• - Uso y mantenimiento
 Planificación
• Antes de que se le de oficialmente el pistoletazo de salida a un proyecto de
desarrollo de un sistema de información, es necesario realizar una serie de
tareas previas que influirán decisivamente en la finalización con éxito del
proyecto.
• Las tareas iniciales que se realizarán son tales como la determinación del
ámbito del proyecto, la realización de un estudio de viabilidad, el
análisis de los riesgos asociados al proyecto, una estimación del coste
del proyecto, su planificación temporal y la asignación de recursos a
las distintas etapas del proyecto.
 Análisis
• Lo primero que debemos hacer para construir un sistema de información es
averiguar qué es exactamente lo que tiene que hacer el sistema. La etapa de
análisis en el ciclo de vida del software corresponde al proceso mediante el
cual se intenta descubrir qué es lo que realmente se necesita y se llega a una
comprensión adecuada de los requerimientos del sistema (las características
que el sistema debe poseer).
 ¿Por qué resulta esencial la etapa de análisis?
• Simplemente, porque si no sabemos con precisión qué es lo que se necesita,
ningún proceso de desarrollo nos permitirá obtenerlo. El problema es que,
de primeras, puede que ni nuestro cliente sepa de primeras qué es
exactamente lo que necesita. Por tanto, deberemos ayudarle a averiguarlo con
ayuda de distintas técnicas (algunas de las cuales aprenderemos a utilizar más
adelante).
 Diseño
• Mientras que los modelos utilizados en la etapa de análisis representan los
requisitos del usuario desde distintos puntos de vista (el qué), los modelos
que se utilizan en la fase de diseño representan las características del sistema
que nos permitirán implementarlo de forma efectiva (el cómo).
 Diseño
• En la fase de diseño se han de estudiar posibles alternativas de implementación para
el sistema de información que hemos de construir y se ha de decidir la estructura
general que tendrá el sistema (su diseño arquitectónico). El diseño de un sistema
es complejo y el proceso de diseño ha de realizarse de forma iterativa. La solución
inicial que propongamos probablemente no resulte la más adecuada para nuestro
sistema de información, por lo que deberemos refinarla. Afortunadamente, tampoco
es necesario que empecemos desde cero. Existen auténticos catálogos de patrones
de diseño que nos pueden servir para aprender de los errores que otros han
cometido sin que nosotros tengamos que repetirlos.
 Implementación
• Una vez que sabemos qué funciones debe desempeñar nuestro sistema de
información (análisis) y hemos decidido cómo vamos a organizar sus
distintos componentes (diseño), es el momento de pasar a la etapa de
implementación, pero nunca antes. Antes de escribir una sola línea de código
(o de crear una tabla en nuestra base de datos) es fundamental haber
comprendido bien el problema que se pretende resolver y haber aplicado
principios básicos de diseño que nos permitan construir un sistema de
información de calidad.
 Pruebas
• Las pruebas de unidad sirven para comprobar el correcto funcionamiento
de un componente concreto de nuestro sistema. Es este tipo de pruebas, el
"probador“ debe buscar situaciones límite que expongan las limitaciones de
la implementación del componente, ya sea tratando éste como una caja negra
("pruebas de caja negra") o fijándonos en su estructura interna ("pruebas de
caja blanca"). Resulta recomendable que, conforme vamos añadiéndole nueva
funcionalidad a nuestras aplicaciones, vayamos creando nuevos tests con los
medir nuestro progreso y también repitamos los antiguos para comprobar
que lo que antes funcionaba sigue funcionando (test de regresión).
 Pruebas
• Las pruebas de integración son las que se realizan cuando vamos juntando
los componentes que conforman nuestro sistema y sirven para detectar
errores en sus interfaces. En algunas empresas, como Microsoft, se hace una
compilación diaria utilizando los componentes del sistema tal como estén en
ese momento (daily build) y se somete al sistema a una serie de pruebas
básicas (la prueba de humo, smoke test) que garanticen que el proyecto podrá
seguir avanzando al día siguiente
 Instalación
• Una vez concluidas las etapas de desarrollo de un sistema de información
(análisis, diseño, implementación y pruebas), llega el instante de que poner el
sistema en funcionamiento, su instalación o despliegue.
• De cara a su instalación, hemos de planificar el entorno en el que el sistema
debe funcionar, tanto hardware como software: equipos necesarios y su
configuración física, redes de interconexión entre los equipos y de acceso a
sistemas externos, sistemas operativos (actualizados para evitar problemas de
seguridad), bibliotecas y componentes suministrados por terceras partes,
etcétera.
 Uso y mantenimiento
• La etapa de mantenimiento consume típicamente del 40 al 80 por ciento de los recursos de una
empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente la etapa más
importante del ciclo de vida del software. Dada la naturaleza del software, que ni se rompe ni se
desgasta con el uso, su mantenimiento incluye tres facetas diferentes:
• - Eliminar los defectos que se detecten durante su vida útil (mantenimiento correctivo), lo primero
que a uno se le viene a la cabeza cuando piensa en el mantenimiento de cualquier cosa.
• - Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistema ha de funcionar
sobre una nueva versión del sistema operativo o en un entorno hardware diferente, por ejemplo.
• - Añadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponen características
deseables que supondrían una mejora del sistema ya existente.
Modelos del
ciclo de vida
 Diseño de base de datos
• El diseño de una base de datos es un proceso complejo que abarca decisiones
a muy distintos niveles. La complejidad se controla mejor si se descompone
el problema en subproblemas y se resuelve cada uno de estos subproblemas
independientemente, utilizando técnicas específicas. Así, el diseño de una
base de datos se descompone en diseño conceptual, diseño lógico y diseño
físico.
 Fases del diseño de base de datos
• - Análisis de requisitos
• - Diseño conceptual
• - Elección del sistema gestor de bases de datos
• - Diseño lógico
• - Diseño físico
• - Instalación y mantenimiento
 Modelos de datos
• Un modelo de dato es un conjunto de herramientas que permiten describir
los datos, sus relaciones, las restricciones de seguridad a aplicar y la
terminología a utilizar. Los modelos deben representar la realidad, por lo que
deben poseer las siguientes cualidades: • Expresividad: deben tener
suficientes conceptos para expresar perfectamente la realidad. • Simplicidad:
deben ser simples para que los esquemas sean fáciles de entender. •
Formalidad: todos los conceptos deben tener una interpretación única,
precisa y bien definida.
 Modelo Entidad - Relación
• El modelado Entidad-Relación es una técnica para el modelado de datos utilizando
diagramas entidad relación. No es la única técnica pero sí la más utilizada.
Brevemente consiste en los siguientes pasos: 1. Se parte de una descripción textual
del problema o sistema de información a automatizar (los requisitos). 2. Se hace una
lista de los sustantivos y verbos que aparecen. 3. Los sustantivos son posibles
entidades o atributos. 4. Los verbos son posibles relaciones. 5. Analizando las frases
se determina la cardinalidad de las relaciones y otros detalles. 6. Se elabora el
diagrama (o diagramas) entidad-relación. 7. Se completa el modelo con listas de
atributos y una descripción de otras restricciones que no se pueden reflejar en el
diagrama.
 Ejemplo
Este modelo diferenciamos tres
entidades, Profesor, Curso y
Departamento y varias relaciones. Un
departamento tiene muchos profesores
y un profesor puede dar muchos cursos.
Para cada una de las entidades existe
una propiedad que las identifica
únicamente y que se corresponde con la
clave primaria (en este caso clave
subrogada). Las entidades, además,
tienen otras propiedades que las
describen (los atributos no clave).
 Entidad
• Cualquier tipo de objeto o concepto sobre el que se recoge información
relevante para el sistema: cosa, persona, concepto abstracto o suceso. Por
ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de
productos, conciertos, excursiones, etc. Las entidades se representan
gráficamente mediante rectángulos y su nombre aparece en el interior. Un
nombre de entidad sólo puede aparecer una vez en el esquema conceptual.
• Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una
entidad cuya existencia depende de la existencia de otra entidad. Una entidad
fuerte es una entidad que no es débil.
 Cardinalidad
• La cardinalidad con la que una entidad participa en una relación especifica el
número mínimo y el número máximo de correspondencias en las que puede
tomar parte cada ocurrencia de dicha entidad. La participación de una
entidad en una relación es obligatoria (total) si la existencia de cada una de
sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra
entidad participante. Si no, la participación es opcional (parcial).
• Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá
cada ejemplar de la entidad (el valor que se anota es de cero o uno, aunque tenga
una cardinalidad mínima de más de uno, se indica sólo un uno) Cardinalidad
máxima. Indica el número máximo de relaciones en las que puede aparecer cada
ejemplar de la entidad. Puede ser uno, otro valor concreto mayor que uno (tres por
ejemplo) o muchos (se representa con n) En los esquemas entidad / relación la
cardinalidad se puede indicar de muchas formas. Quizá la más completa (y la que se
utiliza en este documento es ésta) consiste en anotar en los extremos la cardinalidad
máxima y mínima de cada entidad en la relación.
 Tipo de Correspondencia
• Indica el nº máximo de entidades de un tipo que se puede relacionar por cada
entidad del otro tipo asociadas por la relación, lo obtenemos a partir de las
cardinalidades. Las más frecuentes son: • 1:1 Por cada elemento de una
entidad sólo aparece uno de la otra • 1:N Por cada elemento de una entidad
aparece un nº indeterminado de elementos de la otra • N:M Lo anterior
ocurre en ambos sentidos
 Atributo
• Es una característica de interés o un hecho sobre una entidad o sobre una
relación. Los atributos representan las propiedades básicas de las entidades y
de las relaciones. Toda la información extensiva es portada por los atributos.
Gráficamente, se representan mediante bolitas que cuelgan de las entidades o
relaciones a las que pertenecen
• Cada atributo tiene un conjunto de valores asociados denominado dominio.
El dominio define todos los valores posibles que puede tomar un atributo.
Puede haber varios atributos definidos sobre un mismo dominio.
 Identificador o clave
• Un identificador de una entidad es un atributo o conjunto de atributos que
determina de modo único cada ocurrencia de esa entidad. Un identificador
de una entidad debe cumplir dos condiciones: 1. No pueden existir dos
ocurrencias de la entidad con el mismo valor del identificador. 2. Si se omite
cualquier atributo del identificador, la condición anterior deja de cumplirse.
Toda entidad tiene al menos una clave y puede tener varios claves
alternativas. Las relaciones no tienen identificadores. La clave puede estar
formaba por uno o varios atributos y se representa con ese/os atributos
subrayados
 Metodología diseño conceptual
• El primer paso en el diseño de una base de datos es la producción del modelo lógico.
Pueden construirse varios esquemas lógicos, cada uno para representar las distintas visiones
que los usuarios tienen de la información. Cada una de estas visiones suelen corresponder a
las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas,
recursos humanos, etc. Las tareas a realizar en el diseño lógico son las siguientes:
• 1. Identificar las entidades.
• 2. Identificar las relaciones.
• 3. Identificar los atributos y asociarlos a entidades y relaciones.
• 4. Determinar los dominios de los atributos.
• 5. Determinar los identificadores.
• 6. Determinar las jerarquías de generalización (si las hay).
• 7. Dibujar el diagrama entidad-relación.
• 8. Revisar el esquema lógico con el usuario.
 Diseño Lógico
• El diseño lógico parte de las especificaciones de requisitos de usuario y su
resultado es el esquema lógico de la base de datos. Este esquema es una
descripción de alto nivel de la estructura de la base de datos,
independientemente del SGBD que se vaya a utilizar para manipularla. El
objetivo es describir el contenido de información de la base de datos y no las
estructuras de almacenamiento que se necesitarán para manejar esta
información.
Ejemplo
 Ejercicio
• El Análisis de la Base de Datos la Farmacia
• Una farmacia necesita un sistema informático, por ello necesita el diseño de una base de
datos, esta empresa tiene las siguientes reglas:
1. Se necesita llevar el control de los fármacos, de estos se tiene un nombre y descripción.
• 2. Los fármacos se clasifican por acción y laboratorios, es decir, cada fármaco corresponde a
un laboratorio y tiene alguna acción.
• 3. Laboratorios tienen nombre y dirección. De las acciones se tiene en cuenta su nombre y
descripción.
• 4. En la farmacia se vende los medicamentos a clientes, estas ventas deben ser registradas, se
debe registrar que medicamento se vende, el cliente que compra, la fecha al que se vende el
medicamento, la cantidad y el precio al que se vende.
• 5. De los clientes (nombre y dirección) también se debe tener en cuenta el vendedor que
hace una venta y se debe considerar su nombre, dirección y teléfono.