ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объясните грамотно почему это не правильно.
25 сообщений из 51, страница 1 из 3
  1  все
Объясните грамотно почему это не правильно.
    #35408812
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
Кого не затруднит привести грамотные аргументы почему данная схема не правльная?
...
Рейтинг: 0 / 0
03.07.2008, 13:50
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35408921
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
что это?
...
Рейтинг: 0 / 0
03.07.2008, 14:22
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35408951
Алексей Р.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Р.
Участник
Предположу, что схема не реляционна, есть лишняя (избыточная) связь.
(Если я правильно понимаю "реляционность").
...
Рейтинг: 0 / 0
03.07.2008, 14:32
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35408978
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
Это схема
база проверок врачей (но в принципе это не важно), мне нужен аргумент почему это не правильно.
слева три таблицы , для произвольного количества различный атрибутов по объектам
1) справочник объектов (проверка квалификации, опоздания, жлобы больных). 2) справочник атрибутов (прошёл повышение квалификации, не опаздывает, правильно заполняет карточки) 3) связующий справочник - какие атрибуты какому объекту принадлежат. Справа сами проверки и результаты....
Тут упрощено, но сам подход ясен. Почему он не правильный? Пожалуйста заумные, грамотные фразы
...
Рейтинг: 0 / 0
03.07.2008, 14:39
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409682
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
Хм...
Повторю вопрос: ой, что это???

Что за нотация, почему не знаю?
IDEF1X (Традиционная) ? - нет
EER ? - нет
EER(1,n) ? - нет
Вороньи лапки ? - нет

Дык, что это?
...
Рейтинг: 0 / 0
03.07.2008, 17:18
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409701
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
Ааа.. тогда это - сам подход, наброски так сказать, которые можно оформлять хоть в еер хоть в лапки. А что пока не оформлю правильно по какомунить стандарту, смысл никак не уловить? :)
...
Рейтинг: 0 / 0
03.07.2008, 17:24
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409745
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
Если напрячь рассудок, и представить, что сия стрелка - реляция 1 ко многим, то получается что-то вроде:

Зачем такая конструкция, многоие к очень многим?
...
Рейтинг: 0 / 0
03.07.2008, 17:41
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409756
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
ах, так вы про стрелку.. да, да 1 ко многим.... Вы спрашиваете зачем, а спрашиваю чем это плохо.
...
Рейтинг: 0 / 0
03.07.2008, 17:45
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409779
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
Только "кольцевая" связь замыкается на табла01 1:М табла04. Пятая не входит.
...
Рейтинг: 0 / 0
03.07.2008, 17:49
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409787
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
Cheerful Calfах, так вы про стрелку.. да, да 1 ко многим.... Вы спрашиваете зачем, а спрашиваю чем это плохо.

Я просто "на пальцах" или "сырмяжно" пытаюсь растолковать про нормальные формы...
...
Рейтинг: 0 / 0
03.07.2008, 17:52
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409795
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
ах вы про НФ... А других аргументов (кроме того что классика это правильно, потому что она правильная) не будет?
...
Рейтинг: 0 / 0
03.07.2008, 17:55
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409840
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
Cheerful Calfах вы про НФ... А других аргументов (кроме того что классика это правильно, потому что она правильная) не будет?

Отчего-ж? Говорят англичане научились гланды через жопу вырезать:)
...
Рейтинг: 0 / 0
03.07.2008, 18:03
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35409990
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
nik_xЕсли напрячь рассудок, и представить, что сия стрелка - реляция 1 ко многим,

Реляция - это таблица. А что вы имеете в виду - ссылка. Foreign key.

С чего вы решили, что схема неправильная ? И к тому же надо знать постановку задачи, чтобы сказать, правильная она или нет. А мы ее не знаем. Никаких явных ляпов здесь вроде бы нет. Можно было бы иметь еще словарь проверяющих и проверяемых, лучше в одной таблице людей, возможно с ролями, поскольку наверняка проверяющих тоже проверяют, и они становятся проверяемыми, хотя точно это знаете только вы сами.
...
Рейтинг: 0 / 0
03.07.2008, 19:02
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410224
Чорный Бада
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чорный Бада
Участник
Если я правильно понимаю тут что-то типа EAV.

По своему печальному опыту - EAV, это, пардон, гамно. Как правильно подобные суперабстрактные и, типа, универсальные модели возникают от (нужное подчеркнуть) нежелания/неумения/невозможности достаточно разобраться в предметной области и разумно определить скоуп проекта. Типа, отличная идея - слепить БД, в которую запихнуть можно всё что угодно. Слепить можно. Работать потом правда с ней нереально.
...
Рейтинг: 0 / 0
03.07.2008, 21:56
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410324
Формально
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Формально
Гость
возражений нет, работать будет. А по сути - говно, а не схема.
...
Рейтинг: 0 / 0
03.07.2008, 23:15
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410405
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Чорный БадаЕсли я правильно понимаю тут что-то типа EAV
Неправильно понимаете. Hint: попробуйте найти в нарисованном поля "тип значения атрибута", "значение атрибута"...

Безусловно, со временем может вырасти в EAV. Но пока к тому никаких продвижений не видно. Если бы вместо "атрибут" автор употребил слово "критерий", подозреваю, никто и не шелохнулся бы.
...
Рейтинг: 0 / 0
04.07.2008, 01:00
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410410
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Cheerful CalfКого не затруднит привести грамотные аргументы почему данная схема не правльная?
1. Главный недостаток - в "проверке" фактически теряется информация о проверяемом. "Имя проверяемого" - это не информация, это дерьмо. Проверяемые, как впрочем и проверяющие - это справочник. Который будет активно обрастать атрибутами и связями, например "какого человека какой проверке как часто подвергать".

2. Развязка "многие ко многим" между объектами и атрибутами лишняя. Обычное один ко многим будет куда уместнее. Кроме того, если ты будешь утверждать, что атрибуты различных проверок нередко совпадают, я скажу, что поле "частота проверок в месяц" становится совершенно бредовым.

3. Cхема не поддерживает целостность данных. Так, как нарисовано, "результат проверки" может ссылаться на атрибут объекта1 и проверку объекта2, что явно некорректно.

4. Сущности неудачно названы. Если взять случайного разработчика и сказать: "в схеме есть сущности "проверки" и "объекты проверок". как ты думаешь, в чем их смысл и чем они различаются", мало кто угадает придуманное Вами :) Я бы предложил, например, "Варианты проверок", "Проверяемые критерии", "Факты проверок", "Результаты проверок".

5. У факта проверки напрашивается поле со смыслом "статус". Сейчас, скажем, может быть так, что по какому-то атрибуту нет результата проверки, и непонятно - то ли это означает "нет без комментариев", то ли ошибку, то ли просто данные в процессе ввода.
...
Рейтинг: 0 / 0
04.07.2008, 01:17
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410412
Чорный Бада
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чорный Бада
Участник
softwarerНеправильно понимаете. Hint: попробуйте найти в нарисованном поля "тип значения атрибута", "значение атрибута"...
Ну почему же. Для каждого обьекта проверки имеется несколько проверок. Каждая проверка заключается в проверке некоторого критерия на "да/нет". Атрибут - это проверяемый в проверке критерий. Его значение - "да" или "нет".
...
Рейтинг: 0 / 0
04.07.2008, 01:25
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410419
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Чорный БадаНу почему же.
Потому что сходство формальное, но не фактическое. Такими рассуждениями можно что угодно объявить EAV, например оценки, полученные студентами за экзамены (а что? экзамены - это справочник атрибутов; курсы - это классы; студенты - это объекты; оценки за экзамены - значения атрибутов).

