Создание базы данных различными способами

Способы создания компьютерной базы данных

Что такое база данных

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

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

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

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

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

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

Способы создания компьютерной базы данных

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

· С помощью прикладной среды, например Visual Basic. Данный способ требует некоторых навыков работы в программных средах и навыков программирования. С его помощью можно создавать базы данных, требующие каких-то индивидуальных особенностей построения. Создание такой базы под силу только опытным пользователям.

· С помощью специальных программных сред, которые называются Системами Управления Базами Данных (СУБД). Работа с такими системами требует навыков работы с компьютером и может быть освоена пользователями в достаточно короткие сроки.

В настоящее время существует несколько видов СУБД. Наиболее известными и популярными СУБД являются Access, FoxPro и Paradox. Каждая из этих систем обладает своими достоинствами и недостатками. Остановим свой выбор на базе данных Access, которая входит в программный продукт Microsoft Office и является наиболее доступной для изучения в школьном курсе. Прежде чем переходить к работе по созданию базы данных на компьютере, необходимо перейти от информационной модели данных, к модели, ориентированной на компьютерную реализацию.

Источник

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

Вы будете перенаправлены на Автор24

Способы создания баз данных

Способы создания различных баз данных (БД) различаются. Например, в базах данных класса NoSQL (Redis, MongoDB) вообще нет понятия «создания». В них сразу можно вводить данные, а за их структуру будут отвечать специальным образом организованные «ключи», по которым и производятся выборки.

В реляционных, т.е. состоящих из взаимосвязанных таблиц, базах для создания компонентов БД следует выполнять команды на специальном языке SQL. Это требует от пользователей специальной подготовки (изучения этого языка).

Наиболее удобны с точки зрения быстрого создания реляционных БД офисные пакеты, такие как Microsoft Office, OpenOffice, LibreOffice и др. В них создание баз данных и наполнение их таблицами, формами, отчетами и другими объектами производится в визуальном режиме: с помощью меню, мыши и других комфортных средств. Лидером среди офисных баз данных является Microsoft Access. Рассмотрим особенности создания баз данных в этом приложении.

В этой статье рассматривается пример для Access из пакета Office-365. Для более ранних версий процесс аналогичен, но может различаться в деталях.

Варианты создания баз данных в Microsoft Access

Пустую базу данных можно создать в проводнике Windows, щелкнув правой кнопкой на пустом пространстве и выбрав «Создать. Базу данных Microsoft Access». Появится пустой файл (ему сразу же можно присвоить подходящее имя), который следует открыть двойным щелчком. Однако в современных версиях программы предусмотрены более эффективные способы выполнения этого действия.

Работа с шаблонами

Можно создать новую БД:

• из стандартного шаблона: несколько готовых шаблонов поставляются вместе с программой;
• из шаблона с сайта Office.com: там имеется обширная коллекция заготовок для баз данных различного назначения; их можно загружать по сети с помощью меню (вкладка «Создать»).

Рисунок 1. Варианты создания новой базы данных в MS Access. Автор24 — интернет-биржа студенческих работ

Готовые работы на аналогичную тему

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

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

С сайта Office.com можно загружать не только целые шаблоны, но и так называемые «части приложения» — связанные между собой компоненты, например, таблица и построенная на ее основе форма.

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

Создание пустой базы данных

Для создания пустой БД следует на вкладке «Файл» выбрать пункт «Создать» и вариант «Пустая база данных», затем указать имя файла. Access создаст БД с незаполненной таблицей «Таблица1». Она сразу же будет открыта в режиме таблицы. Для добавления данных нужно просто вводить их, отложив оптимизацию структуры колонок. Процесс ввода данных похож на работу с листом Excel.

Файл Blank.accdb в папке [диск установки]:\Program Files\Microsoft Office\Templates\1049\Access. используется как шаблон для всех новых локальных пустых баз данных. Все новые базы данных наследуют содержимое этого файла. Это отличный способ распространения содержимого по умолчанию.

Создание таблиц и других объектов БД

