Бизнес как создать базу данных

Создание новой базы данных

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

В окне Свойства подключения к базе в поле Сервер базы данных укажите локальный или сетевой сервер базы данных и нажмите на кнопку Новая…, чтобы открыть окно Новая база (Рис. 1).

В поле Имя новой базы введите имя базы данных. Для имени базы действуют следующие ограничения:

В поле Сервер лицензий укажите сервер, на котором будет выделяться лицензия для работы с базой данных.

От типа активированной лицензии на сервере лицензий зависит возможность подключения к базе данных пользователей с различными типами лицензий (см. Лицензирование).

После выбора сервера лицензий и ввода имени базы нажмите на кнопку ОК. Окно Новая база будет закрыто.

В окне Свойства подключения к базе в поле База данных будет отображено имя новой базы данных. В поле Пользовательское название базы будет по умолчанию подставлено значение из поля База данных. При необходимости измените название новой базы и нажмите на кнопку ОК. Новая база будет добавлена в список баз данных.

Нажатие на кнопку Отмена в окне Новая база прерывает процедуру создания новой базы данных и закрывает окно.

Источник

Проектирование Базы Данных. Лучшие практики

В преддверии старта очередного потока по курсу «Базы данных» подготовили небольшой авторский материал с важными советами по конструированию БД. Надеемся данный материал будет полезен для вас.

Базы данных повсюду: от простейших блогов и директорий до надежных информационных систем и крупных социальных сетей. Не настолько важно, простая или сложная база данных, насколько существенно спроектировать ее правильно. Когда база спроектирована бездумно и без четкого понимания цели, она не просто не эффективна, но и дальнейшая работа с базой будет реальным мучением, непроходимым лесом для пользователей. Вот несколько советов по конструированию базы данных, которые помогут создать полезный и простой в использовании продукт.

1. Определите, для чего таблица и какова ее структура

Сегодня такие методы разработки, как Scrum или RAD (быстрая разработка приложения), помогают ИТ-командам быстро разрабатывать базы данных. Однако, в погоне за временем очень велик соблазн погрузиться сразу в построение базы, смутно представляя, в чем же сама цель, какие должны быть конечные результаты.

Как будто команда нацелена на эффективную, скоростную работу, но это мираж. Чем дальше и быстрее погружаться вглубь проекта, тем больше потребуется времени, чтобы выявить и изменить ошибки в проекте базы.

Поэтому первое, что нужно решить — это определить цель для вашей базы данных. Для какого типа приложения разрабатывается база? Пользователь будет лишь работать с записями и нужно уделить внимание транзакциям или его больше интересует аналитика данных? Где база должна быть развернута? Будет ли она отслеживать поведение клиентов или же просто управлять отношениями между ними?

Чем раньше команда проектирования ответит на эти вопросы, тем мягче, плавнее пройдет процесс проектирования базы данных.

2. Какие данные выбрать для хранения?

Планируйте наперед. Мысли о том, что в будущем будет делать сайт или система, для которых проектируется база данных. Важно выходить за рамки простых требований технического задания. Только пожалуйста, не начинайте размышлять сразу обо всех возможных типах данных, которые когда-либо будет хранить пользователь. Лучше подумайте о том, смогут ли пользователи писать посты, загружать документы или фотографии или обмениваться сообщениями. Если это так, то в базе нужно выделить место под них.

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

Неизбежно потребности пользователей в рамках даже одного департамента будут конфликтовать. Если вы столкнетесь с этим, не бойтесь опереться на собственный опыт и найти компромисс, который устроит все стороны и будет удовлетворять конечной цели БД. Будьте уверенны: в будущем вам прилетит +100500 в карму и гора печенек.

3. Моделируйте данные с осторожностью

Есть несколько ключевых моментов, на которые стоит обратить внимание при моделировании данных. Как мы уже ранее говорили, от назначения базы данных зависит, какие методы использовать при моделировании. Если мы проектируем базу данных для оперативной обработки записей (OLTP), иными словами для их создания, редактирования и удаления, то используем моделирование транзакций. Если же база данных должна быть реляционной, то лучше всего применять многомерное моделирование.

Во время моделирования строятся концептуальные (CDM), физические (PDM) и логические (LDM) модели данных.

Концептуальные модели описывают сущности и типы данных, которые они включают, а также отношения между ними. Делите ваши данные на логические куски — так намного проще жить.
Главное — мера, не переусердствуйте.

Если сущность очень сложно классифицировать одним словом или фразой, то пришло время использовать подтипы (дочерние сущности).

Если же сущность ведет собственную жизнь, имеет атрибуты, которые описывают ее поведение и ее вид, а также отношения с другими объектами, то смело можно использовать не только подтип, но и супертип ( родительская сущность).

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

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

Затем Логическая модель данных сопоставляется с выбранной заранее платформой СУБД (системы управления базами данных) и получается Физическая модель. Она описывает способ физического хранения данных.

