ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Primera forma normal wiki: info, historia y vídeos

videos internet

salud  Primera forma normal 


La primera forma normal (1FN o bien forma mínima) es forma normal utilizada en normalización de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren esencialmente a asegurarse que la tabla es una representación leal de una relación y está libre de "conjuntos repetitivos".


Sin embargo, el término de "conjunto repetitivo", es entendido de distintas formas por diferentes teóricos. Como consecuencia, no hay un pacto universal en lo que se refiere a qué peculiaridades descalificarían a una tabla de estar en 1FN. Muy de manera notable, la 1FN, como es definida por ciertos autores excluye "atributos relación-valor" (tablas en tablas) siguiendo el precedente establecido por (Y también.F. Codd (ciertos de esos autores son: Ramez Elmasri y Shamkant B. Navathe). Por otra parte, conforme lo definido por otros autores, la 1FN sí los deja (por servirnos de un ejemplo como la define Chris Date).


Según la definición de Date de la 1FN, una tabla está en 1FN si y solo si es "isomorfa a alguna relación", lo que significa, particularmente, que satisface las próximas 5 condiciones:



La violación de cualquiera de estas condiciones querría decir que la tabla no es rigurosamente relacional, y por ende no está en 1FN.


Algunos ejemplos de tablas (o bien de vistas) que no satisfacen esta definición de primera forma normal son:



  • Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación de la condición tres.
  • Una vista cuya definición demanda que los resultados sean retornados en un orden particular, de forma que el orden de la fila sea un aspecto intrínseco y significativo de la vista. Esto viola la condición 1. Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra.
  • Una tabla con al menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estaría en violación de la condición cuatro, que requiere a cada campo contener precisamente un valor de su dominio de columna. No obstante, debe observarse que este aspecto de la condición cuatro es discutido. Muchos autores estiman que una tabla está en 1FN si ninguna clave aspirante puede contener valores nulos, mas se admiten estos para atributos (campos) que no sean clave, conforme el modelo original de Codd sobre el modelo relacional, el que hizo predisposición explícita para los nulos.

La cuarta condición de Date, que expresa "lo que la mayor parte de la gente piensa como la característica que define la 1FN", concierne a conjuntos repetidos. El próximo ejemplo ilustra de qué forma un diseño de base de datos puede agregar la reiteración de conjuntos, en violación de la 1FN.


Ejemplo 1: Dominios y valores


Suponga que un diseñador principiante quiere guardar los nombres y los teléfonos de los clientes del servicio. Procede a delimitar una tabla de usuario como la que sigue:

ClienteID ClienteNombreApellidoTeléfono123RachelIngram555-ochocientos sesenta y uno-2025456JamesWright555-cuatrocientos tres-1659789CesarDure555-ochocientos ocho-9633

En este punto, el diseñador se da cuenta que un requerimiento es guardar múltiples números de teléfono para ciertos clientes del servicio. Razona que la forma más simple de hacer esto es dejar que el campo "Teléfono" contenga más de un valor en cualquier registro dado:

ClienteID ClienteNombreApellidoTeléfono123RachelIngram555-ochocientos sesenta y uno-2025456JamesWright555-cuatrocientos tres-1659
quinientos cincuenta y cinco-setecientos setenta y seis-4100789CesarDure555-ochocientos ocho-9633

Asumiendo, no obstante, que la columna "Teléfono" está definida en algún género de dominio de número de teléfono (por servirnos de un ejemplo, el dominio de cadenas de doce caracteres de longitud), la representación de arriba no está en 1FN. La 1FN (y el RDBMS) prohíbe a un campo contener más de un valor de su dominio de columna.


Ejemplo 2: Conjuntos repetidos por medio de columnas


El diseñador puede eludir esta limitación definiendo múltiples columnas del número telefónico:

ClienteID ClienteNombreApellidoTeléfono 1Teléfono 2Teléfono 3123RachelIngram555-ochocientos sesenta y uno-2025456JamesWright555-cuatrocientos tres-un millón seiscientos cincuenta y nueve mil quinientos cincuenta y cinco-setecientos setenta y seis-4100789CesarDure555-ochocientos ocho-9633

Sin embargo, esta representación utiliza columnas que dejan valores nulos, y por tanto no se conforman con la definición de la 1FN de Date. Aun si se contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía con el espíritu de 1NF. Teléfono 1, Teléfono dos, y Teléfono tres, comparten el mismo dominio y el mismo significado, dividir los números telefónicos en 3 encabezados es artificial y causa inconvenientes lógicos.



  • Dificultad en hacer consultas a la tabla. Es bastante difícil responder preguntas como "¿Qué clientes del servicio tienen el teléfono X?" y "¿Qué pares de clientes del servicio comparten un número?".
  • La imposibilidad de hacer cumplir la unicidad los links Usuario-a-Teléfono por medio del RDBMS. Al usuario setecientos ochenta y nueve se le puede dar erróneamente un valor para el Teléfono dos que es precisamente igual que el valor de su Teléfono 1.
  • La limitación de los números telefónicos por usuario a 3. Si viene un cliente del servicio con 4 teléfonos, tenemos la obligación de guardar únicamente 3 y dejar el cuarto sin guardar. Esto quiere decir que el diseño de la base de datos está imponiendo limitaciones al proceso del negocio, en lugar de (como idealmente ha de ser el caso) del revés.

Ejemplo 3: Reiteración de conjuntos en columnas


El diseñador puede, de forma alternativa, preservar una sola columna de número, mas alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos:

ClienteID ClienteNombreApellidoTeléfono123RachelIngram555-ochocientos sesenta y uno-2025456JamesWright555-cuatrocientos tres-mil seiscientos cincuenta y nueve, quinientos cincuenta y cinco-setecientos setenta y seis-4100789CesarDure555-ochocientos ocho-9633

Éste es defendiblemente el peor diseño de todos, y otra vez no sostiene el espíritu de la 1NF. El encabezado "Teléfono" llega a ser semánticamente difuso, puesto que ahora puede representar, o bien un número, o bien una lista de números telefónicos, o bien en verdad cualquier cosa.Una consulta como "¿Qué pares de clientes del servicio comparten un teléfono?" es virtualmente imposible de elaborar, dada la necesidad de proveerse de listas de números de teléfono como teléfonos individuales. Con este diseño en la RDBMS, son asimismo imposibles de acotar significativas limitaciones en teléfonos.


Un diseño con 1FN


Un diseño que está inequívocamente en 1FN usa 2 tablas: una tabla de cliente del servicio y una tabla de teléfono del usuario.

ClienteID ClienteNombreApellido123RachelIngram456JamesWright789CesarDureTeléfono del clienteID ClienteTeléfono123555-ochocientos sesenta y uno-dos mil veinticinco millones cuatrocientos cincuenta y seis mil quinientos cincuenta y cinco-cuatrocientos tres-mil seiscientos cincuenta y nueve millones cuatrocientos cincuenta y seis mil quinientos cincuenta y cinco-setecientos setenta y seis-cuatro mil cien setecientos ochenta y nueve mil quinientos cincuenta y cinco-ochocientos ocho-9633

En este diseño no ocurren conjuntos repetidos de números de teléfono. En vez de eso, cada link Cliente del servicio-a-Teléfono aparece en su registro. Es valioso apreciar que este diseño cumple los requerimientos auxiliares para la segunda (2NF) y la tercera forma normal (3FN).


Algunas definiciones de 1NF, más de forma notable la de Y también.F. Codd, hacen referencia al término de atomicidad. Codd señala que "se precisa que los valores sean atómicos respecto al DBMS en los dominios en los que cada relación es definida". Codd define un valor atómico como uno que "no puede ser descompuesto en pedazos más pequeños por el DBMS (salvo ciertas funciones singulares)".


y han sugerido que el término de Codd de un "valor atómico" es equívoco, y que esta vaguedad ha conducido a una extensa confusión sobre de qué forma ha de ser entendida la 1NF. Particularmente, la noción de un "valor que no puede ser descompuesto" es conflictiva, puesto que parecería implicar que pocos, si algún, géneros de datos son atómicos:



  • Una cadena de caracteres parecería no ser atómica, puesto que el RDBMS típicamente da operadores para descomponerla en subcadenas.
  • Una data parecería no ser atómica, puesto que el RDBMS da típicamente operadores para descomponerla los componentes de día, mes, y año.
  • Un número de punto fijo parecería no ser atómico, puesto que el RDBMS da típicamente operadores para descomponerlo en componentes de números enteros y fraccionarios.

Date sugiere que "la noción de atomicidad no tiene ningún significado absoluto": un valor puede ser considerado atómico para ciertos propósitos, mas puede ser considerado un ensamblaje de elementos más básicos para otros propósitos. Si esta situación es admitida, la 1NF no puede ser definida con referencia a la atomicidad. Las columnas de cualquier clase de datos concebible (desde géneros de cadenas y tipos numéricos hasta géneros de arreglos y géneros de tabla) son entonces admisibles en una tabla 1NF - si bien tal vez no siempre y en toda circunstancia deseable. Date discute que los atributos relación-valor, a través de los que un campo en una tabla puede contener una tabla, son útiles en casos extraños.


Cualquier tabla que esté en la segunda forma normal (2NF) o bien más arriba, asimismo está, por definición, en 1NF (cada forma normal tiene criterios más estrictos que su predecesor). Por un lado, una tabla que está en 1NF puede o bien no puede estar en 2NF; si está en 2NF, puede o bien no puede estar en 3NF, y de esta forma consecutivamente.


Las formas normales más arriba que la 1NF son concebidas para encargarse de las situaciones en las que una tabla padece de inconvenientes de diseño que pueden comprometer la integridad de los datos dentro de ella. Por poner un ejemplo, la tabla siguiente está en 1NF, mas no está en 2NF y por ende es frágil a inconsistencias lógicas:

Dirección de correo del subscriptorID del subscriptorDirección de correoPrimer nombre del subscriptorApellido del Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.Clark

La clave de la tabla es undefined.


Si Carol Robertson cambia su apellido por el de matrimonio, el cambio ha de ser aplicado a 2 filas. Si el cambio es aplicado únicamente a una fila, resulta en una contradicción: el interrogante "¿cuál es nombre del usuario doscientos cincuenta y dos?" tiene 2 contestaciones que están en enfrentamiento. La 2NF aborda este inconveniente.


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 

Está aquí: Inicio > [ INTERNET ] > ıllı Primera forma normal wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas