Нормализация информации

← →
Ega23 © (2008-02-17 10:19) [40]

Хочу напомнить, что далеко не у всех есть Фамилия, Имя и Отчество.
У монголов, например, нет фамилии. Только Имя и Отчество.
У каких-нибудь зимбабвийцев кроме основного имени может быть родовое и запасное.
И т.д.
Это я всё к тому, что специфику применения справочника тоже нужно учитывать.

← →
sniknik © (2008-02-17 13:08) [41]

> специфику применения справочника тоже нужно учитывать.
с нее вообще надо начинать, а не общие теории разводить.

у меня к примеру местная (для своей конторы) программа по учету работ, так там вообще никакого разделения на имена, фамилии, просто одно поле "ФИО" и пишут, что хотят... и какой смысл "парится" если всего таких записей 500шт (по количеству работников конторы), ну будет там небольшая денормализация, ну и что, все одно никаких поисков/группировок отдельно по именам/фамилиям не бывает, единственное где используется подставляется к основной таблице, показать кто заявку оформлял и выполнял (ну не ID же, т.е. ключ по сотруднику там показывать ;)). сортировка есть конечно если захотят по фамилии (т.к. ее забивают первой) но не пользуется, т.к. работа исключительно с группами по отделам/должностям а такого идиотизма как "посмотреть сколько сделано товарищами с именем Вася например ..." пока нет, и вряд ли будет, а если вдруг когда возникнет, на тот невероятный случай и будем "парится", а не заранее.

но если бы в программе список людей был основным, типа как общесоюзный справочник, или телефонный... тогда бы "моя" огранизация таблицы людей была бы ущербной т.к. там как раз поиск по "Васям" вполне естественен... типа "помню что Вася, помню что в 12й квартире, и вроде на улице Пушкина... ну вы выведите по первым 2м параметрам, если там немного то почитаю и по улицам вспомню..."

а вот так абстрактно, как в [0], к некой базе с неизвестно чем занимающейся..., имхо, бред. (как в общем то практически все абстрактное...)
хотя там у него проскакивало "сотни тысяч", т.е. всетаки больше на справочник по людям похоже, тут бред в естественном ключе... прямо показательный бред, как аргумент в споре естественный vs искусственный можно использовать.

← →
Ega23 © (2008-02-17 13:50) [42]

Кстати, я бы всё равно нормализацию по именам-фамилиям начал бы от миллиона человек делать.

← →
Sergey13 © (2008-02-17 13:55) [43]

2Альберт (15.02.08 17:45) [37]

> про 5 атрибутов, если не жалко времени по подробнее, плиз.

Если ПК одной таблицы состоит из 5 полей, то в ссылающейся на нее таблице должны быть те же 5 полей для ссылки на первую.

← →
sniknik © (2008-02-17 14:08) [44]

> Кстати, я бы всё равно нормализацию по именам-фамилиям начал бы от миллиона человек делать.
какая разница сколько там людей в базе если сама специфика справочника требует выборок/группировок по именам или фамилиям? будеш "вычленять" имя из общего поля?
главное всетаки не размер базы, а ее специфика. а вот если если на требования специфики можно "забить", ну не нужно там ничего "эдакого", то вторым уже размер, можно провести нормализацию только ради него...

← →
Anatoly Podgoretsky © (2008-02-17 14:26) [45]

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

← →
Anatoly Podgoretsky © (2008-02-17 14:28) [46]

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

← →
Sergey13 © (2008-02-18 08:51) [47]

ИМХО, экономия байтов тут еще тоже не доказана. Придется вводить индекс на это поле, который возможно по размеру будет сопоставим с данными. Плюс к этому он будет скорее всего весьма плохим индексом, так как на наиболее распространенные имена придется львиная доля данных, а следовательно избирательность индекса будет очень неоднородной.

← →
Альберт (2008-02-18 11:19) [48]

> Хочу напомнить, что далеко не у всех есть Фамилия, Имя и
> Отчество.
> У монголов, например, нет фамилии. Только Имя и Отчество.
>
> У каких-нибудь зимбабвийцев кроме основного имени может
> быть родовое и запасное.
> И т.д.
> Это я всё к тому, что специфику применения справочника тоже
> нужно учитывать.

Спасибо за хороший совет.

> хотя там у него проскакивало "сотни тысяч", т.е. всетаки
> больше на справочник по людям похоже,

Да, вы правы и он вырастет на порядок, постепенно.

> Плюс к этому он будет скорее всего весьма плохим индексом,
> так как на наиболее распространенные имена придется львиная
> доля данных, а следовательно избирательность индекса будет
> очень неоднородной.

Спасибо за хороший совет.

← →
ANB (2008-02-18 14:05) [49]

> Альберт (18.02.08 11:19) [48]

ИМХО :
Если уж прикручивать такую штуку, то только в качестве вспомогательного справочника. Никаких ссылок, имя по прежнему хранить в текстовом виде. И только по кнопке/сочетанию кнопок, выдавать в качестве доп. сервиса.
Очень похоже было сделано в АСУ Экспресс-2.

← →
Альберт (2008-02-18 14:21) [50]

Так я уже понял, еще после 36 поста. Но я отписываюсь, увидев новые советы знающих людей.

← →
Anatoly Podgoretsky © (2008-02-18 15:19) [51]

> то только в качестве вспомогательного справочника

А для этого не надо никаких отдельных таблиц, запрос distinct и в dbcombo его

← →
ANB (2008-02-18 15:51) [52]

> Anatoly Podgoretsky © (18.02.08 15:19) [51]

Ну это как репу почесать. Сейчас не великая проблема нарыть готовый справочник имен. А дистинкт будет значить, что только из ранее введенных предлагать будет. Во. Мысля.
дистинкт
юнион олл
справочник.

← →
AnSi_Sr (2008-02-18 20:25) [53]

Описанное выведение ФИО в справочнике - опасная тенденция в разработке архитектуры. Для любой мало-мальски сложной выборки при таком подходе очень быстро разрастается количество подзапросов или джойнов в селекте.

← →
Ega23 © (2008-02-19 10:00) [54]

Кстати, насчёт паспорта: у военных паспорта нет. Есть или Военный билет, или Удостоверение личности.

← →
ANB (2008-02-19 10:05) [55]

> у военных паспорта нет.

Уже есть. У офицеров и прапорщиков - на руках, у срочников отбирают при призыве.
Причем сначала выдавали по блату, потом по желанию, а потом многие структуры стали требовать только паспорт (это незаконно, но хрен кому чего докажешь) и народ начал получать уже практически принудительно.

← →
Альберт (2008-02-19 10:15) [56]

> Кстати, насчёт паспорта: у военных паспорта нет. Есть или
> Военный билет, или Удостоверение личности.

Мой пост

>
> для этой цели есть документ его заменяющий, причем в отдельной
> таблице.

← →
Альберт (2008-02-19 10:25) [57]

CREATE DOMAIN "CITY" AS VARCHAR(20) CHARACTER SET WIN1251;
CREATE DOMAIN "DOG" AS VARCHAR(10) CHARACTER SET WIN1251;
CREATE DOMAIN "HOME" AS VARCHAR(7) CHARACTER SET WIN1251;
CREATE DOMAIN "MYNAME" AS VARCHAR(15) CHARACTER SET WIN1251;
CREATE DOMAIN "POST" AS VARCHAR(5) CHARACTER SET WIN1251
CHECK ((VALUE >= "000" AND VALUE <= "99999")
OR (VALUE IS NULL));

