Base De Datos II

BASE DE DATOS II

Conceptual database design > construcción de un modelo independentiente de todas las consideracion fisicas

Logical database design > consideracion de un modelo especificando el modelo de datos (ej. relacional) independentiente de dbms y consideraciones fisicas

Physical database design > el proceso de producir una descripcion de la implementation de la base de datos en disco

describiendo, la organizacion de archivos los indices las constraints y medidas de seguridad

Criterios de exito para el diseño de una base de datos

Work interactively with the users as much as possible.

>trabajar intectivamente con los usuarios lo mas posible

Follow a structured methodology throughout the data modeling process.

>seguir una metodologia estructurada del modelado de los procesos

Employ a data-driven approach.

Incorporate structural and integrity considerations into the data models.

>incorporar consideraciones estructurada y de integridad en el modelo de datos

Combine conceptualization, normalization, and transaction validation techniques into the data modeling methodology.

>combinar conceptualizaciones, normalizaciones y tecnicas de validacion de integridad dentro de la metodologia del modelado

Use diagrams to represent as much of the data models as possible.

>usar diagramas para representar el modelo de datos lo mejor posible

Build a data dictionary to supplement the data model diagrams.

>construir un diccionario de datos para suplementar el diagrama de modelado de datos

Diseño conceptual de la base de datos (STEPS)

Step 1 Build conceptual data model

Step 1.1 Identify entity types

indentificar los diferentes tipos de entidades

Step 1.2 Identify relationship types

indentificar los diferentes tipos de relaciones

Step 1.3 Identify and associate attributes with entity or relationship types

identificar y asociar atributos con entidades o tipos de relaciones

Step 1.4 Determine attribute domains

determinar los atributos de dominio

Step 1.5 Determine candidate, primary, and alternate key attributes

determinar claves candidatas y primarias

Step 1.6 To consider the use of enhanced modeling concepts, such as specialization / generalization, aggregation, and composition.

considerar mejoras al modelado utilizando conceptos como especializacion generalizacion, agregacion y composicion

Step 1.7 Check model for redundancy

verificar la redundancia del modelo

Step 1.8 Validate conceptual model against user transactions

validar el modelo conceptual contra las transacciones de los usuarios

Step 1.9 Review conceptual data model with user

repasar el modelo de datos conceptual con los usuarios

Step 2 Build and validate logical data model

Step 2.1 Derive relations for logical data model

derivar las relaciones a un modelado de datos logicos

Step 2.2 Validate relations using normalization

validar relaciones usando normalizacion

Step 2.3 Validate relations against user transactions

validar relaciones contra transacciones de usuarios

Step 2.4 Define integrity constraints

definir las restricciones de integridad

Step 2.5 Review logical data model with user

revisar el modelado logico con los usarios

Step 2.7 Check for future growth

verificar modelo para futuro crecimiento

Step 3 Translate logical data model for target DBMS

traducir logicamente el modelo de datos en un dbms data base modelo storage

Step 3.1 Design base relations

diseñar relaciones base

Step 3.2 Design representation of derived data

diseñar la representacion de los datos derivados

Step 3.3 Design general constraints

diseñar las restricciones generales

Step 4 Design file organizations and indexes

diseñar la organizacion de los archivos y los indices

Step 4.1 Analyze transactions

analizar las transacciones

Step 4.2 Choose file organization

elegir archivos de organizacion

Step 4.3 Choose indexes

elegir indices

Step 4.4 Estimate disk space requirements

estimar el espacio necesario del disco

Step 5 Design user views

diseñar las vistas de los usuarios

Step 6 Design security mechanisms

diseñar los mecanismos de seguridad

Step 7 Consider the introduction of controlled redundancy

controlar redundancia de datos

Step 8 Monitor and tune the operational system

monitorear y afinar las operaciones del sys.

Controlando la redundancia de datos

redundancia minima

A veces es necesaria un cierta redundancia a favor de la performance del sistema

