Normalización de Base de Datos

El proceso de normalización de bases de datos 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.

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.

Primera Forma Normal (1FN)

Una tabla está en Primera Forma Normal si:

• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples e indivisibles.
• La tabla contiene una clave primaria única.
• La clave primaria no contiene atributos nulos.
• No debe existir variación en el número de columnas.
• Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
• Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados

Esta forma normal elimina los valores repetidos dentro de una Base de Datos.

Segunda Forma Normal (2FN)

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal). Por ejemplo {DNI, ID_PROYECTO}  HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente funcional dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO  HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO}  NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI  NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

Estas tres son las que más vamos a utilizar ya que con estos 3 pasos por así decirlo ya tendriamos una base de datos funcional al 99.9% :3

Vistas y Procedimientos SQL

VISTAS

Crea una tabla virtual cuyo contenido (columnas y filas) se define mediante una consulta. Utilice esta instrucción para crear una vista de los datos de una o varias tablas de la base de datos. Por ejemplo, una vista se puede utilizar para lo siguiente:

• Para centrar, simplificar y personalizar la percepción de la base de datos para cada usuario.
• Como mecanismo de seguridad, que permite a los usuarios obtener acceso a los datos por medio de la vista, pero no les conceden el permiso de obtener acceso directo a las tablas base subyacentes de la vista.
• Para proporcionar una interfaz compatible con versiones anteriores para emular una tabla cuyo esquema ha cambiado.

Sintaxis

CREATE VIEW [ schema_name . ] view_name [ (column [ ,...n ] ) ] 
[ WITH <view_attribute> [ ,...n ] ] 
AS select_statement 
[ WITH CHECK OPTION ] 
[ ; ]

<view_attribute> ::= 
{
    [ ENCRYPTION ]
    [ SCHEMABINDING ]
    [ VIEW_METADATA ]     
} 

Ejemplo

USE AdventureWorks2012 ;
GO
IF OBJECT_ID ('Purchasing.PurchaseOrderReject', 'V') IS NOT NULL
    DROP VIEW Purchasing.PurchaseOrderReject ;
GO
CREATE VIEW Purchasing.PurchaseOrderReject
WITH ENCRYPTION
AS
SELECT PurchaseOrderID, ReceivedQty, RejectedQty, 
    RejectedQty / ReceivedQty AS RejectRatio, DueDate
FROM Purchasing.PurchaseOrderDetail
WHERE RejectedQty / ReceivedQty > 0
AND DueDate > CONVERT(DATETIME,'20010630',101) ;
GO

                                                                     Procedimientos


En este tema se describe cómo se crea un procedimiento almacenado de Transact-SQL mediante SQL Server Management Studio y la instrucción CREATE PROCEDURE de Transact-SQL.
Requiere el permiso CREATE PROCEDURE en la base de datos y el permiso ALTER en el esquema en el que se va a crear el procedimiento.


Ejemplo


USE AdventureWorks2012;
GO
CREATE PROCEDURE HumanResources.uspGetEmployeesTest2 
    @LastName nvarchar(50), 
    @FirstName nvarchar(50) 
AS 

    SET NOCOUNT ON;
    SELECT FirstName, LastName, Department
    FROM HumanResources.vEmployeeDepartmentHistory
    WHERE FirstName = @FirstName AND LastName = @LastName
    AND EndDate IS NULL;
GO

Disparadores SQL

Los Triggers o Disparadores son objetos que se asocian con tablas y se almacenan en la base de datos. Su nombre se deriva por el comportamiento que presentan en su funcionamiento, ya que se ejecutan cuando sucede algún evento sobre las tablas a las que se encuentra asociado. Los eventos que hacen que se ejecute un trigger son las operaciones de inserción (INSERT), borrado (DELETE) o actualización (UPDATE), ya que modifican los datos de una tabla.

La utilidad principal de un trigger es mejorar la administración de la base de datos, ya que no requieren que un usuario los ejecute. Por lo tanto, son empleados para implementar las REGLAS DE NEGOCIO (tipo especial de integridad) de una base de datos. Una Regla de Negocio es cualquier restricción, requerimiento, necesidad o actividad especial que debe ser verificada al momento de intentar agregar, borrar o actualizar la información de una base de datos. Un trigger puede prevenir errores en los datos, modificar valores de una vista, sincronizar tablas, entre otros.

Son usados para mejorar la administración de la Base de datos, sin necesidad de contar con que el usuario ejecute la sentencia de SQL. Además, pueden generar valores de columnas, previene errores de datos, sincroniza tablas, modifica valores de una vista, etc. Permite implementar programas basados en paradigma lógico (sistemas expertos, deducción).

Estructura

• Llamada de activación: es la sentencia que permite "disparar" el código a ejecutar.
• Restricción: es la condición necesaria para realizar el código. Esta restricción puede ser de tipo condicional o de tipo nulidad.
• Acción a ejecutar: es la secuencia de instrucciones a ejecutar una vez que se han cumplido las condiciones iniciales

Ejemplo

CREATE TRIGGER insertar_tabla

BEFORE UPDATE ON tabla_almacen

FOR ALL records

