Diseo conceptual de bases de datos.

Modelo entidad-relacin
En este captulo se presenta una metodologa para el diseo conceptual de bases de datos que se basa en el modelo de datos ms popular en la actualidad, el modelo entidad-relacin.

Introduccin Para la introduccin a este captulo se toman algunos prrafos del texto de Batini, Ceri !a"at#e $%&&'(. )El diseo de bases de datos es el proceso por el que se determina la organi*acin de una base de datos, incluidos su estructura, contenido las aplicaciones que se #an de desarrollar. +urante muc#o tiempo, el diseo de bases de datos fue considerado una tarea para expertos, ms un arte que una ciencia. -in embargo, se #a progresado muc#o en el diseo de bases de datos .ste se considera a#ora una disciplina estable, con m.todos t.cnicas propios. +ebido a la creciente aceptacin de las bases de datos por parte de la industria el gobierno en el plano comercial, a una "ariedad de aplicaciones cientficas t.cnicas, el diseo de bases de datos desempea un papel central en el empleo de los recursos de informacin en la ma ora de las organi*aciones. El diseo de bases de datos #a pasado a constituir parte de la formacin general de los informticos, en el mismo ni"el que la capacidad de construir algoritmos usando un lengua/e de programacin con"encional.) )0as 1ltimas dos d.cadas se #an caracteri*ado por un fuerte crecimiento en el n1mero e importancia de las aplicaciones de bases de datos. 0as bases de datos son componentes esenciales de los sistemas de informacin, usadas rutinariamente en todos los computadores 2...3. El diseo de bases de datos se #a con"ertido en una acti"idad popular, desarrollada no slo por profesionales sino tambi.n por no especialistas. 4 finales de la d.cada de %&56, cuando las bases de datos entraron por primera "e* en el mercado del soft7are, los diseadores de bases de datos actuaban como artesanos, con #erramientas mu primiti"as, diagramas de bloques estructuras de registros eran los formatos comunes para las especificaciones, el diseo de bases de datos se confunda frecuentemente con la implantacin de las bases de datos. Esta situacin a#ora #a cambiado, los m.todos modelos de diseo de bases de datos #an e"olucionado paralelamente con el progreso de la tecnologa en los sistemas de bases de datos. -e #a entrado en

la era de los sistemas relacionales de bases de datos, que ofrecen poderosos lengua/es de consulta, #erramientas para el desarrollo de aplicaciones e interfaces amables con los usuarios. 0a tecnologa de bases de datos cuenta a con un marco terico, que inclu e la teora relacional de datos, procesamiento optimi*acin de consultas, control de concurrencia, gestin de transacciones recuperacin, etc. -eg1n #a a"an*ado la tecnologa de bases de datos, as se #an desarrollado las metodologas t.cnicas de diseo. -e #a alcan*ado un consenso, por e/emplo, sobre la descomposicin del proceso de diseo en fases, sobre los principales ob/eti"os de cada fase sobre las t.cnicas para conseguir estos ob/eti"os.) )+esafortunadamente, las metodologas de diseo de bases de datos no son mu populares8 la ma ora de las organi*aciones de los diseadores indi"iduales confa mu poco en las metodologas para lle"ar a cabo el diseo esto se considera, con frecuencia, una de las principales causas de fracaso en el desarrollo de los sistemas de informacin. +ebido a la falta de enfoques estructurados para el diseo de bases de datos, a menudo se subestiman el tiempo o los recursos necesarios para un pro ecto de bases de datos, las bases de datos son inadecuadas o ineficientes en relacin a las demandas de la aplicacin, la documentacin es limitada el mantenimiento es difcil. 9uc#os de estos problemas se deben a la falta de una claridad que permita entender la naturale*a exacta de los datos, a un ni"el conceptual abstracto. En muc#os casos, los datos se describen desde el comien*o del pro ecto en t.rminos de las estructuras finales de almacenamiento8 no se da peso a un entendimiento de las propiedades estructurales de los datos que sea independiente de los detalles de la reali*acin.) Metodologa de diseo de bases de datos El diseo de una base de datos es un proceso comple/o que abarca decisiones a mu distintos ni"eles. 0a comple/idad se controla me/or si se descompone el problema en subproblemas se resuel"e cada uno de estos subproblemas independientemente, utili*ando t.cnicas especficas. 4s, el diseo de una base de datos se descompone en diseo conceptual, diseo lgico diseo fsico. El diseo conceptual parte de las especificaciones de requisitos de usuario su resultado es el esquema conceptual de la base de datos. :n esquema conceptual es una descripcin de alto ni"el de la estructura de la base de datos, independientemente del -;B+ que se "a a a utili*ar para manipularla. :n modelo conceptual es un lengua/e que se utili*a para describir esquemas conceptuales. El ob/eti"o del diseo conceptual es describir el contenido de