4. Используйте подходящие типы данных

Применение неправильного типа данных может привести к менее точным данным, трудностям в объединении таблиц, синхронизации атрибутов и к раздуванию размеров файлов.
Чтобы гарантировать целостность информации, атрибут должен содержать только приемлемые для него типы данных. Если в базу данных вносится возраст, то убедитесь, что в колонке хранятся целые числа из максимум 3 цифр.

Создавайте минимум пустых столбцов со значением NULL. Если вы создаете все столбцы как NULL, это грубая ошибка. Если же вам нужен пустой столбец для исполнения конкретной бизнес-функции, когда данные неизвестны или еще не имеют смысла, то смело создавайте. Ведь мы же не можем заранее заполнить столбцы “Дата смерти” или “Дата увольнения”, мы же не предсказатели тыкать пальцем в небо :-).

Большинство софта для моделирования (ER/Studio, MySQL Workbench, SQL DBM, gliffy . com) данных позволяет создавать прототипы областей данных. Так гарантируется не только правильный тип данных, логика приложения и хорошая производительность, но также и обязательное задание значения.

5. Предпочитайте естественное

Когда вы решаете, какой столбец в таблице выбрать в качестве ключа, всегда обращайте внимание, какие поля может редактировать пользователь. Никогда не выбирайте их в качестве ключа — плохая идея. Произойти может все что угодно, а вы должны гарантировать уникальность.

Лучше всего использовать естественный, или бизнес, ключ (natural key). Он имеет смысловое значение, так вы избежите дублирования в базе данных.

Если только бизнес-ключ не уникален (имя, фамилия, должность) и повторяется в разных строках таблицы или он должен изменяться, то первичным ключом стоит назначить сгенерированный искусственный, суррогатный ключ (artificial key).

6. Нормализуйте в меру

Чтобы эффективно организовать данные в БД, необходимо следовать набору рекомендаций и нормализовать базу данных. Существует пять нормальных форм, которым нужно следовать.
С помощью нормализации вы избежите избыточности и обеспечите целостность данных, использующихся в приложении или на сайте.

Как всегда, всего должно быть в меру, даже нормализации. Если в БД слишком много таблиц с одинаковыми уникальными ключами, то вы увлеклись и чрезмерно нормализовали базу данных. Излишняя нормализация негативно влияет на производительность базы данных.

7. Тестируйте пораньше, тестируйте почаще

Тестовый план и надлежащее тестирование должны быть частью проектирования базы данных.

Лучше всего тестировать базу данных путем Continuous Integration (непрерывной интеграции). Моделируйте сценарий “Один день из жизни базы данных” и проверяйте, все ли граничные случаи обрабатываются, какие взаимодействия пользователей вероятны. Чем раньше вы найдете баги, тем больше сэкономите и времени, и денег.

Это всего лишь семь советов, с помощью которых вы можете спроектировать отличную базу данных по производительности и эффективности. Если будете следовать им, вы избежите большинства головных болей в будущем. Эти советы — всего лишь верхушка айсберга в моделировании базы данных. Существует огромное число лайфхаков. Какими пользуетесь вы?

Источник

Как создать базу знаний, чтобы она стала «интеллектуальным активом» компании

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

В сентябре 2020 года я выступила спикером IV-й конференции «Управление корпоративными знаниями», проходившей в рамках недели корпоративного обучения. Мой мастер-класс «Как создать корпоративную базу знаний, чтобы она стала «интеллектуальным активом» компании» заинтересовал собравшихся, и я решила сделать из материалов выступления статью. Буду рада если текст поможет вам в работе. Буду рада, если кто-то из вас захочет в комментариях обсудить этот пост.

Источник

Универсального сценария «Как создать базу знаний», который бы подходил всем и всегда, нет и быть не может. Обусловлено это как разными подходами к организации баз, так и разными IT-инструментами. А вот общие требования, своеобразный cookbook, – как раз предмет моей статьи.

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

Написать понятно для всех

Текст статьи из базы знаний должен быть понятен всем, кто будет её читать. Притом понятен с первого прочтения, ибо скорее всего второй раз её читать просто не будут. Статья не должна быть слишком длинной или чрезмерно короткой. Материал должен быть изложен так, чтобы трактовки его содержания были однозначными, и не нужно было переводить с «бухгалтерского» или «IT-шного» на «человеческий».

Например, статья, описывающая решение типовой проблемы, написанная в стиле «… перед входом в личный кабинет очистите кэш», скорее всего вызовет вопросы, а вот если дополнить его алгоритмом очистки кэша, написанным «для вашей бабушки», то ответ будет понятен всем.

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

На первый взгляд, кажется, что достичь этого невозможно: если статья написана для «чайника», то погруженному в тему она будет избыточной, а если ориентироваться на профи, то «чайнику» потребуется «перевод». Как быть?

