Я поймал себя на мысли, что когда объясняли на лекциях по БД суть внешних ключей (FK) - я всё понял либо не так, либо недопонял.
С одной стороны всё понятно. И связи 1-ко-многим (к которым нужно стремиться преобразовывая многие-ко-многим и 1-к-1), и логический смысл всего этого (когда связь описываешь глаголом и всё становится ясно).
И схемы строятся на ура в любом ER моделлере или на листочке. Но когда начинаешь применять это на практиче - в реализации начинаются затыки. Пример:
В MySQL WorkBanch (недавно узнал про этот замечательный бесплатный продукт от Oracle для MySQL да ещё и с ER построителем) создал схему данных (ниже попробую вставить 2 файла если получится).
Теперь ломаю голову - какая схема правильная.
В одной схеме связи к таблице СВТ (средства вычислительной техники) идут параллельно от справочников (СВТ_тип, СВТ_модель, СВТ_Брэнд). Планируется отдельно через форму заполнения НСИ вносить новые модели СВТ, новые ТИПы (монитор, принтер и т.д), а на форме оформления в ремонт СВТ планируется выбирать из справочников нужные данные и формировать тем самым сервисный лист. При этом не могу понять - будет ли возможно реализовать при таком виде связей нужную мне выборку. Так как пока мутно представляю себе - сам принцип связи в действии. Мне нужно в результате получить конструкцию, подобную такой, какая на сайте АСУС Загрузка драйверов (где выбирается сначала продукт, потом подгружаются все серии данного продукта, потом все модели данной серии).
Во второй схеме я описал последовательные связи от родителя СВТ к дочке СВТ_класс - от неё к СВТ_брэнд, а от неё к СВТ_модель.
Помогите представить себе схему правильно и выбрать один из вариантов.
PS. Не пойму как вставить сразу 2 файла, поэтому следующим постом будет ещё одно прикрепление.

Вторая схема, которая мне более предпочтительна, но не знаю верная ли.

А это вид сайта АСУС с выборкой для загрузки драйверов.

П-ЛSVT конкретный экземпляр какой-то модели, значит 1:М к SVT_model
SVT_model характеризуется типом техники (монитор, принтер) и производителем (Toshiba, Samsung) стало быть 1:М к SVT_Type и 1:М к SVT_Brand
Так что мне обе схемы не нравятся.
Я когда кумекал после опубликования своего вопроса - это дотямил сам и даже записал свои мысли :)
Именно, не было понимания сущности SVT_Model. Я всё никак не мог понять, как я буду из поля со списком выбирать огроменную кучу моделей техники разных типов (ПК, монитор), фирм и классов (лазерный, матричный и т.д.) и дотямал, что нужно привязать именно SVT_type и SVT_Brand к SVT_Model (реально я сам допёр - тулился по кухне нарезал круги ждал ответа с форума) :)

guest_20040621Ни один из представленных.
Вы можете пойти кривым, но простым путем: вендоры, категории продуктов, серии продуктов (вендор, категория), продукты (серия, модель).
Вы имеете ввиду тупо заполнять одну таблицу? Без возможности выбора отдельных позиций? Всмысле денормализовать?
Если это не учебная работа, я бы рекомендовал вам отложить реализацию.
Это выпусная квалификационная работа (она же ВКР или диплом) :)
Срок сдачи 20 февраля. 27 защита :)
Сижу ночами с 23:00 до 06:00, т.к. днем ребенок не дает (я в отпуске дипломном).
Думаю успею, т.к. сижу плотно и наконец-то осознание пришло :) У меня был затык именно в части непонимания svt_model и правильной нормализации этой таблицы. Теперь я понял - это главная часть моего проекта. Правда сейчас голову ломать нужно будет как организовать историю выполнения работ по ремонту принятого СВТ, но думаю всё аналогично или близкое к тому :)
Кстати, подскажите почему нельзя редактировать свои сообщения?

guest_20040621Есть конкретные вопросы?
Верно ли я последнюю схему данных представил? Этот вопрос больше наверное к П-Л , т.к. он намекнул, что:
1) SVT (1) ---> (M) SVT_Mode .
2) SVT_Model (1) ---> (M) (SVT_Class, SVT_Brand).

Но я проанализировал схему с обратной стороны и сделал выводы:
1) Существует Класс (Монитор, принтер) который подразделяется на множество моделей.
2) Существует Брэнд (LG,Samsung, IBM) который выпускает много моделей СВТ.
3) Существует Модель (P3200, F700) которая продана магазином множество раз с разными серийными номерами. Эта же модель если встали на работу предприятия подписана многими инвентарными номерами.

Выходит у одной и той же задачи есть 2 совершенно разных схемы данных?
Или одна из них принципиально неверная?
Или, тогда с какой стороны начинать рассматривать сущности? По идее с минимальной единицы - атомарной (Класс, Брэнд)?

guest_20040621> Верно ли я последнюю схему данных представил?

create table "vendors" (id int4, name varchar(256), ...);

create table "product_categories" (id int4, name varchar(256), ...);

create table "product_series" (id int4, name varchar(256), ..., vendor_id int4, product_category_id int4,
...
CONSTRAINT product_series_fk_vendor FOREIGN KEY (vendor_id) REFERENCES "vendors" (id),
CONSTRAINT product_series_fk_product_category FOREIGN KEY (product_category_id) REFERENCES "product_categories" (id));

create table "products" (id int4, model varchar(256),
...
product_series_id int4,
...
CONSTRAINT products_fk_product_series FOREIGN KEY (product_series_id) REFERENCES "product_series" (id));


Запутали меня, т.к.:
1) Вендор это производитель? (Можно конечно Brand заменить на Vendor)
2) Product - это то (имхо), что производят и продают. В контексте моей задачи (сервис по ремонту и обслуживанию) СВТ является не продуктом, а средством вычислительной техники. Если бы я магазин компьютерный описывал - возможно я бы выбрал продукт вместо СВТ.
3) Product_categories. Не совсем понятно. Если имеется ввиду категория СВТ (Монитор, принтер, сканер) - то отлично. Мне не нравится сущность СВТ_Класс (многозадачная трактовка - действительно.
Если же имеется в виду что-то другое - подскажите пожалуйста.
4) Product_series. Если имеется ввиду, к примеру, телевизор Самсунг 5й серии, то если нам нужна задача как можно проще - тогда серию нужно держать просто текстовым полем в таблице Product_model.
Если под серией Вы имеете ввиду модель продукта, тогда лучше её моделью и назвать.
5) Если "4" не вариант "б" - тогда где Product_Model. Хотя по ФК в таблице видна связь и аналогия с Моделью.

guest_20040621> Существует Брэнд (LG,Samsung, IBM)
> Существует Класс который выпускает много моделей СВТ
Старайтесь не использовать понятий с многозначной трактовкой. Есть конкретная лавка. У это конкретной лавки есть позиционируемое имя (как правило, простое), которое часто является зарегистрированной торговой маркой. Причем, для разных стран и языков эта торговая марка может представлять собой разное сочетание символов. Вообще говоря, то же самое справедливо и для продуктовых линеек, и для моделей.

Ну я и говорю - Vendor вместо Brand мне нравится. Я просто сам не допер более верное название этой сущности - vendor.
А вот Product лучше заменить на СВТ (в моём случае).

guest_20040621> у одной и той же задачи есть 2 совершенно разных схемы данных?
Гораздо больше, чем две. Для вашей задачи можно не напрягаясь придумать десяток. В данном случае критерий - как можно проще.
Ну тут я бессилен :)
Я вижу только одно решение применительно к моей задаче - это именно так, как я показал на последнем скрине. Правда нормализация таблицы svt_class (как по картинке) я бы расширил на таблицу svt_class_type (ЖК/ЭЛТ для мониторов, Лазерный/Струйный/Матричный для принтеров и т.п.) - но тут опять:
1) многозначная трактовка type
2) не смог самостоятельно нормализовать по аналогии с model, к которой связи идут от class и brand.
У меня получается М:М. Не знаю какую промежуточную сущность придумать.
Нарисуйте если не сложно коротенькую схему того - что Вы имеете ввиду.
Я вчера в ПХП форму заполнения справочника категорий СВТ сделал. Сейчас буду делать аналогичную форму для вендоров.
А так же буду делать форму с полями списков (вендор и категория) и с полем ввода названия модели. Пошел делать - жду ответа с нетерпением!

guest_20040621> Вендор это производитель?
Э... вообще как бы не совсем. Вендор - это лавка, под именем которой девайс продается. Вообще четкого разделения понятий я не встречал, но сам использовал термин в такой интерпретации. Можно написать "компания" или "организация", - поскольку дополнительных требований, расширяющих функционал, нет, ролей нет, то это не принципиально.
Блин. Я уже не дожидаясь ответа переименовал все свои записи в файлах ПХП с Brand на Vendor :) В принципе можно find & replase в дримвьювере так же заменить на другое название, но уже не хочется кучу кода пересматривать.
Вот же гадость - работаю 10 лет в обслуживании и ремонте СВТ, а так и не разделяю этих понятий :)
Хотя если подумать - вендор это производитель микросхемы на видеокарте, а видеокарта может быть как раз под брэндом совершенно другого производителя. Верно?
Пример: Видеокарты Asus но на чипсете nVidia. Вендор - nVidia. Как тогда назвать Asus?

