Логика БД

← →
No_Dead (2007-11-26 13:54) [0]

Делаю сейчас БД для библиотеки (для зачета задание).
Но получается как-то, имхо, не правильно.
Создаю БД с полями:
ID_Book, Title, ID_Author, ID_Publish, ISBN, ID_Section, ID_SubSection, ID_Lang, ID_Format, ID_Resolut, Link_Libra, ID_Shop, Page, Size, ID_Comment.
Далее, для всех записей с ID_ создаю свои таблицы, ну к примеру, для ID_Section будет таблица с полями ID_Section и Section_Name.
В итоге как бы получается одна таблица сформированная на основе всех остальных (попытался в Toad Data Modeler набросать структуру получается что эта таблица как «ствол дерева», а все остальные как «ветви»).
Допустима ли такая структура БД?
Или сама «логика» неверная?

← →
Kerk © (2007-11-26 13:58) [1]

Вроде все нормально

← →
No_Dead (2007-11-26 14:04) [2]

> [1] Kerk © (26.11.07 13:58)

да просто как-то на здесь на форуме (давно может даже в прошлом году) кто-то показывал свою БД нарисованную, так вот «куча» всяких переплетений, связей, а у меня получается все как-то все черезчур все просто, имхо. это то и смутило, несколько. Вот и подумал, что либо у меня ТЗ  простая, либо  что то упускаю (в смысле самого проектирования).

← →
Desdechado © (2007-11-26 14:06) [3]

Для зачета пойдет.
Для реалий - вряд ли, т.к. книга может относиться к нескольким категориям, у нее может быть много авторов, она может быть переиздана (года не вижу) другим издательством, с другим числом страниц, на другом языке и т.п.

← →
Sergey13 © (2007-11-26 14:11) [4]

> [0] No_Dead (26.11.07 13:54)
> ID_Author,

Может быть и несколько авторов, а может и ни одного.

← →
No_Dead (2007-11-26 14:14) [5]

> года не вижу

это действительно упустил

> книга может относиться к нескольким категориям

хм&#133 не могу сообразить. есть же ББК по которым книгу можно однозначно идентифицировать, т.е. к какому разделу она относится.

> нее может быть много авторов

авторские коллектив в смысле?

Замечания, указания на «пробелы» понятны, а вот как от этих «пробелов» избавиться&#133 слету как-то и не предложу:(

← →
Anatoly Podgoretsky © (2007-11-26 14:19) [6]

Нужно структуру нормализовывать, с введением связей Многие ко Многим.
По авторам и издательствам как минимум.

← →
oldman © (2007-11-26 14:30) [7]

А почему не сделать ОДНУ таблицу с полями:

Title
Author (Authors)
Publish
ISBN
Section,
SubSection
Lang
Format
Resolut
Link_Libra
Shop
Page
Size
Comment

???

← →
No_Dead (2007-11-26 14:31) [8]

> [6] Anatoly Podgoretsky © (26.11.07 14:19)

т.е. более тщательно произвести разбиение на таблицы?

← →
No_Dead (2007-11-26 14:44) [9]

> [7] oldman © (26.11.07 14:30)

хм&#133 об этом даже не подумал.
На выбор предложенной «тактики» оказало влияние:
1. Имхо, чем там таблица будет проще разбита на более мелкие таблицы, тем лучше(подобное высказывание многих заставит улыбнуться, может быть, и не серьезно, но интуиция подсказывает что так эффектинее)
2. Необходимо отобразить именно связи между таблицами, сам механизм работы (если бы не стояло такого конкретного указания, может и сделал бы в одной таблице, но вот 1 вызвало сомнения)

← →
Павел Калугин © (2007-11-26 15:01) [10]

> oldman © (26.11.07 14:30) [7]
> А почему не сделать ОДНУ таблицу с полями:

А потому что тогда зачет не сдаст:)

