Problemas I_II (2015)

Apunte Español
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Genética - 2º curso
Asignatura Técnicas instrumentales
Año del apunte 2015
Páginas 10
Fecha de subida 09/04/2015
Descargas 37

Vista previa del texto

SESIÓN 1-3. 19 febrero-3 marzo BASES DE DATOS 1.
A partir de los datos personales de los alumnos, se debe realizar el diseño de una base de datos. Por ejemplo, incluir datos como Nombre, Apellidos, NIU, Sexo...
A. Se debe indicar en cada tabla qué datos se guardan y de qué tipo son. Recuerda incluir las claves necesarias.
En primer lugar, debemos indicar los datos personales, que son datos constantes porque se quieren fijar los parámetros (por ello no pondremos edad por ejemplo).
EP! No debería tener ni ñ ni acentos, así como otros caracteres especiales.
Así pues, en cada fila se añaden entidades, que en este caso serían alumnos; por tanto, para cada dato nos preguntaremos qué tipo de relación hay para cada alumno.
Una persona tiene solo un nombre pero un nombre puede presentarlo más de una persona, teniendo la relación 1:N, sucediendo lo mismo con los apellidos. Para evitar redundancias podríamos poner a un nombre distintos códigos únicos; aun así, si justo esos datos no queremos estudiarlos, podemos asumir la redundancia para no segregar tanto los datos  1. Por el contrario, el DNI ya sería una entidad (1).
Asimismo, una persona puede tener varios estados civiles, así como un mismo estado civil lo pueden presentar distintas personas, siendo una relación N:M  en este caso, podríamos situar una tabla aparte estableciendo datos numéricos para consumir menos  tablas pequeñas que encontramos aparte. Si queremos almacenar toda la información decimos que la relación es N:M; pero como en la primera tabla no se podría poner más de un dato, debe estar en otra. Pero, como realmente no es el objeto de estudio primordial, se simplifica poniendo 1:N, siendo el estado civil del día de matriculación.
(¡!) Además, la tabla de las personas depende de la tabla de sexo, puesto que es la tabla que primero rellenamos  la tabla completa en un primer lugar es la independiente. Y, a partir de la tabla principal, sale la clave foránea (sexo), coincidiendo el valor de ambas columnas. En definitiva, se crea en la tabla dependiente y desde esa columna se hace referencia a la tabla de sexo creada anteriormente. A continuación pondremos el conjunto con su respectiva relación: Nombre  1 Apellido 1  1 Apellido 2  1 Estado civil  N:M, pero para simplificar 1:N, por lo que solo pondremos el estado civil de la fecha de matriculación.
DNI 1 Fecha de nacimiento  1, debido a que se asume redundancia y se pone en la misma tabla, ya que si no seria 1:N. NO? Sexo  1. Se cambia hombre y mujer por 0 y 1 para consumir menos recursos (¡!).
Dirección principal 1. Si se cambia se eliminará la anterior porque no interesa acumular, es decir, no interesa mantener el registro, por lo que se puede dejar en la tabla y solo se tendrá el dato del momento siendo una relación de 1. Si no fuera así, se debería tener en otra tabla.
Teléfono  1 Correo electrónico 1 NIU 1 EP! CLAVE PRIMARIA. Conjunto de datos que hacen distintivo una entidad, es único.
Siempre se intentará que ocupe lo menos posible. CLAVE FORÁNEA: Relación entre dos tablas.
SESIÓN 1-3. 19 febrero-3 marzo B. ¿Cuántas tablas son necesarias para guardar la información relativa a los datos personales? Depende de las relacionas que asumimos en el apartado A, necesitaremos más o menos tablas.
Se debe hacer otra tabla para evitar la redundancia, es decir, que no ponga hombre, hombre, hombre…, seria: Sexo Hombre Mujer Código 0 1 Tiene sentido relacionar datos con sexo, relación 1:N  se pueden relacionar directamente. Haremos la relación en la dirección 1:1, a una persona le asignaremos un sexo, lo relacionamos con el dato único, la clave primaria. La relación tiene un sentido porque una tabla depende de la otra. La clave foránea se creará en la tabla y de la columna sexo apuntará a la columna código. La columna de datos depende de la de sexo, se tienen que llenar una para que la otra tenga sentido.
Si la relación es 1:N  cada país tienen un código, igual que la tabla sexo pero más larga. Será una tabla de nacionalidad y código.
Nacionalidad España Italia Francia Codigo 0 1 2 Nacionalidad (código)#  clave foránea (FK) Si la relación es N:M. Se necesita otra tabla que contenga los datos y la nacionalidad.
Código nacionalidad NIU 0 1 0 2 0 3* 1 3* 0 4 La persona con el NIU 3 tiene dos nacionalidades diferentes.
Tendré los datos personales y luego a cada NIU le podré decir la nacionalidad. Entre las dos tablas, nacionalidad y código y la de datos personales, hay una relación N:M ninguna depende de la otra. Sin embargo las dos dependen de esta última que hemos hecho, es una tabla intermedia de la que salen dos claves foráneas (FK), una relacionada con el la tabla datos (gracias al NIU) y otra a la tabla de nacionalidad y código (la primera que hemos hecho de nacionalidad).
TIPOLOGÍA. Datos personales  Nombre VARCHAR (30)  Apellido 1 VARCHAR (20)  Apellido 2 VARCHAR (20)  Niu PK INT  DNI INT (no letra)//VARCHAR (9) (puedes poner la letra)  Fecha nacimiento DATE  Dirección VARCHAR (40) Sexo  Sexo TINYINT  Codigo PK TINYINT SESIÓN 1-3. 19 febrero-3 marzo   Nacionalidad: Pais VARCHAR (20) Codigo PK TINYINT C. A continuación, se debe incorporar en la base de datos la información relativa a los estudios que realizan (nombre del grado y asignaturas matriculadas por cada alumno junto con sus notas).
NOTA: se debe tener en cuenta que no todo el mundo se matricula de las mismas asignaturas.
En definitiva, nos preguntan qué información podemos almacenar de los grados y las asignaturas. Así pues: CréditosAsig. Una asignatura tiene un número constante de créditos. Como se repiten y ya está, no haremos otra tabla a parte si no que aceptaremos la redundancia  2 Profesor N:M  el profesor no va en esta tabla por mucho que simplifiquemos. Aun así podríamos poner un profesor responsable, siendo una relación 1:N y tampoco estaría en esta tabla, porque no se da la redundancia por casualidad.
Asignatura (nombre)  2. Aunque tengan el mismo nombre, si tienen un código distinto, nos estamos refiriendo a diferentes entidades CodigoAsig 2. En definitiva, un registro, una entidad.
Grados. 1:N. Un código concreto solo se va a dar en un grado, pero un grado no solo tiene ese código, siendo una relación 1:N no casual, por lo que también se quita de la tabla.
Turno (mañanaytarde)  N:M. Si una asignatura tiene dos turnos, se puede crear una tabla intermedia para ahorrar recursos. Aún así, también se quitaría.
Notas. También se quitaría debido a que es una relación N:M.
Así pues tendríamos una segunda tabla con Profesor, profesor responsable, grados y codigoasig  hay que hacer las relaciones para no crear filas repetidas. Si relacionamos grados con alumnos, y grados con asignaturas seguimos sin saber cuáles asignaturas hace un alumno. Pero si relacionamos grados con asignaturas y asignaturas con alumnos, si que sabemos el grado que cursa el alumno.
Entidades:  Asignatura: o NombreAsignatura VARCHAR (30) o CodigoAsignatura PK TINYINT o GuiaDocente LONGTEXT o CreditosAsignatura TINYINT o CodigoGrado (FKgrado.CodigoGrado) TINYINT  Grado: o NombreGrado VARCHAR (30) o PrecioCredito FLOAT (4,2 o 6,3; aunque también podría ser 5,2) o CodigoGrado PK TINYINT  Nota FLOAT *Como mucho una asignatura tendría 18 y TINYINT llega hasta 255.
SESIÓN 1-3. 19 febrero-3 marzo Las tablas tienen el campo código, esa va a ser la clave primaria.
Un alumno varias asignaturas, un asignatura varios alumnos. Como mínimo una tabla intermedia que tendrá el NIU y el código de la asignatura. A demás añadimos la nota.
NIU 1 1 1 CodigoAsignatura Tec, Ins.
Tec. Ins.
Tec. Ins Nota 4 4 8 Falta algún dato para diferenciar los que son iguales, la fecha Fecha 2010 2011 2012 NIU 1 1 1 CodigoAsignatura Tec. Ins.
Tec. Ins.
Tec. Ins.
Esta tabla también sirve para guardar la nota.
 Matricula: o Fechamatricula o Niu FK  alumno.niu o CodigoAsignatura FK  asignatura.codigoAsignatura o Nota Nota 4 4 8 YEAR INT TINYINT FLOAT (3,1 o 4,2) *Fecha matricula: YEAR debido a que se matricula una vez al año, con tener la idea del año está bien. Si se pudiera matricular dos veces no valdría 2.
