Diseño de una base de datos

ANALISIS DE UNA BASE DE DATOS

Si usa un proceso de diseño de base de datos establecido, puede crear de forma rápida y efectiva una base de datos bien diseñada que le proporciona acceso conveniente a la información que desea. Con un diseño sólido tardará menos tiempo en construir la base de datos y obtendrá resultados más rápidos y precisos.

Nota   Los términos "base de datos" y "tabla" no son sinónimos en Visual FoxPro. El término base de datos (archivo .dbc) se refiere a una base de datos relacional que almacena información sobre una o más tablas (archivos .dbf) o vistas.

La clave para obtener un diseño de base de datos eficaz radica en comprender exactamente qué información se desea almacenar y la forma en que un sistema de administración de bases de datos relacionales, como Visual FoxPro, almacena los datos. Para ofrecer información de forma eficiente y precisa, Visual FoxPro debe tener almacenados los datos sobre distintos temas en tablas separadas. Por ejemplo, puede haber una tabla donde sólo se almacenen datos sobre empleados y otra tabla que sólo contenga datos de ventas.

Al organizar los datos de forma apropiada, proporciona flexibilidad a la base de datos y tiene la posibilidad de combinar y presentar información de muchas formas diferentes.

Al diseñar una base de datos, en primer lugar debe dividir la información que desea almacenar como temas distintos y después indicar a Visual FoxPro cómo se relacionan estos temas para que pueda recuperar la información correcta cuando sea necesario. Si mantiene la información en tablas separadas facilitará la organización y el mantenimiento de los datos y conseguirá aplicaciones de alto rendimiento.

A continuación se indican los pasos que hay que seguir en el proceso de diseño de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta sección.

1. Determinar el propósito de la base de datos   Este paso le ayudará a decidir los datos que desea que Visual FoxPro almacene.
2. Determinar las tablas necesarias   Cuando ya conozca claramente el propósito de la base de datos, puede dividir la información en temas distintos, como "Employees" u "Orders". Cada tema será una tabla de la base de datos.
3. Determinar los campos necesarios   Tiene que decidir la información que desea incluir en cada tabla. Cada categoría de información de una tabla se denomina campo y se muestra en forma de columna al examinar la tabla. Por ejemplo, un campo de la tabla Employee podría ser Last_name y otro podría ser Hire_date.
4. Determinar las relaciones   Observe cada tabla y decida cómo se relacionan sus datos con los de las tablas restantes. Agregue campos a las tablas o cree tablas nuevas para clarificar las relaciones, si es necesario.
5. Perfeccionar el diseño   Busque errores en el diseño. Cree las tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los resultados que desea de sus tablas. Haga los ajustes necesarios al diseño.

No se preocupe si se equivoca o si olvida algunos aspectos en el diseño inicial. Piense en él como en un borrador que podrá mejorar posteriormente. Pruebe con datos de ejemplo y con prototipos de los formularios e informes. Con Visual FoxPro resulta sencillo modificar el diseño de la base de datos durante su creación. Sin embargo, es mucho más difícil modificar las tablas cuando ya están llenas de datos y se han generado formularios e informes. Por este motivo, debe asegurarse de tener un diseño sólido antes de llegar demasiado lejos en la programación de una aplicacion

REGLAS DE NORMALIZACION

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Disminuir problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

• Cada tabla debe tener su nombre único.
• No puede haber dos filas iguales. No se permiten los duplicados.
• Todos los datos en una columna deben ser del mismo tipo.

• Relación = tabla
• Registro = registro, o tupla
• Atributo = columna o campo
• Clave = llave o código de identificación
• Clave Candidata = superclave mínima
• Clave Primaria = clave candidata elegida
• Clave Externa = clave ajena o clave foránea
• Clave Alternativa = clave secundaria
• Dependencia Multivaluada = dependencia multivalor
• RDBMS = Del inglés Relational Data Base Management System que significa, Sistema Gestor de Bases de Datos Relacionales.
• 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.

Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la fuente teórica del modelo de base de datos relacional.

Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.

CLAVES

Una clave primaria se ajusta a la definición de identificador, en cuanto a que determina de forma única una instancia de una entidad (Teorey, Lightstone, Nadeau, & Jagadish, 2011).

---

Una clave primaria es un campo o grupo de campos que identifica de forma única a cada registro dentro de una tabla (Hernandez, 2013).

---

La clave primaria se utiliza para identificar a un registro de manera única. También se le conoce como identificador de la entidad. Cuando más de un elemento dato se utiliza para identificar a un registro, se le denomina clave concatenada (Singh, 2011).

Una clave secundaria se ajusta a la definición de un descriptor, en cuanto a que no es necesariamente única para cada instancia de una entidad (Teorey, Lightstone, Nadeau, & Jagadish, 2011).

---

Cuando determinas que dos tablas guardan una relación entre sí, generalmente estableces la relación tomando una copia de la clave primaria de la primer tabla y la incorporas dentro de la estructura de la segunda tabla, donde se convierte en una clave secundaria. El nombre “clave secundaria” se deriva del hecho de que la segunda tabla ya tiene una clave primaria propia, y la clave primaria que estás introduciendo desde la primer tabla es “secundaria” a la segunda tabla (Hernandez, 2013).

---

La clave secundaria se utiliza para identificar todos aquellos registros que tienen una cierta propiedad. Es un atributo o combinación de atributos que no necesariamente sean una clave concatenada, pero que clasifican el conjunto entidad en una característica particular (Singh, 2011).

EXTERNAS E INTERNAS

Restricciones de clave principal

Una tabla suele tener una columna o una combinación de columnas cuyos valores identifican de forma única cada fila de la tabla. Estas columnas se denominan claves principales de la tabla y exigen la integridad de entidad de la tabla. Debido a que las restricciones de clave principal garantizan datos únicos, con frecuencia se definen en una columna de identidad.

Cuando especifica una restricción de clave principal en una tabla, Motor de base de datos exige la unicidad de los datos mediante la creación automática de un índice único para las columnas de clave principal. Este índice también permite un acceso rápido a los datos cuando se usa la clave principal en las consultas. Si se define una restricción de clave principal para más de una columna, puede haber valores duplicados dentro de la misma columna, pero cada combinación de valores de todas las columnas de la definición de la restricción de clave principal debe ser única.

Como se muestra en la siguiente ilustración, las columnas ProductID y VendorID de la tabla Purchasing.ProductVendor forman una restricción de clave principal compuesta para esta tabla. De este modo, se garantiza que todas las filas de la tabla ProductVendor tengan una combinación de ProductID y VendorID. Esto impide la inserción de filas duplicadas.

• Una tabla solo puede incluir una restricción de clave principal.
• Una clave principal no puede superar las 16 columnas y una longitud de clave total de 900 bytes.
• El índice generado por una restricción de clave principal no puede hacer que el número de índices de la tabla supere 999 índices no clúster y 1 índice clúster.
• Si no se especifica si es en clúster o no en clúster para una restricción de clave principal, se usa la disposición en clúster si no hay índices clúster en la tabla.
• Todas las columnas definidas en una restricción de clave principal se deben definir como no NULL. Si no se especifica nulabilidad, la nulabilidad de todas las columnas que participan en una restricción de clave principal se establece en no NULL.
• Si la clave principal se define en una columna de tipo definido por el usuario CLR, la implementación del tipo debe admitir el orden binario.

Restricciones de clave externa

Una clave externa (FK) es una columna o combinación de columnas que se usa para establecer y aplicar un vínculo entre los datos de dos tablas a fin de controlar los datos que se pueden almacenar una tabla de clave externa. En una referencia de clave externa, se crea un vínculo entre dos tablas cuando las columnas de una de ellas hacen referencia a las columnas de la otra que contienen el valor de clave principal. Esta columna se convierte en una clave externa para la segunda tabla.

Por ejemplo, la tabla Sales.SalesOrderHeader tiene un vínculo de clave externa a la tabla Sales.SalesPerson porque existe una relación lógica entre pedidos de ventas y personal de ventas. La columna SalesPersonID de la tabla SalesOrderHeader coincide con la columna de clave principal de la tabla SalesPerson . La columna SalesPersonID de la tabla SalesOrderHeader es la clave externa para la tabla SalesPerson . Al crear esta relación de clave externa, no se puede insertar un valor para SalesPersonID en la tabla SalesOrderHeader si no existe en la tabla SalesPerson .

Una tabla puede hacer referencia a otras 253 tablas y columnas como claves externas (referencias de salida) como máximo. SQL Server 2016 aumenta el límite para la cantidad de otras tablas y columnas que pueden hacer referencia a las columnas de una sola tabla (referencias de entrada) de 253 a 10 000. (Requiere al menos el nivel de compatibilidad 130). El aumento conlleva las siguientes restricciones:

• Mayor que 253 referencias de clave externa solo se admite para operaciones DELETE DML. No se admiten operaciones UPDATE y MERGE.
• Una tabla con una referencia de clave externa a sí misma sigue estando limitada a 253 referencias de clave externa.
• Mayor que 253 referencias de clave externa no está actualmente disponible para índices de almacén de columnas, tablas con optimización para memoria, Stretch Database o tablas de clave externa particionadas.

