powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проблема с нормализацией данных
14 сообщений из 14, страница 1 из 1
Проблема с нормализацией данных
    #32807714
vitaliy14
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
День добрый! столкнулся с проблемой: Есть следующая таблица(выборка в клиенте будет по полю Наименование ) :

ID
Субъект
Наименование
Адрес
Телефон
Организационно-правовая форма
Учредители
Директор
Факс
e-mail
Лицензия
Тип учреждения (социальной службы):
Штатная численность
Финансирование
Категория обслуживаемых
Количество обслуженных за год
Дата ввода
Дата изменения
Пользователь

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

Шо -то низкая здесь активность за час
ни ответа ни привета
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32807891
TanyaO
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В данном случае это вообще не может быть таблицей. Таблицы даже изначально при проектировании (перед нормализацией) создаются таким образом, чтобы между полями существовала хоть какая-нибудь функциональная зависимость.
Например создать таблицу АДРЕС с полями
ID
город
улица
и т.д.
В этой таблице нельзя помещать данные не относящиеся к адресу.

Таблица ДАННЫЕ О СУБЪЕКТЕ
ID
Субъект
Наименование
и т.д.
Поля которые потом можно рассчитать, используя запрос не вносятся (допустим КОЛИЧЕСТВО ОБСЛУЖЕННЫХ ЗА ГОД, если есть данные по месяцам или дата обслуживания, то количество можно будет вычислить с помощью запроса)
Потом эти две таблицы связать между собой по ID.
А лишь потом смотреть каждую из этих таблиц и приводить хотя бы к первым 3 нормальным формам. Таким образом вам эту таблицу изначально нужно разбить на несколько. Эта тема очень большая в двух словах не объяснишь. Ко всему надо еще знать смысл названия приведенных вами полей. А то не ясно к чему относится ДАТА ВВОДА и т.д.
Лучше почитать какую-нибудь книгу по проектированию базы данных (например Кренке "Проектирование баз данных").
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32807922
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Если это база данных для коммерческого использования, дешевле оплатить услуги специалиста по проектированию. Пересказывать в форуме правила проектирования - долго, дорого и незачем.

Кроме того, правильнее формулировать задачу более подробно, - плохо строить ответ на догадках.

Назовем для определенности Вашу таблицу my_table. ;)

> Субъект

Чего субъект? Федерации? Ссылка на соответствующую таблицу, если связь однозначная.

> Адрес

Таблица адресов, типы адресов, связь my_table с таблицей адресов n:m с учетом типа адреса.

> Телефон

Аналогично адресам. Факсы, e-mail'ы - здесь же.

> Организационно-правовая форма

Связь с таблицей организационно-правовых форм.

> Учредители
> Директор

Таблица физических лиц, таблица штатного расписания (правильнее использовать более сложную схему, связанную с организационно-правовыми формами), связь my_table с таблицей физических лиц n:m с учетом штатного расписания.

> Лицензия

Таблица лицензирующих органов, таблица лицензий, связь my_table с таблицей лицензий n:m с учетом лицензирующих органов.

> Тип учреждения (социальной службы):

Ссылка на классификатор, если классификация однозначная.

> Финансирование

Имеются в виду типы финансирования? Или абсолютные значения?

> Категория обслуживаемых

Судя по всему, таблица категорий, связь my_table с таблицей категорий n:m.

> Дата изменения
> Пользователь

Правильнее хранить историю изменений, а не последнее изменение.
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32807935
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Судя по названиям поля

Организационно-правовая форма
Учредители
Тип учреждения (социальной службы):
Финансирование
Категория обслуживаемых
Пользователь

скорее всего должны быть ссылками на другие таблицы
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32807969
AiSK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TanyaO
Таблицы даже изначально при проектировании (перед нормализацией) создаются таким образом, чтобы между полями существовала хоть какая-нибудь функциональная зависимость.
Например создать таблицу АДРЕС с полями
ID
город
улица
и т.д.
В этой таблице нельзя помещать данные не относящиеся к адресу.

Не совсем понятный совет (который мало согласуется с понятием нормализации - особенно "функциональная зависимость между полями").
Не вижу смысла создавать отдельную таблицу Адреса - ясно же , что адреса в таблице сведений об учреждениях повторяться не будут и никакой избыточности нет и в помине.
Таблица ДАННЫЕ О СУБЪЕКТЕ (ID,Субъект,Наименование,и т.д.) - если имеется в виду субъекты РФ, то хватит и двух полей - код субъекта (причем стандартный) и наименование, а впрочем.
Дата ввода - допустим, понятно, что это дата ввода записи.
Дата изменения - видимо дата посленего изменения.
Пользователь - вот это непонятно, имеется в виду оператор, который ввел запись?
Финансирование - непонятно.

Итого можно отдельно выделить таблицы (связанные с основной таблицей по первичному ключу) только :
- Субъекты РФ
- Перечень типов учреждений
- Перечень организационно-правовых форм
- Список пользователей
- Список категорий обслуживаемых ( и то непонятно, одна ли категория жестко закреплена за учреждением, если нет, то следует создавать таблицу - "Деятельность учреждения", по внешнему ключу Id_Учреждения связанному с таблицей учреждений)
"Количество обслуженных за год" - непонятно, определяется ли это количество из других таблиц, тогда да, можно определять каждый раз запросами, но ничего страшного, если и это поле будет (хотя и избыточно, но каждый раз при просмотре пересчитывать пациентов может и не стоит). С другой стороны, может ведь не быть таблицы обслуженных граждан, откуда можно запросом получить количество обслуженных, то есть чисто вводится статистика, поступающая из учреждений, тогда уж это поле необходимо. Опять же если учреждение обслуживает несколько категорий и нужна разбивка по категориям, то это поле будет в таблице "Деятельность учреждения"
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32808018
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Не вижу смысла создавать отдельную таблицу Адреса - ясно же , что адреса в
> таблице сведений об учреждениях повторяться не будут и никакой избыточности
> нет и в помине.

Хех, уважаемый дон представляет себе значение буквосочетания "количество информации"?
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32808150
AiSK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор Хех, уважаемый дон представляет себе значение буквосочетания "количество информации"?
Не беспокойтесь, имена Шэннон и Котельников мне кое-что говорят, хотя речь идет о скромной нормализации и вы могли изъясняться без обиняков (припугнуть священными именами Бойса и Кодда) и даже представляю, что такое КЛАДР, но использовать его для таких вещей - слишком уж нормально-академично, впрочем не впервой сталкиваюсь с такими товарищами "guest_20040621" - надуваем щеки, для расчета водопровода берем систему уравнений Навье-Стокса, путем логических упражнений сводим к уравнению Бернулли, далее справочник Идельчика по местным сопротивлениям. Но согласитесь, Навье-Стокс как звучит по сравнению с Идельчиком?

Если по существу, vitaliy14 все-таки не диссертацию пишет, под адрес у товарища тут отведено одно поле, если есть желание, можно разложить на Субъект РФ,Район,Город,Почтовый индекс,Населенный пункт,Улица,Дом, Корпус, Квартира.. связать с КЛАДР, но стоит ли овчинка выделки?
Если же для связи один к одному хотите сочинить таблицу Адресов, то вы только энтропию Вселенной увеличите без особой пользы.

Аналогично, всех учредителей можно связать со списками переписи населения РФ и реестор юридических лиц, ну а можно просто перечислить через запятую.
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32808213
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vitaliy14 , ты не тушуйся, не верь, что тебе тут говорят - нормальная таблица у тебя. Просто некоторые тут не понимают, что такое "функциональная зависимость",
что она, вообще говоря, в предметной области определяется, а не абстрактно-независимо.
Но вот дать совет по нормализации твоих данных, увы, невозможно - по той же причине. Нормализация базируется на функциональной записимости, а последняя определяется в рамках предметной области, в рамках условий использования данных. У тебя должно быть техническое задание , где прописано, как какие данные должны использоваться, и только прочитав его ты (или кто-то еще) сможет судить о том, насколько "нормализированны" твои таблицы, и вообще, как проектировать БД.
Так что, поскольку ТЗ высылать ты сюда вряд ли будешь, а если и вышлешь, то вряд ли кто-то прочитает его целиком и полностью, да еще и подумает над ним хорошенько, то , видимо, придется тебе уж самому как-то разбираться с нормализацией твоей таблицы. Ты не бойся - дорогу осилит идущий.
Успехов.
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32808242
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Не беспокойтесь, имена Шэннон и Котельников мне кое-что говорят
...
> именами Бойса и Кодда

Хм... приятно встретить начитанного оппонента. ;)

> даже представляю, что такое КЛАДР, но использовать его для таких вещей -
> слишком уж нормально-академично

Разочаровываете. КЛАДР имеет крайне примитивную структуру и вполне подходит для описанной задачи.

> /.../ надуваем щеки, для расчета водопровода берем систему уравнений
> Навье-Стокса /.../ далее по тексту

Хех, вот уже и ярлык прилепили. Ну-ну.

> под адрес у товарища тут отведено одно поле,

Уважаемый дон представляет себе количество геморроя при использовании одного поля для адреса?

> разложить на Субъект РФ,Район,Город,Почтовый индекс,Населенный
> пункт,Улица,Дом, Корпус, Квартира.. связать с КЛАДР, но стоит ли овчинка
> выделки?

В таком виде - конечно не стоит. Imho есть два варианта: 1. использовать КЛАДР (лучше - модифицированый; точнее, структуру, подобную КЛАДР), 2. использовать унифицированную структуру данных.

> Если же для связи один к одному хотите сочинить таблицу Адресов,

Хм... почему 1:1? Уважаемый дон представляет себе количество адресов, которое может иметь предприятие [не считая филиалов]?

> только энтропию Вселенной увеличите без особой пользы.

Я бы не был так категоричен относительно пользы.

> Аналогично, всех учредителей можно связать со списками переписи населения
> РФ

Хех, дружище, где сказано, что учредитель должен быть гражданином РФ?

> и реестор юридических лиц,

Можно. Если есть такая необходимость.

> ну а можно просто перечислить через запятую.

Конечно, можно. Но дешевле так не делать.
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32808243
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Второе, более практически полезное письмо.

Субъект, Финансирование - не понятно, что содержат поля. Комментарии невозможны.


Наименование, Директор, Штатная численность - без комментариев, OK.


Организационно-правовая форма

Тип учреждения (социальной службы):
- эти поля очевидно должны заполняться из соотв. справочников, т.е. быть ссылками.


Лицензия

Адрес

Телефон

Учредители

Факс

e-mail
- общее замечание - всего может быть по многу. Это потенциальное нарушение 1НФ - очень плохо. Особенно поле "Учредители" настораживает. Но однако если в вашей задаче будет использоваться только по одному экземпляру в соотв. поле, то это допустимо. "Лицензия" - на что ? Тоже множественность, и, видимо, еще и с требованием доп. атрибутов.


Категория обслуживаемых - не понятно, что содержит поле.

Количество обслуженных за год - за какой год ? Видимо, должна быть вообще отдельная таблица. Если "в среднем за год " - допустимо.


Дата ввода Дата изменения Пользователь - ну это чисто служебные поля, видимо. Обсуждать нечего.

Надеюсь, это поможет.
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32808442
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полностью согласен с MasterZiv
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32813501
Нафаня
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv
...
Телефон

Факс

e-mail
...



В принципе согласен.
Пойдем дальше. Эти поля запросто укладываются в табличку

ID (ключ)
Тип контакта (под справочником, как раз телефон, факс, ....)
Значение
...
Рейтинг: 0 / 0
Проблема с нормализацией данных
    #32815805
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну знаешь ли, вообще все эти атрибуты укладываются в отдельную табличку
IDобъекта НазваниеАтрибута ЗначениеАтрибута.

Вопрос в том, надо ли это автору вопроса.
...
Рейтинг: 0 / 0
14 сообщений из 14, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проблема с нормализацией данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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