powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Интересные модели БД!
25 сообщений из 188, страница 1 из 8
Интересные модели БД!
    #35712617
junior_oracle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Друзья! Я интересуюсь моделированием БД. Если вам не жалко своих моделей (схем) БД, и они не являются коммерческой или иной тайной, выкладывайте, предметная область не важна.
Спасибо!
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35715399
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junior_oracleЕсли вам не жалко своих моделей (схем) БД, и они не являются коммерческой или иной тайной, выкладывайте, предметная область не важна .

Очень интересная тема. А особенно про ПРЕДМЕТНУЮ ОБЛАСТЬ. Вам картинок хотелось? - их есть у меня...©

Но они ВСЕ - по разным предметным областям, ничего, Коллега?
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35715944
Фёдоров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2junior_oracle

Будьте осторожны, довольно много абсолютно неграмотных моделей. Как например, вот эта, с таблицами Cars_for_Sale и Cars_Sold

http://www.databaseanswers.org/data_models/car_sales/index.htm
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35716306
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Фёдоровмного абсолютно неграмотных моделей. Как например, вот эта

http://www.databaseanswers.org/data_models/car_sales/index.htm

и в чем ее абсолютная неграмотность?
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717086
LUCIAN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Для я задачи учёт материальных ценностей на складах
цехах и материально-отв лицах использую следующую модель БД:

имеется справочник контрагентов следующей структуры

СТРУКТУРА SP_AG-справочник контрагентов

Код: plaintext
1.
2.
3.
4.
5.
ID_AGN I( 4 , 0 ) идентификатор контрагента
NAM C( 40 , 0 ) наименование контрагента
K_POST N( 4 , 0 ) код поставщика,покупателя
K_CEX N( 3 , 0 ) код цеха
TAB_N N( 8 , 0 ) табельный №
K_IZD N( 4 , 0 ) код изделия

В этом справочнике поле ID_AGN - идентификатор контрагента
формируется автоматечески. Если контрагент явл. материально-отв лицом,
то поле TAB_N принимает значение табельного № этого лица,а поля
K_POST,K_CEX,K_IZD принимают значение 0,аналогично для других типов контрагента
Этот справочник ежедневно обновляется за счет НСИ из других БД.

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

СТРУКТУРА DOK-шапка документа

Код: plaintext
1.
2.
3.
4.
5.
6.
ID_DOK I( 4 , 0 ) идентификатор документа
D_DOK D( 8 , 0 ) дата документа
OTP I( 4 , 0 ) идентификатор отправителя
POL I( 4 , 0 ) идентификатор получателя
K_DOK C( 3 , 0 ) код документа
N_DOK C( 10 , 0 ) № документа
SUMA N( 18 , 2 ) сумма документа


СТРУКТУРА DOKS-детальные строки документа

Код: plaintext
1.
2.
3.
4.
5.
6.
ID_STR I( 4 , 0 ) идентификатор детальной строки документа
ID_TOV I( 4 , 0 ) идентификатор товара,материала
CENA N( 16 , 8 ) цена товара
KOL N( 15 , 3 ) количество
SUMA N( 18 , 2 ) сумма товара
ID_DOK I( 4 , 0 ) идентификатор документа

При такой организации БД поступление мат.ценности от поставщика на предприятие
в табл.DOK отразится следующим образом:поле OTP -идентификатор поставщика,
POL-идентификатор склада,а расход мат.ценности на производство продукции отразится так:OTP -идентификатор цеха,POL-идентификатор изделия.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717334
KOT MATPOCKuH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LUCIAN
При такой организации БД поступление мат.ценности от поставщика на предприятие
в табл.DOK отразится следующим образом...
Это только в том случае, если в таблице
Код: plaintext
DOK-шапка документа
в поле
Код: plaintext
K_DOK C( 3 , 0 ) код документа
стоит некий код, обозначающий приходную накладную.
Не путать с расходной накладной, счетом, возвратной поставщику и еще несколькими десятками других документов.
В связи только с этим комментарием ответте сами - правильная Ваша структура или нет
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717339
junior_oracle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо, начнем смотреть)
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717360
junior_oracle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mr Marmelad,

ничего, нормально), сенкс!
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717650
LUCIAN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
KOT MATPOCKuH
Это только в том случае, если в таблице
Код: plaintext
DOK-шапка документа
в поле
Код: plaintext
K_DOK C( 3 , 0 ) код документа
стоит некий код, обозначающий приходную накладную.
Не путать с расходной накладной, счетом, возвратной поставщику и еще несколькими десятками других документов.
В связи только с этим комментарием ответте сами - правильная Ваша структура или нет
Если она работает уже около 5 лет ,то почему она может быть неправильной.
Типы всевозможных документов следующие:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
K_dok     Naimdok                                                Sxema          
 7        АКТ НА СПИСАНИЕ ИНВЕНТ.(С М/О  ЛИЦА)     МОЛ ==>   0 
 8        АКТ НА СПИСАНИЕ (УБЫЛЬ)                        СКЛАД  ==>   0 
 9        АКТ НА СПИСАНИЕ (НЕДОСТАЧА)                 СКЛАД ==>   0 
 10      АКТ НА ПЕРЕДАЧУ ДРУГОМУ М/О   ЛИЦУ       МОЛ==>МОЛ
 11      АКТ НА СПИСАНИЕ                                     СКЛАД      ==>  0 
 12      АКТ НА СПИСАНИЕ (УБЫЛЬ)                        СКЛАД  ==>   0 
 13      АКТ НА СПИСАНИЕ (НЕДОСТАЧА)                 СКЛАД  ==>   0 
 18      АКТ НА ОПРИХОДОВАНИЕ ИЗЛИШКОВ             0  ==>СКЛАД
 22      ЛИМИТНО-ЗАБОРНАЯ КАРТА                        СКЛАД ==> ЦЕХ
 50      Т.Т.Н. (ПРОДАЖА)                                     СКЛАД==> ПАРТНЕР
 53     Т.Т.Н. (ПОКУПКА)                                        ПАРТНЕР==>СКЛАД
 59     ТРЕБОВАНИЕ-НАКЛАДНАЯ(СО СКЛАДА)           СКЛАД ==>  ЦЕХ
 60     ТРЕБОВАНИЕ-НАКЛАДНАЯ (ПРОДАЖА)            СКЛАД ==> ПАРТНЕР
 61     ТРЕБ.-НАКЛАДНАЯ(СО СКЛАДА НА   СКЛАД)    СКЛАД ==>СКЛАД
 62     ТРЕБОВАНИЕ-НАКЛАДНАЯ(НА СКЛАД)            ЦЕХ ==> СКЛАД
 64     ТРЕБОВАНИЕ-НАКЛАДНАЯ (ПОКУПКА)              0   ==>СКЛАД
 93     ВВОД ОСТАТКОВ ПО МАТЕРИАЛЬНО  ОТВ.Л.     0   ==> МОЛ
 99     ВВОД ОСТАТКОВ ПО СКЛАДУ      (КУПЛЕНО)    0   ==> СКЛАД
 159   ТРЕБОВАНИЕ-НАКЛАДНАЯ(СО СКЛАДА)          СКЛАД ==>  ЦЕХ
 101   Отчёт о расходе мат.ценн. цеха                   Цех ==>  Изделие
 199   ВВОД ОСТАТКОВ ПО ЦЕХУ                             0  ==> ЦЕХ

...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717706
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> и в чем ее абсолютная неграмотность?

Вы не видите? Открываете страницу, две первые таблицы: Addresses и Customers. Все, дальше можно не смотреть. Типичная одноразовая поделка.

И чувак по имени Barry Williams ни разу не стесняется подписываться Principal Consultant. Криворукие китайские первоклассники - гуру по сравнению с Барри.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717735
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621

Вы не видите? Открываете страницу, две первые таблицы: Addresses и Customers. Все, дальше можно не смотреть.

А Вы и есть Федоров Richmond VA?

для случая когда у одного Кастомера может быть несколько Адресов такая схема вполне применима
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717835
Фёдоров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
proposed amendmentguest_20040621

Вы не видите? Открываете страницу, две первые таблицы: Addresses и Customers. Все, дальше можно не смотреть.

А Вы и есть Федоров Richmond VA?

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

