Resume SQL Server

DBMS
Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el almacenamiento,
modificación y extracción de la información en una base de datos. Los usuarios pueden acceder a la información
usando herramientas específicas de consulta y de generación de informes, o bien mediante aplicaciones al efecto.
Estos sistemas también proporcionan métodos para mantener la integridad de los datos, para administrar el acceso
de usuarios a los datos y para recuperar la información si el sistema se corrompe. Permiten presentar la información
de la base de datos en variados formatos. La mayoría incluyen un generador de informes. También pueden incluir un
módulo gráfico que permita presentar la información con gráficos y tablas.
Generalmente se accede a los datos mediante lenguajes de consulta, lenguajes de alto nivel que simplifican la tarea
de construir las aplicaciones. También simplifican las consultas y la presentación de la información. Un SGBD permite
controlar el acceso a los datos, asegurar su integridad, gestionar el acceso concurrente a ellos, recuperar los datos tras
un fallo del sistema y hacer copias de seguridad. Las bases de datos y los sistemas para su gestión son esenciales para
cualquier área de negocio, y deben ser gestionados con esmero.
• Almacena y recupera datos de las tablas de la BD
• Interacciona con Usuarios, otras apps, BD
• Crea BD
• Mantiene la BD
• Analiza datos: Consultas (ordenar, seleccionar), Crea reportes
• Manipula los datos: Insertar, editar, borrar

Trasacciones

1. ¿Qué son las transacciones?

Las transacciones en SQL son unidades o secuencias de trabajo realizadas de forma ordenada y separada en una base
de datos. Normalmente representan cualquier cambio en la base de datos, y tienen dos objetivos principales:
• Proporcionar secuencias de trabajo fiables que permitan poder recuperarse fácilmente ante errorres y
mantener una base de datos consistente incluso frente a fallos del sistema.
• Proporcionar aislamiento entre programas accediendo a la vez a la base de datos.
Una transacción es una propagación de uno o más cambios en la base de datos, ya sea cuando se crea, se modifica o
se elimina un registro. En la práctica suele consistir en la agrupación de consultas SQL y su ejecución como parte de
una transacción.
2. Propiedades de las transacciones
Las transacciones siguen cuatro propiedades básicas, bajo el acrónimo ACID (Atomicity, Consistency, Isolation,
Durability):
• Atomicidad: aseguran que todas las operaciones dentro de la secuencia de trabajo se completen
satisfactoriamente. Si no es así, la transacción se abandona en el punto del error y las operaciones
previas retroceden a su estado inicial.
• Consistencia: aseguran que la base de datos cambie estados en una transacción exitosa.
• Aislamiento: permiten que las operaciones sean aisladas y transparentes unas de otras.
• Durabilidad: aseguran que el resultado o efecto de una transacción completada permanezca en caso
de error del sistema.
3. Control de las transacciones
Existen tres comandos básicos de control en las transacciones SQL:
• COMMIT. Para guardar los cambios.

1
 • ROLLBACK. Para abandonar la transacción y deshacer los cambios que se hubieran hecho en la
transacción.
• SAVEPOINT. Crea checkpoints, puntos concretos en la transacción donde poder deshacer la transacción
hasta esos puntos.
Los comandos de control de transacciones se usan sólo con INSERT, DELETE y UPDATE. No pueden utilizarse creando
tablas o vaciándolas porque las operaciones se guardan automáticamente en la base de datos.
Motores transaccionales¿Qué es una base de datos transaccionales?
Una base de datos transaccionales es un sistema de gestión de base de datos relacionales (SGDBR) que funciona de
manera asociada a una base de datos relacional. Su objetivo es asegurar que las transacciones dentro de la BDR se
cumplan al 100% o, en su defecto, se reviertan. Es decir, no permite que las transacciones queden incompletas.
Las bases de datos transaccionales se caracterizan por ejecutar grandes cantidades de transacciones a muy alta
velocidad, ya que solo se encargan del envío y recepción de datos.
Sobresalen en la lectura y escritura de datos individuales y mantienen la integridad de los datos almacenados. Las
bases de datos transaccionales no se construyen específicamente para el análisis de datos.
Sin embargo, a menudo se convierten en entornos analíticos porque ya están implementadas como bases de datos de
producción. Esto, gracias a que han existido por décadas, son comunes, accesibles y eficaces.
Las bases de datos transaccionales se almacenan en el disco como filas, en lugar de columnas. Esto es estupendo ya
que si, por ejemplo, necesitas saber todo acerca de un cliente en la tabla de usuarios, tendrás la opción de tomar solo
los datos que necesitas.Ejemplo de la funcionalidad de una base de datos transaccionales
En cada transferencia bancaria se desarrollan dos operaciones distintas:
• Primero, se debita el dinero en la cuenta de origen.
• Segundo, se suma el dinero en la cuenta de destino.
La base de datos transaccionales es la encargada de validar o deshacer dicha transferencia. Es decir, si ambas
operaciones se completan, entonces la transferencia se registra como finalizada. Si la segunda operación falla, el
dinero se devuelve a la cuenta de origen y la transferencia no se registra en la base de datos.
En este sentido, el sistema gestor de base de datos evita que el dinero desaparezca ante cualquier error
producido, pues garantiza que las dos operaciones se cumplan o no se cumpla ninguna.

Ventajas de una base de datos transaccionales para tu empresa

Aseguran la integridad de los datos

Las bases de datos transaccionales están diseñadas para ser compatibles con ACID, lo que permite que la base de datos
pueda mantener un alto nivel de integridad de los datos que se incluyen en ella. Esto es de vital importancia sobre
todo en las transacciones bancarias y comerciales.
Para los que desconocen el término ACID, es un conjunto de propiedades que describe cómo se diseñan las bases de
datos transaccionales para preservar la integridad de la escritura en la base de datos.
Baja latencia
Debido a que las bases de datos transaccionales están diseñadas para ejecutar sistemas de producción, son muy
buenas en operaciones que deben completarse en milisegundos. En pocas palabras, son increíblemente rápidas.
Monitoreo de sistemas operativos
Si estás tratando de monitorear las cargas de trabajo de soporte o el inventario u otro sistema operativo y necesita
tomar decisiones basadas en datos recientes, replicar la base de datos de producción puede ser la mejor opción.
Y las bases de datos transaccionales pueden realizar esta réplica de forma casi instantánea en tiempo real.
Las principales ventajas de una base de datos transaccionales son:

2
 • Permite modificar la información sin poner en riesgo la integridad de los datos más sensibles del sistema.
• Asegura la integridad de los datos gracias a sus propiedades ACID.
• Brinda una gran capacidad de recuperar el historial de los datos almacenados, reduciendo al máximo el
riesgo de pérdida de datos por fallas en el sistema.
• Organiza, estructura y optimiza los datos dentro de los almacenes de datos empresariales, facilitando
así las consultas complejas.
• Ofrece datos actuales y en tiempo real necesarios para algunos tipos de análisis y posterior toma de
decisiones tácticas.
• Ejecuta las operaciones con muy baja latencia. Es decir, su velocidad de procesamiento es bastante
rápida.
• Realiza réplicas de base de datos de producción en tiempo real para actividades de monitoreo.
• Ayuda a capturar datos sobre el contexto histórico de cada operación, con el fin de facilitar los análisis
posteriores.
• Posee un tamaño relativamente reducido en el caso de que se encargue de archivar datos históricos.
• Aumenta la consistencia del procesamiento de transacciones al integrarse con sistemas de analítica.

Lenguaje SQL en base de datos transaccionales

SQL (Structured Query Language) o Lenguaje de Consulta Estructurada es un lenguaje de programación basado en el
cálculo y el álgebra relacional. Su función es permitir el acceso y la modificación de los datos dentro de una base de
datos o su sistema de gestión.
Hoy en día, el lenguaje SQL es un estándar según el American National Standards Institute (ANSI) y la International
Organization for Standardization (ISO).
Dicha estandarización permite contar con el SQL como un lenguaje en común para una gran cantidad de bases de
datos y sistemas de gestión como la base de datos transaccionales. Esto facilita la intercomunicación entre todos los
productos basados en SQL
Bases de datos transaccionales populares
Aquí te nombramos tres bases de datos transaccionales que puedes probar. Escoge la que más se adapte a tus
necesidades.
• MySQL
• MemSQL
• PostgreSQL

Flat-File Model

Flat File Model A file structure involving data records that have no structured interrelationship. A flat file takes up less
computer space than a structured file but requires the database application to know how the data are organized within
the file.

Base de Datos de archivo plano

Una base de datos de archivo plano es una base de datos almacenada en un archivo llamado archivo plano. Los
registros siguen un formato uniforme y no existen estructuras para indexar o reconocer relaciones entre registros. El
archivo es simple. Un archivo plano puede ser un archivo de texto sin formato o un archivo binario. Las relaciones se
pueden inferir de los datos de la base de datos, pero el formato de la base de datos en sí no hace que esas relaciones
sean explícitas. El término generalmente implica una base de datos pequeña, pero las bases de datos muy grandes
también pueden ser planas. Base de datos de archivo plano - https://es.qaz.wiki/wiki/Flat-file_database

3
Los archivos de texto sin formato suelen contener un registro por línea. Existen diferentes convenciones para
representar datos. En valores separados por comas y valores separados por delimitadores de archivos, los campos
pueden ser separados por delimitadores tales como comas o tabuladores caracteres. En otros casos, cada campo
puede tener una longitud fija; los valores cortos pueden rellenarse con espacios. Puede ser necesario un formato
adicional para evitar la colisión de delimitadores. El uso de delimitadores supone una sobrecarga para localizarlos cada
vez que se procesan (a diferencia del formato de ancho fijo), lo que puede tener implicaciones en el rendimiento. Sin
embargo, el uso de delimitadores de caracteres (especialmente comas) también es una forma burda de compresión
de datos que puede ayudar al rendimiento general al reducir los volúmenes de datos, especialmente para fines de
transmisión de datos. El uso de delimitadores de caracteres que incluyen un componente de longitud (notación
declarativa) es relativamente poco común, pero reduce enormemente la sobrecarga asociada con la ubicación de la
extensión de cada campo. Los ejemplos de archivos planos incluyen /etc/passwdy /etc/groupen sistemas operativos
similares a Unix. Otro ejemplo de un archivo plano es una lista de nombres y direcciones con los campos Nombre,
Dirección y Número de teléfono. Una lista de nombres, direcciones y números de teléfono escritos a mano en una hoja
de papel es una base de datos de archivo plano. Esto también se puede hacer con cualquier máquina de escribir o
procesador de textos. Se puede usar una hoja de cálculo o un programa de edición de texto para implementar una
base de datos de archivo plano, que luego se puede imprimir o usar en línea para mejorar las capacidades de búsqueda.
Base de datos de archivo plano