IF New.producto < 100 then 

      INSERT INTO tabla_pedidos(Producto) VALUES ('1000');

END IF;

SELECT DBO.POLVE.TEST

END

Constraints SQL

Son usados para especificar reglas para los datos de la tabla.
si hay una violación entre la acción de los datos y la constraints, la accion es abortada por el constraints.

Los constraints pueden ser especificado cuando la tabla es creada(en el comando de CREATE TABLE) o despues de crearla con (ALTER TABLE).

Syntaxis

CREATE TABLE table_name
(
column_name1 data_type(size) constraint_name,
column_name2 data_type(size) constraint_name,
column_name3 data_type(size) constraint_name,
....
);

CREATE TYPE

Crea un alias de tipo de datos o un tipo definido por el usuario en la base de datos actual en SQL Server o Base de datos SQL de Azure. La implementación de un alias de tipo de datos se basa en un tipo nativo del sistema de SQL Server. Un tipo definido por el usuario se implementa a través de una clase de un ensamblado de Common Language Runtime (CLR) de Microsoft .NET Framework. Para enlazar un tipo definido por el usuario a su implementación, el ensamblado CLR que contiene la implementación del tipo se debe registrar primero en SQL.

Para seleccionar tipos de datos y equilibrar el tamaño de almacenamiento
con los requisitos, tenga en cuenta las directrices siguientes:

• „ Si la longitud de la columna varía, utilice uno de los tipos de datos variables. Por ejemplo, si tiene una lista de nombres, puede definirlos como varchar en lugar de char (fijo).
• „ Si es dueño de un próspero negocio de venta de libros con filiales en muchos lugares y ha especificado el tipo de datos tinyint para el identificador de cada librería en la base de datos, puede tener problemas cuando decida abrir la librería número 256.
• „ Para los tipos de datos numéricos, el tamaño y el nivel de precisión requeridos determinan su elección. En general, utilice decimal.
• „ Si el almacenamiento es superior a 8000 bytes, utilice text o image. Si es inferior a 8000, utilice binary o char. Cuando sea posible, lo mejor es utilizar varchar porque tiene mayor funcionalidad que text e image.
• „ Para la moneda utilice el tipo de datos money. „ No utilice los tipos de datos aproximados float y real como claves principales. Debido a que los valores de estos tipos de datos no son exactos, no es adecuado utilizarlos en comparaciones. 

EJEMPLO

CREATE TYPE LocationTableType AS TABLE 
    ( LocationName VARCHAR(50)
    , CostRate INT );
GO

Esquema SQL

Limitaciones y restricciones

El esquema nuevo es propiedad de una de las siguientes entidades de seguridad de nivel de base de datos: usuario de base de datos, rol de base de datos o rol de aplicación. Los objetos creados dentro de un esquema son propiedad del esquema y tienen un principal_id NULL en sys.objects. La propiedad de los objetos incluidos en el esquema puede transferirse a cualquier entidad de seguridad de nivel de base de datos, pero el propietario del esquema siempre mantiene el permiso CONTROL en los objetos del esquema.

Cuando se crea un objeto de base de datos, si especifica una entidad de seguridad de dominio válida (usuario o grupo) como la propietaria del objeto, la entidad de seguridad de dominio se agregará a la base de datos como esquema. Esa entidad de seguridad de dominio será la propietaria del nuevo esquema.

EJEMPLO

USE AdventureWorks2012;
GO
CREATE SCHEMA Sprockets AUTHORIZATION Annik
    CREATE TABLE NineProngs (source int, cost int, partnumber int)
    GRANT SELECT ON SCHEMA::Sprockets TO Mandar
    DENY SELECT ON SCHEMA::Sprockets TO Prasanna;
GO 

FileGroups

Como mínimo, todas las bases de datos de SQL Server tienen dos archivos del sistema operativo: un archivo de datos y un archivo de registro. Los archivos de datos contienen datos y otros objetos, como tablas, índices, procedimientos almacenados y vistas. Los archivos de registro contienen la información necesaria para recuperar todas las transacciones de la base de datos. Los archivos de datos se pueden agrupar en grupos de archivos para su asignación y administración.

Archivos de la base de datos

Grupos de archivos

Cada base de datos tiene un grupo de archivos principal. Este grupo de archivos contiene el archivo de datos principal y cualquier otro archivo secundario que no se encuentre en otro grupo de archivos. Se pueden crear grupos de archivos definidos por el usuario para agrupar archivos con fines administrativos y de asignación y ubicación de datos.

Por ejemplo, tres archivos, Data1. ndf, Data2. ndf, y Data3. ndf, puede crearse en tres unidades de disco, respectivamente, y asignarse al grupo de archivos grArchivos1. A continuación, se puede crear una tabla específicamente para el grupo de archivos grArchivos1. Las consultas de datos de la tabla se distribuirán por los tres discos, con lo que mejorará el rendimiento. Puede obtenerse la misma mejora del rendimiento con un solo archivo creado en un conjunto de bandas RAID (matriz redundante de discos independientes). No obstante, los archivos y grupos de archivos permiten agregar fácilmente nuevos archivos a discos nuevos.

Todos los archivos de datos se almacenan en los grupos de archivos que se indican en la tabla siguiente.