Ключевое отличие EAV от "обычных схем" в том, что в одно поле укладываются разные с точки зрения бизнес-логики значения. В том, что в поле NUM_VALUE может лежать как "расстояние от Земли до Луны", так и "количество листов в тетради". Это не достаточное условие, но необходимое. В данной схеме это необходимое условие не выполняется (по крайней мере, нет признаков того, что выполняется). Критерии - это критерии и есть, справочник. Дальше - проверяющий ставит галочку и может быть пишет примечания, вот и вся бизнес-логика.
...
Рейтинг: 0 / 0
04.07.2008, 01:45
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410424
Чорный Бада
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чорный Бада
Участник
softwarerКлючевое отличие EAV от "обычных схем" в том, что в одно поле укладываются разные с точки зрения бизнес-логики значения. В том, что в поле NUM_VALUE может лежать как "расстояние от Земли до Луны", так и "количество листов в тетради".
Тут я полностью согласен. И вот тогда наступает ЖОПА
...
Рейтинг: 0 / 0
04.07.2008, 01:48
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410426
Чорный Бада
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чорный Бада
Участник
В первом приближении у меня получилось бы что-то вроде этого:
...
Рейтинг: 0 / 0
04.07.2008, 01:49
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410435
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Чорный БадаВ первом приближении у меня получилось бы что-то вроде этого:
В первом приближении у меня получилось бы что-то вроде этого:

Код: 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.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
SQL> create table CheckCase (CheckCaseID integer not null primary key);

Table created

SQL> create table CheckMeasure (
   2     CheckMeasureID integer not null primary key,
   3     CheckCaseID integer not null references CheckCase (CheckCaseID),
   4     MeasureName varchar2( 100 ) not null,
   5     Description clob);

Table created

SQL> alter table CheckMeasure add unique (CheckMeasureID, CheckCaseID);

Table altered

SQL> create table Person (
   2     PersonID integer not null primary key,
   3     PersonName varchar2( 100 ) not null unique);

Table created

SQL> create table CheckEvent (
   2     CheckEventID integer not null primary key,
   3     CheckCaseID integer not null references CheckCase (CheckCaseID),
   4     PersonID_Checked integer not null references Person (PersonID),
   5     EventDate date not null,
   6     Description clob);

Table created

SQL> alter table CheckEvent add unique (CheckEventID, CheckCaseID);

Table altered

SQL> create table CheckResult (
   2     CheckResultID integer not null primary key,
   3     CheckCaseID integer not null,
   4     CheckEventID integer not null,
   5     CheckMeasureID integer not null,
   6     PersonID_Checking integer not null references Person (PersonID),
   7     Score char( 1 ) not null check (Score in ('Y', 'N')),
   8     Notes clob);

Table created

SQL> alter table CheckResult add foreign key (CheckMeasureID, CheckCaseID)
   2     references CheckMeasure (CheckMeasureID, CheckCaseID);

Table altered

SQL> alter table CheckResult add foreign key (CheckEventID, CheckCaseID)
   2     references CheckEvent (CheckEventID, CheckCaseID);

Table altered
...
Рейтинг: 0 / 0
04.07.2008, 02:11
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410448
Чорный Бада
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Чорный Бада
Участник
softwarerВ первом приближении у меня получилось бы что-то вроде этого

1) Не очень понятно назначение таблицы CheckCase.