Открыв в режиме конструктора вновь созданную таблицу, можно построчно добавлять поля, давать им названия, присваивать типы и прочие свойства. Названия полей должны соответствовать предметной области. Например, если БД используется для учета книг, то в основной таблице следует предусмотреть такие поля, как «Название», «Автор», «Год издания» и т.п. Сами таблицы по окончании их создания тоже следует называть адекватными именами: «Книги», «Авторы», «Издательства» и т.п.

В конструкторе таблиц предусмотрены следующие характеристики полей:

1. размер: для текста это максимально допустимое количество сохраняемых в поле знаков; для числовых полей — варианты «Длинное целое», «Двойное с плавающей точкой» и др.;
2. формат поля — способ отображения данных (текст, число, дата);
3. маска ввода позволяет обеспечить корректность вводимых данных;
4. значение по умолчанию будет отображаться в поле при добавлении новой строки в таблицу;
5. обязательное поле — свойство, указывающее, обязательно ли вводить значение; невозможно будет добавить запись, если в обязательное поле не введено значение.

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

Рисунок 2. Схема данных, показывающая связи по ключевым полям между таблицами. Автор24 — интернет-биржа студенческих работ

Импортирование данных из других источников

Можно скопировать и вставить в таблицу Access данные из других офисных таблиц (Word, Excel). Для этого используется буфер обмена. При этом целесообразно проектировать таблицы БД так, чтобы типы данных в них соответствовали вставляемым. Другой эффективный способ — перенос данных их внешних файлов (текстовых, html, внешних источников) с помощью визардов импорта, которые позволяют контролировать процесс переноса: разбивает текст на колонки, пытается определить типы хранящихся в них данных и заголовки полей и т.п.

Рисунок 3. Импорт данных из внешнего файла. Автор24 — интернет-биржа студенческих работ

Создание запросов, форм, отчетов

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

Источник

Основы правил проектирования базы данных

Введение

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

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

Для начала, разберем создание базы данных в MS SQL Server для сервиса поиска соискателей на работу.

Этот материал можно перенести и на другую СУБД такую как MySQL или PostgreSQL.

Основы правил проектирования

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

Опишем более детально 7 формальных правил:

отношение один к одному:

1.1) с обязательной связью:

примером может выступать гражданин и его паспорт: у любого гражданина должен быть паспорт; паспорт один для каждого гражданина

Реализовать данную связь можно двумя способами:

1.1.1) в одной сущности (таблице):

Рис.1. Сущность Citizen

Здесь таблица Citizen представляет собой сущность гражданина, а атрибут (поле) PassportData содержит все паспортные данные гражданина и не может быть пустым (NOT NULL).

1.1.2) в двух разных сущностях (таблицах):

Рис.2. Отношение сущностей Citizen и PassportData

Здесь таблица Citizen представляет собой сущность гражданина, а таблица PassportData — сущность паспортных данных гражданина (самого паспорта). Сущность гражданина содержит атрибут (поле) PassportID, который ссылается на первичный ключ таблицы PassportData. В свою очередь сущность паспортных данных содержит атрибут (поле) CitizenID, которое ссылается на первичный ключ CitizenID таблицы Citizen. Поле PassportID таблицы Citizen не может быть пустым (NOT NULL). Также здесь важно поддерживать целостность поля CitizenID таблицы PassportData, чтобы обеспечить связь один к одному. Иными словами, поле PassportID таблицы Citizen и поле CitizenID таблицы PassportData должны ссылаться на одни и те же записи как если бы это была одна сущность (таблица), представленная в пункте 1.1.1.

1.2) с необязательной связью:

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

Реализовать данную связь можно двумя способами:

1.2.1) в одной сущности (таблице):

Рис.3. Сущность Person

Таблица Person представляет собой сущность человека, а атрибут (поле) PassportData содержит все его паспортные данные и может быть пустым (NULL).

1.2.2) в двух сущностях (таблицах):

Рис.4. Отношение сущностей Person и PassportData