Implementaciones modernas
Los almacenes lineales de datos NoSQL, datos con formato JSON, hojas de cálculo primitivas (quizás separadas por
comas o delimitadas por tabulaciones) y archivos de texto pueden verse como bases de datos de archivos planos,
porque carecen de índices integrados, referencias integradas entre elementos de datos, o tipos de datos complejos.
Los programas para administrar colecciones de libros o citas y libretas de direcciones pueden utilizar bases de datos
de archivos planos esencialmente de un solo propósito, almacenando y recuperando información de archivos planos
sin adornos con índices o sistemas de señalamiento. Si bien un usuario puede escribir una tabla de contenido en un
archivo de texto, el formato del archivo de texto en sí no incluye el concepto de tabla de contenido. Si bien un usuario
puede escribir "amigos de Kathy" en la sección "Notas" para la información de contacto de John, esto es interpretado
por el usuario en lugar de una característica incorporada de la base de datos. Cuando un sistema de base de datos
comienza a reconocer y codificar relaciones entre registros, comienza a alejarse de ser "plano", y cuando tiene un
sistema detallado para describir tipos y relaciones jerárquicas, ahora está demasiado estructurado para ser
considerado "plano". Base de datos de archivo plano.

Modelo Relacional -> Capitulo 8 Kroenke

Según Internet

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos basado en la lógica de
predicados y en la teoría de conjuntos.

Su idea fundamental es el uso de relaciones. Estas relaciones podrían considerarse en forma lógica como conjuntos
de datos llamados tuplas. Pese a que esta es la teoría de las bases de datos relacionales creadas por Codd, la mayoría
de las veces se conceptualiza de una manera más fácil de imaginar, pensando en cada relación como si fuese
una tabla que está compuesta por registros (cada fila de la tabla sería un registro o "tupla") y columnas (también
llamadas "campos")

4
Descripcion

En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden
en el que estos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto
tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información
puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para
administrar la información.
Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa
una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un
valor que interpretado describe el mundo real. Cada fila también se puede denominar tupla o registro y a cada columna
también se le puede llamar campo o atributo.
Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales
el Álgebra relacional y el Cálculo relacional. El Álgebra relacional permite describir la forma de realizar una consulta,
en cambio, el Cálculo relacional solamente indica lo que se desea devolver.
Ventajas
• Provee herramientas que garantizan evitar la duplicidad de registros.
• Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros relacionados
dependientes.
• Favorece la normalización por ser más comprensible y aplicable.

Desventajas

• Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de información geográfica.
• No se manipulan de forma eficiente los bloques de texto como tipo de dato.
Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de satisfacer las necesidades de las
aplicaciones anteriores y así, complementar, pero no sustituir a las bases de datos relacionales.

Base de datos relacionales

Una base de datos relacional es un conjunto de una o más tablas estructuradas en registros (líneas) y campos
(columnas), que se vinculan entre sí por un campo en común, en ambos casos posee las mismas características como
por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave.
A esta manera de construir bases de datos se le denomina modelo relacional.
Estrictamente hablando el término se refiere a una colección específica de datos pero a menudo se le usa, en forma
errónea como sinónimo del software usado para gestionar esa colección de datos. Ese software se conoce
como sistema gestor de base de datos relacional (SGBD) o en inglés relational database management
system (RDBMS).
Un sistema de software utilizado para mantener las bases de datos relacionales es un relational database management
system (RDBMS) o sistema de gestión de bases de datos relacionales. Virtualmente, todos los sistemas de bases de
datos relacionales utilizan SQL (Structured Query Language) para consultar y mantener la base de datos.

Software propietario y software libre

Llave primaria y Llave foranea

• PK: Es una llave que identifica a una tabla, son unicas
• FK: Es una llave primaria, pero de otra tabla, se utiliza para poder realizar relaciones entre tablas

El modelo relacional
5
 • Logica de predicados
• Teoria de Conjuntos

Lenguaje SQL Basico -> Capitulo 9 kroenke

Resumen dado en clase:

SQL Conceptos elementales

Categorias
• DDL: Data Definicion Language, Creacion de estructuras de datos
• DML: Data Manipulation Language, Creacion y edicion de datos, Consultas y filtrados sobre una tabla
• DCL: Data Control Language

Estandarizacion
• Ansi, ISO, W3C, etc
• Tipos de Datos

SQL: Consultas aisladas, procedimientos, triggers, user function, etc

DDL:
• CREATE
• ALTER
• DROP

Tipos de datos:
• Numeros
• Fechas y Horas
• Caracteres

DML:
• Select
• Insert
• Update
• Delete

Funciones y Operadores
• Una funcion es un conjunto de lineas de codigo que realizan una tarea específica y puede retornar un
valor
• Grupos:
o String Functions
o Numeric Functions
o Date functions
o Aggregate function
o System Functions
o Meta-data functions
• Join - Buscar ejemplos de algun libro
o INNER JOIN - ANSI: Filtra la informacion de entre varias tablas
6
 o Left OUTER JOIN: nos permite obtener los datos de una tabla determinada y los
relacionados de otra tabla
• Subconsultas o consultas anidadas: Son consultas dentro de una consulta, primero resuelve la consulta
interna (1° consulta) y luego sobre el resultado de esa consulta, se realiza la segunda consulta
• ALIAS: Es darle un nombre temporal a una consulta o tabla
• ORDER BY: ordena un listado por la restriccion que nosostros queramos

SQL Server

Microsoft SQL Server es un sistema de gestión de base de datos relacional, desarrollado por la empresa Microsoft.
El lenguaje de desarrollo utilizado (por línea de comandos o mediante la interfaz gráfica de Management Studio)
es Transact-SQL (TSQL), una implementación del estándar ANSI del lenguaje SQL, utilizado para manipular y recuperar
datos (DML), crear tablas y definir relaciones entre ellas (DDL).
Dentro de los competidores más destacados de SQL Server están: Oracle, MariaDB, MySQL, PostgreSQL. SQL Server
ha estado tradicionalmente disponible solo para sistemas operativos Windows de Microsoft, pero desde 2016 está
disponible para GNU/Linux,23 y a partir de 2017 para Docker también.4
Puede ser configurado para utilizar varias instancias en el mismo servidor físico, la primera instalación lleva
generalmente el nombre del servidor, y las siguientes - nombres específicos (con un guion invertido entre el nombre
del servidor y el nombre de la instalación).

Versiones

El código fuente original de SQL Server que fue utilizado en las versiones previas a la versión 7.0 habría sido comprado
de Sybase, pero fue actualizado en las versiones 7.0 y 2000, y reescrito en la versión 2005. Generalmente, cada 2-3
años, una nueva versión es lanzada y, entre estos lanzamientos, se proponen service packs con mejoras y correcciones
de bugs, y hotfixes por problemas urgentes en el sistema de seguridad o bugs críticos.

Caracteristicas

• Soporte de transacciones.
• Soporta procedimientos almacenados.
• Incluye también un entorno gráfico de administración, que permite el uso
de comandos DDL y DML gráficamente.
• Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y
los terminales o clientes de la red sólo acceden a la información.
• Además, permite administrar información de otros servidores de datos.
Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos pero orientado a
proyectos más pequeños, que en sus versiones 2005 y 2008 pasa a ser el SQL Express Edition, que es una edición que
se distribuye en forma gratuita.
Es común desarrollar proyectos completos empleando Microsoft SQL Server y Microsoft Access a través de los
llamados ADP (Access Data Project). De esta forma se completa la base de datos (Microsoft SQL Server), con el entorno
de desarrollo (VBA Access), a través de la implementación de aplicaciones de dos capas mediante el uso de
formularios Windows.
En el manejo de SQL mediante líneas de comando se utiliza el SQLCMD, osql, o PowerShell.
Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL Server incluye interfaces de acceso
para varias plataformas de desarrollo, entre ellas .NET, pero el servidor sólo está disponible para Sistemas Operativos.
El tipo NUMERIC fue mejorado para ser usado como identificador de columna a partir de la versión 2008 R2.

7
Ediciones y servicios

Cada versión de SQL Server posee distintas versiones con distintos precios (para cada versión) que dependen también
en la configuración física del servidor. 13A continuación se presentan las versiones principales:
Enterprise
Contempla todas las características (deshabilitadas en otras ediciones). Es el tipo de versión con más privilegios
existente en el mercado.
Developer
Una edición con las mismas características que la Enterprise, con el fin de ser instalada solamente en ambiente de
desarrollo y no en producción. Si se desarrolla para una edición Standard hay que tener en cuenta las características
deshabilitadas para esta versión.
Standard
Una versión limitada según la configuración del servidor y sus características, diseñada para servidores inferiores.
Por ejemplo: en la versión 2012, la edición Enterprise soporta un número ilimitado de procesadores, y la agregación
de memoria y CPUs en caliente sin la interrupción del servicio o del servidor; mientras la edición Standard está
limitada a 16 procesadores y no soporta la "agregación en caliente".
Express
Una versión gratuita que posibilita la creación de bases de datos limitadas con características básicas, con el fin de
apoyar aplicaciones que necesiten una solución simple para almacenamiento de una cantidad limitada de datos, o
usuarios que sus recursos y necesidades son limitados.
En la versión 2012, esta edición puede utilizar un máximo de 1 GB de memoria, y almacenar no más de 10GB, funciona
en servidores con un número máximo de cuatro procesadores. Estas limitaciones se mantienen en la versión 2014 (4
cores, 1GB ram, y 10Gb por base de datos).
SQL Azure
Es una versión de SQL Server en la nube, que permite pagar mensualmente por el servicio sin la necesidad de mantener
un servidor físico (On Premise). La empresa paga solo por el servicio, y el servicio es manejado a través de torres de
servidores en distintos lugares en el mundo.
Con SQL Azure no es necesario instalar, mantener o actualizar un servidor físico; a pesar de que este servicio depende
de aspectos relacionados con problemas de seguridad con respecto a su presencia fuera de la empresa y a la
disponibilidad de conexión a Internet.
Durante un tiempo, el servicio fue ampliado con la opción de crear un servidor virtual por la red, e instalar SQL Server
tanto como uno de los servicios competidores, y manejar el servidor virtual como si fuera un servidor físico local
(aunque físicamente no está accesible); y se puede diferenciar entre la opción original que esta denominada PAAS
(Platform as a Service: Plataforma como un Servicio) y la nueva opción de los servidores virtuales denominada IAAS
(Infrastructure as a Service: Infraestructura como un Servicio).
Este servicio esta otorgado por Microsoft desde 2009 y se une a servicios similares de empresas de third-party.

Servicios

A contrario de sistemas de bases de datos como Microsoft Access que son "pasivas" y contienen un archivo a cual hay
que conectar y la ejecución de los comandos se lleva a cabo en el cliente (la computadora de usuario), en SQL Server
hay número de servicios, software que están ejecutadas en la memoria del servidor por parte del sistema, y por lo
tanto aprovechan las capacidades del servidor que es más potente que los clientes, previenen congestión en la red, y
pueden programar tareas que corran aunque el cliente no está conectado.
Los servicios principales:
• SQL Server - El "motor" del sistema
• SQL Agent - Ejecución de tareas (Jobs, scripts programados) y envió de advertencias en caso de carga pesada
e irregulares en el sistema
8
 • Full-Text Filter Daemon Launcher - La utilización de los índices especiales del "Full text search" por búsqueda
textual avanzada
• SQL Browser - El "oyente" dedicado a comandos enviados y redirigirlos a su destino
• SSIS Server - La operación del SSIS (la herramienta de ETL)
• SSAS Server - La operación del SSAS (la herramienta de OLAP)
• SSRS Server - La operación del SSRS (la herramienta de informes)

Herramientas de inteligencia empresarial