informacin de la base de datos no las estructuras de almacenamiento que se necesitarn para mane/ar esta informacin. El diseo lgico parte del esquema conceptual da como resultado un esquema lgico. :n esquema lgico es una descripcin de la estructura de la base de datos en t.rminos de las estructuras de datos que puede procesar un tipo de -;B+. :n modelo lgico es un lengua/e usado para especificar esquemas lgicos $modelo relacional, modelo de red, etc.(. El diseo lgico depende del tipo de -;B+ que se "a a a utili*ar, no depende del producto concreto. El diseo fsico parte del esquema lgico da como resultado un esquema fsico. :n esquema fsico es una descripcin de la implementacin de una base de datos en memoria secundaria, las estructuras de almacenamiento los m.todos utili*ados para tener un acceso eficiente a los datos. Por ello, el diseo fsico depende del -;B+ concreto el esquema fsico se expresa mediante su lengua/e de definicin de datos. Modelos de datos :n modelo de datos es una serie de conceptos que puede utili*arse para describir un con/unto de datos las operaciones para manipularlos. <a dos tipos de modelos de datos, los modelos conceptuales los modelos lgicos. 0os modelos conceptuales se utili*an para representar la realidad a un alto ni"el de abstraccin. 9ediante los modelos conceptuales se puede construir una descripcin de la realidad fcil de entender. En los modelos lgicos, las descripciones de los datos tienen una correspondencia sencilla con la estructura fsica de la base de datos. En el diseo de bases de datos se usan primero los modelos conceptuales para lograr una descripcin de alto ni"el de la realidad, luego se transforma el esquema conceptual en un esquema lgico. El moti"o de reali*ar estas dos etapas es la dificultad de abstraer la estructura de una base de datos que presente cierta comple/idad. :n esquema es un con/unto de representaciones ling=sticas o grficas que describen la estructura de los datos de inter.s. 0os modelos conceptuales deben ser buenas #erramientas para representar la realidad, por lo que deben poseer las siguientes cualidades, > Expresividad, deben tener suficientes conceptos para expresar perfectamente la realidad. > Simplicidad, deben ser simples para que los esquemas sean fciles de entender.

>

Minimalidad, cada concepto debe tener un significado distinto.

> Formalidad, todos los conceptos deben tener una interpretacin 1nica, precisa bien definida. En general, un modelo no es capa* de expresar todas las propiedades de una realidad determinada, por lo que #a que aadir aserciones que complementen el esquema. El modelo entidad-relacin El modelo entidad-relacin es el modelo conceptual ms utili*ado para el diseo conceptual de bases de datos. ?ue introducido por Peter C#en en %&@5. El modelo entidad-relacin est formado por un con/unto de conceptos que permiten describir la realidad mediante un con/unto de representaciones grficas ling=sticas. Ariginalmente, el modelo entidad-relacin slo inclua los conceptos de entidad, relacin atributo. 9s tarde, se aadieron otros conceptos, como los atributos compuestos las /erarquas de generali*acin, en lo que se #a denominado modelo entidad-relacin extendido.

Figura: Conceptos del modelo entidad-relacin extendido. Entidad Cualquier tipo de ob/eto o concepto sobre el que se recoge informacin, cosa, persona, concepto abstracto o suceso. Por e/emplo, coc#es, casas, empleados, clientes, empresas, oficios, diseos de productos, conciertos, excursiones, etc. 0as entidades se representan grficamente mediante rectngulos su nombre aparece en el interior. :n nombre de entidad slo puede aparecer una "e* en el esquema conceptual. <a dos tipos de entidades, fuertes d.biles. :na entidad dbil es una entidad cu a existencia depende de la existencia de otra entidad. :na entidad fuerte es una entidad que no es d.bil. Relacin (interrelacin) Es una correspondencia o asociacin entre dos o ms entidades. Cada relacin tiene un nombre que describe su funcin. 0as relaciones se representan grficamente mediante rombos su nombre aparece en el interior.

0as entidades que estn in"olucradas en una determinada relacin se denominan entidades participantes. El n1mero de participantes en una relacin es lo que se denomina grado de la relacin. Por lo tanto, una relacin en la que participan dos entidades es una relacin binaria8 si son tres las entidades participantes, la relacin es ternaria8 etc. :na relacin recursiva es una relacin donde la misma entidad participa ms de una "e* en la relacin con distintos papeles. El nombre de estos papeles es importante para determinar la funcin de cada participacin. 0a cardinalidad con la que una entidad participa en una relacin especifica el n1mero mnimo el n1mero mximo de correspondencias en las que puede tomar parte cada ocurrencia de dic#a entidad. 0a participacin de una entidad en una relacin es obligatoria total! si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad participante. -i no, la participacin es opcional parcial!. 0as reglas que definen la cardinalidad de las relaciones son las reglas de negocio. 4 "eces, surgen problemas cuando se est diseado un esquema conceptual. Estos problemas, denominados trampas, suelen producirse a causa de una mala interpretacin en el significado de alguna relacin, por lo que es importante comprobar que el esquema conceptual carece de dic#as trampas. En general, para encontrar las trampas, #a que asegurarse de que se entiende completamente el significado de cada relacin. -i no se entienden las relaciones, se puede crear un esquema que no represente fielmente la realidad. :na de las trampas que pueden encontrarse ocurre cuando el esquema representa una relacin entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de resol"erla es reestructurando el esquema para representar la asociacin entre las entidades correctamente. Atra de las trampas sucede cuando un esquema sugiere la existencia de una relacin entre entidades, pero el camino entre una otra no existe para algunas de sus ocurrencias. En este caso, se produce una p.rdida de informacin que se puede subsanar introduciendo la relacin que sugera el esquema que no estaba representada. tributo Es una caracterstica de inter.s o un #ec#o sobre una entidad o sobre una relacin. 0os atributos representan las propiedades bsicas de las entidades de las relaciones. Boda la informacin extensi"a es

portada por los atributos. ;rficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen. Cada atributo tiene un con/unto de "alores asociados denominado dominio. El dominio define todos los "alores posibles que puede tomar un atributo. Puede #aber "arios atributos definidos sobre un mismo dominio. 0os atributos pueden ser simples o compuestos. :n atributo simple es un atributo que tiene un solo componente, que no se puede di"idir en partes ms pequeas que tengan un significado propio. :n atributo compuesto es un atributo con "arios componentes, cada uno con un significado por s mismo. :n grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. :n atributo compuesto se representa grficamente mediante un "alo. 0os atributos tambi.n pueden clasificarse en mono"alentes o poli"alentes. :n atributo monovalente es aquel que tiene un solo "alor para cada ocurrencia de la entidad o relacin a la que pertenece. :n atributo polivalente es aquel que tiene "arios "alores para cada ocurrencia de la entidad o relacin a la que pertenece. 4 estos atributos tambi.n se les denomina multivaluados, pueden tener un n1mero mximo un n1mero mnimo de "alores. 0a cardinalidad de un atributo indica el n1mero mnimo el n1mero mximo de "alores que puede tomar para cada ocurrencia de la entidad o relacin a la que pertenece. El "alor por omisin es. Por 1ltimo, los atributos pueden ser deri"ados. :n atributo derivado es aquel que representa un "alor que se puede obtener a partir del "alor de uno o "arios atributos, que no necesariamente deben pertenecer a la misma entidad o relacin. Identi!icador :n identificador de una entidad es un atributo o con/unto de atributos que determina de modo 1nico cada ocurrencia de esa entidad. :n identificador de una entidad debe cumplir dos condiciones, %. !o pueden existir dos ocurrencias de la entidad con el mismo "alor del identificador. C. -i se omite cualquier atributo del identificador, la condicin anterior de/a de cumplirse. Boda entidad tiene al menos un identificador puede tener "arios identificadores alternati"os. 0as relaciones no tienen identificadores.

"erar#ua de generali$acin :na entidad E es una generali*acin de un grupo de entidades E " E " ... E , si cada ocurrencia de cada una de esas entidades es tambi.n una ocurrencia de E. Bodas las propiedades de la entidad gen.rica E son #eredadas por las subentidades. Cada /erarqua es total o parcial, exclusi"a o superpuesta. :na /erarqua es total si cada ocurrencia de la entidad gen.rica corresponde al menos con una ocurrencia de alguna subentidad. Es parcial si existe alguna ocurrencia de la entidad gen.rica que no corresponde con ninguna ocurrencia de ninguna subentidad. :na /erarqua es exclusiva si cada ocurrencia de la entidad gen.rica corresponde, como muc#o, con una ocurrencia de una sola de las subentidades. Es superpuesta si existe alguna ocurrencia de la entidad gen.rica que corresponde a ocurrencias de dos o ms subentidades diferentes. :n subcon#unto es un caso particular de generali*acin con una sola entidad como subentidad. :n subcon/unto siempre es una /erarqua parcial exclusi"a.

Metodologa de diseo conceptual

El primer paso en el diseo de una base de datos es la produccin del esquema conceptual. !ormalmente, se constru en "arios esquemas conceptuales, cada uno para representar las distintas "isiones que los usuarios tienen de la informacin. Cada una de estas "isiones suelen corresponder a las diferentes reas funcionales de la empresa como, por e/emplo, produccin, "entas, recursos #umanos, etc. Estas "isiones de la informacin, denominadas vistas, se pueden identificar de "arias formas. :na opcin consiste en examinar los diagramas de flu/o de datos, que se pueden #aber producido pre"iamente, para identificar cada una de las reas funcionales. 0a otra opcin consiste en entre"istar a los usuarios, examinar los procedimientos, los informes los formularios, tambi.n obser"ar el funcionamiento de la empresa. 4 los esquemas conceptuales correspondientes a cada "ista de usuario se les denomina esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e identificadores. El esquema conceptual tambi.n tendr una documentacin, que se ir produciendo durante su desarrollo. 0as tareas a reali*ar en el diseo conceptual son las siguientes, %. Ddentificar las entidades.

C. E. '. F. 5. @. G.

Ddentificar las relaciones. Ddentificar los atributos asociarlos a entidades relaciones.

+eterminar los dominios de los atributos. +eterminar los identificadores. +eterminar las /erarquas de generali*acin $si las #a (. +ibu/ar el diagrama entidad-relacin. He"isar el esquema conceptual local con el usuario.

%. Ddentificar las entidades En primer lugar #a que definir los principales ob/etos que interesan al usuario. Estos ob/etos sern las entidades. :na forma de identificar las entidades es examinar las especificaciones de requisitos de usuario. En estas especificaciones se buscan los nombres o los sintagmas nominales que se mencionan $por e/emplo, n1mero de empleado, nombre de empleado, n1mero de inmueble, direccin del inmueble, alquiler, n1mero de #abitaciones(. Bambi.n se buscan ob/etos importantes como personas, lugares o conceptos de inter.s, exclu endo aquellos nombres que slo son propiedades de otros ob/etos. Por e/emplo, se pueden agrupar el n1mero de empleado el nombre de empleado en una entidad denominada empleado, agrupar n1mero de inmueble, direccin del inmueble, alquiler n1mero de #abitaciones en otra entidad denominada inmueble. Atra forma de identificar las entidades es buscar aquellos ob/etos que existen por s mismos. Por e/emplo, empleado es una entidad porque los empleados existen, sepamos o no sus nombres, direcciones tel.fonos. -iempre que sea posible, el usuario debe colaborar en la identificacin de las entidades. 4 "eces, es difcil identificar las entidades por la forma en que aparecen en las especificaciones de requisitos. 0os usuarios, a "eces, #ablan utili*ando e/emplos o analogas. En lugar de #ablar de empleados en general, #ablan de personas concretas, o bien, #ablan de los puestos que ocupan esas personas. Para liarlo a1n ms, los usuarios usan, muc#as "eces, sinnimos #omnimos. +os palabras son sinnimos cuando tienen el mismo significado. 0os #omnimos ocurren cuando la misma palabra puede tener distintos significados dependiendo del contexto.

!o siempre es ob"io saber si un ob/eto es una entidad, una relacin o un atributo. Por e/emplo Icmo se podra clasificar matrimonioJ Pues de cualquiera de las tres formas. El anlisis es sub/eti"o, por lo que distintos diseadores pueden #acer distintas interpretaciones, aunque todas igualmente "lidas. Bodo depende de la opinin la experiencia de cada uno. 0os diseadores de bases de datos deben tener una "isin selecti"a clasificar las cosas que obser"an dentro del contexto de la empresa u organi*acin. 4 partir de unas especificaciones de usuario es posible que no se pueda deducir un con/unto 1nico de entidades, pero despu.s de "arias iteraciones del proceso de anlisis, se llegar a obtener un con/unto de entidades que sean adecuadas para el sistema que se #a de construir. Conforme se "an identificando las entidades, se les dan nombres que tengan un significado que sean ob"ias para el usuario. 0os nombres de las entidades sus descripciones se anotan en el diccionario de datos. Cuando sea posible, se debe anotar tambi.n el n1mero aproximado de ocurrencias de cada entidad. -i una entidad se conoce por "arios nombres, .stos se deben anotar en el diccionario de datos como alias o sinnimos. C. Ddentificar las relaciones :na "e* definidas las entidades, se deben definir las relaciones existentes entre ellas. +el mismo modo que para identificar las entidades se buscaban nombres en las especificaciones de requisitos, para identificar las relaciones se suelen buscar las expresiones "erbales $por e/emplo, oficina tiene empleados, empleado gestiona inmueble, cliente "isita inmueble(. -i las especificaciones de requisitos refle/an estas relaciones es porque son importantes para la empresa , por lo tanto, se deben refle/ar en el esquema conceptual. Pero slo interesan las relaciones que son necesarias. En el e/emplo anterior, se #an identificado las relaciones empleado gestiona inmueble cliente visita inmueble. -e podra pensar en incluir una relacin entre empleado cliente, empleado atiende a cliente, pero obser"ando las especificaciones de requisitos no parece que #a a inter.s en modelar tal relacin. 0a ma ora de las relaciones son binarias $entre dos entidades(, pero no #a que ol"idar que tambi.n puede #aber relaciones en las que participen ms de dos entidades, as como relaciones recursi"as. Es mu importante repasar las especificaciones para comprobar que todas las relaciones, explcitas o implcitas, se #an encontrado. -i se tienen pocas entidades, se puede comprobar por pare/as si #a alguna relacin entre ellas. +e todos modos, las relaciones que no se

identifican a#ora se suelen encontrar cuando se "alida el esquema con las transacciones que debe soportar. :na "e* identificadas todas las relaciones, #a que determinar la cardinalidad mnima mxima con la que participa cada entidad en cada una de ellas. +e este modo, el esquema representa de un modo ms explcito la semntica de las relaciones. 0a cardinalidad es un tipo de restriccin que se utili*a para comprobar mantener la calidad de los datos. Estas restricciones son aserciones sobre las entidades que se pueden aplicar cuando se actuali*a la base de datos para determinar si las actuali*aciones "iolan o no las reglas establecidas sobre la semntica de los datos. Conforme se "an identificando las relaciones, se les "an asignando nombres que tengan significado para el usuario. En el diccionario de datos se anotan los nombres de las relaciones, su descripcin las cardinalidades con las que participan las entidades en ellas. E. Ddentificar los atributos asociarlos a entidades relaciones

4l igual que con las entidades, se buscan nombres en las especificaciones de requisitos. -on atributos los nombres que identifican propiedades, cualidades, identificadores o caractersticas de entidades o relaciones. 0o ms sencillo es preguntarse, para cada entidad cada relacin, Iqu. informacin se quiere saber de ...J 0a respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos. Pero, en ocasiones, ser necesario preguntar a los usuarios para que aclaren los requisitos. +esgraciadamente, los usuarios pueden dar respuestas a esta pregunta que tambi.n contengan otros conceptos, por lo que #a que considerar sus respuestas con muc#o cuidado. 4l identificar los atributos, #a que tener en cuenta si son simples o compuestos. Por e/emplo, el atributo direccin puede ser simple, teniendo la direccin completa como un solo "alor, K-an Hafael 'F, 4lma*oraL8 o puede ser un atributo compuesto, formado por la calle $K-an HafaelL(, el n$mero $K'FL( la poblacin $K4lma*oraL(. El escoger entre atributo simple o compuesto depende de los requisitos del usuario. -i el usuario no necesita acceder a cada uno de los componentes de la direccin por separado, se puede representar como un atributo simple. Pero si el usuario quiere acceder a los componentes de forma indi"idual, entonces se debe representar como un atributo compuesto. Bambi.n se deben identificar los atributos deri"ados o calculados, que son aquellos cu o "alor se puede calcular a partir de los "alores de otros atributos. Por e/emplo, el n1mero de empleados de cada

oficina, la edad de los empleados o el n1mero de inmuebles que gestiona cada empleado. 4lgunos diseadores no representan los atributos deri"ados en los esquemas conceptuales. -i se #ace, se debe indicar claramente que el atributo es deri"ado a partir de qu. atributos se obtiene su "alor. +onde #a que considerar los atributos deri"ados es en el diseo fsico. Cuando se estn identificando los atributos, se puede descubrir alguna entidad que no se #a identificado pre"iamente, por lo que #a que "ol"er al principio introduciendo esta entidad "iendo si se relaciona con otras entidades. Es mu 1til elaborar una lista de atributos e ir eliminndolos de la lista conforme se "a an asociando a una entidad o relacin. +e este modo, uno se puede asegurar de que cada atributo se asocia a una sola entidad o relacin, que cuando la lista se #a acabado, se #an asociado todos los atributos. <a que tener muc#o cuidado cuando parece que un mismo atributo se debe asociar a "arias entidades. Esto puede ser por una de las siguientes causas, > -e #an identificado "arias entidades, como director, supervisor administrativo, cuando, de #ec#o, pueden representarse como una sola entidad denominada empleado. En este caso, se puede escoger entre introducir una /erarqua de generali*acin, o de/ar las entidades que representan cada uno de los puestos de empleado. > -e #a identificado una relacin entre entidades. En este caso, se debe asociar el atributo a una sola de las entidades #a que asegurarse de que la relacin a se #aba identificado pre"iamente. -i no es as, se debe actuali*ar la documentacin para recoger la nue"a relacin. Conforme se "an identificando los atributos, se les asignan nombres que tengan significado para el usuario. +e cada atributo se debe anotar la siguiente informacin, > > > > !ombre descripcin del atributo.

4lias o sinnimos por los que se conoce al atributo. Bipo de dato longitud.

Malores por defecto del atributo $si se especifican(.

> -i el atributo siempre "a a tener un "alor $si admite o no nulos(.

> -i el atributo es compuesto simples lo forman. > -i el atributo es deri"ado "alor. >

, en su caso, qu. atributos

, en su caso, cmo se calcula su

-i el atributo es multie"aluado.

'. +eterminar los dominios de los atributos El dominio de un atributo es el con/unto de "alores que puede tomar el atributo. Por e/emplo el dominio de los n1meros de oficina son las tiras de #asta tres caracteres en donde el primero es una letra el siguiente o los dos siguientes son dgitos en el rango de % a &&8 el dominio de los n1meros de tel.fono los n1meros de fax son las tiras de & dgitos. :n esquema conceptual est completo si inclu e los dominios de cada atributo, los "alores permitidos para cada atributo, su tamao su formato. Bambi.n se puede incluir informacin adicional sobre los dominios como, por e/emplo, las operaciones que se pueden reali*ar sobre cada atributo, qu. atributos pueden compararse entre s o qu. atributos pueden combinarse con otros. 4unque sera mu interesante que el sistema final respetara todas estas indicaciones sobre los dominios, esto es toda"a una lnea abierta de in"estigacin. Boda la informacin sobre los dominios se debe anotar tambi.n en el diccionario de datos. F. +eterminar los identificadoresNcla"es Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los identificadores de cada una de las entidades. 0os identificadores pueden ser simples o compuestos. +e cada entidad se escoger uno de los identificadores como cla"e primaria en la fase del diseo lgico. Cuando se determinan los identificadores es fcil darse cuenta de si una entidad es fuerte o d.bil. -i una entidad tiene al menos un identificador, es fuerte $otras denominaciones son padre, propietaria o dominante(. -i una entidad no tiene atributos que le sir"an de identificador, es dbil $otras denominaciones son %i#o, dependiente o subordinada(. Bodos los identificadores de las entidades se deben anotar en el diccionario de datos.

5. +eterminar las /erarquas de generali*acin En este paso #a que obser"ar las entidades que se #an identificado #asta el momento. <a que "er si es necesario refle/ar las diferencias entre distintas ocurrencias de una entidad, con lo que surgirn nue"as subentidades de esta entidad gen.rica8 o bien, si #a entidades que tienen caractersticas en com1n que realmente son subentidades de una nue"a entidad gen.rica. En cada /erarqua #a que determinar si es total o parcial o superpuesta. @. +ibu/ar el diagrama entidad-relacin :na "e* identificados todos los conceptos, se puede dibu/ar el diagrama entidad-relacin correspondiente a una de las "istas de los usuarios. -e obtiene as un esquema conceptual local. G. He"isar el esquema conceptual local con el usuario 4ntes de dar por finali*ada la fase del diseo conceptual, se debe re"isar el esquema conceptual local con el usuario. Este esquema est formado por el diagrama entidad-relacin toda la documentacin que describe el esquema. -i se encuentra alguna anomala, #a que corregirla #aciendo los cambios oportunos, por lo que posiblemente #a a que repetir alguno de los pasos anteriores. Este proceso debe repetirse #asta que se est. seguro de que el esquema conceptual es una fiel representacin de la parte de la empresa que se est tratando de modelar. Hesumen El diseo de bases de datos se descompone en tres etapas, diseo conceptual, diseo lgico diseo fsico. El diseo conceptual es el proceso por el cual se constru e un modelo de la informacin que se utili*a en una empresa u organi*acin, independientemente del -;B+ que se "a a a utili*ar para implementar el sistema de los equipos informticos o cualquier otra consideracin fsica. :n modelo conceptual es un con/unto de conceptos que permiten describir la realidad mediante representaciones ling=sticas grficas. 0os modelos conceptuales deben poseer una serie de propiedades, expresi"idad, simplicidad, minimalidad formalidad. El modelo conceptual ms utili*ado es el modelo entidad-relacin, que posee los siguientes conceptos, entidades, relaciones, atributos, dominios de atributos, identificadores /erarquas de generali*acin. exclusi"a

En la metodologa del diseo conceptual se constru e un esquema conceptual local para cada "ista de cada usuario o grupo de usuarios. En el diseo lgico se obtiene un esquema lgico local para cada esquema conceptual local. Estos esquemas lgicos se integran despu.s para formar un esquema lgico global que represente todas las "istas de los distintos usuarios de la empresa. Por 1ltimo, en el diseo fsico, se constru e la implementacin de la base de datos sobre un -;B+ determinado. Oa que este diseo debe adaptarse al -;B+, es posible que #a a que introducir cambios en el esquema lgico para me/orar las prestaciones a ni"el fsico. Cada "ista de usuario comprende los datos que un usuario mane/a para lle"ar a cabo una determinada tarea. !ormalmente, estas "istas corresponden a las distintas reas funcionales de la empresa, se pueden identificar examinando los diagramas de flu/o de datos o entre"istando a los usuarios, examinando los procedimientos, informes formularios, obser"ando el funcionamiento de la empresa. Cada esquema conceptual local est formado por entidades, relaciones, atributos, dominios de atributos, identificadores puede #aber tambi.n /erarquas de generali*acin. 4dems, estos esquemas se completan documentndolos en el diccionario de datos.

Diseo lgico de bases de datos

En este captulo se describen los pasos para lle"ar a cabo el diseo lgico. Oa que aqu se trata el diseo de bases de datos relacionales, en esta etapa se obtiene un con/unto de relaciones $tablas( que representen los datos de inter.s. Este con/unto de relaciones se "alida mediante la normali*acin, t.cnica que se estudia al final del captulo. Introduccin El ob/eti"o del diseo lgico es con"ertir los esquemas conceptuales locales en un esquema lgico global que se a/uste al modelo de -;B+ sobre el que se "a a a implementar el sistema. 9ientras que el ob/eti"o fundamental del diseo conceptual es la complecin expresi"idad de los esquemas conceptuales locales, el ob/eti"o del diseo lgico es obtener una representacin que use, del modo ms eficiente posible, los recursos que el modelo de -;B+ posee para estructurar los datos para modelar las restricciones 0os modelos de bases de datos ms extendidos son el modelo relacional, el modelo de red el modelo /errquico. El modelo

orientado a ob/etos es tambi.n mu modelo estndar orientado a ob/etos.

popular, pero no existe un

El modelo relacional $ los modelos pre"ios( carecen de ciertos rasgos de abstraccin que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseo lgico consistir en la con"ersin de esos mecanismos de representacin de alto ni"el en t.rminos de las estructuras de ba/o ni"el disponibles en el modelo relacional. Metodologa de diseo lgico en el modelo relacional 0a metodologa que se "a a seguir para el diseo lgico en el modelo relacional consta de dos fases, cada una de ellas compuesta por "arios pasos que se detallan a continuacin. Construir usuario. "alidar los esquemas lgicos locales para cada "ista de

%. Con"ertir los esquemas conceptuales locales en esquemas lgicos locales. C. +eri"ar un con/unto de relaciones $tablas( para cada esquema lgico local. E. '. F. 5. Malidar cada esquema mediante la normali*acin. Malidar cada esquema frente a las transacciones del usuario. +ibu/ar el diagrama entidad-relacin. +efinir las restricciones de integridad. esquema lgico local con el usuario

@. He"isar cada correspondiente. Construir

"alidar el esquema lgico global.

G. 9e*clar los esquemas lgicos locales en un esquema lgico global. &. Malidar el esquema lgico global.

%6. Estudiar el crecimiento futuro. %%. +ibu/ar el diagrama entidad-relacin final. %C. He"isar el esquema lgico global con los usuarios.

En la primera fase, se constru en los esquemas lgicos locales para cada "ista de usuario se "alidan. En esta fase se refinan los esquemas conceptuales creados durante el diseo conceptual, eliminando las estructuras de datos que no se pueden implementar de manera directa sobre el modelo que soporta el -;B+, en el caso que nos ocupa, el modelo relacional. :na "e* #ec#o esto, se obtiene un primer esquema lgico que se "alida mediante la normali*acin frente a las transacciones que el sistema debe lle"ar a cabo, tal como se refle/a en las especificaciones de requisitos de usuario. El esquema lgico a "alidado se puede utili*ar como base para el desarrollo de prototipos. :na "e* finali*ada esta fase, se dispone de un esquema lgico para cada "ista de usuario que es correcto, comprensible sin ambig=edad. %. Con"ertir los esquemas conceptuales locales en esquemas lgicos locales En este paso, se eliminan de cada esquema conceptual las estructuras de datos que los sistemas relacionales no modelan directamente, (a) Eliminar las relaciones de muc%os a muc%os" sustitu endo cada una de ellas por una nue"a entidad intermedia dos relaciones de uno a muc#os de esta nue"a entidad con las entidades originales. 0a nue"a entidad ser d.bil, a que sus ocurrencias dependen de la existencia de ocurrencias en las entidades originales. (b) Eliminar las relaciones entre tres o m&s entidades" sustitu endo cada una de ellas por una nue"a entidad $d.bil( intermedia que se relaciona con cada una de las entidades originales. 0a cardinalidad de estas nue"as relaciones binarias depender de su significado. (c) Eliminar las relaciones recursivas" sustitu endo cada una de ellas por una nue"a entidad $d.bil( dos relaciones binarias de esta nue"a entidad con la entidad original. 0a cardinalidad de estas relaciones depender de su significado. (d) Eliminar las relaciones con atributos" sustitu endo cada una de ellas por una nue"a entidad $d.bil( las relaciones binarias correspondientes de esta nue"a entidad con las entidades originales. 0a cardinalidad de estas relaciones depender del tipo de la relacin original de su significado. (e) Eliminar los atributos multievaluados" sustitu endo cada uno de ellos por una nue"a entidad $d.bil( una relacin binaria de uno a muc#os con la entidad original.

(!) 'evisar las relaciones de uno a uno , a que es posible que se #a an identificado dos entidades que representen el mismo ob/eto $sinnimos(. -i as fuera, ambas entidades deben integrarse en una sola. (g) Eliminar las relaciones redundantes . :na relacin es redundante cuando se puede obtener la misma informacin que ella aporta mediante otras relaciones. El #ec#o de que #a a dos caminos diferentes entre dos entidades no implica que uno de los caminos corresponda a una relacin redundante, eso depender del significado de cada relacin. :na "e* finali*ado este paso, es ms correcto referirse a los esquemas conceptuales locales refinados como esquemas lgicos locales, a que se adaptan al modelo de base de datos que soporta el -;B+ escogido. C. +eri"ar un con/unto de relaciones $tablas( para cada esquema lgico local En este paso, se obtiene un con/unto de relaciones $tablas( para cada uno de los esquemas lgicos locales en donde se representen las entidades relaciones entre entidades, que se describen en cada una de las "istas que los usuarios tienen de la empresa. Cada relacin de la base de datos tendr un nombre, el nombre de sus atributos aparecer, a continuacin, entre par.ntesis. El atributo o atributos que forman la cla"e primaria se subra an. 0as cla"es a/enas, mecanismo que se utili*a para representar las relaciones entre entidades en el modelo relacional, se especifican aparte indicando la relacin $tabla( a la que #acen referencia. 4 continuacin, se describe cmo las relaciones $tablas( del modelo relacional representan las entidades relaciones que pueden aparecer en los esquemas lgicos. (a) Entidades fuertes. Crear una relacin para cada entidad fuerte que inclu a todos sus atributos simples. +e los atributos compuestos incluir slo sus componentes. Cada uno de los identificadores de la entidad ser una candidata. +e entre las cla"es candidatas #a que escoger la primaria8 el resto sern cla"es alternati"as. Para escoger la primaria entre las cla"es candidatas se pueden seguir indicaciones, > Escoger la cla"e candidata que tenga menos atributos. cla"e cla"e cla"e estas

> Escoger la cla"e candidata probabilidad de cambiar en el futuro.

cu os

"alores "alores

no no

tengan tengan

> Escoger la cla"e candidata cu os probabilidad de perder la unicidad en el futuro.

> Escoger la cla"e candidata con el mnimo n1mero de caracteres $si es de tipo texto(. > Escoger la cla"e candidata ms fcil de utili*ar desde el punto de "ista de los usuarios. (b) Entidades dbiles. Crear una relacin para cada entidad d.bil inclu endo todos sus atributos simples. +e los atributos compuestos incluir slo sus componentes. 4adir una cla"e a/ena a la entidad de la que depende. Para ello, se inclu e la cla"e primaria de la relacin que representa a la entidad padre en la nue"a relacin creada para la entidad d.bil. 4 continuacin, determinar la cla"e primaria de la nue"a relacin. (c) 'elaciones binarias de uno a uno. Para cada relacin binaria se inclu en los atributos de la cla"e primaria de la entidad padre en la relacin $tabla( que representa a la entidad #i/o, para actuar como una cla"e a/ena. 0a entidad #i/o es la que participa de forma total $obligatoria( en la relacin, mientras que la entidad padre es la que participa de forma parcial $opcional(. -i las dos entidades participan de forma total o parcial en la relacin, la eleccin de padre e #i/o es arbitraria. 4dems, en caso de que ambas entidades participen de forma total en la relacin, se tiene la opcin de integrar las dos entidades en una sola relacin $tabla(. Esto se suele #acer si una de las entidades no participa en ninguna otra relacin. (d) 'elaciones binarias de uno a muc%os. Como en las relaciones de uno a uno, se inclu en los atributos de la cla"e primaria de la entidad padre en la relacin $tabla( que representa a la entidad #i/o, para actuar como una cla"e a/ena. Pero a#ora, la entidad padre es la de )la parte del muc#os) $cada padre tiene muc#os #i/os(, mientras que la entidad #i/o es la de )la parte del uno) $cada #i/o tiene un solo padre(. (e) (erarquas de generali)acin. En las /erarquas, se denomina entidad padre a la entidad gen.rica entidades #i/o a las subentidades. <a tres opciones distintas para representar las /erarquas. 0a eleccin de la ms adecuada se #ar en funcin de su tipo $totalNparcial, exclusi"aNsuperpuesta(. %. Crear una relacin por cada entidad. 0as relaciones de las entidades #i/o #eredan como cla"e primaria la de la entidad padre.

Por lo tanto, la cla"e primaria de las entidades #i/o es tambi.n una cla"e a/ena al padre. Esta opcin sir"e para cualquier tipo de /erarqua, total o parcial exclusi"a o superpuesta. C. Crear una relacin por cada entidad #i/o, #eredando los atributos de la entidad padre. Esta opcin slo sir"e para /erarquas totales exclusi"as. E. Dntegrar todas las entidades en una relacin, inclu endo en ella los atributos de la entidad padre, los atributos de todos los #i/os un atributo discriminati"o para indicar el caso al cual pertenece la entidad en consideracin. Esta opcin sir"e para cualquier tipo de /erarqua. -i la /erarqua es superpuesta, el atributo discriminati"o ser multie"aluado. :na "e* obtenidas las relaciones con sus atributos, cla"es primarias cla"es a/enas, slo queda actuali*ar el diccionario de datos con los nue"os atributos que se #a an identificado en este paso. E. Malidar cada esquema mediante la normali*acin 0a normali*acin se utili*a para me/orar el esquema lgico, de modo que satisfaga ciertas restricciones que e"iten la duplicidad de datos. 0a normali*acin garanti*a que el esquema resultante se encuentra ms prximo al modelo de la empresa, que es consistente que tiene la mnima redundancia la mxima estabilidad. 0a normali*acin es un proceso que permite decidir a qu. entidad pertenece cada atributo. :no de los conceptos bsicos del modelo relacional es que los atributos se agrupan en relaciones $tablas( porque estn relacionados a ni"el lgico. En la ma ora de las ocasiones, una base de datos normali*ada no proporciona la mxima eficiencia, sin embargo, el ob/eti"o a#ora es conseguir una base de datos normali*ada por las siguientes ra*ones, > :n esquema normali*ado organi*a los datos de acuerdo a sus dependencias funcionales, es decir, de acuerdo a sus relaciones lgicas. > El esquema lgico no tiene porqu. ser el esquema final. +ebe representar lo que el diseador entiende sobre la naturale*a el significado de los datos de la empresa. -i se establecen unos ob/eti"os en cuanto a prestaciones, el diseo fsico cambiar el esquema lgico de modo adecuado. :na posibilidad es que algunas relaciones normali*adas se desnormalicen. Pero la desnormali*acin no implica que se #a a malgastado tiempo normali*ando, a que mediante este proceso el diseador aprende ms sobre el significado de los datos. +e #ec#o, la normali*acin obliga a entender

completamente cada uno de los atributos que se #an de representar en la base de datos. > :n esquema normali*ado es robusto carece de redundancias, por lo que est libre de ciertas anomalas que .stas pueden pro"ocar cuando se actuali*a la base de datos. > 0os equipos informticos de #o en da son muc#o ms potentes, por lo que en ocasiones es ms ra*onable implementar bases de datos fciles de mane/ar $las normali*adas(, a costa de un tiempo adicional de proceso. > 0a normali*acin produce bases de datos con esquemas flexibles que pueden extenderse con facilidad. El ob/eti"o de este paso es obtener un con/unto de relaciones que se encuentren en la forma normal de Bo ce-Codd. Para ello, #a que pasar por la primera, segunda tercera formas normales

'. Malidar cada esquema frente a las transacciones del usuario El ob/eti"o de este paso es "alidar cada esquema lgico local para garanti*ar que puede soportar las transacciones requeridas por los correspondientes usuarios. Estas transacciones se encontrarn en las especificaciones de requisitos de usuario. 0o que se debe #acer es tratar de reali*ar las transacciones de forma manual utili*ando el diagrama entidad-relacin, el diccionario de datos las conexiones que establecen las cla"es a/enas de las relaciones $tablas(. -i todas las transacciones se pueden reali*ar, el esquema queda "alidado. Pero si alguna transaccin no se puede reali*ar, seguramente ser porque alguna entidad, relacin o atributo no se #a incluido en el esquema. F. +ibu/ar el diagrama entidad-relacin En este momento, se puede dibu/ar el diagrama entidad-relacin final para cada "ista de usuario que reco/a la representacin lgica de los datos desde su punto de "ista. Este diagrama #abr sido "alidado mediante la normali*acin frente a las transacciones de los usuarios. 5. +efinir las restricciones de integridad 0as restricciones de integridad son reglas que se quieren imponer para proteger la base de datos, de modo que no pueda llegar a un estado inconsistente. <a cinco tipos de restricciones de integridad.

(a) *atos requeridos. 4lgunos atributos deben contener "alores en todo momento, es decir, no admiten nulos. (b) 'estricciones de dominios. Bodos los atributos tienen un dominio asociado, que es el con/unto los "alores que cada atributo puede tomar. (c) +ntegridad de entidades. El identificador de una entidad no puede ser nulo, por lo tanto, las cla"es primarias de las relaciones $tablas( no admiten nulos. (d) +ntegridad referencial. :na cla"e a/ena enla*a cada tupla de la relacin #i/o con la tupla de la relacin padre que tiene el mismo "alor en su cla"e primaria. 0a integridad referencial dice que si una cla"e a/ena tiene un "alor $si es no nula(, ese "alor debe ser uno de los "alores de la cla"e primaria a la que referencia. <a "arios aspectos a tener en cuenta sobre las cla"es a/enas para lograr que se cumpla la integridad referencial. %. I4dmite nulos la cla"e a/enaJ Cada cla"e a/ena expresa una relacin. -i la participacin de la entidad #i/o en la relacin es total, entonces la cla"e a/ena no admite nulos8 si es parcial, la cla"e a/ena debe aceptar nulos. C. IPu. #acer cuando se quiere borrar una ocurrencia de la entidad padre que tiene alg1n #i/oJ A lo que es lo mismo, Iqu. #acer cuando se quiere borrar una tupla que est siendo referenciada por otra tupla a tra".s de una cla"e a/enaJ <a "arias respuestas posibles, o 'estringir, no se pueden borrar tuplas que estn siendo referenciadas por otras tuplas. o -ropagar, se borra la tupla deseada todas las tuplas que le #acen referencia. se propaga el borrado a

o .nular, se borra la tupla deseada todas las referencias que tena se ponen, automticamente, a nulo $esta respuesta slo es "lida si la cla"e a/ena acepta nulos(.

o /alor por defecto, se borra la tupla deseada todas las referencias toman, automticamente, el "alor por defecto $esta respuesta slo es "lida si se #a especificado un "alor por defecto para la cla"e a/ena(. o 0o comprobar, se borra la tupla deseada no se #ace nada para garanti*ar que se sigue cumpliendo la integridad referencial. E. IPu. #acer cuando se quiere modificar la cla"e primaria de una tupla que est siendo referenciada por otra tupla a tra".s de una cla"e a/enaJ 0as respuestas posibles son las mismas que en el caso anterior. Cuando se escoge propagar, se actuali*a la cla"e primaria en la tupla deseada se propaga el cambio a los "alores de cla"e a/ena que le #acan referencia. (e) 'eglas de negocio. Cualquier operacin que se realice sobre los datos debe cumplir las restricciones que impone el funcionamiento de la empresa. Bodas las restricciones de integridad establecidas en este paso se deben refle/ar en el diccionario de datos para que puedan ser tenidas en cuenta durante la fase del diseo fsico. @. He"isar cada esquema lgico local con el usuario correspondiente Para garanti*ar que cada esquema lgico local es una fiel representacin de la "ista del usuario lo que se debe #acer es comprobar con .l que lo refle/ado en el esquema en la documentacin es correcto est completo. Relacin entre el es#uema lgico % los diagramas de !lu&o de datos El esquema lgico refle/a la estructura de los datos a almacenar que mane/a la empresa. :n diagrama de flu/o de datos muestra cmo se mue"en los datos en la empresa los almacenes en donde se guardan. -i se #an utili*ado diagramas de flu/o de datos para modelar las especificaciones de requisitos de usuario, se pueden utili*ar para comprobar la consistencia completitud del esquema lgico desarrollado. Para ello, > Cada almac.n de datos debe corresponder con una o "arias entidades completas. > 0os atributos en los flu/os de datos deben corresponder a alguna entidad.

0os esquemas lgicos locales obtenidos #asta este momento se integrarn en un solo esquema lgico global en la siguiente fase para modelar los datos de toda la empresa. G. 9e*clar los esquemas lgicos locales en un esquema lgico global En este paso, se deben integrar todos los esquemas locales en un solo esquema global. En un sistema pequeo, con dos o tres "istas de usuario unas pocas entidades relaciones, es relati"amente sencillo comparar los esquemas locales, me*clarlos resol"er cualquier tipo de diferencia que pueda existir. Pero en los sistemas grandes, se debe seguir un proceso ms sistemtico para lle"ar a cabo este paso con .xito, %. C. E. He"isar los nombres de las entidades He"isar los nombres de las relaciones. 9e*clar las entidades de las "istas locales. sus cla"es primarias.

'. Dncluir $sin me*clar( las entidades que pertenecen a una sola "ista de usuario. F. 9e*clar las relaciones de las "istas locales.

5. Dncluir $sin me*clar( las relaciones que pertenecen a una sola "ista de usuario. @. G. &. Comprobar que no se #a omitido ninguna entidad ni relacin. Comprobar las cla"es a/enas. Comprobar las restricciones de integridad.

%6. +ibu/ar el esquema lgico global. %%. 4ctuali*ar la documentacin. &. Malidar el esquema lgico global Este proceso de "alidacin se reali*a, de nue"o, mediante la normali*acin mediante la prueba frente a las transacciones de los usuarios. Pero a#ora slo #a que normali*ar las relaciones que #a an cambiado al me*clar los esquemas lgicos locales slo #a que probar las transacciones que requieran acceso a reas que #a an sufrido alg1n cambio. %6. Estudiar el crecimiento futuro

En este paso, se trata de comprobar que el esquema obtenido puede acomodar los futuros cambios en los requisitos con un impacto mnimo. -i el esquema lgico se puede extender fcilmente, cualquiera de los cambios pre"istos se podr incorporar al mismo con un efecto mnimo sobre los usuarios existentes. %%. +ibu/ar el diagrama entidad-relacin final

:na "e* "alidado el esquema lgico global, a se puede dibu/ar el diagrama entidad-relacin que representa el modelo de los datos de la empresa que son de inter.s. 0a documentacin que describe este modelo $inclu endo el esquema relacional el diccionario de datos( se debe actuali*ar completar. %C. He"isar el esquema lgico global con los usuarios

:na "e* ms, se debe re"isar con los usuarios el esquema global la documentacin obtenida para asegurarse de que son una fiel representacin de la empresa. !ormali*acin 0a normali*acin es una t.cnica para disear la estructura lgica de los datos de un sistema de informacin en el modelo relacional, desarrollada por E. ?. Codd en %&@C. Es una estrategia de diseo de aba/o a arriba, se parte de los atributos .stos se "an agrupando en relaciones $tablas( seg1n su afinidad. 4qu no se utili*ar la normali*acin como una t.cnica de diseo de bases de datos, sino como una etapa posterior a la correspondencia entre el esquema conceptual el esquema lgico, que elimine las dependencias entre atributos no deseadas. 0as "enta/as de la normali*acin son las siguientes, > > E"ita anomalas en inserciones, modificaciones 9e/ora la independencia de datos. borrados.

> !o establece restricciones artificiales en la estructura de los datos. :no de los conceptos fundamentales en la normali*acin es el de dependencia funcional. :na dependencia funcional es una relacin entre atributos de una misma relacin $tabla(. -i e son atributos de la relacin , se dice que es funcionalmente dependiente de $se denota por ( si cada "alor de tiene asociado un solo "alor de $ e pueden constar de uno o "arios atributos(. 4 se le denomina determinante, a que determina el "alor de . -e dice que el atributo es

completamente dependiente de si depende funcionalmente de depende de ning1n subcon/unto de .

no

0a dependencia funcional es una nocin semntica. -i #a o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, ms bien, los modelos mentales del usuario las reglas de negocio de la organi*acin o empresa para la que se desarrolla el sistema de informacin. Cada dependencia funcional es una clase especial de regla de integridad representa una relacin de uno a muc#os. En el proceso de normali*acin se debe ir comprobando que cada relacin $tabla( cumple una serie de reglas que se basan en la cla"e primaria las dependencias funcionales. Cada regla que se cumple aumenta el grado de normali*acin. -i una regla no se cumple, la relacin se debe descomponer en "arias relaciones que s la cumplan. 0a normali*acin se lle"a a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se "a a"an*ando en la normali*acin, las relaciones tienen un formato ms estricto $ms fuerte( , por lo tanto, son menos "ulnerables a las anomalas de actuali*acin. El modelo relacional slo requiere un con/unto de relaciones en primera forma normal. 0as restantes formas normales son opcionales. -in embargo, para e"itar las anomalas de actuali*acin, es recomendable llegar al menos a la tercera forma normal. 'rimera !orma normal ((F)) :na relacin est en primera forma normal si, slo si, todos los dominios de la misma contienen "alores atmicos, es decir, no #a grupos repetiti"os. -i se "e la relacin grficamente como una tabla, estar en %?! si tiene un solo "alor en la interseccin de cada fila con cada columna. -i una relacin no est en %?!, #a que eliminar de ella los grupos repetiti"os. :n grupo repetiti"o ser el atributo o grupo de atributos que tiene m1ltiples "alores para cada tupla de la relacin. <a dos formas de eliminar los grupos repetiti"os. En la primera, se repiten los atributos con un solo "alor para cada "alor del grupo repetiti"o. +e este modo, se introducen redundancias a que se duplican "alores, pero estas redundancias se eliminarn despu.s mediante las restantes formas normales. 0a segunda forma de eliminar los grupos repetiti"os consiste en poner cada uno de ellos en una relacin aparte, #eredando la cla"e primaria de la relacin en la que se encontraban.

:n con/unto de relaciones se encuentra en %?! si ninguna de ellas tiene grupos repetiti"os. *egunda !orma normal (+F)) :na relacin est en segunda forma normal si, slo si, est en %?! , adems, cada atributo que no est en la cla"e primaria es completamente dependiente de la cla"e primaria. 0a C?! se aplica a las relaciones que tienen cla"es primarias compuestas por dos o ms atributos. -i una relacin est en %?! su cla"e primaria es simple $tiene un solo atributo(, entonces tambi.n est en C?!. 0as relaciones que no estn en C?! pueden sufrir anomalas cuando se reali*an actuali*aciones. Para pasar una relacin en %?! a C?! #a que eliminar las dependencias parciales de la cla"e primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes se ponen en una nue"a relacin con una copia de su determinante $los atributos de la cla"e primaria de los que dependen(. ,ercera !orma normal (-F)) :na relacin est en tercera forma normal si, slo si, est en C?! , adems, cada atributo que no est en la cla"e primaria no depende transiti"amente de la cla"e primaria. 0a dependencia es transiti"a si existen las dependencias , , siendo , , atributos o con/untos de atributos de una misma relacin. 4unque las relaciones en C?! tienen menos redundancias que las relaciones en %?!, toda"a pueden sufrir anomalas frente a las actuali*aciones. Para pasar una relacin de C?! a E?! #a que eliminar las dependencias transiti"as. Para ello, se eliminan los atributos que dependen transiti"amente se ponen en una nue"a relacin con una copia de su determinante $el atributo o atributos no cla"e de los que dependen(. Forma normal de .o%ce-/odd (./F)) :na relacin est en la forma normal de Bo ce-Codd si, todo determinante es una cla"e candidata. slo si,

0a C?! la E?! eliminan las dependencias parciales las dependencias transiti"as de la cla"e primaria. Pero este tipo de dependencias toda"a pueden existir sobre otras cla"es candidatas, si .stas existen. 0a BC?! es ms fuerte que la E?!, por lo tanto, toda relacin en BC?! est en E?!.

0a "iolacin de la BC?! es poco frecuente a que se da ba/o ciertas condiciones que raramente se presentan. -e debe comprobar si una relacin "iola la BC?! si tiene dos o ms cla"es candidatas compuestas que tienen al menos un atributo en com1n. Hesumen El diseo de bases de datos consta de tres etapas, diseo conceptual, lgico fsico. El diseo lgico es el proceso mediante el que se constru e un esquema que representa la informacin que mane/a una empresa, basndose en un modelo lgico determinado, pero independientemente del -;B+ concreto que se "a a a utili*ar para implementar la base de datos e independientemente de cualquier otra consideracin fsica. 0as dos fases de que consta el diseo lgico son la construccin "alidacin de los esquemas lgicos locales para cada "ista de usuario, la construccin "alidacin de un esquema lgico global. Cada una de estas fases consta de una serie de pasos. :n paso importante es la con"ersin del esquema conceptual a un esquema lgico adecuado al modelo relacional. Para ello, se deben #acer algunas transformaciones, eliminar las relaciones de muc#os a muc#os, eliminar las relaciones comple/as, eliminar las relaciones recursi"as, eliminar las relaciones con atributos, eliminar los atributos multie"aluados, reconsiderar las relaciones de uno a uno eliminar las relaciones redundantes. 0os esquemas lgicos se pueden "alidar mediante la normali*acin frente a las transacciones de los usuarios. 0a normali*acin se utili*a para me/orar el esquema, de modo que .ste satisface ciertas restricciones que e"itan la duplicidad de datos. 0a normali*acin garanti*a que el esquema resultante est ms prximo al modelo de la empresa, es consistente, tiene la mnima redundancia la mxima estabilidad. 0as restricciones de integridad son las restricciones que se imponen para que la base de datos nunca llegue a un estado inconsistente. <a cinco tipos de restricciones de integridad, datos requeridos, restricciones de dominio, integridad de entidades, integridad referencial reglas de negocio. Para garanti*ar la integridad referencial se debe especificar el comportamiento de las cla"es a/enas, si aceptan nulos qu. #acer cuando se borra la tupla a la que se #ace referencia, o cuando se modifica el "alor de su cla"e primaria.

Diseo !sico de bases de datos

En este captulo se describe la metodologa de diseo fsico para bases de datos relacionales. En esta etapa, se parte del esquema lgico global obtenido durante el diseo lgico se obtiene una descripcin de la implementacin de la base de datos en memoria secundaria. Esta descripcin es completamente dependiente del -;B+ especfico que se "a a a utili*ar. En este captulo se dan una serie de directrices para escoger las estructuras de almacenamiento de las relaciones base, decidir cundo crear ndices cundo desnormali*ar el esquema lgico e introducir redundancias. Introduccin El diseo de una base de datos se descompone en tres etapas, diseo conceptual, lgico fsico. 0a etapa del diseo lgico es independiente de los detalles de implementacin dependiente del tipo de -;B+ que se "a a a utili*ar. 0a salida de esta etapa es el esquema lgico global la documentacin que lo describe. Bodo ello es la entrada para la etapa que "iene a continuacin, el diseo fsico. 9ientras que en el diseo lgico se especifica qu. se guarda, en el diseo fsico se especifica cmo se guarda. Para ello, el diseador debe conocer mu bien toda la funcionalidad del -;B+ concreto que se "a a a utili*ar tambi.n el sistema informtico sobre el que .ste "a a traba/ar. El diseo fsico no es una etapa aislada, a que algunas decisiones que se tomen durante su desarrollo, por e/emplo para me/orar las prestaciones, pueden pro"ocar una reestructuracin del esquema lgico. 9etodologa de diseo fsico para bases de datos relacionales El ob/eti"o de esta etapa es producir una descripcin de la implementacin de la base de datos en memoria secundaria. Esta descripcin inclu e las estructuras de almacenamiento los m.todos de acceso que se utili*arn para conseguir un acceso eficiente a los datos. El diseo fsico se di"ide de cuatro fases, cada una de ellas compuesta por una serie de pasos, Braducir el esquema lgico global para el -;B+ especfico. +isear las relaciones base para el -;B+ especfico. +isear las reglas de negocio para el -;B+ especfico. +isear la representacin fsica. 4nali*ar las transacciones. Escoger las organi*aciones de fic#eros.

Escoger los ndices secundarios. Considerar la introduccin de redundancias controladas. Estimar la necesidad de espacio en disco. +isear los mecanismos de seguridad. +isear las "istas de los usuarios. +isear las reglas de acceso. 9onitori*ar afinar el sistema. Braducir el esquema lgico global 0a primera fase del diseo lgico consiste en traducir el esquema lgico global en un esquema que se pueda implementar en el -;B+ escogido. Para ello, es necesario conocer toda la funcionalidad que .ste ofrece. Por e/emplo, el diseador deber saber, -i el sistema soporta la definicin de cla"es primarias, cla"es a/enas cla"es alternati"as. -i el sistema soporta la definicin de datos requeridos $es decir, si se pueden definir atributos como no nulos(. -i el sistema soporta la definicin de dominios. -i el sistema soporta la definicin de reglas de negocio. Cmo se crean las relaciones base. (. Disear las relaciones base para el *0.D espec!ico 0as relaciones base se definen mediante el lengua/e de definicin de datos del -;B+. Para ello, se utili*a la informacin producida durante el diseo lgico, el esquema lgico global el diccionario de datos. El esquema lgico consta de un con/unto de relaciones , para cada una de ellas, se tiene, El nombre de la relacin. 0a lista de atributos entre par.ntesis. 0a cla"e primaria las cla"es a/enas, si las tiene. 0as reglas de integridad de las cla"es a/enas. En el diccionario de datos se describen los atributos , para cada uno de ellos, se tiene, -u dominio, tipo de datos, longitud restricciones de dominio. El "alor por defecto, que es opcional. -i admite nulos. -i es deri"ado , en caso de serlo, cmo se calcula su "alor.

+. Disear las reglas de negocio para el *0.D espec!ico 0as actuali*aciones que se reali*an sobre las relaciones de la base de datos deben obser"ar ciertas restricciones que imponen las reglas de negocio de la empresa. 4lgunos -;B+ proporcionan mecanismos que permiten definir estas restricciones "igilan que no se "iolen. Por e/emplo, si no se quiere que un empleado tenga ms de die* inmuebles asignados, se puede definir una restriccin en la sentencia CHE4BE B4B0E de la relacin D!9:EB0E,

CA!-BH4D!B inmueblesQporQempleado C<ECR $-E0ECB enum ?HA9 inmueble ;HA:P BO CA:!B$T(U%6((

$!AB enum

ESD-B<4MD!;

Atro modo de definir esta restriccin es mediante un disparador $ trigger(, CHE4BE BHD;;EH inmueblesQporQempleado A! inmueble ?AH D!-EHB,:P+4BE 4- D? $$-E0ECB CA:!B$T( ?HA9 inmueble i V<EHE i.inumWD!-EHBE+.inum(U%6( BE;D! PHD!B )Este empleado a tiene %6 inmuebles asignados) HA00B4CR BH4!-4CBDA! E!+ <a algunas restricciones que no las pueden mane/ar los -;B+, como por e/emplo Ka las C6,E6 del 1ltimo da laborable de cada ao arc#i"ar los inmuebles "endidos borrarlosX. Para estas restricciones #abr que escribir programas de aplicacin especficos. Por otro lado, #a -;B+ que no permiten la definicin de restricciones, por lo que .stas debern incluirse en los programas de aplicacin. Bodas las restricciones que se definan deben estar documentadas. -i #a "arias opciones posibles para implementarlas, #a que explicar porqu. se #a escogido la opcin implementada. +isear la representacin fsica :no de los ob/eti"os principales del diseo fsico es almacenar los datos de modo eficiente. Para medir la eficiencia #a "arios factores que se deben tener en cuenta, -roductividad de transacciones. Es el n1mero de transacciones que se quiere procesar en un inter"alo de tiempo. 1iempo de respuesta. Es el tiempo que tarda en e/ecutarse una transaccin. +esde el punto de "ista del usuario, este tiempo debera ser el mnimo posible. Espacio en disco. Es la cantidad de espacio en disco que #ace falta para los fic#eros de la base de datos. !ormalmente, el diseador querr minimi*ar este espacio. 0o que suele suceder, es que todos estos factores no se pueden satisfacer a la "e*. Por e/emplo, para conseguir un tiempo de respuesta mnimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando ms espacio en disco. Por lo tanto, el diseador deber ir a/ustando estos factores para conseguir un equilibrio ra*onable. El diseo fsico inicial no ser el definiti"o, sino que #abr que ir monitori*ndolo para obser"ar sus prestaciones e ir a/ustndolo como sea oportuno. 9uc#os -;B+ proporcionan #erramientas para monitori*ar afinar el sistema.

<a algunas estructuras de almacenamiento que son mu eficientes para cargar grandes cantidades de datos en la base de datos, pero no son eficientes para el resto de operaciones, por lo que se puede escoger dic#a estructura de almacenamiento para iniciali*ar la base de datos cambiarla, a continuacin, para su posterior operacin. 0os tipos de organi*aciones de fic#eros disponibles "aran en cada -;B+. 4lgunos sistemas proporcionan ms estructuras de almacenamiento que otros. Es mu importante que el diseador del esquema fsico sepa qu. estructuras de almacenamiento le proporciona el -;B+ cmo las utili*a. Para me/orar las prestaciones, el diseador del esquema fsico debe saber cmo interact1an los dispositi"os in"olucrados cmo esto afecta a las prestaciones, Memoria principal. 0os accesos a memoria principal son muc#o ms rpidos que los accesos a memoria secundaria $decenas o centenas de miles de "eces ms rpidos(. ;eneralmente, cuanta ms memoria principal se tenga, ms rpidas sern las aplicaciones. -in embargo, es aconse/able tener al menos un FY de la memoria disponible, pero no ms de un %6Y. -i no #a bastante memoria disponible para todos los procesos, el sistema operati"o debe transferir pginas a disco para liberar memoria $ paging(. Cuando estas pginas se "uel"en a necesitar, #a que "ol"er a traerlas desde el disco $ faltas de p&gina(. 4 "eces, es necesario lle"ar procesos enteros a disco $ s2apping( para liberar memoria. El #acer estas transferencias con demasiada frecuencia empeora las prestaciones. C-3. 0a CP: controla los recursos del sistema e/ecuta los procesos de usuario. El principal ob/eti"o con este dispositi"o es lograr que no #a a bloqueos de procesos para conseguirla. -i el sistema operati"o, o los procesos de los usuarios, #acen muc#as demandas de CP:, .sta se con"ierte en un cuello de botella. Esto suele ocurrir cuando #a muc#as faltas de pgina o se reali*a muc#o s7apping. Entrada4salida a disco. 0os discos tienen una "elocidad de entradaNsalida. Cuando se requieren datos a una "elocidad ma or que .sta, el disco se con"ierte en un cuello de botella. +ependiendo de cmo se organicen los datos en el disco, se conseguir reducir la probabilidad de empeorar las prestaciones. 0os principios bsicos que se deberan seguir para repartir los datos en los discos son los siguientes, 0os fic#eros del sistema operati"o deben estar separados de los fic#eros de la base de datos. 0os fic#eros de datos deben estar separados de los fic#eros de ndices 0os fic#eros con los diarios de operaciones deben estar separados del resto de los fic#eros de la base de datos. 'ed. 0a red se con"ierte en un cuello de botella cuando tiene muc#o trfico cuando #a muc#as colisiones. Cada uno de estos recursos afecta a los dems, de modo que una me/ora en alguno de ellos puede pro"ocar me/oras en otros.

-.

nali$ar las transacciones

Para reali*ar un buen diseo fsico es necesario conocer las consultas las transacciones que se "an a e/ecutar sobre la base de datos. Esto inclu e tanto informacin cualitati"a, como cuantitati"a. Para cada transaccin, #a que especificar, 0a frecuencia con que se "a a e/ecutar. 0as relaciones los atributos a los que accede la transaccin, el tipo de acceso, consulta, insercin, modificacin o eliminacin. 0os atributos que se modifican no son buenos candidatos para construir estructuras de acceso. 0os atributos que se utili*an en los predicados del V<EHE de las sentencias -P0. Estos atributos pueden ser candidatos para construir estructuras de acceso dependiendo del tipo de predicado que se utilice. -i es una consulta, los atributos in"olucrados en el /oin de dos o ms relaciones. Estos atributos pueden ser candidatos para construir estructuras de acceso. 0as restricciones temporales impuestas sobre la transaccin. 0os atributos utili*ados en los predicados de la transaccin pueden ser candidatos para construir estructuras de acceso. 1. Escoger las organi$aciones de !ic2eros El ob/eti"o de este paso es escoger la organi*acin de fic#eros ptima para cada relacin. Por e/emplo, un fic#ero desordenado es una buena estructura cuando se "a a cargar gran cantidad de datos en una relacin al iniciali*arla, cuando la relacin tiene pocas tuplas, tambi.n cuando en cada acceso se deben obtener todas las tuplas de la relacin, o cuando la relacin tiene una estructura de acceso adicional, como puede ser un ndice. Por otra parte, los fic#eros dispersos $#as#ing( son apropiados cuando se accede a las tuplas a tra".s de los "alores exactos de alguno de sus campos $condicin de igualdad en el V<EHE(. -i la condicin de b1squeda es distinta de la igualdad $b1squeda por rango, por patrn, etc.(, la dispersin no es una buena opcin. <a otras organi*aciones, como la D-49 o los rboles BZ. 0as organi*aciones de fic#eros elegidas /ustificando en cada caso la opcin escogida. 3. Escoger los ndices secundarios 0os ndices secundarios permiten especificar caminos de acceso adicionales para las relaciones base. Por e/emplo, la relacin D!9:EB0E se puede #aber almacenado en un fic#ero disperso a tra".s del atributo inum. -i se accede a menudo a esta relacin a tra".s del atributo alquiler, se puede plantear la creacin de un ndice sobre dic#o atributo para fa"orecer estos accesos. Pero #a que tener deben documentarse,

en cuenta que estos ndices conlle"an un coste de mantenimiento que #a que sopesar frente a la ganancia en prestaciones. 4 la #ora de seleccionar los ndices, se pueden seguir las siguientes indicaciones, Construir un ndice sobre la cla"e primaria de cada relacin base. !o crear ndices sobre relaciones pequeas. 4adir un ndice sobre los atributos que se utili*an para acceder con muc#a frecuencia. 4adir un ndice sobre las cla"es a/enas que se utilicen con frecuencia para #acer /oins. E"itar los ndices sobre atributos que se modifican a menudo. E"itar los ndices sobre atributos poco selecti"os $aquellos en los que la consulta selecciona una porcin significati"a de la relacin(. E"itar los ndices sobre atributos formados por tiras de caracteres largas. 0os ndices creados se deben documentar, explicando las ra*ones de su eleccin. 4. /onsiderar la introduccin de redundancias controladas En ocasiones puede ser con"eniente rela/ar las reglas de normali*acin introduciendo redundancias de forma controlada, con ob/eto de me/orar las prestaciones del sistema. En la etapa del diseo lgico se recomienda llegar, al menos, #asta la tercera forma normal para obtener un esquema con una estructura consistente sin redundancias. Pero, a menudo, sucede que las bases de datos as normali*adas no proporcionan la mxima eficiencia, con lo que es necesario "ol"er atrs desnormali*ar algunas relaciones, sacrificando los beneficios de la normali*acin para me/orar las prestaciones. Es importante #acer notar que la desnormali*acin slo debe reali*arse cuando se estime que el sistema no puede alcan*ar las prestaciones deseadas. O, desde luego, la necesidad de desnormali*ar en ocasiones no implica eliminar la normali*acin del diseo lgico, la normali*acin obliga al diseador a entender completamente cada uno de los atributos que se #an de representar en la base de datos. Por lo tanto, #a que tener en cuenta los siguientes factores, 0a desnormali*acin #ace que la implementacin sea ms comple/a. 0a desnormali*acin #ace que se sacrifique la flexibilidad. 0a desnormali*acin puede #acer que los accesos a datos sean ms rpidos, pero ralenti*a las actuali*aciones. Por regla general, la desnormali*acin de una relacin puede ser una opcin "iable cuando las prestaciones que se obtienen no son las deseadas la relacin se actuali*a con poca frecuencia, pero se consulta mu a menudo. 0as redundancias que se pueden incluir al desnormali*ar son de "arios tipos, se pueden introducir datos

deri"ados $calculados a partir de otros datos(, se pueden duplicar atributos o se pueden #acer /oins de relaciones. El incluir un atributo deri"ado depender del coste adicional de almacenarlo mantenerlo consistente con los datos de los que se deri"a, frente al coste de calcularlo cada "e* que se necesita. !o se pueden establecer una serie de reglas que determinen cundo desnormali*ar relaciones, pero #a algunas situaciones mu comunes en donde puede considerarse esta posibilidad, Combinar relaciones de uno a uno. Cuando #a relaciones $tablas( in"olucradas en relaciones de uno a uno, se accede a ellas de manera con/unta con frecuencia casi no se les accede separadamente, se pueden combinar en una sola relacin $tabla(. *uplicar atributos no clave en relaciones de uno a muc%os para reducir los #oins. Para e"itar operaciones de /oin, se pueden incluir atributos de la relacin $tabla( padre en la relacin $tabla( #i/o de las relaciones de uno a muc#os. 1ablas de referencia. 0as tablas de referencia $ loo5up( son listas de "alores, cada uno de los cuales tiene un cdigo. Por e/emplo puede #aber una tabla de referencia para los tipos de inmueble, con las descripciones de estos tipos un cdigo asociado. Este tipo de tablas son un caso de relacin de uno a muc#os. En la relacin D!9:EB0E #abr una cla"e a/ena a esta tabla para indicar el tipo de inmueble. +e este modo, es mu fcil "alidar los datos, adems de que se a#orra espacio escribiendo slo el cdigo no la descripcin para cada inmueble, adems de a#orrar tiempo cuando se actuali*an las descripciones. -i las tablas de referencia se utili*an a menudo en consultas crticas, se puede considerar la introduccin de la descripcin /unto con el cdigo en la relacin $tabla( #i/o, manteniendo la tabla de referencia para "alidacin de datos. *uplicar claves a#enas en relaciones de uno a muc%os para reducir los #oins. Para e"itar operaciones de /oin, se pueden incluir cla"es a/enas de una relacin $tabla( en otra relacin $tabla( con la que se relaciona $#abr que tener en cuenta ciertas restricciones(. *uplicar atributos en relaciones de muc%os a muc%os para reducir los #oins. +urante el diseo lgico se eliminan las relaciones de muc#os a muc#os introduciendo dos relaciones de uno a muc#os. Esto #ace que apare*ca una nue"a relacin $tabla( intermedia, de modo que si se quiere obtener la informacin de la relacin de muc#os a muc#os, se tiene que reali*ar el /oin de tres relaciones $tablas(. Para e"itar algunos de estos /oins se pueden incluir algunos de los atributos de las relaciones $tablas( originales en la relacin $tabla( intermedia. +ntroducir grupos repetitivos. 0os grupos repetiti"os se eliminan en el primer paso de la normali*acin para conseguir la primera forma normal. Estos grupos se eliminan introduciendo una nue"a relacin $tabla(, generando una relacin de uno a muc#os. 4 "eces, puede ser

con"eniente reintroducir los grupos repetiti"os para me/orar las prestaciones. Bodas las redundancias que se introdu*can en este paso se deben documentar ra*onar. El esquema lgico se debe actuali*ar para refle/ar los cambios introducidos. 5. Estimar la necesidad de espacio en disco En caso de que se tenga que adquirir nue"o equipamiento informtico, el diseador debe estimar el espacio necesario en disco para la base de datos. Esta estimacin depende del -;B+ que se "a a a utili*ar del #ard7are. En general, se debe estimar el n1mero de tuplas de cada relacin su tamao. Bambi.n se debe estimar el factor de crecimiento de cada relacin. +isear los mecanismos de seguridad 0os datos constitu en un recurso esencial para la empresa, por lo tanto su seguridad es de "ital importancia. +urante el diseo lgico se #abrn especificado los requerimientos en cuanto a seguridad que en esta fase se deben implementar. Para lle"ar a cabo esta implementacin, el diseador debe conocer las posibilidades que ofrece el -;B+ que se "a a a utili*ar. 6. Disear las 7istas de los usuarios El ob/eti"o de este paso es disear las "istas de los usuarios correspondientes a los esquemas lgicos locales. 0as "istas, adems de preser"ar la seguridad, me/oran la independencia de datos, reducen la comple/idad permiten que los usuarios "ean los datos en el formato deseado. 8. Disear las reglas de acceso El administrador de la base de datos asigna a cada usuario un identificador que tendr una palabra secreta asociada por moti"os de seguridad. Para cada usuario o grupo de usuarios se otorgarn permisos para reali*ar determinadas acciones sobre determinados ob/etos de la base de datos. Por e/emplo, los usuarios de un determinado grupo pueden tener permiso para consultar los datos de una relacin base concreta no tener permiso para actuali*arlos. 9onitori*ar afinar el sistema

:na "e* implementado el esquema fsico de la base de datos, se debe poner en marc#a para obser"ar sus prestaciones. -i .stas no son las deseadas, el esquema deber cambiar para intentar satisfacerlas.

:na "e* afinado el esquema, no permanecer esttico, a que tendr que ir cambiando conforme lo requieran los nue"os requisitos de los usuarios. 0os -;B+ proporcionan #erramientas para monitori*ar el sistema mientras est en funcionamiento. Hesumen El diseo fsico es el proceso de producir una descripcin de la implementacin de la base de datos en memoria secundaria. +escribe las relaciones base las estructuras de almacenamiento m.todos de acceso que se utili*arn para acceder a los datos de modo eficiente. El diseo de las relaciones base slo se puede reali*ar cuando el diseador conoce perfectamente toda la funcionalidad que presenta el -;B+ que se "a a a utili*ar. El primer paso consiste en traducir el esquema lgico global de modo que pueda ser fcilmente implementado por el -;B+ especfico. 4 continuacin, se escogen las organi*aciones de fic#eros ms apropiadas para almacenar las relaciones base, los m.todos de acceso, basndose en el anlisis de las transacciones que se "an a e/ecutar sobre la base de datos. -e puede considerar la introduccin de redundancias controladas para me/orar las prestaciones. Atra tarea a reali*ar en este paso es estimar el espacio en disco. 0a seguridad de la base de datos es fundamental, por lo que el siguiente paso consiste en disear las medidas de seguridad necesarias mediante la creacin de "istas el establecimiento de permisos para los usuarios. El 1ltimo paso del diseo fsico consiste en monitori*ar afinar el sistema para obtener las me/ores prestaciones satisfacer los cambios que se puedan producir en los requisitos.