Índices de restricciones de clave externa

A diferencia de las restricciones de clave principal, la creación una restricción de clave externa no crea automáticamente el índice correspondiente. No obstante, la creación manual de un índice en una clave externa suele ser útil por los siguientes motivos:

• Las columnas de clave externa suelen usarse en los criterios de combinación cuando los datos de las tablas relacionadas se combinan en consultas mediante la correspondencia de la columna o columnas de la restricción de clave externa de una tabla y la columna o columnas de la clave única o principal de la otra. Un índice permite al Motor de base de datos buscar con rapidez datos relacionados en la tabla de clave externa. No obstante, no es necesario crear este índice. Pueden combinarse los datos de dos tablas relacionadas aunque no se hayan definido restricciones de clave principal o de clave externa entre ellas, pero una relación de clave externa entre dos tablas indica que estas se han optimizado para su combinación en una consulta que use las claves como criterio.
• Los cambios en las restricciones de clave principal se comprueban con restricciones de clave externa en las tablas relacionadas.

Integridad referencial

Aunque el fin principal de una restricción de clave externa es controlar los datos que pueden almacenarse en la tabla de la clave externa; también controla los cambios realizados en los datos de la tabla de la clave principal. Por ejemplo, si se elimina la fila de un vendedor de la tabla Sales.SalesPerson y el identificador del vendedor se usa para pedidos de ventas en la tabla Sales.SalesOrderHeader , se rompe la integridad relacional entre ambas tablas: los pedidos del vendedor eliminado quedarán sin correspondencia en la tabla SalesOrderHeader sin ningún vínculo con los datos de la tabla SalesPerson .

Con una restricción de clave externa se evita esta situación. Esta restricción exige la integridad referencial al garantizar que no se puedan realizar cambios en los datos de la tabla de la clave principal si esos cambios anulan el vínculo con los datos de la tabla de la clave externa. Si se intenta eliminar la fila de una tabla de la clave principal o cambiar un valor de clave principal, la acción no progresará si el valor de la clave principal cambiado o eliminado corresponde a un valor de la restricción de clave externa de otra tabla. Para cambiar o eliminar una fila de una restricción de clave externa, debe antes eliminar o cambiar los datos de clave externa de la tabla de clave externa, lo que vincula la clave externa con otros datos de clave principal.

Integridad referencial en cascada

Las restricciones de integridad referencial en cascada permiten definir las acciones que Motor de base de datos lleva a cabo cuando un usuario intenta eliminar o actualizar una clave a la que apuntan las claves externas existentes. Se pueden definir las acciones en cascada.

NO ACTION
Motor de base de datos genera un error y se revierte la acción de eliminación o actualización de la fila de la tabla primaria.

CASCADE
Si esa fila se actualiza o elimina en la tabla primaria, las filas correspondientes se actualizan o eliminan en la tabla de referencia. CASCADE no se puede especificar si una columna timestamp es parte de una clave externa o de la clave con referencia. ON DELETE CASCADE no se puede especificar en una tabla que tenga un desencadenador INSTEAD OF DELETE. No se puede especificar ON UPDATE CASCADE para las tablas que tienen desencadenadores INSTEAD OF UPDATE.

SET NULL
Cuando se actualiza o elimina la fila correspondiente en la tabla primaria, todos los valores que componen la clave externa se establecen en NULL. Para que esta restricción se ejecute, las columnas de clave externa deben aceptar valores NULL. No se puede especificar para las tablas que tienen desencadenadores INSTEAD OF UPDATE.

SET DEFAULT
Todos los valores que forman la clave externa se establecen en los valores predeterminados si se actualiza o elimina la fila correspondiente de la tabla primaria. Para que esta restricción se ejecute, todas las columnas de clave externa deben tener definiciones predeterminadas. Si una columna acepta valores NULL y no se ha establecido un valor predeterminado explícito, NULL se convierte en el valor predeterminado explícito de dicha columna. No se puede especificar para las tablas que tienen desencadenadores INSTEAD OF UPDATE.

CASCADE, SET NULL, SET DEFAULT y NO ACTION se pueden combinar en las tablas con relaciones referenciales entre sí. Si el Motor de base de datos detecta NO ACTION, detiene y revierte las acciones CASCADE, SET NULL y SET DEFAULT relacionadas. Cuando una instrucción DELETE hace que se combinen las acciones CASCADE, SET NULL, SET DEFAULT y NO ACTION, todas las acciones CASCADE, SET NULL y SET DEFAULT se aplican antes de que el Motor de base de datos compruebe la existencia de NO ACTION.

Desencadenadores y acciones referenciales en cascada