CREATE TABLE "MAN_LIST"
(
"MAN_NAME_F" "CITY" NOT NULL,
"MAN_NAME_I" "DOG" NOT NULL,
"MAN_NAME_O" "MYNAME" NOT NULL,
"MAN_R_DATE" DATE,
"MAN_GOR_CODE" SMALLINT,
"MAN_STR_CODE" SMALLINT,
"MAN_B1" "HOME",
"MAN_B2" "HOME",
"MAN_ROOM" "HOME",
"MAN_P_COUNT" SMALLINT,
"MAN_P_NUMBER" SMALLINT,
"MAN_E_COUNT" SMALLINT,
"MAN_E_NUMBER" SMALLINT,
"MAN_JOB_CODE" SMALLINT ,
"MAN_ORG_CODE" SMALLINT,
"MAN_CODE" SMALLINT,
"MAN_POST" "POST",
"MAN_P_DATE" DATE,
"MAN_P_CODE" "DOG",
"MAN_P_POLICY" SMALLINT default 1,
"MAN_DOOR" SMALLINT default 1,
"MAN_DOOR_CODE" SMALLINT,
"MAN_R_COUNT" SMALLINT default 1,
"MAN_TEL_CODE" SMALLINT,
"MAN_MOB_CODE" SMALLINT,
"MAN_PST_CODE" SMALLINT,
"MAN_WRK_CODE" SMALLINT,
PRIMARY KEY ("MAN_NAME_F", "MAN_NAME_I", "MAN_NAME_O")
);

Ладно, вот такая структура пока есть.

← →
Sergey13 © (2008-02-19 10:33) [58]

> [57] Альберт (19.02.08 10:25)
> Ладно, вот такая структура пока есть.
Т.е. 4 дня и 50 постов обсуждения псу под хвост? 8-)

← →
Альберт (2008-02-19 10:39) [59]

> Т.е. 4 дня и 50 постов обсуждения псу под хвост? 8-)

Нет, она будет изменена.

← →
Sergey13 © (2008-02-19 10:58) [60]

> [59] Альберт (19.02.08 10:39)
> Нет, она будет изменена.

Ура! Мы сделали это! На когда запланировано это эпохальное событие (я в календаре отмечу красным)?

← →
DiamondShark © (2008-02-19 15:33) [61]

> Ладно, вот такая структура пока есть.

Ахтунг.

1. За капс -- убивать.
2. За подчёркивание -- вешать ногами вниз.
3. От MAN_ глаза пучит. Информационный шум.
4. Использование доменов -- шизофрения. Неужели "MAN_NAME_I" и "MAN_P_CODE" -- это однотипные данные с типом "DOG"?
5. Откуда такая шизофрения в типах атрибутов "MAN_NAME_F", "MAN_NAME_I", "MAN_NAME_O"?
6. За PRIMARY KEY ("MAN_NAME_F", "MAN_NAME_I", "MAN_NAME_O") -- колесовать без права переписки. Это не праймари кей, это северный пушной зверёк.
7. "MAN_TEL_CODE" SMALLINT, а если у меня пять телефонов?
8. _CODE означает ссылку по внешнему ключу? Тогда суффикс -- информационный шум.
9. "MAN_GOR_CODE" SMALLINT, "MAN_STR_CODE" SMALLINT, -- Нью-Йорк, проспект Калинина.

> Нет, она будет изменена.

Это не поможет. Она должна быть уничтожена.

← →
ANB (2008-02-19 16:00) [62]

> 2. За подчёркивание -- вешать ногами вниз.

Со всем согласен, кроме этого пункта. Чем так подчеркивание не угодило ?
Очень удобно выставлять Инит_Капс в форматалке и форматить запросы.

← →
Альберт (2008-02-19 17:04) [63]

> От MAN_ глаза пучит
- Согласно примеров

> За капс -- убивать.
- Так это с метаданных взято.

> Откуда такая шизофрения в типах атрибутов "MAN_NAME_F",
> "MAN_NAME_I", "MAN_NAME_O"?
- ну у каждого свои тараканы

> "MAN_GOR_CODE" SMALLINT, "MAN_STR_CODE" SMALLINT, --
> Нью-Йорк, проспект Калинина.

А почему бы нет, ... брайтон бич давно уже одесский... :)

> За подчёркивание -- вешать ногами вниз.

Как хочу так и ворочу.

← →
MsGuns © (2008-02-19 22:45) [64]

>PRIMARY KEY ("MAN_NAME_F", "MAN_NAME_I", "MAN_NAME_O")

Маленький Освенцим. Ни одного плюса, одни минуса и тучи не граблей, а бОрон как в отладке, так и (особенно !) при эксплуатации. Начиная от тормозов и заканчивая невозможностью ввести двух Ивановых Иван Иванычей

Остальное не комментирую - Шарк достаточно красочно описал.

← →
Сергей М. © (2008-02-20 10:41) [65]

> невозможностью ввести двух Ивановых Иван Иванычей

Ну отчего же ?

Если предобработки регистра символов вводимых данных нет, то запросто:

Первый - Иванов ИВан Иваныч
Второй - Иванов Иван Иваныч

Здесь автора скореее другая засада поджидает - ограничение на длину индексов по строковым полям.

← →
Павел Калугин © (2008-02-20 13:23) [66]

> [63] Альберт (19.02.08 17:04)

Если стремтитесь к нормализации то почему в одну структуру свалено нессколько сущностей?
в идеале , если речь действительно о нормализации надо сначала анализировать предметную область
я вот с трудом, ибо > [61] DiamondShark © (19.02.08 15:33) кроме пункта 2 верно, вижу следующее
сущности
Лицо,Документ, Адрес, Должность, Телефон номер
связи
владеет документом
проживает по адресу
работает по адресу
работает в должности
доступен по номеру
Если все это расписать грамотно, то получится вполне удобный справочник. В отличии от помойки из которой вынесены имена :)
Но чтобы это все описывать надо знать конкретную предметую область.
Так что рекомендую читать про модели "сущности-связи", Анализировать предмиетную область. И только после постороения такой модели, после ее нормализации приступать к "погружению" в БД

так что опять рав
> [61] DiamondShark © (19.02.08 15:33)

Уничтожить и начать с чистого листа

← →
Игорь Шевченко © (2008-02-20 16:31) [67]

> CREATE DOMAIN "DOG" AS VARCHAR(10) CHARACTER SET WIN1251;

Это имя собаки ?
А нафига ?

← →
Sergey13 © (2008-02-20 16:36) [68]

> [67] Игорь Шевченко © (20.02.08 16:31)

Она просто на собаку не откликается.

> Чем так подчеркивание не угодило ?

Ну не нравится оно мне ;) Шуму много, а толку мало, только глаза спотыкаются.

Впрочем, это сущие пустяки. Имена -- дело привычки, стиля и вкуса.
Всё это меркнет пред лицом ПК из трёх строковых полей.

DiamondShark © (20.02.08 23:46) [69]

> Всё это меркнет пред лицом ПК из трёх строковых полей.

Собственно, если на таблицу никто не ссылается и требуется уникальность, в этом нет криминала. Не к этому примеру, а вообще.

> [69] DiamondShark © (20.02.08 23:46)
> Всё это меркнет пред лицом ПК из трёх строковых полей.

особенно если учесть что из сочетание не уникально

> Так что рекомендую читать про модели "сущности-связи", Анализировать
> предмиетную область. И только после постороения такой модели,
> после ее нормализации приступать к "погружению" в БД

Вот именно.
Таблицв "Имена" возможна только в серьезном Филологическом НИИ занимающегося проблемами имяобразования в России.

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

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

Если же Ф.И.О. взято из какого-то аусвайс-а, то это именно атрибуты этого документа. Причем в разных они могут быть к тому же разными. В документе об образовании стоит, например, девичья фамилия, в свидетельстве о рождении написано Наталия, а в паспорте - Наталья.
К тому же из документа абсолютно неясно, Иван там стоит или ивАн (большая - ударная), а это извмните два разных объкты сущности "Имя" и где-то могут вылезти боком эти особенности

> К тому же из документа абсолютно неясно, Иван там стоит
> или ивАн (большая - ударная), а это извмните два разных
> объкты сущности "Имя" и где-то могут вылезти боком эти особенности

Да-да. Особенно увлекательно написание фамилии Щучкин в загранпаспорте.

← →
ANB (2008-02-22 17:25) [74]

> Собственно, если на таблицу никто не ссылается и требуется
> уникальность,

Я тоже так думал. До тех пор, пока не пришла необходимость ссылаться на линковку, на которую ну ни в жисть бы не подумал, что придется. С тех пор тока искусственные ключи. Причем целые. Гуиды тоже идут лесом.