Хотя сли смотреть на то как у нас читают подобный курс от этого и надо отталкиватся.
1. создать таки большую таблицу
2. выбрать алгоритм нормализации
3. Описать все необходимыее для применения алгоритма зависимости
4. применить алгоритм

← →
Anatoly Podgoretsky © (2007-11-26 15:22) [11]

> Имхо, чем там таблица будет проще разбита на более мелкие
> таблицы, тем лучше

Неверно по сути, разбиение не является самоцелью, база должна выполнять свои функции без аномалий.
Если не сделаешь связи Многие ко Многим не сможешь нормально искать по автору или по издательству, будет большое дублирование информации и сложность в ее управление.

← →
oldman © (2007-11-26 15:26) [12]

Я не про то в [7].
Не проще ли пожертвовать размером базы, но отказаться от ID?
А то при поиске, например, по "Пушкин А.С.", придется сначала лезть в базу Authors, чтоб сначала найти его там и выяснить его ID.

← →
Sergey13 © (2007-11-26 15:34) [13]

> [12] oldman © (26.11.07 15:26)
> А то при поиске, например, по "Пушкин А.С.", придется сначала
> лезть в базу Authors

А при поиске по "А.С. Пушкин" или по "А Пушкин" в твоем варианте уже можно повеситься. А если еще окажется, что например первая А - латинская, то у библиотекаря будет столбняк. 8-)

← →
Anatoly Podgoretsky © (2007-11-26 16:45) [14]

> oldman (26.11.2007 15:26:12) [12]

Зачем? Про Join и Where слышал.

where Autors like "Пушкин"

← →
oldman © (2007-11-26 17:01) [15]

> Anatoly Podgoretsky © (26.11.07 16:45) [14]

При этом программа не выполнит действий [12]?

← →
sniknik © (2007-11-26 17:22) [16]

> При этом программа не выполнит действий [12]?
авторов скажем 10 000, книг 10 000 000...
что выгоднее, найти "... from Autors where Name like "%Пушкин%"" в 10 000 ID автора и после по ключевому полю выбрать его книги, или делать (типа без лишних действий в [12]) поиск "... from Books where AutorsName like "%Пушкин%"" в 10 000 000?
hint: индексы в таком like не используются...

тут как должен понимать (?) размер базы дело десятое...

← →
Desdechado © (2007-11-26 17:24) [17]

> oldman © (26.11.07 14:30) [7]
Рассуждаешь на уровне школьника 10 лет от роду.
Чему, ты думаешь, учили автора? Наверняка правила нормализации рассказывали. Вот пусть и применяет (тем более, что это действительнонужно).
И ты заодно почитай, зачем нужны суррогатные ключи и что такое вообще ключи.

← →
kaif (2007-11-26 17:37) [18]

В догонку к замечаниям, сделанным другими участниками (насчет отношений многие-ко-многим в случае множества авторов у одной книги)

ID_Section,
ID_SubSection

Если допустимые значения второго поля здесь хотя бы как-то зависят от первого, то это - нарушение нормализации.
Проверь.
Если это так, то оставь лишь одно поле ID_SubSection из этих двух в своей таблице, а второе перенеси в таблицу SubSection.
Или же оставь оба поля в таблице данных, но снабди их составным внешним ключом на справочник SubSection, в который добавь поле ID_Section, которое в сочетании с полем ID_Subsection имело бы ограничение уникальности.

В общем, обмозгуй этот момент.
Главное - не допустить такого редактирования таблицы накопителя (смены секции), когда останется субсекция из другой секции, несовместимая с текущей секцией

← →
oldman © (2007-11-26 18:08) [19]

> Desdechado © (26.11.07 17:24) [17]
> Рассуждаешь на уровне школьника 10 лет от роду.

Я, конечно, понимаю, что для зачета все сойдет...
Но не решается автоматизация процесса (пусть даже библиотекаря) вот так вот в лоб. Проблем не оберешься.
Там ведь, если анализировать, половину проблем можно решить анализом.
Например: зачем поле Size?
Ты будешь, приходя в библиотеку интересоваться размером книги? Или искать книгу по размеру?
И т.д. и т.п.