Las acciones referenciales en cascada activan los desencadenadores AFTER UPDATE o AFTER DELETE de la siguiente manera:

• Primero se realizan todas las acciones referenciales en cascada generadas directamente por las instrucciones DELETE o UPDATE originales.
• Si se ha definido algún desencadenador AFTER en las tablas afectadas, estos desencadenadores se activan una vez realizadas todas las acciones en cascada. Estos desencadenadores se activan en el orden contrario a la acción en cascada. Si hay varios desencadenadores en una sola tabla, se activan en un orden aleatorio a no ser que el primer o último desencadenador de la tabla sea un desencadenador dedicado. Este orden es como se especifica mediante sp_settriggerorder.
• Si varias cadenas en cascada se originan desde la tabla que era el objetivo directo de una acción UPDATE o DELETE, el orden en que estas cadenas activan sus respectivos desencadenadores no está especificado. Sin embargo, una cadena siempre activa todos sus desencadenadores antes que otra cadena inicie la activación.
• Un desencadenador AFTER en la tabla que es el objetivo directo de una acción UPDATE o DELETE se activa independientemente de si afecta a alguna fila. En este caso, ninguna otra tabla se ve afectada por la cascada.
• Si alguno de los desencadenadores anteriores realiza operaciones UPDATE o DELETE en otras tablas, estas acciones pueden iniciar cadenas en cascada secundarias. Estas cadenas secundarias se procesan a la vez para cada operación UPDATE o DELETE una vez activados todos los desencadenadores de todas las cadenas principales. Este proceso puede repetirse recursivamente para las operaciones UPDATE o DELETE posteriores.
• Realizar CREATE, ALTER, DELETE u otras operaciones de lenguaje de definición de datos (DDL) dentro de los desencadenadores puede causar la activación de los desencadenadores DDL. Esto puede hacer que se lleven a cabo operaciones DELETE o UPDATE que inician cadenas y desencadenadores en cascada adicionales.
• Si se genera un error en una cadena de acción referencial en cascada determinada, se produce un error, no se activa ningún desencadenador AFTER en esa cadena y la operación DELETE o UPDATE que ha creado la cadena se revierte.
• Una tabla con un desencadenador INSTEAD OF no puede tener también una cláusula REFERENCES que especifique un acción en cascada. Sin embargo, un desencadenador AFTER de la tabla de destino de una acción en cascada puede ejecutar una instrucción INSERT, UPDATE o DELETE en otra tabla o vista que active un desencadenador INSTEAD OF definido para dicho objeto.

INTEGRIDAD REFERENCIAL

La integridad referencial es un sistema de reglas que utilizaAccess 2010 para asegurarse que las relaciones entre registros de tablas relacionadas son válidas y que no se borren o cambien datos relacionados de forma accidental.

DISPERADORES Y INDICES

ecordando algunas utilidades de una base de datos hoy hablaré de una en particular: los Disparadores o Triggers.

Un Disparador o Trigger es una rutina autónoma asociada con una tabla o vista que automáticamente realiza una acción cuando una fila en la tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra (DELETE).  Un Disparador nunca se llama directamente, en cambio, cuando una aplicación o usuario intenta insertar, actualizar, o anular una fila en una tabla, la acción definida en el disparador se ejecuta automáticamente (se dispara).

Las ventajas de usar los Disparadores son:

• La entrada en vigor automática de restricciones de los datos, hace que los usuarios entren sólo valores válidos.
• El mantenimiento de la aplicación se reduce, los cambios a un disparador se refleja automáticamente en todas las aplicaciones que tienen que ver con la tabla sin la necesidad de recompilar o relinquear.
• Logs automáticos de cambios a las tablas. Una aplicación puede guardar un registro corriente de cambios, creando un disparador que se active siempre que una tabla se modifique.
• La notificación automática de cambios a la Base de Datos con alertas de evento en los disparadores.

Los Dispararores tienen dos palabras clave, OLD y NEW que se refieren a los valores que tienen las columnas antes y después de la modificación.  Los INSERT permiten NEW, los DELETE sólo OLD y los UPDATE ambas.

Un ejemplo de un disparador seria uno asociado a la sentencia DELETE en una tabla de clientes, para impedir que se elimine uno que tenga un saldo distinto de cero.  Otro disparador seria guardar los datos que se modifican de un cliente en otra base de datos que serviria de auditoria.

RELACIONES

Office Access 2007 usa relaciones de tablas para decidir cómo combinar las tablas si hay que usarlas en un objeto de base de datos. ... Las relaciones de tabla son la base con la que exigir integridad referencial y evitar los registros huérfanos en la base de datos.