Una instalación típica incluye también las herramientas de Inteligencia empresarial (en inglés, bussiness
intelligence o BI):
SSIS (SQL Server Integration Services)
Una herramienta de ETL que posibilita la extracción de datos de distintos orígenes (no solo SQL Server), la
transformación de dichos datos, y la carga (generalmente pero no obligatoriamente a almacén de datos).
SSAS (SQL Server Analysis Services)
Una herramienta para crear Bases de Datos Multidimensionales (no relacionales), que se puede explorar mediante
extracciones de datos en distintos niveles de agrupación, profundización (Drill Down) de una suma a sus detalles, y
utilización de MDX (un lenguaje parecido a SQL, adaptado a bases de datos multidimensionales).
SSRS (SQL Server Reporting Services)
Una herramienta para crear y dar formato a informes, otorgar derechos de contemplación en ellos, y su distribución.
Se puede contemplarlos con un Navegador web, y se puede exportarlos a archivos de Excel, PDF, etc. los datos se
extraen generalmente del almacén de datos o del OLAP.

Capacidades y herramientas basicas

Bases de datos
En cada instalación de SQL Server hay 4 bases de datos de sistema, y la capacidad de crear nuevas bases de datos por
el usuario, en los cuales los datos están almacenados en tablas.
Estas bases de datos, creadas por parte de los usuarios, incluyen básicamente un archivo de datos (con el sufijo mdf)
con las tablas y los distintos objetos a nivel de la base de datos; y un archivo de registro (con el sufijo ldf) con las
transacciones abiertas, y transacciones cerradas, Sujeto al modelo de recuperación seleccionado (se puede acumular
en el archivo de registro todos los cambios en la base de datos desde el último respaldo). Se puede crear un conjunto
de archivos de datos además del principal (con el sufijo ndf) por consideraciones de eficiencia, partición de carga de
trabajo entre los discos rígidos, etc.
Las bases de datos del sistema:
• master - Todos los procedimientos, funciones y tablas del sistema que están utilizadas por parte de todas las
bases de datos y que están instaladas automáticamente, tanto como las que han sido creado por parte de los
administradores del sistema. Además, todas las definiciones en respecto a la seguridad a nivel del servidor,
están almacenadas en esta base de datos.
• msdb - Almacenamiento de las tareas del agente, los códigos de CLR combinados en el sistema, los paquetes
de SSIS, y otros más.
• model - El molde de las bases de datos. Cada nueva base de datos se crea como una copia de esta base de
datos, menos que algo más estaba definido explícitamente.
• tempdb - Base de datos temporal que se crea de nuevo cada vez que el servicio reinicia. Se utiliza para
almacenar tablas temporales creadas por parte de los usuarios o el sistema (por ejemplo, en ordenaciones
complejos).
Tablas fijas y temporales
Desde la perspectiva lógica, los datos almacenados en las bases de datos en tablas, que mediante ellas se implementa
la teoría de las bases de datos relacionales. La tabla se divide en filas y columnas (A veces se les conoce como registros
9
y campos). Las tablas pueden ser fijas o temporales, mientras que en el segundo caso existen físicamente en la base
de datos tempdb, y se borran automáticamente en caso de desconexión de la sesión o de la conexión al servidor,
depende en el tipo de la tabla temporal.
Desde la perspectiva física, el sistema divide los archivos de la base datos en Extents de 64 KB, y cada cual a ocho
páginas de 8 KB. Generalmente, cada Extent se asigna a una tabla o un índice, menos las tablas pequeñas; y cada
página se asigna siempre a una tabla específica. El sistema es responsable del aumento de los archivos, de acuerdo
con los ajustes del usuario, y de asignar Extents y páginas a las tablas.
A las tablas se puede crear índices. Los índices se almacenan junto a la tabla (Non Clustered Index) o son la tabla en sí
(Clustered Index). Los índices asisten en la búsqueda de datos en las tablas (como los ficheros en las librerías), en
ordenarlas, y la definición de claves primarias.
Entre las tablas se puede crear una relación de uno a muchos.
Aparte de las tablas de los usuarios, hay tablas que almacenan meta data: datos sobre el sistema mismo, los diferentes
objetos, los derechos, estadísticas sobre el rendimiento del sistema (DMV), etc.
Tipos de dato
Para cada columna en una tabla y a cada variable o parámetro, se define un tipo de datos que sean almacenados en
él, entre ellos:
1. Numeros: Números enteros y no enteros en distintos tamaños, y en diferentes niveles de precisión; y auto
incremento opcional.
2. Textos: Cadenas de distintas longitudes, y distintas capacidades de apoyar distintas lenguas.
3. Fechas: Fechas en distintos niveles de precisión, desde días completos hasta fracciones menores de un
segundo, que apoyan fechas a partir del principio del siglo XX o del calendario gregoriano, y la capacidad de
diferenciar entre distintos usos de horarios.
4. XML: Datos textuales (cadenas) que representan conjuntos estándares de datos (estándar SGML).
5. Datos binarios: Datos almacenados como datos binarios (bits y bytes), que posibilitan el almacenamiento de
archivos gráficos, etc.
6. Geography: Representación estándar de información geográfica, tales como estados, zonas geográficas,
localidades; y los cálculos como distancias.
7. Geometry: Representación estándar de puntas, líneas, superficies en el plano; y las relaciones entre ellas.
8. Hierarchid: Representación estándar de información jerárquica como lista de materiales, relaciones de
subordinación entre empleados, etc.
Vistas
Las vistas representan generalmente comandos de extracción de datos, que se almacenan sin los datos (que están
almacenados en las tablas). Esta opción nos posibilita crear extracciones complejas o estándares, almacenarlas como
vistas, y utilizar las vistas sin la necesidad de escribir de nuevo los comandos o mantener los códigos donde ellas
aparecen. Adicionalmente, es un medio muy importante para otorgar derechos selectivos de lectura (en caso de que
queremos posibilitar a un usuario contemplar parcialmente las columnas o las filas de una tabla).
Una vista se puede considerar una tabla virtual o una consulta almacenada. Los datos accesibles a través de una vista
no están almacenados en un objeto distinto de la base de datos. Lo que está almacenado en la base de datos es una
instrucción SELECT. El resultado de la instrucción SELECT forma la tabla virtual que la vista devuelve. El usuario puede
utilizar dicha tabla virtual haciendo referencia al nombre de la vista en instrucciones Transact-SQL, de la misma forma
en que se hace referencia a las tablas. Las vistas se utilizan para alguna de estas funciones, o para todas:
• Restringir el acceso del usuario a filas concretas de una tabla. Por ejemplo, permitir que un empleado sólo
vea las filas que guardan su trabajo en una tabla de seguimiento de actividad laboral.
• Restringir el acceso del usuario a columnas específicas. Por ejemplo, permitir que los empleados que no
trabajen en el departamento de nóminas vean las columnas de nombre, oficina, teléfono y departamento de
la tabla de empleados, pero no permitir que vean las columnas con los datos de salario u otra información
personal.
• Combinar columnas de varias tablas de forma que parezcan una sola tabla.
10
 • Agregar información en lugar de presentar los detalles. Por ejemplo, presentar la suma de una columna o el
valor máximo o mínimo de una columna.

Las vistas se crean definiendo la instrucción SELECT que recupera los datos presentados por la vista. Las tablas de datos
a las que hace referencia la instrucción SELECT se conocen como las tablas base para la vista. Las vistas en todas las
versiones de SQL Server son actualizables (pueden ser objetivo de instrucciones UPDATE, DELETE o INSERT) mientras
la modificación afecte sólo a una de las tablas base de la vista.

Funciones definidas por el usuario

Las funciones son un objeto que combina algunas capacidades de las vistas, con otras de los procedimientos. Como
las vistas, pueden extraer datos y ejecutar cálculos, y devuelven un resultado al usuario o al programa que les ejecutó.
Tanto como los procedimientos, incluyen códigos de TSQL, y pueden ser ejecutados con parámetros.
Las funciones devuelven un valor o un conjunto de valores.
Las funciones definidas por el usuario se crean con la instrucción CREATE FUNCTION, se modifican con la
instrucción ALTER FUNCTION y se quitan con la instrucción DROP FUNCTION. Todos los nombres de funciones
completos (database_name. owner_name.function_name) definidos por el usuario deben ser únicos. Para crear,
modificar o quitar funciones definidas por el usuario, debe tener permisos de CREATE FUNCTION. Los usuarios
distintos del propietario deben tener permiso EXECUTE para una función, y solo así podrán utilizarla en una instrucción
de Transact-SQL. Para crear o modificar tablas con referencias a funciones definidas por el usuario en la
restricción CHECK, la cláusula DEFAULT o la definición de una columna calculada, también debe tener
permiso REFERENCES para las funciones. Los errores de Transact-SQL que producen la cancelación de una instrucción
y continúan con la siguiente instrucción del módulo, como desencadenadores o procedimientos almacenados, se
tratan de forma distinta dentro de una función. En las funciones, estos errores hacen que se detenga la ejecución de
la función. Esto hace que se cancele la función que invocó la instrucción. Una función definida por el usuario no tiene
ninguno o tiene varios parámetros de entrada y devuelve un valor escalar o una tabla. Una función puede tener un
máximo de 1024 parámetros de entrada. Cuando un parámetro de la función toma un valor predeterminado, debe
especificarse la palabra clave DEFAULT al llamar a la función para poder obtener el valor predeterminado. Este
comportamiento es diferente del de los parámetros con valores predeterminados de los procedimientos almacenados,
para los cuales omitir el parámetro implica especificar el valor predeterminado. Las funciones definidas por el usuario
no admiten parámetros de salida.

Consultas distribuidas
Las consultas distribuidas tienen acceso a datos de varios orígenes, que pueden estar almacenados en un equipo o en
equipos distintos. Microsoft SQL Server 2000 admite las consultas distribuidas a través de OLE DB Las consultas
distribuidas proporcionan a los usuarios de SQL Server acceso a:
• Datos distribuidos almacenados en múltiples instancias SQL Server.
• Datos heterogéneos almacenados en varios orígenes de datos relacionales y no relacionales a los que se tiene acceso
mediante un proveedor OLE DB.
Los proveedores OLE DB exponen datos en objetos tabulares llamados conjuntos de filas. En las instrucciones Transact-
SQL, SQL Server 2000 permite que se haga referencia a los conjuntos de filas de los proveedores OLE DB como si fueran
una tabla de SQL Server. En las instrucciones SELECT, INSERT, UPDATE y DELETE de Transact-SQL, se puede hacer
referencia directa a las tablas y vistas de orígenes de datos externos. Puesto que las consultas distribuidas usan OLE
DB como interfaz subyacente, éstas tienen acceso a los sistemas DBMS relacionales tradicionales con procesadores de
consultas SQL, así como a los datos administrados por orígenes de datos de capacidad y sofisticación diversas. Siempre
que el software propietario de los datos los expone en un conjunto de filas tabular a través del proveedor OLE DB, los
datos se podrán usar en las consultas distribuidas. Nota: El uso de las consultas distribuidas en SQL Server es similar a
la funcionalidad de las tablas vinculadas mediante ODBC, que anteriormente admitía Microsoft Access. Esta
funcionalidad se encuentra ahora integrada en SQL Server con OLE DB como interfaz para los datos externos.
11
Transacciones
Una transacción es un conjunto de comandos, que se está ejecutado completamente o no ejecutado en absoluto: todo
o nada. Por ejemplo, si una suma de dinero fue trasladada de una cuenta bancaria a otra, y hay que actualizar ambas
cuentas sobre el depósito y la retirada; es obligatorio que ambas cuentas se actualicen juntas, o ninguna (en caso de
que una de las actualizaciones falle); para evitar consecuencias inconsistentes de un depósito sin ninguna retirada, o
viceversa. Por lo tanto, una transacción es una secuencia de operaciones realizadas como una sola unidad lógica de
trabajo. Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades ACID
(atomicidad, coherencia, aislamiento y durabilidad), para ser calificada como transacción:
• Atomicidad
Una transacción debe ser una unidad atómica de trabajo, tanto si se realizan todas sus modificaciones en los datos,
como si no se realiza ninguna de ellas.
• Coherencia
Cuando finaliza, una transacción debe dejar todos los datos en un estado coherente. En una base de datos relacional,
se deben aplicar todas las reglas a las modificaciones de la transacción para mantener la integridad de todos los datos.
Todas las estructuras internas de datos, como índices de árbol B o listas doblemente vinculadas, deben estar correctas
al final de la transacción.
• Aislamiento
Las modificaciones realizadas por transacciones simultáneas se deben aislar de las modificaciones llevadas a cabo por
otras transacciones simultáneas. Una transacción ve los datos en el estado en que estaban antes de que otra
transacción simultánea los modificara o después de que la segunda transacción se haya concluido, pero no ve un
estado intermedio. Esto se conoce como seriabilidad debido a que su resultado es la capacidad de volver a cargar los
datos iniciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban
después de realizar las transacciones originales.
• Durabilidad
Una vez concluida una transacción, sus efectos son permanentes en el sistema. Las modificaciones persisten aún en el
caso de producirse un error del sistema.
SQL Server tiene una capacidad limitada de anidar transacciones.

