Проблема, с которой вы сталкиваетесь, заключается в попытке принудительного размещения ваших классов OO в реляционной базе данных.
Если вы хотите мощь и гибкость реляционных баз данных;если вы хотите избежать «повторного факторинга» данных каждый раз, когда вы «повторно анализируете» свои классы, не делайте этого.
Забудьте о своих классах и смоделируйте данные как данные.Это не будет "сложно" или "сложно".Когда вы закончите, сопоставьте ваши классы с данными.
Если вам нужна дополнительная информация об абсурдности реализации классов OO в базе данных, прочитайте этот ответ , начиная с записи 11 Dec 10 .
Теперь, если вы сообщите нам, что ваши данные и как они связаны друг с другом, мы можем смоделировать их для вас.
Ответы на комментарии 27 декабря 10
Конечно.Забудьте пока таблицы и классы, просто подумайте о данных с точки зрения сущностей или вещей, существительных, которые могут относиться друг к другу.Не беспокойтесь об И / ИЛИ, это легко, если данные смоделированы правильно (и невозможно, если нет!).
1) Идентифицирует ли класс Qualification;Sector?И это не зависит от Enterprise?(Я так думаю, поэтому я смоделировал это.)
2) У вас есть имена вместо цифр для MinimumClass / Sector / Qualification?(Пожалуйста, перестаньте наклеивать столбцы Id на все, что движется: это серьезно затрудняет процесс моделирования; понимание данных.) Мне нужны примеры реальных данных: Sector;Qualification;Class.
3) Каждый из Class, Sector, Qualification существует сам по себе;например.Qualification существует только в контексте Sector?
Посмотрите на эту исходную диаграмму ▶ ER (стр. 1) ◀ (мы не готовы к модели данных.) (Встроенные ссылки не работают нанекоторые браузеры / версии.)
- У вас есть хорошее представление о том, что вы хотите;Я прошу вас отложить это в сторону и подумать только о данных и о том, как они связаны с другими данными
- Я подозреваю, что модель слева - это то, на что вы смотрели;это знакомо;но в одном месте происходит слишком многоЭто определенно не нормализовано, и это то, что мы должны исправить в первую очередь.
- Я думаю, что вы не можете иметь квалификацию без сектора.Правильно?
- Далее, Квалификация существует независимо от Класса
- Далее, Класс имеет набор Требований, который состоит из Квалификаций.Правильно?
- тогда мы можем думать о том, что такое класс;каковы эти требования;AND и OR.
1) Ссылка, конечно, дает квалификационные номера секторов, но это больше похоже на номера разделов глав, которые изменятся в следующем году.Я согласен с тем, что люди говорят о «квалификации Classe Une»;но я сомневаюсь, что люди на самом деле обсуждают «квалификацию 1,3».Я смоделировал это на основе того, что вы заявили, но если номера секторов / квалификаций нестабильны, вам лучше либо использовать приращение 10;или какой-либо другой номер или код, который что-то значит для вас, а не для внешнего мира. Имя - это значение, которое не изменится.
2) И / ИЛИ.В прошлом я использовал два метода, которые полезны здесь.Один был основан на серии BIT или BOOLEAN индикаторов, таких как IsOne и IsOneOfTwo;это было более полезно для вовлеченного кодирования;и были IsMandatory требования.
Для вас простой способ использования столбца Weight - это все, что вам нужно.Всего Weight из любого квалифицируемого набора для Class, в том же Sector* ( не общего Weight для Class, их может быть несколько наборов ) равных 1,0.Если Weight строки для Class в том же Sector меньше 1, вам нужно сохранять AND для других строк, чтобы получить полное значение Class.Это позволит вам иметь тройки в будущем.Я предоставил полный набор строк для примеров, которые вы использовали.Задайте конкретные вопросы, если что-либо из этого не понято полностью.
Модель данных
Оцените это ▶ Исходная модель данных (Страница 2) ◀ (встроенные ссылки не работают в некоторых браузерах / версиях.)
Читатели, не знакомые со стандартом реляционного моделирования, могут счесть ▶ IDEF1X нотацией ◀ полезной.
Ответ на комментарий 01 января 11
3) Если у меня есть (3.1 и 3.2) или (5.6 и 5.9), если я использую 0.5, как я могу дифференцировать это с (3.1 и 3.2 и 5.6 и 5.9), я должен использовать другой вес для каждая группа это правильно? 0,5 для (3,1 и 3,2) и 0,6 для (5,6 и 5,9)?
Нет. Вы немного добавили к вопросу (нет проблем; моделирование - это упражнение туда и обратно). Никогда не играйте с попытками идентифицировать контроль в данных. Контроль лежит в ключах, идентификаторах. Эта дифференциация уже представлена в модели. Измененное требование (вопрос, а не таблица) теперь:
- Для
Class до Qualify вес Requirement должен быть не менее 1,0 в том же Sector
(5,6 и 5,9) остаются на 0,5 каждый; они отличаются Sector (5) от (3.1 и 3.2), которые (3).
4) Вы прочитали и поняли нотацию IDEF1X и цените ли вы составные ключи в модели? Requirement PK - (ClassNo, SectorNo, QaulificationNo); единственные данные Weight.
5) Вы понимаете бизнес-правила, которые поддерживает Модель? Вы хотите, чтобы я перечислил их?
Ответы на комментарии 02 января 11
Некоторая точность, (1) Класс полностью отличается от Сектора / Квалификации, они не связаны напрямую.
Да, он уже независим. Класс соответствует всем приведенным выше инструкциям, плюс Sector и Qualification являются правильными: «СЕКТОРЫ; ДЕЯТЕЛЬНОСТЬ КВАЛИФИКАЦИИ И КЛАССИФИКАЦИЯ КОМПАНИЙ, ВСТУПАЮЩИХ В СЕКТОР ЗДАНИЯ». Мы должны сделать один шаг назад и подтвердить простые правила, прежде чем двигаться вперед. Новая модель данных. Пожалуйста, подтвердите / опровергните каждое из этих утверждений, работая бок о бок с DM:
Сектор состоит из 1-ко-многих квалификаций (ссылка предоставлена)
Квалификация является требованием в 1-ко-многим классификациям
Классификация требует 1-ко-многим квалификации:
- a набор квалификаций необходим для проведения квалификации
- Некоторые квалификации имеют ИЛИ-редакцию
- Некоторые квалификации являются И-ред
- набор квалификаций, требуемых для классификации, с ИЛИ или И-ИД, должен находиться в одном и том же секторе
.
(Новая информация) Уведомление о классификации выдается 1-ко-многим предприятиям.
Предприятию присвоены 1-ко-многим классификации.
(2) Предполагается, что два операнда имеют один и тот же сектор, это может быть (3.1 и 4.6) или (5.6 и 1.9).
(я ничего не предполагаю, я перебираю предоставленную вами информацию: дайте мне больше информации, и я дам вам более точную модель); -}
Нет проблем. (2.a) Определите базис для (3.1 и 4.6), сгруппированных. (2.b) Укажите имя каждой классификации (3.1 и 4.6), (5.6 и 1.9); что отличает их от группы (3.1 и 3.2)
(4) для ERD и dm нам просто нужно изменить Enterprise на Notice и подключить его к Требованию.
Не беспокойтесь о «связях», это работа, которую я принял, по вашей просьбе. ; -}
(5) в каждом Уведомлении содержится много требований, которым должно соответствовать каждое предприятие, чтобы иметь возможность участвовать.
(5.a) Каково содержание этих Уведомлений; разве это не подтверждение того, что они достигли Классификации? Или что они достигли единого требования?
(5.b) Должна ли система отслеживать каждое требование, которое выполняет каждое Предприятие?
(5.c) Отдельно от требований, когда Предприятие достигает Классификации (набора требований), выдает ли Система Уведомление о классификации?
Обновление
Основываясь на новой информации, я вижу, куда вы направляетесь. Пожалуйста, оцените это ▶ Очень предварительная модель данных (Страница 3) ◀ .
- ИЛИ-И-И еще проще
- Каждая классификация имеет набор возможных требований (ИЛИ-ред.)
- Каждый ClassificationSet требуется полностью (AND-ed)
- Вес больше не требуется
- Это отслеживает каждую квалификацию, присуждаемую Предприятию (пользователь вставляет это); и обновления уведомляются при выдаче уведомления
- и каждая достигнутая классификация
Возможно, ежедневно требуется процедура для обработки EnterpriseQualifications (сравнение с ClassificationSet) и производства (вставки) EnterpriseClassification. И снова обновите IsNotify при выдаче Уведомления.
Хорошо, я удалил ненужные биты согласно комментариям и обновил Предварительную модель данных.
В ожидании ответа на оставшиеся вопросы. Так что теперь это ▶ Модель неполных данных (Страница 4) ◀ .
Чтобы «связать» Уведомление с требованиями, мне нужно знать базис отношения; это не может быть одним Уведомлением для многих, любым Требованием.
Простота. На самом деле, я мастер простоты. ПОЦЕЛУЙ. это не мелкая мантра, в ней есть наука. Чтобы устранить проблемы во время разработки и кодирования, вам нужна чистая модель данных; простой, несложный. Это то, что я пытаюсь тебе дать. Но мне нужна информация.
Ожидается ответ на оставшиеся вопросы. Так что теперь это ▶ Модель с запутанными данными (Страница 5) ◀ .
Ответ на комментарии от 05 января 11
Хорошо, мы куда-то добираемся. Я пересмотрел DM на основе вашего последнего пересмотра вопроса. Теперь у нас есть ▶ Пятая модель данных (стр. 6) ◀ (не проблема, такова природа моделирования, бумага дешевая, рефакторинг дорогой).
Изначально идентифицированные Class и т. Д. Удаляются. Notice is Tender.
Имена, идентификация, определение, на самом деле очень важны, вы поймете, что как только вы начнете кодировать; и позже, когда вам нужно расширить модель данных.
Weight, основанный на более раннем понимании, также удаляется. Теперь у нас есть понятие необязательных наборов Requirements на Tender (ИЛИ), и каждый набор является обязательным (И).
код и определения классов теперь будут очень простыми.
Я использовал точные значения данных, приведенные в ваших последних примерах.
Синим цветом обозначены статические справочные таблицы; Зеленым обозначены идентифицирующие элементы.
Пожалуйста, убедитесь, что вы прочитали документ с обозначениями IDEF1X, чтобы вы могли полностью интерпретировать DM и создать DDL. Это будет иметь полную целостность, силу и мощь (гибкость) реляционной модели.
Когда это будет завершено, я исправлю свой ответ, удаляю всю устаревшую информацию, с которой мы работали.
Ответ на комментарии от 07 января 11
(1) Примеры 2 и 3 хранятся одинаково, как вы отличаете (3) ИЛИ от (2) И?
Ошибка спецификации данных на моей стороне. ▶ Пятая модель данных (стр. 7) ◀ без изменений, с исправленными данными.
(2) Поддерживает ли он какую-либо комбинацию требований ИЛИ / И? Это только примеры, это может быть что угодно, например (6.4 или (3.7 и 1.1)) и (9.6 или 8.5). Он должен быть гибким.
Модель данныхобладает всей «гибкостью», которую вы ранее определили.Нет, он не поддерживает никаких требований, которые вы не определили (у меня достаточно возможностей, но ESP - это то, чего у меня нет!).
В этом случае, очевидно, вы не делаете «точно знаю, что вы хотите сделать», вы снова вводите новые требования.И данные не необработанные, это очень специфические контрольные данные, поэтому, пожалуйста, давайте перестанем воспринимать это как простое требование «хранить необработанные данные» и приступим к не такой простой задаче.
Какая еще «гибкость», «точно», вам требуется?Укажите все эти формы, и я дам вам модель данных, которая удовлетворяет всем требованиям;это займет меньше времени и усилий, чем этот инкрементный метод туда-сюда, который вы используете.
В случае, если вы забыли, вот ▶ Ранняя версия вашего Вопроса ** . Все исправления вашего вопроса доступны для всех, у кого достаточно очков, чтобы их увидеть.
Инкрементальный метод, без сомнения, полезен для вас, чтобы понять ваши данные ичтобы понять прогресс модели, но, как вы можете видеть, это очень медленный и трудоемкий путь.Прекрасно, когда ты работаешь один и имеешь все время в мире;не хорошо, когда вы работаете с профессионалом.
Быстрый путь - определить все ваши требования заранее и позволить профессионалу предоставить полную модель данных.(Например, ваше последнее новое требование займет у меня пять минут; но я мог бы включить это в последнюю модель данных, если бы вы ее определили; и, конечно, это тоже не будет выполнено.) Затем задайте вопросы, чтобы заполнить все пробелыпонимание.
Опытный профессиональный Data Modeller не должен работать в крошечные пошаговые шаги.Мы смотрим на всю картину (нам нужна реляционная база данных без дублирования) и нормализуем всю модель.Однажды.
И не тратьте время на определение ваших объектов и классов, они будут меняться с каждым крошечным приращением;Вы можете подождать, пока Модель данных будет завершена, и определить свои классы один раз.Это будет стабильно.
Я обновил документ, чтобы показать серию изменений, которые были подготовлены для Вопроса в результате ваших требований о небольшом постепенном прогрессе.Я бы попросил вознаграждение за решение вопроса, который занимает так много времени и требует так много пересмотров, но у вас нет очков, чтобы отдать.Я так много раз редактировал свой ответ, что теперь это «вики сообщества», дальнейшие пункты не будут подтверждены.Завершение этого вопроса для вас теперь является чисто благотворительной работой (не волнуйтесь, я очень благотворительная).
Я аннотировал вышеприведенное, но Пятая модель данных остается неизменной.
Пожалуйста, внесите все изменения (укажите все "точная" "гибкость" , которые вам необходимы) в ваш вопрос, и я отвечу на него.Пожалуйста, не не изменяйте текст своего Вопроса и не удаляйте ничего;оставь то, что там есть, и добавь к нему .
Ответ на комментарии от 08 января 11
(1) Я добавилЕще два примера, я буду рад видеть ваш общий метод, я хочу его.В любом случае, с этими двумя примерами я думаю, что этого достаточно для большинства случаев.
Эти новые примеры вводят (неявно) еще более новые требования:
в основномдревовидная структура (если не требуется массовое дублирование и связанная с этим проблема целостности данных).
И и ИЛИ, возникающие в любой точке / узле дерева
- Это предоставляется логическим
IsAndSet;false означает, что это ИЛИ.
.
a RequirementSet может состоять из:
Qualifications;- прочее
RequirementSets (если вы не хотите массового дублирования); или оба
Для этого требуется Подтип (объясняется в документе нотации IDEF1X) для учета необязательных столбцов - внешнего ключа. Существует только один, поэтому Дискриминатор не требуется. Это Эксклюзивный Супертип / Подтип.
Остается необязательным, только для RequirementSet, составленного из других RequirementSets
Узлы - это атомный или листовой уровень, все остальное - нет (оно состоит из узлов). Узлы устраняют дубликаты данных и обновляют аномалии.
Некоторые разработчики сворачивают RequirementSet и RequirementSetNode в одну таблицу: она будет ненормализована и трудна в обслуживании. Кроме того, для этого потребуются нулевые иностранные ключи. Каждый из них по отдельности нарушает правила реляционного моделирования и проектирования и имеет сопутствующие проблемы, поэтому я не предполагаю, что я предоставляю только стандартные модели. Может показаться, что код сложнее, но на самом деле это проще.
Я предоставил все данные для ваших примеров (5) и (6), а также древовидную диаграмму. Вы можете выполнить рефакторинг данных, предоставленных для примеров (1) - (4) [если бы вы дали эти примеры в самом начале, пять предыдущих версий модели данных не потребовались бы, и данные, которые я предоставил для них, не понадобились бы рефакторинга].
Обновлена модель данных, теперь мы находимся на ▶ Шестая модель данных (стр. 8) ◀
Следующий пример ...?
Ответ на комментарии от 10 января 11
(1) Не понимаю, почему в нем не может храниться ни одна комбинация.
Может, AFAIK ... но всегда есть вероятность, что кто-то в Новой Каледонии придумает что-то, что не сможет сохранить; будучи консервативным, я не заявляю, что он может хранить любую комбинацию ; просто он универсален и чрезвычайно гибок при сохранении полной реляционной целостности и мощи.
(2) Не могли бы вы объяснить, что вы подразумеваете под "Узлы атомного или листового уровня"? Вы имеете в виду, что оно не включает в себя голову дерева?
Эти термины распространены в структурах B-Tree и Directory.
Я изменил RequirementSetNode на RequirementSetChild, чтобы улучшить понимание.
Конечный уровень - это самый конец любой ветви. Обратите внимание, что Листья не все на одном уровне. В нашем случае они всегда Requirements.
Узел - это любая ветвь или соединение в дереве в древовидной диаграмме (не в модели); коллекция узлов или листьев или их комбинация. В нашем случае это RequirementSets.
- Коллекция Листьев, принадлежащая
RequirementSet, находится в Requirement
- Коллекция узлов, принадлежащих
RequirementSet, находится в RequirementSetChild.
,
Атомарный - это термин «транзакция» (база данных SQL IEC / ISO / ANSI) из свойств ACID. Атомное означает, что оно неделимо; либо весь блок действителен; или это недействительно. Здесь я утверждаю, что с точки зрения вашего приложения вам просто нужно рассматривать каждый узел (элементы, которые он содержит) как единое целое.
(Лист всегда атомный.)
Точные данные примеров следует уточнить; Я предоставил расширение на стр. 9.
(3) "Это остается необязательным, только для набора требований, который состоит из других наборов требований" Что остается необязательным?
RequirementSetChild - необязательный дочерний элемент RequirementSet. Не каждый RequirementSet имеет RequirementSetChildren; только RequirementSet, которые являются узлами, следовательно, это необязательно. (Но, конечно, у ребенка всегда есть родитель; это внешний ключ, а не необязательный.)
(4) «Это эксклюзивный супертип / подтип». Что такое Супертип и Подтип в вашей модели? Что означает «Эксклюзив» в этом случае, подтип не может иметь подтипы?
На самом деле, поскольку существует только один подтип, мы можем устранить проблему Supertype :: Subtype и рассматривать ее как простой необязательный дочерний элемент.Модель изменена.