Realiza el diseño de una base de datos que almacene la información disponible en archivos como el ejemplo BN000065.txt (también disponible en el Campus Virtual). Este archivo pertenece al European Nucleotide Archive y contiene información de un secuencia nucleotídica humana. (tablas en el enunciado) En este tipo de archivos a la izquierda se indica qué dato se almacena (en el recuadro rojo) y a continuación se muestra el valor: Vemos información sobre una secuencia, donde la información se almacena en textos planos. Si tenemos la misma información en distintas secuencias es muy redundante  diseño para hacer un modelo relacional. Se debe guardar la información relativa a las etiquetas:  ID (incluyendo el número de acceso, el tipo de secuencia de DNA y la longitud)  AC (Accession Number)  DT (fecha)  DE (descripción)  KW (palabras clave)  OS (organismo de origen)  OC (clasificación taxonómica)  Referencias: o RA (autor) o RT (título)  FT (características)  SQ (resumen del contenido de la secuencia junto con la secuencia) SESIÓN 1-3. 19 febrero-3 marzo En cuanto a las características, incluyen distintos tipos como ‘mRNA’, ‘CDS’, ‘exon’ o ‘intron’ y para cada una de estas características, se ofrece un conjunto de etiquetas con valores. En primer lugar, siempre se indica la posición a la cual hace referencia en la secuencia y después el resto de información sigue la estructura: /ETIQUETA="VALOR" Cada bloque sería una característica.
Secuencia de DNA, mRNA, CDS, exón, intrón  BIGINT Accession Number  TINYINT Fecha  DATE Descripción  VARCHAR (30) Palabras clave  VARCHAR (20) Organismo de origen  VARCHAR (20) Clasificación taxonómica Autor  VARCHAR (20) Título  VARCHAR (30) Etiquetas de valores EP! Las etiquetas db_xref no es necesario incluirlas.
El diseño de la base de datos debe incluir claramente las distintas tablas con los campos y los tipos de datos que almacenarán junto con todas las claves necesarias.
PROCEDIMIENTO: Toda la información gira entorno a una secuencia, el identificador y las características de la secuencia, la fecha, palabras clave, origen, referencias, etc.
La secuencia de DNA es una entidad, por lo que en la misma tabla se almacenará: Longitud (el hecho de que se repita es casualidad  se puede poner en esta) Especie** Fecha_creacion. En el conjunto de la base de datos también será casualidad, por lo que la dejaremos en la tabla.
Fecha_modificacio:si solo se almacena la última aquí, si se tiene el registro en otra tabla.
Última_modificación. Si solo almaceno la ultima, puede ir en la tabla. Sin embargo si se va teniendo el registro de las modificaciones, esta columna debería estar en otra tabla.
Palabra clave (N:M), se trataría de una relación M:N, teniendo que poner otra tabla (KW)donde: - Keyword PK  La clave primaria es una combinación de Keyword y acc - Acc (FK)** **Nos inventamos un numero de acceso único mediante el cual podamos relacionar la información Ahora creamos otra tabla para crear un código  intermedia. Como es una relación M:N debemos hacer una tabla intermedia. Luego haríamos la clave foránea, pero en este caso como solo tendríamos keyword nos lo podríamos saltar. Entonces a pesar de ser M:N llegamos a la conclusión que cuando no tenemos mas información de la identidad nos quedamos con la intermedia (que será FK, es decir, foreign key), para poder ahorrar recursos. Así pues, cada columna acabará teniendo un valor. Así pues: - Keyword (FK) - ID EP! Las referencias también serían relación N:M.
SESIÓN 1-3. 19 febrero-3 marzo La especie, genero… Tiene relación 1:N con las secuencias, por lo que se debe crear una tabla a parte U(no intermedia). Creamos una tabla especie - Especie - ID (PK) - Genero (*) Tendríamos otra tabla para los géneros con el código y, en definitiva, podríamos guardar SP en la tabla de SEQ.
(*) En la tabla SP, homo sapiens solo estará escrito una vez, mientras que su código estará múltiples veces en la tabla SEQ.
(*)Para evitar redundancia cada nivel (especie, genero…) tendría que tener una tabla. Por ejemplo, si lo hacemos así, solo escribiré una vez eucariota y metazoa igual, cuando bajo de nivel y voy a otra tabla puedo repetir el código de metazoa. Si hay 5000 secuencias de homo sapiens repetiré el código pero no toda la palabra. Esta forma de trabajar ahorra bastantes datos.
Anotaciones: si los datos que hay para cada característica no son tan constantes, habrá muchas columnas que rellenar (una tabla para cada una de las características); mientras que cuando es exón y mRNA, haríamos diferentes tablas, una para cada uno. Pero, si en cada característica los datos que hay son bastante constantes (en todos hay más o menos la misma información) puedo hacer una tabla que una de las columnas sean las características.
Entonces, el mRNA no hay posición inicio y fin, si no que hay una serie de intervalos en cada uno de los exones.
¿Cómo relaciono el exón con la secuencia? Una secuencia tiene más de un exón, mientras que un exón proviene de una secuencia, siendo una tabla 1:N. entonces la tabla EXON: - Posición - Gen - Numero Acceso (FK) (una secuencia tiene varios exones y un exón es de una secuencia).
PK: combinar Acc con alguna de las otra menos con el gen para obtener la clave primaria.
SEQ: - Acc -Long - sp -Fecha creación - fecha mod KW: -keyword SP: - Especie -id - Acc - Genero EXON: - posición* -Gen -numero* - acceso *o una o la otra La tabla SEQ, sería la tabla clave, mientras que KW sería la intermedia, puesto que la relación KW. SEQ es del tipo N:M. Además, pese debería haber una tercera para estas, donde solo estuvieran os valores de KW, como son pocos datos no hace falta. Las claves primarias son las que están en negrita mientras que las foráneas serían las que siguen la flecha.
EP! Relación: - 1:N se debe crear otra tabla. P.ej: sexo - M:N: se deben crear 2 tablas mas, una intermedia y una final.
SESIÓN 1-3. 19 febrero-3 marzo 3.
Los investigadores pueden compartir sus estudios a través de las publicaciones científicas. A continuación se muestra una lista de artículos de revistas bioinformáticas. Realiza el diseño de una base de datos que almacene la información de la lista anterior. Recuerda incluir las claves necesarias y especificar los tipos de datos. ENTREGA 1 RELACIONES tabla clave (articulo): Articulo-PMID  1 PK.
Artículo-título 1.
Articulo- fecha: relación 1:N; pero en este caso admitiremos al redundancia.
Artículo-pagina_inicio  1 Articulo-autor N:M  un autor puede escribir varios artículos, así como un artículo puede estar escrito por varios autores. Por ello, debemos hacer dos tablas adicionales: una para establecer la relación y otra intermedia para “comunicarlas”.
(*)Relaciones tabla autores (intermedia): Autor-ID PK Autor- PMID Se necesita la combinación de ambas para poder establecer el lazo entre tabla clave y tabla “nombre_autor”.
(*)Relaciones tabla nombre_autor: Nombre_autor – ID: relación 1  PK.
Nombre_autor –nombre: relación 1:N. Aunque deberíamos hace runa tabla adicional, admitiremos redundancia en este caso.
Apellido: relación 1:N  Haremos lo mismo que en el caso anterior.
Articulo-revista  1:N  Un articulo solo puede encontrarse en una revista, así como una revista puede contener varios artículos. Por tanto, haremos una tabla adicional.
(*)Relaciones tabla revista: Revista-nombre  1  PK Revista- volumen  1:N  una revista tiene más de un volumen, pero un volumen determinado solo se puede encontrar una vez en la revista; en este caso aceptaremos la redundancia, por lo que no haremos una tabla adicional.
Revista-articulo  1:N  FK; es el dato que va a relacionar esta tabla con la tabla clave (articulo).
CORRECCIÓN.
SESIÓN 1-3. 19 febrero-3 marzo Según los ejemplos del enunciado hay que guardar la siguiente información: Título de un artículo; Autores de un artículo; Revista en la que se ha publicado; Fecha de publicación; Volumen; Edición; Página de inicio; Página de fin; PMID.
Esta información se distribuirá en distintas tablas. Las principales entidades que detectamos son el artículo, los autores y las revistas.
Para cada entidad, agruparemos la información que dependa de cada una y crearemos una tabla. Nos quedaría distribuido de la siguiente manera:  Artículo: Titulo; Fecha publicación; Página inicio; Página fin, PMID  Autores: Autor  Revistas: Revista (El volumen y la edición generarían redundancias si los ponemos en algunas de las tablas anteriores, lo ideal para reducir redundancias sería generar tablas para ellos).
Para relacionar las tablas, debemos saber qué tipo de relación hay entre ellas: - Un artículo puede tener más de un autor y un autor puede publicar más de un artículo. Así que su relación es N:M, por lo tanto crearemos una tabla intermedia.
- Un artículo se publica en una revista y una revista tendrá más de un artículo. Así que su relación es 1:N, podemos crear una relación directa entre las dos tablas.
Con toda esta información, faltará indicar cada columna qué tipo de dato sería, cada tabla cuál será la clave primaria y para resolver las relaciones, crear las claves foráneas.
Tipos de datos: - El tipo de dato más utilizado será varchar y es obligatorio definir el máximo de caracteres aceptado.
- La fecha de publicación deberá ser date - Las páginas de inicio y fin son numéricos aunque no caben en tinyint, por lo tanto podemos poner smallint.
- Cuando añadamos campos para crear claves primarias, serán int, por ejemplo PMID es int.
Claves primarias: - La tabla de los artículos ya tiene el campo PMID para ser clave primaria.
- A la tabla autores se le puede añadir un campo numérico para que sea clave primaria.
El apellido o la combinación de nombre y apellido podrían repetirse, así que no pueden ser la clave primaria.
- La tabla revistas también debería tener un campo numérico adicional que será la clave primaria. El nombre de la revista no se repetirá, pero en el caso de nombres de revistas largos ocuparían más espacio que un número.
- Al haber creado una tabla para resolver la relación entre artículos y autores, los campos de esa tabla serán el campo que sea clave primaria en la tabla autores y el campo que sea clave primaria en la tabla artículos. La combinación de ambas columnas será la clave primaria de esta tabla.
- Si se hubieran creado más tablas para la edición y/o el volumen, cada tabla deberá tener su clave primaria.
Claves foráneas: - La tabla revistas no depende de ninguna otra, por lo tanto no hay ninguna clave foránea en esta tabla.
- La tabla autores no depende de ninguna otra, por lo tanto no hay ninguna clave foránea en esta tabla.
- La tabla artículo depende de otras tablas. Se puede relacionar directamente con la tabla SESIÓN 1-3. 19 febrero-3 marzo revistas, pero si se ha creado alguna tabla para la edición y/o el volumen, la relación se hará a través de estas tablas. En el caso que la relación sea directa, es necesario que haya dos columnas en común, por lo tanto, en esta tabla debemos tener el campo que sea la clave primaria de la tabla revistas. Y de este campo saldrá una clave foránea que apunte a la tabla revistas, el campo que sea clave primaria. Dicho de otra manera, 1 revista publica varios artículos (1->N) mientras que 1 artículo se publica en una revista (1->1), las claves foráneas siempre se hacen en el sentido 1>1 apuntando al campo que es único en la segunda tabla, por lo tanto, desde la tabla artículo sale una clave foránea hacia la tabla revistas.
- Los autores y los artículos tienen una relación N:M, por lo tanto no los podemos relacionar directamente. Hemos creado una tabla intermedia y de esta tabla intermedia saldrán 2 claves foráneas. En esta tabla, de la columna que sea igual a la clave primaria de la tabla autores saldrá una clave foránea que apuntará a la columna clave primaria de la tabla autores. Y de esta tabla intermedia, de la columna que sea igual a la clave primaria de la tabla artículos, saldrá otra clave foránea que apuntará al campo PMID de la tabla artículos.
Si alguna de las relaciones no hubiera sido correcta, hay que comprobar si la creación de la clave foránea tiene sentido con la relación que se ha establecido. Pero cuando hemos establecido una relación incorrecta, estaremos generando redundancias innecesarias.
4.- Tenint en compte el disseny de l’exercici 1, crea les sentències SQL per saber: a) El llistat de graus que hi ha a la Universitat.
SELECT nombre_asignaturas FROM grados;  dará un listado con los nombres guardados en la tabla.
b) Quants graus hi ha a la Universitat SELECT COUNT (nombre_asignaturas) FROM Grados; c) El llistat d’assignatures de la Universitat SELECT nombre_asignaturas FROM Asignaturas; d) El llistat d’assignatures d’un grau determinat SELECT nombre_asignaturas FROM Asignaturas WHERE grado=’11579’; SELECT nombre_asignaturas FROM Asignaturas INNERJOIN Grados ON asignaturas.grado= grados.codigo WHERE Grados.nombre=’Genetica’; e) Quantes assignatures s’ofereixen a cada grau SELECT COUNT (Asignaturas.nombre), Grados.nombre FROM Asignaturas INNER JOIN Grados ON asignaturas.grado= grados.codigo; Pero, ¿quiero que me sumen todas las asignaturas? NO, quiero clasificarlas mediante GROUP BY. Por tanto: SELECT COUNT (Asignaturas.nombre), Grados.nombre FROM Asignaturas INNER JOIN Grados ON asignaturas.grado= grados.codigo GROUP BY Grados.codigo; Ahora se irá agrupando i como serán varias, por cada código habrá múltiples nombres en la tabla de asignatura.
f) Tota la informació personal dels alumnes SELECT * FROM alumnes; g) Tota la informació personal d’un alumne concret SELECT*FROM alumnes WHERE NIU=’xxxxx’; SESIÓN 1-3. 19 febrero-3 marzo h) La informació personal de l’alumne més jove SELECT * FROM Alumnes ORDER BY data_naixement DESC LIMIT 1; i) Les assignatures que ha fet o està fent un alumne junt amb les seves notes SELECT assignatures.nombre,Matriculas.Nota FROM Assignatures A INNER JOIN Matriculas M ON A.codigo= M.CodigoA INNER JOIN alumnes Al ON M.NIU=Al.NIU WHERE Al.nombre=’xxxx’ A i M así como Allo ponemos para escribir menos.
j) El grau que està fent un alumne SELECT Grados.nombre FROM Grados INNER JOIN Assigantures ON assignatures.grado=Grados.codigo INNER JOIN Matricules ON matricules.codigoA =Assignatures.codigo INNER JOIN Alumnes ON alumnes.NIU= Matricules.NIU WHERE Alumnos.nombre=’XX’ AND ALumnos.apellido=’XX’.
FONAMENTS DE PROGRAMACIÓ 5.- Suposa que tens un arxiu que emmagatzema informació de diverses seqüència (que poden estar en format FASTA), i vols obtenir informació sobre les seqüències.
Crea diferents algoritmes per saber: a) Si totes les seqüències tenen la mateixa llargada.
El primer paso va a ser abrir el archivo, mediante OPEN. Una vez abierto, se tiene que leer: si tiene el símbolo > nom, querrá decir que es FASTA. Esto conlleva a que se quiten los nombres de línea i se ajunten las dos secuencias para que sea una línea, también eliminando los saltos de línea (\n). Al final, conseguiremos tener los tres datos diferentes.
Para poder contar se usará un bucle en cada secuencia que sería capaz de acceder i contarlas una a una. Entonces, se guarda cada vez que se cuenta la longitud.
Se puede comparar con la previa sin necesidad de guardar, dado que es igual. Si la 1 y la 2 son distintas, o hace falta mirar la 3, porque ya hemos determinado si son diferentes o no.
Después de estipular las variables, se usaría length.
b) Si totes les seqüències són CDS (codo que codifica per la proteina des de l’inici fins STOP) Para ello deberíamos comprobar mediante una búsqueda de patrón si se trata de secuencias que tan solo contienen A, C, G o T y si van de 3 en 3  tema 7 c) Suposant que són seqüències homòlogues ja alineades, comprova quantes posicions diferents hi ha entre les seqüències.
Para este caso, deberemos hacer la operación lenght de una secuencia y luego de otra, para así conocer el número de nucleótidos que presentan.
EP! Deberemos vigilar que no contengan saltosde línea.
...