powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
25 сообщений из 63, страница 2 из 3
Проектирование без избыточности
    #39396541
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,
Например таблицы

persons
accounts
operations
documents_associates

образуют "кольцо". Это явный признак избыточности данных (денормализованная база). У вас явно не те объемы данных, чтобы денормализация была оправданной. Поэтому на вашем месте я бы попробовал для начала привести всё к третьей форме, а уже после этого продумывать, как связывать действия и документы.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396545
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, я не знаю, захотите ли Вы смотреть мою базу, если я ее приложу, но я уверяю Вас - моя база в смысле нормализации хорошая! У меня ни оно значение не вводится дважды, как и пишут в книгах про базы. И ни одно значение не вводится, если его можно рассчитать (ну, типа стажа - он считается программно). Как и пишут в книгах про базы, у меня таблицы приведены к этим пресловутым нормальным формам. Ну, по крайней мере, я старалась.
Хорошо, я дома постараюсь поаккуратней расположить на экране таблицы и сделаю скрин снова.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396547
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, если Вы так считаете, что там кольцо, то тогда я подумаю. Возможно, я чего-то не учла.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396552
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurels_ustinov, я не знаю, захотите ли Вы смотреть мою базу, если я ее приложу, но я уверяю Вас - моя база в смысле нормализации хорошая!

А тот рисунок, что вы выложили - не ваша база?
Я говорил про базу на рисунке - она довольно сильно денормализована.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396561
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, проклятие, я не знала не про какие кольца! Но я поняла - располагать группами, связывать в группах, а связь групп - только в малых дозах. Посмотрю. Мне всегда казалось, что надо одну тему располагать в одной таблице, скажем "награждения", "звания", "лицевые счета", "табельные номера", "наказания", "отпуска" и т.д., у меня так сделано, и все это висит на персон_ид, ну, на человеке то есть... На аккаунт_ид висят операции.
Думаю, кольцо из-за сборной таблицы "ассоциированные документы", где каждому документу ставятся в соответствие или отпуск, или звание, или наказание, или персона. Не делать же много таблиц "документы", где каждому документу только одно что-то соответствует, типа "документ званий", "документы отпусков". Так разве правильно. Таблиц будет уйма.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396568
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurels_ustinov, проклятие, я не знала не про какие кольца! Но я поняла - располагать группами, связывать в группах, а связь групп - только в малых дозах. Посмотрю.

Это не жесткое правило, но так намного удобнее проектировать схему БД.

OkeTurelМне всегда казалось, что надо одну тему располагать в одной таблице, скажем "награждения", "звания", "лицевые счета", "табельные номера", "наказания", "отпуска" и т.д.,
Правильно, это называется "сущность".

OkeTurelДумаю, кольцо из-за сборной таблицы "ассоциированные документы", где каждому документу ставятся в соответствие или отпуск, или звание, или наказание, или персона. Не делать же много таблиц "документы", где каждому документу только одно что-то соответствует, типа "документ званий", "документы отпусков". Так разве правильно. Таблиц будет уйма.
У вас проблема со схемой БД - именно об этом свидетельствуют "кольца". В чем именно... В том виде, в каком схема БД сейчас, разбирать долго. Попробуйте сами упорядочить свою схему - после этого будет понятнее.
А количество таблиц не обязательно станет больше. Скорее всего можно будет обойтись одной универсальной таблицей "документы".
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396577
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelsoftwarer, это все так красиво выглядит, как Вы начертили, а на деле не знаю даже, на каждой таблице куча других
О том, что я нарисовал, надо думать ещё до таблиц. Надо представить бизнес-процесс в чётких и удобных терминах. А те таблицы, которые Вы называете - это справочники, их может быть сколько угодно, они практически не влияют на сложность запроса.

s_ustinovобразуют "кольцо". Это явный признак избыточности данных (денормализованная база).
Хм. Имхо, недостаточно обоснованное утверждение, назовём так. Прямо таки хочется спросить, как избавиться от избыточности данных и нормализовать следующую базу:

Код: plaintext
1.
2.
3.
4.
5.
1, Адам, null
2, Каин, 1
3, Авель, 1
4, Енох, 2
5, Ирад, 4
....

s_ustinovУ вас проблема со схемой БД - именно об этом свидетельствуют "кольца"
Хм.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396627
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerХм. Имхо, недостаточно обоснованное утверждение, назовём так.
https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D1%82%D1%8C%D1%8F_%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0]Запоминающееся и, по традиции, наглядное резюме определения 3NF Кодда было дано Биллом Кентом: каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа »[1].
То есть атрибут должен зависеть только от ключа. Не допускается зависимость одного неключевого атрибута от другого неключевого атрибута.
На картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id. И при этом operation_id не является первичным ключом documents_associates.
И как раз "петли" и показывают "визуально" наличие таких нарушений.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396637
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovНа картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id.
Вы так думаете? :) Я вот не вижу оснований для такого утверждения. И даже уверен, что нет никаких проблем построить контрпример.

s_ustinovИ как раз "петли" и показывают "визуально" наличие таких нарушений.
Я Вам чуть выше нарисовал петлю. И жду указаний на избыточные данные и инструкций по денормализации.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396648
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarers_ustinovНа картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id.
Вы так думаете? :) Я вот не вижу оснований для такого утверждения. И даже уверен, что нет никаких проблем построить контрпример.

Я уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates. А это и есть зависимость одного атрибута от другого.
Любопытно будет посмотреть на контрпример.
softwarers_ustinovИ как раз "петли" и показывают "визуально" наличие таких нарушений.
Я Вам чуть выше нарисовал петлю. И жду указаний на избыточные данные и инструкций по денормализации.
Не очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396688
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelvmag, я долго ломала голову, что первично, мне кажется, что первично действие, возможно я ошибаюсь. Не знаю, в таблице "Документы" можно сделать ссылку на что угодно...

По вашей логике кадровик сидит в курилке курит и вдруг видит дрейфующего по аллее прапорщика Сидорова, который пришпандорил себе на китель майорские погоны... ну да, действие совершено, нужно подрываться и срочно готовить приказ о присвоении прапорщику Сидорову очередное воинское звание майор...
Документ (грубо) состоит из: шапки и тела документа (возьмите за образец что угодно для наглядности например накладную, счет, акт...). В главную таблицу docs пишут шапку (номер, дата документа, ...) а в подчиненную строки этого документа - в вашем случае это подчиненная таблица "действия"... То, что у вас все наоборот (действие первично) говорит о том, что у вас очень разнородные документы вплоть до полной несовместимости, например, как совместить присвоение звания и отпуск (разное количество и назначение атрибутов) ?
Если бы вы сразу сказали, что у вас кадровая задача, я бы вам сразу посоветовал уйти от реляционной БД и посмотреть в сторону БД для хранения документов типа 1С кадры и ей подобных, там именно складируются разнородные документы, на базе которых написаны соответствующие обработки и кстати там такая же структура всех документов - шапка + тело документа... НО ОНИ ВСЕ РАЗНЫЕ ПО СТРУКТУРЕ И В ШАПКЕ И В ТЕЛЕ...
OkeTurelя кадровик, а специализированных кадровых систем типа 1-С или Паруса у нас нет
Остается только посочувствовать...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396710
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovНе очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички.
Хм. А Вы посмотреть в эти данные не пробовали? Могу ещё написать ddl этой таблицы, если так не очевидно:

Код: sql
1.
2.
3.
4.
5.
6.
create table Men(
  id integer not null,
  name varchar2(240 char) not null,
  parent_id integer,
  constraint Men_pk primary key(id),
  constraint Men_Men_fk foreign key(parent_id) references Men(id));


По-прежнему жду указаний по нормализации этой петли :)

s_ustinovЯ уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates.
А кто Вам сказал, что person_id, лежащий в таблице documents_associates, каким-либо образом зависит от person_id, который Вы можете определить через operation_id? Положите в эту структуру информацию "Иванов выписал живительных пиздюлей Петрову" - вот и будет тот контрпример, который Вы не чаяли увидеть
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396711
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag,

только хотел пригласить Вас в студию..

))


да чо ждать-то

жисть - покажет


обязательно
обязательно










избыточность
может быть - ОЧЕНЬ полезна

))
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396730
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,

у вас к таблице persons прицеплено по кону персоны наверное 20 таблиц
без малейшего ущерба для понимания вы можете скрыть эту таблицу(правой мышкой)
---
тогда вы увидите реальную схему ваших остальных таблиц, а не паутину
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396758
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarers_ustinovНе очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички.
Хм. А Вы посмотреть в эти данные не пробовали? Могу ещё написать ddl этой таблицы, если так не очевидно:

Код: sql
1.
2.
3.
4.
5.
6.
create table Men(
  id integer not null,
  name varchar2(240 char) not null,
  parent_id integer,
  constraint Men_pk primary key(id),
  constraint Men_Men_fk foreign key(parent_id) references Men(id));


По-прежнему жду указаний по нормализации этой петли :)

Насколько помню, во "Введении" что то написано о нормализации в таких ситуациях... Будет время, прочитаю - напишу.

softwarers_ustinovЯ уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates.
А кто Вам сказал, что person_id, лежащий в таблице documents_associates, каким-либо образом зависит от person_id, который Вы можете определить через operation_id? Положите в эту структуру информацию "Иванов выписал живительных пиздюлей Петрову" - вот и будет тот контрпример, который Вы не чаяли увидеть
Я исхожу из того, что имена атрибутам выдаются все же осмысленно. Например, чуть выше используются названия "id" и "parent_id"
В нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли".
Я все таки верю в людей... Возможно, зря...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396772
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ПЕНСИОНЕРКАOkeTurel,

у вас к таблице persons прицеплено по кону персоны наверное 20 таблиц
без малейшего ущерба для понимания вы можете скрыть эту таблицу(правой мышкой)
---
тогда вы увидите реальную схему ваших остальных таблиц, а не паутинусхема - в Мозгу
и
из Мозга..

и тд

лична
не нужны бумазьки, карандаши и авторучки



правильно
Уровень - Чуйки





с Уважением к ВАМ
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396775
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovВ нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли".

А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396796
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинs_ustinovВ нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли".

А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью?
Неееее...
Для таких задач создают ОДНУ таблицу:

CREATE TABLE actions (
[id_action] [int] IDENTITY(1,1) NOT NULL,
[Что Дулин сделал для Михалыча] [nvarchar](max)
);

А потом заносят в неё мега ценную информацию:
INSERT INTO actions
([Что Дулин сделал для Михалыча])
VALUES
('Подарил очень красивую красную розу');

или

INSERT INTO actions
([Что Дулин сделал для Михалыча])
VALUES
('Признался в неземной любви');
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396802
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovКот Матроскинпропущено...

А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью?
Неееее...
Для таких задач создают ОДНУ таблицу:



Для каких "таких"?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396810
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинs_ustinovпропущено...

Неееее...
Для таких задач создают ОДНУ таблицу:



Для каких "таких"?

Для таких:
Кот МатроскинА длчя записи информации "Иванов подарил цветочки Петрову"
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396823
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov,

Т.е. Вы все верите, верите в людей, рассчитываете что они будут только морды друг другу бить, и тут раз - кто-то кому-то дарит цветочки. И все, базу на выброс? Непрактично как-то :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396846
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин,
Не так всё было. :))
Я верю в людей, верю в то, что дети сегодня заснут пораньше... И тут бац! Предлагают хранить в базе информацию "Иванов подарил цветочки Петрову"... Ну вот как так можно?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396968
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag, я вчера вечером подумала и теперь согласна с Вами. Я переделаю базу "от документа", т.е. первичным будет документ, пляшем от документа, на нем висят дейтсвия. Кстати, по-моему и в Парусе сделано "от документа".
Спасибо за совет.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396973
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ПЕНСИОНЕРКА, совершенно верно, у меня на персон_ид висят образование, аттестация, семейное положение, больничные, контроль флюорографии и санминимума, ассоциированные персоны (мамы-папы), наказания и награждения.
Да, скрыла, стало понятней. Спасибо.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39397051
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer, все в общих чертах понятно, и я решила вообще уйти от реаляционной модели и сделать как в 1-С, как мне советовал vmag. У меня получалась реляция, потому что я придавала большое значение таблице "персоны" и считала ее главной и думала - надо, чтобы на ней все висело. Думаю, надо сделать "Персоны" простым справочником, который, может, и связан-то ни с чем не будет, ну, будет ИД, но этот ИД в таком большом количестве документов будет (как шапок документов, так и табличной части), что нет смысла там связи будет делать.
...
Рейтинг: 0 / 0
25 сообщений из 63, страница 2 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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