guest_20040621> СВТ является не продуктом, а средством вычислительной техники
;) Совершенно обычный продукт. Ну да, внутри есть процессор, так сейчас и в холодильниках, и в стиральных машинах процессоры и операционные системы появились, но их как-то никто не называет вычислительной техникой.
Вы вырезаете из контекста мои слова. Я сказал, что применительно к моей работе и моему проекту больше подойдет СВТ, т.к. работа моя заключается в обслуживании и ремонте средств вычислительной техники и сетей передачи данных.
Не могу же я обслуживать продукт - хотя ПК несомненно является продуктом производства и предложения определенного производителя. Мы обслуживаем вычислительные средства.

guest_20040621> Правда нормализация таблицы svt_class (как по картинке) я бы расширил на таблицу svt_class_type (ЖК/ЭЛТ для
> мониторов, Лазерный/Струйный/Матричный для принтеров и т.п.)
Опять же предложу кривой, но простой вариант: связать характеристики с категорией продукта.


guest_20040621> Нарисуйте если не сложно коротенькую схему того - что Вы имеете ввиду.
Вы будете смеяться - нечем рисовать.
Вы так лихо набросали текст SQL запроса на построение таблиц.
Так же лихо можно и MySQL WorkBanch слить и установить. Вообще классная штуковина :)
Но мы то не наглые - не настаиваем :)

БредятинаВы же не нарисовали на ура на листочке с описанием связи глаголами:)
Почему же? Я рисовал. И второй Аттач вначале темы (во втором посте) показывает то, как я это представляю с глаголами :)
Я же говорю - одно дело нарисовать схему, а совсем другое её додумать для реализации. К примеру, нормализации таблицы СВТ казалось достаточно если все атрибуты будут браться из соответствующих таблиц, но одна таблица оказалась составной (Модель) и вот это при создании схемы сложно учесть. Хотя я пытался учесть, но не мог представить как это будет выглядеть в реализации.
БредятинаТогда бы Вы поняли, возможно, что в РМД (которую Вы используете) принципиально нет никаких связей. А есть ограничения целостности. Ключи - это органичения целостности (именно в РМД), и не имеют к связям между объектами абсолютно никакого отношения. Как и к проектированию БД. Тем не менее Вам постепенно удалось прийти к нормальному варианту решения:)
В контексте обсуждения данной темы и при более детальном освоении Mysql workbanck я это допетрил наконец-то. Этому же в принципе и Access учит, т.к. нельзя просто перетащить ФК в другую таблицу - необходимо перед этим создать ключ с идентичным названием и свойствами в другой таблице.
А вот ER Win меня и сбил с пути вместе с преподавателем. Там можно перетащить ключ не создавая аналогичный и связь образуется. Из-за этого многие вообще не понимают механизма, который и я доселе не понимал. Кстати тему долго думал как назвать - по моему я угадал с названием.
Хорошо, что Вы меня окончательно убедили в том, что я допетрил верно (надеюсь).

БредятинаМожно еще использовать избыточные связи (денорамализация) СВТ с Типом и Моделью:
Почему-то думал, что нормализация это и есть стремление к избыточности, а Денормализация - убирать лишнюю избыточность.
Где я не прав подскажите пожалуйста..
БредятинаСВТ<--Имеет/Относится к--Продукт
СВТ<--Имеет/Для--Тип [денормализация]
СВТ<--Имеет/Для--Модель [денормализация]
Модель<--Относится к/Имеет--Тип
Продукт<--Производится/Производит--Производитель
Продукт<--Имеет/Относится к--Модель
Никогда не мог читать данный синтаксис и подобные конструкции. Очень нравится визуальная реализация подобного. Уже 21 век вроде бы настал давно, а мы всё в коммандной строке. Меня конечно подвела тяга к всему визуальному (я про ER Win) - но для наглядности и простоты понимания уж очень хорошо подходит.

БредятинаЗдесь, на всякий случай, полагается, что модель может производиться разными производителями (может быть полезно добавить "конструкторское бюро":)).
:) Нееее... Мне ТЗ тогда 2 года придется писать. У меня простое казалось бы ТЗ - не хочу его усложнять до нельзя и ничего в результате не реализовать, а если реализуешь - никому не нужно будет, т.к. такого класса продукты уже есть у нормальных производителей.

