powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите спроектировать базу данных пословиц
19 сообщений из 19, страница 1 из 1
Помогите спроектировать базу данных пословиц
    #37531311
Jorik12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте. Мне нужно спроектировать базу данных так, чтобы одном запросе я могу сразу все данные получить. Запрос такой, что я ввожу текст, получить должен список пословиц, их аналогов и их описание.


У меня есть список русских пословиц и список других (английских, и т.д.).

Русская пословица имееет несколько аналогов (может иметь несоклько английских, а также русских аналогов и т.д.). Также есть общее описание (когда употребляется), оно относится к какому-то множеству пословиц (т.е. 4 пословицы, эквиваленты , аналоги , будут иметь 1 описание)

Т.е. пользователь ищет пословицу русскую: "блаблаблабла", а я в базе данных должны поискать все аналоги и выдать результат:

Искомый вариант: "блаблаблабла".
Английские аналоги:
"blablablablabla"
"WTF"
"It's a piece of shit"
Когда употребляется:
"Когда лень придумать пример, то мы пишем полнейший бред"


Я создал 3 таблицы.

1-ая:

uid(int), proverbText(varchar); PK = uid

2-ая:

uid(int), description(TEXT); PK = uid

3-ая:

id(int), rusAnalogvarchar(255), OtherAnalog(varchar(255)), description(int)

3-ая таблциа - это связка между 3 таблицами.

Т.е. сначала я ищу текст в 1-ой таблице(1), затем по найденным id я ищу в таблице аналогов описание, нахожу описание по id в 2 таблице(*), затем мне нужно найти аналоги списка таблиц из 1-го подзапроса.


Я почти седал заспрос, до *, но уменя уже запрос в 6 строчек, но работает но слишком длинный. Можно спроектировать так, чтобы запросы были поменьше? Преподаватель сказал: "it's a bullshit", также добавил, что это не будет проверять.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
select description, proverbText
from
   description,

   (SELECT DISTINCT proverbText,descriptionNum 
   FROM (
                 SELECT proverbText, proverbs.uid FROM proverbs WHERE proverbs.uid IN 
                    (SELECT DISTINCT comparison.rusAnalog FROM comparison WHERE comparison.rusAnalog IN
                        (SELECT proverbs.uid FROM proverbs WHERE proverbText LIKE '%д%'))
              ) as TempTable,comparison 
   WHERE TempTable.uid = comparison.rusAnalog or TempTable.uid = comparison.otherAnalog) as View1


where
   description.uid = descriptionNum
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531356
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 11/17/2011 01:59 PM, Jorik12 wrote:

> 1-ая:
>
> uid(int), proverbText(varchar); PK = uid
>
> 2-ая:
>
> uid(int), description(TEXT); PK = uid

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

Также тут должен наверное быть язык пословици.


> 3-ая:
>
> id(int), rusAnalogvarchar(255), OtherAnalog(varchar(255)), description(int)

Нарушение 1НФ,
rusAnalogvarchar(255), OtherAnalog(varchar(255)) -- массив полей.

description на фиг не нужен.

Таблица должна быть типа

uid(int), analog_uid(int)

причём либо отношение аналога должно быть несимметричным,
либо ты должен писать запросы с UNION-ами с двух сторон,
либо ты должен всегда вставлять записи

AA - BB
BB - AA

> 3-ая таблциа - это связка между 3 таблицами.

Не, это не связка, это дейтвительно bullshit.
Тебе надо почитать сначала что-то по проектированию реляционных БД,
иначе ты далеко не уйдёш.


> Я почти седал заспрос, до *, но уменя уже запрос в 6 строчек, но работает но

Запрос на неправильную структуру рассматривать бессмысленно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531459
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jorik12,

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
-- Create table
create table LANGUAGES
(
  lang_id   NUMBER not null,
  lang_name VARCHAR2( 200 )
)
tablespace DATA
  pctfree  10 
  pctused  40 
  initrans  1 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );
-- Create/Recreate primary, unique and foreign key constraints 
alter table LANGUAGES
  add constraint LANG_ID primary key (LANG_ID)
  using index 
  tablespace DATA
  pctfree  10 
  initrans  2 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
-- Create table
create table PROVERBS
(
  prvrb_id        NUMBER not null,
  text            CLOB,
  prvrb_parent_id NUMBER,
  lang_lang_id    NUMBER
)
-- Create/Recreate primary, unique and foreign key constraints 
alter table PROVERBS
  add constraint PRVRB_ID primary key (PRVRB_ID)
  using index 
  tablespace QUORUM_DATA
  pctfree  10 
  initrans  2 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );
alter table PROVERBS
  add constraint PRVRB_PARENT_ID foreign key (PRVRB_PARENT_ID)
  references LANGUAGES (LANG_ID);

Т.к. нужно хранить аналоги - в prvrb_parent_id пишеш айди пословицы, к которой данный аналог приаттачен. Выбираеш потом - в 1 запросе либо с подзапросом, либо рекурсивным запросом пословицу + ее аналоги. Про рекусривные запросы - читай в доке по своей субд. Преподу - скажи чтоб шел в жопу, иперед тем как "валить" - сказал бы как правильно.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531491
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 11/17/2011 02:54 PM, DeathHand wrote:

> create table PROVERBS
> (
> prvrb_idNUMBER not null,
> text CLOB,
> prvrb_parent_idNUMBER,
> lang_lang_idNUMBER
> )

> Т.к. нужно хранить аналоги - в prvrb_parent_id пишеш айди пословицы, к которой
> данный аналог приаттачен. Выбираеш потом - в 1 запросе либо с подзапросом, либо
> рекурсивным запросом пословицу + ее аналоги. Про рекусривные запросы - читай в

Не понятно, с чего ты решил сделать из пословиц дерево.
Во-первых, граф аналогов пословиц не факт, что ациклический, во-вторых, он
ненаправленный (скорее всего). И главное -- это "многие ко многим" в чистом
виде, очевидно, что у одной пословицы может быть много аналогов, и наоборот
(потому что отношение симметричное).

Так что всё правильно, но для отношения "аналогия пословиц" нужна
отдельная таблица связи, "многие ко многим", и ещё к тому же симметричная
связь должна быть.

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

Не, я согласен с преподом.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531509
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DeathHand,

Ну и с коментами к пословицам - разберешься. Тогда нужно добавить еще столбец в PROVERBS, который многими значениями будет указывать на одно значение в таблице COMENTS к примеру.

Типа:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
create table PROVERBS
(
  prvrb_id        NUMBER not null,
  text            CLOB,
  prvrb_parent_id NUMBER,
  lang_lang_id    NUMBER,
  cmnt_cmnt_id    NUMBER
)
tablespace QUORUM_DATA
  pctfree  10 
  pctused  40 
  initrans  1 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );
-- Create/Recreate primary, unique and foreign key constraints 
alter table PROVERBS
  add constraint PRVRB_ID primary key (PRVRB_ID)
  using index 
  tablespace QUORUM_DATA
  pctfree  10 
  initrans  2 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );
alter table PROVERBS
  add constraint CMNT_CMNT_ID foreign key (CMNT_CMNT_ID)
  references COMMENTS (CMNT_ID);
alter table PROVERBS
  add constraint PRVRB_PARENT_ID foreign key (PRVRB_PARENT_ID)
  references LANGUAGES (LANG_ID);

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
-- Create table
create table COMMENTS
(
  cmnt_id      NUMBER not null,
  comment_body CLOB
)
tablespace QUORUM_DATA
  pctfree  10 
  pctused  40 
  initrans  1 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );
-- Create/Recreate primary, unique and foreign key constraints 
alter table COMMENTS
  add constraint CMNT_ID primary key (CMNT_ID)
  using index 
  tablespace QUORUM_DATA
  pctfree  10 
  initrans  2 
  maxtrans  255 
  storage
  (
    initial 64K
    minextents  1 
    maxextents unlimited
  );
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531517
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivТак что всё правильно, но для отношения "аналогия пословиц" нужна
отдельная таблица связи, "многие ко многим", и ещё к тому же симметричная
связь должна быть.

Хм. Каждая пословица имеет уникальный номер. Даже дочерняя(аналог). Аналог, может иметь тоже аналог, что благодаря наличию уникального ключа - так же, становится реализуемо. Вопрос уровня вложенности, данным примером - по сути можно сделать любой уровень.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531521
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivНе, я согласен с преподом.

Я тоже, только сначала покажи примеры - как делать "жесть", научи, разжуй, а потом сношай моск.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531625
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 11/17/2011 03:15 PM, DeathHand wrote:

> Я тоже, только сначала покажи примеры - как делать "жесть", научи, разжуй, а
> потом сношай моск.

Тут ему не книжка. Книжек полно, пусть читает.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531637
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 11/17/2011 03:14 PM, DeathHand wrote:

> Хм. Каждая пословица имеет уникальный номер. Даже дочерняя(аналог).

Что значит дочерняя ? Родительская является аналогом дочереней в
той же степени, что и дочерняя -- аналогом родительской.

Аналог,
> может иметь тоже аналог, что благодаря наличию уникального ключа - так же,
> становится реализуемо.

Какая на х. разница, уникальный ключ или нет ? Ключ всегда уникальный,
ну и что ?
Почему дерево ? Дерево -- ациклический направленный граф.
Тут отношение аналогии, оно симметрично
A =a= B следовательно
B =a= A

т.е. граф аналогов ненаправленный, и к тому же там могут
быть циклы.

Скорее всего надо вообще хранить в таблице результат
выполнения транзитивного замыкания даже.
Может быть даже две таблицы надо -- для хранения изначальных
данных, и для храннения замыкания.



Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531644
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivOn 11/17/2011 03:14 PM, DeathHand wrote:

> Хм. Каждая пословица имеет уникальный номер. Даже дочерняя(аналог).

Что значит дочерняя ? Родительская является аналогом дочереней в
той же степени, что и дочерняя -- аналогом родительской.

Аналог,
> может иметь тоже аналог, что благодаря наличию уникального ключа - так же,
> становится реализуемо.

Какая на х. разница, уникальный ключ или нет ? Ключ всегда уникальный,
ну и что ?
Почему дерево ? Дерево -- ациклический направленный граф.
Тут отношение аналогии, оно симметрично
A =a= B следовательно
B =a= A

т.е. граф аналогов ненаправленный, и к тому же там могут
быть циклы.

Скорее всего надо вообще хранить в таблице результат
выполнения транзитивного замыкания даже.
Может быть даже две таблицы надо -- для хранения изначальных
данных, и для храннения замыкания.
А что курите то, уважаемый?
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531647
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv Родительская является аналогом дочереней в
той же степени, что и дочерняя -- аналогом родительской.
Ну и хрен бы с ней, собственно. Имею в парке 100500 баз, аналогичных сабжу, аналогичных тем что я предложил выше. Не комплексуем.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531681
Jorik12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо за комментарии. Поясню, что и почему как я сделал.
Сначала у меня были вот такие записи:

авторлибо ты должен всегда вставлять записи

AA - BB
BB - AA

Но я посчитал, что это избыточность, т.к. если 1-ая пословица связана со второй, то и 2-ая ОБЯЗАТЕЛЬНО связана с первой. Не бывает ассиметричности, всегда будет симметричный граф, причем будет повторяющие ключи,, поэтому мне пришлось еще один левый primary ключ создавать, например:

id
1 A - B
2 B - A
3 A - C
4 C - A

Почему я решил описание во вторую таблицу-связку.
Потому что опять же избыточность данных. Например, у 4-х половиц (они являются аналогами) есть 1 описание общее, поэтому я буду хранить кучу избыточных данных. А в моей таблице была симметричная связь. Т.е. блы а сзвяь ТОЛЬКО A - B, а подразумевалось, это то, что и B - A, но это отражалось только в запросах (OR).
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531727
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jorik12,

1) БД должна хранить данные так, как от нее требуется;
2) В БД нет графов - есть записи, ключи, таблицы, индексы и многое другое;
3) Избыточности не бывает - бывает больше записей, чем реально нужно, что бы хранить данные;
4) БД должна быть спроектирована так, чтобы запросы из нее были короче, а массивы данных обратаваемые такиими запросами - меньше;
5) БД должна быть умной. Т.е. имет ограничения и не давать.
6) Связь А-Б и Б-А не существует. Бывает 1-много, 1-1, много-к-много. Есть направление связи - от меньшего к большему;
7) Нормальных форм нет - есть спицифика приложений и особенности работы СУБД.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531734
DeathHand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jorik12,

Вывод - учитесь оперировать земными терминами. Глядишь - объем каши в голове то - поубавиться, да существенно.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531766
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> симметричный граф, причем будет повторяющие ключи,, поэтому мне пришлось еще
> один левый primary ключ создавать, например:
>
> id
> 1 A - B
> 2 B - A
> 3 A - C
> 4 C - A

Лучше именно так данные и хранить.
Удобнее будет писать запросы.

> Почему я решил описание во вторую таблицу-связку.
> Потому что опять же избыточность данных.

Нет избыточности.