NORMALIZACIÓN

NORMALIZACIÓN: Es el procesos de crear más y más tablas hasta evitar cualquier posible redundancia de información.

El proceso de normalización se compone por varios pasos llamados formas normales, en donde el nivel de normalización deseado es subjetivo.

FORMA NORMAL: Es un conjunto específico de propiedades o criterios, declarados por una norma, que define el diseño lógico de los datos.

Se considera que una normalización de una base de datos es completa cuando cubre, por lo menos, las cinco formas normales siguientes.

PRIMERA FORMA NORMAL: Cada campo o columna debe de tener un solo valor ( dato atómico ).

Se refiere a que un dato debe ser dividido hasta que ya no se pueda dividir más, ejemplo: una dirección con calle, número y colonia se puede dividir en dos campos, uno que tenga calle y número, y otro que tenga la colonia. También puede ser que para alguien, un nombre de un cliente, no esté totalmente atomizado y decida dividirlo en dos campos, apellidos y nombres. Generalmente para atomizar los datos hay que agregar más campos o registros en las tablas.

SEGUNDA FORMA NORMAL: Los campos independientes de la tabla no deben depender de una parte parcial de la clave principal de la misma tabla, sino de toda la clave principal.

Es decir, que todos los campos independientes de la tabla deben tener dependencia funcional de la clave principal completa y no de una parte de la clave principal. Esto puede suceder cuando la clave principal está formada por varios campos concatenados y algún campo independiente del mismo registro, no necesita toda la clave principal para encontrarlo, solo de una parte de la clave principal, en este caso hay que dividir la tabla en tablas más sencillas, hasta que todos los campos, en cada tabla, dependan solamente de la clave principal completa.

El paso a segunda forma normal supone dividir las tablas en tablas más pequeñas, en donde:

a) Separar la información que no se corresponda entre si misma, de

una tabla, en otras tablas diferentes o grupos afines de información.

Si tengo una tabla con datos revueltos de clientes y facturas, entonces debo separar los datos formando dos nuevas tablas, una que contenga los datos de los clientes, tabla de clientes, y otra que contenga los datos de las facturas, tabla de facturas.

b) Si existe información repetida en dos o más campos o columnas de una tabla, hay que separar los datos que se repiten, en otras tablas, de tal forma que esa información esté representada solo una vez

En una tabla de calificaciones de alumnos, no vamos a repetir el nombre del alumno en cada una de sus calificaciones, por lo que formamos dos tablas, una de nombres de alumnos y otra de calificaciones, y las tablas se van a relacionar por la matricula de alumno.

TERCERA FORMA NORMAL: Los campos independientes de la tabla deben depender solamente de la clave principal y no de otros campos independientes de la misma tabla.

Cuando un campo depende de otro campo y a la vez este otro campo depende de la clave principal, entonces se dice que hay una DEPENDENCIA TRANSITIVA; la tercera forma normal rompe estas dependencias transitivas formando dos tablas, una tabla con la clave principal y el campo que depende directamente de ella, que pasa a ser una clave externa, y una segunda tabla en donde la clave externa de la primera tabla, pasa a ser la clave principal de la segunda tabla, anexando a esta tabla, el último campo que queda libre, que va a depender exclusivamente de esta clave principal de la segunda tabla.

La segunda forma normal rompe dependencias entre campos y partes parciales de las claves principales, pero la tercera forma normal, además de hacer lo mismo que hace la segunda forma normal, también rompe dependencias transitivas.

CUARTA FORMA NORMAL: No incluir registros lógicos dependientes en las tablas que modelen una relación de muchos a muchos

Cuando tenemos una relación de muchos a muchos, se está duplicando información, esto sucede porque tenemos un registro independiente a la tabla en la misma tabla, es decir, que estos registros independientes pueden formar sus propias tablas, rompiendo la relación de muchos a muchos.

QUINTA FORMA NORMAL: Recomponer las tablas

...