Список всех функциональных зависимостей для экземпляра отношения [duplicate]

Ваша проблема новая (создание объекта в стиле java)

MileageFeeCalculator calc = new MileageFeeCalculator();

С аннотацией @Service, @Component, @Configuration beans создаются в контексте приложения Spring при запуске сервера , Но когда мы создаем объекты с использованием нового оператора, объект не регистрируется в контексте приложения, который уже создан. Для примера используется класс Employee.java.

Проверьте это:

public class ConfiguredTenantScopedBeanProcessor implements BeanFactoryPostProcessor {

@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
    String name = "tenant";
    System.out.println("Bean factory post processor is initialized"); 
    beanFactory.registerScope("employee", new Employee());

    Assert.state(beanFactory instanceof BeanDefinitionRegistry,
            "BeanFactory was not a BeanDefinitionRegistry, so CustomScope cannot be used.");
    BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;

    for (String beanName : beanFactory.getBeanDefinitionNames()) {
        BeanDefinition definition = beanFactory.getBeanDefinition(beanName);
        if (name.equals(definition.getScope())) {
            BeanDefinitionHolder proxyHolder = ScopedProxyUtils.createScopedProxy(new BeanDefinitionHolder(definition, beanName), registry, true);
            registry.registerBeanDefinition(beanName, proxyHolder.getBeanDefinition());
        }
    }
}

}
2
задан user559142 25 April 2011 в 23:59
поделиться

4 ответа

С первого взгляда. , .

custName -> custNo
model -> make
outletLoc -> outletNo
carReg, custNo -> hireDate
carReg, custName -> hireDate

И я уверен, что есть другие. Примеры данных не являются репрезентативными, и это проблема, когда вы пытаетесь определить функциональные зависимости от данных. Скажем, ваши образцы данных имели только одну строку.

carReg    hireDate make  model  custNo  custName  outletNo  outletLoc
--
MS34 0GD  14/5/03  Ford  Focus  C100    Smith, J  01        Bearsden

FDs ответили на вопрос: «Учитывая одно значение для« x », знаю ли я одно и только одно значение для« y »?» Основываясь на этом наборе данных с одной строкой, каждый атрибут определяет каждый другой атрибут. custNo определяет аренду. rentDate определяет outletLoc. custName определяет модель.

Когда выборочные данные не являются репрезентативными, легко включить недопустимые FD. Вам нужны более репрезентативные образцы данных для отсечения некоторых недействительных функциональных зависимостей.

custName -> custNo isn't valid ('C101', 'Hen, P')
carReg, custNo -> hireDate isn't valid ('MS34 0GD', 'C100', '15/7/04')
carReg, custName -> hireDate isn't valid ('MS34 0GD', 'Hen, P', '15/8/03')

Вы можете исследовать функциональные зависимости в образцах данных с помощью SQL.

create table reg (
  CarReg char(8) not null,
  hireDate date not null,
  Make varchar(10) not null,
  model varchar(10) not null,
  custNo char(4) not null,
  custName varchar(10) not null,
  outletNo char(2) not null,
  outletLoc varchar(15) not null
);

insert into reg values
('MS34 OGD', '2003-05-14', 'Ford', 'Focus', 'C100', 'Smith, J', '01', 'Bearsden'),
('MS34 OGD', '2003-05-15', 'Ford', 'Focus', 'C201', 'Hen, P', '01', 'Bearsden'),
('NS34 TPR', '2003-05-16', 'Nissan', 'Sunny', 'C100', 'Smith, J', '01', 'Bearsden'),
('MH34 BRP', '2003-05-14', 'Ford', 'Ka', 'C313', 'Blatt, O', '02', 'Kelvinbridge'),
('MH34 BRP', '2003-05-20', 'Ford', 'Ka', 'C100', 'Smith, J', '02', 'Kelvinbridge'),
('MD51 OPQ', '2003-05-20', 'Nissan', 'Sunny', 'C295', 'Pen, T', '02', 'Kelvinbridge');

