Dominio/clave

La forma normal de dominio/clave (DKNF) es una forma normal usada en normalización de bases de datos que requiere que la base de datos contenga restricciones de dominios y de claves.

Una restricción del dominio especifica los valores permitidos para un atributo dado, mientras que una restricción clave especifica los atributos que identifican únicamente una fila en una tabla dada.

Esta es el santo grial de la Base de datos y es alcanzado cuando cada restricción en la relación es una consecuencia lógica de la definición de claves y dominios, y, haciendo cumplir las restricciones y condiciones de la clave y del dominio, causa que sean satisfechas todas las restricciones. Así, esto evita todas las anomalías no-temporales.

Es mucho más fácil construir una base de datos en forma normal de dominio/clave que convertir pequeñas bases de datos que puedan contener numerosas anomalías. Sin embargo, construir con éxito una base de datos en forma normal de dominio/clave sigue siendo una tarea difícil, incluso para programadores experimentados de bases de datos. Así, mientras que la forma normal de dominio/clave elimina los problemas encontrados en la mayoría de las bases de datos, tiende para ser la forma normal más costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalías que aparecen con el tiempo en las bases de datos que solamente se adhieren a formas normales más bajas.

Una violación de DKNF ocurre en la siguiente tabla:

Persona rica

DNI Persona rica	Tipo de persona rica	Valor neto en dólares
123	Millonario excéntrico	124,543,621
456	Multimillonario malvado	6,553,228,893
789	Multimillonario excéntrico	8,829,462,998
012	Millonario malvado	495,565,211

Qué es el SQL ?

El SQL (Structured query language), lenguaje de consulta estructurado, es un lenguaje surgido de un proyecto de investigación de IBM para el acceso a bases de datos relacionales. Actualmente se ha convertido en un estándar  de lenguaje de bases de datos, y la mayoría de los sistemas de bases de datos lo soportan, desde sistemas para ordenadores personales, hasta grandes ordenadores. Por supuesto, a partir del estándar cada sistema ha desarrollado su propio SQL que puede variar de un sistema a otro, pero con cambios que no suponen ninguna complicación para alguien que conozca un SQL concreto, como el que vamos a ver aquí corespondiente al Access2000. Como su nombre indica, el SQL nos permite realizar consultas a la base de datos. Pero el nombre se queda corto ya que SQL además realiza funciones de definición, control y gestión de la base de datos. Las sentencias SQL se clasifican según su finalidad dando origen a tres ‘lenguajes’ o mejor dicho sublenguajes:

el DDL (Data Description Language), lenguaje de definición de datos, incluye órdenes para definir, modificar o borrar las tablas en las que se almacenan los datos y de las relaciones entre estas. (Es el que más varia de un sistema a otro)

el DCL (Data Control Language), lenguaje de control de datos, contiene elementos útiles para trabajar en un entorno multiusuario, en el que es importante la protección de los datos, la seguridad de las tablas y el establecimiento de restricciones en el acceso, así como elementos para coordinar la compartición de datos por parte de usuarios concurrentes, asegurando que no interfieren unos con otros.

el DML (Data Manipulation Language), lenguaje de manipulación de datos, nos permite recuperar los datos almacenados en la base de datos y también incluye órdenes para permitir al usuario actualizar la base de datos añadiendo nuevos datos, suprimiendo datos antiguos o modificando datos previamente almacenados.

• modelo de objetos semanticos
• DEFINICIÓN DE OBJETOS SEMÁNTICOS • Un objeto semántico es una representación de algunas cosas identificables en el ambiente de trabajo de los usuarios, es un conjunto de atributos que describen suficientemente un identidad bien definida. • Una clase de objetos tiene un nombre que las distingue de otras y se escriben con letras mayúsculas.
• 5. • Los objetos representan entidades bien definidas ya que son ciertas cosas que los usuarios reconocen como independientes y separadas a las que desean dar seguimiento y a partir de eso elaborar reportes.
• 6. ATRIBUTOS • Existen 3 tipos de atributos: • Atributos Simples: Son lo que tienen un elemento. • Atributos Grupales: Son combinaciones de otros atributos. • Atributos De Los Objetos Semánticos También conocido como enlaces del objeto, establecen una relación entre un objetos semántico y otro.
• 7. CARDINALIDAD DE LOS ATRIBUTOS • Cardinalidad de los atributos: Cada atributo en un objeto semántico tiene una cardinalidad minima y una cardinalidad máxima. • La minima indica la cantidad de instancias del atributo que debe existir para que el objeto sea valido. • La máxima indica el numero máximo de instancias del atributo que el objeto puede tener. • La cardinalidad se muestra por subíndices en los atributos en el formato “N.M.” , donde “N” es la cardinalidad minima y “M” la cardinalidad maxima.
• 8. INSTANCIAS DE OBJETOS • Son un formato, o estructura general, que puede utilizarse para cualquier departamento. • Los departamentos pueden tener menos o mas que otros pero debe de tener por lo menos uno.

formularios en acces

Un formulario es un tipo de objeto de base de datos que se utiliza fundamentalmente para introducir o mostrar datos en una base de datos. También puede utilizar un formulario como un panel de control que abre otros formularios e informes de la base de datos, o como  un cuadro de diálogo personalizado que acepta las entradas del usuario y realiza una acción basada en las entradas. 

para crear rápidamente un formulario, utilice el comando Autoformato o un Asistente. La función Autoformulario crea un formulario que muestra todos los campos y registros de la tabla o consulta base. El asistente hace preguntas y crea un informe basándose en las respuestas que obtiene. Después, podrá personalizar el formulario en la vista Diseño.

Quinta forma normal

La quinta forma normal (5FN), también conocida como forma normal de proyección-unión (PJ/NF), es un nivel de normalización de bases de datos diseñado para reducir redundancia en las bases de datos relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5NFsi y sólo si está en 4NF y cada dependencia de unión (join) en ella es implicada por las claves candidatas.

Considere el siguiente ejemplo:

Psiquiatra-para-Asegurador-para-Condición

Psiquiatra	Asegurador	Condición
Dr. James	Healthco	Ansiedad
Dr. James	Healthco	Depresión
Dr. Kendrick	FriendlyCare	OCD
Dr. Kendrick	FriendlyCare	Ansiedad
Dr. Kendrick	FriendlyCare	Depresión
Dr. Lowenstein	FriendlyCare	Esquizofrenia
Dr. Lowenstein	Healthco	Ansiedad
Dr. Lowenstein	Healthco	Demencia
Dr. Lowenstein	Victorian Life	Trastorno de conversión

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condición dada y que son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja las combinaciones válidas posibles de psiquiatra, asegurador, y condición, la tabla de tres atributos Psiquiatra-para-Asegurador-para-Condición es necesaria para modelar la situación correctamente.

Sin embargo, suponga que la regla siguiente se aplica:

Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados por el asegurador P, y el psiquiatra puede tratar la condición C, entonces - en caso que el asegurador P cubra la condición C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a los pacientes que sufren de la condición C y están asegurados por el asegurador P.

Con estas restricciones es posible dividir la relación en tres partes.

Psiquiatra-para-Condición Psiquiatra Condición Dr. James Ansiedad Dr. James Depresión Dr. Kendrick OCD Dr. Kendrick Ansiedad Dr. Kendrick Depresión Dr. Lowenstein Esquizofrenia Dr. Lowenstein Ansiedad Dr. Lowenstein Demencia Dr. Lowenstein Trastorno de conversión

Psiquiatra-para-Asegurador Psiquiatra Asegurador Dr. James Healthco Dr. Kendrick FriendlyCare Dr. Lowenstein FriendlyCare Dr. Lowenstein Healthco Dr. Lowenstein Victorian Life

Asegurador-para-Condición Asegurador Condición Healthco Ansiedad Healthco Depresión Healthco Demencia FriendlyCare OCD FriendlyCare Ansiedad FriendlyCare Depresión FriendlyCare Trastorno emocional FriendlyCare Esquizofrenia Victorian Life Trastorno de conversión

Note como esta disposición ayuda a quitar redundancia. Suponga que el Dr. James se convierte en un proveedor de tratamientos para FriendlyCare. En la disposición anterior tendríamos que agregar dos nuevas entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por FriendlyCare: ansiedad y depresión. Con la nueva disposición necesitamos agregar una sola entrada (en la tabla Psiquiatra-para-Asegurador).

consultas de referencias cruzadas

Se define una consulta de referencias cruzadas cuando queremos representar una consulta resumen con dos columnas de agrupación como una tabla de doble entrada en la que cada una de las columnas de agrupación es una entrada de la tabla.

Por ejemplo queremos obtener las ventas mensuales de nuestros empleados a partir de los pedidos vendidos. Tenemos que diseñar una consulta resumen calculando la suma de los importes de los pedidos agrupando por empleado y mes de la venta.

La consulta quedaría mucho más elegante y clara presentando los datos en un formato más compacto como el siguiente:

Pues este último resultado se obtiene mediante una consulta de referencias cruzadas.

Observa que una de las columnas de agrupación (empleado) sigue definiendo las filas que aparecen (hay una fila por cada empleado), mientras que la otra columna de agrupación (mes) ahora sirve para definir las otras columnas, cada valor de mes define una columna en el resultado, y la celda en la intersección de un valor de empleado y un valor de mes es la columna resumen, la que contiene la función de agregado (la suma de importes).

Las consultas de referencias cruzadas se pueden crear desde la vista diseño pero es mucho más cómodo y rápido utilizar el asistente.

Agrupar en consultas

Cuando se utiliza la función totales en una consulta, los datos de los campos se agrupan por valor, es decir, todos los elementos de un tipo se encuentran juntos. 

1.    En la ventana Base de datos, elija Consultas  en Objetos y, a continuación, haga clic en la consulta que desea abrir y en la barra de herramientas de la ventana Base de datos, elija Diseño.

2.    Comience la consulta agregando las tablas, vistas o funciones que desea resumir en el panel Diagrama.

3.    Haga clic con el botón secundario del mouse en el panel Diagrama, a continuación elija Agrupar por en el menú contextual. El Diseñador de consultas agrega una columna Agrupar por a la cuadrícula del panel Cuadrícula.

4.    Agregue la columna o columnas que desee agrupar al panel Cuadrícula. Si desea que la columna aparezca en el resultado de la consulta, asegúrese de que la columna Resultados, está seleccionada.

5.    Agregue la columna o columnas que desee agregar al panel Cuadrícula. Asegúrese de que la columna está marcada para el resultado.

6.    En la celda de cuadrícula Agrupar por de la columna que se va a agregar, seleccione la función de agregado correspondiente.

Consultas con referencias cruzadas

Se define una consulta de referencias cruzadas cuando queremos representar una consulta resumen con dos columnas de agrupación como una tabla de doble entrada en la que cada una de las columnas de agrupación es una entrada de la tabla.

http://www.aulaclic.es/access-2010/t_9_1.htm

http://office.microsoft.com/es-mx/access-help/agrupar-filas-en-los-resultados-de-la-consulta-adp-HP003084017.aspx

Diagrama Entidad Relación

Diagrama Entidad Relación: Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de un Esquema gráfico empleando los terminología de Entidades, que son objetos que existen y son los elementos principales que se identifican en el problema a resolver con el diagramado y se distinguen de otros por sus características particulares denominadas Atributos, el enlace que rige la unión de las entidades está representada por la relación del modelo.

Este diagrama o modelo lo propuso Peter Chen en 1976

Entidad: es el objeto del cual se recoge información de interés, de cara a la base de datos. 
Relación: como su palabra la dice (relación) se trata de la asociación de dos o más entidades. a cada relación se le asigna un campo único para poder identificarse y saber cuál es su función dentro del modelo -e-r- 

y sirve para identificar los campos únicos de una base de datos

El modelo de datos entidad-relación está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre esos objeto.

reglas para convertir E-R a B.D

Para convertir un diagrama Entidad-Relación a B.D relacional se tienen que seguir las siguientes reglas:

1. Cada conjunto de entidades fuerte se representa con una tabla, cuyas columnas corresponden a los atributos de las entidades.
2. Cada conjunto de entidades débil se representa con una tabla, con una columna por cada atributo de las entidades más una columna por cada atributo de la llave primaria de la entidad fuerte de la cual el conjunto de entidades débil depende.
3. Cuando existe una relación “uno a varios” se  va a generar una tabla que incluye los atributos de la entidad del extremo “varios”, es decir una columna por cada uno de los atributos de la entidad varios y una columna del atributo principal de la entidad del extremo “uno”. En otras palabras se toma el campo llave del extremo uno y se inserta en la tabla del extremo varios.
4. Cuando existe una relación “varios a varios” (binaria) y toda relación donde el grado de participación sea de 2 o más de dos conjuntos de entidades (ternaria, cuaternaria) se representa con una tabla, la cual tiene una columna por cada atributo de las llaves primarias de los conjuntos de entidades a los que participan en la relación, más una o más columnas por cada atributo que fueron necesarios para describir la relación.
5. Si existieran campos compuestos en cualquiera de las entidades, conviene evaluar si se necesitara en la base de datos hacer búsquedas por los elementos individuales o atributos que componen el atributo compuesto, si se requiere hacer dichas búsquedas, entonces cada atributo que compone el atributo compuesto deberá ser un campo de la tabla, en caso de que no, la tabla solo contendrá una campo con el nombre del atributo compuesto y el valor de cada registro de este campo estará formado por los valores de los atributos que lo componen. Esto debido a que para hacer búsquedas en un atributo compuesto, es más fácil si se tiene una columna por cada campo que compone el campo compuesto.
6. Si existe un atributo multivalorado en una tabla, este se convierte en una tabla que va a estar compuesta por una columna para el campo llave de esta nueva tabla, otro campo que será el campo llave de la tabla de donde proviene el atributo multivalorado (llave foránea) y finalmente un campo que será el que representa al atributo multivalorado, en la tabla habrá un registro por cada valor del atributo multivalorado, con diferente campo llave, y donde se va a repetir la llave foránea para conocer que registros de esta nueva tabla corresponden a un registro de la tabla original.
7. Los campos derivados se representan como una columna de la tabla.
8. Si una relación contiene atributos, automáticamente se convierte en tabla, tomando los atributos de la relación como campos de la tabla y  los campos llaves de las tablas que participan en la relación como campos de esta nueva tabla.