Таблица ведения объектов
Таблица ведения объектовСкачать файл - Таблица ведения объектов
Алексей Михайличенко, Королевство Дельфи. Если мы начали разработку базы данных для некоторой задачи, определились с набором схем, таблиц, полей, внешних ключей, то как нам следует называть все эти объекты, и зачем вообще нужно говорить о какой-то особой системе наименований? Проблема чем-то похожа на выбор имен для переменных при написании программного кода. Но разница в том, что в написании процедур мир давно уже пришел к идее локальных переменных, и их имена остаются на совести автора-программиста - согласуются только параметры вызова. А вот база данных - штука глобального характера. Имена таблиц и полей используются в процедурах обработки, в клиентских формах ввода, в отчетах. Стройная система имен позволит 'протащить' логику организации данных сквозь весь проект, сделать все его части более читабельными, за что вы получите немало благодарностей как от коллег по команде, так и от себя лично, когда вернетесь к задаче эдак через полгодика. Итак, какова бы ни была система имен, она должна решить следующие задачи: Единство именования программных единиц во всем проекте. Другими словами, нельзя допускать размножения сущностей без необходимости. Нередко проектировщики свято соблюдают этот принцип Оккама при моделировании 'внешних' данных, но напрочь игнорирую его во внутренней 'кухне'. Самодокументируемость структуры базы данных. Сформулировать это зыбкое понятие трудно, но без него работать еще труднее. Единообразие подачи информации пользователю. О конкретной цели статьи. Описываемая схема не является ни единственно правильной, ни вообще оптимальной в каком-либо смысле. Скорее это исторически сложившийся взгляд автора, применяемый лишь потому, что лучше хоть какая-то система, чем никакой. Основная цель - обсудить основные принципы и проблемы 'именования', и предложить один из вариантов. Если кто-то предложит лучше - буду рад. Выбор имени сущности Обычно в результате нормализации каждая таблица ассоциируется с неким объектом или событием реального мира - человеком, документом, посещением и т. При выборе имени сущности разумно придерживаться таких правил: Имя должно быть существительным полным, сокращенным либо аббревиатурой в единственном числе. Имя должно быть как можно короче. Оптимально - буквы, максимум до Имя должно быть уникальным в пределах базы данных. Имя должно быть мнемонически понятным проектантам без заглядывания в словарь но словарь такой хорошо бы составить. Желательно, чтобы имена не начинались и не заканчивались на другие имена сущностей. Нетрудно заметить, что все эти правила противоречат друг другу. И в инженерной практике это скорее правило, чем исключение. Чего стоит хотя бы идея плавающего танка Так что придется выкручиваться. Итак, почему как можно короче? Потому что на основании имени сущности мы будем 'лепить' другие идентификаторы. Они будут встречаться целыми списками в секциях FROM, WHERE. И если названия таблицы и пяти соединенных справочников будут несокращенными словами в символов, то это порадует лишь поклонников языка Шекспира, но успешно затуманит смысл простейших SQL-запросов. Требование уникальности понятно само собой. Стоит лишь заметить, что здесь нужно максимально учесть перспективы роста БД. Возможно, стоит набросать список сущностей, которые могут войти в БД в следующих версиях системы, даже если эта работа отдаленного будущего. Чтобы сделать имена понятными, нужно определиться - 'salary' или 'zarplata'? То есть в качестве имен сущностей можно использовать английские слова и сокращения, либо русские кстати, почему бы и не на других языках? Правило 4 ;- Кстати, неплохо использовать комбинации из двух понятий. Например 'группа пользователей' - 'ugroup', 'группа домов' - 'hgroup'. Другие же ратуют за то, что таблицы нужно называть множественным числом - streets, cities. И единого мнения быть не может. Дело в том, что если говорить об удобочитаемости SQL-запросов, вроде следующего: ИЗ городов, улиц '. Если вспомнить, что мы хотим использовать имя сущности также в программах обработки данных, где объектом работы становится именно 'единица' информации например в названии класса для хранения одной улицы TStreet, а затем в названии переменой-объекта objStreet1 , то разумнее остановиться на единственном числе как на стандарте. Но ведь в таблице все-таки живет множество сущностей! Для таблиц примем следующее волюнтаристское решение: Имя таблицы состоит из служебного префикса и имени сущности. Префикс Имя сущности Имя таблицы Название таблицы в целом как множества сущностей C STRTYPE тип улицы C STRTYPE Каталог типов улиц S STREET улица S STREET Справочник улиц R ABON абонент R ABON Реестр абонентов J CALCOP выч. Я предлагаю такие префиксы: C - Catalog, список. Самая безобидная форма жизни информации. Представляет собой простейший справочник из десятка пунктов чего-то неизменного, или почти неизменного. Структурирует некую фундаментальную природу вещей. Например, перечисляет типы улиц - 'улица', 'переулок', 'проезд', 'тупик', 'овраг'. Через пару лет построят в деревне первый проспект - добавим 'проспект'. Можно ввести дополнительные соглашения, приятные для программистов. Относительно большая таблица, выходящая за пределы простого каталога. Могут требовать инкрементального поиска, времязависимости, древовидных показов и чего угодно. Таблица объектов, для поголовного учета которых собственно предназначена система, например Абонентов, Приборов. Объекты интенсивно добавляются, редактируются, удаляются или иным образом помечаются как выведенные из учета. Таблицы, как правило, времязависимы. Объем таблиц может быть велик. Просмотр всей таблицы обычно не имеет смысла, из-за чего применяются специальный поиск и фильтрация, зависящие от прикладной специфики. Обычно такие таблицы слегка растут со временем, скажем, на несколько процентов в месяц. Растет линейно со временем жизни системы поэтому при больших объемах может понадобиться сбрасывание части информации в архив. Также используются для расчетов, отчетов. Разумеется, можно придумать и другие префиксы. Чем еще привлекает прибавление префиксов к единственному числу по сравнению с множественным числом - своей однозначностью. А если вы захотите поиском найти по всем файлам проекта фрагменты, где завязаны города, придется вспоминать этот нюанс. Не будем также забывать, что в качестве имен сущностей мы разрешили себе использовать сокращения и аббревиатуры. А в этом случае добавление 's' или 'es' вряд ли добавит ясности и читабельности. Будем считать, что с правилом именования таблиц мы определились. Разумеется, из любого правила есть исключения. Скажем, как именовать таблицы, отражающие связи 'много-ко-многим'? Возможны и другие исключения. Например scity - Справочник городов cityid Ид PK city name Название city area Площадь км2 city populcnt Население cstrtype - Список типов улиц strtypeid Ид PK strtype name Название sstreet - Справочник улиц городов 1 streetid Ид PK 2 cityid Город. Ид FK scity 3 strtypeid Тип улицы. Ид FK cstrtype 4 street name Название В зале слышны крики ревнителей минимализма и экономии символов. Мы видим, что в имени каждого поля таблицы участвует название сущности, то есть практически повторяется имя таблицы без префикса. Почему бы всегда не называть идентификаторы просто ID , названия - Name? Ведь в SQL-запросах есть возможность полной нотации имен, с указанием таблицы: Первое, на чем споткнется такой подход - внешние ключи. Пусть в списке типов улиц cstrtype ключ мы назвали ID , и ключ улицы тоже назвали ID. Как прикажете назвать поле номер 3 в таблице улиц sstreet , которое ссылается на тип улицы cstrtype? Но тогда получается, что в БД есть поля, содержащие одну и ту же информацию, а названные по-разному. Кто здесь хотел не плодить сущности без необходимости? К той же печке и пританцевали. Ну хорошо, не унимаются минималисты. А названия, и прочие неключевые поля? Их-то можно назвать просто Name? Назовем названия города, улицы и типа улицы просто Name, и составим запрос, выводящий 'Улица Ленина, Москва'. FROM scity, cstrtype, sstreet WHERE Три поля с одинаковыми названиями в результате запроса. Интересно, что на большинстве SQL-серверов ошибки выдано не будет, и строки данных будут правильны. Другие издевательски вернут набор данных с тремя одинаковыми полями - типа вам из погреба виднее, разбирайтесь. Редкий ClientDataSet не выдаст Access Violation от такого зрелища, не говоря уже о безнадежности задачи FieldByName. В этом месте обычно вспоминают о возможности SELECT cstrtype. Ну хорошо, умоляют последние минималисты. Обозначать принадлежность поля таблице надо. Но зачем же полное имя сущности повторять? Ведь зачем мы добавляем имя сущности в имя поля? Обеспечить уникальность полей в результатах запросов! А уникальность эта в общем виде должна работать в масштабах базы данных. Вот завтра выйдете на международный рынок, появится у вас понятие стран Country , и имя страны как сократите - опять 'CName'? Поэтому ставим вопрос ребром. Если вы можете сократить имя сущности до удобочитаемой и в то же время уникальной величины - так это сокращение и используйте изначально как имя сущности. Нет - используйте полное. Но везде одно и то же. С именем сущности в составе названия поля вроде бы разобрались. А что там за смысловой префикс, все эти -id, -name, -label, -area? Это собственно обозначения содержимого полей. Опять же произвольные английские либо латинизированно-русские слова и сокращения, минимальной длины и максимальной понятности, уникальные теперь уже в пределах таблицы. Но некоторые из них хорошо бы канонизировать, и заключить по ним дополнительные соглашения. Например, табельный номер сотрудника. Что еще сказать по названиям полей. Как уже было видно из примеров, при построении внешних ключей поля-ссылки на справочники cityid рекомендуется называть так же, как они называются в самих справочниках опять же за исключением множественных ссылок, рассмотренных ниже. Это красиво выглядит в статье, но отвратительно в программном коде, потому что в точечной нотации objStreet. Кроме того, подчеркивания плохо видны на некоторых шрифтах и на бумажных распечатках. Поэтому подчеркивания я использую редко. В Pascal достаточно придерживаться общепринятой венгерской нотации - начинать каждое слово с заглавной буквы: StreetName, а в SQL чаще всего пишут ключевые слова большими буквами, идентификаторы - в венгерской нотации или просто маленькими буквами. Здесь нужно следить, чтобы имена сущностей не пересекались с названиями таких полей, иначе служебные поля будут ошибочно 'мысленно привязаны' к какой-то нашей таблице. Множественные ссылки Иногда в базах данных встречается ситуация, требующая дополнения описанных правил. Рассмотрим пример - точки и вектор, имеющий начало и конец: Это тот редкий случай, когда я использую подчеркивание. Кроме того, те же дополнительные суффиксы придется использовать и при переобозначении выходных полей запроса, если придется объединять оба экземпляра справочника. Например, выведем список векторов с указанием координат начала и конца: Коварство ситуации заключается в том, что помимо очевидного случая две ссылки из одной таблицы на другую , мы можем прийти к той же проблеме на внешне благополучной схеме БД, если, начав путешествие из какой-либо таблицы по стрелкам внешних ключей, имеем возможность попасть в какой-либо справочник более чем одним путем. Если в каком-либо запросе мы захотим объединения всех промежуточных таблиц, опять придется разруливать варианты справочника. Если в процессе проектирования наклевывается ситуация с множественными ссылками, особенно более чем в двух вариантах - проверьте, не лучше ли заменить эту схему таблицей один-то-многим. Например, если у города есть руководитель мэрии, и председатель обкома партии: SCITY- справочник городов cityid CBSTYPE - виды начальников bstype id bstypename Название мэр, партийный лидер и т. Когда же разумно применять такое преобразование? Например, трудно представить себе, что у вектора появится третья вершина, или что у бухгалтерской проводки появится что-то кроме дебета и кредита - следовательно, таблица 1-N не нужна. А вот новые начальники в городе могут появиться запросто - например, военный комендант, если произойдет военный переворот, и командир партизанского военного округа, возглавляющий ему сопротивление. Баррикады, стрельба, переделка структуры БД Другие объекты базы данных Разумное наименование других объектов базы данных, таких как первичные, уникальные и внешние ключи, помогает прежде всего в отладке программ и импорте внешних данных, когда имя нарушенного ключа выводится в сообщении об ошибке. Текст ошибки станет понятен программисту, даже если ему продиктуют его по телефону. Кроме того, в перехвате ошибок можно отловить известные строки, и снабдить их понятными комментариями. Первичные ключи называем так: Как вы уже заметили, в рассмотренных примерах в каждой таблице есть первичный ключ, причем ключ суррогатный. В этом вопросе я являюсь поклонником мнения Анатолия Тенцера, высказанного в статье ' Естественные ключи против искусственных ключей '. Лучше всего, когда в первичном ключе всего одно поле. Еще один вопрос, который напрашивается после 'упорядочения' названий в БД - как автоматизировать использование этого богатства? К сожалению, не существует общепринятого способа сохранения таких метаданных для использования различными средами разработки. Все движения в этом направлении намертво завязаны на конкретные продукты Репозиторий в Delphi, системный словарь в PowerBuilder, конфигуратор в 1C, метаданные в Visual FoxPro , и все они обладают определенными ограничениями и неудобствами. Так что здесь есть о чем помечтать. ГиперХост — хостинг сайтов который Вы искали. Виртуальный хостинг, Аренда VPS серверов, Регистрация доменных имен, SSL сертификаты Все для Вашего сайта тут! Правила именования объектов базы данных Алексей Михайличенко, Королевство Дельфи 'Всякое приказание должно быть отдано в должное время, в должном месте, и в выражениях, исключающих двоякое толкование' Из Устава Петровских времен Обсуждаемый вопрос заключается в следующем. Название таблицы в целом как множества сущностей. SBOSS - справочник начальников один город - много начальников. Paint не будет удалён, а переместится в Windows Store Все про аренду автомобилей и каршеринг Отличный вариант для покупки серверов и сопутствующего оборудования Где купить SSL-сертификат? Решения 1cloud для повышения технологической эффективности бизнес-процессов вашей компании Colocation и аренда выделенных серверов: PR-акции, размещение рекламы — adv citforum. Пресс-релизы — pr citforum. Обратная связь Информация для авторов. Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.
Набор подсистем 'Умные таблицы'
Управление затратами в строительстве
Социологические исследования доверие
Офисмаг волгоград каталог товаров официальный сайт
Виды разрешённого использования земельных участков. Классификатор ВРИ - 2015
Держатель для пластиковых карт и очков
Как отличить оригинальный айфон 4 от подделки
Эликсир для растений своими руками