El optimizado
El optimizador es una parte del software que "toma la decisión" de como cada comando se ejecutará, tanto que la
ejecución será lo más eficiente, o por lo menos bastante eficiente (es decir, bastante eficiente para evitar seguir
buscando otra solución, que aún que sea más eficiente, el precio de la búsqueda adicional "costará" más que el ahorro
de recursos).
SQL es un lenguaje declarativo, en el cual el desarrollador declara que quiere extraer o actualizar sin la necesidad de
indicar cómo (a contrario de los lenguajes imperativos, y por lo tanto el optimizador juega un papel protagónico, que
de acuerdo con las estadísticas que el sistema almacena sobre las distribuciones de los datos en las tablas, los índices,
y reglas internas; toma la decisión adecuada.

Instancias del motor de base de datos (SQL Server)

Una instancia de Motor de base de datos es una copia del ejecutable de sqlservr.exe que se ejecuta como un servicio
de sistema operativo. Cada instancia administra varias bases de datos del sistema y una o varias bases de datos de
usuario. Cada equipo puede ejecutar varias instancias de Motor de base de datos. Las aplicaciones se conectan a la
instancia para realizar el trabajo en una base de datos administrada por la instancia.
Instancias
Una instancia de Motor de base de datos funciona como un servicio que controla todas las solicitudes de aplicación
para trabajar con datos de cualquiera de las bases de datos administradas por dicha instancia. Es el destino de las
solicitudes de conexión (inicios de sesión) de aplicaciones. La conexión se ejecuta en una conexión de red si la
12
aplicación y la instancia están en equipos independientes. Si la aplicación y la instancia están en el mismo equipo, la
conexión de SQL Server se puede ejecutar como una conexión de red o una conexión en memoria. Cuando una
conexión se ha completado, una aplicación envía instrucciones Transact-SQL a través de la conexión hasta la
instancia. La instancia resuelve las instrucciones de Transact-SQL en operaciones con los datos y objetos de las bases
de datos y, si se han concedido los permisos necesarios a las credenciales de inicio de sesión, realiza el trabajo. Los
datos recuperados se devuelven a la aplicación, junto con cualesquiera mensajes como errores.
Puede ejecutar múltiples instancias de Motor de base de datos en un equipo. Una instancia puede ser la instancia
predeterminada. La instancia predeterminada no tiene nombre. Si una solicitud de conexión especifica solo el nombre
del equipo, se establece la conexión a la instancia predeterminada. Una instancia con nombre es una instancia en la
que se especifica un nombre de instancia al instalar la instancia. Una solicitud de conexión debe especificar el nombre
del equipo y el nombre de instancia para conectar a la instancia. No hay ningún requisito para instalar una instancia
predeterminada; todas las instancias que se ejecutan en un equipo pueden ser instancias con nombre.

Herramientas de administracion
Las herramientas siguientes proporcionan una interfaz gráfica de usuario (GUI).
Herramienta Descripción Sistema operativo

Azure Data Un editor ligero que puede ejecutar consultas SQL a Windows
Studio petición, ver y guardar resultados como texto, JSON o macOS
Excel. Edite los datos, organice sus conexiones de bases de Linux
datos favoritas y examine los objetos de base de datos en
una experiencia de exploración de objetos conocida.

SQL Server Administre una instancia de SQL Server o una base de datos Windows
Management con compatibilidad completa con GUI. Acceda, configure,
Studio (SSMS) administre y desarrolle todos los componentes de
SQL Server, Azure SQL Database y Azure Synapse
Analytics. Proporciona una única utilidad integral que
combina un amplio grupo de herramientas gráficas con una
serie de editores de script enriquecidos que permiten a
desarrolladores y administradores de bases de datos de
todos los niveles acceder a SQL.

SQL Server Una herramienta de desarrollo moderna para crear bases Windows
Data Tools de datos relacionales de SQL Server, bases de datos de
(SSDT) Azure SQL, modelos de datos de Analysis Services (AS),
paquetes de Integration Services (IS) e informes de
Reporting Services (RS). Gracias a SSDT, puede diseñar e
implementar cualquier tipo de contenido de SQL Server con
la misma facilidad con la que desarrollaría una aplicación
en Visual Studio .

Visual Studio La extensión mssql para Visual Studio Code es la extensión Windows
Code oficial de SQL Server que admite conexiones a SQL Server y macOS
la experiencia de edición enriquecida para T-SQL en Visual Linux
Studio Code. Escriba scripts T-SQL en un editor ligero.

13
Arquitectura de Bases de Datos SQL Server
La arquitectura interna de las bases de datos en SQL Server está compuesta por 2 tipos de estructura, la estructura
lógica y la estructura física. Es muy importante conocer cómo es que estas estructuras están compuestas y cuál es la
relación que tienen los objetos de base de datos con cada una de estas estructuras.

Estructura Lógica:
Desde el punto de vista lógico, la base de datos debe tener al menos 1 “FileGroup” el cual contiene a toda la metadata
de la misma base de datos, es decir tablas y vistas de sistema, a este “FileGroup” inicial se le conoce como “Primario”
y está presente en todas las bases de datos. Todos los objetos de usuario que contengan data ya sean tablas o índices,
deben estar ligados a un “FileGroup”, esto se puede definir al momento de ejecutar la sentencia DDL de creación del
objeto, si no se indica a que “FileGroup” estará ligado ese objeto, este pertenecerá al “FileGroup” por defecto definido
en la base de datos. La base de datos solo puede tener definido 1 solo default “FileGroup”.
Las bases de datos pueden tener hasta 32767 “FileGroups” definidos, según los límites establecidos para la última
versión de SQL Server, la cual es SQL Server 2008 R2. Uno de los propósitos de los “FileGroups” es poder distribuir la
data a través de varios discos duros físicos, de esta manera se puede obtener mayor rendimiento en las operaciones
de I/O debido a que más de un disco trabajara al mismo tiempo. Otro de los propósitos es poder esconder la ubicación
física real de la información a los programadores, ya que para ellos la tabla “X” pertenece al “FileGroup” “A”, pero no
saben en que data files físicamente se encuentra la información de la tabla “X”.
Los “FileGroups” pueden contener 1 o más “Datafiles”, y cada uno de estos datafiles se pude encontrar en un disco
diferente, lo cual también agilizará las consultas y los ingresos de información a las tablas que se encuentren asignadas
a este “FileGroup”, debido a que SQL Server distribuirá la información uniformemente a través de todos los “DataFiles”
del “FileGroup”.

Estructura Física:
Desde el punto de vista físico, como ya hemos visto, tenemos los “DataFiles” que los en realidad los archivos de datos,
es decir donde se guarda toda la información de la base de datos. Un “DataFile” solo puede pertenecer a 1 “FileGroup”.
Internamente los “DataFiles” están divididos en “Extends” y estos a su vez en “Pages”. Las “Pages” son la unidad
minima de almacenamiento dentro de la base de datos. Un “Page” tiene 8 Kb de tamaño en espacio de disco. Un
“Extend” tiene 8 “Pages” contiguas que lo conforman, es decir, un “Extend” tiene como tamaño 64 Kb de espacio en
disco.
En un “Page” solo puede haber información de 1 sola tabla, es decir el espacio de un “Page” no es compartido entre
tablas o índices. En el caso de los “Extends”, estos pueden ser de dos tipos:
14
 • “Mixed”: Los cuales son compartidos hasta por 8 objetos, uno por cada “Page”.
• “Uniform”: Los cuales solo pertenecen a un solo objeto, es decir que todos los “Pages” pertenecen a un solo
objeto.
Normalmente cuando se crea una nueva tabla esta es asignada a un “Extend” de tipo “Mixed”, hasta alcanzar la
utilización de hasta 8 “Pages”, a partir de ese momento se asignan “Extends” de tipo “Uniform” para optimizar el uso
del espacio en la tabla.
Los “DataFiles” normalmente tienen 2 extensiones de archivo, las cuales son estandar mas no obligarias, la extencion
“mdf” que se utiliza para el primer “Datafile” perteneciente al “FileGroup” primario, y la extension “ndf” que se utiliza
para los demas datafiles que se agregan posteriormente a los demas “FileGroups” de la base de datos.
En el caso del “LogFile”, este no pertenece a un “FileGroup” en específico, en cambio archivo está ligado directamente
a la base de datos. Las bases de datos de SQL Server solo pueden tener un solo “LogFile” activo al mismo tiempo, si
bien se pueden crear multiples “LogFiles” en la base de datos, solo uno podra ser escrito, ya que solo uno puede estar
activo, cuando este archivo se llene, la base de datos pasara a escribir al siguiente archivo de transacciones, y asi
sucesivamente. Por esta razon no es muy conveniente ni util tener más de un “LogFile”.
En conclusión, espero que sea de ayuda estas explicaciones sobre la arquitectura de una base de datos de SQL Server,
si desean temas por favor no duden en solicitarlo, haré lo posible para poder cubrir los temas solicitados en el más
corto tiempo.

Roles de bases de datos - Roles de Servidor

Para administrar con facilidad los permisos en las bases de datos, SQL Server proporciona varios roles, que son las
entidades de seguridad que agrupan a otras entidades de seguridad. Son como los grupos del sistema
operativo Microsoft Windows. Los roles de nivel de base de datos se aplican a toda la base de datos en lo que respecta
a su ámbito de permisos.

Existen dos tipos de roles en el nivel de base de datos: los roles fijos de base de datos que están predefinidos en la
base de datos y los roles de base de datos definidos por el usuario que el usuario puede crear.
Los roles fijos de base de datos se definen en el nivel de base de datos y existen en cada una de ellas. Los miembros
de los roles de base de datos db_owner pueden administrar la pertenencia a roles fijos de base de datos. También hay
algunos roles de base de datos con fines especiales en la base de datos msdb.
Puede agregar cualquier cuenta de la base de datos y otros roles de SQL Server a los roles de nivel de base de datos.

Los permisos de los roles de base de datos definidos por el usuario se pueden personalizar con las instrucciones
GRANT, DENY y REVOKE. Los permisos de nivel de servidor no se pueden conceder a los roles de base de datos. Los
inicios de sesión y otras entidades de seguridad a nivel de servidor [como roles de servidor] no se pueden agregar a
los roles de base de datos. Para la seguridad a nivel de servidor en SQL Server, use en su lugar roles de servidor . Los
permisos de nivel de servidor no se pueden conceder a través de roles en SQL Database y Azure Synapse.

Roles fijos de base de datos

En la tabla siguiente se muestran los roles fijos de base de datos y sus funcionalidades. Estos roles existen en todas las
bases de datos. A excepción del rol de base de datos public, no se pueden cambiar los permisos asignados a los roles
fijos de base de datos.
Nombre del rol fijo de base de Descripción
datos

db_owner Los miembros del rol fijo de base de datos db_owner pueden realizar todas las
actividades de configuración y mantenimiento en la base de datos y también
pueden quitar la base de datos en SQL Server. (En SQL Database y Azure Synapse,

15
 algunas actividades de mantenimiento requieren permisos de nivel de servidor y
los roles db_owners no las pueden realizar).

db_securityadmin Los miembros del rol fijo de base de datos db_securityadmin pueden modificar la
pertenencia a roles únicamente para roles personalizados y administrar
permisos. Los miembros de este rol pueden elevar potencialmente sus privilegios
y se deben supervisar sus acciones.

db_accessadmin Los miembros del rol fijo de base de datos db_accessadmin pueden agregar o
quitar el acceso a la base de datos para inicios de sesión de Windows, grupos de
Windows e inicios de sesión de SQL Server.

db_backupoperator Los miembros del rol fijo de base de datos db_backupoperator pueden crear copias
de seguridad de la base de datos.

db_ddladmin Los miembros del rol fijo de base de datos db_ddladmin pueden ejecutar cualquier
comando del lenguaje de definición de datos (DDL) en una base de datos.

db_datawriter Los miembros del rol fijo de base de datos db_datawriter pueden agregar, eliminar
o cambiar datos en todas las tablas de usuario.

db_datareader Los miembros del rol fijo de base de datos db_datareader pueden leer todos los
datos de todas las tablas de usuario.

db_denydatawriter Los miembros del rol fijo de base de datos db_denydatawriter no pueden agregar,
modificar ni eliminar datos de tablas de usuario de una base de datos.

db_denydatareader Los miembros del rol fijo de base de datos db_denydatareader no pueden leer
datos de las tablas de usuario dentro de una base de datos.

Trabajar con roles de nivel de base de datos

En la tabla siguiente se explican los comandos, las vistas y las funciones que se usan para trabajar con los roles de nivel
de base de datos.
Característica Tipo Descripción

sp_helpdbfixedrole (Transact-SQL) Metadatos Devuelve la lista de los roles fijos de base de datos.

sp_dbfixedrolepermission Metadatos Muestra los permisos de un rol fijo de base de

(Transact-SQL) datos.

sp_helprole (Transact-SQL) Metadatos Devuelve información acerca de los roles de la base

de datos actual.

sp_helprolemember (Transact- Metadatos Devuelve información acerca de los miembros de

SQL) un rol de la base de datos actual.

sys.database_role_members Metadatos Devuelve una fila por cada miembro de cada rol de
(Transact-SQL) base de datos.

IS_MEMBER (Transact-SQL) Metadatos Indica si el usuario actual es miembro del grupo de

Microsoft Windows o del rol de base de datos de
SQL Server especificados.

16
 CREATE ROLE (Transact-SQL) Get-Help Crea un rol de base de datos nuevo en la base de
datos actual.

ALTER ROLE (Transact-SQL) Get-Help Cambia el nombre o la pertenencia de un rol de

base de datos.

DROP ROLE (Transact-SQL) Get-Help Quita un rol de la base de datos.

sp_addrole (Transact-SQL) Get-Help Crea un rol de base de datos nuevo en la base de

datos actual.

sp_droprole (Transact-SQL) Get-Help Quita un rol de base de datos de la base de datos

actual.

sp_addrolemember (Transact- Get-Help Agrega un usuario de base de datos, un rol de base

SQL) de datos, un inicio de sesión de Windows o un
grupo de Windows a un rol de base de datos en la
base de datos actual. Todas las plataformas,
excepto Almacenamiento de datos paralelos y
Azure Synapse, deben usar ALTER ROLE en su lugar.

sp_droprolemember (Transact- Get-Help Quita una cuenta de seguridad de un rol de SQL

SQL) Server de la base de datos actual. Todas las
plataformas, excepto Almacenamiento de datos
paralelos y Azure Synapse, deben usar ALTER
ROLE en su lugar.

GRANT Permisos Agrega el permiso a un rol.

DENY Permisos Deniega un permiso a un rol.

REVOKE Permisos Quita un permiso concedido o denegado

anteriormente.

Rol de base de datos public

Todos los usuarios de una base de datos pertenecen al rol de base de datos publics. Cuando a un usuario no se le han
concedido ni denegado permisos específicos para un objeto protegible, el usuario hereda los permisos concedidos a
la función pública para ese objeto. Los usuarios de base de datos no se pueden quitar del rol public.

Roles de servidor y base de datos en SQL Server

Todas las versiones de SQL Server usan la seguridad basada en roles, que permite asignar permisos a un rol, o grupo
de usuarios, en lugar de asignarlos a usuarios individuales. Los roles fijos de servidor y base de datos cuentan con un
conjunto fijo de permisos asignados.
Roles fijos de servidor
Los roles fijos de servidor cuentan con un conjunto fijo de permisos y ámbito de servidor. Están pensadas para su uso
en la administración de SQL Server y los permisos asignadas a ellas no se pueden modificar. Se pueden asignar inicios
de sesión a los roles fijos de servidor sin necesidad de disponer de una cuenta de usuario en una base de datos.
Importante
El rol fijo de servidor sysadmin incluye a todos los demás roles y cuenta con un ámbito ilimitado. No agregue entidades
de seguridad a este rol a menos que sean de total confianza. Los miembros del rol sysadmin disponen de permisos
administrativos irrevocables en todas las bases de datos y recursos del servidor.
17
Sea selectivo a la hora de agregar usuarios a los roles fijos de servidor. Por ejemplo, el rol bulkadmin permite a los
usuarios insertar el contenido de cualquier archivo local en una tabla, lo que puede poner en peligro la integridad de
los datos. Consulte Libros en pantalla de SQL Server para obtener la lista completa de los permisos y roles fijos de
servidor.
Roles fijos de base de datos
Los roles fijos de base de datos incluyen un conjunto predefinido de permisos diseñados para permitir administrar
grupos de permisos con facilidad. Los miembros del rol db_owner pueden realizar todas las actividades de
configuración y mantenimiento de la base de datos.
Para obtener más información sobre los roles predefinidos en SQL Server, vea los siguientes recursos.
Recurso Descripción

Roles de nivel de servidor Describe los roles fijos de servidor y los permisos asociados a ellos en SQL Server.

Roles de nivel de base de Describe los roles fijos de base de datos y los permisos asociados a ellas.
datos

ROLES FIJOS DE BASE DE DATOS

Roles y usuarios de base de datos
Para trabajar con objetos de base de datos, se deben asignar inicios de sesión a cuentas de usuario de base de
datos. Estos usuarios de base de datos se podrán agregar entonces a roles de base de datos y heredarán los conjuntos
de permisos asociados con estos roles. Se pueden conceder todos los permisos.
A la hora de diseñar la seguridad para la aplicación, también debe tener en cuenta el rol public, la cuenta de
usuario dbo y la cuenta guest.
Rol public
El rol public está contenido en todas las bases de datos, incluidas las bases de datos del sistema. No se puede eliminar
y no se pueden agregar ni quitar usuarios de ella. Todos los usuarios y los demás roles heredan los permisos concedidos
al rol public, ya que pertenecen de forma predeterminada al rol public. Por tanto, solo debe conceder al rol public los
permisos que desee que tengan todos los usuarios.
Cuenta de usuario dbo
dbo, o propietario de base de datos, es una cuenta de usuario con permisos implícitos para realizar todas las
actividades en la base de datos. Los miembros del rol fijo del servidor sysadmin se asignan automáticamente a dbo.
Nota
dbo también es el nombre de un esquema, como se describe en propiedad y separación de esquema de usuario en
SQL Server.
La cuenta de usuario dbo se confunde a menudo con el rol fijo de base de datos db_owner. El ámbito de db_owner es
una base de datos y el ámbito de sysadmin es el servidor completo. La pertenencia al rol db_owner no proporciona
privilegios de usuario dbo.
Cuenta de usuario guest
Después de que un usuario se haya autenticado y se le haya permitido iniciar sesión en una instancia de SQL Server,
debe existir una cuenta de usuario independiente en cada base de datos a la que tenga acceso el usuario. Si se exige
una cuenta de usuario en cada base de datos, se impide que los usuarios se conecten a una instancia de SQL Server y
puedan tener acceso a todas las bases de datos de un servidor. La existencia de una cuenta de usuario guest en la base
de datos evita este requisito, ya que permite que un inicio de sesión sin cuenta de usuario de base de datos tenga
acceso a una base de datos.
La cuenta guest es una cuenta integrada en todas las versiones de SQL Server. De forma predeterminada, está
deshabilitada en las bases de datos nuevas. Si está habilitada, se puede deshabilitar mediante la revocación de su
permiso CONNECT, que se lleva a cabo con la ejecución de la instrucción REVOKE CONNECT FROM GUEST de Transact-
SQL.
18
Funciones usuales -> Capitulo 9
Joins -> Capitulo 9
Uso de transacciones -> Capitulo 11
Suconsultas -> Capitulo 9
Filegroups
Los filegroups (o grupos de archivos) son útiles para distribuir tablas con alto volumen de información en diferentes
discos para separar los índices de los datos. Definen conjuntos de archivos para obtener paralelismo en distintas
unidades almacenamiento. Sólo se pueden asignar filegroups a los data files.
Por defecto viene el Filegroup Primary que se asignan automáticamente las tablas del sistema y todas las tablas no
asignadas a otro grupo
Archivos de base de datos y grupos de archivos

Como mínimo, cada base de datos de SQL Server tiene dos archivos de sistema operativo: un archivo de datos y un
archivo de registro. Los archivos de datos contienen datos y objetos como tablas, índices, procedimientos
almacenados y vistas. Los archivos de registro contienen la información necesaria para recuperar todas las
transacciones en la base de datos. Los archivos de datos se pueden agrupar en grupos de archivos con fines de
asignación y administración.
Archivos de base de datos
Las bases de datos de SQL Server tienen tres tipos de archivos, como se muestra en la siguiente tabla.
Archivo Descripción

Primario Contiene información de inicio para la base de datos y apunta a los otros archivos de la base
de datos. Cada base de datos tiene un archivo de datos principal. La extensión de nombre
de archivo recomendada para los archivos de datos primarios es .mdf.

Secundario Archivos de datos opcionales definidos por el usuario. Los datos se pueden distribuir en
varios discos colocando cada archivo en una unidad de disco diferente. La extensión de
nombre de archivo recomendada para archivos de datos secundarios es .ndf.

Registro de El registro contiene información que se utiliza para recuperar la base de datos. Debe haber
transacciones al menos un archivo de registro para cada base de datos. La extensión de nombre de archivo
recomendada para los registros de transacciones es .ldf.

ARCHIVOS DE BASE DE DATOS

Por ejemplo, una base de datos simple denominada Ventas tiene un archivo principal que contiene todos los datos y
objetos y un archivo de registro que contiene la información del registro de transacciones. Se puede crear una base
de datos más compleja denominada Pedidos que incluya un archivo principal y cinco archivos secundarios. Los datos
y los objetos dentro de la base de datos se distribuyen en los seis archivos, y los cuatro archivos de registro contienen
la información del registro de transacciones.
De forma predeterminada, los registros de datos y transacciones se colocan en la misma unidad y ruta para manejar
sistemas de un solo disco. Es posible que esta elección no sea óptima para entornos de producción. Le recomendamos
que coloque los datos y los archivos de registro en discos separados.
Nombres de archivos lógicos y físicos
Los archivos de SQL Server tienen dos tipos de nombre de archivo:

19
nombre_archivo_lógico: el nombre_archivo_lógico es el nombre que se utiliza para hacer referencia al archivo físico
en todas las instrucciones Transact-SQL. El nombre de archivo lógico debe cumplir con las reglas para identificadores
de SQL Server y debe ser único entre los nombres de archivo lógico en la base de datos.
os_file_name: os_file_name es el nombre del archivo físico, incluida la ruta del directorio. Debe seguir las reglas para
los nombres de archivo del sistema operativo.

Páginas de archivos de datos

Las páginas de un archivo de datos de SQL Server se numeran secuencialmente, comenzando con cero (0) para la
primera página del archivo. Cada archivo de una base de datos tiene un número de identificación de archivo
único. Para identificar de forma única una página en una base de datos, se requieren tanto el ID de archivo como el
número de página. El siguiente ejemplo muestra los números de página en una base de datos que tiene un archivo de
datos principal de 4 MB y un archivo de datos secundario de 1 MB.

Una página de encabezado de archivo es la primera página que contiene información sobre los atributos del
archivo. Varias de las otras páginas al comienzo del archivo también contienen información del sistema, como mapas
de asignación. Una de las páginas del sistema almacenadas tanto en el archivo de datos principal como en el primer
archivo de registro es una página de inicio de la base de datos que contiene información sobre los atributos de la base
de datos.
Tamaño del archivo
Los archivos de SQL Server pueden crecer automáticamente desde su tamaño especificado originalmente. Cuando
define un archivo, puede especificar un incremento de crecimiento específico. Cada vez que se llena el archivo,
aumenta su tamaño en el incremento de crecimiento. Si hay varios archivos en un grupo de archivos, no crecerán
automáticamente hasta que todos los archivos estén llenos.
Cada archivo también puede tener un tamaño máximo especificado. Si no se especifica un tamaño máximo, el archivo
puede seguir creciendo hasta que haya utilizado todo el espacio disponible en el disco. Esta característica es
especialmente útil cuando SQL Server se utiliza como una base de datos incrustada en una aplicación donde el usuario
no tiene un acceso conveniente a un administrador del sistema. El usuario puede permitir que los archivos crezcan
automáticamente según sea necesario para reducir la carga administrativa de monitorear el espacio libre en la base
de datos y asignar manualmente espacio adicional.
Archivos de instantáneas de base de datos
La forma de archivo que utiliza una instantánea de base de datos para almacenar sus datos de copia en escritura
depende de si la instantánea es creada por un usuario o se utiliza internamente:
• Una instantánea de la base de datos creada por un usuario almacena sus datos en uno o más archivos
dispersos. La tecnología de archivos dispersos es una característica del sistema de archivos NTFS. Al principio,
un archivo disperso no contiene datos del usuario y el espacio en disco para los datos del usuario no se ha
20
 asignado al archivo disperso. Para obtener información general sobre el uso de archivos dispersos en
instantáneas de base de datos y cómo crecen las instantáneas de base de datos, consulte Ver el tamaño del
archivo disperso de una instantánea de base de datos .
• Las instantáneas de la base de datos se utilizan internamente mediante ciertos comandos DBCC. Estos
comandos incluyen DBCC CHECKDB, DBCC CHECKTABLE, DBCC CHECKALLOC y DBCC CHECKFILEGROUP. Una
instantánea de base de datos interna utiliza flujos de datos alternativos escasos de los archivos de base de
datos originales. Al igual que los archivos dispersos, los flujos de datos alternativos son una característica del
sistema de archivos NTFS. El uso de flujos de datos alternativos dispersos permite asociar múltiples
asignaciones de datos con un solo archivo o carpeta sin afectar el tamaño del archivo o las estadísticas de
volumen.
Grupos de archivos
• El grupo de archivos contiene el archivo de datos principal y los archivos secundarios que no se colocan en
otros grupos de archivos.
• Se pueden crear grupos de archivos definidos por el usuario para agrupar archivos de datos con fines
administrativos, de asignación de datos y de ubicación.
Por ejemplo: Data1.ndf, Data2.ndf, y Data3.ndf, se pueden crear en tres unidades de disco, respectivamente, y se
asigna al grupo de archivos fgroup1. A continuación, se puede crear una tabla específicamente en el grupo de
archivos fgroup1. Las consultas de datos de la tabla se distribuirán en los tres discos; mejorará el rendimiento. La
misma mejora del rendimiento se puede lograr utilizando un solo archivo creado en un conjunto de bandas RAID
(matriz redundante de discos independientes). Sin embargo, los archivos y grupos de archivos le permiten agregar
fácilmente nuevos archivos a nuevos discos.
Todos los archivos de datos se almacenan en los grupos de archivos que se enumeran en la siguiente tabla.
Grupo de archivos Descripción

Primario El grupo de archivos que contiene el archivo principal. Todas las tablas del sistema forman parte
del grupo de archivos principal.

Datos optimizados Un grupo de archivos optimizado para memoria se basa en un grupo de archivos de flujo de
para memoria archivos

Flujo de archivos

Usuario definido Cualquier grupo de archivos creado por el usuario cuando el usuario crea por primera vez o
posteriormente modifica la base de datos.

<https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-files-and-filegroups?view=sql-
server-ver15> - > Aca se encuentra toda la informacion, tambien en ingles

Mecanismos de Migración
• Backup – Restore: es el más limpio y presenta el menor riesgo. Es sencillo ya que crea un único archivo con
todo.
• Detach – Attach: se utiliza más que nada cuando queremos mover a otro disco físico. Es el método más rápido.
• Copy Database Wizard: asistente para crear una copia personalizada de una bd.
• Manual: copiamos los archivos de forma manual.

21
SQL Server Administracion
Uno de los puntos más importantes dentro de las bases de datos es su mantenimiento y administración. Muchas veces
podemos encontrarnos con problemas con el log de transacciones, copias de seguridad incompletas o una mala
estrategia de mantenimiento, lo que ocasiona problemas de rendimiento o pérdida irreparable de información. En
esta publicación del blog nos centraremos en bases de datos SQL Server, aunque también podría aplicarse la misma
filosofía en otros modelos.

A la hora de idear un plan de mantenimiento para una base de datos, tendremos que tener en cuenta varios factores:
• Modelo de recuperación.
• Tamaño de la base de datos.
• Frecuencia de realización de copias de seguridad.

Conceptos iniciales:
• El log de transacciones es un registro de la base de datos que guarda las instrucciones de todos los cambios
realizados. Cualquier actualización, inserción y/o borrado de datos quedará registrado. Gracias a este log se
podrá recuperar la información en un momento concreto, deshacer un cambio o reproducirlo.
• Una copia de seguridad diferencial se trata de un backup parcial que guarda la información a partir de un
backup completo. Es decir, sólo guarda la información modificada desde la última copia completa. De esta
forma podremos realizar copias de seguridad de forma más regular (ya que ocupan menos espacio) y seremos
capaces de volver a un punto concreto utilizando la copia diferencial y completa.
Tipos de modelos de recuperación
Los modelos de recuperación establecen la complejidad de la administración de nuestra base de datos. Dependiendo
del tamaño o de la estrategia de copias de seguridad que queramos tener, debemos elegir el modelo apropiado para
poder llevar a cabo todo el mantenimiento.
En SQL Server tenemos tres tipos de modelos de recuperación:
• Simple: Se trata del modelo de recuperación más sencillo de todos, orientado a entornos de pruebas o con
muy pocas transacciones. Sólo permite copias de seguridad completas o diferenciales. El log de transacciones
deberá ser pequeño y manejable, pero no se podrá realizar un backup del log. Dicho log se truncará cada vez
que se realice una copia de la base de datos, ya sea completa o parcialmente.
Este modelo simplifica la parte administrativa, aunque tiene más riesgos de pérdida de información si la base
de datos es muy grande.
El modelo simple no permite las copias de seguridad del registro de transacciones. Como resultado, no puede
restaurar una base de datos a un punto en el tiempo. Su base de datos es vulnerable a la pérdida de datos cuando usa
este modelo. Dicho esto, usar este modelo facilita la tarea de administración porque SQL Server recuperará espacio
automáticamente del registro de transacciones.
• Completo: El modelo de recuperación más recomendado para cualquier base de datos con un gran número
de transacción. Se podrán realizar copias de seguridad completas, diferenciales y del log de transacciones. Se
necesitará tener un buen mantenimiento con este tipo de base de datos, ya que una mala estrategia puede
ocasionar que el log de transacciones se llene muy rápido y su tamaño sea demasiado grande, o que los

22
 backups tarden demasiado en realizarse por programarlos cada mucho tiempo. Aunque tiene más sobrecarga
administrativa, simplifica los riesgos y la pérdida de información.

Con el modelo completo, la pérdida de datos es mínima cuando se realiza una copia de seguridad periódica del registro
de transacciones. Todas las transacciones se registran por completo en el registro de transacciones, y el registro de
transacciones continuará creciendo hasta que se haga una copia de seguridad. Si bien este modelo agrega una
sobrecarga administrativa, sus datos están protegidos contra la pérdida de datos.

• Registro masivo: Similar al modelo de recuperación completa pero no guarda las transacciones masivas
(inserts masivos, creación de índices…). Consigue un mejor rendimiento y ocupa menos espacio, pero tiene un
gran riesgo al no contemplar los cambios masivos en la base de datos.

Cuando utiliza el modelo de registro masivo, las operaciones masivas se registran mínimamente, lo que reduce el
tamaño del registro de transacciones. Tenga en cuenta que esto no elimina la necesidad de hacer una copia de
seguridad del registro de transacciones. A diferencia del modelo de recuperación completa, en el modelo de registro
masivo puede restaurar solo hasta el final de cualquier copia de seguridad; no puedes restaurar en algún punto en el
tiempo.

Recovery Models
• Full: Nunca trunca el transaction log (sólo cuando se hace backup). Permite la restauración en cualquier punto
en el tiempo (sólo EE). Guarda todo, se usa cuando la información es muy crítica.
• Simple: Log mínimo, simple y eficiente manejo del transaction log. Trunca el transaction log luego de cada
checkpoint. No permite page-restore.
• Bulk logged: No guarda todas las operaciones en el transaction log (solo operaciones bulk). No permite la
restauración en cualquier punto en el tiempo.

Descripción general del modelo de recuperación

La siguiente tabla resume los tres modelos de recuperación.
Modelo de Descripción Exposición a la ¿Recuperarse a un punto en
recuperación pérdida de trabajo el tiempo?

Sencillo No hay copias de seguridad de Los cambios desde Solo se puede recuperar hasta
registros. la copia de el final de una copia de
seguridad más seguridad. Para obtener más
Recupera automáticamente el reciente no están información,
espacio del registro para protegidos. En caso consulte Restauraciones
mantener los requisitos de de desastre, esos completas de bases de datos
espacio pequeños, eliminando cambios deben (modelo de recuperación
esencialmente la necesidad de rehacerse. simple) .
administrar el espacio del
registro de transacciones. Para Para obtener una explicación
obtener información sobre las más detallada del modelo de
copias de seguridad de la base recuperación simple,
de datos en el modelo de consulte Modelo de
recuperación simple, recuperación simple de SQL

23
 consulte Copias de seguridad Server proporcionado por la
completas de la base de datos gente de MSSQLTips.
(SQL Server) .

Las operaciones que requieren

copias de seguridad del
registro de transacciones no
son compatibles con el modelo
de recuperación simple. Las
siguientes funciones no se
pueden usar en el modo de
recuperación simple:

-Registro de envío

-Siempre activado o
duplicación de la base de

datos

-Recuperación de medios sin

pérdida de datos -
Restauraciones puntuales

Lleno Requiere copias de seguridad Normalmente Puede recuperarse hasta un

de registros. ninguno. punto específico en el tiempo,
suponiendo que sus copias de
No se pierde ningún trabajo Si la parte final del seguridad estén completas
debido a un archivo de datos registro está hasta ese momento. Para
perdido o dañado. dañada, los cambios obtener información sobre el
desde la copia de uso de copias de seguridad de
Puede recuperarse a un punto seguridad del registros para restaurar hasta
arbitrario en el tiempo (por registro más el punto de falla,
ejemplo, antes de la aplicación reciente deben consulte Restaurar una base
o error del usuario). Para rehacerse. de datos de SQL Server a un
obtener información sobre las punto en el tiempo (modelo
copias de seguridad de la base de recuperación completa) .
de datos en el modelo de
recuperación completa, Nota: Si tiene dos o más bases
consulte Copias de seguridad de datos de modelos de
completas de la base de datos recuperación completa que
(SQL Server) y Restauraciones deben ser lógicamente
completas de la base de datos coherentes, es posible que
(modelo de recuperación deba implementar
completa) . procedimientos especiales
para asegurarse de la
recuperabilidad de estas bases

24
 de datos. Para obtener más
información,
consulte Recuperación de
bases de datos relacionadas
que contienen transacciones
marcadas .

Registro masivo Requiere copias de seguridad Si el registro está Puede recuperarse hasta el
de registros. dañado o se final de cualquier copia de
realizaron seguridad. No se admite la
Un complemento del modelo operaciones de recuperación en un momento
de recuperación completa que registro masivo determinado.
permite operaciones de copia desde la copia de
masiva de alto rendimiento. seguridad del
registro más
Reduce el uso de espacio de reciente, los
registro al utilizar un registro cambios desde la
mínimo para la mayoría de las última copia de
operaciones masivas. Para seguridad deben
obtener información sobre las rehacerse.
operaciones que se pueden
registrar mínimamente, De lo contrario, no
consulte El registro de se pierde ningún
transacciones (SQL Server) . trabajo.

Las copias de seguridad del

registro pueden tener un
tamaño significativo porque
las operaciones mínimamente
registradas se capturan en la
copia de seguridad del
registro. Para obtener
información sobre las copias
de seguridad de la base de
datos en el modelo de
recuperación de registro
masivo, consulte Copias de
seguridad completas de la
base de datos (SQL
Server) y Restauraciones
completas de la base de datos
(modelo de recuperación
completa) .

Mantenimiento de backups
Una vez escogido nuestro modelo de base de datos, debemos diseñar una estrategia de mantenimiento. Podremos
realizar backups de forma manual o programando un horario para que se realicen de forma automática. Para esta
programación automática tendremos que tener en cuenta varios factores para decidir la mejor estrategia:
25
 • Escoger un momento del día en el que se prevea poca actividad para las copias de seguridad completas.
• En el modelo de recuperación simple, se recomienda realizar copias diferenciales entre las copias de
seguridad completas para minimizar el riesgo lo máximo posible.
• En el modelo de recuperación completo, se debe realizar copias del log de transacciones de forma frecuente,
con esto conseguiremos disminuir el tiempo que se tarda en realizar copias de seguridad completas, y de
nuevo, minimizar el riesgo de pérdida de información.
• Realizar un estudio del tamaño que se necesitará para guardar las copias de seguridad. Para saber esto,
podemos utilizar la función sp_spaceused para saber el espacio real de la información de nuestra base de
datos. La copia de seguridad sólo guarda la información real, por lo que lo normal es que ocupe menos que el
tamaño de la base de datos, que también contiene espacio en blanco.
Un ejemplo de mantenimiento de una base de datos de tamaño medio/grande, con el modo de recuperación
completo, podría ser:
• Una copia de seguridad completa de forma nocturna.
• Una copia de seguridad diferencial a medio día.
• Copias del log de transacciones cada cuatro horas.

Tres Tipos de Copia de Seguridad SQL Server

1. Copia de seguridad completa
Una copia de seguridad completa contiene todos los datos de una base de datos específica o un conjunto de grupos
de archivos o archivos, y también el registro suficiente para permitir la recuperación de esos datos. Es la base de la
copia de seguridad diferencial y de la copia de seguridad de los registros de transacciones.
2. Copia de seguridad diferencial
Una copia de seguridad diferencial no es independiente y debe basarse en la última copia de seguridad completa de
los datos. Eso significa que debería haber una copia de seguridad completa como base. Una copia de seguridad
diferencial contiene sólo los datos que han cambiado desde la base diferencial. Normalmente, las copias de seguridad
diferenciales son más pequeñas y rápidas de crear que la base de una copia de seguridad completa y también
requieren menos espacio en disco para almacenar imágenes de copia de seguridad.
Por lo tanto, el uso de copias de seguridad diferenciales puede ahorrar espacio disponible y acelerar el proceso de
realizar copias de seguridad frecuentes para reducir el riesgo de pérdida de datos. En el momento de la restauración,
primero se restaura la copia de seguridad completa, seguida de la copia de seguridad diferencial más reciente.
Recuerda no depender de una sola base, cree varias bases de respaldo diferencial en diferentes momentos para
garantizar la seguridad de los archivos de respaldo.
3. Copias de seguridad de registros de transacciones (sólo modelos de recuperación completos y masivos)
El registro de transacciones es un registro en serie de todas las transacciones que se han realizado contra la base de
datos desde que se realizó la última copia de seguridad del registro de transacciones. Con las copias de seguridad del
registro de transacciones, puede recuperar la base de datos hasta un momento específico (por ejemplo, antes de
introducir datos no deseados) o hasta el punto de fallo.
Las copias de seguridad del registro de transacciones sólo son valiosas bajo el modelo de recuperación completa o el
modelo de recuperación en bloque. Cada copia de seguridad de registro cubre la parte del registro de transacciones
que estaba activa cuando se creó la copia de seguridad, e incluye todos los registros de registro que no se copiaron en
una copia de seguridad de registro anterior. Una secuencia ininterrumpida de copias de seguridad de registros
contiene la cadena completa de registros de la base de datos, que se dice que no está rota. En el modelo de
recuperación completa, y a veces en el modelo de recuperación de registros masivos, una cadena de registro
ininterrumpida le permite restaurar la base de datos a cualquier punto en el tiempo.
Al igual que la copia de seguridad diferencial, la copia de seguridad del registro de transacciones también se basa en
una copia de seguridad completa. Por lo tanto, antes de que pueda crear la primera copia de seguridad del registro,
debe crear una copia de seguridad completa, como una copia de seguridad de la base de datos. Debido a que requiere

26
menos espacio en disco que una copia de seguridad completa, puede crearlas con más frecuencia que las copias de
seguridad de la base de datos.
Descarga gratuitamente el software de copia de seguridad y recuperación SQL y haz copias de seguridad de SQL Server
con diferentes tipos de copias de seguridad SQL; consulta las funciones y soluciones más detalladas para copias de
seguridad y recuperación SQL, más informaciones de EaseUS Todo Backup Advanced Server.

Gestión de los accesos al servidor

Antes de poder trabajar con los datos gestionados por las bases de datos, es necesario en primer lugar conectarse al
servidor SQL. Esta etapa permite hacerse identificar por el servidor SQL y utilizar posteriormente todos los derechos
que se asignan a la conexión. En SQL existen dos modos de gestión de los accesos al servidor de base de datos.
Atención: en esta sección únicamente se aborda la parte de conexión al servidor. Es importante distinguir bien la
conexión al servidor de la utilización de bases de datos. La conexión al servidor permite hacerse identificar por el
servidor SQL como un usuario válido para utilizar, posteriormente, una base de datos: los datos y los objetos. El
conjunto de estos derechos se definirá más adelante. Estos derechos se asocian a un usuario de base de datos al que
corresponde una conexión. Podes acceder al servidor de 3 maneras diferentes:
Tipos de inicios de sesión
SQL Server admite tres tipos de inicios de sesión:
• Una cuenta de usuario local de Windows o una cuenta de dominio de confianza. SQL Server se basa en
Windows para autenticar las cuentas de usuario de Windows.
• Grupo de Windows. La concesión de acceso a un grupo de Windows otorga acceso a todos los inicios de
sesión de usuario de Windows que son miembros del grupo.
• Inicio de sesión de SQL Server. SQL Server almacena el nombre de usuario y un hash de la contraseña en
la base de datos master mediante métodos de autenticación internos para comprobar los intentos de
inicio de sesión.
Modo mixto de autenticación
Si tiene que usar la autenticación de modo mixto, debe crear inicios de sesión de SQL Server, que se almacenan en
SQL Server. Luego debe proporcionar el nombre de usuario y la contraseña de SQL Server en tiempo de ejecución.

Gestión de los usuarios de la base de datos

Después de la definición de las conexiones (login) a nivel del servidor, es necesario definir los usuarios en las diferentes
bases de datos.
Los permisos de uso de los objetos definidos en la base de datos se asignan a nivel de los usuarios de base de datos.
Cuando se define una conexión, la base de datos predeterminada permite situar la cuenta de conexión sobre una base
de datos para comenzar a trabajar. Sin embargo, la conexión solo podrá trabajar sobre la base de datos si existe una
cuenta de usuario definida a nivel de la base de datos y asociada a la conexión. Este es un punto de paso obligatorio,
salvo si se asignan a la conexión los privilegios de alto nivel.
Si no se define ninguna base de datos predeterminada a nivel de la conexión, entonces la base Master se considera la
base de datos predeterminada, lo que no es una buena elección.
Los usuarios de base de datos se asocian a una conexión a nivel del servidor. Sin embargo, algunos usuarios,
como guest, sys e INFORMATION_SCHEMA, no se mapean a ninguna conexión.
Si un usuario tiene una conexión a SQL Server, pero no existe usuario de base de datos que le permita trabajar sobre
las bases de datos, el usuario solo puede realizar operaciones muy limitadas:
• Seleccionar la información contenida en las tablas de sistema y ejecutar algunos procedimientos
almacenados.
• Acceder a todas las bases de datos de usuario con una cuenta de usuario guest.

27
 Autenticación en SQL Server
SQL Server admite dos modos de autenticación, el modo de autenticación de Windows y el modo mixto.
• La autenticación de Windows es el modo predeterminado y a veces se le conoce como seguridad
integrada porque este modelo de seguridad de SQL Server está estrechamente integrado en
Windows. Se confía en las cuentas de usuario y grupo específicas de Windows para iniciar sesión en SQL
Server. Los usuarios de Windows que ya se han autenticado no tienen que presentar credenciales
adicionales.
• El modo mixto admite la autenticación mediante Windows y SQL Server. Los pares de nombre de usuario
y contraseña se mantienen en SQL Server.
Importante
Se recomienda usar la autenticación de Windows siempre que sea posible. La autenticación de Windows usa una serie
de mensajes cifrados para autenticar a los usuarios en SQL Server. Cuando se usan inicios de sesión de SQL Server, los
nombres de inicio de sesión y las contraseñas cifrados se pasan a través de la red, lo que hace de este un método
menos seguro.
Con la autenticación de Windows, los usuarios ya están registrados en Windows y no es necesario que inicien sesión
por separado en SQL Server. La siguiente SqlConnection.ConnectionString especifica autenticación de Windows sin
que los usuarios tengan que proporcionar un nombre de usuario ni una contraseña.
Escenarios de autenticación
La autenticación de Windows suele ser la mejor opción en las siguientes situaciones:
• Hay un controlador de dominio.
• La aplicación y la base de datos están en el mismo equipo.
• Está usando una instancia de SQL Server Express o LocalDB.
Los inicios de sesión de SQL Server se suelen usar en las siguientes situaciones:
• Si tiene un grupo de trabajo.
• Los usuarios se conectan desde dominios diferentes que no son de confianza.
• Aplicaciones de Internet, como ASP.NET.

Privilegios y seguridad de datos

Para conectarse al SQL Server, se necesita un Login (usuario a nivel del servidor). Cuando la política de seguridad se
define como Windows Authentication y el servidor se combina con las definiciones del Domain, los Logins se definen en
el Active Directory. Cuando la definición es SQL Server Authentication los logins (usuario y contraseña) se definen en el
SQL Server mismo. Consecuentemente, en el primer caso hay que identificarse con nombre y contraseña solamente al
conectarse a la red, y luego se conecta automáticamente a todos los servidores que son Windows Authentication (con
el Login global); y en el segundo caso hay que identificarse al conectarse a cada servidor de SQL Server Authentication
(cada vez con un Login local).
A nivel de la base de datos, el usuario se identifica como un User que está relacionado generalmente al Login (que es a
nivel del servidor), y los privilegios al User existen solamente en el ámbito de la base de datos (además a los privilegios
al Login). Para otorgar derechos generales puede asistirse con listas de Server Roles (roles a nivel del servidor) o Database
Roles (roles a nivel de la base de datos específica), cada cual con privilegios específicos a un rol específico; y cada usuario
asociado con uno de estos Roles obtiene los privilegios asociados con él. Además, el administrador puede otorgar
derechos specificos, y crear otros Database Roles (no se puede crear Server Roles).
Los privilegios a nivel del servidor incluyen la capacidad de crear bases de datos, utilizar las tareas (Jobs), crear respaldos
de bases de datos y restaurarlos, modificar las definiciones del servidor, etc. Los privilegios a nivel de la base de datos
posibilitan extraer y actualizar datos, crear objetos como procedimientos y tablas, utilizar dichos objetos, etc. Como regla
general se puede otorgar derechos (Grant), revocar privilegios existentes (Revoke), y denegar privilegios aún no existen
(Deny).

28
Vistas
Una vista es una tabla virtual cuyo contenido está definido por una consulta. Al igual que una tabla, una vista consta de
un conjunto de columnas y filas de datos con un nombre. Sin embargo, a menos que esté indizada, una vista no existe
como conjunto de valores de datos almacenados en una base de datos. Las filas y las columnas de datos proceden de
tablas a las que se hace referencia en la consulta que define la vista y se producen de forma dinámica cuando se hace
referencia a la vista.
Una vista actúa como filtro de las tablas subyacentes a las que se hace referencia en ella. La consulta que define la vista
puede provenir de una o de varias tablas, o bien de otras vistas de la base de datos actual u otras bases de
datos. Asimismo, es posible utilizar las consultas distribuidas para definir vistas que utilicen datos de orígenes
heterogéneos. Esto puede resultar de utilidad, por ejemplo, si desea combinar datos de estructura similar que proceden
de distintos servidores, cada uno de los cuales almacena los datos para una región distinta de la organización.
Las vistas suelen usarse para centrar, simplificar y personalizar la percepción de la base de datos para cada usuario. Las
vistas pueden emplearse como mecanismos de seguridad, que permiten 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. Las
vistas pueden utilizarse para proporcionar una interfaz compatible con versiones anteriores con el fin de emular una
tabla que existía, pero cuyo esquema ha cambiado. También pueden usarse para copiar datos entre SQL Server a fin de
mejorar el rendimiento y crear particiones de los datos.

Tipos de vistas
Además del rol estándar de las vistas básicas definidas por el usuario, SQL Server proporciona los siguientes tipos de
vistas que permiten llevar a cabo objetivos especiales en una base de datos.

Vistas indizadas
Una vista indizada es una vista que se ha materializado. Esto significa que se ha calculado la definición de la vista y que
los datos resultantes se han almacenado como una tabla. Se puede indizar una vista creando un índice clúster único en
ella. Las vistas indizadas pueden mejorar de forma considerable el rendimiento de algunos tipos de consultas. Las vistas
indizadas funcionan mejor para consultas que agregan muchas filas. No son adecuadas para conjuntos de datos
subyacentes que se actualizan frecuentemente.

Vistas con particiones

Una vista con particiones combina datos horizontales con particiones de un conjunto de tablas miembro en uno o más
servidores. Esto hace que los datos aparezcan como si fueran de una tabla. Una vista que combina tablas miembros en
la misma instancia de SQL Server es una vista con particiones local.

Vistas del sistema

Las vistas de sistema exponen metadatos de catálogo. Puede usar las vistas del sistema para devolver información acerca
de la instancia de SQL Server u objetos definidos en la instancia. Por ejemplo, puede consultar la vista de catálogo
sys.databases para devolver información sobre las bases de datos definidas por el usuario disponibles en la
instancia. Para obtener más información, vea Vistas del sistema (Transact-SQL).

Tareas de vista comunes

En la tabla siguiente se proporcionan vínculos a las tareas comunes asociadas con la creación o modificación de una
vista.
Tareas de vista Tema

Describe cómo crear una vista. Crear vistas

Describe cómo crear una vista indizada. Crear vistas indizadas

29
Describe cómo modificar la definición de la vista. Modificar vistas

Describe cómo modificar datos mediante una vista. Modificar datos mediante una vista

Describe cómo eliminar una vista. Eliminar vistas

Describe cómo devolver información acerca de una vista, Obtener información acerca de una vista
como la definición de la vista.

Describe cómo cambiar el nombre de una vista. Cambiar el nombre de las vistas

Catalogos

Los catálogos, en una base de datos, son indispensables para un buen diseño de la misma. Es por eso la importancia de
conocer las ventajas y desventajas de su uso. Comencemos definiendo “catálogo” en una base de datos. Un catálogo es
una tabla de datos que contiene información relevante sobre las opciones finales de un usuario en una aplicación. A
continuación, menciono las ventajas y desventajas de los catálogos en el diseño de base de datos:
Ventajas
• Permite una rápida obtención de los datos requeridos al momento de realizar una consulta.
• Permite una reducción de tiempo en programación.
• Permite al usuario final la posibilidad de realizar una modificación de manera dinámica a las opciones del
software, fácil y rápidamente desde una administración.
• Permite crear una base de datos normalizada.

Desventajas
• El uso de memoria en el servidor SQL puede verse afectado.
• La desventaja puede ser solucionada con el uso correcto de las consultas SQL, tal es el caso de evitar
productos cartesianos al momento de dicha consulta y en su reemplazo utilizar INNER JOIN, LEFT JOIN,
RIGHT JOIN según se requiera.
• Ciertos desarrolladores necesitan ver un proceso de normalización de una base datos, sin embargo, si
comienzas a diseñarla utilizando catálogos, dicho proceso puede llegar a ser innecesario.

Procedimientos almacenados
Los procedimientos son scripts de comandos de TSQL, que pueden ser ejecutados con distintos parámetros. Por ejemplo,
procedimiento que obtiene número de año como parámetro, y actualiza una tabla de resumen de ventas, con las ventas
de los agentes en el dicho año, basada en la tabla de registro de ventas.
Los procedimientos almacenados pueden facilitar en gran medida la administración de la base de datos y la visualización
de información sobre dicha base de datos y sus usuarios. Los procedimientos almacenados son una colección
precompilada de instrucciones SQL e instrucciones de control de flujo opcionales almacenadas bajo un solo nombre y
procesadas como una unidad. Los procedimientos almacenados se guardan en una base de datos; se pueden ejecutar
desde una aplicación y permiten variables declaradas por el usuario, ejecución condicional y otras funciones eficaces de
programación. Los procedimientos almacenados pueden contener flujo de programas, lógica y consultas a la base de
datos. Pueden aceptar parámetros, proporcionar resultados de parámetros, devolver conjuntos de resultados
individuales o múltiples y devolver valores.
Las ventajas de utilizar procedimientos almacenados en SQL Server en vez de programas Transact-SQL almacenados
localmente en equipos clientes consisten en que:
• Permiten una programación modular.

30
Puede crear el procedimiento una vez, almacenarlo en la base de datos, y llamarlo desde el programa el número de
veces que desee. Un especialista en programación de bases de datos puede crear procedimientos almacenados, que
luego será posible modificar independientemente del código fuente del programa. Facilitan el mantenimiento.
• Permiten una ejecución más rápida.
En situaciones en las que se necesita una gran cantidad de código Transact-SQL, o si las operaciones se realizan varias
veces, los procedimientos almacenados pueden ser más rápidos que los lotes de código Transact-SQL. Los
procedimientos son analizados y optimizados en el momento de su creación, y es posible utilizar una versión del
procedimiento que se encuentra en la memoria después de que se ejecute por primera vez. Las instrucciones de
Transact-SQL que se envían varias veces desde el cliente cada vez que deben ejecutarse tienen que ser compiladas y
optimizadas siempre que SQL Server las ejecuta.
• Pueden reducir el tráfico de red.
Una operación que necesite centenares de líneas de código Transact-SQL puede realizarse mediante una sola instrucción
que ejecute el código en un procedimiento, en vez de enviar cientos de líneas de código por la red.
• Pueden utilizarse como mecanismo de seguridad.
Es posible conceder permisos a los usuarios para ejecutar un procedimiento almacenado, incluso si no cuentan con
permiso para ejecutar directamente las instrucciones del procedimiento.

31