В чем заключается построение модели данных

Учитель информатики

Сайт учителя информатики. Технологические карты уроков, Подготовка к ОГЭ и ЕГЭ, полезный материал и многое другое.

В чем заключается построение модели данных?

а) В чем заключается построение модели данных?

б) Что означает свойство целостности БД?

в) Какие данные следует добавить в БД приемной комиссии, если требуется учитывать преподавателей, принимающих экзамены, и деление абитуриентов на экзаменационные группы?

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

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

Ответ

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

б) Це́лостность ба́зы да́нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам.

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

Источник

ГДЗ по информатике 11 класс учебник Семакин параграф 6

1. а) Перечислите задачи, которые должна решать проектируемая информационная система « Приемная комиссия ».

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

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

задачи должна решать:

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

б) Какие информационные процессы происходят на различных этапах

приемной кампании в вузе?

в) Какая информация добавляется к базе данных на каждом этапе?

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

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

4. Этап зачисления в университет. Здесь нас будет интересовать окончательный список с информацией о том, кто из абитуриентов принят в университет, а кто — нет:

2. а) В чем заключается построение модели данных?

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

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

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

б) Что означает свойство целостности БД?

в) Какие данные следует добавить в БД приемной комиссии, если требуется учитывать преподавателей, принимающих экзамены, и деление абитуриентов на экзаменационные группы?

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

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

3. а) При проектировании БД были определены следующие отношения:

МАГАЗИН(НОМЕР _МАГ, ТИП, АДРЕС, ДИРЕКТОР, ТЕЛЕФОН)

ОТДЕЛ (НАЗВАНИЕ_ОТД, ЗАВЕДУЮЩИЙ, ТЕЛЕФОН)

ПРОДАВЕЦ (ТАБЕЛЬНЫЙ_НОМ, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО,

Являются ли эти отношения связанными? Добавьте всё, что необходимо

для их связи; изобразите схему БД в графическом виде.

Источник

Модели данных и концептуальное моделирование

Выше уже упоминалось, что схема создается с помощью некоторого языка определения данных. В действительности она создается на основе языка определения данных конкретной целевой СУБД. К сожалению, это язык относительно низкого уровня; с его помощью трудно описать требования к данным в масштабе всей организации так, чтобы созданная схема была доступна пониманию пользо­вателей самых разных категорий. В чем мы действительно нуждаемся, так это в описании схемы на некотором, более высоком уровне. Это описание будем назы­вать моделью Данных.

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

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

Объектные модели данных

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

Модели данных на основе записей

В модели на основе записей база данных состоит из нескольких записей фик­сированного формата, которые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фикси­рованную длину. Существуют три основных типа логических моделей данных на основе записей: реляционная модель данных ( relational data model ), сетевая мо­дель данных ( network data model ) и иерархическая модель данных ( hierarchical data model ). Иерархическая и сетевая модели данных были созданы почти на де­сять лет раньше реляционной модели данных, потому их связь с концепциями традиционной обработки файлов более очевидна.

Реляционная модель данных

Таблица 1. Пример описания сущности Branch в реляционной схеме

Таблица 2. Пример описания сущности Staff в реляционной схеме

Источник

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

Введение

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

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

Для начала, разберем создание базы данных в 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) в двух сущностях (таблицах):

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

Источник