Подскажите пожалуйста, почему мне с таким кодом создаются таблицы MyISAM, при том, что я (как видно из кода) указываю InnoDB ??

andy.s, Действительно :)
Переменные Мускула:
storage engine MyISAM
have innodb DISABLED
have isam NO
table type MyISAM
Блин, а я и не думал, что в Денвере отключена ИнноДБ.
Я читал на форумах, что Форент Кейсы не работали в Мускуле до версии 5, но и там надо использовать ИнноДБ для их работы. Верно? Щас пойду пробовать включать InnoDB в Денвере.

А краеугольным камнем моего непонимания принципа функционирования связей в реляционных БД оказалось то, что я думал, что если в таблице присутствует FK другой таблицы, то просто обратившись к ней за нужным полем можно его данные загрузить в поле FK ,хотя как, если нужно текстовое поле а FK (int) ? :)
Только при реализации вчера базы данных по своей схеме данных я понял, что для загрузки нужных данных из другой таблицы - нужно в основной таблице помимо FK поля создать ещё и аналогичное нужному тебе полю. В моём коде создания таблиц при создании таблицы svt_model_name я вчера добавил ещё 2 поля svt_model_category и svt_model_brand - вот так:
Вот теперь я счастлив - я наконец-то понял БД :)

У меня форма ввода новой модели.
В таблице модели если не завести эти 2 поля - невозможно будет поместить данные текстовые - чтобы потом таблица читалась нормально, по типу:
1 2 3 4
|--|---------|--------|-------|
|1.| Монитор| LG | F700P |
|--|---------|--------|-------|
|2.| Принтер | Epson | F700P |
|--|---------|--------|-------|

Поля прежней таблицы были:
1 - svt_model_id
2 - (fk)svt_category_id
3 - (fk)svt_brand_id
4 - svt_model_name

и что в таком случае бы отображалось и как реализовать тогда? Я этого и не мог понять. И теперь опять с толку сбит.

П-ЛТС: у вас полная каша в голове.
Возьмите аксес, который прост, как сапог и сделайте в нем свою звезду или снежинку с помощью его мастеров и визардов. В таблицах используйте ТОЛЬКО обычные поля без комбо с подстановками. На формах евойные мастера сделают вам красивый вывод текстового поля из справочника при том, что храниться будет именно целый код. Делов на полчаса тыканья мышкой.
Взял. Уже не раз к нему прибегал. Именно пол часа в Акцессе набросал то, что показываю на скрине.
Заполняю сначала справочники категорий и производителей. Там проблем не возникает, т.к. одна форма на одну таблицу.
Создаю форму модели мастером, где указываю все поля из всех таблиц для простоты дальнейшего редактирования формы конструктором. Далее удаляю все лишние появившиеся на форме поля и оставляю только поле для ввода модели. Добавляю 2 поля со списком производителей и категорий.
И вот тут возможно есть вся загвоздка, которую я не пойму.
При создании поля со списком вылезает мастер, который говорит что делать: комбо бокс уже с фиксированными значениями или из таблицы брать данные. Конечно из таблицы.
Далее указываем таблицу svt_brand и из неё тоже все поля (хотя нужно только svt_brand_name). Потом выбираем сортировку по имени.
А вот ключевой вопрос - где будем сохранять? Пробовал всё что можно - результат или ошибки - или на картинке.

БредятинаВы на правильном пути:) Теперь ответьте себе на вопрос: а что делать, если в Вашей "таблице" нужно отобразить ТРИ характеристики ("поля") из объекта svt_caterory и ЧЕТЫРЕ из svt_brand (в частности, когда будете пользоваться access, как Вам посоветовали)? Вы поместите эти поля в Вашу таблицу? Вот это и есть денормализация. Но это, вероятно, не будет считаться денормализацией, если значения этих полей будут вычисляемыми (то есть, не будут храниться в БД).
Про понятие денормализации - спасибо. Теперь я понял это. Про подумать как и что делать - выше ответил - не пойму и всё :(

ViPRosБредятина, неужто сложно сказать чеку, что храним одно, а показываем другое? что это разные модели?
уууууу преподы :)
Ну можно снизойти до нас стрёмных и показать на пальцах.
Я со своей стороны могу записать видеоролик спец-программкой, как и что я делаю - а Вы скажете - где ошибка.
Я вроде не ленивый - делать хочу и делаю - за себя ничего делать не прошу - прошу помочь понять.