|
27 Кб. |
|
| Представьте себе такую ситуацию:моя БД доолжна содержать в себе исполнителей и их песни, причем песни группируются по начальной букве, т.е.
-Выбираю исполнителя.(пример: Петров)
-Передо мною возникает алфавит ()
-Выбираю нужную мне букву (пример: В)
-Выбираю песню (пример: Велосипеды)
Ну т.е. требуется некий рубрикатор. Я пытался сделать схему но что-то у меня не очень вышло, я тут прикрепил скриншот показывающий мою задумку.
Не могли бы вы подкорректировать мою схему данных или подсказать как разработать новую ... В общем помогите плиз. | |
|
| |
|
33 Кб. |
|
| Тут тот же скриншот что и в первом сообщении но покачественнее | |
|
| |
|
11 Кб. |
|
| Подкорректировать скриншот трудновато...
если бы живые таблицы формы........
А ваще то можно и без явных связей нагородить. | |
|
| |
|
12 Кб. |
|
| Да точно скриншот корректировать трудновато , вот мое детище. | |
|
| |
|
11 Кб. |
|
| а может без алфавитов обойтись
Отсортировать названия и так можно и искать в подчинённой форме быстрее будет.. | |
|
| |
|
|
|
| Товарищ час, спасибо что вы хотите мне помочь но мне нужно только схема данных , наподобие той которую я пытался сделать . Формы, отчеты мне не нужны , так как я хочу эту базу реализовать на MySQL и работать с ней через PHP в инете. А Access мне нужен только для составления схемы данных, так сказать для проверки целостности. | |
|
| |
|
|
|
| АААААААААААААААААААААААА воооооон оно чё
Виноват не въехал..
извините не знал, не понял сразу....
Подождём завтрева.
Подгребут спецы SQL вот тогда.................................. | |
|
| |
|
|
|
|
>только схема данных , наподобие той которую я пытался
|
не знаю что именно вы затеяли в этой схеме, но выглядит довольно горбато...
можете описать подробнее (обычным языком-словами) предметную область? что за задача перед вами стоит? | |
|
| |
|
|
|
| Хорошо, как я уже сказал эта база данных для Web .Представьте вы заходите на музыкальный сайт.
-Выбрали исполнителя- например Ивановский.
-Далее перед нами буковки :A,Б,В..... которые отвечают за начальную букву у песни.Нажимаем на буковку.
-Перед нами все песни на выбранную букву , но у песни может быть ремикс, а может и не быть.
-Выбираем песенку -Например "Я по полю ходил." Если ремиксов нет то выбираем, если есть
то по "связи у одного названия много ремиксов " делаем переход и окончательно имеем то что нам нужно.
Для этого всего мне нужна схема данных, как я уже говорил можно подкорректировать мою, или предложить какую-нить другую,т.к. мне что-то подсказывает что я сделал мега-herovyu схему данных, в которой отстутствуют целостность данных. Заранее спасибо. | |
|
| |
|
|
|
| Такой вопрос если я выбираю букву "Я", должны ли сразу показываться и ремиксы? или только та песня которая является "родительской"?
Может одна песня быть ремиксом нескольких?
После ответа попробую набросать схему.
На мой взгляд никакой рубликатор (как отдельная таблица) не нужен. | |
|
| |
|
|
|
| Ну собст-но схемы которые я хотел предложить уже есть ниже :-) | |
|
| |
|
11 Кб. |
|
| ну , например, так:
tbPerf: ID(счетчик), PNAME
tbSongs: ID(счетчик), SNAME
tbRemix: ID(счетчик), IDSONG(длинное целое), RNAME
tbRelations: IDPERF(длинное целое), IDSONG(длинное целое)
схема данных в аттаче | |
|
| |
|
|
13 Кб. |
|
| вот такой варинат по такому ТЗ проходит: (см. аттач)
исполнители с песнями связаны отношением один-ко-многим таблиц tblAutors и tblSongs по полю AutorID
песни с ремиксами связаны отношением один-ко-многим в одной таблице tblSongs по полям SongID и SourceID | |
|
| |
|
|
|
| а я чето не захотел ремиксы вкидывать в одну таблицу с просто песнями
но твой вариант более оптимальный для задачи | |
|
| |
|
|
|
| интересно, а что автор ТЗ собирается делать с попурри (pot-pourri фр.) на темы нескольких разных песен | |
|
| |
|
11 Кб. |
|
| отмечу петитом воизбежание недопонимания - tblSongs и tblSongs_1 - это одна и та же таблица (tblSongs), представленная в схеме данных двумя инстансами с разными именами...
аксессная рисовалка схемы не дает отображать такой тип связи иначе, а рисовалка в визио что-то у меня слетела | |
|
| |
|
|
|
| ну да :) а sourceID - "обычный" parentid
а для "первой буквы" на mysql тоже "канает"
select distinct LEFT(SongName,1) as L1 from tblSongs order by L1
|
и для поиска либо ... where (SongName LIKE 'я%'), либо where (LEFT(SongName,1)='я')
... поиск по умолчанию нечувствителен к регистру | |
|
| |
|
|
|
| :) привет, Олег | |
|
| |
|
|
|
|
| Всем спс за то что откликнулись.А скажите плиз у кого рабочая схема у Кабана или Explorera? | |
|
| |
|
|
|
|
| Люди я рассматриваю схему данных кабана, но никак не могу врубить зачем тут связб многие ко многим.
Вроде на языке слов должно быть так.
-Есть авторы песен.
-У каждого автора есть много песен
-У каждой песни может быть несколько ремиксов.
Объясните плиз эту схему ...не могу я понять зачем там эта связь многие ко многим. | |
|
| |
|
|
|
| >Объясните плиз эту схему ...не могу я понять зачем там эта
>связь многие ко многим.
Performer <> Autor | |
|
| |
|
|
|
| Performer <> Autor , что-то не очень то эта строчка разнясняет мне мой вопрос. | |
|
| |
|
|
|
| tbPerf - авторы (можно назвать как угодно :)
tbSong - пестни
tbRemix - ремиксы
tbRelations - Связь между Автором и песнями
в даную схему всралась ошибко по скорости создания - tbRemix , связанный с tbSong теряет автороство :)
в общем то, хреновая сырая и непродуманная схема получилась :) тяп-ляп
я беру самоотвод и посыпаю голову пеплом :)
Схема, предложенная Explorerом наиболее отвечает вашим потребностям. Мало того - там всего две таблицы, которые обеспечат вам фсё. | |
|
| |
|
|
|
| Performer = Исполнитель
Исполнитель <> Автор | |
|
| |
|
|
|
|
верно! | |
|
| |
|
9 Кб. |
|
| Скажите плиз я правильно понял схему Explorera ,Есть Авторы которые исполняют песни-первая связь, а вторая связь - у поля одной таблицы есть много полей этой же таблицы, так что ли? Просто мне не очень ясно возможно ли такое что поле одной таблицы связью один ко многим с полями этой же таблицы.
Я тут прикрепил файл со схемой показывающий мое понимание схемы . Я правильно ее понял? | |
|
| |