← →
Desdechado © (2007-11-26 18:14) [20]

> зачем поле Size?Ты будешь, приходя в библиотеку интересоваться
> размером книги? Или искать книгу по размеру?
Почему бы и нет?
Например, видел 2 издания одной книги, отличаются только годом выпуска (допустим, я не помню) и размером (А4 и А5). Но для меня важно именно А4, т.к. там другая нумерация страниц, а у меня нужные страницы на бумажке записаны, когда в прошлый раз смотрел.

← →
oldman © (2007-11-26 18:17) [21]

> Desdechado © (26.11.07 18:14) [20]

Для этого нужно знать издателя и год издания.

← →
oldman © (2007-11-26 18:19) [22]

Для западных книг - еще и переводчика неплохо-бы...

Кстати, в списке полей нед поля "перевод/адаптация"

← →
oldman © (2007-11-26 18:26) [23]

Кстати, что-то знакомая тема курсовика по "базы данных"...
Товарисч No_Dead, вы не в СГА учитесь?
:)

← →
kaif (2007-11-26 18:28) [24]

2 oldman ©
Нарекания на твое сказанное относились целиком к части странного (если не сказать больше) отношения к нормализации. Нормализация ведь не есть самоцель. Она призвана защищать целостность и осмысленность данных. Вот тебе лично приходилось когда-нибудь осуществлять импорт из плохонормализованной базы данных? Или вообще ненормализованной? Когда вместо записей вроде "Пушин А.С." легко можно найти в поле такие данные, как например, "Сказки народов мира", "Прочее..." или даже "остаток на складе на 01.12.2005". А какая разница, что, собственно, писать в поле "Автор"? Если программа позволяет туда писать любой текст...

← →
oldman © (2007-11-26 18:34) [25]

> kaif (26.11.07 18:28) [24]
> Вот тебе лично приходилось когда-
> нибудь осуществлять импорт из плохонормализованной базы
> данных? Или вообще ненормализованной?

Приходилось.
Но в 98% случаев я связывался с разработчиком и все ему высказывал.
И даже помощи добивался, пскольку это были его ошибки.

← →
Desdechado © (2007-11-26 18:58) [26]

> Для этого нужно знать издателя и год издания.
Вот ты уже и загоняешь пользователя в плохие рамки. А ты ему помогать должен, автоматизировать. Если я не помно издател и год, мне важна книга определенного размера, то что - Dataset.IsEmpty=True?

← →
Anatoly Podgoretsky © (2007-11-26 19:21) [27]

> При этом программа не выполнит действий [12]?

Еще как выполнит

На мой взгляд, ID_Section, ID_SubSection, Link_Libra, ID_Shop, возможно, и ID_Comment не являются атрибутами книги. Я, например, когда ищу книгу в "Библио-Глобусе", вижу еще такие данные: зал, полка... Как только кто-то приобрел книгу, все это становится неактуально.

← →
No_Dead (2007-11-26 22:08) [29]

> [13] Sergey13 © (26.11.07 15:34)

прочитав пост первое что пришло в голову  написать функцию проверки при вводе данных в БД, что бы данные вводились только в определенной раскладке, что бы не было «смешивания» латиницы и кириллицы, хотя это не выход и совсем не нужное ограничение, наверное

← →
No_Dead (2007-11-26 22:47) [30]

> [18] kaif (26.11.07 17:37)

возможно Вы правы. Я вот как размышлял.
Все книги классифицируются по ББК. В качестве ID_Section я хотел взять именно крупные разделы (т.е. по стандартам ББК, насколько я помню, 1. Естественные науки, 2. Гуманитарные науки, 3. Техника. Технические науки), а под ID_SubSection хотел взять «более мелкие составные от крупного», т.е. например (но немного начав знакомиться с библиотечным делом, понял что «усложняется» решение)

