Структура данных для базы данных корпуса текстов

Question

Текст корпус, как правило, представлены в XML, как, например:

<corpus name="foobar" date="08.09.13" authors="mememe"> 
    <document filename="br-392"> 
    <paragraph pnumber="1"> 
     <sentence snumber="1"> 
     <word wnumber="1" partofspeech="VB" sensetag="-v" nameentity="None">Hello</word> 
     <word wnumber="2" partofspeech="NN" sensetag="-n" nameentity="World">Foo bar</word> 
     </sentence> 
    </paragraph> 
    </document> 
</corpus> 

Когда я пытаюсь поставить корпус в базу данных я имел каждую строку, чтобы представить слово, а столбцы являются такие как:

| uid | corpusname | docfilename | pnumber | snumber | wnumber | токен | pos | sensetag | ne

| 198317 | foobar | br-392 | 1 | 1 | 1 | Привет! VB |-v | Нет |

| 192184 | foobar | br-392 | 1 | 1 | 1 | foobar | NN | 87654321-n | Мир |

Я положил данные в базу данных sqlite3 как таковой:

# I read the xml file and now it's in memory as such. 
w1 = (198317,'foobar','br-392',1,1,1,'hello','VB','12345678-n','Hello') 
w2 = (192184,'foobar','br-392',1,1,1,'foobar','NN','87654321-n','World') 

con = sqlite3.connect('semcor.db', isolation_level=None) 
cur = con.cursor() 
engtable = "CREATE TABLE eng(uid INT, corpusname TEXT, docname TEXT,"+\ 
         "pnum INT, snum INT, tnum INT,"+\ 
         "word TEXT, pos TEXT, sensetag TEXT, ne TEXT)" 
cur.execute(engtable) 
cur.executemany("INSERT INTO eng VALUES(?,?,?,?,?,?,?,?,?,?)", \ 
           wordtokens) 

Цель этой базы данных, так что я могу выполнять запросы, как такой

SELECT * from ENG if paragraph=1; 
SELECT * from ENG if sentence=1; 
SELECT * from ENG if sentence=1 and pos="NN" or sensetag="87654321-n" 
SELECT * from ENG if pos="NN" and sensetag="87654321-n" 
SELECT * from ENG if docfilename="br-392" 
SELECT * from ENG if corpusname="foobar" 

Похоже, когда я структуру базы данных, как указано выше, мой размер базы данных взрывается, потому что количество токенов в каждом корпусе может увеличиться до миллионов или миллиардов.

Помимо структурирования корпуса, имея каждую строку для слова и столбцы свой атрибут и родительский атрибут, как еще я могу структурировать базу данных, чтобы я мог выполнять запросы и получать один и тот же результат?

Для индексации большого размера корпуса,

1. я должен использовать другие, чем sqlite3 некоторые другие программы баз данных?

2. И должен ли я использовать ту же схему для таблицы, как я определил выше?

Answer 1

И должен ли я использовать ту же схему для таблицы, как я определил выше?

В перспективе реляционной базы данных, из-за 1NF, я буду использовать таблицу на элемент XML-файла.
Мы сэкономим место, и мы поможем работать с СУБД.
Используя модель, желательные запросы будут appliable
Проект модель будет:

я должен использовать другие, чем sqlite3 некоторые другие программы баз данных?

Что можно ответить на основе вашей спецификации приложений, как, сколько записей данных вы будете иметь через месяц, год, ..., сколько пользователей будут подключены, является его OLTP или OLAP или смешанной , бюджет проектов и ...
BTW взгляните на бесплатные R-DBMS, такие как PostgreSQL, MySQL и коммерческие, такие как Oracle.
Для решения NoSQL, имеющего вид на post может быть полезным

Answer 2

Я думаю, ответ очевиден «нормализация» ... у вас есть огромное количество дублированной информации в строку и что собирается массово увеличить размер базы данных.

Вы должны выработать из каждой строки то, что дублируется, а затем создать таблицу для хранения этих данных, а затем вы уменьшите, например, дублируемую строку, содержащую длину тела, скажем, 20 символов, до указателя к строке в таблице «corpus name», которая для аргументов может просто взять 4 символа в качестве значения идентификатора этой записи.

Вы не говорите, какую платформу вы используете. Если это мобильное устройство, оно действительно действительно платит, чтобы нормализовать ваши данные как можно больше. Это делает код немного более сложным, но это всегда компромисс между пространством и временем с такими вещами. Я предполагаю, что это какое-то ссылочное приложение, и в этом случае чистая ослепляющая скорость, вероятно, является вторичной для того, чтобы заставить ее работать.

Обязательная ссылка википедии для normalisation

и это YouTube video

Google является вашим другом, надеюсь, что помогает. :) Sean