Например, у 4-х половиц (они являются
> аналогами) есть 1 описание общее, поэтому я буду хранить кучу избыточных данных.

Тогда, извини, тебе надо иметь как отдельную сущность описание, (она у тебя
была), и тогда надо было иметь связь между поговоркой и её описанием.
У тебя она была, но была в таком виде, что я ничего не понял.

В одной таблице нельзя хранить несколько связей.
Надо столько таблиц, сколько связей обычно.
Так что делай отдельную таблицу связи поговорки с её описанием.
Описание одно, поговорок много, 1:M, тогда можно просто в поговорке
сделать ссылку на описание (не нужно отдельной таблицы).
Хотя если у одной поговорки может быть много описаний -- нужно таблицу
связи.

> А в моей таблице была симметричная связь. Т.е. блы а сзвяь ТОЛЬКО A - B, а
> подразумевалось, это то, что и B - A, но это отражалось только в запросах (OR).

Лучше хранить 2 записи, чем писать в 2 раза более сложный запрос.
Это по опыту.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37531783
Jorik12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо, понял.
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37534074
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jorik12Спасибо за комментарии. Поясню, что и почему как я сделал.
Сначала у меня были вот такие записи:

авторлибо ты должен всегда вставлять записи

AA - BB
BB - AA

Но я посчитал, что это избыточность, т.к. если 1-ая пословица связана со второй, то и 2-ая ОБЯЗАТЕЛЬНО связана с первой. Не бывает ассиметричности, всегда будет симметричный граф, причем будет повторяющие ключи,, поэтому мне пришлось еще один левый primary ключ создавать, например:

id
1 A - B
2 B - A
3 A - C
4 C - A



Скорее всего, если пословицы - синонимы, то это отношение транзистивно. То есть, если АА синоним ВВ, и ВВ - синоним СС, то и АА - синоним СС.

Если так, то все пословицы в группе синонимов равнозначны между собой, и граф как таковой не нужен. Можно ввести сущность "группа пословиц-синонимов". В ней не будет ни "зеркальных" записей, ни избыточности, и запросы по получению синонимов будут просты.

Пословицы
----------
АА
ВВ
СС
DD

Группы синонимов
------------------
1 о природе
2 о труде
3 о социальной справедливости

Вхождение пословиц в группы синонимов
-----------------------------------------
1 АА
1 ВВ
1 СС
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37534181
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Немного позанудствую

> 1) БД должна хранить данные так, как от нее требуется;
Кем требуется, зачем требуется? Ваша мысль непонятна

> 2) В БД нет графов - есть записи, ключи, таблицы, индексы и многое другое;
+1

> 3) Избыточности не бывает - бывает больше записей, чем реально нужно, что бы хранить данные;
Избыточность таки бывает (см денормализация) причем даже не связаная с количеством записей.

> 4) БД должна быть спроектирована так,
Чтобы запросы возвращали правильный результат за приемлимое время.
> чтобы запросы из нее были короче
Длина запросов рояля не играет, но в кривых плохочитаемых запросов ошибится легче,
> а массивы данных обратаваемые такиими запросами - меньше;
в общем случае это не верно, хотя часто это так

> 5) БД должна быть умной. Т.е. имет ограничения и не давать.
То есть если человек ограничен, то он тупой, а если база то она умная.
Про не дающих комментировать не буду, я джентельмен

> 6) Связь А-Б и Б-А не существует. Бывает 1-много, 1-1, много-к-много.
+1, хотя можно было упомянуть про 1-0 и так далее.
> Есть направление связи - от меньшего к большему;
Если связей не существует то как могут существовать направление связи.

> 7) Нормальных форм нет - есть спицифика приложений и особенности работы СУБД.
Нормальные формы есть. Приложение может на них забивать, полностью осознавая неприятности которые за этим последуют.

Ставить +1 MasterZiv не буду, ибо много придется ставить
...
Рейтинг: 0 / 0
Помогите спроектировать базу данных пословиц
    #37534295
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv(потому что отношение симметричное)
Ну вот это для учебной задачи конечно, а по сути очень большая натяжка. Ближе к реальности следующая модель: есть "пословицы", есть "смыслы" (они же "когда употребляется") и есть многие-ко многим между ними.

Например, в некоторых ситуациях "одного поля ягоды" и "яблоко от яблони недалеко падает" - синонимы, а в других - вовсе нет.
...
Рейтинг: 0 / 0
19 сообщений из 19, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите спроектировать базу данных пословиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]