ID_Section = 3. Техника. Технические науки ID_SubSection = 32. Радиоэлектроника. ID_SubSection = 32.97 Вычислительная техника. ID_SubSection = 32.973 Электронные вычислительные машины и устройства. ID_SubSection = 32.973.2 Электронно вычислительные машины и устройства дискретного действия.

даже из этого примера видно что получается, если следовать в предложенном ключе проектирования, то необходимо вводить еще и ID_SubSubSection (для 32.*), ID_SubSubSubSection(32.*.*).
я подумаю как «утонченнее» сделать этот момент, и склонен считать что от ID_SubSub(&#133) надо уходить, имхо

← →
No_Dead (2007-11-26 23:01) [31]

> [23] oldman © (26.11.07 18:26)

нет, у меня другой ВУЗ:)

> [28] uw © (26.11.07 19:59)

я сейчас хочу с проектировать БД. А реализовываться она будет в mySQL. Это БД будет использоваться для инетнет-библиотеки(!), поэтому я решил будет неплохо включить такие поля как
Link_Libra  т.е. линк на книгу в самой библиотеке (или другой именно библиотеки),
ID_Shop  где ее можно приобрести (здесь тоже можно помозговать: интернет-магазины, книжные магазины, и магазины именно в вашем регионе/городе, т.е. простор есть)
ID_Comment  комментарии читателей (понравилось/непонравилось, голосование, и пр., ну это я пока на задний план отодвигаю)

> No_Dead (26.11.07 22:47) [30]
> и склонен считать что от ID_SubSub(…) надо уходить, имхо

Получится дерево. Т.е
TABLE SECTIONS ( ID INTEGER, PARENT_ID INTEGER, NAME VARCHAR(100), PRIMARY KEY (ID), FOREIGN KEY (PARENT_ID) REFERENCES SECTIONS (ID) ON UPDATE CASCADE ON DELETE CASCADE )

No_Dead (26.11.07 23:01) [31]
Это БД будет использоваться для инетнет-библиотеки(!),

Ясно. Это и вправду меняет дело.

> [31] No_Dead (26.11.07 23:01)
> ID_Comment — комментарии читателей (понравилось/непонравилось,
> голосование, и пр., ну это я пока на задний план отодвигаю)

ИМХО, не книга должна ссылаться на коментарии, а коментарии на книгу.

> ИМХО, не книга должна ссылаться на коментарии, а коментарии
> на книгу.

То же касается и Link_Libra и ID_Shop.

> ЮЮ (27.11.2007 09:04:35) [35]

> Link_Libra — т.е. линк на книгу в самой библиотеке
> ID_Shop — где ее можно приобрести
> ID_Comment — комментарии читателей
Опять отношение 1-ко-многим или многие-ко-многим, т.е. реализуется отдельными таблицами, т.к. приобрести или почитать можно в разных магазинах/библиотеках, а комментариев может быть много.

> Все книги классифицируются по ББК. В качестве ID_Section я хотел
> взять именно крупные разделы
Одна книга тоже может относиться к разным секциям. Например, "Глубинная философия математического анализа погодных явлений" :)

Как уже было замечено, имеется путаница отношений один-ко-многим в части комментариев. Выбрось Comment_id. Таблица комментариев должна ссылаться на id книги, а не наоборот.
Рубрикатор проще всего сделать в виде дерева id,parent_id,name.
Если одна книга может относиться более чем к одной секции, то потребутется еще одна дополнительная таблица, в которой будут храниться пары ссылок на id книги и id секции.
Кстати, лучше таблицу не называть section, так как (если я правильно помню) это ключевое слово в некоторых СУБД.

No_Dead (26.11.07 22:08) [29]
> написать функцию проверки при вводе данных в БД,
это защита от очевидных ошибок, например, чтоб имя автора на твердый знак не начиналось. Но не спасет от неочевидных, напишут "Пушкинд" и никогда ты эту книгуне найдешь.

Логика БД Найти похожие ветки