Есть много инструментов, помогающих решить проблемы. В Департаменте корпоративных систем ЛАНИТ мы используем три подхода.

1. Ревью от ведущего эксперта предметной области. Процесс направлен на повышение качества материалов базы знаний (далее БЗ). Суть в том, что эксперт проверяет корректность изложения материала, в том числе логичность и последовательность изложения.

2. Обратная связь от пользователей в виде оценки и предложений по расширению/сокращению/изменению формулировок, порядка изложения/структурирования и т. п. по результатам использования материала. Обратную связь могут оставить все заинтересованные. Предложения и пожелания прорабатываются. Технически это может быть реализовано в виде оценок ответов от пользователей, лайков, благодарностей и т. п.

3. Структурирование. Этот инструмент условно можно разделить на два типа воздействий:

• административное воздействие – регламентированный порядок изложения в едином стиле, порядок фиксации изменений, дополнений и т. п.;
• технические решения – использование макросов и надстроек, позволяющих раскрывать подробности и расшифровки только в случае, если в них есть необходимость. Это решает вопрос разного уровня подготовки читателей: для специалиста статья будет максимально коротко изложенной на языке профессиональных требований, а для новичка будет содержать расшифровки терминов и ссылки на статьи по смежным вопросам.

Например, статьи, описывающие алгоритм решения типовых проблем, у нас имеют вот такую структуру:

Всегда актуально

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

По сути, knowledge manager должен иметь свою систему мониторинга, в которой будут свои триггеры и четко описанные алгоритмы реагирования.

Например, для базы знаний службы поддержки информационной системы триггером будет служить выход новой версии, изменение законодательства и т. п. Разработка набора триггеров и действий при их наступлении, а также определение ответственных за их выполнение – задача, решение которой обеспечивает значительную долю успеха базы знаний.

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

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

Пример статусной модели:

Как не создать информационную «мусорку» вместо базы знаний

Статьи, отвечающие на неактуальные вопросы или имеющие узко сформулированные заголовки, – путь к созданию информационной «мусорки» вместо базы знаний. Заголовок, сформулированный недостаточно широко, означает, что в нужный момент найти такую статью смогут только те, кто знает, что она есть в базе знаний. Остальные начнут решать задачу с нуля и создадут на основании этого решения статью-дубль.

Например, заголовок «Шаблоны заявлений» вполне корректен, но сформулирован узко. Искать будет легче, если добавить в него ключевые слова и написать так: «Шаблоны заявлений: отпуск, отгул, удаленная работа, увольнение, перевод».

Решить проблему помогает статистика использования материалов базы знаний. Опираясь на статистику использования, мы можем найти редко используемые и либо отправить их в архив (если материал утратил актуальность), либо расширить, обеспечив популярность в дальнейшем.

Статьи, собранные по принципу Lego из констант и переменных, снижают затраты на базу знаний

Есть правило, к которому мы пришли не сразу, но которое значительно экономит время на поддержание актуальности базы знаний. Это правило – никакого дублирования! Информация фиксируется один раз, далее используются ссылки на нее. Технически есть масса возможностей «вживлять» константы в нужные места по тексту статьи так, чтобы читатель даже не знал о том, что статья как конструктор состоит из частей.

Почему «не летит»

Даже самая актуальная база знаний, содержащая ответы на все востребованные вопросы, может «не взлететь», если найти нужную информацию сложно.

Решить проблему поиска можно структурированием и многоуровневой классификацией. Причём классификация должна быть не только на уровне разделов каталога БЗ, но и с метками по разным тематикам (например, если у нас база знаний службы поддержки пользователей, то по темам, личным кабинетам и т.д.). Каждый пользователь может отобрать перечень статей по заданным критериям, используя форму расширенного поиска.

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

Мобильность — наше всё

Для мобильности и в силу популярности Telegram дополнительно развиваем чат-бота.

Бот реализован в Telegram и доступен с любого устройства пользователя. Уровень доступа к информации через бот соответствует уровню доступа к сервисам компании. По запросу ответ можно получить в том числе из wiki.

Каждый ответ можно оценить. Система оценок позволяет своевременно корректировать как ответы, так и классификаторы. Вопросы, ответы на которые найдены не были, собираются отдельно и выступают идеями для развития базы знаний.

Рассмотренные принципы – не исчерпывающий список требований к базе знаний, сформулированный за четыре года активной работы над несколькими проектами, в том числе над базой знаний службы поддержки большой государственной информационной системы. Кроме того, следует отметить, что все принципы и правила работают тогда, когда в базе знаний заинтересованы все её пользователи и авторы. Главные метрики для оценки заинтересованности — количество использованных в работе материалов и количество правок от каждого автора. Мой личный список требований постоянно расширяется и в последний год появляется всё больше нюансов к требованию структурирования статей. Охотно поделюсь им в следующей статье.

Источник