Она применима, но она не правильная. Если следовать логике автора, предложившего таблицы Cars_for_Sale и Cars_Sold, то тогда нужна ещё, как минимум, одна - Cars_Returned. Можно создать ещё 3 таких же для подержанных машин. Нет предела фантазии.

guest_20040621 разбирается в этом деле лучше меня
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717894
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ФёдоровБудьте осторожны, довольно много абсолютно неграмотных моделей. Как например, вот эта, с таблицами Cars_for_Sale и Cars_Sold

Ув. Коллега Фёдоров. В Ричмонде, штат Вирджиния пожалуй как нигде в мире должно быть известно что:
1. Остерегаться абсолютно нечего - то что существует срок жизни того или иного продукта - это нормальное явление.
2. Мы не стоИм на месте - Всё течёт Всё изменя
3. Грамотность не определяется умением не делать ошибок (я их кстати так и не заметил)
4. Моделей абсолютно неграмотных не бывает - все они относительно грамотные.

Дело в том что моделирование само по себе весьма относительная вещь как и бизнес который модели описывают и все связанные с этим бизнесом науки. Я за "старый свет" не в ответе но Вам то в "Новом Свете" уж что что а ЭТО должно быть ясно как дважды два = четыре... :)
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717903
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junior_oracleMr Marmelad,

ничего, нормально), сенкс!

Any time ( you are most welcome!)
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717915
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Фёдоровguest_20040621 разбирается в этом деле лучше меня

Без комментариев...
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717942
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> для случая когда у одного Кастомера может быть несколько Адресов такая схема вполне
> применима

Вы напрасно получаете деньги за проектирование баз данных.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717960
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ФёдоровОна применима, но она не правильная.
Правильность той или иной модели не определяется одним предложением или даже попыткой найти в ней недостающие или избыточные величины (сущности - атрибуты). Моделирование - это ИСКУССТВО. Никак не наука. Попробуйте объяснить правильность " Красного Квадрата " или " Чёрного Квадрата " Малевича. А тем более повестить эти картины "неправильно".

Улавливаете иронию?... Коллега.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35717981
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Для чего нужна БД? Чтобы хранить данные. Если БД позволяет хранить данные, значит она правильная. Всё остальное - дополнительные условия. Соответствие дополнительным условиям не есть критерий правильности. Это только критерий того, что для ваших конкретных условий решение является приемлемым или нет.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718055
Фёдоров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
proposed amendmentguest_20040621

Вы не видите? Открываете страницу, две первые таблицы: Addresses и Customers. Все, дальше можно не смотреть.

А Вы и есть Федоров Richmond VA?

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

Супруги пришли покупать автомобиль. На двоих. Два имени и два адреса должны быть указаны в свидетельстве о собственности на машину. Так случилось, что адрес места проживания и у Маши Ивановой, и у Пети Иванова один и тот же. Сколько повторяющихся записей будет внесено в таблицу адресов? Правильно, два. С этим можно жить? Можно. Но, лучше, этого не делать.
Маша и Петя говорят, вы нам документы пришлите не на домашний адрес, а на абонентский ящик. Какой именно адрес будем сохранять в таблице, с учётом того, что машину, как только она прибудет с завода, надо подогнать им домой?

Вообще то, база данных автодилера гораздо сложнее. Они же ещё и запчасти продают. Как-то всё это оторвано от реальной жизни.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718070
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
proposed amendmentФёдоровмного абсолютно неграмотных моделей. Как например, вот эта

http://www.databaseanswers.org/data_models/car_sales/index.htm

и в чем ее абсолютная неграмотность?

Эту схему надо показывать студентам, как пример, как не надо писать БД.

Таблица Addresses

Зачем там поле address_ID? Это суррогатный ключ? Почему он ни где не участвует?
Ладно. Пусть предполагается, что у каждого из Customers, есть несколько адресов.
Что можно с ними сделать в этой базе? Ничего. Единственно, что на уровне клиента юзер может выбрать по каким-то неформализованым признаком нужный адрес, что бы доставить его в почтовое уведомление. Уволится такой грамотный юзер и все.

address_Line_1 - address_Line_4. Это из разряда юмора.
Единственное объяснение - в используемой базе данных слишком короткие строковые поля.

В поля town_city, state_country_province, country данные вбиваются вероятно ручками.

Поля, начинающиеся с other_, заканчивающимия Detail и Description - это вообще - песня.

Например. manufacturer_othe detail - eg. Ford, GM, Toyota.
Приходит новый работник и начинает набирать : Fort, JM, Taiota.

И так почти во всех таблицах.

Я, конечно, не лучший знаток машин, но даже я знаю, что модель должна соотноситься с маркой.

"Форд Калина", как-то не звучит. :)

Не берусь судить полную модель, так как не знаю этой модели бизнеса, но связи и таблицы очень странные.

========
Однако уверен, для гаража по торговле крадеными машинам с оборотом в 10 машин в год, такая база наверняка вполне подойдет.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718071
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ФёдоровОни же ещё и запчасти продают. Как-то всё это оторвано от реальной жизни.

Есть многое такое друг Горацио...
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718103
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
explaДля чего нужна БД? Чтобы хранить данные. Если БД позволяет хранить данные, значит она правильная. Всё остальное - дополнительные условия. Соответствие дополнительным условиям не есть критерий правильности. Это только критерий того, что для ваших конкретных условий решение является приемлемым или нет.

Все базы могут хранить данные. Следовательно все базы данных правильные.

Но некоторые их них не соответствуют реляционной модели, некоторые ненормализованы.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718105
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cat2 пишет:

> Эту схему надо показывать студентам, как пример, как не надо писать БД.

Ну ничего особенно страшного там нету, кроме 4-х addreddLine-ов
в адресе, да otherDetails (нарушение 1 нормальной формы )

> Зачем там поле address_ID? Это суррогатный ключ? Почему он ни где не
> участвует?

А где он должен участвовать ? У каждой таблицы должен быть какой-то PK.
Ну, можно было бы сделать составной, из кустомера и номера адреса.
Тогда нельзя повторно использовать адреса для разных кустомеров.

> Что можно с ними сделать в этой базе? Ничего.

Записать и прочитать. Послать по адресу письмо.

> address_Line_1 - address_Line_4. Это из разряда юмора.

Это - да . Плюс ещё же есть otherDetails ! В общем я тоже поржал.

> Я, конечно, не лучший знаток машин, но даже я знаю, что модель должна
> соотноситься с маркой.

Там странно, что есть выплаты кредитов и страховок. По идее, магазин
это интересовать не должно -- это платит сам клиент.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718110
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Фёдоровproposed amendmentguest_20040621

Вы не видите? Открываете страницу, две первые таблицы: Addresses и Customers. Все, дальше можно не смотреть.

А Вы и есть Федоров Richmond VA?

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

Супруги пришли покупать автомобиль. На двоих.
Такое наверняка должно быть. Анесколько адресов должны отличаться признаками.
Например, адрес для уведомления, адрес для доставки. Причем они могут совпадать. Не так уж трудно это завести в структуре базы.
...
Рейтинг: 0 / 0
Интересные модели БД!
    #35718113
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cat2,

Коллега Cat2 ну хоть вы наберитесь уважения и внимания к собранным годами системам. Поверьте - они не просто ТАК там живут. ЕСТЬ где то необходимость в той или иной аттрибутике. Она ВАМ не видна. Примите ЭТУ аксиому если не хватает Вам доказательств что там в искусстве ОШИБОК НЕТ и быть не может.

address_ID - ключ (правильно суррогатный) для обозначения уникальности записи. Не всегда удаётся адрес обозначить ДРУГИМ уникальным атрибутом. В Америке к промеру 123 Washington Street и Washington St, 123 и Wash. St - 123 могут обозначать как одну так и разные адреса. И ничего в этом такого нет что стоЯт они под уникальными айди 734, 823 и 1234.

Четыре Adress_Line - это скорее традиция и удобство чем что либо ещё.
Town_city - муниципалитеты
State_county_province - расчитаны на Англоязычников (USA, CA, AUS) потомков пилигримов и понятное дело к конкретно республикам - регионам или что там у вас никакого отношения не имеют.

Но поучиться у этих ребят британцев вам ой как следовало бы... Хотя бы терпимости к другому ПРАВИЛЬНОМУ мнению
...
Рейтинг: 0 / 0
25 сообщений из 188, страница 1 из 8
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Интересные модели БД!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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