Определяет ли модель?

select distinct model 
from reg
order by model;

model
--
Focus
Ka
Sunny

Три разных модели , , .

select model, make
from reg
group by model, make
order by model;

model   make
--
Focus   Ford
Ka      Ford
Sunny   Nissan

Yup. Для каждой модели нужно сделать один.

Использует carReg, custName -> hireDate?

select distinct carReg, custName
from reg
order by custName;

carReg
--
MH34 BRP  Blatt, O
MS34 OGD  Hen, P
MD51 OPQ  Pen, T
MS34 OGD  Smith, J
NS34 TPR  Smith, J
MH34 BRP  Smith, J

Шесть различных комбинаций carReg и custName.

select carReg, custName, hireDate
from reg
group by carReg, custName, hireDate
order by custName;

carReg  custName  hireDate
--
MH34 BRP  Blatt, O  2003-05-14
MS34 OGD  Hen, P    2003-05-15
MD51 OPQ  Pen, T    2003-05-20
MH34 BRP  Smith, J  2003-05-20
NS34 TPR  Smith, J  2003-05-16
MS34 OGD  Smith, J  2003-05-14
]

Yup. Один найм для каждой комбинации carReg и custName. Поэтому на основе данных выборки {carReg, custName} -> hireDate.

5
ответ дан Mike Sherrill 'Cat Recall' 21 August 2018 в 13:50
поделиться
  • 1
    Привет, спасибо за ваш ответ. Я не согласен с некоторыми из упомянутых вами FD. 1) custName - & gt; custNo не может быть прав, поскольку может существовать несколько J Smiths. 2) make - & gt; модель не может быть прав, поскольку Ford делает несколько моделей автомобилей. 3) outletLoc - & gt; outLetNo не может быть прав, поскольку в пределах местоположения может быть много точек. 4) carReg, custNo - & gt; rentDate AND carRegs, custName - & gt; RentalDate не может быть прав, поскольку J Smith, например, мог бы арендовать один и тот же автомобиль дважды в отдельные дни ... – user559142 25 April 2011 в 21:13
  • 2
    Я признаю, что ваши FD-файлы предназначены для этого конкретного экземпляра, показанного для отношения, но разве FD не должны удерживаться для всех возможных значений внутри домена ...? – user559142 25 April 2011 в 21:14
  • 3
    Выбранные данные образца поддерживают каждый идентифицированный мной FD. Возможно, вам следует прочитать то, что я написал снова, особенно часть, которая начинается & quot; Примеры данных не являются репрезентативными, и это проблема. , . & Quot; и часть, которая начинается "Когда выборочные данные не являются репрезентативными. , . & Quot; – Mike Sherrill 'Cat Recall' 25 April 2011 в 21:18
  • 4
    @catcall - По определению, функциональная зависимость должна выполняться в течение ВСЕГО времени. Так что, упоминая FD, вы должны учитывать любые будущие дополнения к таблице ... Может быть, я ошибаюсь, я не знаю?!?! Пожалуйста, не обижайтесь на меня, оспаривая ваш ответ, это единственный способ узнать меня. – user559142 25 April 2011 в 21:29
  • 5
    Когда вы обнаружите, что ваши данные образца не являются репрезентативными, исправьте образцы данных. См., Например, образцы данных, которые я опубликовал после «custName» - & gt; custNo недействительно ". Когда ваши образцы данных являются репрезентативными, автоматизированные инструменты могут генерировать все возможные схемы 5NF. Когда ваши образцы данных не являются репрезентативными, все ставки отключены. – Mike Sherrill 'Cat Recall' 25 April 2011 в 21:43
  • 6
    – Mike Sherrill 'Cat Recall' 27 April 2011 в 01:07

Хорошо, так как вы попросили второе мнение, я дам вам один.