> > Чем так подчеркивание не угодило ?
>
> Ну не нравится оно мне ;) Шуму много, а толку мало, только
> глаза спотыкаются.

Толк есть и очень прикольный. Когда форматишь запрос девелопером с настройкой ИнитКапс - очень клево получается.

> С тех пор тока искусственные ключи.

Эта...все оно хорошо, искусственные, в смысле синтетические, ключи..До тех пор, пока не взводится в догму. А оно, как известно учение Маркса всесильно, потому что верно.
В общем, первичный ключ на то и первичный, что однозначно определяет уникальные атрибуты записи в таблице. И если на то есть несинтетические ключи, а, например, искусственные типа некоего кода, то вполне разумно пользоватт именно этот код, а не вводить искусственные идентификаторы.

Я так думаю (с)

> Толк есть и очень прикольный. Когда форматишь запрос девелопером
> с настройкой ИнитКапс - очень клево получается.

Ни разу не форматил запрос девелопером, я даже не знаю, что такое девелопер. Да и запрос я не помню, когда форматил хоть чем-нибудь, кроме табов в текстовом редакторе.
Но это не суть.
Главное, что идентификаторы с подчёркиваниями очень сильно тормозят чтение. Для языков, вроде Паскаля, это не так страшно, потому что плотность идентификаторов на квадратный метр текста там небольшая. В SQL эта плотность раза в 2--3 больше. Кроме того, Паскаль императивный язык, и его естественно читать строчка за строчкой. SQL не императивный, и его приходится схватывать крупными блоками, что при ряби в глазах значительно труднее.

> В общем, первичный ключ на то и первичный, что однозначно
> определяет уникальные атрибуты записи в таблице. И если
> на то есть несинтетические ключи, а, например, искусственные
> типа некоего кода, то вполне разумно пользоватт именно этот
> код, а не вводить искусственные идентификаторы.

Вообще-то, речь тут больше о том, что приятнее иметь ПК атомарный. А естественный он или генномодифицированный -- дело шестнадцатое.

> DiamondShark (23.02.2008 01:06:16) [76]

И для Паскаля тоже в глазах рябит и идет отторжение кода. Это удел СИ подобных языков.

← →
Альберт (2008-02-23 18:28) [78]

> Это имя собаки ?
> А нафига ?

Нет, код человека, дословно /data of global/, пенсионный.
Если нет данных по паспорту, тогда сверка из пенсионной базы.

> Т.к. если в твоей системе найдется место дюжине квалифицированных
> филологов, которые, и только они, будут заполнять эту таблицу
> - вперед.
>
> Если же Ф.И.О. взято из какого-то аусвайс-а, то это именно
> атрибуты этого документа. Причем в разных они могут быть
> к тому же разными. В документе об образовании стоит, например,
> девичья фамилия, в свидетельстве о рождении написано Наталия,
> а в паспорте - Наталья.
> К тому же из документа абсолютно неясно, Иван там стоит
> или ивАн (большая - ударная), а это извмните два разных
> объкты сущности "Имя" и где-то могут вылезти боком эти особенности

Имена взяты с книги "Что имя твое значит", где представлены все славянские, греческие и германские их производные.

Но, как тут заметили имен узбеков, монгол и иже подобных здесь нет, потому как они мне не нужны.

> имен узбеков, монгол и иже подобных здесь нет, потому как
> они мне не нужны

Спасибо тебе, о великий, что всего через неделю, всего лишь на 78-м посту ты посвятил нас в свою великую тайну - узбеки и иже с ними в контору к вам будут не вхожи)

> ЮЮ © (21.02.08 04:55) [72]
> Если исходить из того, что таблица - это объект предметной
> области, то всякий его эккземляр не должен возникать неизвестно
> откуда

ну подумаешь, следующий вопрос будет по поиску дублей
:)

> Но, как тут заметили имен узбеков, монгол и иже подобных
> здесь нет, потому как они мне не нужны.

автор, а как же осетинские и якутские?

Нормализация информации Найти похожие ветки