Post #31

Так, с сущностями и атрибутами разобрались. Ну, мы с ними и так разбираемся, если составляем концептуальную модель, на чем обычно аналитик и останавливается. Но для проектирования нужно пойти дальше. Это у нас будет во-вторых: Домены атрибутов. Кропотливая работа, которую никто не любит. Домен = тип данных + ограничения. Ну, какие-то типы в лучшем случае накидаем, и самые очевидные ограничения пропишем, типа маски для телефона. Но и тут есть много подводных камней. Ограничения работают не только на ограничения, извините за тавтологию, но и на расширение. Не нужно вводить их искусственно. Особенно это касается длин текстовых полей, и оказывается довольно печальным, когда в них не влезают тексты, характерные для предметной области (примеры реальных текстов крайне важны и для дизайна, но тут почти все вопросы имеют двойное назначение — и для структуры данных, и для их корректного представления в интерфейсах). Неожиданностью могут стать длинные имена файлов. Да даже и имена и фамилии! В совсем, казалось бы простых случаях вы можете столкнуться со значением, вылезающим за рамки типичных значений домена. В институте в моей группе училась студентка с испанским традиционным ФИО из трех или четырех имен и двух фамилий. Уместит ли ваша БД такое и сможет ли она это вывести? (Дальше всех, кажется, в деле формального определения именования человека пошли с стандарте обмена медицинской информацией HL7 — там имя описывается структурой из 7 полей, три из которых являются списками и одно — ссылкой на контексты использования данного имения в отношении данного человека, которых тоже семь разных вариантов. Итого, у одного человека может быть 7 различных имен для использования в разных контекстах, и каждое "имя" представляет собой сложную структуру с суффиксами, префиксами, личными и семейными именами и их порядком следования. Да, и всё это в привязке к временному периоду, когда это имя являлось актуальным). Другой пример определения домена — даты. Вот, скажем, дата регистрации компании. Иногда может понадобиться для расчета льгот, скоринговой оценки или какого-нибудь контроля. Какой домен у этой даты? Ну, она не должна быть в будущем. А в прошлом? Знаете ли вы, что в Microsoft SQL Server минимальное значение для типа datetime — 1 января 1753 года? И когда в одну компанию пришла карточка досточтимого контрагента — частной компании с датой основания где-то в XVII веке, её просто не смогли ввести в базу данных? (Пример из реального проекта). Или вот при анализе образования московских учителей мы нашли как аксакалов, окончивших московский педагогический университет в первые века нашей эры (в 198, 203 и даже просто в 3 годах!), так и гостей из будущего, окончивших его же в 2201 или в 2118. Очень радостно за многотысячелетнюю историю московского педа, но, кажется на домен можно было бы и наложить какие-то ограничения и проверки при вводе. Даже с простыми типами данных иногда возникают вопросы. Какой тип должен иметь атрибут "число комнат в квартире"? Вроде бы очевидно, что это целое число, большее 0. Однако мы сразу же упираемся в понятие "свободная планировка", где и комнат-то никаких пока нет. И вроде не скажешь, что их 0. А если думать про ограничение сверху, то вроде разумно допустить 20... или 100... ну точно же не 1000?.. и тут выясняется, что это понятие "число комнат" вообще не очень четко определено. Если это число помещений, то их и в обычной двушке штук 6-8, и не все из них комнаты. Но это, кроме БТИ, мало кого интересует. А если это для поиска потенциальным покупателем, то в большой квартире ему, в общем-то, всё равно - 10 комнат или 11. И оказывается, что это вовсе и не целое число, а справочник из значений "свободная планировка", "1", "2", "3", "4", "5 и больше"... Вот такие неочевидные моменты при рассмотрении простой вроде бы вещи — домена атрибута, то есть — диапазона возможных значений. Если вам понравилось — ставьте реакцию, а я допишу вторую часть — что ещё нужно учесть и на какие вопросы должен ответить системный аналитик, чтобы дать нужную информацию для проектирования базы данных.