Таблица Person представляет собой сущность человека, а таблица PassportData — сущность паспортных данных человека (самого паспорта). Сущность человека содержит атрибут (поле) PassportID, который ссылается на первичный ключ таблицы PassportData. В свою очередь сущность паспортных данных содержит атрибут (поле) PersonID, которое ссылается на первичный ключ PersonID таблицы Person. Поле PassportID таблицы Person может быть пустым (NULL). Здесь также важно поддерживать целостность поля PersonID таблицы PassportData. Это нужно, чтобы обеспечить связь один к одному. Поле PassportID таблицы Person и поле PersonID таблицы PassportData должны ссылаться на одни и те же записи как если бы это была одна сущность (таблица), показанная в пункте 1.2.1. Или же данные поля должны быть неопределенными, то есть, содержать NULL.

отношение один ко многим:

2.1) с обязательной связью:

примером могут выступать родитель и его дети. У каждого родителя есть как минимум один ребенок.

Реализовать данную связь можно двумя способами:

2.1.1) в одной сущности (таблице):

Рис.5. Сущность Parent

Таблица Parent представляет сущность родителя, а атрибут (поле) ChildList содержит информацию о детях. Данное поле не может быть пустым (NOT NULL). Обычно типом поля ChildList выступают неполно структурированные данные (NoSQL) такие как XML, JSON и т д.

2.1.2) в двух сущностях (таблицах):

Рис.6. Отношение сущностей Parent и Child

Таблица Parent представляет сущность родителя, а таблица Child — сущность ребенка. У таблицы Child есть поле ParentID, ссылающееся на первичный ключ ParentID таблицы Parent. Поле ParentID таблицы Child не может быть пустым (NOT NULL).

2.2) с необязательной связью:

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

Реализовать данную связь можно двумя способами:

2.2.1) в одной сущности (таблице):

Рис.7. Сущность Person

Таблица Parent представляет сущность родителя, а атрибут (поле) ChildList содержит информацию о детях. Данное поле может быть пустым (NULL). Обычно типом поля ChildList выступают неполно структурированные данные (NoSQL) такие как XML, JSON и т д.

2.2.2) в двух сущностях (таблицах):

Рис.8. Отношение сущностей Person и Child

Таблица Parent представляет сущность родителя, а таблица Child — сущность ребенка. У таблицы Child есть поле ParentID, ссылающееся на первичный ключ ParentID таблицы Parent. Поле ParentID таблицы Child может быть пустым (NULL).

2.2.3) в одной сущности со ссылкой на саму себя при условии, что у сущностей (таблиц) родителя и ребенка будут одинаковые наборы атрибутов (полей) без учета ссылки на родителя:

Рис.9. Сущность Person со связью на саму себя

Сущность (таблица) Person содержит атрибут (поле) ParentID, который ссылается на первичный ключ PersonID этой же таблицы Person и может содержать пустое значение (NULL).

Также данная реализация является примером реализации отношения «многие к одному» с необязательной связью.

отношение многие к одному:

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

отношение многие ко многим:

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

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

Рис.10. Отношение сущностей Person и RealEstate

Таблицы Person и RealEstate представляют соответственно сущности человека и недвижимости. Связываются данные сущности (таблицы) через сущность (таблицы) PersonRealEstate. Атрибуты (поля) PersonID и RealEstateID ссылаются на первичные ключи PersonID таблицы Person и RealEstateID таблицы RealEstate соответственно. Обратите внимание, что для таблицы PersonRealEstate пара (PersonID; RealEstateID) всегда является уникальной и потому может выступать первичный ключем для самой связующей сущности PersonRealEstate.

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

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

А где же семь формальных правил?

1. п.1 (п.1.1 и п.1.2) — первое и второе формальные правила
2. п.2 (п.2.1 и п.2.2) — третье и четвертое формальные правила
3. п.3 (аналогично п.2) — пятое и шестое формальные правила
4. п.4 — седьмое формальное правило

В тексте выше эти семь формальных правил объединены в четыре блока по функционалу.

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

Обратным процессом нормализации называется денормализация. Это упрощение построения запросов доступа к данным за счет укрупнения и вложенности сущностей (например, как было показано выше в пунктах 2.1.1 и 2.2.1 с помощью неполно-структурированных данных (NoSQL)).

Вот и вся суть правил проектирования баз данных.

А вы уверены, что поняли отношения в семи формальных правилах? Именно поняли, а не узнали? Ведь знать и понимать — две совершенно разных концепции.

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

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

Также, эти отношения могут меняться, переходя из один к одному к одному ко многим, многие к одному или многие ко многим. Обязательность связи может меняться или остаться неизменной.

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

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

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

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

Вы проследили, какие отношения были между субъектами, и как менялись эти отношения?
Давайте присмотримся внимательнее.

• Когда семья была полной, с несколькими детьми, отношение между родителями и детьми имело вид многие ко многим.
• Когда остались мать и дети, отношение между родителем и детьми стало один ко многим с обязательной связью. Однако, в любой семье, где может и не быть детей, это отношение будет таким же, но уже с необязательной связью.
• А вот со стороны детей отношение к родителю было как многие к одному с обязательной связью пока родителя не лишили родительских прав.
• Когда дети оказались в детском доме — отношение изменилось на многие к одному с необязательной связью.
• Когда у детей появились попечители, связь между ними стала многие ко многим: у каждого попечителя могут быть другие подопечные дети, а у каждого ребенка могут быть другие попечители (родители).

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

Читайте также:  Ягоды бархата способы применения

Надеюсь, теперь вы значительно приблизились к пониманию этих семи формальных правил.

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

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

Также вы увидите, что реализовать отношение можно разными способами, а сами отношения могут меняться. Модель (схема) базы данных — это «снимок» отношений между сущностями в определенный момент времени. Именно поэтому важно определить как сами сущности — образы объектов из реального мира или предметной области, так и их отношения между собой с учетом изменений в будущем.

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

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

Проектирование схемы базы данных для поиска соискателей на работу

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

Для начала, определим, что важно для сотрудников из компании, которые ищут кандидатов:

1.1) компании, где работал соискатель
1.2) позиции, которые ранее занимал соискатель в данных компаниях
1.3) навыки и умения, которыми соискатель пользовался в работе;
а также продолжительность работы соискателя в каждой компании на каждой позиции и длительность использования каждого навыка и умения

для технического специалиста:

2.1) позиции, которые занимал соискатель в данных компаниях
2.2) навыки и умения, которыми соискатель пользовался в работе
2.3) проекты, в которых участвовал соискатель;
а также продолжительность работы соискателя на каждой позиции и в каждом проекте, длительность использования каждого навыка и умения

Для начала выявим нужные сущности:

1. Сотрудник (Employee)
2. Компания (Company)
3. Позиция (должность) (Position)
4. Проект (Project)
5. Навык (Skill)

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

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

Рис.11. Схема базы данных для поиска соискателей на работу

Здесь таблица JobHistory выступает как сущность истории работы каждого соискателя. То есть, это резюме, которое педставляет отношения многие ко многим между сущностями сотрудник, компания, позиция и проект.

Проекты и навыки относятся друг другу как многие ко многим и потому связываются между собой через сущность (таблицу) ProjectSkill.

Когда вы понимаете отношения между субъектами и между субъектами и объектами — уже упомянутые семь формальных правил — эту или схожую схему можно реализовать «на коленке»: на листке бумаги, мене чем за час. И это еще с учетом усталости после плодотворного рабочего дня.

Здесь можно было упростить схему добавления данных, если «навыки» вложить в сущность «проекты» через неполно структурированные данные (NoSQL) в виде XML, JSON или просто перечислять названия навыков через точку с запятой. Но это бы усложнило выборку с группировкой по навыкам и фильтрацию по отдельным навыкам.

Подобная модель лежит в основе базы данных проекта Geecko.

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

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

Немного лирики

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

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

Вообще, я уверен, что эти отношения (семь формальных правил) выявил очень хороший психотерапевт, возможно — женщина. Это было очень давно, задолго до появления самого понятия информационных технологий. И самое интересное, что эти отношения живут вне базы данных и ИТ — последние лишь используют их для моделирования информационных систем.

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

Послесловие

Диаграммы для примеров были реализованы с помощью инструмента Database Diagram Tool for SQL Server. Однако, подобный функционал есть и в DBeaver.

Источник