2) вот это ещё мне не очень:
Код: plaintext
1.
2.
create table CheckMeasure (
    CheckMeasureID integer not null primary key,
    CheckCaseID integer not null references CheckCase (CheckCaseID),
и одновременно тут же
Код: plaintext
alter table CheckMeasure add unique (CheckMeasureID, CheckCaseID);
Если тут имеется в виду идентифицирующая связка, то не разумней ли сразу первичным ключом сделать (CheckCaseID, CheckMeasureID)?
...
Рейтинг: 0 / 0
04.07.2008, 02:56
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410456
сосед. был акцессник. теперь неи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
сосед. был акцессник. теперь неи
Гость
2 softwarer +0.75 с уточнениями

П1 - Указанный вами пункт 1 не является главным недостатком предложенной схемы.
Т.к. в схеме просто нет сущностей «проверяющий» и «проверяемый» и нет ясного понимания причины их отсутствия, то нет и оснований для выставления этого момента на первое место. Такое его творческое видение предмета, что «проверяемые» с «проверяющими» вовсе не сущности, а просто атрибуты. Составит это проблему для его задачи или нет – предмет правдоподобного, но домысливания.
К недостаткам предложенной схемы это относимо с натяжкой.
Тем более, что превращение их в сущности не составляет формальной проблемы в предложенной схеме.

П2 про излишество N-N – по существу – почти наверно - да.
N-N может оказаться практически неприемлемым при переименовании атрибутов. Но может и не оказаться.

П3. В предложенной схеме это главный недостаток.
Может быть компенсирован
- либо организацией интерфейса пользователя ( не гарантирует от ошибок программиста и администратора БД)
- либо организацией нетривиальных условий проверки целостности c использованием check constraint (если выбранная субд сможет их поддержать) или триггеров ( с тем же условием.).

Либо изменением характера связей между сущностями и перепроектированием сущности [Результаты_проверки].

Так, если изменить связи между [Объекты_проверок] и [Проверки]
И между [Объекты_проверок] и [Справочник_атрибутов_по_объектам]
С неидентифицирующих на идентифицирующие, то использованные в схеме сущности
более-менее естественным образом можно представить так;


[Объекты_Проверок](АйДи, прочие_атрибуты)
PK(АйДи)

[Справочник_Атрибутов](PK,АйДи, прочие_атрибуты)
PK(PK,АйДи)
FK(АйДи) REFERENCES [Объекты_Проверок](АйДи)

[Проверки](PK,АйДи, прочие_атрибуты)
PK(PK,АйДи)
FK(АйДи) REFERENCES [Объекты_Проверок] (АйДи)


[Результаты_проверок](PK,PK_П,АйДи,PK_А, прочие_атрибуты)
PK(PK,PK_П,АйДи)
FK(PK_П,АйДи) REFERENCES [Проверки](PK,АйДи)
FK(PK_А,АйДи) REFERENCES [Справочник_Атрибутов](PK,АйДи)

Использованный переход с идентифицирующим зависимостям позволит явно указать дерево зависимости сущностей - [Справочник_Атрибутов] оказывается явным образом ведомым для сущности [Объекты_Проверок], а [Результаты_проверок] явным образом ведомая для сущности [Проверки]. Дополнительно, такой вариант оформления сущности
[Результаты_проверки] автоматически не даст возможности допустить ошибку связывания строки проверки с атрибутом чужого проверяемого объекта без использования как heck constraint, так и триггеров.
П3 – ключевой в рамках предложенной схемы (если принять характер связей как адекватный предметной области – независимо от справедливости такого принятия, то проблема именно в сущности [Результаты_проверки]).


П4 – вопрос вкуса/стиля

П5 – домысливание задачи за пределы предложенной для выявления недостатков схемы.
...
Рейтинг: 0 / 0
04.07.2008, 03:47
| Ответить | Цитировать | Написать  
Объясните грамотно почему это не правильно.
    #35410802
Фотография Cheerful Calf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cheerful Calf
Участник
2 Чорный Бада
Это не Тенцер. Им тут и не пахнет. Хотя на первый взгляд сходство с неким подобием модели еав есть.

2 softwarer | сосед. был акцессник. теперь неи

1) Cущность «проверяющий» возможно будет, в данной схеме её не составит труда добавить. Но пока она не на первом месте, это скорее действительно атрибут проверки. В общих чертах, чтобы удовлетворить главное требование заказчика (а это гос. учереждение) - то сущность может быть вообще всего одна - Проверка. Всё остальное пофигу. Главное - была ли проверка, что проверили и соответсвовало ли это некоим подтверждённым требованиям... (утрированно)

2) Ага. Спасибо, доктор, пожалуй именно это меня и беспокоило... Связи М:М тут действительно надо переделывать.

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

4) Наименования из картинки (типа АйДи русскими буквами) в базе не будет :)

5) "может быть так, что по какому-то атрибуту нет результата проверки" - исключено
...
Рейтинг: 0 / 0
04.07.2008, 10:21
| Ответить | Цитировать | Написать  
25 сообщений из 51, страница 1 из 3
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объясните грамотно почему это не правильно.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=101&tid=1543754]:
 0ms
get settings:
 7ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 61ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 207ms
total:  374ms
созд. / загр.: 374ms
x
x
Закрыть


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