Второе мнение заключается в том, что первый (CatCall's) является полностью правильным.

Примеры данных недостаточно для определения / определения функциональных зависимостей в данных. Что необходимо для определения / определения функциональных зависимостей в данных, являются требованиями пользователей, описаниями / определениями бизнес-среды, к которой предназначена база данных, ...

Только ваши пользователи могут сказать вам, в одном направлении или другой, какие функциональные зависимости применяются. (Не интерпретируйте это как означающее, что вы должны сообщать своим пользователям, что они должны сообщать вам «какие применимые FD», потому что ваши пользователи обычно не знают, что означает этот термин. Однако, что применимы FD, все еще выводятся из ничего, кроме тех бизнес-спецификаций, которые пользователь предоставляет вам.)

(например, выборочные данные PS могут быть достаточно, чтобы продемонстрировать, что определенный данный FD, конечно, НЕ будет применяться. Но это не ваше вопрос.)

3
ответ дан Erwin Smout 21 August 2018 в 13:50
поделиться
  • 1
    «выборочных данных», наоборот, действительно достаточно, чтобы продемонстрировать, что определенный данный FD, конечно, НЕ будет применяться ». - & GT; нормально, так как данные выборки недостаточно репрезентативны, чтобы указать custName - & gt; custNo неверно, правильно ли сказать, что для этого набора данных данных, это действительный FD? – user559142 26 April 2011 в 10:05
  • 2
    Не совсем правильно. Было бы правильно сказать, что этот конкретный набор данных удовлетворяет FD. Сказать, что FD является «действительным», является просто неаккуратным и неточным использованием языка. Сказать, что FD применяется («поддерживает» или что-то в этом роде) заключается в том, что в реальном мире действует определенное правило (правило единственности). Сказать, что FD Name-& gt; ID применяется , означает, что Имя является уникальным свойством лиц, с которыми вы имеете дело в своей деятельности (что, вероятно, является ложью). Сказать, что этот FD является "действительным" (извините, если это кажется оскорбительным), будучи многословным, ничего не говоря. – Erwin Smout 26 April 2011 в 12:57
  • 3
    Если мой комментарий кажется чрезмерно заниженным, подумайте: (а) Являются ли компьютеры точными машинами или нет, в том смысле, что они всегда выполняют точно так, как им говорят ? (b), и если ответ на этот вопрос «да», то насколько важно для людей, которые программируют эти компьютеры , быть точными ? – Erwin Smout 26 April 2011 в 13:00

FD (функциональная зависимость) выражает определенное свойство отношения значение или переменную . Мы можем сказать, что оно выполняется для или не выполняется для (выполняется или не выполняется) (истинно или не соответствует) заданного отношения значение . Когда мы говорим, что оно удерживает или не поддерживает переменную , мы имеем в виду, что она выполняется или не выполняется для любого возможного значения переменной, которая может возникнуть в приложении.

Также, если нам дано значение , и нам говорят, что FDs, которые он удовлетворяет, являются FD, что переменная, которая может ее удержать, удовлетворяет , а затем по этому предположению переменные FDs являются FD. (Это иногда называют «репрезентативными данными» для переменной). Но если нам просто присваивается значение, которое может возникнуть для переменной, то мы знаем только, что

  • FDs, которые дон 't в значении также не имеют значения в переменной
  • [тривиальных FDs для обоих удержаний (те, которые имеют вид S -> подмножество S) (те, которые должны выполняться независимо от значения, основанные только на атрибутах) (что должно быть одинаковым для значения & amp; переменной)

См. также этот ответ .

0
ответ дан philipxy 21 August 2018 в 13:50
поделиться

Вот моя попытка отношений:

enter image description here [/g0]

0
ответ дан Raj More 21 August 2018 в 13:50
поделиться
  • 1
    Эти много: 1 "отношения" внешние ключи в некоторой декомпозиции исходных, а не функциональных зависимостей , которые хранятся в оригинале (что оправдывало бы разложения). – philipxy 23 April 2018 в 04:58
Другие вопросы по тегам:

Похожие вопросы: